Control: tags -1 - upstream On Tue, Jan 02, 2018 at 10:57:44AM +0100, Mark Wielaard wrote: > Could you please file a bug for that. I am not aware of any such issue. > So would like to fix it, and would if I knew about it. Thanks.
No. Matthias Klose will file them, when he considers gcc-8 ready as some of the gcc-8 issues are indeed compiler bugs. If -Werror is turned on, the issues should be fixed proactively. This is not happening or only happening upstream and not on the Debian side. In your other mail, you mention the gcc-8 -Wpacked-not-aligned issue being fixed upstream. That's great, but unless it gets uploaded to Debian, I don't see the fix. Reporting this issue again is useless as you'd have to wade through the report again figuring that it already is fixed and turn it into a "new upstream release please"-bug. This would be wasting both of our time. Or rather -Werror wastes our time. > My apologies for not fixing such issues in the past fast enough. We try > to push out a release every 3 to 4 months. That's insane. If you figure that your release is broken by the next compiler release, you wait 3 months until it is fixed. In the mean time one of the other packages essential to architecture bootstrap FTBFS. Then add the delay until the release gets uploaded. By that measure you can never bootstrap a new architecture. In contrast, what we need is that essential is buildable roughly 90% of the time. That means you get roughly 3 days for fixing, not 3 months. In Debian, not upstream. This is a hard requirement or we can just stop doing QA as it would become infeasible. Alternatively, make it less prone to failure by removing -Werror. > And in general we do try to > fix any bugs and make patches available upstream as quickly as > possible. For example Fedora often does trial runs with newer compilers > and if they report an issue we try to get a fix asap. But we can only > fix them if they get reported. We do see that this doesn't work in practise (on the Debian side, upstream git is a different story). > My experience is the opposite. With make distcheck we even make sure > the build is valgrind and gcc -fsanitize-undefined clean. Which has > caught many issues early. I'm all for making make distcheck fail loudly, but I'm trying to just build elfutils. My issue is that when elfutils fails to build due to -Werror, I cannot build reverse dependencies of it. Thus failures in reverse dependencies are hidden. This is a problem and costs significant human resources, because identifying those later failures becomes significantly harder. Building distribution packages with -fsanitize-undefined is not something that we ever want to do. It's useful to do that in CI only. I'm not asking to disable -Werror in your CI. > We do currently have a buildbot for elfutils, but it isn't widely > publized yet. Currently we do not have a gcc-8 setup, but that could be > added: https://builder.wildebeest.org/buildbot/#/builders?tags=elfutils > It currently does centos, debian, fedora on x86_64, amd64, i386, ppc64, > ppc64le and s390x. If you could provide other workers that would be > appreciated. We can try using jenkins.d.n resources. There I'm cross building elfutils for alpha, arm64, armel, armhf, i386, kfreebsd-i386, m68k, mips64el, mips, mipsel, nios2, powerpc, powerpcspe, ppc64, ppc64el, s390x, sh4, sparc, sparc64, tilegx, x32 and would like to cross build it for some more (including musl-linux-any, mips64r6el, ia64, sh3, hppa). Compare to glibc maybe. glibc relates very closely to gcc, so it declares which compiler versions are "supported". By default, it enables -Werror and provides a configure flag --disable-werror for trying with other compilers. It could be as simple as passing such a switch to the Debian build. Helmut
