jiebi/CodeConvo huggingface dataset:
Change:
# kernelPatches.cpu-cgroup-v2."4.11" kernelPatches.modinst_arg_list_too_long kernelPatches.bcm2835_mmal_v4l2_camera_driver # Only needed for 4.16! <ins> # https://github.com/NixOS/nixpkgs/issues/42755 # Remove these xen-netfront patches once they're included in # upstream! Fixes https://github.com/NixOS/nixpkgs/issues/42755 kernelPatches.xen-netfront_fix_mismatched_rtnl_unlock kernelPatches.xen-netfront_update_features_after_registering_netdev </ins> ]; };

Discussion:
Network access works well on a new instance booted from the stable AMIs listed on the website, but after running and rebooting the instance, it is broken. More specifically, the host can no longer send packets with an MSS larger than 3836. two EC2 instances from one of the 18.03 AMIs in the same VPC one of them latest stable with and reboot the security group to allow internal VPC communication on the host without the updates and on the updated one As I was writing this, I dug a bit deeper and found out that this is a bug introduced in the 4.14.37 release of the kernel. It is fixed in master (commit and possibly .) Applying those patches to the 4.14.51 kernel in stable fixes this issue for me.
Fix is now backported to 18.03.
Change:
}; youcompleteme = buildVimPluginFrom2Nix { # created by nix#NixDerivation <del> name = "youcompleteme-2016-03-08"; </del> <ins> name = "youcompleteme-2016-03-10"; </ins> src = fetchgit { url = "git://github.com/valloric/youcompleteme"; <del> rev = "381b2132719a959f41e57ec0e6396fc1c3b6daf4"; sha256 = "1gski3s1960pmxisyq85awda0a3kb22ji9y76f67k1a4smy5q9xa"; </del> <ins> rev = "f44435b88ec98156d17869aa67ad15f38cfecbf3"; sha256 = "1y50ilyfwj6rvpvg50iq418maxvsfs54i202v7x0lfs5hmvcb4hi"; </ins> }; dependencies = []; buildInputs = [

Discussion:
To make sure that we are on the same page: Kernel: (run ): System: (NixOS: , Ubuntu/Fedora: , ...): Nix version: (run ): Nixpkgs version: (run ): fails with Build succeeds Build fails
I have the same issue.
Change:
"-DGPERF_PRG=${gperf}/bin/gperf" "-DLUA_PRG=${neovimLuaEnv.interpreter}" "-DLIBLUV_LIBRARY=${luvpath}" <ins> "-DUSE_BUNDLED=OFF" </ins> ] ++ optional doCheck "-DBUSTED_PRG=${neovimLuaEnv}/bin/busted" ++ optional (!lua.pkgs.isLuaJIT) "-DPREFER_LUA=ON"

Discussion:
Describe the bug I have an overlay to install neovim from a recent commit. When you use that overlay on a intel macbook neovim is compiled against luajit 2.1.0-beta3 while the same derivation on an M1 macbook compiles against Lua 5.1. I tried checking why that might be given it's the same exact overlay and luajit seems to compile just fine on aarch64 but I am afraid my nix skills weren't good enough. To Reproduce neovim with the following overlay: neovim the command On intel you will see: While on arm: Main issue is that lots of nvim plugins require luajit and don't work with lua 5.1 Expected behavior neovim should be compiled against luajit. Screenshots N/A Additional context Add any other context about the problem here. Notify maintainers Metadata Intel: Arm: Maintainer information:
This is alredy done in
Oh, thanks for the quick response and for the great work. Closing this :)
Reopening, since this will again be the case once is merged. By some reason builds with luajit on aarch64 still fail and I do not know why. As explained in , simply updating luajit does not help.
fixed in
switched back to using Lua 5.1 due to I think this issue should be reopened. Especially due to from the OP Also see my comment above
I've been messing around with this for a few days without much success, but I do think that compiling with openresty-luajit does work (at least, luarocks builds successfully and the error in question with goes away). I am utterly lost in the maze of Nix abstractions though and don't know the best way to do this. I've tried using overlays to set LuaJIT to be the openresty version which seems to half work, but when I try and build neovim it's still using the version of luarocks built with LuaJIT 2.1. Can someone who knows their way around Nix a little better take a deeper look into this? EDIT: I got it to work! I'm using the following overlay: This issue helped me figure out why my overriden value of wasn't applying to the packages.

