jiebi/CodeConvo huggingface dataset:
Code change:
Package name: Latest released version: <!-- Search your package here: --- Current version on the unstable channel: Current version on the stable/release channel: <!-- 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 /cc <!-- 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]:

Related discussion:
text: <ins> { stdenvNoCC, lib, autoPatchelfHook, fetchzip }: let version = "1.1.0"; dist = { "x86_64-linux" = { url = "https://github.com/osquery/osquery-toolchain/releases/download/${version}/osquery-toolchain-${version}-x86_64.tar.xz"; hash = "sha256-irekR8a0d+T64+ZObgblsLoc4kVBmb6Gv0Qf8dLDCMk="; }; "aarch64-linux" = { url = "https://github.com/osquery/osquery-toolchain/releases/download/${version}/osquery-toolchain-${version}-aarch64.tar.xz"; hash = "sha256-cQlx9AtO6ggIQqHowa+42wQ4YCMCN4Gb+0qqVl2JElw="; }; }; in stdenvNoCC.mkDerivation { name = "osquery-toolchain-bin"; inherit version; src = fetchzip dist.${stdenvNoCC.hostPlatform.system}; nativeBuildInputs = [ autoPatchelfHook ]; installPhase = '' mkdir $out cp -r * $out ''; meta = with lib; { description = "A LLVM-based toolchain for Linux designed to build a portable osquery"; homepage = "https://github.com/osquery/osquery-toolchain"; platforms = [ "x86_64-linux" "aarch64-linux" ]; sourceProvenance = with sourceTypes; [ binaryNativeCode ]; license = with licenses; [ gpl2Only asl20 ]; maintainers = with maintainers; [ squalus ]; }; } </ins>
Code change:
Steps to reproduce the behavior: to the NixOS configuration. nixos-rebuild to build NixOS. According to the Nixpkgs search, there should be the packages python312Packages.journalwatch and python311Packages.journalwatch in the Nixpkgs unstable branch. I just checked the master branch and I haven't been able to find those. I could only find pkgs.journalwatch. That's fine, but then it means the journalwatch module needs to be updated. Perhaps this is related to <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --I won't add the Metadata since I'm in the process of building NixOS, so the result would be incorrect anyway. I'm on Nixpkgs commit Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Breakage caused by . Please have a look at and let me know if that works.
Ran into this as well, the PR looks good and seems to fix the issue. Backport should land soon. Thank you all!

Related discussion:
text: ''; }; <ins> package = mkPackageOption pkgs "journalwatch" { }; </ins> priority = mkOption { type = types.int; default = 6;
Code change:
Steps to reproduce the behavior: to the NixOS configuration. nixos-rebuild to build NixOS. According to the Nixpkgs search, there should be the packages python312Packages.journalwatch and python311Packages.journalwatch in the Nixpkgs unstable branch. I just checked the master branch and I haven't been able to find those. I could only find pkgs.journalwatch. That's fine, but then it means the journalwatch module needs to be updated. Perhaps this is related to <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --I won't add the Metadata since I'm in the process of building NixOS, so the result would be incorrect anyway. I'm on Nixpkgs commit Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Breakage caused by . Please have a look at and let me know if that works.
Ran into this as well, the PR looks good and seems to fix the issue. Backport should land soon. Thank you all!

Related discussion:
text: # requires a relative directory name to create beneath /var/lib StateDirectory = user; StateDirectoryMode = "0750"; <del> ExecStart = "${pkgs.python3Packages.journalwatch}/bin/journalwatch mail"; </del> <ins> ExecStart = "${getExe cfg.package} mail"; </ins> # lowest CPU and IO priority, but both still in best-effort class to prevent starvation Nice=19; IOSchedulingPriority=7;
Code change:
Mainline / hardened / testing / ... kernels can be painlessly modified via : Sadly, this does not work with a bunch of other kernel variants: All kernels should honor I am not entirely sure how dynamic binding is implemented in kernel stuff, however slightly changing xanmod parts this way seems to fix : zen and lqx look similar to xanmod, no idea about libre Pinging people who seem to update affected packages often Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
same underlying issue as it seems
Can confirm that this patch fix the issue for zen and lqx kernels:
have you submitted these changes as a PR that I can review?
sorry for the late response. I created a new PR with this changes.
This issue has been mentioned on NixOS Discourse. There might be relevant details there:

Related discussion:
text: sha256 = "0q3kg7dqvsiar3m70mvmn6bkkm4k1zn4fbh5r8ynib753wlhf504"; } , ... <del> }: </del> <ins> } @ args: </ins> let majorMinor = lib.versions.majorMinor linux.modDirVersion;
Code change:
Mainline / hardened / testing / ... kernels can be painlessly modified via : Sadly, this does not work with a bunch of other kernel variants: All kernels should honor I am not entirely sure how dynamic binding is implemented in kernel stuff, however slightly changing xanmod parts this way seems to fix : zen and lqx look similar to xanmod, no idea about libre Pinging people who seem to update affected packages often Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
same underlying issue as it seems
Can confirm that this patch fix the issue for zen and lqx kernels:
have you submitted these changes as a PR that I can review?
sorry for the late response. I created a new PR with this changes.
This issue has been mentioned on NixOS Discourse. There might be relevant details there:

Related discussion:
text: maintainers = with lib.maintainers; [ qyliss ]; }; <del> } </del> <ins> } // (args.argsOverride or { }) </ins>
Code change:
Mainline / hardened / testing / ... kernels can be painlessly modified via : Sadly, this does not work with a bunch of other kernel variants: All kernels should honor I am not entirely sure how dynamic binding is implemented in kernel stuff, however slightly changing xanmod parts this way seems to fix : zen and lqx look similar to xanmod, no idea about libre Pinging people who seem to update affected packages often Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
same underlying issue as it seems
Can confirm that this patch fix the issue for zen and lqx kernels:
have you submitted these changes as a PR that I can review?
sorry for the late response. I created a new PR with this changes.
This issue has been mentioned on NixOS Discourse. There might be relevant details there:

Related discussion:
text: for line in f: result = line result = re.sub( <del> fr'^    version = ".+"; #{variant}', f'    version = "{version}"; #{variant}', </del> <ins> fr'^      version = ".+"; #{variant}', f'      version = "{version}"; #{variant}', </ins> result) result = re.sub( <del> fr'^    suffix = ".+"; #{variant}', f'    suffix = "{suffix}"; #{variant}', </del> <ins> fr'^      suffix = ".+"; #{variant}', f'      suffix = "{suffix}"; #{variant}', </ins> result) result = re.sub( <del> fr'^    sha256 = ".+"; #{variant}', f'    sha256 = "{sha256}"; #{variant}', </del> <ins> fr'^      sha256 = ".+"; #{variant}', f'      sha256 = "{sha256}"; #{variant}', </ins> result) print(result, end='')
Code change:
Mainline / hardened / testing / ... kernels can be painlessly modified via : Sadly, this does not work with a bunch of other kernel variants: All kernels should honor I am not entirely sure how dynamic binding is implemented in kernel stuff, however slightly changing xanmod parts this way seems to fix : zen and lqx look similar to xanmod, no idea about libre Pinging people who seem to update affected packages often Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
same underlying issue as it seems
Can confirm that this patch fix the issue for zen and lqx kernels:
have you submitted these changes as a PR that I can review?
sorry for the late response. I created a new PR with this changes.
This issue has been mentioned on NixOS Discourse. There might be relevant details there:

Related discussion:
text: <del> { lib, stdenv, fetchFromGitHub, buildLinux, ... } @ args: </del> <ins> { lib, stdenv, fetchFromGitHub, buildLinux, variant, ... } @ args: </ins> let # These names are how they are designated in https://xanmod.org. # NOTE: When updating these, please also take a look at the changes done to # kernel config in the xanmod version commit <del> ltsVariant = { version = "6.6.46"; hash = "sha256-ZtXFIHRM5YCb+5Ry3zcQt44OBqfhCI/Ig32jETUBrJo="; variant = "lts"; }; mainVariant = { version = "6.10.5"; hash = "sha256-tETGtCNNgYj1IUNuI/Am5kimFndUC4O+cZwZzlPitFA="; variant = "main"; </del> <ins> variants = { lts = { version = "6.6.46"; hash = "sha256-ZtXFIHRM5YCb+5Ry3zcQt44OBqfhCI/Ig32jETUBrJo="; }; main = { version = "6.10.5"; hash = "sha256-tETGtCNNgYj1IUNuI/Am5kimFndUC4O+cZwZzlPitFA="; }; </ins> }; <del> xanmodKernelFor = { version, suffix ? "xanmod1", hash, variant }: buildLinux (args // rec { </del> <ins> xanmodKernelFor = { version, suffix ? "xanmod1", hash }: buildLinux (args // rec { </ins> inherit version; pname = "linux-xanmod"; modDirVersion = lib.versions.pad 3 "${version}-${suffix}";
Code change:
Mainline / hardened / testing / ... kernels can be painlessly modified via : Sadly, this does not work with a bunch of other kernel variants: All kernels should honor I am not entirely sure how dynamic binding is implemented in kernel stuff, however slightly changing xanmod parts this way seems to fix : zen and lqx look similar to xanmod, no idea about libre Pinging people who seem to update affected packages often Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
same underlying issue as it seems
Can confirm that this patch fix the issue for zen and lqx kernels:
have you submitted these changes as a PR that I can review?
sorry for the late response. I created a new PR with this changes.
This issue has been mentioned on NixOS Discourse. There might be relevant details there:

Related discussion:
text: }; } // (args.argsOverride or { })); in <del> { lts = xanmodKernelFor ltsVariant; main = xanmodKernelFor mainVariant; } </del> <ins> xanmodKernelFor variants.${variant} </ins>
Code change:
Mainline / hardened / testing / ... kernels can be painlessly modified via : Sadly, this does not work with a bunch of other kernel variants: All kernels should honor I am not entirely sure how dynamic binding is implemented in kernel stuff, however slightly changing xanmod parts this way seems to fix : zen and lqx look similar to xanmod, no idea about libre Pinging people who seem to update affected packages often Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
same underlying issue as it seems
Can confirm that this patch fix the issue for zen and lqx kernels:
have you submitted these changes as a PR that I can review?
sorry for the late response. I created a new PR with this changes.
This issue has been mentioned on NixOS Discourse. There might be relevant details there:

Related discussion:
text: <del> { lib, stdenv, fetchFromGitHub, buildLinux, ... } @ args: </del> <ins> { lib, stdenv, fetchFromGitHub, buildLinux, variant, ... } @ args: </ins> let # comments with variant added for update script <del> # ./update-zen.py zen zenVariant = { version = "6.10.5"; #zen suffix = "zen1"; #zen sha256 = "08ibz7560xsmlnrm8j13hxf8hjjcxfmnjdrwffqc81g9g6rvpqra"; #zen isLqx = false; }; # ./update-zen.py lqx lqxVariant = { version = "6.10.5"; #lqx suffix = "lqx1"; #lqx sha256 = "09rscj20j94qkmvk0hlpjm6v1n1ndnkv2vl035gsp5lwggws2jqm"; #lqx isLqx = true; </del> <ins> variants = { # ./update-zen.py zen zen = { version = "6.10.5"; #zen suffix = "zen1"; #zen sha256 = "08ibz7560xsmlnrm8j13hxf8hjjcxfmnjdrwffqc81g9g6rvpqra"; #zen isLqx = false; }; # ./update-zen.py lqx lqx = { version = "6.10.5"; #lqx suffix = "lqx1"; #lqx sha256 = "09rscj20j94qkmvk0hlpjm6v1n1ndnkv2vl035gsp5lwggws2jqm"; #lqx isLqx = true; }; </ins> }; zenKernelsFor = { version, suffix, sha256, isLqx }: buildLinux (args // { inherit version;
Code change:
Mainline / hardened / testing / ... kernels can be painlessly modified via : Sadly, this does not work with a bunch of other kernel variants: All kernels should honor I am not entirely sure how dynamic binding is implemented in kernel stuff, however slightly changing xanmod parts this way seems to fix : zen and lqx look similar to xanmod, no idea about libre Pinging people who seem to update affected packages often Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
same underlying issue as it seems
Can confirm that this patch fix the issue for zen and lqx kernels:
have you submitted these changes as a PR that I can review?
sorry for the late response. I created a new PR with this changes.
This issue has been mentioned on NixOS Discourse. There might be relevant details there:

Related discussion:
text: } // (args.argsOverride or { })); in <del> { zen = zenKernelsFor zenVariant; lqx = zenKernelsFor lqxVariant; } </del> <ins> zenKernelsFor variants.${variant} </ins>
Code change:
Mainline / hardened / testing / ... kernels can be painlessly modified via : Sadly, this does not work with a bunch of other kernel variants: All kernels should honor I am not entirely sure how dynamic binding is implemented in kernel stuff, however slightly changing xanmod parts this way seems to fix : zen and lqx look similar to xanmod, no idea about libre Pinging people who seem to update affected packages often Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
same underlying issue as it seems
Can confirm that this patch fix the issue for zen and lqx kernels:
have you submitted these changes as a PR that I can review?
sorry for the late response. I created a new PR with this changes.
This issue has been mentioned on NixOS Discourse. There might be relevant details there:

Related discussion:
text: # https://github.com/NixOS/nixpkgs/pull/161773#discussion_r820134708 zenKernels = callPackage ../os-specific/linux/kernel/zen-kernels.nix; <del> linux_zen = (zenKernels { </del> <ins> linux_zen = zenKernels { variant = "zen"; </ins> kernelPatches = [ kernelPatches.bridge_stp_helper kernelPatches.request_key_helper ]; <del> }).zen; </del> <ins> }; </ins> <del> linux_lqx = (zenKernels { </del> <ins> linux_lqx = zenKernels { variant = "lqx"; </ins> kernelPatches = [ kernelPatches.bridge_stp_helper kernelPatches.request_key_helper ]; <del> }).lqx; </del> <ins> }; </ins> # This contains the variants of the XanMod kernel <del> xanmodKernels = callPackage ../os-specific/linux/kernel/xanmod-kernels.nix { </del> <ins> xanmodKernels = callPackage ../os-specific/linux/kernel/xanmod-kernels.nix; linux_xanmod = xanmodKernels { variant = "lts"; kernelPatches = [ kernelPatches.bridge_stp_helper kernelPatches.request_key_helper ]; }; linux_xanmod_stable = xanmodKernels { variant = "main"; kernelPatches = [ kernelPatches.bridge_stp_helper kernelPatches.request_key_helper ]; }; linux_xanmod_latest = xanmodKernels { variant = "main"; </ins> kernelPatches = [ kernelPatches.bridge_stp_helper kernelPatches.request_key_helper ]; }; <del> linux_xanmod = xanmodKernels.lts; linux_xanmod_stable = xanmodKernels.main; linux_xanmod_latest = xanmodKernels.main; </del> linux_libre = deblobKernel packageAliases.linux_default.kernel;
Code change:
Unable to use Podman's quadlets feature for a user, since the service unit files are not generated by systemd. Steps to reproduce the behavior: a quadlet file in (say, ) . Systemd says that no unit files were found. Caddy service should have been generated and its status displayed. This issue is caused by not symlinking the provided by the package to . Does not occur at the system level, since is already symlinked to Fix: Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Confirmed the quadlet systemd user generator is not found in /etc/systemd. I'm gonna take this one and try to come up with a fix in NixOS module.

Related discussion:
text: environment.systemPackages = [ cfg.package ]; environment.etc = let <del> # generate contents for /etc/systemd/system-${type} from attrset of links and packages hooks = type: links: pkgs.runCommand "system-${type}" { </del> <ins> # generate contents for /etc/systemd/${dir} from attrset of links and packages hooks = dir: links: pkgs.runCommand "${dir}" { </ins> preferLocalBuild = true; packages = cfg.packages; } ''
Code change:
Unable to use Podman's quadlets feature for a user, since the service unit files are not generated by systemd. Steps to reproduce the behavior: a quadlet file in (say, ) . Systemd says that no unit files were found. Caddy service should have been generated and its status displayed. This issue is caused by not symlinking the provided by the package to . Does not occur at the system level, since is already symlinked to Fix: Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Confirmed the quadlet systemd user generator is not found in /etc/systemd. I'm gonna take this one and try to come up with a fix in NixOS module.

Related discussion:
text: mkdir -p $out for package in $packages do <del> for hook in $package/lib/systemd/system-${type}/* </del> <ins> for hook in $package/lib/systemd/${dir}/* </ins> do ln -s $hook $out/ done
Code change:
Unable to use Podman's quadlets feature for a user, since the service unit files are not generated by systemd. Steps to reproduce the behavior: a quadlet file in (say, ) . Systemd says that no unit files were found. Caddy service should have been generated and its status displayed. This issue is caused by not symlinking the provided by the package to . Does not occur at the system level, since is already symlinked to Fix: Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Confirmed the quadlet systemd user generator is not found in /etc/systemd. I'm gonna take this one and try to come up with a fix in NixOS module.

Related discussion:
text: ${cfg.sleep.extraConfig} ''; <del> "systemd/system-generators" = { source = hooks "generators" cfg.generators; }; "systemd/system-shutdown" = { source = hooks "shutdown" cfg.shutdown; }; </del> <ins> "systemd/user-generators" = { source = hooks "user-generators" cfg.user.generators; }; "systemd/system-generators" = { source = hooks "system-generators" cfg.generators; }; "systemd/system-shutdown" = { source = hooks "system-shutdown" cfg.shutdown; }; </ins> }); services.dbus.enable = true;
Code change:
Unable to use Podman's quadlets feature for a user, since the service unit files are not generated by systemd. Steps to reproduce the behavior: a quadlet file in (say, ) . Systemd says that no unit files were found. Caddy service should have been generated and its status displayed. This issue is caused by not symlinking the provided by the package to . Does not occur at the system level, since is already symlinked to Fix: Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Confirmed the quadlet systemd user generator is not found in /etc/systemd. I'm gonna take this one and try to come up with a fix in NixOS module.

Related discussion:
text: }; }; <ins> systemd.user.generators = mkOption { type = types.attrsOf types.path; default = {}; example = { systemd-gpt-auto-generator = "/dev/null"; }; description = '' Definition of systemd generators; see {manpage}`systemd.generator(5)`. For each `NAME = VALUE` pair of the attrSet, a link is generated from `/etc/systemd/user-generators/NAME` to `VALUE`. ''; }; </ins> systemd.additionalUpstreamUserUnits = mkOption { default = []; type = types.listOf types.str;
Code change:
Unable to use Podman's quadlets feature for a user, since the service unit files are not generated by systemd. Steps to reproduce the behavior: a quadlet file in (say, ) . Systemd says that no unit files were found. Caddy service should have been generated and its status displayed. This issue is caused by not symlinking the provided by the package to . Does not occur at the system level, since is already symlinked to Fix: Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Confirmed the quadlet systemd user generator is not found in /etc/systemd. I'm gonna take this one and try to come up with a fix in NixOS module.

Related discussion:
text: import ../make-test-python.nix ( <del> { pkgs, lib, ... }: { </del> <ins> { pkgs, lib, ... }: let quadletContainerFile = pkgs.writeText "quadlet.container" '' [Unit] Description=A test quadlet container [Container] Image=localhost/scratchimg:latest Exec=bash -c 'trap exit SIGTERM SIGINT; while true; do sleep 1; done' ContainerName=quadlet Volume=/nix/store:/nix/store Volume=/run/current-system/sw/bin:/bin [Install] WantedBy=default.target ''; in { </ins> name = "podman"; meta = { maintainers = lib.teams.podman.members;
Code change:
Unable to use Podman's quadlets feature for a user, since the service unit files are not generated by systemd. Steps to reproduce the behavior: a quadlet file in (say, ) . Systemd says that no unit files were found. Caddy service should have been generated and its status displayed. This issue is caused by not symlinking the provided by the package to . Does not occur at the system level, since is already symlinked to Fix: Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Confirmed the quadlet systemd user generator is not found in /etc/systemd. I'm gonna take this one and try to come up with a fix in NixOS module.

Related discussion:
text: with subtest("A podman non-member can not use the docker cli"): docker.fail(su_cmd("docker version", user="mallory")) <ins> with subtest("A rootless quadlet container service is created"): dir = "/home/alice/.config/containers/systemd" rootless.succeed(su_cmd("tar cv --files-from /dev/null | podman import - scratchimg")) rootless.succeed(su_cmd(f"mkdir -p {dir}")) rootless.succeed(su_cmd(f"cp -f ${quadletContainerFile} {dir}/quadlet.container")) rootless.systemctl("daemon-reload", "alice") rootless.systemctl("start quadlet", "alice") rootless.wait_until_succeeds(su_cmd("podman ps | grep quadlet"), timeout=20) rootless.systemctl("stop quadlet", "alice") </ins> # TODO: add docker-compose test '';