Overview
Request 455481 accepted
- tunables-bigendian.patch: Fix getting tunable values on big-endian (BZ
#21109) (forwarded request 455480 from Andreas_Schwab)
- Created by Andreas_Schwab
- In state accepted
- Supersedes 454921
Request History
Andreas_Schwab created request
- tunables-bigendian.patch: Fix getting tunable values on big-endian (BZ
#21109) (forwarded request 455480 from Andreas_Schwab)
factory-auto added opensuse-review-team as a reviewer
Please review sources
factory-auto added factory-repo-checker as a reviewer
Please review build success
factory-auto accepted review
Check script succeeded
maxlin_factory set openSUSE:Factory:Staging:B as a staging project
Being evaluated by staging project "openSUSE:Factory:Staging:B"
maxlin_factory accepted review
Picked openSUSE:Factory:Staging:B
factory-repo-checker reopened review
glibc-testsuite is still building for repository openSUSE_Factory
factory-repo-checker accepted review
Builds for repo openSUSE:Factory:Staging:B/standard
coolo accepted review
jengelh accepted review
factory-repo-checker reopened review
glibc.i686 is still building for repository openSUSE_Factory
factory-repo-checker accepted review
Builds for repo openSUSE:Factory:Staging:B/standard
dimstar_suse accepted review
ready to accept
dimstar_suse approved review
ready to accept
dimstar_suse accepted request
Accept to openSUSE:Factory
with libqt4 fixed, the list of fallouts is much shorter - but there are still a good number of failures
See https://build.opensuse.org/project/staging_projects/openSUSE:Factory/B
Current failures include (CCing respective maintainers):
Ekiga fails in configure with:
Apparently that disappeared from glibc 2.25?
@Andreas_Schwab just wondering; is this change expected? (it's what makes ekiga fail)
So with glibc 2.24, there is a res_gethostbyaddr DEFAULT symbol; on glibc 2.25 there is no longer a default, just the two symbols for backwards compat.
Repetitive build failures of libzio on ppc64le observed:
@WernerFink - glibc 2.25 update is involved here
Does this only happen on ppc64le?
From what I have seen in Staging so far yes - the other archs seem to build
I had yesterday add the -D_DEFAULT_SOURCE switch as this is more up to date than the old -D_REENTRANT switch. I'd like to know if this might help on ppc64le to get /usr/include/bits/sigthread.h loaded by /usr/include/signal.h ... that is that __USE_POSIX199506 becomes a defined switch by /usr/include/features.h
strace fails test suite on x86_64 with glibc 2.25
https://build.opensuse.org/package/live_build_log/openSUSE:Factory:Staging:B/strace/standard/x86_64
@AndreasSchwab
Worksforme. https://build.opensuse.org/package/show/home:Andreas_Schwab:Factory/strace
Thanks for your verification run - seems strace has seen an update on a parallel staging process - which did not make it through :B
r59 | dimstar_suse | 2017-02-20 13:27:15 | f301a16e90ce036a83aada8800755127 | 4.16 | rq457371
:B did still test strace 4.15.. will fix this up
gcc5 fails constantly to build on ppc64le using glibc 2.25
CC @rguenther and matz2
https://build.opensuse.org/package/live_build_log/openSUSE:Factory:Staging:B/gcc5/standard/ppc64le
../../../../libsanitizer/asan/asan_linux.cc: In f unction 'bool __asan::AsanInterceptsSignal(int)': [ 3365s] ../../../../libsanitizer/asan/asan_linux.cc:222:20: error: 'SIGSEGV' wa s not declared in this scope [ 3365s] return signum == SIGSEGV && common_flags()->handle_segv; [ 3365s] ^
missing include. But gcc5 can be dropped once libffi is in... (openSUSE:Factory:Staging:adi:24)
You really want me to fix gcc5?
gcc5 can move out of ring0 to DVD, only libffi-gcc5 needs to be retained for now (in -MinimalX)
wouldn't change the fact that I need a fix for gcc5 - ring0, ring1 and ring2 are tested and guaranteed to build; but moving it out of Ring0 to a higher ring is certainly something we will have a look at then. Thanks for the pointer
Fix is in devel:gcc/gcc5
Hmm. you mean gcc5 could be completley dropped with libffi in; that sounds actually interesting and would indeed mean we should not invest into fixing this.
I'll try to add a delete request for gcc5 and temporarily add libffi from adi:24 over here to Staging:C - then we also get the confirmation that this is indeed all as good as we expect
Yes. At least gcc5 can be moved from Ring0 to DVD (so out of stagings). Without libffi in we only need libffi-gcc5 in Ring1.
That part is unfortunatley not possible, as libffi-gcc5 is not the 'leading' package, it requires at least that gcc5 to be in the rings too (ring0, 1 or 2) and in this case the build would need to be fixed.
But the current setup I have is with libffi 3.2.1 added to ring1 with gcc5 and libff-gcc5 removed from the rings. This seems to work and is a solution I like (especially as I can get a compiler out of the rings)
Ah, that's unfortunate. Let's hope we can get the pending legal review for libffi quickly then.
gdb fails to build with glibc 2.25 (x86_64 and ppc64le)
https://build.opensuse.org/package/live_build_log/openSUSE:Factory:Staging:B/gdb/standard/x86_64
CC @matz2
SR#460722
Xen fails to build with glibc 2.25
https://build.opensuse.org/package/live_build_log/openSUSE:Factory:Staging:B/xen/standard/x86_64
CC @olh @charlesa