jiebi/CodeConvo huggingface dataset:
Code change:
]; buildInputs = [ <del> gdk-pixbuf </del> glib gnome.adwaita-icon-theme gtk3

Related discussion:
text: Describe the bug I'm unsure what the error is, but it seems to relate to ulauncher being unable to find the project path, whatever that may be. To Reproduce Steps to reproduce the behavior: Expected behavior For Ulauncher to start normally Additional context This is the error message I get: Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Metadata Please run and paste the result. system: host os: multi-user?: sandbox: version: channels(root): channels(miyuki): nixpkgs: Maintainer information:
See the PR linked above. The issue is that the ulauncher package must be installed via , , , or something similar. Using does not work (for reasons explained in the patch). The PR both updates ulauncher and adds a note to explain what's going on to Nix users trying out the package. I think it would be a good idea to create a NixOS module for Ulauncher. I might be able to do this after I finish exams in a couple weeks.
Alright guys, the real solution here is to just use rofi. With a little work you can make it look pretty good and with a little extra work one could easily make it look similar to ulauncher. Here is my config I tried to fix this issue up but it seemed to work for maintainers thus it was the end of that story
Hello ulauncher package maintainer here. This definitely shouldn't be the end of the story. I do want to get these issues fixed. The problem is that ulauncher wants to store paths to its assets in a config file within . Typically we'd just let it use paths for everything, but that would cause ulauncher to break if we update the derivation then garbage-collect the old paths in . I also use Rofi right now, and it works. But I really want the plugin ecosystem of Ulauncher, so I'm motivated to fix this situation. Perhaps we could modify the current package to allow decoratively specifying the file contents (like ), which would allow the package to be used without messing with system state? Maybe we could even create something like and a NixOS module?
Perhaps this is a good fit for a home-manager module?
Code change:
]; buildInputs = [ <del> gdk-pixbuf </del> glib gnome.adwaita-icon-theme gtk3

Related discussion:
text: In any case, this issue can probably be closed once is merged. Maybe a new issue should be opened to track the addition of an unlauncher module?
I marked this as stale due to inactivity. &rarr;
bad bot
I installed (rev ) through . Unfortunately, I get this error message on launch anyway.
same issue here
Code change:
<ins> { lib, buildNpmPackage, fetchFromGitHub }: buildNpmPackage rec { pname = "whistle"; version = "2.9.58"; src = fetchFromGitHub { owner = "avwo"; repo = "whistle"; rev = "v${version}"; hash = "sha256-/dt4xwUZrvymCpc3xRyWM2Wsh7zk7ndepgOWJwJ2Das="; }; npmDepsHash = "sha256-9GBhC2PQyaqi64ncIuMZSf9CLB8l+cywT7QTzW9WiTs="; dontNpmBuild = true; meta = with lib; { description = "HTTP, HTTP2, HTTPS, Websocket debugging proxy"; homepage = "https://github.com/avwo/whistle"; changelog = "https://github.com/avwo/whistle/blob/${src.rev}/CHANGELOG.md"; license = licenses.mit; maintainers = [ maintainers.marsam ]; mainProgram = "whistle"; }; } </ins>

Related discussion:
text: Project description HTTP, HTTP2, HTTPS, Websocket debugging proxy Metadata homepage URL: source URL: license: mit platforms: unix, linux, darwin
Code change:
{ config, stdenv, lib, fetchurl, pkgconfig, zlib, expat, openssl, autoconf , libjpeg, libpng, libtiff, freetype, fontconfig, libpaper, jbig2dec <del> , libiconv, ijs, lcms2 </del> <ins> , libiconv, ijs, lcms2, fetchpatch </ins> , cupsSupport ? config.ghostscript.cups or (!stdenv.isDarwin), cups ? null , x11Support ? cupsSupport, xlibsWrapper ? null # with CUPS, X11 only adds very little }:

Related discussion:
text: , (nixos-unstable, nixos-19.03, nixos-18.09) Scanned versions: nixos-unstable: ; nixos-19.03: ; nixos-18.09: . May contain false positives.
Code change:
{ config, stdenv, lib, fetchurl, pkgconfig, zlib, expat, openssl, autoconf , libjpeg, libpng, libtiff, freetype, fontconfig, libpaper, jbig2dec <del> , libiconv, ijs, lcms2 </del> <ins> , libiconv, ijs, lcms2, fetchpatch </ins> , cupsSupport ? config.ghostscript.cups or (!stdenv.isDarwin), cups ? null , x11Support ? cupsSupport, xlibsWrapper ? null # with CUPS, X11 only adds very little }:

Related discussion:
text: Can't simply apply the upstream commits, unfortunately (AFAICT). This looks pretty serious!
Thank you!! :sparkle:
Code change:
# GitKraken expects the CA bundle to be located in the bundled git directory. Since we replace it with # the one from nixpkgs, which doesn't provide a CA bundle, we need to explicitly set its location at runtime <del> makeWrapper $out/share/${pname}/gitkraken $out/bin/gitkraken --set GIT_SSL_CAINFO "${cacert}/etc/ssl/certs/ca-bundle.crt" </del> <ins> makeWrapper $out/share/${pname}/gitkraken $out/bin/gitkraken  --set GIT_SSL_CAINFO "${cacert}/etc/ssl/certs/ca-bundle.crt"  "''${gappsWrapperArgs[@]}" </ins> ''; };

Related discussion:
text: The application is crashing when trying to open a file Steps to reproduce the behavior: to open a repository application crashes Supposed to open a file exploer Using KDE Plasma 5 under wayland <!-- 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.
I’m running Gnome 45 under Wayland and the « Open a Repository » feature is working fine. I’ll give a look with KDE Plasma 5 when I have some time.
same here
As in it it works or it does not?
not work kde + wayland
Code change:
sub pathToUnitName { my ($path) = @_; <del> open my $cmd, "-|", "@systemd@/bin/systemd-escape", "--suffix=mount", "-p", $path </del> <ins> # Use current version of systemctl binary before daemon is reexeced. open my $cmd, "-|", "/run/current-system/sw/bin/systemd-escape", "--suffix=mount", "-p", $path </ins> or die "Unable to escape $path!n"; my $escaped = join "", <$cmd>; chomp $escaped;

Related discussion:
text: When executing switch-to-configuration in a pure environment it fails: I am calling switch-to-configuration via systemd-run to active a new profile using the Hail update tool. The actual executed script is as follows: Actual output: <preactivating the configuration... perl: warning: Setting locale failed. perl: warning: Please check that your locale settings: LANGUAGE = (unset), LCALL = (unset), LANG = "enUS.UTF-8" are supported and installed on your system. perl: warning: Falling back to the standard locale ("C"). setting up /etc... perl: warning: Setting locale failed. perl: warning: Please check that your locale settings: LANGUAGE = (unset), LCALL = (unset), LANG = "enUS.UTF-8" are supported and installed on your system. perl: warning: Falling back to the standard locale ("C"). setting up tmpfiles Too few arguments. sh: systemctl: command not found </preThe script works if I pass on the PATH and LOCALE_ARCHIVE environment variables: System: (NixOS: 17.09pre-git (Hummingbird)) Nix version: nix-env (Nix) 1.11.13 Nixpkgs version: nixos-unstable (Commit ) Sandboxing enabled: no (Related Hail issue: )
Code change:
}); beta = selectHighestVersion latest (generic { <del> version = "550.40.07"; sha256_64bit = "sha256-KYk2xye37v7ZW7h+uNJM/u8fNf7KyGTZjiaU03dJpK0="; sha256_aarch64 = "sha256-AV7KgRXYaQGBFl7zuRcfnTGr8rS5n13nGUIe3mJTXb4="; openSha256 = "sha256-mRUTEWVsbjq+psVe+kAT6MjyZuLkG2yRDxCMvDJRL1I="; settingsSha256 = "sha256-c30AQa4g4a1EHmaEu1yc05oqY01y+IusbBuq+P6rMCs="; persistencedSha256 = "sha256-11tLSY8uUIl4X/roNnxf5yS2PQvHvoNjnd2CB67e870="; patches = [ rcu_patch ]; </del> <ins> version = "555.42.02"; sha256_64bit = "sha256-k7cI3ZDlKp4mT46jMkLaIrc2YUx1lh1wj/J4SVSHWyk="; sha256_aarch64 = "sha256-ekx0s0LRxxTBoqOzpcBhEKIj/JnuRCSSHjtwng9qAc0="; openSha256 = "sha256-3/eI1VsBzuZ3Y6RZmt3Q5HrzI2saPTqUNs6zPh5zy6w="; settingsSha256 = "sha256-rtDxQjClJ+gyrCLvdZlT56YyHQ4sbaL+d5tL4L4VfkA="; persistencedSha256 = "sha256-3ae31/egyMKpqtGEqgtikWcwMwfcqMv2K4MVFa70Bqs="; </ins> }); # Vulkan developer beta driver

Related discussion:
text: Package name: Latest released version: 555.42.02 <!-- Search your package here: --- Current version on the unstable channel: 550.78 Current version on the stable/release channel: 545.29.02 <!-- 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]:
Code change:
<del> let inherit (import <nixpkgs> { }) snapTools hello; in snapTools.makeSnap { meta = { name = "hello"; summary = hello.meta.description; description = hello.meta.longDescription; architectures = [ "amd64" ]; confinement = "strict"; apps.hello.command = "${hello}/bin/hello"; }; } </del>

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.
Code change:
<del> let inherit (import <nixpkgs> { }) snapTools hello; in snapTools.makeSnap { meta = { name = "hello"; summary = hello.meta.description; description = hello.meta.longDescription; architectures = [ "amd64" ]; confinement = "strict"; apps.hello.command = "${hello}/bin/hello"; }; } </del>

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.
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
I opened a PR here: Thanks in advance for reviewing :-)
Code change:
"wallpapers" "applications" "desktop-directories" "mime" "appdata" "dbus-1"  ) <del> ecmHostPathSeen=( ) </del> <ins> # ecmHostPathsSeen is an associative array of the paths that have already been # seen by ecmHostPathHook. declare -gA ecmHostPathsSeen </ins> <del> ecmUnseenHostPath() { for pkg in "${ecmHostPathSeen[@]}" do if [ "${pkg:?}" == "$1" ] then return 1 fi done ecmHostPathSeen+=("$1") return 0 </del> <ins> ecmHostPathIsNotSeen() { if [[ -n "${ecmHostPathsSeen["$1"]:-}" ]]; then # The path has been seen before. return 1 else # The path has not been seen before. # Now it is seen, so record it. ecmHostPathsSeen["$1"]=1 return 0 fi </ins> } ecmHostPathHook() { <del> ecmUnseenHostPath "$1" || return 0 </del> <ins> ecmHostPathIsNotSeen "$1" || return 0 </ins> local xdgConfigDir="$1/etc/xdg" if [ -d "$xdgConfigDir" ]

Related discussion:
text: Describe the bug The file has this function: Since this is called for every dependency, we get quadratic complexity. This may cause a non-trivial slowdown - building digikam I noticed it takes a few seconds just to get to , but there might be other causes. It also causes huge amounts of debug output when you add a to (about 600 MB for digikam). We should use an associative array for this like stdenv does (see ). Notify maintainers
We also need to do this in the setup hook for paths seen by .
I marked this as stale due to inactivity. &rarr;
Not stale.
Fixed in .
Code change:
{ stdenv <ins> , python3 </ins> , fetchFromGitHub , makeWrapper , gdb <del> , future , isort , psutil , pycparser , pyelftools , python-ptrace , ROPGadget , six , unicorn , pygments , }: </del> <ins> }: </ins> <del> stdenv.mkDerivation rec { pname = "pwndbg"; version = "2019.01.25"; src = fetchFromGitHub { owner = "pwndbg"; repo = "pwndbg"; rev = version; sha256 = "0k7n6pcrj62ccag801yzf04a9mj9znghpkbnqwrzz0qn3rs42vgs"; }; nativeBuildInputs = [ makeWrapper ]; propagatedBuildInputs = [ </del> <ins> let pythonPath = with python3.pkgs; makePythonPath [ </ins> future isort psutil

Related discussion:
text: Describe the bug fails to run because setuptools is no longer propagated implictly. If were purely a python application built with then we would just need to add to propagatedBuildInputs and be done. However, is not simply a Python application, but a wrapper around , and isn't built using. The derivation patches the script as follows: This does result in the site-packages directories from all python packages ending up in , including setuptools (e.g. ). I'm not that familiar with Python packaging but from experimenting I found that the full path to the Python egg needs to be included (e.g. ) in order for this method to work. I made an attempt at resolving the issue but being new to Python packaging in Nix, neither are likely to be ideal: We could use buildPythonPackage in place of mkDerivation, using and use Or continue to use mkDerivation and manually set for patchPythonScript: I'm happy to submit a PR but I'm not sure what the recommended solution is here. To Reproduce Steps to reproduce the behavior: Expected behavior should launch with the extension loaded: Metadata system: host os: multi-user?: sandbox: version: nixpkgs: Maintainer information:
It seems is normally used by adding a to , or calling with (what the wrapper registered in does). This script then just does some addition calculations to register itself (we probably don't that at all) and some python 2 specific fixups, and then calls , which starts executing some code on import. I'd suggest to package it as a regular python application first (via ), so you can successfully import it inside a . The python tooling should automatically take care of patching the python shebang properly if you make script executable.
proposed fix
Code change:
} } else { skipBuild("Unknown platform. Qt WebEngine only supports Linux, Windows, and macOS.") <ins> @@ -111,7 +107,7 @@ defineTest(isMinOSXSDKVersion) { requested_minor = $$2 requested_patch = $$3 isEmpty(requested_patch): requested_patch = 0 -    WEBENGINE_OSX_SDK_PRODUCT_VERSION = $$system("/usr/bin/xcodebuild -sdk $$QMAKE_MAC_SDK -version ProductVersion 2>/dev/null") +    WEBENGINE_OSX_SDK_PRODUCT_VERSION = $$system("xcrun --show-sdk-version") export(WEBENGINE_OSX_SDK_PRODUCT_VERSION) isEmpty(WEBENGINE_OSX_SDK_PRODUCT_VERSION) { skipBuild("Could not resolve SDK product version for '$$QMAKE_MAC_SDK'.") </ins> diff --git a/src/core/config/mac_osx.pri b/src/core/config/mac_osx.pri <ins> index 4426901c..3aa6057e 100644 </ins> --- a/src/core/config/mac_osx.pri +++ b/src/core/config/mac_osx.pri <del> @@ -5,8 +5,6 @@ load(functions) </del> <ins> @@ -5,16 +5,16 @@ load(functions) </ins> # otherwise query for it. QMAKE_MAC_SDK_VERSION = $$eval(QMAKE_MAC_SDK.$${QMAKE_MAC_SDK}.SDKVersion) isEmpty(QMAKE_MAC_SDK_VERSION) { -     QMAKE_MAC_SDK_VERSION = $$system("/usr/bin/xcodebuild -sdk $${QMAKE_MAC_SDK} -version SDKVersion 2>/dev/null") <del> -     isEmpty(QMAKE_MAC_SDK_VERSION): error("Could not resolve SDK version for '$${QMAKE_MAC_SDK}'") </del> <ins> +     QMAKE_MAC_SDK_VERSION = $$system("xcrun --show-sdk-version") isEmpty(QMAKE_MAC_SDK_VERSION): error("Could not resolve SDK version for '$${QMAKE_MAC_SDK}'") </ins> } QMAKE_CLANG_DIR = "/usr" <ins> -QMAKE_CLANG_PATH = $$eval(QMAKE_MAC_SDK.macx-clang.$${QMAKE_MAC_SDK}.QMAKE_CXX) -!isEmpty(QMAKE_CLANG_PATH) { -    clang_dir = $$clean_path("$$dirname(QMAKE_CLANG_PATH)/../") -    exists($$clang_dir): QMAKE_CLANG_DIR = $$clang_dir -} +# QMAKE_CLANG_PATH = $$eval(QMAKE_MAC_SDK.macx-clang.$${QMAKE_MAC_SDK}.QMAKE_CXX) +# !isEmpty(QMAKE_CLANG_PATH) { +#     clang_dir = $$clean_path("$$dirname(QMAKE_CLANG_PATH)/../") +#     exists($$clang_dir): QMAKE_CLANG_DIR = $$clang_dir +# } QMAKE_CLANG_PATH = "$${QMAKE_CLANG_DIR}/bin/clang++" message("Using clang++ from $${QMAKE_CLANG_PATH}") </ins>

Related discussion:
text: The component of the derivation fails to compile on MacOS. But in two ways, and I can't tell what causes one or the other to trigger. On command: On command: the channel compilation failure Compiles.
It has been broken for a while now for different reasons. Maintaining it for darwin is a lot of work and nobody has stepped up to do that. Also, this is a duplicate of
By the way, what is your use case for ?
We're building a desktop version of mobile application and we need for our in-app browser with Ethereum support.
Code change:
singularity = finalAttrs.finalPackage; }; }; <ins> gpuChecks = lib.optionalAttrs (projectName == "apptainer") { # Should be in tests, but Ofborg would skip image-hello-cowsay because # saxpy is unfree. image-saxpy = callPackage ({ singularity-tools, cudaPackages }: singularity-tools.buildImage { name = "saxpy"; contents = [ cudaPackages.saxpy ]; memSize = 2048; diskSize = 2048; singularity = finalAttrs.finalPackage; }) { }; saxpy = callPackage ({ runCommand, writeShellScriptBin }: let unwrapped = writeShellScriptBin "apptainer-cuda-saxpy" '' ${lib.getExe finalAttrs.finalPackage} exec --nv $@ ${finalAttrs.passthru.tests.image-saxpy} saxpy ''; in runCommand "run-apptainer-cuda-saxpy" { requiredSystemFeatures = [ "cuda" ]; nativeBuildInputs = [ unwrapped ]; passthru = { inherit unwrapped; }; } '' apptainer-cuda-saxpy '') { }; }; </ins> }; })

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:
singularity = finalAttrs.finalPackage; }; }; <ins> gpuChecks = lib.optionalAttrs (projectName == "apptainer") { # Should be in tests, but Ofborg would skip image-hello-cowsay because # saxpy is unfree. image-saxpy = callPackage ({ singularity-tools, cudaPackages }: singularity-tools.buildImage { name = "saxpy"; contents = [ cudaPackages.saxpy ]; memSize = 2048; diskSize = 2048; singularity = finalAttrs.finalPackage; }) { }; saxpy = callPackage ({ runCommand, writeShellScriptBin }: let unwrapped = writeShellScriptBin "apptainer-cuda-saxpy" '' ${lib.getExe finalAttrs.finalPackage} exec --nv $@ ${finalAttrs.passthru.tests.image-saxpy} saxpy ''; in runCommand "run-apptainer-cuda-saxpy" { requiredSystemFeatures = [ "cuda" ]; nativeBuildInputs = [ unwrapped ]; passthru = { inherit unwrapped; }; } '' apptainer-cuda-saxpy '') { }; }; </ins> }; })

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.