jiebi/CodeConvo huggingface dataset:
Code change:
${optionalString cfg.caching.apcu "'memcache.local' => 'OCMemcacheAPCu',"} 'log_type' => 'syslog', 'log_level' => '${builtins.toString cfg.logLevel}', <del> ${optionalString (cfg.config.overwriteProtocol != null) "'overwriteprotocol' => '${cfg.config.overwriteProtocol}',"} </del> <ins> ${optionalString (c.overwriteProtocol != null) "'overwriteprotocol' => '${c.overwriteProtocol}',"} ${optionalString (c.dbname != null) "'dbname' => '${c.dbname}',"} ${optionalString (c.dbhost != null) "'dbhost' => '${c.dbhost}',"} ${optionalString (c.dbport != null) "'dbport' => '${toString c.dbport}',"} ${optionalString (c.dbuser != null) "'dbuser' => '${c.dbuser}',"} ${optionalString (c.dbtableprefix != null) "'dbtableprefix' => '${toString c.dbtableprefix}',"} ${optionalString (c.dbpass != null) "'dbpassword' => '${c.dbpass}',"} ${optionalString (c.dbpassFile != null) "'dbpassword' => nix_read_pwd(),"} 'dbtype' => '${c.dbtype}', 'trusted_domains' => ${writePhpArrary c.extraTrustedDomains}, </ins> ]; ''; occInstallCmd = let <del> c = cfg.config; adminpass = if c.adminpassFile != null then ''"$(<"${toString c.adminpassFile}")"'' else ''"${toString c.adminpass}"''; </del> dbpass = if c.dbpassFile != null then ''"$(<"${toString c.dbpassFile}")"'' else if c.dbpass != null then ''"${toString c.dbpass}"'' else null; <ins> adminpass = if c.adminpassFile != null then ''"$(<"${toString c.adminpassFile}")"'' else ''"${toString c.adminpass}"''; </ins> installFlags = concatStringsSep " n    " (mapAttrsToList (k: v: "${k} ${toString v}") { "--database" = ''"${c.dbtype}"'';

Related discussion:
text: Well, for the record it was actually idea :sweat_smile: I guess so, all the stuff from is also in my at the moment. I'll probably have sufficient time next weekend to check if I can trigger such a case. I can't promise that, but unless anybody beats me, I can hopefully prepare a fix for this :)
Did you gain some new insights on this?
Unfortunately not... I was pretty busy back then. But as this only requires some fiddling in the module and no patching of the actual package, the change shouldn't be too painful, so if you'd like to take over... :sweat_smile:
there's with a fix now :)
Code change:
# luarocks only looks for rockspecs in the default/system tree instead of all # configured trees) luarocks_config = "luarocks-config.lua"; <del> luarocks_content = '' </del> <ins> luarocks_content = let extraVariablesStr = lib.concatStringsSep "n " (lib.mapAttrsToList (k: v: "${k}='${v}';") extraVariables); in '' </ins> local_cache = "" -- To prevent collisions when creating environments, we install the rock -- files into per-package subdirectories

Related discussion:
text: 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?
Code change:
# luarocks only looks for rockspecs in the default/system tree instead of all # configured trees) luarocks_config = "luarocks-config.lua"; <del> luarocks_content = '' </del> <ins> luarocks_content = let extraVariablesStr = lib.concatStringsSep "n " (lib.mapAttrsToList (k: v: "${k}='${v}';") extraVariables); in '' </ins> local_cache = "" -- To prevent collisions when creating environments, we install the rock -- files into per-package subdirectories

Related discussion:
text: 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.
Code change:
# luarocks only looks for rockspecs in the default/system tree instead of all # configured trees) luarocks_config = "luarocks-config.lua"; <del> luarocks_content = '' </del> <ins> luarocks_content = let extraVariablesStr = lib.concatStringsSep "n " (lib.mapAttrsToList (k: v: "${k}='${v}';") extraVariables); in '' </ins> local_cache = "" -- To prevent collisions when creating environments, we install the rock -- files into per-package subdirectories

Related discussion:
text: 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.
Code change:
}; }; <ins> # Test OCSP Stapling specialisation.ocsp-stapling.configuration = { pkgs, ... }: { security.acme.certs."a.example.test" = { ocspMustStaple = true; }; services.nginx.virtualHosts."a.example.com" = { extraConfig = '' ssl_stapling on; ssl_stapling_verify on; ''; }; }; </ins> # Test using Apache HTTPD specialisation.httpd-aliases.configuration = { pkgs, config, lib, ... }: { services.nginx.enable = lib.mkForce false;

Related discussion:
text: Describe the bug causes Lego to fail. To Reproduce Steps to reproduce the behavior: set on an enabled certificate. to this configuration. fail. Lego complains about an unrecognized (really misplaced) flag. Expected behavior The certificate will be successfully fetched, with Must-Staple enabled. Screenshots Additional context I think the problematic code is here: should not be in commonOpts, it should instead be in runOpts and renewOpts. Lego runs successfully when is to and . Notify maintainers (the acme team) Metadata Maintainer information:
Thanks for the report :) It appears that the --must-staple option is common to both "run" and "renew" modes, but is not actually a common option that can be specified before the mode. I'll get a PR ready for this.
Code change:
"test_album_from_string" "test_album_from_url" "test_album_length" <del> "test_artist_from_url" </del> "test_artist_from_string" <ins> "test_artist_from_url" </ins> "test_convert" "test_download_ffmpeg" "test_download_song"

Related discussion:
text: Failure happens locally as well when trying to build spotdl on the nixos-23.05 branch. this the tail of the log: The last line is apparently unrelated: (maintainer) (recent bumps)
This test doesn't fail if spotdl is built using version from this nixpkgs commit , I'm not sure if this is an upstream issue with spotdl while using newer yt-dlp versions (newer than ).
Code change:
* Full encryption, DHT, and PEX support ''; homepage = "http://www.transmissionbt.com/"; <del> license = lib.licenses.gpl2; # parts are under MIT </del> <ins> license = lib.licenses.gpl2Plus; # parts are under MIT </ins> maintainers = with lib.maintainers; [ astsmtl vcunat wizeman ]; platforms = lib.platforms.unix; };

Related discussion:
text: Project description Fragments is a modern, responsive and graphical Gnome bittorrent client Metadata homepage URL: source URL: license: gpl3 platforms: linux The new version of Fragments depends on libutp which hopefully gets merged soon. I've opened a pull request for it . for Fragments.
We have transmission and torrential. Maybe that's something for you.
That's true but Fragments is a really neat, easy and modern looking torrent client. It has an adaptive interface which would also work quite well on mobile devices, for example NixOS mobile :+1:
Code change:
<ins> { lib , stdenv , fetchurl , pkg-config , lua , readline , ncurses , lz4 , tbox , xmake-core-sv }: stdenv.mkDerivation rec { pname = "xmake"; version = "2.7.9"; src = fetchurl { url = "https://github.com/xmake-io/xmake/releases/download/v${version}/xmake-v${version}.tar.gz"; hash = "sha256-m0LYY0gz9IhbBbiUKd1gBE3KmSMvYJYyC42Ff7M9Ku8="; }; nativeBuildInputs = [ pkg-config ]; buildInputs = [ lua lua.pkgs.cjson readline ncurses lz4 tbox xmake-core-sv ]; configureFlags = [ "--external=y" ]; meta = with lib; { description = "A cross-platform build utility based on Lua"; homepage = "https://xmake.io"; license = licenses.asl20; platforms = lua.meta.platforms; maintainers = with maintainers; [ rewine ]; }; } </ins>

Related discussion:
text: Project description A lightweight cross-platform build utility based on Lua Metadata homepage URL: source URL: license: asl20 platforms: unix
Code change:
are used internally to configure an HTTP server using <literal><link xlink:href="https://php-fpm.org/">PHP-FPM</link></literal> and <literal>nginx</literal>. The <literal>config</literal> attribute set is <del> used for the <literal>config.php</literal> which is used for the application's configuration. <emphasis>Beware: this isn't entirely pure since the config is modified by the application's runtime!</emphasis> </del> <ins> used by the imperative installer and all values are written to an additional file to ensure that changes can be applied by changing the module's options. </ins> </para> <para> <del> In case the application serves multiple hosts (those are checked with </del> <ins> In case the application serves multiple domains (those are checked with </ins> <literal><link xlink:href="http://php.net/manual/en/reserved.variables.server.php">$_SERVER['HTTP_HOST']</link></literal>) <del> those can be added using </del> <ins> it's needed to add them to </ins> <literal><link linkend="opt-services.nextcloud.config.extraTrustedDomains">services.nextcloud.config.extraTrustedDomains</link></literal>. </para> <ins> <para> Auto updates for Nextcloud apps can be enabled using <literal><link linkend="opt-services.nextcloud.autoUpdateApps.enable">services.nextcloud.autoUpdateApps</link></literal>. </para> </ins> </section> <section xml:id="module-services-nextcloud-pitfalls-during-upgrade"> <title>Pitfalls</title>

Related discussion:
text: Well, for the record it was actually idea :sweat_smile: I guess so, all the stuff from is also in my at the moment. I'll probably have sufficient time next weekend to check if I can trigger such a case. I can't promise that, but unless anybody beats me, I can hopefully prepare a fix for this :)
Did you gain some new insights on this?
Unfortunately not... I was pretty busy back then. But as this only requires some fiddling in the module and no patching of the actual package, the change shouldn't be too painful, so if you'd like to take over... :sweat_smile:
there's with a fix now :)
Code change:
libsoup gnome3.gnome-settings-daemon gnome3.nautilus gnome3.mutter gnome3.gnome-desktop gobjectIntrospection gnome3.nautilus <ins> # Makes it possible to select user themes through the `user-theme` extension gnome3.gnome-shell-extensions </ins> ]; postPatch = ''

Related discussion:
text: The meson build doesn't compile the schemas, opting to do it instead in a package shell script. Unfortunately it seems that compiling the schemas aren't enough to make all the extensions work. In particular at least and still won't work (seems to fix though). With the schemas installed Tweaks simply complains that the extension is incorrectly installed. complains about lacking any typelib file for . I'm not sure how well these extensions worked before 3.28, but a report on irc indicated that at least worked before. cc Run Tweaks on nixos-unstable, try to enable eg. the extension under or . Running a schema fix on top of system: host os: multi-user?: sandbox: version: channels(hed): channels(root): nixpkgs:
The extension works for me when I manually change the directory structure to: As for the , I removed from dependencies so that might explain this failure. The extension should probably be fixed like .
You're able to switch switch themes in in Tweaks? Might be something wrong on my end. I'll submit a PR fixing the schemas at least.
Testing out a fix for .
Hmm, I can enable it but the theme switching does not work. I seems to require the extension schemas in when running Tweaks. Maybe it got picked up from global for bash users, but the option was always disabled for me with fish.
We might want to add as a dependency to Tweaks so that it could work for non-bash users. Then we will need to fix the schemas: the schemas in and find a hack similar to to add the schemas path to the extension. like the following to put the schemas where extensions can find them and add symlink for Tweaks. same thing as the second point but accomplished by patching files.
Your suggested fix worked for at least :) I went with basically adding the code from to to fix the schema problem. Generating the directory structure you quoted above seems the most sane and keeping with upstream. Tested things out in a vm with bash, and didn't seem to work there either. So not sure if the problem is non bash. Anyway, adding to fixes , so I think that's appropriate. I should've got everything now, will submit a PR :)
I think it only works in bash and globally installed packages or something.
Code change:
libsoup gnome3.gnome-settings-daemon gnome3.nautilus gnome3.mutter gnome3.gnome-desktop gobjectIntrospection gnome3.nautilus <ins> # Makes it possible to select user themes through the `user-theme` extension gnome3.gnome-shell-extensions </ins> ]; postPatch = ''

Related discussion:
text: I would not rely on it since I consider it an ugly impurity. I would prefer the first solution since it will be the cleanest and could be possibly automated in the future, but number two is fine too.
Code change:
EOF cat ${certdata2pem} > certdata2pem.py <del> patch -p1 < ${./fix-unicode-ca-names.patch} ${optionalString includeEmail '' # Disable CAs used for mail signing substituteInPlace certdata2pem.py --replace ['CKA_TRUST_EMAIL_PROTECTION'] ''' ''} </del> ''; buildPhase = ''

Related discussion:
text: Describe the bug Putting a valid certificate name in will cause nixos-rebuild to fail. To Reproduce Steps to reproduce the behavior: this line in . This command will fail. Expected behavior finishes sucessfully. Additional context This error message is related to : I guess this error is caused by switching to python 3. 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 Please run and paste the result. Maintainer information:
isn't compatible with Python 3, it seems. We'll need to update or carry a patch.
MRTC:
Code change:
# For backwards compatibility with removed pkgs/development/interpreters/hy # Example usage: #   hy.withPackages (ps: with ps; [ hyrule requests ]) <del> withPackages = python-packages: python.withPackages (ps: (python-packages ps) ++ [ ps.hy ]); </del> <ins> withPackages = python-packages: (python.withPackages (ps: (python-packages ps) ++ [ ps.hy ])).overrideAttrs (old: { name = "${hy.name}-env"; meta = lib.mergeAttrs (builtins.removeAttrs hy.meta [ "license" ]) { mainProgram = "hy"; }; }); </ins> }; meta = with lib; {

Related discussion:
text: Using with and any packages depending on results in the following error: However, packages not depending on work fine, as does running on packages depending on and entering the manually. Steps to reproduce the behavior: the following flake: and that fails while succeeds. To be dropped in a with packages depending on . <!-- 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.
While I could reproduce your case with nixos-22.05, on master, in both cases, I get dropped to a python shell, not a hy shell. Here is a version of your flake that overrides the so that you land in a hy repl. But I think it would be better to put this into eventually.
I'd done that with , but hadn't thought to do it with ; it works! Thanks! Should one of us submit a pull request?
Or perhaps would want to?
Not really, if you want to open a PR I can review/merge.
Sorry, the instructions for contributing are a little confusing to me; could someone give me a summary of steps I need to take?
Also, I just realized I don't know how to merge this with ...
And my own problem was fixed after changing the way the flake apps were made; thanks for all the help!
Code change:
# badPlatformsConditions :: AttrSet Bool # Sets `meta.badPlatforms = meta.platforms` if any of the conditions are true. # Example: Broken on a specific architecture when some condition is met (like targeting Jetson). <del> badPlatformsConditions = { }; </del> <ins> badPlatformsConditions = { "No source" = !sourceMatchesHost; }; </ins> # src :: Optional Derivation src = trivial.pipe redistArch [

Related discussion:
text: should have only eliminated the s and removed some of the platform-based (adding new broken/non-buildable attrs), but instead has changed the actual logic. Since that commit, no longer resolves into but into (note the wrong cuda release), later leading to evaluation errors This currently breaks on Steps to reproduce the behavior: We should probably add some tests for the selection logic as well... A clear and concise description of what you expected to happen. If applicable, add screenshots to help explain your problem. Add any other context about the problem here. <!-- 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. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Code change:
nativeBuildInputs = [ cmake ninja curl git pandoc wrapQtAppsHook copyDesktopItems pkg-config unzip zip ]; buildInputs = [ libGL libGLU xorg.libXxf86vm xorg.libSM <del> freeimage freetype qtbase catch2 fmt </del> <ins> freeimage freetype qtbase qtwayland catch2 fmt </ins> glew miniz tinyxml-2 assimp ]; QT_PLUGIN_PATH = "${qtbase}/${qtbase.qtPluginPrefix}";

Related discussion:
text: Package name: trenchbroom Latest released version: 2024.1 <!-- Search your package here: --- Current version on the unstable channel: 2023.1 Current version on the stable/release channel: 2023.1 <!-- 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]:
Code change:
cmakeFlags = '' -DSC_WII=OFF <del> -DSC_EL=${if useSCEL then "ON" else "OFF"} </del> <ins> -DSC_EL=${if useSCEL then "ON" else "OFF"} </ins> ''; nativeBuildInputs = [ cmake pkgconfig ]; <del> buildInputs = [ gcc libjack2 libsndfile fftw curl libXt qt readline ] </del> <ins> buildInputs = [ gcc ljack2 libsndfile fftw curl libXt qt readline ] </ins> ++ optional useSCEL emacs; }

Related discussion:
text: nix-shell -p supercollider [anders $ nixos-version (Flounder) [anders $ nix-env --version nix-env (Nix) 1.11.2 [anders $ nix-instantiate --eval '<nixpkgs' -A lib.nixpkgsVersion ""
you use supercollider ?
no, sorry.
Same here: