jiebi/CodeConvo huggingface dataset:
Change:
fastcgi_read_timeout 120s; ''; }; <del> "~ ^/(?:updater|ocs-provider|ocm-provider)(?:$|/)".extraConfig = '' try_files $uri/ =404; index index.php; ''; "~ .(?:css|js|woff2?|svg|gif)$".extraConfig = '' </del> <ins> "~ .(?:css|js|svg|gif|map)$".extraConfig = '' </ins> try_files $uri /index.php$request_uri; <del> add_header Cache-Control "public, max-age=15778463"; add_header X-Content-Type-Options nosniff; add_header X-XSS-Protection "1; mode=block"; add_header X-Robots-Tag none; add_header X-Download-Options noopen; add_header X-Permitted-Cross-Domain-Policies none; add_header X-Frame-Options sameorigin; add_header Referrer-Policy no-referrer; </del> <ins> expires 6M; </ins> access_log off; ''; <del> "~ .(?:png|html|ttf|ico|jpg|jpeg|bcmap|mp4|webm)$".extraConfig = '' </del> <ins> "~ .woff2?$".extraConfig = '' </ins> try_files $uri /index.php$request_uri; <ins> expires 7d; </ins> access_log off; ''; <ins> "~ ^/(?:updater|ocs-provider|ocm-provider)(?:$|/)".extraConfig = '' try_files $uri/ =404; index index.php; ''; </ins> }; extraConfig = '' <ins> index index.php index.html /index.php$request_uri; expires 1m; </ins> add_header X-Content-Type-Options nosniff; add_header X-XSS-Protection "1; mode=block"; add_header X-Robots-Tag none;

Discussion:
Describe the bug Nextcloud tries to load several * files, but the nginx config redirects the user away. works redirects to Both files exist in the package: The map suffix needs to be here to make them work. I also get an endless spinner on the files tab, so the nginx config probably has more places where it is out of sync with the upstream docs. To Reproduce Steps to reproduce the behavior: nextcloud Browser console source map errors Expected behavior They should be accessible. Screenshots If applicable, add screenshots to help explain your problem. 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:
I also installed the maps application and it seems there are more routes missing. The file requested is located at , but I guess a more generic routes is warranted.
Change:
<del> { lib , stdenv , buildNpmPackage , fetchFromGitHub , pkg-config , python3 , pixman , libpng , libjpeg , librsvg , giflib , cairo , pango , nodePackages , makeWrapper , CoreText , nix-update-script }: buildNpmPackage rec { pname = "lv_img_conv"; version = "0.4.0"; src = fetchFromGitHub { owner = "lvgl"; repo = pname; rev = "refs/tags/v${version}"; hash = "sha256-LB7NZKwrpvps1cKzRoARHL4S48gBHadvxwA6JMmm/ME="; }; npmDepsHash = "sha256-uDF22wlL3BlMQ/+Wmtgyjp4CVN6sDnjqjEPB4SeQuPk="; nativeBuildInputs = [ pkg-config python3 makeWrapper ]; buildInputs = [ pixman libpng libjpeg librsvg giflib cairo pango ] ++ lib.optionals stdenv.isDarwin [ CoreText ]; postInstall = '' makeWrapper ${nodePackages.ts-node}/bin/ts-node $out/bin/lv_img_conv --add-flags $out/lib/node_modules/lv_img_conv/lib/cli.ts ''; passthru.updateScript = nix-update-script { }; meta = with lib; { changelog = "https://github.com/lvgl/lv_img_conv/releases/tag/v${version}"; description = "Image converter for LVGL"; homepage = "https://github.com/lvgl/lv_img_conv"; license = licenses.mit; maintainers = with maintainers; [ stargate01 ]; }; } </del>

Discussion:
Steps to reproduce the behavior: w/ channel check hydra: 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. -- ping :) Please run and paste the result.
Do you need this package? The original reason I it was to support building . Recently, that project has deprecated and instead uses their own tooling ( , "Replace the tool that convert the images (lvimgconv) by a custom re-implementation in Python"), so my use-case for this package has disappeared. I don't know what is causing this issue, I tried rebuilding the package with the most recent changes from its repo, but no success. I propose to mark this package as broken or remove it.
fascinating, you're right. I was using it to build infinitime too and have that working now by adding to my devShell's python environemnt. might just want to mark it as broken and move along then. cheers
Change:
else ''$(mktemp -t "${pname}-deps-XXXXXX.nix")''; storeSrc = srcOnly args; <del> projectFileStr = lib.escapeShellArg projectFiles; testProjectFileStr = lib.escapeShellArg testProjectFiles; </del> <ins> projectFileStr = lib.escapeShellArgs projectFiles; testProjectFileStr = lib.escapeShellArgs testProjectFiles; </ins> path = lib.makeBinPath [ coreutils runtimeShellPackage

Discussion:
I believe converted the following generated line of Bash: into: , so it's , and is the empty string; but when escaped, it became . The result is that the passthru does not generate a lockfile. After I manually change the two into in the definitions of and , I successfully start getting a NuGet restore. Failing passthru: Add any other context about the problem here. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Hm, that is weird. Note that cannot be null.
This should be (plural). Introduced in .
I even checked the implementation of and discovered that it's secretly a function rather than as documented, and didn't make the connection. I clearly need to go to sleep.
Change:
--replace 'exec' 'exec ${steam-run}/bin/steam-run' '' + '' wrapProgram $out/bin/XIVLauncher.Core --prefix GST_PLUGIN_SYSTEM_PATH_1_0 ":" "$GST_PLUGIN_SYSTEM_PATH_1_0" <ins> # the reference to aria2 gets mangled as UTF-16LE and isn't detectable by nix: https://github.com/NixOS/nixpkgs/issues/220065 mkdir -p $out/nix-support echo ${aria2} >> $out/nix-support/depends </ins> ''; executables = [ "XIVLauncher.Core" ];

Discussion:
Despite being referenced by the aria2c path patching step, xivlauncher's closure (as seen by running ) does not contain aria2, allowing it to be garbage collected if nothing else on the system requires it, breaking patch downloads if that happens. Steps to reproduce the behavior: xivlauncher into a profile. that patch downloads work. garbage collect the store, or wait until after an automatic collection. downloads now fail with an "path not found" error for aria2c. Workaround: Install aria2c to a profile explicitly, to ensure that it has a GC root. (ping per bug template instructions)
(My gut instinct here is that the process of compiling to CLR is, as an unintentional side effect, obfuscating the path enough that nix doesn't pick up on it, but I'm not sure how I'd go about verifying that, nor how to get nix to pick up the path anyway.)
argh, that's annoying. fixing the missing dependency should be fairly easy – you need to make a file as part of the xivlauncher build that contains the path to aria2c as ASCII/UTF-8 so that nix will see it. there's an idiomatic way to do this (ending up with a file under ), but I can't remember the details; if you feel like looking into it, feel free to open a PR, else I'll try to get around to it at some point.
ok, seems like maybe there is not actually an idiomatic way to do it...
Change:
{file = "idna-3.3.tar.gz", hash = "sha256:9d643ff0a55b762d5cdb124b8eaa99c66322e2157b69160bc32796e824360e6d"}, ] jmespath = [ <del> {file = "jmespath-1.0.0-py3-none-any.whl", hash = "sha256:e8dcd576ed616f14ec02eed0005c85973b5890083313860136657e24784e4c04"}, {file = "jmespath-1.0.0.tar.gz", hash = "sha256:a490e280edd1f57d6de88636992d05b71e97d69a26a19f058ecf7d304474bf5e"}, </del> <ins> {file = "jmespath-1.0.1-py3-none-any.whl", hash = "sha256:02e2e4cc71b5bcab88332eebf907519190dd9e6e82107fa7f83b1003a6252980"}, {file = "jmespath-1.0.1.tar.gz", hash = "sha256:90261b206d6defd58fdd5e85f478bf633a2901798906be2ad389150c5c60edbe"}, </ins> ] jsonpickle = [ {file = "jsonpickle-2.2.0-py2.py3-none-any.whl", hash = "sha256:de7f2613818aa4f234138ca11243d6359ff83ae528b2185efdd474f62bcf9ae1"},

Discussion:
Steps to reproduce the behavior: Please run and paste the result.
Looks like there is already a PR to address this at And fwiw I had to bisect this to fix my config, first bad commit is
Closing since the linked PR was merged. (Not sure why merge of the linked PR didn't close this...)
Change:
stdenv.mkDerivation rec { pname = "spice-gtk"; <del> version = "0.37"; </del> <ins> version = "0.40"; </ins> outputs = [ "out" "dev" "devdoc" "man" ]; src = fetchurl { <del> url = "https://www.spice-space.org/download/gtk/${pname}-${version}.tar.bz2"; sha256 = "1drvj8y35gnxbnrxsipwi15yh0vs9ixzv4wslz6r3lra8w3bfa0z"; </del> <ins> url = "https://www.spice-space.org/download/gtk/${pname}-${version}.tar.xz"; sha256 = "sha256-I/X/f6gLdWR85zzaXq+LMi80Mtu7f286g5Y0YYrbztM="; </ins> }; postPatch = '' # get rid of absolute path to helper in store so we can use a setuid wrapper substituteInPlace src/usb-acl-helper.c  --replace 'ACL_HELPER_PATH"/' '"' <ins> # don't try to setcap/suid in a nix builder substituteInPlace src/meson.build  --replace "meson.add_install_script('../build-aux/setcap-or-suid',"  "# meson.add_install_script('../build-aux/setcap-or-suid'," </ins> ''; nativeBuildInputs = [

Discussion:
A regular update fails because apparently won't find the module: (edit: line-wrapped for clarity) Please run and paste the result.
now I see that this is fixed by . I did my search before, but I haven't seen that one.
This PR is already on nixos-unstable, but I still cannot compile :
I had the same problem and can still reproduce on master building with the flake:
We need this upstream patch: freedesktop/spice-common
fixed , not . , like , pulls in as a Git submodule.
I just tried bumping spice-gtk to version 0.40 locally (like suggested by ) and it indeed passes that "check for dependencies" phase of the build. It fails later on though for reasons that I'm not familiar enough with the build process to understand. With this patch: I get the following build log:
the issue is still persisting after 4 days :(
Not directly, it's fixed on master (and stable branches I guess, it builds on nixos-21.11 for example), but nixos-unstable can't catch up right now because of another completely unrelated issue, see .
Change:
unnaturalscrollwheels = callPackage ../tools/inputmethods/unnaturalscrollwheels { }; <del> unrar = callPackage ../tools/archivers/unrar { }; </del> unrar-wrapper = python3Packages.callPackage ../tools/archivers/unrar-wrapper { }; uptime-kuma = callPackage ../servers/monitoring/uptime-kuma { };

Discussion:
Package name: unrar Latest released version: 7.00 beta 3 Current version on the unstable channel: 6.2.12 Current version on the stable/release channel: 6.2.12 I receive more and more RAR files which are created with Unrar 7.00 beta versions / require a more recent version tan 6.2.12 I would appreciated if the existing unrar package can be updated or a new unrar-beta package be proposed .. Changelog : Notify maintainers
There was an automatic update in that I marked as draft, exactly because it's in beta. I'd much rather add a new package. what do you think?
I don't think we should update to the beta either. Sometimes I think about adding beta and release candidate versions to package , but that would be a nixpkgs policy discussion.
If people are still creating new RAR files then I don't want to be maintainer of this package. Stop using RAR.
Change:
opendht = callPackage ../development/libraries/opendht {}; <del> opendkim = callPackage ../development/libraries/opendkim { }; </del> <ins> opendkim = callPackage ../development/libraries/opendkim { libbsd = libbsd-freedesktop; }; </ins> opendylan = callPackage ../development/compilers/opendylan { opendylan-bootstrap = opendylan_bin;

Discussion:
After , no longer compiles in . $ nix-build ~/src/nixpkgs --no-out-link -A opendkim Ping
Change:
lv = callPackage ../tools/text/lv { }; <del> lv_img_conv = callPackage ../development/tools/lv_img_conv  { inherit (darwin.apple_sdk.frameworks) CoreText; }; </del> lwc = callPackage ../tools/misc/lwc { }; lxd-image-server = callPackage ../tools/virtualization/lxd-image-server { };

Discussion:
Steps to reproduce the behavior: w/ channel check hydra: 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. -- ping :) Please run and paste the result.
Do you need this package? The original reason I it was to support building . Recently, that project has deprecated and instead uses their own tooling ( , "Replace the tool that convert the images (lvimgconv) by a custom re-implementation in Python"), so my use-case for this package has disappeared. I don't know what is causing this issue, I tried rebuilding the package with the most recent changes from its repo, but no success. I propose to mark this package as broken or remove it.
fascinating, you're right. I was using it to build infinitime too and have that working now by adding to my devShell's python environemnt. might just want to mark it as broken and move along then. cheers
Change:
after = [ "network-pre.target" "systemd-udevd.service" "systemd-sysctl.service" ]; before = [ "network.target" "shutdown.target" ]; wants = [ "network.target" ]; <del> partOf = map (i: "network-addresses-${i.name}.service") interfaces; </del> <ins> # exclude bridges from the partOf relationship to fix container networking bug #47210 partOf = map (i: "network-addresses-${i.name}.service") (filter (i: !(hasAttr i.name cfg.bridges)) interfaces); </ins> conflicts = [ "shutdown.target" ]; wantedBy = [ "multi-user.target" ] ++ optional hasDefaultGatewaySet "network-online.target";

Discussion:
Reported in -- couldn't find another relevant issue. The test stopped working after First failing run: It appears that the veth is no longer properly associated with the bridge after reconfiguration.
During reconfiguration the bridge interface is destroyed and then recreated with the same name but a new interface id (while the container network namespace is unchanged): Initial: After switching config:
I wonder if we should just let manage container networking. It is supposed to work pretty much out of the box with containers.
Here's what happens in terms of systemd units: restarts (makes sense) -stop due to the relationship introduced in . -stop due to a (correct) dependency. removes the interface despite the container veth is still associated with it.
I don't understand step 2. Why restart the entire networking setup because one address has changed? But we can't just revert because that it fixed a nixops bug unrelated to bridge interfaces. As a hack, we could skip deleting the bridge if a container veth is still associated with it.
Change:
''; homepage = https://gnunet.org/; <del> license = licenses.gpl2Plus; </del> <ins> license = licenses.agpl3Plus; </ins> maintainers = with maintainers; [ vrthra ]; platforms = platforms.gnu ++ platforms.linux; };

Discussion:
The release and git versions show gpl2+. It should be Affero GPL v3 or later. GNUnet is free software released under the GNU Affero General Public License (v3 or later).
Change:
buildPlatformLlvmStdenv.cc pkg-config libuuid <del> libpng # needed for "host/generate_colors_info" </del> <ins> (libpng.override { apngSupport = false; }) # needed for "host/generate_colors_info" </ins> ] # When cross-compiling, chromium builds a huge proportion of its # components for both the `buildPlatform` (which it calls

Discussion:
The for libpng is known to cause animated PNGs to flicker in Chromium, and (by extension) any app which uses Electron such as and (where the problem is much more noticeable since stickers on Discord are often animated PNGs, which is how I discovered this). Chromium itself includes a , which allows APNGs to be rendered properly with an unpatched libpng. The issue does not occur when Chromium or Electron is built against an unpatched libpng. , , and previously included this patch with their libpng packages, but (I think) removed them for this reason. Chromium definitely doesn't need this patch in any case, since it breaks things there. Edit: It looks like Chromium is supposed to be built against an unpatched libpng, so I'm not sure where it's still getting the patched version from, but using an overlay to disable the patch causes it to be fixed. Steps to reproduce the behavior: in Chromium the animated PNG flickering A clear and concise description of what you expected to happen. The PNG should not flicker. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --- system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Change:
}; "kicad-unstable" = { kicadVersion = { <del> version =			"2021-05-13"; </del> <ins> version =			"2021-05-16"; </ins> src = { <del> rev =			"8513ca974c28d76d9f74a7dc96601d98e66e87fd"; sha256 =		"1xlj6jwzwxsa14djqhj0csziii21mr9czvdj6fxqp6px84cifjsh"; </del> <ins> rev =			"c33b2cfa8d16072b9d1bce558e443c4afa889d06"; sha256 =		"1fvbxjpf880ikjqjhzj8wlxj0845gzrj1yv35rk7akbg4vl9ph72"; </ins> }; }; libVersion = { <del> version =			"2021-05-13"; </del> <ins> version =			"2021-05-16"; </ins> libSources = { i18n.rev =		"e89d9a89bec59199c1ade56ee2556591412ab7b0"; i18n.sha256 =		"04zaqyhj3qr4ymyd3k5vjpcna64j8klpsygcgjcv29s3rdi8glfl";

Discussion:
Describe the bug The kicad package installs a broken symlink to . This seems to be both on the commit the symlink was introduced in () and master (). It causes problems when installing this package via home-manager (see nix-community/home-manager and ). To Reproduce Expected behavior I expect the symlink to point to an existing file, or not exist. Notify maintainers Metadata Please run and paste the result. system: host os: multi-user?: sandbox: version: channels(kai): channels(root): nixpkgs: Maintainer information:
woeps, sorry, i that for kicad-unstable thinking it wouldn't affect the stable package to have a dead link there (at least i think that's the issue, i'll look into it in a few hours) (how does relate to this issue? it's an erlang related change, which i don't think affects kicad)
just to make sure you get notified i opened to fix this (i'm assuming you meant to point to rather than the erlang commit)
Thanks! I tagged because that was the latest commit on when I tested this, just in case it was fixed since.
Seems to be working now, thanks very much for the quick fix :)
Change:
license = licenses.lgpl21Plus; platforms = platforms.linux ++ platforms.darwin; maintainers = with maintainers; [ pyrolagus fpletz fgaz ]; <del> # https://github.com/NixOS/nixpkgs/pull/186160#issuecomment-1212635918 broken = stdenv.isDarwin; </del> }; };

Discussion:
minetest fails to run and reports Killed: 9 build minetest and run on macos aarch64 (I can't confirm if x86 is also broken). A clear and concise description of what you expected to happen. 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.
Change:
src = fetchurl { url = "https://dbeaver.io/files/${version}/dbeaver-ce-${version}-linux.gtk.x86_64.tar.gz"; <del> sha256 = "0ggay9igpqwq016yzfz2dw3cjhlzadaml0hi06iqzhxljr86qm44"; </del> <ins> sha256 = "1fnvwndzny51z0zmdnlafdcxawsyz435g712mc4bjjj29qy0inzm"; </ins> }; installPhase = ''

Discussion:
Describe the bug The dbeaver-ce-7.0.0 package has a hash mismatch To Reproduce nix-build -A dbeaver Screenshots Tested on master @
Change:
in modules // { <del> inherit python isPy26 isPy27 isPy33 isPy34 isPy35 isPyPy isPy3k pythonName buildPythonPackage; </del> <ins> inherit python isPy26 isPy27 isPy33 isPy34 isPy35 isPyPy isPy3k pythonName buildPythonPackage buildPythonApplication; </ins> # helpers

Discussion:
Most python packages seem to use a versioned prefix, e.g. python2.7-. Some modules don't, e.g. python-tkinter, python-pyaudio. I think all packages should use a versioned prefix (in contrast to apps, that should not use a prefix, see ). Having all packages use a versioned prefix we could also enable recursion for python2.6 and python3.2 though this might be a separate discussion.
This is still somewhat undocumented, packages in are versioned and others are not. I agree - all packages should be versioned and separatation should be based on app/module use case (which is also not always easy to determine)
Is this (mostly?) handled by the upcoming stuff?
Change:
# > The following imported targets are referenced, but are missing: # > SPIRV-Tools-opt ./cmakelists.patch <del> # Remove on next release # https://github.com/cemu-project/Cemu/pull/1076 (fetchpatch { url = "https://github.com/cemu-project/Cemu/commit/72aacbdcecc064ea7c3b158c433e4803496ac296.patch"; hash = "sha256-x+ZVqXgGRSv0VYwJAX35C1p7PnmCHS7iEO+4k8j0/ug="; }) </del> ]; nativeBuildInputs = [

Discussion:
Steps to reproduce the behavior: cemu In ImGui changelog for 1.90.2: <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --cc Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Always paste the full log or big parts from it, not just the short log.
my build log failure
apparently decided to ignore this build failure in . Not sure why we even have tests if we just blindly ignore them.
Change:
<ins> { buildPythonPackage, fetchPypi, setuptools, lib, pythonOlder, }: buildPythonPackage rec { pname = "pwinput"; version = "1.0.3"; pyproject = true; disabled = pythonOlder "3.7"; src = fetchPypi { inherit version; pname = "pwinput"; hash = "sha256-yhqL0G4ohy11Hb1BMthjcSfCW0COo6NJN3MUpUkUJvM="; }; build-system = [ setuptools ]; pythonImportsCheck = [ "pwinput" ]; # Requires graphical environment to use pyautogui doCheck = false; meta = { description = "Python module that masks password input"; homepage = "https://github.com/asweigart/pwinput"; license = lib.licenses.mit; maintainers = with lib.maintainers; [ bwkam ]; }; } </ins>

Discussion:
Project description A fast and customizable music and podcast downloader. Metadata homepage URL: source URL: license: zlib platforms: linux, darwin Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Change:
vendorHash = "sha256-ePhObvm3m/nT+7IyT0W6K+y+9UNkfd2kYjle2ffAd9Y="; <del> nativeBuildInputs = [ installShellFiles makeWrapper ]; </del> <ins> nativeBuildInputs = [ installShellFiles ]; </ins> outputs = [ "out"

Discussion:
The current package depends on wayland/x11, making its use in servers unnecessarily cumbersome. This is nothing a simple overlay can't help with, but that requires building the package from source and is yet another thing to learn for newbies (plus, some may not notice the dependencies and inadvertently end up putting wayland on their servers... ask me how I know :wink:). Would a separate (or similar name) package be worth it? (possibly, together with some options?) mantainers: Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
We have no explicit policy prohibiting green aliases. I will create something about this. On the other hand I do not see why creating a dedicated NixOS module for it - at least not now. You can merely throw it at environment.systemPackages and the effect will be the same.
concurrent effort ^
/ I would suggest a huge load of modifications in your idea, so here is my implementation:
Change:
These packages are manually refined in lua-overrides.nix */ <del> { self, lib, stdenv, fetchurl, fetchgit, pkgs, ... } @ args: </del> <ins> { self, stdenv, lib, fetchurl, fetchgit, pkgs, ... } @ args: </ins> self: super: with self; {

Discussion:
I tried adding to , then running and noticed in the diff this still uses , and non-string URLs. To Reproduce Steps to reproduce the behavior: Expected behavior The diff shouldn't contain non-string URLs, and not use via . Notify maintainers
luarocks-nix needs to be updated. Its current state is messy (not clear which branch to use), I will update it.