jiebi/CodeConvo huggingface dataset:
Change:
patchShebangs tests/ff-load-save/tests_ff_load_save.sh tests/opencl/opencl_test.sh tools/xml_insert.sh ''; <ins> postFixup = '' # Cannot be in postInstall, otherwise _multioutDocs hook in preFixup will move right back. moveToOutput "share/doc" "$devdoc" ''; </ins> # tests fail to connect to the com.apple.fonts daemon in sandboxed mode doCheck = !stdenv.isDarwin;

Discussion:
Package name: gegl Latest released version: 0.4.48 <!-- Search your package here: --- Current version on the unstable channel: 0.4.46 Current version on the stable/release channel: 0.4.46 <!-- 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. -- I can take over the package if you wish. Note for maintainers: Please tag this issue in your PR. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
If you are able to bump the package (and babl), feel free. I probably will not be able to get to it this week.
Change:
github = "calbrecht"; name = "Christian Albrecht"; }; <ins> callahad = { email = "dan.callahan@gmail.com"; github = "callahad"; name = "Dan Callahan"; }; </ins> calvertvl = { email = "calvertvl@gmail.com"; github = "calvertvl";

Discussion:
As described in , GNOME 3 needs the to handle authenticating Thunderbolt 3 devices. This is not yet packaged for NixOS. I've bolt myself but have thus far been unsuccessful. Start a Gnome 3 session Navigate to Settings → Devices → Thunderbolt Expected Results: A nice GUI as . Actual Results: An error message: ! (Note: The error message is slightly misleading. Thunderbolt 3 is supported and working on my laptop, albeit with authorization disabled, but without GNOME doesn't know that.) system: host os: multi-user?: sandbox: version: channels(root): nixpkgs:
Can you share the errors you have encountered when packaging? Perhaps we can point you to solution.
Right now I'm hitting two roadblocks with bolt itself: the man pages fails somewhere inside asciidoc: I'm not sure how to get more information / further work on that. I disable manpage generation (), everything compiles and links just fine but then fails with:
Yeah, meson sometimes gives incredibly useless error messages. The problem is the build trying to install files in and , which it looks up through pkgconfig. Adding these fixes these: We'll also need to knock out as it tries to create a directory in . This fixed the build for me:
You can try to add flag to the asciidoc command in the meson file (I recommend setting to the local checkout of the project in question). As for the second error, Meson only calls when it fails to write to install destination, which means that some is probably wrong.
There ought to be a message Perhaps you can find it in build directory under if you run with .
Woohoo! ! Now I just have to: things up out how to get the systemd unit file linked out how to properly test a patch against this repo request!
We'll have to make module, something like this: Will probably need too.
Change:
patchelf --set-interpreter ${{glibc}}/lib/ld-linux-x86-64.so.2 {{}} ; ''""" <del> derivation = f"""{{ </del> <ins> return f"""stdenv.mkDerivation {{ </ins> name = "{artifact_name}"; src = fetchurl {{ url = "{url}";

Discussion:
I'm trying out the new Julia framework, but the following command fails Am I doing it wrong? If I only ask for the "Plots" package it works. <!-- 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]:
Are you doing any overrides?
Hmm, this is arising from a Julia artifact in here: The artifact URL is given as The Nix code we generate as part of the Julia machinery looks like this: The URL seems to be valid. The problem seems to be that it doesn't end in . So the Nix derivation downloads it, but doesn't unzip or untar it, which is why we run into a problem in the . I'm thinking we need to stick a into the call. I'll try this in a bit.
This works for this example if I add a name ending with . The problem, of course, is that Julia artifacts are not necessarily tarballs, but can be arbitrary files. I think what we need to do is parse the artifact URL and determine if it's an archive that the default knows how to handle. If so, we keep using the current derivation, and otherwise replace it with a plain call. Per the , the supported archive extensions are: ? The manual may not perfectly match the actual code; the relevant part of the default is .
No
Unfortunately I've found another failing case, unrelated to the previous (it fails with PR ) It fails to build , likely for the reason I reported in PR
Hi should I open another issue for ?
Or just reopen this one and use it as a tracker for future issues?
Let's reopen this one for the known issues.
This problem is due to the upstream issue where it can't precompile in a headless environment, as discussed originally in . It's also mentioned in the . The workaround is to use . Maybe we could open a Nixpkgs issue to track the upstream issue, but I view this primarily as an upstream problem.
You are right, I forgot about the workaround. Disabling pre-compilation works indeed.
Change:
<ins> { lib , stdenv , autoreconfHook , bash , boost , bzip2 , cereal_1_3_2 , cmake , curl , fetchFromGitHub , jemalloc , libgff , libiconv , libstaden-read , pkg-config , tbb_2021_8 , xz , zlib }: stdenv.mkDerivation (finalAttrs: { pname = "salmon"; version = "1.10.2"; pufferFishSrc = fetchFromGitHub { owner = "COMBINE-lab"; repo = "pufferfish"; rev = "salmon-v${finalAttrs.version}"; hash = "sha256-JKbUFBEsqnENl4vFqve1FCd4TI3n9bRi2RNHC8QGQGc="; }; src = fetchFromGitHub { owner = "COMBINE-lab"; repo = "salmon"; rev = "v${finalAttrs.version}"; hash = "sha256-kwqoUmVCqjr/xRxJjQKaFjjCQW+MFASHJ2f9OiAumNU="; }; patches = [ # Use pufferfish source fetched by nix ./fetch-pufferfish.patch ]; postPatch = "patchShebangs ."; buildInputs = [ (boost.override { enableShared = false; enabledStatic = true; }) bzip2 cereal_1_3_2 curl jemalloc libgff libstaden-read tbb_2021_8 xz zlib ] ++ lib.optionals stdenv.isDarwin [ libiconv ]; nativeBuildInputs = [ cmake pkg-config ]; strictDeps = true; meta = { description = "Tool for quantifying the expression of transcripts using RNA-seq data"; longDescription = '' Salmon is a tool for quantifying the expression of transcripts using RNA-seq data. Salmon uses new algorithms (specifically, coupling the concept of quasi-mapping with a two-phase inference procedure) to provide accurate expression estimates very quickly and while using little memory. Salmon performs its inference using an expressive and realistic model of RNA-seq data that takes into account experimental attributes and biases commonly observed in real RNA-seq data. ''; homepage = "https://combine-lab.github.io/salmon"; downloadPage = "https://github.com/COMBINE-lab/salmon/releases"; changelog = "https://github.com/COMBINE-lab/salmon/releases/tag/" + "v${finalAttrs.version}"; license = lib.licenses.gpl3Only; platforms = lib.platforms.all; maintainers = [ lib.maintainers.kupac ]; }; }) </ins>

Discussion:
Salmon is a bioinformatics tool to produce a highly accurate, transcript level quantification estimates from short-read RNA-seq data. It's mostly written in C++. There's a similar tool already in nixpkgs (Kallisto), but they both have a few unique features, so packaging Salmon is still useful. It's also quite a popular tool. homepage URL: source URL: license: GLP v3.0 platforms: linux, others?
I started packaging it, and made good progress. It's a way for me to learn Nix, but may need a few pointers to get it done
Open a draft PR, then.
Change:
<del> { lib, stdenv, python, makeWrapper, unzip , pipInstallHook , setuptoolsBuildHook , wheel, pip, setuptools }: stdenv.mkDerivation rec { pname = "pip"; inherit (pip) version; name = "${python.libPrefix}-bootstrapped-${pname}-${version}"; srcs = [ wheel.src pip.src setuptools.src ]; sourceRoot = "."; dontUseSetuptoolsBuild = true; dontUsePipInstall = true; # Should be propagatedNativeBuildInputs propagatedBuildInputs = [ # Override to remove dependencies to prevent infinite recursion. (pipInstallHook.override{pip=null;}) (setuptoolsBuildHook.override{setuptools=null; wheel=null;}) ]; postPatch = '' mkdir -p $out/bin '' + (pip.postPatch or ""); # `pip` does not necessarily have a `postPatch` field. nativeBuildInputs = [ makeWrapper unzip ]; buildInputs = [ python ]; dontBuild = true; installPhase = lib.optionalString (!stdenv.hostPlatform.isWindows) '' export SETUPTOOLS_INSTALL_WINDOWS_SPECIFIC_FILES=0 '' + '' # Give folders a known name mv pip* pip mv setuptools* setuptools mv wheel* wheel # Set up PYTHONPATH: # - pip and setuptools need to be in PYTHONPATH to install setuptools, wheel, and pip. # - $out is where we are installing to and takes precedence, and is where wheel will end so we can install pip. export PYTHONPATH="$out/${python.sitePackages}:$(pwd)/pip/src:$(pwd)/setuptools:$(pwd)/setuptools/pkg_resources:$PYTHONPATH" echo "Building setuptools wheel..." pushd setuptools rm pyproject.toml ${python.pythonForBuild.interpreter} -m pip install --no-build-isolation --no-index --prefix=$out  --ignore-installed --no-dependencies --no-cache . popd echo "Building wheel wheel..." pushd wheel ${python.pythonForBuild.interpreter} -m pip install --no-build-isolation --no-index --prefix=$out  --ignore-installed --no-dependencies --no-cache . popd echo "Building pip wheel..." pushd pip rm pyproject.toml ${python.pythonForBuild.interpreter} -m pip install --no-build-isolation --no-index --prefix=$out  --ignore-installed --no-dependencies --no-cache . popd ''; meta = { description = "Version of pip used for bootstrapping"; license = lib.unique (pip.meta.license ++ setuptools.meta.license ++ wheel.meta.license); homepage = pip.meta.homepage; }; } </del>

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- . nix-build '<nixpkgs' -A python3Packages.bootstrapped-pip --check --keep-failed 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: nix-store --read-log $(nix-instantiate '<nixpkgs' -A python3Packages.bootstrapped-pip) Tested on All single-character differences, swapping and . I cannot reproduce the problem with , so perhaps (like with ) we should simply wait until Python 3.11 is released and use that instead.
A later run () also has a different timestamp and checksum for vendored .exe files
was released Oct. 24, 2022 but it looks like we're still using 3.10 as the default .
Correct, following the update schedule () we can expect the update 'real soon now' :)
Change:
in stdenv.mkDerivation rec { pname = "koreader"; <del> version = "2023.04"; </del> <ins> version = "2024.03.1"; </ins> src = if stdenv.isAarch64 then fetchurl { url = "https://github.com/koreader/koreader/releases/download/v${version}/koreader-${version}-arm64.deb"; <del> sha256 = "sha256-uuspjno0750hQMIB5HEhbV63wCna2izKOHEGIg/X0bU="; </del> <ins> hash = "sha256-9Bu+mWfJuPaH5nV71JMrcGipiZWfcf19KfVauCW92+I="; </ins> } else fetchurl { url = "https://github.com/koreader/koreader/releases/download/v${version}/koreader-${version}-amd64.deb"; <del> sha256 = "sha256-tRUeRB1+UcWT49dchN0YDvd0L5n1YRdtMSFc8yy6m5o="; </del> <ins> hash = "sha256-EZ3iqp0A2BZwI343nvvp71RGQx6FPesUBy4Lha4Yz4U="; </ins> }; src_repo = fetchFromGitHub {

Discussion:
Package name: koreader Latest released version: 2024.03.1 <!-- Search your package here: --- Current version on the unstable channel: 2023.04 Current version on the stable/release channel: 2023.04 <!-- 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]:
please test
Change:
<ins> { lib , stdenv , fetchFromGitHub , qt5 , makeWrapper , libvibrant , libX11 , libXrandr , libxcb , linuxPackages }: stdenv.mkDerivation rec { pname = "vibrantLinux"; version = "2.1.10"; src = fetchFromGitHub { owner = "libvibrant"; repo = "vibrantLinux"; rev = version; hash = "sha256-rvJiVId6221hTrfEIvVO9HTMhaZ6KY44Bu3a5MinPHI="; }; nativeBuildInputs = [ makeWrapper ] ++ (with qt5; [ qmake wrapQtAppsHook ]); buildInputs = [ libX11 libXrandr libxcb libvibrant linuxPackages.nvidia_x11.settings.libXNVCtrl ] ++ (with qt5; [ qtbase qttools ]); postPatch = '' substituteInPlace vibrantLinux.pro  --replace '$$(PREFIX)' '$$PREFIX' ''; meta = with lib; { description = "A tool to automate managing your screen's saturation depending on what programs are running"; homepage = "https://github.com/libvibrant/vibrantLinux"; license = licenses.mit; maintainers = with maintainers; [ unclamped ]; platforms = platforms.linux; mainProgram = "vibrantLinux"; }; } </ins>

Discussion:
Project description vibrantLinux is a GUI tool to serves the same purpose as for Windows, which to modify the saturation of any given screen whenever certain programs are launched/are in focus. Metadata homepage URL: source URL: license: MIT platforms: Linux Required Dependencies [x] git [x] qt [x] libxcb [ ] libxcb-ewmh

Project description vibrantLinux is a GUI tool to serves the same purpose as for Windows, which to modify the saturation of any given screen whenever certain programs are launched/are in focus. Metadata homepage URL: source URL: license: MIT platforms: Linux Only
Bump. I have some low vision issues and "vibrance" makes it much easier to read the screen. Thanks!
Change:
homepage = "https://pysam.readthedocs.io/"; maintainers = with maintainers; [ unode ]; license = licenses.mit; <del> platforms = [ "i686-linux" "x86_64-linux" ]; </del> <ins> platforms = platforms.unix; </ins> }; }

Discussion:
(Apologies if this is the wrong place/format for this issue; I'm a Nix newcomer.) I'm trying to use the Python package as supported. I'd be happy to contribute a patch to change this if someone could help me figure out what needs to happen.
That sounds reasonable to me. The list of supported platforms came from , which doesn't mention MacOS, only that the package failed to build on aarch64-linux. I was locally able to build it on aarch64-darwin, so the restriction doesn't seem to be needed for MacOS. You can open a PR that adds (which is a list) to the platforms list (in Nix, is the list concatenation operator), following the .
per , failed due to lack of on aarch64. But nothing is marked as broken in . FWIW, I successfully built both and on . Any volunteers to test it on ?
Change:
vanillaPackages = { # recurse to build modules for the kernels <del> linux_4_4 = throw "linux 4.4 was removed because it reached its end of life upstream"; # Added 2022-02-11 linux_4_9 = recurseIntoAttrs (packagesFor kernels.linux_4_9); </del> <ins> linux_4_9 = throw "linux 4.9 was removed because it will reach its end of life within 22.11"; # Added 2022-11-08 </ins> linux_4_14 = recurseIntoAttrs (packagesFor kernels.linux_4_14); linux_4_19 = recurseIntoAttrs (packagesFor kernels.linux_4_19); linux_5_4 = recurseIntoAttrs (packagesFor kernels.linux_5_4); linux_5_10 = recurseIntoAttrs (packagesFor kernels.linux_5_10); linux_5_15 = recurseIntoAttrs (packagesFor kernels.linux_5_15); <del> linux_5_16 = throw "linux 5.16 was removed because it reached its end of life upstream"; # Added 2022-04-23 </del> linux_5_17 = throw "linux 5.17 was removed because it reached its end of life upstream"; # Added 2022-06-23 linux_5_18 = throw "linux 5.18 was removed because it reached its end of life upstream"; # Added 2022-09-17 linux_5_19 = throw "linux 5.19 was removed because it reached its end of life upstream"; # Added 2022-11-01

Discussion:
The Linux 4.9 LTS release will be EOL after 2023/01 and I hope we can remove it before the 22.11 release, so we don't carry it around until then. via cc kernel maintainer team
Thanks for the heads-up. I'd be fine with doing the removal right now (considering that it's LTS and having that one removed on stable may be an unpleasant surprise), but FWIW: we usually drop kernel releases when they get EOLed (also from stable branches), otherwise we wouldn't be able to provide non-LTS kernels on any stable branch anyways.
Change:
) ) { <del> rust = rustc'; </del> <ins> rust = crate_.rust or rustc; cargo = crate_.cargo or cargo; </ins> release = crate_.release or true; verbose = crate_.verbose or true; extraRustcOpts = [ ];

Discussion:
I'm running an issue with overriding the rust toolchain since , I pass the following to crate2nix: to set the toolchain when building something, since I don't want to override the toolchain globally. But after this PR it doesn't work because it uses the toolchain in instead of the one I'm passing in. Now I don't really know how to override the rust toolchain to the version I want. is a nightly version I got from This problem is caused by this optimization: Another issue is that the attribute is missing in rust-overlay:
I'm having this issue as well. I've overridden my input to my flake to as a workaround for now.
Hi, sorry for the delay, I'm back home now from "holiday". Can any of you give me a minimal flake that reproduces the issue so I can experiment and find the best way to fix it?
I'm also hitting this. I don't have a minimal flake but I can at least offer the error message which seems to be missing from the OP.
Let me know if this fixes it.
unfortunately it does not, because it still defaults to for the rustc compiler. I've created a reproduction here: As you can see in I'm overriding rustc and cargo to the specific nightly version I want, but when I run I get the following output: This is the rustc version that's current in nixpkgs, not the nightly I specified. Thanks a lot for looking into this
One problem with your reproducer is that it uses the for which takes an arg called not . I think that still wouldn't have solved it. I made some changes in the PR that would allow passing a custom toolchain via the but also using . I did some refactoring to get rid of the and variables.
Change:
sha256 = "0zp61axx93b7nrbsyhn2x4dnw7n9y6g4rys21hyqxk4khrnc2yr9"; }) ./CVE-2016-4912.patch <ins> ./CVE-2019-5544.patch </ins> ]; meta = with lib; {

Discussion:
, CVSSv3=9.8 (nixos-19.03, nixos-19.09, nixos-unstable) Scanned versions: nixos-19.03: ; nixos-19.09: ; nixos-unstable: . May contain false positives.
03 is out of support - we don't backport security fixes there anymore.
But this was also about nixos-unstable.
This was a grave mistake from your side. See
Change:
stdenv.mkDerivation rec { pname = "jetty"; <del> version = "9.4.39.v20210325"; </del> <ins> version = "9.4.41.v20210516"; </ins> src = fetchurl { url = "https://repo1.maven.org/maven2/org/eclipse/jetty/jetty-distribution/${version}/jetty-distribution-${version}.tar.gz"; <del> sha256 = "0mn3ranh599w946cnykj7sbkj4w7ddpdhly7njmalsgabfbk8qv5"; </del> <ins> sha256 = "sha256-hFQC1UiqZbbvyMf1FC3eqvVga3QdPWh0fbotatkVHBI="; </ins> }; dontBuild = true;

Discussion:
, CVSSv3=5.3 (nixos-21.05) Scanned versions: nixos-21.05: . Cc
Fixed by the linked PR .
Change:
hunspellTargetDirs = "$out/opt/Pulsar/resources/app.asar.unpacked/node_modules/spellchecker/vendor/hunspell_dictionaries"; hunspellCopyCommands = lib.concatMapStringsSep "n" (lang: "cp -r ${lang}/* ${hunspellTargetDirs};") hunspellDirs; in <del> stdenv.mkDerivation rec { </del> <ins> stdenv.mkDerivation { </ins> inherit pname version; src = with sourcesPath; fetchurl {

Discussion:
Package name: pulsar Latest released version: 1.118.0 Current version on the unstable channel: 1.117.0 Current version on the stable/release channel: 1.117.0 Notify maintainers
Sorry I'm super busy these days... I'll try to get back to this as soon as possible. In the meantime, please try the of this package if you can, and see if the resulting package build fine. Thank you!
i am not familiar with updateScript and not really urgently need the latest Pulsar version, but i think update request is a good way to keep actual nixpkgs's packages version.
Change:
nativeBuildInputs = with python3.pkgs; [ installShellFiles <ins> wrapGAppsNoGuiHook gobject-introspection </ins> setuptools-scm docutils

Discussion:
it's impossible to use due to an import error: Steps to reproduce the behavior: to run eg ratbagctl "shows something". (i.e. current mouse hardware/mapping etc.) (no gui, cli only) I (may) need because it has infos/options that are not yet fully implemented in Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:

When trying to launch whipper it instead fails with the following trace: Steps to reproduce the behavior: or any equivalent way of running the whipper program Clearly, I expect the program to execute without an error. I bisected the error and the bug was introduced in which bumped . <!-- 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]:
Note: Adding to double-wraps all executables, but allows to run successfully.
Also no double-wrapping.

As title says, openrazer-daemon no longer work after update. Steps to reproduce the behavior: system -daemon fail to start. Openrazer-daemon start on boot. If applicable, add screenshots to help explain your problem. Manually calling openrazer-daemon -Fv print me this: <!-- 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]:
overlay fix for anyone who have this issue.
This overlay fix worked for me, thank you!
Change:
nativeBuildInputs = [ pkgconfig gettext perl python ]; <del> propagatedBuildInputs = [ pcre zlib libffi ] ++ libiconvOrEmpty ++ libintlOrEmpty; </del> <ins> propagatedBuildInputs = [ pcre zlib libffi ] ++ optional (!stdenv.isDarwin) libiconvOrEmpty ++ libintlOrEmpty; </ins> configureFlags = optional stdenv.isDarwin "--disable-compile-warnings"

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