jiebi/CodeConvo huggingface dataset:
Change:
$machine->waitForUnit('multi-user.target'); $machine->succeed('sysctl net.core.default_qdisc | grep -q "fq_codel"'); }; <ins> # Test cgroup accounting is enabled subtest "systemd cgroup accounting is enabled", sub { $machine->waitForUnit('multi-user.target'); $machine->succeed('systemctl show testservice1.service -p IOAccounting | grep -q "yes"'); $machine->succeed('systemctl status testservice1.service | grep -q "CPU:"'); }; </ins> ''; })

Discussion:
I want to see systemd services in netdata monitoring. For that "cgroup accounting" is needed. The question is if enabling it on all systems would have any negative effect. In that case i would activate it only when netdata service is enabled. Arch Linux, Ubuntu and Fedora seem to have it enabled by default. debian not. shows no resources for services. System: NixOS 17.03.1700. (Gorilla) Nix version: nix-env (Nix) 1.11.13 Nixpkgs version: "17.03.1700." Sandboxing enabled: build-use-sandbox = true
I will implement it as option, that is enabled by default and for netdata service.
I believe you can set this with: And maybe also: (ideas from )
sure, that is how i do it right now. But i want to propose it to be enabled by default, so you have it when you need it for debugging. But also a single option to disable it when you have reasons to.
Is this still open for the discussion about defaulting to or is this still open simply because it wasn't closed? Unless something else than the PR is required? (
I created this issue to have this enabled for netdata. So an additional PR needs to be created to enable the new option when netdata is enabled. In addition it could be discussed to enable the option by default when a desktopManager is enabled (for desktop users). It should not be enabled by default on servers because it could have a little impact on performance.
Nowadays, this might already be enabled per default half-way: from my `systemd- (latest master right now) Are there any recent figures about performance implications when enabling the rest? If Fedora enables it, we could probably do so too.
this might already be enabled per default half-way thanks for noticing! can you create an issue or PR to change ? Are there any recent figures about performance implications when enabling the rest? i don't know any. i have no issues on my servers where i set it manually
Change:
outputs = [ "out" "doc" ]; patches = [ <del> # Hardcode system installed banks & presets </del> <ins> # Lazily expand ZYN_DATADIR to fix builtin banks across updates </ins> (fetchpatch { <del> url = "https://patch-diff.githubusercontent.com/raw/zynaddsubfx/zynaddsubfx/pull/295.patch"; hash = "sha256-UN62i9/JBs7uWTmHDKk3lkAxUXsVmIs6+6avOcL1NBg="; </del> <ins> url = "https://github.com/zynaddsubfx/zynaddsubfx/commit/853aa03f4f92a180b870fa62a04685d12fca55a7.patch"; hash = "sha256-4BsRZ9keeqKopr6lCQJznaZ3qWuMgD1/mCrdMiskusg="; </ins> }) ];

Discussion:
I upgraded Zynaddsubfx (latest unstable), and was surprised to discover the new amazing interface (whooa)... and that I had no more loaded instrument (empty bank). I solved that problem by removing the user zynaddsubfx configuration and bank cache (I think the problem is the bank cache): and indeed, once you reload zynaddsubfx, you can see that the instruments are back. Also, a new file is created, and the bank path is hardcoded, like: I guess that in other distributions this path does not change when zynaddsubfx is updated, but with nix the bank path changes on upgrade, so the user needs to manually clear the cache on each upgrade. I'm not sure what's the best way to solve this problem. I was thinking that the best solution may be to add a small wrapper around zynaddsubfx which clears the cache if it detects in a path to another nix executable. The other possibility may be to use instead of the one, but it won't work outside of NixOs. If these options are not working, at least it would be nice to document that bank cache should be cleared on upgrades. Steps to reproduce the behavior: zynaddsubfx and potentially garbage collect the old version zynaddsubfx: instruments may disapear
Yeah it's really nice :blush: It was a lot of work to get it built. I'm not sure if any other distro even uses the new Zyn-Fusion interface, because it's not the default UI when building from source. I also noticed this problem before between upgrading & running . I tried working on a patch to avoid dumping the default paths into the config, but I never finished it. I'll try looking into it again!
I marked this as stale due to inactivity. &rarr;
still relevant, just haven't gotten around to fixing it
I think this issue should not be closed as for now it is based on a non-accepted PR , so I'll re-open waiting for the changes to be merged upstream.
Change:
buildInputs = [ bash ]; installPhase = '' installManPage grimshot.1 <ins> installShellCompletion --cmd grimshot grimshot-completion.bash </ins> install -Dm 0755 grimshot $out/bin/grimshot wrapProgram $out/bin/grimshot --set PATH 

Discussion:
Steps to reproduce the behavior: add --wait to your command, for instance: no warning on nixos unstable <!-- 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:
azure-cli = callPackage ../tools/admin/azure-cli { }; <ins> azure-functions-core-tools = callPackage ../development/tools/azure-functions-core-tools { }; </ins> azure-storage-azcopy = callPackage ../development/tools/azcopy { }; azure-vhd-utils  = callPackage ../tools/misc/azure-vhd-utils { };

Discussion:
Project description Command line tools for Azure Functions Existing package from here: Metadata homepage URL: source URL: license: mit platforms: unix
Change:
]; disabledTestPaths = [ <ins> "tests/dependencies" "tests/unit/botocore" </ins> # Integration tests require networking "tests/integration"

Discussion:
Steps to reproduce the behavior: awscli2 New to NixOS, I ran and . Removing and reinstalling the package did not fix the issue. Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Hello Thank you for reporting the issue. Indeed, I have a PR to upgrade awscli2 to 2.15.29 whose the build is failing now after rebasing it with master: Looks like the issue could be caused by this python-updates PR merged into staging branch: (and then merged into master yesterday: ) Looks like could be the cause. I will take a look.
Indeed, used to check if the installed dependencies meets constraints does only supports simple version numbers (X.Y.Z). And version does not parse and the script fails ( is also not semver compliant, and using ).
I am also experiencing the same issue
Looks like upstream may be trying to avoid this version too for now, they made recently pinning it to . Overriding the package to use (and adding a substitution for 's version string and some test weirdness) seems to let it build -- maybe just worth doing that in your upgrade PR?
Thanks for your help. Indeed, looks like pinning python-dateutil to 2.8.2 is a resolution: Yes, I the fix in my upgrade PR.
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:
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
The build has just passed on Hydra:
Its arrived in . I think this can be closed now
Yes we can close now :)
Awesome, thank you for your help !
Change:
hasura-cli = callPackage ../servers/hasura/cli.nix { }; <del> inherit (callPackage ../servers/hbase {}) hbase_1_7 hbase_2_4 hbase_3_0; hbase1 = hbase_1_7; hbase2 = hbase_2_4; </del> <ins> inherit (callPackage ../servers/hbase {}) hbase_2_4 hbase_2_5 hbase_3_0; hbase2 = hbase_2_5; </ins> hbase3 = hbase_3_0; hbase = hbase2; # when updating, point to the latest stable release

Discussion:
Apache HBase 1.7 EOL was in 2022/08, can we remove it? via
Hey. Thanks for reminding me. I have a WIP PR for this: I'm not sure why I left it as a draft... I'll go over it again and open it if it's ready.
Change:
hasAllowedInsecure = attrs: (attrs.meta.knownVulnerabilities or []) == [] || allowInsecurePredicate attrs || <del> config.allowInsecure or false; </del> <ins> builtins.getEnv "NIXPKGS_ALLOW_INSECURE" == "1"; </ins> showLicense = license: toString (map (l: l.shortName or "unknown") (lib.lists.toList license));

Discussion:
Describe the bug Unable to evaluate due to bug To Reproduce Expected behavior does a nix-review Additional context Add any other context about the problem here. Metadata
Change:
qtbase qtdeclarative qtsvg qtlocation qtwebchannel qtwebengine ]; in <del> stdenv.mkDerivation rec { </del> <ins> mkDerivation rec { </ins> pname = "eagle"; version = "9.5.0";

Discussion:
Describe the bug Eagle does not start anymore. When starting it from the command line I get the following message: To Reproduce Steps to reproduce the behavior: eagle it by calling Expected behavior Instead of getting an error message on the console, I'd expect the software to show a graphical window. Metadata system: host os: multi-user?: sandbox: version: channels(root): channels(matthias): nixpkgs: Maintainer information:
cc
I noted this as well
CC maintainer
it has to do with the qt wrapping, and i keep forgetting the best practices
AFAIK, the eagle expression should use mkDerivation from qt instead of stdenv. And perhaps look into using autoPatchelfHook.
I tried that, but it needs some non-qt libraries, and felt like i was wasting too much time on it, so i moved on
Hmm, I'll try to look into the issue this week.
I think this should fix it:
It's probably going to be wrapped several times because of the old logic
How can I apply this patch locally? I tried to load eagle from nixos-unstable, but that patch isn't there yet.
Thanks for merging it :)
Change:
description = "Service to forward websocket connections to TCP connections (from port:to port %I)"; script = '' IFS=':' read -a array <<< "$1" <del> ${pkgs.pythonPackages.websockify}/bin/websockify --ssl-only  </del> <ins> ${pkgs.python3Packages.websockify}/bin/websockify --ssl-only  </ins> --cert=${cfg.sslCert} --key=${cfg.sslKey} 0.0.0.0:''${array[0]} 0.0.0.0:''${array[1]} ''; scriptArgs = "%i";

Discussion:
Steps to reproduce the behavior: this code to : the command sudo nixos-rebuild switch It's asking to use 2.7 for websockify (insecure) adding it and rebuild, websockify refuse by telling that it doesn't support 2.7 :-/ checking in , it seems like this package require Python 3.11 or 3.10 (I do have it on my machine). using this tuto to access VM from Browser : I've searched for were was the 2.7 marked, but couldn't find it. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- (based on ) Please run and paste the result.
Change:
### C ### <ins> calligra = kdePackages.calligra; # Added 2024-09-27 </ins> callPackage_i686 = pkgsi686Linux.callPackage; cadence = throw "cadence has been removed from nixpkgs, as it was archived upstream"; # Added 2023-10-28 cask = emacs.pkgs.cask; # Added 2022-11-12

Discussion:
Package name: calligra Latest released version: 4.0.0 <!-- Search your package here: --- Current version on the unstable channel: 3.2.1 Current version on the stable/release channel: 3.2.1 <!-- 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]:
Github moment. Completed in .
Change:
<del> { lib , stdenv , fetchFromGitHub , pkg-config , autoreconfHook , enablePsm2 ? (stdenv.isx86_64 && stdenv.isLinux) , libpsm2 , enableOpx ? (stdenv.isx86_64 && stdenv.isLinux) , libuuid , numactl }: </del> <ins> { lib, stdenv, fetchFromGitHub, pkg-config, autoreconfHook, libpsm2 , enablePsm2 ? (stdenv.isx86_64 && stdenv.isLinux) }: </ins> stdenv.mkDerivation rec { pname = "libfabric"; <del> version = "1.17.0"; </del> <ins> version = "1.15.1"; </ins> enableParallelBuilding = true;

Discussion:
fails the build, because running the tests terminates with a segfault on unstable. Complete build log: Build succeeds. N/A N/A <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Please run and paste the result. system: host os: multi-user?: sandbox: version: channels(henri): nixpkgs:
Bisected to
I just tried : it does not segfault, but it causes the test to hang.
It seems that there are at least two problems: the segfault in the test and the hanging test. I suggest reverting the upgrade back to version for now. Maybe has an idea or wants to report the issue upstream?
Well, there's a bunch of ways to start openmpi, with many many options and some combinations may lead to such segfault. I see that before the backtrace, there's an UCX error about the tcp interface not found. Then, the OFI BTL seems to be used. But OFI (open fabric interface) is meant to be used on computing nodes hosting a specific network interface. I suggest trying to force the mpi4py test to use the "VADER" or "SELF" interface: or You may also try or
That is true, but I think the default should just work and not segfault. You can make the tests in mpi4py pass by setting in its test phase, but I don't think this is a good solution. Rather should the auto-detect mechanism just work without crashing. EDIT: this could be an acceptable solution if the failure is specific to the builder's sandbox, but does not appear if used outside the sandbox.
Maybe let's start with adding to the test phase to get the ball rolling and improve further at a later time if necessary.
Isn't that just masking the problem? It then may just break at run time, which is could be super annoying for someone who does not know why this happens.
I see the libfabric update was just reverted although I wonder whether this will work out in the long run. An update will be necessary sooner or later.
I agree, that we should update libfabric at some point, but at least we have everything in a well working state right now. IMHO that should have higher priority than updating at any cost.

I would expect that we can either find a proper solution to fix the problem or that, ideally, libfabric is fixed upstream. Is someone willing to report this issue upstream?
I reported it here
Change:
<ins> { stdenv, buildGoPackage, fetchFromGitHub, pkg-config, libsecret }: buildGoPackage rec { pname = "docker-credential-helpers"; version = "0.6.3"; goPackagePath = "github.com/docker/docker-credential-helpers"; src = fetchFromGitHub { owner = "docker"; repo = pname; rev = "v${version}"; sha256 = "0xgmwjva3j1s0cqkbajbamj13bgzh5jkf2ir54m9a7w8gjnsh6dx"; }; nativeBuildInputs = stdenv.lib.optionals stdenv.isLinux [ pkg-config ]; buildInputs = stdenv.lib.optionals stdenv.isLinux [ libsecret ]; buildPhase = if stdenv.isDarwin then '' cd go/src/${goPackagePath} go build -ldflags -s -o bin/docker-credential-osxkeychain osxkeychain/cmd/main_darwin.go '' else '' cd go/src/${goPackagePath} go build -o bin/docker-credential-secretservice secretservice/cmd/main_linux.go go build -o bin/docker-credential-pass pass/cmd/main_linux.go ''; installPhase = if stdenv.isDarwin then '' install -Dm755 -t $bin/bin bin/docker-credential-osxkeychain '' else '' install -Dm755 -t $bin/bin bin/docker-credential-pass install -Dm755 -t $bin/bin bin/docker-credential-secretservice ''; meta = with stdenv.lib; { description = "Suite of programs to use native stores to keep Docker credentials safe"; homepage = "https://github.com/docker/docker-credential-helpers"; license = licenses.mit; maintainers = [ maintainers.marsam ]; platforms = platforms.linux ++ platforms.darwin; }; } </ins>

Discussion:
Project description docker-credential-helpers is a suite of programs to use native stores to keep Docker credentials safe. Metadata (same as source) source URL: license: mit platforms: unix, linux, darwin Please note that contains multiple programs: (Windows specific) These might want to be shipped as independent packages Some of them are platform specific while others like , should work on both darwin (), linux and BSDs as well.
Change:
sha256_64bit = "sha256-Xagqf4x254Hn1/C+e3mNtNNE8mvU+s+avPPHHHH+dkA="; settingsSha256 = "sha256-ryUSiI8PsY3knkJLg0k1EmyYW5OWkhuZma/hmXNuojw="; persistencedSha256 = "sha256-/2h90Gq9NQd9Q+9eLVE6vrxXmINXxlLcSNOHxKToOEE="; <ins> prePatch = "pushd kernel"; postPatch = "popd"; patches = [ # source: https://gist.github.com/joanbm/963906fc6772d8955faf1b9cc46c6b04 (fetchpatch { url = "https://gist.github.com/joanbm/963906fc6772d8955faf1b9cc46c6b04/raw/0f99aa10d47b524aa0e6e3845664deac3a1ad9d9/nvidia-470xx-fix-linux-6.2.patch"; hash = "sha256-5n5/4ivK8od8EJNJf0PI9ZZ4U5RjOw+h4HakA+lmW1c="; }) # source: https://gist.github.com/joanbm/d10e9cbbbb8e245b6e7e27b2db338faf (fetchpatch { url = "https://gist.github.com/joanbm/d10e9cbbbb8e245b6e7e27b2db338faf/raw/f5d5238bdbaa16cd4008658a0f82b9dd84f1b38f/nvidia-470xx-fix-linux-6.3.patch"; hash = "sha256-mR+vXDHgVhWC0JeLgGlbNVCH8XTs7XnhEJS6BV75tI8="; }) ]; </ins> }; # Last one supporting x86

Discussion:
with nixpkgs Steps to reproduce the behavior: kernel 6.1.10 <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- system: host os: multi-user?: sandbox: version: nixpkgs:
Looks like this is the patch other distros are using: Bonus patch for 6.3 if Nvidia doesn't release a maintenance update:
Change:
<ins> --- a/plug-ins/pygimp/Makefile.am +++ b/plug-ins/pygimp/Makefile.am @@ -157,7 +157,7 @@ install-interp-file: echo 'python=$(PYBIN_PATH)' > '$(DESTDIR)$(pyinterpfile)' echo 'python2=$(PYBIN_PATH)' >> '$(DESTDIR)$(pyinterpfile)' echo '/usr/bin/python=$(PYBIN_PATH)' >> '$(DESTDIR)$(pyinterpfile)' -	echo ":Python:E::py::`basename $(PYTHON)`:" >> '$(DESTDIR)$(pyinterpfile)' +	echo ":Python:E::py::$(PYTHON):" >> '$(DESTDIR)$(pyinterpfile)' install-data-local: install-env-file install-interp-file </ins>

Discussion:
Describe the bug GIMP uses Python and GTK+ for e.g. plugins. But GIMP in the NixOS-GIMP-package cannot find the Python-gtk-module: GIMP itself starts, but e.g. some plugins cannot be used, e.g. . When selecting this plugin, nothing happens, and the following error is shown in the console (again): To Reproduce Steps to reproduce the behavior: GIMP. GIMP. at the error-messages. Metadata system: host os: multi-user?: sandbox: version: channels(root): nixpkgs:
Can confirm this still doesn't work. Of note is that installing will allow when used from the REPL, but GIMP will still not recognize it. Tagging since they are tagged as the maintainer.

I see the following warnings when running gimp: Not sure if they are critical or not. I do have problems with one Python plugin, not sure if this could be related. Run gimp from the terminal. I'm running it from i3+none desktop environment, if that matters. Please run and paste the results.
I can see the warning too. This is what the file looks like on Arch: nothing special compared to ours: The file exists and is executable Not really sure what is wrong. Also the Python scripts seem to work, at least does.
For me, resynthesizer runs but it doesn't produce correct results:
Thank you for your contributions. This has been automatically marked as stale because it has had no activity for 180 days. If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity. Here are suggestions that might help resolve this more quickly: for maintainers and people that previously touched the related code and @ mention them in a comment. on the . on the on .
Still important to me. This is the current console output:
I have found this issue can be fixed by installing the python package by yourself (which is weird: it looks like GIMP may be trying to use the command from your ). I have it in my systemPackages and I got past that stage. However, is still blocking the usage of some plugins.
Spent some time in and it looks like the extension mapping from file only searches in path, not in the mapping described on previous lines and registered in : : The extension is so some other mechanism than extension matching must be involved – perhaps shebangs are applied. We will still want to hardcode the path to ensure purity.
Change:
<xref linkend="opt-services.xserver.videoDrivers" /> no longer uses the deprecated <literal>cirrus</literal> and <literal>vesa</literal> device dependent X drivers by default. It also enables both <literal>amdgpu</literal> and <literal>nouveau</literal> drivers by default now. </para> </listitem> <ins> <listitem> <para> The <literal>kindlegen</literal> package is gone, because it is no longer supported or hosted by Amazon. Sadly, its replacement, Kindle Previewer, has no Linux support. However, there are other ways to generate MOBI files. See <link xlink:href="https://github.com/NixOS/nixpkgs/issues/96439">the discussion</link> for more info. </para> </listitem> </ins> </itemizedlist> </section>

Discussion:
. Consequently, the is broken. I suppose we need to choose whether to remove the package or find a mirror? CC maintainer: Side notes: Sadly, its replacement, , has no Linux support. But on a more positive note, there are other programs that can produce mobi files, some mentioned in .
I suggest we just drop it. Considering that kindlegen was under an unfree license, we're probably not allowed to distribute it, so let's just blow it away with a release note entry that mentions some alternatives.
I marked this as stale due to inactivity. &rarr;
My current recommendation for NixOS is to use calibre for conversion. It also has commandline tools for scripting.
Change:
, cmake , cups , fetchurl <del> , fetchpatch </del> , fontconfig , freetype , harfbuzzFull

Discussion:
Package name: scribus Latest released version: 1.6.0 Current version on the unstable channel: 1.5.8 Current version on the stable/release channel: 1.4.8 Notify maintainers Note for maintainers: Please tag this issue in your PR. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
The version on the stable channel is also 1.5.8, 1.4 existed only on the old NixOS 23.05 release and got removed since.