jiebi/CodeConvo huggingface dataset:
Code change:
libceph = ceph.lib; inherit (callPackages ../tools/filesystems/ceph { <del> lua = lua5_4; fmt = fmt_8; </del> <ins> lua = lua5_4; # Ceph currently requires >= 5.3 # To see which `fmt` version Ceph upstream recommends, check its `src/fmt` submodule. # # Ceph does not currently build with `fmt_10`; see https://github.com/NixOS/nixpkgs/issues/281027#issuecomment-1899128557 # If we want to switch for that before upstream fixes it, use this patch: # https://github.com/NixOS/nixpkgs/pull/281858#issuecomment-1899648638 fmt = fmt_9; </ins> }) ceph ceph-client;

Related discussion:
text: Steps to reproduce the behavior:  nixos-unstable Noticed when setting and rebuilding &lt;!-- 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]:
You won't get a reply if you leave that empty.
I'm having the same issue I didn't notice when it happened, but I also have sambaFull
Same error whit the package .
This seems related to
That turned out not to be the issue. The actual error: In colour so that one can actually make sense of C++ error messages: ! One potential problem here: This is because of having: Switching to : Builds Removing entirely (which swiches to ): Fails on new related errors (see below) Removing and : Fails because Ceph requires lua = 5.3 and nixpkgs's default is still 5.2: CMake saysCould NOT find Lua (missing: LUAINCLUDEDIR) (Required is at least version "5.3")` Build failure with : <details</detailsI noticed Arch . But we can just use to fix the build.
PR for the
Code change:
"19.09".ap-east-1.hvm-ebs = "ami-055b2348db2827ff1"; "19.09".sa-east-1.hvm-ebs = "ami-018aab68377227e06"; <del> latest = self."19.09"; </del> <ins> # 20.03.1554.94e39623a49 "20.03".eu-west-1.hvm-ebs = "ami-02c34db5766cc7013"; "20.03".eu-west-2.hvm-ebs = "ami-0e32bd8c7853883f1"; "20.03".eu-west-3.hvm-ebs = "ami-061edb1356c1d69fd"; "20.03".eu-central-1.hvm-ebs = "ami-0a1a94722dcbff94c"; "20.03".eu-north-1.hvm-ebs = "ami-02699abfacbb6464b"; "20.03".us-east-1.hvm-ebs = "ami-0c5e7760748b74e85"; "20.03".us-east-2.hvm-ebs = "ami-030296bb256764655"; "20.03".us-west-1.hvm-ebs = "ami-050be818e0266b741"; "20.03".us-west-2.hvm-ebs = "ami-06562f78dca68eda2"; "20.03".ca-central-1.hvm-ebs = "ami-02365684a173255c7"; "20.03".ap-southeast-1.hvm-ebs = "ami-0dbf353e168d155f7"; "20.03".ap-southeast-2.hvm-ebs = "ami-04c0f3a75f63daddd"; "20.03".ap-northeast-1.hvm-ebs = "ami-093d9cc49c191eb6c"; "20.03".ap-northeast-2.hvm-ebs = "ami-0087df91a7b6ebd45"; "20.03".ap-south-1.hvm-ebs = "ami-0a1a6b569af04af9d"; "20.03".ap-east-1.hvm-ebs = "ami-0d18fdd309cdefa86"; "20.03".sa-east-1.hvm-ebs = "ami-09859378158ae971d"; latest = self."20.03"; </ins> }; in self

Related discussion:
text: Describe the bug There is no AWS AMI for NixOS 20.03 To Reproduce Steps to reproduce the behavior: Check or Try find it in AWS AMI console Expected behavior 03 is created and uploaded to AWS
CC I think knows how to do this part.
Yep, I have no idea how to do this for NixOS, so I'd need someone in the know with AWS AMI for 20.03. This actually was one of my concerns for 20.03.
I know how to build the release AMI and put it on a personal AWS S3 bucket (I'm using one now for my NixOps AWS cluster), but do not have the permissions to upload it on the official account. about 2 months ago I followed this process, which you can use if you're looking to unblock yourself: then follow these instructions to upload using : Then on NixOps you set to your custom AMI. You can also use this to bake in pkgs to the AMI so there's less startup time if you know you'll be downloading specific things on provisioning startup otherwise.
Code change:
electron_15 electron_16 electron_17 <del> electron_18; </del> <ins> electron_18 electron_19; </ins> autobuild = callPackage ../development/tools/misc/autobuild { };

Related discussion:
text: 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
Code change:
security.acme.server = "https://acme.test/dir"; specialisation.second-cert.configuration = {pkgs, ...}: { <del> systemd.targets."acme-finished-b.example.test" = {}; systemd.services."acme-b.example.test" = { wants = [ "acme-finished-b.example.test.target" ]; before = [ "acme-finished-b.example.test.target" ]; after = [ "nginx.service" ]; </del> <ins> systemd.targets."acme-finished-b.example.test" = { after = [ "acme-b.example.test.service" ]; wantedBy = [ "acme-b.example.test.service" ]; </ins> }; services.nginx.virtualHosts."b.example.test" = { enableACME = true;

Related discussion:
text: I use enabled. I also have a web server service that specifies: Because my web server is a bit long to start, the timeout and its systemd unit fails. To Reproduce Use the following example module: Expected behavior The acme systemd units created by  should wait that nginx is started before starting. Metadata Maintainer information:
Should adding to what is already to  fix the issue?
Making a note that has the same code and presumably the same issue so any fix on should likely be ported to .
Thank you for the issue and reproducer. I'll have a closer look at this today
what exactly do you mean by "timeout" here by the way. could you provide some journal logs of this failure? I can try reproduce when I'm home, but maybe the logs are enough to understand what is going wrong
I mean "Timeout during connect (likely firewall problem)" in the logs below. Note that the hostname, email and domain have been redacted. Also notice the long time between and . nginx was not started when the Let's Encrypt tried to retrieve the challenge:
I'm scared that won't work. The lack of here is very deliberate pulls in (Through and ) to create fake certs, as nginx crashes hard when certificate paths aren't present. We want to start up before the acme challenge is initiated, as nginx is responsible for serving the director to complete it. If starts before nginx, it will always fail. It's all a bit mind-boggling and the dependencies are a bit complicated. I wish it was a bit more simpler too. However; isn't what we want here instead? We want to guarentee that is running before the certificate request is fired off. So adding a to might work? I'll see if that fixes it..
Absolutely, that is what I meant but I wrote it wrongly.
Should we go for the solution proposed?
Yep. I have a PR in the works on my machine. I'll try to get it out this week
Code change:
# Appended to the generated luarocks config , extraConfig ? "" # Inserted into the generated luarocks config in the "variables" table <del> , extraVariables ? "" </del> <ins> , extraVariables ? {} </ins> # The two above arguments have access to builder variables -- e.g. to $out # relative to srcRoot, path to the rockspec to use when using rocks

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:
# Appended to the generated luarocks config , extraConfig ? "" # Inserted into the generated luarocks config in the "variables" table <del> , extraVariables ? "" </del> <ins> , extraVariables ? {} </ins> # The two above arguments have access to builder variables -- e.g. to $out # relative to srcRoot, path to the rockspec to use when using rocks

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:
# Appended to the generated luarocks config , extraConfig ? "" # Inserted into the generated luarocks config in the "variables" table <del> , extraVariables ? "" </del> <ins> , extraVariables ? {} </ins> # The two above arguments have access to builder variables -- e.g. to $out # relative to srcRoot, path to the rockspec to use when using rocks

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> From f72924a59d4a30daefccf84526bd854ebbe65ac8 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Tor=20Hedin=20Br=C3=B8nner?= <torhedinbronner@gmail.com> Date: Tue, 3 Apr 2018 14:13:12 +0200 Subject: [PATCH] Fix gmenu typelib path --- extensions/apps-menu/extension.js | 2 ++ 1 file changed, 2 insertions(+) diff --git a/extensions/apps-menu/extension.js b/extensions/apps-menu/extension.js index 5b38213..d706f64 100644 --- a/extensions/apps-menu/extension.js +++ b/extensions/apps-menu/extension.js @@ -1,5 +1,7 @@ /* -*- mode: js2; js2-basic-offset: 4; indent-tabs-mode: nil -*- */ +imports.gi.GIRepository.Repository.prepend_search_path('@gmenu_path@'); + const Atk = imports.gi.Atk; const DND = imports.ui.dnd; const GMenu = imports.gi.GMenu; -- 2.16.2 </ins>

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:
<ins> From f72924a59d4a30daefccf84526bd854ebbe65ac8 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Tor=20Hedin=20Br=C3=B8nner?= <torhedinbronner@gmail.com> Date: Tue, 3 Apr 2018 14:13:12 +0200 Subject: [PATCH] Fix gmenu typelib path --- extensions/apps-menu/extension.js | 2 ++ 1 file changed, 2 insertions(+) diff --git a/extensions/apps-menu/extension.js b/extensions/apps-menu/extension.js index 5b38213..d706f64 100644 --- a/extensions/apps-menu/extension.js +++ b/extensions/apps-menu/extension.js @@ -1,5 +1,7 @@ /* -*- mode: js2; js2-basic-offset: 4; indent-tabs-mode: nil -*- */ +imports.gi.GIRepository.Repository.prepend_search_path('@gmenu_path@'); + const Atk = imports.gi.Atk; const DND = imports.ui.dnd; const GMenu = imports.gi.GMenu; -- 2.16.2 </ins>

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:
, cjs , clutter , fetchFromGitHub <ins> , fetchpatch </ins> , gdk-pixbuf <ins> , gettext </ins> , libgnomekbd , glib , gobject-introspection

Related discussion:
text: I am new to nixos... When I try to use printScr Key on keyboard. it not responding. non of the printScreen optins working.. Steps to reproduce the behavior: ... press Key PrintScr ... ... Should take a screen shot ask for location to save to. 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.
I am not too sure but according to the , cinnamon does not have a "native" screenshot tool but gnome-screenshot could be used. I am not too sure if enabling cinnamon auto includes gnome-screenshot. If it doesn't you can just add it and see if it solves your problem.
Code change:
, cjs , clutter , fetchFromGitHub <ins> , fetchpatch </ins> , gdk-pixbuf <ins> , gettext </ins> , libgnomekbd , glib , gobject-introspection

Related discussion:
text: I have user-installed Cinnamon applets, desklets, extensions, themes, which have been installed in the home folder by a different OS (as far as i remember). Many of them work under NixOS (some do not: ). However, i cannot update them. When i try, i get the message: The same happens if i try to install a new applet. Steps to reproduce the behavior: up Cinnamon desktop on NixOS and log in. to install an applet. Should be able to install and update user-installed applets, desklets, extensions, themes. ! I am just beginning to switch over to Cinnamon from GNOME 3 (having been fed up with GNOME, especially under NixOS).
Installing [][gettext] that provided solved the issue. Shouldn't be a dependency of Cinnamon desktop then? [gettext]:
Code change:
"-DLOGDIR=/var/log/rspamd" "-DLOCAL_CONFDIR=/etc/rspamd" "-DENABLE_JEMALLOC=ON" <del> ] ++ lib.optional withHyperscan "-DENABLE_HYPERSCAN=ON"; </del> <ins> ] ++ lib.optional withHyperscan "-DENABLE_HYPERSCAN=ON" ++ lib.optional (!withLuaJIT) "-DENABLE_LUAJIT=OFF"; </ins> passthru.tests.rspamd = nixosTests.rspamd;

Related discussion:
text: Describe the bug rspamd for aarch64 can't find luajit and fails to build. To Reproduce At the moment of writing, the latest unstable seems to be . Expected behavior Build succeeds Screenshots n/a Additional context Hydra build log: Notify maintainers Metadata Maintainer information:
I managed to pinpoint the issue to the commit , where rspamd was updated from 2.5 to 2.6. Build log: It looks like rspamd is trying to find LuaJIT, but it's only available in builds. Probable fix would be disabling LuaJIT support in CMake flags.
Sorry, looks like I broke it in PR . I didn't notice the failure, probably because it showed as a grey dot instead of a red cross :x:: I'm not sure why that is, perhaps because it has both a build failure in the output (same one as you see), AND an evaluation failure
Code change:
in stdenv.mkDerivation rec { pname = "sumneko-lua-language-server"; <del> version = "3.2.3"; </del> <ins> version = "3.4.1"; </ins> src = fetchFromGitHub { owner = "sumneko"; repo = "lua-language-server"; rev = version; <del> sha256 = "sha256-n54PWkiB+vXAqIOZ5FOTUNgGhAdBs81Q1WYxJ2XIb8o="; </del> <ins> sha256 = "sha256-A5a3cOhdPkheMooPjcZW5jneziDcFB0o3gfY2nEOJ4Y="; </ins> fetchSubmodules = true; };

Related discussion:
text: <!-- 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: sumneko-lua-language-server <!-- 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: 3.2.3 desired version: 3.4.1 <!-- 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.
Code change:
<ins> { lib, buildPythonPackage, fetchFromGitHub, poetry-core, textx, pytestCheckHook, }: buildPythonPackage rec { pname = "strpdatetime"; version = "0.3.0"; pyproject = true; src = fetchFromGitHub { owner = "RhetTbull"; repo = "strpdatetime"; rev = "v${version}"; hash = "sha256-eb3KJCFRkEt9KEP1gMQYuP50qXqItrexJhKvtJDHl9o="; }; build-system = [ poetry-core ]; dependencies = [ textx ]; pythonRelaxDeps = [ "textx" ]; patches = [ ./fix-locale.patch ]; pythonImportsCheck = [ "strpdatetime" ]; nativeCheckInputs = [ pytestCheckHook ]; meta = { description = "Parse strings into Python datetime objects"; license = lib.licenses.psfl; changelog = "https://github.com/RhetTbull/strpdatetime/blob/${src.rev}/CHANGELOG.md"; homepage = "https://github.com/RhetTbull/strpdatetime"; maintainers = with lib.maintainers; [ sigmanificient ]; }; } </ins>

Related discussion:
text: Project description Python app to work with pictures and associated metadata from Apple Photos on macOS. Also includes a package to provide programmatic access to the Photos library, pictures, and metadata. Metadata homepage URL: source URL: license: mit platforms: unix, linux, darwin Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
This was the most complex package i ever tried to write :sweat_smile: