jiebi/CodeConvo huggingface dataset:
Code change:
--prefix XDG_DATA_DIRS : "$XDG_ICON_DIRS:${gtk3.out}/share:${gsettings-desktop-schemas}/share:$out/share:$GSETTINGS_SCHEMAS_PATH"  --add-flags "-Dsun.java2d.opengl=true -jar $out/share/java/${module}-${version}.jar -cp $out/share/java/Furniture.jar:$out/share/java/Textures.jar:$out/share/java/Help.jar -d${toString stdenv.hostPlatform.parsed.cpu.bits}" <ins> # remember the store paths found inside the .jar libraries. note that # which file they are in does not matter in particular, just that some # file somewhere lists them in plain-text mkdir -p $out/nix-support cp .jar-paths $out/nix-support/depends </ins> runHook postInstall '';

Related discussion:
text: It looks like the program copies some so files to on start-up: Two of the programs match to libraries in the but I could not match the other two; also I do not have the same filenames as you. Not sure what libraries’ RPATH should be patched but perhaps adding the following to wrapper would work as well:
For the reference, the libraries loaded are listed here:
Thank you for your contributions. This has been automatically marked as stale because it has had no activity for 180 days. If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity. Here are suggestions that might help resolve this more quickly: for maintainers and people that previously touched the related code and @ mention them in a comment. on the . on the on .
Code change:
stdenv.mkDerivation rec { pname = "mbedtls"; <del> name = "mbedtls-${version}"; version = "2.16.3"; # nixpkgs-update: no auto update </del> <ins> version = "2.16.9"; # nixpkgs-update: no auto update </ins> src = fetchFromGitHub { owner = "ARMmbed"; repo = "mbedtls"; rev = "${pname}-${version}"; <del> sha256 = "1mzh92yyz93099a1gb2wvwc76jv12d1k1wg9k3dimbgczxgrkirc"; </del> <ins> sha256 = "0mz7n373b8d287crwi6kq2hb8ryyi228j38h25744lqai23qj5cf"; </ins> }; nativeBuildInputs = [ cmake ninja perl python ];

Related discussion:
text: , CVSSv3=5.5 (nixos-20.03, nixos-20.09, nixos-unstable) Scanned versions: nixos-20.03: ; nixos-20.09: ; nixos-unstable: . Cc
Code change:
- Deprecated `xlibsWrapper` transitional package has been removed in favour of direct use of its constitutents: `xorg.libX11`, `freetype` and others. <ins> - .NET 5.0 was removed due to being end-of-life, use a newer, supported .NET version - https://dotnet.microsoft.com/en-us/platform/support/policy/dotnet-core </ins> ## Other Notable Changes {#sec-release-23.05-notable-changes} <!-- To avoid merge conflicts, consider adding your item at an arbitrary place in the list instead. -->

Related discussion:
text: Since May 10, .NET 5.0 is EOL (End Of Life), and should not be used. Should it be marked as EOF similar to dotnet 2.2 and 3.0? See All packages using dotnet 5.0 should be updated to use a newer, supported version. These packages still need updating: [x] - [x] - [x] - [x] pkgs/development/tools/build- - [x] -
There is at least one package, which currently uses dotnet 5 sdk - . So we will need to update it beforehand. Btw, I'm not sure if we have any policy regarding packages removal, for nixpkgs in general or specifically for it's dotnet part. , what do you think?
The package is also using .NET 5: . But this is because I made the PR upstream updating it from .NET 4 to 5. I suspect that the transition to 6 will be similarly easy.
I think we should just mark it as depricated, as many projects do still use it upstream. Dotnet version 3 is also still commonly used, so I dont expect it would be realistic to remove version 5 any time soon. also uses dotnet 5 by default, I'll go ahead and switch that over now. See . That doesnt mark dotnet 5 as deprecated or change anything from a SDK perspective, just some preperation work.
See as well, it adds a warning whenever dotnet version 5 is used. Not using a throw for now since a few packages depend on it and I dont have the time to clean that all up at the moment.
Can you provide a list of packages that need updating?
Based on a quick grep: pkgs/development/tools/build-
I believe that after all the above PRs are merged, we should be able to safely remove .NET 5 from nixpkgs :)
Code change:
version = "0.24"; src = pkgs.fetchurl { <del> url = "http://www.cython.org/release/${name}.tar.gz"; </del> <ins> url = "mirror://pypi/C/Cython/${name}.tar.gz"; </ins> sha256 = "1wd3q97gia3zhsgcdlvxh26hkrf3m53i6r1l4g0yya119264vr3d"; };

Related discussion:
text: Source no longer apparently available from upstream website. They recommend using pypi. Attempt to build , as in :
Code change:
<ins> import ./make-test.nix ({ pkgs, lib, ...} : { name = "gotify-server"; meta = with pkgs.stdenv.lib.maintainers; { maintainers = [ ma27 ]; }; machine = { pkgs, ... }: { environment.systemPackages = [ pkgs.jq ]; services.gotify = { enable = true; port = 3000; }; }; testScript = '' startAll; $machine->waitForUnit("gotify-server"); $machine->waitForOpenPort(3000); my $token = $machine->succeed( "curl --fail -sS -X POST localhost:3000/application -F name=nixos " . '-H "Authorization: Basic $(echo -ne "admin:admin" | base64 --wrap 0)" ' . '| jq .token | xargs echo -n' ); my $usertoken = $machine->succeed( "curl --fail -sS -X POST localhost:3000/client -F name=nixos " . '-H "Authorization: Basic $(echo -ne "admin:admin" | base64 --wrap 0)" ' . '| jq .token | xargs echo -n' ); $machine->succeed( "curl --fail -sS -X POST 'localhost:3000/message?token=$token' -H 'Accept: application/json' " . '-F title=Gotify -F message=Works' ); my $title = $machine->succeed( "curl --fail -sS 'localhost:3000/message?since=0&token=$usertoken' | jq '.messages|.[0]|.title' | xargs echo -n" ); $title eq "Gotify" or die "Wrong title ($title), expected 'Gotify'!"; ''; }) </ins>

Related discussion:
text: Project description A simple server for sending and receiving messages in real-time per WebSocket. Includes a web UI, also has an Android client for receiving notifications and an optional CLI program (distributed separately) for sending notifications. Metadata homepage URL: source URL: license: MIT platforms: anything Go runs on
I started an attempt locally, however it failed due to some timeouts while fetching Go dependencies... will retry during this week :)
I think the main difficulty is the UI, which needs to be compiled with NPM. In essence, I think the build is three-staged: fetch UI dependencies, fetch Go dependencies, do the actual build.
You may want to take a look at .
Code change:
# https://github.com/NixOS/nixpkgs/pull/161773#discussion_r820134708 zenKernels = callPackage ../os-specific/linux/kernel/zen-kernels.nix; <del> linux_zen = (zenKernels { </del> <ins> linux_zen = zenKernels { variant = "zen"; </ins> kernelPatches = [ kernelPatches.bridge_stp_helper kernelPatches.request_key_helper ]; <del> }).zen; </del> <ins> }; </ins> <del> linux_lqx = (zenKernels { </del> <ins> linux_lqx = zenKernels { variant = "lqx"; </ins> kernelPatches = [ kernelPatches.bridge_stp_helper kernelPatches.request_key_helper ]; <del> }).lqx; </del> <ins> }; </ins> # This contains the variants of the XanMod kernel <del> xanmodKernels = callPackage ../os-specific/linux/kernel/xanmod-kernels.nix { </del> <ins> xanmodKernels = callPackage ../os-specific/linux/kernel/xanmod-kernels.nix; linux_xanmod = xanmodKernels { variant = "lts"; kernelPatches = [ kernelPatches.bridge_stp_helper kernelPatches.request_key_helper ]; }; linux_xanmod_stable = xanmodKernels { variant = "main"; kernelPatches = [ kernelPatches.bridge_stp_helper kernelPatches.request_key_helper ]; }; linux_xanmod_latest = xanmodKernels { variant = "main"; </ins> kernelPatches = [ kernelPatches.bridge_stp_helper kernelPatches.request_key_helper ]; }; <del> linux_xanmod = xanmodKernels.lts; linux_xanmod_stable = xanmodKernels.main; linux_xanmod_latest = xanmodKernels.main; </del> linux_libre = deblobKernel packageAliases.linux_default.kernel;

Related discussion:
text: Mainline / hardened / testing / ... kernels can be painlessly modified via : Sadly, this does not work with a bunch of other kernel variants: All kernels should honor I am not entirely sure how dynamic binding is implemented in kernel stuff, however slightly changing xanmod parts this way seems to fix : zen and lqx look similar to xanmod, no idea about libre Pinging people who seem to update affected packages often Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
same underlying issue as it seems
Can confirm that this patch fix the issue for zen and lqx kernels:
have you submitted these changes as a PR that I can review?
sorry for the late response. I created a new PR with this changes.
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Code change:
"-p:PublishTrimmed=true" ]; dotnetInstallFlags = [ <del> "--framework=net7.0" </del> <ins> "--framework=net8.0" </ins> ]; selfContainedBuild = true;

Related discussion:
text: Looks like it now uses .NET 8 which probably made all existing plugins incompatible - Package name: ArchiSteamFarm Latest released version: 5.5.0.11 <!-- Search your package here: --- Current version on the unstable channel: 5.4.13.4 Current version on the stable/release channel: 5.4.12.5 <!-- 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]:
The package/module has no official way to use plugins, so there is no way to use them unless people are using overlays which should be constructed in a smart way to re-use the same methods as archisteamfarm does. Anyway, here is the update
Code change:
libXScrnSaver libXcursor libXtst libGLU libGL pciutils protobuf speechd libXdamage at-spi2-core jre <ins> pipewire_0_2 </ins> ] ++ optional useVaapi libva ++ optional gnomeKeyringSupport libgnome-keyring3 ++ optionals gnomeSupport [ gnome.GConf libgcrypt ]

Related discussion:
text: Project description This flag is available in most other major distros. It is necessary to enable screen sharing on wayland inside of chromium, combined with xlr-desktop-portal-wlr and pipewire. It requires the build flag and a dependency on libpipewire02. See as an example. Metadata homepage URL: source URL: license: mit, bsd, gpl2+ , ... platforms: unix, linux, darwin, ...
that would definitely be nice to have :) I actually also noticed this but unfortunately cannot test this easily as I'm not using screen sharing. If you could contribute a PR that would be awesome (but be aware that Chromium does unfortunately take quite some time to compile). Alternatively (but less preferably) we could make the required changes with the next update and test the core functionality (as always) and you could test screen sharing after the new version is available in the binary caches. Additionally we would need to package in Nixpkgs to make this work on wlroots based compositors. On Gnome/KDE this might work out-of-the-box, but I don't know what they currently implement/provide.
was just merged w/ . I'll try building chromium w/ the flag - as you say it takes a while, so I can leave it overnight and give it a shot.
how does the situation look like with ? Is the flag available there, as in, screensharing with wayland already works there?
yes, it's available in google-chrome. ! I'm still trying to get it to work with xlr-desktop-portal-wlr - I've done this in the past, but it's not working out of the box yet with
And just to make sure, you also did set as described there?
yes I did. I'm almost got it working I think. There are a few issues out of the box: -chrome is missing the pipewire 0.2 runtime dependency, so I it as (I'm on 20.03 so pkgs.pipewire is 0.2): .pipewire service doesn't work - it doesn't seem to be setting up the path correctly. I'm trying to fix this now: My current config on 20.03 looks like: Where is the same package that was recently merged.
Code change:
libXScrnSaver libXcursor libXtst libGLU libGL pciutils protobuf speechd libXdamage at-spi2-core jre <ins> pipewire_0_2 </ins> ] ++ optional useVaapi libva ++ optional gnomeKeyringSupport libgnome-keyring3 ++ optionals gnomeSupport [ gnome.GConf libgcrypt ]

Related discussion:
text: yeah, I'm currently already looking at it - pipewire wants to execute , but it's not in . We can patch to contain the absolute path. I'll check if it works and will get back to you.
Btw, we /really/ need a sway NixOS test, and better documentation on how to use sway. I was trying stuff until it worked, and does autologin me into a sway, but there might be a smarter way to do this, without also starting X.
The sway recommendation is to just run sway from the terminal after login - that's how I do it at least. I was able to workaround the environment issue by doing (but this is a kludge I think and shouldn't be necessary). But unfortunately it's now crashing and I'm not sure why:
Yeah, even my sddm config I also had to , otherwise pipewire complained about not being able to reach dbus: Afterwards, it segfaulted, as it wasn't able to find ; I patched to be able to find the path to , and that error message is gone. Now (apart from not being able to find bluez or rtkit) it /might/ only be some version incompatibilities, not sure: I'll see if I can get as far with your chromium PR, will merge that then, and also submit the pipewire patch.
Okay, with the pipewire patch and , It seems I'm able to share at least my own application window :tada:. I don't know yet why the alacritty window nearby isn't shown, and why "Entire Screen" is black, but that's probably due to me running sway inside X via ssdm.
pipewire PRs:
I don't think you're using pipewire in that case. xdg-desktop-portal-wlr only supports full screen sharing atm. If it is black that means it's not working. By the way I had to add pipewire02 to my system packages to prevent xdg-desktop-portal from crashing. But now there seems to be some incompatibility in the pipewire service logs when chrome tries to connect:
you should be able to cherry-pick the to not have to manually add this to $PATH.
Thanks! I'm suspecting google-chrome is compiled with a too old version of pipewire.
Code change:
libXScrnSaver libXcursor libXtst libGLU libGL pciutils protobuf speechd libXdamage at-spi2-core jre <ins> pipewire_0_2 </ins> ] ++ optional useVaapi libva ++ optional gnomeKeyringSupport libgnome-keyring3 ++ optionals gnomeSupport [ gnome.GConf libgcrypt ]

Related discussion:
text: Enabling pipewire debug logs, it seems to be sending an incompatible format to the pipewire server (similar to ). I have got this working with chromium compiled against pipewire 0.2.7 in the past, so I'm pretty sure it should work assuming the client library is recent enough. Once the chromium package has that flag enabled I'll try to retest.
I just confirmed my last comment by building chromium locally w/ rtcusepipewire=true. It works perfectly for fullscreen sharing.
Hmm take that back - it worked the first time but not anymore :/. Not sure what lib is missing where.
Seems like xdg-desktop-portal is crashing:
This might be yet another version incompatibility problem. I propose merging (as it's built with 0.2 everywhere else too), and then see if we can get it to work if the system pipewire also is 0.2. I asked upstream about these problems in - maybe 0.3 needs to support 0.2 clients for some time until we should switch.
Heads-up: the bad client situation should have been fixed with the latest pipewire release, PR at
Thanks for your help! I'm still getting the xdg-desktop-portal crash, however. I'm guessing there is something missing from my dbus environment - or perhaps it's trying to access a file/directory not available in nixos.
could you open a new issue with some more details, like logs etc.?
Okay, I made
Code change:
jre = jre8; # TODO: remove override https://github.com/NixOS/nixpkgs/pull/89731 }; <del> freenet = callPackage ../applications/networking/p2p/freenet { gradle = gradle_7; jdk = jdk17_headless; # Reduce closure size jre = pkgs.jre17_minimal.override { modules = [ "java.base" "java.logging" "java.naming" "java.sql" "java.desktop" "java.management" ]; jdk = jdk17_headless; }; }; </del> freeoffice = callPackage ../applications/office/softmaker/freeoffice.nix { }; freepv = callPackage ../applications/graphics/freepv { };

Related discussion:
text: Freenet installs successfully but fails to run for both the service and the package with Steps to reproduce the behavior: Failure with Or alternatively with the service = true; to config For Freenet to start and be able to access setup wizard on 127.0.0.1:8888 Add any other context about the problem here. Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Code change:
sha256 = "1z66m16n4r16zqmnv84a5jndr5x6mdqdq4b1wq929sablwqd2rl4"; }; <del> cargoSha256 = "1xdx0gjqd4zyhnp72hz88rdmgry1m7rcw2j73lh67vp08z74y54y"; </del> <ins> cargoSha256 = "0hp68w5mvk725gzbmlgl8j6wa1dv2fydil7jvq0f09mzxxaqrwcs"; </ins> nativeBuildInputs = [ pkgconfig ];

Related discussion:
text: On today's master () - and probably others - building the attribute of many package produces an output that differs from the output on another architecture. Nix will display a hash mismatch. I tried with x8664-linux and aarch64-linux. Execute this on aarch64 and x8664. The aarch64 build produces the below output while x8664 is happy with the hash in nixpkgs. Please run and paste the results. system: host os: multi-user?: sandbox: version: nixpkgs: and system: host os: multi-user?: sandbox: version: channels(root): channels(andi): nixpkgs:
x8664 build produces same output for me: system: host os: multi-user?: sandbox: version: channels(root): nixpkgs:
I noticed something similar on macOS in Could some recent change have caused this? Perhaps ?
I reverted in a branch on my fork. My x86_64-linux laptop doesn't complain about the hash sum - as before. The aarch64-linux community box also doesn't complain anymore. Can anyone else confirm this?
I just made a diff of : The left side is aarch64, the right side is x86_64. Both are done on the same git revision ().
What a weird behavior that is missing.
Probably related:
I think this may be related: I also see different hashes on NixOS 19.03 vs. stable. I use the branch, but when CI builds the derivation on 19.03, the hashes do not match. If I build on NixOS 19.03 with from master, the hashes do match. This is quite annoying, because it makes it impossible to have package sets that work on NixOS stable and unstable without using rustPlatform from a nixpkgs newer than 19.03. I'll try to revert and see if I get the same hashes on 19.03 and master.
That's indeed it. When I revert , I get the same as 19.03. Maybe this change should be reverted? Since NixOS is not a rolling distribution and people run both stable and unstable, it would really be nice if package sets and overlays work on both versions. This also makes backporting changes easier.
Code change:
sha256 = "1z66m16n4r16zqmnv84a5jndr5x6mdqdq4b1wq929sablwqd2rl4"; }; <del> cargoSha256 = "1xdx0gjqd4zyhnp72hz88rdmgry1m7rcw2j73lh67vp08z74y54y"; </del> <ins> cargoSha256 = "0hp68w5mvk725gzbmlgl8j6wa1dv2fydil7jvq0f09mzxxaqrwcs"; </ins> nativeBuildInputs = [ pkgconfig ];

