Rewrite the microsoft/surface linuxPackage function to make it simpler to use

[mexisme]

Description of changes

The original linuxPackage function required passing-in more metadata / params than necessary (apologies for my code!).
I rewrote it some months ago, based on a similar set of functions I use in a private repo to (hopefully) make it simpler to use.

Things done

• Tested the changes in your own NixOS Configuration
• Tested the changes end-to-end by using your fork of nixos-hardware and
  importing it via <nixos-hardware> or Flake input

[mexisme]

cc @stigtsp @ifd3f @damianoognissanti

[damianoognissanti]

I had to manually set microsoft-surface.kernelVersion="6.6.13"; in my configuration.nix for it to build. Previously you could leave it unset for the default value.
I am building it now to see if everything works as expected. Will write again later today.

[damianoognissanti]

Btw, are there plans to cache the builds somehow? Either in the regular cache or the nix-community one? To avoid the frequent recompilations?

[damianoognissanti]

Everything seems to work on my machine. Batteries are detected (but they are with stock kernel too), the camera works (using v4l2loopback), and touchscreen too.

[mexisme]

I had to manually set microsoft-surface.kernelVersion="6.6.13"; in my configuration.nix for it to build. Previously you could leave it unset for the default value. I am building it now to see if everything works as expected. Will write again later today.

Yes, I ran out of time to find this, and just found + fixed it:

• 98e04a5

Thanks for testing it!

[mexisme]

I had to manually set microsoft-surface.kernelVersion="6.6.13"; in my configuration.nix for it to build. Previously you could leave it unset for the default value. I am building it now to see if everything works as expected. Will write again later today.

Ah, I see how that code was intended, now; I misinterpreted the intention.
Let me fix this, now...

[mexisme]

I had to manually set microsoft-surface.kernelVersion="6.6.13"; in my configuration.nix for it to build. Previously you could leave it unset for the default value. I am building it now to see if everything works as expected. Will write again later today.

Ah, I see how that code was intended, now; I misinterpreted the intention. Let me fix this, now...

I think I've fixed it — i.e. restored the functionality — so you can set the major.minor version as the default kernel-version.

[mexisme]

Btw, are there plans to cache the builds somehow? Either in the regular cache or the nix-community one? To avoid the frequent recompilations?

IDK if the nixos-hardware repo is cached anywhere by default?
However, it seems to come-up every so often.

Partly perhaps because I've been told that some people would prefer the hardware-specific fixes were rolled-into the main nixpkgs repo — except that moves pretty slow c.f. how quickly some hardware gets support...

[damianoognissanti]

I had to manually set microsoft-surface.kernelVersion="6.6.13"; in my configuration.nix for it to build. Previously you could leave it unset for the default value. I am building it now to see if everything works as expected. Will write again later today.

Ah, I see how that code was intended, now; I misinterpreted the intention. Let me fix this, now...

I think I've fixed it — i.e. restored the functionality — so you can set the major.minor version as the default kernel-version.

After a flake update I could unset the kernelVersion and it didn't complain and didn't try to build a different version, so it's probably fixed.

[damianoognissanti]

Btw, are there plans to cache the builds somehow? Either in the regular cache or the nix-community one? To avoid the frequent recompilations?

IDK if the nixos-hardware repo is cached anywhere by default? However, it seems to come-up every so often.

Partly perhaps because I've been told that some people would prefer the hardware-specific fixes were rolled-into the main nixpkgs repo — except that moves pretty slow c.f. how quickly some hardware gets support...

But one also cache just the microsoft part of nixos-hardware. This is done by someone with a powerful machine (or some build system somewhere), and uploaded to the binary cache.
Here are the instructions for the nix-community cache (but I am not sure how to get an authorized account though): https://app.cachix.org/cache/nix-community#push

And sorry that this is off topic...

[mexisme]

But one also cache just the microsoft part of nixos-hardware. This is done by someone with a powerful machine (or some build system somewhere), and uploaded to the binary cache. Here are the instructions for the nix-community cache (but I am not sure how to get an authorized account though): https://app.cachix.org/cache/nix-community#push

And sorry that this is off topic...

Afraid I'm not sure what the right thing to say, here, would be?

Perhaps looking into creating your own small build-cluster might help?

• https://nixos.wiki/wiki/Distributed_build
• https://nixos.org/manual/nix/stable/advanced-topics/distributed-builds.html

Desktop-style machines are almost always more performant than laptops, primarily because they can provide much better power and cooling, and even some of the very small 2nd-hand office-style machines can be surprisingly quick for the cost.

[Mic92]

Btw, are there plans to cache the builds somehow? Either in the regular cache or the nix-community one? To avoid the frequent recompilations?

If you can help me to add a hydra jobset to this repository, we can enable hydra.nixos.org for this repository. Than everything would land in the official binary cache.

[Mic92]

@mergify queue

[mergify]

queue

❌ Pull request must be rebased manually

The pull request can't be rebased without conflict and must be rebased manually

[Mic92]

@mergify rebase

[mergify]

rebase

❌ Base branch update has failed

Git reported the following error:

Rebasing (1/10)
CONFLICT (modify/delete): microsoft/surface/common/kernel/linux-6.1.x/patches.nix deleted in HEAD and modified in 8605f35 (Use a new linuxPackage function).  Version 8605f35 (Use a new linuxPackage function) of microsoft/surface/common/kernel/linux-6.1.x/patches.nix left in tree.
CONFLICT (modify/delete): microsoft/surface/common/kernel/linux-6.5.x/default.nix deleted in HEAD and modified in 8605f35 (Use a new linuxPackage function).  Version 8605f35 (Use a new linuxPackage function) of microsoft/surface/common/kernel/linux-6.5.x/default.nix left in tree.
Auto-merging microsoft/surface/common/kernel/linux-6.6.x/default.nix
CONFLICT (content): Merge conflict in microsoft/surface/common/kernel/linux-6.6.x/default.nix
Auto-merging microsoft/surface/common/kernel/linux-6.6.x/patches.nix
error: could not apply 8605f35... Use a new linuxPackage function
hint: Resolve all conflicts manually, mark them as resolved with
hint: "git add/rm <conflicted_files>", then run "git rebase --continue".
hint: You can instead skip this commit: run "git rebase --skip".
hint: To abort and get back to the state before "git rebase", run "git rebase --abort".
Could not apply 8605f35... Use a new linuxPackage function

[Mic92]

@mergify update

[mergify]

update

✅ Branch has been successfully updated

[Mic92]

@mergify queue

[mergify]

queue

❌ Pull request must be rebased manually

The pull request can't be rebased without conflict and must be rebased manually

[damianoognissanti]

Btw, are there plans to cache the builds somehow? Either in the regular cache or the nix-community one? To avoid the frequent recompilations?

If you can help me to add a hydra jobset to this repository, we can enable hydra.nixos.org for this repository. Than everything would land in the official binary cache.

I have created a new Issue to discuss this here:
#854