jiebi/CodeConvo huggingface dataset:
Change:
, gnomeSupport ? false, gnome, makeWrapper , libimobiledevice, libbluray, libcdio-paranoia, libnfs, openssh , libsecret, libgdata <ins> # Remove when switching back to meson , autoreconfHook, lzma, bzip2 </ins> }: <ins> # TODO: switch to meson when upstream fixes a non-deterministic build failure # See https://bugzilla.gnome.org/show_bug.cgi?id=794549 # Meson specific things are commented out and annotated, so switching back # should simply require deleting autotools specific things and adding back meson # flags etc. </ins> let pname = "gvfs"; version = "1.36.0";

Discussion:
Upstream bug: Random hydra log: We should probably switch back to autotools as suggested until it's fixed upstream? Or would turning parallel building off fix it too? cc
Sounds good to me.
Change:
nodes.machine = { config, ... }: { environment.etc."guix/scripts".source = ./scripts; <del> services.guix.enable = true; </del> <ins> services.guix = { enable = true; gc.enable = true; }; </ins> }; testScript = ''

Discussion:
The guix-gc.service doesn't work. Steps to reproduce the behavior: in `systemctl status guix-gc.service I think this is because the JIT needs write and execute permissions but the service disallows it with . I changed it to and it works now. The guix-gc service should run normally and collect the garbage. Please run and paste the result. system: host os: multi-user?: sandbox: version: channels(root): channels(maxsilvester): nixpkgs: Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
I can reproduce the error and so does the fix. Thank you for reporting!
Change:
{ lib , lua , wrapLua <del> , luarocks </del> <ins> , luarocks_bootstrap </ins> , writeTextFile # Whether the derivation provides a lua module or not.

Discussion:
luarocks exists that other luarocks packages can depend on. When trying to build a rockspec that depends on luarocks with , it fails. The entry in the generated luarocks config contains an entry for luarocks, but luarocks doesn't recognise it and tries to download the package instead. I have created a repository to reproduce it with: Run A workaround is to use to generate a expression for luarocks (), and to add that package to the 's instead of the package from nixpkgs. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
thanks for creating the test repo, it's helpful. I've looked at the generated LUAROCKSCONFIG and all looks good and I think luarocks just doesn't recognize the installed luarocks because of My first thought would have been to rename the current luarocks into a luarocksbootstrap and add a generated derivation, for which we could run the tests without the cyclic dependency luarocks -busted -luarocks. While this might be the best outcome longterm, I am looking into the quickfix which would be to generate the manifest for the current luarocks
Change:
python3.pkgs.buildPythonApplication rec { pname = "typstwriter"; <del> version = "0.1"; </del> <ins> version = "0.2"; </ins> pyproject = true; src = fetchFromGitHub { owner = "Bzero"; repo = "typstwriter"; rev = "V${version}"; <del> hash = "sha256-xgBBZTViMzYgxaYb24druUwLqVWdf9utCETC+goLqYk="; </del> <ins> hash = "sha256-LhK1e6q7nmk13ZW55/1uEKhg7stQLIs+2bdFJDc24bg="; </ins> }; build-system = [ python3.pkgs.flit-core ];

Discussion:
Package name: typstwriter Latest released version: 0.2 <!-- Search your package here: --- Current version on the unstable channel: 0.1 Current version on the stable/release channel: none <!-- 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. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Change:
buildGoModule { pname = "ncdns"; <del> version = "unstable-2022-10-07"; </del> <ins> version = "unstable-2024-05-18"; </ins> <del> src = x509; vendorHash = "sha256-ENtTnDsz5WhRz1kiqnWQ5vyEpZtgi7ZeYvksffgW78k="; # Override the goModules fetcher derivation to apply # upstream's patch of the crypto/x509 library. modBuildPhase = '' go mod init github.com/namecoin/x509-compressed go generate ./... go mod tidy </del> <ins> src = fetchFromGitHub { owner = "namecoin"; repo = "ncdns"; rev = "8a9f7c3037384f12fae400268d0a7f79d26b5532"; hash = "sha256-lFpjfpOAgvYoV3ci2oSdy8ZOlQ2rWlApiFWcvOMdkyk="; }; </ins> <del> cd ncdns go mod init github.com/namecoin/ncdns go mod edit  -replace github.com/coreos/go-systemd=github.com/coreos/go-systemd/v22@latest  -replace github.com/namecoin/x509-compressed=$NIX_BUILD_TOP/source go mod tidy </del> <ins> # Note: to update ncdns add the following lines # #   chmod -R +w . #   go mod tidy #   cat go.mod go.sum #   exit 1 # # to the `preBuild` here and update the lock files preBuild = '' # Sideload the generated x509 module ln -s '${x509}' x509 </ins> ''; <del> # Copy over the lockfiles as well, because the source # doesn't contain it. The fixed-output derivation is # probably not reproducible anyway. modInstallPhase = '' mv -t vendor go.mod go.sum cp -r --reflink=auto vendor "$out" ''; </del> <ins> vendorHash = "sha256-FoCK2qkhbc+6D4V77pNLiC9d68nkeYJxb7uiNYEP2Xw="; </ins> buildInputs = [ libcap ]; <del> # The fetcher derivation must run with a different # $sourceRoot, but buildGoModule doesn't allow that, # so we use this ugly hack. unpackPhase = '' runHook preUnpack </del> <ins> patches = [./fix-tpl-path.patch ]; </ins> <del> unpackFile "$src" sourceRoot=$PWD/source/ncdns chmod -R u+w -- "$sourceRoot" cd $sourceRoot runHook postUnpack ''; # Same as above: can't use `patches` because that would # be also applied to the fetcher derivation, thus failing. patchPhase = '' runHook prePatch patch -p1 < ${./fix-tpl-path.patch} runHook postPatch ''; preBuild = '' chmod -R u+w vendor mv -t . vendor/go.{mod,sum} </del> <ins> # Put in our own lockfiles postPatch = '' cp ${./ncdns-go.mod} go.mod cp ${./ncdns-go.sum} go.sum </ins> ''; preCheck = '' # needed to run the ncdns test suite <del> ln -s $PWD/vendor ../../go/src </del> <ins> ln -s $PWD/vendor ../go/src </ins> ''; postInstall = ''

Discussion:
Steps to reproduce the behavior: ncdns.goModules with or 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]:
The goModules derivation can't be built since go 1.17, see I don't think I can fix it.
Change:
vendorSha256 = "sha256-q3dDV0eop2NxXHFrlppWsZrO2Hz1q5xhs1DnB6PvG9g="; <ins> buildFlagsArray = '' -ldflags= -s -w -X main.Version=v${version} -X main.DefaultBuildkitdImage=earthly/buildkitd:v${version} -extldflags -static ''; BUILDTAGS = "dfrunmount dfrunsecurity dfsecrets dfssh dfrunnetwork"; preBuild = '' makeFlagsArray+=(BUILD_TAGS="${BUILDTAGS}") ''; </ins> postInstall = '' mv $out/bin/debugger $out/bin/earthly-debugger mv $out/bin/shellrepeater $out/bin/earthly-shellrepeater

Discussion:
Describe the bug prints some information that misses the actual version can't do anything as it doesn't know what buildkit image to use Expected behavior version is properly printed knows the default image Additional context earthly/earthly Notify maintainers Metadata Maintainer information:
trying to add them now
Do you mind mentioning me in the PR? Sadly GitHub doesn't notify me about mentions of my tickets :(
okay i will when i make it
Change:
<del> { lib, stdenv, fetchurl, makeWrapper , python3, perl, textual-window-manager , gettext, vim, bc, screen }: let pythonEnv = python3.withPackages (ps: with ps; [ snack ]); in stdenv.mkDerivation rec { version = "5.133"; pname = "byobu"; src = fetchurl { url = "https://launchpad.net/byobu/trunk/${version}/+download/byobu_${version}.orig.tar.gz"; sha256 = "0qvmmdnvwqbgbhn5c8asmrmjhclcl029py2d2zvmd7h5ij7s93jd"; }; doCheck = true; strictdeps = true; nativeBuildInputs = [ makeWrapper gettext ]; buildInputs = [ perl ]; # perl is needed for `lib/byobu/include/*` scripts propagatedBuildInputs = [ textual-window-manager screen ]; postPatch = '' substituteInPlace usr/bin/byobu-export.in  --replace "gettext" "${gettext}/bin/gettext" substituteInPlace usr/lib/byobu/menu  --replace "gettext" "${gettext}/bin/gettext" ''; postInstall = '' # Byobu does not compile its po files for some reason for po in po/*.po; do lang=''${po#po/} lang=''${lang%.po} # Path where byobu looks for translations as observed in the source code and strace mkdir -p $out/share/byobu/po/$lang/LC_MESSAGES/ msgfmt $po -o $out/share/byobu/po/$lang/LC_MESSAGES/byobu.mo done # Override the symlinks otherwise they mess with the wrapping cp --remove-destination $out/bin/byobu $out/bin/byobu-screen cp --remove-destination $out/bin/byobu $out/bin/byobu-tmux for i in $out/bin/byobu*; do # We don't use the usual ".$package-wrapped" because arg0 within the shebang scripts # points to the filename and byobu matches against this to know which backend # to start with file=".$(basename $i)" mv $i $out/bin/$file makeWrapper "$out/bin/$file" "$out/bin/$(basename $i)" --argv0 $(basename $i)  --set BYOBU_PATH ${lib.escapeShellArg (lib.makeBinPath [ vim bc ])}  --set BYOBU_PYTHON "${pythonEnv}/bin/python" done ''; meta = with lib; { homepage = "https://launchpad.net/byobu/"; description = "Text-based window manager and terminal multiplexer"; longDescription = ''Byobu is a GPLv3 open source text-based window manager and terminal multiplexer. It was originally designed to provide elegant enhancements to the otherwise functional, plain, practical GNU Screen, for the Ubuntu server distribution. Byobu now includes an enhanced profiles, convenient keybindings, configuration utilities, and toggle-able system status notifications for both the GNU Screen window manager and the more modern Tmux terminal multiplexer, and works on most Linux, BSD, and Mac distributions. ''; license = licenses.gpl3; platforms = platforms.unix; maintainers = with maintainers; [ qknight berbiche ]; }; } </del>

Discussion:
Package name: Byobu Latest released version: 6.12Current version on the unstable channel: 5.133 Current version on the stable/release channel: 5.133 Byobu development has permanently moved from Launchpad to GitHub Note for maintainers: Please tag this issue in your PR. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
pinging and as maintainers
Change:
./services/databases/virtuoso.nix ./services/desktops/accountsservice.nix ./services/desktops/bamf.nix <ins> ./services/desktops/blueman.nix </ins> ./services/desktops/deepin/deepin.nix ./services/desktops/dleyna-renderer.nix ./services/desktops/dleyna-server.nix

Discussion:
Blueman package cannot just be used from when installing it from user. It is expected to be an OS level service. See: We should have a NixOS module for it: . Try installing blueman using nix-env and then run .
should work when is enabled. Have you tried it?
When did this happen? I had the same problem as rycee/home-manager
Where does this mention blueman?
Change:
cmake lmdbxx pkg-config <ins> wrapQtAppsHook </ins> ]; buildInputs = [

Discussion:
Steps to reproduce the behavior: i noticed the break after the nheko 0.10.2 -0.11.0 upgrade landed in nixos-unstable: hydra failure (click for the build log): build is currently broken in both master () and has been fixed in nixos-22.11, see for having initiated the backport. tagging as maintainer of both mtxclient and nheko. Please run and paste the result.
tested against the outstanding mtxclient 0.9.0 -0.9.1 PR: still broken.
I have no idea why a standard library would depend, let alone be missing, on a different architecture.
Likely due to us using outdated gcc (gcc9) on aarch64-linux. The story is complicated, but is being addressed.
Forcing it to use gcc11Stdenv may fix the issue.
It seems so: I tested by cross-compiling mtxclient (I don't have an aarch64 system).
Opened
Great... now coeurl fails to build. EDIT: Fixed, but nheko is still broken.
hope nobody minds this extra notification that is me thanking you all for jumping in so readily to fix things, even for someone you’ve never met. anyone reading this: what you’re doing here has more impact than you know.
Change:
stdenv.mkDerivation rec { pname = "threema-desktop"; <del> version = "1.2.27"; </del> <ins> version = "1.2.31"; </ins> src = fetchurl { # As Threema only offers a Latest Release url, the plan is to upload each # new release url to web.archive.org until their Github releases page gets populated. <del> url = "https://web.archive.org/web/20230302151220/https://releases.threema.ch/web-electron/v1/release/Threema-Latest.deb"; sha256 = "0jx271zwqja7i7qdvhiyq5m6g19a12falfvxbkxrw7ab3ycds2px"; </del> <ins> url = "https://web.archive.org/web/20230731230034if_/https://releases.threema.ch/web-electron/v1/release/Threema-Latest.deb"; hash = "sha256-eZ/bjcSnrnzub1G4sbwPn3GCTwhDfFuYv9Plf5SJL90="; </ins> }; nativeBuildInputs = [

Discussion:
Package name: threema-desktop Latest released version: 1.2.31 <!-- Search your package here: --- Current version on the unstable channel: 1.2.27 Current version on the stable/release channel: 1.2.27 <!-- 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. -- You commented that you are waiting for threema to populate their releases on GitHub with the current workaround being to upload the binaries to Their releases seem to be there now, at least here are all the versions listed under : Note for maintainers: Please tag this issue in your PR.
tags is not what was meant in the code comment, but .deb releases etc for the app
Change:
fetchpijul = callPackage ../build-support/fetchpijul { }; <del> inherit (callPackages ../build-support/node/fetch-yarn-deps { }) </del> <ins> inherit (callPackage ../build-support/node/fetch-yarn-deps { }) </ins> prefetch-yarn-deps fetchYarnDeps;

Discussion:
The NixOS tests for netbox are failing to evaluate: It seems like the module tries to override the package to pass in the plugins that are configured in the module, but for some reason it's overriding the function in instead of the one in . The former doesn't have a plugins argument, so that causes this error. You can also replicate this in : I don't really know what changed to cause this to happen, as it doesn't seem like it should. Steps to reproduce the behavior: The system configuration should evaluate. <!-- 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]:
Possibly related issue with an which used to work: Ping
The thing these packages have in common seems to be that they use to pull in a few different versions into . It seems like something changed about recently.
I think you're right, That commit changes to for a bunch of packages, including citrix_workspace and netbox.
Change:
, fetchurl , pkg-config , libxml2 <ins> , autoreconfHook , gtk-doc </ins> , glib , gtk3 , enchant2

Discussion:
Project description CherryTree by Giuspen, currently, we are using version 0.39.4, meanwhile the latest application is on 0.99.37. There's a weird jump of version from 0.39.4 to 0.99.13. I don't know why this happens. Metadata homepage URL: source URL: license: GPL3 + platforms: Linux
Package request is the wrong issue type for this, Out-of-date package report would've been better. ! The package is sadly orphaned so there's no maintainer to ping for this.
Change:
usb_modeswitch = throw "'usb_modeswitch' has been renamed to/replaced by 'usb-modeswitch'"; # Converted to throw 2022-02-22 usbguard-nox = throw "'usbguard-nox' has been renamed to/replaced by 'usbguard'"; # Converted to throw 2022-09-24 util-linuxCurses = util-linux; # Added 2022-04-12 <del> utillinux = throw "'utillinux' has been renamed to/replaced by 'util-linux'"; # Converted to throw 2022-09-24 </del> ### V ###

Discussion:
After updating nix flake inputs, rebuilding with returns the following error: Commenting out the package rebuilds successfully. Steps to reproduce the behavior: ; ; `. succeeds with Slack package. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --The error may got introduced after this . cc Please run and paste the result.
Change:
{ stdenv, fetchurl, pkgconfig, glib, freetype, cairo, libintlOrEmpty , icu, graphite2 , withIcu ? false # recommended by upstream as default, but most don't needed and it's big <del> , withGraphite2 ? true # it is small and major distros do include it </del> <ins> , withGraphite2 ? !stdenv.isDarwin # it is small and major distros do include it </ins> }: # TODO: split non-icu and icu lib into different outputs?

Discussion:
It used to be possible to build (it is possible on 20.09), but these days it fails with: I’ll try to bisect it…
Bisecting points to by Nathan, do you have a hunch?
Cargoculting what I saw in the GHC code, trying this right now:
Seems to work, fix in
There appear to be multiple linker bugs affecting at least Rust and GHC with Musl . Both bfd or gold had issues, gold seems a little worse. I would suggest trying lld, it may fix it.
lld with gcc is currently not supported and I think last time I tried we can't build OCaml and all its dependencies with clang+lld fully yet…
The second commit of ("match leading/trailing arguments") should fix this
That's great news!
Fixed by
Change:
, qtscxml , qtsvg , qtdeclarative <ins> , qtwayland </ins> , qt5compat , wrapQtAppsHook , nix-update-script

Discussion:
Starting from the package will not run natively on Wayland anymore. When running without , on my machine the program will launch fine with some minor quirks, presumably using XCB and XWayland. The program should launch using the Wayland Qt platform plugin. Install and on the latest unstable channel. Then open a session. Inside a terminal emulator, launch . Possibly because of upstream release  updating to Qt6. However, adding to environment does not fix this issue. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --
I get the same error as you when I do not have in the environment. But albert works fine for me on wayland with Qt6 qtwayland available.
Thank you for trying to reproduce. Then might be a necessary but insufficient condition for albert to work. For me, the error appears even with in .
Same issue
Change:
{ stdenv, lib, fetchurl, pkgconfig, zlib, expat, openssl, autoconf , libjpeg, libpng, libtiff, freetype, fontconfig, libpaper, jbig2dec <del> , libiconv, ijs </del> <ins> , libiconv, ijs, fetchpatch </ins> , x11Support ? false, xlibsWrapper ? null , cupsSupport ? false, cups ? null }:

Discussion:
, (nixos-unstable, nixos-19.03, nixos-18.09) Scanned versions: nixos-unstable: ; nixos-19.03: ; nixos-18.09: . May contain false positives.

Can't simply apply the upstream commits, unfortunately (AFAICT). This looks pretty serious!
Thank you!! :sparkle:
Change:
dontPatchELF = true; dontStrip = true; <del> libPath = lib.makeLibraryPath [ gtk2 libXtst ]; </del> <ins> libPath = lib.makeLibraryPath [ gtk3 libXtst ]; </ins> desktopItem = makeDesktopItem { name = "XMind";

Discussion:
Building in a current git checkout of the Nixpkgs repo gives the following error:
Ping

Steps to reproduce the behavior: -env -i xmind or xmind to nixos config Please run and paste the result.
Install log when installing via is not exactly the same :
Change:
assert_lacks(out, "as well:") assert_contains(out, "would start the following units: test.servicen") <ins> # Ensure  works in unit names out = switch_to_specialisation("${machine}", "unitWithBackslash") assert_contains(out, "stopping the following units: test.servicen") assert_lacks(out, "NOT restarting the following changed units:") assert_lacks(out, "reloading the following units:") assert_lacks(out, "nrestarting the following units:") assert_lacks(out, "nstarting the following units:") assert_contains(out, "the following new units were started: escapedx2ddash.servicen") assert_lacks(out, "as well:") out = switch_to_specialisation("${machine}", "unitWithBackslashModified") assert_contains(out, "stopping the following units: escapedx2ddash.servicen") assert_lacks(out, "NOT restarting the following changed units:") assert_lacks(out, "reloading the following units:") assert_lacks(out, "nrestarting the following units:") assert_contains(out, "nstarting the following units: escapedx2ddash.servicen") assert_lacks(out, "the following new units were started:") assert_lacks(out, "as well:") </ins> with subtest("failing units"): # Let the simple service fail switch_to_specialisation("${machine}", "simpleServiceModified")

Discussion:
Switching NIxOS configurations when using produces the following warning: Steps to reproduce the behavior: (current master) file in the directory with the following content: test fails and produces the warning should not produce warnings. It looks like currently can't handle service file names containing a . I tracked the first failing commit down to . The warning seems to not create any problems for me at the moment and all services are running.
Great… I'll take a look
Change:
<del> { lib , stdenv , fetchFromGitHub , cmake , version , sha256 , patches ? [ ] , preConfigure ? null }: stdenv.mkDerivation rec { pname = "flatbuffers"; inherit version; src = fetchFromGitHub { owner = "google"; repo = "flatbuffers"; rev = "v${version}"; inherit sha256; }; inherit patches preConfigure; nativeBuildInputs = [ cmake ]; cmakeFlags = [ "-DFLATBUFFERS_BUILD_TESTS=${if doCheck then "ON" else "OFF"}" ]; doCheck = stdenv.hostPlatform == stdenv.buildPlatform; checkTarget = "test"; meta = with lib; { description = "Memory Efficient Serialization Library"; longDescription = '' FlatBuffers is an efficient cross platform serialization library for games and other memory constrained apps. It allows you to directly access serialized data without unpacking/parsing it first, while still having great forwards/backwards compatibility. ''; homepage = "https://google.github.io/flatbuffers/"; license = licenses.asl20; maintainers = [ maintainers.teh ]; mainProgram = "flatc"; platforms = platforms.unix; }; } </del>

Discussion:
We define two packages, one for version 1.12 and one for version 2.0. The package for version 1.12 . Upstream has the fixes needed but only for version 2.0. The version 1.12 branch does not appear maintained, and there to it since March of 2020. We can continue to maintain this (e.g. we can disable warnings, or we can adapt those fixes to 1.12 and patch them), but perhaps we could drop support for the old version altogether? ZHF: /cc
Disabling -Werror is always reasonable, but if there's no users left in nixpkgs I think it's ok to drop it. Unless the maintainer or someone else still has a use for this (do a scream test by removing it, I guess)
is unused and can be safely removed.