This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: glibc 2.24 -- Release blockers
- From: Adhemerval Zanella <adhemerval dot zanella at linaro dot org>
- To: GNU C Library <libc-alpha at sourceware dot org>
- Cc: Florian Weimer <fweimer at redhat dot com>
- Date: Fri, 8 Jul 2016 17:48:28 -0300
- Subject: Re: glibc 2.24 -- Release blockers
- Authentication-results: sourceware.org; auth=none
- References: <577EB298.4050903@linaro.org>
I forgot to add in the previous email my initial idea for the dates
regarding 2.24 release.
I would like to start hard freeze by July 12th (Tue), it will give
us some time to settle (either commit or drop) the remaining release
blockers.
Based on previous releases, I would like to follow with 4 weeks for
testing and set the release date to Aug 2th. Depending of testing
discussion I think it might be feasible to short it to just 3 weeks.
On 07/07/2016 16:50, Adhemerval Zanella wrote:
> Hi all,
>
> Now that we proposed and defined current release blockers, I would like
> to move forward and either commit them or move to 2.25. The idea is, as
> in previous releases, to have a somewhat large time window to allow
> multiple arch and distro maintainers to test the upcoming release.
>
> I plan to announce hard freeze by the start of next week, so we have a
> quite narrow time window to sort out all the current release blockers.
> The idea is to have all of them either committed or postponed to 2.25.
>
> The current release blockers are listed in release wiki [1] below and I am
> listing them with some comments:
>
> * [BZ #20139] Don't allow configure with not supporting AVX512 assembler
> w/o --disable-avx512 [2]
>
> This seems to fix possible broken build depending of binutils and target
> hardware. I tend to see this a arch specific issue where the arch
> maintainer should have the final answer.
>
> * [BZ #20309] X86-64: Properly align stack in _dl_tlsdesc_dynamic [3]
>
> This seems to be an important ABI fix and look ok to me. I think also
> the arch maintainer have the final word.
>
> * Revised^2: deprecate major/minor/makedev in sys/types.h [4]
>
> This is a 4 patch set. I see from previous iterations that some
> developers would like to include it in 2.24.
>
> First patch is already commit.
>
> Second patch seems ok with just the version inclusion and abifiles update
> seems to be wrong. There is not compat symbol being added and both old
> an new version seems to be produce the same output. I will reply to
> original thread.
>
> Patch 3 also seems most straightforward and I think is ok for upstream.
>
> Patch 4 also seems ok.
>
> I am plan to check all the patches (with second one being adjusted to
> not add any version in Version or abilist).
>
> * Refactor Linux raise implementation (BZ#15368) [5]
>
> I think I addressed all the issue from previous revisions and I would like
> to commit it before hard release.
>
> * Remove __ASSUME_OFF_DIFF_OFF64 definition [6]
>
> This is another cleanup that I would like to push on 2.24 mainly to get rid
> of superfluous __ASSUME_OFF_DIFF_OFF64 define. I see it is mostly safe, since
> the __OFF_T_MATCHES_OFF64_T have the same meaning.
>
> I would also like to push it before hard freeze.
>
> * Add pretty printers for the NPTL lock types [7]
>
> I do not have a strong opinion about this one, but I do see some developers
> would like to push this forward on 2.24. Since it is not a non-intrusive
> and tests are already returning UNSUPPORTED, so I think it is safe for testing.
> I will let the reviewers of the thread device or not if the patch is ok for
> inclusion.
>
> * [BZ #13165] New condition variable [9]
>
> I would like to move forward on this one. Based on Torvald feedback is has been
> tested on fedora rawride I think it is ok for inclusion.
>
> I will also check on the architectures I have access.
>
> * [BZ #20024] Fixed vector sincos/sincosf ABI [10]
>
> This is another ABI fix that I think should be up to arch maintainer the final
> word.
>
> * malloc: Remove malloc_get_state, malloc_set_state [11]
>
> I plan to test and review this patch as well, but I think is should be safe
> due its limited usage by programs.
>
>
> So I would like for inputs of current blocker and if should move any of them to
> 2.25 (I see we have a narrow window for hard freeze).
>
> Florian, could you also handle the security bugs (NEWS addition, CVE identifiers,
> etc.) since you already have some experience from previous releases?
>
>
> [1] https://sourceware.org/glibc/wiki/Release/2.24
> [2] https://sourceware.org/ml/libc-alpha/2016-06/msg01280.html
> [3] https://sourceware.org/ml/libc-alpha/2016-06/msg01209.html
> [4] https://sourceware.org/ml/libc-alpha/2016-05/msg00274.html
> [5] http://patchwork.sourceware.org/patch/13220/
> [6] http://patchwork.sourceware.org/patch/13448/
> [7] https://sourceware.org/ml/libc-alpha/2016-06/msg01126.html
> [8] https://sourceware.org/ml/libc-alpha/2016-05/msg00605.html
> [9] https://sourceware.org/ml/libc-alpha/2016-05/msg00605.html
> [10] https://sourceware.org/ml/libc-alpha/2016-07/msg00008.html
> [11] https://sourceware.org/ml/libc-alpha/2016-06/msg00905.html
>