From: Adrian Bunk <bunk@stusta.de>
To: Khem Raj <raj.khem@gmail.com>
Cc: openembedded-devel@lists.openembedded.org
Subject: Re: [meta-oe][PATCH 1/2] collectd: Fix build with glibc 2.30
Date: Sun, 28 Jul 2019 19:15:09 +0300 [thread overview]
Message-ID: <20190728161509.GA12635@localhost> (raw)
In-Reply-To: <70043baa-9e74-53c0-c22c-0fd6fad7383b@gmail.com>
On Sun, Jul 28, 2019 at 08:26:18AM -0700, Khem Raj wrote:
>
> On 7/28/19 2:37 AM, Adrian Bunk wrote:
> > On Sat, Jul 27, 2019 at 01:06:13PM -0700, Khem Raj wrote:
> > > ...
> > > +Glibc 2.30 has added deprecation notice and collectd detects it as
> > > +warning
> > > +
> > > +Fixes
> > > +sys/sysctl.h:21:2: error: "The <sys/sysctl.h> header is deprecated and will be removed." [-Werror,-W#warnings]
> > > ...
> > This package accumulates patches in OE that could be avoided by
> > configuring with --disable-werror instead.
>
> thats true but it would mask these issues by disabling werror and we wont be
> doing submissions like https://github.com/collectd/collectd/pull/3234,
With what range of glibc versions has this submission been verified?
Putting !defined(__GLIBC__) into source files is usually wrong,
and in this case it is unclear what happens with ancient glibc versions.
Note that --disable-werror would do the right thing will all glibc
versions past, present and future since the file will no longer be
included without any patch needed once the header is actually gone.
> I would like us to fix things upstream instead of masking them.
Status quo is that people look at harmless issues like this one in the
tiny subset of packages where -Werror is used, but noone seems to care
about serious runtime problems like implicit function declarations in
other packages.
And looking at the huge number of questionable patches in OE I don't
agree that it would in general be a good idea to apply fixes for random
issues in OE before they have been applied upstream - there are plenty
examples in the open source world where downstreams "fixing" issues in
upstream software caused problems, including major security issues
(I remember Debian/Ubuntu releases shipping a patched openssl generating
predictable private keys due to a bogus Debian "fix" for a Valgrind warning).
Reality is often more complicated, but in general downstream
distributions should try to avoid touching the upstream code
and aim at shipping unpatched upstream sources whenever possible.
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
prev parent reply other threads:[~2019-07-28 16:15 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-27 20:06 [meta-oe][PATCH 1/2] collectd: Fix build with glibc 2.30 Khem Raj
2019-07-27 20:06 ` [meta-oe][PATCH 2/2] pegtl: Fix build with clang/libc++ Khem Raj
2019-07-28 9:37 ` [meta-oe][PATCH 1/2] collectd: Fix build with glibc 2.30 Adrian Bunk
2019-07-28 15:26 ` Khem Raj
2019-07-28 16:15 ` Adrian Bunk [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190728161509.GA12635@localhost \
--to=bunk@stusta.de \
--cc=openembedded-devel@lists.openembedded.org \
--cc=raj.khem@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.