jiebi/CodeConvo huggingface dataset:
Code change:
# Add gio to PATH so that moving files to the trash works when not using a desktop environment --prefix PATH : ${glib.bin}/bin --add-flags "''${NIXOS_OZONE_WL:+''${WAYLAND_DISPLAY:+--enable-features=UseOzonePlatform --ozone-platform=wayland}}" <ins> --add-flags ${lib.escapeShellArg commandLineArgs} </ins> ) '';

Related discussion:
text: For Chromium, there's a convenient way to define custom flags through . However, there doesn't seem to be a similar option for . I tried setting to "--touch-events", but touchscreen scrolling is not enabled when starting VSCode from desktop launcher, while running in console works as expected. Steps to reproduce the behavior: to "--touch-events" VSCode from desktop launcher on the editor area through touchscreen The editor should scroll as I drag. system: host os: multi-user?: sandbox: version: channels(yes): channels(root): nixpkgs:
Code change:
meson ninja pkg-config <del> python3 </del> wrapGAppsHook4 ] ++ (with rustPlatform; [ cargoSetupHook

Related discussion:
text: Package name: fragments Latest released version: <!-- Search your package here: --- Current version on the unstable channel: 2.0.2 Current version on the stable/release channel: 2.0.2 <!-- 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.
Code change:
SystemCallFilter = [ "@system-service" <del> "~@resources" </del> "~@privileged" ]; SystemCallArchitectures = "native";

Related discussion:
text: Gotenberg crashes immediately on startup Enter the following into your nix config: It not crashing but starting up normally ! Gotenberg was to be used in conjunction with paperless-ngx. is the entire file Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Are there any more logs from the Gotenberg service? Or is the coredump all that's available?
Sadly that is all. The service log literally doesn't say anything. There you only see that the service started and immediately exited. This log i got by typing
Sorry for the slow response, but I looked at this and figured out the issue. Could you test and see if it fixes your issue?
Code change:
<del> { lib, buildGoModule, fetchFromGitHub, installShellFiles }: buildGoModule rec { pname = "pritunl-client"; </del> <ins> { lib , stdenv , fetchFromGitHub , runtimeShell , runCommand , makeWrapper , installShellFiles , buildGoModule , coreutils , which , gnugrep , gnused , openresolv , systemd , iproute2 , openvpn , electron }: let </ins> version = "1.3.3584.5"; src = fetchFromGitHub { owner = "pritunl"; repo = "pritunl-client-electron";

Related discussion:
text: Project description <!-- Describe the project a little: --This is a electron-based app client for Pritunl server Metadata homepage URL: source URL: license: Non-Commercial platforms: linux
Pending review in
Code change:
#!/usr/bin/env nix-shell <del> #! nix-shell -I nixpkgs=../../../.. -i python3 -p bundix bundler nix-update nix nix-universal-prefetch python3 python3Packages.requests python3Packages.click python3Packages.click-log python3Packages.packaging prefetch-yarn-deps git </del> <ins> #! nix-shell -I nixpkgs=../../../.. -i python3 -p bundix bundler nix-update nix python3 python3Packages.requests python3Packages.click python3Packages.click-log python3Packages.packaging prefetch-yarn-deps git </ins> import click import click_log

Related discussion:
text: The gitlab  script depends on , which was removed by in . Steps to reproduce the behavior: The update scripts succeeds. (myself) Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Also looks like nix-update could be used here.
Ok. looks like switching to nix-update would require some other major refactoring because the writes out some json file out. But here is a simpler approach:
Code change:
julia_11 = throw "julia_11 has been deprecated in favor of the latest stable version"; # Added 2020-09-15 julia_13 = throw "julia_13 has been deprecated in favor of the latest stable version"; # Added 2021-03-13 julia_10-bin = throw "julia_10-bin has been deprecated in favor of the latest LTS version"; # Added 2021-12-02 <ins> julia_17-bin = throw "julia_17-bin has been deprecated in favor of the latest stable version"; # Added 2022-09-04 </ins> json_glib = throw "'json_glib' has been renamed to/replaced by 'json-glib'"; # Converted to throw 2022-02-22 jvmci8 = throw "graalvm8 and its tools were deprecated in favor of graalvm8-ce"; # Added 2021-10-15

Related discussion:
text: <!-- Note that these are hard requirements --<!-- You can use the "Go to file" functionality on GitHub to find the package Then you can go to the history for this package Find the latest "packagename: oldversion -newversion" commit The "newversion" is the current version of the package --- <!-- 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! --- name: <!-- The current version can be found easily with the same process as above for checking the master branch If an open PR is present for the package, take this version as the current one and link to the PR --current version: 1.7.3 desired version: <!-- Search your package here: If no maintainer is listed for your package, tag the person that last updated the package --maintainers: Please tag this issue in your PR.
I started preparing the update in . Cc:
Code change:
# Allow multiple colon-separated authorized keys files to be # specified in the file= option. ./multiple-key-files.patch <ins> ./edcsa-crash-fix.patch </ins> ]; configureFlags = [

Related discussion:
text: Describe the bug After upgrading to NixOS 20.03, sudo often (but not always) segfaults: From the logs: Disabling appears to have made this problem to away, so the problem may be in . Metadata NixOS 20.03..
Maybe the patch to use a not insecure openssl is the source of the issue for you
same issue here - the sourceforge repo is way old, there's a github mirror but not maintained either, and there's a fork of the mirror which includes fixes for openssl 1.1.1:
I marked this as stale due to inactivity. &rarr;
Hmm, kinda forgot about this
I missed the fact that the "supported" branch didn't actually include the patch to fix this.
Code change:
sourceRoot = if stdenv.isDarwin then "" else "."; in callPackage ./generic.nix rec { <del> inherit sourceRoot; </del> <ins> inherit sourceRoot commandLineArgs; </ins> # Please backport all compatible updates to the stable release. # This is important for the extension ecosystem.

Related discussion:
text: For Chromium, there's a convenient way to define custom flags through . However, there doesn't seem to be a similar option for . I tried setting to "--touch-events", but touchscreen scrolling is not enabled when starting VSCode from desktop launcher, while running in console works as expected. Steps to reproduce the behavior: to "--touch-events" VSCode from desktop launcher on the editor area through touchscreen The editor should scroll as I drag. system: host os: multi-user?: sandbox: version: channels(yes): channels(root): nixpkgs:
Code change:
clojure-vim/vim-jack-in cloudhead/neovim-fuzzy CoatiSoftware/vim-sourcetrail <ins> coc-extensions/coc-svelte </ins> cocopon/iceberg.vim codota/tabnine-vim cohama/lexima.vim

Related discussion:
text: Project description Various vim plugins iamcco/coc-tailwindcss coc-extensions/coc-svelte evanleck/vim-svelte
Code change:
if [[ ! -e .git || ! -e VERSION ]]; then echo "${version}" > VERSION fi # Patch shebangs for script run during build patchShebangs --build "$configureScript" makeit e2e scripts mlocal/scripts # Patching the hard-coded defaultPath by prefixing the packages in defaultPathInputs substituteInPlace cmd/internal/cli/actions.go  --replace "defaultPath = "${defaultPathOriginal}"" "defaultPath = "''${defaultPathInputs// //bin:}''${defaultPathInputs:+/bin:}${defaultPathOriginal}"" <ins> substituteInPlace internal/pkg/util/gpu/nvidia.go  --replace  'return fmt.Errorf("/usr/bin not writable in the container")'  "" </ins> ''; postConfigure = ''

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:
if [[ ! -e .git || ! -e VERSION ]]; then echo "${version}" > VERSION fi # Patch shebangs for script run during build patchShebangs --build "$configureScript" makeit e2e scripts mlocal/scripts # Patching the hard-coded defaultPath by prefixing the packages in defaultPathInputs substituteInPlace cmd/internal/cli/actions.go  --replace "defaultPath = "${defaultPathOriginal}"" "defaultPath = "''${defaultPathInputs// //bin:}''${defaultPathInputs:+/bin:}${defaultPathOriginal}"" <ins> substituteInPlace internal/pkg/util/gpu/nvidia.go  --replace  'return fmt.Errorf("/usr/bin not writable in the container")'  "" </ins> ''; postConfigure = ''

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:
if [[ ! -e .git || ! -e VERSION ]]; then echo "${version}" > VERSION fi # Patch shebangs for script run during build patchShebangs --build "$configureScript" makeit e2e scripts mlocal/scripts # Patching the hard-coded defaultPath by prefixing the packages in defaultPathInputs substituteInPlace cmd/internal/cli/actions.go  --replace "defaultPath = "${defaultPathOriginal}"" "defaultPath = "''${defaultPathInputs// //bin:}''${defaultPathInputs:+/bin:}${defaultPathOriginal}"" <ins> substituteInPlace internal/pkg/util/gpu/nvidia.go  --replace  'return fmt.Errorf("/usr/bin not writable in the container")'  "" </ins> ''; postConfigure = ''

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:
</listitem> <listitem> <para> <ins> The <literal>miller</literal> package has been upgraded from 5.10.3 to <link xlink:href="https://github.com/johnkerl/miller/releases/tag/v6.2.0">6.2.0</link>. See <link xlink:href="https://miller.readthedocs.io/en/latest/new-in-miller-6">What’s new in Miller 6</link>. </para> </listitem> <listitem> <para> </ins> MultiMC has been replaced with the fork PolyMC due to upstream developers being hostile to 3rd party package maintainers. PolyMC removes all MultiMC branding and is aimed at providing

Related discussion:
text: <!-- Note that these are hard requirements --<!-- You can use the "Go to file" functionality on GitHub to find the package Then you can go to the history for this package Find the latest "packagename: oldversion -newversion" commit The "newversion" is the current version of the package --- <!-- 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! --- name: miller <!-- The current version can be found easily with the same process as above for checking the master branch If an open PR is present for the package, take this version as the current one and link to the PR --current version: 5.10.3 desired version: 6.1.0 miller is now written in Go; there's still a configure script and a makefile, but I don't know if it's now more complicated to package because of fetching dependencies in a reproducible way or whatever. <!-- Search your package here: If no maintainer is listed for your package, tag the person that last updated the package --maintainers: Please tag this issue in your PR.
Code change:
librarypath="${lib.makeLibraryPath deps}:$libdir" wrapProgram $out/share/spotify/spotify  <ins> ''${gappsWrapperArgs[@]}  </ins> --prefix LD_LIBRARY_PATH : "$librarypath"  --prefix PATH : "${gnome.zenity}/bin"

Related discussion:
text: Describe the bug When adding a local directory to spotify client, it always fails due to missing gtk schema(s) To Reproduce Steps to reproduce the behavior: on button Expected behavior Open a file chooser to select which directory to be . Screenshots If applicable, add screenshots to help explain your problem. Additional context Running spotify with flag from console gives me 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 think that this issue is not NixOS specific:
Still seems to be an issue. I'm using flakes so above is not applicable I'm on.
Tail end of strace.
Yep I can confirm that. However, as IvanMalison commented above, the bug might be not by nixos but by upstream.
I'm getting the same issue as OP when clicking the button I also tried this on EndeavourOS with the same version of spotify and there it works flawlessly. So I think this is actually a nixpkgs problem and not something upstream related. Maybe the issue can be reopened?
Code change:
} </programlisting> </para> <para> <del> Here's a recipe on how to override a particular plugin through an overlay: </del> <ins> Here's a recipe on how to override a particular plugin through an overlay: </ins> <programlisting> self: super: { postgresql_11 = super.postgresql_11.override { this = self.postgresql_11; } // {

Related discussion:
text: to newer version to different directory as under postgresql user Output I get:
The NixOS service module for PostgreSQL, for some unfathomable reason, initializes new databases using a non-standard superuser role name ( instead of ). This makes it a nightmare to get to work right, so forget that. Instead: back to your old version of postgresql root, dump your entire database to a file somewhere: to the new version of postgresql root, read in the database dump: (you'll likely see an error go by about the role already existing, you can ignore this) For good measure I went and tested this upgrading a 9.2 database to 9.4 under NixOS, worked fine, the applications using it continued on as normal after the import. That said, the real issue here is: why are we initializing databases using a non-standard install / superuser role name?
cc
See regarding the superuser role name.
Shouldn't we switch the default user to "postgres" on new databases and keep the "root" account around for existing-ones ? See
I strongly agree we should switch the default superuser to . Currently, it seems impossible to use to upgrade postgresql databases due to NixOS using the superuser: simply refuses to run as root.
The approach given by above doesn't work for me:
I can submit the change as a PR but don't use postgresql and it needs testing. Feel free to steal it and do the upgrade process with it.
pgdumpall tends to e pretty useless if you database isn't tiny_ :(
that would be a good start :)
there you go :)
FYI: I've just tested migrating 9.2 to 9.6 using and it works flawlessly.
Ok, I think I found out why wasn't working for me, like I mentioned in It seems to be due to this line in the Hydra module: If I change the mapping to then the command works fine. But I'm not exactly sure what are the implications of doing this, or why was mapped to in the first place...
In case someone runs into the same issue as me, I am documenting the procedure I used to upgrade a PostgreSQL database that was being used (only) for Hydra.
Code change:
} </programlisting> </para> <para> <del> Here's a recipe on how to override a particular plugin through an overlay: </del> <ins> Here's a recipe on how to override a particular plugin through an overlay: </ins> <programlisting> self: super: { postgresql_11 = super.postgresql_11.override { this = self.postgresql_11; } // {

Related discussion:
text: I tried to follow procedure above, but as I mentioned before, to use as suggested I needed to change the PostgreSQL user mapping in the Hydra module as specified in my comment just above this one, otherwise I would get a message. However, to read the database dump back into the new PostgreSQL installation I had to change the user mapping as follows: ... and then, after activating the configuration, I needed to run the command in the following way (as root): After doing this, the upgrade from PostgreSQL 9.4 to 9.6 seems to have completed successfully.
Related
If anyone else stumbles on this, pgupgrade seems to work now. I realized after upgrade that my db got reinitialized, so steps for me were much more brutish than that post, but in a nutshell: with new postgresql running, clear whatever got reinitialized (pgupgrade won't run if there are data around, but won't tell you what to remove... lists databases, don't know how to list users, I guessed) drop database whatever; drop user whatever; stop postgresql.service figure path for old binaries, e.g. and copy it somewhere. run the actual pgupgrade as user: restart the postgresql service if all went well after some testing pgupgrade suggests removing the old db with (disclaimer: Don't blame me if that eats your data)