jiebi/CodeConvo huggingface dataset:
Change:
}; patches = [ <del> ./use-packaged-deps.patch </del> <ins> # Unconditionally depend on packaged yt-dlp. This removes the ability to # use youtube_dl, which is unmaintained and considered vulnerable (see # CVE-2024-38519). ./use-packaged-yt-dlp.patch </ins> ]; propagatedBuildInputs = [

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:
"CVE-2022-38928" "CVE-2022-41842" "CVE-2022-41843" <del> "CVE-2022-41844" </del> "CVE-2022-43071" "CVE-2022-43295" "CVE-2022-45586" "CVE-2022-45587" <del> "CVE-2023-2662" "CVE-2023-2663" "CVE-2023-2664" </del> "CVE-2023-26930" "CVE-2023-26931" "CVE-2023-26934"

Discussion:
XPDF updated their version from 4.04 → 4.05 and seem to have broken the download URL to the older version. returns a 404, but works
Change:
}; in releaseTools.nixBuild rec { name = "hydra-${version}"; <del> version = "2017-06-22"; </del> <ins> version = "2017-07-24"; </ins> inherit stdenv; src = fetchFromGitHub { owner = "NixOS"; repo = "hydra"; <del> rev = "803833aba77e1082c14857aa26933fc7fe5ae190"; sha256 = "1cnxpsan8l6fnbr73n0qxxq1szlda1n3qfkk9k9ic8ijk7md4pvs"; </del> <ins> rev = "a6d9201947aa1468d31ef5c2651251ceeefceb5c"; sha256 = "0hk5pxzn94ip3nyccxl91zc5n6wd1h2zcbhdq9p38wa4lrnnm5zv"; </ins> }; buildInputs =

Discussion:
I noticed that hydra fails to build on the latest (): I guess this is related to the recent .
Yeah, we should update Hydra in Nixpkgs. Upstream does build
If someone can make a PR to bump Hydra I'd be happy to review that!
see: and
Change:
haxe_3_2 = throw "'haxe_3_2' has been removed because it is old and no longer used by any packages in nixpkgs"; # Added 2023-03-15 haxe_3_4 = throw "'haxe_3_4' has been removed because it is old and no longer used by any packages in nixpkgs"; # Added 2023-03-15 hepmc = throw "'hepmc' has been renamed to/replaced by 'hepmc2'"; # Converted to throw 2023-09-10 <ins> hikari = throw "hikari has been removed from nixpkgs, it was unmaintained and required wlroots_0_15 at the time of removal"; # Added 2024-03-28 </ins> hip = throw "'hip' has been removed in favor of 'rocmPackages.clr'"; # Added 2023-10-08 hipcc = throw "'hipcc' has been replaced with 'rocmPackages.hipcc'"; # Added 2023-10-08 hipchat = throw "'hipchat' has been discontinued since 2019; upstream recommends Slack."; # Added 2023-12-02

Discussion:
With merged we want to eventually drop . That'll take at least a couple of months though and we still have around as well. I'll just open this issue so that we don't forget about it. The affected packages should switch to the latest wlroots release when possible (usually a new upstream release). There's no hurry but let's use this issue to track the current progress. Packages: TODO (currently all packages that depend on wlroots -I'll update this when we're getting closer) Previous issue:
need rebuild [x] waybar [x] mpvpaper [x] qt-video-wlr [x] wl-gammactl [x] hyprpicker TODO [ ] hikari [x] waybox: [x] pywlroots: 0.16 has been released and adapted to wlroots 0.16, but qtile need pywlroots 0.15 [x] qtile [x] phoc [x] cage: [x] cagebreak
Change:
python312Packages.buildPythonPackage rec { pname = "ark-pixel-font"; <del> version = "2024.04.05"; </del> <ins> version = "2024.05.12"; </ins> src = fetchFromGitHub { owner = "TakWolf"; <del> repo = pname; rev = version; hash = "sha256-G34cu/mSt/p8UPJt+Q1T2qy6d9LGgT1Jslt9syRz5eo="; </del> <ins> repo = "ark-pixel-font"; rev = "refs/tags/${version}"; hash = "sha256-PGhhKWHDpvOqa3vaI40wuIsAEdWGb62cN7QJeHQqiss="; </ins> }; format = "other";

Discussion:
looking over broken python packages for ZHF and pixel-font-builder is missing a python module and needs a dependency relaxed. Steps to reproduce the behavior: *pixel-font-builder" pcffont not part of nixpkgs would add it but no longer a maintainer <!-- 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]:
Change:
<ins> { lib, rustPlatform, fetchFromGitHub, cryptsetup, pkg-config, }: rustPlatform.buildRustPackage rec { pname = "fido2luks"; version = "0.2.21"; src = fetchFromGitHub { owner = "shimunn"; repo = pname; rev = version; sha256 = "sha256-bXwaFiRHURvS5KtTqIj+3GlGNbEulDgMDP51ZiO1w9o="; }; cargoPatches = [ ./0001-libcryptsetup-rs-bump-version-to-0.9-55.patch ./0002-cargo-update.patch ]; nativeBuildInputs = [ pkg-config rustPlatform.bindgenHook ]; buildInputs = [ cryptsetup ]; cargoHash = "sha256-BcwcgQzNH1p9pOVbelaGTN7bKqDgvxD4Red2JeavpJQ="; meta = { description = "Decrypt your LUKS partition using a FIDO2 compatible authenticator"; homepage = "https://github.com/shimunn/fido2luks"; license = lib.licenses.mpl20; maintainers = with lib.maintainers; [ mmahut ]; platforms = lib.platforms.linux; }; } </ins>

Discussion:
Steps to reproduce the behavior: Enable or run <!-- 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]:
this seems to still be an issue
Issue filed upstream, fix was a simple update to as well as a for good measure.
(I kinda figured the reference as rendered by GitHub immediately above my comment would be sufficient)
shimunn has responded on the issue on the upstream repo, and is asking us to start using 0.3. I'd personally suggest we stick with 0.2 and either vendor it or patch it. The changed files are just and , which I'm attaching both of as confirmed working. I'm not sure the preferred way to address it, but I hope this helps.
Change:
] ++ lib.optionals (versionAtLeast version "4.4") [ "--link-model=static" ] ++ map (lib: "--use-system-${lib}") system-libraries; <ins> # This seems to fix mongodb not able to find OpenSSL's crypto.h during build hardeningDisable = [ "fortify3" ]; </ins> preBuild = '' sconsFlags+=" CC=$CC" sconsFlags+=" CXX=$CXX"

