glibc August 2017

glibc@lists.fedoraproject.org

8 participants
12 discussions

Source RPM size
by Florian Weimer 15 May '18

15 May '18

Would it concern you if the source RPM size grew to about 110 MiB? This data would not have to be uploaded with a “fedpkg new-sources” command for every upstream import, only once per Fedora release cycle. Thanks, Florian

2 14

Switching Fedora ppc64 glibc to IFUNC-only optimizations
by Florian Weimer 13 Dec '17

13 Dec '17

I would like to tweak glibc so that it only builds one POWER 620/970 libc for ppc64, and not multiple libcs with POWER6/POWER7/POWER8 optimizations. This does not affect ppc64le in any way. The reason for this change is that the ppc64 builders are awfully slow as of late, and the multiple builds (four times currently) currently make ppc64 the slowest architecture to build by quite a margin. Any comments? Thanks, Florian

8 27

Make glibc/valgrind check more robust
by Mark Wielaard 31 Aug '17

31 Aug '17

Hi, Some recent glibc hardening updates broke valgrind on arm32. The fix was easy, but it could have been caught earlier. I have CCed Stef Walter since he is the contact for https://fedoraproject.org/wiki/CI and they might have ideas for a better way to do this (see below). But for now I would suggest the following patch for the glibc.spec file: diff --git a/glibc.spec b/glibc.spec index 5e8486a..ecb41c0 100644 --- a/glibc.spec +++ b/glibc.spec @@ -2042,7 +2042,8 @@ pushd build-%{target} LD_SHOW_AUXV=1 elf/ld.so --library-path .:elf:nptl:dlfcn /bin/true %if %{with valgrind} -elf/ld.so --library-path .:elf:nptl:dlfcn /usr/bin/valgrind \ +elf/ld.so --library-path .:elf:nptl:dlfcn \ + /usr/bin/valgrind --error-exitcode=1 \ elf/ld.so --library-path .:elf:nptl:dlfcn /usr/bin/true %endif popd That makes sure that not only is valgrind run on /bin/true, but also that no errors are produced by valgrind. There really should be none for /bin/true, if there are any that would mean such error/warnings would show up for each and every program run under valgrind, and that is really just noise. I put something similar in the valgrind.spec file and it passes on all rawhide arches. Stef, the above spec file snippet (and a similar variant in the valgrind.spec) is done during %check to make sure that the newly build glibc and/or newly build valgrind works as expected. Updates to glibc sometimes break valgrind because valgrind has some very specific startup requirements that rely on some specific functions in the dynamic loader being called in specific order. This is almost always a bug in valgrind, but we would like to catch these early and often. This is especially helpful on secondary architectures where catching these issues might otherwise take some time because there are less users. valgrind is similarly "fragile" when it comes to updates to the kernel (auxv changes, glibc may start calling new syscalls that valgrind doesn't recognize yet, etc.) and gcc updates (there might be a new optimization that generate code patterns valgrind/memcheck doesn't recognize). So I was wondering if the CI effort could help us here. Putting the test in the spec file %check of the packages is really helpful. But maybe it would be more helpful if such a check could be run on a new compose on all architectures whenever one of these packages is updated by the new Fedora CI initiative. Currently only glibc and valgrind have this cross check, updates to gcc or the kernel are only caught later when glibc or valgrind are rebuild. Cheers, Mark

5 6

F27 and rawhide currently broken
by Florian Weimer 29 Aug '17

29 Aug '17

I broke the build with my attempt at forward-porting our downstream syscall list changes. Carlos hasn't given up on upstreaming them yet, and Joseph was supportive, so I posted a new patch upstream. If we don't get quick upstream acceptance, I'll put the necessary fixes into F27 and rawhide. The existing build failures are likely caused by the missing before-compile directive in the current patch. Thanks, Florian

2 2

Confirm changes in your account Details
by Liliana Costache 19 Aug '17

19 Aug '17

Hello, Please Verify account Details on Invoice attached, we received a new account Details of your corresponding London Office Your prompt reply is needed. Liliana Costache Purchasing Manager 1606 Rock Creek Dairy Road Whitsett North Carolina United State UAN: +1 951 111-22- 00-22 Ext 210 Fax: +1 951 2858164 Mobile: + 1 916 371 8529111 Email: liliana.costcahe(a)gmail.com URL: http://www.cullen.com

1 0

Re: pjones pushed to glibc32 (f27). "Make glibc32.x86_64 provide glibc-static(x86-32) and glibc(x86-32) (..more)"
by Florian Weimer 17 Aug '17

17 Aug '17

On 08/16/2017 11:02 PM, notifications(a)fedoraproject.org wrote: > +# Without this there's no way to make a non-file build dependency on > +# /usr/lib/libc.a from a 64-bit package that works both in mock and in > +# koji. > +%ifarch x86_64 > +Provides: glibc-static(x86-32) = %{version}-%{release} > +Provides: glibc(x86-32) = %{version}-%{release} > +%endif If you need to do this, you need a Koji extension, or we have to keep glibc32 more recent. You can't compile with newer headers and link against an older libc.a. This happens with libc.so as well, but there are more significant issues with static libraries. What's your exact use-case? If it is significant enough, we may need to fix Koji for good, but the timing for that would be a bit odd. Thanks, Florian

2 3

Disabling multi-arch for i386
by Florian Weimer 16 Aug '17

16 Aug '17

I will disable multi-arch on i386 for F26 and F27 because legacy applications keep causing crashes with an unaligned stack. (Unlike downstream, Fedora does not assume the presence of SSE2 support, so only IFUNCs hit this issue there.) Thanks, Florian

2 1

f27 build failures due to langpack packages
by Florian Weimer 16 Aug '17

16 Aug '17

I get this: Checking for unpackaged file(s): /usr/lib/rpm/check-files /builddir/build/BUILDROOT/glibc-2.26-1.fc27.1.i386 error: Installed (but unpackaged) file(s) found: /usr/lib/locale/aa_DJ.utf8/LC_ADDRESS … This also happens with a version which built previously. It appears to be caused by RPM changes which result in an empty list of langpack packages. I'm trying to fix this. Florian

2 3

f27 branch currently on upstream master
by Florian Weimer 16 Aug '17

16 Aug '17

This commit on the f27 branch: commit 8742b0f94950f8e5d3a735be8b5cdd5140a53763 (origin/master, origin/f27, origin/HEAD) Author: Carlos O'Donell <carlos(a)systemhalted.org> Date: Thu Aug 3 09:47:24 2017 -0400 glibc-2.26-1 Auto-sync with upstream release/2.26/master Upstream commit: 2aad4b04ad7b17a2e6b0e66d2cb4bc559376617b - Update to released 2.26 branch. - getaddrinfo: Release resolver context on error in gethosts (swbz#21885) does not actually sync to the 2.26 branch because commit 2aad4b04ad7b17a2e6b0e66d2cb4bc559376617b is on upstream master, not the 2.26 branch. I looked at the commit history and it was still sufficiently early so that it shouldn't be a problem that we hop branches now. Thanks, Florian

1 0

BTrain your brain for success!
by neurofux＠qymail.com 10 Aug '17

10 Aug '17

Peak performance neurofeedback training. http://www.neurofux.com

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

glibc August 2017