jiebi/CodeConvo huggingface dataset:
Code change:
}) else stdenv.mkDerivation { inherit pname version passthru; <del> src = sources.darwin; </del> <ins> src = if stdenv.isAarch64 then sources.darwin-aarch64 else sources.darwin-x86_64; </ins> nativeBuildInputs = [ undmg ]; sourceRoot = ".";

Related discussion:
text: After upgrading to the current version of nixpgs (nixos-unstable) anki starts up to a blank main window. According to the documentation () that is because of the system glibc having changed to a version not compatible with anki. Their suggested fix is that users move to using the beta package instead. Steps to reproduce the behavior: -shell -p Anki working as usual Add any other context about the problem here. Please run and paste the result. Excerpt from
Can confirm the behaviour.
Code change:
lispLibs = o.lispLibs ++ [ self.mcclim ]; <del> }); </del> <ins> }); cl-charms = super.cl-charms.overrideLispAttrs (o: { nativeLibs = [ pkgs.ncurses ]; }); libusb-ffi = super.libusb-ffi.overrideLispAttrs (o: { nativeLibs = [ pkgs.libusb-compat-0_1 ]; }); cl-fam = super.cl-fam.overrideLispAttrs (o: { nativeLibs = [ pkgs.fam ]; }); jpeg-turbo = super.jpeg-turbo.overrideLispAttrs (o: { nativeLibs = [ pkgs.libjpeg_turbo ]; }); vorbisfile-ffi = super.vorbisfile-ffi.overrideLispAttrs (o: { nativeLibs = [ pkgs.libvorbis ]; }); png = super.png.overrideLispAttrs (o: { nativeLibs = [ pkgs.libpng ]; }); zmq = super.zmq.overrideLispAttrs (o: { nativeLibs = [ pkgs.czmq ]; }); consfigurator = super.consfigurator.overrideLispAttrs (o: { nativeLibs = [ pkgs.acl pkgs.libcap ]; }); cl-gss = super.cl-gss.overrideLispAttrs (o: { nativeLibs = [ pkgs.libkrb5 ]; }); magicffi = super.magicffi.overrideLispAttrs (o: { nativeLibs = [ pkgs.file ]; }); keystone = super.keystone.overrideLispAttrs (o: { nativeLibs = [ pkgs.keystone ]; }); capstone = super.capstone.overrideLispAttrs (o: { nativeLibs = [ pkgs.capstone ]; }); </ins> }); qlpkgs =

Related discussion:
text: is missing a dependency, hence the build fails. Steps to reproduce the behavior: to : end up with this error: should build without any issues - -
If doesn't work, that is a bug but kind:bug and not kind:build-failure so another issue not to mix stuff…
Code change:
containerdHash = "sha256-y3CYDZbA2QjIn1vyq/p1F1pAVxQHi/0a6hGWZCRWzyk="; tiniRev = "v0.19.0"; tiniHash = "sha256-ZDKu/8yE5G0RYFJdhgmCdN3obJNyRWv6K/Gd17zc1sI="; <ins> knownVulnerabilities = [ "CVE-2024-23651" "CVE-2024-23652" "CVE-2024-23653" "CVE-2024-41110" ]; </ins> }; docker_25 = callPackage dockerGen rec { <del> version = "25.0.5"; cliRev = "v${version}"; </del> <ins> version = "25.0.6"; cliRev = "v25.0.5"; </ins> cliHash = "sha256-CACMi3bXUN6oGc2f/Z+lNQqMgQ4llRWPRKgijdpiPGg="; mobyRev = "v${version}"; <del> mobyHash = "sha256-4QGz22fXxyAD77pyUWb2lF3VKqxmPIrGqcJGoyrEHew="; </del> <ins> mobyHash = "sha256-+zkhUMeVD3HNq8WrWQmLskq+HykvD5kzSACmf67YbJE="; </ins> runcRev = "v1.1.12"; runcHash = "sha256-N77CU5XiGYIdwQNPFyluXjseTeaYuNJ//OsEUS0g/v0="; <del> containerdRev = "v1.7.13"; containerdHash = "sha256-y3CYDZbA2QjIn1vyq/p1F1pAVxQHi/0a6hGWZCRWzyk="; </del> <ins> containerdRev = "v1.7.20"; containerdHash = "sha256-Q9lTzz+G5PSoChy8MZtbOpO81AyNWXC+CgGkdOg14uY="; </ins> tiniRev = "v0.19.0"; tiniHash = "sha256-ZDKu/8yE5G0RYFJdhgmCdN3obJNyRWv6K/Gd17zc1sI="; }; docker_26 = callPackage dockerGen rec { <del> version = "26.1.4"; </del> <ins> version = "26.1.5"; </ins> cliRev = "v${version}"; <del> cliHash = "sha256-7yCR49Un1i1kB+66IKt/8lgwKNkUjtVh52DH9OY8Pw4="; </del> <ins> cliHash = "sha256-UlN+Uc0YHhLyu14h5oDBXP4K9y2tYKPOIPTGZCe4PVY="; </ins> mobyRev = "v${version}"; <del> mobyHash = "sha256-0WwlpUECvmNq6DBm7U7rjzYfGKF7pxsfs9+x5uVPV0k="; </del> <ins> mobyHash = "sha256-6Hx7GnA7P6HqDlnGoc+HpPHSl69XezwAEGbvWYUVQlE="; </ins> runcRev = "v1.1.12"; runcHash = "sha256-N77CU5XiGYIdwQNPFyluXjseTeaYuNJ//OsEUS0g/v0="; <del> containerdRev = "v1.7.15"; containerdHash = "sha256-qLrPLGxsUmgEscrhyl+1rJ0k7c9ibKnpMpsJPD4xDZU="; </del> <ins> containerdRev = "v1.7.18"; containerdHash = "sha256-IlK5IwniaBhqMgxQzV8btQcbdJkNEQeUMoh6aOsBOHQ="; </ins> tiniRev = "v0.19.0"; tiniHash = "sha256-ZDKu/8yE5G0RYFJdhgmCdN3obJNyRWv6K/Gd17zc1sI="; };

Related discussion:
text: Today one of my containers wouldn't start after I updated the docker-compose file and it was due to the docker engine being too old to support a certain feature. Easy enough to fix in config but is there a specific reason the attribute points at rather than ? Last time the attr was touched was
The reason is basically this: Quoting a recent comment in that PR:
Code change:
export TEXMFSYSVAR="$out/share/texmf-var" export PERL5LIB="$out/share/texmf/scripts/texlive" '' + <del> # patch texmf-{dist,local} -> texmf to be sure </del> <ins> # patch texmf-dist  -> $out/share/texmf # patch texmf-local -> $out/share/texmf-local </ins> # TODO: perhaps do lua actions? # tried inspiration from install-tl, sub do_texmf_cnf ''

Related discussion:
text: TEXMF defines the order in which files are read in The idea is that TEXMFSYSVAR and TEXMFCONFIG files take precedence over files distributed with TEXMFDIST, so there is a way for the user to override configuration files. Our lists: This seems all fine, except that our derivation also makes TEXMFLOCAL point to TEXMFDIST as well, and this destroys override-ability. My suggestion is to use a separate and empty $out/share/texmf-local for TEXMFLOCAL.
Could you please provide an example of the override that doesn't work?
I dropped my customization here: It boils down to adding a custom package (minionpro availble for my ) and running: in postBuild.
I investigated your override. I see that you sneak the original , then add your font to it and regenerate the mappings which go to share/texmf-var. At the same time our texlive setup just reuses prebuilt maps provided by (for pdftex), individual font packages and others and those are installed into share/texmf which happens to be also pointed by TEXMFLOCAL. I also now discover that the line does nothing for us. Your change makes sense to me. Makes me wonder if we could do better. For example, not deleting should not hurt anything. I could not find any way to automatically scan for new entries for The Gentoo documentation mentions [1] concatenating it from /etc/texmf/updmap.d. [1]
First of all thank you for taking such a careful look at my code snippet. I really appreciate it! First, yes, I sneak out and later sneak back in. I do think that there are no adverse side-effects from not deleting in texlive.combine. I will submit a PR to remove it. This will minimize my postBuild override to just: That looks much cleaner :) As there is no real "hooks" functionality in our texlive package derivation, it seems to be a good idea to optimistically merge (by concatenation) separate snippets. I will file a separate issue to discuss this.
Thank you!
Code change:
# powerManagement.powerDownCommands power.ups = { <del> enable = mkOption { default = false; type = with types; bool; description = lib.mdDoc '' Enables support for Power Devices, such as Uninterruptible Power Supplies, Power Distribution Units and Solar Controllers. ''; }; </del> <ins> enable = mkEnableOption (lib.mdDoc '' Enables support for Power Devices, such as Uninterruptible Power Supplies, Power Distribution Units and Solar Controllers. ''); </ins> <del> # This option is not used yet. </del> mode = mkOption { default = "standalone"; <del> type = types.str; </del> <ins> type = types.enum [ "none" "standalone" "netserver" "netclient" ]; </ins> description = lib.mdDoc '' The MODE determines which part of the NUT is to be started, and which configuration files must be modified.

Related discussion:
text: Describe the bug I'm trying to use NixOS in a UPS client (not server). When , the and services shouldn't be running. There is a note that says that is not used currently. To Reproduce Steps to reproduce the behavior: Error: and fail. Expected behavior only upsmon should be running Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Metadata Maintainer information: See also
Looks like there's a pretty simple workaround:
I marked this as stale due to inactivity. &rarr;
Code change:
# powerManagement.powerDownCommands power.ups = { <del> enable = mkOption { default = false; type = with types; bool; description = lib.mdDoc '' Enables support for Power Devices, such as Uninterruptible Power Supplies, Power Distribution Units and Solar Controllers. ''; }; </del> <ins> enable = mkEnableOption (lib.mdDoc '' Enables support for Power Devices, such as Uninterruptible Power Supplies, Power Distribution Units and Solar Controllers. ''); </ins> <del> # This option is not used yet. </del> mode = mkOption { default = "standalone"; <del> type = types.str; </del> <ins> type = types.enum [ "none" "standalone" "netserver" "netclient" ]; </ins> description = lib.mdDoc '' The MODE determines which part of the NUT is to be started, and which configuration files must be modified.

