Question:
Since May 10, .NET 5.0 is EOL (End Of Life), and should not be used. Should it be marked as EOF similar to dotnet 2.2 and 3.0? See All packages using dotnet 5.0 should be updated to use a newer, supported version. These packages still need updating: [x] - [x] - [x] - [x] pkgs/development/tools/build- - [x] -
There is at least one package, which currently uses dotnet 5 sdk - . So we will need to update it beforehand. Btw, I'm not sure if we have any policy regarding packages removal, for nixpkgs in general or specifically for it's dotnet part. , what do you think?
The package is also using .NET 5: . But this is because I made the PR upstream updating it from .NET 4 to 5. I suspect that the transition to 6 will be similarly easy.
I think we should just mark it as depricated, as many projects do still use it upstream. Dotnet version 3 is also still commonly used, so I dont expect it would be realistic to remove version 5 any time soon. also uses dotnet 5 by default, I'll go ahead and switch that over now. See . That doesnt mark dotnet 5 as deprecated or change anything from a SDK perspective, just some preperation work.
See as well, it adds a warning whenever dotnet version 5 is used. Not using a throw for now since a few packages depend on it and I dont have the time to clean that all up at the moment.
Can you provide a list of packages that need updating?
Based on a quick grep: pkgs/development/tools/build-
I believe that after all the above PRs are merged, we should be able to safely remove .NET 5 from nixpkgs :)

## Files in versions/ are generated automatically by update.sh ## dotnet_3_1 = import ./versions/3.1.nix (buildAttrs // { icu = icu70; }); <del> dotnet_5_0 = import ./versions/5.0.nix (buildAttrs // { inherit icu; }); </del> dotnet_6_0 = import ./versions/6.0.nix (buildAttrs // { inherit icu; }); dotnet_7_0 = import ./versions/7.0.nix (buildAttrs // { inherit icu; }); in


Question:
Since May 10, .NET 5.0 is EOL (End Of Life), and should not be used. Should it be marked as EOF similar to dotnet 2.2 and 3.0? See All packages using dotnet 5.0 should be updated to use a newer, supported version. These packages still need updating: [x] - [x] - [x] - [x] pkgs/development/tools/build- - [x] -
There is at least one package, which currently uses dotnet 5 sdk - . So we will need to update it beforehand. Btw, I'm not sure if we have any policy regarding packages removal, for nixpkgs in general or specifically for it's dotnet part. , what do you think?
The package is also using .NET 5: . But this is because I made the PR upstream updating it from .NET 4 to 5. I suspect that the transition to 6 will be similarly easy.
I think we should just mark it as depricated, as many projects do still use it upstream. Dotnet version 3 is also still commonly used, so I dont expect it would be realistic to remove version 5 any time soon. also uses dotnet 5 by default, I'll go ahead and switch that over now. See . That doesnt mark dotnet 5 as deprecated or change anything from a SDK perspective, just some preperation work.
See as well, it adds a warning whenever dotnet version 5 is used. Not using a throw for now since a few packages depend on it and I dont have the time to clean that all up at the moment.
Can you provide a list of packages that need updating?
Based on a quick grep: pkgs/development/tools/build-
I believe that after all the above PRs are merged, we should be able to safely remove .NET 5 from nixpkgs :)

combinePackages = attrs: callPackage (import ./combine-packages.nix attrs) {}; # EOL <del> sdk_2_1 = throw "Dotnet SDK 2.1 is EOL, please use 3.1 (LTS), 5.0 (Current) or 6.0 (LTS)"; sdk_2_2 = throw "Dotnet SDK 2.2 is EOL, please use 3.1 (LTS), 5.0 (Current) or 6.0 (LTS)"; sdk_3_0 = throw "Dotnet SDK 3.0 is EOL, please use 3.1 (LTS), 5.0 (Current) or 6.0 (LTS)"; } // dotnet_3_1 // dotnet_5_0 // dotnet_6_0 // dotnet_7_0 </del> <ins> sdk_2_1 = throw "Dotnet SDK 2.1 is EOL, please use 6.0 (LTS) or 7.0 (Current)"; sdk_2_2 = throw "Dotnet SDK 2.2 is EOL, please use 6.0 (LTS) or 7.0 (Current)"; sdk_3_0 = throw "Dotnet SDK 3.0 is EOL, please use 6.0 (LTS) or 7.0 (Current)"; sdk_5_0 = throw "Dotnet SDK 5.0 is EOL, please use 6.0 (LTS) or 7.0 (Current)"; } // dotnet_3_1 // dotnet_6_0 // dotnet_7_0 </ins>


Question:
Since May 10, .NET 5.0 is EOL (End Of Life), and should not be used. Should it be marked as EOF similar to dotnet 2.2 and 3.0? See All packages using dotnet 5.0 should be updated to use a newer, supported version. These packages still need updating: [x] - [x] - [x] - [x] pkgs/development/tools/build- - [x] -
There is at least one package, which currently uses dotnet 5 sdk - . So we will need to update it beforehand. Btw, I'm not sure if we have any policy regarding packages removal, for nixpkgs in general or specifically for it's dotnet part. , what do you think?
The package is also using .NET 5: . But this is because I made the PR upstream updating it from .NET 4 to 5. I suspect that the transition to 6 will be similarly easy.
I think we should just mark it as depricated, as many projects do still use it upstream. Dotnet version 3 is also still commonly used, so I dont expect it would be realistic to remove version 5 any time soon. also uses dotnet 5 by default, I'll go ahead and switch that over now. See . That doesnt mark dotnet 5 as deprecated or change anything from a SDK perspective, just some preperation work.
See as well, it adds a warning whenever dotnet version 5 is used. Not using a throw for now since a few packages depend on it and I dont have the time to clean that all up at the moment.
Can you provide a list of packages that need updating?
Based on a quick grep: pkgs/development/tools/build-
I believe that after all the above PRs are merged, we should be able to safely remove .NET 5 from nixpkgs :)

<del> { buildAspNetCore, buildNetRuntime, buildNetSdk, icu }: # v5.0 (eol) { aspnetcore_5_0 = buildAspNetCore { inherit icu; version = "5.0.17"; srcs = { x86_64-linux = { url     = "https://download.visualstudio.microsoft.com/download/pr/a2b96f83-e22a-4fa6-a10e-709b3effac9a/0d6ade6c0ceebc8ef7dbf2b1a6d86f17/aspnetcore-runtime-5.0.17-linux-x64.tar.gz"; sha512  = "d8e87804e9e86273c6512785bd5a6f0e834ff3f4bbebc11c4fcdf16ab4fdfabd0d981a756955267c1aa9bbeec596de3728ce9b2e6415d2d80daef0d999a5df6d"; }; aarch64-linux = { url     = "https://download.visualstudio.microsoft.com/download/pr/6eb8aee2-cbea-4c4f-9bb9-ea6229ec229b/d6c438e5071c359ad995134f0a33e731/aspnetcore-runtime-5.0.17-linux-arm64.tar.gz"; sha512  = "ac1a9d89f1b730dfdca9c2e48373ef21f8f9316014eefbe6b11516f8195d3b3efc4e482883774b74ea2ff1cb77174a2cb471bd1157ab5b7d71621e3026c38e9b"; }; x86_64-darwin = { url     = "https://download.visualstudio.microsoft.com/download/pr/25e4817f-6fd0-46dc-be0d-d819445bac5c/a8fa228c872df683741c8a79745f8fb3/aspnetcore-runtime-5.0.17-osx-x64.tar.gz"; sha512  = "bb0c43c723090fa2d8a0255e6fc8c004ebe7baf2d5d56e22ad2e6336a67fe415333d451e459c8857c0ccb5819d998232c9617bf45f222559d4b8891b0af41f20"; }; }; }; runtime_5_0 = buildNetRuntime { inherit icu; version = "5.0.17"; srcs = { x86_64-linux = { url     = "https://download.visualstudio.microsoft.com/download/pr/e77438f6-865f-45e0-9a52-3e4b04aa609f/024a880ed4bfbfd3b9f222fec0b6aaff/dotnet-runtime-5.0.17-linux-x64.tar.gz"; sha512  = "a9c4784930a977abbc42aff1337dda06ec588c1ec4769a59f9fcab4d5df4fc9efe65f8e61e5433db078f67a94ea2dfe870c32c482a50d4c16283ffacacff4261"; }; aarch64-linux = { url     = "https://download.visualstudio.microsoft.com/download/pr/6690730f-cf10-40f1-9d4d-4c0d002f22d0/e117133858f190c169873200b8d7b9d7/dotnet-runtime-5.0.17-linux-arm64.tar.gz"; sha512  = "99cb11871924d3abedcc9c8079c54bc0c550203c7cbe4e349ed70d4355f40e4620b68d90b797e6461d898c06bed6953580e2cd4ad01483e5de107ca5a3409610"; }; x86_64-darwin = { url     = "https://download.visualstudio.microsoft.com/download/pr/39326cf0-dc7f-42a3-9f7a-fe30c75c7a7f/33cbce552148e13d47120fe4502f5b5e/dotnet-runtime-5.0.17-osx-x64.tar.gz"; sha512  = "31add512418640f98bc9511509db2049a2674c7725169d26be89218a02ac7972e03e5d6be5a3d45a0dfa764e6eade503a8f4957b7b198ec6ad412e423d95f1b9"; }; }; }; sdk_5_0 = buildNetSdk { inherit icu; version = "5.0.408"; srcs = { x86_64-linux = { url     = "https://download.visualstudio.microsoft.com/download/pr/904da7d0-ff02-49db-bd6b-5ea615cbdfc5/966690e36643662dcc65e3ca2423041e/dotnet-sdk-5.0.408-linux-x64.tar.gz"; sha512  = "abbf22c420df2d8398d1616efa3d31e1b8f96130697746c45ad68668676d12e65ec3b4dd75f28a5dc7607da58b6e369693c0e658def15ce2431303c28e99db55"; }; aarch64-linux = { url     = "https://download.visualstudio.microsoft.com/download/pr/d4b71fac-a2fd-4516-ac58-100fb09d796a/e79d6c2a8040b59bf49c0d167ae70a7b/dotnet-sdk-5.0.408-linux-arm64.tar.gz"; sha512  = "50f23d7aca91051d8b7c37f1a76b1eb51e6fe73e017d98558d757a6b9699e4237d401ce81515c1601b8c21eb62fee4e0b4f0bbed8967eefa3ceba75fc242f01b"; }; x86_64-darwin = { url     = "https://download.visualstudio.microsoft.com/download/pr/4aeecc7c-7ffa-418f-9362-cf5eb3ed0396/055d5e6064a9fdecd7d906f5f262373d/dotnet-sdk-5.0.408-osx-x64.tar.gz"; sha512  = "3fdd4deac2809b00c0f669d5488000ac1b9a47dee6ab7b31167d7cec4759a10ee347fd4f52090a40684e5ecc1e1f57eb99c558e561edfd1436a2f77fc1c1a0b2"; }; }; packages = { fetchNuGet }: [ (fetchNuGet { pname = "Microsoft.AspNetCore.App.Runtime.linux-arm"; version = "5.0.17"; sha256 = "0mfawgcc23r44a1r7ynafxwga6jzn0f0z5ys03qssrvlcdsb376x"; }) (fetchNuGet { pname = "Microsoft.AspNetCore.App.Runtime.linux-arm64"; version = "5.0.17"; sha256 = "183xgqzlwd5lhacxdwcjl8vcq7r7xypv0hddps9k32mmmwf83d8h"; }) (fetchNuGet { pname = "Microsoft.AspNetCore.App.Runtime.linux-musl-arm64"; version = "5.0.17"; sha256 = "0i5pp1smjkyhiyhcbkyc3cxz0sx9204bfml8wsdy7bxznbh2gkmw"; }) (fetchNuGet { pname = "Microsoft.AspNetCore.App.Runtime.linux-musl-x64"; version = "5.0.17"; sha256 = "1fmd9jq2nzy63hjh4sa6zl636wpgwr3r8ahzln5w14m9k87lfdbk"; }) (fetchNuGet { pname = "Microsoft.AspNetCore.App.Runtime.linux-x64"; version = "5.0.17"; sha256 = "066fwdlssbv556zd9w1x87x1j8j4kafj9rxyy0692bssdb4gcyc8"; }) (fetchNuGet { pname = "Microsoft.AspNetCore.App.Runtime.osx-x64"; version = "5.0.17"; sha256 = "1qvvqf8mmzzc7a7fhx324dprnbxhknr3qxspb2xhsn3yyg44xn2d"; }) (fetchNuGet { pname = "Microsoft.AspNetCore.App.Runtime.win-arm"; version = "5.0.17"; sha256 = "1gzf2gv4z9bn1cr1kpqpf1jf7m0p0wd1pxq5ndylq6bw353yglk1"; }) (fetchNuGet { pname = "Microsoft.AspNetCore.App.Runtime.win-arm64"; version = "5.0.17"; sha256 = "1lml70ln9bfjrfjf3jbxfzd5kgd4cp4h7v052md5ja364g7lalsy"; }) (fetchNuGet { pname = "Microsoft.AspNetCore.App.Runtime.win-x64"; version = "5.0.17"; sha256 = "0j90fri15c05lw96xybgvqkysfm7g8grhkrg25g75vhi6ni2ricj"; }) (fetchNuGet { pname = "Microsoft.AspNetCore.App.Runtime.win-x86"; version = "5.0.17"; sha256 = "1bdb887xvgxsmphys83zp9skn848p1r8viclc8p29w1rby4wi19i"; }) (fetchNuGet { pname = "Microsoft.NETCore.App.Host.linux-arm"; version = "5.0.17"; sha256 = "0y90p765sj54clf2bwrka99w73g8b9550b4qvyilqggzydl1c1hk"; }) (fetchNuGet { pname = "Microsoft.NETCore.App.Host.linux-arm64"; version = "5.0.17"; sha256 = "07v7vyqm556xr1ypkazfp6gh6drgf20zkwbhkpja8bwdcr6lphbb"; }) (fetchNuGet { pname = "Microsoft.NETCore.App.Host.linux-musl-arm64"; version = "5.0.17"; sha256 = "0sbzlzhazh31s63hw9553hk9j56fxssncmfgidiyh0dg73aacrsp"; }) (fetchNuGet { pname = "Microsoft.NETCore.App.Host.linux-musl-x64"; version = "5.0.17"; sha256 = "1qxphvlr882rvmj71y2imnf6r3hh4ln2n138qjyv1z129dp2g4y1"; }) (fetchNuGet { pname = "Microsoft.NETCore.App.Host.linux-x64"; version = "5.0.17"; sha256 = "1lc2jhr4ikffi5ylyf8f6ya6k0hdj0wp1l0017grrwd4m5ajj4vv"; }) (fetchNuGet { pname = "Microsoft.NETCore.App.Host.osx-x64"; version = "5.0.17"; sha256 = "02g5w41ivrw3n6cy3l3ixhcl8bw1fsv4bzs2m34k9h5fqmliaf3c"; }) (fetchNuGet { pname = "Microsoft.NETCore.App.Host.win-arm"; version = "5.0.17"; sha256 = "07rfkxpf6rp8x0lybl8hx40mk09w5gjrr9djkjcp8lvjgzidnxq9"; }) (fetchNuGet { pname = "Microsoft.NETCore.App.Host.win-arm64"; version = "5.0.17"; sha256 = "1i7wka56n3akr96jrkj37jx98bwxfzhpx5705930v50izligd08x"; }) (fetchNuGet { pname = "Microsoft.NETCore.App.Host.win-x64"; version = "5.0.17"; sha256 = "15f1kqlpp1d05dhg3dfya32vvzbpj6c7gxds947f10jb0hqlnhdj"; }) (fetchNuGet { pname = "Microsoft.NETCore.App.Host.win-x86"; version = "5.0.17"; sha256 = "1j1334zxv815ksdnllnbwwsbwnimjlpknjmqy1riy2zpswxlfkz6"; }) (fetchNuGet { pname = "Microsoft.NETCore.App.Runtime.linux-arm"; version = "5.0.17"; sha256 = "0mmgd6nacx4fzf0w02ch0qxa43vrv6wfspykxsy2bkpvrnvr8xr9"; }) (fetchNuGet { pname = "Microsoft.NETCore.App.Runtime.linux-arm64"; version = "5.0.17"; sha256 = "16whaq82pj6fqa0vam3a0va9ly843aa1z12hza040vn6252kk9fq"; }) (fetchNuGet { pname = "Microsoft.NETCore.App.Runtime.linux-musl-arm64"; version = "5.0.17"; sha256 = "1zavnwqvn2f7lhb880wgv02anrvqsh6l34w72knwd31irggph08l"; }) (fetchNuGet { pname = "Microsoft.NETCore.App.Runtime.linux-musl-x64"; version = "5.0.17"; sha256 = "173r2srcbad2prrw3l914scmdks3mghxgszvlwypdjnv0f2szgvv"; }) (fetchNuGet { pname = "Microsoft.NETCore.App.Runtime.linux-x64"; version = "5.0.17"; sha256 = "0jgcfs3jc98jfyaaamssznckbpnaygplk8pjsp6dswpansz5bnnq"; }) (fetchNuGet { pname = "Microsoft.NETCore.App.Runtime.osx-x64"; version = "5.0.17"; sha256 = "1ph5kx18syinp8bpzw80bgq3njl65gwzws727xcmxnysgm7snmjp"; }) (fetchNuGet { pname = "Microsoft.NETCore.App.Runtime.win-arm"; version = "5.0.17"; sha256 = "0m4jhn70parwnl18fql0sk9sf14y8cf08xw6x2cm5bfhnc9jvjny"; }) (fetchNuGet { pname = "Microsoft.NETCore.App.Runtime.win-arm64"; version = "5.0.17"; sha256 = "1af20jkv73767b4fy18s2dvjncaca1ny0csyr7wbhvqfs59y3n1x"; }) (fetchNuGet { pname = "Microsoft.NETCore.App.Runtime.win-x64"; version = "5.0.17"; sha256 = "0llhsi03wyp2yjqy0snywqgwjgam91i4nsf5lc9kaxkk5h6vj1a0"; }) (fetchNuGet { pname = "Microsoft.NETCore.App.Runtime.win-x86"; version = "5.0.17"; sha256 = "0xvprbjwd3fymddvavsy7wk5q2hp45hdi10qz4rdbmns23vqkzmf"; }) (fetchNuGet { pname = "Microsoft.NETCore.DotNetAppHost"; version = "5.0.17"; sha256 = "0vhvxpba3i9ffp4gp56l3rnlhq9yg07n3dv5qi89zb90vgyqjh1p"; }) (fetchNuGet { pname = "Microsoft.NETCore.DotNetHost"; version = "5.0.17"; sha256 = "074c9byxwmndfdavxn103220f5gklaaxc9wj7zpb5v3yr3ads30f"; }) (fetchNuGet { pname = "Microsoft.NETCore.DotNetHostPolicy"; version = "5.0.17"; sha256 = "03jkkpsy2zjfp722fa2fcnpk2g6jzy0bn9vip5c39k78y5pz29x6"; }) (fetchNuGet { pname = "Microsoft.NETCore.DotNetHostResolver"; version = "5.0.17"; sha256 = "1ih6c104skp9q17i2dnsma45l6nv5c62vv2i1988dcjw2v0sl98m"; }) (fetchNuGet { pname = "runtime.linux-arm64.Microsoft.NETCore.DotNetAppHost"; version = "5.0.17"; sha256 = "0gwsxd1l0n32xnw0lyjixj2634iyygdb8pd7chydsr3qk8njxnpk"; }) (fetchNuGet { pname = "runtime.linux-arm64.Microsoft.NETCore.DotNetHost"; version = "5.0.17"; sha256 = "0x5dhn1jkwqnd0cki1vi97rhyfac6w79hvh9dxvnkn2k04sbps8q"; }) (fetchNuGet { pname = "runtime.linux-arm64.Microsoft.NETCore.DotNetHostPolicy"; version = "5.0.17"; sha256 = "1ipx3qn78z6gi415c4fa9wgy8k75aifbml6ys1c9ghl6yxbv0fd0"; }) (fetchNuGet { pname = "runtime.linux-arm64.Microsoft.NETCore.DotNetHostResolver"; version = "5.0.17"; sha256 = "1wgbx648yndl0hh8vx6sflfwjyr5pfhi7vj7v19l6vxnrr1096w7"; }) (fetchNuGet { pname = "runtime.linux-arm.Microsoft.NETCore.DotNetAppHost"; version = "5.0.17"; sha256 = "17jc8jc2dk1g8996jpq3k0g6c5inijivxkbz0grxrgr5jbyiv19y"; }) (fetchNuGet { pname = "runtime.linux-arm.Microsoft.NETCore.DotNetHost"; version = "5.0.17"; sha256 = "0ydn40qn6cs6f20byvmc9j008s6csxjbh6jh5w4q995vipcmcpcj"; }) (fetchNuGet { pname = "runtime.linux-arm.Microsoft.NETCore.DotNetHostPolicy"; version = "5.0.17"; sha256 = "0bw08wlf96vcyix850y8jips1glrz2cbj647af4d7gggw8p3wwzw"; }) (fetchNuGet { pname = "runtime.linux-arm.Microsoft.NETCore.DotNetHostResolver"; version = "5.0.17"; sha256 = "0xsqyw848scwcz09pgc719776q712xabx4xv47srzij34p2pq7np"; }) (fetchNuGet { pname = "runtime.linux-musl-arm64.Microsoft.NETCore.DotNetAppHost"; version = "5.0.17"; sha256 = "00b0vipypjai4l8icr74kjhglxx2xlc3nw3vyiwisg52l9zyby66"; }) (fetchNuGet { pname = "runtime.linux-musl-arm64.Microsoft.NETCore.DotNetHost"; version = "5.0.17"; sha256 = "1cdgd4p5zr1mzz9hlb5mj946zfa1vn9wya5y2bhqn9y4ak831wzp"; }) (fetchNuGet { pname = "runtime.linux-musl-arm64.Microsoft.NETCore.DotNetHostPolicy"; version = "5.0.17"; sha256 = "17v8m4fxm4q40z49a2h4lw9dawg6pwfv4s2dskzc23ggcjgr6dp1"; }) (fetchNuGet { pname = "runtime.linux-musl-arm64.Microsoft.NETCore.DotNetHostResolver"; version = "5.0.17"; sha256 = "1fbqi92prqmvxx0rx7vhl10l665jmmhb2ng5jndimggydb0ckpqh"; }) (fetchNuGet { pname = "runtime.linux-musl-x64.Microsoft.NETCore.DotNetAppHost"; version = "5.0.17"; sha256 = "1rijxkzzk65xs9z2ygs13h0rhw1cli5vwshmvs1gfnwhhn8ic0gx"; }) (fetchNuGet { pname = "runtime.linux-musl-x64.Microsoft.NETCore.DotNetHost"; version = "5.0.17"; sha256 = "02mxvpm2zs5jvawigvxlnrw6si4zwj6qlcas99m9xdmm8yqq22cm"; }) (fetchNuGet { pname = "runtime.linux-musl-x64.Microsoft.NETCore.DotNetHostPolicy"; version = "5.0.17"; sha256 = "0c1lcl3yy88vdfw12c7h0ww596qfjd5f8l2mn7mlqs6i3f864bkg"; }) (fetchNuGet { pname = "runtime.linux-musl-x64.Microsoft.NETCore.DotNetHostResolver"; version = "5.0.17"; sha256 = "0w0wg9ah7vngvpyds67l6qhizpkdf2r6m6cqyyvv3s5dw5l8rxin"; }) (fetchNuGet { pname = "runtime.linux-x64.Microsoft.NETCore.DotNetAppHost"; version = "5.0.17"; sha256 = "17yy7605vkfz0f4h58005gdfg6fnjxlcnq0vg0hrxsgbdqmd7p1i"; }) (fetchNuGet { pname = "runtime.linux-x64.Microsoft.NETCore.DotNetHost"; version = "5.0.17"; sha256 = "0av25fgkdl7zvn44wp8gqx2xl2mdlv1f9cgxzp7xk5yq8f7ynxpq"; }) (fetchNuGet { pname = "runtime.linux-x64.Microsoft.NETCore.DotNetHostPolicy"; version = "5.0.17"; sha256 = "1smhmdfq0jlv1gq18hdaj0y9yzkvqzmki19c0b3j5b76yxxxpbwz"; }) (fetchNuGet { pname = "runtime.linux-x64.Microsoft.NETCore.DotNetHostResolver"; version = "5.0.17"; sha256 = "0n0cdb9zpdb4h4v6r265pqmqg8c94ydywvna6jp1c6qhqlr0qk39"; }) (fetchNuGet { pname = "runtime.osx-x64.Microsoft.NETCore.DotNetAppHost"; version = "5.0.17"; sha256 = "1s2n2sx29c8rx549zizj8yrddjl98a7vwvxw56y0jvvbwphr9gz4"; }) (fetchNuGet { pname = "runtime.osx-x64.Microsoft.NETCore.DotNetHost"; version = "5.0.17"; sha256 = "19m66yvv0hnmyrmx2l4drbls0fcib75fxq2csdx6p8gd54bnrsh3"; }) (fetchNuGet { pname = "runtime.osx-x64.Microsoft.NETCore.DotNetHostPolicy"; version = "5.0.17"; sha256 = "0bcnlsxcrvhybcjbb9879njx0c4z76y7djx4643g1rpjnkcrj9ww"; }) (fetchNuGet { pname = "runtime.osx-x64.Microsoft.NETCore.DotNetHostResolver"; version = "5.0.17"; sha256 = "1bf95h2f0dmpmv7z7961zia5vaqvmjq3wkf6iil9jxv4z674624w"; }) (fetchNuGet { pname = "runtime.win-arm64.Microsoft.NETCore.DotNetAppHost"; version = "5.0.17"; sha256 = "02q593q09mwwh23m86048vc7b7an7pqch5nd86d4hxzkamnpnpsa"; }) (fetchNuGet { pname = "runtime.win-arm64.Microsoft.NETCore.DotNetHost"; version = "5.0.17"; sha256 = "16vzxywfj88gjcwfnmcb6b50ld8dp46i4pqiwwcy7yz15xgdhbm2"; }) (fetchNuGet { pname = "runtime.win-arm64.Microsoft.NETCore.DotNetHostPolicy"; version = "5.0.17"; sha256 = "1ix5lg2j5ihdfp9j3jdxc042g4syjzc4bafid465j52h6znsm6wm"; }) (fetchNuGet { pname = "runtime.win-arm64.Microsoft.NETCore.DotNetHostResolver"; version = "5.0.17"; sha256 = "0w30v8r26cg427n5glm9nz6r10baalkqq5icqqxkq71hmh8fsjqb"; }) (fetchNuGet { pname = "runtime.win-arm.Microsoft.NETCore.DotNetAppHost"; version = "5.0.17"; sha256 = "168iq4hdp6bhdpgqa1mir1bygmh2ggwkys1r82d6kpl2lzbxjy28"; }) (fetchNuGet { pname = "runtime.win-arm.Microsoft.NETCore.DotNetHost"; version = "5.0.17"; sha256 = "18jpw2wbrb1b941729lb7hiq4yfq2z53pcxwz4mpgawnr58y0562"; }) (fetchNuGet { pname = "runtime.win-arm.Microsoft.NETCore.DotNetHostPolicy"; version = "5.0.17"; sha256 = "0ig464fcsj2jr0p02f6slifwf1m0408g95npm0vccf5ww1nbgkpi"; }) (fetchNuGet { pname = "runtime.win-arm.Microsoft.NETCore.DotNetHostResolver"; version = "5.0.17"; sha256 = "0qj5avmjrvabxzimprg4m54k3p6zkwrhbpv0byc8c9gbi47s323j"; }) (fetchNuGet { pname = "runtime.win-x64.Microsoft.NETCore.DotNetAppHost"; version = "5.0.17"; sha256 = "05ghz164lpff7n8mrxs7jm2h8n3clsg4w953zrag3k5ry9j36m9c"; }) (fetchNuGet { pname = "runtime.win-x64.Microsoft.NETCore.DotNetHost"; version = "5.0.17"; sha256 = "0azgs542mbg69jlc81529i2z5m728w8sc2i9m5dx15hvxqqqcjiz"; }) (fetchNuGet { pname = "runtime.win-x64.Microsoft.NETCore.DotNetHostPolicy"; version = "5.0.17"; sha256 = "12n1kcgcv5z8hkvjqfk0n705kcipbai4sgcwiimi52xpaf34xw8m"; }) (fetchNuGet { pname = "runtime.win-x64.Microsoft.NETCore.DotNetHostResolver"; version = "5.0.17"; sha256 = "0b1s2m0a7xcdzfz22x6k7v5hkca90azdjk6pw7wwdnvszwq26nxp"; }) (fetchNuGet { pname = "runtime.win-x86.Microsoft.NETCore.DotNetAppHost"; version = "5.0.17"; sha256 = "1sjpq07swgj0isdgyh6p2yb254qb9781lv44xfhj6nz7mx2yhdh1"; }) (fetchNuGet { pname = "runtime.win-x86.Microsoft.NETCore.DotNetHost"; version = "5.0.17"; sha256 = "1gnzrqdp26d7pwwz29gm4qb09n2zsb767qkhbwkifcsyxlwi6m0f"; }) (fetchNuGet { pname = "runtime.win-x86.Microsoft.NETCore.DotNetHostPolicy"; version = "5.0.17"; sha256 = "089jww13gaf7x7yd9d3qkyx9iq8abcp3r147hd9nblh561c9bzbg"; }) (fetchNuGet { pname = "runtime.win-x86.Microsoft.NETCore.DotNetHostResolver"; version = "5.0.17"; sha256 = "1nycl1rayk0fhaakpj6q9rfp2lv3dpl7pziavmd9kcfryz952ff5"; }) ]; }; } </del>


Question:
Since May 10, .NET 5.0 is EOL (End Of Life), and should not be used. Should it be marked as EOF similar to dotnet 2.2 and 3.0? See All packages using dotnet 5.0 should be updated to use a newer, supported version. These packages still need updating: [x] - [x] - [x] - [x] pkgs/development/tools/build- - [x] -
There is at least one package, which currently uses dotnet 5 sdk - . So we will need to update it beforehand. Btw, I'm not sure if we have any policy regarding packages removal, for nixpkgs in general or specifically for it's dotnet part. , what do you think?
The package is also using .NET 5: . But this is because I made the PR upstream updating it from .NET 4 to 5. I suspect that the transition to 6 will be similarly easy.
I think we should just mark it as depricated, as many projects do still use it upstream. Dotnet version 3 is also still commonly used, so I dont expect it would be realistic to remove version 5 any time soon. also uses dotnet 5 by default, I'll go ahead and switch that over now. See . That doesnt mark dotnet 5 as deprecated or change anything from a SDK perspective, just some preperation work.
See as well, it adds a warning whenever dotnet version 5 is used. Not using a throw for now since a few packages depend on it and I dont have the time to clean that all up at the moment.
Can you provide a list of packages that need updating?
Based on a quick grep: pkgs/development/tools/build-
I believe that after all the above PRs are merged, we should be able to safely remove .NET 5 from nixpkgs :)

dotnet-sdk_7 = dotnetCorePackages.sdk_7_0; dotnet-runtime_3 = dotnetCorePackages.runtime_3_1; <del> dotnet-runtime_5 = dotnetCorePackages.runtime_5_0; </del> dotnet-runtime_6 = dotnetCorePackages.runtime_6_0; dotnet-runtime_7 = dotnetCorePackages.runtime_7_0; dotnet-aspnetcore_3 = dotnetCorePackages.aspnetcore_3_1; <del> dotnet-aspnetcore_5 = dotnetCorePackages.aspnetcore_5_0; </del> dotnet-aspnetcore_6 = dotnetCorePackages.aspnetcore_6_0; dotnet-aspnetcore_7 = dotnetCorePackages.aspnetcore_7_0;


Question: Shotwell can't build thumbnails for video files. package has an additional executable , which is broken. When run manually, it fails with this message:

sqlite webkitgtk gst_all_1.gstreamer <ins> gst_all_1.gst-libav </ins> gst_all_1.gst-plugins-base <ins> gst_all_1.gst-plugins-good </ins> libgee libgudev gexiv2


Question:
Project description  Selectdefaultapplication is a very simple GUI application that lets you define default applications on Linux in a sane way. Basically it just loads all installed applications by reading their .desktop files, reads the MimeType fields to see what it supports, and updates with what the user wants. Not all desktop environments provide such a tool, prompting for an agnostic tool. Metadata homepage URL: source URL: license: gpl2 platforms: linux Additional info: AUR package:
You can try using this in an overlay, use .
Seems to work!

githubId = 20391; name = "Nahum Shalman"; }; <ins> nsnelson = { email = "noah.snelson@protonmail.com"; github = "peeley"; githubId = 30942198; name = "Noah Snelson"; }; </ins> nthorne = { email = "notrupertthorne@gmail.com"; github = "nthorne";


Question:
Project description  Selectdefaultapplication is a very simple GUI application that lets you define default applications on Linux in a sane way. Basically it just loads all installed applications by reading their .desktop files, reads the MimeType fields to see what it supports, and updates with what the user wants. Not all desktop environments provide such a tool, prompting for an agnostic tool. Metadata homepage URL: source URL: license: gpl2 platforms: linux Additional info: AUR package:
You can try using this in an overlay, use .
Seems to work!

<ins> { stdenv, lib, fetchFromGitHub, qmake, qtbase, wrapQtAppsHook }: stdenv.mkDerivation { pname = "selectdefaultapplication"; version = "unstable-2021-08-12"; src = fetchFromGitHub { owner = "sandsmark"; repo = "selectdefaultapplication"; rev = "c752df6ba8caceeef54bcf6527f1bccc2ca8202a"; sha256 = "C/70xpt6RoQNIlAjSJhOCyheolK4Xp6RiSZmeqMP4fw="; }; nativeBuildInputs = [ qmake wrapQtAppsHook ]; buildInputs = [ qtbase ]; installPhase = '' runHook preInstall mkdir -p $out/bin cp selectdefaultapplication $out/bin install -Dm644 -t "$out/share/applications" selectdefaultapplication.desktop install -Dm644 -t "$out/share/icons/hicolor/48x48/apps" selectdefaultapplication.png runHook postInstall ''; meta = with lib; { description = "A very simple application that lets you define default applications on Linux in a sane way"; homepage = "https://github.com/sandsmark/selectdefaultapplication"; maintainers = with maintainers; [ nsnelson ]; license = licenses.gpl2; platforms = platforms.linux; }; } </ins>


Question:
Project description  Selectdefaultapplication is a very simple GUI application that lets you define default applications on Linux in a sane way. Basically it just loads all installed applications by reading their .desktop files, reads the MimeType fields to see what it supports, and updates with what the user wants. Not all desktop environments provide such a tool, prompting for an agnostic tool. Metadata homepage URL: source URL: license: gpl2 platforms: linux Additional info: AUR package:
You can try using this in an overlay, use .
Seems to work!

seexpr = callPackage ../development/compilers/seexpr { }; <ins> selectdefaultapplication = libsForQt5.callPackage ../applications/misc/selectdefaultapplication { }; </ins> semgrep = python3.pkgs.callPackage ../tools/security/semgrep { }; semgrep-core = callPackage ../tools/security/semgrep/semgrep-core.nix { };


Question:
I'm bringing up new RPis and their clocks are often wrong. Even though upstream systemd has given exceptions to be able to skip dnssec check for ntp sync, it doesn't... appear to be working. If I set the date manually, often by time I check timesyncd will have already taken care of kicking in and it reports that it's synced. Steps to reproduce the behavior: the clock badly. . and see if your DNS works
If I read it right, only works for systemd-resolved. One general workaround is to use hard-coded IP addresses for NTP (our routers actually do that IIRC).
That commit seems to indicate that it should bypass DNSSEC for timesyncd. This would get my clock back in sync, thus resolving DNSSEC errors for the rest of the system. But timesyncd isn't doing its job. I assume that's because: date wrong -dnssec failure. But maybe also fails if the clock is just too askew? I'll try to look more later, maybe I have to opt-in large corrections? Seems a bit weird to me. Or do we maybe use timesyncd in a non-standard way?
I ran into this on a Raspberry Pi 3B. I'm using systemd-networkd including systemd-resolved. At some point DNS started failing, and I noticed the system clock was out of sync by about 4 hours and not synchronizing anymore. The log of systemd-resolved was full of DNSSEC s: I'm not sure what changed, because I was able to install NixOS just fine. It also was offline before for some time without this problem happening (as far as I noticed at least), and it started happening after it was online for some time without break. Also, the systemd-native workaround should be working on NixOS as well, I can't find anything that indicates a non-standard setup that might overwrite tha workaround. Checking is the standard original systemd unit file that includes the relevant line and as far as I can see it isn't overridden. I also checked and it includes . For now, I worked around the issue by specifying my NTP servers by IP (I used the ones by the ).
Closing as this should be fixed by Please reopen if this is still an issue.

wantedBy = [ "sysinit.target" ]; aliases = [ "dbus-org.freedesktop.timesync1.service" ]; restartTriggers = [ config.environment.etc."systemd/timesyncd.conf".source ]; <ins> # systemd-timesyncd disables DNSSEC validation in the nss-resolve module by setting SYSTEMD_NSS_RESOLVE_VALIDATE to 0 in the unit file. # This is required in order to solve the chicken-and-egg problem when DNSSEC validation needs the correct time to work, but to set the # correct time, we need to connect to an NTP server, which usually requires resolving its hostname. # In order for nss-resolve to be able to read this environment variable we patch systemd-timesyncd to disable NSCD and use NSS modules directly. # This means that systemd-timesyncd needs to have NSS modules path in LD_LIBRARY_PATH. When systemd-resolved is disabled we still need to set # NSS module path so that systemd-timesyncd keeps using other NSS modules that are configured in the system. environment.LD_LIBRARY_PATH = config.system.nssModules.path; </ins> preStart = ( # Ensure that we have some stored time to prevent


Question:
I'm bringing up new RPis and their clocks are often wrong. Even though upstream systemd has given exceptions to be able to skip dnssec check for ntp sync, it doesn't... appear to be working. If I set the date manually, often by time I check timesyncd will have already taken care of kicking in and it reports that it's synced. Steps to reproduce the behavior: the clock badly. . and see if your DNS works
If I read it right, only works for systemd-resolved. One general workaround is to use hard-coded IP addresses for NTP (our routers actually do that IIRC).
That commit seems to indicate that it should bypass DNSSEC for timesyncd. This would get my clock back in sync, thus resolving DNSSEC errors for the rest of the system. But timesyncd isn't doing its job. I assume that's because: date wrong -dnssec failure. But maybe also fails if the clock is just too askew? I'll try to look more later, maybe I have to opt-in large corrections? Seems a bit weird to me. Or do we maybe use timesyncd in a non-standard way?
I ran into this on a Raspberry Pi 3B. I'm using systemd-networkd including systemd-resolved. At some point DNS started failing, and I noticed the system clock was out of sync by about 4 hours and not synchronizing anymore. The log of systemd-resolved was full of DNSSEC s: I'm not sure what changed, because I was able to install NixOS just fine. It also was offline before for some time without this problem happening (as far as I noticed at least), and it started happening after it was online for some time without break. Also, the systemd-native workaround should be working on NixOS as well, I can't find anything that indicates a non-standard setup that might overwrite tha workaround. Checking is the standard original systemd unit file that includes the relevant line and as far as I can see it isn't overridden. I also checked and it includes . For now, I worked around the issue by specifying my NTP servers by IP (I used the ones by the ).
Closing as this should be fixed by Please reopen if this is still an issue.

systemd-shutdown = handleTest ./systemd-shutdown.nix {}; systemd-sysupdate = runTest ./systemd-sysupdate.nix; systemd-timesyncd = handleTest ./systemd-timesyncd.nix {}; <ins> systemd-timesyncd-nscd-dnssec = handleTest ./systemd-timesyncd-nscd-dnssec.nix {}; </ins> systemd-user-tmpfiles-rules = handleTest ./systemd-user-tmpfiles-rules.nix {}; systemd-misc = handleTest ./systemd-misc.nix {}; systemd-userdbd = handleTest ./systemd-userdbd.nix {};


Question:
I'm bringing up new RPis and their clocks are often wrong. Even though upstream systemd has given exceptions to be able to skip dnssec check for ntp sync, it doesn't... appear to be working. If I set the date manually, often by time I check timesyncd will have already taken care of kicking in and it reports that it's synced. Steps to reproduce the behavior: the clock badly. . and see if your DNS works
If I read it right, only works for systemd-resolved. One general workaround is to use hard-coded IP addresses for NTP (our routers actually do that IIRC).
That commit seems to indicate that it should bypass DNSSEC for timesyncd. This would get my clock back in sync, thus resolving DNSSEC errors for the rest of the system. But timesyncd isn't doing its job. I assume that's because: date wrong -dnssec failure. But maybe also fails if the clock is just too askew? I'll try to look more later, maybe I have to opt-in large corrections? Seems a bit weird to me. Or do we maybe use timesyncd in a non-standard way?
I ran into this on a Raspberry Pi 3B. I'm using systemd-networkd including systemd-resolved. At some point DNS started failing, and I noticed the system clock was out of sync by about 4 hours and not synchronizing anymore. The log of systemd-resolved was full of DNSSEC s: I'm not sure what changed, because I was able to install NixOS just fine. It also was offline before for some time without this problem happening (as far as I noticed at least), and it started happening after it was online for some time without break. Also, the systemd-native workaround should be working on NixOS as well, I can't find anything that indicates a non-standard setup that might overwrite tha workaround. Checking is the standard original systemd unit file that includes the relevant line and as far as I can see it isn't overridden. I also checked and it includes . For now, I worked around the issue by specifying my NTP servers by IP (I used the ones by the ).
Closing as this should be fixed by Please reopen if this is still an issue.

<ins> # This test verifies that systemd-timesyncd can resolve the NTP server hostname when DNSSEC validation # fails even though it is enforced in the systemd-resolved settings. It is required in order to solve # the chicken-and-egg problem when DNSSEC validation needs the correct time to work, but to set the # correct time, we need to connect to an NTP server, which usually requires resolving its hostname. # # This test does the following: # - Sets up a DNS server (tinydns) listening on the eth1 ip addess, serving .ntp and fake.ntp records. # - Configures that DNS server as a resolver and enables DNSSEC in systemd-resolved settings. # - Configures systemd-timesyncd to use fake.ntp hostname as an NTP server. # - Performs a regular DNS lookup, to ensure it fails due to broken DNSSEC. # - Waits until systemd-timesyncd resolves fake.ntp by checking its debug output. #   Here, we don't expect systemd-timesyncd to connect and synchronize time because there is no NTP #   server running. For this test to succeed, we only need to ensure that systemd-timesyncd #   resolves the IP address of the fake.ntp host. import ./make-test-python.nix ({ pkgs, ... }: let ntpHostname = "fake.ntp"; ntpIP = "192.0.2.1"; in { name = "systemd-timesyncd"; nodes.machine = { pkgs, lib, config, ... }: let eth1IP = (lib.head config.networking.interfaces.eth1.ipv4.addresses).address; in { # Setup a local DNS server for the NTP domain on the eth1 IP address services.tinydns = { enable = true; ip = eth1IP; data = '' .ntp:${eth1IP} +.${ntpHostname}:${ntpIP} ''; }; # Enable systemd-resolved with DNSSEC and use the local DNS as a name server services.resolved.enable = true; services.resolved.dnssec = "true"; networking.nameservers = [ eth1IP ]; # Configure systemd-timesyncd to use our NTP hostname services.timesyncd.enable = lib.mkForce true; services.timesyncd.servers = [ ntpHostname ]; services.timesyncd.extraConfig = '' FallbackNTP=${ntpHostname} ''; # The debug output is necessary to determine whether systemd-timesyncd successfully resolves our NTP hostname or not systemd.services.systemd-timesyncd.environment.SYSTEMD_LOG_LEVEL = "debug"; }; testScript = '' machine.wait_for_unit("tinydns.service") machine.wait_for_unit("systemd-timesyncd.service") machine.fail("resolvectl query ${ntpHostname}") machine.wait_until_succeeds("journalctl -u systemd-timesyncd.service --grep='Resolved address ${ntpIP}:123 for ${ntpHostname}'") ''; }) </ins>


Question:
I'm bringing up new RPis and their clocks are often wrong. Even though upstream systemd has given exceptions to be able to skip dnssec check for ntp sync, it doesn't... appear to be working. If I set the date manually, often by time I check timesyncd will have already taken care of kicking in and it reports that it's synced. Steps to reproduce the behavior: the clock badly. . and see if your DNS works
If I read it right, only works for systemd-resolved. One general workaround is to use hard-coded IP addresses for NTP (our routers actually do that IIRC).
That commit seems to indicate that it should bypass DNSSEC for timesyncd. This would get my clock back in sync, thus resolving DNSSEC errors for the rest of the system. But timesyncd isn't doing its job. I assume that's because: date wrong -dnssec failure. But maybe also fails if the clock is just too askew? I'll try to look more later, maybe I have to opt-in large corrections? Seems a bit weird to me. Or do we maybe use timesyncd in a non-standard way?
I ran into this on a Raspberry Pi 3B. I'm using systemd-networkd including systemd-resolved. At some point DNS started failing, and I noticed the system clock was out of sync by about 4 hours and not synchronizing anymore. The log of systemd-resolved was full of DNSSEC s: I'm not sure what changed, because I was able to install NixOS just fine. It also was offline before for some time without this problem happening (as far as I noticed at least), and it started happening after it was online for some time without break. Also, the systemd-native workaround should be working on NixOS as well, I can't find anything that indicates a non-standard setup that might overwrite tha workaround. Checking is the standard original systemd unit file that includes the relevant line and as far as I can see it isn't overridden. I also checked and it includes . For now, I worked around the issue by specifying my NTP servers by IP (I used the ones by the ).
Closing as this should be fixed by Please reopen if this is still an issue.

<ins> From 7a27556920fe1feefd17096841c8f3ca1294a1b3 Mon Sep 17 00:00:00 2001 From: Yuri Nesterov <yuriy.nesterov@unikie.com> Date: Wed, 21 Jun 2023 17:17:38 +0300 Subject: [PATCH] timesyncd: disable NSCD when DNSSEC validation is disabled Systemd-timesyncd sets SYSTEMD_NSS_RESOLVE_VALIDATE=0 in the unit file to disable DNSSEC validation but it doesn't work when NSCD is used in the system. This patch disabes NSCD in systemd-timesyncd when SYSTEMD_NSS_RESOLVE_VALIDATE is set to 0 so that it uses NSS libraries directly. --- src/timesync/timesyncd.c | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/src/timesync/timesyncd.c b/src/timesync/timesyncd.c index 1d8ebecc91..2b0ae361ff 100644 --- a/src/timesync/timesyncd.c +++ b/src/timesync/timesyncd.c @@ -21,6 +21,11 @@ #include "timesyncd-conf.h" #include "timesyncd-manager.h" #include "user-util.h" +#include "env-util.h" + +struct traced_file; +extern void __nss_disable_nscd(void (*)(size_t, struct traced_file *)); +static void register_traced_file(size_t dbidx, struct traced_file *finfo) {} static int advance_tstamp(int fd, const struct stat *st) { assert_se(fd >= 0); @@ -198,6 +203,12 @@ static int run(int argc, char *argv[]) { if (r < 0) return log_error_errno(r, "Failed to parse fallback server strings: %m"); +        r = getenv_bool_secure("SYSTEMD_NSS_RESOLVE_VALIDATE"); +        if (r == 0) { +                log_info("Disabling NSCD because DNSSEC validation is turned off"); +                __nss_disable_nscd(register_traced_file); +        } + log_debug("systemd-timesyncd running as pid " PID_FMT, getpid_cached()); notify_message = notify_start("READY=1n" -- 2.34.1 </ins>


Question:
I'm bringing up new RPis and their clocks are often wrong. Even though upstream systemd has given exceptions to be able to skip dnssec check for ntp sync, it doesn't... appear to be working. If I set the date manually, often by time I check timesyncd will have already taken care of kicking in and it reports that it's synced. Steps to reproduce the behavior: the clock badly. . and see if your DNS works
If I read it right, only works for systemd-resolved. One general workaround is to use hard-coded IP addresses for NTP (our routers actually do that IIRC).
That commit seems to indicate that it should bypass DNSSEC for timesyncd. This would get my clock back in sync, thus resolving DNSSEC errors for the rest of the system. But timesyncd isn't doing its job. I assume that's because: date wrong -dnssec failure. But maybe also fails if the clock is just too askew? I'll try to look more later, maybe I have to opt-in large corrections? Seems a bit weird to me. Or do we maybe use timesyncd in a non-standard way?
I ran into this on a Raspberry Pi 3B. I'm using systemd-networkd including systemd-resolved. At some point DNS started failing, and I noticed the system clock was out of sync by about 4 hours and not synchronizing anymore. The log of systemd-resolved was full of DNSSEC s: I'm not sure what changed, because I was able to install NixOS just fine. It also was offline before for some time without this problem happening (as far as I noticed at least), and it started happening after it was online for some time without break. Also, the systemd-native workaround should be working on NixOS as well, I can't find anything that indicates a non-standard setup that might overwrite tha workaround. Checking is the standard original systemd unit file that includes the relevant line and as far as I can see it isn't overridden. I also checked and it includes . For now, I worked around the issue by specifying my NTP servers by IP (I used the ones by the ).
Closing as this should be fixed by Please reopen if this is still an issue.

./0017-core-don-t-taint-on-unmerged-usr.patch ./0018-tpm2_context_init-fix-driver-name-checking.patch ./0019-systemctl-edit-suggest-systemdctl-edit-runtime-on-sy.patch <ins> ./0020-timesyncd-disable-NSCD-when-DNSSEC-validation-is-dis.patch </ins> ] ++ lib.optional stdenv.hostPlatform.isMusl ( let oe-core = fetchzip {


Question:
<!-- Note that these are hard requirements --<!-- You can use the "Go to file" functionality on GitHub to find the package Then you can go to the history for this package Find the latest "packagename: oldversion -newversion" commit The "newversion" is the current version of the package --- <!-- 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! --- name: syncthingtray <!-- The current version can be found easily with the same process as above for checking the master branch If an open PR is present for the package, take this version as the current one and link to the PR --current version: 1.1.3 desired version: 1.1.20 <!-- Search your package here: If no maintainer is listed for your package, tag the person that last updated the package --maintainers: Please tag this issue in your PR.
There's a new dependency now needed for syncthingtray - but there's a problem in the logic upstream here: Here's my packaging attempt:

, extra-cmake-modules , cpp-utilities , qtutilities <ins> , qtforkawesome , boost </ins> , cmake , kio , plasma-framework


Question:
<!-- Note that these are hard requirements --<!-- You can use the "Go to file" functionality on GitHub to find the package Then you can go to the history for this package Find the latest "packagename: oldversion -newversion" commit The "newversion" is the current version of the package --- <!-- 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! --- name: syncthingtray <!-- The current version can be found easily with the same process as above for checking the master branch If an open PR is present for the package, take this version as the current one and link to the PR --current version: 1.1.3 desired version: 1.1.20 <!-- Search your package here: If no maintainer is listed for your package, tag the person that last updated the package --maintainers: Please tag this issue in your PR.
There's a new dependency now needed for syncthingtray - but there's a problem in the logic upstream here: Here's my packaging attempt:

}: mkDerivation rec { <del> version = "1.1.3"; </del> <ins> version = "1.1.20"; </ins> pname = "syncthingtray"; src = fetchFromGitHub { owner = "Martchus"; repo = "syncthingtray"; rev = "v${version}"; <del> sha256 = "sha256-ovit2XSkxSjcbpqQUv8IzMqfsfItbtXLbx0/Vy0+J0Y="; </del> <ins> sha256 = "sha256-T0ddAROwVSh+IKGZZNDMC7YB2IfQZal2pAQ5ArirtjI="; </ins> }; <del> buildInputs = [ qtbase cpp-utilities qtutilities ] </del> <ins> buildInputs = [ qtbase cpp-utilities qtutilities boost qtforkawesome ] </ins> ++ lib.optionals webviewSupport [ qtwebengine ] ++ lib.optionals jsSupport [ qtdeclarative ] ++ lib.optionals kioPluginSupport [ kio ]


Question:
<!-- Note that these are hard requirements --<!-- You can use the "Go to file" functionality on GitHub to find the package Then you can go to the history for this package Find the latest "packagename: oldversion -newversion" commit The "newversion" is the current version of the package --- <!-- 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! --- name: syncthingtray <!-- The current version can be found easily with the same process as above for checking the master branch If an open PR is present for the package, take this version as the current one and link to the PR --current version: 1.1.3 desired version: 1.1.20 <!-- Search your package here: If no maintainer is listed for your package, tag the person that last updated the package --maintainers: Please tag this issue in your PR.
There's a new dependency now needed for syncthingtray - but there's a problem in the logic upstream here: Here's my packaging attempt:

<ins> { stdenv , lib , fetchFromGitHub , cpp-utilities , qtutilities , qttools , qtbase , cmake , perl }: let fork_awesome_release = fetchFromGitHub { owner = "ForkAwesome"; repo = "Fork-Awesome"; rev = "1.2.0"; sha256 = "sha256-zG6/0dWjU7/y/oDZuSEv+54Mchng64LVyV8bluskYzc="; }; in stdenv.mkDerivation rec { pname = "qtforkawesome"; version = "0.0.4"; src = fetchFromGitHub { owner = "Martchus"; repo = pname; rev = "v${version}"; sha256 = "sha256-J3F+ikz6gQqV+JsOX8EpMOWoTmI6UK5KndFALUo4oiU="; }; buildInputs = [ qtbase cpp-utilities qtutilities ]; nativeBuildInputs = [ cmake qttools perl perl.pkgs.YAML ]; cmakeFlags = [ "-DFORK_AWESOME_FONT_FILE=${fork_awesome_release}/fonts/forkawesome-webfont.woff2" "-DFORK_AWESOME_ICON_DEFINITIONS=${fork_awesome_release}/src/icons/icons.yml" ]; dontWrapQtApps = true; meta = with lib; { homepage = "https://github.com/Martchus/qtforkawesome"; description = "Library that bundles ForkAwesome for use within Qt applications"; license = licenses.gpl2Plus; maintainers = with maintainers; [ doronbehar ]; platforms   = platforms.linux; }; } </ins>


Question:
<!-- Note that these are hard requirements --<!-- You can use the "Go to file" functionality on GitHub to find the package Then you can go to the history for this package Find the latest "packagename: oldversion -newversion" commit The "newversion" is the current version of the package --- <!-- 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! --- name: syncthingtray <!-- The current version can be found easily with the same process as above for checking the master branch If an open PR is present for the package, take this version as the current one and link to the PR --current version: 1.1.3 desired version: 1.1.20 <!-- Search your package here: If no maintainer is listed for your package, tag the person that last updated the package --maintainers: Please tag this issue in your PR.
There's a new dependency now needed for syncthingtray - but there's a problem in the logic upstream here: Here's my packaging attempt:

qtfeedback = callPackage ../development/libraries/qtfeedback { }; <ins> qtforkawesome = callPackage ../development/libraries/qtforkawesome { }; </ins> qtutilities = callPackage ../development/libraries/qtutilities { }; qtinstaller = callPackage ../development/libraries/qtinstaller { };


Question:
The file generated for nixos is not compatible with the R programming language's interpreter (). On startup, the R interpreter prints the following warning (though it does continue as normal after printing the warning): This could be resolved by adding a trailing newline to . Steps to reproduce the behavior: the R interpreter by running , or if you don't have R installed. No error message should be printed. I'm not entirely sure whether this should be resolved adding the trailing newline to , or whether R should be modified so it doesn't assume a trailing newline. The man page for describes the format of the file as "a newline-separated list of environment-like shell-compatible variable assignments". The existing format (no trailing newline) is indeed newline-separated and shell-compatible (bash and zsh both have no problems with it), so maybe I should bring this up with the R folks instead? On the other hand, all the other distros I've checked (ubuntu, archlinux, and alpine) include a trailing newline, so maybe we should just stick to what they're doing? The fix is trivial: Let me know what you think, and I'd be happy to open a PR wherever we decide the fix should be made. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --
This! It shouldn’t be needed and yet here we are. No harm in doing so that though, so I’m all for this. Sounds great!

attrsToText = attrs: concatStringsSep "n" ( mapAttrsToList (n: v: ''${n}=${escapeIfNeccessary (toString v)}'') attrs <del> ); </del> <ins> ) + "n"; </ins> osReleaseContents = { NAME = "NixOS";


Question:
The Zen kernel is failing to build for me since the update to 5.18, and so I thought I'd open an issue since I can't seem to find any existing info about it. Bisected to system: host os: multi-user?: sandbox: version: channels(root): channels(alex): nixpkgs:
Looks like it didn't build even in the CI of : But, we already have a new version: Cc (since you're always the one to bump it)
Unfortunately 5.18.1 doesn't seem to build either for me. :( Given that the file in question hasn't been touched in months, I'm wondering if this has something to do with the move to C11 for the 5.18 kernel. But that's just a guess. I can think of two possible quick solutions: Include a patch that adds a comment Ignore that warning everywhere in the kernel
Staging recently got change to avoid Werror-style failures.
Given that that change will take a bit to get to master, do you think it would make sense to set for just the zen kernel in the meantime? Or even just revert and move it to staging so that it gets merged when the change does? I'm asking because—while it's not too much trouble to add patches to my personal NixOS configuration—right now the zen kernel is broken for everyone, and so it might be a good idea to get it back to a working state in the meantime. I'm not sure how many people use the zen kernel though, it seems to be not very many, and so if it's better to just leave it as-is for a bit that's fine too; I don't really know how such things are usually handled in nixpkgs and am trying to learn. :)
I'd say setting for zen kernel is perfectly fine. Should be a matter of adding it to Do you want to give it a try and propose a PR? AFAIU you already run that kernel version and have a chance to validate it if still boots. You could also add a TODO to remove it once staging is merged.
should've gone to master and/or be merged with the next kernel bump or something if the rebuilds were that critical which I don't think they are. We could cherry-pick it if we need it now.
I made , but it's late here so I don't have time to test it properly and am waiting to open a PR until I can do so. It at least builds though. I figured while I was at it I should also bump the version to 5.18.1-zen1, but in hindsight maybe I should wait until the mainline kernel is updated to 5.18.1 in nixpkgs? Anyway, I'll test it when I have time tomorrow evening, make any necessary changes, and open a PR, unless we decide to cherry-pick ? That seems like a nicer solution to me personally, but I don't really have a strong preference.
I finally got around to testing this and opened a PR: :). I'm personally in favor of cherry-picking , though.

let # having the full version string here makes it easier to update <del> modDirVersion = "5.18.0-zen1"; </del> <ins> modDirVersion = "5.18.1-zen1"; </ins> parts = lib.splitString "-" modDirVersion; version = lib.elemAt parts 0; suffix = lib.elemAt parts 1;


Question:
The Zen kernel is failing to build for me since the update to 5.18, and so I thought I'd open an issue since I can't seem to find any existing info about it. Bisected to system: host os: multi-user?: sandbox: version: channels(root): channels(alex): nixpkgs:
Looks like it didn't build even in the CI of : But, we already have a new version: Cc (since you're always the one to bump it)
Unfortunately 5.18.1 doesn't seem to build either for me. :( Given that the file in question hasn't been touched in months, I'm wondering if this has something to do with the move to C11 for the 5.18 kernel. But that's just a guess. I can think of two possible quick solutions: Include a patch that adds a comment Ignore that warning everywhere in the kernel
Staging recently got change to avoid Werror-style failures.
Given that that change will take a bit to get to master, do you think it would make sense to set for just the zen kernel in the meantime? Or even just revert and move it to staging so that it gets merged when the change does? I'm asking because—while it's not too much trouble to add patches to my personal NixOS configuration—right now the zen kernel is broken for everyone, and so it might be a good idea to get it back to a working state in the meantime. I'm not sure how many people use the zen kernel though, it seems to be not very many, and so if it's better to just leave it as-is for a bit that's fine too; I don't really know how such things are usually handled in nixpkgs and am trying to learn. :)
I'd say setting for zen kernel is perfectly fine. Should be a matter of adding it to Do you want to give it a try and propose a PR? AFAIU you already run that kernel version and have a chance to validate it if still boots. You could also add a TODO to remove it once staging is merged.
should've gone to master and/or be merged with the next kernel bump or something if the rebuilds were that critical which I don't think they are. We could cherry-pick it if we need it now.
I made , but it's late here so I don't have time to test it properly and am waiting to open a PR until I can do so. It at least builds though. I figured while I was at it I should also bump the version to 5.18.1-zen1, but in hindsight maybe I should wait until the mainline kernel is updated to 5.18.1 in nixpkgs? Anyway, I'll test it when I have time tomorrow evening, make any necessary changes, and open a PR, unless we decide to cherry-pick ? That seems like a nicer solution to me personally, but I don't really have a strong preference.
I finally got around to testing this and opened a PR: :). I'm personally in favor of cherry-picking , though.

owner = "zen-kernel"; repo = "zen-kernel"; inherit rev; <del> sha256 = "sha256-A0QrY1REbRODnHtmyNqVaiLhDgYCECevfHZCxtoQ9kU="; </del> <ins> sha256 = "sha256-LCLfLE85NifuskYl2dxLOJEsUNHLegF8ecYyU4xOCtY="; </ins> }; structuredExtraConfig = with lib.kernel; { ZEN_INTERACTIVE = yes; <ins> # TODO: Remove once #175433 reaches master # https://nixpk.gs/pr-tracker.html?pr=175433 WERROR = no; </ins> }; extraMeta = {


Question:
I setup the server quite a while ago. I recognized that the service is not running. As I normally do auto update I saw that the process failed as the configuration changed. After rebuild + switch the service fails to start: Steps to reproduce the behavior: Service be able to start. I tried to 1) chmod +w -still fails and permissions are somehow adjusted 2) delete -file is created, startup still fails
Digged a little bit deeper: The error is thrown by the pre-start script. It seems that my installation is missing the which causes some gitea command to generate it and write it into . Which fails as the file is set to non writable by the pre-start script.

function gitea_setup { cp -f ${configFile} ${runConfig} <del> if [ ! -e ${secretKey} ]; then </del> <ins> if [ ! -s ${secretKey} ]; then </ins> ${gitea}/bin/gitea generate secret SECRET_KEY > ${secretKey} fi # Migrate LFS_JWT_SECRET filename <del> if [[ -e ${oldLfsJwtSecret} && ! -e ${lfsJwtSecret} ]]; then </del> <ins> if [[ -s ${oldLfsJwtSecret} && ! -s ${lfsJwtSecret} ]]; then </ins> mv ${oldLfsJwtSecret} ${lfsJwtSecret} fi <del> if [ ! -e ${oauth2JwtSecret} ]; then </del> <ins> if [ ! -s ${oauth2JwtSecret} ]; then </ins> ${gitea}/bin/gitea generate secret JWT_SECRET > ${oauth2JwtSecret} fi <del> if [ ! -e ${lfsJwtSecret} ]; then </del> <ins> if [ ! -s ${lfsJwtSecret} ]; then </ins> ${gitea}/bin/gitea generate secret LFS_JWT_SECRET > ${lfsJwtSecret} fi <del> if [ ! -e ${internalToken} ]; then </del> <ins> if [ ! -s ${internalToken} ]; then </ins> ${gitea}/bin/gitea generate secret INTERNAL_TOKEN > ${internalToken} fi


Question:
I've been using PipeWire+JACK with until now. I'd like to switch to , but the service crashes at startup. The key error in the logs seems to be: . The result is that : (1) I have no sound, (2) I see no volume control knob in GNOME, (3) I see no devices appear in or any other JACK patchbay tools. Here's (hopefully) all relevant build configuration: Here are some logs: It seems others haven't run into this. What could I be doing wrong? Steps to reproduce the behavior: the above build configuration in the computer the above-written commands to view relevant logs I expect to the service to start, and to have sound.
Do you need a systemwide setup? That seems to be the issue here.
My use case is: I use virtual machines that run as another user (for security), but I want them to have sound. Using allows this, and it's the only (secure) solution I'm aware of.
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Thanks for this patch. I was finally able to test it. Unfortunately, I still have the issue. Your patch removed the "" error, but the wireplumber service still fails to start. Here's some evidence that your patch is applied: Here's the failure output/logs: According to the "" shouldn't be a problem because wireplumber shouldn't require X11. Looking more broadly at logs, there's this:
There have been some dbus related fixes in Wireplumber master, can you try that?
: I don't know how to cherry-pick from wireplumber; I only recently learned to cherry pick your pull request. I suppose I can wait until the next release. Maybe I should open this as an issue against wireplumber? Also, this crash only occurs with . Can you offer insight into what this means, so I can best phrase my question? I think the pipewire socket moves to a different what else? Does pipewire and/or wireplumber run as a different user? Anything else?
should get this fixed for good.
Also, if you don't know what does, you should probably disable it, as it's not a well supported configuration.

] ++ lib.optional config.security.rtkit.enable "rtkit"; description = "Pipewire system service user"; isSystemUser = true; <ins> home = "/var/lib/pipewire"; createHome = true; </ins> }; groups.pipewire.gid = config.ids.gids.pipewire; };


Question:
Fonts are missing, square characters are displayed ! Steps to reproduce the behavior: vmware-workstation vmware workstation or player I started a discussion on <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --/cc
I can reproduce this, probably related to some missing font in freshly installed systems
I launched vmware with FC_DEBUG=8, but I'm not able to interpret these errors messages, hope this can help
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
I found reason for missing fonts, it just loads from instead of system path and vmware's config points to wrong FHS paths, removing file fixes it, i will make a PR with fix, thanks.
I confirm that deleting fixes the issue. Thanks a lot !

