This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Status of backport at bugzilla
- From: Allan McRae <allan at archlinux dot org>
- To: Adhemerval Zanella <azanella at linux dot vnet dot ibm dot com>, libc-alpha at sourceware dot org, OndÅej BÃlka <neleai at seznam dot cz>
- Date: Sun, 22 Sep 2013 21:53:27 +1000
- Subject: Re: Status of backport at bugzilla
- Authentication-results: sourceware.org; auth=none
- References: <20130921212153 dot GA10434 at domone dot kolej dot mff dot cuni dot cz> <523ED58A dot 6080506 at linux dot vnet dot ibm dot com>
On 22/09/13 21:33, Adhemerval Zanella wrote:
> On 21-09-2013 18:21, OndÅej BÃlka wrote:
>> Hi, there are few 2.15 backports at bugzilla, they lose relevance with
>> time so we should check their status.
>>
>> I made list by searching bugzilla for 'backport'. What we will do with these?
>>
>> 14343 [2.15] Function logb() in math.h produces incorrect results for small inputs 2013-03-20
>> 14033 [2.15] <bits/math-finite.h> references non-existing *l_finite symbols on double-only ports 2013-03-20
>> 14284 [2.15 backport] Fix invalid memory access in do_lookup_x. 2013-02-19
>> 14599 [Linux/SPARC] libm_pic.a linking failure 2012-12-03
>> 14287 Backport RPC header patch from master 2012-12-03
>> 13690 pthread_mutex_unlock potentially cause invalid access 2012-12-03
>> 13765 [2.15 backport] Make fmtmsg() function thread-safe 2012-12-03
>> 14668 [2.15 backport] Don't parse %s format argument as multibyte string 2012-12-03
>> 13773 [2.15 backport] Call __fxstatat64 from faccessat() to avoid PLT in -Os builds 2012-06-28
>> 13756 [2.15 backport] Sort objects before relocations 2012-06-28
>> 14041 getcontext@GLIBC_2.3.3 missing from libc 2012-06-27
>> 13902 [2.15 backport] Fix confstr use of local buffer outside its extent. 2012-06-27
>> 13755 [2.15 backport] Do not cache negative results in nscd if these are transient 2012-06-27
>>
> I checked in glibc wiki and page and looks like we don't have any policy
> regarding backport/mantainer policy. So I guess it will be a release maintainer
> decision, in this case Carlos O'Donnell.
>
> Should we create a policy regarding how we maintain, hw many releases (maybe
> based on time)?
>
It looks like there was no objections to the 2.16 and older branches
being closed. See:
https://sourceware.org/ml/libc-alpha/2013-09/msg00267.html
Allan