Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Zero Hydra Failures for release-16.03 branch #13559

Closed
domenkozar opened this Issue Feb 28, 2016 · 42 comments

Comments

Projects
None yet
@domenkozar
Copy link
Member

domenkozar commented Feb 28, 2016

Creating a tracking issue for ZHF effort in 16.03 release.

Failing packages (https://hydra.nixos.org/jobset/nixos/release-16.03):

@lethalman

This comment has been minimized.

Copy link
Contributor

lethalman commented Mar 1, 2016

devhelp fixed at b2889ef

@cpages

This comment has been minimized.

Copy link
Contributor

cpages commented Mar 1, 2016

pvr-hts should also be fixed at 7eb1526. Thanks for poking me about that.

@domenkozar

This comment has been minimized.

Copy link
Member Author

domenkozar commented Mar 1, 2016

Please also cherry-pick to release-16.03 branch. Thanks! 🍺

@pSub pSub referenced this issue Mar 1, 2016

Merged

libclc: 2015-03-27 -> 0.2.0 #13604

4 of 5 tasks complete
@magnetophon

This comment has been minimized.

Copy link
Contributor

magnetophon commented Mar 1, 2016

I can not reproduce on 15.09, and I can't switch to 16.03 now, because I'm in the middle of a project.

The error is: <command-line>:0:1: error: macro names must be identifiers .
I have no idea how to troubleshoot that.

If wanted, I could do a PR with faust1 as the default, and see if that builds???

@pmahoney Do you have ideas?

@domenkozar domenkozar changed the title Zero Hydra Failures for 16.03 Zero Hydra Failures for release-16.03 branch Mar 2, 2016

@cleverca22

This comment has been minimized.

Copy link
Contributor

cleverca22 commented Mar 2, 2016

multimc builds without any error on my end, when on the release-16.03 branch and all overrides disabled

aha, chroot builds break it

found and fixed, cmake was downloading .tar.gz files at buildtime, and when the chroot cut off network, it silently continued without the tar, and tried to patch the files the tar provided

@cleverca22 cleverca22 referenced this issue Mar 2, 2016

Merged

multimc: fix building under chroot #13618

3 of 3 tasks complete
@globin

This comment has been minimized.

Copy link
Member

globin commented Mar 5, 2016

ceph is fixed

@zimbatm

This comment has been minimized.

Copy link
Member

zimbatm commented Mar 6, 2016

evolution builds fine here, it was a "No space left on device" error

@domenkozar

This comment has been minimized.

Copy link
Member Author

domenkozar commented Mar 9, 2016

I've removed fixed packages. Could we get the rest of them to build?

@abbradar

This comment has been minimized.

Copy link
Member

abbradar commented Mar 9, 2016

StepMania is fixed in c82d282

vcunat added a commit that referenced this issue Mar 9, 2016

gpgstats: fix build on 32-bit; LFS problems
(cherry picked from commit 5782b5d)
/cc #13559.
@vcunat

This comment has been minimized.

Copy link
Member

vcunat commented Mar 10, 2016

The tests are getting lots of these errors again:

machine# building path(s) ‘/nix/store/cy5h6d0swa5c1463dkz3y54aa6821ws3-libxslt-1.1.28.tar.gz’
machine# error checking the existence of http://tarballs.nixos.org/sha256/13029baw9kkyjgr7q3jccw2mz38amq7mmpr5p3bh775qawd1bisz:
machine# curl: (6) name lookup timed out
machine# [...]

Does someone know what's happening in there? I know we've had them relatively often in the past.

@domenkozar

This comment has been minimized.

Copy link
Member Author

domenkozar commented Mar 10, 2016

This looks to me like it's because it wants to build the manual due to some reference to a package.

@domenkozar

This comment has been minimized.

Copy link
Member Author

domenkozar commented Mar 10, 2016

@vcunat

This comment has been minimized.

Copy link
Member

vcunat commented Mar 10, 2016

Ah, right. My new code only purges derivations, and kernelPatches is a plain attrset that contains derivations in lists (which aren't traversed during purging).

@domenkozar

This comment has been minimized.

Copy link
Member Author

domenkozar commented Mar 10, 2016

@vcunat are you planning to fix this soonish or should I make a temporary fix?

@vcunat

This comment has been minimized.

Copy link
Member

vcunat commented Mar 10, 2016

By "fix" you mean to traverse lists as well? I don't plan that soonish. And in this particular case I do not think we actually want to display the contents of the whole attrset with patch descriptions anyway. I'd go with the usual mkDefault, which I presume is the temporary fix you planned?

@domenkozar

This comment has been minimized.

Copy link
Member Author

domenkozar commented Mar 10, 2016

@vcunat yes, but we also want to catch this kind of errors. Didn't we have some hackish logic to detect hashes in manual?

@vcunat

This comment has been minimized.

Copy link
Member

vcunat commented Mar 10, 2016

I thought we did have a check in there. I don't fully understand this issue, apparently.

@domenkozar

This comment has been minimized.

Copy link
Member Author

domenkozar commented Mar 10, 2016

OK, I'll look into it. I'll also write a script to generate a list of packages that need fixing since tracking them is becoming a bit tedious.

domenkozar added a commit to domenkozar/nixpkgs that referenced this issue Mar 11, 2016

domenkozar added a commit that referenced this issue Mar 12, 2016

@domenkozar

This comment has been minimized.

Copy link
Member Author

domenkozar commented Mar 12, 2016

I've pushed a fix dbcb901 to release-16.03, but now I'm getting some really weird errors on idempotent nixos-install invokations:

machine# Installation finished. No error reported.                                                                                                                                                                                                 [132/1924]
machine# setting up /etc...
machine# Initializing machine ID from random generator.
machine# installation finished!
machine: exit status 0
machine: must succeed: nixos-install < /dev/null >&2
machine# building the system configuration...
machine# error: anonymous function at /tmp/root/nix/store/mix539jcyx47h4s0agp66zd9583m1vp2-nixos-16.03.git.58f9896/nixos/pkgs/development/libraries/polkit/default.nix:1:1 called with unexpected argument ‘spidermonkey’, at /tmp/root/nix/store/mix539jcyx4
7h4s0agp66zd9583m1vp2-nixos-16.03.git.58f9896/nixos/lib/customisation.nix:56:12
machine# (use ‘--show-trace’ to show detailed location information)

Happens a;so on 16.03 channel commit (that passed tests), so I'm really confused.

@domenkozar

This comment has been minimized.

Copy link
Member Author

domenkozar commented Mar 27, 2016

Chromium is failing due to https://sourceware.org/bugzilla/show_bug.cgi?id=19542 - maybe we should use gold linker? cc @aszlig

@peti

This comment has been minimized.

Copy link
Member

peti commented Mar 31, 2016

No more Haskell packages fail to build (or evaluate) in 16.03. It's all in pretty fine condition.

@domenkozar

This comment has been minimized.

Copy link
Member Author

domenkozar commented Apr 1, 2016

We're down to ~180 packages. Still needs a bit of work.

@joachifm

This comment has been minimized.

Copy link
Contributor

joachifm commented Apr 1, 2016

@domenkozar do you know what's up with those remaining failing grsec builds? They refer to an error that has been fixed. The fixed code should be used by all grsec variants.

@domenkozar

This comment has been minimized.

Copy link
Member Author

domenkozar commented Apr 6, 2016

I'm now mostly worried about lots of transient failures in tests, often blocking a channel update: http://hydra.nixos.org/job/nixos/release-16.03/tested#tabs-constituents

@domenkozar

This comment has been minimized.

Copy link
Member Author

domenkozar commented Apr 6, 2016

I see the following transient errors:

I'm going to increase timeout for udevadm settle, but for the rest of them no idea yet.

domenkozar added a commit that referenced this issue Apr 6, 2016

@domenkozar

This comment has been minimized.

Copy link
Member Author

domenkozar commented Apr 6, 2016

The first one seems to be due 146c727, @edolstra you seem to have marked it as fragile, any specific reason why?

@domenkozar

This comment has been minimized.

Copy link
Member Author

domenkozar commented Apr 6, 2016

For mdadm, I think we're hitting a timeout for mdadm to finish syncing, but mdadm doesn't let us specify one. I'm assuming here, maybe the sync really fails (can't reproduce locally).

@domenkozar

This comment has been minimized.

Copy link
Member Author

domenkozar commented Apr 7, 2016

Kernel crashes should be fixed once https://lkml.org/lkml/2016/3/29/1010 is released in the kernel update for 4.3+.

ckauhaus added a commit to ckauhaus/nixpkgs that referenced this issue Apr 13, 2016

ckauhaus added a commit to ckauhaus/nixpkgs that referenced this issue Apr 13, 2016

ckauhaus added a commit to ckauhaus/nixpkgs that referenced this issue Apr 13, 2016

ckauhaus added a commit to ckauhaus/nixpkgs that referenced this issue Apr 13, 2016

ckauhaus added a commit to ckauhaus/nixpkgs that referenced this issue Apr 13, 2016

ckauhaus added a commit to ckauhaus/nixpkgs that referenced this issue Apr 13, 2016

ckauhaus added a commit to ckauhaus/nixpkgs that referenced this issue Apr 13, 2016

ckauhaus added a commit to ckauhaus/nixpkgs that referenced this issue Apr 13, 2016

@domenkozar

This comment has been minimized.

Copy link
Member Author

domenkozar commented May 24, 2016

Eelco fixed the major issue in ad29b72, I'll check if mdadm issue still appears and open a new issue. Thanks everyone!

@domenkozar domenkozar closed this May 24, 2016

@edolstra

This comment has been minimized.

Copy link
Member

edolstra commented May 24, 2016

The mdadm failures should be addressed by 3e7b510.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.