No talking please. Please update the bug when a new revision is bumped (update summary to new revision, remove fixed blocking bugs, ...)
Created attachment 490502 [details] emerge --info I'm getting this access violation error upon sys-libs/glibc-2.25-r4 emerge. It was, at first, complaining about sys-libs/timezone-data-2017b, as being a blocker. >>> Completed installing glibc-2.25-r4 into /var/tmp/portage/sys-libs/glibc-2.25-r4/image/ * Final size of build directory: 588440 KiB * Final size of installed tree: 69820 KiB * --------------------------- ACCESS VIOLATION SUMMARY --------------------------- * LOG FILE: "/var/log/sandbox/sandbox-32269.log" * VERSION 1.0 FORMAT: F - Function called FORMAT: S - Access Status FORMAT: P - Path as passed to function FORMAT: A - Absolute Path (not canonical) FORMAT: R - Canonical Path FORMAT: C - Command Line F: open_wr S: deny P: /etc/ld.so.cache~ A: /etc/ld.so.cache~ R: /etc/ld.so.cache~ C: /var/tmp/portage/sys-libs/glibc-2.25-r4/work/build-x86-x86_64-pc-linux-gnu-nptl/elf/ldconfig -r /var/tmp/portage/sys-libs/glibc-2.25-r4/image /lib32 /usr/lib32 F: open_wr S: deny P: /etc/ld.so.cache~ A: /etc/ld.so.cache~ R: /etc/ld.so.cache~ C: /var/tmp/portage/sys-libs/glibc-2.25-r4/work/build-amd64-x86_64-pc-linux-gnu-nptl/elf/ldconfig -r /var/tmp/portage/sys-libs/glibc-2.25-r4/image /lib64 /usr/lib64 * --------------------------------------------------------------------------------
(In reply to Frederico Freire Boaventura from comment #1) > Created attachment 490502 [details] > emerge --info > > I'm getting this access violation error upon sys-libs/glibc-2.25-r4 emerge. > It was, at first, complaining about sys-libs/timezone-data-2017b, as being a > blocker. > > > >>> Completed installing glibc-2.25-r4 into /var/tmp/portage/sys-libs/glibc-2.25-r4/image/ > > * Final size of build directory: 588440 KiB > * Final size of installed tree: 69820 KiB > > * --------------------------- ACCESS VIOLATION SUMMARY > --------------------------- > * LOG FILE: "/var/log/sandbox/sandbox-32269.log" > * > > VERSION 1.0 > FORMAT: F - Function called > FORMAT: S - Access Status > FORMAT: P - Path as passed to function > FORMAT: A - Absolute Path (not canonical) > FORMAT: R - Canonical Path > FORMAT: C - Command Line > > F: open_wr > S: deny > P: /etc/ld.so.cache~ > A: /etc/ld.so.cache~ > R: /etc/ld.so.cache~ > C: > /var/tmp/portage/sys-libs/glibc-2.25-r4/work/build-x86-x86_64-pc-linux-gnu- > nptl/elf/ldconfig -r /var/tmp/portage/sys-libs/glibc-2.25-r4/image /lib32 > /usr/lib32 > > F: open_wr > S: deny > P: /etc/ld.so.cache~ > A: /etc/ld.so.cache~ > R: /etc/ld.so.cache~ > C: > /var/tmp/portage/sys-libs/glibc-2.25-r4/work/build-amd64-x86_64-pc-linux-gnu- > nptl/elf/ldconfig -r /var/tmp/portage/sys-libs/glibc-2.25-r4/image /lib64 > /usr/lib64 > * > ----------------------------------------------------------------------------- > --- Please file a separate bug.
Hi, Could you please ad a dependency on bug 628576 ? Thanks.
(In reply to jack_mort from comment #3) > Hi, > Could you please ad a dependency on bug 628576 ? > Thanks. I think you got the bug number wrong, I see no connection, sorry.
(In reply to Andreas K. Hüttel from comment #4) > (In reply to jack_mort from comment #3) > > Hi, > > Could you please ad a dependency on bug 628576 ? > > Thanks. > > I think you got the bug number wrong, I see no connection, sorry. Yes sorry, it's bug 628020 !
Separated bug 630414 filed.
Turning this into future stable request.
New revbump, patchlevel 10, adding only fixes for hppa and arm64
Another revbump, sorry about this. Security patch for libcidn.so (CVE-2017-14062, bug 632556).
Please test carefully and thoroughly, and stabilize if possible: sys-libs/glibc-2.25-r7 [This version does NOT have a functional test suite yet, so running the test phase is only of limited help (and will likely fail). That is fixed from 2.26-r2 on upwards, but the fixes required too many changes to be done late in the stabilization / testing cycle.] So far I have * positive feedback from: amd64, arm64, hppa * negative feedback from: mips (bash segfaults)
White glibc itself works fine on ia64/ppc/ppc64 i'm uncomfortable stabling it and breaking xorg-server build: bug #634590
(In reply to Sergei Trofimovich from comment #11) > White glibc itself works fine on ia64/ppc/ppc64 i'm uncomfortable > stabling it and breaking xorg-server build: bug #634590 Yes. Makes sense. So let's wait a bit and use the time for extra testing. In the meantime I'm going to find out what upstream glibc plans are.
Please stabilize sys-libs/glibc-2.25-r8 instead. The only difference between -r7 and -r8 is that in -r8 the header <sys/types.h> again includes <sys/sysmacros.h> (which means we don't need to wait for bug 575232).
Shouldn't the fix for CVE-2017-15670 (bug 634920) be added before stabilizing, in view of severity of the vulnerability? To avoid having a to do a security bump right after marking stable?
(In reply to Eddie Chapman from comment #14) > Shouldn't the fix for CVE-2017-15670 (bug 634920) be added before > stabilizing, in view of severity of the vulnerability? To avoid having a to > do a security bump right after marking stable? No. Deadline missed. We're already blocking two A3 and one A4 here for much too long. If I add more patches here, given the critical role of glibc, we need another testing period of a 2 weeks min. I'll be happy to prepare another revbump as soon as arches have started stabilizing here. However, we need to make the step from 2.23 to 2.25 first.
gcc-5.4.0 can't be built with glibc-2.25-r8 (same as bug #629502) On ppc it failed as: .../portage/sys-devel/gcc-5.4.0-r3/work/gcc-5.4.0/libsanitizer/asan/asan_linux.cc: In function 'bool __asan::AsanInterceptsSignal(int)': .../portage/sys-devel/gcc-5.4.0-r3/work/gcc-5.4.0/libsanitizer/asan/asan_linux.cc:222:20: error: 'SIGSEGV' was not declared in this scope return signum == SIGSEGV && common_flags()->handle_segv; ^
(In reply to Andreas K. Hüttel from comment #15) > (In reply to Eddie Chapman from comment #14) > > Shouldn't the fix for CVE-2017-15670 (bug 634920) be added before > > stabilizing, in view of severity of the vulnerability? To avoid having a to > > do a security bump right after marking stable? > > No. Deadline missed. We're already blocking two A3 and one A4 here for much > too long. If I add more patches here, given the critical role of glibc, we > need another testing period of a 2 weeks min. > > I'll be happy to prepare another revbump as soon as arches have started > stabilizing here. However, we need to make the step from 2.23 to 2.25 first. Understood, and normally I'd agree. But in this case the upstream patch for CVE-2017-15670 is just: --- a/posix/glob.c +++ b/posix/glob.c @@ -870,7 +870,7 @@ glob (const char *pattern, int flags, int (*errfunc) (const char *, int), *p = '\0'; } else - *((char *) mempcpy (newp, dirname + 1, end_name - dirname)) + *((char *) mempcpy (newp, dirname + 1, end_name - dirname - 1)) = '\0'; user_name = newp; } Now worries though, was just a suggestion, doesn't affect me either way as I have it in /etc/portage/patches. Thanks.
x86 stable
ia64 stable
dropped bug #629502 from blockers as stable gcc got one-liner fix of missing header. ppc/ppc64 stable
hppa stable (thanks to Rolf Eike Beer)
alpha stable
sparc stable
amd64 stable
Current stable version of net-nds/yp-tools (2.12-r1) can't be installed with glibc-2.25. See #603302 and #635886
@ arm: please continue with -r9 in bug 637140