Discussion:
Currently is broken on unstable. Steps to reproduce the behavior: mongodb log output ! <!-- 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.
Looking at the reveals that we probably need .
Change:
url = "https://gitlab.gnome.org/GNOME/mutter/-/commit/285a5a4d54ca83b136b787ce5ebf1d774f9499d5.patch"; sha256 = "/npUE3idMSTVlFptsDpZmGWjZ/d2gqruVlJKq4eF4xU="; }) <ins> # Revert clutter optimization causing issues on X11 # https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2667 # Will be replaced with a proper fix in 43.2 # https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6054 (fetchpatch { url = "https://gitlab.gnome.org/GNOME/mutter/-/commit/7e7a639cc5132cf3355e861235f325540fe56548.patch"; sha256 = "NYoKCRh5o1Q15c11a79Hk5tGKq/jOa+e6GpgBjPEepo="; revert = true; }) # Backport edge resistance fix (should be part of 43.2) # https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2687 (fetchpatch { url = "https://gitlab.gnome.org/GNOME/mutter/-/commit/accf532a29ea9a1d70880dfaa1834050aa3ae7be.patch"; sha256 = "XAHcPGQFWfZujlqO/cvUryojPCMBBSxeIG06BesDQQw="; }) </ins> ]; mesonFlags = [

Discussion:
I already updated my system to and it generally works well, but i have one bug so far: When i maximize apps, some of them freeze when maximized. They don't seem to crash but the window's content visibly freezes. Steps to reproduce the behavior: gnome by double-clicking the title bar or pressing alt+up stuff in the shell, observe that the window content is frozen and doesn't show the inputs -maximize it and see that the app indeed accepted the inputs. This does not occur with all apps, only some. It also seems to work with most of the time, but is my most reliable reproducer so far. Maximizing an app does not make its window content freeze A screenshot of a frozen app would not show anything helpful <!-- 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
Are you using Wayland or X11 session? (See e.g. environment variable.) I can reproduce this consistently on unstable as well with GNOME Terminal, Boxes, Console and gedit (all GTK 3 apps) but not with GNOME Text Editor, Control Center or Calculator (GTK 4). GTK version: 3.24.34 GNOME Shell (X11)
i am on x11
Change:
buildInputs = [ libxslt docbook_xsl makeWrapper ]; preFixup = '' <ins> # fallback values need to be last </ins> wrapProgram "$out/bin/xdg-user-dirs-update"  <del> --prefix XDG_CONFIG_DIRS : "$out/etc/xdg" </del> <ins> --suffix XDG_CONFIG_DIRS : "$out/etc/xdg" </ins> ''; meta = with stdenv.lib; {

Discussion:
The xdg-user-dirs package contains a file named . A module allowing to customize this file would be great.
GNOME users, at least, already have generated in their profile by the . That would override the XDG module.
The command, executed in the GNOME session script you are referring to, reads the file, translates it if needed and places it in . Yes, this is exactly what I am talking about. If can be customized, then the GNOME session script would copy the customized one.
This looks like a duplicate of . The environment variable determines the search paths for . This is currently as a profile-relative path variable. For this to work, I think it would also need to define as a profile non-relative path so that a module could produce the file in that path.
I'm also interested in a way to customize xdg-user-dirs
There is little need for dedicated options, you can just use in your .
It does not work... What I have tried so far in a VM: removing the user homedir + changing to + removing the user homedir + changing to + removing the user homedir + I am using Gnome as a DE and the following user-dirs structure:
will not be enough. relies on to run so you need to re-login for it to be triggered.
I did reboot the VM after every and then logged in as the unpriviledged user
Hmm, apparently, it should have been , not or .
... sorry for the delay... But I just tried with only this And it does not use the user-dirs I configure above
Okay, there are several issues here: correctly points out, is profile-relative variable and since it is set, will not be used as per the : could add to which would add it to but that will conflict with the file from the preset file from the package . , I have came up with the following abomination to add to your : But again, it does not work. Turns out we are prefixing the with presets when running as well. With the patch and the horrendous snippet, I can confirm the expected directories were created. We should try to find out how to make the environment variable contain before all the profile-related stuff so that the simple solution works.
now contains full fix enabling us to use as suggested in
Awesome .... I just built from your branch and works like a charm.

Thanks a lot, I owe you one The config I'm currently using after the developments in is...
you probably want to reopen this, because functionality implemented here is currently broken. Please see:
As mentioned in the , there is a prerequisite of and having something that runs autostart entries (which DEs like GNOME or Plasma do out of the box).
Change:
license = lib.licenses.gpl2; maintainers = [ maintainers.puffnfresh ]; platforms = platforms.linux; <del> broken = true; # Last evaluated on Hydra on 2021-05-18 </del> <ins> broken = stdenv.isLinux && stdenv.isAarch64; </ins> }; }

Discussion:
Describe the bug It's impossible to install natron as the package is marked as broken. To Reproduce Steps to reproduce the behavior: natron to systemPackages Expected behavior Package to system as usual Screenshots [nix sudo nixos-rebuild switch building Nix... building the system configuration... error: --- ThrownError
------------------------------------------------- nix-build Package ‘natron-2.1.9’ in /nix/store/h56h9jaa88b5mhwmg7hqn2w426ljg63c-nixos- is marked as broken, refusing to evaluate. a) For you can set { = true; } in to override this. b) For , , or any other Nix command you can add { allowBroken = true; } to (use '--show-trace' to show detailed location information) system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: yaml attribute: module:
note: it seems to work when installed via flatpak ( on flathub)
I marked this as stale due to inactivity. &rarr;
Change:
]}" ] ++ lib.optionals (stdenv.buildPlatform != stdenv.hostPlatform) [ "--with-build-cc=${buildPackages.stdenv.cc}/bin/${buildPackages.stdenv.cc.targetPrefix}cc" <del> ]; </del> <ins> ] ++ (lib.optionals (stdenv.cc.bintools.isLLVM && lib.versionAtLeast stdenv.cc.bintools.version "17") [ # lld17+ passes `--no-undefined-version` by default and makes this a hard # error; ncurses' `resulting.map` version script references symbols that # aren't present. # # See: https://lists.gnu.org/archive/html/bug-ncurses/2024-05/msg00086.html # # For now we allow this with `--undefined-version`: "LDFLAGS=-Wl,--undefined-version" ]); </ins> # Only the C compiler, and explicitly not C++ compiler needs this flag on solaris: CFLAGS = lib.optionalString stdenv.isSunOS "-D_XOPEN_SOURCE_EXTENDED";