I had to add to the override function.
Maybe make a pr for that so nixpkgs will use this version of luajit by default on macOS aarch64.
Done
merged.
This problem appear again, I used on ubuntu22.04 aarch64 (m1 Docker), and got same error with the NVIM 0.7.2: And my luaSnip plugin can not work. (It's ok under intel x64)
I'm also hitting this issue again on aarch64 (m1 Docker) on ubuntu 22.04 and 20.04
Same here, exact same environment and output as
I am also seeing the same error in ubuntu 22.04 VM running on M1 MAC. This is based on aarch64. Anyone know how to fix the issue?
Change:
<ins> diff --git a/Makefile b/Makefile index b0b682cb..513822d9 100644 --- a/Makefile +++ b/Makefile @@ -58,17 +58,14 @@ endif INCDIRS =										 -isystem ./lib/ncurses/include				 -	-iquote ./lib/libgit2/include				 -iquote ./src								 -iquote . LIBDIRS =										 -	-L./lib/libgit2/build-$(PLATFORM)			 -L./lib/ncurses/build-$(PLATFORM) LIBS =											 -lgit2										 -	-lz											 -lpthread									 -lformw										 -lmenuw										 @@ -102,7 +99,7 @@ $(OBJS): | lib $(GITHASHHEADER) # Libs: execute make from `lib` directory .PHONY: lib lib: -	$(MAKE) -C $@ +	$(MAKE) -C $@ ncurses/$(BUILDROOT) # C rule $(BUILDDIR)/%.o: %.c </ins>

Discussion:
Project description debase is a TUI for drag-and-drop manipulation of Git commits: Metadata homepage URL: source URL: license: proprietary platforms: Linux, macOS Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
I noticed it bundles a vastly outdated version (2.0) of a , which makes it quite risky. It also oddly bundles its own , and I couldn't get it to use the system .
I've been playing around with packaging it. Here's what I have so far: This packages debase two different ways: one with debase's vendored and , and one with nix's and . The parameter switches between them. Both versions are building and running for me on my aarch64-darwin laptop. Using the nix deps seems better, but debase has made a few patches to its copy of ncurses that are necessary to support its drag-and-drop features. I'm looking into that now to see if there is a good way to use nix's ncurses while still supporting those features. Using nix's libgit2 just seems to be a straightforward win, though.
I've looked at the patches that debase made to ncurses, and they are significant enough that it seems worthwhile to use debases's vendored copy of ncurses instead of using nix's ncurses. Also, debase has now changed its submodule URLs, which allows us to drop the GITCONFIG* overrides. So here is a derivation that builds debase using debase's vendored ncurses and nix's libgit2: I tested it on my aarch64-darwin laptop and it builds and runs and supports drag and drop.
Due to the fact that it's still unlicensed (hence redistribution or even patching may not be appropriate), I'd hold off on packaging this.
The bundled http-parser issue is easy to resolve. It is part of libgit2, but as demonstrated in the packages I provided above and in the linked (closed) PR, you can use nixpkgs' libgit2 instead, which is up to date and no longer uses http-parser. I agree the lack of license is still an issue, though.
The linked PR doesn't build on linux, but fair enough, the license is really what gives me pause.

Whoops, I see I broke the PR on linux during the review process. FWIW I just pushed a fix.
Change:
buildPythonPackage rec { pname = "ratarmountcore"; <del> version = "0.6.0"; format = "setuptools"; </del> <ins> version = "0.6.3"; pyproject = true; </ins> disabled = pythonOlder "3.6"; <del> src = fetchgit { url = "https://github.com/mxmlnkn/ratarmount"; # The revision is hardcoded for now to fix problems with the tests, which are not worthy of a new release # tag because releases do not officially contain tests. On the next release, use the commented revision, # which points to a release tag, instead. #rev = "core-v${version}"; rev = "ea43572dfbac4770a27ef2169f72ff73ee4a4ae9"; hash = "sha256-sPApM5OW+UbujFXHSL4ptMaegajz7FNtXz/KftTlw+U="; </del> <ins> src = fetchFromGitHub { owner = "mxmlnkn"; repo = "ratarmount"; rev = "core-v${version}"; hash = "sha256-2jG066BUkhyHRqRyFAucQRJrjXQNw2ccCxERKkltO3Y="; </ins> fetchSubmodules = true; }; sourceRoot = "${src.name}/core"; <ins> nativeBuildInputs = [ setuptools ]; </ins> propagatedBuildInputs = [ indexed-gzip indexed-bzip2 indexed-zstd python-xz rapidgzip rarfile ]; pythonImportsCheck = [ "ratarmountcore" ]; nativeCheckInputs = [ pytestCheckHook zstandard zstd ]; <ins> disabledTestPaths = [ # Disable this test because for arcane reasons running pytest with nix-build uses 10-100x # more virtual memory than running the test directly or inside a local development nix-shell. # This virtual memory usage caused os.fork called by Python multiprocessing to fail with # "OSError: [Errno 12] Cannot allocate memory" on a test system with 16 GB RAM. It worked fine # on a system with 96 GB RAM. In order to avoid build errors on "low"-memory systems, this # test is disabled for now. "tests/test_BlockParallelReaders.py" ]; </ins> meta = with lib; { description = "Library for accessing archives by way of indexing"; homepage = "https://github.com/mxmlnkn/ratarmount/tree/master/core"; license = licenses.mit; maintainers = with lib.maintainers; [ mxmlnkn ]; <del> platforms = platforms.all; </del> }; }

Discussion:
Steps to reproduce the behavior: python3Packages.ratarmountcore This first occurs after updates to and itself. The failure is not actually in a test, and occurs after the tests run. This indicates that some difference in the way the derivation is executing tests compared to upstream's CI is causing the error. Please run and paste the result. Not relevant; the log is on Hydra. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
It seems that only the rapidgzip backend got updated but not ratarmountcore. Either downgrade rapidgzip or update ratarmountcore to 0.6.3 if possible. I'll have to see to get the latter update merged, it seems the auto-update bot does not work for ratarmountcore. This should fix the and output. I have no idea about the last 2 error lines. I cannot reproduce it with nix 2.16.1 on Ubuntu. The command runs fine:
Change:
restartByActivationScript = handleTest ./restart-by-activation-script.nix {}; restic = handleTest ./restic.nix {}; retroarch = handleTest ./retroarch.nix {}; <ins> rkvm = handleTest ./rkvm {}; </ins> robustirc-bridge = handleTest ./robustirc-bridge.nix {}; roundcube = handleTest ./roundcube.nix {}; rshim = handleTest ./rshim.nix {};

Discussion:
Project description It's like synergy or barrier, but supports wayland and windows as well. I started packaging it , but it doesn't build yet ( fails to find the evdev files it wants). Metadata homepage URL: source URL: license: mit platforms: linux
here's the build log so far:
well, this is probably the issue: I'll file an issue.
If this is the only issue you can probably patch it like this: And during phrase you can use or to substitute with . Should work.
Good idea. Another weird one popped out though: Not sure what's up, since libevdev does not seem to actually come with that header file included... and from what I can tell ubuntu's libevdev-dev packages don't either??
Weird, debian's libevdev-dev pkg:
Looks like I misunderstood. I think they bundle their input.h for building their lib, but expect to be providing , so I'm adding that to the clang_args too...
Okay, update: error:
I marked this as stale due to inactivity. &rarr;
build: please see:
What's the status on this, doesn't look like it's made it into the binary cache yet. Is it a 23.11 addition?
the PR is still being reviewed:
Change:
<del> { stdenv, lib, fetchurl, fetchpatch, libiconv, xz, bash , gnulib </del> <ins> { stdenv, lib, fetchurl, libiconv, xz, bash </ins> }: # Note: this package is used for bootstrapping fetchurl, and thus

Discussion:
mingw32 build support for gettext is broken. There are conditionals within the gettext derivation that leads me to believe that mingw32 builds should be working. Steps to reproduce the behavior: The package to be built with not error If applicable, add screenshots to help explain your problem. Here is the error that I get Looks like the changes for one of the patches was upstreamed. If I remove the patch (this is okay because it is now in the source code), I will get the following error. <!-- 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]:
Change:
<del> { lib, fetchurl, perlPackages, wrapGAppsHook3, fetchpatch, </del> <ins> { lib, fetchurl, perlPackages, wrapGAppsHook3, </ins> # libs librsvg, sane-backends, sane-frontends, # runtime dependencies

Discussion:
: can not open Edit-Preferences : can not open Edit-Preferences A dialogue should happen This is the debug log: Add any other context about the problem here. Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Hi! I'm afraid I could not reproduce the issue; the Preferences dialogue shows up fine for me. I tried with on NixOS 23.11 with Sway.
Thank you for your fast reply. Does the dialogue connect to some service that must be running?
Quoting Jens Getreu (2024-03-03 14:46:03) The whole app might be trying to connect to SANE when it starts, but I don't think anything is needed for that particular dialogue.
works fine. All other dialogues open correctly. When I try to open Preferences the second time, a tiny little empty window opens. On the console the above error is dumped.
I am running the i3 window manager. Gnome has a settings deamon. I tried: with but it did not help. I still get and no Edit-Preferences dialogue appears.
I'm having the same issue - gscan2pdf v2.13.2, GNOME 45.3, kernel 6.6.16-1-lts
Same for me on KDE on current master with v2.13.2: EDIT: Upstream seems to be ware of the issue:
This should be fixed with Please test and review.
Change:
"test_model_cpu_offload_forward_pass" # tries to run ruff which we have intentionally removed from nativeCheckInputs "test_is_copy_consistent" <ins> ] ++ lib.optionals (pythonAtLeast "3.12") [ # RuntimeError: Dynamo is not supported on Python 3.12+ "test_from_save_pretrained_dynamo" </ins> ]; meta = with lib; {

Discussion:
Steps to reproduce the behavior: Gradio / Gradio Client <!-- 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]:
fix for py311
Change:
}; version = "1.10.0"; }; <ins> git = { groups = ["default"]; platforms = []; source = { remotes = ["https://rubygems.org"]; sha256 = "0bf83icwypi3p3pd97vlqbnp3hvf31ncd440m9kh9y7x6yk74wyh"; type = "gem"; }; version = "1.5.0"; }; </ins> haml = { dependencies = ["temple" "tilt"]; groups = ["default"];

Discussion:
Describe the bug Oxidized crashes on startup when using gitcrypt as output method. It works with any other output method (including git). I think this is because there is a missing dependency (gem git). This is not triggered when using output git because it relies on rugged (which is in the ) rather than git. To Reproduce Steps to reproduce the behavior: oxidized to use gitcrypt, e.g.: oxidized Crash file says: Expected behavior Oxidized should start normally. Additional context Metadata
Change:
mozc = callPackage ../tools/inputmethods/ibus-engines/ibus-mozc { python = python2; inherit (python2Packages) gyp; <del> protobuf = pkgs.protobuf.overrideDerivation (oldAttrs: { stdenv = clangStdenv; }); </del> <ins> protobuf = pkgs.protobuf3_8.overrideDerivation (oldAttrs: { stdenv = clangStdenv; }); </ins> }; table = callPackage ../tools/inputmethods/ibus-engines/ibus-table { };

Discussion:
Describe the bug I was trying to upgrade my system to latest unstable when I encountered this error: error: --- Error
--------------------- nix-build builder for '/nix/store/4akxpw50h059071m68rm96qi3jmdv7zi-ibus-mozc-' failed with exit code 1; last 10 log lines: File "", line 854, in BuildMain BuildWithNinja(options, targets) File "", line 828, in BuildWithNinja RunOrDie([ninja, '-C', buildarg] + ninjatargets) File "", line 99, in RunOrDie '=========='])) ERROR: ninja -C outlinux/Release ibusmozc mozcemacshelper mozcserver mozctool mozc_renderer
cc: because of .
likewsie fcitx-mozc stopped working. Seems like there is this fork of google-mozc with more recent commits but changing upstream would require more changes:
Change:
, grpcio-tools , hdfs , httplib2 <ins> , hypothesis </ins> , lib , mock , mypy-protobuf , numpy <del> , oauth2client </del> <ins> , objsize </ins> , orjson , pandas , parameterized

Discussion:
Build of failed on x86_64-linux as of . This is currently breaking . python39Packages.tensorflow-datasets maintainers cc: maintainers cc: Other cc: n/a nixpkgs at commit This issue was automatically generated by . that created this issue. Internal tags: - -
huh this is a weird failure to me since fasteners==0.18 at the time of this commit which should be working... building locally on this commit i get a different failure: very peculiar...
Change:
buildDotnetModule rec { pname = "github-runner"; <del> version = "2.317.0"; </del> <ins> version = "2.319.0"; </ins> src = fetchFromGitHub { owner = "actions"; repo = "runner"; rev = "v${version}"; <del> hash = "sha256-+VwEH4hmEjeYFWm7TOndD5SOJwsyPZEhKkCSyl7x8cE="; </del> <ins> hash = "sha256-02vIMuaeU5CsdwmJzUdfa6BFKewsKGFsEWKza3CqRtQ="; </ins> leaveDotGit = true; postFetch = '' git -C $out rev-parse --short HEAD > $out/.git-revision

Discussion:
Package name: github-runner Latest released version: 2.318.0 <!-- Search your package here: --- Current version on the unstable channel: 2.317.0 Current version on the stable/release channel: 2.317.0 <!-- 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. I got the package updated but a ton of tests fail. Hopefully there's a .net expert here that can help out. Feel free to use any part of this in a PR: Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
is out now.
Change:
packageOverrides = self: super: { # The bravado-core dependency is incompatible with jschonschema 4.0: # https://github.com/Yelp/bravado-core/pull/385 <del> jsonschema = super.jsonschema.overridePythonAttrs (oldAttrs: rec { version = "3.2.0"; src = oldAttrs.src.override { inherit version; hash = "sha256-yKhbKNN3zHc35G4tnytPRO48Dh3qxr9G3e/HGH0weXo="; sha256 = ""; }; SETUPTOOLS_SCM_PRETEND_VERSION = version; doCheck = false; }); </del> <ins> jsonschema = super.jsonschema_3; </ins> }; };

Discussion:
Steps to reproduce the behavior: (as of ) <details<summaryBuild Log</summary<preerror: builder for '/nix/store/8r1frbwzxwncagff57r7zz86zl2nsxbm-python3.10-jsonschema-' failed with exit code 1; last 10 log lines: For full logs, run 'nix log /nix/store/8r1frbwzxwncagff57r7zz86zl2nsxbm-python3.10-jsonschema-'. error: 1 dependencies of derivation '/nix/store/2413pkb4n4z1bj0rywpcfbi8s1yisvkg-python3.10-bravado-core-' failed to build error: 1 dependencies of derivation '/nix/store/x9h491ipp10gpp771jzfr3qyn3y6pbf9-powerdns-admin-' failed to build </pre</detailsLooks like json schema got updated to 4.13 which requires adding a patch. When , we're not patching (please excuse the pun), so it tries to apply to new patch against 3.2.0 which, of course, fails. Seems like we probably just need to override the to remove the offending patch? <!-- 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.
, and are also broken in similar fashion.
I'll take a look later today.
I opened .
Change:
OpenCL(TM) and the Intel(R) Media Driver for VAAPI. ''; platforms = [ "x86_64-linux" "i686-linux" ]; <del> maintainers = with maintainers; [ primeos ]; </del> <ins> maintainers = with maintainers; [ primeos SuperSandro2000 ]; </ins> }; }

Discussion:
The build of fails on i686. Fails with: Found with Please run and paste the result. Maintainer information:
if you don't ping any maintainer likely nothing will happen ping
I think I never tried compiling intel-media-driver on i686 but only fixed an eval error in nixGL. The problem seems to be that it compiles 64 bit code on 32 bit.
I did a quick look what other distros do and found this helpful Debian patch () at least fixes. There are still some other compile errors that need fixing. Edit1: and with it compiles
Change:
, ninja , pkgconfig , fetchFromGitLab <ins> , fetchpatch </ins> , python3 , umockdev , gobject-introspection

Discussion:
Describe the bug bolt 0.9 appears to have broken/flaky tests. As of I cannot rebuild my system. Hydra fails in the same way: To Reproduce Build bolt-0.9, (hopefully) observe test failure. Expected behavior Bolt passes tests/has tests disabled. Screenshots N/A Additional context N/A Notify maintainers Metadata Maintainer information:
cc
This is now blocking the nixos-unstable channel. One restart didn't fix it. Upstream issue No response for two weeks.
The perceived nondeterminism of the test may have been caused by the presence of mount options on some/most of the builders. I've proposed to remove atime-dependent assertions in and upstream (linked from there)
Change:
<ins> { stdenv , fetchFromGitHub , nix-update-script , meson , ninja , pkg-config , scdoc , gnome-builder , gnused , glib , libgee , json-glib , jsonrpc-glib , vala }: stdenv.mkDerivation rec { pname = "vala-language-server"; version = "0.48.1"; src = fetchFromGitHub { owner = "benwaffle"; repo = pname; rev = version; sha256 = "12k095052jkvbiyz8gzkj6w7r7p16d5m18fyikl48yvh5nln8fw0"; }; passthru = { updateScript = nix-update-script { attrPath = pname; }; }; nativeBuildInputs = [ meson ninja pkg-config scdoc # GNOME Builder Plugin gnused gnome-builder ]; buildInputs = [ glib libgee json-glib jsonrpc-glib vala ]; meta = with stdenv.lib; { description = "Code Intelligence for Vala & Genie"; homepage = "https://github.com/benwaffle/vala-language-server"; license = licenses.lgpl21Plus; maintainers = with maintainers; [ andreasfelix worldofpeace ]; platforms = platforms.linux; }; } </ins>

Discussion:
Project description Code Intelligence for Vala Metadata homepage URL: source URL: license: LGPL2.1 platforms: unix, linux, darwin, ...
any relation to
There are some efforts to merge the two servers but otherwise they are independent.
Hello, I'm a bot and I thank you in the name of the community for opening this issue. To help our human contributors focus on the most-relevant reports, I check up on old issues to see if they're still relevant. This issue has had no activity for 180 days, and so I marked it as stale, but you can rest assured it will never be closed by a non-human. The community would appreciate your effort in checking if the issue is still valid. If it isn't, please close it. If the issue persists, and you'd like to remove the stale label, you simply need to leave a comment. Your comment can be as simple as "still important to me". If you'd like it to get more attention, you can ask for help by searching for maintainers and people that previously touched related code and @ mention them in a comment. You can use or on the relevant files to find them. Lastly, you can always ask for help at or at .