jiebi/CodeConvo huggingface dataset:
Code change:
if a folder is a substring of another folder, we don't delete it even if we have overrideFolders and the substring id got removed from the config. Steps to reproduce the behavior: a folder with id "xxx" a folder with id "yyyzzzxxx"; folder with id "xxx" from config never gets removed folder "xxx" should have been removed after removing it from config <!-- 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.
Thanks for spotting the issue and reporting :) It sounds to me like a issue not being accurate... Maybe only the 1st commit in does the job?
yes, the first commit solves the issue with substring ids. the second commit solves the issue with ids like "hello/world". I tried escaping the id to send a DELETE request but couldn't find out how to correctly escape the / in the id
I'd never imagine someone would do that LOL. What if we'd impose a check in the module that would prevent such ids? Is it even supported upstream?
well it works in the webinterface. so it seems supported? also the default value for the id in our nixos module is the key, which also is the path. I usually do something like so all those ids are broken. as a workaround we could replace all / in the id, but that would break interaction with non nixos setups. PUTing the config seems to not have that issue. Were there any problems with PUTing the config if we want to override folders and devices anyway?
Could you perhaps give more context? I don't understand what kind of a json object is passed to the commands when you do that. I also observed in the below code that "/" are taken care of in a special way? As I in , I don't like how the code diverges in the , and it seems to me it doesn't handle the case where you want to delete a stale folder, and you don't .
yeah the PR sadly isn't complete, I just used it as a test for my local systems where I just override everything. I guess we need to handle individual overrides better, but not sure how. setting wold result in a nixos configuration of when I initially wrote this module this seemed unique enough and like a sane default. I thought about hashing the key for the id, but this would have ended in unnecessary long keys.
I see. I think that using such IDs for folders and devices is very uniqe usage... I tend towards suggesting to take the 1st commit of the PR, and a message when evaluating the script, in case the folders' IDs contain "/", and is true. However, that would not solve your particular, usage. Perhaps we can talk with upstream about it? They are rather responsive from my experience.
that sounds like an idea. I'm busy the next couple of days, but you can cherry pick the first commit from my PR and close it and we will continue with this once we have some better idea how to handle things and we maybe have an answer from upstream?

Related discussion:
text: import ./make-test-python.nix ({ lib, pkgs, ... }: let testId = "7CFNTQM-IMTJBHJ-3UWRDIU-ZGQJFR6-VCXZ3NB-XUH3KZO-N52ITXR-LAIYUAU"; <del> testName = "testDevice foo'bar"; </del> in { name = "syncthing-init";
Code change:
Project description Colorful, adaptive gemini browser <!-- Describe the project a little: --Metadata homepage URL: source URL: license: gpl3 platforms: linux

Related discussion:
text: <ins> { stdenv , cargo , rustc , fetchFromGitHub , glib , gtk4 , libadwaita , rustPlatform , openssl , pkg-config , lib , wrapGAppsHook4 , meson , ninja , gdk-pixbuf , cmake , desktop-file-utils , gettext , blueprint-compiler , appstream-glib }: stdenv.mkDerivation rec { pname = "geopard"; version = "1.4.0"; src = fetchFromGitHub { owner = "ranfdev"; repo = pname; rev = version; hash = "sha256-elHxtFEGkdhEPHxuJtcMYwWnvo6vDaHiOyN51EOzym0="; }; cargoDeps = rustPlatform.importCargoLock { lockFile = ./Cargo.lock; }; nativeBuildInputs = [ openssl gettext glib # for glib-compile-schemas meson ninja pkg-config wrapGAppsHook4 cmake blueprint-compiler desktop-file-utils appstream-glib blueprint-compiler cargo rustc rustPlatform.cargoSetupHook ]; buildInputs = [ desktop-file-utils gdk-pixbuf glib gtk4 libadwaita openssl ]; meta = with lib; { homepage = "https://github.com/ranfdev/Geopard"; description = "Colorful, adaptive gemini browser"; maintainers = with maintainers; [ jfvillablanca ]; license = licenses.gpl3Plus; platforms = platforms.linux; mainProgram = "geopard"; }; } </ins>
Code change:
Steps to reproduce the behavior: llpp Works on 22.05 05 probably depends on insecure with:
I don't use this package, but I looked into it because why not I guess It looks like it builds if you bump the AUR patch to the latest one but only if you also include (which fixes a derivation bug but was reverted because other packages in nixpkgs have workarounds that stopped working when the bug was fixed....)
ohh, thanks for looking at this! I build it with that version of mupdf and the aur patch, and it does build fine, but I get a runtime error now if run without arguments . Still, it does seem able to open pdfs now, so it's sort of usable :p
Hmm I don't actually seem to get that error when running it without args I don't actually know how to use this program though
I'll still merge in a bit to fix build for now, but I may have gotten sniped into taking back up again and will hopefully making a staging PR today (because we really should fix that....)
Sorry! :p
Snipe is in now

Related discussion:
text: url = "https://aur.archlinux.org/cgit/aur.git/plain/system-makedeps.patch?h=llpp&id=0d2913056aaf3dbf7431e57b7b08b55568ba076c"; hash = "sha256-t9PLXsM8+exCeYqJBe0LSDK0D2rpktmozS8qNcEAcHo="; }) <ins> ./fix-mupdf.patch </ins> ]; postPatch = ''
Code change:
Steps to reproduce the behavior: llpp Works on 22.05 05 probably depends on insecure with:
I don't use this package, but I looked into it because why not I guess It looks like it builds if you bump the AUR patch to the latest one but only if you also include (which fixes a derivation bug but was reverted because other packages in nixpkgs have workarounds that stopped working when the bug was fixed....)
ohh, thanks for looking at this! I build it with that version of mupdf and the aur patch, and it does build fine, but I get a runtime error now if run without arguments . Still, it does seem able to open pdfs now, so it's sort of usable :p
Hmm I don't actually seem to get that error when running it without args I don't actually know how to use this program though
I'll still merge in a bit to fix build for now, but I may have gotten sniped into taking back up again and will hopefully making a staging PR today (because we really should fix that....)
Sorry! :p
Snipe is in now

Related discussion:
text: <ins> --- a/link.c +++ b/link.c @@ -1522,8 +1522,9 @@ static void *mainloop (void UNUSED_ATTR *unused) if (pdf && nameddest && *nameddest) { fz_point xy; struct pagedim *pdim; -                int pageno = pdf_lookup_anchor (state.ctx, pdf, nameddest, +                fz_location location = fz_resolve_link (state.ctx, state.doc, nameddest, &xy.x, &xy.y); +                int pageno = location.page; pdim = pdimofpageno (pageno); xy = fz_transform_point (xy, pdim->ctm); printd ("a %d %d %d", pageno, (int) xy.x, (int) xy.y); </ins>
Code change:
Another security release for Exim: 4.96.2. See CC maintainers:
Part of the report also concerns libspf2. (For some reason, it has been filed against Exim instead...) The patch(es) should probably be cherry-picked as well onto helsinki-systems/libspf2 (the fork that we're using).

Related discussion:
text: stdenv.mkDerivation rec { pname = "exim"; <del> version = "4.96.1"; </del> <ins> version = "4.96.2"; </ins> src = fetchurl { url = "https://ftp.exim.org/pub/exim/exim4/${pname}-${version}.tar.xz"; <del> hash = "sha256-k6wHVcMX4f276ozLcKhoh2vfMUhpKJHHKtD+gWdnAz0="; </del> <ins> hash = "sha256-A44yfo0ek9AFusm7Bv0irsRNUCiTDW2+iBetRLv8HeY="; </ins> }; enableParallelBuilding = true;
Code change:
Ditto. I have noticed this accidentially whily working at . Nixpkgs version: (run ) cc
You can puts secrets in an additionnal initrd readable by root only, and use See
There is more generic option now, . We probably want to merge those.

Related discussion:
text: a stable URL for Nixpkgs to use to package this proprietary software. </para> </listitem> <ins> <listitem> <para> The GRUB specific option <option>boot.loader.grub.extraInitrd</option> has been replaced with the generic option <option>boot.initrd.secrets</option>. This option creates a secondary initrd from the specified files, rather than using a manually created initrd file. </para> </listitem> </ins> </itemizedlist> </section>
Code change:
Ditto. I have noticed this accidentially whily working at . Nixpkgs version: (run ) cc
You can puts secrets in an additionnal initrd readable by root only, and use See
There is more generic option now, . We probably want to merge those.

Related discussion:
text: let efiSysMountPoint = if args.efiSysMountPoint == null then args.path else args.efiSysMountPoint; efiSysMountPoint' = replaceChars [ "/" ] [ "-" ] efiSysMountPoint; <ins> initrdSecrets = config.boot.initrd.secrets != {}; </ins> in pkgs.writeText "grub-config.xml" (builtins.toXML { splashImage = f cfg.splashImage;
Code change:
Ditto. I have noticed this accidentially whily working at . Nixpkgs version: (run ) cc
You can puts secrets in an additionnal initrd readable by root only, and use See
There is more generic option now, . We probably want to merge those.

Related discussion:
text: storePath = config.boot.loader.grub.storePath; bootloaderId = if args.efiBootloaderId == null then "NixOS${efiSysMountPoint'}" else args.efiBootloaderId; timeout = if config.boot.loader.timeout == null then -1 else config.boot.loader.timeout; <del> inherit efiSysMountPoint; </del> <ins> inherit efiSysMountPoint initrdSecrets; </ins> inherit (args) devices; inherit (efi) canTouchEfiVariables; inherit (cfg) version extraConfig extraPerEntryConfig extraEntries forceInstall useOSProber <del> extraEntriesBeforeNixOS extraPrepareConfig extraInitrd configurationLimit copyKernels </del> <ins> extraEntriesBeforeNixOS extraPrepareConfig configurationLimit copyKernels </ins> default fsIdentifier efiSupport efiInstallAsRemovable gfxmodeEfi gfxmodeBios; path = (makeBinPath ([ pkgs.coreutils pkgs.gnused pkgs.gnugrep pkgs.findutils pkgs.diffutils pkgs.btrfs-progs
Code change:
Ditto. I have noticed this accidentially whily working at . Nixpkgs version: (run ) cc
You can puts secrets in an additionnal initrd readable by root only, and use See
There is more generic option now, . We probably want to merge those.

Related discussion:
text: ''; }; <del> extraInitrd = mkOption { type = types.nullOr types.path; default = null; example = "/boot/extra_initramfs.gz"; description = '' The path to a second initramfs to be supplied to the kernel. This ramfs will not be copied to the store, so that it can contain secrets such as LUKS keyfiles or ssh keys. This implies that rolling back to a previous configuration won't rollback the state of this file. ''; }; </del> useOSProber = mkOption { default = false; type = types.bool;
Code change:
Ditto. I have noticed this accidentially whily working at . Nixpkgs version: (run ) cc
You can puts secrets in an additionnal initrd readable by root only, and use See
There is more generic option now, . We probably want to merge those.

Related discussion:
text: { path = "/boot"; inherit (cfg) devices; inherit (efi) efiSysMountPoint; } ]; <ins> boot.loader.supportsInitrdSecrets = true; </ins> system.build.installBootLoader = let install-grub-pl = pkgs.substituteAll {
Code change:
Ditto. I have noticed this accidentially whily working at . Nixpkgs version: (run ) cc
You can puts secrets in an additionnal initrd readable by root only, and use See
There is more generic option now, . We probably want to merge those.

Related discussion:
text: my $extraPerEntryConfig = get("extraPerEntryConfig"); my $extraEntries = get("extraEntries"); my $extraEntriesBeforeNixOS = get("extraEntriesBeforeNixOS") eq "true"; <del> my $extraInitrd = get("extraInitrd"); </del> <ins> my $initrdSecrets = get("initrdSecrets"); </ins> my $splashImage = get("splashImage"); my $configurationLimit = int(get("configurationLimit")); my $copyKernels = get("copyKernels") eq "true";
Code change:
Ditto. I have noticed this accidentially whily working at . Nixpkgs version: (run ) cc
You can puts secrets in an additionnal initrd readable by root only, and use See
There is more generic option now, . We probably want to merge those.

Related discussion:
text: if ($copyKernels == 0) { $grubStore = GrubFs($storePath); } <del> my $extraInitrdPath; if ($extraInitrd) { if (! -f $extraInitrd) { print STDERR "Warning: the specified extraInitrd " . $extraInitrd . " doesn't exist. Your system won't boot without it.n"; } $extraInitrdPath = GrubFs($extraInitrd); } </del> # Generate the header. my $conf .= "# Automatically generated.  DO NOT EDIT THIS FILE!n";
Code change:
Ditto. I have noticed this accidentially whily working at . Nixpkgs version: (run ) cc
You can puts secrets in an additionnal initrd readable by root only, and use See
There is more generic option now, . We probably want to merge those.

Related discussion:
text: my $kernel = copyToKernelsDir(Cwd::abs_path("$path/kernel")); my $initrd = copyToKernelsDir(Cwd::abs_path("$path/initrd")); <del> if ($extraInitrd) { $initrd .= " " .$extraInitrdPath->path; </del> <ins> # Include second initrd with secrets if ($initrdSecrets) { # Get last element of path $initrd =~ //([^/]+)$/; my $initrdSecretsPath = "$bootPath/kernels/$1-secrets"; $initrd .= " $initrd-secrets"; my $oldUmask = umask; # Make sure initrd is not world readable (won't work if /boot is FAT) umask 0137; my $initrdSecretsPathTemp = File::Temp::mktemp("$initrdSecretsPath.XXXXXXXX"); system("$path/append-initrd-secrets", $initrdSecretsPathTemp) == 0 or die "failed to create initrd secretsn"; rename $initrdSecretsPathTemp, $initrdSecretsPath or die "failed to move initrd secrets into placen"; umask $oldUmask; $copied{$initrdSecretsPath} = 1; </ins> } my $xen = -e "$path/xen.gz" ? copyToKernelsDir(Cwd::abs_path("$path/xen.gz")) : undef; # FIXME: $confName
Code change:
Ditto. I have noticed this accidentially whily working at . Nixpkgs version: (run ) cc
You can puts secrets in an additionnal initrd readable by root only, and use See
There is more generic option now, . We probably want to merge those.

Related discussion:
text: if ($copyKernels == 0) { $conf .= $grubStore->search . "n"; } <del> if ($extraInitrd) { $conf .= $extraInitrdPath->search . "n"; } </del> $conf .= "  $extraPerEntryConfign" if $extraPerEntryConfig; $conf .= "  multiboot $xen $xenParamsn" if $xen; $conf .= "  " . ($xen ? "module" : "linux") . " $kernel $kernelParamsn";
Code change:
Package name: mautrix-googlechat Latest released version: 0.5.1 <!-- Search your package here: --- Current version on the unstable channel: 0.5.0 Current version on the stable/release channel: 0.5.0 Notify maintainers Note for maintainers: Please tag this issue in your PR.
Thanks

Related discussion:
text: , enableSqlite ? true }: python3.pkgs.buildPythonApplication rec { pname = "mautrix-googlechat"; <del> version = "unstable-2023-07-16"; </del> <ins> version = "0.5.1"; </ins> src = fetchFromGitHub { owner = "mautrix"; repo = "googlechat"; <del> rev = "f4cddafd474b12be09efd15c6652c04d0650458e"; sha256 = "sha256-WMJVAX5oUdYYuXoJKk7OoERR0LJM0Er5444xwqIUTm8="; </del> <ins> rev = "refs/tags/v${version}"; hash = "sha256-a/EWz/aCkBE6XdDpmZcx2Q7/xKNwGCiZUhZc9YIIDhU="; </ins> }; patches = [
Code change:
introduced a deprecation warning for the option. Upon following the warning and moving all options out of the option and removing it, the build fails with the following error: Steps to reproduce the behavior: the service without using the option the configuration Build succeeds. As a temporary workaround, I tried setting to an empty set but then borgmatic fails to parse the config file. <!-- 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.

Related discussion:
text: config = mkIf cfg.enable { warnings = [] <del> ++ optional (cfg.settings != null && cfg.settings.location != null) </del> <ins> ++ optional (cfg.settings != null && cfg.settings ? location) </ins> "`services.borgmatic.settings.location` is deprecated, please move your options out of sections to the global scope" ++ optional (catAttrs "location" (attrValues cfg.configurations) != []) "`services.borgmatic.configurations.<name>.location` is deprecated, please move your options out of sections to the global scope"
Code change:
Attempting to upgrade to kernel v6.5.x results in the arm64 prl-tools package (18.3.0-) failing to compile. Steps to reproduce the behavior: NixOS in a Parallels VM from kernel version v6.4.x to v6.5.x nixos-rebuild to complete without error Using allows an upgrade to succeed with no tools installed. Attempting an upgrade with the unstable version of (19.0.0-) results in a similar build error. Please run and paste the result.
Just noticed a new DMG is available with Linux 6.5 mentioned in the : Not sure how to patch locally to test this.
I've already opened for that.

Related discussion:
text: in stdenv.mkDerivation (finalAttrs: { pname = "prl-tools"; <del> version = "19.0.0-54570"; </del> <ins> version = "19.1.0-54729"; </ins> # We download the full distribution to extract prl-tools-lin.iso from # => ${dmg}/Parallels Desktop.app/Contents/Resources/Tools/prl-tools-lin.iso src = fetchurl { url = "https://download.parallels.com/desktop/v${lib.versions.major finalAttrs.version}/${finalAttrs.version}/ParallelsDesktop-${finalAttrs.version}.dmg"; <del> hash = "sha256-y7UC+E5i2cxkOJ9nVI6aQAFJ5kTXv9uaZoMO4/SCS6k="; </del> <ins> hash = "sha256-Qo/6EuILu5i3hjhxecf3qfoMFEJHJZVY19tDIXDJiag="; </ins> }; hardeningDisable = [ "pic" "format" ];
Code change:
Steps to reproduce the behavior: , or anything depending on it (my failure specifically was triggered by udiskie). Looks like the exact same issue that is being reported in Hydra, on the same hash: Seems similar to reports that it was generated with cython 0.29.3. Unfortunately also seems to be archived and a cursory check does not seem to show a fork floating around.
Related:
Update: I was able to rebuild udiskie successfully by changing its build input (and all respective downstream references) to , so I'm guessing this might have only surfaced now with the recent cut to python 3.11 (maybe ?)
Another comment looks like . I'm guessing we could do the same here.

Related discussion:
text: <del> { lib, buildPythonPackage, fetchFromGitHub, keyutils, pytest-runner, pytest }: </del> <ins> { lib , buildPythonPackage , cython , fetchFromGitHub , keyutils , pytestCheckHook }: </ins> buildPythonPackage rec { pname = "keyutils";
Code change:
Steps to reproduce the behavior: , or anything depending on it (my failure specifically was triggered by udiskie). Looks like the exact same issue that is being reported in Hydra, on the same hash: Seems similar to reports that it was generated with cython 0.29.3. Unfortunately also seems to be archived and a cursory check does not seem to show a fork floating around.
Related:
Update: I was able to rebuild udiskie successfully by changing its build input (and all respective downstream references) to , so I'm guessing this might have only surfaced now with the recent cut to python 3.11 (maybe ?)
Another comment looks like . I'm guessing we could do the same here.

Related discussion:
text: substituteInPlace setup.py --replace '"pytest-runner"' "" ''; <ins> preBuild = '' cython keyutils/_keyutils.pyx ''; preCheck = '' rm -rf keyutils ''; </ins> buildInputs = [ keyutils ]; <del> nativeCheckInputs = [ pytest pytest-runner ]; </del> <ins> nativeBuildInputs = [ cython ]; nativeCheckInputs = [ pytestCheckHook ]; </ins> meta = { description = "A set of python bindings for keyutils";
Code change:
Package name: cardinal Latest released version: 23.10 Current version on the unstable channel: 23.09 Current version on the stable/release channel: 22.12 Notify maintainers Note for maintainers: Please tag this issue in your PR.

Related discussion:
text: stdenv.mkDerivation rec { pname = "cardinal"; <del> version = "23.09"; </del> <ins> version = "23.10"; </ins> src = fetchurl { url = "https://github.com/DISTRHO/Cardinal/releases/download/${version}/cardinal+deps-${version}.tar.xz"; <del> hash = "sha256-q42ry47y4tTkUbejv6iN5jXcadXSSTPQ3omhMUevfqU="; </del> <ins> hash = "sha256-6Wt2sC7vdrz2Fkl08bNLfnGu+pAV7b5lZUmsx1wtJRE="; </ins> }; prePatch = ''
Code change:
Vesktop opens up to a white screen. It cannot update from tray to latest version. I tried completely removing config files from Vencord but it doesn't change anything. Running Vesktop with flag --disable-gpu makes the Vesktop stuck at loading Steps to reproduce the behavior: Vesktop Launching Vesktop should open up the app normally ! Kernel: 6.5.7-xanmod1 Gpu: AMD (mesa 23.1.7)
vencorddesktop command doesn't output any logs. When doing update from the gui, it doesn't show anything. Only time it shows something is when i try updating from tray icon. The output is the following:
This is a problem with Vencord. It is currently broken with the curren versions of Discord (including the web app) We have to wait for upstream to fix these issues and release a new version of vencord
Alright, thank you for the fast response! Cheers
I encountered the same issue, and can confirm it is fixed when the system version of vencord is 1.6.0.

Related discussion:
text: , buildWebExtension ? false }: let <del> version = "1.5.8"; gitHash = "544edce"; </del> <ins> version = "1.6.0"; gitHash = "ffe6bb1"; </ins> in buildNpmPackage rec { pname = "vencord";
Code change:
Vesktop opens up to a white screen. It cannot update from tray to latest version. I tried completely removing config files from Vencord but it doesn't change anything. Running Vesktop with flag --disable-gpu makes the Vesktop stuck at loading Steps to reproduce the behavior: Vesktop Launching Vesktop should open up the app normally ! Kernel: 6.5.7-xanmod1 Gpu: AMD (mesa 23.1.7)
vencorddesktop command doesn't output any logs. When doing update from the gui, it doesn't show anything. Only time it shows something is when i try updating from tray icon. The output is the following:
This is a problem with Vencord. It is currently broken with the curren versions of Discord (including the web app) We have to wait for upstream to fix these issues and release a new version of vencord
Alright, thank you for the fast response! Cheers
I encountered the same issue, and can confirm it is fixed when the system version of vencord is 1.6.0.

Related discussion:
text: owner = "Vendicated"; repo = "Vencord"; rev = "v${version}"; <del> hash = "sha256-cJ+8CKCET7Z2MebyrW5OQr50tvbDM3mkvEQQm3zSbdU="; </del> <ins> hash = "sha256-t4+8ybPzqcCtTSukBBgvbD7HiKG4K51WPVnJg0RQbs8="; </ins> }; ESBUILD_BINARY_PATH = lib.getExe (esbuild.overrideAttrs (final: _: {