jiebi/CodeConvo huggingface dataset:
Change:
GRAALVM_HOME = graalvm11-ce; CLOJURE_LSP_JAR = jar; <ins> CLOJURE_LSP_XMX = "-J-Xmx4g"; patches = lib.optionals stdenv.isDarwin [ ./disable-check-toolchain.patch ]; </ins> buildInputs = [ graalvm11-ce ];

Discussion:
Describe the bug When running I get the following error message: Looking at the executable the first line is: In fish does not return the name of the current executed file. It appear to work when running this using . Also as comparison look at the file generated via package manager: To Reproduce Steps to reproduce the behavior: Expected behavior should start the server Additional context So with . Notify maintainers Metadata Please run and paste the result. system: host os: multi-user?: sandbox: version: channels(yogsototh): nixpkgs: Maintainer information:
Hey this version is pretty outdated, could you try latest which is using graalvm binary?
Also the brew forumla you saw is outdated as well, the updated is
You are probably using the stable channel 20.09 channel, that should explain why you're still using the with JVM instead of GraalVM compiled binary. Switch to the unstable channel instead. I am not sure if it will work though since this package was never tested with macOS (and the fact that this package is broken in Hydra: ).
I just tested with latest master commit And if failed to build: I think the main bug is probably fixed. This is just another one :). This is late for me. I'll probably give it a look another day. Thanks for checking!
I think all GraalVM's packages build with Clojure are broken in macOS simply by the lack of people that has macOS systems to test/fix them. If you can fix this, a PR would be welcome :slightlysmilingface: .
Agreed If you have mac, using the homebrew official clojure-lsp formula should work as well: https://clojure-
Change:
}; allowedTCPPortRanges = mkOption { <del> type = types.listOf (types.attrsOf types.int); </del> <ins> type = types.listOf (types.attrsOf types.port); </ins> default = [ ]; example = [ { from = 8999; to = 9003; } ]; description =

Discussion:
networking.firewall.allowedTCPPorts = [ 443 443 ]; Seems to generate two identical iptables rules instead of just one. This kind of configuration can easily happen when multiple independent modules append the same port to the list. IMO it would be worth de-duplicating ports (and maybe sorting?) so that the generated firewall configuration is easier to read. system: host os: multi-user?: sandbox: version: channels(delroth): nixpkgs:
Great idea - want to take a stab at a PR?
Change:
homepage = "https://ceph.io/en/"; inherit description; license = with lib.licenses; [ lgpl21 gpl2Only bsd3 mit publicDomain ]; <del> maintainers = with lib.maintainers; [ adev ak johanot krav ]; </del> <ins> maintainers = with lib.maintainers; [ adev ak johanot krav nh2 ]; </ins> platforms = [ "x86_64-linux" "aarch64-linux" ]; };

Discussion:
Steps to reproduce the behavior: ceph via Happening on current (currently at ), as well as on and . Do note that while this looks like a build failure for , is the one overriding the package version to something incompatible. The unaltered package builds fine. Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
See also , which I think should fix this.
Trying to build samba4Full and it errors on the same package. Just for any info for anyone.
I have addressed further review comments in Please somebody review.
Same error today with 'github:nixos/nixpkgs/' (2024-08-18)'
Change:
cabal.mkDerivation (self: { pname = "shelly"; <del> version = "1.5.6"; sha256 = "1vnn0s3i3n76286b7rc70qjzgkmfwllpg7w4zin627v6466pfpzl"; </del> <ins> version = "1.6.0"; sha256 = "0yrx7sv1s8pddpap143d3yi3ypvf84jjh16i8b3dm4kb3m4x3mdv"; </ins> buildDepends = [ async enclosedExceptions exceptions liftedAsync liftedBase monadControl mtl systemFileio systemFilepath text time transformers

Discussion:
Installing xmonad result in the following error: Looking at the git log leads to commit cc
This is indeed due to , upgrading should fix it, I'm doing it right now.
IMHO, the best way to ensure that works properly in the future is to port the NixOS module to the package set (which should not be difficult). Many Haskell users in Nix have converted already, and so the stuff in doesn't get as much anymore attention as it used to.
Change:
- The `services.mosquitto` module has been rewritten to support multiple listeners and per-listener configuration. Module configurations from previous releases will no longer work and must be updated. <ins> - The `fluidsynth_1` attribute has been removed, as this legacy version is no longer needed in nixpkgs. The actively maintained 2.x series is available as `fluidsynth` unchanged. </ins> ## Other Notable Changes {#sec-release-21.11-notable-changes}

Discussion:
no longer compiles with GLib 2.70: The failure looks patchable: We'd need to replace the use of in by an equivalent call to . However I'm not quite confident about the right place to call it, since we need to avoid calling it twice (which is UB according to the GLib documentation) and it looks like there are two different intialization routines that'd need to initialize the lock, and . Therefore I think should try to make an effort to finally get rid of this vulnerable version of fluidsynth (). Remaining uses: [x] , fixed in [x] (cc fixed in [x] (cc fixed in
Change:
ln -s ${sqitchModule}/$d $out/$d fi done <ins> '' + stdenv.lib.optionalString stdenv.isDarwin '' shortenPerlShebang $out/bin/sqitch </ins> ''; dontStrip = true; postFixup = "wrapProgram $out/bin/sqitch --prefix PERL5LIB : $PERL5LIB";

Discussion:
fails with the following error on macOS: To Reproduce Steps to reproduce the behavior: Expected behavior sqitch's version should be printed. Additional context seems to be the original sqitch main file, while exports in preparation of calling the original (perl) main file. However, still contains a shebang with all the library paths (each path is appended five times, but that's a different matter) as the environment variable, and when it's called, it fails with this error: Trial and error shows that limiting the shebang line to 512 character fixes the “exec format error” issue, and since there is no need to add all the paths (five times) to the shebang – since they are in the enviroment variable set by – they can be removed. This fixes the issue. Metadata Maintainer information:
Change:
<ins> { lib , rustPlatform , fetchFromGitHub }: rustPlatform.buildRustPackage rec { pname = "dnglab"; version = "0.5.0"; src = fetchFromGitHub { owner = "dnglab"; repo = pname; rev = "v${version}"; sha256 = "sha256-4uTpCBzBBkcpVBVZMOBD6f9ut71OuUNQ5+AkaQcU86M="; }; cargoSha256 = "sha256-WvXQNDYvR6s4M2Hlpqwq1/wFQYW2QU/ngQimKOFkhOQ="; postInstall = '' rm $out/bin/benchmark $out/bin/identify ''; meta = with lib; { description = "Camera RAW to DNG file format converter"; homepage = "https://github.com/dnglab/dnglab"; license = licenses.lgpl21Only; maintainers = with maintainers; [ dit7ya ]; }; } </ins>

Discussion:
Project description DNGLab - A camera RAW to DNG file format converter Command line tool to convert camera RAW files to Digital Negative Format (DNG). Metadata homepage URL: n/a source URL: license: GNU Lesser General Public License v2.1 platforms: unix, linux, darwin
Can you please test the linked PR and let me know if it works for you (I have not personally tested the program)?
Change:
<ins> # Elm {#sec-elm} To start a development environment do ```ShellSession nix-shell -p elmPackages.elm elmPackages.elm-format ``` To update the Elm compiler, see <filename>nixpkgs/pkgs/development/compilers/elm/README.md</filename>. To package Elm applications, [read about elm2nix](https://github.com/hercules-ci/elm2nix#elm2nix). </ins>

Discussion:
This issue tracks the conversion of from Docbook to CommonMark per . If you intend to work on this conversion, please comment below! here that you intend to work on it. (Please also post if you stop working on it.) a new branch of nixpkgs master. : change to . to . the contents from Docbook to . Follow . Use existing sections for inspiration. from the folder to build the manual. the manual on your computer at after running from folder: it looks good, submit a PR and reference this issue.
Change:
} ]; <del> environment.systemPackages = [ pkgs.flatpak ] ++ cfg.guiPackages; </del> <ins> environment.systemPackages = [ pkgs.flatpak ]; </ins> services.dbus.packages = [ pkgs.flatpak ];

Discussion:
Describe the bug Some options for gnome configuration don't work. I have disabled xterm and excluded gnome-software in my configuration but it is still installed in my system. config I am using Xterm shouldn't be installed if it is disabled. If gnome-software is installed by default for flatpak then I think that it should be an option and shouldn't override . Notify maintainers Metadata Please run and paste the result. system: host os: multi-user?: sandbox: version: nixpkgs: Maintainer information:
GNOME Software is actually installed by Flatpak module (introduced in ) so does not handle it. Maybe it should. Do not see in your config, maybe double check it is disabled using program. Either way, it should be unrelated to GNOME.
I have enabled it, sorry didn't post the snippet.
GNOME Software consumes a lot of memory even if it is not launched and is quite slow also there are alternatives that are being worked on like . So people in future might want to switch the gui for flatpak. If handling by exclude package doesn't look like a good solution then adding a module for flatpak to choose to install the software center would be better.
I used this . Maybe just add the documentation for this option since it is not present in .
Change:
my $configurationLimit = int(get("configurationLimit")); my $copyKernels = get("copyKernels") eq "true"; my $timeout = int(get("timeout")); <del> my $defaultEntry = int(get("default")); </del> <ins> my $defaultEntry = get("default"); </ins> my $fsIdentifier = get("fsIdentifier"); my $grubEfi = get("grubEfi"); my $grubTargetEfi = get("grubTargetEfi");

Discussion:
only supports signed integers. Using "saved" inplace of the integer is supported by grub to boot the previously booted OS Set in your nixos config Output of
Change:
<ins> { stdenv, lib, fetchurl, meson, ninja, pkg-config , gtk-doc, docbook-xsl-nons , glib, ncurses, libxml2 , buildDocs ? true }: stdenv.mkDerivation rec { pname = "libgnt"; version = "2.14.1"; outputs = [ "out" "dev" ] ++ lib.optional buildDocs "devdoc"; src = fetchurl { url = "mirror://sourceforge/pidgin/${pname}-${version}.tar.xz"; sha256 = "1n2bxg0ignn53c08cp69pj4sdg53kwlqn23rincyjmpr327fdhsy"; }; nativeBuildInputs = [ meson ninja pkg-config ] ++ lib.optionals buildDocs [ gtk-doc docbook-xsl-nons ]; buildInputs = [ glib ncurses libxml2 ]; postPatch = '' substituteInPlace meson.build --replace  "ncurses_sys_prefix = '/usr'"  "ncurses_sys_prefix = '${lib.getDev ncurses}'" '' + lib.optionalString (!buildDocs) '' sed "/^subdir('doc')$/d" -i meson.build ''; meta = with lib; { description = "An ncurses toolkit for creating text-mode graphical user interfaces"; homepage = "https://keep.imfreedom.org/libgnt/libgnt/"; license = licenses.gpl2Plus; platforms = platforms.unix; maintainers = with lib.maintainers; [ ony ]; }; } </ins>

Discussion:
Looks like there has been a new release this year: maintainer: cc it adds XDG portal support, which might be necessary for screen sharing on phosh and other Wayland clients.
PR:
I marked this as stale due to inactivity. &rarr;
Change:
inherit (nixosTests) sane; }; <del> meta = with lib; { </del> <ins> meta = { </ins> description = "SANE (Scanner Access Now Easy) backends"; longDescription = '' Collection of open-source SANE backends (device drivers).

Discussion:
My Canon CanoScan LiDE 20 does not work on NixOS. I wrote a minimal SANE config dir to reproduce: Invocation: ` Reveals: <details</detailsImportant part: It's failing because it's trying to write a lock file into .
I suspect the code involved is this: Looks like the packaging overrode the string, putting the nix output store path prefix in front; that seems wrong.
Grepping further: Indeed, the build logs show the wrong path:
Probably the nix build sets to a store path. Fixing it via: Other nixpkgs packages also set . Maybe nixpkgs should do this automatically for all packages? Probably is what puts the nix store path in. However, trying the workaround fails the build at step:
In PR I made an option to set the package without mass rebuilds. With that, the following workarounds make the scanner work: Now I can scan.
I'd be happy if somebody could pick up the task to pass a proper lock dir and ensure it exists in NixOS.
Another option is to disable locking entirely. Putting this in my nixos config is working for me:
Yes, that's what's mentioned in the comment just above:
It seems only scanners covered by SANE's driver are affected by this, as only those use locks as per : Note this driver, even though called , handles also many other vendors' scanners, including some Canon, Epson, HP, and others.
I think that's the reason it isn't being done by default, because upstream build systems try to create directories inside the runtime state directory at install time. So we're trading build time successes for runtime failures. A similar situation exists with /etc (sysconfdir), where I think the default should be /etc, but nixpkgs uses $prefix/etc because it has a higher success rate at build time.
With the workaround mentioned in I'm able to scan on a CanonScan Lide 25 using the sane-plustek backend. Would be great to have this properly fixed.
Using a Canon N670U (also covered by ) I ran into the same issue and resolved it with workaround Proper fix would be highly appreciated though.
Please give a try, it should fix the issue
Change:
, rustPlatform , makeWrapper , writeScript <ins> , python3 </ins> , fuseSupport ? false }:

Discussion:
NixOS on boot loops waiting for devices with wrong names. According to device paths are split by ":", but for some persistent block device names we have ":" in valid paths. The boot is stuck trying to load: Steps to reproduce the behavior: NixOS using /dev/disk/by-path devices boot waiting loop Boot without waiting for nonexistant devices ! Please run and paste the result.
This is a recent phenomenon I've experienced a few times, on bcachefs. I'm not entirely sure why this happens, but since Linux 6.4.8 I believe, I haven't had this issue. There are two reasons why this could happen AFAIK: is messed up between the linux kernel and stage-1. needs to have all the devices loaded before trying to mount multiple. That's the best I have ATM. Current nix-info for reference: system: host os: multi-user?: sandbox: version: channels(mado): channels(root): nixpkgs:
I should also clarify in my case that it was a breaking bug, where I would have to reboot because one of the devices never loaded and would drop me into an error, until it worked.
it seems like you're describing a different issue with bcachefs and multiple devices separated by . This bug, as far as I understand, is about non-bcachefs block device paths that contain incidentally (not as a multi-device delimiter). I'd suggest filing a separate issue for your problem.
(But as the author of the change that introduced that behavior - - I suspect you might want to be involved here regardless :P)
My bad, the usual bad reading comprehension and I didn't look at the paths that were listed closely enough. I would suggest, if possible, using something like instead until this is fixed. As for the fix, while it would break the use-case of colon-separated if it is the aforementioned path.
This should be considered a bug. There are a lot of paths in that have colons in their name (including RAID UUID devices). Requiring users to know that devices with colons in their name are treated special is unreasonable, especially if it's not documented. If bcachefs requires this then I think we need a new configuration option or the stage 1 function needs to be extended so it considers the file system type before setting .

IMO, we should get rid of it for bcachefs (it's only use) and just use the new ` mechanism.
I don't use bcachefs so I don't know what the mechanism is. Is it safe to simply revert your patch to ?
Unfortunately no, because many people's auto-generated configs still use the ':' separator. It's something I think we'll have to do at some point though. I think the better option may be to omit a warning if it's being used (i.e: using bcachefs) until 24.05, backport that to 23.11, and remove it in 24.05.
I would suggest that we change the function to take an optional second argument, the file system type. If that argument is set and it is set to "" then (and only then) do we set . Of course, this only works if the auto-generated configs correctly set the file system type. Can you point me to the commit where you changed the auto-generation process?
Should be fixed in
Change:
stdenv.mkDerivation rec { pname = "csxcad"; <del> version = "unstable-2022-05-18"; </del> <ins> version = "0.6.3"; </ins> src = fetchFromGitHub { owner = "thliebig"; repo = "CSXCAD"; <del> rev = "cd9decb4d9cebe3c8bf115e2c0ee73f730f22da1"; sha256 = "1604amhvp7dm8ych7gwzxwawqvb9hpjglk5ffd4qm0y3k6r89arn"; </del> <ins> rev = "v${version}"; sha256 = "sha256-SSV5ulx3rCJg99I/oOQbqe+gOSs+BfcCo6UkWHVhnSs="; </ins> }; patches = [./searchPath.patch ];

Discussion:
Package name: OpenEMS Latest released version: 0.0.36 <!-- Search your package here: --- Current version on the unstable channel: 2020-02-15 Current version on the stable/release channel: 2020-02-15 <!-- Type the name of your package and try to find an open pull request for the package If you find an open pull request, you can review it! There's a high chance that you'll have the new version right away while helping the community! --- Notify maintainers <!-- If the result shows no maintainers, tag the person that last updated the package. -- Note for maintainers: Please tag this issue in your PR.
Change:
in stdenvNoCC.mkDerivation (finalAttrs: { pname = "composer-local-repo-plugin"; <del> version = "1.0.0"; </del> <ins> version = "1.0.2"; </ins> src = fetchFromGitHub { owner = "nix-community"; repo = "composer-local-repo-plugin"; rev = finalAttrs.version; <del> hash = "sha256-sjWV4JXK8YJ5XLASMPipKlk9u57352wIDV2PPFIP+sk="; </del> <ins> hash = "sha256-L1DPAINlYiC/HdcgDpI72OI58v8LWfhZVuS1vtNDnEw="; </ins> }; COMPOSER_CACHE_DIR = "/dev/null";

Discussion:
Steps to reproduce the behavior: <!-- 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.
is already loaded by default so there's no need to enable it.
On nixpkgs stable this works and on unstable it breaks (probably because of the new builder). There is some backward incompatible change that lead to this breakage. Maybe it should not be possible to pick in the first place if it leads to a failure?
Investigation ongoing... I'll keep you posted.
I can reproduce the issue and I see the problem in the file. nix build --impure --expr '((import ./. { }).php.withExtensions ({all, enabled}: enabled ++ [])).packages.composer' --keep-failed Then That's the kind of issue that could potentially happen when using bash pipes to generate crucial files.
I think I will need an update of to fix this properly....
Issue fixed in: , could you please test and report back so we can merge this asap ?
Change:
let appName = "heroic"; in stdenv.mkDerivation rec { pname = "heroic-unwrapped"; <del> version = "2.9.2"; </del> <ins> version = "2.10.0"; </ins> src = fetchFromGitHub { owner = "Heroic-Games-Launcher"; repo = "HeroicGamesLauncher"; rev = "v${version}"; <del> hash = "sha256-kCvMUhN1kjGb5rV+lkKm1FFYBJUSQGOKTY1DQdiAWLU="; </del> <ins> hash = "sha256-umPQIxwIahjbO4QbkKEoeSSeYT2UatsTGRPrLgw5KW8="; </ins> }; offlineCache = fetchYarnDeps { yarnLock = "${src}/yarn.lock"; <del> hash = "sha256-kHZL7TENVK58dvr8PBFtWYZ2PSKEYESX4e1xYmMA5+Y="; </del> <ins> hash = "sha256-o5ztk4okH21Op1jqHZfranR12M8B1Y/K95aWb10tf5o="; </ins> }; nativeBuildInputs = [

Discussion:
Heroic Launcher while trying to install a game from gog will download it, but won't install it. You can see downloaded installer inside your directory. After "installation", launcher will say on the game's details screen that It should install. ! You can't just use the gog installer like in a normal linux distribution: So you need to use steam-run to install it. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --heroic-launcher: 2.9.2 - unstable nixpkgs
This sounds exactly like a bug I encountered in a previous version of Heroic, but they have since fixed it, and I have not run into it on 2.9.2. Could you please attach the Heroic log file from right after trying to install the game? It's accessible via the sidebar Settings-Log.
<details</details
It looks like it successfully installs, going by that log. I seem to vaguely recall now having some issues with my GOG library in Heroic 2.9.2, and I eventually removed (with Heroic closed) and logged in to GOG through Heroic again, and it's been behaving since. You might try that, otherwise I don't see anything indicating this would be an issue specific to the Heroic package, so I think it would be appropriate to go to upstream's support channel, which is .
I will try moving to nixpkgs unstable and see if it was an issue of using stable and unstable in the same time. It should not, but maybe it is. Thank you for your help PS. I tried different game and the situation is still the same.
I found that heroic needs unzip to be installed to extract the gog linux installers. When I have somewhere in my installed packages (home or system), it just works. Probably it will have to be to the heroic wrapper.
Could you please try changing in your Nix config to the following and see if that fixes your problem?
By using: Everything started to work.
Change:
buildPythonPackage rec { pname = "beancount-black"; <del> version = "0.1.13"; </del> <ins> version = "0.1.14"; </ins> disabled = pythonOlder "3.9"; format = "pyproject";

Discussion:
Steps to reproduce the behavior: Full build log: This error occurs because the version of in nixpkgs is 0.1.23 and requires a prior version. Setting resolves the build error but leads to a runtime error that crashes the program. There is an but they seem to be rather unresponsive. Everything does work as intended when the version of is manually pinned to 0.1.21.
Change:
* mkKeyValue is the same as in toINI. */ toKeyValue = { <del> mkKeyValue ? mkKeyValueDefault {} "=" }: attrs: let mkLine = k: v: mkKeyValue k v + "n"; in libStr.concatStrings (libAttr.mapAttrsToList mkLine attrs); </del> <ins> mkKeyValue ? mkKeyValueDefault {} "=", listsAsDuplicateKeys ? false }: let mkLine = k: v: mkKeyValue k v + "n"; mkLines = if listsAsDuplicateKeys then k: v: map (mkLine k) (if lib.isList v then v else [v]) else k: v: [ (mkLine k v) ]; in attrs: libStr.concatStrings (lib.concatLists (libAttr.mapAttrsToList mkLines attrs)); </ins> /* Generate an INI-style config file from an

Discussion:
Describe the bug I'd like the function to accept lists and produce duplicate keys, like so: which would yield:
ping to see if he has any interest in implementing this :heart:
Done in :)