cp -r $unpacked/sbin/* $out/bin/ cp -r $unpacked/lib/libconf $out/lib/vmware/ <ins> rm $out/lib/vmware/libconf/etc/fonts/fonts.conf </ins> cp -r $unpacked/lib/bin $out/lib/vmware/ cp -r $unpacked/lib/lib $out/lib/vmware/ cp -r $unpacked/lib/scripts $out/lib/vmware/


Question:
Building fails when rebuilding system configuration. System configuration should build successfully with on kernel 5.18 There are no current maintainers. This appears to be a repetition of
Arch Linux appears to have a new patch here: Attempting to apply it has failed for me. I tried this block: Maybe someone who helped solve this the last time can comment?
Already have a PR up .
Looks like an issue with the patch for 5.17. Try replacing it with this one:
This issue has been mentioned on NixOS Discourse. There might be relevant details there:

./linux-5.6.patch # source: https://gist.github.com/joanbm/5c640ac074d27fd1d82c74a5b67a1290 ./linux-5.9.patch <del> # source: https://github.com/archlinux/svntogit-community/blob/5ec5b248976f84fcd7e3d7fae49ee91289912d12/trunk/012-linux517.patch </del> <ins> # source: https://github.com/archlinux/svntogit-community/blob/33b4bd2b9e30679b03f5d7aa2741911d914dcf94/trunk/012-linux517.patch </ins> ./linux-5.17.patch <ins> # source: https://github.com/archlinux/svntogit-community/blob/2e1fd240f9ce06f500feeaa3e4a9675e65e6b967/trunk/013-linux518.patch ./linux-5.18.patch ./pedantic-fix.patch </ins> ./null-pointer-fix.patch ./gcc.patch ];


Question:
Building fails when rebuilding system configuration. System configuration should build successfully with on kernel 5.18 There are no current maintainers. This appears to be a repetition of
Arch Linux appears to have a new patch here: Attempting to apply it has failed for me. I tried this block: Maybe someone who helped solve this the last time can comment?
Already have a PR up .
Looks like an issue with the patch for 5.17. Try replacing it with this one:
This issue has been mentioned on NixOS Discourse. There might be relevant details there:

<del> diff -u -r a/src/wl/sys/wl_linux.c b/src/wl/sys/wl_linux.c --- a/src/wl/sys/wl_linux.c	2022-03-23 00:35:42.930416350 +0000 +++ b/src/wl/sys/wl_linux.c	2022-03-23 00:40:12.903771013 +0000 @@ -2980,7 +2980,11 @@ </del> <ins> From 31b7849092c43805c7fbaf7518b99874aa1b310c Mon Sep 17 00:00:00 2001 From: Joan Bruguera <joanbrugueram@gmail.com> Date: Wed, 12 Jan 2022 20:49:20 +0100 Subject: [PATCH] Tentative fix for broadcom-wl 6.30.223.271 driver for Linux 5.17-rc1 Set netdev->dev_addr through dev_addr_mod + PDE_DATA fix Since Linux 5.17 netdev->dev_addr is const and must be changed through dev_addr_mod, otherwise a warning is logged in dmesg and bad things may happen. NB: The #if is not wrong, dev_addr_mod is defined since Linux 5.15-rc1 Plus a trivial fix for PDE_DATA. Applies on top of all the patches applied to broadcom-wl-dkms 6.30.223.271-28 on Arch Linux. See also: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=adeef3e32146a8d2a73c399dc6f5d76a449131b1 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=359745d78351c6f5442435f81549f0207ece28aa --- src/wl/sys/wl_linux.c | 16 +++++++++++++--- 1 file changed, 13 insertions(+), 3 deletions(-) diff --git a/src/wl/sys/wl_linux.c b/src/wl/sys/wl_linux.c index e491df7..e4614fb 100644 --- a/src/wl/sys/wl_linux.c +++ b/src/wl/sys/wl_linux.c @@ -93,6 +93,10 @@ struct iw_statistics *wl_get_wireless_stats(struct net_device *dev); #include <wlc_wowl.h> +#if (LINUX_VERSION_CODE >= KERNEL_VERSION(5, 17, 0)) +#define PDE_DATA pde_data +#endif + #if LINUX_VERSION_CODE >= KERNEL_VERSION(4, 15, 0) static void wl_timer(struct timer_list *tl); #else @@ -490,6 +494,12 @@ wl_if_setup(struct net_device *dev) #endif } +#if LINUX_VERSION_CODE < KERNEL_VERSION(5, 15, 0) +static inline void eth_hw_addr_set(struct net_device *dev, const void *addr) { +	memcpy(dev->dev_addr, addr, ETHER_ADDR_LEN); +} +#endif + static wl_info_t * wl_attach(uint16 vendor, uint16 device, ulong regs, uint bustype, void *btparam, uint irq, uchar* bar1_addr, uint32 bar1_size) @@ -634,7 +644,7 @@ wl_attach(uint16 vendor, uint16 device, ulong regs, WL_ERROR(("wl%d: Error setting MAC ADDRESSn", unit)); } #endif -	bcopy(&wl->pub->cur_etheraddr, dev->dev_addr, ETHER_ADDR_LEN); +	eth_hw_addr_set(dev, wl->pub->cur_etheraddr.octet); online_cpus = 1; @@ -1835,7 +1845,7 @@ wl_set_mac_address(struct net_device *dev, void *addr) WL_LOCK(wl); -	bcopy(sa->sa_data, dev->dev_addr, ETHER_ADDR_LEN); +	eth_hw_addr_set(dev, sa->sa_data); err = wlc_iovar_op(wl->wlc, "cur_etheraddr", NULL, 0, sa->sa_data, ETHER_ADDR_LEN, IOV_SET, (WL_DEV_IF(dev))->wlcif); WL_UNLOCK(wl); @@ -3010,7 +3020,7 @@ _wl_add_monitor_if(wl_task_t *task) </ins> else dev->type = ARPHRD_IEEE80211_RADIOTAP; <del> +#if LINUX_VERSION_CODE < KERNEL_VERSION(5, 17, 0) bcopy(wl->dev->dev_addr, dev->dev_addr, ETHER_ADDR_LEN); +#else +	eth_hw_addr_set(wl->dev, dev->dev_addr); +#endif </del> <ins> -	bcopy(wl->dev->dev_addr, dev->dev_addr, ETHER_ADDR_LEN); +	eth_hw_addr_set(dev, wl->dev->dev_addr); </ins> #if defined(WL_USE_NETDEV_OPS) dev->netdev_ops = &wl_netdev_monitor_ops; <del> @@ -3261,7 +3265,11 @@ static ssize_t wl_proc_read(struct file *filp, char __user *buffer, size_t length, loff_t *offp) { +#if LINUX_VERSION_CODE < KERNEL_VERSION(5, 17, 0) wl_info_t * wl = PDE_DATA(file_inode(filp)); +#else +	wl_info_t * wl = pde_data(file_inode(filp)); +#endif #endif int bcmerror, len; int to_user = 0; @@ -3318,7 +3326,11 @@ static ssize_t wl_proc_write(struct file *filp, const char __user *buff, size_t length, loff_t *offp) { +#if LINUX_VERSION_CODE < KERNEL_VERSION(5, 17, 0) wl_info_t * wl = PDE_DATA(file_inode(filp)); +#else +	wl_info_t * wl = pde_data(file_inode(filp)); +#endif #endif int from_user = 0; int bcmerror; </del> <ins> -- 2.35.1 </ins>


Question:
Building fails when rebuilding system configuration. System configuration should build successfully with on kernel 5.18 There are no current maintainers. This appears to be a repetition of
Arch Linux appears to have a new patch here: Attempting to apply it has failed for me. I tried this block: Maybe someone who helped solve this the last time can comment?
Already have a PR up .
Looks like an issue with the patch for 5.17. Try replacing it with this one:
This issue has been mentioned on NixOS Discourse. There might be relevant details there:

<ins> diff -u -r a/src/shared/linux_osl.c b/src/shared/linux_osl.c --- a/src/shared/linux_osl.c	2022-05-24 20:51:15.662604980 +0000 +++ b/src/shared/linux_osl.c	2022-05-24 21:13:38.264472425 +0000 @@ -599,6 +599,8 @@ va = kmalloc(size, GFP_ATOMIC | __GFP_ZERO); if (va) *pap = (ulong)__virt_to_phys(va); +#elif LINUX_VERSION_CODE >= KERNEL_VERSION(5, 18, 0) +	va = dma_alloc_coherent(&((struct pci_dev *)osh->pdev)->dev, size, (dma_addr_t*)pap, GFP_ATOMIC); #else va = pci_alloc_consistent(osh->pdev, size, (dma_addr_t*)pap); #endif @@ -612,6 +614,8 @@ #ifdef __ARM_ARCH_7A__ kfree(va); +#elif LINUX_VERSION_CODE >= KERNEL_VERSION(5, 18, 0) +	dma_free_coherent(&((struct pci_dev *)osh->pdev)->dev, size, va, (dma_addr_t)pa); #else pci_free_consistent(osh->pdev, size, va, (dma_addr_t)pa); #endif @@ -623,7 +627,11 @@ int dir; ASSERT((osh && (osh->magic == OS_HANDLE_MAGIC))); +#if LINUX_VERSION_CODE >= KERNEL_VERSION(5, 18, 0) +	dir = (direction == DMA_TX)? DMA_TO_DEVICE: DMA_FROM_DEVICE; +#else dir = (direction == DMA_TX)? PCI_DMA_TODEVICE: PCI_DMA_FROMDEVICE; +#endif #if defined(__ARM_ARCH_7A__) && defined(BCMDMASGLISTOSL) if (dmah != NULL) { @@ -641,7 +649,11 @@ ASSERT(totsegs + nsegs <= MAX_DMA_SEGS); sg->page_link = 0; sg_set_buf(sg, PKTDATA(osh, skb), PKTLEN(osh, skb)); +#if LINUX_VERSION_CODE >= KERNEL_VERSION(5, 18, 0) +				dma_map_single(&((struct pci_dev *)osh->pdev)->dev, PKTDATA(osh, skb), PKTLEN(osh, skb), dir); +#else pci_map_single(osh->pdev, PKTDATA(osh, skb), PKTLEN(osh, skb), dir); +#endif } totsegs += nsegs; totlen += PKTLEN(osh, skb); @@ -656,7 +668,11 @@ } #endif +#if LINUX_VERSION_CODE >= KERNEL_VERSION(5, 18, 0) +	return (dma_map_single(&((struct pci_dev *)osh->pdev)->dev, va, size, dir)); +#else return (pci_map_single(osh->pdev, va, size, dir)); +#endif } void BCMFASTPATH @@ -665,8 +681,13 @@ int dir; ASSERT((osh && (osh->magic == OS_HANDLE_MAGIC))); +#if LINUX_VERSION_CODE >= KERNEL_VERSION(5, 18, 0) +	dir = (direction == DMA_TX)? DMA_TO_DEVICE: DMA_FROM_DEVICE; +	dma_unmap_single(&((struct pci_dev *)osh->pdev)->dev, (uint32)pa, size, dir); +#else dir = (direction == DMA_TX)? PCI_DMA_TODEVICE: PCI_DMA_FROMDEVICE; pci_unmap_single(osh->pdev, (uint32)pa, size, dir); +#endif } #if defined(BCMDBG_ASSERT) </ins>


Question:
Building fails when rebuilding system configuration. System configuration should build successfully with on kernel 5.18 There are no current maintainers. This appears to be a repetition of
Arch Linux appears to have a new patch here: Attempting to apply it has failed for me. I tried this block: Maybe someone who helped solve this the last time can comment?
Already have a PR up .
Looks like an issue with the patch for 5.17. Try replacing it with this one:
This issue has been mentioned on NixOS Discourse. There might be relevant details there:

<ins> diff --git a/src/shared/linux_osl.c b/shared/linux_osl.c index 711b771..5a2636a 100644 --- a/src/shared/linux_osl.c +++ b/src/shared/linux_osl.c @@ -1105,7 +1105,7 @@ osl_os_get_image_block(char *buf, int len, void *image) if (!image) return 0; -	rdlen = kernel_read(fp, fp->f_pos, buf, len); +	rdlen = kernel_read(fp, (void *)fp->f_pos, (size_t)len, (loff_t *)buf); if (rdlen > 0) fp->f_pos += rdlen; diff --git a/src/wl/sys/wl_cfg80211_hybrid.c b/wl/sys/wl_cfg80211_hybrid.c index 41c16d8..d39d9de 100644 --- a/src/wl/sys/wl_cfg80211_hybrid.c +++ b/src/wl/sys/wl_cfg80211_hybrid.c @@ -790,6 +790,7 @@ wl_set_auth_type(struct net_device *dev, struct cfg80211_connect_params *sme) break; case NL80211_AUTHTYPE_NETWORK_EAP: WL_DBG(("network eapn")); +		break; default: val = 2; WL_ERR(("invalid auth type (%d)n", sme->auth_type)); @@ -2347,21 +2348,20 @@ wl_bss_roaming_done(struct wl_cfg80211_priv *wl, struct net_device *ndev, const wl_event_msg_t *e, void *data) { struct wl_cfg80211_connect_info *conn_info = wl_to_conn(wl); +	s32 err = 0; #if LINUX_VERSION_CODE >= KERNEL_VERSION(4, 12, 0) struct cfg80211_bss *bss; struct wlc_ssid *ssid; +	struct cfg80211_roam_info roam_info; ssid = &wl->profile->ssid; bss = cfg80211_get_bss(wl_to_wiphy(wl), NULL, (s8 *)&wl->bssid, ssid->SSID, ssid->SSID_len, WLAN_CAPABILITY_ESS, WLAN_CAPABILITY_ESS); -	struct cfg80211_roam_info roam_info = { -		.bss = bss, -		.req_ie = conn_info->req_ie, -		.req_ie_len = conn_info->req_ie_len, -		.resp_ie = conn_info->resp_ie, -		.resp_ie_len = conn_info->resp_ie_len, -	}; +	roam_info.bss = bss; +	roam_info.req_ie = conn_info->req_ie; +	roam_info.req_ie_len = conn_info->req_ie_len; +	roam_info.resp_ie = conn_info->resp_ie; +	roam_info.resp_ie_len = conn_info->resp_ie_len; #endif -	s32 err = 0; wl_get_assoc_ies(wl); memcpy(wl->profile->bssid, &e->addr, ETHER_ADDR_LEN); diff --git a/src/wl/sys/wl_iw.h b/wl/sys/wl_iw.h index 3ab084f..471d11f 100644 --- a/src/wl/sys/wl_iw.h +++ b/src/wl/sys/wl_iw.h @@ -70,7 +70,6 @@ struct cntry_locales_custom { #define	WL_IW_RSSI_EXCELLENT	-57 #define	WL_IW_RSSI_INVALID	 0 #define MAX_WX_STRING 80 -#define isprint(c) bcm_isprint(c) #define WL_IW_SET_ACTIVE_SCAN	(SIOCIWFIRSTPRIV+1) #define WL_IW_GET_RSSI			(SIOCIWFIRSTPRIV+3) #define WL_IW_SET_PASSIVE_SCAN	(SIOCIWFIRSTPRIV+5) diff --git a/src/wl/sys/wl_linux.c b/wl/sys/wl_linux.c index d13fb98..97ae2a6 100644 --- a/src/wl/sys/wl_linux.c +++ b/src/wl/sys/wl_linux.c @@ -797,14 +797,15 @@ wl_pci_probe(struct pci_dev *pdev, const struct pci_device_id *ent) pci_read_config_dword(pdev, 0x40, &val); if ((val & 0x0000ff00) != 0) pci_write_config_dword(pdev, 0x40, val & 0xffff00ff); -		bar1_size = pci_resource_len(pdev, 2); -		#if LINUX_VERSION_CODE >= KERNEL_VERSION(5, 6, 0) -		bar1_addr = (uchar *)ioremap(pci_resource_start(pdev, 2), -			bar1_size); -		#else -		bar1_addr = (uchar *)ioremap_nocache(pci_resource_start(pdev, 2), -			bar1_size); -		#endif /* LINUX_VERSION_CODE >= KERNEL_VERSION(5, 6, 0) */ + +	bar1_size = pci_resource_len(pdev, 2); +	#if LINUX_VERSION_CODE >= KERNEL_VERSION(5, 6, 0) +	bar1_addr = (uchar *)ioremap(pci_resource_start(pdev, 2), +		bar1_size); +	#else +	bar1_addr = (uchar *)ioremap_nocache(pci_resource_start(pdev, 2), +		bar1_size); +	#endif /* LINUX_VERSION_CODE >= KERNEL_VERSION(5, 6, 0) */ wl = wl_attach(pdev->vendor, pdev->device, pci_resource_start(pdev, 0), PCI_BUS, pdev, pdev->irq, bar1_addr, bar1_size); </ins>


