jiebi/CodeConvo huggingface dataset:
Code change:
<del> { stdenv, lib, fetchFromGitHub, cmake, pkg-config , mpg123, ffmpeg, libvorbis, libao, jansson, speex </del> <ins> { stdenv, lib, fetchFromGitHub, cmake, pkg-config, gtk3 , audacious, mpg123, ffmpeg, libvorbis, libao, jansson, speex </ins> , nix-update-script <ins> , buildAudaciousPlugin ? false  # only build cli by default, pkgs.audacious-plugins sets this to enable plugin support </ins> }: stdenv.mkDerivation rec {

Related discussion:
text: The audacious package imports audacious-plugins to build most of the common plugins and then link them into the audacious lib path. However, this makes it hard to add more audacious plugins, like vgmstream. The vgmstream package currently has its , because importing the audacious package causes an infinite recursion error. Steps to reproduce the behavior: vgmstream to audacious-plugins buildInputs audacious to vgmstream's buildInputs and comment out the disable configure flag -shell -p audacious-plugins I expected that adding vgmstream to audacious-plugins would enable the plugin. Instead, the build crashes with an infinite recursion. How is it currently working for audacious to import audacious-plugins and audacious-plugins to import audacious? Can this same magic be extended to other plugins? This about how fcitx is packaged shows that fcitx-addons imports fcitx with no reverse import, should the audacious package be refactored to be similar? Should the audacious package gain an extra parameter to take extra plugin derivations, which can be created outside of the audacious-plugins derivation? Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Instead of adding , did you try to add instead? is without as input, and it is used to break the loop.
Thank you for the quick response! That would be elegant, but I don't see any result in my grep of nixpkgs or in the .
Sorry, it is here: Basically you need to do and this should do the trick. Considering that we are going to use this in more than one place it probably makes sense to introduce it as a , but the result is the same regardless.
Oh that's a neat trick! I'll try that approach out next. Thank you so much! I tried out the extra-plugins approach here, seems to work but is not ergonomic:
I , and it's a lot easier to use as a user! If it looks good as an approach, please provide some review feedback and I'll squash it down for a PR :)
Shall I send a PR for a final review?
Code change:
extraInstallCommands = '' # Add desktop convencience stuff <del> mv $out/bin/{${name},${pname}} </del> <ins> mv $out/bin/{${pname}-*,${pname}} </ins> install -Dm444 ${appimageContents}/flexoptix-app.desktop -t $out/share/applications install -Dm444 ${appimageContents}/flexoptix-app.png -t $out/share/pixmaps substituteInPlace $out/share/applications/flexoptix-app.desktop 

Related discussion:
text: name: flexoptix-app current version: 5.11.0 desired version: 5.12.1 maintainers: Please tag this issue in your PR.
Code change:
, xdg-dbus-proxy , substituteAll , glib <ins> , addOpenGLRunpath </ins> }: assert enableGeoLocation -> geoclue2 != null;

Related discussion:
text: Describe the bug Epiphany crashes on startup with a bind mount error. To Reproduce Steps to reproduce the behavior: epiphany Expected behavior The browser should startup Additional context Error: exists and opengl is enabled I bet is relevant 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:
I can't reproduce this on my machine. Can you try running it with ?
Thanks for responding. I think this is the relevant part from :
Ah, this only shows that emits the error message. To trace what it actually does, could you try adding the flag?
I just piped it all into here:
The output got cut off there, unfortunately. Maybe you could just attach the text file directly to your reply?
Sorry about that, here is the file:
Thanks for the log! I think I've found the culprit. I've opened which seems to fix it - please try it out.
Code change:
--replace "/etc/g810-led/profile" "${profile}" ''; <ins> # GCC 13 cannot find `uint16_t` and other similar types by default anymore env.CXXFLAGS = "-include cstdint"; </ins> buildInputs = [ hidapi ];

Related discussion:
text: Steps to reproduce the behavior: g810-led Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Code change:
owner = "tailscale"; repo = "tailscale"; rev = "v${version}"; <del> hash = "sha256-aweJys46MMnkSKJoLUFCzc6sWUP+Cv5+IFVVe9iEPGI="; </del> <ins> hash = "sha256-jWnke49b6inybPmiZOkxI3C8VoYe4Syi84YhvL8zxeI="; </ins> }; <del> vendorHash = "sha256-oELDIt+mRiBGAdoEUkSAs2SM6urkHm1aAtJnev8jDYM="; </del> <ins> vendorHash = "sha256-Fr4VZcKrXnT1PZuEG110KBefjcZzRsQRBSvByELKAy4="; </ins> nativeBuildInputs = lib.optionals stdenv.isLinux [ makeWrapper ];

