jiebi/CodeConvo huggingface dataset:
Change:
wrapProgram $out/bin/mendeleydesktop  --add-flags "--unix-distro-build"  <del> ${stdenv.lib.optionalString autorunLinkHandler ''--run "$out/bin/install-mendeley-link-handler.sh $out/bin/mendeleydesktop"''} </del> <ins> ${stdenv.lib.optionalString autorunLinkHandler # ignore errors installing the link handler ''--run "$out/bin/install-mendeley-link-handler.sh $out/bin/mendeleydesktop ||:"''} </ins> # Remove bundled qt bits rm -rf $out/lib/qt

Discussion:
A recent update broke mendeleydesktop for me so I can't start it anymore. System: 17.03.917. (Gorilla) Nix version: nix-env (Nix) 1.11.8 Nixpkgs version: 17.03.917. Channel: nixos
Clone of: (with a temporary fix).
is in my PATH.
Sorry, obviously I didn't read your problem well enough.
Is this still a problem? If so I'll get to fixing it right away :).
Please let me know if doesn't fix it for you!

Following the Mendeley update in , refuses to launch on one of my machine and spits out some errors half in French half in English: This led me to think that the problem was with and calling it specifically gives: So the problem seems to be a missing dependency on . Installing it with fixed the problem for me. And this correlates with the fact that on my other machines (where I have XFCE installed), I had no problem launching Mendeley but that on this machine (where I only have i3 installed), I had such problems. I'm not sure how to fix the problem in the derivation though. cc
Actually the other machines I have are laptops on which I have network-manager-applet and this is dependent on gconf. That's why Mendeley could run there.
I can confirm this is a problem, and will look into fixing it. Starting with the GConf stuff--what does installing it accomplish that we're not? I mean we /could/ include gconf2 in "propagatedUserEnvPkgs" but hopefully that's not necessary.
Please let me know if doesn't fix this for you, sorry for the delay!
Change:
githubId = 15379000; name = "schneefux"; }; <ins> schnow265 = { email = "thesnowbox@icloud.com"; github = "schnow265"; githubId = 57457177; name = "Luca Scalet"; }; </ins> schnusch = { github = "schnusch"; githubId = 5104601;

Discussion:
Project description goread is an RSS/Atom feed reader for your terminal. It allows you to categorize and follow feeds and read articles right in the terminal. Metadata homepage URL: source URL: license: gpl3 platforms: unix, linux, darwin Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Change:
installPhase = '' cp -r ${ipaexfont}/share/fonts/opentype/* lib-satysfi/dist/fonts/ cp -r ${junicode}/share/fonts/junicode-ttf/* lib-satysfi/dist/fonts/ <del> cp -r ${lm}/* lib-satysfi/dist/fonts/ cp -r ${lm-math}/otf/latinmodern-math.otf lib-satysfi/dist/fonts/ </del> <ins> cp -r ${lmodern}/share/fonts/opentype/public/lm/* lib-satysfi/dist/fonts/ cp -r ${lmmath}/share/fonts/opentype/latinmodern-math.otf lib-satysfi/dist/fonts/ </ins> make install PREFIX=$out LIBDIR=$out/share/satysfi mkdir -p $out/share/satysfi/ cp -r lib-satysfi/dist/ $out/share/satysfi/

Discussion:
A grep of : The latest version is 1.959 per I'd say that the texlive and fonts/lm-math versions can stay as they have different paths ( vs ), although ideally just the texlive version would stay, but the others are not helping anything at all.
cc for comments
– has meta, unpacks only the needed files – resides in the same directory with , tries to provide texmf So, perhaps, we should keep the implementation of under the name and make an alias. The satysfi needs to be fixed to use existing packages (also implements a duplicate of ).
Well, for texmf one would presumably use the TexLive package, as it has separated and outputs unlike the other packages. And it auto-updates along with the rest of TexLive. The only issue with using it as the sole package is that it's not a multiple output derivation so using it in the fonts list looks like rather than just . It shouldn't be that hard to set up TexLive to have attributes usable directly, by setting and so forth. Nix doesn't support multiple outputs for fixed-output derivations, so it'd be a bit of a hack.
The "packages" in are set up to be used with . They were not intended to be used in any other way.
Change:
requiredSystemFeatures = [ "big-parallel" ]; passthru = { <del> inherit cudaSupport cudaPackages gpuTargetString; cudaCapabilities = supportedCudaCapabilities; </del> <ins> inherit cudaSupport cudaPackages; </ins> # At least for 1.10.2 `torch.fft` is unavailable unless BLAS provider is MKL. This attribute allows for easy detection of its availability. blasProvider = blas.provider; <ins> } // lib.optionalAttrs cudaSupport { # NOTE: supportedCudaCapabilities isn't computed unless cudaSupport is true, so we can't use #   it in the passthru set above because a downstream package might try to access it even #   when cudaSupport is false. Better to have it missing than null or an empty list by default. cudaCapabilities = supportedCudaCapabilities; </ins> }; meta = with lib; {

Discussion:
I discovered today that overriding torchvision with does not work. At least not without making corresponding changes to torch. For example, We should either remove this argument and pull from torch or improve the ergonomics here somehow. cc Checkout nixpkgs at a relatively recent master commit, eg , and then run
can you test if fixes the problem? To be honest, including the argument for was a mistake in the first place -- it should (must?) use whatever was built with, so it should be inherit directly.
Maybe assert torch.cudaSupport is more explicit? Idk
I'm not super comfortable with asserts in the derivation because (afaik) they can't be overridden. Thoughts on me updating to ensure either both are compiled with CUDA, or neither are?
I understand it's a compromise. IIRC if we set here, we'll just exclude the broken package from ofborg and nixpkgs-review, contrary to the purpose.
Why do we need to be asserting or marking things as broken depending on ? shouldn't it build fine either way?
So the question is, should use , or should it accept as an argument and then possibly . I think that silently using may be surprising to people, but then again we're discussing some furnish while the thing is broken xD
ohhh i see, yeah that's tricky. i could envision someone creating a nix-shell with both and and then being very surprised to learn that is not built with CUDA support

From a brief look at the updated cuda section in the manual, it would be logical to take as an argument, rather than the compiled string. And to expose that in via gets even further beyond the scope, so let's skip it Originally posted by in
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Change:
rm "$timestamp" fi fi <del> done < <(find "$dir" -type f -perm -0100 -print0) </del> <ins> done < <(find "$@" -type f -perm -0100 -print0) </ins> stopNest }

Discussion:
I have been burned by this several times; and I am not alone: When calling with multiple arguments, we should either patch all of them or print an error. Ignoring arguments silently should be a crime. cc
Change:
<ins> #pragma once #include <iostream> #include <nix/types.hh> #include <string> nix::Strings parseAttrPath(const std::string & s); bool isVarName(const std::string & s); std::ostream & printStringValue(std::ostream & str, const char * string); </ins>

Discussion:
We can currently display a NixOS module option type using, for example: . It seems to me that, to maximize usability, should display this string. Also, the should display this information. Perhaps it should be toggleable, though, since options involving submodule types could be quite large. EDIT: Apparently the field is currently for any submodule type. It would be nice to either pretty-print the whole type or output some kind of structured data there. Run . There is no indication of the type of this option other than the default/example values. System: (NixOS: , Ubuntu/Fedora: , ...) Nix version: (run ) Nixpkgs version: (run ) Sandboxing enabled: (run )
cc
This was fixed in .
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 .
Change:
mkdir xchg mv saved-env xchg/ <del> diskImage=''${diskImage:-/dev/null} </del> eval "$preVM" if [ "$enableParallelBuilding" = 1 ]; then

Discussion:
Can't use runInLinuxVM? compared to: Please run and paste the results. system: host os: multi-user?: sandbox: version: channels(will): channels(root): nixpkgs:
Yeah, I think QEMU on master/unstable doesn't like passed as a device. Or maybe it happened if was passed multiple times.
Hmm, okay. Could it be related to host OS? I wouldn't expect so but some other machines don't have this problem and they're running 17.09 instead...
Could be. Maybe this '"consistent read" lock' what QEMU uses is only supported on new kernels?
Change:
{ lib , stdenv <del> , linuxPackages </del> , kernel , fetchFromGitHub <ins> , unstableGitUpdater </ins> }: <del> stdenv.mkDerivation rec { </del> <ins> stdenv.mkDerivation { </ins> pname = "framework-laptop-kmod"; <del> version = "0-unstable-2024-01-02"; </del> <ins> version = "0-unstable-2024-09-15"; </ins> src = fetchFromGitHub { owner = "DHowett"; repo = "framework-laptop-kmod"; <del> rev = "a9e8db9ba2959b75c1fb820ffac8fa189f0f63c3"; hash = "sha256-Ai/OxvkaKPltri8R0oyfmxQLUVfaj6Q8vebrhmWYhUU="; </del> <ins> rev = "6164bc3dec24b6bb2806eedd269df6a170bcc930"; hash = "sha256-OwtXQR0H4GNlYjVZ5UU5MEM6ZOjlV3B0x2auYawbS2U="; </ins> }; nativeBuildInputs = kernel.moduleBuildDependencies;

Discussion:
Steps to reproduce the behavior: framework-laptop-kmod with linuxPackagestesting Wanted to try the 6.11 Kernel cause there is a bug fixed in 'crosec' module which pings in kde wrong battery state <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
The same problem is present in 6.11.0:
Seems to be fixed now. Awesome!
Change:
<del> diff --git a/service.py b/service.py index 1d7b6e4..9782993 100644 --- a/service.py +++ b/service.py @@ -241,9 +241,9 @@ def playlistIndex(url, playlist): # Use the chosen resolver while forcing to use youtube_dl on legacy python 2 systems (dlp is python 3.6+) if xbmcplugin.getSetting(int(sys.argv[1]),"resolver") == "0" or sys.version_info[0] == 2: -    from lib.youtube_dl import YoutubeDL +    from youtube_dl import YoutubeDL else: -    from lib.yt_dlp import YoutubeDL +    from yt_dlp import YoutubeDL # patch broken strptime (see above) patch_strptime() </del>

Discussion:
When trying to update nixos-24.05 from revision to , the check and build fail because is newly marked insecure (unstable PR: , backport PR: ). This breaks users of the package. I don't need the youtube-dl functionality and I don't wanna allow this insecure package on my system. Therefore, I'd appreciate an easier method to not depend on youtube-dl. This requires being able to build sendtokodi without youtube-dl altogether (and ensure sendtokodi does not use it). Either by default or as build option. Upstream seems to be mostly inactive, they won't help us here. Steps to reproduce the behavior: insecure packages (default behavior) to include sendtokodi on recent NixOS 24.05 ( or later) or unstable . Stable NixOS doesn't break on channel updates. Sendtokodi can be used without allowing any insecure packages. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --(the relevant nixpkgs commits/PRs are already referenced, I cannot build the config on the broken revision) Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
sure code was never even used or executed in the entire life of this package in anyways, so all one has to do is remove from line and everything will be fine please go ahead and create a PR and it will be much appreciated :bow:
This isn't entirely true, as users can toggle between the two of them via a configuration. But regardless of that I agree that patching out the dependency is the right thing to do, even if it means that we will dishonor that configuration now. I've created to do so.
right, i sorta glossed over that part we should see if upstream wants to drop backend or not i suppose
Change:
isoImage.storeContents = [ pkgs.glibcLocales pkgs.sudo <del> pkgs.sudoWithVisudo </del> pkgs.docbook5 pkgs.docbook5_xsl pkgs.grub

Discussion:
The installer test was broken by the change mentioned below, along with the change which adds a keepVisudo option to the package build of sudo. The installer tests do not have network connectivity, therefore requiring that all packages be located on the iso from which they are being installed. The problem is that this patch forces one of the installed sudo derivations to differ from the default, forcing nix to attempt a rebuild of the derivation and subsequently failing to download the sudo sources. We need to either bundle both versions of the sudo derivation or simply remove the keepVisudo option and always keep it Is it a problem to keep visudo around for the default sudo derivation? Broken in:
Change:
npmBuildScript = "dist"; nativeBuildInputs = [ <del> python3 # Used by gyp </del> <ins> (python3.withPackages (ps: [ ps.setuptools ])) # Used by gyp </ins> ]; patches = [

Discussion:
Steps to reproduce the behavior: to build threema-desktop on latest nixos-unstable Issues happens as python3 switched from 3.11 to python 3.12, where disutils doesn't seem to be available. Look at the PR here for more context, and other packages with similar issues . Currently I've solved it locally just by using Python 3.11 instead of 3.12, using the following override. Ideally we should get threema-web to update their gyp version? Or we could do it ourself? OR we have something something , which we should maybe use? Unsure.
I am not maintaining any packages on Nixpkgs anymore, but another solution to this would be adding setuptools, like on
Sorry, I thought I had checked if you were maintainer for it still. Wasn't meant to bother you :)
Change:
, kdeclarative , plasma-framework , plasma-workspace <del> , gitUpdater </del> <ins> , unstableGitUpdater </ins> }: stdenvNoCC.mkDerivation rec { pname = "qogir-kde"; <del> version = "unstable-2023-10-20"; </del> <ins> version = "0-unstable-2024-06-28"; </ins> src = fetchFromGitHub { owner = "vinceliuice"; repo = pname; <del> rev = "1cfe8da54e6f76d5ce0d2234dcb4f5186431edb3"; hash = "sha256-Ts8cS7dH8RkfRgWvzDKLCC2G6Hsnvx0NAGstfxMIt+Y="; </del> <ins> rev = "5224dbdeed76c5ed4b7b5ff6d0b48ebe82547228"; hash = "sha256-qS0bVfweSXv2Sox3cXQ8PfcPD+WA6kwrEoS0ijxWZE8="; </ins> }; # Propagate sddm theme dependencies to user env otherwise sddm does

Discussion:
Package name: qogir-kde Latest released version: 2024-06-28 <!-- Search your package here: --- Current version on the unstable channel: 2023-10-20 Current version on the stable/release channel: 2023-10-20 <!-- 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:
"/tex/generic/config" # make it a real directory for scheme-infraonly ]; <del> nativeBuildInputs = [ makeWrapper ]; </del> <ins> nativeBuildInputs = [ makeWrapper libfaketime ]; </ins> buildInputs = pkgList.extraInputs; # This is set primarily to help find-tarballs.nix to do its job

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 --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 ) Tested on nixpkgs Notably the ordering of the words in and similar seem nondeterministic, perhaps the other differences are effects of that.
That is an issue with , respectively the tools called by , so it should be solved upstream.
fmtutil here is coming from texlive-scripts in - but it's the output of that's not reproducible. I'm now sure it's in dumping out the hyphenation exception strings in the (random) order in which they appear in the lua hashtable. I guess we should sort them in dictionary order. There is already a qsort routine, so perhaps we should put the exceptions in an array, sort that array using qsort, and only produce the result from that.
I think this is already referring to .
Huh! Indeed that covers the same issue - I did search before digging into this problem, but not good enough apparently :laughing: .
Change:
let remoteRepository = "/root/restic-backup"; remoteFromFileRepository = "/root/restic-backup-from-file"; <ins> remoteNoInitRepository = "/root/restic-backup-no-init"; </ins> rcloneRepository = "rclone:local:/root/restic-rclone-backup"; backupPrepareCommand = ''

Discussion:
Recent changes to the assume the presence of the list even when it is not in use (it defaults to null). This prevents the service from running. Problem line: Steps to reproduce the behavior: a backup service without the 'dynamicFilesFrom' option that is included in the service's ExecStart service failing due to error Argument should not be passed if is not in use <!-- 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.
cc
Please provide the relevant part of your configuration hughobrien am Mi., 1. Nov. 2023, 01:07:
The problematic section is unconditional so I do not believe the config matters. Nevertheless
Ah, I see. I'll send a fix in the evening. In the meantime, you can work around the problem by setting (which does not change anything if the repository already exists). hughobrien am Mi., 1. Nov. 2023, 15:08:
Change:
src = sqitchModule; dontBuild = true; <ins> nativeBuildInputs = stdenv.lib.optional stdenv.isDarwin shortenPerlShebang; </ins> installPhase = '' mkdir -p $out/bin for d in bin/sqitch etc lib share ; do

Discussion:
fails with the following error on macOS: To Reproduce Steps to reproduce the behavior: Expected behavior sqitch's version should be printed. Additional context seems to be the original sqitch main file, while exports in preparation of calling the original (perl) main file. However, still contains a shebang with all the library paths (each path is appended five times, but that's a different matter) as the environment variable, and when it's called, it fails with this error: Trial and error shows that limiting the shebang line to 512 character fixes the “exec format error” issue, and since there is no need to add all the paths (five times) to the shebang – since they are in the enviroment variable set by – they can be removed. This fixes the issue. Metadata Maintainer information:
Change:
yarn' = yarn.override { inherit nodejs; }; defaultYarnOpts = [ ]; <ins> esbuild' = esbuild.override { buildGoModule = args: buildGoModule (args // rec { version = "0.16.17"; src = fetchFromGitHub { owner = "evanw"; repo = "esbuild"; rev = "v${version}"; hash = "sha256-8L8h0FaexNsb3Mj6/ohA37nYLFogo5wXkAhGztGUUsQ="; }; vendorHash = "sha256-+BfxCyg0KkDQpHt/wycy/8CTG6YBA/VJvJFhhzUnSiQ="; }); }; </ins> # replaces esbuild's download script with a binary from nixpkgs patchEsbuild = path : version : '' mkdir -p ${path}/node_modules/esbuild/bin jq "del(.scripts.postinstall)" ${path}/node_modules/esbuild/package.json | sponge ${path}/node_modules/esbuild/package.json <del> sed -i 's/${version}/${esbuild.version}/g' ${path}/node_modules/esbuild/lib/main.js ln -s -f ${esbuild}/bin/esbuild ${path}/node_modules/esbuild/bin/esbuild </del> <ins> sed -i 's/${version}/${esbuild'.version}/g' ${path}/node_modules/esbuild/lib/main.js ln -s -f ${esbuild'}/bin/esbuild ${path}/node_modules/esbuild/bin/esbuild </ins> ''; in stdenv.mkDerivation rec {

Discussion:
Steps to reproduce the behavior: or see: Can someone nail the problem down to a specific pr or commit? <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --
Broken because of PR
Now broken because is insecure.
waiting for as nodejs 18 migration is blocked
Change:
"test_count_nonzero_str" "rolling_methods"  # floating percision error ~0.1*10^8 small "num_workers_config" # flaky <ins> "test_2args_with_array[pandas1-darray1-ldexp]"  # flaky </ins> ]; meta = {

Discussion:
Describe the bug There may be something flaky about the python3{789} build. It's been going on and off on hydra. I can't reliably reproduce the failures seen on hydra locally when building from the exact same commits that failed on hydra, but I have observed the same failure at least once on my machine. ! Expected behavior dask should build cleanly. Notify maintainers Metadata
Change:
# has a split module structure in one repo subPackages = ["." "connect/certgen"]; <del> vendorSha256 = "sha256-cQP1po9LGunFVocl4+HPs67oae2KpgyfRRB+xGVySUY="; </del> <ins> vendorSha256 = "1z4hzkl2n0074hhn154mkk3gvzwrl13g37v24zrp2aa6jifhimmj"; </ins> doCheck = false;

Discussion:
, CVSSv3=6.5 (nixos-21.11) HashiCorp Consul and Consul Enterprise 1.8.0 through 1.9.14, 1.10.7, and 1.11.2 has Uncontrolled Resource Consumption. Scanned versions: nixos-21.11: . Cc Cc Cc Cc
PR
Change:
{ mkDerivation, lib, extra-cmake-modules, <del> ffmpeg_3, kio, taglib </del> <ins> ffmpeg_4, kio, taglib </ins> }: mkDerivation {

Discussion:
Describe the bug Dolphin does not generate video thumbnails on unstable after the update to v20.12.1 . Removing in change appears to have resulted in dropping compatibility with ffmpeg 3. Updating the to reference instead of fixes the issue. To Reproduce Steps to reproduce the behavior: dolphin, ffmpegthumbs video thumbnails in dolphin Expected behavior See thumbnail generated for video files Notify maintainers
Change:
<del> { stdenv, fetchurl, fetchzip, pkgconfig, SDL2, libpng, zlib, xz, freetype, fontconfig </del> <ins> { stdenv, fetchurl, fetchzip, pkgconfig, SDL2, libpng, zlib, xz, freetype, fontconfig, libxdg_basedir </ins> , withOpenGFX ? true, withOpenSFX ? true, withOpenMSX ? true , withFluidSynth ? true, audioDriver ? "alsa", fluidsynth, soundfont-fluid, procps , writeScriptBin, makeWrapper, runtimeShell

Discussion:
OpenTTD as it is currently packaged does not support the XDG base directory specification. According to OpenTTD can support it if libxdg-basedir is available. I've tested this locally and indeed it works if I add libxdg_basedir to the buildInputs. But, adding this would be surprising behaviour to current users, since OpenTTD may suddenly start looking in a different place for its mods and saves and such. Is this something we'd want to change in nixpkgs, or maybe hide it behind a flag? I can open a PR for it but I'd also be happy leaving it in my local config.
It's a game, so it's unlikely that people will mind a change. cc