jiebi/CodeConvo huggingface dataset:
Change:
<del> source 'https://rubygems.org' gem 'neocities' </del>

Discussion:
I'm not really sure how it happened, however we have 2 copies of the Neocities CLI: One from , and another from . After formatting the nix files in each, the only differences are: Description Maintainers Platforms ( lists ) Gemfile lock platform/bundled-with version ( is bundled-with , has as a platform and is bundled-with ) is older, while is newer and slightly more complete, as it seems. One should be removed, with the other aliased to it. CC as the maintainer of the other Neocities package.
this happened before, i wonder if there are more cases like this rn
I'll take care of this -- it seems like is out of date so might as well take care of that, too.
Change:
cp -r * $out rm -rf $out/bin/*.{ps1,bat} <del> rm -rf $out/bin/add-user-keycloak.sh rm -rf $out/bin/jconsole.sh chmod +x $out/bin/standalone.sh wrapProgram $out/bin/standalone.sh  --prefix PATH ":" ${jre}/bin ; </del> <ins> module_path=$out/modules/system/layers/keycloak if ! [[ -d $module_path ]]; then echo "The module path $module_path not found!" exit 1 fi ${lib.optionalString (postgresql_jdbc != null) '' mkdir -p $module_path/org/postgresql/main ln -s ${postgresql_jdbc}/share/java/postgresql-jdbc.jar $module_path/org/postgresql/main/ ln -s ${mkModuleXml "org.postgresql" "postgresql-jdbc.jar"} $module_path/org/postgresql/main/module.xml ''} ${lib.optionalString (mysql_jdbc != null) '' mkdir -p $module_path/com/mysql/main ln -s ${mysql_jdbc}/share/java/mysql-connector-java.jar $module_path/com/mysql/main/ ln -s ${mkModuleXml "com.mysql" "mysql-connector-java.jar"} $module_path/com/mysql/main/module.xml ''} wrapProgram $out/bin/standalone.sh --set JAVA_HOME ${jre} wrapProgram $out/bin/add-user-keycloak.sh --set JAVA_HOME ${jre} wrapProgram $out/bin/jboss-cli.sh --set JAVA_HOME ${jre} </ins> ''; <ins> passthru.tests = nixosTests.keycloak; </ins> meta = with stdenv.lib; { homepage    = "https://www.keycloak.org/"; description = "Identity and access management for modern applications and services"; license     = licenses.asl20; platforms   = jre.meta.platforms; <del> maintainers = [ maintainers.ngerstle ]; </del> <ins> maintainers = with maintainers; [ ngerstle talyz ]; </ins> }; }

Discussion:
Project description Metadata homepage URL: source URL: license: Apache-2.0 platforms: linux, darwin (maybe?)
There exists a package: A module is currently missing.
Uh I was pretty sure I checked in my local nixpkgs checkout. Weird, I wonder if I just made a typo while checking. Sorry about that. We can leave this issue for the module part.
It looks like the maintainer is Have you started work on a module already, or would you prefer someone else step up to work on that part? I haven't dealt with creating modules in the past, but I'd be willing to learn.
I haven't dug into making a module previously. I suspect there's a bit of ugliness around the setup and configuration decoratively, but I'm happy to work with someone on it. Shall I start a basic PR?
yes please :)
Change:
# shadow = 318; # unused hqplayer = 319; moonraker = 320; <ins> distcc = 321; </ins> # When adding a uid, make sure it doesn't match an existing gid. And don't use uids above 399!

Discussion:
Proposed options: (bool: ) (signed integer: ) (list of strings: )
Can you elaborate a bit more? Are you thinking of running a ? Or do you want to enable distcc as a client by default? In the first case you can easily define a systemd-service in nix, but across untrusted networks, you should run over ssh (which does not need a permanently running daemon). For a client, you can easily set up in a Also have a look at and .
I marked this as stale due to inactivity. &rarr;
I'm working on this.
Change:
# doCheck = true; preFixup = '' <del> gappsWrapperArgs+=(--prefix XDG_DATA_DIRS : "${shared-mime-info}/share") </del> <ins> gappsWrapperArgs+=( --prefix XDG_DATA_DIRS : "${shared-mime-info}/share" # See programs reached with fu_common_find_program_in_path in source --prefix PATH : "${stdenv.lib.makeBinPath [ flashrom efibootmgr bubblewrap tpm2-tools ]}" ) </ins> ''; mesonFlags = [

Discussion:
Describe the bug As I am trying to upgrade my XPS 13, fwupd can't find To Reproduce Expected behavior Update completes Additional context I am using nixos-unstable Metadata system: host os: multi-user?: sandbox: version: channels(root): nixpkgs:
Looking back at this patch that's probably not right. Probably all calls to need to be removed and it should just be a string to the executable.
If we're already wrapping the executables with , why not set the instead of patching?
Change:
services.mysql = { enable = true; <del> bind = "127.0.0.1"; </del> <ins> settings.mysqld = { bind-address = "127.0.0.1"; # FIXME(@Ma27) Nextcloud isn't compatible with mariadb 10.6, # this is a workaround. # See https://help.nextcloud.com/t/update-to-next-cloud-21-0-2-has-get-an-error/117028/22 innodb_read_only_compressed = 0; }; </ins> package = pkgs.mariadb; <del> # FIXME(@Ma27) Nextcloud isn't compatible with mariadb 10.6, # this is a workaround. # See https://help.nextcloud.com/t/update-to-next-cloud-21-0-2-has-get-an-error/117028/22 extraOptions = '' innodb_read_only_compressed=0 ''; </del> initialScript = pkgs.writeText "mysql-init" '' CREATE USER 'nextcloud'@'localhost' IDENTIFIED BY 'hunter2'; CREATE DATABASE IF NOT EXISTS nextcloud;

Discussion:
The nixos test for nextcloud fails on master (release-21.11 is fine, though). Steps to reproduce the behavior: The test runs through. Please run and paste the result.
Change:
cups thisPackage ]; <del> runScript = pname; </del> <ins> runScript = "${program}${year}"; </ins> # link desktop item and icon into FHS user environment extraInstallCommands = ''

Discussion:
<!-- Note that these are hard requirements --<!-- You can use the "Go to file" functionality on GitHub to find the package Then you can go to the history for this package Find the latest "packagename: oldversion -newversion" commit The "newversion" is the current version of the package --- <!-- 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! --- name: pdfstudio name: pdfstudioviewer <!-- The current version can be found easily with the same process as above for checking the master branch If an open PR is present for the package, take this version as the current one and link to the PR --current version: 2021.2.0 desired version: 2022.x.x <!-- Search your package here: If no maintainer is listed for your package, tag the person that last updated the package --maintainers: Please tag this issue in your PR.
Just purchased license for this product but can't use it as it's a 2022 license. Thanks for your help!
Change:
gimp = callPackage ../applications/graphics/gimp { autoreconfHook = buildPackages.autoreconfHook269; <del> gegl = gegl_0_4; </del> lcms = lcms2; inherit (darwin.apple_sdk.frameworks) AppKit Cocoa; };

Discussion:
Describe the bug I get this: It can also be seen on hydra: successful build: (revision ) First unsuccessful build: (revision ) To Reproduce Expected behavior It should build. Notify maintainers Maintainer information:
Considering it's abandonware since there's a new version, not resolving it and just setting it as broken is perhaps best.
Or removing arch from meta.platforms. Though really, nothing should be using such ancient version these days.
See for alternative solution (dropping gegl 0.2 completely)
Change:
mkDerivation rec { pname = "telegram-desktop"; <del> version = "2.1.0"; </del> <ins> version = "2.2.0"; </ins> # Telegram-Desktop with submodules src = fetchurl { url = "https://github.com/telegramdesktop/tdesktop/releases/download/v${version}/tdesktop-${version}-full.tar.gz"; <del> sha256 = "0l5917w90z9pg1al1hzcycb4yxv03vc88jg958ifl9nlvz1arll6"; </del> <ins> sha256 = "1chikb02df4qqnickcmx96lcx481b14kmksjsp7h94g0d223ypq0"; </ins> }; postPatch = ''

Discussion:
, CVSSv3=7.8 (nixos-20.03) Scanned versions: nixos-20.03: . Cc Cc
Change:
prospector = callPackage ../development/tools/prospector { }; # https://github.com/protocolbuffers/protobuf/issues/10418 <del> protobuf = if stdenv.hostPlatform.is32bit then protobuf3_20 else </del> <ins> # protobuf versions have to match between build-time and run-time # Using "targetPlatform" in the check makes sure that the version of # pkgsCross.armv7l-hf-multiplatform.buildPackages.protobuf matches the # version of pkgsCross.armv7l-hf-multiplatform.protobuf protobuf = if stdenv.targetPlatform.is32bit then protobuf3_20 else </ins> protobuf3_21; protobuf3_21 = callPackage ../development/libraries/protobuf/3.21.nix { };

Discussion:
Steps to reproduce the behavior: nix build nixpkgs#pkgsCross.armv7l-hf- fails to build since . The commit is an update of protobuf from 3.19 to 3.21. Partial build log: <!-- 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.
The x8664-linux -aarch64-linux cross build works for me on master @ . . x8664-linux -armv7l-hf-multiplatform fails for me as well.
I have updated the title to reflect that the failing build is on armv7. The error logs seems to indicate that there is a version incompatibility between protoc and grpc. However, I find it strange that it is only an issue for armv7.
Change:
}; }; <del> beetle-snes = mkLibretroCore { core = "mednafen-snes"; src = getCoreSrc "beetle-snes"; makefile = "Makefile"; meta = { description = "Port of Mednafen's SNES core to libretro"; license = lib.licenses.gpl2Only; }; }; </del> beetle-supafaust = mkLibretroCore { core = "mednafen-supafaust"; src = getCoreSrc "beetle-supafaust";

Discussion:
Steps to reproduce the behavior: Most common error is along the lines of Possibly related to glibc update? Can reproduce failure on local x8664-linux. Hydra
Related
This core itself seems to be kinda old and not updated anymore. Also not sure how interesting it is, considering it is based in a old version of bsnes. Maybe we can just remove it? Is there any reason you want to use it, or it is just an issue because it makes fail?
For me just because it’s in retroarchFull.
Created a PR to remove it: Would appreciate some reviews.
Change:
type nat hook prerouting priority dstnat; ${optionalString (fwdMap != "") '' <del> iifname "${cfg.externalInterface}" dnat meta l4proto . th dport map { ${fwdMap} } comment "port forward" ''} ${optionalString (fwdRangeMap != "") '' iifname "${cfg.externalInterface}" dnat meta l4proto . th dport map { ${fwdRangeMap} } comment "port forward" </del> <ins> iifname "${cfg.externalInterface}" meta l4proto { tcp, udp } dnat meta l4proto . th dport map { ${fwdMap} } comment "port forward" </ins> ''} ${optionalString (fwdLoopDnatMap != "") '' <del> dnat ${ipVer} daddr . meta l4proto . th dport map { ${fwdLoopDnatMap} } comment "port forward loopback from other hosts behind NAT" ''} ${optionalString (fwdLoopDnatRangeMap != "") '' dnat ${ipVer} daddr . meta l4proto . th dport map { ${fwdLoopDnatRangeMap} } comment "port forward loopback from other hosts behind NAT" </del> <ins> meta l4proto { tcp, udp } dnat ${ipVer} daddr . meta l4proto . th dport map { ${fwdLoopDnatMap} } comment "port forward loopback from other hosts behind NAT" </ins> ''} ${optionalString (dmzHost != null) ''

Discussion:
A NAT port forwarding rule fails to build with nftables when ranges are used. This is also the entirety of nix log /nix/store/sir8pvbk65zk4j6rqcj8sgwi0y78s3kc-nftables- Steps to reproduce the behavior: The nfables-rules derivation should compile. Using a single port rule, or disabling nftables results in a successful build. Please run and paste the result.
Change:
- `appimageTools.wrapAppImage` now creates the binary at `$out/bin/${pname}` rather than `$out/bin/${pname}-${version}`, which will break downstream workarounds. <ins> - `apptainer` and `singularity` now prioritize system-wide `PATH` over those constructed from dependent packages when searching for third-party utilities. The `PATH` to search for third-party utilities, known as `defaultPath` inside Apptainer/Singularity source code, is now constructed from the following sources, ordered by their precedence: - `systemBinPaths`, a new argument introduced to specify system-wide `"/**/bin"` directories. - The FHS `defaultPath` value set by Apptainer/Singularity developers, making Apptainer/Singularity work out of the box in FHS systems. - `defaultPathInputs`, a list of packages to form the fall-back `PATH`. This change is required to enable Sylabs SingularityCE (`singularity`) to run images, as it requires a `fusermount3` commant with the SUID bit set. `newuidmapPath` and `newgidmapPath` arguments are deprecated in favour of `systemBinPaths`. Their support will be removed in future releases. `programs.singularity.systemBinPaths` option is introduced to specify the `systemBinPaths` argument of the overridden package. It includes `"/run/wrappers/bin"` even if specified empty. `programs.singularity.enableFakeroot` option is deprecated and has no effect. `--fakeroot` support is now always enabled as long as `programs.singularity.systemBinPaths` is not forcefully overridden. </ins> - `azure-cli` now has extension support. For example, to install the `aks-preview` extension, use ```nix

Discussion:
Nixpkgs's package of Sylabs SingularityCE () now fails to execute image. After initial examination, the known cause is the failure to substitute default FHS s for some files, but the fix is WIP. Steps to reproduce the behavior: error. should succeed. If applicable, add screenshots to help explain your problem. 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. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
singularity isn't supposed to work without setuid?
Yup. The error seems to result from failure to replace all the default paths after source file hierarchy changes.
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Change:
# Deleting the bundled library is the simplest way to force it to use our version. rm "$out/lib/vmware/gcc/libstdc++.so.6" <ins> # This bundled version of libpng causes browser issues, and would prevent web-based sign-on. rm "$out/lib/vmware/libpng16.so.16" </ins> # This opensc library is required to support smartcard authentication during the # initial connection to Horizon. mkdir $out/lib/vmware/view/pkcs11

Discussion:
When opening a vmware-view server connection it crashes with message like the below. It appears to be trying to trigger a call to my default browser (firefox) but is unable to start it XPCOMGlueLoad error for file /nix/store/lxvr36j5wh5x6j3pm0hr6fwg8k7fhpn5-firefox- /nix/store/lxvr36j5wh5x6j3pm0hr6fwg8k7fhpn5-firefox- undefined symbol: pnggetnextframedelaynum, version PNG160 Couldn't load XPCOM. Steps to reproduce the behavior: vmware-view to launch a vmware-view server connection, for example Not crashing :)
a maybe more precise / more complete description: observe: terminal output VMware Horizon Client window for choosing connection appears with warning <details<summaryscreenshot</summary! </detailswarning by clicking button «Close» to connect by double-clicking connection tile observe: VMware Horizon Client window shows "Authenticating…" with a spinner terminal output VMware Horizon Client window just disappears <details<summaryscreen capture video</summary </details- exit code <details<summarycontent of <code/tmp/vmware-das-g/vmware-horizon-client-</code</summary</details
When I set the default browser to GNOME's "Web" (Epiphany), I get a slightly different error message on the terminal output at step 3 of my «steps to reproduce» in <details<summary<code/tmp/vmware-das-g/vmware-horizon-client-</code</summary</details- system: host os: multi-user?: sandbox: version: channels(root): nixpkgs:
Change:
, nodejs , npmHooks , makeBinaryWrapper <ins> , shellcheck </ins> }: stdenv.mkDerivation (finalAttrs: {

Discussion:
Steps to reproduce the behavior: This seems to have been caused by although I'm not familiar with the package, so I could be wrong. It is causing to fail as a result. I don't quite understand the organization of the structure, so I'm not sure who the appropriate maintainer is. As a fallback, and were involved in the above linked PR, so they may be of help here. Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
sorry for the breakage, i opened to fix this
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Had the same issue. But I think it's fixed in PR as mentioned You can track the progress of the PR , apparently it hasn't been merged into nixpkgs-unstable yet.
Change:
"-Dintrospection=${mesonEnableFeature enableGI}" "-Dsystemd-system-service=true" "-Dsystemd-system-unit-dir=${placeholder "out"}/lib/systemd/system" <ins> "-Dsysconfdir=/etc" </ins> ]; passthru.updateScript = nix-update-script {

Discussion:
WirePlumber doesn't seem to be able to load configuration files from . It's possible that I'm doing something wrong, but what I've found so far leads me to believe that wireplumber is looking in the wrong place. For reference, I have the following in : WirePlumber doesn't read this config. Moving the file to works. Running shows that WirePlumber is looking in the wrong place for its configuration files ( instead of ): The say the following about the configuration directory: …this can be found in : …which is referenced here: Unfortunately, I wasn't able to figure it out in the limited time I had tonight so I thought I'd open an issue describing what I'd found out so far to see if anyone else has ideas. Please run and paste the result.
Looks like you're correct, and we can just override to point to the right place.
Change:
meta = { homepage = http://pkg-shadow.alioth.debian.org/; description = "Suite containing authentication-related tools such as passwd and su"; <del> passthru = { shellPath = "/bin/nologin"; }; </del> <ins> }; passthru = { shellPath = "/bin/nologin"; </ins> }; }

Discussion:
Users with have the shell but should have something like . One result of this issue is that these users can't create forward-only SSH sessions. clever on #nixos found commit which introduced the issue. System: Nix version: Nixpkgs version:
cc
I just found out that the program doesn't export the shellPath passthrough for some reason.
Change:
<del> { stdenv, ruby, bison, fetchFromGitHub }: </del> <ins> { stdenv, ruby, bison, rake, fetchFromGitHub }: </ins> stdenv.mkDerivation rec { pname = "mruby"; <del> version = "2.1.0"; </del> <ins> version = "2.1.1"; </ins> src = fetchFromGitHub { owner   = "mruby"; repo    = "mruby"; rev     = version; <del> sha256  = "1y072c7dh9jf8xwy7kia6cb4dkpspq4zf24ssn7zm5f46p4waxni"; </del> <ins> sha256  = "gEEb0Vn/G+dNgeY6r0VP8bMSPrEOf5s+0GoOcnIPtEU="; </ins> }; <del> nativeBuildInputs = [ ruby bison ]; </del> <ins> nativeBuildInputs = [ ruby bison rake ]; patches = [ ./bison-36-compat.patch ]; </ins> # Necessary so it uses `gcc` instead of `ld` for linking. # https://github.com/mruby/mruby/blob/35be8b252495d92ca811d76996f03c470ee33380/tasks/toolchains/gcc.rake#L25

Discussion:
Describe the bug cannot be built from current master due to failing tests. To Reproduce Additional context Relevant logs: Notify maintainers Metadata Please run and paste the result. Maintainer information:
Change:
<ins> { podman-unwrapped , runCommand , makeWrapper , lib , extraPackages ? [] , podman # Docker compat , runc # Default container runtime , crun # Default container runtime (cgroups v2) , conmon # Container runtime monitor , slirp4netns # User-mode networking for unprivileged namespaces , fuse-overlayfs # CoW for images, much faster than default vfs , utillinux # nsenter , cni-plugins , iptables }: let podman = podman-unwrapped; binPath = lib.makeBinPath ([ runc crun conmon slirp4netns fuse-overlayfs utillinux iptables ] ++ extraPackages); in runCommand podman.name { inherit (podman) name pname version meta outputs; nativeBuildInputs = [ makeWrapper ]; } '' # Symlink everything but $bin from podman-unwrapped ${ lib.concatMapStringsSep "n" (o: "ln -s ${podman.${o}} ${placeholder o}") (builtins.filter (o: o != "bin") podman.outputs)} mkdir -p $bin/bin ln -s ${podman-unwrapped}/share $bin/share makeWrapper ${podman-unwrapped}/bin/podman $bin/bin/podman  --prefix PATH : ${binPath} '' </ins>

Discussion:
Describe the bug Podman's packaging isn't following the spirit of Nix, as far as I can tell. It seems to pull in a bunch of run-time executable dependencies via PATH resolution instead of build-time resolution. To Reproduce nix-shell -p podman --run podman based on the module, it looks like several run-time executables are referenced through PATH resolution instead of build-time pinning: Expected behavior Nix's build products should have stable references to their run-time dependencies whenever possible. Given podman's rootless container support, I doubly expected to give a usable podman.
Maintainer cc
Hmm im not sure how I feel about this. Podman is agnostic of container runtime for example. So it not having a path to either runc or crun is a feature. But conmon should probably be referenced by nix path yes. And utillinux too. We could perhaps default to runc runtime and let people opt to crun?
check out this PR from
I see the issue here. We could also discuss if it generally would make sense to have a build-time config feature for podman. Having strong defaults without configuration could be achieved that way for NixOS, too.
Is this expected to work without registry and policy files in ?
I would like it to, and it sounds like there is upstream work to make that possible.
This already works with rootless podman if you have the appropriate subuib/subgids set up. If is merged will work out of the box on NixOS.
Change:
Specifies the bind address on which the ollama server HTTP interface listens. ''; }; <ins> acceleration = lib.mkOption { type = nullOr (enum [ "rocm" "cuda" ]); default = null; example = "rocm"; description = lib.mdDoc '' Specifies the interface to use for hardware acceleration. - `rocm`: supported by modern AMD GPUs - `cuda`: supported by modern NVIDIA GPUs ''; }; </ins> package = lib.mkPackageOption pkgs "ollama" { }; }; }; config = lib.mkIf cfg.enable { systemd = { services.ollama = { wantedBy = [ "multi-user.target" ];

Discussion:
Ollama can't discover GPU libraries Steps to reproduce the behavior: this completely not overkill nixos config: Ollama discover GPU libraries and able to use GPU acceleration. Previously I was able to discover GPU libs by running downloaded ollama binary via - But anyway it crushes because it uses ROCM 6.0 while in nixpkgs unstable we still have 5.7.1 <!-- 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. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
This appears to be happening because the ollama service currently only ever builds the ollama package in cpu mode. If my understanding is correct, then should fix this, though gpu support won't be enabled automatically. Once is merged, rocm would be enabled like this, and should work without any other configuration:
Change:
githubId = 9939720; name = "Philippe Nguyen"; }; <ins> npulidomateo = { matrix = "@npulidomateo:matrix.org"; github = "npulidomateo"; githubId = 13149442; name = "Nico Pulido-Mateo"; }; </ins> nrdxp = { email = "tim.deh@pm.me"; matrix = "@timdeh:matrix.org";

Discussion:
Project description Typora is a distraction free markdown editor. Developed by Metadata homepage URL: source URL: Not open source :( Github Organization: license: platforms: , darwin
Hmmm I found this issue: Looks like the not open source thing is a problem here
Just checked, It seems to work fine with , so using buildFHSEnv should work. As says, there's nothing preventing this from being present in nixpkgs, as long as it works.