Related discussion:
text: Describe the bug The following snippet: results in services failing to start due to missing config files etc. : : ( fails too, but that could be down to the fact that I haven't plugged the UPS in yet -- but for the record, it complains ) Expected behavior I'd expect the services to start successfully (and probably complain about the missing actual UPS). Notify maintainers (The UPS module appears to have received only drive-by changes for the last several years, so no idea who to bug personally). Metadata system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Maintainer information:
OK, should've read the whole module: I'm supposed to supply the missing /etc/nut files myself because it's unwise to keep them in the store (they could contain passwords and whatnot, I guess?). Declaring (in the service definitions) the state directory to be but creating for the purpose appears to be a real bug, though :)
Also (sorry for the semi-off-topic) what are best practices for referencing hand-written config files without their contents winding up in the store? Double-symlinking? If this is documented somewhere, then I haven't found where.
I was struggling with the same problem as until I noticed this bug report. After copying and editing , , and from to (and setting on all those files), I was able to get it to work. I think this should be more discoverable. If it's not appropriate to copy those sample files to on the users behalf, there should at least be detailed instructions on the option to explain what else needs to be done.
I marked this as stale due to inactivity. &rarr;
Agreed this should be more discoverable. Perhaps at least could be defaulted to empty and written, since I seem to be getting away without anything in there. In case it helps anyone, I got it working with something like this:
I was hit this bug today, too. Maybe we can fix it by using a startup unit that handles the secrets and setup the state directories like nextcloud or syncthing do
Been working on today and wanted to put some notes here. Using version 2.7.4. First, isn't used by for PIDs and it will try to write to .
Code change:
# powerManagement.powerDownCommands power.ups = { <del> enable = mkOption { default = false; type = with types; bool; description = lib.mdDoc '' Enables support for Power Devices, such as Uninterruptible Power Supplies, Power Distribution Units and Solar Controllers. ''; }; </del> <ins> enable = mkEnableOption (lib.mdDoc '' Enables support for Power Devices, such as Uninterruptible Power Supplies, Power Distribution Units and Solar Controllers. ''); </ins> <del> # This option is not used yet. </del> mode = mkOption { default = "standalone"; <del> type = types.str; </del> <ins> type = types.enum [ "none" "standalone" "netserver" "netclient" ]; </ins> description = lib.mdDoc '' The MODE determines which part of the NUT is to be started, and which configuration files must be modified.

Related discussion:
text: flags , , may be needed instead of environment variables until a 2.7.5 release. Ref: Using for debug makes it non-forking, requiring a change to the systemd unit . I was able to get to run as non-root: I'm still working on understanding how to manage state directories in NixOS but this was needed:
I set out to get my UPS (cyberpower CP1500 AVR UPS) working with NixOS today. This was the first issue I came across, I figured this was the best place to share my configuration. I probably made this more complex than it needed to be because I have no idea what I am doing, and it is definitely not secure; one problem at a time.
Not stale; still relevant
Thanks for providing your standalone config! I learned a ton tweaking it into a netserver config! The below config creates a working NUT netserver that other machines on your local network can be connected to. The only thing I have yet to figure out is a secure way to include passwords in .nix files that won't show up if I push my local copy to github. Any ideas? If you want to tweak when NUT shuts down your computers you can modify the values of " = <percentage" and " = <seconds" under "directives". SHUTDOWNCMD will be triggered when both conditions are met. The "ignorelb" directive is necessary to have NUT ignore the UPS's defaults. Anyone using this config may want to make sure SHUTDOWNCMD and NOTIFYCMD point to the correct binaries in their filesystem. One other thing of note is to check the value of the "schedulerRules" field under below. You must give it the path to your file. I just put a copy of it inside my /etc/nixos. Could probably add another variable to hold the path for convenience. `
For secrets in nix config, I think the current recommendation is to put it in a separate file and not include it in the repo. See also
I have been using sops-nix to commit encrypted passwords to my NixOS repo, but I have yet to put in the elbow grease to make this work with my upsmon password.
is my attempt at making generate the config files necessary for basic operation. If you are using , could you try out the changes and leave a review?
Code change:
data_dir = mkOption { default = "/var/lib/garage/data"; <del> example = [ { path = "/var/lib/garage/data"; capacity = "2T"; } ]; </del> <ins> example = [ { path = "/var/lib/garage/data"; capacity = "2T"; } ]; </ins> type = with types; either path (listOf attrs); description = '' The directory in which Garage will store the data blocks of objects. This folder can be placed on an HDD.

Related discussion:
text: Steps to reproduce the behavior: -rebuild test on settings.datadir = "/mnt/garage0"; resolves fine Tested on nixos24.05 but code of the module is unchanged in nixos_unstable. I'm using flakes as well Please run and paste the result.
Looks like doesn't apply, maybe should tinker a bit on my own
It looks like the option type was adjusted, but not the other code in the module that checks that value. Shouldn't be too hard to fix.
Code change:
, texlive , zlib, libiconv, libpng, libX11 , freetype, gd, libXaw, icu, ghostscript, libXpm, libXmu, libXext <del> , perl, perlPackages, pkgconfig, autoreconfHook </del> <ins> , perl, perlPackages, python2Packages, pkgconfig, autoreconfHook </ins> , poppler, libpaper, graphite2, zziplib, harfbuzz, potrace, gmp, mpfr , cairo, pixman, xorg, clisp, biber, xxHash , makeWrapper, shortenPerlShebang

Related discussion:
text: I have installed the TeXLive package on my system, but its binary script fails to run because: its directory is not found in it does not have an explicitly dependency on it does not have an explicitly dependency on the module for Python 2 cannot be found. Please fix this issues so that the script can be run. (Maybe can take a look at this.)
cc
Well, the first two bullets would be fixed very simply by but I don't yet have framework to add external python dependencies to the scripts.
Nothing new here? A similar problem happens with :
cc Maybe while a good solution is not engineered, a package for without the TeX stuff can be to . It would contain the binary with support for the needed Python dependencies. What do you think?
There aren't any true binaries, are there? It's just python scripts IIRC. But still, what you propose is probably the easiest way to resolve this somehow.
It is just a Python script that depends on the module.
My attempt at it:
So pygmentex works as expected now?
It works! It can be tested by downloading the example document from the distribution on , unzipping the downloaded files, removing the Python script and the LaTeX style class, and than compiling : The result is , with many examples of code listings typeset by Pygments.
OK, then I think we can close this.
Sorry for necromancing this (should I have opened a new issue instead?), but it doesn't "just work" – or needs further documentation on how to use it: The created by building the pygmentex texlive package can not find the module. gives us such an environment, just try running the command from there -The package though provides a executable which works just fine and finds the needed pygments python module. So how to combine these both packages? In particular I ran into this when trying to use the texlive package, as that seems to directly invoke the executable during build. Issue appears on release-18.09
I encountered the same issue, the latex package seems to be working fine tough (and can be used as a replacement)
I have in both with (which provides the style file and a non-functional Python script, because of missing Python dependencies) and (which provides the script). This setup works for me.
I still do not know a way of allowing Python module dependencies for Python scripts installed through .
This is to be fixed in
Code change:
''; }; <ins> wireguardConfig = mkOption { default = {}; example = { PrivateKeyFile = "/etc/wireguard/secret.key"; ListenPort = 51820; FwMark = 42; }; type = types.addCheck (types.attrsOf unitOption) checkWireGuard; description = '' Each attribute in this set specifies an option in the <literal>[WireGuard]</literal> section of the unit. See <citerefentry><refentrytitle>systemd.netdev</refentrytitle> <manvolnum>5</manvolnum></citerefentry> for details. Use <literal>PrivateKeyFile</literal> instead of <literal>PrivateKey</literal>: the nix store is world-readable. ''; }; wireguardPeers = mkOption { default = []; example = [ { wireguardPeerConfig={ Endpoint = "192.168.1.1:51820"; PublicKey = "27s0OvaBBdHoJYkH9osZpjpgSOVNw+RaKfboT/Sfq0g="; PresharedKeyFile = "/etc/wireguard/psk.key"; AllowedIPs = [ "10.0.0.1/32" ]; PersistentKeepalive = 15; };}]; type = with types; listOf (submodule wireguardPeerOptions); description = '' Each item in this array specifies an option in the <literal>[WireGuardPeer]</literal> section of the unit. See <citerefentry><refentrytitle>systemd.netdev</refentrytitle> <manvolnum>5</manvolnum></citerefentry> for details. Use <literal>PresharedKeyFile</literal> instead of <literal>PresharedKey</literal>: the nix store is world-readable. ''; }; </ins> vlanConfig = mkOption { default = {}; example = { Id = "4"; };

Related discussion:
text: This configuration: If you poke around in the configuration I linked, you should see that I disable NetworkManager and use a static configuration for my main NIC. I can't think of anything special in my config or with this machine that would affect my usage of Wireguard, but I'm also new to using Wireguard. I'm currently on nixpkgs with a few of my own commits on top of . Please run and paste the results.
It doesn't seem happy when already exists... I have done two things, both of which were necessary, to resolve this: the link manually () sure the path to the private key exists (if not, you get a different failure in the journal, with failing). (It's possible that fixing the private key path and rebooting would have been sufficient). I'm leaving this open for two reasons: user should receive a better error message in both cases. that we're in NixOS, we should assume full control of the interface and just re-configure it, instead of failing in the setup script.
I ran into this issue after trying to debug my wireguard setup. My setup is essentialy identical and I get the same error message. Running the start script that is causing the error results in this output. The offending 2 lines are .
I had to go one step further than deleting the interface. I needed to stop the via then redeploy configuration. But this solved it for me. Nixos should handle this much more gracefully.
I had to remove the routes with etc.
The command is . You can build it in your conf as pre-setup command, but it has the nasty side effect that it possible interferes with other connections.
I am still running into this issue.
Code change:
<ins> { lib , stdenv , fetchFromGitHub , cargo , desktop-file-utils , meson , ninja , pkg-config , rustPlatform , rustc , wrapGAppsHook4 , cairo , gdk-pixbuf , glib , gtk4 , libadwaita , pango , pipewire , wireplumber }: stdenv.mkDerivation rec { pname = "pwvucontrol"; version = "0.2"; src = fetchFromGitHub { owner = "saivert"; repo = "pwvucontrol"; rev = version; hash = "sha256-jBvMLewBZi4LyX//YUyJQjqPvxnKqlpuLZAm9zpDMrA="; }; cargoDeps = rustPlatform.importCargoLock { lockFile = ./Cargo.lock; outputHashes = { "libspa-0.6.0" = "sha256-CVLQ9JXRMo78/kay1TpRgRuk5v/Z5puPVMzLA30JRk8="; "wireplumber-0.1.0" = "sha256-wkku9vqIMdV+HTkWCPXKH2KM1Xzf0xApC5zrVmgxhsA="; }; }; nativeBuildInputs = [ cargo desktop-file-utils meson ninja pkg-config rustPlatform.bindgenHook rustPlatform.cargoSetupHook rustc wrapGAppsHook4 ]; buildInputs = [ cairo gdk-pixbuf glib gtk4 libadwaita pango pipewire wireplumber ]; meta = with lib; { description = "Pipewire Volume Control"; homepage = "https://github.com/saivert/pwvucontrol"; license = licenses.gpl3Plus; maintainers = with maintainers; [ figsoda ]; mainProgram = "pwvucontrol"; platforms = platforms.linux; }; } </ins>

Related discussion:
text: Project description Volume control applet for Pipewire, written in Rust. <!-- Describe the project a little: --Metadata homepage URL: source URL: license: mit, bsd, gpl2+ , ... platforms: unix, linux, darwin, ...
Code change:
services.invoiceplane.webserver = "caddy"; services.invoiceplane.sites = { "site1.local" = { <del> #database.name = "invoiceplane1"; </del> <ins> database.name = "invoiceplane1"; </ins> database.createLocally = true; enable = true; }; "site2.local" = { <del> #database.name = "invoiceplane2"; </del> <ins> database.name = "invoiceplane2"; </ins> database.createLocally = true; enable = true; };

Related discussion:
text: , CVSSv3=7.5 (nixos-unstable) CVSSv3=5.3 (nixos-unstable) CVSSv3=5.3 (nixos-unstable) In InvoicePlane 1.5.11 a misconfigured web server allows unauthenticated directory listing and file download. Allowing an attacker to directory traversal and download files suppose to be private without authentication. In InvoicePlane 1.5.11, the upload feature discloses the full path of the file upload directory. InvoicePlane 1.5.11 doesn't have any rate-limiting for password reset and the reset token is generated using a weak mechanism that is predictable. Scanned versions: nixos-unstable: . Cc
Code change:
wireless.enable = lib.mkDefault false; }; <del> powerManagement.resumeCommands = '' ${config.systemd.package}/bin/systemctl restart network-manager ''; </del> security.polkit.extraConfig = polkitConf; services.dbus.packages = cfg.packages;

Related discussion:
text: after suspend the network-manager applet in plasma5/kde disappears suspend resume search for nm applet log out log in its back
Does this still happen on ? I cannot reproduce it.
i am no longer using nixos