jiebi/CodeConvo huggingface dataset:
Code change:
Describe the bug I believe the auto-cpufreq daemon should start on boot if enabled. To Reproduce auto-cpufreq daemon: . the system. . auto-cpufreq as dead/inactive. Expected behavior auto-cpufreq service should be started on boot. Additional context I was using the unstable service in 20.09 and it worked as expected. In 21.05 stable, the service starts dead/inactive and my system is very slow. I manually start the service and I'm back to the NixOS I know and love. I was able to fix this by adding the following to my configuration: Notify maintainers Metadata Please run and paste the result. system: host os: multi-user?: sandbox: version: channels(pnelson): channels(root): nixpkgs: Maintainer information:
Sorry for being late, should fix this.
I have the exact same issue now, on 23.11.
Same here, also facing this problem on 23.11...
Thought this might be caused due to some false overwrites in the module config, so I decided to try out rewriting the systemd service. Doesn't work either...
For others who might still be hitting this, I thought I was too. When checking the logs I saw that power-profiles-daemon was starting up, causing auto-cpufreq to shut down. I fixed this by adding: From looking at this code, and be kind with me here since I'm a nix beginner, it is .  I think the best action would be to add an assertion to give users a prompt like with tlp. If this looks correct I can open a PR for it

Related discussion:
text: config = mkIf cfg.enable { environment.systemPackages = [ pkgs.auto-cpufreq ]; <del> systemd.packages = [ pkgs.auto-cpufreq ]; systemd.services.auto-cpufreq.path = with pkgs; [ bash coreutils ]; </del> <ins> systemd = { packages = [ pkgs.auto-cpufreq ]; services.auto-cpufreq = { # Workaround for https://github.com/NixOS/nixpkgs/issues/81138 wantedBy = [ "multi-user.target" ]; path = with pkgs; [ bash coreutils ]; }; }; </ins> }; }
Code change:
Describe the bug I believe the auto-cpufreq daemon should start on boot if enabled. To Reproduce auto-cpufreq daemon: . the system. . auto-cpufreq as dead/inactive. Expected behavior auto-cpufreq service should be started on boot. Additional context I was using the unstable service in 20.09 and it worked as expected. In 21.05 stable, the service starts dead/inactive and my system is very slow. I manually start the service and I'm back to the NixOS I know and love. I was able to fix this by adding the following to my configuration: Notify maintainers Metadata Please run and paste the result. system: host os: multi-user?: sandbox: version: channels(pnelson): channels(root): nixpkgs: Maintainer information:
Sorry for being late, should fix this.
I have the exact same issue now, on 23.11.
Same here, also facing this problem on 23.11...
Thought this might be caused due to some false overwrites in the module config, so I decided to try out rewriting the systemd service. Doesn't work either...
For others who might still be hitting this, I thought I was too. When checking the logs I saw that power-profiles-daemon was starting up, causing auto-cpufreq to shut down. I fixed this by adding: From looking at this code, and be kind with me here since I'm a nix beginner, it is .  I think the best action would be to add an assertion to give users a prompt like with tlp. If this looks correct I can open a PR for it

Related discussion:
text: python3Packages.buildPythonPackage rec { pname = "auto-cpufreq"; <del> version = "1.6.1"; </del> <ins> version = "1.6.4"; </ins> src = fetchFromGitHub { owner = "AdnanHodzic"; repo = pname; rev = "v${version}"; <del> sha256 = "sha256-oz3C1150CPfT0kkx1x7VIX/Rm06dkjyxeDPFCRJaWNc="; </del> <ins> sha256 = "sha256-9WYuAWcJGosYEsnnkqvZLXXvqF+1nBEozh6F84Kit6w="; </ins> }; propagatedBuildInputs = with python3Packages; [ click distro psutil ];
Code change:
Describe the bug I believe the auto-cpufreq daemon should start on boot if enabled. To Reproduce auto-cpufreq daemon: . the system. . auto-cpufreq as dead/inactive. Expected behavior auto-cpufreq service should be started on boot. Additional context I was using the unstable service in 20.09 and it worked as expected. In 21.05 stable, the service starts dead/inactive and my system is very slow. I manually start the service and I'm back to the NixOS I know and love. I was able to fix this by adding the following to my configuration: Notify maintainers Metadata Please run and paste the result. system: host os: multi-user?: sandbox: version: channels(pnelson): channels(root): nixpkgs: Maintainer information:
Sorry for being late, should fix this.
I have the exact same issue now, on 23.11.
Same here, also facing this problem on 23.11...
Thought this might be caused due to some false overwrites in the module config, so I decided to try out rewriting the systemd service. Doesn't work either...
For others who might still be hitting this, I thought I was too. When checking the logs I saw that power-profiles-daemon was starting up, causing auto-cpufreq to shut down. I fixed this by adding: From looking at this code, and be kind with me here since I'm a nix beginner, it is .  I think the best action would be to add an assertion to give users a prompt like with tlp. If this looks correct I can open a PR for it

Related discussion:
text: diff --git a/auto_cpufreq/core.py b/auto_cpufreq/core.py <del> index a685db8..1ca1ca1 100644 </del> <ins> index 83d0d64..04b5035 100644 </ins> --- a/auto_cpufreq/core.py +++ b/auto_cpufreq/core.py <del> @@ -72,7 +72,7 @@ def app_version(): print("Git commit:", check_output(["git", "describe", "--always"]).strip().decode()) else: print(getoutput("pacman -Qi auto-cpufreq | grep Version")) -    else: +    else: # source code (auto-cpufreq-installer) try: print("Git commit:", check_output(["git", "describe", "--always"]).strip().decode()) @@ -179,31 +179,13 @@ def get_current_gov(): return print("Currently using:", getoutput("cpufreqctl.auto-cpufreq --governor").strip().split(" ")[0], "governor") </del> <ins> @@ -204,35 +204,13 @@ def get_current_gov(): </ins> def cpufreqctl(): -    """
Code change:
Describe the bug I believe the auto-cpufreq daemon should start on boot if enabled. To Reproduce auto-cpufreq daemon: . the system. . auto-cpufreq as dead/inactive. Expected behavior auto-cpufreq service should be started on boot. Additional context I was using the unstable service in 20.09 and it worked as expected. In 21.05 stable, the service starts dead/inactive and my system is very slow. I manually start the service and I'm back to the NixOS I know and love. I was able to fix this by adding the following to my configuration: Notify maintainers Metadata Please run and paste the result. system: host os: multi-user?: sandbox: version: channels(pnelson): channels(root): nixpkgs: Maintainer information:
Sorry for being late, should fix this.
I have the exact same issue now, on 23.11.
Same here, also facing this problem on 23.11...
Thought this might be caused due to some false overwrites in the module config, so I decided to try out rewriting the systemd service. Doesn't work either...
For others who might still be hitting this, I thought I was too. When checking the logs I saw that power-profiles-daemon was starting up, causing auto-cpufreq to shut down. I fixed this by adding: From looking at this code, and be kind with me here since I'm a nix beginner, it is .  I think the best action would be to add an assertion to give users a prompt like with tlp. If this looks correct I can open a PR for it

Related discussion:
text: -    """ - -    # detect if running on a SNAP <del> -    if os.getenv('PKG_MARKER') == "SNAP": </del> <ins> -    if os.getenv("PKG_MARKER") == "SNAP": </ins> -        pass -    else: -        # deploy cpufreqctl.auto-cpufreq script -        if os.path.isfile("/usr/bin/cpufreqctl"): <del> -            shutil.copy(SCRIPTS_DIR / "cpufreqctl.sh", "/usr/bin/cpufreqctl.auto-cpufreq") </del> <ins> -            shutil.copy( -                SCRIPTS_DIR / "cpufreqctl.sh", "/usr/bin/cpufreqctl.auto-cpufreq" -            ) </ins> -        else: <del> -            shutil.copy(SCRIPTS_DIR / "cpufreqctl.sh", "/usr/bin/cpufreqctl.auto-cpufreq") </del> <ins> -            shutil.copy( -                SCRIPTS_DIR / "cpufreqctl.sh", "/usr/bin/cpufreqctl.auto-cpufreq" -            ) </ins> +    # scripts are already in the correct place +    pass
Code change:
Describe the bug I believe the auto-cpufreq daemon should start on boot if enabled. To Reproduce auto-cpufreq daemon: . the system. . auto-cpufreq as dead/inactive. Expected behavior auto-cpufreq service should be started on boot. Additional context I was using the unstable service in 20.09 and it worked as expected. In 21.05 stable, the service starts dead/inactive and my system is very slow. I manually start the service and I'm back to the NixOS I know and love. I was able to fix this by adding the following to my configuration: Notify maintainers Metadata Please run and paste the result. system: host os: multi-user?: sandbox: version: channels(pnelson): channels(root): nixpkgs: Maintainer information:
Sorry for being late, should fix this.
I have the exact same issue now, on 23.11.
Same here, also facing this problem on 23.11...
Thought this might be caused due to some false overwrites in the module config, so I decided to try out rewriting the systemd service. Doesn't work either...
For others who might still be hitting this, I thought I was too. When checking the logs I saw that power-profiles-daemon was starting up, causing auto-cpufreq to shut down. I fixed this by adding: From looking at this code, and be kind with me here since I'm a nix beginner, it is .  I think the best action would be to add an assertion to give users a prompt like with tlp. If this looks correct I can open a PR for it

Related discussion:
text: -    remove cpufreqctl.auto-cpufreq script -    """ -    # detect if running on a SNAP <del> -    if os.getenv('PKG_MARKER') == "SNAP": </del> <ins> -    if os.getenv("PKG_MARKER") == "SNAP": </ins> -        pass -    else: -        if os.path.isfile("/usr/bin/cpufreqctl.auto-cpufreq"):
Code change:
Describe the bug I believe the auto-cpufreq daemon should start on boot if enabled. To Reproduce auto-cpufreq daemon: . the system. . auto-cpufreq as dead/inactive. Expected behavior auto-cpufreq service should be started on boot. Additional context I was using the unstable service in 20.09 and it worked as expected. In 21.05 stable, the service starts dead/inactive and my system is very slow. I manually start the service and I'm back to the NixOS I know and love. I was able to fix this by adding the following to my configuration: Notify maintainers Metadata Please run and paste the result. system: host os: multi-user?: sandbox: version: channels(pnelson): channels(root): nixpkgs: Maintainer information:
Sorry for being late, should fix this.
I have the exact same issue now, on 23.11.
Same here, also facing this problem on 23.11...
Thought this might be caused due to some false overwrites in the module config, so I decided to try out rewriting the systemd service. Doesn't work either...
For others who might still be hitting this, I thought I was too. When checking the logs I saw that power-profiles-daemon was starting up, causing auto-cpufreq to shut down. I fixed this by adding: From looking at this code, and be kind with me here since I'm a nix beginner, it is .  I think the best action would be to add an assertion to give users a prompt like with tlp. If this looks correct I can open a PR for it

Related discussion:
text: +    # no need to restore +    pass def footer(l=79): <del> print("n" + "-" * l + "n") @@ -233,74 +215,12 @@ def remove_complete_msg(): footer() </del> <ins> @@ -276,76 +254,13 @@ def remove_complete_msg(): </ins> def deploy_daemon(): -    print("n" + "-" * 21 + " Deploying auto-cpufreq as a daemon " + "-" * 22 + "n")
Code change:
Describe the bug I believe the auto-cpufreq daemon should start on boot if enabled. To Reproduce auto-cpufreq daemon: . the system. . auto-cpufreq as dead/inactive. Expected behavior auto-cpufreq service should be started on boot. Additional context I was using the unstable service in 20.09 and it worked as expected. In 21.05 stable, the service starts dead/inactive and my system is very slow. I manually start the service and I'm back to the NixOS I know and love. I was able to fix this by adding the following to my configuration: Notify maintainers Metadata Please run and paste the result. system: host os: multi-user?: sandbox: version: channels(pnelson): channels(root): nixpkgs: Maintainer information:
Sorry for being late, should fix this.
I have the exact same issue now, on 23.11.
Same here, also facing this problem on 23.11...
Thought this might be caused due to some false overwrites in the module config, so I decided to try out rewriting the systemd service. Doesn't work either...
For others who might still be hitting this, I thought I was too. When checking the logs I saw that power-profiles-daemon was starting up, causing auto-cpufreq to shut down. I fixed this by adding: From looking at this code, and be kind with me here since I'm a nix beginner, it is .  I think the best action would be to add an assertion to give users a prompt like with tlp. If this looks correct I can open a PR for it

Related discussion:
text: -            f.seek(0) -            f.truncate() -            f.write(content.replace(orig_set, change_set)) <del> -    except: -        print("nERROR:nWas unable to turn off bluetooth on boot") </del> <ins> -    except Exception as e: -        print(f"nERROR:nWas unable to turn off bluetooth on bootn{repr(e)}") </ins> - -    auto_cpufreq_stats_path.touch(exist_ok=True) - -    print("n* Deploy auto-cpufreq install script") <del> -    shutil.copy(SCRIPTS_DIR / "auto-cpufreq-install.sh", "/usr/bin/auto-cpufreq-install") </del> <ins> -    shutil.copy( -        SCRIPTS_DIR / "auto-cpufreq-install.sh", "/usr/bin/auto-cpufreq-install" -    ) </ins> - -    print("n* Deploy auto-cpufreq remove script") -    shutil.copy(SCRIPTS_DIR / "auto-cpufreq-remove.sh", "/usr/bin/auto-cpufreq-remove") - -    call("/usr/bin/auto-cpufreq-install", shell=True) <del> - </del> +    # prevent needless copying and system changes +    pass # remove auto-cpufreq daemon def remove(): -
Code change:
Describe the bug I believe the auto-cpufreq daemon should start on boot if enabled. To Reproduce auto-cpufreq daemon: . the system. . auto-cpufreq as dead/inactive. Expected behavior auto-cpufreq service should be started on boot. Additional context I was using the unstable service in 20.09 and it worked as expected. In 21.05 stable, the service starts dead/inactive and my system is very slow. I manually start the service and I'm back to the NixOS I know and love. I was able to fix this by adding the following to my configuration: Notify maintainers Metadata Please run and paste the result. system: host os: multi-user?: sandbox: version: channels(pnelson): channels(root): nixpkgs: Maintainer information:
Sorry for being late, should fix this.
I have the exact same issue now, on 23.11.
Same here, also facing this problem on 23.11...
Thought this might be caused due to some false overwrites in the module config, so I decided to try out rewriting the systemd service. Doesn't work either...
For others who might still be hitting this, I thought I was too. When checking the logs I saw that power-profiles-daemon was starting up, causing auto-cpufreq to shut down. I fixed this by adding: From looking at this code, and be kind with me here since I'm a nix beginner, it is .  I think the best action would be to add an assertion to give users a prompt like with tlp. If this looks correct I can open a PR for it

Related discussion:
text: -            f.seek(0) -            f.truncate() -            f.write(content.replace(change_set, orig_set)) <del> -    except: -        print("nERROR:nWas unable to turn on bluetooth on boot") </del> <ins> -    except Exception as e: -        print(f"nERROR:nWas unable to turn on bluetooth on bootn{repr(e)}") </ins> - -    # run auto-cpufreq daemon install script -    call("/usr/bin/auto-cpufreq-remove", shell=True)
Code change:
Describe the bug I believe the auto-cpufreq daemon should start on boot if enabled. To Reproduce auto-cpufreq daemon: . the system. . auto-cpufreq as dead/inactive. Expected behavior auto-cpufreq service should be started on boot. Additional context I was using the unstable service in 20.09 and it worked as expected. In 21.05 stable, the service starts dead/inactive and my system is very slow. I manually start the service and I'm back to the NixOS I know and love. I was able to fix this by adding the following to my configuration: Notify maintainers Metadata Please run and paste the result. system: host os: multi-user?: sandbox: version: channels(pnelson): channels(root): nixpkgs: Maintainer information:
Sorry for being late, should fix this.
I have the exact same issue now, on 23.11.
Same here, also facing this problem on 23.11...
Thought this might be caused due to some false overwrites in the module config, so I decided to try out rewriting the systemd service. Doesn't work either...
For others who might still be hitting this, I thought I was too. When checking the logs I saw that power-profiles-daemon was starting up, causing auto-cpufreq to shut down. I fixed this by adding: From looking at this code, and be kind with me here since I'm a nix beginner, it is .  I think the best action would be to add an assertion to give users a prompt like with tlp. If this looks correct I can open a PR for it

Related discussion:
text: def gov_check(): for gov in get_avail_gov(): <del> @@ -331,7 +251,7 @@ def countdown(s): if auto_cpufreq_stats_file is not None: auto_cpufreq_stats_file.seek(0) auto_cpufreq_stats_file.truncate(0) - + # execution timestamp from datetime import datetime now = datetime.now() </del> diff --git a/scripts/cpufreqctl.sh b/scripts/cpufreqctl.sh index 63a2b5b..e157efe 100755 --- a/scripts/cpufreqctl.sh
Code change:
As reported on we need some patches: In particular: gnome-settings-daemon needs bluetoothd needs cc
At least for g-s-d we're already on 40.0.1, which seems to have the fix? Both commits referenced (!232, !234) are there, but maybe I'm misreading. Not sure if we want to address bluetoothd with , but regardless I have a commit ready.
Above is no longer necessary with 5.60. I'll open a bump for that instead.

Related discussion:
text: ]; in stdenv.mkDerivation rec { pname = "bluez"; <del> version = "5.59"; </del> <ins> version = "5.60"; </ins> src = fetchurl { url = "mirror://kernel/linux/bluetooth/${pname}-${version}.tar.xz"; <del> sha256 = "05kk8zdh3msf5j88jbai8m877rvya6fpkzhicfhv5gyhhsrrasq4"; </del> <ins> sha256 = "sha256-cQmZWA0B7lnsWF5efAf9lO3e3AAaom/nRkxUb52UUwQ="; </ins> }; buildInputs = [
Code change:
Describe the bug The current downloads 2 patches, both of them 404. I realized this when I tried to build my system from scratch without substitors. To Reproduce a system that somehow depends on mercurial (not exactly sure if this is reproducible with just or similar, this was also on a content addressed machine, and reproducing the issue in a more isolated way would require another toolchain bootstrap which takes several days) the system from scratch using see errors like this: Expected behavior mercurial builds without errors Screenshots See log output from reproduction. Also ing the URLs as in the derivation linked in the description result in 404. Additional context The exact commit the system was build from is nixos/nixpkgs/, though as the same path URLs are used in nixos/nixpkgs/master, this is probably only partially relevant. Notify maintainers cc Metadata nix shell nixpkgs#nix-info --option trusted-substituters -c nix-info -m system: host os: multi-user?: sandbox: version: channels(nmelzer): nixpkgs: Maintainer information:

Related discussion:
text: patches = [ # https://phab.mercurial-scm.org/D10638, needed for below patch to apply (fetchpatch { <del> url = "https://phab.mercurial-scm.org/file/data/oymk4awh2dd7q6cwjbzu/PHID-FILE-bfcr7qrp5spg42wspxpd/D10638.diff"; </del> <ins> url = "https://phab.mercurial-scm.org/file/data/l7p2r4zcctcr3pzlybv2/PHID-FILE-bwjzxlz6sbegk3s4irik/D10638.diff"; </ins> sha256 = "0mfi324is02l7cnd3j0gbmg5rpyyqn3afg3f73flnfwmz5njqa5f"; }) # https://phab.mercurial-scm.org/D10639, fixes https://bz.mercurial-scm.org/show_bug.cgi?id=6514 (fetchpatch { <del> url = "https://phab.mercurial-scm.org/file/data/re4uqdhtknjiacx2ogwu/PHID-FILE-4m26id65dno5gzix2ngh/D10639.diff"; </del> <ins> url = "https://phab.mercurial-scm.org/file/data/v53nhburhtkhpccyecei/PHID-FILE-6v34oll6r2gkqo4ng5nt/D10639.diff"; </ins> sha256 = "0h5ilrd2x1789fr6sf4k1mcvxdh0xdyr94yawdacw87v3x12c8cb"; }) ];
Code change:
Describe the bug I'm on a mission to get (and thence ) compiling on M1 Macs, and having fixed , the next stumbling block is 4.1.1. Sadly, the build fails with , presumably related to . To Reproduce Steps to reproduce the behavior: Expected behavior A clear and concise description of what you expected to happen. Screenshots Additional context This works fine when built for x8664 on the same machine. 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(steve): nixpkgs: Maintainer information:
Submitted PR which disables Fortran support for OpenMPI on aarch64-darwin. Would that fix the issue for you or do you require Fortran?
This seems to be the build failure:
I actually have no idea if I require Fortran. I mean, presumably it's enabled for some reason, so I'm a little wary of disabling it on only one platform/arch combination: that feels like an atypical workaround.
To reproduce: I wonder if the gcc maintainers can offer any insight?
seems to hint at the stack-protector hardening, so perhaps something like could work around that? (no idea what's the real cause though, and I have no Darwin machine at hand)
You were right! Sent a PR in

Related discussion:
text: # Enable libfabric support (necessary for Omnipath networks) on x86_64 linux , fabricSupport ? stdenv.isLinux && stdenv.isx86_64 <ins> # Enable Fortran support , fortranSupport ? !(stdenv.isDarwin && stdenv.isAarch64) </ins> }: assert !cudaSupport || cudatoolkit != null; let <del> version = "4.1.1"; </del> cudatoolkit_joined = symlinkJoin { name = "${cudatoolkit.name}-unsplit"; paths = [ cudatoolkit.out cudatoolkit.lib ]; }; in stdenv.mkDerivation rec { pname = "openmpi"; <del> inherit version; </del> <ins> version = "4.1.1"; </ins> src = with lib.versions; fetchurl { url = "https://www.open-mpi.org/software/ompi/v${major version}.${minor version}/downloads/${pname}-${version}.tar.bz2";