jiebi/CodeConvo huggingface dataset:
Change:
netbootxyz-efi = callPackage ../tools/misc/netbootxyz-efi { }; <del> inherit (callPackages ../servers/web-apps/netbox { }) </del> <ins> inherit (callPackage ../servers/web-apps/netbox { }) </ins> netbox netbox_3_5 netbox_3_6; netbox2netshot = callPackage ../tools/admin/netbox2netshot { };

Discussion:
The NixOS tests for netbox are failing to evaluate: It seems like the module tries to override the package to pass in the plugins that are configured in the module, but for some reason it's overriding the function in instead of the one in . The former doesn't have a plugins argument, so that causes this error. You can also replicate this in : I don't really know what changed to cause this to happen, as it doesn't seem like it should. Steps to reproduce the behavior: The system configuration should evaluate. <!-- 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]:
Possibly related issue with an which used to work: Ping
The thing these packages have in common seems to be that they use to pull in a few different versions into . It seems like something changed about recently.
I think you're right, That commit changes to for a bunch of packages, including citrix_workspace and netbox.
Change:
extraConfig = '' internal; <del> proxy_pass http://unix:${cfg.socketPath}; </del> <ins> proxy_pass http://unix:${cfgAuth.socketPath}; </ins> proxy_pass_request_body off; # Upstream uses $http_host here, but we are using gixy to check nginx configurations

Discussion:
Despite the name, tailscale's nginx-auth application works fine with both caddy and traefik. Unfortunately, the nixos service for it is tightly coupled with nginx. It should be possible to run the auth service without enabling nginx. N/A Please run and paste the result.
Change:
''; }; <del> themes = mkOption { type = types.listOf types.package; default = []; </del> <ins> package = mkOption { type = types.package; default = pkgs.sddm; </ins> description = '' <del> Extra packages providing themes. </del> <ins> The SDDM package to install. The default package can be overridden to provide extra themes. </ins> ''; };

Discussion:
On NixOS 17.03, the in the system configuration with Plasma 5 enabled, has and in its runtime closure, which causes unnecessary bloat. This is because has: then causes the directories of and to be to the wrapper script. (Automatically adding everything with a directory to the wrapper seems pretty drastic BTW.) System: NixOS Nix version: 1.12pre5073_1cf4801
KDE upstream is slightly careless about implicit runtime dependencies. I spent hours trying to figure out which runtime dependencies needed to be in . By the way, you have to guess at this because SDDM doesn't log error messages. Could we drop ? Probably. Can I answer that question for any of the other dependencies? Not a chance. So I nuked it from orbit. Guessing the correct setting would be a good project for a first-time contributor with a lot of free time. At the moment, I'm trying to get rid of entirely. This problem may go away as a happy accident, but that won't help this release. I'm open to other suggestions.
Change:
<ins> #! /usr/bin/env nix-shell #! nix-shell --show-trace ./emacs2nix.nix -i bash output="nongnu-devel-generated.nix" nongnu-devel-packages.sh --names $EMACS2NIX/names.nix -o "$output" nixfmt "$output" </ins>

Discussion:
Project description NonGNU-devel ELPA Packages; i.e., development versions of the already packaged Metadata homepage URL: source URL: license: probably (guessed by looking at ) platforms: probably all (guessed by looking at ) Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
This feels like something that should only live in the emacs-overlay, not in Nixpkgs.
Consider that the other two supported ELPAs have both their stable/unstable versions supported in nixpkgs: elpa/elpaDevel; melpaStable/melpa (see to quickly fact-check). What's the reason for this feeling; why should nongnu be an exception?
I think the same about the others.
Change:
md2gemini = with python3.pkgs; toPythonApplication md2gemini; <ins> md2pdf = with python3Packages; toPythonApplication md2pdf; </ins> mdbook-emojicodes = callPackage ../tools/text/mdbook-emojicodes { }; mdbook-epub = callPackage ../tools/text/mdbook-epub {

Discussion:
Project description <!-- Describe the project a little: --Convert Markdown files to PDF with styles. Metadata homepage URL: source URL: license: mit platforms: linux. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Change:
"''${gappsWrapperArgs[@]}"  --add-flags "-Dawt.useSystemAAFontSettings=on -Xmx512M  --add-opens javafx.graphics/com.sun.glass.ui=ALL-UNNAMED  <del> -jar $out/share/bluej/bluej.jar" </del> <ins> -cp $out/share/bluej/boot.jar bluej.Boot" </ins> runHook postInstall '';

Discussion:
Package name: bluej Latest released version: 5.2.0 <!-- Search your package here: --- Current version on the unstable channel: 5.1.0 Current version on the stable/release channel: 5.1.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.
On it. I sadly still haven't found a good way of keeping up with releases, and I only actively use it myself from the end of september through to december.
PR at
Change:
stdenv.mkDerivation rec { pname = "tutanota-desktop"; <del> version = "3.95.4"; </del> <ins> version = "3.98.15"; </ins> src = fetchurl { url = "https://github.com/tutao/tutanota/releases/download/tutanota-desktop-release-${version}/${pname}-${version}-unpacked-linux.tar.gz"; name = "tutanota-desktop-${version}.tar.gz"; <del> sha256 = "0kkkp0nw4fby4663w7g0k2y1sg89pm336slzii1s3n70h8cak3dx"; </del> <ins> sha256 = "sha256-yuSFDLQ7ckuZYuXREbW0VvMapzO2VhVIH1Ccr1uQHmo="; </ins> }; nativeBuildInputs = [

Discussion:
<!-- 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: tutanota-desktop <!-- 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.95.4 desired version: 3.98.15 <!-- Search your package here: If no maintainer is listed for your package, tag the person that last updated the package --maintainers: Version 3.95.4 is not supported by Tutao GmbH anymore. I don't know how that exactly works with Nixpkgs, but it would be desirable to update tutanota in the stable 22.05 channel too. Please tag this issue in your PR.
Change:
, vulkan-loader , alsa-lib , libpulseaudio <ins> , libxcrypt-legacy </ins> , libGL , numactl , libX11

Discussion:
Steps to reproduce the behavior: It is complaining about missing . Building from on master <!-- 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.
Adding from solves the issue. Putting PR soon.
Change:
{ stdenv, fetchurl, makeDesktopItem, makeWrapper, patchelf, p7zip <del> , coreutils, gnugrep, which, git, python, unzip, androidsdk }: </del> <ins> , coreutils, gnugrep, which, git, python, unzip, jdk }: </ins> <del> { name, product, version, build, src, meta, jdk } @ attrs: </del> <ins> { name, product, version, build, src, meta } @ attrs: </ins> with stdenv.lib;

Discussion:
Right now the IntelliJ derivation hardcodes oraclejdk8, and AFAICT the only way to override this choice is by overriding oraclejdk8 itself: (I have tried and with no effect.) Can we make this overridable somehow? (FWIW, I've had no problems with 15 and 15 EAP under openjdk8, although I'm getting redraw artifacts with 16 EAP.) cc
It was just recently changed away from that due to Idea having some bug with and not seeming very open to dealing with it. I can't find the ticket right now...
Oh
Okay, found the root cause of this bug. The crucial line is the following in (in openjdk): This checks that is indeed in , and guess what this returns with our symlink maze... As a temporary workaround you can set as an extra environment variable. This manages to hit the only special case in which doesn't have this check, and then intellij works fine with openjdk. Maybe I can draft a PR to fix this tomorrow.
Since the PR is merged, I assume this issue was just forgotten.
Change:
, sourceVersion , sha256 , passthruFun <ins> , static ? false </ins> }: assert x11Support -> tcl != null

Discussion:
So today I tried to build on unstable as described in the . This fails on the dependency . Thanks for your information in that guide! I tried to build according to the guide on and (with slight modifications for compatibility) on they both fail in at this point. Do you have any insights as to how you managed to get it to build? e.g. a nixpkgs commit?
Fix in
Change:
ln -s /var/log/teamviewer $out/share/teamviewer/logfiles ln -s ${xdg-utils}/bin $out/share/teamviewer/tv_bin/xdg-utils <ins> declare in_script_dir="./opt/teamviewer/tv_bin/script" install -d "$out/share/dbus-1/services" install -m 644 "$in_script_dir/com.teamviewer.TeamViewer.service" "$out/share/dbus-1/services" substituteInPlace "$out/share/dbus-1/services/com.teamviewer.TeamViewer.service"  --replace '/opt/teamviewer/tv_bin/TeamViewer'  "$out/share/teamviewer/tv_bin/TeamViewer" install -m 644 "$in_script_dir/com.teamviewer.TeamViewer.Desktop.service" "$out/share/dbus-1/services" substituteInPlace "$out/share/dbus-1/services/com.teamviewer.TeamViewer.Desktop.service"  --replace '/opt/teamviewer/tv_bin/TeamViewer_Desktop'  "$out/share/teamviewer/tv_bin/TeamViewer_Desktop" install -d "$out/share/dbus-1/system.d" install -m 644 "$in_script_dir/com.teamviewer.TeamViewer.Daemon.conf" "$out/share/dbus-1/system.d" install -d "$out/share/polkit-1/actions" install -m 644 "$in_script_dir/com.teamviewer.TeamViewer.policy" "$out/share/polkit-1/actions" substituteInPlace "$out/share/polkit-1/actions/com.teamviewer.TeamViewer.policy"  --replace '/opt/teamviewer/tv_bin/script/execscript'  "$out/share/teamviewer/tv_bin/script/execscript" </ins> for i in 16 20 24 32 48 256; do size=$i"x"$i

Discussion:
Describe the bug When busybox is installed - teamviewer cannot starts correctly To Reproduce Steps to reproduce the behavior: " = true;" to busybox to "environment.systemPackages = with pkgs;" to launch the teamviewer Expected behavior Teamviewer gui starts Screenshots If applicable, add screenshots to help explain your problem. ! 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 these paths will be fetched (0.05 MiB download, 0.28 MiB unpacked): /nix/store/d43v6bx7r6fcaq3fbbfd5mwh1f5s7rmg-bash-interactive-4.4-p23-dev copying path '/nix/store/d43v6bx7r6fcaq3fbbfd5mwh1f5s7rmg-bash-interactive-4.4-p23-dev' from ''... system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Maintainer information:
I marked this as stale due to inactivity. &rarr;
This should be fixed by . Please confirm by closing if it indeed does.
Change:
django-environ = callPackage ../development/python-modules/django_environ { }; <del> django_extensions = callPackage ../development/python-modules/django-extensions { }; </del> <ins> django-extensions = callPackage ../development/python-modules/django-extensions { }; </ins> django-filter = callPackage ../development/python-modules/django-filter { };

Discussion:
python38Packages.djangoextensions and python39Packages.djangoextensions Fails to build. I discovered it as it was a dependency of Archivebox that also doesnt build now. Simple way to reproduce is: a file : I expected the package to build and not fail with errors. It appears it is the test's that fail and not the actual build. ! I have much larger file that I choose not to include as it is the same error i got in the minimal version and all the other clutter likely is not responsible. No maintainers for either of the packages :( Please run and paste the result. this path will be fetched (0.06 MiB download, 0.30 MiB unpacked):
Change:
The "gnu" ABI is ambiguous on 32-bit ARM. Use "gnueabi" or "gnueabihf" instead. ''; } <del> { assertion = platform: platform.system != "powerpc64-linux"; message = '' The "gnu" ABI is ambiguous on big-endian 64-bit PPC. Use "elfv1" or "elfv2" instead. ''; } </del> ]; }; gnuabi64     = { abi = "64"; }; <del> elfv1        = { abi = "elfv1"; }; elfv2        = { abi = "elfv2"; }; </del> musleabi     = { float = "soft"; }; musleabihf   = { float = "hard"; }; musl         = {};

Discussion:
Describe the bug broke parsing of powerpc64 abi-specific configs and . Previously these ad hoc ELF ABI specifiers passed through fine. Since (cc they error with: () It's possible this only worked due to gnu-config being permissive with its parsing. The abi suffix is just a convention I came up with for powerpc64 weirdness, so I'm open to changing the way this is specified, if there is a more established convention for this. To Reproduce
Change:
# Black starts a local server and needs to bind a local address. __darwinAllowLocalNetworking = true; <del> checkInputs =  [ pytestCheckHook parameterized ]; </del> <ins> checkInputs = [ pytestCheckHook parameterized ]; </ins> preCheck = '' export PATH="$PATH:$out/bin"

Discussion:
Describe the bug Fails during tests on unstable channel: Seems to be caused by To Reproduce Steps to reproduce the behavior: Expected behavior Build succeeds. Notify maintainers Metadata Maintainer information:
May be hitting this:
Simply adding makes the test pass and the build succeed.
Change:
else ./3.7/fix-finding-headers-when-cross-compiling.patch ) <del> ] ++ optionals (isPy37 || isPy38) [ </del> <ins> ] ++ optionals (isPy36 || isPy37 || isPy38) [ </ins> # Backport a fix for ctypes.util.find_library. ./3.7/find_library.patch ];

Discussion:
Describe the bug doesn't build. To Reproduce Steps to reproduce the behavior: Check out nixpkgs master (currently ) and run . Observe the following output: Expected behavior Package should build. Notify maintainers Pinging maintainers and Metadata The result of running : system: host os: multi-user?: sandbox: version: channels(root): channels(fs): nixpkgs: Maintainer information:
Duplicate of
was resolved by , which is already merged into master. is an ancestor of , the commit upon which I saw this error. Are you sure that this issue is already fixed? In fact, I checked out the branch of PR and was still able to reproduce this build failure on that branch. (However, the Python 2.7 build of succeeds.) I think this indicates that this issue is not a duplicate of , which is after all specifically about Python 2. The fix in also only touches Python 2 -related files.
Change:
patches = [ # fix platform detection (fetchpatch { <del> url = "https://salsa.debian.org/multimedia-team/intel-media-driver-non-free/-/raw/master/debian/patches/0002-Remove-settings-based-on-ARCH.patch"; sha256 = "sha256-f4M0CPtAVf5l2ZwfgTaoPw7sPuAP/Uxhm5JSHEGhKT0="; </del> <ins> url = "https://salsa.debian.org/multimedia-team/intel-media-driver-non-free/-/raw/04ffb03f744780a55aba311c612d708b00584bb7/debian/patches/0002-Remove-settings-based-on-ARCH.patch"; sha256 = "sha256-o/Pg0S53SYh3O7L+AwxOPl1Bx4TS6iKB8ql8GhhHI/o="; </ins> }) ];

Discussion:
When building a NixOS config this morning, I started seeing this: It would appear that has changed. Steps to reproduce the behavior: a NixOS build relying on using latest nixos-unstable It should build cleanly and not complain about the FOD hash mismatch. Please run and paste the result.
Last commit was 3 weeks ago. I've tried building with a URL using a few specific commits going back 6 months and all have the same effect. Could this have been a force push?
That's because Debian does useless rebases of their patches with no actual changes except line changes which diff/git can resolve itself. We should just pin it to some commit. eg half of is more or less noise
Change:
<ins> { stdenv, lazarus, qt5 }: stdenv.mkDerivation { pname = "libqt5pas"; inherit (lazarus) version src; sourceRoot = "lazarus/lcl/interfaces/qt5/cbindings"; postPatch = '' substituteInPlace Qt5Pas.pro  --replace "target.path = $$[QT_INSTALL_LIBS]" "target.path = $out/lib" ''; nativeBuildInputs = with qt5; [ qmake ]; buildInputs = with qt5; [ qtbase qtx11extras ]; meta = with stdenv.lib; { description = "Free Pascal Qt5 binding library"; homepage = "https://wiki.freepascal.org/Qt5_Interface#libqt5pas"; maintainers = with maintainers; [ sikmir ]; inherit (lazarus.meta) license platforms; }; } </ins>

Discussion:
Cross-platform text editor, written in Lazarus From: Repository: Mirror: Development seems very active (last commit 15 minutes ago). Might be a nice open source alternative to SublimeText.
Thank you for your contributions. This has been automatically marked as stale because it has had no activity for 180 days. If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity. Here are suggestions that might help resolve this more quickly: for maintainers and people that previously touched the related code and @ mention them in a comment. on the . on the on .
Still important to me.
Change:
rokuecp = callPackage ../development/python-modules/rokuecp { }; <ins> rollbar = callPackage ../development/python-modules/rollbar { }; </ins> roman = callPackage ../development/python-modules/roman { }; roombapy = callPackage ../development/python-modules/roombapy { };

Discussion:
Project description Gigalixir is a hosting provider for Elixir apps. Its CLI is currently available on PyPi homepage URL: source URL: license: mit platforms: linux, darwin
Change:
firefox-devedition = buildMozillaMach rec { pname = "firefox-devedition"; <del> version = "130.0b2"; </del> <ins> version = "131.0b2"; </ins> applicationName = "Mozilla Firefox Developer Edition"; requireSigning = false; branding = "browser/branding/aurora"; src = fetchurl { url = "mirror://mozilla/devedition/releases/${version}/source/firefox-${version}.source.tar.xz"; <del> sha512 = "ef26fa3dad6fdafe8e8e2d9d88101b75244b3f21a499d0b61c4a2c9a0addbcd3184274096a34da958b0ab2489ecf6c3d7684a1f507ed687648b96f9e9e2b123c"; </del> <ins> sha512 = "704d30f4c5d2a7cddda53f572551cc5fe49bc380388bda5c0eceac121c7d91ee616f586231a33539bb277aa4ea4e963a0d7f4d40f9738d4d30e4a3da75233d97"; </ins> }; meta = {

Discussion:
Steps to reproduce the behavior: firefox-[beta/devedition]-unwrapped-130.0b2 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]:
It seems that the relevant error from the logs is : The source file () is erroneous on 130.0b2, but also in b3 and b4. It seems to be fixed since 130.0b5
Should be fixed by
Change:
machine.succeed("loginctl enable-linger alice") machine.wait_until_succeeds("${sudo} systemctl --user is-active livebook.service") <del> machine.wait_for_open_port(20123) </del> <ins> machine.wait_for_open_port(20123, timeout=10) </ins> machine.succeed("curl -L localhost:20123 | grep 'Type password'") '';

Discussion:
doesn't seem to work as a module Steps to reproduce the behavior: livebook service any env variables or use environment file with any variables first of all, its systemd unit does not appear to start by default. so i did and but it doesn't work, i can't access it either by IP or by domain, which is set up in my nginx configuration as a reverse proxy. some strange things happen while the unit is active [1st screenshot]. also there's nothing in the journal except info messages about the unit itself as i see it, livebook fails to start, but the service is active because something is going on with inside this wrapper script i tried to make it work several different ways: from using option instead of my environment file to writing my very own systemd unit in NixOS configuration file, also using home-manager like so: but that doesn't work too. surely i tried starting livebook manually - and it works as expected [2nd screenshot] module/service works and is accessible systemd livebook unit works and is accessible |
---------------| NixOS 24.05.3214. (Uakari) x86_64 running on a VPS cc Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Thank you for reporting this issue. I am ashamed to admit that I have actually known about this for a while now, without doing anything about it. Now that someone else is having problems with the service, I'll prioritize getting something done soon. I'm not actually sure what's going wrong, but it seems like the service hangs in the command. As far as I remember it ends up using 100% cpu and just loop forever. I'll try to take a look at it later this week.
Perhaps you have encountered this issue as well?
I've seen this before and I think it was because livebook was trying to generate a in some weird way. This is my current configuration which works: Could you try manually setting a in your service setup, please?
a screenshot from filtering cpu usage ! not so much is used i've tried setting up a cookie and you can see it works - :pleading_face: thanks!!!! ~<
The issue seems to have been described and debugged here: The solution is to set in the systemd service configuration. I'll mint a PR.
Change:
]; in <del> runCommand "nvim-treesitter-grammar-${name}" { } '' mkdir -p $out/parser ln -s ${grammar}/parser $out/parser/${name}.so ''; </del> <ins> runCommand "nvim-treesitter-grammar-${name}" { meta = { platforms = lib.platforms.all; } // grammar.meta; } '' mkdir -p $out/parser ln -s ${grammar}/parser $out/parser/${name}.so ''; </ins> allGrammars = lib.attrValues generatedDerivations;

Discussion:
Background: requires specific versions of tree-sitter grammars (see issue ), therefore was split from / in PR . However, while grammars in are built by Hydra, grammars are not. When using a lot of grammars or even , the grammars can take a while to build. Check Hydra status of any grammar (e.g. using hydra-check): They should be built by Hydra, same as grammars in : <!-- 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. system: host os: multi-user?: ( did not actually terminate, it's stuck building some derivation, perhaps this is because I have remote builders enabled by default?)