Nixpkgs: Zero Hydra Failures for 17.03

[globin]

We currently have ~100 failing jobs on hydra:
https://hydra.nixos.org/jobset/nixos/release-17.03

I'm hoping for a big effort from all contributors and maintainers to get this down to zero for the release at the end of march.

I'll be updating this issue with further information continuously.

Off we go on a sprint to making 17.03 the best release possible!
Hydra jobset: http://hydra.nixos.org/jobset/nixos/release-17.03
Evaluation: http://hydra.nixos.org/eval/1344293

• [ ] [nixos.tests.gnome3-gdm.i686-linux](http://hydra.nixos.org/build/50778211)
  
  
  
  • maintainers: @lethalman
  
  
• [ ] [nixos.tests.gnome3-gdm.x86_64-linux](http://hydra.nixos.org/build/50778272)
  
  
  
  • maintainers: @lethalman
  
  
• [ ] [nixos.tests.quagga.i686-linux](http://hydra.nixos.org/build/50762888)
  
  
  
  • maintainers: @tavyc
  
  
• [ ] [nixos.tests.quagga.x86_64-linux](http://hydra.nixos.org/build/50762970)
  
  
  
  • maintainers: @tavyc
  
  
• [ ] [nixos.tests.virtualbox.net-hostonlyif](http://hydra.nixos.org/build/50780628)
  
  
  
  • maintainers: @aszlig, @wkennington
  
  
• [ ] [nixos.tests.virtualbox.systemd-detect-virt](http://hydra.nixos.org/build/50780280)
  
  
  
  • maintainers: @aszlig, @wkennington
  
  
• [ ] [nixpkgs.aliceml.x86_64-linux](http://hydra.nixos.org/build/50710124)
  
  
  
  • maintainers: @doublec
  
  
• [ ] [nixpkgs.boomerang.x86_64-linux](http://hydra.nixos.org/build/50714619)
• [ ] [nixpkgs.cabal2nix.i686-linux](http://hydra.nixos.org/build/50711693)
  
  
  
  • maintainers: @peti
  
  
• [ ] [nixpkgs.clisp-tip.i686-linux](http://hydra.nixos.org/build/50717959)
  
  
  
  • maintainers: @7c6f434c, @tohl
  
  
• [ ] [nixpkgs.clisp-tip.x86_64-linux](http://hydra.nixos.org/build/50722188)
  
  
  
  • maintainers: @7c6f434c, @tohl
  
  
• [ ] [nixpkgs.crystal.i686-linux](http://hydra.nixos.org/build/50709987)
  
  
  
  • maintainers: @mingchuan
  
  
• [ ] [nixpkgs.freestyle.x86_64-linux](http://hydra.nixos.org/build/50702809)
• [ ] [nixpkgs.fstar.i686-linux](http://hydra.nixos.org/build/50708423)
• [ ] [nixpkgs.fstar.x86_64-linux](http://hydra.nixos.org/build/50708758)
• [ ] [nixpkgs.gcsfuse.i686-linux](http://hydra.nixos.org/build/50725054)
  
  
  
  • maintainers: @ehmry, @lethalman
  
  
• [ ] [nixpkgs.ghdl_llvm.x86_64-linux](http://hydra.nixos.org/build/50715681)
  
  
  
  • maintainers: @viric
  
  
• [ ] [nixpkgs.glance.i686-linux](http://hydra.nixos.org/build/50716879)
  
  
  
  • maintainers: @chaoflow, @domenkozar
  
  
• [ ] [nixpkgs.guileLint.x86_64-linux](http://hydra.nixos.org/build/50706663)
• [ ] [nixpkgs.haskell.compiler.integer-simple.ghc802.x86_64-linux](http://hydra.nixos.org/build/50718674)
  
  
  
  • maintainers: @marcweber, @andres, @peti
  
  
• [ ] [nixpkgs.hawkthorne.x86_64-linux](http://hydra.nixos.org/build/50724084)
  
  
  
  • maintainers: @campadrenalin
  
  
• [ ] [nixpkgs.hydra.i686-linux](http://hydra.nixos.org/build/50761956)
  
  
  
  • maintainers: @domenkozar
  
  
• [ ] [nixpkgs.ispc.x86_64-linux](http://hydra.nixos.org/build/50707048)
  
  
  
  • maintainers: @aristid
  
  
• [ ] [nixpkgs.jclasslib.x86_64-linux](http://hydra.nixos.org/build/50723928)
• [ ] [nixpkgs.julia-git.x86_64-linux](http://hydra.nixos.org/build/50716068)
  
  
  
  • maintainers: @7c6f434c
  
  
• [ ] [nixpkgs.keystone.i686-linux](http://hydra.nixos.org/build/50706163)
  
  
  
  • maintainers: @chaoflow, @domenkozar
  
  
• [ ] [nixpkgs.libsingular.i686-linux](http://hydra.nixos.org/build/50451336)
  
  
  
  • maintainers: @7c6f434c
  
  
• [ ] [nixpkgs.linuxPackages_chromiumos_3_14.ixgbevf.x86_64-linux](http://hydra.nixos.org/build/50723945)
• [ ] [nixpkgs.linuxPackages_chromiumos_3_14.virtualboxGuestAdditions.x86_64-linux](http://hydra.nixos.org/build/50704308)
  
  
  
  • maintainers: @svanderburg
  
  
• [ ] [nixpkgs.linuxPackages_chromiumos_3_18.e1000e.x86_64-linux](http://hydra.nixos.org/build/50704072)
• [ ] [nixpkgs.linuxPackages_chromiumos_3_18.ixgbevf.x86_64-linux](http://hydra.nixos.org/build/50719145)
• [ ] [nixpkgs.linuxPackages_chromiumos_latest.e1000e.x86_64-linux](http://hydra.nixos.org/build/50721295)
• [ ] [nixpkgs.linuxPackages_chromiumos_latest.ixgbevf.x86_64-linux](http://hydra.nixos.org/build/50705502)
• [ ] [nixpkgs.manticore.x86_64-linux](http://hydra.nixos.org/build/50444211)
• [ ] [nixpkgs.maxima-ecl.i686-linux](http://hydra.nixos.org/build/50714167)
  
  
  
  • maintainers: @peti
  
  
• [ ] [nixpkgs.maxima-ecl.x86_64-linux](http://hydra.nixos.org/build/50702810)
  
  
  
  • maintainers: @peti
  
  
• [ ] [nixpkgs.ncbi_tools.x86_64-linux](http://hydra.nixos.org/build/50446660)
• [ ] [nixpkgs.panomatic.x86_64-linux](http://hydra.nixos.org/build/50704587)
• [ ] [nixpkgs.qt-gstreamer.x86_64-linux](http://hydra.nixos.org/build/50714696)
• [ ] [nixpkgs.qt_gstreamer.x86_64-linux](http://hydra.nixos.org/build/50704321)
• [ ] [nixpkgs.r3rs.x86_64-linux](http://hydra.nixos.org/build/50434393)
• [ ] [nixpkgs.r4rs.x86_64-linux](http://hydra.nixos.org/build/50446512)
• [ ] [nixpkgs.r5rs.x86_64-linux](http://hydra.nixos.org/build/50438506)
• [ ] [nixpkgs.rustBeta.rustc.i686-linux](http://hydra.nixos.org/build/50706193)
  
  
  
  • maintainers: @madjar, @cstrahan, @wizeman, @globin, @havvy, @wkennington, @retrry
  
  
• [ ] [nixpkgs.sage.x86_64-linux](http://hydra.nixos.org/build/50722798)
• [ ] [nixpkgs.sitecopy.x86_64-linux](http://hydra.nixos.org/build/50705687)
• [ ] [nixpkgs.telepathy_rakia.x86_64-linux](http://hydra.nixos.org/build/50709871)
• [ ] [nixpkgs.ultrastardx.x86_64-linux](http://hydra.nixos.org/build/50706146)
• [ ] [nixpkgs.vimiv.i686-linux](http://hydra.nixos.org/build/50706364)
  
  
  
  • maintainers: @chaoflow, @domenkozar
  
  
• [ ] [nixpkgs.wxmupen64plus.x86_64-linux](http://hydra.nixos.org/build/50720542)

[abbradar]

I can't reproduce failure of nixos.tests.keymap.dvorak.x86_64-linux locally.

EDIT: seems a transient error, marked as done.

[vcunat]

I picked some stuff from staging that I trust. I know little about the python stuff in there, so I omitted those changes (/cc @FRidh) which made this a relatively large rebuild when compared to staging.

I created staging-17.03 branch and corresponding jobset so that we're not slowed down when fixing stuff directly on 17.03.

[FRidh]

@vcunat the only issue I saw was with Python 3.4 (which is hardly used in Nixpkgs) and expat. That's an easy to solve issue. The rest is fine so I think it should all go in.

[the-kenny]

Shall we mark packages as done when it works on hydra or when the build works locally?

[globin]

@the-kenny when it is commited, I regurlarly update the list in the description based on the current hydra failures.

[teh]

pandas on i686 is a known upstream bug: https://github.com/pandas-dev/pandas/issues/14866 - I could remove the test for that platform if that's acceptable to @FRidh ?

[DerTim1]

Asterisk works locally, maybe with #23124 it would also build on hydra...

[FRidh]

@teh yes go ahead. Upstream doesn't test against i686. Another option is to mark it as broken for i686.

[vcunat]

So, all commits now merged from staging to master were cherry-picked to 17.03 directly, and that causes almost no rebuilds (all cached from staging). I just reset staging-17.03 to release-17.03, so we can still use it if need be.

[teh]

@peti - I sampled the Haskell failures and I'd say 80% of them are either upstream issues with e.g. newer GHCs or require manual overrides for dependencies. How about we identify the packages that people consider to be really important (e.g. I have a PR to fix purescript) and mark the rest as broken?

[peti]

@teh, yes, that is what I usually do. Don't worry about the Haskell packages. There will be 0 errors in a few days.

[dezgeg]

nixos.tests.installer.* had spurious failures - couldn't reproduce locally.

[alistairbill]

Can't reproduce failure of msgpack-tools on my machine or a clean VM. Ran the 'reproduce locally' script and everything compiles fine.

[vcunat]

@alibabzo: I see -- Downloading: libb64-1.2.1.zip in the log. Normal builds aren't allowed networking iff sandboxing is used.

[magnetophon]

Could someone have a look at #23394 and #23390 ?
Travis has (the same?) issues on both, but I'm pretty sure at least #23394 should build.

[FRidh]

We have 280 failing Python packages in 17.03.
https://headcounter.org/hydra/eval/352053

[peti]

Haskell packages now contribute 0 build or evaluation errors to http://hydra.nixos.org/jobset/nixos/release-17.03.

[bachp]

Regarding the failing of VirtualBox with kernel 4.10 I found that version 5.1.16 is working https://github.com/NixOS/nixpkgs/pull/23687 so maybe this needs to be backporter for 17.03.

[0xABAB]

Just for fun I looked at http://hydra.nixos.org/build/49548363/nixlog/3 (boomerang) and the associated source code. The C++ code is so bad that the solution to the issue would be to tell upstream to write valid C++. The reason it worked before is what I would describe as "pure chance".

(Yes, we can try to fix every problem ever created by everyone who ever touched a computer, but I don't think we should.)

My vote (not that this is a democracy) is to remove boomerang as a package from NixOS, if the author does not fix it upstream in a reasonable amount of time.

[0xABAB]

http://hydra.nixos.org/build/49548633/nixlog/3 is asterisk which has a dependency on some SVN repository, which is likely new, which means the dependency needs to be extracted out of the SVN repository in potentially a new package and the asterisk package needs to be updated.

It appears that asterisk is already fixed; this needs to be reflected in the status post.

[0xABAB]

Package 'refind' is just another case of "We can't write valid code". Such garbage can better just be directed to /dev/null.

[0xABAB]

http://hydra.nixos.org/build/49552500 (or one of its dependencies) should be compiled with a C++11 compatible compiler, so that's a packaging flaw for the Nix maintainer in lightdm.

[0xABAB]

http://hydra.nixos.org/build/49546853/nixlog/3 nbci_tools is another Nix packaging problem (it uses a compiler which is potentially too new).

[0xABAB]

http://hydra.nixos.org/build/49550804/nixlog/3 refers to /bin/bash. That can't possibly be healthy. It also refers to non-existing tools in its compile time configuration, which would likely make some code paths useless at run-time. I.e., it needs repackaging and possibly upstream shouldn't hardcode such stuff (perhaps they shouldn't be writing code in the first place).

[obadz]

Marked coreclr as broken (in 1dd16a9 & 9037001)

[0xABAB]

sage seems to be an upstream problem.

See: http://hydra.nixos.org/build/49667492/nixlog/1

The general trend I see is that many of the packages listed are simply of low quality. It's worth considering the question: should we encourage the distribution of sequences of bits which hardly earn the label "software"?

[0xABAB]

clisp requires a build time dependency on automake-1.15 and then it will probably work.

[0xABAB]

http://hydra.nixos.org/build/49667509 (ultrastard) specifies a dependency when the tree has the dependency itself; it probably shouldn't specify the dependency, since it fails explicitly on user-defined libraries.

[0xABAB]

http://hydra.nixos.org/build/49540856/nixlog/3 (octave) needs a C++11 compiler configured. So, that's a packaging bug.

[0xABAB]

http://hydra.nixos.org/build/49556827/nixlog/3 (panomatic) shows build tool issues (autotools) and missing symbols, which might stem from too old dependencies (the upstream build system is broken, because it shouldn't try to compile things which it cannot compile). Solution would be for upstream to fix their build system first, and then we could consider it for inclusion.

[0xABAB]

http://hydra.nixos.org/build/49550369/nixlog/3 (robomongo) seems so low quality that I would again vote to get rid of it completely.

[0xABAB]

sipp misses libpcap.

[0xABAB]

http://hydra.nixos.org/build/49547864 (ponyc) requires e.g. LLVM 3.9.0, but nothing newer.

[0xABAB]

aliceml returned this gem:
```
aclocal: warning: autoconf input should be named 'configure.ac', not 'configure.in'
````

There are many other issues; my recommendation would be to tell upstream to fix their system first and get it out of Nix. After it's fixed, it can be repackaged. The quality is just not there to have people look at this mess.

[vcunat]

3.9.1 will probably be OK for ponyc, as there are only bugfixes atop.

[0xABAB]

@vcunat We have proof that 3.9.1 does not work in the logs.

We can tell them that ponyc's build system is broken after we have actually tried it with 3.9.0. They specifically mention 3.9.0. We should respect that, before we tell them something is wrong (when there likely isn't).

[0xABAB]

http://hydra.nixos.org/build/49556755/nixlog/3 (taskjuggler) requires a dependency on kde-config (no idea which package that is).

[0xABAB]

http://hydra.nixos.org/build/49545803 (manticore) needs upstream to fix their code:

[[manticore.lex:208.1]] Syntax error: try inserting ;

From a packaging perspective mlton can be added as a dependency, since a WARNING is displayed when it's not found.

[yorickvP]

asterisk should've been fixed in #23124. Maybe pick that to the release branch?

@0xABAB I do use sage, it'd be nice if it was in nixpkgs (also, a more recent version) (currently I resolved the problem by having the sysadmins install it on an ubuntu server). The build failure seems to be related to a wrong version (also see #23304).

[0xABAB]

http://hydra.nixos.org/build/49548474/nixlog/3 (freestyle) checks whether the build platform is x86-64 and stops when it is not. Whether or not this should be a problem I don't know; in principle it should be possible to do cross builds, but I thought Nix didn't always do these. If cross-building works, the check could simply be removed.

Another way to fix it is to tag the build in some way such that the build infrastructure only uses x86-64 machines to build.

[0xABAB]

@yorickvP A way to get sage in nixpkgs is then to install it on Ubuntu and check the exact versions it is using per package and compare those to the currently specified versions in Nix and then report back on that.

[7c6f434c]

Tried to just pass gcc49 version of stdenv to ncbi_tools. make asked to run a specific script called reconfigure.sh in some directory, running this script fails…

[doublec]

aliceml returned this gem:

aclocal: warning: autoconf input should be named 'configure.ac', not 'configure.in'

There are many other issues; my recommendation would be to tell upstream to fix their system first and get it out of Nix. After it's fixed, it can be repackaged. The quality is just not there to have people look at this mess.

I was the maintainer of the aliceml package. I don't use Nix anymore and would suggest removing it if recent Nix changes have broken it.

[7c6f434c]

re: ponyc: I think a fresh (last week) release wants LLVM 3.9.1

[vcunat]

I had looked on https://github.com/ponylang/ponyc/pull/1498 and only noticed adding 3.9.1 to the list of allowed versions, without any real changes in the code. (I don't count switching CI to 3.9.1, etc.)

[globin]

Bumping the version fixed the build

[guibou]

http://hydra.nixos.org/build/49535641 (ispc) can be easily fixed by changing the flex dependency to flex_2_6_1. This is apparently a known regression of flex 2.6.3 (https://github.com/westes/flex/issues/155)

[globin]

@guibou fixed already

[xvapx]

I have looked into tribler, both the current version (6.4.3) and the latest stable release (6.5.2) depend on wxPython 2.8, wich was removed in commit 253634c4acb7f29cae84065a4ba70f2bf0ccf582.
I suppose we should either bring back wxPython 2.8, mark tribler as broken, or upgrade it to a more recent beta version.
I volunteer to do any of these things if you want.

[vcunat]

15764 claimed that wxPython 2.8 is broken. @FRidh may remember more.

[FRidh]

@xvapx @vcunat the last update on the package by a user was 225ae4c5f8a11183fffbc0f78c988f0a2cf3d16f. If tribler needs wxPython 2.8 then that means it was broken already for at least 10 months (and thus also in 16.09). Therefore I think we should mark it as broken or just get rid of it.

[xvapx]

@vcunat @FRidh I agree.
I will probably try to build the 7.0.0-beta for myself though, would it be Ok to mark it as broken and add it back when there is a stable release? or is it better to remove it and maybe add it back whenever it's working again?

[globin]

If the 7.0.0-beta works you can update to that, too.

[xvapx]

Ok, then, I will try it.

[rnhmjoj]

23511 should fix blink once merged.

[vcunat]

python3.5-path.py-10.1 build has been one of the channel channel blockers for a few days (a transitive dependency of gnome); @FRidh: any ideas?

[FRidh]

@vcunat yep, there's a setuptools_scm upgrade on master that is needed. There are a couple of commits that depend on that as well so let's see whether I can cherry-pick them without breaking anything more.

[vcunat]

Thanks! The less risky, the better. Our plan is to release in about ten days and our channel is still ten days old... (which lowers the amount of users running the code and may hide other problems)

[vcunat]

Staged that makeWrapper fix, so blink should be OK after that.

[vcunat]

Tested job succeeded! Expecting channel bump today :-)

[xvapx]

tribler 7.0.0-beta working, #24202

[WilliButz]

~I can't reproduce the error of libsingular on my machine. The build process runs through without an error and the binaries seem to work as intended.
If someone can confirm this we should be able to remove it from the list.~
Seems to be reproducible with 32bit

[AndersonTorres]

Refind was dropped? Well, I think it is a good thing: it only compiles with an old version of gnu-efi.

[joachifm]

I'm fairly confident that the daemontools and runit.i686 failures are hydra problems; both build fine locally.

[globin]

Closing as the release is imminent and there are no larger failures.