Related discussion:
text: Diff between the vendored dependencies: Here the differences also seem to be missing dotfiles (e.g. and ). I think this is the upstream PR that changed this behavior: (Edit: oops, I just saw that already mentioned the associated commit.)
is a critical update and reverting it will break multiple Rust packages. Rather I think we should get that change pushed into the channel, and then update any Rust packages whose changes as a result.
The only bummer is that it also breaks people's own packages on the channel as well.
Yeah, it would be bad to break people's derivations as an update to a stable release. At any rate, the 19.09 release notes should probably have a blurb that points out that hashes will change due to changes, so that people who update from 19.03 to 19.09 are prepared. There are probably also derivations in that have incorrect hashes now, since the file that is generated by is now excluded vendored dependencies.
I’ve updated the title of the issue to better reflect what I think we now know. Additionally, I’ve opened to update the hashes for all packages that haven’t been updated in master yet. I would appreciate a review on it. Once that’s merged, I can do the same thing for the affected release branch.
Looks like I misunderstood and this hasn’t made its was into a release branch yet, so we’re almost done here. Somebody just needs to add the release note for 19.09.
with the changelog PR () being merged, is there anything else missing?
Don't think so. :) Somebody can shout if I'm wrong.
Code change:
{ /* Returns the Agda interface file to a given Agda file. * <ins> * The resulting path may not be normalized. * </ins> * Examples: <del> * interfaceFile "Everything.agda" == "Everything.agdai" * interfaceFile "src/Everything.lagda.tex" == "src/Everything.agdai" </del> <ins> * interfaceFile pkgs.agda.version "./Everything.agda" == "_build/2.6.4.3/agda/./Everything.agdai" * interfaceFile pkgs.agda.version "src/Everything.lagda.tex" == "_build/2.6.4.3/agda/src/Everything.agdai" </ins> */ <del> interfaceFile = agdaFile: lib.head (builtins.match ''(.*.)l?agda(.(md|org|rst|tex|typ))?'' agdaFile) + "agdai"; </del> <ins> interfaceFile = agdaVersion: agdaFile: "_build/" + agdaVersion + "/agda/" + lib.head (builtins.match ''(.*.)l?agda(.(md|org|rst|tex|typ))?'' agdaFile) + "agdai"; </ins> /* Takes an arbitrary derivation and says whether it is an agda library package *  that is not marked as broken.

Related discussion:
text: Describe the bug The new version of Agda is working fine on other systems, but not NixOS. I've reported a bit more about what is known at To Reproduce Steps to reproduce the behavior: Agda 2.6.1 any file (e.g, ) Expected behavior Agda checks the file quickly and exits. Additional context Issue in the Agda repository: agda/agda Metadata Maintainer information:
I believe that this is fixed by rework of our Agda setup ! (Which is included in the most recent nixos-unstable.) Can you confirm? :-) $ echo module Main where && time agda Checking Main (). real 0m0.132s user 0m0.104s sys 0m0.028s Looks reasonable!
I haven't had chance to test the new stuff, but this issue probably should be closed anyway, as it's being worked on upstream (). I'm doing fine now using the workaround of adding option .
Code change:
python3Packages = python3.pkgs; pythonInterpreters = callPackage ./../development/interpreters/python { }; <del> inherit (pythonInterpreters) python27 python37 python38 python39 python310 python3Minimal pypy27 pypy38; </del> <ins> inherit (pythonInterpreters) python27 python37 python38 python39 python310 python3Minimal pypy27 pypy38 rustpython; </ins> # Python package sets. python27Packages = python27.pkgs;

Related discussion:
text: Project description A Python-3 (CPython = 3.9.0) Interpreter written in Rust Metadata homepage URL: source URL: license: mit platforms: unix, linux, darwin
I tried to package it here: but run into compilation failure:
Rustpython master builds just fine. PR in