Related discussion:
text: 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.
You don't need to open an issue if you're going to make a PR right after.
Apologies, my bad. I was not aware :(. I am only 1 day & 1 PR old here.
Code change:
sha256 = "119kj2w0rrxkhg4f9cf5waa55jz1hj8933vh47vcjipcplql02bc"; }; <ins> patches = [ # Makes font a recognized media type. Committed upstream, but no release has been made. (fetchpatch { url = "https://gitlab.freedesktop.org/xdg/desktop-file-utils/commit/92af4108750ceaf4191fd54e255885c7d8a78b70.patch"; sha256 = "14sqy10p5skp6hv4hgiwnj9hpr460250x42k5z0390l6nr6gahsq"; }) ]; </ins> nativeBuildInputs = [ pkgconfig ]; buildInputs = [ glib libintl ];

Related discussion:
text: I saw the following during a rebuild: Error in file "/nix/store/vwd5hb2n6m7nwqijlz0rsmn5x6fpmlhw-system-": "font/ttf" is an invalid MIME type ("font" is an unregistered media type) Error in file "/nix/store/vwd5hb2n6m7nwqijlz0rsmn5x6fpmlhw-system-": "font/ttf" is an invalid MIME type ("font" is an unregistered media type) Error in file "/nix/store/vwd5hb2n6m7nwqijlz0rsmn5x6fpmlhw-system-": "font/opentype" is an invalid MIME type ("font" is an unregistered media type) Error in file "/nix/store/vwd5hb2n6m7nwqijlz0rsmn5x6fpmlhw-system-": "font/collection" is an invalid MIME type ("font" is an unregistered media type) Unknown system: host os: multi-user?: sandbox: version: nixpkgs:
I think we just need to update , c.f.
Ah, it seems that upstream has not released a version with the fixed commit in. The last tagged release was , they haven't tagged anything with the fix commit in. We could build from their git head, I guess, although I'm reluctant to do so. Perhaps complain ?
If the commit applies as a patch that would also be fine.
I'm still having this. had it for build and build (separately). build
Code change:
--prefix PATH ":" "${erlang}/bin:${coreutils}/bin:${curl}/bin:${bash}/bin"  --set CURL_CA_BUNDLE /etc/ssl/certs/ca-certificates.crt done <ins> substituteInPlace $out/bin/mix  --replace "/usr/bin/env elixir" "${coreutils}/bin/env $out/bin/elixir" </ins> ''; meta = with stdenv.lib; {

Related discussion:
text: I'm using Nix 1.9 on OS X 10.10.4 (Yosemite) with the package. It installs without issues, but when I try to use the tool I get this error: I'm using the unstable channel:
Hrm, I get (also Nix 1.9 and OS X 10.10.4) It seems to be an issue with the shebang in as seems to work just fine. I don't see anything obviously wrong with though... (PS hi long time no see :)
I just hit this issue too. Weirdly, just running from different shells would give different errors (I use fish normally, so it's always an early suspect around problems like this). I would get an error like got from , and an error like from . When I change my to this: Everything works, and in all shells the same way. Is this a valid fix? (By "works", I mean I get , but maybe that's a separate issue, or due to a lack of familiarity with Elixir/Erlang...)
Nice catch. Doing will generate a new app skeleton if everything is working as it should.
Turns out I just forgot to put the at the end of my fixed version, so no args were getting through :P Is what I mentioned above an acceptable fix? If so, I can submit a PR.
Code change:
, wayland-scanner , libdrm , zlib <ins> , nixosTests </ins> # Set as 'false' to build monado without service support, i.e. allow VR # applications linking against libopenxr_monado.so to use OpenXR standalone # instead of via the monado-service program. For more information see:

Related discussion:
text: The [monado] package doesn't install the udev rules generated by the [xr-hardware util] from the Monado project. Install the package and check the lack of udev rules in It was expected for the udev rules to be installted with the package. The udev rules are needed as some hmd's have some strange and specific permissions. Maybe instead of adding this to the package, monado could turn into an option like . <!-- 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]: [monado]: [xr-hardware util]:
Trying packaging the udev rules similar to how . [brscan4]:
I was working on a Monado NixOS module. Perhaps I can deal with udev rules there. See
Code change:
yanone-kaffeesatz = callPackage ../data/fonts/yanone-kaffeesatz {}; <ins> yaru-theme = callPackage ../data/themes/yaru {}; </ins> zafiro-icons = callPackage ../data/icons/zafiro-icons { }; zeal = libsForQt5.callPackage ../data/documentation/zeal { };

Related discussion:
text: Project description Metadata homepage URL: source URL: license: lgpl2/lgpl3 platforms: linux
Previously: (which I never finished, sorry, but linking in case helps anyone tackle this).
Code change:
configureFlags = common.configureFlags ++ [ "--without-x" ] # disable xdvik and xpdfopen ++ map (what: "--disable-${what}") ([ <ins> "chktex" </ins> "dvisvgm" "dvipng" # ghostscript dependency "luatex" "luajittex" "mp" "pmp" "upmp" "mf" # cairo would bring in X and more "xetex" "bibtexu" "bibtex8" "bibtex-x" "upmendex" # ICU isn't small

Related discussion:
text: I've hit the same bug as described in The root of the problem seems to be missing configuration file which should be placed somewhere and made accessible by . It is used by, for example, in Emacs. cc
cc
I'm just getting this warning: Otherwise the output seems normal to me, but I've never really used the utility.
Oh, I see, is still a problem, as it used to be in Debian.
Actually, that config file is provided by package, so if I include it in , it works fine even with . Still, it's a bit confusing that the core provides binary but doesn't fully support it.
I currently can't see a simple way how to improve that.
I am not able to use on because it does not accept the option . In the command line I get: Is it related to this issue, or should I report a new issue?
cc When explicitly adding to there are checksum errors. The following patch fixes it for me: With that, does not give the error anymore.
Oh, no, they're updating files in-place on the only mirror. Many of them won't download anymore :angry:
Better discuss the mirroring stuff at this thread:
triage: this might have been fixed in the meantime, is that so?
it's still necessary to explicitly add the package, otherwise the problem persists.
Could anyone, please, provide steps to reproduce?
The "chktex -v" works for me, I have installed with .
works in but not .
This issue still persists as of today under the tetex scheme. the addition of the chktex package is mandatory to not get this error. I was getting this error in emacs: chktex: WARNING -- Could not find global resource file. chktex: ERROR -- Illegal verbosity level. I didn't thought that this was a NixOS related issue so this thread was quite hard to stumble upon.
I can't reproduce:
I guess I forgot . If I include that then it just gives "chktex: command not found". So how do I trigger the issue?
Code change:
<ins> [Nemo Action] Active=true Name=Open in Pulsar Comment=Open in Pulsar #%U is the current selected file, this will also work on current directory Exec=pulsar -n %U Icon-Name=pulsar Selection=any Extensions=any </ins>

Related discussion:
text: Package name: pulsar Latest released version: 1.117.0 Current version on the unstable channel: 1.114.0 Current version on the stable/release channel: 1.117.0 Notify maintainers
Code change:
# Whether to compile with SUID support , enableSuid ? false , starterSuidPath ? null <ins> , substituteAll </ins> # newuidmapPath and newgidmapPath are to support --fakeroot # where those SUID-ed executables are unavailable from the FHS system PATH. # Path to SUID-ed newuidmap executable

Related discussion:
text: singularity cannot use nvidia gpu because it does not access 'nvidia-container-cli' Steps to reproduce the behavior: return result of ! This is because the path is not listed in , as also in a. It is caused by neither the option nor . I tried to handle it with override, but since it was called in , I think it is impossible to handle. Also, I created a conf file in as shown in the singularity docs, but it was not read. <!-- 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.
Thank you for reporting and sorry for the trouble. I'll look at the SingularityCE documentation again. (Those configuration options has been deprecated by Apptainer.) Also, I created a conf file in /usr/local/etc/singularity/ as shown in the singularity docs, but it was not read.  shold be what you are looking for. The overriden package can be assigned to . (If you would like to bypass all the overriding done by the module and directly specify the package to install for some special reason, you can assign it to .)
Thanks for the reply. I followed your advice and tried the override and was able to use the GPU. Here is the code This is simply adding a process to append the nvidia-docker path to the I mentioned earlier that when conf was entered in , it was not reflected, and the same is true for '/etc/singularity'. I referred to .
At least we have confirmed that in works and the path is replaced by , but the product does not seem to be recognizable.
Does setting the to make ldconfig search in help? This is modified from the configuration proposed by (). There's also (probably) related to this topic.
Adding the path of to works well. This once removed from consideration. Next we have a patched version of ldconfig. This does not append the path of to the config. The result was an error that could not be found, and it could not be started.
Oh, I already forgot about this issue. Absolutely coincidentally, but maybe efforts such as might open up a way to implement this hack more reliably.
Code change:
# Whether to compile with SUID support , enableSuid ? false , starterSuidPath ? null <ins> , substituteAll </ins> # newuidmapPath and newgidmapPath are to support --fakeroot # where those SUID-ed executables are unavailable from the FHS system PATH. # Path to SUID-ed newuidmap executable

Related discussion:
text: Meanwhile, in my config I'm still abusing You probably already have guessed, but singularity in nixpkgs is configured to read this config from the package-specific directory, rather than from the global . You could in principle override this behaviour, but there maybe isn't much value in supporting that
I tried to enable the use of external sysconfdir (), but have encountered issue trying to specify a directory under with the NixOS module ().
Have you tried to apply both at the same time?
The SingularityCE Admin Guide says If the value of nvidia-container-cli path is empty, SingularityCE will look for the binary on $PATH at runtime. It should work as long as is found in the run-time , even when is not set. As nvidia-container-cli is alredy included in the PATH-prefixing wrapper, we shouldn't have to set the .
Update: I found a bug in the prefixed PATH of the wrapper introduced in . The prefixing should be specified as (in Bash) I forgot to add , causing the trailing to be missing.
The statement in the SingularityCE Admin Guide turns out to be wrong / irrelevant. The source code clearly states that nvidia-container-cli will only be read from the configuration.
(we need to patch nvidia-container-cli, for many reasons )
Eh, actually, closed semi-automatically. Apptainer with is fixed (on NixOS), but not with . The fix doesn't concern singularity-ce either, unfortunately. Shouldn't be hard to make this work with singularity too, but I'm out of bandwidth
Hi folks, I've been trying to get apptainer to run this (which I've done previously successfully with a slight ldconfig hack -- that doesn't work anymore -- on NixOS 22.11), that will make use of the machine's Tesla V100 to do some simulation stuff. The machine is running NixOS 23.11. Using the workaround from 9th of May post further up, I was able to get past the ldconfig issue, but now I'm getting an error saying the driver and CUDA are not in sync.
Code change:
# Whether to compile with SUID support , enableSuid ? false , starterSuidPath ? null <ins> , substituteAll </ins> # newuidmapPath and newgidmapPath are to support --fakeroot # where those SUID-ed executables are unavailable from the FHS system PATH. # Path to SUID-ed newuidmap executable

Related discussion:
text: Before I start posting any details (I don't want to re-open this issue, but I'm also not sure if I'm just doing something wrong) I was wondering if the current implementation of singularity/apptainer on NixOS is expected to work, and I'm just being an idiot, or if there are known breaking issues? I've seen the other issues about singularity/apptainer here, but I'm not knowledgeable enough to make a judgement call if they are responsible for my problem or not. Thanks very much in advance!
(If I understood the message correctly) That usually means you need a reboot, and you should experience the same issue outside the container
No, the reboot didn't help either. For some reason, though, after upgrading to 24.05, everything "just works[tm]" again. So, whatever the issue was, thanks for fixing it (probably)! :)
Thanks to Nixpkgs 24.05 includes GPU-related changes/fixes to the package and the module.
Well more like thanks to ShamrockLee
Code change:
<ins> { buildGoPackage , fetchFromGitHub , lib }: # upstream is pretty stale, but it still works, so until they merge module # support we have to use gopath: see blynn/nex#57 buildGoPackage rec { pname = "nex"; version = "unstable-2021-03-30"; src = fetchFromGitHub { owner = "blynn"; repo = pname; rev = "1a3320dab988372f8910ccc838a6a7a45c8980ff"; hash = "sha256-DtJkV380T2B5j0+u7lYZfbC0ej0udF4GW2lbRmmbjAM="; }; goPackagePath = "github.com/blynn/nex"; subPackages = [ "." ]; meta = with lib; { description = "Lexer for Go"; homepage = "https://github.com/blynn/nex"; license = licenses.gpl3Only; maintainers = with maintainers; [ urandom ]; }; } </ins>

Related discussion:
text: Project description mgmt: next generation config management! Metadata homepage URL: source URL: license: GNU3 platforms: unix, linux, darwin
After fixing up the mgmt make scripts , from !/bin/bash to !/usr/bin/env bash trying to build from 'nix-shell -p go git' git clone cd mgmt make path make deps make Building: mgmt, os/arch: linux-amd64, version: 0.0.21-90-g5c6a66e-dirty. go build runtime/cgo: copying /run/user/1000/go-build892927552/b057/pkg.a: open /nix/store/y2nrzzz2yz7k36xvwr7bbfx76cb8jg16-go-1.14.8/share/go/pkg/linuxamd64/runtime/cgo.a: read-only file system make: * [Makefile:175: build/mgmt-linux-amd64] Error 1 go env GO111MODULE="" GOARCH="amd64" GOBIN="/home/demo/gopath/bin/" GOCACHE="" GOENV="" GOEXE="" GOFLAGS="" GOHOSTARCH="amd64" GOHOSTOS="linux" GOINSECURE="" GONOPROXY="" GONOSUMDB="" GOOS="linux" GOPATH="/home/demo/gopath/" GOPRIVATE="" GOPROXY=",direct" GOROOT="/nix/store/y2nrzzz2yz7k36xvwr7bbfx76cb8jg16-go-1.14.8/share/go" GOSUMDB="" GOTMPDIR="" GOTOOLDIR="/nix/store/y2nrzzz2yz7k36xvwr7bbfx76cb8jg16-go-1.14.
Code change:
<ins> { buildGoPackage , fetchFromGitHub , lib }: # upstream is pretty stale, but it still works, so until they merge module # support we have to use gopath: see blynn/nex#57 buildGoPackage rec { pname = "nex"; version = "unstable-2021-03-30"; src = fetchFromGitHub { owner = "blynn"; repo = pname; rev = "1a3320dab988372f8910ccc838a6a7a45c8980ff"; hash = "sha256-DtJkV380T2B5j0+u7lYZfbC0ej0udF4GW2lbRmmbjAM="; }; goPackagePath = "github.com/blynn/nex"; subPackages = [ "." ]; meta = with lib; { description = "Lexer for Go"; homepage = "https://github.com/blynn/nex"; license = licenses.gpl3Only; maintainers = with maintainers; [ urandom ]; }; } </ins>

Related discussion:
text: 8/share/go/pkg/tool/linuxamd64" GCCGO="gccgo" AR="ar" CC="gcc" CXX="g++" CGOENABLED="1" GOMOD="" CGOCFLAGS="-g -O2" CGOCPPFLAGS="" CGOCXXFLAGS="-g -O2" CGOFFLAGS="-g -O2" CGOLDFLAGS="-g -O2" PKG_CONFIG="pkg-config" GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/run/user/1000/go-build275716735=/tmp/go-build -gno-record-gcc-switches"
mgmt now compiles under a I'm going to need a little bit of help to turn this into a nix package, as i'm not too sure how to handle it , as there are buildgopackage, buildgomodule , vgo2nix etc etc . Any pointers welcomed. to avoid I had to remove the -i from the go build this seems to be related to this NixOS/nixpkgs golang/go to run
I marked this as stale due to inactivity. &rarr;
Code change:
# require networking "tests/test_init.py" "tests/test_matching.py" <ins> "tests/providers/lyrics" "tests/types" "tests/utils/test_github.py" </ins> "tests/utils/test_m3u.py" "tests/utils/test_metadata.py" "tests/utils/test_search.py"

Related discussion:
text: Steps to reproduce the behavior: spotdl I just tried to install it, doing it from or gives the same result. Let me know if I can provide more useful information.
Code change:
ecdsa = callPackage ../development/python-modules/ecdsa { }; <ins> echo = callPackage ../development/python-modules/echo { }; </ins> ecoaliface = callPackage ../development/python-modules/ecoaliface { }; ecos = callPackage ../development/python-modules/ecos { };

Related discussion:
text: Project description Glue is a python project to link visualizations of scientific datasets across many files. Click on the image for a quick demo: ! Metadata homepage URL: source URL: license: BSD Linux, BSD