Question:
Steps to reproduce the behavior:
Can you check if has an effect?
I've got this error:
Please check the full log of that build and look for ( catching the actual error) and any preceding lines with (actual error from the compiler). What you posted are just harmless warnings and (an error has occurred somewhere else so needs to quit).
Upstream issue:

url = "https://hg.mozilla.org/releases/mozilla-esr102/raw-rev/1fa20fb474f5d149cc32d98df169dee5e6e6861b"; sha256 = "sha256-eCisKjNxy9SLr9KoEE2UB26BflUknnR7PIvnpezsZeA="; }) <ins> ] ++ lib.optionals (lib.versionAtLeast version "91" && stdenv.hostPlatform.system == "i686-linux") [ # Fixes i686 build, https://bugzilla.mozilla.org/show_bug.cgi?id=1729459 ./fix-float-i686.patch </ins> ]; nativeBuildInputs = [


Question:
Steps to reproduce the behavior:
Can you check if has an effect?
I've got this error:
Please check the full log of that build and look for ( catching the actual error) and any preceding lines with (actual error from the compiler). What you posted are just harmless warnings and (an error has occurred somewhere else so needs to quit).
Upstream issue:

<ins> diff --git a/modules/fdlibm/src/math_private.h b/modules/fdlibm/src/math_private.h index 51d79f9c2ec59..fafd7d6fc1e0d 100644 --- a/modules/fdlibm/src/math_private.h +++ b/modules/fdlibm/src/math_private.h @@ -30,5 +30,9 @@ * Adapted from https://github.com/freebsd/freebsd-src/search?q=__double_t */ +#if defined __FLT_EVAL_METHOD__ && (__FLT_EVAL_METHOD__ == 2) +typedef long double      __double_t; +#else typedef double      __double_t; +#endif typedef __double_t  double_t; /* </ins>  No newline at end of file


Question: nicely describes the issue and the fix Steps to reproduce the behavior: salt on to run it errors salt working and may be of interest to ;) <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Please run and paste the result.

{ lib , python3 , openssl <ins> , fetchpatch </ins> # Many Salt modules require various Python modules to be installed, # passing them in this array enables Salt to find them. , extraInputs ? []


Question: nicely describes the issue and the fix Steps to reproduce the behavior: salt on to run it errors salt working and may be of interest to ;) <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Please run and paste the result.

patches = [ ./fix-libcrypto-loading.patch <ins> (fetchpatch { url = "https://github.com/saltstack/salt/commit/6ec8b90e402ff3fa8f27c7da70ece898592416bc.patch"; hash = "sha256-OQCJeG12cp2EZ0BErp6yqsqhv023923rVFDHAFUfF6c="; }) </ins> ]; postPatch = ''


Question: tig crash on macOS (m1) Steps to reproduce the behavior: -shell -p tig ANYGITREPO type "/" to enter search mode Don't crash ! Exception Type: EXCBADACCESS (SIGSEGV) Exception Codes: KERNINVALIDADDRESS at 0x082a0d5c00ab0a2b -0x00000d5c00ab0a2b (possible pointer authentication failure) Exception Codes: 0x0000000000000001, 0x082a0d5c00ab0a2b Exception Note: EXCCORPSENOTIFY Termination Reason: Namespace SIGNAL, Code 11 Segmentation fault: 11 Terminating Process: exc handler [] VM Region Info: 0xd5c00ab0a2b is not in any region. Bytes after previous region: Bytes before following region: REGION TYPE START - END [ VSIZE] PRT/MAX SHRMOD REGION DETAIL commpage (reserved) - [384.0G] ---/--- SM=NUL ...(unallocated) ---GAP OF 0x5f9000000000 BYTES MALLOCNANO - [128.0M] rw-/rwx SM=PRV Thread 0 Crashed:: Dispatch queue: 0 ??? 0x100b84c6c rlinitterminalio + 272 1 ??? 0x100b84c60 rlinitterminalio + 260 2 ??? 0x100b6fc2c readlineinitializeeverything + 164 3 ??? 0x100b6edd0 rlinitialize + 44 4 ??? 0x100b6ed48 readline + 36 5 ??? 0x100981ce4 readprompt + 80 6 ??? 0x10098aaa0 searchview + 56 7 ??? 0x100971680 main + 2608 8 dyld 0x100d61088 start + 516 <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Please run and paste the result.

inherit (darwin.apple_sdk.frameworks) Security; }; <del> tig = callPackage ../applications/version-management/git-and-tools/tig { }; </del> <ins> tig = callPackage ../applications/version-management/git-and-tools/tig { readline = readline81; }; </ins> tilemaker = callPackage ../applications/misc/tilemaker { };


Question:
Noticed while debugging hash errors for . Since got merged via (bisect log further down), doesn't produce fully deterministic results anymore. Sometimes I get an identical hash, several times in a row even? But often it's different. It is worth noting that the fetcher output has changed after that commit. Using as an example, the final line has been replaced by for the main repository + every fetched submodule. Steps to reproduce the behavior: (current master at the time of writing) repl: multiple times and you should get a different hash eventually. "Best" combo I got so far is 3 identical hashes before a different one. Hashes shouldn't randomly be different. It would be understandable if the not-yet-deterministic was used, but this happens even with . Changing hashes: ! ! Changed output: (last identical lines are highlighted) ! Bisect log: Bisection done with . uses with , which uses under the hood, but the hash change should be observable by directly using as well. CC (commit author) CC (PR merger) Please run and paste the result.
I did a quick investigation. First of all: I was able to produce the same results as the OP on my machine. My initial investigation led me to believe that this behavior is caused by 2 bugs. One introduced by commit and the other one being unrelated to this commit. The bug introduced by the commit in question is that seems to use in situations where it shouldn't. The second bug is that specifying produces non deterministic results. Evidence for this is provided by the following experiment: I checked out a revision of that was before No I ran the same experiment as the OP suggested but instead of using I used . As you can see I got two different results for the same call. I suggest that should be reverted to mitigate the damage by the bug it introduced. I don't know well enough to do anything about "the other bug".
This is a .
Pinning this until the fix has made its way into and staging.
Thanks a lot to everyone involved in investigating and fixing this! Also, I'm sorry for breaking this in the first place!
Don't take all the credit for yourself. We broke this together ^^
I'm seeing behavior that I think may be related to this issue. Please consider the derivation contained within the following flake: Changing the dummy value of results in different suggested replacement values. It seems to me that any value except for the corrected one should result in the same suggestion. Furthermore, all suggestions do build successfully (so the allowed values of are not unique) but the only one that actually respects is the empty string case. This may indicate a separate problem with .

fi done <del> if test -n $deepClone; then leaveDotGit=true fi </del> if test -z "$url"; then usage fi


Question:
The reason why I didn't open a PR, is described in . I'm aware of four platforms for Qt's themes right now: Using GTK themes through + ; Using GNOME themes through + ; Using Qt themes, with the non-KDE solution , which uses ; Using Plasma-targeted Qt themes, with as , as done natively in a plasma session, using the theme's colorscheme. Steps to reproduce the behavior:  and it does not provide ; equivalent to  providing ; , then add some Pasma-target themes like , then adjust envvars , set the theme in or with , you'll get the right theme with the proper color scheme. should provide (or ) as an option, it should add only the required packages to the system, and set the proper envvars. (or maybe rename it, since qt6 also uses the same variables and envvars) qbittorrent + breeze + + dark: ! qbittorrent + breeze + + dark: ! qbittorrent + (ignored my theme): ! qbittorrent + (also ignored my theme): ! I tried to discover what package that is being when evaluating provides this platform-theme, but I failed miserably. stated as maintainers of plasma-integration: stated as maintainer of qt5ct: qt5 module contributors: cc Please run and paste the result.
Not exactly your bug, but we should remove and integrate it with configs instead.
is another QT platform theme that can be integrated into config.

isQtStyle = cfg.platformTheme == "gtk2" && !(builtins.elem cfg.style ["adwaita" "adwaita-dark"]); isQt5ct = cfg.platformTheme == "qt5ct"; isLxqt = cfg.platformTheme == "lxqt"; <ins> isKde = cfg.platformTheme == "kde"; </ins> packages = if isQGnome then [ pkgs.qgnomeplatform pkgs.adwaita-qt ] else if isQtStyle then [ pkgs.libsForQt5.qtstyleplugins ] else if isQt5ct then [ pkgs.libsForQt5.qt5ct ] else if isLxqt then [ pkgs.lxqt.lxqt-qtplugin pkgs.lxqt.lxqt-config ] <ins> else if isKde then [ pkgs.libsForQt5.plasma-integration pkgs.libsForQt5.systemsettings ] </ins> else throw "`qt5.platformTheme` ${cfg.platformTheme} and `qt5.style` ${cfg.style} are not compatible."; in


Question:
The reason why I didn't open a PR, is described in . I'm aware of four platforms for Qt's themes right now: Using GTK themes through + ; Using GNOME themes through + ; Using Qt themes, with the non-KDE solution , which uses ; Using Plasma-targeted Qt themes, with as , as done natively in a plasma session, using the theme's colorscheme. Steps to reproduce the behavior:  and it does not provide ; equivalent to  providing ; , then add some Pasma-target themes like , then adjust envvars , set the theme in or with , you'll get the right theme with the proper color scheme. should provide (or ) as an option, it should add only the required packages to the system, and set the proper envvars. (or maybe rename it, since qt6 also uses the same variables and envvars) qbittorrent + breeze + + dark: ! qbittorrent + breeze + + dark: ! qbittorrent + (ignored my theme): ! qbittorrent + (also ignored my theme): ! I tried to discover what package that is being when evaluating provides this platform-theme, but I failed miserably. stated as maintainers of plasma-integration: stated as maintainer of qt5ct: qt5 module contributors: cc Please run and paste the result.
Not exactly your bug, but we should remove and integrate it with configs instead.
is another QT platform theme that can be integrated into config.

