jiebi/CodeConvo huggingface dataset:
Change:
pname = "wlsunset"; version = "0.1.0"; <del> src = fetchurl { url = "https://git.sr.ht/~kennylevinsen/wlsunset/archive/${version}.tar.gz"; sha256 = "0g7mk14hlbwbhq6nqr84452sbgcja3hdxsqf0vws4njhfjgqiv3q"; </del> <ins> src = fetchFromSourcehut { owner = "~kennylevinsen"; repo = pname; rev = version; sha256 = "12snizvf49y40cirhr2brgyldhsykv4k2gnln2sdrajqzhrc98v6"; </ins> }; nativeBuildInputs = [ meson pkg-config ninja wayland ];

Discussion:
Describe the bug Sources from archives from fail to download with hash mismatches. To Reproduce Expected behavior The hash should match and the source should download. Additional context It sounds like , causing changes to all generated archives (to come in-line with GNU gzip). I've determined some packages which this affects (listed in "Maintainer information") by . I'm happy to have a go making a PR for all of these packages with the following process: archive from cache (by with subsituters) archive from both and confirm tar files are identical hash according to newly retrieved archive But if there's a better process, please let me know :) Notify maintainers Metadata system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Maintainer information:
Sounds good
I think it is preferable to switch all affected derivations to fetchzip. This should prevent this from happening again, if the actual content of the tarball is the same. Even better, you could add a fetchFromSourceHut function which uses fetchzip under the hood, like fetchFromGitHub and fetchFromGitLab. This would encourage people not to use fetchurl to fetch procedurally generated tarballs from sourcehut.
From a quick look at the ticket, this is supposed to be a one-time change to make the hash the same as in other forges though
I think getting the new hashes with e.g. should be enough (fetches securely via HTTPS and we should be able to trust that the contents remain unchanged). +1, that seems like the best (long-term) solution. Edit: And IMO we should keep using archives (e.g. because it's consistent with the GitHub and GitLab fetchers) and should indeed be fine now:
the point is: with fetchzip, we don't have to trust this pinky promise (I mean, I'm sure that they intend to keep it, but it could break unwillingly). That's exactly why fetchzip exists in the first place. So on fixes keeping fetchurl.
oh, my bad, I didn't read your comment carefully enough :o I thought you've meant vs. (which didn't make much sense) but realized now that it was vs. . :+1: for that then :)
Hah, same. too then
is merged now so you could submit a PR to switch the affected attributes/packages to the new (s. ). I can also take care of it if you want.
Change:
}; patches = [ ./absolute-paths.diff <ins> # fix reproducibile output, in particular in the grub2 build # https://savannah.gnu.org/bugs/index.php?59658 ./0001-msginit-Do-not-use-POT-Creation-Date.patch </ins> ] ++ lib.optional stdenv.hostPlatform.isWindows (fetchpatch { url = "https://aur.archlinux.org/cgit/aur.git/plain/gettext_formatstring-ruby.patch?h=mingw-w64-gettext&id=e8b577ee3d399518d005e33613f23363a7df07ee"; name = "gettext_formatstring-ruby.patch";

Discussion:
Building this package twice does not produce the bit-by-bit identical result each time, making it harder to detect CI breaches. You can read more about this at https://reproducible- . Fixing bit-by-bit reproducibility also has additional advantages, such as avoiding hard-to-reproduce bugs, making content-addressed storage more effective and reducing rebuilds in such systems. You can use to analyze the differences in the output of the two builds. To view the build log of the build that produced the artifact in the binary cache: possibly related:
I think we haven't hit this problem before (with 2.06) because the files are usually distributed along with the source tarball. Now (with 2.12-rc1) that we've switched to a git checkout the derivation is building the files itself, and I suspect we're either not doing it right, or we're missing part of the process.
(Fixing gettext's reproducibility is also likely an acceptable solution - but I suspect there's a more targeted and less controversial fix we could just apply to grub2 directly.)
should be fixed with on staging - if we can do something to grub2 to fix it 'more targeted and less controversial' that's still fine, but might not be needed
Change:
# 3. Ansible being unable to upgrade to a later version of resolvelib # see here for more details: https://github.com/NixOS/nixpkgs/pull/155380/files#r786255738 packageOverrides = self: super: { <ins> installer = super.installer.overridePythonAttrs (attrs: rec { version = "0.6.0"; src = fetchFromGitHub { owner = "pradyunsg"; repo = "installer"; rev = version; hash = "sha256-IXznSrc/4LopgZDGFSC6cAOCbts+siKpdl5SvN1FFvA="; }; }); </ins> resolvelib = super.resolvelib.overridePythonAttrs (attrs: rec { version = "0.9.0"; src = fetchFromGitHub {

Discussion:
Steps to reproduce the behavior: pdm flake nixpkgs: Please run and paste the result.
Change:
version ? package.version, }: runCommand "${package.name}-test-version" { nativeBuildInputs = [ package ]; meta.timeout = 60; } '' if output=$(${command} 2>&1); then <del> if grep -Fw "${version}" - <<< "$output"; then </del> <ins> if grep -Fw -- "${version}" - <<< "$output"; then </ins> touch $out else echo "Version string '${version}' not found!" >&2

Discussion:
fails when the version string begins with - or --. The tester uses grep to find a version string within a command's output and, in these cases, it's being treated as an option. If we wanted to test hello supports --greeting, we might try this: This test fails with Similar errors occur with single hyphens. This test should pass since --greeting is within hello --help. An easy fix might be to add a -- sentinel argument.
Change:
add_header X-Permitted-Cross-Domain-Policies none; add_header X-Frame-Options sameorigin; add_header Referrer-Policy no-referrer; <del> add_header Strict-Transport-Security "max-age=15552000; includeSubDomains" always; </del> <ins> ''} ${optionalString (cfg.https) '' add_header Strict-Transport-Security "max-age=${toString cfg.nginx.hstsMaxAge}; includeSubDomains" always; </ins> ''} client_max_body_size ${cfg.maxUploadSize}; fastcgi_buffers 64 4K;

Discussion:
The header should only be if is enabled, right?
I don't think so. The description for that option says "Use https for generated links." The commit you linked is from last Feburary (which may be the version in NixOS 21.11 – I'm not sure), and on , that header is controlled by the boolean option . The upstream project recommendes this header, as far as I can tell, and the Nextcloud admin panel warns you if this is not set, so I think it is semantically correct for this header to be if the "recommended HTTP headers" flag is set, but it does get in the way if you are trying to serve Nextcloud as a Tor .onion service, where you don't want to be using SSL/TLS.
Good to hear that it is different in master, but it is not just onion services, many internal services lack tls because the vpn or tls termination is done downstream and nextcloud only speaks http. I would expect we want a single boolean to turn on/off tls, no?
I had not thought of that use case. I would say that is a good reason to have this controlled by the same flag.
Change:
buildPythonPackage rec { pname = "pytest-freezer"; <del> version = "0.4.6"; </del> <ins> version = "0.4.8"; </ins> format = "pyproject"; disabled = pythonOlder "3.6";

Discussion:
Failure happens locally as well when trying to build spotdl on the nixos-23.05 branch. this the tail of the log: The last line is apparently unrelated: (maintainer) (recent bumps)
This test doesn't fail if spotdl is built using version from this nixpkgs commit , I'm not sure if this is an upstream issue with spotdl while using newer yt-dlp versions (newer than ).
Change:
patch = "ffs_no_check_updates.patch"; hash = "sha256-lPyHpxhZz8BSnDI8QfAzKpKwVkp2jiF49RWjKNuZGII="; }) <ins> # Fix build with curl 8.6.0 ./curl-8.6.0.patch </ins> ]; nativeBuildInputs = [

Discussion:
Steps to reproduce the behavior: freefilesync Just tried to update to current nixos-unstable and got hit with this build error for freefilesync. <!-- 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]:
Change:
# socket cannot bind to localhost on darwin for tests doCheck = !stdenv.isDarwin; <del> # needed until upstream bumps to dotnet 7 </del> <ins> # net7.0 replacement needed until upstream bumps to dotnet 7 </ins> postPatch = '' substituteInPlace OpenUtau/OpenUtau.csproj OpenUtau.Test/OpenUtau.Test.csproj --replace  '<TargetFramework>net6.0</TargetFramework>'  '<TargetFramework>net7.0</TargetFramework>' <ins> substituteInPlace OpenUtau/Program.cs --replace  '/usr/bin/fc-match'  '${lib.getExe' fontconfig "fc-match"}' </ins> ''; # need to make sure proprietary worldline resampler is copied

Discussion:
Package name: openutau Latest released version: Current version on the unstable channel: 0.1.158 Current version on the stable/release channel: - Notify maintainers I don't mind sending a PR to bump the version. I've tried building OpenUtau-0.1.201 on my device, and it works just like the previous instances. The app, however, crashes, when I use any key, just like the current version, for which I've created stakira/OpenUtau. Note for maintainers: Please tag this issue in your PR.
That version is marked as a beta/pre-release upstream. I don't mind bumping to that version if it fixes things for you, though
actually, I don't have a Mac, so I also wanted to make sure that bumping this didn't cause any issue with other platforms out there. Looks like the app-crash behavior still exists in the newer version on Linux.
Slightly out of topic, but if license is going to be an issue, would it be okay for you to add and instead? They're both open-source compatible. They may have to be as plugins for OpenUtau. In the same spirit, we can also make Worldline-R a plugin.
License isn't an issue for me, but I'll try later to see if I can't make a derivation without the proprietary bits if it's a concern for you I vaguely recall thinking the code always expects to find the worldline .so, though, so I'll have to double check what that would take later
Alternatively, if upstream could clarify in-writing the license situation for the (e.g. as unfree source but freely redistributable) then that could also be sufficient for your use-case
Fix for crashes is in and license question has been asked at
Also given your interest in this package, would you like to be a co-maintainer for the OpenUtau derivation in nixpkgs?
I don't have any experience with C# and dotnet applications, but if it involves only bumping the version and removing the temporary patches for dotnet and Avalonia 11.0.4, I could do that.
It's up to you!

I'm happy to have assistance for bumps and stuff if nothing else, but you don't have to add yourself as maintainer unless you want to :)
I have no issue with adding myself as the co-maintainer, but it looks like you'd have to wait for to get merged, because I've myself there in the . file
License update in too now, btw
Change:
pkg-config ]; <del> postPatch = '' substituteInPlace adapter/protocol/man  --replace-fail "OUT" $out ''; </del> <ins> buildInputs = [ curlMinimal libseccomp ncurses zlib ]; </ins> buildFlags = [ "all" "manpage" ]; installFlags = [

Discussion:
Steps to reproduce the behavior: chawan () Related to 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]:
Change:
addGstreamer1LibPath () { if test -d "$1/lib/gstreamer-1.0" then <del> export GST_PLUGIN_SYSTEM_PATH_1_0="${GST_PLUGIN_SYSTEM_PATH_1_0-}${GST_PLUGIN_SYSTEM_PATH_1_0:+:}$1/lib/gstreamer-1.0" </del> <ins> addToSearchPath GST_PLUGIN_SYSTEM_PATH_1_0 "$1/lib/gstreamer-1.0" </ins> fi } addEnvHooks "$hostOffset" addGstreamer1LibPath

Discussion:
According to the GStreamer website, the "good" plugins package should contain the "soup" plugin. However, the nix package does not. Steps to reproduce the behavior: packages and Result: nothing found. As a result, cannot play any streams, failing with "could not create souphttpsrc element". should include . : : Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
please try and see if that fixes the problem for radiotray-ng
This fixes the problem for , thanks. Does this mean that is OK?
not really, in my opinion as it doesn't work out of the box. there was a PR to partially fix gstreamer but seems like it was missing glib-networking and didn't want to add it for some reason and was abandoned. if the gstreamer pkg isn't modified then adding glib-networking and libsoup to the ldlibrarypath is a work around.
The issue title is misleading. The loading of the library is broken but gst-plugins-good is actually compiled against libsoup.
Change:
openvdb = callPackage ../development/libraries/openvdb {}; inherit (callPackages ../development/libraries/libressl { }) <del> libressl_3_1 </del> libressl_3_2; # Please keep this pointed to the latest version. See also

