jiebi/CodeConvo huggingface dataset:
Change:
# reference ./shas.nix for available themes selected_themes ? [], }: let <del> version = "2020-12-28"; </del> <ins> version = "1.0"; </ins> # this file is generated via ./update.sh # borrowed from pkgs/data/fonts/nerdfonts themeShas = import ./shas.nix;

Discussion:
Package name: adi1090x-plymouth-themes Latest released version: v1.0 (yay) <!-- Search your package here: --- Current version on the unstable channel: 2020-12-28 Current version on the stable/release channel: 2020-12-28 <!-- 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! --- There's been a few fixes recently and the release is fairly fresh but I thought I'd create this Notify maintainers Note for maintainers: Please tag this issue in your PR.
Tried to prep an update for this in
LGTM, thanks :smile:
Change:
"--with-nqp=${nqp}/bin/nqp" ]; <ins> disallowedReferences = [ stdenv.cc.cc ]; postFixup = '' remove-references-to -t ${stdenv.cc.cc} "$(readlink -f $out/share/perl6/runtime/dynext/libperl6_ops_moar.so)" ''; </ins> meta = with lib; { description = "Raku implementation on top of Moar virtual machine"; homepage    = "https://rakudo.org";

Discussion:
Describe the bug Rakudo depends on gcc unwrapped noticeably increasing closure size To Reproduce Steps to reproduce the behavior: rakudo Expected behavior Rakudo shouldn't depend on gcc. However, currently it does depend on gcc which causes closure bloat. Additional context Add any other context about the problem here. 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:
I marked this as stale due to inactivity. &rarr;
Change:
gbenchmark = callPackage ../development/libraries/gbenchmark {}; <ins> gkraken = callPackage ../tools/system/gkraken { }; </ins> gtkdatabox = callPackage ../development/libraries/gtkdatabox {}; gtklick = callPackage ../applications/audio/gtklick {};

Discussion:
Project description GUI that allows to control the cooling (fan and/or pump profiles) of NZXT Kraken X (X42, X52, X62, X72, X53, X63, X73, Z63 or Z73) devices from Linux. Metadata homepage URL: source URL: license: gpl3Plus platforms: linux
Change:
${pkgs.libsForQt5.kservice}/bin/kbuildsycoca5 ''; <ins> set_XDG_CONFIG_HOME = '' # Set the default XDG_CONFIG_HOME if it is unset. # Per the XDG Base Directory Specification: # https://specifications.freedesktop.org/basedir-spec/latest # 1. Never export this variable! If it is unset, then child processes are # expected to set the default themselves. # 2. Contaminate / if $HOME is unset; do not check if $HOME is set. XDG_CONFIG_HOME=''${XDG_CONFIG_HOME:-$HOME/.config} ''; </ins> startplasma = '' <del> export XDG_CONFIG_HOME="''${XDG_CONFIG_HOME:-$HOME/.config}" mkdir -p "''${XDG_CONFIG_HOME:?}" </del> <ins> ${set_XDG_CONFIG_HOME} mkdir -p "''${XDG_CONFIG_HOME}" </ins> '' + optionalString pulseaudio.enable ''

Discussion:
Describe the bug After upgrade to 20.03 nixos-activation.service don't start . Error log: nixos-activation.service - Run user-specific NixOS activation Loaded: loaded (/nix/store/jcv2nvwkdc4hlhfx2dcchw3xgnmgyk8n-unit-nixos-activation.service/nixos-activation.service; static; vendor preset: enabled) Active: failed (Result: exit-code) since Fri 2020-02-21 11:57:14 CET; 8s ago Process: ExecStart=/nix/store/6hls8gx0c7prqf6gc2s1q9kp5w57jnb4-unit-script-nixos-activation-start (code=exited, status=1/FAILURE) Main PID: (code=exited, status=1/FAILURE) lut 21 11:57:14 nixos systemd[1389]: Starting Run user-specific NixOS activation... lut 21 11:57:14 nixos 6hls8gx0c7prqf6gc2s1q9kp5w57jnb4-unit-script-nixos-activation-start[]: /nix/store/6hls8gx0c7prqf6gc2s1q9kp5w57jnb4-unit-script-nixos-activation-start: line 22: XDGCONFIGHOME: parameter null or not set lut 21 11:57:14 nixos systemd[1389]: nixos-activation.service: Main process exited, code=exited, status=1/FAILURE lut 21 11:57:14 nixos systemd[1389]: nixos-activation.service: Failed with result 'exit-code'. lut 21 11:57:14 nixos systemd[1389]: Failed to start Run user-specific NixOS activation. I am using home manager but empty profile without home manager is also broken. After switch channel to 19.09 everything is OK. To Reproduce Steps to reproduce the behavior: to 20.03 Additional context I am using KDE. Adding XDGCONFIGHOME to this file does not solve the problem completely. Service start but for ex. flatpak app not.

Metadata Please run and paste the result. nix-shell -p nix-info --run "nix-info -m" system: host os: multi-user?: sandbox: version: channels(root): channels(piotrek): nixpkgs: Maintainer information:
caused by
I had this issue too, and it can be fixed by enabling this : I am not really sure why, this fix come from another issue that is plasma related.
cc
Yes, it's solve error related to XDGCONFIGHOME but flatpak app still fail to launch. Starting KeePassXC result in error: The name org.freedesktop.Accounts was not provided by any .service files. Unrelated problem? EDIT: Yes, it's
As far as I understand this is actually a workaround and not a real solution. iirc the suggested workaround was for a now fixed problem where plasma wouldn't start due to a hardcoded limit on env vars
It is indeed a workaround, sorry for the bad phrasing. I know this is a workaround for another issue that has been merged, but it has fixed the issue for me.
Change:
patchelf  --add-needed ${curl.out}/lib/libcurl.so  --add-needed ${libvorbis}/lib/libvorbisfile.so  <ins> --add-needed ${libvorbis}/lib/libvorbisenc.so  </ins> --add-needed ${libvorbis}/lib/libvorbis.so  --add-needed ${libGL.out}/lib/libGL.so  <ins> --add-needed ${freetype}/lib/libfreetype.so  --add-needed ${libpng}/lib/libpng.so  --add-needed ${libtheora}/lib/libtheora.so  </ins> $out/bin/xonotic-glx '' + lib.optionalString withSDL '' patchelf  --add-needed ${curl.out}/lib/libcurl.so  --add-needed ${libvorbis}/lib/libvorbisfile.so  <ins> --add-needed ${libvorbis}/lib/libvorbisenc.so  </ins> --add-needed ${libvorbis}/lib/libvorbis.so  <ins> --add-needed ${freetype}/lib/libfreetype.so  --add-needed ${libpng}/lib/libpng.so  --add-needed ${libtheora}/lib/libtheora.so  </ins> $out/bin/xonotic-sdl ''; };

Discussion:
instead of UTF-8 characters there are often rectangles, spaces and random symbols ! ! ! !
Same here. Xonotic should have its own Xolonium font, but somewhy that one on screenshots is used instead.
Change:
nfstrace = callPackage ../tools/networking/nfstrace { }; nix-direnv = callPackage ../tools/misc/nix-direnv { }; <ins> nix-direnv-flakes = callPackage ../tools/misc/nix-direnv { enableFlakes = true; }; </ins> nix-output-monitor = haskell.lib.compose.justStaticExecutables (haskellPackages.nix-output-monitor);

Discussion:
nix-direnv was updated in to assume that is 2.4, but that is no longer true after was merged. This causes files with to fail to active the . Steps to reproduce the behavior: sure your system is running NixOS 21.11 or is nix-darwin following the nixos-21.11 channel; (or any project with a flake); and . The specified in the flake is activated. Overriding in an overlay with allows the flake to activate the as expected. Please run and paste the result. Maintainer information:
This is only for nixpkgs. There was also a home-manager module option that needs to be re-introduced:
Hi, had the same problem too, just updated and everything is fine, seems like it's fixed now.
Yes. This was fixed in the linked pull requests.
I'm using flakes for my configuration and I still exhibit the problem with these fixed inputs: Is this expected? Or am I doing something wrong?
Looks like it was a configuration problem (). Enabling solved the issue.
Change:
popd ''; <del> postInstall = '' # Use a standard font mkdir -p $out/share/mpv ln -s ${freefont_ttf}/share/fonts/truetype/FreeSans.ttf $out/share/mpv/subfont.ttf </del> <ins> postInstall = '' # Use a standard font mkdir -p $out/share/mpv ln -s ${freefont_ttf}/share/fonts/truetype/FreeSans.ttf $out/share/mpv/subfont.ttf </ins> <del> pushd ../TOOLS cp mpv_identify.sh umpv $out/bin/ popd pushd $out/share/applications </del> <ins> pushd ../TOOLS cp mpv_identify.sh umpv $out/bin/ popd pushd $out/share/applications </ins> <del> # patch out smb protocol reference, since our ffmpeg can't handle it substituteInPlace mpv.desktop --replace-fail "smb," "" </del> <ins> # patch out smb protocol reference, since our ffmpeg can't handle it substituteInPlace mpv.desktop --replace-fail "smb," "" </ins> <del> sed -e '/Icon=/ ! s|mpv|umpv|g; s|^Exec=.*|Exec=umpv %U|'  mpv.desktop > umpv.desktop printf "NoDisplay=truen" >> umpv.desktop popd '' + lib.optionalString stdenv.isDarwin '' mkdir -p $out/Applications cp -r mpv.app $out/Applications ''; </del> <ins> sed -e '/Icon=/ ! s|mpv|umpv|g; s|^Exec=.*|Exec=umpv %U|'  mpv.desktop > umpv.desktop printf "NoDisplay=truen" >> umpv.desktop popd '' + lib.optionalString stdenv.isDarwin '' mkdir -p $out/Applications cp -r mpv.app $out/Applications ''; </ins> # Set RUNPATH so that libcuda in /run/opengl-driver(-32)/lib can be found. # See the explanation in addOpenGLRunpath.