"gnome" "lxqt" "qt5ct" <ins> "kde" </ins> ]; example = "gnome"; relatedPackages = [


Question:
The reason why I didn't open a PR, is described in . I'm aware of four platforms for Qt's themes right now: Using GTK themes through + ; Using GNOME themes through + ; Using Qt themes, with the non-KDE solution , which uses ; Using Plasma-targeted Qt themes, with as , as done natively in a plasma session, using the theme's colorscheme. Steps to reproduce the behavior:  and it does not provide ; equivalent to  providing ; , then add some Pasma-target themes like , then adjust envvars , set the theme in or with , you'll get the right theme with the proper color scheme. should provide (or ) as an option, it should add only the required packages to the system, and set the proper envvars. (or maybe rename it, since qt6 also uses the same variables and envvars) qbittorrent + breeze + + dark: ! qbittorrent + breeze + + dark: ! qbittorrent + (ignored my theme): ! qbittorrent + (also ignored my theme): ! I tried to discover what package that is being when evaluating provides this platform-theme, but I failed miserably. stated as maintainers of plasma-integration: stated as maintainer of qt5ct: qt5 module contributors: cc Please run and paste the result.
Not exactly your bug, but we should remove and integrate it with configs instead.
is another QT platform theme that can be integrated into config.

["libsForQt5" "qtstyleplugins"] ["libsForQt5" "qt5ct"] ["lxqt" "lxqt-qtplugin"] <ins> ["libsForQt5" "plasma-integration"] </ins> ]; description = '' Selects the platform theme to use for Qt5 applications.</para>


Question:
The reason why I didn't open a PR, is described in . I'm aware of four platforms for Qt's themes right now: Using GTK themes through + ; Using GNOME themes through + ; Using Qt themes, with the non-KDE solution , which uses ; Using Plasma-targeted Qt themes, with as , as done natively in a plasma session, using the theme's colorscheme. Steps to reproduce the behavior:  and it does not provide ; equivalent to  providing ; , then add some Pasma-target themes like , then adjust envvars , set the theme in or with , you'll get the right theme with the proper color scheme. should provide (or ) as an option, it should add only the required packages to the system, and set the proper envvars. (or maybe rename it, since qt6 also uses the same variables and envvars) qbittorrent + breeze + + dark: ! qbittorrent + breeze + + dark: ! qbittorrent + (ignored my theme): ! qbittorrent + (also ignored my theme): ! I tried to discover what package that is being when evaluating provides this platform-theme, but I failed miserably. stated as maintainers of plasma-integration: stated as maintainer of qt5ct: qt5 module contributors: cc Please run and paste the result.
Not exactly your bug, but we should remove and integrate it with configs instead.
is another QT platform theme that can be integrated into config.

application. </para></listitem> </varlistentry> <ins> <varlistentry> <term><literal>kde</literal></term> <listitem><para>Use Qt settings from Plasma.</para></listitem> </varlistentry> </ins> </variablelist> ''; };


Question:
The reason why I didn't open a PR, is described in . I'm aware of four platforms for Qt's themes right now: Using GTK themes through + ; Using GNOME themes through + ; Using Qt themes, with the non-KDE solution , which uses ; Using Plasma-targeted Qt themes, with as , as done natively in a plasma session, using the theme's colorscheme. Steps to reproduce the behavior:  and it does not provide ; equivalent to  providing ; , then add some Pasma-target themes like , then adjust envvars , set the theme in or with , you'll get the right theme with the proper color scheme. should provide (or ) as an option, it should add only the required packages to the system, and set the proper envvars. (or maybe rename it, since qt6 also uses the same variables and envvars) qbittorrent + breeze + + dark: ! qbittorrent + breeze + + dark: ! qbittorrent + (ignored my theme): ! qbittorrent + (also ignored my theme): ! I tried to discover what package that is being when evaluating provides this platform-theme, but I failed miserably. stated as maintainers of plasma-integration: stated as maintainer of qt5ct: qt5 module contributors: cc Please run and paste the result.
Not exactly your bug, but we should remove and integrate it with configs instead.
is another QT platform theme that can be integrated into config.

environment.variables.QT_QPA_PLATFORMTHEME = cfg.platformTheme; <del> environment.variables.QT_STYLE_OVERRIDE = mkIf (! (isQt5ct || isLxqt)) cfg.style; </del> <ins> environment.variables.QT_STYLE_OVERRIDE = mkIf (! (isQt5ct || isLxqt || isKde)) cfg.style; </ins> environment.systemPackages = packages;


Question: Latest version uses Electron 18 instead of 16, which fixes issues with Wayland + Nvidia graphics. <!-- Note that these are hard requirements --<!-- You can use the "Go to file" functionality on GitHub to find the package Then you can go to the history for this package Find the latest "packagename: oldversion -newversion" commit The "newversion" is the current version of the package --- <!-- 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! --- name: mullvad-vpn <!-- The current version can be found easily with the same process as above for checking the master branch If an open PR is present for the package, take this version as the current one and link to the PR --current version: 2022.1 desired version: 2022.2 <!-- Search your package here: If no maintainer is listed for your package, tag the person that last updated the package --maintainers: Please tag this issue in your PR.

stdenv.mkDerivation rec { pname = "mullvad-vpn"; <del> version = "2022.1"; </del> <ins> version = "2022.2"; </ins> src = fetchurl { url = "https://github.com/mullvad/mullvadvpn-app/releases/download/${version}/MullvadVPN-${version}_amd64.deb"; <del> sha256 = "0s12y9j75k59kqkcvfflb1v5p3ny7xgc1m5bd635lvql1bv46c3i"; </del> <ins> sha256 = "sha256-h/c4aPH6E2TzbXGROpLJgF9uHYcjvKiW5upIobpJM9o="; </ins> }; nativeBuildInputs = [


Question: Latest version uses Electron 18 instead of 16, which fixes issues with Wayland + Nvidia graphics. <!-- Note that these are hard requirements --<!-- You can use the "Go to file" functionality on GitHub to find the package Then you can go to the history for this package Find the latest "packagename: oldversion -newversion" commit The "newversion" is the current version of the package --- <!-- 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! --- name: mullvad-vpn <!-- The current version can be found easily with the same process as above for checking the master branch If an open PR is present for the package, take this version as the current one and link to the PR --current version: 2022.1 desired version: 2022.2 <!-- Search your package here: If no maintainer is listed for your package, tag the person that last updated the package --maintainers: Please tag this issue in your PR.

, openvpn-mullvad , shadowsocks-rust }: <del> let # result of running address_cache as of 02 Mar 2022 bootstrap-address-cache = writeText "api-ip-address.txt" '' 193.138.218.78:443 193.138.218.71:444 185.65.134.66:444 185.65.135.117:444 217.138.254.130:444 91.90.44.10:444 ''; in </del> rustPlatform.buildRustPackage rec { pname = "mullvad"; <del> version = "2022.1"; </del> <ins> version = "2022.2"; </ins> src = fetchFromGitHub { owner = "mullvad"; repo = "mullvadvpn-app"; rev = version; <del> hash = "sha256-bLwuM3Qy2iStbXIvDEWp31vuiihSQThOej297XKo5Xc="; </del> <ins> hash = "sha256-ZtQKzbFrkacrfPIkMz/UOfIwQBXQUoVVlFla//jmMwY="; </ins> }; <del> cargoHash = "sha256-CBbm8cJHTjyvvzCFQfKmsE5d9N7azEm8nI6KeWLVaa8="; </del> <ins> cargoHash = "sha256-J6h3KY1RDCnAc/tQHNGEyOlVQoQNhRqjWbmimPitydQ="; </ins> nativeBuildInputs = [ pkg-config


Question: Latest version uses Electron 18 instead of 16, which fixes issues with Wayland + Nvidia graphics. <!-- Note that these are hard requirements --<!-- You can use the "Go to file" functionality on GitHub to find the package Then you can go to the history for this package Find the latest "packagename: oldversion -newversion" commit The "newversion" is the current version of the package --- <!-- 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! --- name: mullvad-vpn <!-- The current version can be found easily with the same process as above for checking the master branch If an open PR is present for the package, take this version as the current one and link to the PR --current version: 2022.1 desired version: 2022.2 <!-- Search your package here: If no maintainer is listed for your package, tag the person that last updated the package --maintainers: Please tag this issue in your PR.

postFixup = # Place all binaries in the 'mullvad-' namespace, even though these # specific binaries aren't used in the lifetime of the program. <del> # `address_cache` is used to generate the `api-ip-address.txt` file, which # contains list of Mullvad API servers -- though we provide a "backup" of # the output of this command, it could change at any time, so we want # users to be able to regenerate the list at any time. (The daemon will # refuse to start without this file.) </del> '' <del> for bin in address_cache relay_list translations-converter; do </del> <ins> for bin in relay_list translations-converter; do </ins> mv "$out/bin/$bin" "$out/bin/mullvad-$bin" done '' + <del> # Put distributed assets in-place -- specifically, the # bootstrap-address-cache is necessary; otherwise, the user will have to run # the `address_cache` binary and move the contents into place at # `/var/cache/mullvad-vpn/api-ip-address.txt` manually. '' mkdir -p $out/share/mullvad ln -s ${bootstrap-address-cache} $out/share/mullvad/api-ip-address.txt '' + </del> # Files necessary for OpenVPN tunnels to work. '' <ins> mkdir -p $out/share/mullvad </ins> cp dist-assets/ca.crt $out/share/mullvad ln -s ${openvpn-mullvad}/bin/openvpn $out/share/mullvad ln -s ${shadowsocks-rust}/bin/sslocal $out/share/mullvad


Question:
Steps to reproduce the behavior:
I don't have an M1 to test
Oh, it suffices to use . I'll open a pull request.

<del> { lib, stdenv, fetchurl, cctools, fixDarwinDylibNames }: </del> <ins> { lib , stdenv , fetchurl , cctools , fixDarwinDylibNames , autoSignDarwinBinariesHook }: </ins> stdenv.mkDerivation rec { pname = "lp_solve"; version = "5.5.2.11";


Question:
Steps to reproduce the behavior:
I don't have an M1 to test
Oh, it suffices to use . I'll open a pull request.

nativeBuildInputs = lib.optionals stdenv.isDarwin [ cctools fixDarwinDylibNames <ins> ] ++ lib.optionals (stdenv.isDarwin && stdenv.isAarch64) [ autoSignDarwinBinariesHook </ins> ]; dontConfigure = true; <del> buildPhase = let ccc = if stdenv.isDarwin then "ccc.osx" else "ccc"; in '' runHook preBuild </del> <ins> buildPhase = let ccc = if stdenv.isDarwin then "ccc.osx" else "ccc"; in '' runHook preBuild </ins> <del> (cd lpsolve55 && bash -x -e ${ccc}) (cd lp_solve  && bash -x -e ${ccc}) </del> <ins> (cd lpsolve55 && bash -x -e ${ccc}) (cd lp_solve  && bash -x -e ${ccc}) </ins> <del> runHook postBuild ''; </del> <ins> runHook postBuild ''; </ins> installPhase = '' runHook preInstall


Question:
Steps to reproduce the behavior:
I don't have an M1 to test
Oh, it suffices to use . I'll open a pull request.

meta = with lib; { description = "A Mixed Integer Linear Programming (MILP) solver"; <del> homepage    = "http://lpsolve.sourceforge.net"; license     = licenses.gpl2Plus; </del> <ins> homepage = "http://lpsolve.sourceforge.net"; license = licenses.gpl2Plus; </ins> maintainers = with maintainers; [ smironov ]; <del> platforms   = platforms.unix; </del> <ins> platforms = platforms.unix; </ins> }; }


Question:
Steps to reproduce the behavior:
I don't have an M1 to test
Oh, it suffices to use . I'll open a pull request.

}; lp_solve = callPackage ../applications/science/math/lp_solve { <del> inherit (darwin) cctools; </del> <ins> inherit (darwin) cctools autoSignDarwinBinariesHook; </ins> }; fabric-installer = callPackage ../tools/games/minecraft/fabric-installer { };


Question:
<!-- Note that these are hard requirements --<!-- You can use the "Go to file" functionality on GitHub to find the package Then you can go to the history for this package Find the latest "packagename: oldversion -newversion" commit The "newversion" is the current version of the package --- <!-- 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! --- name: winePackages.{unstable,staging} <!-- The current version can be found easily with the same process as above for checking the master branch If an open PR is present for the package, take this version as the current one and link to the PR --current version: 7.10 desired version: 7.12 <!-- Search your package here: If no maintainer is listed for your package, tag the person that last updated the package --maintainers: Please tag this issue in your PR.
cc
PR at , needs to be tested still. My last attempts at updating have been held back by the fact that there are so many variants that building everything is prohibitively time consuming on my machine, and PRs that were ready have been lingering so long that I've had to update them with one or two even newer wine versions before they were merged, so I was not particularly motivated.

unstable = fetchurl rec { # NOTE: Don't forget to change the SHA256 for staging as well. <del> version = "7.10"; </del> <ins> version = "7.12"; </ins> url = "https://dl.winehq.org/wine/source/7.x/wine-${version}.tar.xz"; <del> sha256 = "sha256-P+skzYWYwQ9q9xHnSsK10kQrtNO4wHj506JTroc2SA0="; </del> <ins> sha256 = "sha256-gJzsE3FmNubq/Uw9pzEkVqhE0xYCClV4YRvNuiEGnGg="; </ins> inherit (stable) gecko32 gecko64 patches; mono = fetchurl rec {