Remove meta.available checks #45727

dezgeg · 2018-08-29T01:16:53Z

Before these meta.available checks spread into Nixpkgs, config.{allowBroken, allowUnfree, allowUnsupportedSystem} only affected the visibility of packages: switching those config options to true just gave access to more packages without affecting the other ones. But with these sort of checks, those options will now affect hashes of packages:

nix-repl> with import ./. { system = "x86_64-darwin"; config.allowUnsupportedSystem = false; }; nix.outPath
"/nix/store/k6vdsvy6zk5ph9blm5dgdyz34dg1rfhx-nix-2.0.4"

nix-repl> with import ./. { system = "x86_64-darwin"; config.allowUnsupportedSystem = true; }; nix.outPath
"/nix/store/27qfxjnxpdflz58ign254afl9nliifj7-nix-2.0.4"

With the old way, if a (say) Darwin user would try to build some package and find it (or its dependencies) marked not supported/broken on Darwin, they could try to build the package with config = { allowUnsupportedSystem = true; allowBroken = true; } (or with the equivalent NIXPKGS_ALLOW_* env vars) to see if it would actually build or gauge how much there is to fix. All this without cloning Nixpkgs or editing any files in it.

With these meta.available checks in, the above can't be done reliably anymore because these checks will now enable some unwanted dependencies. As a practical example, trying the above on any package depending on Nix will always lead to build failure because it will now attempt to build libseccomp for Darwin and fail.

The old behaviour was useful. The new behaviour is insane. Hence remove these meta.available checks to restore what used to work.

ryantm · 2018-08-29T04:33:59Z

cc @oxij

introduction ecd3990
renaming 810c470

oxij · 2018-08-29T14:08:07Z

Thanks for the mention! Let me also mention @Ericson2314, @shlevy, @matthewbauer as common users of the attribute in question (via `git log -p -S meta.available`). 1) Note that `meta.available` wasn't designed for this use in the first place, it was designed for NixOS/nix#1771. In #35906 (comment) I wrote about

Now I'm experimenting with `meta.supported` that only checks the platforms

And `meta.supported` is not in nixpkgs. 2) I agree that the current use of `meta.available` might be problematic for porting to new platforms when you might want to keep packages marked broken while still having everything in the common nixpkgs, but I don't think we should just duplicate meta.platforms of those packages everywhere (i.e. "But encapsulation!" argument). Since there's a demand now, let's just implement `meta.supported`. I propose you to copy the thing in the change to pkgs/tools/filesystems/ceph/generic.nix in this PR to `meta` in make-derivation.nix and then do `s/meta.available/meta.supported/` treewide. That should work. (Also, `x.meta.available or false` must be just `x.meta.available` (same for `supported`) as those attributes should always be available, it's a bug that has to be fixed if it doesn't always work.) 3) So, specifically: - I completely agree with `allowBroken` and "user or Darwin trying to port to RISC-V" arguments, but this would be fixed with `meta.supported`, not by replicating partially evaluated versions of `meta.supported` everywhere. - For `allowUnsupportedSystem` I think you should just add new platform to the package in question, but then mark packages `broken` on said platforms if you so desire. So that use case should be fixed with `meta.supported` too. - `allowUnfree`, too, would be fixed, but I kinda liked the side-effect of the old way: if you didn't have `allowUnfree` set, everything that could be built without unfree deps would be built without them. Arguably, that's not a good feature, though. (And I'm not sure anything actually uses it yet, I think that's unlikely.) Having those things just fail to evaluate is better for debugging.

Ericson2314

Strong no. I've tried to articulate where this should and shouldn't be used, I'm not sure you've even understood my points. I'll try agin

allowUnsupportedSystem should never be used or used to be used.
allowBroken should be used for the purposes of trying to get something to work.

That means if you see something that ought to be build but doesn't, make sure it's marked broken (rather than impossible with meta.platforms). If you want to try building something, make sure it's marked broken or working first rather than using allowUnsupportedSystem. This try-state system allows conveying information which is impossible to convey today.

Packages should only use enableFoo ? !(foo.meta.available or false) for purely optional dependencies that are never needed under any situation.

The libseccomp example is a false example because I believe libseccomp is in fact needed on Linux. If so, just that dependency edge should be modified.

Also, I am suspicious that @dezgeg, who frequently though not always is against support more systems / combinations of features, is also against the abstractions that make supporting more combinations tractable.

Ericson2314 · 2018-08-29T18:51:09Z

Also, this proposal adds back more ? null. null dependencies are an abomination: impossible to debug, easy to forget the assertions. There could well be faults with what we have now, and I am interested in learning more about @oxij's meta.supported, but anything is better than null.

matthewbauer · 2018-08-29T19:07:46Z

I agree on getting rid of meta.available as much as possible. IMO it is much clearer to be more specific when something is 'available' and include the condition directly. libseccomp.meta.available and kexectools.meta.available are two cases where it is legitimate to use and in those cases I think it would be best to replace with any (x: x == stdenv.system) libseccomp.meta.platforms and any (x: x == stdenv.system) kexectools.meta.platforms. This gets more complicated by the fact that there are other things like badPlatforms (which IMO should be replaced with subtractLists platforms.riscv platforms.linux so that platforms is the one true value).

Since there's a demand now, let's just implement meta.supported.

I think that's a bad idea. It doesn't make sense to put these things in meta in the first place. Let's just use any (x: x == stdenv.system) pkg.meta.platforms. meta should avoid calculated values as much as possible.

matthewbauer · 2018-08-29T19:10:06Z

pkgs/development/compilers/ghc/7.10.3.nix

@@ -16,7 +16,7 @@

 , # If enabled, GHC will be built with the GPL-free but slower integer-simple
  # library instead of the faster but GPLed integer-gmp library.
-  enableIntegerSimple ? !(gmp.meta.available or false), gmp
+  enableIntegerSimple ? false, gmp ? null


IMO gmp ? null is confusing to new users. gmp will never be null even if gmp is broken.

matthewbauer · 2018-08-29T19:11:20Z

pkgs/os-specific/linux/systemd/default.nix

@@ -11,8 +11,8 @@
 , hostPlatform
 , buildPackages
 , withSelinux ? false, libselinux
-, withLibseccomp ? libseccomp.meta.available, libseccomp
-, withKexectools ? kexectools.meta.available, kexectools
+, withLibseccomp ? !stdenv.hostPlatform.isRiscV, libseccomp


As mentioned in my comment, I think this can be replaced with any (x: x == stdenv.system) libseccomp.meta.platforms. This avoids the allowBroken issue while also making it more reusable for other platforms.

Ericson2314 · 2018-08-29T19:12:28Z

@matthewbauer you cannot do x == stdenv.system because it isn't always a system string. Use platformMatch instead. https://github.com/NixOS/nixpkgs/blob/master/pkgs/top-level/release-lib.nix#L51-L64 is an example of how to do so.

Ericson2314 · 2018-08-29T19:16:52Z

I'm for the record I'm fine with doing any (lib.meta.platformMatch stdenv.hostPlatform) dependency.meta.platforms. That solves @dezgeg's stated issues, while retaining my and @oxij's principle of encapsulation where optional dependencies can succinctly be used when "roughly available" without the duplication of information of what the "available" conditions are. A fine compromise.

LnL7 · 2018-08-29T20:03:49Z

I do agree that allowUnsupportedSystem influencing optional dependencies is a bit awkward because meta broken/supported isn't clearly separated in nixpkgs.

@Ericson2314 libseccomp isn't required on linux, I have an arm box where I disabled that because because it didn't work. filter-syscalls does have to be disabled in nix.conf if it's not available IIRC.

dezgeg · 2018-08-29T20:19:11Z

No, I do not understand the following point at all:

allowUnsupportedSystem should never be used or used to be used.

Why not? In the pull request message, I have listed the use case where this is useful.

That means if you see something that ought to be build but doesn't, make sure it's marked broken (rather than impossible with meta.platforms).

How do I know a priori whether a package is "ought to build" on a given platform? Let's have a concrete example: lkl in Nixpkgs, or https://github.com/lkl/linux. How am I (or you) going to answer the question of whether the package is ought to build on a) Darwin b) armv7l-linux c) aarch64-linux?

If you want to try building something, make sure it's marked broken or working first rather than using allowUnsupportedSystem.

Yes, trying to build something is the exact thing I want to achieve. But before these meta.available checks, I could do that without editing a single line of code in Nixpkgs. After them, I no longer can. The task has been made harder due to those checks.

The libseccomp example is a false example because I believe libseccomp is in fact needed on Linux. If so, just that dependency edge should be modified.

It used to be a required dependency for Nix on Linux, but it was explicitly made optional because RISC-V doesn't support libseccomp: NixOS/nix@690ac7c. And I personally agree with that tradeoff. It's far better to have Nix working at all on RISC-V even if insecure in a multiuser context than not supporting Nix on RISC-V at all. But obviously, once RISC-V supports libseccomp, Nix on RISC-V should be switched to use it once it is tested that Nix actually works in that configuration, and that the code to enable the less secure configuration just to support Nix on RISC-V is removed from the nix expression for Nix. And thus, if the code reads:

, withLibseccomp ? !stdenv.hostPlatform.isRiscV, libseccomp

I can immediately know that the workaround applies to RISC-V, and to only RISC-V. If I were to replace !stdenv.hostPlatform.isRiscV, with true or just straight away remove the code for withLibseccomp,and test my change on RISC-V and know that my change won't break any other platforms. But if it says:

, withLibseccomp ? libseccomp.meta.available, libseccomp

I cannot know if that workaround can be removed safely (without potentially breaking some other system) or not without digging into the definition of libseccomp.

Also, I am suspicious that @dezgeg, who frequently though not always is against support more systems / combinations of features, is also against the abstractions that make supporting more combinations tractable.

What I want is that Nixpkgs works as consistently as possible even in the rarely used configurations or architectures. Disabling optional stuff to temporarily make things to work should be used as the last resort.

And on a more general level, code is read more often than it is read. When reading code, code which says withLibseccomp ? !stdenv.hostPlatform.isFoo tells me immediately what value withLibseccomp is going to get in which situations. Code which says withLibseccomp ? libseccomp.meta.available forces me to go look into another file for the same answer.

With all that said, I got the impression from the people commenting on this (including me) that code of the form any (x: /* something here */) libseccomp.meta.platforms (or an equivalent helper function) would be either equivalent or better compared to libseccomp.meta.available. Would that work for everyone who commented so far?

oxij · 2018-08-29T21:01:07Z

@Ericson2314

anything is better than `null`

Oops, I missed those while skimmind through the thing. I wholeheartedly agree that no new `null`s should be introduced into package arguments. Those are cancer. @matthewbauer

> Since there's a demand now, let's just implement `meta.supported`. I think that's a bad idea. It doesn't make sense to put these things in meta in the first place. Let's just use ```any (x: x == stdenv.system) pkg.meta.platforms```. ```meta``` should avoid calculated values as much as possible.

It's lazy, though, so I don't think this argument works out. It might even be more efficient to keep it there, since nix does no common expression elimination itself. That needs to be measured, thought, I have no idea if one new thunk in `meta` would cost more than some `n` reevaluations of `any (x: x == stdenv.system) pkg.meta.platforms`. @dezgeg

With all that said, I got the impression from the people commenting on this (including me) that code of the form `any (x: /* something here */) libseccomp.meta.platforms` (or an equivalent helper function) would be either equivalent or better compared to `libseccomp.meta.available`.

I agree. I think that binding that expression to `meta.supported` would be cleaner, but I'm inclined to yield to a helper function like ``` withLibseccomp ? lib.isSupportedOnTheHostPlatform libseccomp ``` (with a better name that eludes me ATM).

…

-- Thinking some more about this, I'm pretty sure that doing the `meta.supported` thing will make memory consumption go up a little, so a helper function is probably a better choice, considering current problems with #38635.

Ericson2314 · 2018-08-29T21:48:21Z

It sounds like we have consensus with the compromise. That's a relief.

But for posterity, let me respond to the points:

, withLibseccomp ? libseccomp.meta.available, libseccomp
I cannot know if that workaround can be removed safely (without potentially breaking some other system) or not without digging into the definition of libseccomp.

Ah, I think this is the core of the misunderstanding. Read this as is "it is always permitted to build without libseccomp, but it is enabled by default on a best-effort basis".

, withLibseccomp ? !stdenv.hostPlatform.isRiscV, libseccomp

This reads as "it is always permitted to build without libseccomp, but it is enabled by default except on RISC-V".

, withLibseccomp ? !stdenv.hostPlatform.isRiscV, libseccomp
}:

asset !stdenv.hostPlatform.isRiscV -> withLibseccomp;

This reads as "libseccomp is required on all but RISC-V, where it is optional but enabled by default."

The differences here are modal, just like https://tools.ietf.org/html/rfc2119. asserts, or better, meta.broken, do MUST and MUST NOT, defaults for withXXX and enableXXX do SHOULD and SHOULD NOT. dependency.meta.available or any (lib.meta.platformMatch stdenv.hostPlatform) dependency.meta.platforms is a better true because it skips obeying the "SHOULD" where it would cause problems.

Ericson2314 · 2018-08-29T21:54:43Z

How do I know a priori whether a package is "ought to build" on a given platform?

Yes, this is matter of taste. The README mentions Ubuntu and Windows, so I'd say lkl ought to work everywhere, though it may be broken on Mac.

Ericson2314 · 2018-08-29T22:06:27Z

Yes, trying to build something is the exact thing I want to achieve. But before these meta.available checks, I could do that without editing a single line of code in Nixpkgs. After them, I no longer can. The task has been made harder due to those checks.

You can only do that assuming rampant duplication where downstream packages constantly guess when their optional dependencies are available. Even with @matthewbauer's plan, then allowedUnsupportedSystems will not save you if the thing in question is a dependency rather than the root derivation: you need to do the 1 step of editing the meta.platform so all the isSupportedOn stuff works. But unlike before, there's one edit per formally broken node, not that + one edit per dependency edge on such node.

Ericson2314 · 2018-08-29T22:22:24Z

pkgs/tools/package-management/nix/default.nix

@@ -6,7 +6,7 @@
 , storeDir ? "/nix/store"
 , stateDir ? "/nix/var"
 , confDir ? "/etc"
-, withLibseccomp ? libseccomp.meta.available, libseccomp
+, withLibseccomp ? stdenv.hostPlatform.isLinux && !stdenv.hostPlatform.isRiscV, libseccomp # RISC-V support in progress https://github.com/seccomp/libseccomp/pull/50


We could do

{ ... , withLibseccomp ? stdenv.hostPlatform.isLinux && libseccomp.meta.available }: # RISC-V support in progress https://github.com/seccomp/libseccomp/pull/50 assert stdenv.hostPlatform.isLinux && !libseccomp.meta.available -> stdenv.hostPlatform.isRiscV; # Useless on other platforms assert withLibseccomp -> stdenv.hostPlatform.isLinux;

This precisely formalizes:

Libseccomp SHOULD be used on Linux where possible. If we are on linux other than RISC-V libseccomp MUST be available, to ensure we only don't use it intentionally, never automatically. If we are not on Linux we MUST NOT try to depend on libseccomp; even if it could somehow be built for us, we wouldn't know how to use it and we wouldn't want to pretend otherwise.

dezgeg · 2018-08-30T16:14:36Z

I cannot know if that workaround can be removed safely (without potentially breaking some other system) or not without digging into the definition of libseccomp.

Ah, I think this is the core of the misunderstanding. Read this as is "it is always permitted to build without libseccomp, but it is enabled by default on a best-effort basis".

No. I repeat: the fact that libseccomp was made optional on Linux is only due to libseccomp not having support for RISC-V yet. It is a workaround. Once libseccomp gains support for RISC-V, the code for the workaround should be dropped entirely, since it is no longer needed. withSeccomp should not be a function parameter to nix at all, it wasn't initially and I don't know why c37b93b added it as a parameter.

@LnL7,

libseccomp isn't required on linux, I have an arm box where I disabled that because because it didn't work.

I suppose by "it doesn't work" you mean Nix builds fail at runtime due to some ancient kernel which lacks support for it? But that doesn't affect building Nix, right? All you need is the runtime configuration switch you mentioned?

dezgeg · 2018-08-30T16:39:18Z

How do I know a priori whether a package is "ought to build" on a given platform?

Yes, this is matter of taste. The README mentions Ubuntu and Windows, so I'd say lkl ought to work everywhere, though it may be broken on Mac.

In other words, you were forced to make a guess. The reality (when I last checked): in Nixpkgs it builds successfully and works on x86_64-linux, aarch64-linux and doesn't build on i686-linux, x86_64-darwinor armv7l-linux. Why should we have a workflow where the developer is forced to answer some question they cannot answer and are forced to guess random things?

As far as I am aware, the rules for changing meta.platforms has been basically: if you find some package failing to build on platform foo and foo is in meta.platforms, then you remove foo from it. If you try compiling a package on a platform foo which is not in meta.platforms and it success (like, maybe upstream has added support for platform foo since the last time someone attempted to build the package for foo), then you add foo to meta.platforms.

Is that not the case? Since when? Where has this been discussed and documented? I certainly don't see anything in https://github.com/NixOS/rfcs.

dezgeg · 2018-08-30T16:56:50Z

Yes, trying to build something is the exact thing I want to achieve. But before these meta.available checks, I could do that without editing a single line of code in Nixpkgs. After them, I no longer can. The task has been made harder due to those checks.

You can only do that assuming rampant duplication where downstream packages constantly guess when their optional dependencies are available. Even with matthewbauer's plan, then allowedUnsupportedSystems will not save you if the thing in question is a dependency rather than the root derivation: you need to do the 1 step of editing the meta.platform so all the isSupportedOn stuff works. But unlike before, there's one edit per formally broken node, not that + one edit per dependency edge on such node.

I do not understand at all. If I find with config.allowWhatever = true that building package foo fails because a dependency libbar also doesn't compile on my platform, it tells me that the first thing I need to do is to fix libbar on my platform. And only if that fails, I can consider investigating whether libbar is optional, or alternatively give up and conclude that foo doesn't work on my platform. Disabling something conditionally on a subset of platforms is something to be done as a last resort, given that it makes Nixpkgs work inconsistently on different platforms. (Of course there are some obvious exceptions like preferring to build a Cocoa UI on Darwin instead of a X11 one)

Ericson2314 · 2018-08-30T20:57:40Z

No. I repeat: the fact that libseccomp was made optional on Linux is only due to libseccomp not having support for RISC-V yet.

@dezgeg It is fine to conceive of libseccomp not as an optional dependency, but required one under exactly those circumstances, as you say. If so, then I agree as one would make the package just as its done in this PR. So I see two different concepts expressed in code, rather than the same concept expressed in two different ways.

Ericson2314 · 2018-08-30T21:03:00Z

In other words, you were forced to make a guess. The reality (when I last checked): in Nixpkgs it builds successfully and works on x86_64-linux, aarch64-linux and doesn't build on i686-linux, x86_64-darwin or armv7l-linux. Why should we have a workflow where the developer is forced to answer some question they cannot answer and are forced to guess random things?

At the risk of being pedantic, When I said about meta.platforms and meta.broken is an arbitrary choice, but not a guess. Fundamentally, I see no reason why the lkl ought not to work on all arches Linux does, leading me to say what I said. I'd then mark those ones were it doesn't work broken. This is inherently subjective, but that is different than an objective with missing information (a guess).

Is that not the case? Since when? Where has this been discussed and documented? I certainly don't see anything in https://github.com/NixOS/rfcs.

I don't think using meta.broken like that is against any policy. But yes, the ramifications relating to meta.available are not spelled out. I rather just go with the compromise which does side-step this.

Ericson2314 · 2018-08-30T21:14:29Z

Disabling something conditionally on a subset of platforms is something to be done as a last resort

Agreed.

If I find with config.allowWhatever = true that building package foo fails because a dependency libbar also doesn't compile on my platform, it tells me that the first thing I need to do is to fix libbar on my platform. And only if that fails, I can consider investigating whether libbar is optional, or alternatively give up and conclude that foo doesn't work on my platform.

I don't think the facts you describe are that different from the current situation. To take your Cocoa UI x11 example, a package that so far only is expected to work on Linux might well make a bunch of such things unconditional. If this is an end application, rather than library, it's probably fairly likely, I think it's only practical to always consider the possibility that the dependency may not be needed. And this risk of "overly needed dependencies" is always there, whether one uses meta.available with config.allowWhatever = true, or manual conditions or @matthewbauer's thing without: it's just simpler to right mandatory than conditional/optional dependencies.

Ericson2314 · 2018-08-30T21:16:11Z

Anyways, the 18.09 fork is soon, so I suppose we better get drafting on the compromise. We can debate the points of things obviated by the compromise after. One of you all want to do it? I have a few too many other last minute things to do.

7c6f434c · 2018-08-30T21:22:10Z

withSeccomp should not be a function parameter to nix at all

Maybe we need to have a separate platform «Linux with userns and seccomp and all the new interfaces like that turned off in the kernel» then? Because it annoyingly still exists in practice.

GrahamcOfBorg · 2018-09-04T03:44:33Z

Success on aarch64-linux (full log)

Attempted: nix, systemd

The following builds were skipped because they don't evaluate on aarch64-linux: ghc

Partial log (click to expand)

to ~/.config/nixpkgs/config.nix.


these paths will be fetched (1.64 MiB download, 8.40 MiB unpacked):
  /nix/store/dpknpcrll5qn6zi01j59zynxkxk7l4i4-nix-2.1
  /nix/store/g16yxlv0f1vk3drvrizhf5iwd4jc29v2-nix-2.1-man
copying path '/nix/store/g16yxlv0f1vk3drvrizhf5iwd4jc29v2-nix-2.1-man' from 'https://cache.nixos.org'...
copying path '/nix/store/dpknpcrll5qn6zi01j59zynxkxk7l4i4-nix-2.1' from 'https://cache.nixos.org'...
/nix/store/dpknpcrll5qn6zi01j59zynxkxk7l4i4-nix-2.1
/nix/store/pq9rcppjfdkrk4jbx6yrrcl30c7dfhfa-systemd-239

GrahamcOfBorg · 2018-09-04T03:45:03Z

Success on x86_64-darwin (full log)

Attempted: ghc, nix

The following builds were skipped because they don't evaluate on x86_64-darwin: systemd

Partial log (click to expand)

