glibc: bump default to version 2.23
PATCH 1/1 glibc: bump default to version 2.23
--- package/glibc/Config.in | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
package/glibc/Config.in +1 -1
@@ -8,7 +8,7 @@ config BR2_PACKAGE_GLIBC choice prompt "glibc version" - default BR2_GLIBC_VERSION_2_22 + default BR2_GLIBC_VERSION_2_23 config BR2_GLIBC_VERSION_2_22 bool "2.22"
Signature · 1 line
2.7.3
PATCH 1/1 glibc: bump default to version 2.23
Quoted 3 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Gustavo" == Gustavo Zacarias <[email protected]> writes:
Signed-off-by Gustavo Zacarias <[email protected]>
Why? In the past we have defaulted to latest-1 and 2.24 isn't released yet.
Signature · 1 line
Bye, Peter Korsgaard
PATCH 1/1 glibc: bump default to version 2.23
Quoted 2 lines · Peter Korsgaard
Why? In the past we have defaulted to latest-1 and 2.24 isn't released yet.
Why not?
We're using latest uclibc-ng if it's suitable/for example. Regards.
PATCH 1/1 glibc: bump default to version 2.23
Hello,
Quoted 6 lines · Gustavo Zacarias
Quoted 2 lines · Peter Korsgaard
Why? In the past we have defaulted to latest-1 and 2.24 isn't released yet.
Why not?
Default to n-1 has been our tradition for gcc/binutils/glibc for ages.
Quoted 1 line
We're using latest uclibc-ng if it's suitable/for example.
Cause uclibc-ng doesn't evolve much beyond bug fixes at the moment, so there's not really a good reason to not use the latest version.
Thomas
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
PATCH 1/1 glibc: bump default to version 2.23
Quoted 8 lines · Thomas Petazzoni
Default to n-1 has been our tradition for gcc/binutils/glibc for ages.
Quoted 1 line
We're using latest uclibc-ng if it's suitable/for example.
Cause uclibc-ng doesn't evolve much beyond bug fixes at the moment, so there's not really a good reason to not use the latest version.
Thomas
Hi.
There are outstanding security bugs that haven't been patched in buildroot for 22/23 yet which are fixed in the upcoming 24 release, and 22 has fixes on top of 23 already.
And these patches need rebasing between 22 and 23, so i'd rather keep moving forward with them than backward.
By introducing 23 as stable sooner in the development cycle rather than later we can spot issues quicker while also avoiding unnecessary work in backporting security patches across a broader spectrum. Regards.
PATCH 1/1 glibc: bump default to version 2.23
Quoted 12 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Gustavo" == Gustavo Zacarias <[email protected]> writes:
Quoted 8 lines · Thomas Petazzoni
Default to n-1 has been our tradition for gcc/binutils/glibc for ages.
Quoted 1 line
We're using latest uclibc-ng if it's suitable/for example.
Cause uclibc-ng doesn't evolve much beyond bug fixes at the moment, so there's not really a good reason to not use the latest version.
Thomas
Quoted 10 lines
Hi.
There are outstanding security bugs that haven't been patched in buildroot for 22/23 yet which are fixed in the upcoming 24 release, and 22 has fixes on top of 23 already.
And these patches need rebasing between 22 and 23, so i'd rather keep moving forward with them than backward.
By introducing 23 as stable sooner in the development cycle rather than later we can spot issues quicker while also avoiding unnecessary work in backporting security patches across a broader spectrum. Regards.
I don't have an issue as such with us more aggressively following glibc development if we decide to do so, but this kind of information should be included in the commit message.
Signature · 2 lines
Venlig hilsen, Peter Korsgaard
PATCH 1/1 glibc: bump default to version 2.23
Quoted 23 lines · Peter Korsgaard
Quoted 12 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Gustavo" == Gustavo Zacarias <[email protected]> writes:
Quoted 8 lines · Thomas Petazzoni
Default to n-1 has been our tradition for gcc/binutils/glibc for ages.
Quoted 1 line
We're using latest uclibc-ng if it's suitable/for example.
Cause uclibc-ng doesn't evolve much beyond bug fixes at the moment, so there's not really a good reason to not use the latest version.
Thomas
Quoted 10 lines
Hi.
There are outstanding security bugs that haven't been patched in buildroot for 22/23 yet which are fixed in the upcoming 24 release, and 22 has fixes on top of 23 already.
And these patches need rebasing between 22 and 23, so i'd rather keep moving forward with them than backward.
By introducing 23 as stable sooner in the development cycle rather than later we can spot issues quicker while also avoiding unnecessary work in backporting security patches across a broader spectrum. Regards.
Quoted 3 lines
I don't have an issue as such with us more aggressively following glibc development if we decide to do so, but this kind of information should be included in the commit message.
My take on this: we should follow the stable branch of upstream. Since glibc
has no concept of stable branches (in fact, none of the libc's do), we really should follow upstream releases aggressively.
In fact, I think it's quite unreasonable that we don't have stable updates for
glibc (or any other libc). As a distro, it's our responsibility to make sure our users get stable updates, particularly for something as important as glibc. Since we (currently) don't have the bandwidth to do that, and since there simply is no viable upstream to rely on [*], we should probably consider dropping the multi-version glibc... Topic for discussion at the next BR developer meeting.
Regards,
Arnout
[*] I've checked if we could use another distro, but most are on glibc 2.19...
Debian would be an option for glibc 2.22, but for 2.23 and 2.24 there will probably no viable distro.
Signature · 6 lines
Arnout Vandecappelle arnout at mind be Senior Embedded Software Architect +32-16-286500 Essensium/Mind http://www.mind.be G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle GPG fingerprint: 7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF
PATCH 1/1 glibc: bump default to version 2.23
Quoted 12 lines · Arnout Vandecappelle
My take on this: we should follow the stable branch of upstream. Since glibc
has no concept of stable branches (in fact, none of the libc's do), we really should follow upstream releases aggressively.In fact, I think it's quite unreasonable that we don't have stable updates for
glibc (or any other libc). As a distro, it's our responsibility to make sure our users get stable updates, particularly for something as important as glibc. Since we (currently) don't have the bandwidth to do that, and since there simply is no viable upstream to rely on [*], we should probably consider dropping the multi-version glibc... Topic for discussion at the next BR developer meeting.
Quoted 6 lines
Regards,
Arnout[*] I've checked if we could use another distro, but most are on glibc 2.19...
Debian would be an option for glibc 2.22, but for 2.23 and 2.24 there will probably no viable distro.
Hi.
My $.02: Ubuntu 16.04 LTS is on 2.23.
In general we haven't seen big regressions with glibc upgrades compared to binutils/gcc.
Also, and don't take this as cockyness, i'm like the only one (except for Bernd one time) putting out security patches for glibc. Currently my spare time is pretty thin, and backporting patches for two versions of glibc and testing them is much more work than a single version. If we default to n-1 this means carrying on more patches since generally n-1 has more vulnerabilities than n when talking about glibc. If in consequence i only post patches for n and we default to n-1, well, that sucks plain and simple, since we would be shipping known-vulnerable by default, and how many users will bother to switch to latest glibc? Regards.
PATCH 1/1 glibc: bump default to version 2.23
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Gustavo" == Gustavo Zacarias <[email protected]> writes:
Hi,
Quoted 4 lines
Hi.
My $.02: Ubuntu 16.04 LTS is on 2.23.
In general we haven't seen big regressions with glibc upgrades compared to binutils/gcc.
Ok, good.
Quoted 8 lines
Also, and don't take this as cockyness, i'm like the only one (except for Bernd one time) putting out security patches for glibc. Currently my spare time is pretty thin, and backporting patches for two versions of glibc and testing them is much more work than a single version.
If we default to n-1 this means carrying on more patches since generally n-1 has more vulnerabilities than n when talking about glibc.
Yes, you do send a lot of package updates (security related or not) - Thanks for that, much appreciated.
Quoted 5 lines
If in consequence i only post patches for n and we default to n-1, well, that sucks plain and simple, since we would be shipping known-vulnerable by default, and how many users will bother to switch to latest glibc?
Regards.
Ok, I'm convinced - Committed, thanks.
Signature · 2 lines
Venlig hilsen, Peter Korsgaard
PATCH 1/1 glibc: bump default to version 2.23
In reply to Arnout VandecappelleQuoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Arnout" == Arnout Vandecappelle <[email protected]> writes:
Hi,
Quoted 7 lines
Quoted 3 lines
I don't have an issue as such with us more aggressively following glibc development if we decide to do so, but this kind of information should be included in the commit message.
My take on this: we should follow the stable branch of upstream. Since glibc
has no concept of stable branches (in fact, none of the libc's do), we really should follow upstream releases aggressively.
Yes, I generally agree (unless there's typically issues with using the absolutely latest version, like there is for gcc).
Quoted 3 lines
In fact, I think it's quite unreasonable that we don't have stable updates for glibc (or any other libc). As a distro, it's our responsibility to make sure our users get stable updates, particularly for something as important as glibc.
I wouldn't call Buildroot a distro, but yeah - Bugfix releases would be nice.
Quoted 4 lines
Since we (currently) don't have the bandwidth to do that, and since there simply is no viable upstream to rely on [*], we should probably consider dropping the multi-version glibc... Topic for discussion at the next BR developer meeting.
In general I think we should only do version selection for tools where it is needed (E.G. hardware dependent stuff like kernel/bootloaders, or "unstable" projects where going with the latest version isn't trivial for api/regression reasons).
I don't know if glibc belongs to that group or not.
Quoted 3 lines
[*] I've checked if we could use another distro, but most are on glibc 2.19...
Debian would be an option for glibc 2.22, but for 2.23 and 2.24 there will probably no viable distro.
Do you have any idea why these other distributions stick to those older versions?
Signature · 2 lines
Venlig hilsen, Peter Korsgaard
PATCH 1/1 glibc: bump default to version 2.23
Quoted 1 line · Peter Korsgaard
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Arnout" == Arnout Vandecappelle <[email protected]> writes:
[snip]
Quoted 6 lines
Quoted 3 lines
[*] I've checked if we could use another distro, but most are on glibc 2.19...
Debian would be an option for glibc 2.22, but for 2.23 and 2.24 there will probably no viable distro.Do you have any idea why these other distributions stick to those older versions?
The ones I mention are of course LTS-style distro's. And understandably, an LTS
is not going to upgrade glibc, just backport patches.
Regards,
Arnout
Signature · 6 lines
Arnout Vandecappelle arnout at mind be Senior Embedded Software Architect +32-16-286500 Essensium/Mind http://www.mind.be G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle GPG fingerprint: 7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF