jiebi/CodeConvo huggingface dataset:
Change:
]; }; <ins> server_localhost_only = { ... }: { services.openssh = { enable = true; listenAddresses = [ { addr = "127.0.0.1"; port = 22; } ]; }; }; server_localhost_only_lazy = { ... }: { services.openssh = { enable = true; startWhenNeeded = true; listenAddresses = [ { addr = "127.0.0.1"; port = 22; } ]; }; }; </ins> client = { ... }: { };

Discussion:
I just noticed that my laptop was listening on port 22 on all interfaces even though I configured it to listen only on the loopback interface. When parameter from is set to true, parameter is ignored when configuring systemd socket. Check listening sockets: Instead, the socket should be listening only on .
Thanks you for reporting and fixing this bug.
Change:
{ lib , stdenv <ins> , fetchpatch </ins> , fetchurl , fetchFromGitHub , fixDarwinDylibNames

Discussion:
Steps to reproduce the behavior: tbb error: hash mismatch in fixed-output derivation '/nix/store/0gxik5jc7k2pbh4kfac7ikmsv7b1jd3v-aarch64-': specified: sha256-JXqrFPCb3q1vfxk752tQu7HhApCB4YH2LoVnGRwmspk= got: sha256-ZAWzx/NOenTDBWt58sm9qEG4zC++92Xs2eSjxhGwZ4U= error: 1 dependencies of derivation '/nix/store/fda6818m9pbkg5wdslp7wxapjaa6zdql-tbb-' failed to build can't send because gcc wants to be built on my laptop o_O Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Change:
fetchYarnDeps, makeDesktopItem, copyDesktopItems, <ins> makeWrapper, </ins> wrapGAppsHook, electron, }:

Discussion:
Koodo reader is an electron application, and although the build process to add the proper ozone flags when the app is launched in a Wayland environment, it seems for some reason, it's not working as expected: But launching the app with the required flags, it works: The process arguments seem weird: Notice that the the by the package are truncated after the first space . I tried splitting up the flag into two sentences to avoid spaces: But now it looks l like the process does not pick up the environment variables: The variables exist, I define them as . Changing the above override to explicitly set the ozone flags (without the shell expansion conditional) works. Other packages like do the same shell expansion, and they also work in my environment without overriding anything. Steps to reproduce the behavior: in a wayland environment (I'm using hyprland) if the application is using xwayland by running shows the application again but with the ozone flags the app does not use xwayland: Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
I'm not a wayland user, so I usually just copy this line from other electron apps' definitions and hope it works. I think the issue here is that when is present will use the binary implementation, which doesn't expand shell variables, thus not making this work. It looks like I forgot about this behaviour when packaging this.
Change:
<ins> diff --git a/modules/setting/server.go b/modules/setting/server.go index 183906268..fa02e8915 100644 --- a/modules/setting/server.go +++ b/modules/setting/server.go @@ -319,7 +319,7 @@ func loadServerFrom(rootCfg ConfigProvider) { OfflineMode = sec.Key("OFFLINE_MODE").MustBool() Log.DisableRouterLog = sec.Key("DISABLE_ROUTER_LOG").MustBool() if len(StaticRootPath) == 0 { -		StaticRootPath = AppWorkPath +		StaticRootPath = "@data@" } StaticRootPath = sec.Key("STATIC_ROOT_PATH").MustString(StaticRootPath) StaticCacheTime = sec.Key("STATIC_CACHE_TIME").MustDuration(6 * time.Hour) </ins>

Discussion:
forgejo fails to start up because the static file root path that is meant to point at the output of the package was not correctly patched at build time Steps to reproduce the behavior: forgejo (I used nixpkgs-unstable) (I was moving an existing install to the nix package to be up to date) the following output: Forgejo should find the required frontend files provided by the output and start properly. I am aware that using nix and especially nixpkgs-unstable on a non-NixOS system comes with essentially no warranty whatsoever. However, given that the nix derivation is clearly intended to remove this placeholder () and that it failing to do so seems to be the only thing wrong with my installation, I do not believe there is an error on my part. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --
Hi, thanks a lot for the report! Turns out, there is a typo in It should be not , just like the patch: This went unnoticed when using forgejo with the nixos module, because we explicitly set in the to by default[^1]. Will open a PR with a fix shortly :) [^1]:
Thank you very much! I didn't notice the typo, glad I was able to provide enough information anyhow ^^
I heard substituteInPlace has a new --replace-fail option(?). Using that should prevent silent failures like this.
There is now. From what I can tell, does not apply to . But feel free to check and write a review in :)
Change:
''; in { description = "Supplicant ${iface}${optionalString (iface=="WLAN"||iface=="LAN") " %I"}"; <del> wantedBy = [ "network.target" ] ++ deps; </del> <ins> wantedBy = [ "multi-user.target" ] ++ deps; wants = [ "network.target" ]; </ins> bindsTo = deps; after = deps; before = [ "network.target" ];

Discussion:
I just switched from a 16.09 system onto a build from master. After rebooting, does not connect me to my WiFi. There does not even seem to be an attempt to start it. This is output from 16.09: Note that restarting the service will connect me to my WiFi: - RebootSystem: (Gorilla) Nix version: nix-env (Nix) 1.11.4 Nixpkgs version: "17.03pre93234."
Useful info from the duplicate issue:
it seems like you changed some related stuff recently, e.g. in . Any ideas what's wrong?
As stated in another issue on misbehavior is wrong in both modules. Also I think that s fix is not needed. Here's an untested patch Can someone who uses one of the broken modules please test if this fixes the issue (even better if both modules are tested)? I'm a bit reluctant on filing a PR blindly CC
Looks better: BTW, I was unable to copy-and-apply the patch and had to overwrite it by hand. For other testers:
I'm not on master, but FWIW is working for me fine (and wasn't before my patch, as unneeded as I agree it should be)
Oh of course the fix is not needed for since the devices take care of pulling the service in.. Maybe a bit hacky :seenoevil: But if it works. Maybe someday someone unifies both modules and removes the hacks :pray:
Could you wrap this into a proper PR?
Change:
by generating an autoconf'd tarball, but that's probably not worth it. */ autoreconfHook gettext docbook_xsl docbook_xml_dtd_42 docbook_xml_dtd_45 <del> ] ++ stdenv.lib.optionals pythonSupport [pythonPackages.python pythonPackages.lxml]; </del> <ins> ]; </ins> configureFlags = [ "--localstatedir=/var"

Discussion:
with current current unstable channel, the fail2ban package misses its etc path. The package hasn't been updated for some time and the out path is apparently generated by rewriting pathes in its : This suggests that the breakage might be related to the recent python packaging rework, so /cc as well as pkg maintainers
Change:
./hardware/ckb-next.nix ./hardware/cpu/amd-microcode.nix ./hardware/cpu/intel-microcode.nix <ins> ./hardware/corectrl.nix </ins> ./hardware/digitalbitbox.nix ./hardware/device-tree.nix ./hardware/i2c.nix

Discussion:
A "tracking issue", related to
I marked this as stale due to inactivity. &rarr;
Change:
passthru = { updateScript = gnome.updateScript { <del> packageName = pname; </del> <ins> packageName = "vte"; </ins> versionPolicy = "odd-unstable"; }; tests = {

Discussion:
They apparently fixed the issue where the cursor wouldn’t show up in new tabs. Needs backport to 23.11. Thanks! Package name: vte Latest released version: 0.74.2 Current version on the unstable channel: 0.74.1 Current version on the stable/release channel: 0.74.1 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]:
Change:
, isPy3k , lxml , pillow <ins> , psutil </ins> , pybind11 <del> , pytestCheckHook </del> <ins> , pytest-cov </ins> , pytest-helpers-namespace , pytest-timeout <del> , pytest_xdist , pytestrunner </del> <ins> , pytest-xdist , pytestCheckHook </ins> , python-dateutil , python-xmp-toolkit <del> , python3 </del> , qpdf <ins> , setuptools-scm </ins> , setuptools-scm-git-archive <del> , setuptools_scm , lib </del> }: buildPythonPackage rec { pname = "pikepdf"; <del> version = "2.2.0"; </del> <ins> version = "2.5.2"; </ins> disabled = ! isPy3k; src = fetchPypi { inherit pname version; <del> sha256 = "74300a32c41b3d578772f6933f23a88b19f74484185e71e5225ce2f7ea5aea78"; </del> <ins> sha256 = "sha256-j8PpeyTa+9SxrAV8jxRMGEZ85V00KhqMQmiIkOrVjvM="; </ins> }; buildInputs = [

Discussion:
Describe the bug fails to build on master and unstable Notify maintainers
could you please take a look at ?
Thanks
Change:
# While upstream has `XDG_DESKTOP_PORTAL_DIR`, it is meant for tests and actually blocks # any configs from being loaded from anywhere else. ./nix-pkgdatadir-env.patch <ins> # test tries to read /proc/cmdline, which is not intended to be accessible in the sandbox ./trash-test.patch </ins> ]; nativeBuildInputs = [

Discussion:
Steps to reproduce the behavior: xdg-desktop-portal Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Can't repro on ()
I'm rebuilding /nix/store/1md85bcdrifm51lwmvj4qbcfcakbkz9r-xdg-desktop-portal- yet. My config was at As you can see, any override was not here.
I still can't repro, even with rebuilding. Could be a flaky test. Try building the package (not the config) on directly to rule out config issues.
It is caused by reading /proc/cmdline. It's confusing. Maybe it was an unreduciable build.
is the command line passed to your kernel, so... check kernel config? The "file" is world-readable for me though.
I mean we shouldn't read this actually, according to . That was a bug caused by nix. I think the best way is disabling this test. Anyway, I just use linux-zen-6.10.1 without any rebuild just from cache. I do not think It has anything to do with my kernel config.
This is a hilarious test actually: I'm tempted to just disable it entirely.
can you check and reply there if it works for you?
My remote desktop lost connection. Will be tested tonight.
Test are done.
Change:
<ins> { lib , buildGoModule , fetchFromGitHub }: buildGoModule rec { pname = "qovery-cli"; version = "0.45.0"; src = fetchFromGitHub { owner = "Qovery"; repo = pname; rev = "v${version}"; hash = "sha256-cJb5Cac7WDhtNL/7uIIvAz7Kum3Ff2g6tmKyTJWvq00="; }; vendorSha256 = "sha256-KHLknBymDAwr7OxS2Ysx6WU5KQ9kmw0bE2Hlp3CBW0c="; meta = with lib; { description = "Qovery Command Line Interface"; homepage = "https://github.com/Qovery/qovery-cli"; license = with licenses; [ asl20 ]; maintainers = with maintainers; [ fab ]; }; } </ins>

Discussion:
Project description helps tech companies to accelerate and scale application development cycle with zero infrastructure management investment. Metadata homepage URL: source URL: license: Apache-2.0 platforms: linux, darwin, windows
Change:
<del> { stdenv, lib, fetchzip, fetchurl, gtk2, jre, libXtst, makeWrapper, makeDesktopItem, runtimeShell }: </del> <ins> { stdenv, lib, fetchzip, fetchurl, gtk3, jre8, libXtst, makeWrapper, makeDesktopItem, runtimeShell }: </ins> stdenv.mkDerivation rec { pname = "xmind"; <del> version = "8-update8"; </del> <ins> version = "8-update9"; </ins> src = fetchzip { <del> url = "https://xmind.net/xmind/downloads/${pname}-${version}-linux.zip"; </del> <ins> url = "https://www.xmind.app/xmind/downloads/${pname}-${version}-linux.zip"; </ins> stripRoot = false; <del> sha256 = "1p68z0b4brgiyybz190alqv716ncql49vsksm41y90mcjd8s4jhn"; </del> <ins> sha256 = "9769c4a9d42d3370ed2c2d1bed5a5d78f1fc3dc5bd604b064b56101fc7f90bb4"; </ins> }; srcIcon = fetchurl { <del> url = "https://aur.archlinux.org/cgit/aur.git/plain/xmind.png?h=xmind"; </del> <ins> url = "https://aur.archlinux.org/cgit/aur.git/plain/xmind.png?h=xmind&id=41936c866b244b34d7dfbee373cbb835eed7860b"; </ins> sha256 = "0jxq2fiq69q9ly0m6hx2qfybqad22sl42ciw636071khpqgc885f"; };

Discussion:
Building in a current git checkout of the Nixpkgs repo gives the following error:
Ping

Steps to reproduce the behavior: -env -i xmind or xmind to nixos config Please run and paste the result.
Install log when installing via is not exactly the same :
Change:
./executable-name.patch # hardcode path to mat2 executable ./tests.patch <ins> # fix gobject-introspection typelib path for Nautilus extension (substituteAll { src = ./fix_poppler.patch; poppler_path = "${poppler_gi}/lib/girepository-1.0"; }) </ins> ]; postPatch = ''

Discussion:
When starting : Steps to reproduce the behavior: nautilus on console No error and the context-menu is shown <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- maybe could help?
Look at the top of . You will need something like that in to find dependencies.
Also linking for context.
Actually, looks like it is there, only incomplete. For some reason does not contain the contents of . In the worse case, you can add it manually: but then it will fail differently: so you need to fix the typelib as mentioned in the manual:
I think i followed your suggestions: but I am still getting the same error :confused:
As you can see from the error, you need Poppler, not Gmenu typelib. And possibly some other.
i can confirm, that the entry is now visible, but two times. Might be, that my configuration is weird.
Change:
yarn ] ++ lib.optionals (!stdenv.isDarwin) [ copyDesktopItems <ins> ] ++ lib.optionals stdenv.isDarwin [ autoSignDarwinBinariesHook </ins> ]; ELECTRON_SKIP_BINARY_DOWNLOAD = true;

Discussion:
Steps to reproduce the behavior: build drawio version 22.1.18 built successfully for me. This failure happens on drawio version 22.0.3. <!-- 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]:
Hello, could you please check if the issue is still occurring in the latest version (see or just run )?
Unfortunately, this fails with the same error: Logs: PS: Thanks for the tip with
Change:
find -name "Makefile.in" -exec sed -i "s/`date`/$ts/" {} ; ''; <del> buildInputs = with stdenv; [ gfortran zlib ] ++ lib.optionals isLinux [ libnl numactl pmix ucx ] </del> <ins> buildInputs = [ zlib ] ++ lib.optionals fortranSupport [ gfortran ] ++ lib.optionals stdenv.isLinux [ libnl numactl pmix ucx ] </ins> ++ lib.optionals cudaSupport [ cudatoolkit ] ++ [ libevent hwloc ] <del> ++ lib.optional (isLinux || isFreeBSD) rdma-core </del> <ins> ++ lib.optional (stdenv.isLinux || stdenv.isFreeBSD) rdma-core </ins> ++ lib.optional fabricSupport [ libpsm2 libfabric ]; nativeBuildInputs = [ perl ]; <del> configureFlags = with stdenv; lib.optional (!cudaSupport) "--disable-mca-dso" ++ lib.optionals isLinux  [ </del> <ins> configureFlags = lib.optional (!cudaSupport) "--disable-mca-dso" ++ lib.optional (!fortranSupport) "--disable-mpi-fortran" ++ lib.optionals stdenv.isLinux  [ </ins> "--with-libnl=${libnl.dev}" "--with-pmix=${pmix}" "--with-pmix-libdir=${pmix}/lib"

Discussion:
Describe the bug I'm on a mission to get (and thence ) compiling on M1 Macs, and having fixed , the next stumbling block is 4.1.1. Sadly, the build fails with , presumably related to . To Reproduce Steps to reproduce the behavior: Expected behavior A clear and concise description of what you expected to happen. Screenshots Additional context This works fine when built for x8664 on the same machine. Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Metadata system: host os: multi-user?: sandbox: version: channels(steve): nixpkgs: Maintainer information:
Submitted PR which disables Fortran support for OpenMPI on aarch64-darwin. Would that fix the issue for you or do you require Fortran?
This seems to be the build failure:
I actually have no idea if I require Fortran. I mean, presumably it's enabled for some reason, so I'm a little wary of disabling it on only one platform/arch combination: that feels like an atypical workaround.
To reproduce: I wonder if the gcc maintainers can offer any insight?
seems to hint at the stack-protector hardening, so perhaps something like could work around that? (no idea what's the real cause though, and I have no Darwin machine at hand)
You were right! Sent a PR in
Change:
<ins> diff --git a/go.mod b/go.mod index 660463a..5249458 100644 --- a/go.mod +++ b/go.mod @@ -2,7 +2,7 @@ module github.com/rs/curlie require ( golang.org/x/crypto v0.0.0-20180524125353-159ae71589f3 -	golang.org/x/sys v0.0.0-20191026070338-33540a1f6037 +	golang.org/x/sys v0.0.0-20211110154304-99a53858aa08 ) go 1.13 </ins>

Discussion:
Steps to reproduce the behavior: build -L 'nixpkgs#curlie' <details</detailsNot a go developer. I think the issue is the same as . That requires a fix from upstream; I don't know whether this is the same, though, and my attempts to patch the build (and thus demonstrate it needs an upstream fix) have been unsuccessful. I used with the following patch. This resulted in the following error. I tried vendoring the derivation and adding the call to (using ) but at this point I hit the time limit I'd set to investigate this. Please run and paste the result.
You need to update vendorSha256, too. IF you get it working please create a PR.
Change:
zuluVersion = "22.28.91"; jdkVersion = "22.0.0"; hash = <del> if enableJavaFX then "sha256-HvMiODsz+puu1xtxG2RRXH/PWCk91PGNZ7UcOd9orqQ=" </del> <ins> if enableJavaFX then "sha256-+qUrZ+GlspSP3RLTAbgEtFm0B0fzX/VD1WUl6mk2c/0=" </ins> else "sha256-HvMiODsz+puu1xtxG2RRXH/PWCk91PGNZ7UcOd9orqQ="; };

Discussion:
The are incorrect for builds with JavaFx enabled - the hashes are identical to the non-JavaFx builds, which produces a hash error when used. Steps to reproduce the behavior: Should download Zulu with the proper hashes <!-- 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:
{ name , description ? "" , deps ? [] <del> }: </del> <ins> , ... }@args: </ins> <del> let nuget-source = stdenvNoCC.mkDerivation { inherit name; </del> <ins> stdenvNoCC.mkDerivation (lib.recursiveUpdate { inherit name; </ins> <del> nativeBuildInputs = [ python3 ]; </del> <ins> nativeBuildInputs = [ python3 ]; </ins> <del> buildCommand = '' mkdir -p $out/{lib,share} </del> <ins> buildCommand = '' mkdir -p $out/{lib,share} </ins> <del> # use -L to follow symbolic links. When `projectReferences` is used in # buildDotnetModule, one of the deps will be a symlink farm. find -L ${lib.concatStringsSep " " deps} -type f -name '*.nupkg' -exec  ln -s '{}' -t $out/lib ';' </del> <ins> # use -L to follow symbolic links. When `projectReferences` is used in # buildDotnetModule, one of the deps will be a symlink farm. find -L ${lib.concatStringsSep " " deps} -type f -name '*.nupkg' -exec  ln -s '{}' -t $out/lib ';' </ins> <del> # Generates a list of all licenses' spdx ids, if available. # Note that this currently ignores any license provided in plain text (e.g. "LICENSE.txt") python ${./extract-licenses-from-nupkgs.py} $out/lib > $out/share/licenses ''; </del> <ins> # Generates a list of all licenses' spdx ids, if available. # Note that this currently ignores any license provided in plain text (e.g. "LICENSE.txt") python ${./extract-licenses-from-nupkgs.py} $out/lib > $out/share/licenses ''; </ins> <del> meta.description = description; } // { # We need data from `$out` for `meta`, so we have to use overrides as to not hit infinite recursion. meta = nuget-source.meta // { licenses = let # TODO: avoid IFD depLicenses = lib.splitString "n" (builtins.readFile "${nuget-source}/share/licenses"); in lib.flatten (lib.forEach depLicenses (spdx: lib.optionals (spdx != "") (lib.getLicenseFromSpdxId spdx) )); }; }; in nuget-source </del> <ins> meta.description = description; } (removeAttrs args [ "name" "description" "deps" ])) </ins>

Discussion:
I was trying to fetch metadata for various packages for analysis and noticed that at least attribute is failing with infinite recursion. The reproducer against : Ideally metadata should evaluate successfully (or report an error with a function or equivalent, then could skip it). Not sure who the maintainer is. Trying recent contributors to . and Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
I think that could have regressed in I think this is because we are merging nuget- into meta and that into nuget-source. But I am not sure how fix this properly.
We have the team @ NixOS/dotnet now.
Change:
<ins> import ./make-test-python.nix ({pkgs, lib, ...}: { name = "code-server"; nodes = { machine = {pkgs, ...}: { services.code-server = { enable = true; auth = "none"; }; }; }; testScript = '' start_all() machine.wait_for_unit("code-server.service") machine.wait_for_open_port(4444) machine.succeed("curl -k --fail http://localhost:4444", timeout=10) ''; meta.maintainers = [ lib.maintainers.drupol ]; }) </ins>

Discussion:
Currently, code-server (and openvscode-server) depends on 16 in nixpkgs, for the upcoming release of NixOS 23.11, this dependency must be dropped, and all upgrades must be performed to 18. From what I see on — 18 is supported as an engine. Otherwise, those programs are to be dropped. Please pick up the pieces cc
Drop will be performed in
Change:
(onFullSupported "nixos.tests.openssh") (onFullSupported "nixos.tests.pantheon") (onFullSupported "nixos.tests.php.fpm") <ins> (onFullSupported "nixos.tests.php.httpd") </ins> (onFullSupported "nixos.tests.php.pcre") (onFullSupported "nixos.tests.plasma5") (onFullSupported "nixos.tests.predictable-interface-names.predictableNetworkd")

Discussion:
Describe the bug When I enable PHP in httpd using , the file when visited can only see 11 extensions instead of the 52 I get when I run it through php CLI command. To Reproduce A failing NixOS test: Additional context Likely caused by the great refactor: Notify maintainers
Yep, the refactor relies on a configuration file with all the extensions to load being present and specified. For the binary, we have a wrapper that just tells PHP to look in the right folder for the config, but with the module, it looks like that's not used, since it loads PHP as an extension. The solution would probably be to inherit the config from the package as the first thing put into the it already generates; it should be accessible as .
Change:
{ pdfstudioviewer = callPackage ./common.nix rec { inherit desktopName pname program year; <del> version = "${year}.0.2"; </del> <ins> version = "${year}.1.0"; </ins> longDescription = '' PDF Studio Viewer is an easy to use, full-featured PDF editing software. This is the free edition. For the standard/pro edition, see the package pdfstudio. '';

Discussion:
When installing pdfstudio2022 the installation is looking for: But this file doesn't exist. The current version of pdfstudio 2022 is 1.1 and I have tried changing the version number, but doesn't exist either. Steps to reproduce the behavior: pdfstudio2022 (unstable) to or Expected to download the deb file and install it. No screenshots applicable. N/A Please run and paste the result. system: host os: multi-user?: sandbox: version: nixpkgs: