jiebi/CodeConvo huggingface dataset:
Code change:
I'm thinking of bringing this line back: and getting rid of nixos/modules/misc/extra- Does anyone have objections? I fully buy the ability to pass arguments in the module system using , but if it doesn't work (and breaks in a horrible way) for the most common use case ( in imports), that seems bad and the cost of restoring the old way seems pretty low. Anyone have objections? I can make the change if nobody objects. Ideally, I'd like it in 15.06, since it's getting in the way of some work I'm trying to squeeze into 15.06. cc
IMO our only choices are to do this or to set as a prerequisite (perhaps enforced using ) that points there. No strong preference either way.
Yeah, this is probably the best solution.
Cool! Do any of you know of VM tests that would suitably make sure I don't break anything too obvious by making that change? I'd obviously rather not make the change and then discover a week from now that I broke someone's key use case :smile: I'll be making the change this evening at this rate.
Any thoughts on having set using scopedImport? That way stays NixOS-independent. But not a huge difference IMO.
I don't see how adding back could break anything.
Famous last words! :grinning: But I agree, as long as it evaluates at all it's almost certainly fine.
That sounds more complicated than the one-liner suggested by

Related discussion:
text: evalModules) and the less declarative the module set is. */ evalModules = { modules , prefix ? [] <ins> , # This should only be used for special arguments that need to be evaluated # when resolving module structure (like in imports). For everything else, # there's _module.args. specialArgs ? {} </ins> , # This would be remove in the future, Prefer _module.args option instead. args ? {} , # This would be remove in the future, Prefer _module.check option instead.
Code change:
I'm thinking of bringing this line back: and getting rid of nixos/modules/misc/extra- Does anyone have objections? I fully buy the ability to pass arguments in the module system using , but if it doesn't work (and breaks in a horrible way) for the most common use case ( in imports), that seems bad and the cost of restoring the old way seems pretty low. Anyone have objections? I can make the change if nobody objects. Ideally, I'd like it in 15.06, since it's getting in the way of some work I'm trying to squeeze into 15.06. cc
IMO our only choices are to do this or to set as a prerequisite (perhaps enforced using ) that points there. No strong preference either way.
Yeah, this is probably the best solution.
Cool! Do any of you know of VM tests that would suitably make sure I don't break anything too obvious by making that change? I'd obviously rather not make the change and then discover a week from now that I broke someone's key use case :smile: I'll be making the change this evening at this rate.
Any thoughts on having set using scopedImport? That way stays NixOS-independent. But not a huge difference IMO.
I don't see how adding back could break anything.
Famous last words! :grinning: But I agree, as long as it evaluates at all it's almost certainly fine.
That sounds more complicated than the one-liner suggested by

Related discussion:
text: }; }; <del> closed = closeModules (modules ++ [ internalModule ]) { inherit config options; lib = import ./.; }; </del> <ins> closed = closeModules (modules ++ [ internalModule ]) (specialArgs // { inherit config options; lib = import ./.; }); </ins> # Note: the list of modules is reversed to maintain backward # compatibility with the old module system.  Not sure if this is
Code change:
I'm thinking of bringing this line back: and getting rid of nixos/modules/misc/extra- Does anyone have objections? I fully buy the ability to pass arguments in the module system using , but if it doesn't work (and breaks in a horrible way) for the most common use case ( in imports), that seems bad and the cost of restoring the old way seems pretty low. Anyone have objections? I can make the change if nobody objects. Ideally, I'd like it in 15.06, since it's getting in the way of some work I'm trying to squeeze into 15.06. cc
IMO our only choices are to do this or to set as a prerequisite (perhaps enforced using ) that points there. No strong preference either way.
Yeah, this is probably the best solution.
Cool! Do any of you know of VM tests that would suitably make sure I don't break anything too obvious by making that change? I'd obviously rather not make the change and then discover a week from now that I broke someone's key use case :smile: I'll be making the change this evening at this rate.
Any thoughts on having set using scopedImport? That way stays NixOS-independent. But not a huge difference IMO.
I don't see how adding back could break anything.
Famous last words! :grinning: But I agree, as long as it evaluates at all it's almost certainly fine.
That sounds more complicated than the one-liner suggested by

Related discussion:
text: config = removeAttrs m ["key" "_file" "require" "imports"]; }; <del> applyIfFunction = f: arg@{ config, options, lib }: if isFunction f then </del> <ins> applyIfFunction = f: arg@{ config, options, lib, ... }: if isFunction f then </ins> let # Module arguments are resolved in a strict manner when attribute set # deconstruction is used.  As the arguments are now defined with the
Code change:
I'm thinking of bringing this line back: and getting rid of nixos/modules/misc/extra- Does anyone have objections? I fully buy the ability to pass arguments in the module system using , but if it doesn't work (and breaks in a horrible way) for the most common use case ( in imports), that seems bad and the cost of restoring the old way seems pretty low. Anyone have objections? I can make the change if nobody objects. Ideally, I'd like it in 15.06, since it's getting in the way of some work I'm trying to squeeze into 15.06. cc
IMO our only choices are to do this or to set as a prerequisite (perhaps enforced using ) that points there. No strong preference either way.
Yeah, this is probably the best solution.
Cool! Do any of you know of VM tests that would suitably make sure I don't break anything too obvious by making that change? I'd obviously rather not make the change and then discover a week from now that I broke someone's key use case :smile: I'll be making the change this evening at this rate.
Any thoughts on having set using scopedImport? That way stays NixOS-independent. But not a huge difference IMO.
I don't see how adding back could break anything.
Famous last words! :grinning: But I agree, as long as it evaluates at all it's almost certainly fine.
That sounds more complicated than the one-liner suggested by

Related discussion:
text: inherit prefix check; modules = modules ++ extraModules ++ baseModules ++ [ pkgsModule ]; args = extraArgs; <ins> specialArgs = { modulesPath = ../modules; }; </ins> }) config options; # These are the extra arguments passed to every module.  In
Code change:
I'm thinking of bringing this line back: and getting rid of nixos/modules/misc/extra- Does anyone have objections? I fully buy the ability to pass arguments in the module system using , but if it doesn't work (and breaks in a horrible way) for the most common use case ( in imports), that seems bad and the cost of restoring the old way seems pretty low. Anyone have objections? I can make the change if nobody objects. Ideally, I'd like it in 15.06, since it's getting in the way of some work I'm trying to squeeze into 15.06. cc
IMO our only choices are to do this or to set as a prerequisite (perhaps enforced using ) that points there. No strong preference either way.
Yeah, this is probably the best solution.
Cool! Do any of you know of VM tests that would suitably make sure I don't break anything too obvious by making that change? I'd obviously rather not make the change and then discover a week from now that I broke someone's key use case :smile: I'll be making the change this evening at this rate.
Any thoughts on having set using scopedImport? That way stays NixOS-independent. But not a huge difference IMO.
I don't see how adding back could break anything.
Famous last words! :grinning: But I agree, as long as it evaluates at all it's almost certainly fine.
That sounds more complicated than the one-liner suggested by

Related discussion:
text: { _module.args = { <del> modulesPath = ../.; </del> pkgs_i686 = import ../../lib/nixpkgs.nix { system = "i686-linux"; config.allowUnfree = true;
Code change:
Describe the bug The description of is: Path to the unix socket file on which to accept FastCGI requests. This option is read-only and managed by NixOS. So i can't set it. But how can i figure out how the socket path is now? Please add an example to the description! To Reproduce Steps to reproduce the behavior: option desciption Expected behavior Useful description. Metadata same in 19.09 and 20.03 Maintainer information:
The point of the option is that you don't need to find out, just reference it. That being said I agree with your issue and it would be helpful to set an example
The point of the option is that you don't need to find out, just reference it. Sure, that works in but i have that path explicitely in my webserver config which is next to the content, e.g. . For reference: The path is actually as i set it before: So i can just remove the option from my .

Related discussion:
text: Path to the unix socket file on which to accept FastCGI requests. <note><para>This option is read-only and managed by NixOS.</para></note> ''; <ins> example = "${runtimeDir}/<name>.sock"; </ins> }; listen = mkOption {
Code change:
Describe the bug Trying to build a combined TexLive that includes Biber (e.g. ) results in failure on darwin. This seems to be the relevant error: To Reproduce Steps to reproduce the behavior: , where Expected behavior The build should succeed. Additional context The build succeeds in the example above if is omitted. Other schemes that include Biber, like , fail with the same error. Metadata system: host os: multi-user?: sandbox: version: channels(matt): nixpkgs: Maintainer information:

Related discussion:
text: install_name_tool -change "$oldPath" "$newPath" "$out/bin/biblex" install_name_tool -change "$oldPath" "$newPath" "$out/bin/bibparse" install_name_tool -change "$oldPath" "$newPath" "$out/bin/dumpnames" <del> install_name_tool -change "$oldPath" "$newPath" "$out/${perl.libPrefix}/${perl.version}/darwin-2level/auto/Text/BibTeX/BibTeX.bundle" </del> <ins> install_name_tool -change "$oldPath" "$newPath" "$out/${perl.libPrefix}/${perl.version}/darwin"*"-2level/auto/Text/BibTeX/BibTeX.bundle" </ins> ''; meta = { description = "Interface to read and parse BibTeX files";
Code change:
Project description A modification of the Mesa Vulkan overlay. Including GUI improvements, temperature reporting, and logging capabilities. Metadata homepage URL: source URL: license: gpl3 platforms: linux
I tried myself at this and have a working package now for NUR based on But I haven't yet figured out how to create a 32 and 64-bit version. Depending on the game both are necessary. To just get a 32bit version I currently just use: instead of just
It might make sense to just build the 32bit and 64bit packages separately and then merge them together in a wrapper.
okay I did something similar, though not with a wrapper which is probably a little hackish I am not sure: but this allows me now to use mangohud with 64 and 32 bit applications
That seems like a reasonable solution, although it is a little bit hackish. I'm running into a similar issue with , and it's not really clear what the best approach is. recommended keeping the two builds separate for vkBasalt. However, to ensure we can install both builds we would have to do extra patching, and use separate names for the 32bit and 64bit build. Users might also expect to have both builds in one package like on other distros. I'm leaning towards something like this or like what I've done in my .
was just released but that changed quite a few things around. instead of using two different binaries it now uses  to decide where the 32/64bit libaries are, but it seems to me that this always expands to 'lib' on NixOS This is what I have so far. Having to ignore collisions is also not really that cool. Well having a running 0.4.1 version would be nice enough, just thought I write about this somewhere
The commit in question:
I marked this as stale due to inactivity. &rarr;
Still important to me.

Related discussion:
text: <ins> { stdenv, pkgs, lib , libXNVCtrl }: let mangohud_64 = pkgs.callPackage ./default.nix { inherit libXNVCtrl; }; mangohud_32 = pkgs.pkgsi686Linux.callPackage ./default.nix { inherit libXNVCtrl; }; in pkgs.buildEnv rec { name = "mangohud-${mangohud_64.version}"; paths = [ mangohud_32 ] ++ lib.optionals stdenv.is64bit [ mangohud_64 ]; meta = mangohud_64.meta; } </ins>
Code change:
Project description A modification of the Mesa Vulkan overlay. Including GUI improvements, temperature reporting, and logging capabilities. Metadata homepage URL: source URL: license: gpl3 platforms: linux
I tried myself at this and have a working package now for NUR based on But I haven't yet figured out how to create a 32 and 64-bit version. Depending on the game both are necessary. To just get a 32bit version I currently just use: instead of just
It might make sense to just build the 32bit and 64bit packages separately and then merge them together in a wrapper.
okay I did something similar, though not with a wrapper which is probably a little hackish I am not sure: but this allows me now to use mangohud with 64 and 32 bit applications
That seems like a reasonable solution, although it is a little bit hackish. I'm running into a similar issue with , and it's not really clear what the best approach is. recommended keeping the two builds separate for vkBasalt. However, to ensure we can install both builds we would have to do extra patching, and use separate names for the 32bit and 64bit build. Users might also expect to have both builds in one package like on other distros. I'm leaning towards something like this or like what I've done in my .
was just released but that changed quite a few things around. instead of using two different binaries it now uses  to decide where the 32/64bit libaries are, but it seems to me that this always expands to 'lib' on NixOS This is what I have so far. Having to ignore collisions is also not really that cool. Well having a running 0.4.1 version would be nice enough, just thought I write about this somewhere
The commit in question:
I marked this as stale due to inactivity. &rarr;
Still important to me.

Related discussion:
text: mandoc = callPackage ../tools/misc/mandoc { }; <ins> mangohud = callPackage ../tools/graphics/mangohud/combined.nix { libXNVCtrl = linuxPackages.nvidia_x11.settings.libXNVCtrl; }; </ins> manix = callPackage ../tools/nix/manix { inherit (darwin.apple_sdk.frameworks) Security; };
Code change:
Describe the bug Systemd ships dbus system services (in ), which are used for dbus system activation (see ) This includes some of the units shipped with systemd itself: We currently don't have the proper tooling ready to make these available in NixOS. Also, we shouldn't blindly enable all. For example, we might not want to enable `share/dbus-1/system-services/org.freedesktop.resolve1.service, if resolved is enabled. Originally discovered in , but it always hasn't worked, so it's not a regression. Notify maintainers
I wonder if that's why every program I have that uses dBus in some way or another, spits from time to time:
Can you tell me which programs those are?
Sure, from , prints: I'm using as my display manager and I'm using as my desktop environment but I don't use . Not sure if that matters.. EDIT: Currently I can't identify another program that spits this message, although IIRC I saw it coming out of other programs as well. This could be an upstream issue as well.
It does seem that somehow picks up the systemd configuration; though I do not fully understand how it's just missing the when is enabled
Ah apparently all applications are loaded into dbus by default? Not sure how I feel about that ... so the only reason why resolved wasn't working is because we didnt included unit file in Easy fix! All the other services already work!
It seems we do, but we shouldn't do that. If we try to not restart , changes in there don't get propagated. It should just use nscd like everything else. can you file a PR removing this?
reopened, as got reverted.
I've found another example for: prints:
Another symptom is:
I'm not sure if that is a symptom of what I am solving here. I recall recently running into the same issue and I think it's a problem with how we set up user environment in certain desktop managers.
Should I open a distinct issue then?

Related discussion:
text: systemd.additionalUpstreamSystemUnits = [ "systemd-resolved.service" <ins> "dbus-org.freedesktop.resolve1.service" </ins> ]; systemd.services.systemd-resolved = {
Code change:
Describe the bug Systemd ships dbus system services (in ), which are used for dbus system activation (see ) This includes some of the units shipped with systemd itself: We currently don't have the proper tooling ready to make these available in NixOS. Also, we shouldn't blindly enable all. For example, we might not want to enable `share/dbus-1/system-services/org.freedesktop.resolve1.service, if resolved is enabled. Originally discovered in , but it always hasn't worked, so it's not a regression. Notify maintainers
I wonder if that's why every program I have that uses dBus in some way or another, spits from time to time:
Can you tell me which programs those are?
Sure, from , prints: I'm using as my display manager and I'm using as my desktop environment but I don't use . Not sure if that matters.. EDIT: Currently I can't identify another program that spits this message, although IIRC I saw it coming out of other programs as well. This could be an upstream issue as well.
It does seem that somehow picks up the systemd configuration; though I do not fully understand how it's just missing the when is enabled
Ah apparently all applications are loaded into dbus by default? Not sure how I feel about that ... so the only reason why resolved wasn't working is because we didnt included unit file in Easy fix! All the other services already work!
It seems we do, but we shouldn't do that. If we try to not restart , changes in there don't get propagated. It should just use nscd like everything else. can you file a PR removing this?
reopened, as got reverted.
I've found another example for: prints:
Another symptom is:
I'm not sure if that is a symptom of what I am solving here. I recall recently running into the same issue and I think it's a problem with how we set up user environment in certain desktop managers.
Should I open a distinct issue then?

Related discussion:
text: users.users.systemd-network.group = "systemd-network"; systemd.additionalUpstreamSystemUnits = [ <del> "systemd-networkd.service" "systemd-networkd-wait-online.service" </del> <ins> "systemd-networkd-wait-online.service" "systemd-networkd.service" "systemd-networkd.socket" </ins> ]; systemd.network.units = mapAttrs' (n: v: nameValuePair "${n}.netdev" (netdevToUnit n v)) cfg.netdevs // mapAttrs' (n: v: nameValuePair "${n}.network" (networkToUnit n v)) cfg.networks; <ins> # systemd-networkd is socket-activated by kernel netlink route change # messages. It is important to have systemd buffer those on behalf of # networkd. systemd.sockets.systemd-networkd.wantedBy = [ "sockets.target" ]; </ins> systemd.services.systemd-networkd = { wantedBy = [ "multi-user.target" ]; <ins> aliases = [ "dbus-org.freedesktop.network1.service" ]; </ins> restartTriggers = map (x: x.source) (attrValues unitFiles); # prevent race condition with interface renaming (#39069) requires = [ "systemd-udev-settle.service" ];
Code change:
Describe the bug Systemd ships dbus system services (in ), which are used for dbus system activation (see ) This includes some of the units shipped with systemd itself: We currently don't have the proper tooling ready to make these available in NixOS. Also, we shouldn't blindly enable all. For example, we might not want to enable `share/dbus-1/system-services/org.freedesktop.resolve1.service, if resolved is enabled. Originally discovered in , but it always hasn't worked, so it's not a regression. Notify maintainers
I wonder if that's why every program I have that uses dBus in some way or another, spits from time to time:
Can you tell me which programs those are?
Sure, from , prints: I'm using as my display manager and I'm using as my desktop environment but I don't use . Not sure if that matters.. EDIT: Currently I can't identify another program that spits this message, although IIRC I saw it coming out of other programs as well. This could be an upstream issue as well.
It does seem that somehow picks up the systemd configuration; though I do not fully understand how it's just missing the when is enabled
Ah apparently all applications are loaded into dbus by default? Not sure how I feel about that ... so the only reason why resolved wasn't working is because we didnt included unit file in Easy fix! All the other services already work!
It seems we do, but we shouldn't do that. If we try to not restart , changes in there don't get propagated. It should just use nscd like everything else. can you file a PR removing this?
reopened, as got reverted.
I've found another example for: prints:
Another symptom is:
I'm not sure if that is a symptom of what I am solving here. I recall recently running into the same issue and I think it's a problem with how we set up user environment in certain desktop managers.
Should I open a distinct issue then?

Related discussion:
text: systemd.services.systemd-resolved = { wantedBy = [ "multi-user.target" ]; <ins> aliases = [ "dbus-org.freedesktop.resolve1.service" ]; </ins> restartTriggers = [ config.environment.etc."systemd/resolved.conf".source ]; };
Code change:
Describe the bug Systemd ships dbus system services (in ), which are used for dbus system activation (see ) This includes some of the units shipped with systemd itself: We currently don't have the proper tooling ready to make these available in NixOS. Also, we shouldn't blindly enable all. For example, we might not want to enable `share/dbus-1/system-services/org.freedesktop.resolve1.service, if resolved is enabled. Originally discovered in , but it always hasn't worked, so it's not a regression. Notify maintainers
I wonder if that's why every program I have that uses dBus in some way or another, spits from time to time:
Can you tell me which programs those are?
Sure, from , prints: I'm using as my display manager and I'm using as my desktop environment but I don't use . Not sure if that matters.. EDIT: Currently I can't identify another program that spits this message, although IIRC I saw it coming out of other programs as well. This could be an upstream issue as well.
It does seem that somehow picks up the systemd configuration; though I do not fully understand how it's just missing the when is enabled
Ah apparently all applications are loaded into dbus by default? Not sure how I feel about that ... so the only reason why resolved wasn't working is because we didnt included unit file in Easy fix! All the other services already work!
It seems we do, but we shouldn't do that. If we try to not restart , changes in there don't get propagated. It should just use nscd like everything else. can you file a PR removing this?
reopened, as got reverted.
I've found another example for: prints:
Another symptom is:
I'm not sure if that is a symptom of what I am solving here. I recall recently running into the same issue and I think it's a problem with how we set up user environment in certain desktop managers.
Should I open a distinct issue then?

Related discussion:
text: systemd.services.systemd-timesyncd = { wantedBy = [ "sysinit.target" ]; <ins> aliases = [ "dbus-org.freedesktop.timesync1.service" ]; </ins> restartTriggers = [ config.environment.etc."systemd/timesyncd.conf".source ]; };