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
Staging next #89388
Staging next #89388
Conversation
Addresses #71803: Kernel options are not merged as described, especially the "optional" aspects. The error silences legitimate warnings.
With the fix in kernel configuration merging, some kernel configuration items marked as mandatory now correctly trigger an error when unused (while they previously were unused).
I hate the thing too even though I made it, and rather just get rid of it. But we can't do that yet. In the meantime, this brings us more inline with autoconf and will make it slightly easier for me to write a pkg-config wrapper, which we need.
This is achieved by patching qtbase `qmake/generators/makefile.cpp` to unconditionally add the missing `-I${includedir}`. The include path is otherwise conditioned on whether it is already available or not. Since there is no unified set of system include paths in nix this cause problems as reported in #52457.
*-wrapper; Switch from `infixSalt` to `suffixSalt`
This reverts commit 237ef30. Looks like we're trying to bump binutils again?
bintools: only add macos flags when targeting macOS
The compiler does not need it anymore, has not needed it for many years iirc. This just goes in and pollutes the environment overriding the users GOPATH and causing grief. Go even warns about it itself, without vs with this commit: ```sh ~> go env GOPATH /home/manny/go ~> nix-shell -p go ~> go env GOPATH warning: GOPATH set to GOROOT (/nix/store/gvw1mfpdrk7i82884yhxf9lf5j3c12zm-go-1.14.1/share/go) has no effect /nix/store/gvw1mfpdrk7i82884yhxf9lf5j3c12zm-go-1.14.1/share/go ~> exit ~> nix-shell -I nixpkgs=cloned/NixOS/nixpkgs -p go ~> go env GOPATH /home/manny/go ~> exit ```
There are two ways to build a package for aarch32 on an aarch64 machine: either by cross compiling as normal, or by adding armv6l/armv7l to extraPlatforms and doing a non-cross compile. Previously, NSS failed to build with both methods: when using extraPlatforms, things failed because NSS includes an armv8-specific file (presumably based on the result of uname); when cross compiling, NSS's build system expects to receive an architecture name of arm (not armv6l or whatever), so was failing to include some arch-specific code and failed with a linker error. This commit fixes those things by a) always passing the arch, even when not cross-compiling, and b) special-casing aarch32 to always pass in an arch of arm.
nss: fix building for aarch32 on aarch64
* format with nixpkgs-fmt * reorder the attributes * use pkg-config instead of the pkgconfig alias * optional → optionals * remove top-level `with lib;`
* remove glibcLocales now that glibc contains C.UTF-8 * remove libintl, that should be in by default or something * update homepage * add gnome team to maintainers * remove the temporary libregress closer its creation
and add comments
stdenv-darwin: now with 50% less LLVM!
Could we not deliver staging-next as is, and go for the next cycle with the fix? It means cross is broken temporarily but it would save another rebuild. edit: |
For me personally, a few channel updates with broken cross certainly won't cause issues, but I don't know how it's generally in the community. |
mplayer now fails with
|
That sounds like some pkg-config as well
|
I was still looking at autogen---the version we had already contained the fix, yet |
Ah, so https://savannah.gnu.org/support/?109050 and |
See comments for details. Patch can be removed whend version is bumped.
Great, cross-compiles for me now. I hurried Hydra to build the commit. Unless you object I'll just aim directly for staging with that autogen update. |
I'm not sure what's the frequency of staging-next being merged into master, but it does mean that the mobile nixos jobset will fail for that whole duration. Not ideal, though I know being tier 3 it's okay if it fails. My main concern with accepting regressions in master for cross-compilation is that they sometimes end up hard to bisect. Having multiple staging-next rounds to bisect through is way harder than only one. (Though for this particular round, the point is likely moot, I'll test with the added fix soon.) |
@samueldr what other packages are broken? I dunno what portion of the breakage is caused by me, but I do feel bad when people bisect an error which I can tell at a glance (like the |
To be clear, |
@Ericson2314 that was more of a general sentiment. This round there was a difficulties bisecting because of breakage you already fixed "internal" to that round. Though that's not really much. I'm more worried about a situation where, let's say no one catches issues for a month or two, it can become harder to untangle. (Still haven't validated whether there are issues elsewhere, will be doing it soon, once what's burning my CPU time is over.) |
This was very similar to the Mesa issues fixed in 62e6d73: the user-written code is looking up an unprefixed binutils program. [I think we should have a way in Meson of specifying a program prefix in the cross / native files, as a fallback for any program that isn't explicitly specified. This could both be availible for user written rules, and help with the default rules.] Fixes NixOS/mobile-nixos#161
Otherwise we'd be delaying this staging-next cycle noticeably.
Looking into it, there are issues still, but they are leafy, and less problematic, I guess they can be handled on then next cycle.
Both issues seem to be related to the pkg-config change. I think the change may require some good documentation work as I fear many upstream packages are doing maybe the wrong thing. I say documentation, I mean it could be upstream pkg-config documentation explaining it, it even would be better, but the goal is to have some solid piece of evidence to point to when providing upstream patches. |
We could make page like https://github.com/jtojnar/cmake-snips#please-fix-your-cmake-builds for cross-compilation. |
In that case it specified $doc output but didn't even create it. I expect it's better to do it this way instead of creating it as an empty directory. (Only the failed builds get rebuilt by this commit.)
With this |
Builds of all kernels except default 5.4 are broken by this staging-next iteration: #88946 (review) |
I re-checked that pkgsCross.aarch64-multiplatform.autogen builds. #89388 (comment)
In particular, this fixes ISO evaluation.
Some of the options didn't have correct kernel version constraints, others had been removed or made optional unnecessarily in #84032.
Next staging iteration: #90058 |
Motivation for this change
Things done
sandbox
innix.conf
on non-NixOS linux)nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
./result/bin/
)nix path-info -S
before and after)