Discussion:
Package name: Latest released version: <!-- Search your package here: --- Current version on the unstable channel: Current version on the stable/release channel: <!-- 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. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Yeeessaah!
Change:
, which }: <ins> let # avoid "malformed 32-bit x.y.z" error on mac when using clang isCleanVer = version: builtins.match "^[0-9].+[0-9]+.[0-9]+" version != null; in </ins> stdenv.mkDerivation rec { pname = "tcc"; version = "unstable-2022-07-15";

Discussion:
Deno no longer working on darwin due to tinycc being broken. error: Package ‘tcc-0.9.27+date=2022-01-11’ in /nix/store/4la4fc5wfn4p0784i12h0a046yqzln16- is marked as broken, refusing to evaluate. It works. Looks like this happened with the move to Deno 1.23.4: Issue related to tinycc being broken: deno: tinycc:
Thanks for raising this. I shouldn't have missed this. I'll try fix tinycc and if we can't Mac might be able to fall back to the same non-tinycc method (even if it has some performance penalties) until they migrate to asm
Thanks for being on this
if you could try out that'd be helpful
i'm on it!
succeeded for me on x86_64-darwin
Nice, it worked for me in my x8664-darwin vm but it's always good to get it checked on real hardware. Would be nice to have someone try it on aarch64-darwin As a note if you want to do a "full" test of the FFI features (the one that requires tcc now) git clone /tmp/deno cd /tmp/deno mkdir -p ./target/result cp /location/of/the/nixpkgs/result/bin/deno ./target/result/ target/release/deno bench --allow-ffi --allow-read --unstable
Ran it on my aarch64-darwin machine:
fantastic thanks
also worked for me on aarch64 (i used an EC2 m1 macos instance). Unfortunately running the FFI tests requires a to be in the directory, which I noticed is output when running outside of nix. However, on aarch64, I can't get a direct to succeed...
sorry I missed a step there try if you still have the instance
cool, that worked.

the benchmarks ran without error...
Reopening as does not resolve this issue
That PR does resolve the issue, see the comments towards the bottom to pull in the fix early The unstable channel hasn't progressed for and not in scope for this issue ~I will open a backport ticket for 22.05 though~ actually is on which is unaffected by this issue
Yes, this is confirmed by ofborg.
OMG Sorry that I didn't follow the PR correctly. Not only I missed the part you fixed on the derivation of deno, but I saw the tinycc's derivation flagged as and mistook that it is the same on deno's. The old message of the beginning of the PR ("tinycc darwin issues were a pain, there's no point holding up this update since it's already broken") also made me confused and gave an idea that this issue was closed by mistake. Sorry for confusing everyone here, and thank you very much for fixing the problem!
I'd pretty much given up on trying to make tinycc build properly on darwin but as a last-ditch effort I tried just building the static lib on it's own and to my surprise it worked just fine
Change:
and fix all the bugs it uncovers. </para> </listitem> <ins> <listitem> <para> The <literal>vlc</literal> package gained support for Chromecast streaming, enabled by default. TCP port 8010 must be open for it to work, so something like <literal>networking.firewall.allowedTCPPorts = [ 8010 ];</literal> may be required in your configuration. Also consider enabling <link xlink:href="https://nixos.wiki/wiki/Accelerated_Video_Playback"> Accelerated Video Playback</link> for better transcoding performance. </para> </listitem> </ins> </itemizedlist> </section> </section>

Discussion:
The current vlc derivation does not include chromecast support. I believe we need to add the flags during the configuration step to enable it by default, which I think is a reasonable thing to do. I tried to do the minimal change myself, but looks like we need some new dependencies that don't exist in nixpkg yet: I'm still fairly new so it will take some learning to figure out what needs to be done to package protobuf-lite (not sure I'll get around to it anytime soon). If anyone else is into making these changes, it would be much appreciated. Or please let me know if I'm off-track here and there's a better way to do this.
You're on the right track. This should work:
Ah, now it builds, and I can see the relevant chromecast features, but it's still not finding the chromecast. Thank you! Sounds like that happens when microdns is not available. I tried adding nssmdns to the derivation but that didn't do the trick. is enabled. Hmmmm.
FWIW (mostly because I like linking things together), but sounds like you're past what is useful from that :). I frequently find chromecast programs on NixOS don't work... especially scanning support... with the firewall enabled. . Should only need mdns support for discovery/scanning, I think :).
Yea I did see that. I don't think it's the firewall, as google-chrome chromecasts fine. Even VLC via flatpak manages to connect to the chromecast (but fails to encode due to some other error). I believe mdns is used to find the chromecast automagically.
Make sure avahi is running and that mdns is set in resolvconf
Avahi is running and nssmdns is enabled, if that's what you mean. Is it working for you? Reading an older VLC PR: Sounds like we need VLC's own libmicrodns packaged before this will work: Edit: Indeed building with :
I managed to package up libmicrodns and it's working now! I'll clean up and send a PR. :) Thanks for the help everyone.
Change:
webserver.succeed("systemctl restart caddy.service") check_connection_key_bits(client, "a.example.test", "384") <del> domains = ["http", "dns", "wildcard"] for server, logsrc in [ ("nginx", "journalctl -n 30 -u nginx.service"), ("httpd", "tail -n 30 /var/log/httpd/*.log"), </del> <ins> common_domains = ["http", "dns", "wildcard"] for server, logsrc, domains in [ ("nginx", "journalctl -n 30 -u nginx.service", common_domains + ["different-key"]), ("httpd", "tail -n 30 /var/log/httpd/*.log", common_domains), </ins> ]: wait_for_server = lambda: webserver.wait_for_unit(f"{server}.service") with subtest(f"Works with {server}"): try: switch_to(webserver, server) <del> # Skip wildcard domain for this check ([:-1]) for domain in domains[:-1]: webserver.wait_for_unit( f"acme-finished-{server}-{domain}.example.test.target" ) </del> <ins> for domain in domains: if domain != "wildcard": webserver.wait_for_unit( f"acme-finished-{server}-{domain}.example.test.target" ) </ins> except Exception as err: _, output = webserver.execute( f"{logsrc} && ls -al /var/lib/acme/acme-challenge"

Discussion:
If you have: During evaluation I get this error , pointing to the line Steps to reproduce the behavior: As described above I think this is because here The pairs are made using the , while here: It is trying to use the vhostName. So I think it should be Also, maybe this could be a problem as well, however I am not sure: I would submit a MR, but embarrassingly, I couldn't figure out how to test a patched nixpkgs lib in a flake without having my whole system rebuilt. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Broken by . Fixed by .
Change:
"orjson" ]; <ins> build-system = [ setuptools setuptools-scm ]; </ins> nativeBuildInputs = [ cargo pkg-config protobuf rustc rustPlatform.cargoSetupHook <del> setuptools setuptools-scm </del> ]; buildInputs = [

Discussion:
Steps to reproduce the behavior: the chromadb python package for python310. [1/7/9 built] building python3.10-chromadb-0.5.0 (pytestCheckPhase): chromadb/test/auth/testbasicauth[1/7/9 built] building python3.10-chromadb-0.5.0 (pytestCheckPhase): chromadb/test/aut[1/7/9 built] building python3.10-chromadb-0.5.0 (pytestCheckPhase): ... [ 4%] [1/7/9 built] building python3.10-chromadb-0.5.0 (pytestCheckPhase): ... [ 4%] [1/7/9 built] building python3.10-chromadb-0.5.0 (pytestCheckPhase): ... [ 4%] This is not the complete log but it is all that is visible in my terminal since only keeps the latest however many lines. The build reaches this test at 4% every time and then stalls there. I was able to fix the issue by adding an overlay to disable pytestCheckPhase, but this is obviously a workaround. <!-- 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]:
The are flaky. I will ship an update later.
Change:
--replace "time.NewTimer(time.Second * 10)" "time.NewTimer(time.Second * 120)"  ''; <del> ldflags = [ "-s" "-w" "-X github.com/VictoriaMetrics/VictoriaMetrics/lib/buildinfo.Version=${version}" ]; </del> <ins> ldflags = [ "-s" "-w" "-X github.com/VictoriaMetrics/VictoriaMetrics/lib/buildinfo.Version=${version}" ]; </ins> preCheck = '' # `lib/querytracer/tracer_test.go` expects `buildinfo.Version` to be unset

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:
''; doInstallCheck = false; <del> requiredSystemFeatures = []; </del> <ins> passthru = oldAttrs.passthru // { inherit betterbird-patches; }; </ins> })

Discussion:
Package name: betterbird Latest released version: 102.12.0-bb37 Current version on the unstable channel: 102.8.0-bb30 Current version on the stable/release channel: 102.8.0-bb30 Notify maintainers The package is outdated since a while. I hope it can be updated in the near feature. Thank you :) Note for maintainers: Please tag this issue in your PR.
see
Change:
"-e" (builtins.toFile "bash-builder.sh" '' export CONFIG_SHELL=$SHELL <ins> # Normalize the NIX_BUILD_CORES variable. The value might be 0, which # means that we're supposed to try and auto-detect the number of # available CPU cores at run-time. We don't have nproc to detect the # number of available CPU cores so default to 1 if not set. NIX_BUILD_CORES="''${NIX_BUILD_CORES:-1}" if [ $NIX_BUILD_CORES -le 0 ]; then NIX_BUILD_CORES=1 fi export NIX_BUILD_CORES </ins> bash -eux $buildCommandPath '') ];

Discussion:
When built with default Nix options, is 0, meaning auto. The stdenv guesses the "correct" core count: minimal-bootstrap just makes fail. Here the build of for example: <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --
Change:
<del> { lib , stdenv , fetchFromGitHub , libX11 }: stdenv.mkDerivation rec { pname = "xmcp"; version = "unstable-2020-10-10"; src = fetchFromGitHub { owner = "blblapco"; repo = "xmcp"; rev = "ee56225f1665f9edc04fe5c165809f2fe160a420"; sha256 = "sha256-B3YkYrVEg6UJ2ApaVook4N2XvrCboxDMUG5CN9I79Sg="; }; buildInputs = [ libX11 ]; installPhase = '' runHook preInstall install -Dm0755 xmcp $out/bin/xmcp runHook postInstall ''; meta = with lib; { description = "Tiny color picker for X11"; homepage = "https://github.com/blblapco/xmcp"; license = licenses.gpl3Plus; maintainers = with maintainers; [ azahi ]; platforms = platforms.linux; }; } </del>

Discussion:
Updating the unstable channel fails on Darwin: this seems to be due to the by-default case-preserving nature of APFS (and HFS+), introduced with this PR: which adds a path which to macOS is the same as the already existing path. Steps to reproduce the behavior: the unstable channel to a macOS machine A new version of the channel is successfully to the machine. Please run and paste the result.
My bad. Should we add a channel blocker label to this to get the PR merged faster?
Change:
nwg-launchers = callPackage ../applications/misc/nwg-launchers { }; <ins> nwg-look = callPackage ../applications/misc/nwg-look { }; </ins> nwg-menu = callPackage ../applications/misc/nwg-menu { }; nwg-panel = callPackage ../applications/misc/nwg-panel { };

Discussion:
Project description A GTK3 settings editor adapted to work in the wlroots environment, a part of the nwg-shell project. <!-- Describe the project a little: --Metadata homepage URL: https://nwg- source URL: license: MIT platforms: Linux
I am happy to work on this and I am currently working a pr to implement it!