Question: github = "thefossguy"; githubId = 44400303; }; <ins> thehans255 = { name = "Hans Jorgensen"; email = "foss-contact@thehans255.com"; github = "thehans255"; githubId = 15896573; }; </ins> thekostins = { name = "Konstantin"; email = "anisimovkosta19@gmail.com";

Project description Dr. Robotnik's Ring Racers is a kart racing video game originally based on the 3D Sonic the Hedgehog fangame , itself based on a modified version of . Metadata homepage URL: source URL: or license: gpl2+ platforms: linux cc (this is kart v2) Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Done. Test it out and let me know if you encounter any issues :+1:


Question: connector-c = self; server = self; mysqlVersion = "5.7"; <ins> tests = nixosTests.mysql; </ins> }; meta = with lib; {

, CVSSv3=5.5 (nixos-21.11, nixos-unstable) CVSSv3=4.9 (nixos-21.11, nixos-unstable) CVSSv3=4.9 (nixos-21.11, nixos-unstable) CVSSv3=4.9 (nixos-21.11, nixos-unstable) CVSSv3=4.9 (nixos-21.11, nixos-unstable) CVSSv3=4.3 (nixos-21.11, nixos-unstable) Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Compiling). Supported versions that are affected are 5.7.36 and prior and 8.0.27 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server. Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server as well as unauthorized update, insert or delete access to some of MySQL Server accessible data. CVSS 3.1 Base Score 5.5 (Integrity and Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:L/A:H). Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Federated). Supported versions that are affected are 5.7.36 and prior and 8.0.27 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server. Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H). Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Stored Procedure). Supported versions that are affected are 5.7.36 and prior and 8.0.27 and prior.


Question: connector-c = self; server = self; mysqlVersion = "5.7"; <ins> tests = nixosTests.mysql; </ins> }; meta = with lib; {

Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server. Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H). Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Parser). Supported versions that are affected are 5.7.36 and prior and 8.0.27 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server. Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H). Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Replication). Supported versions that are affected are 5.7.36 and prior and 8.0.27 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server. Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H). Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Security: Privileges). Supported versions that are affected are 5.7.36 and prior and 8.0.27 and prior. Easily exploitable vulnerability allows low privileged attacker with network access via multiple protocols to compromise MySQL Server. Successful attacks of this vulnerability can result in unauthorized update, insert or delete access to some of MySQL Server accessible data. CVSS 3.1 Base Score 4.3 (Integrity impacts).


Question: connector-c = self; server = self; mysqlVersion = "5.7"; <ins> tests = nixosTests.mysql; </ins> }; meta = with lib; {

CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N). Scanned versions: nixos-21.11: ; nixos-unstable: .
See also: , , , , , ,
Fixed: nixos-21.11: mysql-5.7.37, mysql-8.0.28 nixos-unstable: mysql-5.7.39, mysql-8.0.30


Question: else "") + lib.optionalString targetPlatform.isAvr '' makeFlagsArray+=( <ins> '-s' # workaround for hitting hydra log limit </ins> 'LIMITS_H_TEST=false' ) '';

and fail in this fashion: This seems to have started to happen in December of last year (see ). This effectively means that using the avr toolchain in nixpkgs means re-compiling gcc on every channel update. Not sure what is causing the log size, unfortunately there's no special hydra meta attr to change the log limit. cc Maintainer information:
From doing local rebuilds of this package and noting how much output it gives, the long logs are from echoing back the compiler commands from make when compiling all of the soft float routines for each different AVR chip. It started dumping all this output when we moved from GCC 9 to GCC 10. Looking at the logs prior to that version bump, make must have been quiet because I see no compiler commands getting echoed back. Is it possible to add something like here?
may be worth a try:


Question: <ins> { lib , rustPlatform , fetchFromGitHub , cmake , pkg-config , openssl , fontconfig , nasm , libX11 , libXcursor , libXrandr , libXi , libGL , stdenv , gtk3 , darwin }: rustPlatform.buildRustPackage rec { pname = "oculante"; version = "0.6.38"; src = fetchFromGitHub { owner = "woelper"; repo = pname; rev = version; sha256 = "sha256-0msPeW0FoBzHBDfX2iFH4HzAknaGPNThuCLi2vhdK08="; }; cargoSha256 = "sha256-eKRn8MC4/jjPRoajhwrtXsa8n9bGO5MAKjDuwHWs7Oc="; nativeBuildInputs = [ cmake pkg-config nasm ]; checkFlagsArray = [ "--skip=tests::net" ]; # requires network access buildInputs = [ openssl fontconfig ] ++ lib.optionals stdenv.isLinux [ libX11 libXcursor libXi libXrandr libGL gtk3 ] ++ lib.optionals stdenv.isDarwin [ darwin.libobjc ]; postFixup = lib.optionalString stdenv.isLinux '' patchelf $out/bin/oculante --add-rpath ${lib.makeLibraryPath [ libGL ]} ''; meta = with lib; { broken = stdenv.isDarwin; description = "A minimalistic crossplatform image viewer written in Rust"; homepage = "https://github.com/woelper/oculante"; changelog = "https://github.com/woelper/oculante/blob/${version}/CHANGELOG.md"; license = licenses.mit; maintainers = with maintainers; [ dit7ya ]; }; } </ins>

Project description Oculante's vision is to be a fast, unobtrusive, portable image viewer with wide image format support, offering image analysis and basic editing tools. Metadata homepage URL: source URL: license: MIT platforms: cross


Question: pwdsafety = callPackage ../tools/security/pwdsafety { }; <ins> pwvucontrol = callPackage ../applications/audio/pwvucontrol { }; </ins> pyload-ng = callPackage ../applications/networking/pyload-ng {}; pyrosimple = callPackage ../applications/networking/p2p/pyrosimple { };

Project description Volume control applet for Pipewire, written in Rust. <!-- Describe the project a little: --Metadata homepage URL: source URL: license: mit, bsd, gpl2+ , ... platforms: unix, linux, darwin, ...


Question: ++ stdenv.lib.optional perlBindings perl ++ stdenv.lib.optional saslSupport sasl; <ins> patches = [ ./apr-1.patch ]; </ins> configureFlags = '' ${if bdbSupport then "--with-berkeley-db" else "--without-berkeley-db"} ${if httpServer then "--with-apxs=${apacheHttpd}/bin/apxs" else "--without-apxs"}

When is installed with , works fine. When is installed with , then prints an error message. When installing with , I get this log: So, it might be that git-with-svn-2.6.3 is fine but not . System: NixOS: = () Nix: = Nixpkgs version: () /cc
I think you have nixpkgs and nixos channel. One might be coming from root. So on one channel it works, on the other it doesn't.
This is a bug in the Perl bindings generated as a part of our Subversion build. The library depends on , but it has no RPATH set that allows it to find library. Curiously enough, is the only dependency with that problem: other library like are found properly using a full path into the Nix store. Cc: and
and it was working fine in :
As I said, this as nothing to do with Git. It's that provides broken Perl bindings.
Ran into same problem. git bisect log of checking ldd /nix/store/-subversion-1.9.3/lib/perl5/siteperl//x8664-linux-thread- follows. there's some big binutils related changes in the middle yet.


Question: sha256 = "sha256-kHirHG/bfsU6tKyQ0khNSTyChhzHfzib+HyA3LOtBI8="; }; <del> nativeBuildInputs = [ pkgs.makeWrapper ]; </del> <ins> nativeBuildInputs = [ makeWrapper ]; </ins> preBuild = '' makeFlagsArray+=(prefix="$out")

Describe the bug I need to list the out paths of cross compiled packages beforehand which causes an eval error. To Reproduce Steps to reproduce the behavior: Expected behavior List all out paths like `. Additional context I need this feature for nixpkgs-review when cross compiling. Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Metadata system: host os: multi-user?: sandbox: version: channels(user): nixpkgs: Maintainer information:
I think its because of the lack of splicing for perl-packages. Note however, that when that is fixed, other package sets will fail with the same issue. cc
Probably multiple issues. Have seen that problem with building xwayland for aarch64 too. Removing makeWrapper helps but probably breaks it :(. But the deps don't cross-build anyway so never got that far for now. Was thinking about opening an issue but got caught up trying to find the issue -- to no avail. Not currently at my machine, might post it later.
I marked this as stale due to inactivity. →
still important to me
Fix in


Question: # substitute environment variables if [ -f "${configFile}" ]; then ${pkgs.gawk}/bin/awk '{ <del> for(varname in ENVIRON) gsub("@"varname"@", ENVIRON[varname]) </del> <ins> for(varname in ENVIRON) { find = "@"varname"@" repl = ENVIRON[varname] if (i = index($0, find)) $0 = substr($0, 1, i-1) repl substr($0, i+length(find)) } </ins> print }' "${configFile}" > "${finalConfig}" else

Using the NixOS option to specify the configuration, I noticed that if an ampersand () is present, the password field of isn't generated correctly. the option along with the option. The environment file should contain . the field "password= the content of . The password is decrypted to . The password shuld be decrypted to . The global variable's name shouldn't show. Here are some nix code that is tested to trigger this issue instead. The environment file: Generated in the aforementioned path, note how the field is erroneous. A hack to get around this is to split your password in two halves, and put the & in plain text. . Of course I would still like to see this get fixed :p Thank you for maintaining this module and reading this issue ! Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
It looks like a missed a metacharacter: I don't know if escaping it as works, or it interacts somehow with other systemd/shell/nix metacharacters. I lost counts of how many level of escaping we are in. I hope to get rid of all of this nonsense with , but next release of wpasupplicant is taking forever.
Done in The fix should be in NixOS 24.05.


Question: </listitem> <listitem> <para> <del> <literal>iptables</literal> now uses <literal>nf_tables</literal> backend. </del> <ins> <literal>iptables</literal> is now using <literal>nf_tables</literal> under the hood, by using <literal>iptables-nft</literal>, similar to <link xlink:href="https://wiki.debian.org/nftables#Current_status">Debian</link> and <link xlink:href="https://fedoraproject.org/wiki/Changes/iptables-nft-default">Fedora</link>. This means, <literal>ip[6]tables</literal>, <literal>arptables</literal> and <literal>ebtables</literal> commands will actually show rules from some specific tables in the <literal>nf_tables</literal> kernel subsystem. </para> </listitem> <listitem> <para> systemd got an <literal>nftables</literal> backend, and configures (networkd) rules in their own <literal>io.systemd.*</literal> tables. Check <literal>nft list ruleset</literal> to see these rules, not <literal>iptables-save</literal> (which only shows <literal>iptables</literal>-created rules. </ins> </para> </listitem> <listitem>

On NixOS 21.05, when setting , I could see the result of this settings by running: Since NixOS 21.11 however, altought the masquerade works, I cannot see anything with iptables commands: As discussed on the Discourse topic , I suspect this is linked to the following change in NixOS 21.11 (PR ): Steps to reproduce the behavior: an interface with on a system running NixOS 21.11 the lack of information about the IP masquerade The IP masquerade should be visible like in NixOS 21.05:
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Actually, this is due to systemd since v248 preferring to use nftables if available, see Systemd does not use the iptables binaries and but a separate library that creates iptables rules directly without translation to nft by iptables-nft. So even without using the legacy iptables tools, these rules in nftables by networkd would not be visible. Other services that need to add firewall rules like libvirtd, docker or podman are likely getting proper nftables support soon and users still using iptables will run into the same issues. Since we are not the only distribution dealing with this, this should either be solved in systemd (can rules be generated that are compatible to and can be parsed by iptables-nft?) or in iptables-nft by displaying a warning that other nftables rules are active. The only related problem remaining in NixOS is that since our module is heavily based around iptables, our users assume NixOS is using iptables when in fact it is using nftables with iptables compatibility. cc
This particular issue is also giving me issues running docker on NixOS 21.11 in WSL2 on Windows 10. It requires iptables and the docker service fails to start due to docker trying to issue iptables a command and the nftables reply throws docker as an error. Same configuration using systemd v247 via 21.05 works fine
What you're seeing is directly caused by and has nothing to with this issue since the problem described here is that not all active rules are visible. Are we even supporting WSL officially?


Question: </listitem> <listitem> <para> <del> <literal>iptables</literal> now uses <literal>nf_tables</literal> backend. </del> <ins> <literal>iptables</literal> is now using <literal>nf_tables</literal> under the hood, by using <literal>iptables-nft</literal>, similar to <link xlink:href="https://wiki.debian.org/nftables#Current_status">Debian</link> and <link xlink:href="https://fedoraproject.org/wiki/Changes/iptables-nft-default">Fedora</link>. This means, <literal>ip[6]tables</literal>, <literal>arptables</literal> and <literal>ebtables</literal> commands will actually show rules from some specific tables in the <literal>nf_tables</literal> kernel subsystem. </para> </listitem> <listitem> <para> systemd got an <literal>nftables</literal> backend, and configures (networkd) rules in their own <literal>io.systemd.*</literal> tables. Check <literal>nft list ruleset</literal> to see these rules, not <literal>iptables-save</literal> (which only shows <literal>iptables</literal>-created rules. </ins> </para> </listitem> <listitem>

You might want to open a separate issue for this if you're interested in seeing support or getting this fixed. We would need to detect if nftables support is available and use the correct iptables package everywhere. Not sure if it's worth it, though.
this seems to also cause problems when upgrading systems from before the nftables bump. In my case, these were fixed after a reboot, but it's still a pretty annoying thing, for which we probably should at least make sure there's a release note entry. cc
Hmmh, I'm also a bit baffled about how to interpret defaulting to false. ~It seems and are mutually exclusive, but since we now configure nftables in other places, the firewall module is just broken?~
It seems only supports defining all rules exclusively, which doesn't play very nicely together with other things invoking iptables, or managing rules by themselves (like networkd , libvirt and other programs invoking iptables). Maybe that module needs a bit of a re-vamp - with merged we might want to configure most of what the module was doing, except managing the ruleset by default. However, that's a bit offtopic from the original issue.
you should see nftable tables when invoking , which is where systemd keeps its nft rules. iptables rules configured with the command are in . I think this is mostly a matter of updating the release notes, and raising awareness, that nftables is used, the command is only managing some tables in the nft system, and that there's more rules than what you can see with . I'll try to come up with a PR updating the release notes in that regard. It might not be possible to translate some nftable rules to a iptables syntax - I'm not sure if logging a warning breaks backwards compat with some tools relying on iptables output…
I improved the docs in , PTAL. Fixing the nftables module, and using less iptables in the firewall module should probably be left to another PR.
I opened to track the nftables NixOS module improvements.


Question: (fetchNuGet { pname = "Humanizer.Core.zh-Hans"; version = "2.14.1"; sha256 = "0zn99311zfn602phxyskfjq9vly0w5712z6fly8r4q0h94qa8c85"; }) (fetchNuGet { pname = "Humanizer.Core.zh-Hant"; version = "2.14.1"; sha256 = "0qxjnbdj645l5sd6y3100yyrq1jy5misswg6xcch06x8jv7zaw1p"; }) (fetchNuGet { pname = "JetBrains.Annotations"; version = "2023.3.0"; sha256 = "0vp4mpn6gfckn8grzjm1jxlbqiq2fglm2rk9wq787adw7rxs8k7w"; }) <del> (fetchNuGet { pname = "Markdig.Signed"; version = "0.33.0"; sha256 = "0816lmn0varxwhdklhh5hdqp0xnfz3nlrvaf2wpkk5v1mq86216h"; }) </del> <ins> (fetchNuGet { pname = "Markdig.Signed"; version = "0.34.0"; sha256 = "1jrs5fc8k99mh1kipvvlgwm0qlacrsh82bbpdclb84xz0h6nwwrh"; }) </ins> (fetchNuGet { pname = "Microsoft.AspNetCore.JsonPatch"; version = "7.0.0"; sha256 = "1f13vsfs1rp9bmdp3khk4mk2fif932d72yxm2wszpsr239x4s2bf"; }) (fetchNuGet { pname = "Microsoft.AspNetCore.Mvc.NewtonsoftJson"; version = "7.0.0"; sha256 = "1w49rg0n5wb1m5wnays2mmym7qy7bsi2b1zxz97af2rkbw3s3hbd"; }) (fetchNuGet { pname = "Microsoft.Bcl.AsyncInterfaces"; version = "6.0.0"; sha256 = "15gqy2m14fdlvy1g59207h5kisznm355kbw010gy19vh47z8gpz3"; }) (fetchNuGet { pname = "Microsoft.CodeCoverage"; version = "17.8.0"; sha256 = "173wjadp3gan4x2jfjchngnc4ca4mb95h1sbb28jydfkfw0z1zvj"; }) (fetchNuGet { pname = "Microsoft.CSharp"; version = "4.7.0"; sha256 = "0gd67zlw554j098kabg887b5a6pq9kzavpa3jjy5w53ccjzjfy8j"; }) (fetchNuGet { pname = "Microsoft.Extensions.ApiDescription.Server"; version = "6.0.5"; sha256 = "1pi2bm3cm0a7jzqzmfc2r7bpcdkmk3hhjfvb2c81j7wl7xdw3624"; }) <del> (fetchNuGet { pname = "Microsoft.Extensions.Configuration.Abstractions"; version = "6.0.0"; sha256 = "0w6wwxv12nbc3sghvr68847wc9skkdgsicrz3fx4chgng1i3xy0j"; }) (fetchNuGet { pname = "Microsoft.Extensions.DependencyInjection"; version = "6.0.0"; sha256 = "1wlhb2vygzfdjbdzy7waxblmrx0q3pdcqvpapnpmq9fcx5m8r6w1"; }) (fetchNuGet { pname = "Microsoft.Extensions.DependencyInjection.Abstractions"; version = "6.0.0"; sha256 = "1vi67fw7q99gj7jd64gnnfr4d2c0ijpva7g9prps48ja6g91x6a9"; }) (fetchNuGet { pname = "Microsoft.Extensions.Logging"; version = "6.0.0"; sha256 = "0fd9jii3y3irfcwlsiww1y9npjgabzarh33rn566wpcz24lijszi"; }) (fetchNuGet { pname = "Microsoft.Extensions.Logging.Abstractions"; version = "6.0.0"; sha256 = "0b75fmins171zi6bfdcq1kcvyrirs8n91mknjnxy4c3ygi1rrnj0"; }) (fetchNuGet { pname = "Microsoft.Extensions.Options"; version = "6.0.0"; sha256 = "008pnk2p50i594ahz308v81a41mbjz9mwcarqhmrjpl2d20c868g"; }) (fetchNuGet { pname = "Microsoft.Extensions.Primitives"; version = "6.0.0"; sha256 = "1kjiw6s4yfz9gm7mx3wkhp06ghnbs95icj9hi505shz9rjrg42q2"; }) </del> <ins> (fetchNuGet { pname = "Microsoft.Extensions.Configuration.Abstractions"; version = "8.0.0"; sha256 = "1jlpa4ggl1gr5fs7fdcw04li3y3iy05w3klr9lrrlc7v8w76kq71"; }) (fetchNuGet { pname = "Microsoft.Extensions.DependencyInjection"; version = "8.0.0"; sha256 = "0i7qziz0iqmbk8zzln7kx9vd0lbx1x3va0yi3j1bgkjir13h78ps"; }) (fetchNuGet { pname = "Microsoft.Extensions.DependencyInjection.Abstractions"; version = "8.0.0"; sha256 = "1zw0bpp5742jzx03wvqc8csnvsbgdqi0ls9jfc5i2vd3cl8b74pg"; }) (fetchNuGet { pname = "Microsoft.Extensions.Logging"; version = "8.0.0"; sha256 = "0nppj34nmq25gnrg0wh1q22y4wdqbih4ax493f226azv8mkp9s1i"; }) (fetchNuGet { pname = "Microsoft.Extensions.Logging.Abstractions"; version = "8.0.0"; sha256 = "1klcqhg3hk55hb6vmjiq2wgqidsl81aldw0li2z98lrwx26msrr6"; }) (fetchNuGet { pname = "Microsoft.Extensions.Options"; version = "8.0.0"; sha256 = "0p50qn6zhinzyhq9sy5svnmqqwhw2jajs2pbjh9sah504wjvhscz"; }) (fetchNuGet { pname = "Microsoft.Extensions.Primitives"; version = "8.0.0"; sha256 = "0aldaz5aapngchgdr7dax9jw5wy7k7hmjgjpfgfv1wfif27jlkqm"; }) </ins> (fetchNuGet { pname = "Microsoft.IdentityModel.Abstractions"; version = "7.0.3"; sha256 = "0njmg2lygnirnfjv9gck2f5lq4ly5rgws9cpf8qj3kwcwxfp0b9s"; }) (fetchNuGet { pname = "Microsoft.IdentityModel.JsonWebTokens"; version = "7.0.3"; sha256 = "1ayh85xqdq8rqjk2iqcn7iaczcl7d8qg6bxk0b4rgx59fmsmbqj7"; }) (fetchNuGet { pname = "Microsoft.IdentityModel.Logging"; version = "7.0.3"; sha256 = "13cjqmf59k895q6gkd5ycl89mnpalckda7rhsdl11jdyr32hsfnv"; }) (fetchNuGet { pname = "Microsoft.IdentityModel.Tokens"; version = "7.0.3"; sha256 = "1pmhd0imh9wlhvbvvwjrpjsqvzagi2ly22nddwr4r0pi234khyz1"; }) <ins> (fetchNuGet { pname = "Microsoft.NET.ILLink.Tasks"; version = "8.0.0"; sha256 = "13y3bilk9rrrgsk9abks7xvpwp12zw150xcyi0diig2hqswys1h4"; }) </ins> (fetchNuGet { pname = "Microsoft.NET.Test.Sdk"; version = "17.8.0"; sha256 = "1syvl3g0hbrcgfi9rq6pld8s8hqqww4dflf1lxn59ccddyyx0gmv"; }) (fetchNuGet { pname = "Microsoft.NETCore.Platforms"; version = "5.0.0"; sha256 = "0mwpwdflidzgzfx2dlpkvvnkgkr2ayaf0s80737h4wa35gaj11rc"; }) (fetchNuGet { pname = "Microsoft.OpenApi"; version = "1.2.3"; sha256 = "07b19k89whj69j87afkz86gp9b3iybw8jqwvlgcn43m7fb2y99rr"; })

Looks like it now uses .NET 8 which probably made all existing plugins incompatible - Package name: ArchiSteamFarm Latest released version: 5.5.0.11 <!-- Search your package here: --- Current version on the unstable channel: 5.4.13.4 Current version on the stable/release channel: 5.4.12.5 <!-- 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! --- Notify maintainers <!-- If the result shows no maintainers, tag the person that last updated the package. --Note for maintainers: Please tag this issue in your PR. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
The package/module has no official way to use plugins, so there is no way to use them unless people are using overlays which should be constructed in a smart way to re-use the same methods as archisteamfarm does. Anyway, here is the update


Question: preConfigure = (concatMapStringsSep "n" (mod: mod.preConfigure or "") modules); <del> patches = stdenv.lib.optionals (stdenv.hostPlatform != stdenv.buildPlatform) [ </del> <ins> patches = stdenv.lib.singleton (substituteAll { src = ./nix-etag-1.15.4.patch; preInstall = '' export nixStoreDir="$NIX_STORE" nixStoreDirLen="''${#NIX_STORE}" ''; }) ++ stdenv.lib.optionals (stdenv.hostPlatform != stdenv.buildPlatform) [ </ins> (fetchpatch { url = "https://raw.githubusercontent.com/openwrt/packages/master/net/nginx/patches/102-sizeof_test_fix.patch"; sha256 = "0i2k30ac8d7inj9l6bl0684kjglam2f68z8lf3xggcc2i5wzhh8a";

If you serve files from , nginx will set last-modified header to unix timestamp 1. The result is that browser will cache indefinitely. Not sure what we should do about it really, following nginx configuration helps:
Why do you need to turn etag off?
Ah, I see. nginx's etags aren't hashes.
I wonder if we could find a way to pull the hash out of the nix store path and put it into an etag header.
Thanks for finding this. I've been having issues with broken caching on my nginx/nixos server. Even when the files on the server were updated (files in the nix store), the browser was told that no change had happened. If I'm understanding this correctly, since nginx's etags are based on filesystem modification time; you can't have proper cache invalidation (ie. it will always send 304 not modified). Or is there a workaround?
+1 this is a problem. And turning off etag seems like overkill. Is there some way to 1) set the date on a file so that Nginx can pick it up, or 2) do something else awesome?
Is the zero-timestamp rule set in stone in Nix, or is there some way to override it if you really want a file in /nix/store to have a particular timestamp?
I think we could get away with: It's not perfect, as it will change on each Nix evaluation instead of being content addressed. Another way would be to turn the store path passed to nginx directive to translate into an etag.
The etag function is at called from and . Making it dependent on the realpath of the file seems doable.
Explanation how to configure nginx to use the hash from the nix path:
In my testing, this sends the correct etag, but does not send the 304 not modified, when the etag matches. Also, the header gets stripped out when compression is enabled.
It's working perfectly for me. I've gzip compression enabled, the etag header is sent and the browser gets a 304 when querying the header.
Nice! An example with a directory would be more common:
I've to correct what I said. your statement seems to be correct. What happens in my case is that Cloudflare is actually handling the caching of the ETag correctly, not nginx.


Question: preConfigure = (concatMapStringsSep "n" (mod: mod.preConfigure or "") modules); <del> patches = stdenv.lib.optionals (stdenv.hostPlatform != stdenv.buildPlatform) [ </del> <ins> patches = stdenv.lib.singleton (substituteAll { src = ./nix-etag-1.15.4.patch; preInstall = '' export nixStoreDir="$NIX_STORE" nixStoreDirLen="''${#NIX_STORE}" ''; }) ++ stdenv.lib.optionals (stdenv.hostPlatform != stdenv.buildPlatform) [ </ins> (fetchpatch { url = "https://raw.githubusercontent.com/openwrt/packages/master/net/nginx/patches/102-sizeof_test_fix.patch"; sha256 = "0i2k30ac8d7inj9l6bl0684kjglam2f68z8lf3xggcc2i5wzhh8a";

So this approach is completely useless without external caching. I'll investigate further and see if I can come up with a solution.
Here is a patch: If real path (after dereferencing symlinks) of is in Nix store, it will use path's hash as ETag. For example: I'll take some time to double check everything and only then send a PR. However, feel free to test: nix { pkgs, ... }: { = { enable = true; package = with pkgs; nginx.overrideAttrs (super: { patches = (super.patches or []) ++ [(fetchpatch { url = ; sha256 = "16pa1vwcm7kibkjsxpk3szaa2vnxdinml6v0fp4038i2qaav113k"; })]; }); }; }
This is really great! or anyone, do you have a moment to write an explanation of this new feature and its practical ramifications for anyone configuring an nginx server? Since it isn't typical nginx behavior, I think the nixos manual should explain it somewhere so it doesn't catch people by surprise.
I think is a good explanation, just needs to be put into the manual.
Cool, submitted .


Question: }; }; }) <ins> (mkIf (cfg.enable && cfg.prompt.enable) { environment.interactiveShellInit = '' source ${cfg.package}/share/bash-completion/completions/git-prompt.sh ''; }) </ins> ]; meta.maintainers = with maintainers; [ figsoda ];

git package includes which defines functions for shell prompt customization like . Even though the file is included it's not sourced by default and doesn't make the functions available. Steps to reproduce the behavior: package system-wide. one of the functions provided: the file manually: function becomes available: shell function being available out of the box when package installed. Making the prompt functions available when bash completions are enabled seem to have been the original intention of . However one might also argue that the functions should not be sourced by default if someone doesn't use git prompt customisations provided. It could be placed behind an option but I'm not sure it's worth the hassle. cc
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
I'm not a maintainer or expert, but I read your linked Discourse thread and your ticket because it sounded interesting. Great analysis and writeup. My interpretation is that was never intended to be sourced automatically when completions are enabled, for two reasons. First, inside of : which is an instruction to source it explicitly. Second, the for says: which leads me to believe that was created so that it can be used independently from bash completion. Prior to its creation, it might have been available automatically as a consequence of completion scripts being loaded eagerly, but that was accidental.
Thanks for digging deeper into this, Theodore! I agree with your conclusion: it does look like the prompt script wasn't intended to be sourced automatically. I think the best way to approach this in NixOS would be to have a option that would enable sourcing of the file.
I think something like this sounds reasonable. I'm sorry I can't help with it right now, because I haven't set up NixOS yet. (I'm just using nix on my Mac right now.)
No worries, thanks for your help so far :) I might eventually give it a shot myself.


Question: with lib; <del> # The Magewell Pro Capture drivers are not supported for kernels older than 3.2 assert versionAtLeast kernel.version "3.2.0"; </del> let bits = if stdenv.is64bit then "64"

I'm trying to use the mwprocapture nixos module (which uses the mwprocapture kernel package) on 20.09 (linuxPackageslatest), and I get the following: Is this known and/or already fixed somewhere? (Also, is it safe to use it anyways?) I'd love to try and fix it further myself, but I don't know how to splice in a local/development nix file into my for development purposes :sweatsmile: (also CC
Looks like upgrading the package version resolved things. Will create a PR soon.
Thanks for the heads up.


Question: typst = callPackage ../tools/typesetting/typst { }; <ins> typst-fmt = callPackage ../tools/typesetting/typst-fmt { }; </ins> tz = callPackage ../tools/misc/tz { }; u9fs = callPackage ../servers/u9fs { };

Project description Formatter for typst. Metadata homepage URL: source URL: license: mit, bsd, gpl2+ , ... platforms: unix, linux, darwin, ...
There is no CLI:
Looks like the author use .
looks like it is still a WIP in
what do you mean wrong default branch? Hi there, I wasn't sure there was interest for a cli, I'll merge the cli in a few days, want a ping then?
I merged my change, it should be good to package!
has renamed the project from typst-fmt to typstfmt in


Question: makeCacheWritable = true; npmWorkspace = "apps/desktop"; <del> npmDepsHash = "sha256-KN8C9Y0tfhHVagk+CUMpI/bIRChhzxC9M27HkU4aTEc="; </del> <ins> npmDepsHash = "sha256-bnYpvHO9Pnob+MbrSshv03mSwXCADH/2xw33nLVKMdg="; </ins> cargoDeps = rustPlatform.fetchCargoTarball { name = "${pname}-${version}"; inherit patches src; patchFlags = [ "-p4" ]; sourceRoot = "${src.name}/${cargoRoot}"; <del> hash = "sha256-AmtdmOR3aZJTZiFbkwRXjeTOJdcN40bTmWx4Ss3JNJ8="; </del> <ins> hash = "sha256-pCy3hGhI3mXm4uTOaFMykOzJqK2PC0t0hE8MrJKtA/k="; </ins> }; cargoRoot = "apps/desktop/desktop_native";

Steps to reproduce the behavior: bitwarden Please run and paste the result.
Will be fixed by


Question: orgmode-parse = dontCheck super.orgmode-parse; os-release = dontCheck super.os-release; persistent-redis = dontCheck super.persistent-redis; <ins> pure-zlib = dontCheck super.pure-zlib; # https://github.com/NixOS/nixpkgs/issues/37499 </ins> pipes-extra = dontCheck super.pipes-extra; pipes-websockets = dontCheck super.pipes-websockets; postgresql-binary = dontCheck super.postgresql-binary; # needs a running postgresql server

The package fails to build because of missing test dependencies: system: host os: multi-user?: sandbox: version: channels(z0028sn): nixpkgs:
I jailbroke it and the the tests fail anyway. So it should be set to . succeeds.
The problem is that the release tarball on Hackage is incomplete, i.e. the required file appears to be missing. This should be reported upstream () so that they can release a fixed version. Ping:
This should be fixed in 0.6.1, which I just uploaded to Hackage. Please tell me (probably on a pure-zlib ticket?) if you have any further problems.


Question: inherit (pkgs) stdenv fetchurl unzip; }; <ins> sources = import ./sources.nix { inherit (pkgs) stdenv fetchurl unzip; }; </ins> androidsdk = import ./androidsdk.nix { inherit (pkgs) stdenv fetchurl unzip makeWrapper; inherit (pkgs) zlib glxinfo freetype fontconfig glib gtk2 atk mesa file alsaLib jdk coreutils libpulseaudio dbus; inherit (pkgs.xorg) libX11 libXext libXrender libxcb libXau libXdmcp libXtst xkeyboardconfig; <del> inherit platformTools buildTools support supportRepository platforms sysimages addons; </del> <ins> inherit platformTools buildTools support supportRepository platforms sysimages addons sources includeSources; </ins> stdenv_32bit = pkgs_i686.stdenv; };

Currently, our Android SDK derivations contain only binary files. This is unfortunate during development, when one wants to jump to a definition of a particular symbol in the SDK and it is not found. For comparison, ArchLinux is doing this in their packages, e.g. System: 16.09pre-git (Flounder) Nix version: nix-env (Nix) 1.11.4 Nixpkgs version: "16.09beta335." /cc
Created PR .


Question: stdenv.mkDerivation { pname = "mmc-utils"; <del> version = "2018-12-14"; </del> <ins> version = "2019-10-04"; </ins> src = fetchgit { url = "git://git.kernel.org/pub/scm/linux/kernel/git/cjb/mmc-utils.git"; <del> rev = "aef913e31b659462fe6b9320d241676cba97f67b"; sha256 = "1mak9rqjp6yvqk2h5hfil5a9gfx138h62n3cryckfbhr6fmaylm7"; </del> <ins> rev = "73d6c59af8d1bcedf5de4aa1f5d5b7f765f545f5"; sha256 = "18a7qm86gavg15gv4h6xfnapgq24v4dyvhwfp53lkssxyhjbli0z"; </ins> }; makeFlags = [ "CC=${stdenv.cc.targetPrefix}cc" ];

Describe the bug While Nixpkgs provides version 2018-12-14, there are some fixes landed since then. Notify maintainers Metadata system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Maintainer information:
can please check using with a local chekout of nixpkgs?
Yes, I will. Thank you for your prompt response!
I did and tried some commands. It seems to work fine and the store size does not grow significantly. Is there anything else to test?


Question: <ins> { lib, rustPlatform, fetchFromGitHub, libdrm }: rustPlatform.buildRustPackage rec { pname = "amdgpu_top"; version = "0.1.7"; src = fetchFromGitHub { owner = "Umio-Yasuno"; repo = pname; rev = "v${version}-stable"; hash = "sha256-cdKUj0pUlXxMNx0jypuov4hX3CISTDaSQh+KFB5R8ys="; }; cargoLock.lockFile = ./Cargo.lock; buildInputs = [ libdrm ]; meta = with lib; { description = "Tool to display AMDGPU usage"; homepage = "https://github.com/Umio-Yasuno/amdgpu_top"; changelog = "https://github.com/Umio-Yasuno/amdgpu_top/releases"; license = licenses.mit; maintainers = with maintainers; [ geri1701 ]; }; } </ins>

Project description amdgputop is tool that display AMD GPU utilization, like or . The tool displays information gathered from performance counters (GRBM, GRBM2, CPSTAT), sensors, fdinfo, and AMDGPU driver. Presumably it wouldn't depend on as does, and it's written in that one language. :lobster: Metadata homepage URL: source URL: license: mit platforms: linux


Question: runHook postInstall ''; <ins> checkPhase = attrs.checkPhase or '' runHook preCheck $LUAROCKS test runHook postCheck ''; </ins> passthru = { inherit lua; # The lua interpreter inherit externalDeps;

Describe the bug neovim fails to build with missing , similar to , on . To Reproduce Steps to reproduce the behavior: to from master () Expected behavior The package should successfully build. Metadata On master () Maintainer information:
via in
so you could do until a proper fix.
Reverting the luarocks bump doesn't work for me. That fix is also very surprising to me, since neovim broke (for me) after the latest nixos-unstable channel update.
Interesting. It worked fine for me. Running the above revert command and then (inside my local nixpkgs with it reverted) let me build neovim properly. I don't think it's particularly surprising if updating a channel that happens to include the luarocks bump causes it to break, unless I'm misunderstanding you.
I updated from a channel where the luarocks bump had already happened, and neovim worked on that channel. In fact, I reverted to the previous hydra evaluation to make my system evaluate again.
This was actually before and it was working without problems and then suddenly the problem appeared again. I can also report that I cam getting this in the same way described (updated latest nixos-unstable channel and then neovim stopped building again).
I confirm this fixed by on master (channels may take a while). For now I'll assume that charvp's failure to resolve the issue with that revert was some kind of mistake; we can re-open otherwise, perhaps separately if it's a different kind of error.
Does anyone know why updating the luarocks dependency is so brittle? Is it possible to at least add a test so we don't regress again in the future?
the tool exists (nixpkgs-review) but it takes CPU and disk space to run plus some reviewer time (and was not run in this case). Also for this specific case, the luarocks update broke in subtle ways the build so I wouldn't call it . It is called unstable for a reason. The good thing about nixpkgs is you can pin neovim to an older version while keeping your system on unstable.
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Are we sure this is fixed on Darwin? still shows failing with logs of: Or is this a different issue?


Question: runHook postInstall ''; <ins> checkPhase = attrs.checkPhase or '' runHook preCheck $LUAROCKS test runHook postCheck ''; </ins> passthru = { inherit lua; # The lua interpreter inherit externalDeps;

I think the root problem here is that luarocks has a poor implementation of "move". Combined with the build's behavior being affected by filesystem ordering the result is essentially random. The [implementation of move][] calls out to the operating system commands [][] and [][]. Building with will contain a sequence of , and . I've extracted the [relevant part of the log][]. The critical aspect here is that by default, unix will dereference symlinks and copy their contents. [implementation of move]: []: []: [relevant part of the log]: My theory: luarocks scans the directory for external libraries in filesystem order and attempts to move all shared libraries from to . At which point one of 3! things will happen, but the two main ones are: is copied and deleted and , now broken symlinks, fail to copy and are copied by dereferencing, and deleted is copied and deleted Either way is wrong to some degree, but one of them happens to work well enough for downstream packages to build. If I build locally, the filesystem order I get seems to work, so we can inspect the two results: I've been focusing on this for darwin since the failure case happens to be cached, but I believe it applies equally to linux.
is that sthg you have already witnessed ?
What LuaRocks version is this happening with? I have pushed fixes related to the file deployment stage in 3.3.1.
I've tested 3.2.1 (current nixpkgs master) and 3.3.1 (hasty upgrade locally), they both have similar results, except on 3.3.1 the errors now propagate correctly. I've uploaded a [log of a failed build][] with 3.3.1. [log of a failed build]:
I was hoping to find time to write a proper issue report and a test lua package for this, but haven't yet. My test case would have a directory structure made with , that looks like: In order to succeed the deployment stage would have to produce both the file and its symlink.


Question: runHook postInstall ''; <ins> checkPhase = attrs.checkPhase or '' runHook preCheck $LUAROCKS test runHook postCheck ''; </ins> passthru = { inherit lua; # The lua interpreter inherit externalDeps;

Describe the bug I have neovim in my systemPackages, I did and today and it stuck at building luajit: To Reproduce Steps to reproduce the behavior: to Expected behavior The system should upgrade properly. Additional context Output: Metadata system: host os: multi-user?: sandbox: version: channels(root): channels(kj): nixpkgs: Maintainer information:
Possible fix is in . There was already an open issue about it () but from an unclear reason people have reached the conclusion it was fixed on latest master.
Oh I meant , not .
Well, I agree with that conclusion. For me, on the build is broken with the error above and on current master it isn't. EDIT: note that the channels lag behind, usually less than a couple days, but sometimes we get a week or two due to some harder regression.
Yea right. For me on NixOS I tried with the nixpkgs-unstable channel and could install successfully. The nixos-unstable still fails though.


Question: license = stdenv.lib.licenses.gpl3Plus; maintainers = with stdenv.lib.maintainers; [raskin]; description = "Scientific Pragramming Language"; <ins> # https://savannah.gnu.org/bugs/?func=detailitem&item_id=56425 is the best attempt to fix JIT broken = enableJIT; </ins> platforms = if overridePlatforms == null then (with stdenv.lib.platforms; linux ++ darwin) else overridePlatforms;

I'm trying to build octave with QT5 and with GUI (of course, when I try to build it with GUI, right?). Unfortunately, after the build: Apply this patch: and then system: host os: multi-user?: sandbox: version: channels(m): nixpkgs:
I just noticed that I do not even get the GUI feature when building octave from nixpkgs (neither nor has a GUI).
Pinging: touched the package recently, is the maintainer of the package.
I’ll try to have a look when I have some time. I’ll let you know what I can achieve.
Here is what the configure script says:
yes, I got that and I fixed it. See for my attempt to build with Qt5 (which succeeds, but starting octave with gui fails - see PR).


Question: exit 1 fi <del> VERSION=$1 </del> <ins> VERSION="$1" </ins> declare -A SYSTEMS HASHES SYSTEMS=(

Element v1.11.0 updated to Electron 19, so we need this packaged in Nixpkgs: <!-- 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: <!-- 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: 18.1.0 desired version: 19.0.7 <!-- 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.
When I run the script tries to download which does not exist. Do you know where to get the electron headers?
PR that brings electron19 but does not provide electron19 headers:
I believe that states that they migrated storage. So, I think the new url would be
Great find, thanks! Updated PR to include this change and electron_19 now provides the headers.
electrum_19 to master via - feel free to update your package


Question: <del> { lib, buildPythonPackage, fetchPypi }: </del> <ins> { lib , buildPythonPackage , fetchFromGitHub , pytestCheckHook }: </ins> buildPythonPackage rec { pname = "sarge"; version = "0.1.7"; <ins> format = "setuptools"; </ins> <del> src = fetchPypi { inherit pname version; sha256 = "3b810d396a75a5a2805272f64f4316f6dcc086e0a744b042cdb0effc85c0f21b"; </del> <ins> src = fetchFromGitHub { owner = "vsajip"; repo = pname; rev = version; sha256 = "sha256-E1alSDXj0oeyB6dN5PAtN62FPpMsCKb4R9DpfWdFtn0="; </ins> }; <del> # No tests in PyPI tarball doCheck = false; </del> <ins> checkInputs = [ pytestCheckHook ]; pythonImportsCheck = [ "sarge" ]; </ins> meta = with lib; { <ins> description = "Python wrapper for subprocess which provides command pipeline functionality"; </ins> homepage = "https://sarge.readthedocs.org/"; <del> description = "A wrapper for subprocess which provides command pipeline functionality"; </del> license = licenses.bsd3; maintainers = with maintainers; [ abbradar ]; };

Octoprint can't build on unstable due to a conflict of the required version for . octoprint , while the dependency requires (due to ) . Octoprint builds successfully I ran a between and (known good) , the first bad commit was I suspect that it's necessary to pin the additional dependencies (and maybe some more), too, but I'm not that experienced with packaging python packages. made the first bad commit Octoprint maintainers: system: host os: multi-user?: sandbox: version: channels(root): channels(richard): nixpkgs: Maintainer information:


Question: <ins> { stdenv , lib , buildGoModule , fetchFromGitHub , makeWrapper , coreutils , runCommand , runtimeShell , writeText , terraform-providers , installShellFiles }: let package =  buildGoModule rec { pname = "opentofu"; version = "1.6.0-alpha1"; src = fetchFromGitHub { owner = "opentofu"; repo = "opentofu"; rev = "v${version}"; hash = "sha256-0FO55H1nOyhAd+ex1zA0XycH6x/HKkLlxzuIJNoaI9g="; }; vendorHash = "sha256-3jQfIIZOgOmNHQ06rXz+3QTZ37WcuCc7A7/MhC7udrg="; ldflags = [ "-s" "-w" ]; postConfigure = '' # speakeasy hardcodes /bin/stty https://github.com/bgentry/speakeasy/issues/22 substituteInPlace vendor/github.com/bgentry/speakeasy/speakeasy_unix.go  --replace "/bin/stty" "${coreutils}/bin/stty" ''; nativeBuildInputs = [ installShellFiles ]; patches = [ ./provider-path-0_15.patch ]; passthru = { inherit plugins withPlugins; tests = { inherit opentofu_plugins_test; }; }; # https://github.com/posener/complete/blob/9a4745ac49b29530e07dc2581745a218b646b7a3/cmd/install/bash.go#L8 postInstall = '' installShellCompletion --bash --name tofu <(echo complete -C tofu tofu) ''; preCheck = '' export HOME=$TMPDIR export TF_SKIP_REMOTE_TESTS=1 ''; subPackages = [ "./cmd/..." ]; meta = with lib; { description = "Tool for building, changing, and versioning infrastructure"; homepage = "https://opentofu.org/"; changelog = "https://github.com/opentofu/opentofu/blob/v${version}/CHANGELOG.md"; license = licenses.mpl20; maintainers = with maintainers; [ gmemstr ]; mainProgram = "tofu"; }; }; opentofu_plugins_test = let mainTf = writeText "main.tf" '' resource "random_id" "test" {} ''; opentofu = package.withPlugins (p: [ p.random ]); test = runCommand "opentofu-plugin-test" { buildInputs = [ opentofu ]; } '' # make it fail outside of sandbox export HTTP_PROXY=http://127.0.0.1:0 HTTPS_PROXY=https://127.0.0.1:0 cp ${mainTf} main.tf tofu init touch $out ''; in test; plugins = removeAttrs terraform-providers [ "override" "overrideDerivation" "recurseForDerivations" ]; withPlugins = plugins: let actualPlugins = plugins package.plugins; # Wrap PATH of plugins propagatedBuildInputs, plugins may have runtime dependencies on external binaries wrapperInputs = lib.unique (lib.flatten (lib.catAttrs "propagatedBuildInputs" (builtins.filter (x: x != null) actualPlugins))); passthru = { withPlugins = newplugins: withPlugins (x: newplugins x ++ actualPlugins); full = withPlugins (p: lib.filter lib.isDerivation (lib.attrValues p.actualProviders)); # Expose wrappers around the override* functions of the terraform # derivation. # # Note that this does not behave as anyone would expect if plugins # are specified. The overrides are not on the user-visible wrapper # derivation but instead on the function application that eventually # generates the wrapper. This means: # # 1. When using overrideAttrs, only `passthru` attributes will #    become visible on the wrapper derivation. Other overrides that #    modify the derivation *may* still have an effect, but it can be #    difficult to follow. # # 2. Other overrides may work if they modify the terraform #    derivation, or they may have no effect, depending on what #    exactly is being changed. # # 3. Specifying overrides on the wrapper is unsupported. # # See nixpkgs#158620 for details. overrideDerivation = f: (package.overrideDerivation f).withPlugins plugins; overrideAttrs = f: (package.overrideAttrs f).withPlugins plugins; override = x: (package.override x).withPlugins plugins; }; # Don't bother wrapping unless we actually have plugins, since the wrapper will stop automatic downloading # of plugins, which might be counterintuitive if someone just wants a vanilla Terraform. in if actualPlugins == [ ] then package.overrideAttrs (orig: { passthru = orig.passthru // passthru; }) else lib.appendToName "with-plugins" (stdenv.mkDerivation { inherit (package) meta pname version; nativeBuildInputs = [ makeWrapper ]; # Expose the passthru set with the override functions # defined above, as well as any passthru values already # set on `terraform` at this point (relevant in case a # user overrides attributes). passthru = package.passthru // passthru; buildCommand = '' # Create wrappers for terraform plugins because Terraform only # walks inside of a tree of files. for providerDir in ${toString actualPlugins} do for file in $(find $providerDir/libexec/terraform-providers -type f) do relFile=''${file#$providerDir/} mkdir -p $out/$(dirname $relFile) cat <<WRAPPER > $out/$relFile #!${runtimeShell} exec "$file" "$@" WRAPPER chmod +x $out/$relFile done done # Create a wrapper for opentofu to point it to the plugins dir. mkdir -p $out/bin/ makeWrapper "${package}/bin/tofu" "$out/bin/tofu"  --set NIX_TERRAFORM_PLUGIN_DIR $out/libexec/terraform-providers  --prefix PATH : "${lib.makeBinPath wrapperInputs}" ''; }); in package </ins>

Project description OpenTofu is a fork of Terraform, which is no longer under a free license (and should be marked as unfree for releases = 1.6.0). This fork is from the free sources before the license change to a source-available BSL license. Metadata homepage URL: source URL: license: mpl platforms: unix
cc some active maintainers of terraform:
Related issue:
I think it would be a good idea to wait for it to be actually named, see OpenTF is a placeholder name, and at this point OpenTF didn't release an alpha.
Will to take this on later today if nobody else grabs it.
Pull request has been opened, if the current Terraform maintainers are okay with it I can add them to the maintainers section of the new package. Otherwise more than happy to take responsibility for it.


Question: fribidi p11-kit <ins> gmp </ins> # libraries not on the upstream include list, but nevertheless expected # by at least one appimage libtool.lib # for Synfigstudio

Describe the bug AppImages assume that the gmp library is present on the system, but appimage-run does not include gmp. To Reproduce Steps to reproduce the behavior: +x the appimage Expected behavior The app should run. Additional context I believe it is because of this commit: I fixed it on my end with: Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Metadata system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Maintainer information:
I marked this as stale due to inactivity. →
not stale
Also affected:
as pointed out by t-paul, appimage specifically assumes GMP is provided by the system


Question: ogre = ogre1_10; }; <del> certbot = callPackage ../tools/admin/certbot { }; </del> <ins> certbot = python3Packages.callPackage ../tools/admin/certbot { }; </ins> caf = callPackage ../development/libraries/caf {};

Update certbot Current packaged version is 0.39.0, upstream version is 1.2.0.
Fix in


Question: <ins> { lib, python3Packages, fetchFromGitHub, glibc, SDL2, libjpeg_turbo, alsa-lib, libspnav, desktop-file-utils, gobject-introspection, wrapGAppsHook3, wrapGAppsHook4, cameractrls-gtk3, cameractrls-gtk4, withGtk ? null, }: assert lib.assertOneOf "'withGtk' in cameractrls" withGtk [ 3 4 null ]; let mainExecutable = "cameractrls" + lib.optionalString (withGtk != null) "gtk" + lib.optionalString (withGtk == 4) "4"; modulePath = "${placeholder "out"}/${python3Packages.python.sitePackages}/CameraCtrls"; installExecutables = [ "cameractrls" "cameractrlsd" "cameraptzgame" "cameraptzmidi" "cameraptzspnav" "cameraview" ] ++ lib.optionals (withGtk != null) [ mainExecutable ]; in python3Packages.buildPythonApplication rec { pname = "cameractrls"; version = "0.6.6"; pyproject = false; src = fetchFromGitHub { owner = "soyersoyer"; repo = "cameractrls"; rev = "v${version}"; hash = "sha256-QjjLd5L+8Slxc3ywurhsWp1pZ2E1Y7NOdnCV2ZYBlqU="; }; postPatch = '' substituteInPlace cameractrlsd.py  --replace-fail "ctypes.util.find_library('c')" '"${lib.getLib glibc}/lib/libc.so.6"' substituteInPlace cameraptzgame.py cameraview.py  --replace-fail "ctypes.util.find_library('SDL2-2.0')" '"${lib.getLib SDL2}/lib/libSDL2-2.0.so.0"' substituteInPlace cameraview.py  --replace-fail "ctypes.util.find_library('turbojpeg')" '"${lib.getLib libjpeg_turbo}/lib/libturbojpeg.so"' substituteInPlace cameraptzmidi.py  --replace-fail "ctypes.util.find_library('asound')" '"${lib.getLib alsa-lib}/lib/libasound.so"' substituteInPlace cameraptzspnav.py  --replace-fail "ctypes.util.find_library('spnav')" '"${lib.getLib libspnav}/lib/libspnav.so"' ''; nativeBuildInputs = lib.optionals (withGtk != null) [ desktop-file-utils gobject-introspection ] ++ lib.optionals (withGtk == 3) [ wrapGAppsHook3 ] ++ lib.optionals (withGtk == 4) [ wrapGAppsHook4 ]; # Only used when withGtk != null dependencies = with python3Packages; [ pygobject3 ]; installPhase = '' runHook preInstall mkdir -p $out/bin for file in ${lib.concatStringsSep " " installExecutables}; do install -Dm755 $file.py -t ${modulePath} ln -s ${modulePath}/$file.py $out/bin/$file done '' + lib.optionalString (withGtk != null) '' install -Dm644 pkg/hu.irl.cameractrls.svg -t $out/share/icons/hicolor/scalable/apps install -Dm644 pkg/hu.irl.cameractrls.metainfo.xml -t $out/share/metainfo mkdir -p $out/share/applications desktop-file-install  --dir="$out/share/applications"  --set-key=Exec --set-value="${mainExecutable}"  pkg/hu.irl.cameractrls.desktop '' + '' runHook postInstall ''; dontWrapGApps = true; dontWrapPythonPrograms = true; postFixup = lib.optionalString (withGtk != null) '' wrapPythonPrograms patchPythonScript ${modulePath}/${mainExecutable}.py wrapProgram $out/bin/${mainExecutable} ''${makeWrapperArgs[@]} ''${gappsWrapperArgs[@]} ''; passthru.tests = { # Also build these packages in ofBorg (defined in top-level/all-packages.nix) inherit cameractrls-gtk3 cameractrls-gtk4; }; meta = { description = "Camera controls for Linux"; longDescription = '' It's a standalone Python CLI and GUI (GTK3, GTK4) and camera Viewer (SDL) to set the camera controls in Linux. It can set the V4L2 controls and it is extendable with the non standard controls. Currently it has a Logitech extension (LED mode, LED frequency, BRIO FoV, Relative Pan/Tilt, PTZ presets), Kiyo Pro extension (HDR, HDR mode, FoV, AF mode, Save), Preset extension (Save and restore controls), Control Restore Daemon (to restore presets at device connection). ''; homepage = "https://github.com/soyersoyer/cameractrls"; license = lib.licenses.gpl3Plus; mainProgram = mainExecutable; maintainers = with lib.maintainers; [ aleksana ]; platforms = lib.platforms.linux; }; } </ins>

Project description cameractrls is a UI for v4l camera settings, like pan/tilt/... on fancy Logitech cameras. Metadata homepage URL: source URL: license: MIT platforms: Linux
Here's a prototype:
I'm using this successfully with the latest version,
Is there any progress with this request?
Please test my PR I don't have the device.
Tbh, I would like to, but I don't know how to test a custom package...
For new CLI: Or
I executed and then nothing happened... I can also not find cameractrls
Check your current directory, there's a symlink to store, and the executable is in
I only tested the gui app and it seems to work fine!
Thanks! What about the others executables? Have you tested all the functionality of the app?
I can only test the the GUI, because I don't know how to use the CLI program. But the GUI is working fine, afaict.


Question: rustPlatform.buildRustPackage rec { pname = "racer"; <del> version = "2.1.22"; </del> <ins> version = "2.1.27"; </ins> src = fetchFromGitHub { owner = "racer-rust"; repo = "racer"; rev = "v${version}"; <del> sha256 = "1n808h4jqxkvpjwmj8jgi4y5is5zvr8vn42mwb3yi13mix32cysa"; </del> <ins> sha256 = "1ajj515ck5n0mzig77xnq1qgb2s4gf6ahgd5mab91406jvij9qf3"; </ins> }; <del> cargoSha256 = "0njaa9vk2i9g1c6sq20b7ls97nl532rfv3is7d8dwz51nrwk6jxs"; </del> <ins> cargoSha256 = "0ki5j5gh59c92a0w43kzljpiamv2jvyk4m2w8qldfyl5kaa40dxb"; </ins> buildInputs = [ makeWrapper ] ++ stdenv.lib.optional stdenv.isDarwin Security;

Current version of rustracer 2.1.22 does not build with latest stable rust (see ). Please update rustracer to the newest version 2.1.27


Question: ]; checkInputs = [ pytestCheckHook ]; <del> disabledTests = [ # Steam runtime is hard-coded with steam-run.patch and can't be configured "test_run_steam_runtime_not_found" "test_unknown_steam_runtime_detected" # Steam runtime 2 currently isn't supported # See https://github.com/NixOS/nixpkgs/issues/100655 "test_run_winetricks_steam_runtime_v2" ]; </del> <ins> pythonImportsCheck = [ "protontricks" ]; </ins> meta = with lib; { description = "A simple wrapper for running Winetricks commands for Proton-enabled games";

This issue is mainly a note to myself since the upgrade won't be trivial and will need a lot of testing. Protontricks is now using the Pressure Vessel runtime, so I have to refactor my patches with steam-run to account for this. <!-- 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 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: protontricks <!-- The current version can be found easily with the same process than 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.4.4 desired version: 1.5.0 <!-- Search your package here: If no maintainer is listed for your package, tag the person that last updated the package --maintainers: myself


Question: <ins> { lib, rustPlatform, fetchFromGitHub }: rustPlatform.buildRustPackage rec { pname = "gobang"; version = "0.1.0-alpha.5"; src = fetchFromGitHub { owner = "tako8ki"; repo = pname; rev = "v${version}"; sha256 = "02glb3hlprpdc72ji0248a7g0vr36yxr0gfbbms2m25v251dyaa6"; }; cargoSha256 = "sha256-Tiefet5gLpiuYY6Scg5fjnaPiZfVl5Gy2oZFdhgNRxY="; meta = with lib; { description = "A cross-platform TUI database management tool written in Rust"; homepage = "https://github.com/tako8ki/gobang"; license = licenses.mit; maintainers = with maintainers; [ figsoda ]; }; } </ins>

Project description A cross-platform TUI database management tool written in Rust Metadata homepage URL: source URL: license: mit platforms: unix


Question: <del> <section xmlns="http://docbook.org/ns/docbook" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:xi="http://www.w3.org/2001/XInclude" xml:id="sec-pkgs-ociTools"> <title>pkgs.ociTools</title> <para> <varname>pkgs.ociTools</varname> is a set of functions for creating containers according to the <link xlink:href="https://github.com/opencontainers/runtime-spec">OCI container specification v1.0.0</link>. Beyond that it makes no assumptions about the container runner you choose to use to run the created container. </para> <section xml:id="ssec-pkgs-ociTools-buildContainer"> <title>buildContainer</title> <para> This function creates a simple OCI container that runs a single command inside of it. An OCI container consists of a <varname>config.json</varname> and a rootfs directory.The nix store of the container will contain all referenced dependencies of the given command. </para> <para> The parameters of <varname>buildContainer</varname> with an example value are described below: </para> <example xml:id='ex-ociTools-buildContainer'> <title>Build Container</title> <programlisting> buildContainer { args = [ (with pkgs; writeScript "run.sh" '' #!${bash}/bin/bash exec ${bash}/bin/bash '').outPath ]; <co xml:id='ex-ociTools-buildContainer-1' /> mounts = { "/data" = { type = "none"; source = "/var/lib/mydata"; options = [ "bind" ]; }; };<co xml:id='ex-ociTools-buildContainer-2' /> readonly = false; <co xml:id='ex-ociTools-buildContainer-3' /> } </programlisting> <calloutlist> <callout arearefs='ex-ociTools-buildContainer-1'> <para> <varname>args</varname> specifies a set of arguments to run inside the container. This is the only required argument for <varname>buildContainer</varname>. All referenced packages inside the derivation will be made available inside the container </para> </callout> <callout arearefs='ex-ociTools-buildContainer-2'> <para> <varname>mounts</varname> specifies additional mount points chosen by the user. By default only a minimal set of necessary filesystems are mounted into the container (e.g procfs, cgroupfs) </para> </callout> <callout arearefs='ex-ociTools-buildContainer-3'> <para> <varname>readonly</varname> makes the container's rootfs read-only if it is set to true. The default value is false <literal>false</literal>. </para> </callout> </calloutlist> </example> </section> </section> </del>

This issue tracks the conversion of from Docbook to CommonMark per . If you intend to work on this conversion, please comment below! here that you intend to work on it. (Please also post if you stop working on it.) a new branch of nixpkgs master. : change to . to . the contents from Docbook to . Follow . Use existing sections for inspiration. from the folder to build the manual. the manual on your computer at after running from folder: it looks good, submit a PR and reference this issue.
Hi Already opened a PR for that ().


Question: # NAT from external ports to internal ports. ${concatMapStrings (fwd: '' iptables -w -t nat -A nixos-nat-pre  <del> -i ${cfg.externalInterface} -p tcp  </del> <ins> -i ${cfg.externalInterface} -p ${fwd.proto}  </ins> --dport ${builtins.toString fwd.sourcePort}  -j DNAT --to-destination ${fwd.destination} '') cfg.forwardPorts}

Should there be an ability to specify UDP port forwarding in the nat module? It would necessitate an extra property in the forwarding list specification, like .
Has done this!


Question: sha256 = "02pihqb1lb76a0xbfwjzs1cd6ay3ldfxsm8dvsbl6qs3vkjxax56"; }; <del> patchPhase = stdenv.lib.optionalString stdenv.cc.isClang '' </del> <ins> patches = [ ./gfan-0.6.2-cddlib-prefix.patch ]; postPatch = stdenv.lib.optionalString stdenv.cc.isClang '' </ins> substituteInPlace Makefile --replace "-fno-guess-branch-probability" "" ''; <del> buildFlags = [ "CC=cc" "CXX=c++" "cddnoprefix=1" ]; </del> <ins> buildFlags = [ "CC=cc" "CXX=c++" ]; </ins> installFlags = [ ''PREFIX=$(out)'' ]; buildInputs = [ gmp mpir cddlib ];

Describe the bug Building fails with the following messages: Note that points to which updates . To Reproduce Steps to reproduce the behavior: Expected behavior The package is built successfully. Notify maintainers (gfan, cddlib), (cddlib) Metadata system: host os: multi-user?: sandbox: version: channels(root): channels(omasanori): nixpkgs: Maintainer information:
cddlib put its .h file in <hash-cddlib-0.94l/include/cddlib/ rather than the old version of the library placing it .h headers in the root. <hash-cddlib-0.94j/include/ So options are get upstream to #include "cddlib/setoper.h" (and the rest of the directly pathed includes) Patch it in the derivation Take a look at the library is being why it differs from 0.94j to 0.94l ...... and see if can be symlinked (botched). not sure why it's subpathing these .h file now?
v0.94k header files are now installed to PREFIX/include/cddlib to avoid clashes with other libraries. configuration file for pkg-config : assuming cddlib installed in <prefixknown to pkg-config, "pkg-config --cflags cddlib" etc will work. (Otherwise, one would need PKGCONFIGPATH=<prefix/lib/pkgconfig). this is the source of the breakage. this probably breaks everything that uses this library.... lovely! So, options are fix it gfan upstream, or patch it in nix?????? has a 41 length thread, where the developers are trying to workout how not to break any application that uses this library and which distro's they want to break.
Thank you for your survey, The long-term solution would be fixing gfan upstream, given that this is not Nix-specific. The current Makefile assumes that, if cddlib headers are prefixed, the prefix is instead of . A variable to change the prefix will help every package maintainer IMHO. However, adding a patch to gfan just altering with into nixpkg may be fine for now. I will try to address it next week but feel free to make a PR if it is urgent for anyone.