jiebi/CodeConvo huggingface dataset:
Code change:
postInstall = '' install -Dm755 -t $client/bin $out/bin/tsh <del> wrapProgram $client/bin/tsh --prefix PATH : ${xdg-utils}/bin wrapProgram $out/bin/tsh --prefix PATH : ${xdg-utils}/bin </del> <ins> wrapProgram $client/bin/tsh --prefix PATH : ${lib.makeBinPath [ xdg-utils ]} wrapProgram $out/bin/tsh --prefix PATH : ${lib.makeBinPath [ xdg-utils ]} </ins> ''; doInstallCheck = true;

Related discussion:
text: Describe the bug In order to be able to invoke the command from teleport is using  call. There is a wrapper around to bring into PATH . That means is invoked from without wrapper and the browser page never opens (due to missing ). To Reproduce Steps to reproduce the behavior: Expected behavior The path to the wrapper must be persisted in the Screenshots If applicable, add screenshots to help explain your problem. Additional context 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. Maintainer information:
Code change:
libsForQt5 = pkgs.plasma5Packages; inherit (libsForQt5) kdeGear kdeFrameworks plasma5; <del> inherit (pkgs) writeText; </del> inherit (lib) getBin optionalString literalExpression mkRemovedOptionModule mkRenamedOptionModule mkDefault mkIf mkMerge mkOption types; <del> ini = pkgs.formats.ini { }; gtkrc2 = writeText "gtkrc-2.0" '' # Default GTK+ 2 config for NixOS Plasma 5 include "/run/current-system/sw/share/themes/Breeze/gtk-2.0/gtkrc" style "user-font" { font_name="Sans Serif Regular" } widget_class "*" style "user-font" gtk-font-name="Sans Serif Regular 10" gtk-theme-name="Breeze" gtk-icon-theme-name="breeze" gtk-fallback-icon-theme="hicolor" gtk-cursor-theme-name="breeze_cursors" gtk-toolbar-style=GTK_TOOLBAR_ICONS gtk-menu-images=1 gtk-button-images=1 ''; gtk3_settings = ini.generate "settings.ini" { Settings = { gtk-font-name = "Sans Serif Regular 10"; gtk-theme-name = "Breeze"; gtk-icon-theme-name = "breeze"; gtk-fallback-icon-theme = "hicolor"; gtk-cursor-theme-name = "breeze_cursors"; gtk-toolbar-style = "GTK_TOOLBAR_ICONS"; gtk-menu-images = 1; gtk-button-images = 1; }; }; kcminputrc = ini.generate "kcminputrc" { Mouse = { cursorTheme = "breeze_cursors"; cursorSize = 0; }; }; </del> activationScript = '' ${set_XDG_CONFIG_HOME}

Related discussion:
text: On a fresh install, lightdm is writing several files to / These should probably be either in /root or in some other runtime .cache and .gtkrc-2.0 Steps to reproduce the behavior: NixOS with X enabled, using the default lightdm display manager. soon as the display manager starts, files are written to / That my / will stay clean. If I stop display-manager.service, delete the files, then restart it, the files return. Looking in my /etc/passwd, shows that lightdm does have a home directory set at /var/lib/lightdm. But for some reason these files are not being written there as they should be. Please run and paste the result.
I just realized after I posted this that I used an old iso from 21.11 to install. So I reinstalled with 22.05, and this still happens
Are you using KDE Plasma? Can you reproduce the issue with SDDM?
I am using KDE. The issue also happens with SDDM. I went ahead and tested GDM as well (while still using plasma,) and it does not happen.
I can reproduce. For my case, in I saw one single file with prefix, after some search it is likely cache for kbuildsycoca5 (). I have no idea what that package does so far though.
All the files in my / are exactly the files being generated in
I can reproduce this with Plasma 5/SDDM on nixpkgs-unstable.
I also observed these files, tracked down the problem and prepared a pull-request that -- hopefully -- fixes the issue: . I came to the conclusion that it is best to entirely remove the code that creates those file. However, I feel a bit unconfident about my solution, so it would be good to have it tested by more users. If you can spare the time, please have a look at my draft pull request, maybe try my solution, and feel free to report back or even drop a review. Thanks a lot!
Code change:
, libsodium , cffi , hypothesis <ins> , six </ins> }: buildPythonPackage rec {

Related discussion:
text: The package can't be cross compiled to other architectures, tested: raspberry-pi and aarch-multiplatform Steps to reproduce the behavior: It should be compiled. This doesn't seem to a nix-only problem, but still influenced by nix. Doesn't compile on arm: AIX: Some missing support for aarch64: Doesn't compile via qemu for arm32v7 and arm64v8: The error I'm having doesn't seem to show up anywhere else though. And a few of those threads also post work arounds. There is no maintainer. $ nix-shell -p nix-info --run "nix-info -m" this path will be fetched (0.05 MiB download, 0.28 MiB unpacked): /nix/store/xq77wmzk8d306anyk9rsvl4i4h7ihchw-bash-interactive-4.4-p23-dev copying path '/nix/store/xq77wmzk8d306anyk9rsvl4i4h7ihchw-bash-interactive-4.4-p23-dev' from ''... system: host os: multi-user?: sandbox: version: channels(root): channels(nix): nixpkgs: Maintainer information:
It seems to be that every package that declares in it's is failing to cross compile. If I put it in it fails with another error though: Should I open another, conglomerate, issue for all the other packages?
Code change:
<del> #! @bash@/bin/bash set -eo pipefail PATH=@coreutils@/bin:$PATH export CLASSPATH=$(find @outFreenet@/deps/ -name "*.jar"|grep -v bcprov-jdk15on-1.48.jar|tr $'n' :) CLASSPATH=$CLASSPATH:@outFreenet@/share/freenet/freenet-ext.jar:@outFreenet@/share/freenet/freenet.jar export FREENET_HOME="$HOME/.local/share/freenet" if [ -n "$XDG_DATA_HOME" ] ; then FREENET_HOME="$XDG_DATA_HOME/freenet" fi mkdir -p -- $FREENET_HOME cp -u -- @seednodes@ $FREENET_HOME/seednodes.fref chmod u+rw -- $FREENET_HOME/seednodes.fref cd -- $FREENET_HOME exec @jre@/bin/java -Xmx1024M freenet.node.NodeStarter "$@" </del>

Related discussion:
text: Freenet installs successfully but fails to run for both the service and the package with Steps to reproduce the behavior: Failure with Or alternatively with the service = true; to config For Freenet to start and be able to access setup wizard on 127.0.0.1:8888 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]:
Code change:
inherit (darwin.apple_sdk.frameworks) AppKit Carbon Cocoa IOKit OSAKit Quartz QuartzCore WebKit ImageCaptureCore GSS ImageIO; <ins> stdenv = if stdenv.cc.isClang then llvmPackages_6.stdenv else stdenv; </ins> }; emacsPackagesFor = emacs: self: let callPackage = newScope self; in rec {

Related discussion:
text: crashes instantly and won't start with the new Darwin stdenv. My is bundled with quite a few Emacs packages, so this may be a bit hard to isolate, but hopefully it's reproducible anyway. Build with recent . This is with . Partial Problem Report included below. I've elided most of it for privacy reasons; let me know if you need more info:
Can reproduce on current "master". "open " won't start anything, but I don't get a crash report, nothing appears in ~/Library/Logs/DiagnosticReports/. edit: got my crash report a bit later, it's the same stacktrace as reported
The regular works.
Looks like libdispatch is too old. Working on it now
I've opened up a draft that I think might fix it: I'm building it now, but if you have a beefy machine it might help to try to build it as well
I'm afraid that doesn't fix the issue. Here's a gist with the new crash, which looks more or less identical to the one I posted above: I built this with my fork here: I'm trying to confirm that this has been built with the updated . I'm having trouble tracking it down. Can you tell me how to figure it out?
Here's a simpler repro case. This happens when I try to build using and the melpa Emacs pacakge:
So the short term fix is just to use llvm6. At some point, I'll try to dig into what is actually happening, but I suspect something has changed in how llvm handles threads.
Thank you! I’m happy to use a work-around and didn’t expect you to address this complex issue so quickly! I was resigned to using the vanilla emacs for the foreseeable future, so this is a very welcome development.
I can confirm that this appears to be fixed in my Hydra builds, as well.
Code change:
"CXX_${rust.toRustTarget stdenv.buildPlatform}"="${cxxForBuild}"  "CC_${rust.toRustTarget stdenv.hostPlatform}"="${ccForHost}"  "CXX_${rust.toRustTarget stdenv.hostPlatform}"="${cxxForHost}"  <del> cargo build  </del> <ins> cargo build -j $NIX_BUILD_CORES  </ins> ${stdenv.lib.optionalString (buildType == "release") "--release"}  --target ${rustTarget}  --frozen ${concatStringsSep " " cargoBuildFlags}

Related discussion:
text: Describe the bug Building packages that use always try to use all cores, independent of ( argument to nix-build) To Reproduce Run , and observe that it spawns many rustc processes (depending on the amount of available processors). Expected behavior The function should pass as argument to cargo. Additional notes Fixing this will probably cause a rebuild of all rust packages, so should we batch this with other changes to the cargo builder? Notify maintainers
has been merged
Code change:
gitless = callPackage ../applications/version-management/gitless { python = python3; }; <ins> gitlint = python3Packages.callPackage ../tools/misc/gitlint { }; </ins> gitter = callPackage  ../applications/networking/instant-messengers/gitter { }; gjs = callPackage ../development/libraries/gjs { };

Related discussion:
text: Gitlint CLI tool and pre-commit hook plugin to lint commit messages with presets Metadata homepage URL: source URL: license: MIT platforms: linux, unix, darwin (python3)
This isn't my library, I simply requested for this package. should i still be included as maintainer?
Also, do I make a PR with the code above? Or is there already a PR
There is no PR yet. New packages need a maintainer and I don't want to maintain this.
I'll do it. I'll send in a PR now.
Code change:
''; }; <ins> upsmon = mkOption { default = {}; description = lib.mdDoc '' Options for the `upsmon.conf` configuration file. ''; type = types.submodule upsmonOptions; }; upsd = mkOption { default = {}; description = lib.mdDoc '' Options for the `upsd.conf` configuration file. ''; type = types.submodule upsdOptions; }; </ins> ups = mkOption { default = {}; # see nut/etc/ups.conf.sample

Related discussion:
text: Describe the bug I'm trying to use NixOS in a UPS client (not server). When , the and services shouldn't be running. There is a note that says that is not used currently. To Reproduce Steps to reproduce the behavior: Error: and fail. Expected behavior only upsmon should be running 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 Maintainer information: See also
Looks like there's a pretty simple workaround:
I marked this as stale due to inactivity. &rarr;
Code change:
''; }; <ins> upsmon = mkOption { default = {}; description = lib.mdDoc '' Options for the `upsmon.conf` configuration file. ''; type = types.submodule upsmonOptions; }; upsd = mkOption { default = {}; description = lib.mdDoc '' Options for the `upsd.conf` configuration file. ''; type = types.submodule upsdOptions; }; </ins> ups = mkOption { default = {}; # see nut/etc/ups.conf.sample

Related discussion:
text: Describe the bug The following snippet: results in services failing to start due to missing config files etc. : : ( fails too, but that could be down to the fact that I haven't plugged the UPS in yet -- but for the record, it complains ) Expected behavior I'd expect the services to start successfully (and probably complain about the missing actual UPS). Notify maintainers (The UPS module appears to have received only drive-by changes for the last several years, so no idea who to bug personally). Metadata system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Maintainer information:
OK, should've read the whole module: I'm supposed to supply the missing /etc/nut files myself because it's unwise to keep them in the store (they could contain passwords and whatnot, I guess?). Declaring (in the service definitions) the state directory to be but creating for the purpose appears to be a real bug, though :)
Also (sorry for the semi-off-topic) what are best practices for referencing hand-written config files without their contents winding up in the store? Double-symlinking? If this is documented somewhere, then I haven't found where.
I was struggling with the same problem as until I noticed this bug report. After copying and editing , , and from to (and setting on all those files), I was able to get it to work. I think this should be more discoverable. If it's not appropriate to copy those sample files to on the users behalf, there should at least be detailed instructions on the option to explain what else needs to be done.
I marked this as stale due to inactivity. &rarr;
Agreed this should be more discoverable. Perhaps at least could be defaulted to empty and written, since I seem to be getting away without anything in there. In case it helps anyone, I got it working with something like this:
I was hit this bug today, too. Maybe we can fix it by using a startup unit that handles the secrets and setup the state directories like nextcloud or syncthing do
Been working on today and wanted to put some notes here. Using version 2.7.4. First, isn't used by for PIDs and it will try to write to .
Code change:
''; }; <ins> upsmon = mkOption { default = {}; description = lib.mdDoc '' Options for the `upsmon.conf` configuration file. ''; type = types.submodule upsmonOptions; }; upsd = mkOption { default = {}; description = lib.mdDoc '' Options for the `upsd.conf` configuration file. ''; type = types.submodule upsdOptions; }; </ins> ups = mkOption { default = {}; # see nut/etc/ups.conf.sample

Related discussion:
text: flags , , may be needed instead of environment variables until a 2.7.5 release. Ref: Using for debug makes it non-forking, requiring a change to the systemd unit . I was able to get to run as non-root: I'm still working on understanding how to manage state directories in NixOS but this was needed:
I set out to get my UPS (cyberpower CP1500 AVR UPS) working with NixOS today. This was the first issue I came across, I figured this was the best place to share my configuration. I probably made this more complex than it needed to be because I have no idea what I am doing, and it is definitely not secure; one problem at a time.
Not stale; still relevant
Thanks for providing your standalone config! I learned a ton tweaking it into a netserver config! The below config creates a working NUT netserver that other machines on your local network can be connected to. The only thing I have yet to figure out is a secure way to include passwords in .nix files that won't show up if I push my local copy to github. Any ideas? If you want to tweak when NUT shuts down your computers you can modify the values of " = <percentage" and " = <seconds" under "directives". SHUTDOWNCMD will be triggered when both conditions are met. The "ignorelb" directive is necessary to have NUT ignore the UPS's defaults. Anyone using this config may want to make sure SHUTDOWNCMD and NOTIFYCMD point to the correct binaries in their filesystem. One other thing of note is to check the value of the "schedulerRules" field under below. You must give it the path to your file. I just put a copy of it inside my /etc/nixos. Could probably add another variable to hold the path for convenience. `
For secrets in nix config, I think the current recommendation is to put it in a separate file and not include it in the repo. See also
I have been using sops-nix to commit encrypted passwords to my NixOS repo, but I have yet to put in the elbow grease to make this work with my upsmon password.
is my attempt at making generate the config files necessary for basic operation. If you are using , could you try out the changes and leave a review?
Code change:
, libiconv ? null, ncurses <del> , enableDwarf ? !stdenv.targetPlatform.isDarwin && !stdenv.targetPlatform.isWindows, elfutils # for DWARF support </del> , useLLVM ? !stdenv.targetPlatform.isx86 || (stdenv.targetPlatform.isMusl && stdenv.hostPlatform != stdenv.targetPlatform) , # LLVM is conceptually a run-time-only depedendency, but for # non-x86, we need LLVM to bootstrap later stages, so it becomes a

Related discussion:
text: Our can no longer link executables. For example: This issue is present in current versions of . Compiling and linking works fine with an older revision, say . It looks like this might be related to some change in binutils, maybe?
This is probably from
Yes, it is. came to the same conclusion.
This probably is GHC bug though. Things like gmp and libiconv get their paths hardcoded so this isn't a problem. I would expect the same treatment for elfutils. should provide a arg.
/cc
I guess now I know why there's a patch in branch.
I'll reopen the PR fixing the linking issues.
I opened while we wait on upstream fix.
Which one, from
Yes, although it doesn't help. See
Yes, it would have surprised me a bit if it helped against that symptom -- my patch fixes that DWARF-enabling is skipped completely.
I'm surprised this worked for you back then and now there are linking errors.
Code change:
owner = "Chia-Network"; repo = "chia-blockchain"; rev = version; <del> sha256 = "sha256-yS0/Fy2dj8VIbwv2J9sehP0VN0f/YDxu1k9WkaeEz8M="; </del> <ins> fetchSubmodules = true; sha256 = "sha256-nK/Zk2zgIdrRtw3+VkUXQWfI9j29XFDOR95Dvbn07eA="; </ins> }; patches = [

Related discussion:
text: chia farmer fails to register with a pool over https. Relevant log contains: Steps to reproduce the behavior: a new-style chia plot with a pool up a farming node Chia should successfully run. If applicable, add screenshots to help explain your problem. Based on , the missing file is . Upstream normally but this appears to fail here. (This is in an LXC container so it's a bit weird) system: host os: multi-user?: sandbox: version: nixpkgs: Maintainer information:
Code change:
<xi:include href="emacs.section.xml" /> <xi:include href="firefox.section.xml" /> <xi:include href="fish.section.xml" /> <del> <xi:include href="ibus.xml" /> </del> <ins> <xi:include href="ibus.section.xml" /> </ins> <xi:include href="kakoune.section.xml" /> <xi:include href="linux.section.xml" /> <xi:include href="locales.section.xml" />

Related discussion:
text: This issue tracks the conversion of from Docbook to CommonMark per . If you intend to work on this conversion, please comment below! here that you intend to work on it. (Please also post if you stop working on it.) a new branch of nixpkgs master. : change to . to . the contents from Docbook to . Follow . Use existing sections for inspiration. from the folder to build the manual. the manual on your computer at after running from folder: it looks good, submit a PR and reference this issue.
Hi Opened PR for this.
Code change:
})) ]; <del> postFixup = '' </del> <ins> postFixup = let libPath = lib.makeLibraryPath ([ libglvnd libxkbcommon xorg.libXcursor xorg.libXext xorg.libXrandr xorg.libXi ] ++ lib.optionals enableWayland [ wayland ]); in '' </ins> wrapProgram $out/bin/neovide  <del> --prefix LD_LIBRARY_PATH : ${lib.makeLibraryPath [ libglvnd libxkbcommon wayland xorg.libXcursor xorg.libXext xorg.libXrandr xorg.libXi ]} </del> <ins> --prefix LD_LIBRARY_PATH : ${libPath} </ins> ''; postInstall = ''

Related discussion:
text: Neovide fails to install via Steps to reproduce the behavior: up a terminal (currently I'm on aarch64-darwin, but I think this should be reproducible on different platforms) (or use home-manager/nix-darwin/nixOS) for it to give the mentioned error Neovide should install and run as expected <img width="1398" alt="image" src="https://user-"(text form) Might be a result of this: Please run and paste the result. Maintainer information:
Can you try this?
Code change:
# May fail due to parallelism, see: # https://github.com/astropy/astropy/issues/15441 "TestUnifiedOutputRegistry" <ins> # More flaky tests, see: https://github.com/NixOS/nixpkgs/issues/294392 "test_sidereal_lon_independent" "test_timedelta_full_precision_arithmetic" </ins> ]; meta = {

Related discussion:
text: Build of failed on x86_64-linux as of . This is currently breaking . maintainers cc: python311Packages.astropy maintainers cc: Other cc: n/a nixpkgs at commit Contents of : This issue was automatically generated by . that created this issue. Internal tags: -
Looks like may be the problematic line. Looks like a flaky test, we should prob disable it.
seems to fix this. If anyone wants to review it you are welcome. I will merge it otherwise myself because CI is green there.
Code change:
<del> {fetchzip}: { plugins.civicrm = fetchzip rec { name = "civicrm"; </del> <ins> {fetchzip, stdenv, lib}: { plugins.civicrm = stdenv.mkDerivation rec { pname = "civicrm"; </ins> version = "5.56.0"; <del> url = "https://storage.googleapis.com/${name}/${name}-stable/${version}/${name}-${version}-wordpress.zip"; hash = "sha256-XsNFxVL0LF+OHlsqjjTV41x9ERLwMDq9BnKKP3Px2aI="; </del> <ins> src = fetchzip { inherit version; name = pname; url = "https://storage.googleapis.com/${pname}/${pname}-stable/${version}/${pname}-${version}-wordpress.zip"; hash = "sha256-XsNFxVL0LF+OHlsqjjTV41x9ERLwMDq9BnKKP3Px2aI="; }; meta.license = lib.licenses.agpl3Only; </ins> }; <del> themes.geist = fetchzip rec { name = "geist"; </del> <ins> themes.geist = stdenv.mkDerivation rec { pname = "geist"; </ins> version = "2.0.3"; <del> url = "https://github.com/christophery/geist/archive/refs/tags/${version}.zip"; hash = "sha256-c85oRhqu5E5IJlpgqKJRQITur1W7x40obOvHZbPevzU="; </del> <ins> src = fetchzip { inherit version; name = pname; url = "https://github.com/christophery/geist/archive/refs/tags/${version}.zip"; hash = "sha256-c85oRhqu5E5IJlpgqKJRQITur1W7x40obOvHZbPevzU="; }; meta.license = lib.licenses.gpl2Only; </ins> }; }

Related discussion:
text: The package with that are automatically fetched carry no license. ` cc
Poking upstream does not seem to yield anything. They did indicate they wouldn't support this use case, so what are you expecting from them?
I talked to the authors of wp4nix and they are happy for new contributions. It would be nice if the wp4nix script would somehow handle license informations, for example by manually defining them. Not quite sure yet how to implement it
If we don't know the licenses to these packages we honestly cannot keep them around. For example, it is absolutely unclear, whether we have a license to even redistribute them. Of course upstream will take patches, but they're not exactly in the same boat we are. I think your attitude towards the whole licensing situation around wp4nix/nc4nix and its resulting packages is alarming.
As written : Fixing this for Wordpress packages and themes (wp4nix) and Nextcloud apps (nc4nix) in a foreseeable time exceeds my skills and competence. Therefore I would like to offer to add a flag to these package sets and remove them for the next release 23.11 if it's not resolved by then.
Couldn't we mark them as unfree so they don't get cached on hydra but people can still use them if they want? Unfortunately it seems like the wordpress plugins repository doesn't seem to provide the license information in an easy manner. And I don't know whether it is stored somewhere else or can even be extracted from the derivation without import-from-derivation.
Actuallly we seem to be safe in theory. claims
In an ideal world, that would hold true, but it is up to the user and distributor to validate the final outcome. I therefore think this situation remains unresolved.