[OE-core] [thud] [PATCH] archiver.bbclass: Fix COPYLEFT_LICENSE_{IN, EX}CLUDE
Setting them to empty before inheriting copyleft_filter made them not getting their documented values there. Signed-off-by: Adrian Bunk --- meta/classes/archiver.bbclass | 3 --- 1 file changed, 3 deletions(-) diff --git a/meta/classes/archiver.bbclass b/meta/classes/archiver.bbclass index 0a9fe4fd1d..e321a0e362 100644 --- a/meta/classes/archiver.bbclass +++ b/meta/classes/archiver.bbclass @@ -23,9 +23,6 @@ #COPYLEFT_RECIPE_TYPES = 'target' # -# Don't filter the license by default -COPYLEFT_LICENSE_INCLUDE ?= '' -COPYLEFT_LICENSE_EXCLUDE ?= '' # Create archive for all the recipe types COPYLEFT_RECIPE_TYPES ?= 'target native nativesdk cross crosssdk cross-canadian' inherit copyleft_filter -- 2.11.0 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] archiver.bbclass: Fix COPYLEFT_LICENSE_{IN, EX}CLUDE
Setting them to empty before inheriting copyleft_filter made them not getting their documented values there. Signed-off-by: Adrian Bunk --- meta/classes/archiver.bbclass | 3 --- 1 file changed, 3 deletions(-) diff --git a/meta/classes/archiver.bbclass b/meta/classes/archiver.bbclass index 0a9fe4fd1d..e321a0e362 100644 --- a/meta/classes/archiver.bbclass +++ b/meta/classes/archiver.bbclass @@ -23,9 +23,6 @@ #COPYLEFT_RECIPE_TYPES = 'target' # -# Don't filter the license by default -COPYLEFT_LICENSE_INCLUDE ?= '' -COPYLEFT_LICENSE_EXCLUDE ?= '' # Create archive for all the recipe types COPYLEFT_RECIPE_TYPES ?= 'target native nativesdk cross crosssdk cross-canadian' inherit copyleft_filter -- 2.11.0 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [Openembedded-architecture] Dropping armv5 and armv5e tunes in 2.7
On Thu, Jan 03, 2019 at 02:01:42PM -0800, Khem Raj wrote: > Hello All > > You might have noticed a recent commit in gcc trunk > > https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=b232e6b58e3766bc66fe08fdb7bcba1bdadda8a2 > > Which removed support for deprecated -march=armv5 and armv5e, this > will be released along with gcc-9 release which is upcoming and we > might be able to add gcc9 to 2.7 release or 2.8 release for sure. > > We still have non-thumb tunes for armv5 and armv4 in our tune pack, I > would like to propose a patch to remove them. >... Note that gcc 9 does *not* remove non-thumb armv4 support. Non-thumb armv5/armv5e have been removed due to "have no known implementations". Non-thumb armv4 support was deprecated in gcc 6 together with armv2/armv3, but there are still people using recent gcc on StrongARM - which is non-thumb armv4. > Thanks > -Khem cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] Git commit process question.
On Mon, Apr 01, 2019 at 04:20:41PM -0700, akuster808 wrote: > > > On 4/1/19 4:02 PM, Richard Purdie wrote: > > On Mon, 2019-04-01 at 15:33 -0700, akuster808 wrote: > >> Hello, > >> > >> I have noticed a large number of git commits with no header > >> information being accepted. > > Can you be more specific about what "no header information" means? You > > mean a shortlog and no full log message? > Commits with just a "subject" and signoff. No additional information > > We tend to reference back to how the kernel does things. > > https://www.kernel.org/doc/html/latest/process/submitting-patches.html > These two sections in particular. > > > 2) Describe your changes > > Describe your problem. Whether your patch is a one-line bug fix or 5000 > lines of a new feature, there must be an underlying problem that > motivated you to do this work. Convince the reviewer that there is a > problem worth fixing and that it makes sense for them to read past the > first paragraph. >... The kernel does not have "upgrade foo to the latest upstream version" commits. With the Automatic Upgrade Helper this is a semi-automatic task, and most of the time there is no specific motivation other than upgrading to the latest upstream version. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] cogl: fix compile error with -Werror=maybe-uninitialized
On Tue, Apr 02, 2019 at 05:08:33PM +0800, changqing...@windriver.com wrote:
> From: Changqing Li
>
> fix below compile error with -Werror=maybe-uninitialized
>
> | ../../cogl-1.22.2/cogl/driver/gl/gles/cogl-driver-gles.c:217:17: error:
> 'gltype' may be used uninitialized in this function
> [-Werror=maybe-uninitialized]
> | *out_gltype = gltype;
> | ^~~~
> | ../../cogl-1.22.2/cogl/driver/gl/gles/cogl-driver-gles.c:213:22: error:
> 'glintformat' may be used uninitialized in this function
> [-Werror=maybe-uninitialized]
> | *out_glintformat = glintformat;
> | ~^
>...
Looking at the code, is this a failure that only happens with DEBUG_FLAGS?
> +--- a/cogl/driver/gl/gles/cogl-driver-gles.c
> b/cogl/driver/gl/gles/cogl-driver-gles.c
> +@@ -74,9 +74,9 @@ _cogl_driver_pixel_format_to_gl (CoglContext *context,
> + GLenum *out_gltype)
> + {
> + CoglPixelFormat required_format;
> +- GLenum glintformat;
> ++ GLenum glintformat = 0;
> + GLenum glformat = 0;
> +- GLenum gltype;
> ++ GLenum gltype = 0;
>...
Assigning random values to variables is a bug,
they do not even seem to be valid values for these variables.
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/6] Correct and improve the ARM tunings
On Tue, Apr 02, 2019 at 09:26:46PM +0100, Richard Purdie wrote: >... > "armv4t" is defined in the arm tune files to mean "add -march=armv4t" > which is the convention used throughout all the tune files. >... Unfortunately this is not true. OE has both armv7a and armv7at tunes. There is no armv7a without Thumb support, so no -march=armv7-at exists in gcc. Both armv7a and armv7at tunes pass the same march to gcc, but [1] is not true: Default to using the Thumb-2 instruction set for armv7a and above. The hardware supports Thumb-2 in any case, the actual difference between the armv7a and armv7at OE tunes is whether OE tells the compiler to generate ARM or Thumb-2 code. OE has both armv6 and armv6t tunes. There is no armv6 without Thumb support so no -march=armv6t exists in gcc. Some v6 support only Thumb-1 and some v6 support also Thumb-2, so what gcc does have is an -march=armv6t2. But OE lacks tunes for that. For matching the gcc options it would be correct to remove all armv6t and armv7at tunes that have no coresponding gcc options, and add armv6t2 tunes. And that's only for the legacy 32bit platforms. armv8 already has 21 feature modifiers in gcc 9, and while not all 2^21 or 3^21[2] combinations are valid the old tune approach won't scale for that. > Cheers, > > Richard cu Adrian [1] https://www.yoctoproject.org/docs/2.6/ref-manual/ref-manual.html#migration-2.6-miscellaneous-changes [2] enable/disable/default -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] cogl: fix compile error with -Werror=maybe-uninitialized
On Wed, Apr 03, 2019 at 10:29:08AM +0800, Changqing Li wrote:
>
> On 4/2/19 7:31 PM, Adrian Bunk wrote:
> > On Tue, Apr 02, 2019 at 05:08:33PM +0800, changqing...@windriver.com wrote:
> > > From: Changqing Li
> > >
> > > fix below compile error with -Werror=maybe-uninitialized
> > >
> > > | ../../cogl-1.22.2/cogl/driver/gl/gles/cogl-driver-gles.c:217:17: error:
> > > 'gltype' may be used uninitialized in this function
> > > [-Werror=maybe-uninitialized]
> > > | *out_gltype = gltype;
> > > | ^~~~
> > > | ../../cogl-1.22.2/cogl/driver/gl/gles/cogl-driver-gles.c:213:22: error:
> > > 'glintformat' may be used uninitialized in this function
> > > [-Werror=maybe-uninitialized]
> > > | *out_glintformat = glintformat;
> > > | ~^
> > > ...
> > Looking at the code, is this a failure that only happens with DEBUG_FLAGS?
> Yes, only happen with DEBUG_FLAGS
> > > +--- a/cogl/driver/gl/gles/cogl-driver-gles.c
> > > b/cogl/driver/gl/gles/cogl-driver-gles.c
> > > +@@ -74,9 +74,9 @@ _cogl_driver_pixel_format_to_gl (CoglContext *context,
> > > + GLenum *out_gltype)
> > > + {
> > > + CoglPixelFormat required_format;
> > > +- GLenum glintformat;
> > > ++ GLenum glintformat = 0;
> > > + GLenum glformat = 0;
> > > +- GLenum gltype;
> > > ++ GLenum gltype = 0;
> > > ...
> > Assigning random values to variables is a bug,
> > they do not even seem to be valid values for these variables.
>
> According to code logic, glformat and glintformat will assigned
> simultaneously and usually with same value,
But glformat has an assert later to ensure the 0 doesn't leak anywhere.
> and 0 mean invalid pixel format.
For pixel format 0 means COGL_PIXEL_FORMAT_ANY.
For glintformat I don't know what would happen if 0 is used.
> [snip]
>
> case COGL_PIXEL_FORMAT_DEPTH_24_STENCIL_8:
> glintformat = GL_DEPTH_STENCIL;
> glformat = GL_DEPTH_STENCIL;
> gltype = GL_UNSIGNED_INT_24_8;
> break;
>
> and for gtype, there also should be no problem according to the code logic.
According to the current code.
If some future change breaks the code, it would pass invalid data at
runtime instead of giving a compile warning.
> and the fix is just for eliminate the error when DEBUG_FLAGS is enabled.
Looking at the code, does passing --enable-maintainer-flags=no
to configure work around this gcc bug?
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] Git commit process question.
On Tue, Apr 02, 2019 at 03:46:14PM -0400, Tom Rini wrote: > On Tue, Apr 02, 2019 at 09:51:21AM +0300, Adrian Bunk wrote: > > On Mon, Apr 01, 2019 at 04:20:41PM -0700, akuster808 wrote: > > > > > > > > > On 4/1/19 4:02 PM, Richard Purdie wrote: > > > > On Mon, 2019-04-01 at 15:33 -0700, akuster808 wrote: > > > >> Hello, > > > >> > > > >> I have noticed a large number of git commits with no header > > > >> information being accepted. > > > > Can you be more specific about what "no header information" means? You > > > > mean a shortlog and no full log message? > > > Commits with just a "subject" and signoff. No additional information > > > > > > We tend to reference back to how the kernel does things. > > > > > > https://www.kernel.org/doc/html/latest/process/submitting-patches.html > > > These two sections in particular. > > > > > > > > > 2) Describe your changes > > > > > > Describe your problem. Whether your patch is a one-line bug fix or 5000 > > > lines of a new feature, there must be an underlying problem that > > > motivated you to do this work. Convince the reviewer that there is a > > > problem worth fixing and that it makes sense for them to read past the > > > first paragraph. > > >... > > > > The kernel does not have "upgrade foo to the latest upstream version" > > commits. > > > > With the Automatic Upgrade Helper this is a semi-automatic task, and > > most of the time there is no specific motivation other than upgrading > > to the latest upstream version. > > But since that's just filling in a template the body can also be a > template perhaps with useful AUH data (run at ... by ... ?) ? That would be more trivial than useful. And so far noone has stated any actual problem that would be solved by adding such a new requirement. > Tom cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] Remove the simd tune for armv8a
On Wed, Mar 20, 2019 at 07:56:45PM -0400, Khem Raj wrote: >... > Has need to turn it off then they should chime back > Since removing this just removes a detail which we can actually keep > without much effort Turning it off is the only part that would not be a nop, but this would require adding +nosimd. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] libcomps: put PV in filename
On Tue, Mar 26, 2019 at 11:20:17AM +0100, Martin Jansa wrote:
> On Tue, Mar 26, 2019 at 10:00:52AM +, Burton, Ross wrote:
> > On Tue, 26 Mar 2019 at 01:39, Khem Raj wrote:
> > > > This isn't a git snapshot recipe but a release that is fetched over it.
> > > > For
> > > > clarity, put the PV in the filename.
> > >
> > > I think its better to keep it as it is. since its easy to trace git log
> > > history.
> >
> > So should I be renaming gcc-8.3.bb to gcc_http.bb? If the argument is
> > that the filename should contain the transport protocol and PV is
> > embedded in the recipe so that git log is easier, we should be
> > applying that rule consistently.
>
> FWIW: I agree with Khem.
>
> http fetcher won't (usually) fetch different version just by changing 1
> variable inside the recipe and vice versa, renaming the recipe won't
> fetch different SRCREV with git.
Why should the name of the recipe depend on whatever fetcher is
currently used?
If the same gcc release would be fetched from the upstream SVN,
would you argue that the recipe has to be renamed to gcc_svn.bb?
> If someone wants to update SRCREV in libcoms to be 10 commits behind
> 0.1.10, is he expected to rename the recipe back to libcomps_git.bb and
> re-add the PV variable (with new +git${SRCPV} suffix)?
>
> I got used to "+git${SRCPV}" being dropped when the SRCREV matches
> exactly the git tag, but renaming the recipe and removing the PV seems
> too much, what is the benefit of doing that?
Is it actually a benefit to make it easy to switch from a release to
some random git snapshot?
This is not something that should happen frequently.
> It's not for clarity or
> easier maintenance (at least for me), because PV next to SRCREV makes
> much more sense to me (and helps people not to forget updating both at
> the same time).
There are not only developers, but also users.
It is valuable to see from the filename whether it is a release
(and which release it is) or some VCS snapshot.
Not having the release there also loses the ability to use either
gcc_%.bbappend or gcc_8.3.0.bbappend, which are suitable for
different situations.
> Regards,
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] libcomps: put PV in filename
On Wed, Mar 27, 2019 at 02:33:14PM +0100, Martin Jansa wrote: > On Tue, Mar 26, 2019 at 12:42:12PM +0200, Adrian Bunk wrote: >... > > Not having the release there also loses the ability to use either > > gcc_%.bbappend or gcc_8.3.0.bbappend, which are suitable for > > different situations. > > There is usually just one version per recipe and even with _git.bb > suffix you can easily do gcc_7+git.bb and gcc_8+git.bb if you need to. Thud contains 8.2 today, but might have 8.3 tomorrow. A layer might want to append only to one of them, or have different appends for different versions. That's trivial with gcc_8.2.bb and gcc_8.3.bb, and harder with gcc_8+svn.bb. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 3/8] blktool: update to 4-7.1
On Wed, Mar 27, 2019 at 03:09:17PM +0100, Alexander Kanavin wrote: > This update adds a patch from Debian to match the latest version there. >... > + file://0004-fix-ftbfs-glibc-2.28.patch \ > file://blktool-gnulib-makedev.patch \ >... That's 2 patches adding the same #include. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] musl thoughts
On Fri, Mar 22, 2019 at 02:11:35AM +0100, Andreas Müller wrote: >... > 3. Change our musl slightly: Many patches we currently have are > trivial. Missing headers or #defines for missing functions... So if we > add few headers > * Empty chunks for e.g >... > Some other ideas? Not upstreamable hacks aren't a long-term sustainable way, no matter where you do the patching. net/ethernet.h header problems are requiring 2 patches in NM. It would be good to get whatever is the actual root cause fixed properly, and that fix upstreamed. E.g. I wonder whether this was supposed to be fixed by 0001-if_ether-move-muslc-ethhdr-protection-to-uapi-file.patch Or is this patch in linux-libc-headers even the cause of the problem? linux-libc-headers applying 6 patches just for musl is not a good sign in any case. Is that much patching also done by other distributions that use musl? Why are these patches Upstream-Status: Pending/Submitted for a long time without having been applied upstream? Long-term it would be less work if everything would get fixed properly with fixes reviewed and applied by upstream. > Andreas >... cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [OE-Core][PATCH] wget: Convert EXTRA_OECONF to PACKAGECONFIG, extend PACKAGECONFIG
On Sat, Mar 23, 2019 at 08:29:51PM +, Alex Kiernan wrote: > Convert existing EXTRA_OECONF and DEPENDS to PACKAGECONFIG, fill out > remaining PACKAGECONFIG options. Note we pass in --without-libpsl, which > we didn't previously, but all this actually ends up doing is silencing a > warning from the configure script, the code still uses an internal > implemention when using this option. > > Signed-off-by: Alex Kiernan > --- > > meta/recipes-extended/wget/wget.inc | 17 - > 1 file changed, 12 insertions(+), 5 deletions(-) > > diff --git a/meta/recipes-extended/wget/wget.inc > b/meta/recipes-extended/wget/wget.inc > index 3cff656a68d9..99af039f417a 100644 > --- a/meta/recipes-extended/wget/wget.inc > +++ b/meta/recipes-extended/wget/wget.inc >... > -EXTRA_OECONF = "--with-ssl=gnutls --disable-rpath --disable-iri \ > ---without-libgnutls-prefix ac_cv_header_uuid_uuid_h=no" > +EXTRA_OECONF = "--without-libgnutls-prefix --without-libssl-prefix \ > +--disable-rpath ac_cv_header_uuid_uuid_h=no" >... > +PACKAGECONFIG[libuuid] = "--with-libuuid,--without-libuuid,util-linux" >... Can't the ac_cv_header_uuid_uuid_h hack be removed when this is now handled with PACKAGECONFIG? cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] musl thoughts
On Mon, Mar 25, 2019 at 04:36:44PM +0100, Andrea Adami wrote: > On Sat, Mar 23, 2019 at 11:00 PM Andreas Müller > wrote: > > > > On Sat, Mar 23, 2019 at 10:53 PM Adrian Bunk wrote: > > > > > > On Sat, Mar 23, 2019 at 10:22:15PM +0100, Andreas Müller wrote: > > > > On Sat, Mar 23, 2019 at 10:16 PM Adrian Bunk wrote: > > > > > > > > > > On Fri, Mar 22, 2019 at 03:18:01PM -0700, Khem Raj wrote: > > > > > >... > > > > > > There are certain design aspects of musl which are actually turning > > > > > > out to be good > > > > > > e.g. there is no __MUSL__ define, so non-portable code can not be > > > > > > hidden which is a good thing, > > > > > >... > > > > > > > > > > Please take a closer look at some of the musl changes to NM that made > > > > > upgrading NM so hard for Andreas. > > > > > > > > > > +#if defined(__GLIBC__) > > > > > #include > > > > > +#else /* musl libc */ > > > > > +#define ETH_ALEN 6 /* Octets in one ethernet > > > > > addr */ > > > > > +#endif >... > > Hi, Hi Andrea, > I am jumping in a little late to take side with Khem :) > > What happens now is that more 'bad' sources (written to suit glibc and > thus not portable) are discovered by the wider base of developers and > autobuilders. >... but this does not apply to this example, which is a problem between musl itself and the kernel headers. Code can expect #include to work for any headers, and with any order of these headers. If it does not, the 'bad' sources are whatever sources provide the headers in question. musl does provide net/ethernet.h, but including it causes a compile error here. > As Khem said, this just needs time and efforts to clean up and > upstream the patches. Any sane upstream will refuse such patches that add musl-specific hacks with the wrong define to work around problems in musl itself. > Cheers > Andrea cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/6] Correct and improve the ARM tunings
On Wed, Apr 03, 2019 at 12:29:29PM -0700, Andre McCurdy wrote: > On Tue, Apr 2, 2019 at 11:23 PM Adrian Bunk wrote: > > On Tue, Apr 02, 2019 at 09:26:46PM +0100, Richard Purdie wrote: > > >... > > > "armv4t" is defined in the arm tune files to mean "add -march=armv4t" > > > which is the convention used throughout all the tune files. > > >... > > > > Unfortunately this is not true. > > > > OE has both armv7a and armv7at tunes. > > > > There is no armv7a without Thumb support, > > so no -march=armv7-at exists in gcc. > > > > Both armv7a and armv7at tunes pass the same march to gcc, > > but [1] is not true: > > Default to using the Thumb-2 instruction set for armv7a and above. > > > > The hardware supports Thumb-2 in any case, the actual difference between > > the armv7a and armv7at OE tunes is whether OE tells the compiler to > > generate ARM or Thumb-2 code. > > > > OE has both armv6 and armv6t tunes. > > > > There is no armv6 without Thumb support > > so no -march=armv6t exists in gcc. > > > > Some v6 support only Thumb-1 and some v6 support also Thumb-2, > > so what gcc does have is an -march=armv6t2. > > But OE lacks tunes for that. > > > > For matching the gcc options it would be correct to remove all > > armv6t and armv7at tunes that have no coresponding gcc options, > > and add armv6t2 tunes. > > Aligning the tuning options exposed via the machine config files to > those supported by gcc seems like a worthy goal... but would be a big > upheaval at this point. > > Note that the problem isn't specific to ARM. There are similar issues > for x86, but there we seem happy to provide a very minimal abstraction > with no attempt to track gcc. e.g. "corei7" hasn't been a documented > -march option since gcc 4.8 and we (somewhat arbitrarily) map it to > -march=nehalem to hide that fact from end users. > > So the high level question seems to be: should DEFAULTTUNE even > attempt to provide a full featured mapping to the options provided by > gcc? Are we happy to expose a limited subset without a 1:1 mapping for > the options we do expose (current ARM approach) or is it better for > DEFAULTTUNE to hide away all the complexity of the options provided by > gcc (current x86 approach). The current 32bit ARM[1] approach seems to be an attempt of a 1:1 mapping. For ARMv8 it is already obvious that DEFAULTTUNE is not long-term maintainable, and duplicating all the gcc rules regarding feature flags[2] also sounds like a pointless exercise. What are actually the benefits of DEFAULTTUNE with all the tune files, compared to just let the user provide a string that is passed to -march? cu Adrian [1] ARM <= v7, not the differing 32bit ABI of ARMv8 [2] example: 'fp16fml' Enable FP16 fmla extension. This also enables FP16 extensions and floating-point instructions. This option is enabled by default for '-march=armv8.4-a'. Use of this option with architectures prior to Armv8.2-A is not supported. -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] cogl: fix compile error with -Werror=maybe-uninitialized
On Thu, Apr 04, 2019 at 10:06:44AM +0800, Changqing Li wrote: >... > And also upstream have use same way to fix under > cogl/driver/gl/gl/cogl-driver-gl.c > > https://gitlab.gnome.org/GNOME/cogl/commit/ca5226513eb64bceb38ca01994799c4e7cd9f5fa Have they? This looks like a 4 year old commit that was never merged. > so I think we can fix same way under this > cogl/driver/gl/gles/cogl-driver-gles.c cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/6] Correct and improve the ARM tunings
On Wed, Apr 03, 2019 at 01:48:04PM -0700, Andre McCurdy wrote: >... > If we let the user pass an arbitrary string to -march then we lose the > ability to determine that (for example) it's safe for a > "armv7athf-vfpv3" machine to pull from a "armv7athf-vfpv3d16" package > feed. For ARM <= v7 this is possible, except for bugs like the mentioned around thumb. With ARMv8 you end up duplicating everything gcc knows about architecture and feature flags for a cpu, and about all the interdependencies between features flags. It will also have to tell whether a cpu contains the optional support for the old ARMv7 32bit ABI, or only for the ILP32 variant of the ARMv8 ABI. > Whether or not anyone in the real world actually maintains a generic > package feed and pulls from it from multiple machine specific builds > (verses setting up separate package feeds for each DEFAULTTUNE they > care about) would be an interesting question... It would be good to look at what exactly has to be supported here, and the complexity involved. The simplest "generic" would be armv8.0 with no feature flags. If a generic "is tune A a superset of tune B" is required, you end up duplicating a lot of hardware information from gcc. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] bind: upgrade 9.11.5 -> 9.11.5-P4
Bugfix-only compared to 9.11.5, mostly CVE fixes.
COPYRIGHT checksum changed due to 2018 -> 2019.
Signed-off-by: Adrian Bunk
---
.../bind/{bind_9.11.5.bb => bind_9.11.5-P4.bb} | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
rename meta/recipes-connectivity/bind/{bind_9.11.5.bb => bind_9.11.5-P4.bb}
(96%)
diff --git a/meta/recipes-connectivity/bind/bind_9.11.5.bb
b/meta/recipes-connectivity/bind/bind_9.11.5-P4.bb
similarity index 96%
rename from meta/recipes-connectivity/bind/bind_9.11.5.bb
rename to meta/recipes-connectivity/bind/bind_9.11.5-P4.bb
index 67672792b1..1355841e6b 100644
--- a/meta/recipes-connectivity/bind/bind_9.11.5.bb
+++ b/meta/recipes-connectivity/bind/bind_9.11.5-P4.bb
@@ -3,7 +3,7 @@ HOMEPAGE = "http://www.isc.org/sw/bind/;
SECTION = "console/network"
LICENSE = "ISC & BSD"
-LIC_FILES_CHKSUM = "file://COPYRIGHT;md5=6ba7c9fe0c888a943c79c93e6de744fb"
+LIC_FILES_CHKSUM = "file://COPYRIGHT;md5=8f17f64e47e83b60cd920a1e4b54419e"
DEPENDS = "openssl libcap zlib"
@@ -22,8 +22,8 @@ SRC_URI =
"https://ftp.isc.org/isc/bind9/${PV}/${BPN}-${PV}.tar.gz \
file://0001-avoid-start-failure-with-bind-user.patch \
"
-SRC_URI[md5sum] = "17a0d02102117c9a221e857cf2cc8157"
-SRC_URI[sha256sum] =
"a4cae11dad954bdd4eb592178f875bfec09fcc7e29fe0f6b7a4e5b5c6bc61322"
+SRC_URI[md5sum] = "8ddab4b61fa4516fe404679c74e37960"
+SRC_URI[sha256sum] =
"7e8c08192bcbaeb6e9f2391a70e67583b027b90e8c4bc1605da6eb126edde434"
UPSTREAM_CHECK_URI = "https://ftp.isc.org/isc/bind9/;
UPSTREAM_CHECK_REGEX = "(?P9(\.\d+)+(-P\d+)*)/"
--
2.17.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] gnutls: upgrade 3.6.5 -> 3.6.7
This is a new upstream release from the same stable branch
bringing new features and bugfixes (including CVE fixes).
COPYING changed http -> https.
configure no longer has a --without-libunistring-prefix option.
Signed-off-by: Adrian Bunk
---
.../gnutls/{gnutls_3.6.5.bb => gnutls_3.6.7.bb}| 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
rename meta/recipes-support/gnutls/{gnutls_3.6.5.bb => gnutls_3.6.7.bb} (88%)
diff --git a/meta/recipes-support/gnutls/gnutls_3.6.5.bb
b/meta/recipes-support/gnutls/gnutls_3.6.7.bb
similarity index 88%
rename from meta/recipes-support/gnutls/gnutls_3.6.5.bb
rename to meta/recipes-support/gnutls/gnutls_3.6.7.bb
index dfc35079da..e05dc2b57d 100644
--- a/meta/recipes-support/gnutls/gnutls_3.6.5.bb
+++ b/meta/recipes-support/gnutls/gnutls_3.6.7.bb
@@ -9,7 +9,7 @@ LICENSE_${PN}-bin = "GPLv3+"
LICENSE_${PN}-openssl = "GPLv3+"
LIC_FILES_CHKSUM = "file://LICENSE;md5=71391c8e0c1cfe68077e7fce3b586283 \
-file://doc/COPYING;md5=d32239bcb673463ab874e80d47fae504 \
+file://doc/COPYING;md5=c678957b0c8e964aa6c70fd77641a71e \
file://doc/COPYING.LESSER;md5=a6f89e2100d9b6cdffcea4f398e37343"
DEPENDS = "nettle gmp virtual/libiconv libunistring"
@@ -21,8 +21,8 @@ SRC_URI =
"https://www.gnupg.org/ftp/gcrypt/gnutls/v${SHRT_VER}/gnutls-${PV}.tar
file://arm_eabi.patch \
"
-SRC_URI[md5sum] = "3474849e1bbd4d16403b82ab2579000b"
-SRC_URI[sha256sum] =
"073eced3acef49a3883e69ffd5f0f0b5f46e2760ad86eddc6c0866df4e7abb35"
+SRC_URI[md5sum] = "c4ac669c500df939d4fbfea722367929"
+SRC_URI[sha256sum] =
"5b3409ad5aaf239808730d1ee12fdcd148c0be00262c7edf157af655a8a188e2"
inherit autotools texinfo pkgconfig gettext lib_package gtk-doc
@@ -44,7 +44,6 @@ EXTRA_OECONF = " \
--enable-local-libopts \
--enable-openssl-compatibility \
--with-libpthread-prefix=${STAGING_DIR_HOST}${prefix} \
---without-libunistring-prefix \
"
LDFLAGS_append_libc-musl = " -largp"
--
2.17.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] gnutls: upgrade 3.6.5 -> 3.6.7
On Mon, Apr 08, 2019 at 08:08:08PM +0530, akuster808 wrote: > > > On 4/8/19 5:38 PM, Adrian Bunk wrote: > > This is a new upstream release from the same stable branch > > bringing new features and bugfixes (including CVE fixes). > > > > COPYING changed http -> https. > > > > configure no longer has a --without-libunistring-prefix option. > > Here is the same comment post earlier: > > this was regressing when attempted to be removed last time see > https://git.openembedded.org/openembedded-core/commit/?id=d8d32b5a58eea161711e3539c4530682de551ede > > Does it work when libunstring is installed on build host now ? >... Works for me, and the option no longer exists. This seems to be part of a a change to drop compatibility with ancient autoconf in gnulib, which might have fixed the original cross-building problem? cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] musl thoughts
On Fri, Mar 22, 2019 at 03:20:19PM -0700, Khem Raj wrote: > On Fri, Mar 22, 2019 at 1:03 PM Adrian Bunk wrote: > > > > On Fri, Mar 22, 2019 at 02:11:35AM +0100, Andreas Müller wrote: > > >... > > > 3. Change our musl slightly: Many patches we currently have are > > > trivial. Missing headers or #defines for missing functions... So if we > > > add few headers > > > * Empty chunks for e.g > > >... > > > Some other ideas? > > > > Not upstreamable hacks aren't a long-term sustainable way, > > no matter where you do the patching. > > > > net/ethernet.h header problems are requiring 2 patches in NM. > > > > It would be good to get whatever is the actual root cause fixed properly, > > and that fix upstreamed. > > > > E.g. I wonder whether this was supposed to be fixed by > > 0001-if_ether-move-muslc-ethhdr-protection-to-uapi-file.patch > > > > Or is this patch in linux-libc-headers even the cause of the problem? > > > > linux-libc-headers applying 6 patches just for musl is not a good sign > > in any case. > > Is that much patching also done by other distributions that use musl? > > Why are these patches Upstream-Status: Pending/Submitted for a long > > time without having been applied upstream? > > > > Long-term it would be less work if everything would get fixed properly > > with fixes reviewed and applied by upstream. > > agreed, meanwhile we have to also ensure that musl users keep going and make > it > possible, if OE devs are fixing musl related issues in upstream > packages then it is also good reputation for the project. >... Some of the NM patches are obviously just quick hacks to workaround bugs that are elsewhere. Trying to push such stuff upstream would not exactly improve the reputation. A problem with a "keep going" approach is that you might end up spending much work on working around symptoms, or even working around OE-specific bugs without noticing that they are OE-specific. Building an image (with things like NM included) for musl builds for me, and it also builds for me with all 6 musl patches not applied to the kernel headers. Are these patches still required at all? Could they be the cause of other musl related issues in OE? Patching leaf packages can create a huge mess if the core packages are not in a good state. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] musl thoughts
On Mon, Mar 25, 2019 at 10:44:28AM -0700, Khem Raj wrote: > On Sat, Mar 23, 2019 at 2:16 PM Adrian Bunk wrote: >... > > so that the workaround patches can be dropped from packages like NM? > > I think the right approach is to fix the problem where it belongs, and > generally making changes to headers > is a long term approach but is right one until then live with > temporary solutions. >... Many of the musl-specific header ordering restrictions could alternatively be resolved if there would be an #if defined(__MUSL__) in the linux/libc-compat.h kernel header to reliably disable conflicting declarations in the kernel headers. I wonder whether there is a better temporary solution by doing something like that in OE instead of having workaround hacks in various packages like NetworkManager. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] musl thoughts
On Mon, Mar 25, 2019 at 05:31:47PM +0100, Andrea Adami wrote: > On Mon, Mar 25, 2019 at 5:10 PM Adrian Bunk wrote: > > > > On Mon, Mar 25, 2019 at 04:36:44PM +0100, Andrea Adami wrote: > > > On Sat, Mar 23, 2019 at 11:00 PM Andreas Müller > > > wrote: > > > > > > > > On Sat, Mar 23, 2019 at 10:53 PM Adrian Bunk wrote: > > > > > > > > > > On Sat, Mar 23, 2019 at 10:22:15PM +0100, Andreas Müller wrote: > > > > > > On Sat, Mar 23, 2019 at 10:16 PM Adrian Bunk wrote: > > > > > > > > > > > > > > On Fri, Mar 22, 2019 at 03:18:01PM -0700, Khem Raj wrote: > > > > > > > >... > > > > > > > > There are certain design aspects of musl which are actually > > > > > > > > turning > > > > > > > > out to be good > > > > > > > > e.g. there is no __MUSL__ define, so non-portable code can not > > > > > > > > be > > > > > > > > hidden which is a good thing, > > > > > > > >... > > > > > > > > > > > > > > Please take a closer look at some of the musl changes to NM that > > > > > > > made > > > > > > > upgrading NM so hard for Andreas. > > > > > > > > > > > > > > +#if defined(__GLIBC__) > > > > > > > #include > > > > > > > +#else /* musl libc */ > > > > > > > +#define ETH_ALEN 6 /* Octets in one ethernet > > > > > > > addr */ > > > > > > > +#endif > > >... > > > > > > Hi, > > > > Hi Andrea, > > > > > I am jumping in a little late to take side with Khem :) > > > > > > What happens now is that more 'bad' sources (written to suit glibc and > > > thus not portable) are discovered by the wider base of developers and > > > autobuilders. > > >... > > > > but this does not apply to this example, which is a problem between > > musl itself and the kernel headers. > > > > Code can expect #include to work for any headers, and with any > > order of these headers. If it does not, the 'bad' sources are whatever > > sources provide the headers in question. > > > > musl does provide net/ethernet.h, but including it causes a compile > > error here. > > Adrian, > > I don't know in this specific case, you do surely know better about > kernel/headers than me :) > Strangely I remember one issue with net/if.h and netinet/in.h with > kexec-tools and musl: maybe there is really something too special with > those net headers. > > Switching the order of the headers did solve back then > https://git.openembedded.org/meta-openembedded/commit/meta-initramfs/recipes-kernel/kexec?id=b97358d5a3568deb2a5e939019bb2acef053e53f This changed the order between two headers that are both provided by musl. > Sorry for the OT This is not OT, this is a good example for a patch that is a workaround for some problem in musl (and not a generic portability fix). > Cheers > Andrea cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] musl thoughts
On Mon, Mar 25, 2019 at 06:15:40PM +0100, Andreas Müller wrote:
>...
> Looked into this. Found an old musl build failure of networkmanager
> [1] but I think the issue has not changed:
>
> | In file included from
> TOPDIR/build/tmp/work/mips32r2-yoe-linux-musl/networkmanager/1.14.4-r0/recipe-sysroot/usr/include/net/ethernet.h:10,
> | from ../NetworkManager-1.14.4/shared/n-acd/src/n-acd.c:28:
> |
> TOPDIR/build/tmp/work/mips32r2-yoe-linux-musl/networkmanager/1.14.4-r0/recipe-sysroot/usr/include/netinet/if_ether.h:111:8:
> error: redefinition of 'struct ethhdr'
> | struct ethhdr {
> | ^~
> | In file included from ../NetworkManager-1.14.4/shared/n-acd/src/n-acd.c:26:
> |
> TOPDIR/build/tmp/work/mips32r2-yoe-linux-musl/networkmanager/1.14.4-r0/recipe-sysroot/usr/include/linux/if_ether.h:167:8:
> note: originally defined here
> | struct ethhdr {
> | ^~
>
> glibc does not fail because it does include linux header
> | /* Get definitions from kernel header file. */
> | #include
> and does not define struct ethhdr
>
> linux/if_ether.h says:
> /* allow libcs like musl to deactivate this, glibc does not implement this. */
> #ifndef __UAPI_DEF_ETHHDR
> #define __UAPI_DEF_ETHHDR1
> #endif
>
> #if __UAPI_DEF_ETHHDR
> struct ethhdr {
> unsigned charh_dest[ETH_ALEN];/* destination eth addr*/
> unsigned charh_source[ETH_ALEN];/* source ether addr*/
> __be16h_proto;/* packet type ID field*/
> } __attribute__((packed));
> #endif
>
> musl does not include linux header but defines which is differen from
> what linux does:
> struct ethhdr {
> uint8_t h_dest[ETH_ALEN];
> uint8_t h_source[ETH_ALEN];
> uint16_t h_proto;
> };
> and later
> #define __UAPI_DEF_ETHHDR 0
>
> So for networkmanager there is either some wrong sequence or it
> includes linux headers.
musl headers providing own different definitions of kernel interfaces
is a problem in musl.
After reading [1] I think that this is musl upstream having made the
decision of not even trying to work properly with the kernel headers.
OE adding a not upstreamable patch that removes one of the two
definitions in musl builds might be the best available solution.
> And I am still not confident that it is our job to teach umpteen
> projects written for linux how to write portable code (oe-core has 147
> musl related patches and meta-openembedded has 140)...
>...
This is not about writing portable code, this is about problems with musl.
Using the Linux userspace headers is obviously not portable to non-Linux,
but many packages like NetworkManager are anyways Linux-only no matter
what you do.
> Andreas
cu
Adrian
[1] https://wiki.musl-libc.org/faq.html#Q:-Why-am-I-getting-
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] musl thoughts
On Mon, Mar 25, 2019 at 06:36:19PM +0100, Andreas Müller wrote: >... > Something to add - haven't yet looked into networkmanger: > > Do we have the chance to change the sequence of paths headers are searched for > > 1. musl > 2. linux > > That might fix some issues It would not. The headers are in different namespaces, order is defined solely by the order of #include statements in source and header files. > Andreas cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] musl thoughts
On Fri, Mar 22, 2019 at 03:18:01PM -0700, Khem Raj wrote: >... > There are certain design aspects of musl which are actually turning > out to be good > e.g. there is no __MUSL__ define, so non-portable code can not be > hidden which is a good thing, >... Please take a closer look at some of the musl changes to NM that made upgrading NM so hard for Andreas. +#if defined(__GLIBC__) #include +#else /* musl libc */ +#define ETH_ALEN 6 /* Octets in one ethernet addr */ +#endif Using __GLIBC__ in workarounds for bugs in musl is wrong, and cannot be upstreamed since it would do the wrong thing on other non-broken C libraries. > While the eyes may hurt > to see them, it does serve a > good reminder of whats needed for a given package. >... Who is responsible for fixing the root causes of such bugs in musl, so that the workaround patches can be dropped from packages like NM? cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] musl thoughts
On Sat, Mar 23, 2019 at 10:22:15PM +0100, Andreas Müller wrote: > On Sat, Mar 23, 2019 at 10:16 PM Adrian Bunk wrote: > > > > On Fri, Mar 22, 2019 at 03:18:01PM -0700, Khem Raj wrote: > > >... > > > There are certain design aspects of musl which are actually turning > > > out to be good > > > e.g. there is no __MUSL__ define, so non-portable code can not be > > > hidden which is a good thing, > > >... > > > > Please take a closer look at some of the musl changes to NM that made > > upgrading NM so hard for Andreas. > > > > +#if defined(__GLIBC__) > > #include > > +#else /* musl libc */ > > +#define ETH_ALEN 6 /* Octets in one ethernet addr */ > > +#endif > > > > Using __GLIBC__ in workarounds for bugs in musl is wrong, > > and cannot be upstreamed since it would do the wrong thing > > on other non-broken C libraries. > > > > > While the eyes may hurt > > > to see them, it does serve a > > > good reminder of whats needed for a given package. > > >... > > > > Who is responsible for fixing the root causes of such bugs in musl, > > so that the workaround patches can be dropped from packages like NM? > > > > cu > > Adrian > If I am not mistaken nobody is responsible. It is recipe wise: Sending > out a patch that fails for musl is rejected usually. As you have experienced, it does create a huge technical debt to ship workaround patches in several recipes instead of fixing the bug in musl. > The last example could be fixed easily at musl shipping a ethernet.h > containing > #define ETH_ALEN 6 >... That's already shipped by musl. But there seems to be some incompatibility between musl and the kernel headers used by musl. This has to be sorted out in musl and/or the kernel headers. > Andreas cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 01/12] virglrenderer: add a recipe
On Fri, Feb 22, 2019 at 08:11:27PM +0100, Alexander Kanavin wrote: > Probably this is the very first time virgl is built for mips :-) >... Builds fine in Debian: https://buildd.debian.org/status/package.php?p=virglrenderer > Alex cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/4] Introduce packagegroup-core-base-utils
On Fri, Mar 01, 2019 at 05:26:48PM -0500, Tom Rini wrote: >... > - busybox provides "nslookup" which at this point in time is an > anachronism. bind stopped shipping "nslookup" prior to oe-core replacing > the old monolithic layer. We do provide host and dig and such via > bind-utils. >... I'd say this is a bug in bind-utils. nslookup was was at some point deprecated by bind upstream, but it was undeprecated 15 years ago. > Tom cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] lighttpd: Use the upstream lighttpd.service
We shipped an old version that was missing several fixes.
A minor incompatibility is that this moves
/etc/lighttpd.conf -> /etc/lighttpd/lighttpd.conf
Signed-off-by: Adrian Bunk
---
meta/recipes-extended/lighttpd/lighttpd/lighttpd | 2 +-
meta/recipes-extended/lighttpd/lighttpd/lighttpd.service | 12
meta/recipes-extended/lighttpd/lighttpd_1.4.53.bb| 9 -
3 files changed, 5 insertions(+), 18 deletions(-)
delete mode 100644 meta/recipes-extended/lighttpd/lighttpd/lighttpd.service
diff --git a/meta/recipes-extended/lighttpd/lighttpd/lighttpd
b/meta/recipes-extended/lighttpd/lighttpd/lighttpd
index bf89a60b7d..82fbaa523b 100644
--- a/meta/recipes-extended/lighttpd/lighttpd/lighttpd
+++ b/meta/recipes-extended/lighttpd/lighttpd/lighttpd
@@ -4,7 +4,7 @@ PATH=/sbin:/bin:/usr/sbin:/usr/bin
DAEMON=/usr/sbin/lighttpd
NAME=lighttpd
DESC="Lighttpd Web Server"
-OPTS="-f /etc/lighttpd.conf"
+OPTS="-f /etc/lighttpd/lighttpd.conf"
case "$1" in
start)
diff --git a/meta/recipes-extended/lighttpd/lighttpd/lighttpd.service
b/meta/recipes-extended/lighttpd/lighttpd/lighttpd.service
deleted file mode 100644
index 66a907aa17..00
--- a/meta/recipes-extended/lighttpd/lighttpd/lighttpd.service
+++ /dev/null
@@ -1,12 +0,0 @@
-[Unit]
-Description=Lightning Fast Webserver With Light System Requirements
-After=network.target
-
-[Service]
-ExecStartPre=@SBINDIR@/lighttpd -t -f @SYSCONFDIR@/lighttpd.conf
-ExecStart=@SBINDIR@/lighttpd -D -f @SYSCONFDIR@/lighttpd.conf
-ExecReload=@BASE_BINDIR@/kill -HUP $MAINPID
-
-[Install]
-WantedBy=multi-user.target
-
diff --git a/meta/recipes-extended/lighttpd/lighttpd_1.4.53.bb
b/meta/recipes-extended/lighttpd/lighttpd_1.4.53.bb
index a58faa17be..a0b350f358 100644
--- a/meta/recipes-extended/lighttpd/lighttpd_1.4.53.bb
+++ b/meta/recipes-extended/lighttpd/lighttpd_1.4.53.bb
@@ -16,7 +16,6 @@ SRC_URI =
"http://download.lighttpd.net/lighttpd/releases-1.4.x/lighttpd-${PV}.t
file://index.html.lighttpd \
file://lighttpd.conf \
file://lighttpd \
-file://lighttpd.service \
file://0001-Use-pkg-config-for-pcre-dependency-instead-of-config.patch
\
"
@@ -57,13 +56,13 @@ INITSCRIPT_PARAMS = "defaults 70"
SYSTEMD_SERVICE_${PN} = "lighttpd.service"
do_install_append() {
- install -d ${D}${sysconfdir}/init.d ${D}${sysconfdir}/lighttpd.d
${D}/www/pages/dav
+ install -d ${D}${sysconfdir}/init.d ${D}${sysconfdir}/lighttpd
${D}${sysconfdir}/lighttpd.d ${D}/www/pages/dav
install -m 0755 ${WORKDIR}/lighttpd ${D}${sysconfdir}/init.d
- install -m 0644 ${WORKDIR}/lighttpd.conf ${D}${sysconfdir}
+ install -m 0644 ${WORKDIR}/lighttpd.conf ${D}${sysconfdir}/lighttpd
install -m 0644 ${WORKDIR}/index.html.lighttpd ${D}/www/pages/index.html
install -d ${D}${systemd_unitdir}/system
- install -m 0644 ${WORKDIR}/lighttpd.service
${D}${systemd_unitdir}/system
+ install -m 0644 ${S}/doc/systemd/lighttpd.service
${D}${systemd_unitdir}/system
sed -i -e 's,@SBINDIR@,${sbindir},g' \
-e 's,@SYSCONFDIR@,${sysconfdir},g' \
-e 's,@BASE_BINDIR@,${base_bindir},g' \
@@ -75,7 +74,7 @@ do_install_append() {
FILES_${PN} += "${sysconfdir} /www"
-CONFFILES_${PN} = "${sysconfdir}/lighttpd.conf"
+CONFFILES_${PN} = "${sysconfdir}/lighttpd/lighttpd.conf"
PACKAGES_DYNAMIC += "^lighttpd-module-.*"
--
2.11.0
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] busybox: enable CONFIG_FLOAT_DURATION
The 1.29.3 -> 1.30.1 upgrade lost support for sleep with float values (e.g. "sleep 0.1") since this replacement for CONFIG_FEATURE_FLOAT_SLEEP (enabled in thud) was missing. Signed-off-by: Adrian Bunk --- meta/recipes-core/busybox/busybox/defconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meta/recipes-core/busybox/busybox/defconfig b/meta/recipes-core/busybox/busybox/defconfig index a209eea5a1..493db28e86 100644 --- a/meta/recipes-core/busybox/busybox/defconfig +++ b/meta/recipes-core/busybox/busybox/defconfig @@ -83,7 +83,7 @@ CONFIG_NO_DEBUG_LIB=y # Library Tuning # # CONFIG_FEATURE_USE_BSS_TAIL is not set -# CONFIG_FLOAT_DURATION is not set +CONFIG_FLOAT_DURATION=y CONFIG_FEATURE_RTMINMAX=y # CONFIG_FEATURE_RTMINMAX_USE_LIBC_DEFINITIONS is not set CONFIG_FEATURE_BUFFERS_USE_MALLOC=y -- 2.11.0 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] bitbake.conf: Use -Og in DEBUG_OPTIMIZATION
On Tue, Feb 26, 2019 at 11:04:20PM -0800, Khem Raj wrote:
> -Og is for optimized debugging experience.
> this makes this consistent across different compilers especially gcc and
> clang, -O in clang is equal to -O2 where as in gcc its similar to -O1
> so it was not giving consistent debugging experience across compilers
>
> Signed-off-by: Khem Raj
> ---
> meta/conf/bitbake.conf | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
> index 1c5369ec98..758e89f126 100644
> --- a/meta/conf/bitbake.conf
> +++ b/meta/conf/bitbake.conf
> @@ -610,7 +610,7 @@ DEBUG_FLAGS ?= "-g -feliminate-unused-debug-types
> ${DEBUG_PREFIX_MAP}"
>
> # Disabled until the option works properly -feliminate-dwarf2-dups
> FULL_OPTIMIZATION = "-O2 -pipe ${DEBUG_FLAGS}"
> -DEBUG_OPTIMIZATION = "-O -fno-omit-frame-pointer ${DEBUG_FLAGS} -pipe"
> +DEBUG_OPTIMIZATION = "-Og -fno-omit-frame-pointer ${DEBUG_FLAGS} -pipe"
> SELECTED_OPTIMIZATION = "${@d.getVar(oe.utils.vartrue('DEBUG_BUILD',
> 'DEBUG_OPTIMIZATION', 'FULL_OPTIMIZATION', d))}"
> SELECTED_OPTIMIZATION[vardeps] += "FULL_OPTIMIZATION DEBUG_OPTIMIZATION
> DEBUG_BUILD"
> BUILD_OPTIMIZATION = "${@oe.utils.vartrue('DEBUG_BUILD', '-O -g
> -feliminate-unused-debug-types -fno-omit-frame-pointer', '-O2', d)} -pipe"
>^^
Another place that might have to be updated.
And the ref/dev-maunuals also need updating (they document -O as default).
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] bind-utils: Install nslookup
nslookup was undeprecated 15 years ago,
and installing bind-utils should replace the busybox version.
Signed-off-by: Adrian Bunk
---
meta/recipes-connectivity/bind/bind_9.11.5.bb | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/meta/recipes-connectivity/bind/bind_9.11.5.bb
b/meta/recipes-connectivity/bind/bind_9.11.5.bb
index 11990ee27e..67672792b1 100644
--- a/meta/recipes-connectivity/bind/bind_9.11.5.bb
+++ b/meta/recipes-connectivity/bind/bind_9.11.5.bb
@@ -73,8 +73,6 @@ do_install_prepend() {
do_install_append() {
- rm "${D}${bindir}/nslookup"
- rm "${D}${mandir}/man1/nslookup.1"
rmdir "${D}${localstatedir}/run"
rmdir --ignore-fail-on-non-empty "${D}${localstatedir}"
install -d -o bind "${D}${localstatedir}/cache/bind"
@@ -118,8 +116,12 @@ CONFFILES_${PN} = " \
${sysconfdir}/bind/db.root \
"
+ALTERNATIVE_${PN}-utils = "nslookup"
+ALTERNATIVE_LINK_NAME[nslookup] = "${bindir}/nslookup"
+ALTERNATIVE_PRIORITY = "100"
+
PACKAGE_BEFORE_PN += "${PN}-utils"
-FILES_${PN}-utils = "${bindir}/host ${bindir}/dig ${bindir}/mdig
${bindir}/nsupdate"
+FILES_${PN}-utils = "${bindir}/host ${bindir}/dig ${bindir}/mdig
${bindir}/nslookup ${bindir}/nsupdate"
FILES_${PN}-dev += "${bindir}/isc-config.h"
FILES_${PN} += "${sbindir}/generate-rndc-key.sh"
--
2.17.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/2] rng-tools: Make nistbeacon support optional
Downloading your randomness directly from the US government
is a rare usecase but adds heavy dependencies.
Make it optional and non-default.
Signed-off-by: Adrian Bunk
---
meta/recipes-support/rng-tools/rng-tools_6.6.bb | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/meta/recipes-support/rng-tools/rng-tools_6.6.bb
b/meta/recipes-support/rng-tools/rng-tools_6.6.bb
index d3361ae4e1..6796c9be9e 100644
--- a/meta/recipes-support/rng-tools/rng-tools_6.6.bb
+++ b/meta/recipes-support/rng-tools/rng-tools_6.6.bb
@@ -17,9 +17,7 @@ S = "${WORKDIR}/git"
inherit autotools update-rc.d systemd pkgconfig
-DEPENDS = "curl \
- libxml2 \
- openssl \
+DEPENDS = " \
sysfsutils \
"
@@ -28,6 +26,7 @@ PACKAGECONFIG_libc-musl = "libargp libjitterentropy"
PACKAGECONFIG[libargp] = "--with-libargp,--without-libargp,argp-standalone,"
PACKAGECONFIG[libgcrypt] = "--with-libgcrypt,--without-libgcrypt,libgcrypt,"
PACKAGECONFIG[libjitterentropy] =
"--enable-jitterentropy,--disable-jitterentropy,libjitterentropy"
+PACKAGECONFIG[nistbeacon] = "--with-nistbeacon,--without-nistbeacon,curl
libxml2 openssl"
# Refer autogen.sh in rng-tools
do_configure_prepend() {
--
2.17.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/2] rng-tools: Don't depend on libgcrypt when the PACKAGECONFIG is disabled
PACKAGECONFIG[libgcrypt] already adds it when necessary. Signed-off-by: Adrian Bunk --- meta/recipes-support/rng-tools/rng-tools_6.6.bb | 1 - 1 file changed, 1 deletion(-) diff --git a/meta/recipes-support/rng-tools/rng-tools_6.6.bb b/meta/recipes-support/rng-tools/rng-tools_6.6.bb index 4d91216e32..d3361ae4e1 100644 --- a/meta/recipes-support/rng-tools/rng-tools_6.6.bb +++ b/meta/recipes-support/rng-tools/rng-tools_6.6.bb @@ -21,7 +21,6 @@ DEPENDS = "curl \ libxml2 \ openssl \ sysfsutils \ - libgcrypt \ " PACKAGECONFIG ??= "libgcrypt libjitterentropy" -- 2.17.1 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] wpa-supplicant: Remove no longer required hack for libnl
Upstream already fixed this properly by using pkg-config.
Signed-off-by: Adrian Bunk
---
meta/recipes-connectivity/wpa-supplicant/wpa-supplicant_2.7.bb | 2 --
1 file changed, 2 deletions(-)
diff --git a/meta/recipes-connectivity/wpa-supplicant/wpa-supplicant_2.7.bb
b/meta/recipes-connectivity/wpa-supplicant/wpa-supplicant_2.7.bb
index 6fc5cf5db7..fe5fa2b82e 100644
--- a/meta/recipes-connectivity/wpa-supplicant/wpa-supplicant_2.7.bb
+++ b/meta/recipes-connectivity/wpa-supplicant/wpa-supplicant_2.7.bb
@@ -42,8 +42,6 @@ CONFFILES_${PN} += "${sysconfdir}/wpa_supplicant.conf"
do_configure () {
${MAKE} -C wpa_supplicant clean
install -m 0755 ${WORKDIR}/defconfig wpa_supplicant/.config
- echo "CFLAGS +=\"-I${STAGING_INCDIR}/libnl3\"" >> wpa_supplicant/.config
- echo "DRV_CFLAGS +=\"-I${STAGING_INCDIR}/libnl3\"" >>
wpa_supplicant/.config
if echo "${PACKAGECONFIG}" | grep -qw "openssl"; then
ssl=openssl
--
2.17.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] kmod: Remove compatibility for ancient hosts
Lack of be32toh() is handled upstream since 2014.
Linux 2.6.23 was released 2007, distributions with kernels
older than that are far outside the host distributions
still supported today.
Signed-off-by: Adrian Bunk
---
meta/recipes-kernel/kmod/kmod-native_git.bb | 3 --
meta/recipes-kernel/kmod/kmod.inc | 1 -
...g-bswap_-instead-of-htobe-and-be-toh.patch | 40 ---
.../kmod/kmod/fix-O_CLOEXEC.patch | 36 -
4 files changed, 80 deletions(-)
delete mode 100644
meta/recipes-kernel/kmod/kmod/Change-to-calling-bswap_-instead-of-htobe-and-be-toh.patch
delete mode 100644 meta/recipes-kernel/kmod/kmod/fix-O_CLOEXEC.patch
diff --git a/meta/recipes-kernel/kmod/kmod-native_git.bb
b/meta/recipes-kernel/kmod/kmod-native_git.bb
index f0e274ed79..f61134bbaf 100644
--- a/meta/recipes-kernel/kmod/kmod-native_git.bb
+++ b/meta/recipes-kernel/kmod/kmod-native_git.bb
@@ -7,9 +7,6 @@ DEPENDS += "zlib-native"
inherit native
-SRC_URI += "file://Change-to-calling-bswap_-instead-of-htobe-and-be-toh.patch \
- "
-
do_install_append (){
for tool in depmod insmod lsmod modinfo modprobe rmmod
do
diff --git a/meta/recipes-kernel/kmod/kmod.inc
b/meta/recipes-kernel/kmod/kmod.inc
index 6d0e031c6f..e68860f6b4 100644
--- a/meta/recipes-kernel/kmod/kmod.inc
+++ b/meta/recipes-kernel/kmod/kmod.inc
@@ -21,7 +21,6 @@ PV = "26"
SRC_URI = "git://git.kernel.org/pub/scm/utils/kernel/kmod/kmod.git \
file://depmod-search.conf \
file://avoid_parallel_tests.patch \
- file://fix-O_CLOEXEC.patch \
"
S = "${WORKDIR}/git"
diff --git
a/meta/recipes-kernel/kmod/kmod/Change-to-calling-bswap_-instead-of-htobe-and-be-toh.patch
b/meta/recipes-kernel/kmod/kmod/Change-to-calling-bswap_-instead-of-htobe-and-be-toh.patch
deleted file mode 100644
index 0ec20fad99..00
---
a/meta/recipes-kernel/kmod/kmod/Change-to-calling-bswap_-instead-of-htobe-and-be-toh.patch
+++ /dev/null
@@ -1,40 +0,0 @@
-From 38d6871d9c98e0080426ea375e390728485b2bc2 Mon Sep 17 00:00:00 2001
-From: Ting Liu
-Date: Tue, 10 Sep 2013 06:00:20 +
-Subject: [PATCH] Change to calling bswap_* instead of htobe* and be*toh
-
-We can't use htobe* and be*toh functions because they are not
-available on older versions of glibc, For example, shipped on Centos 5.5.
-
-Change to directly calling bswap_* as defined in+byteswap.h.
-
-Upstream-Status: Inappropriate
-
-Signed-off-by: Ting Liu
-Signed-off-by: Chen Qi
-
- libkmod/libkmod-signature.c | 3 ++-
- 1 file changed, 2 insertions(+), 1 deletion(-)
-
-diff --git a/libkmod/libkmod-signature.c b/libkmod/libkmod-signature.c
-index 48d0145..dd2c6fa 100644
a/libkmod/libkmod-signature.c
-+++ b/libkmod/libkmod-signature.c
-@@ -18,6 +18,7 @@
- */
-
- #include
-+#include
- #include
- #ifdef ENABLE_OPENSSL
- #include
-@@ -343,7 +344,7 @@ bool kmod_module_signature_info(const struct kmod_file
*file, struct kmod_signat
- modsig->hash >= PKEY_HASH__LAST ||
- modsig->id_type >= PKEY_ID_TYPE__LAST)
- return false;
-- sig_len = be32toh(get_unaligned(>sig_len));
-+ sig_len = bswap_32(get_unaligned(>sig_len));
- if (sig_len == 0 ||
- size < (int64_t)(modsig->signer_len + modsig->key_id_len + sig_len))
- return false;
diff --git a/meta/recipes-kernel/kmod/kmod/fix-O_CLOEXEC.patch
b/meta/recipes-kernel/kmod/kmod/fix-O_CLOEXEC.patch
deleted file mode 100644
index 07e4a1f538..00
--- a/meta/recipes-kernel/kmod/kmod/fix-O_CLOEXEC.patch
+++ /dev/null
@@ -1,36 +0,0 @@
-From 5f55e6806cd8ae1a6c8ec1e6cb38ad292cfc1df9 Mon Sep 17 00:00:00 2001
-From: Robert Yang
-Date: Wed, 22 Jan 2014 01:06:40 -0500
-Subject: [PATCH] libkmod/libkmod-internal.h: check whether O_CLOEXEC is
- defined or not
-
-O_CLOEXEC is introduced from Linux 2.6.23, so old kernel doesn't have
-it, we need check before use.
-
-This patch is much more like a workaround, since it may need fcntl() use
-FD_CLOEXEC to replace.
-
-This problem was reported by "Ting Liu "
-Signed-off-by: Robert Yang
-
-Upstream-Status: Pending
-
- libkmod/libkmod-internal.h | 4
- 1 file changed, 4 insertions(+)
-
-diff --git a/libkmod/libkmod-internal.h b/libkmod/libkmod-internal.h
-index a65ddd1..a4f4b77 100644
a/libkmod/libkmod-internal.h
-+++ b/libkmod/libkmod-internal.h
-@@ -10,6 +10,10 @@
-
- #include "libkmod.h"
-
-+#ifndef O_CLOEXEC
-+#define O_CLOEXEC 0
-+#endif
-+
- static _always_inline_ _printf_format_(2, 3) void
- kmod_log_null(struct kmod_ctx *ctx, const char *format, ...) {}
-
--
2.17.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] gdb: Upgrade 8.2 -> 8.2.1
Signed-off-by: Adrian Bunk
---
meta/recipes-devtools/gdb/{gdb-8.2.inc => gdb-8.2.1.inc} | 4 ++--
...{gdb-cross-canadian_8.2.bb => gdb-cross-canadian_8.2.1.bb} | 0
.../gdb/{gdb-cross_8.2.bb => gdb-cross_8.2.1.bb} | 0
meta/recipes-devtools/gdb/{gdb_8.2.bb => gdb_8.2.1.bb}| 0
4 files changed, 2 insertions(+), 2 deletions(-)
rename meta/recipes-devtools/gdb/{gdb-8.2.inc => gdb-8.2.1.inc} (89%)
rename meta/recipes-devtools/gdb/{gdb-cross-canadian_8.2.bb =>
gdb-cross-canadian_8.2.1.bb} (100%)
rename meta/recipes-devtools/gdb/{gdb-cross_8.2.bb => gdb-cross_8.2.1.bb}
(100%)
rename meta/recipes-devtools/gdb/{gdb_8.2.bb => gdb_8.2.1.bb} (100%)
diff --git a/meta/recipes-devtools/gdb/gdb-8.2.inc
b/meta/recipes-devtools/gdb/gdb-8.2.1.inc
similarity index 89%
rename from meta/recipes-devtools/gdb/gdb-8.2.inc
rename to meta/recipes-devtools/gdb/gdb-8.2.1.inc
index f6d75ed081..1fc1ec0da4 100644
--- a/meta/recipes-devtools/gdb/gdb-8.2.inc
+++ b/meta/recipes-devtools/gdb/gdb-8.2.1.inc
@@ -18,6 +18,6 @@ SRC_URI = "http://ftp.gnu.org/gnu/gdb/gdb-${PV}.tar.xz \
file://gdbserver-ctrl-c-handling.patch \
file://0001-Fix-build-with-latest-GCC-9.0-tree.patch \
"
-SRC_URI[md5sum] = "b5a49dbff00d9a87fbe114d14b3101c0"
-SRC_URI[sha256sum] =
"c3a441a29c7c89720b734e5a9c6289c0a06be7e0c76ef538f7bbcef389347c39"
+SRC_URI[md5sum] = "f8b2562e830a4098dd5b5ea9e9296c70"
+SRC_URI[sha256sum] =
"0a6a432907a03c5c8eaad3c3cffd50c00a40c3a5e3c4039440624bae703f2202"
diff --git a/meta/recipes-devtools/gdb/gdb-cross-canadian_8.2.bb
b/meta/recipes-devtools/gdb/gdb-cross-canadian_8.2.1.bb
similarity index 100%
rename from meta/recipes-devtools/gdb/gdb-cross-canadian_8.2.bb
rename to meta/recipes-devtools/gdb/gdb-cross-canadian_8.2.1.bb
diff --git a/meta/recipes-devtools/gdb/gdb-cross_8.2.bb
b/meta/recipes-devtools/gdb/gdb-cross_8.2.1.bb
similarity index 100%
rename from meta/recipes-devtools/gdb/gdb-cross_8.2.bb
rename to meta/recipes-devtools/gdb/gdb-cross_8.2.1.bb
diff --git a/meta/recipes-devtools/gdb/gdb_8.2.bb
b/meta/recipes-devtools/gdb/gdb_8.2.1.bb
similarity index 100%
rename from meta/recipes-devtools/gdb/gdb_8.2.bb
rename to meta/recipes-devtools/gdb/gdb_8.2.1.bb
--
2.17.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 01/14] blktool: upgrade 4-7 -> 4-7.1
On Thu, Feb 21, 2019 at 12:41:17PM +, Richard Purdie wrote:
> Signed-off-by: Richard Purdie
> ---
> .../blktool/{blktool_4-7.bb => blktool_4-7.1.bb}| 2 ++
> 1 file changed, 2 insertions(+)
> rename meta/recipes-extended/blktool/{blktool_4-7.bb => blktool_4-7.1.bb}
> (90%)
>
> diff --git a/meta/recipes-extended/blktool/blktool_4-7.bb
> b/meta/recipes-extended/blktool/blktool_4-7.1.bb
> similarity index 90%
> rename from meta/recipes-extended/blktool/blktool_4-7.bb
> rename to meta/recipes-extended/blktool/blktool_4-7.1.bb
> index 0e6f7ee6df1..468925e329b 100644
> --- a/meta/recipes-extended/blktool/blktool_4-7.bb
> +++ b/meta/recipes-extended/blktool/blktool_4-7.1.bb
> @@ -9,6 +9,8 @@ LIC_FILES_CHKSUM =
> "file://COPYING;md5=94d55d512a9ba36caa9b7df079bae19f \
>
> DEPENDS = "glib-2.0"
>
> +SRC_URI[sha256sum] =
> "b1e6d5912546d2a4b704ec65c2b9664aa3b4663e7d800e06803330335a2cb764"
> +SRC_URI[md5sum] = "62edc09c9908107e69391c87f4f3fd40"
Adding hashes insted of updating them looks wrong.
> SRC_URI =
> "http://snapshot.debian.org/archive/debian/20160728T043443Z/pool/main/b/${BPN}/${BPN}_4.orig.tar.gz;name=tarball
> \
>...
And the recipe seems to build the stale upstream version 4,
not the Debian-patched package.
In a related note, an actual upgrade 4-7 -> 4-7.1 would have failed
since the new patch in 4-7.1 is already applied in yocto.
# for this package we're mostly interested in tracking debian patches,
# and not in the upstream version where all development has effectively stopped
This seems to imply that every new "upstream" version requires manual
checking of the Debian changes, and an automatic upgrade does nothing.
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] Can't build product that uses DEFAULTTUNE="arm926ejs"
On Sat, Mar 16, 2019 at 09:21:57AM +, Peter Kjellerstedt wrote: > > While I agree that your patch will solve the problem with arm926ejs, I > believe there are advantages in applying my patches instead. In addition > to fixing the problem with arm926ejs, my patches (patch set 4, not patch > set 2 that is currently on master-next) also: > > * make it so that there is no change to TUNE_FEATURES, > * make it explicit whether -mcpu or -march is used, and > * make the extra arguments added to -mcpu or -march for armv8 explicit. > > That last point was something that confused me when I read the original > tune files. I did not realize that those extra features were added to > whatever -mcpu or -march happened to be added to TUNE_CCARGS before the > arch-armv8a.inc file was included (especially as it was written to make > it look as they were only added to the -march option). For armv8 a larger redesign is actually required - it doesn't scale to have variables like TUNE_FEATURES_tune-armv8a-crc-crypto with 160k possible combinations[1] in gcc 8. > //Peter cu Adrian [1] target architectures 8.0-8.4 and 15 feature modifiers -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] Fwd: [oe-commits] [openembedded-core] branch thud updated (ad0a553 -> 748f946)
On Sat, Mar 16, 2019 at 08:50:13AM -0700, akuster808 wrote: > On 3/16/19 5:20 AM, Andreas Müller wrote: >... > > 2. This was applied on Feb 6th which is not 3 month back exactly. > then its worst than I thought, I can't remember what my thought process > was back to Feb 6th. > > > > [1] > > https://wiki.yoctoproject.org/wiki/Stable_branch_maintenance#Point_release > > I am glad you are bringing these things up, it helps me revisit my own > processes and help me improve. > > We are planning on revising the maintenance guidelines soon so I hope to > get your input. Was the boost upgrade in thud sent to the mailing list for review? My reading of the "Requesting a fix in a stable branch" section would be that this is already a mandatory part of the process. > - armin cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] Fwd: [oe-commits] [openembedded-core] branch thud updated (ad0a553 -> 748f946)
On Sun, Mar 17, 2019 at 08:38:20AM -0700, akuster808 wrote: > > > On 3/17/19 6:08 AM, Adrian Bunk wrote: > > On Sat, Mar 16, 2019 at 08:50:13AM -0700, akuster808 wrote: > >> On 3/16/19 5:20 AM, Andreas Müller wrote: > >> ... > >>> 2. This was applied on Feb 6th which is not 3 month back exactly. > >> then its worst than I thought, I can't remember what my thought process > >> was back to Feb 6th. > >>> [1] > >>> https://wiki.yoctoproject.org/wiki/Stable_branch_maintenance#Point_release > >> I am glad you are bringing these things up, it helps me revisit my own > >> processes and help me improve. > >> > >> We are planning on revising the maintenance guidelines soon so I hope to > >> get your input. > > Was the boost upgrade in thud sent to the mailing list for review? > That series did not, the previous ones and several Sumo request have. > > So you are the second person to mention the update, is it causing a > problem? You were requesting input. I am not using boost on Yocto, but in Debian it is pretty normal that several packages stop building each time boost gets updated. "Drop signals library as upstream has removed it" in the backported commit shows the tip of this iceberg. What went wrong that even the removal of a library from boost did not prevent this change from entering a stable branch? > > My reading of the "Requesting a fix in a stable branch" section > > would be that this is already a mandatory part of the process. > > That is not under the "Maintainers procedure" so it does not apply. > > I have taken requests via IRC and a simple "please add this to stable > branch X" emails so I have not been enforcing the letter of the law. >... > Like I have mentioned already, the processes mentioned in > "Stable_branch_maintenance" are under review. One problem is that changes to master are getting better reviewed than changes to stable branches. Upgrading boost in a stable branch wouldn't have survived a mailing list review. A possible improvement would be to always use thud-next, and each time commits are added to thud-next an email thread with all new commits gets sent to the mailing list (similar to the review threads for new upstream stable kernels, see [1] for an example). > regards, > Armin cu Adrian [1] https://lkml.org/lkml/2019/3/12/1290 -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [thud][PATCH] systemd: RDEPENDS on util-linux-umount
From: André Draszik
It looks like there is an implicit dependency on util-linux'
umount - as otherwise when using busybox' umount we see a
long delay on shutdown / reboot.
[YOCTO #13058]
(From OE-Core rev: 39a3d2c603429865af632fe41b2cf32c3dfdfb1d)
Signed-off-by: André Draszik
Signed-off-by: Richard Purdie
Signed-off-by: Adrian Bunk
---
meta/recipes-core/systemd/systemd_239.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-core/systemd/systemd_239.bb
b/meta/recipes-core/systemd/systemd_239.bb
index ed10f634b9..edda923a34 100644
--- a/meta/recipes-core/systemd/systemd_239.bb
+++ b/meta/recipes-core/systemd/systemd_239.bb
@@ -544,7 +544,7 @@ FILES_${PN} = " ${base_bindir}/* \
FILES_${PN}-dev += "${base_libdir}/security/*.la ${datadir}/dbus-1/interfaces/
${sysconfdir}/rpm/macros.systemd"
-RDEPENDS_${PN} += "kmod dbus util-linux-mount udev (= ${EXTENDPKGV})
util-linux-agetty util-linux-fsck"
+RDEPENDS_${PN} += "kmod dbus util-linux-mount util-linux-umount udev (=
${EXTENDPKGV}) util-linux-agetty util-linux-fsck"
RDEPENDS_${PN} += "${@bb.utils.contains('PACKAGECONFIG',
'serial-getty-generator', '', 'systemd-serialgetty', d)}"
RDEPENDS_${PN} += "volatile-binds update-rc.d systemd-conf"
--
2.17.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] sqlite3: Upgrade 3.26.0 -> 3.27.2
Signed-off-by: Adrian Bunk
---
meta/recipes-support/sqlite/sqlite3_3.26.0.bb | 10 --
meta/recipes-support/sqlite/sqlite3_3.27.2.bb | 11 +++
2 files changed, 11 insertions(+), 10 deletions(-)
delete mode 100644 meta/recipes-support/sqlite/sqlite3_3.26.0.bb
create mode 100644 meta/recipes-support/sqlite/sqlite3_3.27.2.bb
diff --git a/meta/recipes-support/sqlite/sqlite3_3.26.0.bb
b/meta/recipes-support/sqlite/sqlite3_3.26.0.bb
deleted file mode 100644
index a0d615bac1..00
--- a/meta/recipes-support/sqlite/sqlite3_3.26.0.bb
+++ /dev/null
@@ -1,10 +0,0 @@
-require sqlite3.inc
-
-LICENSE = "PD"
-LIC_FILES_CHKSUM =
"file://sqlite3.h;endline=11;md5=786d3dc581eff03f4fd9e4a77ed00c66"
-
-SRC_URI = "\
- http://www.sqlite.org/2018/sqlite-autoconf-${SQLITE_PV}.tar.gz \
- "
-SRC_URI[md5sum] = "ac2b3b8cd3a97600e36fb8e756e8dda1"
-SRC_URI[sha256sum] =
"5daa6a3fb7d1e8c767cd59c4ded8da6e4b00c61d3b466d0685e35c4dd6d7bf5d"
diff --git a/meta/recipes-support/sqlite/sqlite3_3.27.2.bb
b/meta/recipes-support/sqlite/sqlite3_3.27.2.bb
new file mode 100644
index 00..22fec21454
--- /dev/null
+++ b/meta/recipes-support/sqlite/sqlite3_3.27.2.bb
@@ -0,0 +1,11 @@
+require sqlite3.inc
+
+LICENSE = "PD"
+LIC_FILES_CHKSUM =
"file://sqlite3.h;endline=11;md5=786d3dc581eff03f4fd9e4a77ed00c66"
+
+SRC_URI = "\
+ http://www.sqlite.org/2019/sqlite-autoconf-${SQLITE_PV}.tar.gz \
+ "
+
+SRC_URI[md5sum] = "1f72631ce6e8efa5b4a6e55a43b3bdc0"
+SRC_URI[sha256sum] =
"50c39e85ea28b5ecfdb3f9e860afe9ba606381e21836b2849efca6a0bfe6ef6e"
--
2.17.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 2/6] linux-libc-headers: update to 5.x headers
On Thu, Mar 07, 2019 at 07:20:15AM -0800, Khem Raj wrote: > another one I forgot > https://errors.yoctoproject.org/Errors/Details/231924/ The two commits from https://github.com/miniupnp/miniupnp/issues/346 should fix this (untested). cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [thud][PATCH] systemd: RDEPENDS on util-linux-umount
On Thu, Mar 07, 2019 at 03:56:33PM +0100, Leon Woestenberg wrote: > On Thu, Mar 7, 2019 at 3:27 PM Adrian Bunk wrote: > > > > From: André Draszik > > > > It looks like there is an implicit dependency on util-linux' > > umount - as otherwise when using busybox' umount we see a > > long delay on shutdown / reboot. > > > > [YOCTO #13058] > > > That bug number is wrong, seems only slighty related: > https://bugzilla.yoctoproject.org/show_bug.cgi?id=13058 > > Following the discussions, I think this had to do with older versions > of busybox not ignoring the '-c' option that systemd passes to umount. > > https://github.com/systemd/systemd/issues/7786 > > So, systemd has a dependency on *either* util-linux-mount *or* a > minimal version of busybox. Do we support minimal version dependencies > in Yocto? Then the patch to master didn't make sense, unfixed busybox is not a problem here. If systemd needs util-linux mount/umount in master it should also depend on them in older releases (both master and thud had systemd 239 at that point). If it does not, it should not pull in such dependencies unconditionally in master. > Regards, > > Leon. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [oe-core][PATCH] Revert "systemd: RDEPENDS on util-linux-umount"
This reverts commit d31259fa464cfc8ae3a1f6209e98153aca101060.
busybox umount was already fixed, making this change obsolete.
Signed-off-by: Adrian Bunk
---
meta/recipes-core/systemd/systemd_241.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-core/systemd/systemd_241.bb
b/meta/recipes-core/systemd/systemd_241.bb
index 44a132a4a0..de0a8e5d50 100644
--- a/meta/recipes-core/systemd/systemd_241.bb
+++ b/meta/recipes-core/systemd/systemd_241.bb
@@ -542,7 +542,7 @@ FILES_${PN} = " ${base_bindir}/* \
FILES_${PN}-dev += "${base_libdir}/security/*.la ${datadir}/dbus-1/interfaces/
${sysconfdir}/rpm/macros.systemd"
-RDEPENDS_${PN} += "kmod dbus util-linux-mount util-linux-umount udev (=
${EXTENDPKGV}) util-linux-agetty util-linux-fsck"
+RDEPENDS_${PN} += "kmod dbus util-linux-mount udev (= ${EXTENDPKGV})
util-linux-agetty util-linux-fsck"
RDEPENDS_${PN} += "${@bb.utils.contains('PACKAGECONFIG',
'serial-getty-generator', '', 'systemd-serialgetty', d)}"
RDEPENDS_${PN} += "volatile-binds update-rc.d systemd-conf"
--
2.17.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [meta-oe][RFC][PATCH] Remove openssl10
On Fri, Mar 08, 2019 at 10:15:42PM +0300, Alexander Kanavin wrote: > This is premature. Plenty of recipes outside of oe-core still rely on > openssl10, >... How many and which recipes actually? The upcoming releases of Debian and Ubuntu ship without OpenSSL 1.0. > Alex cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [meta-oe][RFC][PATCH] Remove openssl10
On Fri, Mar 08, 2019 at 11:21:26PM +0300, Alexander Kanavin wrote: > Perhaps you could grep meta-openembedded for openssl10? I do not have access > to a Linux machine for the next two weeks to check that, but I think there’s > a few items there. Once meta-oe layers are free of openssl10 deps, there is a > better case for removing it. >... My patches to remove the last uses of openssl10 in meta-openembedded are already in meta-openembedded master. > Alex cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] mdadm: fix gcc8 maybe-uninitialized/format-overflow warning
On Tue, Mar 19, 2019 at 11:51:47PM -0400, Khem Raj wrote: > On Fri, Mar 15, 2019 at 6:45 AM Adrian Bunk wrote: > > > > On Tue, Mar 12, 2019 at 05:41:58PM +0800, changqing...@windriver.com wrote: > > > From: Changqing Li > > > > > > while compiled with -Werror=maybe-uninitialized/-Werror=format-overflow=, > > > it failed > > > > > > [snip] > > > | Incremental.c: In function 'Incremental_container': > > > | Incremental.c:1593:3: error: 'mdfd' may be used uninitialized in this > > > function [-Werror=maybe-uninitialized] > > > | close(mdfd); > > > | ^~~ > > > > > > [snip] > > > super-intel.c: In function 'apply_takeover_update': > > > | super-intel.c:9615:15: error: '%d' directive writing between 1 and 11 > > > bytes into a region of size 7 [-Werror=format-overflow=] > > > | " MISSING_%d", du->index); > > > | ^~ > > >... > > > > I am seeing these warnings only with -Og, are you also seeing them with > > -Og (DEBUG_OPTIMIZATION) only? > > > > If this is true, I would consider > > https://sources.debian.org/src/mdadm/4.1-2/debian/patches/debian-no-Werror.diff/ > > a better workaround. > > > This seems a broader brush, I really dont like to relegate Werror if > we dont have to, because it will force us > to fix the code. How are we getting such fixes properly reviewed? What actually happens is that the easiest change that silences a warning gets applied. And for such bogus -Og only warnings there was no problem in the code, meaning regression risks by OE/Yocto-only patches without fixing anything. > However, I am seeing it fail with clang now > > https://errors.yoctoproject.org/Errors/Details/233618/ This is caused by the "fix" for the -Og gcc warning. Which looks bogus, and might be harmful. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] bind: Upgrade 9.11.5 -> 9.11.6
On Wed, Mar 20, 2019 at 07:35:53AM -0700, akuster808 wrote: > > > On 3/20/19 7:09 AM, Adrian Bunk wrote: > > Copyright hash changed to to year change. > > You are missing one of the more important bits of info that would help > make the decision if this gets into M4 or waits until after 2.7 releases. > > Go look at the 9.11.5-p4 release notes. What part of the release notes are you referring to? And why are you talking about release notes for a version that is neither of the two versions in this upgrade? > Did you double check this is in line with DHCP? What kind of breakage exactly do you fear? dhcp still builds and I am staying on an LTS branch of bind. > - Armin cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] mdadm: fix gcc8 maybe-uninitialized/format-overflow warning
On Wed, Mar 20, 2019 at 08:59:39AM -0400, Khem Raj wrote: > On Wed, Mar 20, 2019 at 1:21 AM Adrian Bunk wrote: > > > > On Tue, Mar 19, 2019 at 11:51:47PM -0400, Khem Raj wrote: > > > On Fri, Mar 15, 2019 at 6:45 AM Adrian Bunk wrote: > > > > > > > > On Tue, Mar 12, 2019 at 05:41:58PM +0800, changqing...@windriver.com > > > > wrote: > > > > > From: Changqing Li > > > > > > > > > > while compiled with > > > > > -Werror=maybe-uninitialized/-Werror=format-overflow=, > > > > > it failed > > > > > > > > > > [snip] > > > > > | Incremental.c: In function 'Incremental_container': > > > > > | Incremental.c:1593:3: error: 'mdfd' may be used uninitialized in > > > > > this function [-Werror=maybe-uninitialized] > > > > > | close(mdfd); > > > > > | ^~~ > > > > > > > > > > [snip] > > > > > super-intel.c: In function 'apply_takeover_update': > > > > > | super-intel.c:9615:15: error: '%d' directive writing between 1 and > > > > > 11 bytes into a region of size 7 [-Werror=format-overflow=] > > > > > | " MISSING_%d", du->index); > > > > > | ^~ > > > > >... > > > > > > > > I am seeing these warnings only with -Og, are you also seeing them with > > > > -Og (DEBUG_OPTIMIZATION) only? > > > > > > > > If this is true, I would consider > > > > https://sources.debian.org/src/mdadm/4.1-2/debian/patches/debian-no-Werror.diff/ > > > > a better workaround. > > > > > > > This seems a broader brush, I really dont like to relegate Werror if > > > we dont have to, because it will force us > > > to fix the code. > > > > How are we getting such fixes properly reviewed? > > > > What actually happens is that the easiest change that silences a warning > > gets applied. > > > > And for such bogus -Og only warnings there was no problem in the code, > > so then probably a better fix is to add -Wno-error to DEBUG_FLAGS > which will limit it to -Og case, and revert the original fix. For mdadm this might work, for puzzles it would not. Order matters, and upstream can insert your flags before or after the -Werror. So unfortunately this would not cover all recipes. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] bind: Upgrade 9.11.5 -> 9.11.6
On Wed, Mar 20, 2019 at 09:33:56AM -0700, akuster808 wrote: > > > On 3/20/19 8:55 AM, Adrian Bunk wrote: > > On Wed, Mar 20, 2019 at 08:21:31AM -0700, akuster808 wrote: > >> On 3/20/19 7:56 AM, Adrian Bunk wrote: > >>> On Wed, Mar 20, 2019 at 07:35:53AM -0700, akuster808 wrote: > >>>> On 3/20/19 7:09 AM, Adrian Bunk wrote: > >>>>> Copyright hash changed to to year change. > >>>> You are missing one of the more important bits of info that would help > >>>> make the decision if this gets into M4 or waits until after 2.7 releases. > >>>> > >>>> Go look at the 9.11.5-p4 release notes. > >>> What part of the release notes are you referring to? > >>> > >>> And why are you talking about release notes for a version > >>> that is neither of the two versions in this upgrade? > >> Ah, because the 9.11.5 has patch level updates from -p1 to -p5 that are > >> not the current 9.11.5 and those changes are included in 9.11.6. > > Most items in the 9.11.6 release notes are also in the 9.11.5 > > release notes. > > 9.11.5-P4 > > * CVE-2018-5744: A specially crafted packet can cause named to leak > memory > <https://lists.isc.org/pipermail/bind-announce/2019-February/001115.html> > /Michael McNally / > * CVE-2018-5745: An assertion failure can occur if a trust anchor > rolls over to an unsupported key algorithm when using managed-keys > <https://lists.isc.org/pipermail/bind-announce/2019-February/001116.html> > /Michael McNally / > * CVE-2019-6465: Controls for zone transfers might not be properly > applied to Dynamically Loadable Zones (DLZs) if the zones are > writable. > <https://lists.isc.org/pipermail/bind-announce/2019-February/001117.html> > /Michael McNally / > > > please add just the CVE references to the commit message. Precedent in master seems to be to not list CVEs fixed in new upstream, only when CVE fixes get backported. Justifying my patch with CVE numbers would also be wrong since for only these CVE fixes 9.11.5-p4 would be better than 9.11.6. > >> Also, nowhere was it mentioned this is a bugfix only update. > > It is not a bugfix only update. > > The 9.11 series is a Extended Supported Version. (ESV) release. Use the > software for Production Environments needing infrequent upgrades and no > new features. > > https://www.isc.org/downloads/software-support-policy/version-numbering/ I am not disputing that it is an LTS series. But 9.11.5 -> 9.11.6 is not a bugfix only update. > >> This helps > >> me in deciding if this is a back port candidate. > > You are saying you were threatening to veto inclusion into 2.7 because > > you aren't able to decide whether it should be backported to 2.6? > > Not at all. We have entered 2.7 M3 which includes freezing package > updates. The ones that have the best chance of getting in are ones that > are bugfixes and or include CVE fixes. Without any information, the > chance on being included goes down. Having more info in the commit > message helps Richard and Ross to decide if they should include it. >... > I am the package maintainer and I appreciate folks helping me support > the packages I maintain with in updates and fixes. Do whatever you want to do, it's best to end the discussion at this point. > regards, > Armin cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] bind: Upgrade 9.11.5 -> 9.11.6
On Wed, Mar 20, 2019 at 08:21:31AM -0700, akuster808 wrote: > On 3/20/19 7:56 AM, Adrian Bunk wrote: > > On Wed, Mar 20, 2019 at 07:35:53AM -0700, akuster808 wrote: > >> > >> On 3/20/19 7:09 AM, Adrian Bunk wrote: > >>> Copyright hash changed to to year change. > >> You are missing one of the more important bits of info that would help > >> make the decision if this gets into M4 or waits until after 2.7 releases. > >> > >> Go look at the 9.11.5-p4 release notes. > > What part of the release notes are you referring to? > > > > And why are you talking about release notes for a version > > that is neither of the two versions in this upgrade? > > Ah, because the 9.11.5 has patch level updates from -p1 to -p5 that are > not the current 9.11.5 and those changes are included in 9.11.6. Most items in the 9.11.6 release notes are also in the 9.11.5 release notes. > Also, nowhere was it mentioned this is a bugfix only update. It is not a bugfix only update. > This helps > me in deciding if this is a back port candidate. You are saying you were threatening to veto inclusion into 2.7 because you aren't able to decide whether it should be backported to 2.6? > Keywords to look for: Bugfix only, CVE's, ABI changes, dependency > changes, depreciated functions and new features. > > I are hoping a little do-diligence in being applied to package updates > otherwise automation will save us all a bunch of time. Doing the 9.11.5 -> 9.11.6 upgrade in master is something I wouldn't have suggested if I wouldn't have considered it reasonable. Upgrading bind 9.11.4 -> 9.11.6 in thud is a case where automation or keywords in a commit cannot make the decision. It doesn't look like a clear case either way to me. The recipe maintainer might be better qualified to analyse whether or not this is a backport candidate. > Thanks, > Armin cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] bind: Upgrade 9.11.5 -> 9.11.6
Copyright hash changed to to year change.
Signed-off-by: Adrian Bunk
---
...0001-configure.in-remove-useless-L-use_openssl-lib.patch | 4 ++--
...nd-ensure-searching-for-json-headers-searches-sysr.patch | 4 ++--
.../bind/{bind_9.11.5.bb => bind_9.11.6.bb} | 6 +++---
3 files changed, 7 insertions(+), 7 deletions(-)
rename meta/recipes-connectivity/bind/{bind_9.11.5.bb => bind_9.11.6.bb} (96%)
diff --git
a/meta/recipes-connectivity/bind/bind/0001-configure.in-remove-useless-L-use_openssl-lib.patch
b/meta/recipes-connectivity/bind/bind/0001-configure.in-remove-useless-L-use_openssl-lib.patch
index 871bb2a5f6..92a84a206c 100644
---
a/meta/recipes-connectivity/bind/bind/0001-configure.in-remove-useless-L-use_openssl-lib.patch
+++
b/meta/recipes-connectivity/bind/bind/0001-configure.in-remove-useless-L-use_openssl-lib.patch
@@ -16,8 +16,8 @@ Signed-off-by: Hongxu Jia
diff --git a/configure.in b/configure.in
index 54efc55..76ac0eb 100644
a/configure.in
-+++ b/configure.in
+--- a/configure.ac
b/configure.ac
@@ -1691,7 +1691,7 @@ If you don't want OpenSSL, use --without-openssl])
fi
;;
diff --git
a/meta/recipes-connectivity/bind/bind/bind-ensure-searching-for-json-headers-searches-sysr.patch
b/meta/recipes-connectivity/bind/bind/bind-ensure-searching-for-json-headers-searches-sysr.patch
index 37e210e6da..f686862d3d 100644
---
a/meta/recipes-connectivity/bind/bind/bind-ensure-searching-for-json-headers-searches-sysr.patch
+++
b/meta/recipes-connectivity/bind/bind/bind-ensure-searching-for-json-headers-searches-sysr.patch
@@ -33,8 +33,8 @@ Signed-off-by: Paul Gortmaker
Index: bind-9.11.3/configure.in
===
bind-9.11.3.orig/configure.in
-+++ bind-9.11.3/configure.in
+--- bind-9.11.3.orig/configure.ac
bind-9.11.3/configure.ca
@@ -2574,7 +2574,7 @@ case "$use_libjson" in
libjson_libs=""
;;
diff --git a/meta/recipes-connectivity/bind/bind_9.11.5.bb
b/meta/recipes-connectivity/bind/bind_9.11.6.bb
similarity index 96%
rename from meta/recipes-connectivity/bind/bind_9.11.5.bb
rename to meta/recipes-connectivity/bind/bind_9.11.6.bb
index 67672792b1..36c3425cfe 100644
--- a/meta/recipes-connectivity/bind/bind_9.11.5.bb
+++ b/meta/recipes-connectivity/bind/bind_9.11.6.bb
@@ -3,7 +3,7 @@ HOMEPAGE = "http://www.isc.org/sw/bind/;
SECTION = "console/network"
LICENSE = "ISC & BSD"
-LIC_FILES_CHKSUM = "file://COPYRIGHT;md5=6ba7c9fe0c888a943c79c93e6de744fb"
+LIC_FILES_CHKSUM = "file://COPYRIGHT;md5=8f17f64e47e83b60cd920a1e4b54419e"
DEPENDS = "openssl libcap zlib"
@@ -22,8 +22,8 @@ SRC_URI =
"https://ftp.isc.org/isc/bind9/${PV}/${BPN}-${PV}.tar.gz \
file://0001-avoid-start-failure-with-bind-user.patch \
"
-SRC_URI[md5sum] = "17a0d02102117c9a221e857cf2cc8157"
-SRC_URI[sha256sum] =
"a4cae11dad954bdd4eb592178f875bfec09fcc7e29fe0f6b7a4e5b5c6bc61322"
+SRC_URI[md5sum] = "4882bd3eeef779e05b515b32354cc081"
+SRC_URI[sha256sum] =
"4499007f3a6b8bba84fc757053caeabf36466d6f7d278baccef9fd109beac6d4"
UPSTREAM_CHECK_URI = "https://ftp.isc.org/isc/bind9/;
UPSTREAM_CHECK_REGEX = "(?P9(\.\d+)+(-P\d+)*)/"
--
2.17.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] Remove the simd tune for armv8a
SIMD instructions are a mandatory part of armv8a
(they were optional in armv7a), and the gcc docs
also say that they are always enabled.
Signed-off-by: Adrian Bunk
---
meta/conf/machine/include/arm/arch-armv8a.inc | 6 ++
meta/conf/machine/include/tune-cortexa32.inc | 4 ++--
meta/conf/machine/include/tune-cortexa35.inc | 4 ++--
meta/conf/machine/include/tune-cortexa53.inc | 4 ++--
meta/conf/machine/include/tune-cortexa72.inc | 2 +-
5 files changed, 9 insertions(+), 11 deletions(-)
diff --git a/meta/conf/machine/include/arm/arch-armv8a.inc
b/meta/conf/machine/include/arm/arch-armv8a.inc
index 22064559be..44d0ca4557 100644
--- a/meta/conf/machine/include/arm/arch-armv8a.inc
+++ b/meta/conf/machine/include/arm/arch-armv8a.inc
@@ -2,8 +2,6 @@ DEFAULTTUNE ?= "armv8a-crc"
TUNEVALID[armv8a] = "Enable instructions for ARMv8-a"
TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'armv8a', '
-march=armv8-a', '', d)}"
-TUNEVALID[simd] = "Enable instructions for ARMv8-a Advanced SIMD and
floating-point"
-TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'simd', '+simd', '', d)}"
TUNEVALID[crc] = "Enable instructions for ARMv8-a Cyclic Redundancy Check
(CRC)"
TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'crc', '+crc', '', d)}"
TUNEVALID[crypto] = "Enable instructions for ARMv8-a cryptographic"
@@ -18,11 +16,11 @@ ARMPKGARCH_tune-armv8a?= "armv8a"
ARMPKGARCH_tune-armv8a-crc?= "armv8a"
ARMPKGARCH_tune-armv8a-crypto ?= "armv8a"
ARMPKGARCH_tune-armv8a-crc-crypto ?= "armv8a"
-TUNE_FEATURES_tune-armv8a = "aarch64 armv8a simd"
+TUNE_FEATURES_tune-armv8a = "aarch64 armv8a"
TUNE_FEATURES_tune-armv8a-crc = "${TUNE_FEATURES_tune-armv8a} crc"
TUNE_FEATURES_tune-armv8a-crypto = "${TUNE_FEATURES_tune-armv8a}
crypto"
TUNE_FEATURES_tune-armv8a-crc-crypto = "${TUNE_FEATURES_tune-armv8a-crc}
crypto"
-PACKAGE_EXTRA_ARCHS_tune-armv8a= "aarch64 armv8a simd"
+PACKAGE_EXTRA_ARCHS_tune-armv8a= "aarch64 armv8a"
PACKAGE_EXTRA_ARCHS_tune-armv8a-crc=
"${PACKAGE_EXTRA_ARCHS_tune-armv8a} crc"
PACKAGE_EXTRA_ARCHS_tune-armv8a-crypto =
"${PACKAGE_EXTRA_ARCHS_tune-armv8a} crypto"
PACKAGE_EXTRA_ARCHS_tune-armv8a-crc-crypto =
"${PACKAGE_EXTRA_ARCHS_tune-armv8a-crc} crypto"
diff --git a/meta/conf/machine/include/tune-cortexa32.inc
b/meta/conf/machine/include/tune-cortexa32.inc
index 4bf7f774e1..9c948f1766 100644
--- a/meta/conf/machine/include/tune-cortexa32.inc
+++ b/meta/conf/machine/include/tune-cortexa32.inc
@@ -10,8 +10,8 @@ require conf/machine/include/arm/arch-armv8a.inc
AVAILTUNES += "cortexa32 cortexa32-crypto"
ARMPKGARCH_tune-cortexa32 = "cortexa32"
ARMPKGARCH_tune-cortexa32-crypto = "cortexa32"
-TUNE_FEATURES_tune-cortexa32 = "aarch64 cortexa32 simd crc"
-TUNE_FEATURES_tune-cortexa32-crypto = "aarch64 cortexa32 simd crc crypto"
+TUNE_FEATURES_tune-cortexa32 = "aarch64 cortexa32 crc"
+TUNE_FEATURES_tune-cortexa32-crypto = "aarch64 cortexa32 crc crypto"
PACKAGE_EXTRA_ARCHS_tune-cortexa32 =
"${PACKAGE_EXTRA_ARCHS_tune-armv8a-crc} cortexa32"
PACKAGE_EXTRA_ARCHS_tune-cortexa32-crypto =
"${PACKAGE_EXTRA_ARCHS_tune-armv8a-crc-crypto} cortexa32 cortexa32-crypto"
BASE_LIB_tune-cortexa32 = "lib64"
diff --git a/meta/conf/machine/include/tune-cortexa35.inc
b/meta/conf/machine/include/tune-cortexa35.inc
index 6ece810753..d6df6cd6bd 100644
--- a/meta/conf/machine/include/tune-cortexa35.inc
+++ b/meta/conf/machine/include/tune-cortexa35.inc
@@ -9,8 +9,8 @@ require conf/machine/include/arm/arch-armv8a.inc
AVAILTUNES += "cortexa35 cortexa35-crypto"
ARMPKGARCH_tune-cortexa35 = "cortexa35"
ARMPKGARCH_tune-cortexa35-crypto = "cortexa35"
-TUNE_FEATURES_tune-cortexa35 = "aarch64 cortexa35 simd crc"
-TUNE_FEATURES_tune-cortexa35-crypto = "aarch64 cortexa35 simd crc crypto"
+TUNE_FEATURES_tune-cortexa35 = "aarch64 cortexa35 crc"
+TUNE_FEATURES_tune-cortexa35-crypto = "aarch64 cortexa35 crc crypto"
PACKAGE_EXTRA_ARCHS_tune-cortexa35 =
"${PACKAGE_EXTRA_ARCHS_tune-armv8a-crc} cortexa35"
PACKAGE_EXTRA_ARCHS_tune-cortexa35-crypto =
"${PACKAGE_EXTRA_ARCHS_tune-armv8a-crc-crypto} cortexa35 cortexa35-crypto"
BASE_LIB_tune-cortexa35 = "lib64"
diff --git a/meta/conf/machine/include/tune-cortexa53.inc
b/meta/conf/machine/include/tune-cortexa53.inc
index 9fb37ff639..6c0b443eaf 100644
--- a/meta/conf/
Re: [OE-core] [oe-core][PATCH 1/1] puzzles: fix uninitialized variable compiler error
On Fri, Mar 15, 2019 at 12:43:06PM +0200, Adrian Bunk wrote: >... > but when I try to reproduce the problem on amd64 it happens > only with -Og (due to puzzles upstream building with -Werror). >... For the root cause I filed https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89723 cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [thud][PATCH] systemd: RDEPENDS on util-linux-umount
On Thu, Mar 07, 2019 at 09:48:02PM +, Richard Purdie wrote: > > Going from memory I think there were some responses saying we should > probably add this patch regardless since we already needed util-linux- > mount. I didn't think it was a huge issue since mount was already there > and it seemed to solve some problems others were having. > > I don't have a strong preference either way, we just need a general > consensus about what to do... The general problem seems to be that systemd upstream does not care much whether busybox versions of commands work with systemd. This creates a conflict between upstream recommendations and aiming at a tiny system when using systemd. The latter would require a continuous effort from someone at OE/Yocto to ensure that the runtime dependencies of systemd are small but working. > Cheers, > > Richard cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] musl thoughts
On Fri, Mar 22, 2019 at 07:53:03AM -0700, akuster808 wrote: > On 3/21/19 6:11 PM, Andreas Müller wrote: >... > > As you might guess I'd prefer 3 because: > > + Many patches can go and don't need maintenance on upstream refactoring > > anymore > > + Burden for people sending patches would be reduced > > + Recipes not building with musl currently might work without further > > modification > > + Just in case musl stops (we have seen this before with others e.g > > ulibc) the cleanup would be reduced > > Didn't we do something like this with glibc? We carried several patches > that where rejected and just recently got removed so there is a > precedent for carrying OE specific changes so it seems like a > reasonable approach. The glibc patches that got removed were patches where it can be questioned whether they should have ever been applied. glibc still carries far too many patches that simply shouldn't be there. All this is different from the musl situation where some kind of patching is required somewhere at least short-term. > - armin cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] bind: Move nsupdate to bind-utils
This is a client tool that is usually not used one the same
machine as the DNS server.
Signed-off-by: Adrian Bunk
---
meta/recipes-connectivity/bind/bind_9.11.5.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-connectivity/bind/bind_9.11.5.bb
b/meta/recipes-connectivity/bind/bind_9.11.5.bb
index 21e979fd9c..11990ee27e 100644
--- a/meta/recipes-connectivity/bind/bind_9.11.5.bb
+++ b/meta/recipes-connectivity/bind/bind_9.11.5.bb
@@ -119,7 +119,7 @@ CONFFILES_${PN} = " \
"
PACKAGE_BEFORE_PN += "${PN}-utils"
-FILES_${PN}-utils = "${bindir}/host ${bindir}/dig ${bindir}/mdig"
+FILES_${PN}-utils = "${bindir}/host ${bindir}/dig ${bindir}/mdig
${bindir}/nsupdate"
FILES_${PN}-dev += "${bindir}/isc-config.h"
FILES_${PN} += "${sbindir}/generate-rndc-key.sh"
--
2.11.0
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/3] kmod: upgrade to 26
On Wed, Feb 20, 2019 at 09:40:35AM +0800, Chen Qi wrote:
>...
> --- a/meta/recipes-kernel/kmod/kmod.inc
> +++ b/meta/recipes-kernel/kmod/kmod.inc
> @@ -14,9 +14,9 @@ LIC_FILES_CHKSUM =
> "file://COPYING;md5=a6f89e2100d9b6cdffcea4f398e37343 \
> "
> inherit autotools gtk-doc pkgconfig manpages
>
> -SRCREV = "aca4eca103d6699543f7ed663335c28c2e9908bb"
> +SRCREV = "58133a96c894c043e48c74ddf0bfe8db90bac62f"
> # Lookout for PV bump too when SRCREV is changed
> -PV = "25+git${SRCPV}"
> +PV = "26+git${SRCPV}"
>...
Shouldn't this be PV = "26" when the commit is exactly the release?
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] Drop util-linux-native-qsort.patch
CentOS 5.x is no longer supported for 2 years,
and uninative being default since Yocto 2.1 should
in any case already cover this issue better.
Signed-off-by: Adrian Bunk
---
.../util-linux/util-linux-native-qsort.patch | 33 --
meta/recipes-core/util-linux/util-linux_2.32.1.bb | 6
2 files changed, 39 deletions(-)
delete mode 100644
meta/recipes-core/util-linux/util-linux/util-linux-native-qsort.patch
diff --git
a/meta/recipes-core/util-linux/util-linux/util-linux-native-qsort.patch
b/meta/recipes-core/util-linux/util-linux/util-linux-native-qsort.patch
deleted file mode 100644
index 68bf22de8c..00
--- a/meta/recipes-core/util-linux/util-linux/util-linux-native-qsort.patch
+++ /dev/null
@@ -1,33 +0,0 @@
-From f220d809be1baa654503bf6ff52f3630b0d7015c Mon Sep 17 00:00:00 2001
-From: Robert Yang
-Date: Wed, 26 Mar 2014 01:30:29 +
-Subject: [PATCH] sun.c: use qsort() to instead of qsort_r()
-
-qsort_r() was added to glibc in version 2.8, so there is no qsort_r() on
-the host like CentOS 5.x.
-
-Upstream-Status: Inappropriate [Other]
-
-Signed-off-by: Robert Yang
- libfdisk/src/sun.c | 5 ++---
- 1 file changed, 2 insertions(+), 3 deletions(-)
-
-Index: util-linux-2.24.2/libfdisk/src/sun.c
-===
util-linux-2.24.2.orig/libfdisk/src/sun.c
-+++ util-linux-2.24.2/libfdisk/src/sun.c
-@@ -431,10 +431,9 @@ static int sun_verify_disklabel(struct f
- }
- verify_sun_starts = starts;
-
--qsort_r(array,ARRAY_SIZE(array),sizeof(array[0]),
--(int (*)(const void *,const void *,void *)) verify_sun_cmp,
--verify_sun_starts);
--
-+qsort(array,ARRAY_SIZE(array),sizeof(array[0]),
-+ (int (*)(const void *,const void *)) verify_sun_cmp);
-+
- if (array[0] == -1) {
- fdisk_info(cxt, _("No partitions defined."));
- return 0;
diff --git a/meta/recipes-core/util-linux/util-linux_2.32.1.bb
b/meta/recipes-core/util-linux/util-linux_2.32.1.bb
index c909836cbb..0ba218b8f2 100644
--- a/meta/recipes-core/util-linux/util-linux_2.32.1.bb
+++ b/meta/recipes-core/util-linux/util-linux_2.32.1.bb
@@ -1,15 +1,9 @@
MAJOR_VERSION = "2.32"
require util-linux.inc
-# To support older hosts, we need to patch and/or revert
-# some upstream changes. Only do this for native packages.
-OLDHOST = ""
-OLDHOST_class-native = "file://util-linux-native-qsort.patch"
-
SRC_URI += "file://configure-sbindir.patch \
file://runuser.pamd \
file://runuser-l.pamd \
-${OLDHOST} \
file://ptest.patch \
file://run-ptest \
file://display_testname_for_subtest.patch \
--
2.11.0
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] busybox: add devmem
This is a tiny but pretty useful tool. Signed-off-by: Adrian Bunk --- meta/recipes-core/busybox/busybox/defconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meta/recipes-core/busybox/busybox/defconfig b/meta/recipes-core/busybox/busybox/defconfig index d11707abc3..1519159a49 100644 --- a/meta/recipes-core/busybox/busybox/defconfig +++ b/meta/recipes-core/busybox/busybox/defconfig @@ -791,7 +791,7 @@ CONFIG_DC=y # CONFIG_DEVFSD_FG_NP is not set # CONFIG_DEVFSD_VERBOSE is not set # CONFIG_FEATURE_DEVFS is not set -# CONFIG_DEVMEM is not set +CONFIG_DEVMEM=y # CONFIG_EJECT is not set # CONFIG_FEATURE_EJECT_SCSI is not set # CONFIG_FBSPLASH is not set -- 2.11.0 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/2] Ubuntu 16.10 is not LTS
Signed-off-by: Adrian Bunk --- documentation/ref-manual/ref-system-requirements.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/documentation/ref-manual/ref-system-requirements.xml b/documentation/ref-manual/ref-system-requirements.xml index 69d4b4e726..500b2f8f39 100644 --- a/documentation/ref-manual/ref-system-requirements.xml +++ b/documentation/ref-manual/ref-system-requirements.xml @@ -97,7 +97,7 @@ Ubuntu 15.04 Ubuntu 15.10 --> Ubuntu 16.04 (LTS) -Ubuntu 16.10 (LTS) +Ubuntu 16.10 Ubuntu 17.04
[OE-core] [PATCH 2/2] ref-system-requirements.xml: Sync list of supported distributions from poky.conf
Signed-off-by: Adrian Bunk --- documentation/ref-manual/ref-system-requirements.xml | 15 +-- 1 file changed, 9 insertions(+), 6 deletions(-) diff --git a/documentation/ref-manual/ref-system-requirements.xml b/documentation/ref-manual/ref-system-requirements.xml index 500b2f8f39..f2450ab58a 100644 --- a/documentation/ref-manual/ref-system-requirements.xml +++ b/documentation/ref-manual/ref-system-requirements.xml @@ -97,16 +97,18 @@ Ubuntu 15.04 Ubuntu 15.10 --> Ubuntu 16.04 (LTS) -Ubuntu 16.10 -Ubuntu 17.04 + +Ubuntu 18.04 (LTS) -Fedora release 26 +Fedora release 24 +Fedora release 26 --> +Fedora release 28 +openSUSE 13.2 openSUSE 42.1 -openSUSE 42.2 +openSUSE 42.2 --> +openSUSE 42.3 -- 2.11.0 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [thud] [PATCH] Ubuntu 16.10 is not LTS
Signed-off-by: Adrian Bunk --- documentation/ref-manual/ref-system-requirements.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/documentation/ref-manual/ref-system-requirements.xml b/documentation/ref-manual/ref-system-requirements.xml index 69d4b4e726..500b2f8f39 100644 --- a/documentation/ref-manual/ref-system-requirements.xml +++ b/documentation/ref-manual/ref-system-requirements.xml @@ -97,7 +97,7 @@ Ubuntu 15.04 Ubuntu 15.10 --> Ubuntu 16.04 (LTS) -Ubuntu 16.10 (LTS) +Ubuntu 16.10 Ubuntu 17.04
Re: [OE-core] [PATCH] busybox: add devmem
On Wed, Jan 30, 2019 at 08:50:02AM -0800, Khem Raj wrote: > On Wed, Jan 30, 2019 at 1:34 AM Adrian Bunk wrote: > > > > This is a tiny but pretty useful tool. > > > > question is, do we need this enabled in default config, or could be add it via > some DISTRO_FEATURE meant for validation etc. May be if you explain your > usecase then we might be able to make a better assessment. Sorry for being too terse. devmem allows reading and writing hardware configuration registers, which is useful both for debugging and for scripts. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] busybox: add devmem
On Wed, Jan 30, 2019 at 02:18:06PM -0800, Khem Raj wrote: > On Wed, Jan 30, 2019 at 12:31 PM Adrian Bunk wrote: > > > On Wed, Jan 30, 2019 at 08:50:02AM -0800, Khem Raj wrote: > > > On Wed, Jan 30, 2019 at 1:34 AM Adrian Bunk wrote: > > > > > > > > This is a tiny but pretty useful tool. > > > > > > > > > > question is, do we need this enabled in default config, or could be add > > it via > > > some DISTRO_FEATURE meant for validation etc. May be if you explain your > > > usecase then we might be able to make a better assessment. > > > > Sorry for being too terse. > > > > devmem allows reading and writing hardware configuration registers, > > which is useful both for debugging and for scripts. > > > > Thanks for the info this seems useful can you also report how much does it > increase size of busybox In a -O2 build for arm64 busybox.nosuid grows 4 kB. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] busybox: add devmem
On Wed, Jan 30, 2019 at 05:47:03PM -0500, Tom Rini wrote: > > I would also ask if we should be enabling more stuff in busybox, period. I don't think the current status quo would be a good starting point for that. Before submitting I saw CONFIG_PATCH=y, which is a lot more of a "Why would I ever need this on an embedded device?". Not saying that you are wrong, but the starting point should be a review of the current config. > Customizing busybox for what you're trying to _do_ with a custom setup > is one of those top 5 TODO items with making a cut down image and > customizing the kernel config. Outside of -tiny and initramfs/similar > cases, there's not a great reason to use > almost-but-not-quite-complete-busybox-applet compared with the regular > app. I frequently end up in projects where I do have great reason for that: For root filesystems of the 32-64 MB size it is not necessary to use a different libc or use -Os, but using the busybox applets when they are sufficient saves > 10% filesystem size compared to the full versions. E.g. 0.45 MB for a standalone tar is much when the little functionality you actually need is also provided by the busybox applet. Plus there is also the convenience point that most of the tools you need are already installed just by adding busybox with the default config. > Tom cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] busybox: add devmem
On Thu, Jan 31, 2019 at 11:06:22AM +0100, Philip Balister wrote: > On 01/30/2019 05:50 PM, Khem Raj wrote: > > On Wed, Jan 30, 2019 at 1:34 AM Adrian Bunk wrote: > >> > >> This is a tiny but pretty useful tool. > > Also there is http://layers.openembedded.org/layerindex/recipe/1069/ > > I was told a while ago the busybox version has some issues. Hunting > through brain cells, I think it always does a read back after writing > which can be bad for some hardware. So I've always used the recipe from > meta-oe instead. The broken one for that is actually devmem2, the busybox copy of the code has the read back commented out. > Philip cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] dhcp: fix isc_boolean_t patch
On Sun, Apr 14, 2019 at 02:47:01PM +0200, Enrico Scholz via Openembedded-core
wrote:
> There is a copy & paste error in 5775e9ef2fce1d0b9860602f1065bb1e09bc1b61
> which breaks dhcpd.
>
> Cc: Armin Kuster
> Signed-off-by: Enrico Scholz
> ---
> ...1-dhcpd-fix-Replace-custom-isc_boolean_t-with-C-standa.patch | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git
> a/meta/recipes-connectivity/dhcp/dhcp/0001-dhcpd-fix-Replace-custom-isc_boolean_t-with-C-standa.patch
>
> b/meta/recipes-connectivity/dhcp/dhcp/0001-dhcpd-fix-Replace-custom-isc_boolean_t-with-C-standa.patch
> index d2e57714cd..fa3d9c4e1f 100644
> ---
> a/meta/recipes-connectivity/dhcp/dhcp/0001-dhcpd-fix-Replace-custom-isc_boolean_t-with-C-standa.patch
> +++
> b/meta/recipes-connectivity/dhcp/dhcp/0001-dhcpd-fix-Replace-custom-isc_boolean_t-with-C-standa.patch
> @@ -1816,7 +1816,7 @@ Index: dhcp-4.4.1/common/options.c
> {
> if (universe->save_func)
> -(*universe->save_func)(universe, options, oc, ISC_FALSE);
> -+(*universe->save_func)(universe, options, oc, true);
> ++(*universe->save_func)(universe, options, oc, false);
> else
> log_error("can't store options in %s space.", universe->name);
> }
Nice catch.
The root problem is that OE is carrying an own huge patch,
instead of using the much simpler and shorter upstream fix.
I'll send a patch to replace it with the upstream fix.
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] dhcp: Replace OE specific patch for compatibility with latest bind with upstream patch
This also fixes a dhcp breakage noticed by Enrico Scholz.
Signed-off-by: Adrian Bunk
---
...e-custom-isc_boolean_t-with-C-standa.patch | 2882 -
...ludes-of-new-BIND9-compatibility-hea.patch | 79 +
meta/recipes-connectivity/dhcp/dhcp_4.4.1.bb |2 +-
3 files changed, 80 insertions(+), 2883 deletions(-)
delete mode 100644
meta/recipes-connectivity/dhcp/dhcp/0001-dhcpd-fix-Replace-custom-isc_boolean_t-with-C-standa.patch
create mode 100644
meta/recipes-connectivity/dhcp/dhcp/0001-master-Added-includes-of-new-BIND9-compatibility-hea.patch
diff --git
a/meta/recipes-connectivity/dhcp/dhcp/0001-dhcpd-fix-Replace-custom-isc_boolean_t-with-C-standa.patch
b/meta/recipes-connectivity/dhcp/dhcp/0001-dhcpd-fix-Replace-custom-isc_boolean_t-with-C-standa.patch
deleted file mode 100644
index d2e57714cd..00
---
a/meta/recipes-connectivity/dhcp/dhcp/0001-dhcpd-fix-Replace-custom-isc_boolean_t-with-C-standa.patch
+++ /dev/null
@@ -1,2882 +0,0 @@
-From ffb1d1325bd6503df9a324befac5f5039ac77432 Mon Sep 17 00:00:00 2001
-From: Armin Kuster
-Date: Tue, 23 Oct 2018 10:36:56 +
-Subject: [PATCH] dhcpd: fix Replace custom isc_boolean_t with C standard bool
- type
-
-
-Upstream-Status: Pending
-
-Fixes issues introduced by bind when they changed their headers.
-
-Signed-off-by: Armin Kuster
- includes/dhcpd.h | 34 +-
- includes/heap.h| 2 +-
- includes/omapip/omapip.h | 2 +-
- includes/omapip/omapip_p.h | 6 +++---
- includes/tree.h| 2 +-
- 5 files changed, 23 insertions(+), 23 deletions(-)
-
-Index: dhcp-4.4.1/includes/dhcpd.h
-===
dhcp-4.4.1.orig/includes/dhcpd.h
-+++ dhcp-4.4.1/includes/dhcpd.h
-@@ -461,20 +461,20 @@ struct packet {
-* options we got in a previous exchange were still there, we need
-* to signal this in a reliable way.
-*/
-- isc_boolean_t agent_options_stashed;
-+ bool agent_options_stashed;
-
- /*
-* ISC_TRUE if packet received unicast (as opposed to multicast).
-* Only used in DHCPv6.
-*/
-- isc_boolean_t unicast;
-+ bool unicast;
-
- /* Propagates server value SV_ECHO_CLIENT_ID so it is available
- * in cons_options() */
- int sv_echo_client_id;
-
- /* Relay port check */
-- isc_boolean_t relay_source_port;
-+ bool relay_source_port;
- };
-
- /*
-@@ -1174,7 +1174,7 @@ struct dhc6_lease {
- struct dhc6_lease *next;
- struct data_string server_id;
-
-- isc_boolean_t released;
-+ bool released;
- int score;
- u_int8_t pref;
-
-@@ -1695,8 +1695,8 @@ struct ipv6_pool {
- int bits; /* number of bits, CIDR style */
- int units; /* allocation unit in bits */
- iasubopt_hash_t *leases;/* non-free leases */
-- isc_uint64_t num_active;/* count of active leases */
-- isc_uint64_t num_abandoned; /* count of abandoned leases */
-+ uint64_t num_active;/* count of active leases */
-+ uint64_t num_abandoned; /* count of abandoned leases */
- isc_heap_t *active_timeouts;/* timeouts for active leases */
- int num_inactive; /* count of inactive leases */
- isc_heap_t *inactive_timeouts; /* timeouts for expired or
-@@ -1732,11 +1732,11 @@ struct ipv6_pond {
- struct ipv6_pool **ipv6_pools; /* NULL-terminated array */
- int last_ipv6_pool; /* offset of last IPv6 pool
- used to issue a lease */
-- isc_uint64_t num_total; /* Total number of elements in the pond */
-- isc_uint64_t num_active;/* Number of elements in the pond in use */
-- isc_uint64_t num_abandoned; /* count of abandoned leases */
-+ uint64_t num_total; /* Total number of elements in the pond
*/
-+ uint64_t num_active;/* Number of elements in the pond in
use */
-+ uint64_t num_abandoned; /* count of abandoned leases */
- int logged; /* already logged a message */
-- isc_uint64_t low_threshold; /* low threshold to restart logging */
-+ uint64_t low_threshold; /* low threshold to restart logging */
- int jumbo_range;
- #ifdef EUI_64
- int use_eui_64; /* use EUI-64 address assignment when true */
-@@ -1745,9 +1745,9 @@ struct ipv6_pond {
-
- /*
- * Max addresses in a pond that can be supported by log threshold
-- * Currently based on max value supported by isc_uint64_t.
-+ * Currently based on max value supported by uint64_t.
- */
--#define POND_TRACK_MAX ISC_UINT64_MAX
-+#define POND_TRACK_MAX UINT64_MAX
-
- /* Flags for dhcp_ddns_cb_t */
- #define DDNS_UPDATE_ADDR 0x0001
Re: [OE-core] [PATCH v2] nettle: fix ptest failure
On Mon, Apr 15, 2019 at 09:06:12AM +0100, richard.pur...@linuxfoundation.org
wrote:
> On Mon, 2019-04-15 at 16:09 +0800, Yu, Mingli wrote:
> >
> > On 2019年04月15日 15:59, richard.pur...@linuxfoundation.org wrote:
> > > On Mon, 2019-04-15 at 15:40 +0800, mingli...@windriver.com wrote:
> > > > a/testsuite/dlopen-test.c 2016-10-01 00:28:38.0
> > > > -0700
> > > > -+++ b/testsuite/dlopen-test.c 2017-10-13 11:08:57.227572860
> > > > -0700
> > > > -@@ -9,7 +9,7 @@
> > > > +diff --git a/testsuite/dlopen-test.c b/testsuite/dlopen-test.c
> > > > +index 99d3535..92de9f8 100644
> > > > +--- a/testsuite/dlopen-test.c
> > > > b/testsuite/dlopen-test.c
> > > > +@@ -9,7 +9,9 @@ int
> > > >main (int argc UNUSED, char **argv UNUSED)
> > > >{
> > > >#if HAVE_LIBDL
> > > > - void *handle = dlopen ("../libnettle.so", RTLD_NOW);
> > > > + void *handle = dlopen ("/usr/lib/libnettle.so", RTLD_NOW);
> > > > ++ if (!handle)
> > > > ++ handle = dlopen ("/usr/lib64/libnettle.so", RTLD_NOW);
> > > > int (*get_version)(void);
> > > > if (!handle)
> > > >{
> > >
> > > What happens on a 32 bit system?
> > >
> > > You can't hardcode a specific libdir like that!
> >
> > I just rework the patch dlopen-test.patch which Juro Bystricky
> > generated
> > before, the previous patch only check /usr/lib/libnettle.so and I
> > updated it also to check /usr/lib64/libnettle.so if no
> > /usr/lib/libnettle.so exist.
> > - void *handle = dlopen ("../libnettle.so", RTLD_NOW);
> > + void *handle = dlopen ("/usr/lib/libnettle.so", RTLD_NOW);
> > ++ if (!handle)
> > ++ handle = dlopen ("/usr/lib64/libnettle.so", RTLD_NOW);
>
> What happens on x32? n32? or if I set libdir to lib32?
dlopen("libnettle.so", RTLD_NOW) should work,
this uses the normal library search path.
But is it actually worth permanently carrying a patch here?
run-ptest already skips one test for unrelated reasons,
and skipping another one would also be an option.
> Cheers,
>
> Richard
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v3] gcc-sanitizers: fix -Werror=maybe-uninitialized issue
On Mon, Apr 08, 2019 at 08:53:49PM -0700, Khem Raj wrote: > On Mon, Apr 8, 2019 at 7:32 PM wrote: > > > > From: Mingli Yu > > > > When DEBUG_BUILD = "1" added in local.conf, there > > comes below build error when "bitbake gcc-sanitizers": > > | > > ./../../../../../../../../work-shared/gcc-8.3.0-r0/gcc-8.3.0/libsanitizer/libbacktrace/../../libbacktrace/elf.c: > > In function 'elf_is_symlink': > > | > > ../../../../../../../../../work-shared/gcc-8.3.0-r0/gcc-8.3.0/libsanitizer/libbacktrace/../../libbacktrace/elf.c:772:21: > > error: 'st.st_mode' may be used uninitialized in this function > > [-Werror=maybe-uninitialized] > > | return S_ISLNK (st.st_mode); > > > > Per https://gcc.gnu.org/ml/gcc-patches/2019-04/msg00315.html, > > the gcc upstream thinks the warning is a false > > positive and suggests to use -O2 rather than -Og > > or -O1 when compiling that file, so pass -Wno-error > > to compiler when -Og is used to silence the error. > > > > Not particular to this change but in general if a package says that it > does not support -Og > then we are just going to get into more and more untested grounds > especially during runtime > so I wonder how useful it will be to use -Og for such packages or any > other non supported > combination for that matter. This has nothing to do with specific packages not supporting -Og or any other combination, it is just about how to best workaround a compiler bug temporarily. gcc has bug(s) emitting bogus warnings with -Og, and these are build failures with some packages that build with -Werror. None of this is related to whether or not the packages will work at runtime with -Og. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] cryptodev: update SRCREV
On Sun, Apr 14, 2019 at 11:42:31PM -0400, kai.k...@windriver.com wrote:
> From: Kai Kang
>
> Update SRCREV of cryptodev which only contains one fix for linux 5.0:
>...
> --- a/meta/recipes-kernel/cryptodev/cryptodev.inc
> +++ b/meta/recipes-kernel/cryptodev/cryptodev.inc
> @@ -4,7 +4,7 @@ LICENSE = "GPLv2"
> LIC_FILES_CHKSUM = "file://COPYING;md5=b234ee4d69f5fce4486a80fdaf4a4263"
>
> SRC_URI = "git://github.com/cryptodev-linux/cryptodev-linux"
> -SRCREV = "fd8b15ef1c8398a69a37932ee48c74ab40329a29"
> +SRCREV = "f971e0cd4a0ebe59fb2e8e17240399bf6901b09b"
>
> S = "${WORKDIR}/git"
This moves cryptodev from a release to a git snapshot,
but no PV is set to show that.
It is a systematic problem caused by the switch to git hashes for
releases that random git snapshots look exactly the same as releases
without any clean way to see what a commit actually is.
IMHO this needs support for tags, and then checks like (pseudo-code)
if(TAG) (commit(TAG) == SRCREV)
TAG xor (PV contains "+git")
Short-term for the suggested change in cryptodev the
"which only contains one fix" is correct, and this
is not much different from adding the fix as .patch
which also wouldn't change PV.
So no objection from me to applying the suggested patch as-is.
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v3] gcc-sanitizers: fix -Werror=maybe-uninitialized issue
On Mon, Apr 15, 2019 at 07:19:13AM -0700, Khem Raj wrote: > > What are you trying to convey ? That’s what I mentioned before I began my > reply however to reiterate my point was if a package is not usually built > and tested with this combination which is evident because it fails to build > then how good would it be if we fix this error especially complex packages > like compilers so is it worth to fix them or disable Og for them Packages that usually get built and tested with -Og should be pretty rare, and these specific build failures are better at finding the rare packages that use -Werror than pointing at potential miscompilations. From a distribution point of view, a package build with -Werror by default is arguably a bug since this frequently breaks when something is changed (usually the compiler version). -Og is better suited than the -O that was previously used for debugging, but are we talking about debug builds or production builds? If users would be using DEBUG_OPTIMIZATION in production builds that would be wrong - this will always be a mostly untested situation with an increased probability of hitting bugs noone else has seen before. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] i2c-tools: Split binaries and library
On Tue, Apr 16, 2019 at 12:02:04PM +, John Ernberg wrote:
>...
> --- a/meta/recipes-devtools/i2c-tools/i2c-tools_4.1.bb
> +++ b/meta/recipes-devtools/i2c-tools/i2c-tools_4.1.bb
>...
> -PACKAGES =+ "${PN}-misc"
> +PACKAGES =+ "${PN}-misc ${PN}-utils "
>...
i2c-tools-utils is a weird name.
It would be better to add a new package libi2c for the library instead.
This would also not break backwards compatibility for people
already installing i2c-tools to their images.
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 2/2] glibc: Add a C.UTF-8 locale
On Tue, Apr 16, 2019 at 05:49:44PM +0800, changqing...@windriver.com wrote: > From: Changqing Li > > * This patch is get from fedora project, link: > https://src.fedoraproject.org/rpms/glibc/blob/0457f649e3fe6299efe384da13dfc923bbe65707/f/glibc-c-utf8-locale.patch > > * At this point, most major distro have support this locale >... Is there now agreement on the exact semantics of this locale? I remember this was a problem when it was suggested for upstream inclusion ~ 5 years ago. E.g. the Debian definition of C.UTF-8 is very different to and more than 10 times to size of the Fedora definition of C.UTF-8. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] bitbake.conf: add git-lfs to HOSTTOOLS_NONFATAL
On Wed, Apr 17, 2019 at 09:46:25AM +0100, richard.pur...@linuxfoundation.org wrote: > On Wed, 2019-04-17 at 10:20 +0800, Saini, Naveen Kumar wrote: >... > > Should this be added to HOSTTOOLS instead so lfs files are always > > fetched for packages that use it? > > No, that would mean everyone has to install it. > > I'm ok with adding it to HOSTTOOLS_NONFATAL as soon as we have some > mechanism in the fetcher or in recipes which detects lfs usage and hard > errors if its present but git-lfs is not installed. > > That way its deterministic - it builds with git-lfs installed and > errors if it is not. Is it OK that some packages are not buildable at all on supported distributions? Your "everyone has to install it" worry misses the much bigger problem that git-lfs is a relatively new tool and not available in distributions like Debian 9 or Ubuntu 16.04. > Cheers, > > Richard cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] bitbake.conf: add git-lfs to HOSTTOOLS_NONFATAL
On Wed, Apr 17, 2019 at 10:37:45AM +0100, richard.pur...@linuxfoundation.org wrote: > On Wed, 2019-04-17 at 12:35 +0300, Adrian Bunk wrote: >... > > Your "everyone has to install it" worry misses the much bigger > > problem > > that git-lfs is a relatively new tool and not available in > > distributions > > like Debian 9 or Ubuntu 16.04. > > Someone could certainly write a native recipe for lfs and add that as a > dependency which would also solve this problem. I'd be quite happy to > see that and it would neatly solve the problems. This was also my first thought. It stops being neat once you realize that it requires packaging a 3 digit number of Go libraries. > Cheers, > > Richard cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] Set XZ_COMPRESSION_LEVEL to -9
On Fri, Apr 12, 2019 at 02:44:05PM -0700, Andre McCurdy wrote: > On Fri, Apr 12, 2019 at 2:09 PM Adrian Bunk wrote: > > > > It is consistent with other compressors also using their > > best compression. > > > > xz is currently the option that offers best compression, > > using settings even lower than the default is surprising > > and makes it harder to choose the best available compression. > > > > For anyone who cares about compression time using a different > > option like gzip or bzip2 is the logical choice. > > The concern with xz's highest compression level is memory usage rather > than CPU time. Quoting from the manpage: > > Preset DictSize CompCPUCompMem DecMem > -0 256 KiB 0 3 MiB1 MiB > -1 1 MiB 1 9 MiB2 MiB > -2 2 MiB 2 17 MiB3 MiB > -3 4 MiB 3 32 MiB5 MiB > -4 4 MiB 4 48 MiB5 MiB > -5 8 MiB 5 94 MiB9 MiB > -6 8 MiB 6 94 MiB9 MiB > -7 16 MiB 6186 MiB 17 MiB > -8 32 MiB 6370 MiB 33 MiB > -9 64 MiB 6674 MiB 65 MiB > > Given that these are per-thread the memory requirements may start to > get a little unreasonable with xz -9. We do limit usage to 50% of > physical memory via XZ_DEFAULTS though so maybe it's not a big > concern? Due to the limit, and also due to the fact that build machines with very low RAM/core are likely to have bigger problems earlier: The compile task of a recipe spawns the same number of gcc processes, and there can be several compile tasks running. gcc memory usage when compiling C++ code like webkit can be worse than these per-thread numbers. > Either way, perhaps now would be a good time to remove > XZ_COMPRESSION_LEVEL from image_types.bbclass and instead just include > the compression level option in XZ_DEFAULTS so that it gets used > consistently everywhere. OPKGBUILDCMD uses XZ_DEFAULTS, and the decompression memory requirement on the target for -9 might be a problem if someone uses package feeds on low-memory targets. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] gcc: Remove Java support variables
Java support was removed in upstream gcc 7.
Signed-off-by: Adrian Bunk
---
meta/recipes-devtools/gcc/gcc-8.3.inc | 1 -
meta/recipes-devtools/gcc/gcc-configure-common.inc | 8 +---
2 files changed, 1 insertion(+), 8 deletions(-)
diff --git a/meta/recipes-devtools/gcc/gcc-8.3.inc
b/meta/recipes-devtools/gcc/gcc-8.3.inc
index f7bf257fa6..88a9df2049 100644
--- a/meta/recipes-devtools/gcc/gcc-8.3.inc
+++ b/meta/recipes-devtools/gcc/gcc-8.3.inc
@@ -82,7 +82,6 @@ B = "${WORKDIR}/gcc-${PV}/build.${HOST_SYS}.${TARGET_SYS}"
# Language Overrides
FORTRAN = ""
-JAVA = ""
LTO = "--enable-lto"
SSP ?= "--disable-libssp"
diff --git a/meta/recipes-devtools/gcc/gcc-configure-common.inc
b/meta/recipes-devtools/gcc/gcc-configure-common.inc
index 375c5e90c9..b6f2ca541d 100644
--- a/meta/recipes-devtools/gcc/gcc-configure-common.inc
+++ b/meta/recipes-devtools/gcc/gcc-configure-common.inc
@@ -5,15 +5,9 @@ require gcc-shared-source.inc
#
# These can be overridden by the version specific .inc file.
-# Java (gcj doesn't work on all architectures)
-JAVA ?= ",java"
-JAVA_arm ?= ""
-JAVA_armeb ?= ""
-JAVA_mipsel ?= ""
-JAVA_sh3 ?= ""
# gcc 3.x expects 'f77', 4.0 expects 'f95', 4.1 and 4.2 expect 'fortran'
FORTRAN ?= ",f77"
-LANGUAGES ?= "c,c++${FORTRAN}${JAVA}"
+LANGUAGES ?= "c,c++${FORTRAN}"
EXTRA_OECONF_BASE ?= ""
EXTRA_OECONF_PATHS ?= ""
--
2.17.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] Set XZ_COMPRESSION_LEVEL to -9
It is consistent with other compressors also using their best compression. xz is currently the option that offers best compression, using settings even lower than the default is surprising and makes it harder to choose the best available compression. For anyone who cares about compression time using a different option like gzip or bzip2 is the logical choice. For decompression, better compressed is actually faster to decompress. Signed-off-by: Adrian Bunk --- meta/classes/image_types.bbclass | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meta/classes/image_types.bbclass b/meta/classes/image_types.bbclass index 95aa1674cf..1c44ec4a80 100644 --- a/meta/classes/image_types.bbclass +++ b/meta/classes/image_types.bbclass @@ -54,7 +54,7 @@ def imagetypes_getdepends(d): # Sort the set so that ordering is consistant return " ".join(sorted(deps)) -XZ_COMPRESSION_LEVEL ?= "-3" +XZ_COMPRESSION_LEVEL ?= "-9" XZ_INTEGRITY_CHECK ?= "crc32" ZIP_COMPRESSION_LEVEL ?= "-9" -- 2.17.1 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] go: Allow bootstrapping using host go compiler
On Fri, Apr 12, 2019 at 02:26:20PM -0400, Randy MacLeod wrote: >... > In the long run, don't we want to avoid any new binaries or host tools? Is > anyone else in the go community (Debian maybe?) interested in > bootstrapping go on arm64 hosts or do they all just use the binary? >... Binary distributions like Debian have to bootstrap compilers only once per architecture. After the initial bootstrap there is always the previous version package in the distribution that can be used to build the next version. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] go: Allow bootstrapping using host go compiler
On Fri, Apr 12, 2019 at 01:30:46PM +0100, Daniel Thompson wrote: > Currently go-native bootstraps without any dependency on the host go > compiler by building go-1.4 (the last version written in C) and using > that to build a more recent version of go. This does not work on host > architectures, such as arm64, that are not supported by go-1.4. To > support these host architectures we must rely on an existing host go > compiler and use that to build go-native instead. >... Why is this the only option for you? The clean way to bootstrap go would be by building gccgo and using that as starting point for the bootstrap. Haven't tried how trivial or difficult it is to make that work, but it sounds more long-term maintainable than having different problems depending on what architecture and host distribution is used - it doesn't sound like a good idea to have to test and maintain all combinations, e.g. whether Go 1.6 on arm64 in Ubuntu 16.04 manages to bootstrap the latest Go. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] Set XZ_COMPRESSION_LEVEL to -9
On Fri, Apr 12, 2019 at 04:12:19PM -0700, Khem Raj wrote: > On Fri, Apr 12, 2019 at 2:09 PM Adrian Bunk wrote: > > > > It is consistent with other compressors also using their > > best compression. > > > > xz is currently the option that offers best compression, > > using settings even lower than the default is surprising > > and makes it harder to choose the best available compression. > > > > For anyone who cares about compression time using a different > > option like gzip or bzip2 is the logical choice. > > > > For decompression, better compressed is actually faster > > to decompress. > > I worry about resources we need to spend when creating these archives. > Can you post some comparisons > along to assess the performance. On my laptop single-threaded compression of an image I am frequently building takes 20s with -3 and 55s with -9. Building the whole image from scratch takes more than 2 hours. If you care about resources spent, I remember it saved me around 10 minutes build time when I changed OPKGBUILDCMD from the default "xz -6" to "gzip -1" - for the common case where package feeds are not used there is no point in spending time on compression and decompression. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [oe-core][PATCH 1/1] puzzles: fix uninitialized variable compiler error
On Thu, Mar 14, 2019 at 07:25:16PM +, Burton, Ross wrote:
> Can we *please* start sending these upstream. It's not like the
> maintainer isn't responsive.
This would also help to get such patches properly reviewed.
> Ross
>
> On Thu, 14 Mar 2019 at 19:20, Joe Slater wrote:
>...
> > +The compiler does not realize that we must go through the while()
> > +loop at least once, so we replace it with a for() loop.
>...
> > +-n = t->root;
> > +-while (n) {
> > ++/*
> > ++ * We know t->root is not NULL. The logic
> > ++ * to break out of this is at the end of the loop.
> > ++ */
> > ++for (n = t->root;;) {
>...
This is the second patch this week where I don't see why a "fix" should
make any difference.
The code immediately above is:
if (t->root == NULL) {
...
return orig_e;
)
The submitter did not provide information how to reproduce,
but when I try to reproduce the problem on amd64 it happens
only with -Og (due to puzzles upstream building with -Werror).
This would also explain why such patches suddenly start getting
submitted - 2 weeks ago DEBUG_OPTIMIZATION was changed from -O to -Og.
-Werror is added after the passed CFLAGS so adding -Wno-error globally
would not help here, but a non-upstreamable patch to remove the -Werror
looks more correct here as a short-term workaround.
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] mdadm: fix gcc8 maybe-uninitialized/format-overflow warning
On Tue, Mar 12, 2019 at 05:41:58PM +0800, changqing...@windriver.com wrote: > From: Changqing Li > > while compiled with -Werror=maybe-uninitialized/-Werror=format-overflow=, > it failed > > [snip] > | Incremental.c: In function 'Incremental_container': > | Incremental.c:1593:3: error: 'mdfd' may be used uninitialized in this > function [-Werror=maybe-uninitialized] > | close(mdfd); > | ^~~ > > [snip] > super-intel.c: In function 'apply_takeover_update': > | super-intel.c:9615:15: error: '%d' directive writing between 1 and 11 bytes > into a region of size 7 [-Werror=format-overflow=] > | " MISSING_%d", du->index); > | ^~ >... I am seeing these warnings only with -Og, are you also seeing them with -Og (DEBUG_OPTIMIZATION) only? If this is true, I would consider https://sources.debian.org/src/mdadm/4.1-2/debian/patches/debian-no-Werror.diff/ a better workaround. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [yocto] patchwork
On Mon, May 13, 2019 at 10:32:48AM +0300, Mark Hatle wrote: > On 5/12/19 9:04 PM, akuster808 wrote: > > ok, so no Admins. This is unexceptionable. > > > > OE TSC and Board, I believe its your time to get involved. > > I've not used patchwork before, do you know who originally configured it? Was > it Paul Eggleton, or Richard, or? If I have an idea who was originally > responsible, I'm pretty sure we can figure out a handoff plan to someone else. http://git.yoctoproject.org/cgit/cgit.cgi/patchwork/ > --Mark cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] ofono: Use external ell instead of an internal copy
Signed-off-by: Adrian Bunk
---
meta/recipes-connectivity/ofono/ofono.inc | 4 +--
...in-Quiet-ld-errors-with-external-ell.patch | 36 +++
meta/recipes-connectivity/ofono/ofono_1.29.bb | 1 +
3 files changed, 39 insertions(+), 2 deletions(-)
create mode 100644
meta/recipes-connectivity/ofono/ofono/0001-main-Quiet-ld-errors-with-external-ell.patch
diff --git a/meta/recipes-connectivity/ofono/ofono.inc
b/meta/recipes-connectivity/ofono/ofono.inc
index 0472414b19..e1185c6e6b 100644
--- a/meta/recipes-connectivity/ofono/ofono.inc
+++ b/meta/recipes-connectivity/ofono/ofono.inc
@@ -7,7 +7,7 @@ LIC_FILES_CHKSUM =
"file://COPYING;md5=eb723b61539feef013de476e68b5c50a \
inherit autotools pkgconfig update-rc.d systemd bluetooth
gobject-introspection-data
-DEPENDS = "dbus glib-2.0 udev mobile-broadband-provider-info"
+DEPENDS = "dbus glib-2.0 udev mobile-broadband-provider-info ell"
INITSCRIPT_NAME = "ofono"
INITSCRIPT_PARAMS = "defaults 22"
@@ -19,7 +19,7 @@ PACKAGECONFIG ??= "\
PACKAGECONFIG[systemd] =
"--with-systemdunitdir=${systemd_unitdir}/system/,--with-systemdunitdir="
PACKAGECONFIG[bluez] = "--enable-bluetooth, --disable-bluetooth, ${BLUEZ}"
-EXTRA_OECONF += "--enable-test"
+EXTRA_OECONF += "--enable-test --enable-external-ell"
SYSTEMD_SERVICE_${PN} = "ofono.service"
diff --git
a/meta/recipes-connectivity/ofono/ofono/0001-main-Quiet-ld-errors-with-external-ell.patch
b/meta/recipes-connectivity/ofono/ofono/0001-main-Quiet-ld-errors-with-external-ell.patch
new file mode 100644
index 00..f9858e7f20
--- /dev/null
+++
b/meta/recipes-connectivity/ofono/ofono/0001-main-Quiet-ld-errors-with-external-ell.patch
@@ -0,0 +1,36 @@
+From 48e31f9fc3cf3c486c3d27a67b2687f6df0c5c71 Mon Sep 17 00:00:00 2001
+From: Denis Kenzior
+Date: Thu, 16 May 2019 15:10:53 -0500
+Subject: main: Quiet ld errors with external ell
+
+When oFono is built with --enable-external-ell, the compiler for some
+reason does not generate a debug section on some systems. This is due
+to the fact that l_debug is never called. However, ell also does not
+call l_debug, yet when built-in ell is used, the section is created by
+the compiler.
+
+For now work around this by adding a no-op l_debug() call in main.c.
+The real fix is to migrate all of the oFono logging functionality to use
+ell instead.
+
+Upstream-Status: Backport
+Signed-off-by: Adrian Bunk
+---
+ src/main.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/src/main.c b/src/main.c
+index 8623a060..4529cde1 100644
+--- a/src/main.c
b/src/main.c
+@@ -236,6 +236,7 @@ int main(int argc, char **argv)
+ event_loop = g_main_loop_new(NULL, FALSE);
+
+ l_log_set_stderr();
++ l_debug("");
+ l_debug_enable("*");
+ l_main_init();
+
+--
+2.20.1
+
diff --git a/meta/recipes-connectivity/ofono/ofono_1.29.bb
b/meta/recipes-connectivity/ofono/ofono_1.29.bb
index a22b99a728..a5fa81de2f 100644
--- a/meta/recipes-connectivity/ofono/ofono_1.29.bb
+++ b/meta/recipes-connectivity/ofono/ofono_1.29.bb
@@ -5,6 +5,7 @@ SRC_URI = "\
file://ofono \
file://0001-build-Fix-a-race-condition.patch \
file://0001-build-Add-check-for-explicit_bzero-support.patch \
+ file://0001-main-Quiet-ld-errors-with-external-ell.patch \
"
SRC_URI[md5sum] = "4fa0372630ff03f223452e4d05efa8f8"
SRC_URI[sha256sum] =
"67f0f8e5740dea5b46309e40667d1e560be39c90ef08dd01ff9e9ce8e61f0679"
--
2.17.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 33/37] gst-examples: upgrade to latest revision
On Fri, May 17, 2019 at 08:11:47PM +0200, Alexander Kanavin wrote:
> Signed-off-by: Alexander Kanavin
> ---
> meta/recipes-multimedia/gstreamer/gst-examples_git.bb | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/meta/recipes-multimedia/gstreamer/gst-examples_git.bb
> b/meta/recipes-multimedia/gstreamer/gst-examples_git.bb
> index 75ac9b75c13..e572ec8db8d 100644
> --- a/meta/recipes-multimedia/gstreamer/gst-examples_git.bb
> +++ b/meta/recipes-multimedia/gstreamer/gst-examples_git.bb
> @@ -8,7 +8,7 @@ SRC_URI =
> "git://gitlab.freedesktop.org/gstreamer/gst-examples.git;protocol=http
> file://0001-Make-player-examples-installable.patch \
> file://gst-player.desktop"
>
> -SRCREV = "2b3fc175c252cd5a537e4b2864b572a8372473d6"
> +SRCREV = "3f51023aca06d28ccfb1d5383d99ca7fbfb287c8"
> PV = "0.0.1+git${SRCPV}"
> UPSTREAM_CHECK_COMMITS = "1"
Upstream git contains a tagged 1.16.0 release.
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 20/37] gnu-config: upgrade to latest revision
On Fri, May 17, 2019 at 08:11:34PM +0200, Alexander Kanavin wrote:
> Signed-off-by: Alexander Kanavin
> ---
> meta/recipes-devtools/gnu-config/gnu-config_git.bb | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/meta/recipes-devtools/gnu-config/gnu-config_git.bb
> b/meta/recipes-devtools/gnu-config/gnu-config_git.bb
> index e597ebedbc1..f52597936db 100644
> --- a/meta/recipes-devtools/gnu-config/gnu-config_git.bb
> +++ b/meta/recipes-devtools/gnu-config/gnu-config_git.bb
> @@ -8,7 +8,7 @@ DEPENDS_class-native = "hostperl-runtime-native"
>
> INHIBIT_DEFAULT_DEPS = "1"
>
> -SRCREV = "058639be227bbe8f03cc39f79f7ce84918012143"
> +SRCREV = "b98424c249119b79d3f709e26eb86f2fd4d5e5f3"
> PV = "20181128+git${SRCPV}"
>...
PV needs updating to 20190428.
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] libpam: Upgrade 1.3.0 -> 1.3.1
ping
Thanks
Adrian
On Mon, May 20, 2019 at 07:30:52PM +0300, Adrian Bunk wrote:
> Remove patch applied upstream.
> Upstream tarball location changed.
>
> Signed-off-by: Adrian Bunk
> ---
> ...libpam-xtests-remove-bash-dependency.patch | 226 --
> .../pam/{libpam_1.3.0.bb => libpam_1.3.1.bb} | 9 +-
> 2 files changed, 3 insertions(+), 232 deletions(-)
> delete mode 100644
> meta/recipes-extended/pam/libpam/libpam-xtests-remove-bash-dependency.patch
> rename meta/recipes-extended/pam/{libpam_1.3.0.bb => libpam_1.3.1.bb} (95%)
>
> diff --git
> a/meta/recipes-extended/pam/libpam/libpam-xtests-remove-bash-dependency.patch
> b/meta/recipes-extended/pam/libpam/libpam-xtests-remove-bash-dependency.patch
> deleted file mode 100644
> index 680029ae0d..00
> ---
> a/meta/recipes-extended/pam/libpam/libpam-xtests-remove-bash-dependency.patch
> +++ /dev/null
> @@ -1,226 +0,0 @@
> -From 555407ff6e2f742df64ae93859f14a0fc1397829 Mon Sep 17 00:00:00 2001
> -From: Wenzong Fan
> -Date: Fri, 12 Sep 2014 05:35:05 -0400
> -Subject: [PATCH] libpam/xtests: remove bash dependency
> -
> -There's not bash specific syntax in the xtest scripts:
> -
> - # after below patches applied:
> - $ cd Linux-PAM-1.1.6/xtests
> - $ checkbashisms *.sh
> - No output
> -
> -Just remove the runtime dependency to bash.
> -
> -Upstream-Status: Pending
> -
> -Signed-off-by: Wenzong Fan
>
> - xtests/run-xtests.sh |2 +-
> - xtests/tst-pam_access1.sh|2 +-
> - xtests/tst-pam_access2.sh|2 +-
> - xtests/tst-pam_access3.sh|2 +-
> - xtests/tst-pam_access4.sh|2 +-
> - xtests/tst-pam_assemble_line1.sh |2 +-
> - xtests/tst-pam_group1.sh |2 +-
> - xtests/tst-pam_limits1.sh|2 +-
> - xtests/tst-pam_pwhistory1.sh |2 +-
> - xtests/tst-pam_substack1.sh |2 +-
> - xtests/tst-pam_substack2.sh |2 +-
> - xtests/tst-pam_substack3.sh |2 +-
> - xtests/tst-pam_substack4.sh |2 +-
> - xtests/tst-pam_substack5.sh |2 +-
> - xtests/tst-pam_succeed_if1.sh|2 +-
> - xtests/tst-pam_unix1.sh |2 +-
> - xtests/tst-pam_unix2.sh |2 +-
> - xtests/tst-pam_unix3.sh |2 +-
> - xtests/tst-pam_unix4.sh |2 +-
> - 19 files changed, 19 insertions(+), 19 deletions(-)
> -
> -diff --git a/xtests/run-xtests.sh b/xtests/run-xtests.sh
> -index 3a89057..1cf8684 100755
> a/xtests/run-xtests.sh
> -+++ b/xtests/run-xtests.sh
> -@@ -1,4 +1,4 @@
> --#!/bin/bash
> -+#!/bin/sh
> -
> - SRCDIR=$1
> - shift 1
> -diff --git a/xtests/tst-pam_access1.sh b/xtests/tst-pam_access1.sh
> -index 180d256..70521d2 100755
> a/xtests/tst-pam_access1.sh
> -+++ b/xtests/tst-pam_access1.sh
> -@@ -1,4 +1,4 @@
> --#!/bin/bash
> -+#!/bin/sh
> -
> - /usr/sbin/groupadd tstpamaccess
> - /usr/sbin/useradd -G tstpamaccess -p '!!' tstpamaccess1
> -diff --git a/xtests/tst-pam_access2.sh b/xtests/tst-pam_access2.sh
> -index 0a30275..7e3e60f 100755
> a/xtests/tst-pam_access2.sh
> -+++ b/xtests/tst-pam_access2.sh
> -@@ -1,4 +1,4 @@
> --#!/bin/bash
> -+#!/bin/sh
> -
> - /usr/sbin/groupadd tstpamaccess
> - /usr/sbin/useradd -p '!!' tstpamaccess2
> -diff --git a/xtests/tst-pam_access3.sh b/xtests/tst-pam_access3.sh
> -index 348e0c3..3630e2e 100755
> a/xtests/tst-pam_access3.sh
> -+++ b/xtests/tst-pam_access3.sh
> -@@ -1,4 +1,4 @@
> --#!/bin/bash
> -+#!/bin/sh
> -
> - /usr/sbin/useradd -p '!!' tstpamaccess3
> - ./tst-pam_access3
> -diff --git a/xtests/tst-pam_access4.sh b/xtests/tst-pam_access4.sh
> -index 61e7b44..4538df4 100755
> a/xtests/tst-pam_access4.sh
> -+++ b/xtests/tst-pam_access4.sh
> -@@ -1,4 +1,4 @@
> --#!/bin/bash
> -+#!/bin/sh
> -
> - /usr/sbin/useradd -p '!!' tstpamaccess4
> - ./tst-pam_access4
> -diff --git a/xtests/tst-pam_assemble_line1.sh
> b/xtests/tst-pam_assemble_line1.sh
> -index 248d47e..dc2a675 100755
> a/xtests/tst-pam_assemble_line1.sh
> -+++ b/xtests/tst-pam_assemble_line1.sh
> -@@ -1,3 +1,3 @@
> --#!/bin/bash
> -+#!/bin/sh
> -
> - exec ./tst-pam_authfail tst-pam_assemble_line1
> -diff --git a/xtests/tst-pam_group1.sh b/xtests/tst-pam_group1.sh
> -index b76377f..44faca9 100755
> a/xtests/tst-pam_group1.sh
> -+++ b/xtests/tst-pam_group1.sh
> -@@ -1,4 +1,4 @@
> --#!/bin/bash
> -+#!/bin/sh
> -
> - /usr/sbin/groupadd tstpamgrpg
> - /usr/sbin/useradd -p '!!' tstpamgrp
> -diff --git a/xtests/tst-pam_limits1.sh b/xtests/tst-pam_limits1.sh
> -index 4faa822..32c021d 100755
> a/xtests/tst-pam_limits1.sh
> -+++ b/xtests/tst-pam_limits1.
Re: [OE-core] Should systemd be marked as incompatible with musl?
On Fri, May 24, 2019 at 12:34:23PM -0700, Andre McCurdy wrote: > On Fri, May 24, 2019 at 11:46 AM Adrian Bunk wrote: > > On Fri, May 24, 2019 at 11:04:50AM -0700, Khem Raj wrote: >... > > > I think we should put in plan for 2.8 and define the scope, since we > > > are switching > > > poky defaults to systemd, > > > > Switching glibc builds to systemd as default is a reasonable decision. > > > > Switching musl builds to systemd as default would be very bad. > > > > Combining a tiny C library with a huge init system completely misses > > the configurations where the tiny C library actually makes sense for > > users. > > For new projects yes. However I know of a project (a big project, > shipping millions of devices) which picked systemd and glibc long ago > and is now running out of space. They already have various solutions > to free up Flash (some apps switched to being runtime downloadable, > etc) but if/when more savings need to be found then switching from > glibc to musl might be a less invasive change than switching from > systemd to some other init system. We obviously shouldn't make > decisions for OE today based on the historical decisions of one > project, but I just want to make the point that real world projects > have a lifetime and may end up with a combination of systemd + musl > due on past decisions that may not make sense for a new project > starting today. I am feeling guilty that there are two only partially related topics mixed in this discussion. In this part of the discussion the topic was what the default (and CI-tested) init system for musl should be - it seems obvious to me that systemd is not what users will usually want to use with musl. But there is also the topic whether systemd on musl is in a state that it should be made available at all. Does any of these millions of devices have untrusted users or an internet connection? At that point my email that started this thread becomes relevant, the fact that the systemd/musl patches in OE add new security vulnerabilities and other bugs - and none of the systemd-on-musl proponents seems to consider this a problem they have to fix ASAP. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] Remove Go 1.11
There doesn't seem to be a reason to keep it in addition to 1.12 now.
Signed-off-by: Adrian Bunk
---
meta/recipes-devtools/go/go-1.11.inc | 23 --
...ow-CC-and-CXX-to-have-multiple-words.patch | 31 --
...ent-based-hash-generation-less-pedan.patch | 218 --
...-to-be-overridden-in-the-environment.patch | 48 ---
...4-ld-add-soname-to-shareable-objects.patch | 45 ---
...de-CC-when-building-dist-and-go_boot.patch | 37 ---
...dist-separate-host-and-target-builds.patch | 282 --
...d-go-make-GOROOT-precious-by-default.patch | 106 ---
...008-use-GOBUILDMODE-to-set-buildmode.patch | 37 ---
...place-glibc-dynamic-linker-with-musl.patch | 128
.../go/go-cross-canadian_1.11.bb | 2 -
meta/recipes-devtools/go/go-cross_1.11.bb | 2 -
meta/recipes-devtools/go/go-crosssdk_1.11.bb | 2 -
meta/recipes-devtools/go/go-native_1.11.bb| 2 -
meta/recipes-devtools/go/go-runtime_1.11.bb | 2 -
meta/recipes-devtools/go/go_1.11.bb | 14 -
16 files changed, 979 deletions(-)
delete mode 100644 meta/recipes-devtools/go/go-1.11.inc
delete mode 100644
meta/recipes-devtools/go/go-1.11/0001-allow-CC-and-CXX-to-have-multiple-words.patch
delete mode 100644
meta/recipes-devtools/go/go-1.11/0002-cmd-go-make-content-based-hash-generation-less-pedan.patch
delete mode 100644
meta/recipes-devtools/go/go-1.11/0003-allow-GOTOOLDIR-to-be-overridden-in-the-environment.patch
delete mode 100644
meta/recipes-devtools/go/go-1.11/0004-ld-add-soname-to-shareable-objects.patch
delete mode 100644
meta/recipes-devtools/go/go-1.11/0005-make.bash-override-CC-when-building-dist-and-go_boot.patch
delete mode 100644
meta/recipes-devtools/go/go-1.11/0006-cmd-dist-separate-host-and-target-builds.patch
delete mode 100644
meta/recipes-devtools/go/go-1.11/0007-cmd-go-make-GOROOT-precious-by-default.patch
delete mode 100644
meta/recipes-devtools/go/go-1.11/0008-use-GOBUILDMODE-to-set-buildmode.patch
delete mode 100644
meta/recipes-devtools/go/go-1.11/0009-ld-replace-glibc-dynamic-linker-with-musl.patch
delete mode 100644 meta/recipes-devtools/go/go-cross-canadian_1.11.bb
delete mode 100644 meta/recipes-devtools/go/go-cross_1.11.bb
delete mode 100644 meta/recipes-devtools/go/go-crosssdk_1.11.bb
delete mode 100644 meta/recipes-devtools/go/go-native_1.11.bb
delete mode 100644 meta/recipes-devtools/go/go-runtime_1.11.bb
delete mode 100644 meta/recipes-devtools/go/go_1.11.bb
diff --git a/meta/recipes-devtools/go/go-1.11.inc
b/meta/recipes-devtools/go/go-1.11.inc
deleted file mode 100644
index d03e26cea0..00
--- a/meta/recipes-devtools/go/go-1.11.inc
+++ /dev/null
@@ -1,23 +0,0 @@
-require go-common.inc
-
-GO_BASEVERSION = "1.11"
-GO_MINOR = ".4"
-PV .= "${GO_MINOR}"
-FILESEXTRAPATHS_prepend := "${FILE_DIRNAME}/go-${GO_BASEVERSION}:"
-
-LIC_FILES_CHKSUM = "file://LICENSE;md5=5d4950ecb7b26d2c5e4e7b4e0dd74707"
-
-SRC_URI += "\
-file://0001-allow-CC-and-CXX-to-have-multiple-words.patch \
-file://0002-cmd-go-make-content-based-hash-generation-less-pedan.patch \
-file://0003-allow-GOTOOLDIR-to-be-overridden-in-the-environment.patch \
-file://0004-ld-add-soname-to-shareable-objects.patch \
-file://0005-make.bash-override-CC-when-building-dist-and-go_boot.patch \
-file://0006-cmd-dist-separate-host-and-target-builds.patch \
-file://0007-cmd-go-make-GOROOT-precious-by-default.patch \
-file://0008-use-GOBUILDMODE-to-set-buildmode.patch \
-"
-SRC_URI_append_libc-musl = "
file://0009-ld-replace-glibc-dynamic-linker-with-musl.patch"
-
-SRC_URI[main.md5sum] = "a77697673215be465d1b583680ef2318"
-SRC_URI[main.sha256sum] =
"4cfd42720a6b1e79a8024895fa6607b69972e8e32446df76d6ce79801bbadb15"
diff --git
a/meta/recipes-devtools/go/go-1.11/0001-allow-CC-and-CXX-to-have-multiple-words.patch
b/meta/recipes-devtools/go/go-1.11/0001-allow-CC-and-CXX-to-have-multiple-words.patch
deleted file mode 100644
index 4442858c83..00
---
a/meta/recipes-devtools/go/go-1.11/0001-allow-CC-and-CXX-to-have-multiple-words.patch
+++ /dev/null
@@ -1,31 +0,0 @@
-From 7cc519aa5f84cf8fc7ac8c10fc69aa8040330ea0 Mon Sep 17 00:00:00 2001
-From: Matt Madison
-Date: Mon, 19 Feb 2018 08:49:33 -0800
-Subject: [PATCH] allow CC and CXX to have multiple words
-
-Upstream-Status: Inappropriate [OE specific]
-
-Signed-off-by: Matt Madison
-
- src/cmd/go/internal/envcmd/env.go | 4 ++--
- 1 file changed, 2 insertions(+), 2 deletions(-)
-
-diff --git a/src/cmd/go/internal/envcmd/env.go
b/src/cmd/go/internal/envcmd/env.go
-index afadbad..cedbfbf 100644
a/src/cmd/go/internal/envcmd/env.go
-+++ b/src/cmd/go/internal/envcmd/env.go
-@@ -85,11 +85,11 @@ func MkEnv() []cfg.EnvVar {
-
- cc := cfg.DefaultCC(cfg.Goos, cfg.Goarch)
- if env := strings.Fields(os.Getenv("CC")); len(env) > 0 {
-- cc = env[0]
-+ c
[OE-core] [PATCH] vim: Move PACKAGECONFIG[gtkgui] from GTK 2 to GTK 3
Signed-off-by: Adrian Bunk
---
meta/recipes-support/vim/vim.inc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-support/vim/vim.inc b/meta/recipes-support/vim/vim.inc
index 433f233448..5f9f3d79de 100644
--- a/meta/recipes-support/vim/vim.inc
+++ b/meta/recipes-support/vim/vim.inc
@@ -52,7 +52,7 @@ PACKAGECONFIG += " \
${@bb.utils.contains('DISTRO_FEATURES', 'x11', 'x11 gtkgui', '', d)} \
"
-PACKAGECONFIG[gtkgui] = "--enable-gui=gtk2,--enable-gui=no,gtk+,"
+PACKAGECONFIG[gtkgui] = "--enable-gui=gtk3,--enable-gui=no,gtk+3"
PACKAGECONFIG[acl] = "--enable-acl,--disable-acl,acl,"
PACKAGECONFIG[x11] = "--with-x,--without-x,xt,"
PACKAGECONFIG[tiny] = "--with-features=tiny,--with-features=big,,"
--
2.17.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] go: Remove INSANE_SKIP_* textrel that are now handled in go.bbclass
Signed-off-by: Adrian Bunk
---
meta/recipes-devtools/go/go-dep_0.5.0.bb | 10 --
1 file changed, 10 deletions(-)
diff --git a/meta/recipes-devtools/go/go-dep_0.5.0.bb
b/meta/recipes-devtools/go/go-dep_0.5.0.bb
index cfc2186b31..a4d631f8ea 100644
--- a/meta/recipes-devtools/go/go-dep_0.5.0.bb
+++ b/meta/recipes-devtools/go/go-dep_0.5.0.bb
@@ -19,16 +19,6 @@ RDEPENDS_${PN}-dev += "bash"
BBCLASSEXTEND = "native nativesdk"
-# for x86 ends with textrel in ${PN}
-# http://errors.yoctoproject.org/Errors/Details/185630/
-# ERROR: QA Issue: ELF binary
'/work/i586-oe-linux/go-dep/0.4.1-r0/packages-split/go-dep/usr/bin/dep' has
relocations in .text [textrel]
-INSANE_SKIP_${PN} += "textrel"
-
-# for aarch64 ends with textrel in ${PN}-ptest
-# http://errors.yoctoproject.org/Errors/Details/185632/
-# ERROR: QA Issue: ELF binary
'/work/aarch64-oe-linux/go-dep/0.4.1-r0/packages-split/go-dep-ptest/usr/lib/go-dep/ptest/github.com/golang/dep/cmd/dep/dep.test'
has relocations in .text [textrel]
-INSANE_SKIP_${PN}-ptest += "textrel"
-
# For compiling ptest on mips and mips64, the current go-dep version fails
with the go 1.11 toolchain.
# error message: vet config not found
PTEST_ENABLED_mips = "0"
--
2.17.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/2] Revert "pigz: pigz is not gzip"
On Mon, May 27, 2019 at 09:44:18PM +0800, Anuj Mittal wrote:
> This reverts commit a54c59f2a24904daffe51582b6863eebd071db0d.
>...
> # Point this at the homepage in case /fossils/ isn't updated
> +PROVIDES_class-native += "gzip-native"
> +
> UPSTREAM_CHECK_URI = "http://zlib.net/${BPN}/;
> UPSTREAM_CHECK_REGEX = "pigz-(?P.*)\.tar"
>...
This moves the comment to the wrong place.
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] Should systemd be marked as incompatible with musl?
On Fri, May 24, 2019 at 03:25:57PM -0700, Andre McCurdy wrote: > On Fri, May 24, 2019 at 1:28 PM Adrian Bunk wrote: > > On Fri, May 24, 2019 at 12:34:23PM -0700, Andre McCurdy wrote: > > > On Fri, May 24, 2019 at 11:46 AM Adrian Bunk wrote: > > > > On Fri, May 24, 2019 at 11:04:50AM -0700, Khem Raj wrote: > > >... > > > > > I think we should put in plan for 2.8 and define the scope, since we > > > > > are switching > > > > > poky defaults to systemd, > > > > > > > > Switching glibc builds to systemd as default is a reasonable decision. > > > > > > > > Switching musl builds to systemd as default would be very bad. > > > > > > > > Combining a tiny C library with a huge init system completely misses > > > > the configurations where the tiny C library actually makes sense for > > > > users. > > > > > > For new projects yes. However I know of a project (a big project, > > > shipping millions of devices) which picked systemd and glibc long ago > > > and is now running out of space. They already have various solutions > > > to free up Flash (some apps switched to being runtime downloadable, > > > etc) but if/when more savings need to be found then switching from > > > glibc to musl might be a less invasive change than switching from > > > systemd to some other init system. We obviously shouldn't make > > > decisions for OE today based on the historical decisions of one > > > project, but I just want to make the point that real world projects > > > have a lifetime and may end up with a combination of systemd + musl > > > due on past decisions that may not make sense for a new project > > > starting today. > > > > I am feeling guilty that there are two only partially related > > topics mixed in this discussion. > > > > In this part of the discussion the topic was what the default > > (and CI-tested) init system for musl should be - it seems obvious > > to me that systemd is not what users will usually want to use with musl. > > It would be great to have an alternative init system option for > smaller devices in oe-core. I don't think collectively we have the > development capacity to support it though (it's probably far more work > than properly fixing all the currently known issues with systemd on > musl...). Is there development capacity to support musl? Supporting musl is a real pain across the board, with new issues all the time. For really tiny systems you need both a tiny C library and a tiny init system, so not properly supporting the combination of both forces users to use alternative options instead of OE. Which minimizes the benefits gained by the pains of supporting musl. > > But there is also the topic whether systemd on musl is > > in a state that it should be made available at all. > > I think it's wrong to remove stuff from oe-core just because it isn't > perfect or isn't CI tested. Having something in oe-core means there's > a common version to collaborate on. If it gets kicked out then > development efforts inevitably fragment. Users are generally smart > enough to understand the concept of an experimental feature - although > we could perhaps do a better job of identifying them. Maybe one day > when users can create a custom distro config by running "make > menuconfig" there will be an option to enable experimental features > and the combination of musl and systemd would be hidden behind that. > Until then, perhaps we could add a sanity check warning if musl and > systemd are enabled together? That would be an improvement. But it conflicts with the intention to make systemd the default and CI-tested init system for musl. >... > > At that point my email that started this thread becomes relevant, > > the fact that the systemd/musl patches in OE add new security > > vulnerabilities and other bugs - and none of the systemd-on-musl > > proponents seems to consider this a problem they have to fix ASAP. > > It's certainly a problem and we should try to fix it. It's not at all > uncommon that patches to fix build issues with musl, clang, a new > version of gcc, etc have a life cycle... a first pass just to fix the > build and then updates as issues are found or better solutions get > merged upstream. It's the normal process. You could argue that we are > sometimes too quick to merge the first pass hacks and too slow to > review and update them, but unfortunately that's just a consequence of > limited developer resources (and it's always more fun to try to get > the latest version of something working than review and clea
