Source RPM size
by Florian Weimer
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
5 years, 10 months
Switching Fedora ppc64 glibc to IFUNC-only optimizations
by Florian Weimer
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
6 years, 3 months
Make glibc/valgrind check more robust
by Mark Wielaard
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
6 years, 7 months
F27 and rawhide currently broken
by Florian Weimer
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
6 years, 7 months
Confirm changes in your account Details
by Liliana Costache
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
6 years, 7 months
Re: pjones pushed to glibc32 (f27). "Make glibc32.x86_64 provide
glibc-static(x86-32) and glibc(x86-32) (..more)"
by Florian Weimer
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
6 years, 7 months
Disabling multi-arch for i386
by Florian Weimer
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
6 years, 7 months
f27 build failures due to langpack packages
by Florian Weimer
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
6 years, 7 months
f27 branch currently on upstream master
by Florian Weimer
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
6 years, 7 months