Before merging the gcc-7
branch to master (#27794), let's fix as much as possible beforehand. Here are the current direct failures (i.e. not including failing reverse dependencies) when comparing a gcc-7 evaluation (https://hydra.nixos.org/eval/1430074) to a trunk one (https://hydra.nixos.org/eval/142964):
Semi off-topic: what does gcc-7 bring? As in features, benefits for us.
Removed gcj support ;-) Seriously, I don't know of anything particularly interesting to nixpkgs, but there are lots of "smaller" improvements: https://gcc.gnu.org/gcc-7/changes.html
I think the new cross stuff means we can get rid of avrbintools.
/cc @Ericson2314
Well to be fair, the cross stuff for is currently not working until more is merged, but I suppose there's little point fixing that and additionally the one-off AVR stuff once GCC 7 is the default.
apt-cacher-ng
has been resolved in #31924. Someone please tick the checkbox :-)
tvheadend
was fixed with 9e44d34be28a270fd68161e96e335f4d6e2ba6fc
PR #32038 fixes nginx, nginxShibboleth &nginxStable
gcc-7.3 got released upstream, fixing many bugs, but probably (almost) none of those build failures...
@dezgeg Could you re-run your tests against a branch based off current master?
I would be interested in what is still open and would potentially try to fix the remaining packages before 18.03.
I merged master and pushed to gcc-7 with several conflicts. Let's hope I didn't mess up.
Will diff https://hydra.nixos.org/eval/1429098 vs https://hydra.nixos.org/eval/1429091 once it has built.
@dezgeg: FYI I can't see the 7.3 gcc version bump in the gcc-7 branch. Maybe you want to pull https://github.com/NixOS/nixpkgs/commit/2f83f52ab86fd5d7ac2c63da9969107bb5ece883 ?
I merged the current master with gcc 7.3.0 into the gcc-7 branch and triggered another evaluation.
@dezgeg Do you know why the nixos:gcc-7
job on Hydra is configured to evaluate pkgs/top-level/release.nix
instead of nixos/release.nix
. I'd like to change that to see if how the nixos tests are doing.
Updated the list.
I didn't create the jobset, someone else did. But I personally wouldn't mind if you change it to the nixos one.
It was probably me. IIRC I wanted to have at least one evaluation with other platforms (e.g. Darwin), but recently I removed Darwin from there (temporarily?) due to being overloaded on Hydra.
We might be close to a mergeable state now: https://hydra.nixos.org/eval/1434126?filter=x86_64-linux&compare=1433915&full= (still waiting for a few thousand builds from aarch64 and darwin)
A large fraction is caused by a lisp wrapper failing, and I've seen the error appear and disappear on master already.
Ah right, I used stdenv.shell
until not using arrays became too annoying, and forgot to switch to bash. Pushed a fix to master for now.
~Oh, I see, it seems the build slave called "hydra" still has bad /bin/sh
, as the build happened just two days ago. @edolstra: is it easy to fix?~
BTW, /bin/sh
impurity: https://github.com/NixOS/nix/issues/1205#issuecomment-366470525
Hmm, this case probably wasn't related to the /bin/sh
impurities.
Actually, the second script that sources did have #!/bin/sh
shebang. And probably stdenv.shell
was fine and I just overreacted.
Some more fixes have landed, and last parts of the tested job are finishing now. Hydra regression is notable IMHO, but on the whole: last call before merging to master!
Hydra shows under two hundred build-time regressions for x86_64-linux, roughly the same set for aarch64-linux and almost none for x86_64-darwin. That seems reasonable to me; the rest should be possible to handle directly on master, for packages with enough interest.
Tested jobs succeeded :tada: except for ipv6 test which is broken on master.
Bisecting lead me to ca8aa5dc877 (Use GCC 7 by default) and this issue.
gcc7 broke fcgiwrap by defaulting to -Werror=implicit-fallthrough
, which trips on a false-positive during error handling.
It builds again after NIX_CFLAGS_COMPILE = "-Werror=implicit-fallthrough=0";
. Should I PR this, or is there a better fix?
Yeah, PR of that is the right thing. I think the typical spelling is of the flag is -Wno-error=implicit-fallthrough
though.
For extra points, you can report it upstream.
Ah, -W...=0
disabled the warning entirely, -Wno-error=...
just makes it not fail the build while still displaying it. I'll send a PR later. Thank you! :)
Upstream seems dead-ish (2015).
Let's close this ticket. Almost all is solved now.
Most helpful comment
Yeah, PR of that is the right thing. I think the typical spelling is of the flag is
-Wno-error=implicit-fallthrough
though.For extra points, you can report it upstream.