Discussion:
, CVSSv3=7.1 (nixos-21.05, nixos-unstable) CVSSv3=7.1 (nixos-21.05, nixos-unstable) LibreSSL 2.9.1 through 3.2.1 has a heap-based buffer over-read in doprintex (called from asn1itemprintctx and ASN1itemprint). LibreSSL 2.9.1 through 3.2.1 has an out-of-bounds read in asn1itemprintctx (called from asn1templateprint_ctx). Scanned versions: nixos-21.05: ; nixos-unstable: . Cc Cc
It looks like is the only vulnerable version in nixpkgs. I can't find any packages that rely on it:
removing the affected version from nixpkgs would probably the right thing to do.
Change:
build -D CSM_ENABLE -D FD_SIZE_2MB ${if secureBoot then "-DSECURE_BOOT_ENABLE=TRUE" else ""} ''; <ins> postFixup = '' mkdir -p $fd/FV mv $out/FV/OVMF{,_CODE,_VARS}.fd $fd/FV ''; dontPatchELF = true; </ins> meta = { description = "Sample UEFI firmware for QEMU and KVM"; homepage = http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=OVMF;

Discussion:
In , I introduced support in libvirtd for UEFI VM creation. rightfully remarked that this brings closure-size up too much. Looking into OVMF shows that only 1MB out of the 114MB install size is needed to enable said UEFI VM creation. I think that we should look into splitting out OVMF_(CODE|VARS) from the rest package.
Change:
{ lib , stdenv , fetchFromGitHub <del> , pkg-config , cmake </del> , alsa-lib <ins> , cmake </ins> , ffmpeg , game-music-emu <ins> , libXv </ins> , libass , libcddb , libcdio , libpulseaudio , libsidplayfp , libva <del> , libXv , taglib </del> <ins> , pkg-config </ins> , qtbase , qttools <ins> , taglib </ins> , vulkan-headers , vulkan-tools , wrapQtAppsHook }: <del> stdenv.mkDerivation rec { </del> <ins> stdenv.mkDerivation (self: { </ins> pname = "qmplay2"; <del> version = "22.08.21"; </del> <ins> version = "23.02.05"; </ins> src = fetchFromGitHub { owner = "zaps166"; repo = "QMPlay2"; <del> rev = version; sha256 = "sha256-UQf1aJGoUlXBo2lejw8A3lF6rFOKK6LUGDxRY9207Dw="; </del> <ins> rev = self.version; sha256 = "sha256-ZDpUgD9qTvjopGFVrwTBSEmrXn+4aKq2zeqoTnXwmI8="; </ins> fetchSubmodules = true; };

Discussion:
Package name: Latest released version: <!-- Search your package here: --- Current version on the unstable channel: Current version on the stable/release channel: <!-- 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:
serviceConfig = { Type = "forking"; Restart = "on-failure"; <del> # We need to start as root so bird can open netlink sockets i.e. for ospf ExecStart = "${pkgs.bird}/bin/bird -c /etc/bird/bird2.conf -u bird2 -g bird2"; ExecReload = "/bin/sh -c '${pkgs.bird}/bin/bird -c /etc/bird/bird2.conf -p && ${pkgs.bird}/bin/birdc configure'"; </del> <ins> User = "bird2"; Group = "bird2"; ExecStart = "${pkgs.bird}/bin/bird -c /etc/bird/bird2.conf"; ExecReload = "${pkgs.bird}/bin/birdc configure"; </ins> ExecStop = "${pkgs.bird}/bin/birdc down"; RuntimeDirectory = "bird"; <del> CapabilityBoundingSet = [ "CAP_CHOWN" "CAP_FOWNER" "CAP_SETUID" "CAP_SETGID" "CAP_NET_ADMIN" "CAP_NET_BROADCAST" "CAP_NET_BIND_SERVICE" "CAP_NET_RAW" ]; </del> <ins> CapabilityBoundingSet = caps; AmbientCapabilities = caps; </ins> ProtectSystem = "full"; ProtectHome = "yes"; ProtectKernelTunables = true;

Discussion:
Reloading bird2.service fails due to permission denied when connecting to control socket. services.bird2 reload bird2 failed, permission denied show up in the log or just run with this patch applied service reloads successfully This seems to be a regression introduced by <!-- 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.
By adding CAPDACOVERRIDE to CapabilityBoundingSet, it reloads successfully. Guess we now know why it was there in the first place.
Change:
<ins> diff -Naur teapot-2.3.0-old/scanner.c teapot-2.3.0-new/scanner.c --- teapot-2.3.0-old/scanner.c	1969-12-31 21:00:01.000000000 -0300 +++ teapot-2.3.0-new/scanner.c	2021-11-25 17:46:49.936673391 -0300 @@ -25,6 +25,7 @@ #include "main.h" #include "misc.h" #include "scanner.h" +#include "utf8.h" /*}}}*/ /* identcode  -- return number of identifier */ /*{{{*/ </ins>

Discussion:
Project description Teapot is an interesting project that implements a compact spreadsheet in roughly 140k, with the following features: UI: Ncurses terminal UI, FLTK windowed GUI, and a batch processing mode all available. Cell Syntax: Cell locations represented as lists of coordinates. Eg, instead of "B1" or "R1C2", cells are referenced as " Three Dimensions: This 3-coordinate style adds a third dimension to the spreadsheet, reducing the need for hiding columns or rows of intermediate results as is sometimes the case in traditional spreadsheets, among other things. Relative References: This also enables both relative cell and relative formula references that make refactoring the spreadsheet easier. Type-Safety: All values have a type, and all operations and formulas check types. No more adding a float to a string and getting a (probably undesirable) result. Iterative Expressions: Modeled on clocked expressions, these solve problems with circular dependencies in traditional spreadsheets and effectively make teapot Turing-complete. Platform-Independent File format: Defined by XDR and portable across machines, especially floating point representation that may differ across platforms Legacy File format support: Portable ASCII file format, standard CSV, SpreadsheetCalculator SC and Lotus 1-2-3 WK1 format. Extensibility: Easily extended by new functions in C. Internationalization: Can be internationalized and comes with English, Dutch, German and Polish message catalogs. Interoperability: Interfaces to troff/tbl, LATEX, HTML and CSV which are well-suited for further processing, be it graphing, typesetting, accounting or anything else. Metadata homepage URL: source URL: (bottom of page) license: GPL3 platforms: unix, linux, darwin
I tried to build this from source, but I'm getting an issue with it. Here is what I did so far, in case someone wants to try it: I am going to try with the deb and see if it works.
I got the deb working successfully (even created a desktop entry for the GUI client, although no icon). I'm going to keep trying with the source today (it is an issue regarding mbslen not being recognized), but if I can't get that, then I will post the working one.
is just a warning, it can be fixed with a simple patch.

The more serious problems are compiling with FLTK support and build the docs. Maybe more patches are needed. (On the other hand, it can be useful to package the already-given binary targz.)
Change:
mesa xorg.libXrandr libxcb <ins> libglvnd </ins> ]; cmakeFlags = [

Discussion:
Sunshine fails to run when is unavailable () Run , observe warning about failure to load , then a segfault. Adding in an override with fixes it, but I don't know the area well enough to know if this is the correct fix, I just saw this was the package the previous versions had a normal dynamic link against, while 0.21 appears to only access it via . Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Thanks! I totally missed this warning. Working for me too -- opened to resolve.
Change:
}: buildPythonPackage rec { pname = "mkdocs-awesome-pages-plugin"; <del> version = "2.9.2"; </del> <ins> version = "2.9.3"; </ins> pyproject = true; disabled = pythonOlder "3.9";

Discussion:
Steps to reproduce the behavior: command, mkdocs-awesome-pages-plugin is only available in unstable, so pinned to a recent build hash to ensure reproducibility, but fails with fails the same way for python3, python311 and python312
Hello & thanks for the report. Can confirm the package is broken, presumably since the latest python-updates merge but not entirely sure yet. Tests were passing fine when the package was about a month ago.
Seems to be related to the mkdocs update to 1.6.0. I filed an upstream issue to track
Thanks very much for looking into this so quickly and passing it on to upstream. I figured it worked when you originally created it, but that confirmation suggests a work-around until upstream fixes things. So now I just have to figure out how to get a channel hash from that far back. only tracks the most recent few.
Unfortunately, building from the merge commit does not solve the problem: This shouldn't be too surprising since it still pulls the same version of the plugin, but I figured it would be worth a try as a possible work-around.
It's not about the plugins versions, but about the mkdocs version used. If you want to build the plugin with an older mkdocs while using a current nixpkgs, you could do something like the following:
I can confirm that this works for the use-case that this bug was originally created to resolve. Since this was first tested, there has been another nixpkgs-unstable build reported on that could be used (with the more compact fetchTarball buildtin) instead of the merge commit hash, but the most recent one has a "Build problem" badge, so I stuck with the merge hash for reporting. Thanks very much for getting this done so quickly. Also the work-around derivation snippet you provided was above and beyond the call of duty. I would not have been able to get that syntax right myself at this stage in my Nix journey. Unfortunately, it conflicted with some other plugins I was using, but I still learned a lot from it. Thanks again, I appreciate your efforts .
Glad it helped, it can be rough to know where to start! Since the update has been merged to master only yesterday, but it's already in nixpkgs-unstable!

When hydra has finished to run nixos tests, nixos-unstable will be updated to include the fix for mkdocs-awesome-plugin automatically. One can check which branches it hit already at
Change:
, gtkspell2, aspell , gst_all_1, startupnotification, gettext , perlPackages, libxml2, nss, nspr, farstream <del> , libXScrnSaver, ncurses, avahi, dbus, dbus-glib, intltool, libidn , lib, python, libICE, libXext, libSM </del> <ins> , libXScrnSaver, avahi, dbus, dbus-glib, intltool, libidn , lib, python3, libICE, libXext, libSM , libgnt, ncurses </ins> , cyrus_sasl ? null , openssl ? null , gnutls ? null

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;