jiebi/CodeConvo huggingface dataset:
Code change:
services.postgresql = { <link linkend="opt-services.postgresql.enable">enable</link> = true; <del> <link linkend="opt-services.postgresql.initialScript">initialScript</link> = pkgs.writeText "psql-init" '' CREATE ROLE nextcloud WITH LOGIN; CREATE DATABASE nextcloud WITH OWNER nextcloud; ''; </del> <ins> <link linkend="opt-services.postgresql.ensureDatabases">ensureDatabases</link> = [ "nextcloud" ]; <link linkend="opt-services.postgresql.ensureUsers">ensureUsers</link> = [ { name = "nextcloud"; ensurePermissions."DATABASE nextcloud" = "ALL PRIVILEGES"; } ]; </ins> }; # ensure that postgres is running *before* running the setup

Related discussion:
text: What about adding the following (subtile) log statement, to point users to the docs when they peek into the logs while things are not working as expected?
I agree that the log statement is the minimum we can do, and would at least give a hint about the way in which things are broken. Now, I guess the reason we're kind of disagreeing on the path forward is that you're much more hopeful than me that nextcloud will ever fix its stuff -- I'm assuming it'll get fixed in years at best (and even then…) -- and if it's in years then I'd much rather live with for years then spend a year deprecating it by making it conflict with new options than try to live with from now on and have users fail to understand what is going on. Now urhm, I'm investigating the module a bit deeper, and… is there any reason we can't put the database configuration etc. in ? We could then refresh on each activation, and it should be enough? If we have a way to couple it with something that automatically runs iff the database is not ready yet then the setup would actually be… almost perfect?
After having a deeper look at the sources ( at github, (6 commits ahead of v16.0.0RC1)) I guess that this should be possible (I didn't test it yet though). Configs will be loaded from using PHP's function[1] while all files ending with will be taken into account. Hence works as all config arrays will be merged together. This config will be loaded at [2] and is available as which is then used in the DI container[3]. If I understand the code correctly, I assume that it should be possible to render all config options in as config files found by glob will override values from [4]. [4]
Nice catch! This might indeed be possible - we should make very sure that config overrides work the way we think they will - seems to write the merged configuration, and not just the overrides (and merging this with other config in the wrong order can lead to wonderfully weird to debug issues) ;-) While I'd still prefer nextcloud splitting config and state properly, and being able to cope with read-only (base) config - it might be a direction worth exploring. What do you think?
Code change:
services.postgresql = { <link linkend="opt-services.postgresql.enable">enable</link> = true; <del> <link linkend="opt-services.postgresql.initialScript">initialScript</link> = pkgs.writeText "psql-init" '' CREATE ROLE nextcloud WITH LOGIN; CREATE DATABASE nextcloud WITH OWNER nextcloud; ''; </del> <ins> <link linkend="opt-services.postgresql.ensureDatabases">ensureDatabases</link> = [ "nextcloud" ]; <link linkend="opt-services.postgresql.ensureUsers">ensureUsers</link> = [ { name = "nextcloud"; ensurePermissions."DATABASE nextcloud" = "ALL PRIVILEGES"; } ]; </ins> }; # ensure that postgres is running *before* running the setup

Related discussion:
text: Well, for the record it was actually idea :sweat_smile: I guess so, all the stuff from is also in my at the moment. I'll probably have sufficient time next weekend to check if I can trigger such a case. I can't promise that, but unless anybody beats me, I can hopefully prepare a fix for this :)
Did you gain some new insights on this?
Unfortunately not... I was pretty busy back then. But as this only requires some fiddling in the module and no patching of the actual package, the change shouldn't be too painful, so if you'd like to take over... :sweat_smile:
there's with a fix now :)
Code change:
"examples/*" ]; <ins> disabledTests = [ # See https://github.com/google/flax/issues/2554. "test_async_save_checkpoints" "test_jax_array0" "test_jax_array1" "test_keep0" "test_keep1" "test_optimized_lstm_cell_matches_regular" "test_overwrite_checkpoints" "test_save_restore_checkpoints_target_empty" "test_save_restore_checkpoints_target_none" "test_save_restore_checkpoints_target_singular" "test_save_restore_checkpoints_w_float_steps" "test_save_restore_checkpoints" ]; </ins> meta = with lib; { description = "Neural network library for JAX"; homepage = "https://github.com/google/flax";

Related discussion:
text: Build of failed on x86_64-linux as of . This is currently breaking . maintainers cc: maintainers cc: Other cc: n/a nixpkgs at commit This issue was automatically generated by . that created this issue. Internal tags: - -
Code change:
if [ -n "${dirs}" ]; then header "stripping (with command $cmd and flags $stripFlags) in$dirs" <del> find $dirs -type f -exec $cmd $commonStripFlags $stripFlags '{}' ; 2>/dev/null </del> <ins> find $dirs -type f -exec $cmd $stripFlags '{}' ; 2>/dev/null </ins> stopNest fi }

