Closed Svenum closed 2 months ago
Hello, thank you for the PR. I also tried my hand at creating a Nix package for fw-fanctrl a while ago, but without the flake.
Using your package + flake, if I run nix build
and run the resulting executable, I get the following repeated output:
Could not start dynamically linked executable: ectool
NixOS cannot run dynamically linked executables intended for generic
linux environments out of the box. For more information, see:
https://nix.dev/permalink/stub-ld
Are you able to successfully run fw-fanctrl
using your flake? If so, how?
Ok, I am able to build it just like you sad nix build
and then there is the "result/bin" folder with the needed executables in it.
I run my system on unstable branch of NixOS maybe that is something?
I'm running into the same issue as @mdvmeijer reported, running on nixpkgs-unstable@2748d22b
- although a slightly outdated (2 weeks old).
❯ cat /etc/os-release
ANSI_COLOR="1;34"
BUG_REPORT_URL="https://github.com/NixOS/nixpkgs/issues"
BUILD_ID="24.05.20240413.90055d5"
DOCUMENTATION_URL="https://nixos.org/learn.html"
HOME_URL="https://nixos.org/"
ID=nixos
IMAGE_ID=""
IMAGE_VERSION=""
LOGO="nix-snowflake"
NAME=NixOS
PRETTY_NAME="NixOS 24.05 (Uakari)"
SUPPORT_URL="https://nixos.org/community.html"
VERSION="24.05 (Uakari)"
VERSION_CODENAME=uakari
VERSION_ID="24.05"
❯ nix build 'github:TamtamHero/fw-fanctrl/68a710cd3ac6ed0000cbb0bd147b6de4e0bd6689' && result/bin/ectool
Could not start dynamically linked executable: result/bin/ectool
NixOS cannot run dynamically linked executables intended for generic
linux environments out of the box. For more information, see:
https://nix.dev/permalink/stub-ld
Ok, just to be sure you did this:
git clone https://github.com/Svenum/fw-fanctrl
cd fw-fanctrl
git checkout add-flake
nix build .
Yes, I followed those four steps. I'm wondering, are you using NixOS or just the Nix package manager on another distro? It seems like the package should just not work on NixOS since it uses the ./bin/ectool
binary directly from this repo without any changes done for NixOS.
My guess for fixing this:
fw-ectool
package as a dependency and add it to PATH (e.g. propagatedBuildInputs
or makeWrapperArgs
)I would try this myself, but https://github.com/ssddq/fw-ectool doesn't seem to be updated to support AMD yet, so I'll first have to make a PR for that. I don't have easy access to my Intel FW for now.
Ok, weird. I use NixOS. I dont understand why I could build this and you dont. Yes to add it as build input could work. I'll try. I have an framework 16 I hope it works if you say it does not work on amd.
Hmm okay, then I'm not sure. Could be that you have ectool
already installed globally? But if not then I'm also out of ideas.
Not that I know.... But does not matter. I add it to the build inputs that it work for everyone 😉
Sorry for the late respond @mdvmeijer @dantefromhell. I added the built input now.
@mdvmeijer @dantefromhell @TamtamHero:
I have got it working, but now I got this errors:
Missing Chromium EC memory map.
Cannot find I2C adapter
Unable to establish host communication
Couldn't find EC
Missing Chromium EC memory map.
Cannot find I2C adapter
Unable to establish host communication
Couldn't find EC
model: Framework laptop 13, cpu_type: AMD, fan_count: 0
Missing Chromium EC memory map.
Cannot find I2C adapter
Unable to establish host communication
Couldn't find EC
speed: 15% temp: 0°C movingAverage: 0.0°C
Missing Chromium EC memory map.
Cannot find I2C adapter
Unable to establish host communication
Couldn't find EC
And I have an Framework 16 but it says: model: Framework laptop 13, cpu_type: AMD, fan_count: 0
@mdvmeijer @dantefromhell @TamtamHero:
I have got it working, but now I got this errors:
Missing Chromium EC memory map. Cannot find I2C adapter Unable to establish host communication Couldn't find EC Missing Chromium EC memory map. Cannot find I2C adapter Unable to establish host communication Couldn't find EC model: Framework laptop 13, cpu_type: AMD, fan_count: 0 Missing Chromium EC memory map. Cannot find I2C adapter Unable to establish host communication Couldn't find EC speed: 15% temp: 0°C movingAverage: 0.0°C Missing Chromium EC memory map. Cannot find I2C adapter Unable to establish host communication Couldn't find EC
And I have an Framework 16 but it says:
model: Framework laptop 13, cpu_type: AMD, fan_count: 0
If this is fixed it should work. So please help me. :)
After manually adding a config file due to #11 I can build and run
❯ nix build 'github:Svenum/fw-fanctrl/add-flake' --refresh
❯ sudo result/bin/fw-fanctrl
model: Framework laptop 13, cpu_type: Intel, fan_count: 1
speed: 15% temp: 44.75°C movingAverage: 44.75°C
speed: 15% temp: 43.0°C movingAverage: 44.69°C
speed: 15% temp: 43.0°C movingAverage: 44.63°C
^C
❯ sudo result/bin/fw-fanctrl --strategy lazyest
model: Framework laptop 13, cpu_type: Intel, fan_count: 1
speed: 0% temp: 46.0°C movingAverage: 46.0°C
speed: 0% temp: 45.25°C movingAverage: 45.98°C
speed: 0% temp: 44.25°C movingAverage: 45.94°C
speed: 0% temp: 44.5°C movingAverage: 45.9°C
speed: 0% temp: 45.25°C movingAverage: 45.88°C
speed: 0% temp: 44.5°C movingAverage: 45.84°C
speed: 0% temp: 44.5°C movingAverage: 45.81°C
^C
👍🏽
After manually adding a config file due to #11 I can build and run
❯ nix build 'github:Svenum/fw-fanctrl/add-flake' --refresh ❯ sudo result/bin/fw-fanctrl model: Framework laptop 13, cpu_type: Intel, fan_count: 1 speed: 15% temp: 44.75°C movingAverage: 44.75°C speed: 15% temp: 43.0°C movingAverage: 44.69°C speed: 15% temp: 43.0°C movingAverage: 44.63°C ^C ❯ sudo result/bin/fw-fanctrl --strategy lazyest model: Framework laptop 13, cpu_type: Intel, fan_count: 1 speed: 0% temp: 46.0°C movingAverage: 46.0°C speed: 0% temp: 45.25°C movingAverage: 45.98°C speed: 0% temp: 44.25°C movingAverage: 45.94°C speed: 0% temp: 44.5°C movingAverage: 45.9°C speed: 0% temp: 45.25°C movingAverage: 45.88°C speed: 0% temp: 44.5°C movingAverage: 45.84°C speed: 0% temp: 44.5°C movingAverage: 45.81°C ^C
👍🏽
That looks great: :+1: Then it seems like my problems are related to the fact, that I own a Framework 16....
Could you also try to add the flake to your system like that:
{
inputs = {
nixpkgs.url = "github:NixOS/nixpkgs/nixos-23.11"; # You could try unstable as well
fw-fanctrl = {
url = "github:Svenum/fw-fanctrl/add-flake"; # This is NOT a stable tested version
inputs.nixpkgs.follows = "nixpkgs";
};
};
outputs = {nixpkgs, fw-fanctrl}: {
nixosConfigurations.foo = nixpkgs.lib.nixosSystem {
system = "x86_64-linux";
modules = [
fw-fanctrl.nixosModules.default
configuration.nix
];
};
}
}
and then in your configuration.nix:
# Enable fw-fanctrl
programs.fw-fanctrl.enable = true;
# Add a custom config
programs.fw-fanctrl.config = ''
{
...
}
'';
If you know how the tool works, you could try to add a new custom config like I told above with programs.fw-fanctrl.config
.
If you added the config, could you check if evvery thing works?
I'm following this very remotely since I don't know anything about Nix, but:
@Svenum
"Couldn't find EC" is symptomatic of an outdated ectool
binary.
The one available on main
on this repo (https://github.com/TamtamHero/fw-fanctrl/blob/main/bin/ectool) is up to date and supports the 16" model
Ok, then I will try to create a second package definition qnd use your ectool binary. Thanks 👍
I have added the ectool as an extra package, please try the module and the package
I have updated the flake, so that you could edit the config like that:
programs.fw-fanctrl.config = {
defaultStrategy = "lazy";
strategies = {
"lazy" = {
fanSpeedUpdateFrequency = 5;
movingAverageInterval = 30;
speedCurve = [
{ temp = 0; speed = 15; }
{ temp = 50; speed = 15; }
{ temp = 65; speed = 25; }
{ temp = 70; speed = 35; }
{ temp = 75; speed = 50; }
{ temp = 85; speed = 100; }
];
};
};
};
This PR is read for review and would fix: https://github.com/TamtamHero/fw-fanctrl/issues/19 and https://github.com/TamtamHero/fw-fanctrl/issues/11
@thomaseizinger I have updated the descriptions, but on some options I do not know for what they are, maybe you know. :smile:
@thomaseizinger I have updated the descriptions, but on some options I do not know for what they are, maybe you know. 😄
Looks all good from what I can see!
Ok, some descriptions still have only ""
. Maybe you could add some text here. If they got filled the PR is ready I think.
Ok, some descriptions still have only
""
. Maybe you could add some text here. If they got filled the PR is ready I think.
I don't think I understand ectool well enough to actually fill those in unfortunately! But I think it would be valuable to add those descriptions :)
Also, big changes should soon be merged and some of your configurations will need to change along with them. I will do my best to help you make the transition but will need your help for the Nix stuff.
I would also advise against merging packaging-specific files into the main branch as more of them could be added in the future and it would quickly become a mess
(and no guarantee that they will be maintained/updated as new commits are made).
I think a separate branch /nix_packaging
(or similar) would be more appropriate.
What are your thoughts @TamtamHero ?
I would also advise against merging packaging-specific files into the main branch as more of them could be added in the future and it would quickly become a mess (and no guarantee that they will be maintained/updated as new commits are made). I think a separate branch
/nix_packaging
(or similar) would be more appropriate.What are your thoughts @TamtamHero ?
Thats sound valid. But I think its better to create a stable
branch witch is tested at a hole. So main
is for dev work and stable
is the stable one.
I would also advise against merging packaging-specific files into the main branch as more of them could be added in the future and it would quickly become a mess (and no guarantee that they will be maintained/updated as new commits are made). I think a separate branch
/nix_packaging
(or similar) would be more appropriate. What are your thoughts @TamtamHero ?Thats sound valid. But I think its better to create a
stable
branch witch is tested at a hole. Somain
is for dev work andstable
is the stable one.
I'm on board with this, the main branch for the work in progress version, a latest/stable branch for the most recent version and tags/branches for previous ones
*and the nix / packaging ones based on the latest/stable branch
I would also advise against merging packaging-specific files into the main branch as more of them could be added in the future and it would quickly become a mess (and no guarantee that they will be maintained/updated as new commits are made). I think a separate branch
/nix_packaging
(or similar) would be more appropriate. What are your thoughts @TamtamHero ?Thats sound valid. But I think its better to create a
stable
branch witch is tested at a hole. Somain
is for dev work andstable
is the stable one.
YMMV but a separate branch is even harder to maintain, no? It is common for the tip of main to not be stable. That is what tags are for. They mark stable releases within a branch.
The convention for files added to a repo but not necessarily have them up-to-date is to put them in a contrib/
directory.
YMMV but a separate branch is even harder to maintain, no? It is common for the tip of main to not be stable. That is what tags are for. They mark stable releases within a branch.
I agree that more branches can mean more work and that tags may be more appropriate here
The convention for files added to a repo but not necessarily have them up-to-date is to put them in a contrib/ directory.
I disagree.
First of all, some packaging solutions may require files in the root directory of the project, in which case you are cooked.
More than that, it means that you will have every single packaging solution configuration whether you want it or not (imagine installing the package for nix and having AUR configs in the project you pull?).
Lastly, you run the risk of having outdated/broken configs every time someone contributes. If someone wants to contribute to the project, they will have to go through every single packaging solution and make sure their changes do not break them (and most likely won't be able to test them all). In my opinion, this is not their responsibility, but one of the maintainers of that solution. So in this case, the contributor will add the new feature without updating the solutions (and rightly so), which means that you will have outdated/broken solution config most of the time. It will also cause problems with releases, you need to be sure that every single packaging solution are done and working at the exact same time and that they won't need changes before the next stable release.
In the end, I believe that branching is the most appropriate way to do this in our case. Packaging solutions are separate, updated as needed and always in sync with the version they are shipping.
Lastly, you run the risk of having outdated/broken configs every time someone contributes. If someone wants to contribute to the project, they will have to go through every single packaging solution and make sure their changes do not break them (and most likely won't be able to test them all).
That very much depends on what policy is being set. In the best case, nothing breaks and people just get the new features. In the worst case, somebody updating their flakes (speaking for NixOS here) will receive a broken package and make a bug report. Then the maintainer of the nix packaging (or somebody else) can come along and fix things.
If everything is on a separate branch, people have to actively monitor every push to main
and update the respective branches. That is a lot more work for everyone for IMO little benefit. It is much harder to detect outdated packages compared to broken ones.
That very much depends on what policy
That's true, however I still think that active updates for packaging solutions are better than the implicit way.
We should do our best not to break things, and as you said, in most cases it updating them would not require any specific manipulation, just testing that there are no obvious side effects.
This would also improve the security side of things. If, for whatever reason, a commit had a dangerous side effect on some of the packaging solutions, it would have a better chance of being caught early.
I guess we could build some automation to automatically open a PR to the respective branch for each push to main. That way, whoever are the maintainers of the nix packaging stuff can at least get notified.
I think that is a great idea. And for issues templates would be nice, so that the user know that he has to mark us (@thomaseizinger @leopoldhub and @Svenum as long as you want) when its a Nix related problem.
I think that is a great idea. And for issues templates would be nice, so that the user know that he has to mark us (@thomaseizinger @leopoldhub and @Svenum as long as you want) when its a Nix related problem.
OK with me, I will work on the project globally for the time being.
Hi @Svenum , could you please rebase your branch onto the updated main? I will start to adapt this branch as soon as it is done. Have a great day
I am going to do this tomorrow 👍
Branch is up to date now
I think that is a great idea. And for issues templates would be nice, so that the user know that he has to mark us (@thomaseizinger @leopoldhub and @Svenum as long as you want) when its a Nix related problem.
Works for me too! My Nix-fu is still pretty bad but happy to help!
This PR should target a different branch then, right?
Works for me too! My Nix-fu is still pretty bad but happy to help!
This PR should target a different branch then, right?
Thanks, yes, I belive so
Ok, on witch branch should I push then?
Ok, on witch branch should I push then?
We need @TamtamHero to create a new branch and then we can re-direct this PR to it. Something like nixos-flake
?
@Svenum I just created the packaging/nix
branch, could you target this one?
Is changed
I am currently working on a pr related to this one #37 that should make our work easier. I will start working on this one as soon as all is well over there. Have a nice day
The deletion of the requirements.txt borke the nix package
The deletion of the requirements.txt borke the nix package
Hi, yes I will look into it. I haven't had much time in the last 3 days, I will be more active this week. I will keep you informed 👍
Ok, I fixed the build Issue but now I get this after typing fw-fanctrl
:
Traceback (most recent call last):
File "/nix/store/pq5jxxsp2iqwan95fyj3aasc8m01r4kp-python3.11-fw-fanctrl-20-04-2024/bin/.fw-fanctrl-wrapped", line 322, in <module>
main()
File "/nix/store/pq5jxxsp2iqwan95fyj3aasc8m01r4kp-python3.11-fw-fanctrl-20-04-2024/bin/.fw-fanctrl-wrapped", line 303, in main
client_socket.connect(COMMANDS_SOCKET_FILE_PATH)
FileNotFoundError: [Errno 2] No such file or directory
Looks like the same error as in https://github.com/TamtamHero/fw-fanctrl/issues/35.
The problem is maybe that line: https://github.com/TamtamHero/fw-fanctrl/blob/176d34bedafc3540edd9261629ebf47f673252b7/fanctrl.py#L16C1-L16C91
In NixOS you dont have the right to write in /etc
. I would recomend to do the socket under /run/fw-fanctrl/
Hi @Svenum , If the root user cannot write to /etc
, then the socket does not exist.
You are right about using /run
instead of /etc
as it is in the standard.
I will make the change in #37 as well.
I try to add the nixos flake, but I am not very experienced. So if you want to help, fell free. :smile: