UPDATE after initial 20.09 Release:
Fixing broken packages will always be possible throughout the lifetime of the 20.09 release. However, you may need to remove the broken = true; attr on the package. Otherwise please follow normal back-port conventions. :)
Old Post:
Jobsets:
- https://hydra.nixos.org/jobset/nixos/release-20.09
- https://hydra.nixos.org/jobset/nixos/release-20.09-aarch64
- https://hydra.nixos.org/jobset/nixos/release-20.09-small
- https://hydra.nixos.org/jobset/nixpkgs/nixpkgs-20.09-darwin
- https://hydra.nixos.org/jobset/nixpkgs/staging-20.09
Mission
Every time we branch off a release we stabilize the release branch.
Our goal here is to get as little as possible jobs failing on the release-20.09 jobsets.
I'd like to heighten, while it's great to focus on zero as our goal, it's essentially to
have all deliverables that worked in the previous release work here also.
How many failing jobs are there?
At the opening of this issue we have the main x86_64-linux jobset at 1153 failing jobs, x86_64-darwin at >7130, and aarch64-linux at 7573+.
Previous releases first evals
19.09 had 1654 failing jobs.
20.03 had 1204 failing jobs,
20.09 had 1153 failing jobs,
So we're actually getting better at maintaining a more stable "unstable" channel.
However, our darwin story isn't as good (we need more darwin reviewers/contributors)
20.03 had 1384 failing jobs,
20.09 had >7130 failing jobs,
How to help (textual)
Select an evaluation of the release-20.09 jobset by #id
Find a failed job 鉂岋笍
Troubleshoot why it's failing and fix it
Create a Pull Request with the fix targeting master, wait for it to be merged.
Generally the job fails on master also, you can verify that on Hydra - example URL: https://hydra.nixos.org/job/nixpkgs/trunk/bash.x86_64-linux.
That means most PR's should be target themasterbranch, however, if your PR causes around 500+ rebuilds, it's preferred to targetstagingto avoid compute and storage churn.
Always reference this issue in the body of your PR:
ZHF: #97479
- After the master PR was merged, select the commit(s) from the master branch and cherry-pick the commit(s) into a backport PR. See CONTRIBUTING.md for exact details on how that should be performed. An example can be found here: Master PR and 20.09 PR
Please ping @NixOS/nixos-release-managers on the PR.
If you're unable to because you're not a member of the NixOS org please ping
@jonringer and @worldofpeace (the same people in the team).
How to help video tutorial
@jonringer has made a video on YouTube to guide anyone through how fixing something for ZHF will look like: https://www.youtube.com/watch?v=4Zb3GpIc6vk&
New to nixpkgs?
@jonringer created some videos to help get people started with nixpkgs:
- Packaging a basic C application
- Python nix packaging
- Adding a package to nixpkgs
- Backporting changes (ZHF)
Also be sure to check out other resources at: https://github.com/nix-community/awesome-nix
Packages that don't get fixed
The remaining packages will be marked as broken before the release (on the failing platforms).
You can do this like:
meta = {
# ref to issue/explanation
# `true` is for everything
broken = stdenv.isDarwin
};
These are the utility flags used to test the type of platform.
Closing
This is a great way to help NixOS, and it was some of my earliest contributions.
Let's go 鉁岋笍
鉁笍 @worldofpeace and @jonringer
cc @NixOS/nixpkgs-committers @NixOS/nixpkgs-maintainers
Related Issues
- Timeline: #95535
- Feature Freeze Items: #95475
- Release Notes: #95765
jonringer
All 62 comments
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/nixos-20-09-zero-hydra-failures/8928/1
nixos-discourse
on 9 Sep 2020
It can also be useful to refer to https://hydra.nixos.org/eval/1611944, a master evaluation taken around the time of the branchoff, which will have a much longer history you can use to dig back to a package's last successful build and get an indication of the changes which might have caused it to break.
risicle
on 9 Sep 2020
Also, people can use @samueldr 's nix-review-tools to create a report which will show which packages are causing the most failures.
I usually do something like:
mkdir cache
cd cache
../eval-report $evaluation_id > index.html
xdg-open index.html
The nearest NixOS:trunk-combined Hydra evaluation is 1611942 at commit 6152513, 6 commits after the last shared commit 53ce0bf.
Mathnerd314
on 9 Sep 2020
However, our darwin story isn't as good [...]
It's blown up by ghc timing out. That has been occasionally happening and it should go away after some restart(s).
vcunat
on 9 Sep 2020
@vcunat should we pass "big-parallel" for the ghc build so that it has more cores?
jonringer
on 9 Sep 2020
Since last time this was useful to many, here's one way to build all packages which have you as maintainer:
apply #97514Pull frommasterorrelease-20.09so you have the latest build.nix mentioned below- run
nix-build maintainers/scripts/build.nix --argstr maintainer fgaz(adjust the maintainer name to yourself)
fgaz
on 9 Sep 2020
We cannot ping @NixOS/nixos-release-managers as required in the issue if we鈥檙e not part of the organization, is it possible to fix that?
immae
on 9 Sep 2020
I know there's a more limited number of people who use nix on macOS, so I'd like to focus my efforts there, is there a way of getting a list of jobs that are succeeding on nixpkgs/staging-20.09 and failing on nixpkgs/nixpkgs-20.09-darwin?
uri-canva
on 9 Sep 2020
@uri-canva that is possible by opening an evaluation of nixpkgs/nixpkgs-20.09-darwin and the you have to hit the Compare to button and select nixpkgs/staging-20.09. All "Newly failing" builds are fine one staging-20.09, but fail on nixpkgs-20.09-darwin.
However it should be sufficient to filter for jobs matching x86_64-darwin in Search jobs by name, right?
Ma27
on 9 Sep 2020
Yes, but that would also show derivations that are failing for the same reason on linux and darwin, and would be fixed by fixing the linux derivations anyway.
uri-canva
on 9 Sep 2020
Is there any way to get a list of my (currently broken) derivations like in some previous ZHF sprints?
makefu
on 9 Sep 2020
@makefu you could try to build them with the command i posted in this thread
fgaz
on 9 Sep 2020
As an aside, I wish we could opt-in to failed build notification emails from hydra. I didn't know some of my packages were broken :-/
fgaz
on 9 Sep 2020
@makefu you could try to build them with the command i posted in this thread
I actually tried that but the build it looks like the process fails pre-build. I am now in the progress of trying to fix all evaluation errors
~/nixpkgs git reset --hard upstream/master
HEAD is now at 5d131d33268 Merge pull request #97540 from danieldk/fix-clpeak
~/nixpkgs nix-build maintainers/scripts/build.nix --argstr maintainer makefu --show-trace --keep-going
error: while evaluating the attribute 'drvPath' at /home/makefu/nixpkgs/lib/customisation.nix:163:7:
while evaluating the attribute 'buildInputs' of the derivation 'python2.7-aresponses-2.0.0' at /home/makefu/nixpkgs/pkgs/development/interpreters/python/mk-python-derivation.nix:108:5:
while evaluating 'getOutput' at /home/makefu/nixpkgs/lib/attrsets.nix:464:23, called from undefined position:
while evaluating anonymous function at /home/makefu/nixpkgs/pkgs/stdenv/generic/make-derivation.nix:143:17, called from undefined position:
while evaluating 'callPackageWith' at /home/makefu/nixpkgs/lib/customisation.nix:117:35, called from /home/makefu/nixpkgs/pkgs/top-level/python-packages.nix:5446:20:
while evaluating 'makeOverridable' at /home/makefu/nixpkgs/lib/customisation.nix:67:24, called from /home/makefu/nixpkgs/lib/customisation.nix:121:8:
while evaluating anonymous function at /home/makefu/nixpkgs/pkgs/development/python-modules/pytest-asyncio/default.nix:1:1, called from /home/makefu/nixpkgs/lib/customisation.nix:69:16:
while evaluating 'makeOverridablePythonPackage' at /home/makefu/nixpkgs/pkgs/top-level/python-packages.nix:36:37, called from /home/makefu/nixpkgs/pkgs/development/python-modules/pytest-asyncio/default.nix:2:1:
while evaluating 'makeOverridable' at /home/makefu/nixpkgs/lib/customisation.nix:67:24, called from /home/makefu/nixpkgs/pkgs/top-level/python-packages.nix:38:12:
while evaluating anonymous function at /home/makefu/nixpkgs/pkgs/development/interpreters/python/mk-python-derivation.nix:31:1, called from /home/makefu/nixpkgs/lib/customisation.nix:69:16:
pytest-asyncio-0.14.0 not supported for interpreter python2.7
I'll be back once i finished that and maybe encountered some actual build errors.
EDIT: is it preferable to pool all the py3k-related evaluation fixes ( disabled = !isPy3k; ) or should i create a PR for each package?
makefu
on 9 Sep 2020
Since last time this was useful to many, here's one way to build all packages which have you as maintainer:
* ~apply #97514~ Pull from master so you have the latest build.nix mentioned below * run `nix-build maintainers/scripts/build.nix --argstr maintainer fgaz` (adjust the maintainer name to yourself)
@fgaz won't this build on master? Don't we want to test the nixos-20.09 branch?
bbigras
on 9 Sep 2020
@bbigras well we're trying to fix both! But yes, I see what you mean, and I guess that pr needs a backport. I'll open another pr.
edit: done & merged
fgaz
on 9 Sep 2020
@makefu I got a fix for you #97571
I ran into the same issue with python packages where unsupported interpreters throw an error
jonringer
on 9 Sep 2020
I've tried fixing springLobby but it fails to find libcurl, did somethng change about that around 15th August?
EDIT: seems like a CMAKE bump
domenkozar
on 10 Sep 2020
Thank you for clearly describing the contrib process for ZHF. I drive-by fixed a package I happened to use, but wouldn't have bothered contributing to ZHF if it wasn't so easy.
endgame
on 11 Sep 2020
I found a few cases in perlPackages builds on Darwin where there's an issue with ld which is fixed by adding "export LD=$CC", which several packages appear to have done already. Some predicate on i686 or Darwin, and some do it unconditionally.
Is it worth opening an issue and trying to find a more general fix for all perlPackages, or should I just do one-off PRs for each one I find like this?
Or maybe do them both so there's at least a fix for 20.09?
treed
on 12 Sep 2020
@volth , do you know the best way going forward for @treed
jonringer
on 13 Sep 2020
- nix-build maintainers/scripts/build.nix --argstr maintainer fgaz
Is there a way to get past evaluation errors if there are some? (I get an error: bcrypt-3.2.0 not supported for interpreter python2.7)
knedlsepp
on 14 Sep 2020
What is to be done if a package is broken in release-20.09, but works in master? My concrete case is kmime; it was broken by commit ce4eb0b79b3b8e830d40345fb6457fac6ca9a9ec and still is in release-20.09, but is fine in master.
loewenheim
on 14 Sep 2020
What is to be done if a package is broken in
release-20.09, but works inmaster? My concrete case iskmime; it was broken by commit ce4eb0b and still is inrelease-20.09, but is fine inmaster.
A backport I would guess.
bbigras
on 14 Sep 2020
I'd use nix show-derivation -f. kmime > kmime.$(git describe HEAD).json when the master and the release branch are checked out, and diff the outputs.
doronbehar
on 14 Sep 2020
Is there a way to get past evaluation errors if there are some?
@knedlsepp either #97571 or #97647
fgaz
on 14 Sep 2020
What is to be done if a package is broken in
release-20.09, but works inmaster? My concrete case iskmime; it was broken by commit ce4eb0b and still is inrelease-20.09, but is fine inmaster.
@loewenheim see comments in #97242 for why kmime is failing
petabyteboy
on 15 Sep 2020
@thoughtpolice in january you said (in https://github.com/NixOS/nixpkgs/pull/77985#pullrequestreview-344972610):
I would also be fine with dropping FoundationDB 5.x builds, too, since they're pretty heavy to build and I imagine most people are running 6.x at this point.
Do you think now might be the time to do that?
risicle
on 19 Sep 2020
pythonPackages.gipc looks like it'll be stuck waiting on https://github.com/jgehrcke/gipc/issues/103
(good thing I tried enabling the tests to discover that)
risicle
on 23 Sep 2020
I was thinking about going through and disabling all the failing python27Packages that have explicitly dropped python 2 upstream, but I see this https://github.com/NixOS/nixpkgs/pull/92099. Is there any point in bothering? @jonringer
mvnetbiz
on 24 Sep 2020
I was thinking about going through and disabling all the failing python27Packages that have explicitly dropped python 2 upstream, but I see this #92099. Is there any point in bothering? @jonringer
I've been somewhat doing that while reviewing other packages https://github.com/NixOS/nixpkgs/pulls?q=is%3Apr+author%3Ajonringer+disable+is%3Aclosed+python
The discussion you linked to is a bit more involved.
Not recursing into the attr set is the "easiest" solution, but will not perfect for users that still need some python2 packages
jonringer
on 24 Sep 2020
I am a bit late and don't know if this is the right place as I am new to ZHF but I had a look at some darwin packages with the help of nixpkgs-review-tools:
| Name |Count |Builds Locally|Builds on Hydra |Action Needed|
|:---:|:---:|:---:|:---:|:---:|
| python38-curio-1.2 | 112 | :heavy_check_mark: | :heavy_check_mark: | :white_check_mark: #98927 |
| qtbase-5.14.2 | 95 | :x: | :x: Cannot find feature sdk | @eqyiel https://github.com/eqyiel/nixpkgs/commit/50c2b5fd030459ff9508f65e9ffdebad0de36a63 has a WIP that removes the usr/bin/xcodebuild impurities. Unfortunately it needs at least the 10.13 sdk. See https://github.com/NixOS/nixpkgs/issues/95199 for more details. @matthewbauer Would now be a good time to upgrade the sdk? Probably that is too much work but is it possible to have multiple apple sdk versions? |
| qtbase-5.15.0 | 47 | :x: | use of undeclared identifier | not looked at maybe the 5.14.2 actions fix this too |
| python3.7-notebook-6.1.3 | 40 | :heavy_check_mark: | :heavy_check_mark: | :white_check_mark: #98621 |
| python3.8-notebook-6.1.3 | 38 | :heavy_check_mark: | :heavy_check_mark: | :white_check_mark: #98621 |
| python3.8-fsspec-0.7.4 | 27 | :heavy_check_mark: | :x: def test_modified fails | I disabled the one failing test in this backport #98987 for review |
| python3.8-fs-2.4.11 | 18 | :x: | :x: resource tracker cannot free resource | Seems to be a multiprocessing issue with python 3.8.5 on macosx as it works with python37. I opened an issue here https://github.com/PyFilesystem/pyfilesystem2/issues/430 and disabled the tests in this pr https://github.com/NixOS/nixpkgs/pull/98619 which is open for review too. |
tricktron
on 26 Sep 2020
@tricktron re curio, I think it would be perfectly acceptable to disable these two tests on darwin given the impact. It's clearly not an issue with the library.
Also, notebook backport has been approved.
risicle
on 26 Sep 2020
I also keep finding someone has got ahead of me discovering upstream issues (frequently @jonringer) so I think it might be useful to link to upstream blocker issues here to save people digging down to the same issue.
pythonPackages.localzoneis held up on https://github.com/ags-slc/localzone/issues/1
(there's also a chance the author seeing the issue referenced might get spurred into action...)
risicle
on 26 Sep 2020
Samba build is fixed on darwin in 4.13+ by
https://gitlab.com/samba-team/devel/samba/-/commit/847208cd8ac68c4c7d1dae63767820db1c69292b
which has also been backported in 4.12.6. I also backported the patch to apply cleanly to the current 4.12.5 to avoid rebuilds, but would it be preferable to just update to 4.12.6? (New to ZHF so I don't know what impact that would have)
r-burns
on 26 Sep 2020
@tricktron re
curio, I think it would be perfectly acceptable to disable these two tests on darwin given the impact. It's clearly not an issue with the library.
@risicle Ok pr opened here https://github.com/NixOS/nixpkgs/pull/98875
Also,
notebookbackport has been approved.
Thanks
tricktron
on 26 Sep 2020
@r-burns I'd personally go for the bump.
risicle
on 26 Sep 2020
~git-annex-adapter is stuck waiting on https://github.com/alpernebbi/git-annex-adapter/issues/13 and https://github.com/alpernebbi/git-annex-adapter/issues/14~
~(after getting past the immediate trivial build-stopper by passing cacert to checkInputs)~
I can't tell my branches apart.
risicle
on 26 Sep 2020
/me coughs in the direction of #98688
risicle
on 27 Sep 2020
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
nixos-discourse
on 29 Sep 2020
PRs still needing review in this thread:
_vcunat EDIT: all done now_
100049
99673
99655
99642
99586
99500
99383
99252
99076
99052
99040
98580
98381
risicle
on 10 Oct 2020
yea, sorry, mixture of burnout and ck3 has lead me to neglecting this
jonringer
on 11 Oct 2020
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/nixos-weekly-08-nixos-weekly/9431/1
nixos-discourse
on 12 Oct 2020
@jonringer went through all of open ones and merged most of them :)
domenkozar
on 13 Oct 2020
Many others also helped, I'll do a proper thanks in the release post :)
jonringer
on 13 Oct 2020
The x86_64 build of itk-5.1.1 is broken on Hydra with an "Illegal instruction" error, but building locally succeeds (and Hydra builds master), so I'm not exactly sure how to bisect/troubleshoot this.
bcdarwin
on 15 Oct 2020
The x86_64 build of itk-5.1.1 is broken on Hydra with an "Illegal instruction" error, but building locally succeeds (and Hydra builds master), so I'm not exactly sure how to bisect/troubleshoot this.
"Illegal instruction" means a program uses an instruction that is unsupported by a CPU, Hydra builders have different CPUs so certain instructions will be supported only by some machines.
This happens because ITK is built with -march=corei7 (https://github.com/InsightSoftwareConsortium/ITK/blob/4b48c9025f66d179d7b134999e2398f5924093b4/CMake/ITKSetStandardCompilerFlags.cmake#L245). -march=corei7 means that the program is compiled for CPUs supporting MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1 and SSE4.2 only.
I believe we may want to remove -march=corei7 (because it's not correct for NixOS, currently the distribution doesn't assume any particular CPU) and -mtune=native (because reproducibility).
xfix
on 16 Oct 2020
What's the plan for theano? @twhitehead had several suggestions in https://github.com/NixOS/nixpkgs/pull/99516#issuecomment-703289554 but which do we want to take forward for release-20.09?
risicle
on 16 Oct 2020
Hmm... I quite need #99587 merged to be able to backport it to 20.09, but its dependencies are now broken on master.
risicle
on 17 Oct 2020
Hmm... I quite need #99587 merged to be able to backport it to 20.09, but its dependencies are now broken on
master.
Assuming the dependencies aren't broken on 20.09, would it be permissible in this extraordinary case to either
- make the backport already now, although #99587 isn't merged yet
or to
- implement the pymc3 fix directly on 20.09 and later forward-port it to master
?
das-g
on 17 Oct 2020
I've essentially made the backport already because it requires some subtle tweaks on release-20.09. It's just it would feel pretty wrong for something that includes a new package to make it to a stable branch before master.
risicle
on 17 Oct 2020
Evals report
Report built at 2020-10-24 20:55:13 UTC
Built for evals:
i686-linux
- 77 issues
Failure table
x86_64-linux
- 491 issues
Failure table
aarch64-linux
- 63 issues
Failure table
Problematic dependencies
| name | count |
|---|---|
x86_64-linux kmime-20.08.1
|
45 |
aarch64-linux ghc-8.6.5-binary
|
16 |
i686-linux SHA-1.6.4.4
|
13 |
i686-linux aeson-1.4.7.1
|
12 |
i686-linux OVMF-201911
|
12 |
x86_64-linux kpimtextedit-20.08.1
|
11 |
aarch64-linux tracker-2.3.4
|
8 |
aarch64-linux mono-5.20.1.27
|
8 |
x86_64-linux libkgapi-20.08.1
|
8 |
x86_64-linux library_hello-world_latest-config.json
|
6 |
x86_64-linux jvmci-19.3-b05
|
6 |
x86_64-linux foundationdb-6.0.18
|
6 |
aarch64-linux gegl-0.4.26
|
4 |
aarch64-linux nixos-boot-disk
|
4 |
x86_64-linux docker-layer-ca4f61b1923c10e9eb81228bd46bee1dfba02b9c7dac1844527a734752688ede.tar.gz
|
4 |
i686-linux hydra-2020-10-20
|
4 |
i686-linux prometheus-2.20.1
|
4 |
x86_64-linux seexpr-2.11
|
4 |
x86_64-linux skein-0.8.0-maven-repo
|
4 |
x86_64-linux python3.8-pyside-shiboken-1.2.4
|
4 |
x86_64-linux ruby2.6.6-pango-3.4.1
|
4 |
x86_64-linux sage-tests-8.9
|
4 |
x86_64-linux python2.7-pywbem-1.0.2
|
3 |
x86_64-linux sbv-7.13
|
3 |
x86_64-linux python2.7-zc.lockfile-2.0
|
3 |
x86_64-linux python3.7-JPype1-1.0.2
|
3 |
x86_64-linux bcachefs-tools-2020-04-04
|
2 |
i686-linux beanstalkd-1.12
|
2 |
i686-linux rocksdb-6.10.2
|
2 |
i686-linux clickhouse-20.5.2.7
|
2 |
i686-linux perl5.32.0-Unicode-UTF8-0.62
|
2 |
i686-linux ejabberd-20.03
|
2 |
i686-linux python3.8-python-efl-1.24.0
|
2 |
i686-linux php-calendar-7.3.23
|
2 |
i686-linux python3.8-pycognito-0.1.3
|
2 |
i686-linux grafana-loki-1.6.1
|
2 |
i686-linux gradle-6.6
|
2 |
i686-linux mbuffer-20200505
|
2 |
i686-linux sope-5.0.0
|
2 |
i686-linux VictoriaMetrics-1.40.0
|
2 |
x86_64-linux rust_url-1.6.0
|
2 |
x86_64-linux FSharp.Compiler.Service-0.0.90
|
2 |
x86_64-linux googleapis-cpp-cmakefiles-0.1.5
|
2 |
x86_64-linux idris-sdl2-0.1.1
|
2 |
x86_64-linux ocaml4.08.1-x509-0.11.2
|
2 |
x86_64-linux ostinato.desktop
|
2 |
x86_64-linux perl5.30.3-Math-BigInt-Lite-0.19
|
2 |
x86_64-linux CNTK-2.7
|
2 |
x86_64-linux python2.7-ECPy-1.2.3
|
2 |
x86_64-linux python3.7-piexif-1.1.3
|
2 |
x86_64-linux python3.7-umap-learn-0.3.10
|
2 |
x86_64-linux python3.8-piexif-1.1.3
|
2 |
x86_64-linux python3.8-umap-learn-0.3.10
|
2 |
x86_64-linux arm-none-eabihf-stage-static-gcc-debug-9.3.0
|
2 |
x86_64-linux ruby2.5.8-pango-3.4.1
|
2 |
x86_64-linux ruby2.7.1-pango-3.4.1
|
2 |
x86_64-linux libtoggl-7.4.231
|
2 |
i686-linux yabar-unstable-2018-01-18
|
1 |
i686-linux noto-fonts-emoji-unstable-2020-08-20
|
1 |
x86_64-linux ocaml4.10.0-tls-0.12.4
|
1 |
x86_64-linux ocaml4.10.0-mirage-crypto-pk-0.8.5
|
1 |
Generated by eval-report
das-g
on 24 Oct 2020
aarch64 GHC: that's issue #97407. We currently have a fixup in staging-next, so if it turns out well on Hydra, I planned to pick it to 20.09 as well. (other platforms won't even rebuild)
vcunat
on 25 Oct 2020
I expect that KDE/Qt failures might be some remaining cases of combining different Qt5 versions, e.g. /cc https://github.com/NixOS/nixpkgs/pull/101411 EDIT: I haven't had time to really look into these so far.
metrics is my problem, please disregard it for now (I trust the outage doesn't cause problems to anyone).
vcunat
on 25 Oct 2020
Regarding the Fritzing build error, it seems I forgot to backport https://github.com/NixOS/nixpkgs/pull/98381
avdv
on 25 Oct 2020
Fritzing didn't build, now it starts up OK. Picked as f5ad6d9f77.
vcunat
on 25 Oct 2020
Another current state of the ZHF:
Evals report
Report built at 2020-10-26 19:06:44 UTC
Built for evals:
i686-linux
- 81 issues
Failure table
x86_64-linux
- 486 issues
Failure table
aarch64-linux
- 66 issues
Failure table
Still queued
- 1 issues
Failure table
| job | status | platform |
|---|---|---|
| nixpkgs.metrics | Queued | x86_64-linux |
Problematic dependencies
| name | count |
|---|---|
x86_64-linux kmime-20.08.1
|
45 |
x86_64-linux kpimtextedit-20.08.1
|
11 |
i686-linux aeson-1.4.7.1
|
9 |
aarch64-linux ghc-8.6.5-binary
|
8 |
x86_64-linux libkgapi-20.08.1
|
8 |
aarch64-linux tracker-2.3.4
|
6 |
i686-linux OVMF-201911
|
6 |
x86_64-linux jvmci-19.3-b05
|
6 |
x86_64-linux foundationdb-6.0.18
|
6 |
x86_64-linux docker-layer-ca4f61b1923c10e9eb81228bd46bee1dfba02b9c7dac1844527a734752688ede.tar.gz
|
5 |
x86_64-linux library_hello-world_latest-config.json
|
4 |
aarch64-linux mono-5.20.1.27
|
4 |
x86_64-linux seexpr-2.11
|
4 |
x86_64-linux skein-0.8.0-maven-repo
|
4 |
x86_64-linux python3.8-pyside-shiboken-1.2.4
|
4 |
x86_64-linux ruby2.6.6-pango-3.4.1
|
4 |
x86_64-linux sage-tests-8.9
|
4 |
i686-linux SHA-1.6.4.4
|
3 |
x86_64-linux python2.7-pywbem-1.0.2
|
3 |
x86_64-linux sbv-7.13
|
3 |
x86_64-linux python2.7-zc.lockfile-2.0
|
3 |
x86_64-linux python3.7-JPype1-1.0.2
|
3 |
aarch64-linux nixos-boot-disk
|
2 |
i686-linux hydra-2020-10-20
|
2 |
i686-linux prometheus-2.20.1
|
2 |
x86_64-linux rust_url-1.6.0
|
2 |
x86_64-linux FSharp.Compiler.Service-0.0.90
|
2 |
x86_64-linux googleapis-cpp-cmakefiles-0.1.5
|
2 |
x86_64-linux idris-sdl2-0.1.1
|
2 |
x86_64-linux ocaml4.08.1-x509-0.11.2
|
2 |
x86_64-linux ostinato.desktop
|
2 |
x86_64-linux perl5.30.3-Math-BigInt-Lite-0.19
|
2 |
x86_64-linux CNTK-2.7
|
2 |
x86_64-linux python2.7-ECPy-1.2.3
|
2 |
x86_64-linux python3.7-piexif-1.1.3
|
2 |
x86_64-linux python3.7-umap-learn-0.3.10
|
2 |
x86_64-linux python3.8-piexif-1.1.3
|
2 |
x86_64-linux python3.8-umap-learn-0.3.10
|
2 |
x86_64-linux arm-none-eabihf-stage-static-gcc-debug-9.3.0
|
2 |
x86_64-linux ruby2.5.8-pango-3.4.1
|
2 |
x86_64-linux ruby2.7.1-pango-3.4.1
|
2 |
x86_64-linux libtoggl-7.4.231
|
2 |
x86_64-linux bcachefs-tools-2020-04-04
|
1 |
i686-linux beanstalkd-1.12
|
1 |
i686-linux rocksdb-6.10.2
|
1 |
i686-linux clickhouse-20.5.2.7
|
1 |
i686-linux perl5.32.0-Unicode-UTF8-0.62
|
1 |
i686-linux ejabberd-20.03
|
1 |
i686-linux python3.8-python-efl-1.24.0
|
1 |
i686-linux php-calendar-7.3.23
|
1 |
i686-linux python3.8-pycognito-0.1.3
|
1 |
i686-linux grafana-loki-1.6.1
|
1 |
i686-linux gradle-6.6
|
1 |
i686-linux mbuffer-20200505
|
1 |
i686-linux sope-5.0.0
|
1 |
i686-linux VictoriaMetrics-1.40.0
|
1 |
i686-linux yabar-unstable-2018-01-18
|
1 |
x86_64-linux ocaml4.10.0-tls-0.12.4
|
1 |
x86_64-linux ocaml4.10.0-mirage-crypto-pk-0.8.5
|
1 |
Generated by eval-report
das-g
on 26 Oct 2020
c851af868fe / efe4ba95b4e36f3016e3831f0e7586a689cacad7 fix the docker-edge test
NeQuissimus
on 26 Oct 2020
We have our first 20.09 stable evaluation completed: https://hydra.nixos.org/build/129285763. Thus this should be closed.
Fixing broken packages will always be possible throughout the lifetime of the 20.09 release. However, you may need to remove the broken = true; attr on the package.
jonringer
on 27 Oct 2020
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
nixos-discourse
on 1 Nov 2020
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/20-09-release-retrospective/9851/19
nixos-discourse
on 11 Nov 2020
Related issues
lverns
路
3Comments
matthiasbeyer
路
3Comments
teto
路
3Comments
ghost
路
3Comments
yawnt
路
3Comments
Most helpful comment
As an aside, I wish we could opt-in to failed build notification emails from hydra. I didn't know some of my packages were broken :-/