Related discussion:
text: The Linux stdenv sets But that flag is specific to GNU strip, and LLVM's strip will fail if passed it. Conveniently, we silence all errors from stripping, so this has gone unnoticed until now: I noticed this while trying to fix . One of the reasons it doesn't work is that it has in , and strip should be removing that reference but isn't. What I'm not sure about here is the best way to fix this. There's nothing platform-specific about this option, so it shouldn't live in the Linux stdenv. (Other platforms like NetBSD use GNU binutils by default.) Ideally it would be a conditional in the strip setup hook, but we don't really have a bash equivalent to . So where (in Nix) should we check this and set the variable? cc
With what we have at the moment, I can only think of hacky workarounds like checking if ends in . However such an approach (and even checking ) is actually incorrect: and don't have to be matched, e. g. with as linker and GNU bintools is quite common actually. Looking at prior art in nixpkgs, I'm quite convinced that the cleanest solution for now would be to bite the bullet and extend to also wrap . In fact, we already seem to have a strip wrapper for darwin.
Hmm, I don't like the idea of globally adding a flag only to remove it again in a wrapper. Another idea I had was to do this in the definition of make- — the hardening flags are precedent for doing manipulation of environment variables for setup hooks in there. We could add an isGNU attribute to the possible values of , and use that? I don't much like this idea either, but I like it better than adding the flag globally and then wrapping to remove it. What do you think?
Since this flag is unconditionally in general, I think we can just remove it from the linux hook and instead add it in the binutils-wrapper. This should also solve the issue of this being binutils-specific and not linux-specific AIUI.
Oh, you mean wrap GNU binutils' strip to add this flag? That sounds fine to me.
If I understand correctly this is now done:
Code change:
home = "/root"; shell = mkDefault cfg.defaultUserShell; group = "root"; <ins> initialHashedPassword = mkDefault "!"; </ins> }; nobody = { uid = ids.uids.nobody;

Related discussion:
text: Describe the bug There are reasons to want a system, that has no user that can log in by SSH or with their password, for example in a declarative container To Reproduce Steps to reproduce the behavior: up a minimal declarative container asserts that I will be locked out from the system and refuses to build the configuration with Expected behavior nix generates me a container that I can log in with , or maybe I don't want to log into it at all (because it's a disposable VM or something of the like). I think there should be a check whether the generated system is a container and an additional "I know what I'm doing" override for other cases. I'll create a PR once we agreed on what's best. Maintainer information: Code causing the problem: mentioning since you the check.
Is it an option to set a randomly-generated (the hash itself would be generated, not obtained by honestly hashing a password)? Recovering the password from such a hash is probably harder than a lot of other attack vectors. But an override «doLockOutEveryone» sounds fine.
Setting a password would certainly be a possibility, but somewhat (for lack of a better word) really lame. Having slept a night over it, I propose , that disables all the assertions at the bottom. I can see scenarios where two users with the same uid could be wanted. I want my unixoid to always give me enough rope to shoot myself in the leg.
What about not enabling ssh and disabling the getty? It should completely lock anyone out, unless I am missing something. Take a look at the profile.
In case of a nixos declaratively defined nixos container, you are not logged out because the root system(d) can generate a root shell without any authentication, which is why I consider this a bug. Having to "fool" the assertion to actually lock oneself out is another matter, I could live with that but I don't think it's nice behavior.
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.
Code change:
home = "/root"; shell = mkDefault cfg.defaultUserShell; group = "root"; <ins> initialHashedPassword = mkDefault "!"; </ins> }; nobody = { uid = ids.uids.nobody;

Related discussion:
text: 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 . 3. Ask on the on .
This is still an issue.
I marked this as stale due to inactivity. &rarr;
Fixed via
Code change:
}; goPackagePath = "github.com/Stebalien/localtime"; <del> buildInputs = [ systemd polkit m4 ]; </del> <ins> buildInputs = [ m4 ]; </ins> <del> makeFlags = [ "PREFIX=$(out)" ]; </del> <ins> makeFlags = [ "PREFIX=${placeholder "out"}" "BINDIR=${placeholder "bin"}/bin" ]; </ins> buildPhase = '' cd go/src/${goPackagePath} <del> make localtimed </del> <ins> make $makeFlags </ins> ''; installPhase = '' <del> mkdir -p $bin/bin install -Dm555 localtimed $bin/bin </del> <ins> make install $makeFlags </ins> ''; meta = with stdenv.lib; {

Related discussion:
text: I've just set on my laptop while on holiday. The timezone never updates (tried restarting, waiting a while). Running I see: I see in that the service is run as the user. If I run: I also see the message . Whereas if I run there is no output and the timezone immediately updates (as shown by an immediate change in the time in my status bar, and confirmed by running ). It seems that the user just doesn't have permission to set the timezone. in (and unset ) to see if timezone changes , look for messages with "Failed to set timezone" (will only appear if the timezone it would need to set is different than the current timezone) system: host os: multi-user?: sandbox: version: channels(root): nixpkgs:
It worked for me after a reboot. Maybe the polkit rules are not getting appliead during a ?
Code change:
+            # https://stackoverflow.com/a/17022146/4935114 +            shutil.copystat = lambda x, y: x +            shutil.copytree(self.srcdir, self.dir, copy_function=shutil.copyfile) <del> try: shutil.copyfile(os.path.join(gr.prefix(), 'share', 'gnuradio', 'clang-format.conf'), os.path.join(self.dir, '.clang-format')) </del> <ins> source_dir = os.path.join(gr.prefix(), "share", "gnuradio") for source_name, target_name in ( ("clang-format.conf", ".clang-format"), </ins>

Related discussion:
text: Package name: gnuradio Latest released version: 3.10.8.0 <!-- Search your package here: --- Current version on the unstable channel: 3.10.7.0 Current version on the stable/release channel:3.10.7.0 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]:
Tnx. Update is proposed at
Code change:
pdf-quench = callPackage ../applications/misc/pdf-quench { }; <ins> pdf-sign = callPackage ../tools/graphics/pdf-sign { }; </ins> pdfarranger = callPackage ../applications/misc/pdfarranger { }; briss = callPackage ../tools/graphics/briss { };

Related discussion:
text: Project description From the project page: A tool to sign PDF files with Linux support. Why There appears to be a lack of applications that run on Linux and allow for attaching free-hand signatures to PDF files in a good way. (Non-)alternatives include: Xournal and Xournal++: Allows free-hand annotations but not saving those for later use. Allows inserting images and .pdf files but will rasterize them rather than retain the vector graphics, resulting in lower quality. LibreOffice Draw: Allows inserting images and .pdf files but will rasterize them rather than retain the vector graphics, resulting in lower quality. Okular: Allows free-hand annotations but not saving those for later use. Allows inserting custom saved stamps, but these will not be visible in other PDF readers. Evince: Allows certain kinds of annotations, but nothing that can look like a free-hand signature. pdftk, Ghostscript, and other command-line tools: Allows superimposing .pdf files, but not interactively selecting where. Metadata homepage URL: source URL: license: MIT platforms: linux
Working on it
Code change:
let debPatch = fetchzip { <del> url = "mirror://debian/pool/main/v/vorbis-tools/vorbis-tools_1.4.0-6.debian.tar.xz"; sha256 = "1xmmpdvxyr84lazlg23c6ck5ic97ga2rkiqabb1d98ix2zdzyqz5"; </del> <ins> url = "mirror://debian/pool/main/v/vorbis-tools/vorbis-tools_1.4.0-11.debian.tar.xz"; sha256 = "0kvmd5nslyqplkdb7pnmqj47ir3y5lmaxd12wmrnqh679a8jhcyi"; </ins> }; in stdenv.mkDerivation {

Related discussion:
text: , (nixos-19.03) (nixos-19.03) (nixos-19.03) (nixos-19.03) (nixos-19.03) Scanned versions: nixos-19.03: . May contain false positives.
See also
Can be fixed by bumping the debian patchseries we pull from -6 to -11. Already fixed by the -6 debian patchseries. Fixed, indirectly, by the patches for CVE-2014-9638 and CVE-2014-9639 (above). This CVE was a fulldisclosure publication, so it didn't get triaged and fixed... But it is fixed. Conclusion: we can close this bug by pulling in the new debian patch series from 1.4.0-11 (up from 1.4.0-6). Sending PRs.
Code change:
npmInstallHook = makeSetupHook { name = "npm-install-hook"; <del> deps = [ makeWrapper ]; </del> <ins> deps = [ buildPackages.makeWrapper ]; </ins> substitutions = { hostNode = "${nodejs}/bin/node"; jq = "${buildPackages.jq}/bin/jq";

Related discussion:
text: Describe the bug I need to list the out paths of cross compiled packages beforehand which causes an eval error. To Reproduce Steps to reproduce the behavior: Expected behavior List all out paths like `. Additional context I need this feature for nixpkgs-review when cross compiling. 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 system: host os: multi-user?: sandbox: version: channels(user): nixpkgs: Maintainer information:
I think its because of the lack of splicing for perl-packages. Note however, that when that is fixed, other package sets will fail with the same issue. cc
Probably multiple issues. Have seen that problem with building xwayland for aarch64 too. Removing makeWrapper helps but probably breaks it :(. But the deps don't cross-build anyway so never got that far for now. Was thinking about opening an issue but got caught up trying to find the issue -- to no avail. Not currently at my machine, might post it later.
I marked this as stale due to inactivity. &rarr;
still important to me
Fix in
Code change:
- [Mealie](https://nightly.mealie.io/), a self-hosted recipe manager and meal planner with a RestAPI backend and a reactive frontend application built in NuxtJS for a pleasant user experience for the whole family. Available as [services.mealie](#opt-services.mealie.enable) <ins> - [Sunshine](https://app.lizardbyte.dev/Sunshine), a self-hosted game stream host for Moonlight. Available as [services.sunshine](#opt-services.sunshine.enable). </ins> - [Uni-Sync](https://github.com/EightB1ts/uni-sync), a synchronization tool for Lian Li Uni Controllers. Available as [hardware.uni-sync](#opt-hardware.uni-sync.enable) ## Backward Incompatibilities {#sec-release-24.05-incompatibilities}

Related discussion:
text: Project description <!-- Describe the project a little: --Sunshine has already been packaged here in nixpkgs: But it doesn't come out of the box just by , according to and and , at least it needs a and maybe . It would be better if we could add a NixOS module for it to make it availale just by sth. like or . CC maintainer Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
This has been on my to-do list for ages :) The module itself wouldn't be a huge deal, and I think I have a plan for tests, just need some time to work on it.
I actually started working on this a while ago. My module can create valid and files (i.e. they work when I start sunshine manually) and open the necessary ports, however I couldn't get the systemd service to function properly. If I recall correctly, the issue was related to getting access to the screen. Here is what I have so far, maybe it can help someone:
Thanks I used yours as inspiration and opened for this. It's still a draft -- I need to work on the tests -- but any testing or comments are welcome. I've tested on Plasma 6 + Wayland + AMD and seems to work, have not tested much with Xorg or NVIDIA.
Think it's got all the functionality I had planned -- marked as ready for review.
Code change:
<del> { stdenv, fetchFromGitLab, cmake, fcitx, pkgconfig, qtbase, extra-cmake-modules }: </del> <ins> { lib, mkDerivation, fetchFromGitLab , cmake , extra-cmake-modules , fcitx , pkgconfig , qtbase }: </ins> <del> stdenv.mkDerivation rec { </del> <ins> mkDerivation rec { </ins> pname = "fcitx-qt5"; version = "1.2.3";

Related discussion:
text: Describe the bug fcitx-qt5 fails to build on unstable: To Reproduce Metadata nixos unstable
It's trying to install into qtbase . Probably should set this to be within the proper prefix.
yep I've seen that as well. Seems like some packages set to work around this but haven't had the time to test it yet. EDIT: that fixed the first problem but not the second one:
will fix this.
This is still an issue on stable -- Installing: /nix/store/phkl5sfpn4jvncjd2sa29g182gpmmja7-fcitx-qt5-1.2.3/share/locale/zhCN/LCMESSAGES/fcitx- -- Installing: /nix/store/phkl5sfpn4jvncjd2sa29g182gpmmja7-fcitx-qt5-1.2.3/share/locale/zhTW/LCMESSAGES/fcitx- -- Installing: /nix/store/g83143pyn6sc1x1nqqjcamap4c2b1rbw-qtbase-5.12.0-bin/lib/qt- CMake Error at (file): file INSTALL cannot copy file "" to "/nix/store/g83143pyn6sc1x1nqqjcamap4c2b1rbw-qtbase-5.12.0-bin/lib/qt-".
Code change:
<del> { stdenv, fetchFromGitLab, cmake, fcitx, pkgconfig, qtbase, extra-cmake-modules }: </del> <ins> { lib, mkDerivation, fetchFromGitLab , cmake , extra-cmake-modules , fcitx , pkgconfig , qtbase }: </ins> <del> stdenv.mkDerivation rec { </del> <ins> mkDerivation rec { </ins> pname = "fcitx-qt5"; version = "1.2.3";

Related discussion:
text: Call Stack (most recent call first): (include) make: * [Makefile:106: install] Error 1 builder for '/nix/store/ypfmrmajq452nmskg0ffwa27hm58l492-fcitx-qt5-' failed with exit code 2 cannot build derivation '/nix/store/hdsvn6hc7h7wf29kdnpvr7iaivplyyb8-fcitx-with-plugins-': 1 dependencies couldn't be built cannot build derivation '/nix/store/4lwxfbacn5fcymlm3jpv6wl4anllxmzd-system-': 1 dependencies couldn't be built cannot build derivation '/nix/store/d4k8dywj47xrbxfmvdaw4gywnwdn874r-xsession-': 1 dependencies couldn't be built cannot build derivation '/nix/store/fj8xinm3fjd7sp9s20iqg23yx27zc193-nixos-system-voyagertwo-': 1 dependencies couldn't be built error: build of '/nix/store/fj8xinm3fjd7sp9s20iqg23yx27zc193-nixos-system-voyagertwo-' failed Note that I have a following setting in environment.extraOutputsToInstall = ["out"]; environment.pathsToLink = [ "/share/locale" ];
:confused: Didn't expect that to broken the same way on stable. please open a separate issue requesting some sort of backport for the relevant commit
Still seems to fail on unstable?
Code change:
<ins> { lib , rustPlatform , fetchFromGitHub , openssl , pkg-config }: rustPlatform.buildRustPackage rec { pname = "awatcher"; version = "0.3.0"; src = fetchFromGitHub { owner = "2e3s"; repo = "awatcher"; rev = "v${version}"; hash = "sha256-G7UH2JcKseGZUA+Ac431cTXUP7rxWxYABfq05/ENjUM="; }; nativeBuildInputs = [ pkg-config ]; buildInputs = [ openssl ]; doCheck = false; cargoLock = { lockFile = ./Cargo.lock; outputHashes = { "aw-client-rust-0.1.0" = "sha256-yliRLPM33GWTPcNBDNuKMOkNOMNfD+TI5nRkh+5YSnw="; }; }; meta = with lib; { description = "Activity and idle watchers"; longDescription = '' Awatcher is a window activity and idle watcher with an optional tray and UI for statistics. The goal is to compensate the fragmentation of desktop environments on Linux by supporting all reportable environments, to add more flexibility to reports with filters, and to have better UX with the distribution by a single executable. ''; downloadPage = "https://github.com/2e3s/awatcher/releases"; homepage = "https://github.com/2e3s/awatcher"; license = licenses.mpl20; mainProgram = "awatcher"; maintainers = [ maintainers.aikooo7 ]; platforms = platforms.linux; }; } </ins>

Related discussion:
text: Project description awatcher is a window watcher designed to be used in combination with Activitywatch, an open-source time tracker that is already in nixpkgs. Activitywatch needs a window watcher program running to get info on what programs are open and for how long. nixpkgs already includes the default window watcher (aw-watcher-window) and the WIP wayland version (aw-watcher-window-wayland), but awatcher supports both X11 and Wayland, while featuring better Wayland support than aw-watcher-window-wayland. This would allow using Activitywatch in combination with KDE or Gnome on Wayland or when running Hyprland. Metadata homepage URL: source URL: license: Mozilla Public License 2.0 platforms: linux Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]: