jiebi/CodeConvo huggingface dataset:
Change:
sha256 = "1iwa17s8ipj6a2b8zss5csb1k5y9s5js38syvq932rxcinbyjsl4"; }; <del> postPatch = '' </del> <ins> postPatch = lib.optional (stdenv.hostPlatform.libc == "glibc") '' </ins> sed -ie '/sys/sysctl.h/d' ATOOLS/Org/Run_Parameter.C '';

Discussion:
$ nix-shell --pure -p sherpa fails on macOS Big Sur with the following output Also, I believe the package needs to be a dependency for Darwin systems. $ nix-shell --pure -p sherpa Should be enough to reproduce the problem. Strangely, the following seems to compile just fine, after downloading the source code of a recent version of Sherpa. I am tagging you, as I believe you were the last to touch the derivative. By the way I am just starting to use nix but would be happy to help with some of the physics packages in the future as I learn a bit more. I appreciate your work maintaining these packages very much. Here's my nix-info.
Thanks for reporting!
Change:
# logic was not fixed.  So we must disable it. '' substituteInPlace configure --replace 'noconfigdirs target-newlib target-libgloss' 'noconfigdirs' <ins> substituteInPlace configure --replace 'cross_only="target-libgloss target-newlib' 'cross_only="' </ins> '';

Discussion:
riscv64-none-elf-gcc fails to link basic file. This breaks the build of spike. . You will see Steps to reproduce the behavior: , or followed by Spike builds, or linker errors are only related to the empty C file, not to default linking options failing. team gcc:
Bisected here: Repro: I think may not take into account the fact that, with standalone / toolchains, you actually need those built with the compiler. Maybe we add an optional argument for such platforms? Let me know what you think
is the relevant PR. Maybe we can modify the environment of these platforms specifically. The principle behind the fix in the commit in question makes sense to me, but I am not sure how best to proceed.
I think I know what this is. Getting my builds caught up.
Testing fix:
Yep, it fixes .
Change:
PrivateUsers = true; ProtectClock = true; # Breaks if the home dir of the user is in /home <del> # Also does not add much value in combination with the TemporaryFileSystem. </del> # ProtectHome = true; ProtectHostname = true; <del> # Would re-mount paths ignored by temporary root #ProtectSystem = "strict"; </del> <ins> ProtectSystem = "strict"; </ins> ProtectControlGroups = true; ProtectKernelLogs = true; ProtectKernelModules = true;

Discussion:
My paperless-ngx install has been broken for some time; it looks like paperless-scheduler.service fails to start, which means that paperless-consumer.service and paperless-web.service can't run: I don't have any idea at all how to debug this, sorry. Steps to reproduce the behavior: paperless should work! <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --paperless-ngx maintainers: nixos/paperless maintainers: Please run and paste the result.
+1 habe die selbe fehlermeldung
Here's the .
Will try to find this later, or do you want to do that
Probably caused by the latest systemd update and something in the mount-sandboxing does not work as expected anymore.
The more invasive fix is to set . I actually don't know whether this a regression in systemd or intented. Also there's surely a better fix (maybe with the new systemd option ?), so what should we do?
Change:
inherit clang-tools-extra_src stdenv; }; <del> clang = wrapCC self.clang-unwrapped; </del> <ins> clang = if stdenv.cc.isGNU then self.libstdcxxClang else self.libcxxClang; libstdcxxClang = ccWrapperFun { cc = self.clang-unwrapped; /* FIXME is this right? */ inherit (stdenv.cc) libc nativeTools nativeLibc; extraPackages = [ libstdcxxHook ]; }; </ins> libcxxClang = ccWrapperFun { cc = self.clang-unwrapped; <del> isClang = true; inherit (self) stdenv; </del> /* FIXME is this right? */ inherit (stdenv.cc) libc nativeTools nativeLibc; extraPackages = [ self.libcxx self.libcxxabi ]; }; <del> stdenv = overrideCC stdenv self.clang; </del> <ins> stdenv = stdenv.override (drv: { allowedRequisites = null; cc = self.clang; # Don't include the libc++ and libc++abi from the original stdenv. extraBuildInputs = stdenv.lib.optional stdenv.isDarwin darwin.CF; }); </ins> <del> libcxxStdenv = overrideCC stdenv self.libcxxClang; </del> <ins> libcxxStdenv = stdenv.override (drv: { allowedRequisites = null; cc = self.libcxxClang; # Don't include the libc++ and libc++abi from the original stdenv. extraBuildInputs = stdenv.lib.optional stdenv.isDarwin darwin.CF; }); </ins> lldb = callPackage ./lldb.nix {};

Discussion:
In Nixpkgs 17.09, 3.9 cannot find libstdc++ headers: This does work correctly with Clang 4.0 in 17.09, or Clang 3.9 in 17.03. Setting shows that the cc-wrapper is not adding the appropriate flags pointing to libstdc++ in gcc. See above. System: NixOS 17.03 Nix version: 1.12pre Nixpkgs version: 17.09beta285. Sandboxing enabled: no
According to git-bisect, one of the following commits is causing the issue (all by
Hmm, was supposed to have fixed this, but I guess only fixed 4.0. any idea?
Really thought I already applied those changes to the other versions, must have forgotten to push or something.
Ah I see now---I should have noticed when reviewing that. While we're at it, maybe we should inject it in cc-wrapper instead of stdenv? This mirrors and keeps slimmer.
Change:
installFlags = "NO_INSTALL_HARDLINKS=1"; <ins> preInstall = stdenv.lib.optionalString stdenv.isDarwin '' mkdir -p $out/bin mv $PWD/contrib/credential/osxkeychain/git-credential-osxkeychain $out/bin ''; </ins> postInstall = '' notSupported() {

Discussion:
Git includes a number of credential storage systems. On OS X there's a Keychain-based store that uses the encrypted login keychain to keep track of sensitive credentials. https://git- The implementation is written in C, and can be found in . If we could change the git expression to , and install the credential helper on OS X that would be amazing! Install git on OS X. Set your credential helper to use the built-in osxkeychain method included with git. Try pushing or pulling from an HTTPS GitHub repo where authentication is required. System: Darwin 15.4.0 Darwin Kernel Version 15.4.0: Fri Feb 26 22:08:05 PST 2016; root:xnu-3248.40.184~3/RELEASEX8664 x86_64 i386 MacBookPro11,5 Darwin Nix version: nix-env (Nix) 1.11.2 Nixpkgs version: "16.09pre-git"
Change:
owner = "astrada"; repo = "google-drive-ocamlfuse"; rev = "v${version}"; <del> sha256 = "027j1r2iy8vnbqs8bv893f0909yk5312ki5p3zh2pdz6s865h750"; </del> <ins> sha256 = "sha256-8s3DnpdYIVyJj5rtsof3WpLvX9wCrWU47dp4D6c986s="; </ins> }; buildInputs = [ ocaml_extlib ocamlfuse gapi_ocaml ocaml_sqlite3 ];

Discussion:
<!-- 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 than 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: desired version: <!-- 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.
Change:
<ins> { lib, victoriametrics }: lib.addMetaAttrs { mainProgram = "vmagent"; } ( victoriametrics.override { withServer = false; withVictoriaLogs = false; withVmAlert = false; withVmAuth = false; withBackupTools = false; withVmctl = false; withVmAgent = true; } ) </ins>

Discussion:
Initially, I opened this issue to get vmagent removed in favour of victoriametrics. Instead, we propose that vmagent be based on the victoriametrics package. The package provides a subset of the programs provided by the package. This package should be removed (and aliased to victoriametrics).
Correct me if I'm wrong, but it seems as if vmagent could be useful without the whole victoriametrics package. Maybe someone wants that without also having vmbackup, vmrestore and so on?
So could all of the other programs in the package. :D If removal is not the best option, is there a way to provide all or some of the programs as individual packages without maintaining versions in ?
cc
i played a bit around with the code. Would something like that fulfill the goal? vmagent as client tool could then be exposed like that If yes i could create a pr for that. i tried to put those into groups that might make sense setup wise.
That looks good to me! :)
That looks good to me as well
Cool, that looks like a reasonable solution! :) I'll leave this issue open to be closed by merging the PR.
As in the issue was some response and the PR did not attract any deeper looks yet, does some from here feel comfortable in peeking at the linked pr?
Sorry, I haven't been checking my GitHub notifications since. The merged solution looks good to me. Especially leaving the vmalert program in the victoriametrics package. :)
Change:
--prefix FCITX_ADDON_DIRS : "$out/lib/fcitx5"  --suffix XDG_DATA_DIRS : "$out/share"  --suffix PATH : "$out/bin" <ins> desktop=share/applications/org.fcitx.Fcitx5.desktop autostart=etc/xdg/autostart/org.fcitx.Fcitx5.desktop rm $out/$desktop rm $out/$autostart cp ${fcitx5}/$desktop $out/$desktop sed -i $out/$desktop -e "s|^Exec=.*|Exec=$out/bin/fcitx5|g" ln -s $out/$desktop $out/$autostart </ins> ''; meta = fcitx5.meta;

Discussion:
Describe the bug fcitx5 does not emerge after pressed <kbdCtrl</kbd+ <kbdSpace</kbdin qt applications. Relevant information from : Additional context IIUC, fcitx5-qt should provide as a qt plugin. However, the current output does not contain this file: Notify maintainers Metadata system: host os: multi-user?: sandbox: version: channels(berberman): channels(root): nixpkgs: Maintainer information:
Change:
in buildPythonApplication rec { pname = "lutris-original"; <del> version = "0.5.7.1"; </del> <ins> version = "0.5.8.3"; </ins> src = fetchFromGitHub { owner = "lutris"; repo = "lutris"; rev = "v${version}"; <del> sha256 = "12ispwkbbm5aq263n3bdjmjfkpwplizacnqs2c0wnag4zj4kpm29"; </del> <ins> sha256 = "sha256-NnWIP9oEndk/hDo5Z33pkmZ61pxT/ScmZ4YpS2ajK/8="; </ins> }; nativeBuildInputs = [ wrapGAppsHook ];

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 the current version of the package --- name: lutris <!-- The current version can be found easily with the same process than 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: 0.5.7.1 desired version: 0.5.8.3 <!-- Search your package here: If no maintainer is listed for your package, tag the person that last updated the package --maintainers: As there is no maintainer listed, was the last to update the package. Please tag this issue in your PR. Just bumping the version didn't seem to work. You have to add python magic as a dependency, but then, all the tests were failing. I don't recall why tho (tried it a few days ago)
Change:
tag = last (splitString "-" version); in '' rm -rf dependencies/imgui <del> ln -s ${imgui}/include/imgui dependencies/imgui </del> <ins> ln -s ${imgui'}/include/imgui dependencies/imgui </ins> substituteInPlace src/Common/version.h --replace " (experimental)" "-${tag} (experimental)" substituteInPlace dependencies/gamemode/lib/gamemode_client.h --replace "libgamemode.so.0" "${gamemode.lib}/lib/libgamemode.so.0" '';

Discussion:
Steps to reproduce the behavior: cemu In ImGui changelog for 1.90.2: <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --cc Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Always paste the full log or big parts from it, not just the short log.
my build log failure
apparently decided to ignore this build failure in . Not sure why we even have tests if we just blindly ignore them.
Change:
qtbase taglib zlib <ins> py </ins> ] ++ (with gst_all_1; [ gstreamer

Discussion:
Describe the bug A clear and concise description of what the bug is. The and python scripts in need their interpreter to be patched (and the module available). To Reproduce Steps to reproduce the behavior: Expected behavior A clear and concise description of what you expected to happen. They should work :stuckouttongue:. Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Metadata Please run and paste the result. system: host os: multi-user?: sandbox: version: channels(bt1cn): nixpkgs: Maintainer information:

<!-- 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 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: sayonara <!-- The current version can be found easily with the same process than 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: 1.6.0-beta6 desired version: 1.6.0-beta7 <!-- 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.
Change:
let gdbDefaultsTo = if gdbUseFixed then "${gdb}/bin/gdb" else "gdb"; <del> openDebugAD7Script = writeScript "OpenDebugAD7" '' #!${runtimeShell} BIN_DIR="$(cd "$(dirname "$0")" && pwd -P)" ${if gdbUseFixed then '' export PATH=''${PATH}''${PATH:+:}${gdb}/bin '' else ""} ${mono}/bin/mono $BIN_DIR/bin/OpenDebugAD7.exe $* ''; </del> in vscode-utils.buildVscodeMarketplaceExtension rec { mktplcRef = { name = "cpptools"; publisher = "ms-vscode"; <del> version = "1.9.1"; </del> <ins> version = "1.11.0"; sha256 = "c0725d3914aeb2515627691727455cc27e7a75031fa02ca957be02cc210bd64d"; arch = "linux-x64"; </ins> }; <del> vsix = fetchurl { name = "${mktplcRef.publisher}-${mktplcRef.name}.gz"; url = "https://marketplace.visualstudio.com/_apis/public/gallery/publishers/${mktplcRef.publisher}/vsextensions/${mktplcRef.name}/${mktplcRef.version}/vspackage?targetPlatform=linux-x64"; sha256 = "sha256-BtTl9DR8hnwNpO5k99M4dtqcTQ2hTzVbjR8VZh+tdDI="; }; unpackPhase = '' runHook preUnpack gzip -d $src --stdout &> temporary.zip unzip temporary.zip rm temporary.zip cd extension/ runHook postUnpack ''; </del> <ins> nativeBuildInputs = [ autoPatchelfHook makeWrapper ]; </ins> buildInputs = [ jq <ins> lttng-ust libkrb5 zlib stdenv.cc.cc.lib </ins> ]; postPatch = ''

Discussion:
OpenDebug does not work. vscode-cpptools working opendebug -not work !
correct path ) !
Change:
} { <del> assertion = cfg.open -> (cfg.package ? open && cfg.package ? firmware); message = "This version of NVIDIA driver does not provide a corresponding opensource kernel driver"; </del> <ins> assertion = cfg.gsp.enable -> (cfg.package ? firmware); message = "This version of NVIDIA driver does not provide a GSP firmware."; } { assertion = cfg.open -> (cfg.package ? open); message = "This version of NVIDIA driver does not provide a corresponding opensource kernel driver."; } { assertion = cfg.open -> cfg.gsp.enable; message = "The GSP cannot be disabled when using the opensource kernel driver."; </ins> } {

Discussion:
The RPATH of , as installed by the standard nvidia package () in nixos 23.11, has no entry for , causing it to fail if anyone actually used that particular interface. Steps to reproduce the behavior: The nvidia package should set proper RPATHs on the installed libraries. I ran into this because I was trying to clean up the steam package of issues, and steam's does a lot of sanity checking of its environment and reported the issue from inside the FHS environment. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
That library is an internal compatibility layer for openssl1.1. Since we link openssl3 into the nvidia driver it never gets used and is meant to fail to load. Since NixOS makes sure that openssl3 is always available this library is functionally useless. We could probably just remove that file (like we do with ) to regain some disk space and satisfy the checks you mentioned.
Sounds good. Better to not ship it than ship it broken, especially if nobody needs it.
Change:
postPatch = '' echo "${finalAttrs.version}" > IGRAPH_VERSION <ins> '' # https://github.com/igraph/igraph/issues/2340 + lib.optionalString stdenv.isDarwin '' sed -i "/safelocale/d" tests/CMakeLists.txt </ins> ''; outputs = [ "out" "dev" "doc" ];

Discussion:
Please report directly at Likely something changed in macOS recently. EDIT: This is a bug in macOS, not in igraph.
Issue opened
Change:
regular2 = foreground; }; }; <ins> etc."gpg-agent.conf".text = '' pinentry-timeout 86400 ''; </ins> }; fonts.fonts = [ pkgs.inconsolata ];

Discussion:
the sway test is flaky, both because ocr itself seems to flaky and because ocr seems to be very slow. Steps to reproduce the behavior: a couple times, we haven't gotten it to work even once this seems to be blocking nixos-unstable channel updates. there are a number of timeouts in the hydra build logs that we can very clearly attribute to either ocr not working, or ocr timing out because it gets only one shot at finding the gpg prompt (and if that fails, loops forever on the empty desktop).
I found it failing quite reliably, exactly since merging the .
scrolling throug hydra logs it's been flaky before too though, something is definitely up. there's failures in early may that look exactly like what we see now
Where do you see this? Looking through I only see successful builds (apart from the cancelled builds and dependency failures). I also don't remember it ever failing when working on it. So this definitely seems to be a regression from staging-next (either it just causes issues with (some of) the OCR tests or it can even affect users - in which case it would be very good that the test is failing). Unfortunately I don't really have time to look into it right now (maybe Thursday or Saturday). It could be due to a font rendering regression. Hm, that's strange - the GnuPG pinentry-gnome3 passphrase prompt shouldn't disappear automatically / after a short timeout (if that's the case than we definitely need to change that part).
Both and failed consistently at this point: So it looks like either doesn't start when using the Wayland backend or the font rendering is broken then (with the X11 backend (XWayland) the test succeeds).
Some of the “cancelled” builds are cancelled due to it timing-out, e.g. and ; the reason there may be unrelated, though. Indeed most appear to be non-timeout cancellations.
run locally here the things the tests wants to happen did always happen, but OCR was incredibly flaky and either did not detect them at the first try, or not at all. this is especially bad for pinentry because it closes after 10 seconds for reasons we have not dug into.

it looks like this is squarely a failure of OCR (and the way it's used here does seem at least somewhat suspect, maybe using other tooling to list windows would be more appropriate? would almost certainly not take three minutes per attempt to find a window)
Ah, right, thanks for the examples :) Indeed, that seems to be to the gnome3-pinentry timeout that I wasn't aware of (so that part would be fixable). Weird, that shouldn't happen. OCR is slow but should be reliable. Not sure if this could be setup dependant. On Hydra it doesn't seem to be an issue. That is indeed bad. Luckily already found a solution for the timeout in . I intentionally chose OCR to ensure that the (font) rendering works but it isn't required for ensuring that the windows are there. The slowness of OCR is certainly a drawback though.
Change:
# https://github.com/NixOS/nixpkgs/issues/53441 ./unset-env-vars.patch <ins> # Use flatpak from PATH to avoid references to `/nix/store` in `/desktop` files. # Applications containing `DBusActivatable` entries should be able to find the flatpak binary. # https://github.com/NixOS/nixpkgs/issues/138956 ./binary-path.patch </ins> # The icon validator needs to access the gdk-pixbuf loaders in the Nix store # and cannot bind FHS paths since those are not available on NixOS. finalAttrs.passthru.icon-validator-patch

Discussion:
When trying to start a flatpak which contains in its .desktop file it refuses to start (tested in GNOME shell). Commenting out (tested in copied .desktop to home dir) or just seems to work fine. Steps to reproduce the behavior: e.g. it from GNOME shell Flatpak should open.
Try this, maybe it'll give a error or something foot terminal used as a example desktop file in share/applications
Pre-requisite would be Flatpak linking D-Bus service files to a well-known location. Not sure if it currently does that.
there is nothing. Tbh i don't get how this helps. FWIW gnome-maps (also with dbus actication) installed with nix works; the gnome-maps flatpak not.
on both my Fedora Silverblue machine and NixOS machine the services are symlinked to the same location if that's what you mean.
Maybe we need to add to :
! ! !
Did you try adding the path to ?
yes got to /etc/dbus- doesn't work
this is what i have for now i switched to dbus-broker since fedora is using that and it has better logs it does find the geany service file but it if someone wants to try: this patch applied to nixos-unstable branch very rough for now to run this vm
I marked this as stale due to inactivity. &rarr;
I am still having this issue in 22.05 and the 22.11 unstable channel. I get the following log output when trying to launch one of the Flatpaks in question:
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
The patch hasn't been applied to unstable. The issue still persists...
Here's my fix for the issue if you use : This "solution" is based on the fact launch services via systemd using transient units with prefix . however does not have in its and these transient units do not have them specified either. The drop-in is used to point systemd to where it could find flatpak. EDIT: Updated to not use as it injects environment variables override that may break other applications.
Same issue on unstable
This issue has been mentioned on NixOS Discourse.

There might be relevant details there:
Having the same issue on nixos unstable channel
Same issue on 23.05
I'm experiencing the same behaviour in sway with gnome.nautilus and flatpaks. However, the error I receive from .nautilus-wrapp gives errors, so may be unrelated.
This seems like quite a critical issue, any updates? Same error.
This issue has been mentioned on NixOS Discourse. There might be relevant details there: