jiebi/CodeConvo huggingface dataset:
Change:
mullvad-vpn = callPackage ../applications/networking/mullvad-vpn { }; <ins> mullvad-browser = callPackage ../applications/networking/browsers/mullvad-browser { }; </ins> mycorrhiza = callPackage ../servers/mycorrhiza { }; napalm = with python3Packages; toPythonApplication (

Discussion:
Project description The Mullvad Browser is a privacy-focused web browser developed in a collaboration between and the . It’s designed to minimize tracking and fingerprinting. You could say it’s a Tor Browser to use without the Tor Network. Instead, you can use it with a trustworthy VPN. The idea is to provide one more alternative – beside the Tor Network – to browse the internet with more privacy. To get as many people as possible to fight the big data gathering of today. To free the internet from mass surveillance. Metadata homepage URL: source URL: license: free platforms: linux, darwin
that would be awesome! Lookin' forward to test it
Thank you very much,
Change:
ln -s ${nspr.out}/lib/libnspr4.so $libdir/libnspr4.so ln -s ${nspr.out}/lib/libplc4.so $libdir/libplc4.so <del> ln -s ${ffmpeg.lib}/lib/libavcodec.so* $libdir ln -s ${ffmpeg.lib}/lib/libavformat.so* $libdir </del> <ins> ln -s ${ffmpeg_4.lib}/lib/libavcodec.so* $libdir ln -s ${ffmpeg_4.lib}/lib/libavformat.so* $libdir </ins> rpath="$out/share/spotify:$libdir"

Discussion:
A clear and concise description of what the bug is. You can browse files and it'll show them but playing a song (in my case an MP3 file) results in this error: On the next start, the song is greyed out. I've d it and it seems to try (and fail?) to load libavcodec. That might be why. is in spotify's library path but somehow it's not loading. Investigating now. <!-- 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.
Fallout from , PR incoming.
Change:
, lib , stdenv , fetchFromGitHub <del> , glib </del> , gobject-introspection <del> , python3 </del> , pkg-config , ninja , wayland

Discussion:
Package name: clapper Latest released version: 0.6.0 Current version on the unstable channel: 0.5.2 Current version on the stable/release channel: 0.5.2 Notify maintainers 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:
<ins> diff --git a/src/arma3-unix-launcher/mainwindow.cpp b/src/arma3-unix-launcher/mainwindow.cpp index 66b73cc..f89f66b 100644 --- a/src/arma3-unix-launcher/mainwindow.cpp +++ b/src/arma3-unix-launcher/mainwindow.cpp @@ -56,6 +56,3 @@ MainWindow::MainWindow(std::unique_ptr<ARMA3::Client> arma3_client, std::filesys { -    if (use_steam_integration) -        steam_integration = std::make_unique<Steam::SteamIntegration>(ARMA3::Definitions::app_id); -    else -        steam_integration = std::make_unique<Steam::IntegrationStub>(ARMA3::Definitions::app_id); +    steam_integration = std::make_unique<Steam::IntegrationStub>(ARMA3::Definitions::app_id); diff --git a/src/dayz-linux-launcher/mainwindow.cpp b/src/dayz-linux-launcher/mainwindow.cpp index d9223db..5773593 100644 --- a/src/dayz-linux-launcher/mainwindow.cpp +++ b/src/dayz-linux-launcher/mainwindow.cpp @@ -56,6 +56,3 @@ MainWindow::MainWindow(std::unique_ptr<DayZ::Client> arma3_client, std::filesyst { -    if (use_steam_integration) -        steam_integration = std::make_unique<Steam::SteamIntegration>(DayZ::Definitions::app_id); -    else -        steam_integration = std::make_unique<Steam::IntegrationStub>(DayZ::Definitions::app_id); +    steam_integration = std::make_unique<Steam::IntegrationStub>(DayZ::Definitions::app_id); </ins>

Discussion:
Project description A clean, intuitive Arma 3 + DayZ SA Launcher for GNU/Linux and MacOS. Metadata homepage URL: source URL: license: mit (does require the steamworks SDK which has its own license.) platforms: linux, darwin Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
I was trying to package this myself, but the way cmake is set up has it trying to download dependencies with git, and modifying it to build properly with nix is over my head.
With a lot of trial and error, I got this functioning . No idea if my code is up to the standards for proper integration into nixpkgs, I'm not 100% sure if everything I have in there is even required, might have missed some failed attempts at fixes that aren't actually doing anything. Also haven't tested the version of the launcher for DayZ.
Looks great to me! Run it through to pretty it up and I think it'd fit in just fine in nixpkgs. I am getting a build error with the DayZ launcher, though: This might inspire me to go back to arma 3. Longtime OFP/arma fan!
What would I put for the license if the launcher itself is using MIT but the steam works sdk has its own custom license (not sure if it is considered unfree, either)
You can just include multiple licenses, though I'm not entirely sure what the Steamworks SDK license is, or if the license is in nixpkgs in the first place. I'd just mark it unfree if you don't know.
Change:
rulesProto = fetchFromGitHub { owner = "bazelbuild"; repo = "rules_proto"; <del> rev = "4.0.0-3.19.2"; sha256 = "sha256-wdmp+Tmf63PPr7G4X5F7rDas45WEETU3eKb47PFVI6o="; </del> <ins> rev = "4.0.0"; hash = "sha256-WVPZx14thneAC4PdiDhBibnPwlCKEF9c93CHR0t1Efo="; </ins> postFetch = '' sed -i 's|name = "protoc"|name = "_protoc_original"|' $out/proto/private/BUILD.release cat <<EOF >>$out/proto/private/BUILD.release

Discussion:
Steps to reproduce the behavior: The builds are also failing on Hydra Please run and paste the result.
Several errors like this locally and in
is not set on the system outside the nix-shell and also does not seem to be set when the bazel command is executed within the nix-build. On the same system, with bazelisk, version 0.23.1 builds from source:
merge introduced a build failure (found via git bisect) which merged this change: Reverting it on master makes it work but also reverts bazel-watcher to an older version. AND only works if the is set. I assume it will not actually call the updated fetch logic at all since it just uses the fetched dependencies from the cache. Maybe can help out fixing it...
:)
The makes it hard to bisect since it will "hide" all fetch affecting changes behind that cached results. Long live fixed output derivations!
I was wrong. The fetchAttrs.sha256 hid that it was, in fact, broken before
I bisected this to the following commit: with this bisect script: Unfortunately, it is a huge merge.
Okay fetching broke when go was unpinned:
Maybe related to
: Could you maybe merge ? It would be appreciated.
Change:
}; mutt-wizard = callPackage ../tools/misc/mutt-wizard { }; <ins> mutt-ics = callPackage ../tools/networking/mutt-ics { }; </ins> mwic = callPackage ../applications/misc/mwic { pythonPackages = python3Packages; };

Discussion:
Project description A tool to show calendar event details in Mutt. Metadata homepage URL: source URL: license: mit platforms: unix, linux, darwin, (all platforms supporting Python)
Change:
<ins> diff --git a/dvc/daemon.py b/dvc/daemon.py index 1d67a37..7ce6fde 100644 --- a/dvc/daemon.py +++ b/dvc/daemon.py @@ -67,14 +67,8 @@ def daemon(args): Args: args (list): list of arguments to append to `dvc daemon` command. """ -    cmd = [sys.executable] -    if not is_binary(): -        cmd += ['-m', 'dvc'] -    cmd += ['daemon', '-q'] + args - -    env = fix_env() -    file_path = os.path.abspath(inspect.stack()[0][1]) -    env['PYTHONPATH'] = os.path.dirname(os.path.dirname(file_path)) +    cmd = [ "@dvc@" , "daemon", "-q"] + args +    env = None logger.debug("Trying to spawn '{}' with env '{}'".format(cmd, env)) </ins>

Discussion:
dvc () is version control system for "biggish" data and code It integrates with Git but offers a solution for managing and versioning big data sets that come with code commits. Related technology () are like git annex and git lfs. If nobody gets around to this, I may work on this later.
Need to first package the Python dependencies nanotime, grandalf and asciimatics dependencies.
The extra dependencies: These will need to be packaged as optional dependencies and provided as a separate alias. Something like and or something like that. What are some good suggestions for names? The and don't appear to be packaged.
Google cloud storage is packaged already here: However is still not packaged as is though. The pypi is:
Initial PR for azure-storage:
Inital PR for nanotime:
Initial PR for grandalf:
Initial PR for asciimatics:
For the smaller dependent packages that are unrelated it would have been preferred to group them in one pr.
However too late now :smile: so just to know in the future.
Yea that would have been better as I could have then worked on dvc commit as well, but now that all dependent packages are separated between different branches, that's not possible. So I'm just waiting for those to be merged to master.
Initial PR for dvc:
Change:
[[package]] name = "std_detect" version = "0.1.5" <del> source = "git+https://github.com/tensorchord/stdarch.git?branch=avx512fp16#db0cdbc9b02074bfddabfd23a4a681f21640eada" </del> <ins> source = "git+https://github.com/rust-lang/stdarch.git?branch=master#d2b1a070afc72d9ba4df80e055109ede5fc0a81f" </ins> dependencies = [ "cfg-if", "libc",

Discussion:
I was attempting to build 0.2.1 which relies on , and hit a build failure on (nixos-unstable via flakes). I add to my system flake . Steps to reproduce the behavior: into a rust compilation failure of the crate while building , which relies on. <details<summaryClick to view logs</summary</detailsI was able to build 0.2.1 successfully in the past, and there hasn't been an update to or recently, so I'm not sure why this is failing now. Perhaps I was relying on the build cache's copy of , and now I'm not? The error looks to be due to using an unstable rust library feature () while not using a nightly rust compiler. Did the default rust compiler used to build packages change recently? cargo-pgrx maintainers: pgvecto-rs maintainers: Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Its most likely a version issue. Cargo pgrx is very version sensitive. Every minor upgrade is breaking. Ive been waiting for 1.0 to try to make the upgrade in nixpkgs otherwise we have to add and maitain every minor version. You cam try with a different version is you want and that might solve your problem. Sorry for not having a better solution than this unfortunately.
This seems to have been caused by an upgrade of rustc to 1.78 (from 1.77.2). I'll see if it can be patched in (or pgrx if that's the case).
Some more information I found: pgvecto-rs uses a fork of rust's crate (under the repo), which only has a single commit (): This commit has since been merged upstream The build is failing because of (you can see the devs trying to fix all the build failures in the commit history ) I think the easiest fix here would be to patch pgvecto-rs to use Rust's crate instead of the fork, which should work fine. I'll still have to investigate whether there were any other changes to the crate that could cause problems, but it seems to be a fairly small crate, so fingers crossed it doesn't.

Can you try my branch in PR It's based on commit , so it should be a drop-in replacement for nixos-unstable. Let me know on the PR if it works fine with Immich (perhaps backup first, but I don't think it should have problems).
Change:
minissdpd = callPackage ../tools/networking/minissdpd { }; <del> miniupnpc = callPackage ../tools/networking/miniupnpc { inherit (darwin) cctools; }; </del> <ins> miniupnpc = callPackage ../tools/networking/miniupnpc { }; </ins> miniupnpd = callPackage ../tools/networking/miniupnpd { };

Discussion:
the build ends up with:
We can trivially workaround this by disabling the tests for aarch64-darwin: but it would be much better to understand the underlying issue and fix that instead
ping
Fixed by
follow-up fix in PR:
I can see two PRs disabling hardening features, and , but neither have an explanation of the problem, or why turning off hardening features was the best / correct fix? Can you explain further? I see the workarounds are still present: and It would be great to know why this is necessary for Nix. These hardening features work fine for native builds, and are used in our release binaries.
This used to fix "Killed: 9" error while running the tests, but it seems this is not helping anymore. My guess is that code signing is somehow messing with the test binaries.
I think the hardening feature was broken when building with gfortran. The issue has been fixed recently.
Still broken with "Killed: 9". Looks like binaries are not signed before .
As can be seen here, the issue is intermittent and does not appear all the time: This makes it harder to debug.
Fix in
Change:
./hardware/video/amdgpu.nix ./hardware/video/ati.nix ./hardware/video/bumblebee.nix <ins> ./hardware/video/displaylink.nix </ins> ./hardware/video/nvidia.nix ./hardware/video/webcam/facetimehd.nix ./i18n/input-method/default.nix

Discussion:
DisplayLink, as far as I can tell, seems to be unfortunately emerging as the only choice for connecting external monitors to laptops without display ports (for example, via the ). It would be great if NixOS could support it. I have no idea what is involved in this. There is an Ubuntu driver. DisplayLink the company claims that it should be possible to port (). The says it's difficult to get working.
Do you have hardware for testing this? The driver itself seems fairly straightforward and I could help packaging it.
I do - I have the Dell adapter linked above.
Change:
mkdocs-rss-plugin = callPackage ../development/python-modules/mkdocs-rss-plugin { }; <del> mkdocs-simple-hooks = callPackage ../development/python-modules/mkdocs-simple-hooks { }; </del> mkdocs-swagger-ui-tag = callPackage ../development/python-modules/mkdocs-swagger-ui-tag { }; mkdocstrings = callPackage ../development/python-modules/mkdocstrings { };

Discussion:
Steps to reproduce the behavior: (e.g. use sth like ) (tried on both unstable n unstable-small) Seems somewhat similara Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Perhaps we can just remove this package? It's only required by ntfy-sh currently, which . Also, according to those release notes, hooks are a native part of mkdocs since 1.4, so I want to propose to just remove this.
Change:
openjdk11.overrideAttrs (oldAttrs: rec { pname = "jetbrains-jdk"; <del> version = "11.0.10-b37"; </del> <ins> version = "11.0.10-b1427"; </ins> src = fetchFromGitHub { owner = "JetBrains"; repo = "JetBrainsRuntime"; rev = "jb${lib.replaceStrings ["."] ["_"] version}"; <del> sha256 = "0bcvwnwi29z000b1bk5dhfkd33xfp9899zc3idzifdwl7q42zi02"; </del> <ins> sha256 = "sha256-2cn+FiFfGpp7CBeQMAASVZwTm6DOFaXaWxAL/nVC2Nk="; </ins> }; patches = []; meta = with lib; {

Discussion:
Describe the bug On the latest nixos-unstable-small, jetbrains idea-ultimate crashes when font ligatures are enabled due to a segfault in the libharfbuzz-library. This library is a dependency of . From the crash log file: To Reproduce Steps to reproduce the behavior: idea-ultimate to Editor Font and enable ligatures a project a file editor crashes and exits I was able to open an empty project without files. Once I created a file it crashed. I think this might have something to do with the rendering of font ligatures. This also occurs when trying to open the editor font settings (not the normal font settings). Expected behavior Intellij IDEA Ultimate should be able to open files normally. Screenshots The last screen before the program exits: ! Additional context I am running the Fira Code font which has ligatures. Notify maintainers Metadata system: host os: multi-user?: sandbox: version: channels(rien): nixpkgs: Maintainer information:
The crashes are still occurring after reverting . I will try to look for recent changes with fonts that might have caused this.
I was able to pinpoint the problem. After a full reset everything works again. Going to Editor Font and selecting "Enable font ligatures" immediately crashes it. I have opened a report with JetBrains for this issue:
I was able to fix this issue by reverting this commit where jetbrains-jdk was updated from 11.0.7-b64 to 11.0,10.b37. how should we go further with this? It seems like this issue is solved in the latest release.
Change:
preFixup = '' for entry in $(find $out -name libipopt.so); do <del> patchelf --shrink-rpath --allowed-rpath-prefixes /nix/store $entry patchelf --set-rpath '$ORIGIN':"$(patchelf --print-rpath $entry)" $entry </del> <ins> patchelf --shrink-rpath --allowed-rpath-prefixes "$NIX_STORE" "$entry" patchelf --set-rpath '$ORIGIN':"$(patchelf --print-rpath $entry)" "$entry" </ins> done '';

Discussion:
Steps to reproduce the behavior: on nixos-unstable I believe this is related to <!-- 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.
It'll need a similar fix like the ones in Wasn't caught in staging because it's marked insecure
Change:
blst = callPackage ../development/libraries/blst { }; <ins> bloom = qt6Packages.callPackage ../development/tools/bloom { }; </ins> bloodhound-py = callPackage ../tools/security/bloodhound-py { }; bodyclose = callPackage ../development/tools/bodyclose { };

Discussion:
Project description On-chip debugging for AVR microcontrollers, on GNU/Linux. Bloom exposes an interface to the connected target via a GDB Remote Serial Protocol (RSP) server. Alongside the GDB server, Bloom provides an optional GUI for insight into the connected AVR target. Metadata homepage URL: source URL: license: LGPLv3 platforms: linux
Change:
version = "3.1.0"; <del> # At first start, the program checks for supported operating systems by calling `lsb_release -a` # and only runs when it finds Debian/Ubuntu. So we present us as Debian an make it happy. fake-lsb-release = writeShellScriptBin "lsb_release" '' echo "Distributor ID: Debian" echo "Description:    Debian GNU/Linux 10 (buster)" echo "Release:        10" echo "Codename:       buster" ''; binPath = lib.makeBinPath [ fake-lsb-release ]; </del> systemArgs = rec { x86_64-linux = rec { src = fetchurl {

Discussion:
Running results in the following error message showing up: which roughly translates to: Run , e.g. via . App should run without causing error that prevents usage. See previous issue & . The runtime error is probably related to:
I'm sorry for the delay, but I did't have much free time lately. I could bisect the issue back to , which adds the file to NixOS. Digging into the node module used to handle the OS detection () reveals that in fact this file is preferred over the binary, which renders the fake data workaround ineffective. I will open a PR soon to fix this.

Installing fails due to missing command : Install , e.g. via . App should build, install & run without errors.
Looks like was removed in as part of was this change intended?
Probably not. Let me see...
Oh, yes, it seemed to me that it was only intended as an internal function for autoPachelf inner loop. Obviously, with bash nothing is really "internal". I think that you should be able to use autoPachelf for the same goal. Let me have a second look at it.
Does not seem like is a nixpkgs thing. I guess that is why I missed such a use case when refactoring. You should not really be using that function. You should let autoPatchelf find the right things to do for you in the whole file tree. There are plenty of examples, sometimes quite involved, of the expected usage of autopatchelfhook in nixpkgs. Still willing to have a look if you point me to the sources of breitbandmessung.
is part of nixpkgs, but it also seems to be the only package in here that uses :
Oh, I see. Do you happen to know why one would want to patch only that file, and specifically not the others ?
I'm not entirely sure, but I just replaced with without any other changes, and it still seems to build (in an older nixpkgs version before that python rewrite). On the latest nixpkgs master, I can get the build working with: Now the GUI shows a curious error, though: which roughly translates to: I get the same error when I try to run from an older nixpkgs state that still has , though. So, it doesn't seem related to the patchelf change.
The runtime error is probably related to: Perhaps has some insight as to why this stopped working.
Yes, indeed. The error happens because for some reason the other files should not be modified, only that one. And that is not feasible with my rewrite. Please have a look at my patch in , to test if it works for you. I think it is a reasonable way forward without having to re-introduce autoPatchelfFile.
Change:
, appdirs , argcomplete , colorama <del> , gnugrep </del> <ins> , nose2 , semver </ins> }: buildPythonPackage rec { pname = "milc"; <del> version = "1.0.10"; </del> <ins> version = "1.3.0"; </ins> src = fetchFromGitHub { owner = "clueboard"; repo = "milc"; rev = version; <del> sha256 = "04mk057b6jh0k4maqkg80kpilxak9r7vlr9xqwzczh2gs3g2x573"; </del> <ins> sha256 = "sha256-koyOBz+pB/vkTHOR1p77ACO11/ULDIBzqsszUUpnE88="; </ins> }; <del> checkInputs = [ gnugrep ]; </del> propagatedBuildInputs = [ appdirs argcomplete colorama ]; <del> # Upstream has a nose2 test suite that runs this hello script in a handful of # ways, but it's not in setup.py and makes assumptions about relative paths in # the src repo, so just sanity-check basic functionality. </del> <ins> checkInputs = [ nose2 semver ]; </ins> checkPhase = '' <del> patchShebangs ./hello ./hello | grep "Hello, World" </del> <ins> patchShebangs example hello nose2 </ins> ''; <ins> pythonImportsCheck = [ "milc" ]; </ins> meta = with lib; { description = "An Opinionated Batteries-Included Python 3 CLI Framework"; homepage = "https://milc.clueboard.co";

Discussion:
Project description A program to help users work with QMK Firmware. Metadata homepage URL: source URL: license: mit platforms: anywhere where python runs
Change:
preFixup = '' # We cannot use -exec since wrapProgram is a function but not a # command. <del> for bin in $( find "$out" -executable -type f -not -path '*/languages/ruby/lib/gems/*' ); do </del> <ins> # # jspawnhelper is executed from JVM, so it doesn't need to wrap it, # and it breaks building OpenJDK (#114495). for bin in $( find "$out" -executable -type f -not -path '*/languages/ruby/lib/gems/*' -not -name jspawnhelper ); do </ins> if patchelf --print-interpreter "$bin" &> /dev/null || head -n 1 "$bin" | grep '^#!' -q; then wrapProgram "$bin"  --prefix LD_LIBRARY_PATH : "${runtimeLibraryPath}"

Discussion:
Describe the bug The derivation does not build A clear and concise description of what the bug is. To Reproduce Steps to reproduce the behavior: -build -A openjdk15 Additional context 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 system: host os: multi-user?: sandbox: version: channels(tsteinbach): nixpkgs:
This might be relevant:
Maybe this is related to jspawnhelper and the extra wrappers to adoptopenjdk-bin-14 (the bootstrap jdk for openjdk-15) in ()? My computer is slow so I can't really check. cc
Facing the same issue with , is there a temporary workaround? Can I override 's version somehow? The issue occurs when I try to build with support, which tries to build .
you are correct, that commit introduced the issue. I've opened a PR to revert it pending a proper fix.
Opened PR: . We can build now.