jiebi/CodeConvo huggingface dataset:
Code change:
Steps to reproduce the behavior: Bisected: Introduced in
From the build log: What the heck is that meant to do? This test would pass if the reported size of the TIFF starts with a 7, a 9, or a pipe character, and fails otherwise? Surely this is an upstream gscan2pdf issue.
Issue reported to the gscan2pdf project: Since this should not be impacting the other features of the program, I think it's safe to temporarily disable that one test for that package on our side.
Disabling the test temporarily in:
With merged, let's close this. There's nothing we can do until upstream reacts.
Apparently upstream did update their test according to , but we need to wait for a new release containing the fix.

Related discussion:
text: ]); checkPhase = '' <ins> # Temporarily disable a test failing after a patch imagemagick update. # It might only due to the reporting and matching used in the test. # See https://github.com/NixOS/nixpkgs/issues/223446 # See https://sourceforge.net/p/gscan2pdf/bugs/417/ # #   Failed test 'valid TIFF created' #   at t/131_save_tiff.t line 44. #                   'test.tif TIFF 70x46 70x46+0+0 8-bit sRGB 10024B 0.000u 0:00.000 # ' #     doesn't match '(?^:test.tif TIFF 70x46 70x46+0+0 8-bit sRGB [7|9][.d]+K?B)' rm t/131_save_tiff.t </ins> # Temporarily disable a dubiously failing test: # t/169_import_scan.t ........................... 1/1 # #   Failed test 'variable-height scan imported with expected size'
Code change:
If gdm is enabled with Gnome enabled, gdm will crash and not load into the login screen after logout or reboot. This is due to gdm using wayland as the default. Once wayland is disabled in gdm, the login works. Steps to reproduce the behavior: channel nixos-unstable, "sudo nixos-rebuild switch upgrade-all" with Gnome enabled and gdm enabled in will hang at the gdm check point. gdm wayland in and the reboot works but with Wayland not working. Reboot into gdm with Wayland <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --
I just hit the same issue. After updating to latest nixos-unstable, the boot hangs just before login screen I think this is related to , at least the workaround posted there worked for me also
Would be relevant with a machine without AMD graphics and without KDE? As, I am running Intel's build in graphics and using Gnome. Also, I did find a "workaround" by disabling wayland in gdm then nixos-unstable will boot.
I managed to work around this issue with on GNOME Wayland. Graphic card: Intel Xe Graphics (TGL GT2)
Totally worked! Thanks and ! Should I leave this open as this is a bug or a new config that needs to be applied to 23.05?

Related discussion:
text: mesaPackage = mkOption { type = types.package; <del> default = pkgs.mesa_23; defaultText = literalExpression "pkgs.mesa_23"; </del> <ins> default = pkgs.mesa; defaultText = literalExpression "pkgs.mesa"; </ins> example = literalExpression "pkgs.mesa_22"; description = lib.mdDoc '' The Mesa driver package used for rendering support on the system.
Code change:
If gdm is enabled with Gnome enabled, gdm will crash and not load into the login screen after logout or reboot. This is due to gdm using wayland as the default. Once wayland is disabled in gdm, the login works. Steps to reproduce the behavior: channel nixos-unstable, "sudo nixos-rebuild switch upgrade-all" with Gnome enabled and gdm enabled in will hang at the gdm check point. gdm wayland in and the reboot works but with Wayland not working. Reboot into gdm with Wayland <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --
I just hit the same issue. After updating to latest nixos-unstable, the boot hangs just before login screen I think this is related to , at least the workaround posted there worked for me also
Would be relevant with a machine without AMD graphics and without KDE? As, I am running Intel's build in graphics and using Gnome. Also, I did find a "workaround" by disabling wayland in gdm then nixos-unstable will boot.
I managed to work around this issue with on GNOME Wayland. Graphic card: Intel Xe Graphics (TGL GT2)
Totally worked! Thanks and ! Should I leave this open as this is a bug or a new config that needs to be applied to 23.05?

Related discussion:
text: }; mesaPackage32 = mkOption { type = types.package; <del> default = pkgs.pkgsi686Linux.mesa_23; defaultText = literalExpression "pkgs.pkgsi686Linux.mesa_23"; </del> <ins> default = pkgs.pkgsi686Linux.mesa; defaultText = literalExpression "pkgs.pkgsi686Linux.mesa"; </ins> example = literalExpression "pkgs.pkgsi686Linux.mesa_22"; description = lib.mdDoc '' Same as {option}`mesaPackage` but for the 32-bit Mesa on 64-bit
Code change:
Package name: organicmaps Latest released version: 2023.04.02-7Current version on the unstable channel: 2023.03.05-5 Current version on the stable/release channel: 2023.01.25-3 Notify maintainers Note for maintainers: Please tag this issue in your PR.

Related discussion:
text: mkDerivation rec { pname = "organicmaps"; <del> version = "2023.03.05-5"; </del> <ins> version = "2023.04.02-7"; </ins> src = fetchFromGitHub { owner = "organicmaps"; repo = "organicmaps"; rev = "${version}-android"; <del> sha256 = "sha256-PfudozmrL8jNS/99nxSn0B3E53W34m4/ZN0y2ucB2WI="; </del> <ins> sha256 = "sha256-xXBzHo7IOo2f1raGnpFcsvs++crHMI5SACIc345cX7g="; </ins> fetchSubmodules = true; };
Code change:
Building powerpc kernels (I only tested pkgsCross.powernv, but examination of the kernel source code suggests to me that 32-bit powerpc, and well as big-endian 64-bit will be the same) is broken since This happens because on powerpc, the kernel target we install is vmlinux, rather than any derivative of it like zImage. The kernel build system will strip when creating such a derivative image, but because we install vmlinux directly, we get an unstripped image. This means the kernel contains references to its build directory, which since that PR will be the $dev output. AIUI, 64-bit POWER boots via kexec, and a zImage is a self-extracting kernel ELF image, so hopefully the fix would just be to switch the kernel target for powerpc to zImage, and things will work again, and POWER users will get smaller kernel images as a bonus. I'm not sure about 32-bit PowerPC, but this might be helpful. If we can't use an *Image target for any powerpc targets, there is also a target called that we could fall back to, but let's take the opportunity to evaluate whether anything else is more suitable first, when we're changing this stuff anyway. Apart from powerpc, the only we have that uses vmlinux as its kernel target is a MIPS machine called the Fuloong 2.0. I don't know how it boots.
I'll handle this. I don't have big-endian POWER hardware, but pointed out that qemu can probably boot a BE kernel under emulation at full hardware speeds. So if that works I can take care of the 32-bit POWER (which is mostly BE) too.
For reference, I managed to get a working kernel derivation for Power9 with Just setting building a zImage without fully stripping it afterwards wasn't enough. There still was a reference to in the debug info somewhere.
Yep, very plausible that there are other references as well. We had for x86 and RISC-V, although that specific issue didn't apply to other architectures.
I'll dig into this this evening. thank you for the tip! Also putting this link here so I don't lose it:
Verified (after fixing a bunch of other things) that is affected too. Thanks again for the heads up Working on a fix.
Edit: I meant to post this .
Fixed by

Related discussion:
text: # symbolic name and `patch' is the actual patch.  The patch may # optionally be compressed with gzip or bzip2. kernelPatches ? [] <del> , ignoreConfigErrors ? stdenv.hostPlatform.linux-kernel.name or "" != "pc" </del> <ins> , ignoreConfigErrors ? stdenv.hostPlatform.linux-kernel.name != "pc" </ins> , extraMeta ? {} , isZen      ? false
Code change:
Building powerpc kernels (I only tested pkgsCross.powernv, but examination of the kernel source code suggests to me that 32-bit powerpc, and well as big-endian 64-bit will be the same) is broken since This happens because on powerpc, the kernel target we install is vmlinux, rather than any derivative of it like zImage. The kernel build system will strip when creating such a derivative image, but because we install vmlinux directly, we get an unstripped image. This means the kernel contains references to its build directory, which since that PR will be the $dev output. AIUI, 64-bit POWER boots via kexec, and a zImage is a self-extracting kernel ELF image, so hopefully the fix would just be to switch the kernel target for powerpc to zImage, and things will work again, and POWER users will get smaller kernel images as a bonus. I'm not sure about 32-bit PowerPC, but this might be helpful. If we can't use an *Image target for any powerpc targets, there is also a target called that we could fall back to, but let's take the opportunity to evaluate whether anything else is more suitable first, when we're changing this stuff anyway. Apart from powerpc, the only we have that uses vmlinux as its kernel target is a MIPS machine called the Fuloong 2.0. I don't know how it boots.
I'll handle this. I don't have big-endian POWER hardware, but pointed out that qemu can probably boot a BE kernel under emulation at full hardware speeds. So if that works I can take care of the 32-bit POWER (which is mostly BE) too.
For reference, I managed to get a working kernel derivation for Power9 with Just setting building a zImage without fully stripping it afterwards wasn't enough. There still was a reference to in the debug info somewhere.
Yep, very plausible that there are other references as well. We had for x86 and RISC-V, although that specific issue didn't apply to other architectures.
I'll dig into this this evening. thank you for the tip! Also putting this link here so I don't lose it:
Verified (after fixing a bunch of other things) that is affected too. Thanks again for the heads up Working on a fix.
Edit: I meant to post this .
Fixed by

Related discussion:
text: , isHardened ? false # easy overrides to stdenv.hostPlatform.linux-kernel members <del> , autoModules ? stdenv.hostPlatform.linux-kernel.autoModules or true </del> <ins> , autoModules ? stdenv.hostPlatform.linux-kernel.autoModules </ins> , preferBuiltin ? stdenv.hostPlatform.linux-kernel.preferBuiltin or false , kernelArch ? stdenv.hostPlatform.linuxArch , kernelTests ? []
Code change:
Building powerpc kernels (I only tested pkgsCross.powernv, but examination of the kernel source code suggests to me that 32-bit powerpc, and well as big-endian 64-bit will be the same) is broken since This happens because on powerpc, the kernel target we install is vmlinux, rather than any derivative of it like zImage. The kernel build system will strip when creating such a derivative image, but because we install vmlinux directly, we get an unstripped image. This means the kernel contains references to its build directory, which since that PR will be the $dev output. AIUI, 64-bit POWER boots via kexec, and a zImage is a self-extracting kernel ELF image, so hopefully the fix would just be to switch the kernel target for powerpc to zImage, and things will work again, and POWER users will get smaller kernel images as a bonus. I'm not sure about 32-bit PowerPC, but this might be helpful. If we can't use an *Image target for any powerpc targets, there is also a target called that we could fall back to, but let's take the opportunity to evaluate whether anything else is more suitable first, when we're changing this stuff anyway. Apart from powerpc, the only we have that uses vmlinux as its kernel target is a MIPS machine called the Fuloong 2.0. I don't know how it boots.
I'll handle this. I don't have big-endian POWER hardware, but pointed out that qemu can probably boot a BE kernel under emulation at full hardware speeds. So if that works I can take care of the 32-bit POWER (which is mostly BE) too.
For reference, I managed to get a working kernel derivation for Power9 with Just setting building a zImage without fully stripping it afterwards wasn't enough. There still was a reference to in the debug info somewhere.
Yep, very plausible that there are other references as well. We had for x86 and RISC-V, although that specific issue didn't apply to other architectures.
I'll dig into this this evening. thank you for the tip! Also putting this link here so I don't lose it:
Verified (after fixing a bunch of other things) that is affected too. Thanks again for the heads up Working on a fix.
Edit: I meant to post this .
Fixed by

Related discussion:
text: ++ lib.optionals (lib.versionAtLeast version "4.16") [ bison flex ] ++ lib.optional (lib.versionAtLeast version "5.2") pahole; <ins> platformName = stdenv.hostPlatform.linux-kernel.name; </ins> # e.g. "defconfig" <del> kernelBaseConfig = if defconfig != null then defconfig else stdenv.hostPlatform.linux-kernel.baseConfig or "defconfig"; </del> <ins> kernelBaseConfig = if defconfig != null then defconfig else stdenv.hostPlatform.linux-kernel.baseConfig; # e.g. "bzImage" kernelTarget = stdenv.hostPlatform.linux-kernel.target; </ins> makeFlags = lib.optionals (stdenv.hostPlatform.linux-kernel ? makeFlags) stdenv.hostPlatform.linux-kernel.makeFlags ++ extraMakeFlags;
Code change:
Building powerpc kernels (I only tested pkgsCross.powernv, but examination of the kernel source code suggests to me that 32-bit powerpc, and well as big-endian 64-bit will be the same) is broken since This happens because on powerpc, the kernel target we install is vmlinux, rather than any derivative of it like zImage. The kernel build system will strip when creating such a derivative image, but because we install vmlinux directly, we get an unstripped image. This means the kernel contains references to its build directory, which since that PR will be the $dev output. AIUI, 64-bit POWER boots via kexec, and a zImage is a self-extracting kernel ELF image, so hopefully the fix would just be to switch the kernel target for powerpc to zImage, and things will work again, and POWER users will get smaller kernel images as a bonus. I'm not sure about 32-bit PowerPC, but this might be helpful. If we can't use an *Image target for any powerpc targets, there is also a target called that we could fall back to, but let's take the opportunity to evaluate whether anything else is more suitable first, when we're changing this stuff anyway. Apart from powerpc, the only we have that uses vmlinux as its kernel target is a MIPS machine called the Fuloong 2.0. I don't know how it boots.
I'll handle this. I don't have big-endian POWER hardware, but pointed out that qemu can probably boot a BE kernel under emulation at full hardware speeds. So if that works I can take care of the 32-bit POWER (which is mostly BE) too.
For reference, I managed to get a working kernel derivation for Power9 with Just setting building a zImage without fully stripping it afterwards wasn't enough. There still was a reference to in the debug info somewhere.
Yep, very plausible that there are other references as well. We had for x86 and RISC-V, although that specific issue didn't apply to other architectures.
I'll dig into this this evening. thank you for the tip! Also putting this link here so I don't lose it:
Verified (after fixing a bunch of other things) that is affected too. Thanks again for the heads up Working on a fix.
Edit: I meant to post this .
Fixed by

Related discussion:
text: { lib, stdenv, buildPackages, runCommand, nettools, bc, bison, flex, perl, rsync, gmp, libmpc, mpfr, openssl <del> , libelf, cpio, elfutils, zstd, python3Minimal, zlib, pahole, ubootTools </del> <ins> , libelf, cpio, elfutils, zstd, python3Minimal, zlib, pahole </ins> , fetchpatch }:
Code change:
Building powerpc kernels (I only tested pkgsCross.powernv, but examination of the kernel source code suggests to me that 32-bit powerpc, and well as big-endian 64-bit will be the same) is broken since This happens because on powerpc, the kernel target we install is vmlinux, rather than any derivative of it like zImage. The kernel build system will strip when creating such a derivative image, but because we install vmlinux directly, we get an unstripped image. This means the kernel contains references to its build directory, which since that PR will be the $dev output. AIUI, 64-bit POWER boots via kexec, and a zImage is a self-extracting kernel ELF image, so hopefully the fix would just be to switch the kernel target for powerpc to zImage, and things will work again, and POWER users will get smaller kernel images as a bonus. I'm not sure about 32-bit PowerPC, but this might be helpful. If we can't use an *Image target for any powerpc targets, there is also a target called that we could fall back to, but let's take the opportunity to evaluate whether anything else is more suitable first, when we're changing this stuff anyway. Apart from powerpc, the only we have that uses vmlinux as its kernel target is a MIPS machine called the Fuloong 2.0. I don't know how it boots.
I'll handle this. I don't have big-endian POWER hardware, but pointed out that qemu can probably boot a BE kernel under emulation at full hardware speeds. So if that works I can take care of the 32-bit POWER (which is mostly BE) too.
For reference, I managed to get a working kernel derivation for Power9 with Just setting building a zImage without fully stripping it afterwards wasn't enough. There still was a reference to in the debug info somewhere.
Yep, very plausible that there are other references as well. We had for x86 and RISC-V, although that specific issue didn't apply to other architectures.
I'll dig into this this evening. thank you for the tip! Also putting this link here so I don't lose it:
Verified (after fixing a bunch of other things) that is affected too. Thanks again for the heads up Working on a fix.
Edit: I meant to post this .
Fixed by

Related discussion:
text: }: let <del> config_ = config; in let </del> inherit (lib) hasAttr getAttr optional optionals optionalString optionalAttrs maintainers platforms;
Code change:
The pkg-config file in pkg looks like this: The and variables are empty. The keyword is also empty. As a result, the flags returned by pkg-config are wrong and checking the version does not work. Note the empty and and that the package version is actually 3.0.1, i.e. = 3.0.0. and should point to the correct directories in the and outputs of the pkg.

Related discussion:
text: }) ]; <ins> # Tweaks to fix undefined variable substitutions # https://github.com/HowardHinnant/date/pull/538#pullrequestreview-1373268697 postPatch = '' substituteInPlace date.pc.in  --replace '@CMAKE_INSTALL_LIB@' '@CMAKE_INSTALL_FULL_LIBDIR@'  --replace '@CMAKE_INSTALL_INCLUDE@' '@CMAKE_INSTALL_FULL_INCLUDEDIR@'  --replace '@PACKAGE_VERSION@' '${version}' ''; </ins> nativeBuildInputs = [ cmake ]; cmakeFlags = [
Code change:
Project description A cross platform mod loader for The Legend of Zelda: Breath of the Wild in CEMU. Metadata homepage URL: source URL: license: GPL3+ platforms: Windows, Linux
I actually have this packaged in my nur repo: , but I let it go out of date for a bit. (should get back to updating that ). You can test it out with The version I packaged works really well (or at least when I was still using it ) - it was just frustrating to maintain with all the patches & new dependencies, and I decided to hold of on merging to nixpkgs for now.
Maybe should be made instead?
Please test / .

Related discussion:
text: <ins> { lib , rustPlatform , fetchFromGitHub , cmake , pkg-config , wrapGAppsHook , atk , glib , gtk3-x11 }: rustPlatform.buildRustPackage rec { pname = "ukmm"; version = "0.7.1"; src = fetchFromGitHub { owner = "NiceneNerd"; repo = pname; rev = "v${version}"; sha256 = "sha256-TvRaaAVJPqvTTqs+d5d4y1KmDTvE41uP5AykLtHxD9w="; }; cargoLock = { lockFile = ./Cargo.lock; outputHashes = { "catppuccin-egui-1.0.2" = "sha256-+ILfvDgZxe/QPJuVqIbRjaHNovpRAX+ym2QZ96glb4w="; "ecolor-0.20.0" = "sha256-uTDkNRWsA1nM8Qhb0X2LjVDRuaW31vWxR8kDLL27BVE="; "egui-notify-0.4.0" = "sha256-jybtUnv9xqzulZ5nfg+T1u8iTOsPjKGVVQ7JhwbvPdU="; "egui_commonmark-0.6.0" = "sha256-hsVbtL2F+jifnzN6FgcDAVtLd1bVxTs0twn0SMvq9eU="; "egui_dock-0.2.1" = "sha256-gGIO0boXKxLu0ABDH/uJhEZEoE/ql8E65LRmr0Xhv3s="; "junction-0.2.0" = "sha256-6+pPp5wG1NoIj16Z+OvO4Pvy0jnQibn/A9cTaHAEVq4="; "msbt-0.1.1" = "sha256-PtBs60xgYrwS7yPnRzXpExwYUD3azIaqObRnnJEL5dE="; "msyt-1.2.1" = "sha256-aw5whCoQBhO0u9Fx2rTO1sRuPdGnAAlmPWv5q8CbQcI="; }; }; RUSTC_BOOTSTRAP = true; nativeBuildInputs = [ cmake pkg-config wrapGAppsHook ]; buildInputs = [ atk glib gtk3-x11 ]; cargoTestFlags = [ "--all" ]; checkFlags = [ # Requires a game dump of Breath of the Wild "--skip=gui::tasks::tests::remerge" "--skip=pack::tests::pack_mod" "--skip=project::tests::project_from_mod" "--skip=tests::read_meta" "--skip=unpack::tests::read_mod" "--skip=unpack::tests::unpack_mod" "--skip=unpack::tests::unzip_mod" # Requires Clear Camera mod "--skip=bnp::test_convert" ]; meta = with lib; { description = "A new mod manager for The Legend of Zelda: Breath of the Wild"; homepage = "https://github.com/NiceneNerd/ukmm"; changelog = "https://github.com/NiceneNerd/ukmm/blob/${src.rev}/CHANGELOG.md"; license = licenses.gpl3Plus; maintainers = with maintainers; [ kira-bruneau ]; platforms = platforms.linux; }; } </ins>
Code change:
Project description A cross platform mod loader for The Legend of Zelda: Breath of the Wild in CEMU. Metadata homepage URL: source URL: license: GPL3+ platforms: Windows, Linux
I actually have this packaged in my nur repo: , but I let it go out of date for a bit. (should get back to updating that ). You can test it out with The version I packaged works really well (or at least when I was still using it ) - it was just frustrating to maintain with all the patches & new dependencies, and I decided to hold of on merging to nixpkgs for now.
Maybe should be made instead?
Please test / .

Related discussion:
text: ttchat = callPackage ../tools/misc/ttchat { }; <ins> ukmm = callPackage ../tools/games/ukmm { }; </ins> unflac = callPackage ../tools/audio/unflac { }; veikk-linux-driver-gui = libsForQt5.callPackage ../tools/misc/veikk-linux-driver-gui { };