| Message ID | 1466590187-21862-1-git-send-email-gustavo@zacarias.com.ar |
|---|---|
| State | Accepted |
| Commit | 0b87314aa59520c84dfff9cf047fa2cb6c9afa9a |
| Headers | show |
>>>>> "Gustavo" == Gustavo Zacarias <gustavo@zacarias.com.ar> writes: > Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar> Why? In the past we have defaulted to latest-1 and 2.24 isn't released yet.
On 2016-06-22 11:53, Peter Korsgaard wrote: > 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.
Hello, On Wed, 22 Jun 2016 12:02:15 -0300, Gustavo Zacarias wrote: > On 2016-06-22 11:53, Peter Korsgaard wrote: > > > 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. > 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
On 2016-06-22 12:13, Thomas Petazzoni wrote: > Default to n-1 has been our tradition for gcc/binutils/glibc for ages. > >> 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.
>>>>> "Gustavo" == Gustavo Zacarias <gustavo@zacarias.com.ar> writes: > On 2016-06-22 12:13, Thomas Petazzoni wrote: >> Default to n-1 has been our tradition for gcc/binutils/glibc for ages. >> >>> 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. 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.
On 22-06-16 17:27, Peter Korsgaard wrote: >>>>>> "Gustavo" == Gustavo Zacarias <gustavo@zacarias.com.ar> writes: > > > On 2016-06-22 12:13, Thomas Petazzoni wrote: > >> Default to n-1 has been our tradition for gcc/binutils/glibc for ages. > >> > >>> 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. > > 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.
On 22/06/16 17:38, Arnout Vandecappelle wrote: > 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. 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.
>>>>> "Arnout" == Arnout Vandecappelle <arnout@mind.be> writes: Hi, >> 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). > 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. > 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. > [*] 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?
>>>>> "Gustavo" == Gustavo Zacarias <gustavo@zacarias.com.ar> writes: Hi, > 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. > 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. > 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.
On 27-06-16 21:27, Peter Korsgaard wrote: >>>>>> "Arnout" == Arnout Vandecappelle <arnout@mind.be> writes: [snip] > > [*] 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
diff --git a/package/glibc/Config.in b/package/glibc/Config.in index 02cae35..f86822d 100644 --- a/package/glibc/Config.in +++ b/package/glibc/Config.in @@ -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"
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar> --- package/glibc/Config.in | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)