Branch-off is the 10th. Staging-next stabilization typically takes a week, although if there are no regressions its only 2 or 3 days. I’m about to start a new staging-next cycle.
This I reverted because there were too many regressions.
IMO, would be great to include asus-wmi-sensors
package asus-wmi-sensors: init at 0.0.1 by voanhduy1512 · Pull Request #75885 · NixOS/nixpkgs · GitHub that gives sensors support for fresh Asus motherboards.
Would it be possible to upgrade to Plasma 5.17?
That’s in progress Plasma 5.17.5 by ttuegel · Pull Request #79011 · NixOS/nixpkgs · GitHub, I asked and @ttuegel said that’s what is planned .
Ideally (pending agreement from maintainers), I would like to get this in:
https://github.com/NixOS/nixpkgs/pull/78501
This includes opt-in new behavior for fetchCargo
that makes it much more efficient and possible to cache in hashed mirrors, but at the cost of changing the cargoSha256
for Rust applications (once opted in). I’m planning on sending a treewide PR that updates all the Rust applications to the new behavior and makes it opt-out once the infra lands, so it’d be nice of the functionality for that new behavior is on the NixOS release so that backporting changes to 20.03 will be easier for maintainers.
Note that the proposed functionality has no functional change to how we build Rust applications, just how we manage the cargo vendor directory.
The networking.resolvconf.useHostResolvConf
option seems to have been superseeded by networking.useHostResolvConf
and doesn’t do anything anymore.
I think it would be nice to have that fixed for 20.03, as that was quite confusing when figuring out why DNS didn’t work.
Overlayfs instead of unionfs on installation media is long overdue. Every major distribution is using it.
https://github.com/NixOS/nixpkgs/pull/35188
If I read this correctly, the option silently did nothing and now you’ll be warned about that if you use it. What do you suggest to improve? nixos/resolvconf: Remove useHostResolvConf option by infinisil · Pull Request #79243 · NixOS/nixpkgs · GitHub
Ah, I’m sorry… I didn’t realize the PR happened after you wrote this.
I’m starting to get nervous about Replace simp-le with lego and support DNS-01 challenge by m1cr0man · Pull Request #77578 · NixOS/nixpkgs · GitHub and its inclusion in 20.03
@worldofpeace @disassembler, any chance you could have a look at this one for 20.03:
https://github.com/NixOS/nixpkgs/pull/77622
Thanks!
Would be great to get some attention to nixos/grub: make memtest work with EFI by wedens · Pull Request #78453 · NixOS/nixpkgs · GitHub to get memtest fixed with EFI.
Hello everyone again. Me and @disassembler personal assessment of master right now is it’s very clear for branch off. But we don’t have perfect vision, if there’s anything serious please PM us on IRC or mention us in #nixos-dev.
I plan to begin the beta tasks around 18:30 UTC.
Just want to confirm that 20.03 was branched at the time we said.
I haven’t done the Zero Hydra failure and beta announcement (this is essentially a call for testing), because we ran into an issue with the release-20.03 jobset not evaluating Hydra: nixos/release-20.03 and unstable fails to evaluate · Issue #79907 · NixOS/nixpkgs · GitHub. This means hydra isn’t building anything, so that obviously would make any contributions to 20.03 difficult. Anyways, if you have PRs coming into master that has security implications please ping us @NixOS/nixos-release-managers.
If Hydra isn’t evaluating release-20.03 why isn’t unstable also affected, or is it?
Is it too late to consider adding rakudo-2020.01?
rakudo: 2017.01 -> 2020.01 by stigtsp · Pull Request #76656 · NixOS/nixpkgs · GitHub was just merged into unstable, I’m worried that 20.03 might release with 2017.01 which is quite outdated.
@worldofpeace I think it would be great to include into 20.03:
- bump of smartmontools as we currently have 1+ year old version with old devicedb smartmontools: 7.0 -> 7.1 and devicedb updated to latest by Frostman · Pull Request #81099 · NixOS/nixpkgs · GitHub
- go 1.14 - it was released yesterday, but there are releases every half a year and we had 1.13 in 19.09, so, it’ll be great to have 1.14 in 20.03 go_1_14: init at 1.14 and switch to it by Frostman · Pull Request #81071 · NixOS/nixpkgs · GitHub
I can do and test backports for them as soon as (if? ) accepted to master.