jiebi/CodeConvo huggingface dataset:
Change:
{ _module.args = { <del> modulesPath = ../.; </del> pkgs_i686 = import ../../lib/nixpkgs.nix { system = "i686-linux"; config.allowUnfree = true;

Discussion:
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
Change:
gsl poppler imagemagick libwpg librevenge libvisio libcdr libexif potrace hicolor-icon-theme <ins> librsvg # for loading icons </ins> python2Env perlPackages.perl ];

Discussion:
Describe the bug After installing inkscape either in the user or system profile, no icons are found. When opening dialogs such as "Fill and stroke" or "Layers" the program crashes. I've confirmed this on two of my machines. To Reproduce Steps to reproduce the behavior: inkscape that all icons display incorrectly to Object -Fill and Stroke crash Expected behavior Inkscape should have the full set of icons and dialogs should be accessible. Screenshots ! Additional Context <details<summaryConsole log</summary</detailsMetadata system: host os: multi-user?: sandbox: version: channels(root): channels(riley): nixpkgs:
I think you can easily fix this issue by installing an icon theme to your system.
I believe these icons are part of Inkscape. Possibly issue with gdk-pixbuf loaders – though, I cannot reproduce it within plain xterm session. What desktop environment are you running? Does adding to Inkscape’s help?
Sorry, I should have mentioned - I already tried the following overlay for inkscape after reading the gdk-pixbuf issue and related ones. Unfortunately it didn't seem to change anything after rebuilding and compiling. One of my computers is running sway (launched via startx) and the other i3 + sddm.
Maybe does not work because of :
That worked! I to the overlay and all the icons show up, and dialogs work. I tried looking up docs on but I couldn't find much about it, what does it do exactly?
:confused: I thought the issue with strictDeps only touched gobject-introspection
IIRC, it might also affect hook’s not being picked up correctly. Does the following work with enabled?
Yes, that worked! Would the best workaround for now be to add those inputs to the derivation?
Change:
]; patchFlags = "-p0"; <ins> nativeBuildInputs = [ swig2 ]; </ins> buildInputs = [ swig2 openssl ]; propagatedBuildInputs = [ typing ];

Discussion:
I am seeing a new (but similar to ) build problem with crda when using a global libressl override. Things were working fine until maybe a week ago, I think. I am confused, because I can't see anything relevant that has changed lately, but for some reason something about has changed for libressl or m2crypto. Does anyone know what is going on?
- was merged about a week ago; I'm not near a NixOS machine right now, but maybe try reverting that on a fork and see if builds once again?
Oh, interesting. Thanks for the idea! Just to be clear: So, if I'm reading this right, this depends only on , and not . Can your suggestion still be right?
And just tried it. No luck. Doesn't affect any of the derivation paths/hashes.
FWIW: EDIT: See PR below
aaaaaand this is why you make the big bucks. Works great for me! Thanks!
Change:
NIX_LDFLAGS = lib.optionalString stdenv.isLinux "-lrt -lpthread"; meta = { <del> homepage = "http://nbd.sourceforge.net"; </del> <ins> homepage = "https://nbd.sourceforge.io/"; </ins> description = "Map arbitrary files as block devices over the network"; license = lib.licenses.gpl2; <del> platforms = lib.platforms.linux; </del> <ins> platforms = lib.platforms.unix; </ins> }; }

Discussion:
Thank you for packaging NBD! However, the current NBD package does not have TLS support. Is it possible to add TLS support to the compile process? Set and try to connect to an TLS-enabled server. system: host os: multi-user?: sandbox: version: channels(root): nixpkgs:
Change:
sha256 = "0kdq0sc7dsfzlr0ggbxggcbkivc6yp30nqwjwcaxg9295s3b06wa"; }; <del> patchPhase = '' </del> <ins> patches = [ (fetchpatch { url = "https://anonscm.debian.org/git/pkg-games/torcs.git/plain/debian/patches/gcc6-isnan.patch"; sha256 = "16scmq30vwb8429ah9d4ws0v1w6ai59lvn7hcgnvfzyap42ry876"; }) (fetchpatch { url = "https://anonscm.debian.org/git/pkg-games/torcs.git/plain/debian/patches/format-argument.patch"; sha256 = "04advcx88yh23ww767iysydzhp370x7cqp2wf9hk2y1qvw7mxsja"; }) (fetchpatch { url = "https://anonscm.debian.org/git/pkg-games/torcs.git/plain/debian/patches/glibc-default-source.patch"; sha256 = "0k4hgpddnhv68mdc9ics7ah8q54j60g394d7zmcmzg6l3bjd9pyp"; }) ]; postPatch = '' </ins> sed -i -e s,/bin/bash,`type -P bash`, src/linux/torcs.in '';

Discussion:
failed to build with Full building log exists but I am not sure how to apply it correctly. Could be easy for anyone who know the process. $ cd /nix/nixpkgs/; git rev-parse HEAD $ nix-shell -I nixpkgs=/nix/nixpkgs -p torcs 2&1 | tee System: NixOS: (Impala) Nix version: nix-env (Nix) 1.11.15 Nixpkgs version: "18.03pre117327." Sandboxing enabled: build-use-sandbox = true
Change:
prey-bash-client is deprecated upstream '') <ins> (mkRemovedOptionModule ["hardware" "u2f" ] '' The U2F modules module was removed, as all it did was adding the udev rules from libu2f-host to the system. Udev gained native support to handle FIDO security tokens, so this isn't necessary anymore. '') </ins> # Do NOT add any option renames here, see top of the file ]; }

Discussion:
Describe the bug I recently noticed errors in logs around a missing group: To Reproduce Steps to reproduce the behavior: to on a NixOS system built from a recent commit logs with e.g Expected behavior No errors in logs. Additional context I'm not 100% sure what changed to trigger this error or how to best address it, but the config file does refer to a group, which commonly is present on other distros: The group is indeed not present on my NixOS system: The udev config seems to be fetched from the package. Metadata Maintainer information:
I see 2 ways of fixing this: a) just adding the group - this group is used in older Debian/Ubuntu distributions to indicate the device can be mounted using pmount b) removing from udev files as should be enough
A simple nixpkgs search shows there are more modules/packages using the group such as: and upstream packages tarballs used in: In we replace the the group with the group.
Since we don't include that group by default like Debian does, we should probably remove these references to plugdev. Users can always add their own custom udev rules if they want special group handling.
Looking at , seems to be the right way forward for most of these rules. We might just want to patch those to use it, and upstream these patches.
most of the affected udev files already have ; they just include the group for older Debian/Ubuntu distros. This is indeed obsolete method, so fix is indeed just a matter of removing this from the udev files.
According to removing breaks some non-systemd distros where nixpkgs maybe independently installed. What are your thoughts on removing the offending rule via ? Same approach can be taken with other . This would preserve backward compatibility with non NixOS systems.
If I'm not mistaken, this comment is not about nixpkgs on non-systemd distros, but other non-systemd distros in general. As written in , we probably can just ignore the warning for now, and remove the udev rule entirely once a systemd with has landed in nixpkgs.
This should be solved by , PTAL.
Change:
}; }; }; <ins> specialisation.explicit-config-file.configuration = { services.caddy.configFile = pkgs.writeText "Caddyfile" '' localhost:80 respond "hello world" ''; }; </ins> }; }; testScript = { nodes, ... }: let <ins> explicitConfigFile = "${nodes.webserver.system.build.toplevel}/specialisation/explicit-config-file"; </ins> justReloadSystem = "${nodes.webserver.system.build.toplevel}/specialisation/config-reload"; multipleConfigs = "${nodes.webserver.system.build.toplevel}/specialisation/multiple-configs"; rfc42Config = "${nodes.webserver.system.build.toplevel}/specialisation/rfc42";

Discussion:
I wanted to configure caddy with my own config file, setting as documented in the option. Steps to reproduce the behavior: above snippet how caddy does not start, as does not exist. at the filesystem, observe there's a directory with a inside, while sets Possibly introduced in Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Looks like a regression to me. Will investigate further. Thanks for your report and the commit you suggested that might have introduced it :)
I don't think it's that commit. Can you try ?
I am pretty sure this documentation error has been introduced all the way back in . The option docs simply switched from to , but forgot to wrap add a at the end. And now we are somewhat stuck with behavior that expects it that way... sigh.
I think this in combination with introduced the breaking change, since we now always pass as the arg, but expect a basename of to enable the adapter.
It works if you do as demonstrated here: But it's ugly.
Alternatively do and explicitly set .
I tried with too, it doesn't work. I extended with an example (at least I think I did), and it fails. It's pushed to , if someone does a PR fixing the issue feel free to cherry-pick it in ;-)
With you also need to explicitly set .
Fixed it in (when using )
Can you also fix the writeTextDir case? That's what the documentation recommends to use...
I adjusted the documentation to use (which it used to be before )
I could also instead fix the case, if you have strong opinions, but this was a bit easier.
I think fixing the writeTextDir case makes more sense. That's what people might have in their configs, and getting everyone to notice they now need to write it like this, and update configs is worse UX than fixing the usage that was documented. Assuming it worked with 23.05 for example, but regressed with 23.11 again. That is, if this ever worked like this before. If it was broken all the time, no one could have a working config so it doesn't matter much :laughing:
Both and (without ) have been broken since , which landed in .
Ok, in that case, it's been broken for an entire release, so this is not just a regression when upgrading to 23.11. then it's probably ok.
Change:
hash = "sha256-4VC1fwQh9L3c5tgLUaC36p9QHL4dR2vkWc2XlNl0Xzw="; }; <del> # Disable version check </del> postPatch = '' <ins> # Drop broken version specifier sed -i '/python_requires/d' setup.py # Disable version check </ins> substituteInPlace raphodo/constants.py  --replace "disable_version_check = False" "disable_version_check = True" '';

Discussion:
Steps to reproduce the behavior: (the current version in ) I was having the same issue that was fixed by until a few days ago and built and worked flawlessly. I am currently using the version it is supposedly trying to build. returns , so I do not understand why the build is needed in the first place. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- (because you made the last commit) Please run and paste the result.
I tried rebuilding today after the fix you committed (thank you for being so quick), I am still receiving the same error. Is there something in particular I need to do for the fix to propogate? I know that there is a little lag before a commit comes in from , but I thought 3 days later would be enough?
The fix is now on and , so if you are on either, I guess you just need to update the channel. Otherwise, the following command should work:
FWIW, is also a handy tool for checking the status of a PR's movement into the various channels.
that worked, thank you. this is also very useful, will put it in my bookmarks!
Change:
systemd.sockets.nix-daemon.wantedBy = [ "sockets.target" ]; systemd.services.nix-daemon = <del> { path = [ nix pkgs.utillinux ] ++ optionals cfg.distributedBuilds [ config.programs.ssh.package pkgs.gzip ] </del> <ins> { path = [ nix pkgs.utillinux config.programs.ssh.package ] ++ optionals cfg.distributedBuilds [ pkgs.gzip ] </ins> ++ optionals (!isNix20) [ pkgs.openssl.bin ]; environment = cfg.envVars

Discussion:
On an 18.03 machine (deployed with NixOps, but that doesn't matter), even with my fix for , I'm getting ing the invocation, I see it comes from the local nix daemon socket: on the : This is interesting, it look like the ed process can't even find an binary to (all its tries end with ) and thus dies. It tries to tell its parent via but since the parent tries to write to the pipe first and gets , it never reads the error. I filed this as I think the issue here is that doesn't contain on the . This line could have put it in: but isn't enabled. My 17.09 service somehow had it on the , not sure why; wasn't on there either. (but leaving at its default ). In the addition of to the shouldn't be conditional on . needs SSH also when distributed builds aren't enabled, namely when SSH substituters are used.
I don't know if the should be made unconditional as well; I don't know if it's needed for Nix's general SSH usage, or really only for .
Ah, the issue was introduced in and before there was CC
It would be nice if somebody could provide a justification for the dependency (or even better, all these dependencies), then I'd put that in comments along with a fix PR.
PR at
I'm getting the same issue with ssh-serve only. Not sure if due to missing . strace:
Change:
, openssl , wxGTK32 , gitUpdater <del> , wrapGAppsHook </del> <ins> , makeDesktopItem </ins> }: <del> gcc12Stdenv.mkDerivation rec { </del> <ins> stdenv.mkDerivation rec { </ins> pname = "freefilesync"; version = "12.1";

Discussion:
For FreeFileSync, add a desktop file to $out/share/applications so that the application can be found in an app launcher. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Please run and paste the result.
Change:
stripRoot = false; }; <ins> backendPackage = if backend == "webengine" then python3Packages.pyqtwebengine else if backend == "webkit"    then python3Packages.pyqt5_with_qtwebkit else throw '' Unknown qutebrowser backend "${backend}". Valid choices are qtwebengine (recommended) or qtwebkit. ''; </ins> in mkDerivationWith python3Packages.buildPythonApplication rec { pname = "qutebrowser"; version = "1.13.0";

Discussion:
The current version of qutebrowser (1.13.0, nixpkgs svn-revision: .) packaged in unstable fails to start with webkit backend. Forcing the backend in the resulting error dialog does nothing. To Reproduce Steps to reproduce the behavior: in qutebrowser Screenshots ! Notify maintainers
The qtwebkit backend was disabled in . Apparently at the time there was talk about dropping the backend but eventually they decided to keep it for a while. In any case here's what the current README says about it Soo, we could revert the commit but it seems it's going to be anyway. This is the reason, it looks like a variable that points to the qutebrowser executable is not actually resolved:
Thanks for the info regarding the readme and webkit. I'm pretty new to nixpks. Let me now if this would be a viable solution: and I'll make the PR. Also, where should I branch off of and what should be the target branch for my PR. It is the best I could come up with, because webkit and webengine depend on to different versions of qt5 so, we cannot easily have qutebrowser depend on both.
You can just revert the commit I mentioned: that should take care of also enabling qtwebkit by default, which is probably what you want. To make a PR you should target the master branch, also take a look at the .
Hmm... I don't really know, what to make of this part: in the current version it reads: and reverting just the other changes gives me build-errors.
Uhm, try something like this:
Now I get the original import error on starting qutebrowser, when I have set to . Maybe was the right solution after all, because that at least worked.
Change:
in concatLists (mapAttrsToList mkKeyVal cfg.submissionOptions); }; } // optionalAttrs cfg.enableSmtp { <ins> smtp_inet = { name = "smtp"; type = "inet"; private = false; command = "smtpd"; }; </ins> smtp = {}; relay = { command = "smtp";

Discussion:
The postfix module keeps adding a smtp entry to even though I have set . I would like to overwrite the default smtp service in , but postfix uses the last entry in the file (which is always the default one). To Reproduce Steps to reproduce the behavior: postfix: smtp : in Expected behavior following line should be excluded from Additional context Here's the resulting file with double entries: Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- it looks like you wrote this part a while ago. Have you heard of this issue? Metadata Maintainer information:
I think, I fixed this a long time ago in my private nixpkgs repository and never upstreamed the change. I'll make a pull request.
Issue seems to be fixed. Thanks for the quick help!
Change:
<ins> { lib , stdenv , fetchFromGitHub , fetchpatch , cmake }: stdenv.mkDerivation rec { pname = "flatbuffers"; version = "2.0.0"; src = fetchFromGitHub { owner = "google"; repo = "flatbuffers"; rev = "v${version}"; sha256 = "1zbf6bdpps8369r1ql00irxrp58jnalycc8jcapb8iqg654vlfz8"; }; patches = [ # Pull patch pending upstream inclustion for gcc-12 support: # https://github.com/google/flatbuffers/pull/6946 (fetchpatch { name = "gcc-12.patch"; url = "https://github.com/google/flatbuffers/commit/17d9f0c4cf47a9575b4f43a2ac33eb35ba7f9e3e.patch"; sha256 = "0sksk47hi7camja9ppnjr88jfdgj0nxqxy8976qs1nx73zkgbpf9"; }) ]; nativeBuildInputs = [ cmake ]; cmakeFlags = [ "-DFLATBUFFERS_BUILD_TESTS=${if doCheck then "ON" else "OFF"}" ]; doCheck = stdenv.hostPlatform == stdenv.buildPlatform; checkTarget = "test"; meta = with lib; { description = "Memory Efficient Serialization Library"; longDescription = '' FlatBuffers is an efficient cross platform serialization library for games and other memory constrained apps. It allows you to directly access serialized data without unpacking/parsing it first, while still having great forwards/backwards compatibility. ''; homepage = "https://google.github.io/flatbuffers/"; license = licenses.asl20; maintainers = [ maintainers.teh ]; mainProgram = "flatc"; platforms = platforms.unix; }; } </ins>

Discussion:
We define two packages, one for version 1.12 and one for version 2.0. The package for version 1.12 . Upstream has the fixes needed but only for version 2.0. The version 1.12 branch does not appear maintained, and there to it since March of 2020. We can continue to maintain this (e.g. we can disable warnings, or we can adapt those fixes to 1.12 and patch them), but perhaps we could drop support for the old version altogether? ZHF: /cc
Disabling -Werror is always reasonable, but if there's no users left in nixpkgs I think it's ok to drop it. Unless the maintainer or someone else still has a use for this (do a scream test by removing it, I guess)
is unused and can be safely removed.
Change:
./services/hardware/throttled.nix ./services/hardware/trezord.nix ./services/hardware/triggerhappy.nix <del> ./services/hardware/u2f.nix </del> ./services/hardware/udev.nix ./services/hardware/udisks2.nix ./services/hardware/upower.nix

Discussion:
Describe the bug I recently noticed errors in logs around a missing group: To Reproduce Steps to reproduce the behavior: to on a NixOS system built from a recent commit logs with e.g Expected behavior No errors in logs. Additional context I'm not 100% sure what changed to trigger this error or how to best address it, but the config file does refer to a group, which commonly is present on other distros: The group is indeed not present on my NixOS system: The udev config seems to be fetched from the package. Metadata Maintainer information:
I see 2 ways of fixing this: a) just adding the group - this group is used in older Debian/Ubuntu distributions to indicate the device can be mounted using pmount b) removing from udev files as should be enough
A simple nixpkgs search shows there are more modules/packages using the group such as: and upstream packages tarballs used in: In we replace the the group with the group.
Since we don't include that group by default like Debian does, we should probably remove these references to plugdev. Users can always add their own custom udev rules if they want special group handling.
Looking at , seems to be the right way forward for most of these rules. We might just want to patch those to use it, and upstream these patches.
most of the affected udev files already have ; they just include the group for older Debian/Ubuntu distros. This is indeed obsolete method, so fix is indeed just a matter of removing this from the udev files.
According to removing breaks some non-systemd distros where nixpkgs maybe independently installed. What are your thoughts on removing the offending rule via ? Same approach can be taken with other . This would preserve backward compatibility with non NixOS systems.
If I'm not mistaken, this comment is not about nixpkgs on non-systemd distros, but other non-systemd distros in general. As written in , we probably can just ignore the warning for now, and remove the udev rule entirely once a systemd with has landed in nixpkgs.
This should be solved by , PTAL.
Change:
patches = [ ./option-debugging.patch # ffmpeg 6 fix https://github.com/cmus/cmus/pull/1254/ <del> (fetchpatch { url = "https://github.com/cmus/cmus/commit/07b368ff1500e1d2957cad61ced982fa10243fbc.patch"; hash = "sha256-5gsz3q8R9FPobHoLj8BQPsa9s4ULEA9w2VQR+gmpmgA="; }) </del> <ins> (fetchpatch { name = "ffmpeg-6-compat.patch"; url = "https://github.com/cmus/cmus/commit/07b368ff1500e1d2957cad61ced982fa10243fbc.patch"; hash = "sha256-5gsz3q8R9FPobHoLj8BQPsa9s4ULEA9w2VQR+gmpmgA="; }) # function detection breaks with clang 16 (fetchpatch { name = "clang-16-function-detection.patch"; url = "https://github.com/cmus/cmus/commit/4123b54bad3d8874205aad7f1885191c8e93343c.patch"; hash = "sha256-YKqroibgMZFxWQnbmLIHSHR5sMJduyEv6swnKZQ33Fg="; }) </ins> ]; nativeBuildInputs = [ pkg-config ];

Discussion:
I'm on macOS (sonoma, ) and my packages are managed by . When I launch , I get a few errors. The text is only in black and white, and I can't seem to switch between panes using . Sadly, I didn't capture the three lines of minor errors and I'm unable to reproduce them. They seem to be related to decoders. I'm filing this issue because cmus is known to work on darwin with the binary obtained with homebrew, so I'm suspecting something might be off in the nix package. Steps to reproduce the behavior: Theming should work Tab should work (for pane switching) shouldn't show error at startup not working (nix): <img width="1325" alt="image" src=""working (brew) (please ignore the lyrics, that is a tmux pane): <img width="2416" alt="unknown" src=""Add any other context about the problem here. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Please run and paste the result. Thank you for your help :)