Discussion:
Steps to reproduce the behavior: Found while building gcc with <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Adding as this looks like a very similar issue to Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
I believe this is fixed in
Amazing, I wasn't aware you already made a patch. I've been running through to find issues so it could be possible to make a NixOS system with LLVM.
Change:
{ lib, stdenv, fetchurl, pkg-config, dbus, nettle, fetchpatch <del> , libidn, libnetfilter_conntrack }: </del> <ins> , libidn, libnetfilter_conntrack, buildPackages }: </ins> with lib; let

Discussion:
Describe the bug fails to cross-compile on atleast and . it fails with: To Reproduce Steps to reproduce the behavior: - Expected behavior dnsmasq is successfully cross-compiled. 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(root): channels(betaboon): nixpkgs:
I marked this as stale due to inactivity. &rarr;
This is still relevant.
Change:
<ins> { lib , stdenv , fetchFromGitHub , libX11 }: stdenv.mkDerivation rec { pname = "xmcp"; version = "unstable-2020-10-10"; src = fetchFromGitHub { owner = "blblapco"; repo = "xmcp"; rev = "ee56225f1665f9edc04fe5c165809f2fe160a420"; sha256 = "sha256-B3YkYrVEg6UJ2ApaVook4N2XvrCboxDMUG5CN9I79Sg="; }; buildInputs = [ libX11 ]; installPhase = '' runHook preInstall install -Dm0755 xmcp $out/bin/xmcp runHook postInstall ''; meta = with lib; { description = "Tiny color picker for X11"; homepage = "https://github.com/blblapco/xmcp"; license = licenses.gpl3Plus; maintainers = with maintainers; [ azahi ]; platforms = platforms.linux; }; } </ins>

Discussion:
Updating the unstable channel fails on Darwin: this seems to be due to the by-default case-preserving nature of APFS (and HFS+), introduced with this PR: which adds a path which to macOS is the same as the already existing path. Steps to reproduce the behavior: the unstable channel to a macOS machine A new version of the channel is successfully to the machine. Please run and paste the result.
My bad. Should we add a channel blocker label to this to get the PR merged faster?
Change:
<ins> { lib , buildGoModule , fetchFromGitHub , stdenv }: let finalAttrs = { pname = "fm"; version = "0.16.0"; src = fetchFromGitHub { owner = "mistakenelf"; repo = "fm"; rev = "v${finalAttrs.version}"; hash = "sha256-wiACaszbkO9jBYmIfeQpcx984RY41Emyu911nkJxUFY="; }; vendorHash = "sha256-AfRGoKiVZGVIbsDj5pV1zCkp2FpcfWKS0t+cTU51RRc="; meta = { homepage = "https://github.com/mistakenelf/fm"; description = "A terminal based file manager"; changelog = "https://github.com/mistakenelf/fm/releases/tag/${finalAttrs.src.rev}"; license = with lib.licenses; [ mit ]; mainProgram = "fm"; maintainers = with lib.maintainers; [ AndersonTorres ]; }; }; in buildGoModule finalAttrs </ins>

Discussion:
Project description A terminal based file manager Metadata homepage URL: source URL: license: mit platforms: unix, linux, darwin, ... note this is distinct from the previously packaged  package, also a file manager tho using GTK rather than using Bubbles
Let's play!
Change:
nativeBuildInputs = [ copyDesktopItems <ins> makeWrapper </ins> wrapGAppsHook ];

Discussion:
Koodo reader is an electron application, and although the build process to add the proper ozone flags when the app is launched in a Wayland environment, it seems for some reason, it's not working as expected: But launching the app with the required flags, it works: The process arguments seem weird: Notice that the the by the package are truncated after the first space . I tried splitting up the flag into two sentences to avoid spaces: But now it looks l like the process does not pick up the environment variables: The variables exist, I define them as . Changing the above override to explicitly set the ozone flags (without the shell expansion conditional) works. Other packages like do the same shell expansion, and they also work in my environment without overriding anything. Steps to reproduce the behavior: in a wayland environment (I'm using hyprland) if the application is using xwayland by running shows the application again but with the ozone flags the app does not use xwayland: Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
I'm not a wayland user, so I usually just copy this line from other electron apps' definitions and hope it works. I think the issue here is that when is present will use the binary implementation, which doesn't expand shell variables, thus not making this work. It looks like I forgot about this behaviour when packaging this.
Change:
# The closure of the init script of boot stage 1 is what we put in # the initial RAM disk. initialRamdisk = pkgs.makeInitrd { <ins> name = "initrd-${kernel-name}"; </ins> inherit (config.boot.initrd) compressor prepend; contents =

