text:
Freeform modules

Motivation for this change
This implement freeform modules, which are like a combination between types.submodule and types.attrsOf: The options declared with the submodule are type-checked, while the others are combined using a freeform type. This has been a desired feature in multiple occasions now:

This will simplify NixOS/rfcs#42 drastically, making the process of declaring options corresponding to settings values very conventional.
Type checking for nixpkgs' config argument, as previously attempted in https://github.com/NixOS/nixpkgs/pull/57123 and https://github.com/NixOS/nixpkgs/pull/80582, will now be possible in a sane way.

How it looks like (updated for latest version) (evaluate with nix-instantiate --eval --strict example.nix -A config)
with import ./lib; evalModules {
  modules = [{
    options.settings = mkOption {
      default = {};
      type = with types; submodule {
        # All values that don't have an associated option have to be of this type
        freeformType = attrsOf int;

        options.port = mkOption {
          type = port;
          default = 80;
          description = "The port to use.";
        };
      };
    };

    # Works, even though foo isn't declared as an option
    config.settings.foo = 10;

    # error: The option value `settings.port' in `example.nix' is not of type
    # `16 bit unsigned integer; between 0 and 65535 (both inclusive)'.
    #config.settings.port = "not-a-port";

    ## Overrides default value
    config.settings.port = 8080;
  }];
}

Ping @roberth @Ma27 @rycee @Profpatsch @oxij
TODO

[x] Write tests
[x] Potentially separate orthogonal changes into a separate PR
[x] Write docs
[x] Check how this affects performance -> The current implementation is slower than it could be when many freeform values are defined, but since the number of them per module evaluation is expected to be rather low, I'll leave it at this for now.

I now separated the orthogonal changes into https://github.com/NixOS/nixpkgs/pull/82751

I don't think attrValueType is necessary if you merge in one go at the root of the submodule and then recursiveUpdate the unstructured values back into config.
This puts less burden on the types and, if we don't hardcode recursiveUpdate, it allows the module author to keep the unstructured attributes separate if desired.

@roberth I don't think this would work without big changes, because currently it's not known upfront which values are unstructured and which aren't, and this could get complicated with nested submodules and attrsOf and such.

@Infinisil mergeModules could return the option values and unstructured attrs separately. Doing so should also fix the laziness problem caused by generating fake option names for the unstructured definitions.
Quote for when the commit is lost:

TODO: This leads to infinite recursion in NixOS if it's always turned on, so some use cases won't be supported anymore because of unstructured attrs. Figure out what they are.

One feature I suspect may be lost due to this change is the ability to check for the existence of option declarations before defining them, which I think will be important when modules move into flakes and need to adapt a bit at runtime to their now variable environment.
I've used this to optionally define NixOps deployment keys in a NixOS-compatible module.
I'll make sure we have a test for this laziness property.

@roberth I think I see what you mean, this might be possible, I'll give it a try soon. Implementation would be a bit like: Do a recursive mergeModules' for declared options first. After that, determine which definitions haven't been matched with a declaration, and merge those with a single unstructured type. Then combine the results of the mergeModules' and the unstructured merge with something like recursiveUpdate (it will need to insert the fake option declarations). I don't think it needs to be configurable though, as it will essentially only allow unstructured values under option sets, which makes a lot of sense, and is also the behavior of the current implementation.

@roberth Done that! Commits need some cleanup, and other things are still left to do, but now the code is looking much nicer. I also did some very sweet cleanups related to this. Also I'm now not generating fake options anymore: Only .config will now contain unstructured values, .options doesn't, which should then also not get in the way of what you mentioned in https://github.com/NixOS/nixpkgs/pull/82802.
Unfortunately without attrValueType, a specific error message is significantly worse: With something like
{
  config._module.unstructuredType = attrsOf int;
  options.a.b = mkOption {};
  config.a.c = "foo";
}

it now throws
The option value `a' in `example.nix' is not of type `signed integer'.

and if you change it to
{ config.a = 0; }

you get (as expected)
error: The option path `a' is an attribute set of options,
  but it is defined to not be an attribute set in `example.nix'.
  Did you define its value at the correct and complete path?

Instead of the previous (code now in https://github.com/Infinisil/nixpkgs/tree/partially-typed-v2-old)
The option `a.c' defined in `example.nix' does not exist
  and the unstructured type `signed integer' of `a' does not support attribute sets.

I could get back the original error message if I add attrValueType again, but I'm not sure if it's worth it. Maybe that's better left for the future.

error message

This can probably be improved quite a bit by rethrowing the error with an extra message.
"The module at ${prefix} allows undeclared definitions to be mixed with known options, but a definition did not satisfy the type for undeclared definitions: ${caughtMsg}. This may also be the result of mistyping an otherwise known option."

@roberth Hm it does work with builtins.tryEval and a deepSeq on the unstructuredType.merge ..., but that's not very nice. I'd have to do some changes to how types throw errors to make it work without tryEval.

I think I'll have to get the attrValueType thing back after all. Not only does it allow for much better error messages in some cases, but after doing a performance check, I also found that the whole definition coercion thing is really slow due to the many list operations.

@roberth I think let's not do this attrValueType thing after all, for now. The current implementation here works well and has clean and simple code, the only problem is that it can be a bit slow if there are many unstructured attributes, but that will be a rare occurence. If this does becomes a problem in the future, it can still be changed then, though ideally this would also bring some module system improvements along with it so attrValueType can be implemented nicely (which it currently can't).
So I think the only thing left to do here is to write some docs. Also I think the naming is a bit off, it's not "partially typed modules", because everything is still type checked, there's just a fallback type now for undeclared options. "unstructured attributes" is also a bit unfitting. Maybe the feature could be called "Fallback-typing" instead.

I have now written some initial docs for this feature. Once the docs are finalized and reviewed, I think this is ready to be merged.

The docs read like you're describing a change, like you would in an rfc or a commit message

Yeah that's what I noticed too, will definitely try to improve on that

Another use would be to use packages as submodules,like what I would like to do in https://github.com/NixOS/nixpkgs/pull/89943

@roberth What do you think would be a better term for this feature? Maybe one of:

A fallback option type
Declarationless definitions
Optionless definitions
Freeform definitions
Freeform configuration
Freeform modules

The last one sounds pretty good imo

Freeform modules
The last one sounds pretty good imo

:100:

I'll wait until https://github.com/NixOS/nixpkgs/pull/75584 is merged so I can extend the "Options for Program Settings" section with this feature.

Now updated to term this feature freeform modules instead and revised the documentation to be less RFC-y. Also fixed a bug with freeform modules. Once the documentation is reviewed, I think this PR is ready for merging.
New section under "Writing modules":

New section under the settings option docs (introduced in #75584):

@roberth Thanks for all the suggestions, I implemented them now. After some thought, I think there's no reason not to introduce some syntactic sugar for freeformType, so I did that now. Was fairly easy to add even.

The freeform type doesn't seem to be visible in the generated option docs. Could we generate a line for an "option" like "${somePrefix}.*" there?
I think we've discussed this in an earlier pr, but I couldn't find it.
We may want to use a freeform "option" rather than a freeform type for this reason, because that provides an opportunity to provide the description string and an example.

@roberth With https://github.com/NixOS/nixpkgs/pull/82743/commits/2d45a62899d47c109a0b8ce4ca9d33265b8a1a37 the freeform type is shown as the submodules type. E.g. with a config like
{ lib, ... }: {
  options.fofofofo = lib.mkOption {
    type = lib.types.submodule {
      freeformType = lib.types.attrsOf lib.types.str;
      options.babababa = lib.mkOption {};
    };
  };
  config = {
    documentation.nixos.includeAllModules = true;
    fileSystems."/".device = "ntest";
    boot.loader.grub.device = "nodev";
  };
}

Building with nix-build '<nixpkgs/nixos>' --arg configuration ./config.nix -A config.system.build.manual.manualHTML gives

Awesome! Thanks for all the reviewing and merging @roberth!

This broke nix-darwin, bisected to https://github.com/NixOS/nixpkgs/commit/fd75dc876586bde8cdb683a6952a41132e8db166
$ darwin-rebuild build --dry-run
building the system configuration...
error: The option `nixpkgs.localSystem' defined in `<unknown-file>' does not exist.
(use '--show-trace' to show detailed location information)

full trace
$ darwin-rebuild build --dry-run --show-trace
building the system configuration...
error: while evaluating the attribute 'activationScript' of the derivation 'darwin-system-20.09.git.78922ca+darwin3.47fe6db' at /Users/marsam/code/nix-config/darwin/modules/system/default.nix:74:7:
while evaluating the attribute 'activationScripts.script.text' at undefined position:
while evaluating 'g' at /Users/marsam/code/nix-config/nixpkgs/lib/attrsets.nix:276:19, called from undefined position:
while evaluating anonymous function at /Users/marsam/code/nix-config/nixpkgs/lib/modules.nix:98:72, called from /Users/marsam/code/nix-config/nixpkgs/lib/attrsets.nix:279:20:
while evaluating the attribute 'value' at /Users/marsam/code/nix-config/nixpkgs/lib/modules.nix:450:9:
while evaluating the option `system.activationScripts.script.text':
while evaluating the attribute 'mergedValue' at /Users/marsam/code/nix-config/nixpkgs/lib/modules.nix:482:5:
while evaluating the attribute 'values' at /Users/marsam/code/nix-config/nixpkgs/lib/modules.nix:476:9:
while evaluating the attribute 'values' at /Users/marsam/code/nix-config/nixpkgs/lib/modules.nix:575:7:
while evaluating anonymous function at /Users/marsam/code/nix-config/nixpkgs/lib/modules.nix:462:28, called from /Users/marsam/code/nix-config/nixpkgs/lib/modules.nix:462:17:
while evaluating definitions from `/Users/marsam/code/nix-config/darwin/modules/system/activation-scripts.nix':
while evaluating 'dischargeProperties' at /Users/marsam/code/nix-config/nixpkgs/lib/modules.nix:534:25, called from /Users/marsam/code/nix-config/nixpkgs/lib/modules.nix:463:137:
while evaluating the attribute 'value' at /Users/marsam/code/nix-config/nixpkgs/lib/modules.nix:327:44:
while evaluating the attribute 'activationScripts.applications.text' at undefined position:
while evaluating 'g' at /Users/marsam/code/nix-config/nixpkgs/lib/attrsets.nix:276:19, called from undefined position:
while evaluating anonymous function at /Users/marsam/code/nix-config/nixpkgs/lib/modules.nix:98:72, called from /Users/marsam/code/nix-config/nixpkgs/lib/attrsets.nix:279:20:
while evaluating the attribute 'value' at /Users/marsam/code/nix-config/nixpkgs/lib/modules.nix:450:9:
while evaluating the option `system.activationScripts.applications.text':
while evaluating the attribute 'mergedValue' at /Users/marsam/code/nix-config/nixpkgs/lib/modules.nix:482:5:
while evaluating the attribute 'values' at /Users/marsam/code/nix-config/nixpkgs/lib/modules.nix:476:9:
while evaluating the attribute 'values' at /Users/marsam/code/nix-config/nixpkgs/lib/modules.nix:575:7:
while evaluating anonymous function at /Users/marsam/code/nix-config/nixpkgs/lib/modules.nix:462:28, called from /Users/marsam/code/nix-config/nixpkgs/lib/modules.nix:462:17:
while evaluating definitions from `/Users/marsam/code/nix-config/darwin/modules/system/applications.nix':
while evaluating 'dischargeProperties' at /Users/marsam/code/nix-config/nixpkgs/lib/modules.nix:534:25, called from /Users/marsam/code/nix-config/nixpkgs/lib/modules.nix:463:137:
while evaluating the attribute 'value' at /Users/marsam/code/nix-config/nixpkgs/lib/modules.nix:327:44:
while evaluating the attribute 'passAsFile' of the derivation 'system-applications' at /Users/marsam/code/nix-config/nixpkgs/pkgs/build-support/trivial-builders.nix:7:7:
while evaluating the attribute 'buildCommand' of the derivation 'darwin-manpages' at /Users/marsam/code/nix-config/nixpkgs/pkgs/build-support/trivial-builders.nix:7:7:
while evaluating the attribute 'buildCommand' of the derivation 'manual-olinkdb' at /Users/marsam/code/nix-config/nixpkgs/pkgs/build-support/trivial-builders.nix:7:7:
while evaluating the attribute 'buildCommand' of the derivation 'darwin-manual-combined' at /Users/marsam/code/nix-config/nixpkgs/pkgs/build-support/trivial-builders.nix:7:7:
while evaluating the attribute 'buildCommand' of the derivation 'generated-docbook' at /Users/marsam/code/nix-config/nixpkgs/pkgs/build-support/trivial-builders.nix:7:7:
while evaluating the attribute 'buildCommand' of the derivation 'options-db.xml' at /Users/marsam/code/nix-config/nixpkgs/pkgs/build-support/trivial-builders.nix:7:7:
while evaluating 'flip' at /Users/marsam/code/nix-config/nixpkgs/lib/trivial.nix:138:16, called from /Users/marsam/code/nix-config/darwin/doc/manual/default.nix:48:21:
while evaluating 'optionAttrSetToDocList'' at /Users/marsam/code/nix-config/nixpkgs/lib/options.nix:140:37, called from /Users/marsam/code/nix-config/darwin/doc/manual/default.nix:9:72:
while evaluating 'collect' at /Users/marsam/code/nix-config/nixpkgs/lib/attrsets.nix:178:19, called from /Users/marsam/code/nix-config/nixpkgs/lib/options.nix:162:67:
while evaluating 'isType' at /Users/marsam/code/nix-config/nixpkgs/lib/types.nix:14:18, called from /Users/marsam/code/nix-config/nixpkgs/lib/attrsets.nix:179:8:
while evaluating 'evalModules' at /Users/marsam/code/nix-config/nixpkgs/lib/modules.nix:21:17, called from /Users/marsam/code/nix-config/darwin/modules/documentation/default.nix:19:24:
The option `nixpkgs.localSystem' defined in `<unknown-file>' does not exist.

The only place nix-darwin uses nixpkgs.localSystem is in the manual https://github.com/LnL7/nix-darwin/blob/47fe6db9c9cd22c4ba57df3281f98f454880bea7/modules/documentation/default.nix#L20.
I'm not familiar with modules internals, so I'm appreciate any hint to for a proper fix
cc: @LnL7

@marsam I can't find a declaration for localSystem in nix-darwin, so the error message seems to be correct. Grepping only reveals the usage site you linked but no declaration.
The file analogous to Nixpkgs where I would expect it to be defined is https://github.com/LnL7/nix-darwin/blob/master/modules/nix/nixpkgs.nix
I don't think nix-darwin needs that option, so I've created a PR for the simple solution https://github.com/LnL7/nix-darwin/pull/216
NixOS-specific rant:
If a module needs access to cross-compilation info, it should generally be taken from pkgs directly; either pkgs.stdenv.hostPlatform, which is the what the eventual machine runs or if you really do need to care about where the config is built: pkgs.stdenv.buildPlatform. Generally you care about pkgs.stdenv.hostPlatform which can not be assumed to be equivalent to config.nixpkgs.localSystem because of config.nixpkgs.crossSystem. local and cross only make sense in the context of nixos-rebuild --target-host, which uses incompatible terminology...

TL;DR: I assume we'll revert this merge until the issues get resolved?
This merge also broke Hydra's evaluation of trunk-combined.  It's some kind of interaction with other conditions and I haven't managed to reproduce it locally so far though @samueldr did (maybe this just triggered some Nix bug)... but the merge commit of this PR (6d0a85fe52) won't evaluate on Hydra whereas the parent commit succeeded.
The message is
error: [json.exception.type_error.302] type must be string, but is null

and it seems likely that it comes from evaluating nixos/release-combined.nix -A nixos.manual.x86_64-linux.  Some context was on IRC yesterday.

@roberth Nice detective work! Both the nix-darwin and the hydra failures seem to originate from https://github.com/NixOS/nixpkgs/commit/fd75dc876586bde8cdb683a6952a41132e8db166, which apparently checks options stricter, but I'm not quite sure yet why (I'll investigate this a bit more)
Fyi, the hydra failure originates from this command now failing:
$ nix-instantiate nixos/tests/boot.nix -A biosCdrom
error: The option `virtualisation.qemu.consoles' defined in `/home/infinisil/src/nixpkgs/nixos/modules/testing/test-instrumentation.nix' does not exist.

Which is indeed fixed by @roberth's PR. Similar for nix-darwin.

TL;DR: I assume we'll revert this merge until the issues get resolved?

Shouldn't be necessary.
This change is merely exposing undeclared options that weren't discovered by the previous implementation.
I've merged a fix for the one that was blocking release-small. trunk-combined should also be fixed now, because it doesn't seem to suffer from other errors of the same time. We'll see when evaluation is done.
(I'm wondering, shouldn't TL;DR be a summary?)

Ah figured it out: The previous implementation only checked option existence for config paths that are evaluated, while the new one checks all of them unconditionally. Here's an example that illustrates this:
(import <nixpkgs/lib>).evalModules {
  modules = [({ lib, ... }: {
    options.root = lib.mkOption {};
    options.foo.bar = lib.mkOption {};

    config.root = "root";
    config.foo.qux = "qux";
  })];
}

Evaluating with nix-instantiate --eval -A config.root previously worked because config.foo wasn't evaluated, so it would still fail with nix-instantiate --eval -A config.foo. With the new implementation, both commands fail. I think this change in behavior is justified, because there can be other reasons an option doesn't exist other than the config path not being evaluated (e.g. misspellings). In fact I think this change might even fix https://github.com/NixOS/nixpkgs/issues/36590.
It looks like previously this was (ab)used to make evaluation not fail: https://github.com/NixOS/nixpkgs/blob/aeffd67cec5b76e327f244c7464a4254113836cc/nixos/modules/testing/test-instrumentation.nix#L11-L18

Thanks, that was really fast.

(I'm wondering, shouldn't TL;DR be a summary?)

I did consider that as something like summary/conclusion, explaining the details below, though I agree I typically see it used in a bit different way.

@Infinisil I think @LnL7 has a good point here https://github.com/LnL7/nix-darwin/pull/216#issuecomment-674966068 that this is an api change. Even if the old api is undocumented and untested, it may have an important role in modular code bases. Do you think it's feasible to warn about the old behavior or to emulate it?
If only warning about it is feasible, we can recommend to extract the option into a separate file, which may be a good idea.

I don't think trying to emulate the old behavior is a good idea, because from what we've seen already, that behavior was very prone to mistakes (https://github.com/NixOS/nixpkgs/issues/36590 and https://github.com/LnL7/nix-darwin/pull/216). While https://github.com/NixOS/nixpkgs/pull/95584 wasn't a mistake per se, it still relied on a hack to make it work.
I think it would be a good idea to mention this change in behavior though, probably in the breaking changes section in the release notes.

There doesn't seem to be any way to define typing for an optional setting, I was looking to set  default = unset in some way, since some configuration handle null and "not set" differently.

@dali99 Indeed, that's something that could be improved in the future. See also https://github.com/NixOS/nixpkgs/pull/63553 which is related.

authors: Infinisil dali99 marsam pasqui23 roberth vcunat


text:
Revert "luaPackages.luv: 1.30.0-0 -> 1.34.1-1"

This reverts commit eaa47284113cda19a037b7fcbaa892ddb596b813.
With 81461cff5f540c92e5030f62b89ee7b64e85c6df luv also needs to be
downgraded until luarocks can be updated to 3.3.1 again.
Fixes #82727

Motivation for this change
Things done

[x] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[x] NixOS
[x] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

On the luv issue, as we have no proper fix really (the current fix is just as complicated as the current one), I am fine with this. I have not understood yet if the issue on darwin was random or systematic (i.e., if it could be fixed by trying several times).

For reference the darwin build worked fine with luarocks-3.3.1 + luv-1.34.1-1 (even without your changes). So once #80528 is resolved we just have to make sure to update both.

source: gharchive/pull-request

repo: NixOS/nixpkgs

license: MIT

license_type: permissive

license_source: github-api


text:
pyspinel: fix python3 build

Motivation for this change
Update to reference an upstream fix to build on python >=3.3
Things done

[ ] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[ ] NixOS
[x] macOS
[x] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[x] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[x] Determined the impact on package closure size (by running nix path-info -S before and after)
[x] Ensured that relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

sorry for all the round about trips.
To comply with CONTRIBUTING.md please have the commit message name be of the format
<pkg-name>: <subject-line>

for more examples, please look at https://github.com/NixOS/nixpkgs/blob/master/.github/CONTRIBUTING.md#submitting-changes
in your case, the commit message should be:
python3Packages.pyspinel: fix build

authors: jonringer siriobalmelli


text:
nixos/networkd: update options

Motivation for this change
To fix missing option DNSDefaultRoute= (see #91761) and other missing options.
Things done
I have not tested all options that I touched.

[ ] Tested using NixOps
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[ ] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[ ] Fits CONTRIBUTING.md.

I will update the PR following this comment.

This needs another rebase.

This needs another rebase.

Done
This is the second time I rebased my PR on master after more recent PRs than mine were merged. What guides the order in which PRs are merged?

Thanks!

This is the second time I rebased my PR on master after more recent PRs than mine were merged. What guides the order in which PRs are merged?

There's no specific order, but this PR is quite big, which is why it's harder to review.

Networking-Tests are looking good.
/nix/store/4y8k9isgglvhycvq59kg50hx62rw08kn-vm-test-run-Bond-Networking-Networkd
/nix/store/0kmcb3mwlm63hjkbd50h075d61ncqf0i-vm-test-run-Bridge-Networking-Networkd
/nix/store/dcz18v4qz82sx9ynr3wyqimzrmaigpgg-vm-test-run-OneInterfaceDHCP-Networking-Networkd
/nix/store/1g9p0kgpd8nzbv6kqkkcq08nh8hmvmxi-vm-test-run-SimpleDHCP-Networking-Networkd
/nix/store/3014l21l3qrg01s3x33ys08fgjqrs9lw-vm-test-run-Link-Networking-Networkd
/nix/store/jllmqcvalzn1imsb6x0r57dfcdw2v7cz-vm-test-run-Loopback-Networking-Networkd
/nix/store/431izfl3mb82crr6kaw143ky0r04c9yl-vm-test-run-MACVLAN-Networking-Networkd
/nix/store/p7vj2zfcl228a9p5ri27ycrdm1yix6v9-vm-test-run-Privacy-Networking-Networkd
/nix/store/fs1rk6x92h83gfm1f8pm4ps8158g17ph-vm-test-run-routes-Networking-Networkd
/nix/store/wvh4cha8ssx3ypplwqp75wf1phiy46yx-vm-test-run-Sit-Networking-Networkd
/nix/store/blbh606jdzsbgdadbavj8nl0ic00c4d0-vm-test-run-Static-Networking-Networkd
/nix/store/mgv2b09h658glqn8lgz2s3akxdwzf7d7-vm-test-run-Virtual-Networking-Networkd
/nix/store/8kfj6r2kh6ab2w5g6ix304fr21zlw2vz-vm-test-run-vlan-Networking-Networkd

I tried reviewing this, but it's really hard to do.
e9d13d3 added some commented-out checks due to Nix' <= 2.2 integer size, and 70407f0 commented them back in. Could this be squashed together, so we only add the checks in a single commit?

As much as I could try, each of these 2 commits do one logical thing and one thing only, as described by the commit messages

e9d13d3: update options for systemd 245. That commit synchronizes the code with the man page of networkd and, for homogeneity with the rest of the code, keeps avoiding the use of assertRange with 64bits integers.
70407f0: use assertRange with 64bits integers. This commit takes into account this comment. Perhaps it would better fit as a separate PR after this one would have been merged. Since the PR is about cleaning up the networkd module, I included this commit here.

I apologize if my commit messages were not clear enough.

Also, e9d13d3 does a bit too much at once. For example, it removes OriginalName. Is this intended?

Again, that commit synchronizes the code with the man page of networkd. The best way to review that I would suggest is to read the man page. For the specifics of OriginalName, refer to man systemd.link. I also try to double check by contacting the author here, without success. However, you kind of confirmed it yourself here. To facilitate our work, let's discuss specific code issues/questions with the review feature of Github.

Could you revise the commits, and make it these changes easier to review? Maybe something like this also deserves a separate commit.

I do not think it is beneficial because the commit does one clear logical thing. If you disagree, please describe what you mean by "these changes" because, as you may have noted, this is not the only thing I removed in this commit e9d13d3.

Thanks again for your patience! I'll try to react quicker on further updates.

Thank you as well for reviewing this.

Could we move on with this PR?

I gave this another close look, and while it is pretty hard to review due to the amount of changes, this seems to be fine, and should make things more readable and understandable in the longer run.
Thanks for the work you put in this, and your patience with me :-)

authors: datafoo flokli mweinelt


text:
jack2: update from b5bceb to 460063

An especially important commit that this includes is https://github.com/jackaudio/jack2/commit/05216197b491d64036733a2d3be511456c1f65cd which changes the API to match jack1 and the official JACK specification.

I tested this. Travis failure is due to a network failure.

@andrewrk this does look like a nice improvement, but personally I'd rather wait for the next release. Does it fix any particular issue for you at the moment?
@wkennington why did you upgrade jack2 to 460063d8d from the v1.9.10 release (you didn't provide any reason in your commit message)? Do we need to have a separate unstable version of jack2 in addition to the stable release, or do we really need to use git master as the default?

@andrewrk this does look like a nice improvement, but personally I'd rather wait for the next release. Does it fix any particular issue for you at the moment?

Yes. This commit modifies the project I am working on to be compliant against jack1 and the official JACK specification. However it causes my project to fail to build from source when compiling against jack2Full. This nixpkgs update allows me to compile my project against jack1, jack2, and be compliant with the spec, at the same time.
Furthermore, the previous version of the package was not an official JACK release so I see no reason to prefer one arbitrary SHA1 over another.

@andrewrk ah, so if we added an expression for jack2-git, that would be OK for your development work (or if you override it locally). I'd be happy with that, but I'm also curious to hear why we're not using the release at the moment.

ah, so if we added an expression for jack2-git, that would be OK for your development work (or if you override it locally)

It's not so bad working from my nixpkgs fork for now. But I'm also collaborating with people from other distros whose package managers have updated to include this fix. For example, debian: https://packages.debian.org/source/sid/jackd2

@goibhniu I usually only use git snapshots if the build is fubar for one of
the releases or there is no release at all. I don't remember now what the
issue was but there was something wrong with the stable version at the time.
On Thu, Aug 27, 2015, 01:11 Andrew Kelley notifications@github.com wrote:

ah, so if we added an expression for jack2-git, that would be OK for your
development work (or if you override it locally)
It's not so bad working from my nixpkgs fork for now. But I'm also
collaborating with people from other distros whose package managers have
updated to include this fix. For example, debian:
https://packages.debian.org/source/sid/jackd2
—
Reply to this email directly or view it on GitHub
https://github.com/NixOS/nixpkgs/pull/9467#issuecomment-135335582.

@wkennington thanks. If nobody objects, I'd like to try to get the released version working again and use that as the default and then we could also add jack2-git for @andrewrk and others, since jack2 stable releases seem to only happen every year or two. I'll add a separate ticket for it but if you want to have something sooner @andrewrk, I'd be happy to merge a PR with a separate expression for jack2-git.

authors: andrewrk cillianderoiste wkennington


text:
[20.09] orangefs: 2.9.7 -> 2.9.8, fix build

Motivation for this change
backport #98525
ZHF: #97479
(cherry picked from commit aa25c6576611ebab7d7448fa30edad9eb1c1a066)
Things done

[x] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[x] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[x] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

@GrahamcOfBorg test orangefs

tests passed


text:
gitit: Remove staticDir and templatesDir

as these cannot be overridden if specified here.

My attempt to fix #9863. I don't know whether this is a step in the right direction or not.
Ping to all haskellers I can find, because I have no clue who is responsible for the service file
CC: @gebner @gridaphobe @jb55 @khumba @psibi @ttuegel

(Disclaimer, I don't know about gitit.)  I see that there are config
options defined for those, and that the options are used in the
generated config file and the systemd service, but strangely, they're
hard-coded.  It conflicts if you try to set it without your patch,
right?  If so, looks fine to me, but I'd recommend setting default
attributes for staticDir and templatesDir to what they were
previously fixed to.

@khumba Good idea!

As the author of the module I would like to have these options available, which I'm using in a private module. For nixpkgs, it was commit https://github.com/NixOS/nixpkgs/commit/99750d89dd962cc7011b02e487ed1a38c7842524 that essentially made them useless.
@khumba that would require evaluation of the haskellPackages set.
I would recommend setting them null by default and changing the type to nullOr. Also checking for null in the config inclusion.

@edwtjo Sorry I do not understand your comment. Shall I set these options to null by default?
What's funny: As far as I can see, the path for the static and template dir is hard coded to the store itself in the service definition. And there is no way to override a service, is there? So this package is rather useless as-is.

@matthiasbeyer yes that is what I meant, but also modify configFile. Anyway these alterations will just be ugly hacks, let's avoid those on second thought.

And there is no way to override a service, is there? So this package is rather useless as-is.

I'm not exactly sure what you mean but no 99750d89dd962cc7011b02e487ed1a38c7842524 was not a very good idea. So since @edolstra don't want the computational and storage overhead with the module; The only correct way to move forward is to remove gitit.nix from the module list, reverting 99750d89dd962cc7011b02e487ed1a38c7842524 and instead requiring it to be manually added into your configuration.nix. Which was done in 122d5e497e6df55f4b2e5c353bb2224b79cfd7b0 and aeba3eabcdbfa6308d9af27b2a70e7864ec4d3e3

authors: edwtjo khumba matthiasbeyer


text:
🛑 GotHub gothub.frontendfriendly.xyz is down

In 66b3a3c, GotHub gothub.frontendfriendly.xyz (https://gothub.frontendfriendly.xyz) was down:

HTTP code: 0
Response time: 0 ms

Resolved: GotHub gothub.frontendfriendly.xyz is back up in 0cb0ddf after 10 minutes.

source: gharchive/issue

repo: NoPlagiarism/services-personal-upptime


text:
🛑 AnonymousOverflow overflow.lunar.icu is down

In 3f86182, AnonymousOverflow overflow.lunar.icu (https://overflow.lunar.icu) was down:

HTTP code: 0
Response time: 0 ms

Resolved: AnonymousOverflow overflow.lunar.icu is back up in 39c7a71 after 10 minutes.


text:
🛑 rimgo rimgo.lunar.icu is down

In 595caf0, rimgo rimgo.lunar.icu (https://rimgo.lunar.icu) was down:

HTTP code: 0
Response time: 0 ms

Resolved: rimgo rimgo.lunar.icu is back up in 3765936 after 7 minutes.


text:
Add Knockback component(s)

Similar to DealsDamage and TakesDamage.
Knockback and KnockbackAffected.

For now, we just configure the entity configs to have knockback behavior.
Knockback components may be nice for a knockback state in the future, but has low priority for now.
Could also help with #41


text:
Merge pull request #1 from NobyDa/master

修正误杀

merge NobyDa

pr拉反了小兄弟

pr拉反了小兄
发现了, 有点难受

authors: NobyDa ZhipengRen

repo: NobyDa/ND-AD