copying path '/nix/store/936fwryxrkhdhjq1ic2h95vx24yc8gls-curl-7.59.0' from 'https://cache.nixos.org'...
copying path '/nix/store/7ap80dcgzw4d4wvcrh5is54y0b2fsq93-ghc-8.4.3-doc' from 'https://cache.nixos.org'...
copying path '/nix/store/phlh1mayxzra4jvhx833myyvjbdyyvhw-gmp-6.1.2-dev' from 'https://cache.nixos.org'...
copying path '/nix/store/x4pfd1vp87ykgxxqrcn028hzfp70jkjj-libatomic_ops-7.6.4' from 'https://cache.nixos.org'...
copying path '/nix/store/rw2008dcqvw7pwpv93ia822vj8h6av0k-ghc-8.4.3' from 'https://cache.nixos.org'...
copying path '/nix/store/9k1x12sm6rd2bnhg5d6b9x8rkw58m3g1-boehm-gc-7.6.6' from 'https://cache.nixos.org'...
copying path '/nix/store/kxyg6rxh3w2gk27xmnwii5xgjcahkjjw-libsodium-1.0.16' from 'https://cache.nixos.org'...
copying path '/nix/store/cw6g6ia7q6v5rcih81zfdcjyjbqibisy-nix-2.1' from 'https://cache.nixos.org'...
/nix/store/rw2008dcqvw7pwpv93ia822vj8h6av0k-ghc-8.4.3
/nix/store/cw6g6ia7q6v5rcih81zfdcjyjbqibisy-nix-2.1

GrahamcOfBorg · 2018-09-04T03:46:09Z

Success on x86_64-linux (full log)

Attempted: ghc, nix, systemd

Partial log (click to expand)

  /nix/store/jmah5a1828n48k2m2fhr76hd5xnaba9n-ghc-8.4.3
  /nix/store/qj1rl5rfa46xrdbr1prsn5pcpa6qfwkw-ghc-8.4.3-doc
  /nix/store/yl12ga4svrrq7qmzyxhig2mmrf0wmql6-nix-2.1
copying path '/nix/store/2plv4r5pkgh4p7443ahii1da2386rgzj-nix-2.1-man' from 'https://cache.nixos.org'...
copying path '/nix/store/qj1rl5rfa46xrdbr1prsn5pcpa6qfwkw-ghc-8.4.3-doc' from 'https://cache.nixos.org'...
copying path '/nix/store/yl12ga4svrrq7qmzyxhig2mmrf0wmql6-nix-2.1' from 'https://cache.nixos.org'...
copying path '/nix/store/jmah5a1828n48k2m2fhr76hd5xnaba9n-ghc-8.4.3' from 'https://cache.nixos.org'...
/nix/store/jmah5a1828n48k2m2fhr76hd5xnaba9n-ghc-8.4.3
/nix/store/yl12ga4svrrq7qmzyxhig2mmrf0wmql6-nix-2.1
/nix/store/rx76y57vl69ynnig325pid8jb0466298-systemd-239

oxij · 2018-09-12T13:54:56Z

As of f6b29c69beb2cd60aebf19c0d088e53ae939dc4f pkgs/tools/filesystems/ceph/generic.nix pkgs/development/libraries/wiredtiger/default.nix still use `==` instead of `platformMatch`.

This sort of code breaks config.{allowBroken, allowUnsupportedSystem} = true by making them do unpredictable things.

This reverts commit 79d8353. This sort of code breaks config.{allowBroken, allowUnsupportedSystem} = true by making them do unpredictable things.

This sort of code breaks config.{allowBroken, allowUnsupportedSystem} = true by making them do unpredictable things.

dezgeg · 2018-09-27T14:46:43Z

Good catch, fixed ceph and wiredtiger (they hadn't matched my sed expression).

GrahamcOfBorg · 2018-09-27T14:59:33Z

Success on x86_64-darwin (full log)

Attempted: ghc, nix

The following builds were skipped because they don't evaluate on x86_64-darwin: systemd

Partial log (click to expand)

  { nixpkgs.config.allowUnsupportedSystem = true; }
in configuration.nix to override this.

b) For `nix-env`, `nix-build`, `nix-shell` or any other Nix command you can add
  { allowUnsupportedSystem = true; }
to ~/.config/nixpkgs/config.nix.


/nix/store/lr9s1fwapid7fn6bysh091wvr8sgzcma-ghc-8.4.3
/nix/store/k7h38gc48fjkwcmyk5j0mvnprafv346y-nix-2.1.2

GrahamcOfBorg · 2018-09-27T14:59:43Z

Success on aarch64-linux (full log)

Attempted: nix, systemd

The following builds were skipped because they don't evaluate on aarch64-linux: ghc

Partial log (click to expand)

copying path '/nix/store/0i80air3rcm5b1964wr5ymcnd8cbqk60-busybox-1.29.3' from 'https://cache.nixos.org'...
copying path '/nix/store/1zymllml853wicjnhrj642x36c26ahxh-nix-2.1.2-man' from 'https://cache.nixos.org'...
copying path '/nix/store/xyxz2yfvwn7niv9crpch1zmcrqqmympk-brotli-1.0.6-lib' from 'https://cache.nixos.org'...
copying path '/nix/store/mzrzm5ddaz8bfrq2i6dcy6z2dqpjcagp-libatomic_ops-7.6.4' from 'https://cache.nixos.org'...
copying path '/nix/store/nxxlrwqgjf9qlw50q0sy2j56nvjrzzsj-aws-sdk-cpp-1.5.17' from 'https://cache.nixos.org'...
copying path '/nix/store/f3s7vls5bw7h2h0bkby4bgkakzxaqbfv-curl-7.59.0' from 'https://cache.nixos.org'...
copying path '/nix/store/d9qd0i32s39mz1ax2nwayr7y8pmc526x-boehm-gc-7.6.6' from 'https://cache.nixos.org'...
copying path '/nix/store/3vp7cpjpq49jc1g1663gsgd1nfp44v18-nix-2.1.2' from 'https://cache.nixos.org'...
/nix/store/3vp7cpjpq49jc1g1663gsgd1nfp44v18-nix-2.1.2
/nix/store/kcdgk5ww9h7amv7vk4bmsl2qlhv33z2r-systemd-239

GrahamcOfBorg · 2018-09-27T15:00:22Z

Success on x86_64-linux (full log)

Attempted: ghc, nix, systemd

Partial log (click to expand)

copying path '/nix/store/55gcsw2yii9r3c3pl25wxcn0fpl60ani-ghc-8.4.3-doc' from 'https://cache.nixos.org'...
copying path '/nix/store/nxmpp08ap5mslgnfzfdyfb1v18q9i5gk-gmp-6.1.2-dev' from 'https://cache.nixos.org'...
copying path '/nix/store/d0vhkrqdshsaliaqqzmi0d2wjqcwf9x2-libatomic_ops-7.6.4' from 'https://cache.nixos.org'...
copying path '/nix/store/sx4pjh0nh0acqszld5rrxwbjnzl3djrg-ghc-8.4.3' from 'https://cache.nixos.org'...
copying path '/nix/store/6b39xw9zjm0wyjvyn43417h95w9vf9ii-boehm-gc-7.6.6' from 'https://cache.nixos.org'...
copying path '/nix/store/q9xck41cd5prw22j19mvk191r8ah1n79-nix-2.1.2-man' from 'https://cache.nixos.org'...
copying path '/nix/store/mdxx15pdf5afga4mpvk4j59fs4xhvxq0-nix-2.1.2' from 'https://cache.nixos.org'...
/nix/store/sx4pjh0nh0acqszld5rrxwbjnzl3djrg-ghc-8.4.3
/nix/store/mdxx15pdf5afga4mpvk4j59fs4xhvxq0-nix-2.1.2
/nix/store/755srn9lwkidg9k9w6mvwd7806r8wbfz-systemd-239

dezgeg · 2018-09-28T12:01:04Z

I got the impression this solution is satisfactory to all for now, it can be improved later further if necessary.

dezgeg added this to the 18.09 milestone Aug 29, 2018

dezgeg requested a review from edolstra August 29, 2018 01:16

dezgeg requested review from basvandijk, peti and ryantm as code owners August 29, 2018 01:16

GrahamcOfBorg added 6.topic: haskell 6.topic: nixos 8.has: module (update) labels Aug 29, 2018

Ericson2314 requested changes Aug 29, 2018

View reviewed changes

Ericson2314 requested a review from matthewbauer August 29, 2018 18:47

matthewbauer reviewed Aug 29, 2018

View reviewed changes

matthewbauer requested changes Aug 29, 2018

View reviewed changes

Ericson2314 reviewed Aug 29, 2018

View reviewed changes

dezgeg force-pushed the meta-available-excise branch from dc71ac3 to f6b29c6 Compare September 4, 2018 03:33

GrahamcOfBorg added 10.rebuild-darwin: 1-10 10.rebuild-linux: 1-10 labels Sep 4, 2018

matthewbauer approved these changes Sep 11, 2018

View reviewed changes

dezgeg added 6 commits September 27, 2018 00:18

systemd: Replace meta.available checks

c4c6df7

This sort of code breaks config.{allowBroken, allowUnsupportedSystem} = true by making them do unpredictable things.

nix: Replace meta.available checks

d159baa

This sort of code breaks config.{allowBroken, allowUnsupportedSystem} = true by making them do unpredictable things.

apparmor: Replace meta.available checks

d38a04b

This sort of code breaks config.{allowBroken, allowUnsupportedSystem} = true by making them do unpredictable things.

treewide: Replace meta.available checks in shouldUsePackages copypasta

672034b

This reverts commit 79d8353. This sort of code breaks config.{allowBroken, allowUnsupportedSystem} = true by making them do unpredictable things.

ghc: Replace meta.available checks for enableIntegerSimple

2cbde84

This sort of code breaks config.{allowBroken, allowUnsupportedSystem} = true by making them do unpredictable things.

nixos/kexec: Replace meta.available checks

2666fb0

This sort of code breaks config.{allowBroken, allowUnsupportedSystem} = true by making them do unpredictable things.

dezgeg force-pushed the meta-available-excise branch from f6b29c6 to 2666fb0 Compare September 27, 2018 14:45

GrahamcOfBorg added 10.rebuild-darwin: 0 10.rebuild-linux: 0 and removed 10.rebuild-darwin: 1-10 10.rebuild-linux: 1-10 labels Sep 27, 2018

dezgeg merged commit 599c4df into NixOS:master Sep 28, 2018

matthewbauer mentioned this pull request Nov 11, 2018

R: Remove jdk dependency on aarch32/64 #50179

Merged

9 tasks

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Remove meta.available checks #45727

Remove meta.available checks #45727

dezgeg commented Aug 29, 2018

ryantm commented Aug 29, 2018

oxij commented Aug 29, 2018 via email

Ericson2314 left a comment •

edited

Ericson2314 commented Aug 29, 2018

matthewbauer commented Aug 29, 2018

matthewbauer Aug 29, 2018 •

edited

matthewbauer Aug 29, 2018 •

edited

Ericson2314 commented Aug 29, 2018 •

edited

Ericson2314 commented Aug 29, 2018 •

edited

LnL7 commented Aug 29, 2018

dezgeg commented Aug 29, 2018

oxij commented Aug 29, 2018 via email

Ericson2314 commented Aug 29, 2018 •

edited

Ericson2314 commented Aug 29, 2018

Ericson2314 commented Aug 29, 2018 •

edited

Ericson2314 Aug 29, 2018 •

edited

dezgeg commented Aug 30, 2018

dezgeg commented Aug 30, 2018

dezgeg commented Aug 30, 2018 •

edited

Ericson2314 commented Aug 30, 2018

Ericson2314 commented Aug 30, 2018

Ericson2314 commented Aug 30, 2018

Ericson2314 commented Aug 30, 2018

7c6f434c commented Aug 30, 2018

GrahamcOfBorg commented Sep 4, 2018

GrahamcOfBorg commented Sep 4, 2018

GrahamcOfBorg commented Sep 4, 2018

oxij commented Sep 12, 2018 via email

dezgeg commented Sep 27, 2018

GrahamcOfBorg commented Sep 27, 2018

GrahamcOfBorg commented Sep 27, 2018

GrahamcOfBorg commented Sep 27, 2018

dezgeg commented Sep 28, 2018

Remove meta.available checks #45727

Remove meta.available checks #45727

Conversation

dezgeg commented Aug 29, 2018

ryantm commented Aug 29, 2018

oxij commented Aug 29, 2018 via email

Ericson2314 left a comment • edited

Choose a reason for hiding this comment

Ericson2314 commented Aug 29, 2018

matthewbauer commented Aug 29, 2018

matthewbauer Aug 29, 2018 • edited

Choose a reason for hiding this comment

matthewbauer Aug 29, 2018 • edited

Choose a reason for hiding this comment

Ericson2314 commented Aug 29, 2018 • edited

Ericson2314 commented Aug 29, 2018 • edited

LnL7 commented Aug 29, 2018

dezgeg commented Aug 29, 2018

oxij commented Aug 29, 2018 via email

Ericson2314 commented Aug 29, 2018 • edited

Ericson2314 commented Aug 29, 2018

Ericson2314 commented Aug 29, 2018 • edited

Ericson2314 Aug 29, 2018 • edited

Choose a reason for hiding this comment

dezgeg commented Aug 30, 2018

dezgeg commented Aug 30, 2018

dezgeg commented Aug 30, 2018 • edited

Ericson2314 commented Aug 30, 2018

Ericson2314 commented Aug 30, 2018

Ericson2314 commented Aug 30, 2018

Ericson2314 commented Aug 30, 2018

7c6f434c commented Aug 30, 2018

GrahamcOfBorg commented Sep 4, 2018

GrahamcOfBorg commented Sep 4, 2018

GrahamcOfBorg commented Sep 4, 2018

oxij commented Sep 12, 2018 via email

dezgeg commented Sep 27, 2018

GrahamcOfBorg commented Sep 27, 2018

GrahamcOfBorg commented Sep 27, 2018

GrahamcOfBorg commented Sep 27, 2018

dezgeg commented Sep 28, 2018

Ericson2314 left a comment •

edited

matthewbauer Aug 29, 2018 •

edited

matthewbauer Aug 29, 2018 •

edited

Ericson2314 commented Aug 29, 2018 •

edited

Ericson2314 commented Aug 29, 2018 •

edited

Ericson2314 commented Aug 29, 2018 •

edited

Ericson2314 commented Aug 29, 2018 •

edited

Ericson2314 Aug 29, 2018 •

edited

dezgeg commented Aug 30, 2018 •

edited