Discussion:
always has the same , and the same filename inside. Build NixOS with , look into I think it would be sometimes more convenient if the kernel version would be clear for each (which is actually initramfs). I think it would be better to literally include the as a suffix to .
This sounds like a sane idea to me.
Change:
stdenv.mkDerivation rec { pname = "zimlib"; <del> version = "8.2.0"; </del> <ins> version = "9.1.0"; </ins> src = fetchFromGitHub { owner = "openzim"; repo = "libzim"; rev = version; <del> sha256 = "sha256-ab7UUF+I0/xaGChvdjylEQRHLOjmtg/wk+/JEGehGLE="; </del> <ins> hash = "sha256-yWnW/+CaQwbemrNLzvQpXw5yvW2Q6LtwDgvA58+fVUs="; </ins> }; testData = fetchzip rec { <del> passthru.version = "0.4"; </del> <ins> passthru.version = "0.5"; </ins> url = "https://github.com/openzim/zim-testing-suite/releases/download/v${passthru.version}/zim-testing-suite-${passthru.version}.tar.gz"; <del> sha256 = "sha256-2eJqmvs/GrvOD/pq8dTubaiO9ZpW2WqTNQByv354Z0w="; </del> <ins> hash = "sha256-hCIFT1WPDjhoZMlsR2cFbt4NhmIJ4DX1H/tDCIv4NjQ="; </ins> }; nativeBuildInputs = [

Discussion:
Package name: zimlib Latest released version: 9.1.0 <!-- Search your package here: --- Current version on the unstable channel: 8.2.0 Current version on the stable/release channel: 8.2.0 <!-- 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! --- 0 made zimlib compatible with gtest 1.13+, and is going to break you otherwise. 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 reason I initially filed this is that both 9.0.0 and 9.1.0 have a compilation error (mismatched-new-delete). However, it seems perfectly safe to bring it down to a warning, so I'll open the PR for this one as well.
Change:
<del> { lib, stdenv, fetchurl, fetchzip, libogg, libvorbis, libao, pkg-config, curl , speex, flac }: </del> <ins> { lib, stdenv, fetchurl, libogg, libvorbis, libao, pkg-config, curl , speex, flac , autoreconfHook }: stdenv.mkDerivation rec { pname = "vorbis-tools"; version = "1.4.2"; </ins> <del> let debPatch = fetchzip { url = "mirror://debian/pool/main/v/vorbis-tools/vorbis-tools_1.4.0-11.debian.tar.xz"; sha256 = "0kvmd5nslyqplkdb7pnmqj47ir3y5lmaxd12wmrnqh679a8jhcyi"; }; in stdenv.mkDerivation { name = "vorbis-tools-1.4.0"; </del> src = fetchurl { <del> url = "http://downloads.xiph.org/releases/vorbis/vorbis-tools-1.4.0.tar.gz"; sha256 = "1g12bnh5ah08v529y72kfdz5lhvy75iaz7f9jskyby23m9dkk2d3"; </del> <ins> url = "http://downloads.xiph.org/releases/vorbis/vorbis-tools-${version}.tar.gz"; sha256 = "1c7h4ivgfdyygz2hyh6nfibxlkz8kdk868a576qkkjgj5gn78xyv"; </ins> }; <del> postPatch = '' for patch in $(ls "${debPatch}"/patches/*.{diff,patch} | grep -v debian_subdir) do patch -p1 < "$patch" done ''; nativeBuildInputs = [ pkg-config ]; </del> <ins> nativeBuildInputs = [ autoreconfHook pkg-config ]; </ins> buildInputs = [ libogg libvorbis libao curl speex flac ]; meta = with lib; {

Discussion:
, (nixos-unstable) (nixos-unstable) (nixos-unstable) (nixos-unstable) (nixos-unstable) Scanned versions: nixos-unstable: . May contain false positives.
BTW, I opened
CVE-2014-9638: Fixed upstream at , not released yet. CVE-2014-9639: Fixed upstream at , not released yet. CVE-2014-9640: Fixed upstream at , not released yet. CVE-2015-6749: Fixed upstream at , not released yet. CVE-2017-: Not fixed upstream, though apparently covers this case according to .
I wonder when they manage to release years-old fixes :-/