jiebi/CodeConvo huggingface dataset:
Change:
- The `services.fwupd` module now allows arbitrary daemon settings to be configured in a structured manner ([`services.fwupd.daemonSettings`](#opt-services.fwupd.daemonSettings)). <ins> - The `zramSwap` is now implemented with `zram-generator`, and the option `zramSwap.numDevices` for using ZRAM devices as general purpose ephemeral block devices has been removed. </ins> - The `unifi-poller` package and corresponding NixOS module have been renamed to `unpoller` to match upstream. - The new option `services.tailscale.useRoutingFeatures` controls various settings for using Tailscale features like exit nodes and subnet routers. If you wish to use your machine as an exit node, you can set this setting to `server`, otherwise if you wish to use an exit node you can set this setting to `client`. The strict RPF warning has been removed as the RPF will be loosened automatically based on the value of this setting.

Discussion:
Project description In the author says, In 2020 the zram-generator doesn't seem to have had any releases. In the meantime, it's gone from initial release version 0.2.0 up to the somewhat-mature version 1.1.2. It's probably a good time to port this to zram-generator. Metadata homepage URL: source URL: license: mit platforms: linux
Change:
environment.REQUESTS_CA_BUNDLE = "/etc/ssl/certs/ca-certificates.crt"; serviceConfig = { Type = "oneshot"; <ins> # With RemainAfterExit the service is considered active even # after the main process having exited, which means when it # gets changed, the activation phase restarts it, meaning # the permissions of the StateDirectory get adjusted # according to the specified group RemainAfterExit = true; </ins> SuccessExitStatus = [ "0" "1" ]; User = data.user; Group = data.group;

Discussion:
Changing or will not do anything till the next round of refresh after refresh, changes to do not actually propagate. The permissions of the key are not changed. Only of the surrounding directory. a cert with change to : Afterwards add Observe that the owner is still and that there are no group read permissions yet after manually refreshing by calling the timer manually, the did change, by the permission bits still not allow read access to even if is set Please run and paste the results.
Hey I made a PR that fixes this, would love to have somebody else make sure it fixes this problem:
Lets re-open this issue.
Hello, I'm a bot and I thank you in the name of the community for opening this issue. To help our human contributors focus on the most-relevant reports, I check up on old issues to see if they're still relevant. This issue has had no activity for 180 days, and so I marked it as stale, but you can rest assured it will never be closed by a non-human. The community would appreciate your effort in checking if the issue is still valid. If it isn't, please close it. If the issue persists, and you'd like to remove the stale label, you simply need to leave a comment. Your comment can be as simple as "still important to me". If you'd like it to get more attention, you can ask for help by searching for maintainers and people that previously touched related code and @ mention them in a comment. You can use or on the relevant files to find them. Lastly, you can always ask for help at or at .
wasnt this fixed by the recent bugfix round ?
Yeah, that option has been removed Infact :P
This option is now gone in favour of always making the certificates group readable and owned by the acme user, and letting users change only the group that will be applied to them. Closing this issue.
Change:
zulip = callPackage ../development/python-modules/zulip { }; <ins> zulip-emoji-mapping = callPackage ../development/python-modules/zulip-emoji-mapping { }; </ins> zwave-me-ws = callPackage ../development/python-modules/zwave-me-ws { }; zwave-js-server-python = callPackage ../development/python-modules/zwave-js-server-python { };

Discussion:
Project description A Zulip puppeting bridge for Zulip. similar to mautrix-signal etc. Metadata homepage URL: source URL: license: agpl 3 platforms: linux Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
See
Change:
else ""; <ins> pathConfig = runCommand "ldc-lib-paths" {} '' mkdir $out echo ${tzdata}/share/zoneinfo/ > $out/TZDatabaseDirFile echo ${curl.out}/lib/libcurl${stdenv.hostPlatform.extensions.sharedLibrary} > $out/LibcurlPathFile ''; </ins> in stdenv.mkDerivation rec {

Discussion:
Describe the bug The ldc package (1.17.0) is currently failing to build properly in the unstable branch. It looks like the following is the culprit: To Reproduce Steps to reproduce the behavior: done! Expected behavior The package should build and install cleanly. Metadata system: host os: multi-user?: sandbox: version: channels(root): channels(chrisaw): nixpkgs: cc
Right, looks like is commit introducing the failure. The relied on shell expansion which no longer happens, so we get this: Instead of this:
cc
is right. So a fix could be to use but I find the hardcoded /build quite ugly. The path doesn't need to be in /build but I put it there to make sure it's not a file used by some other process. Switching from /build to /tmp or whatever is for this reason not a good solution.
I'm not sure with the changes for structured attrs we could use shell expansion for like before. Perhaps could comment since the fix looks obvious.
Right CMake does not interpolate environment variable, this was oversight on our part. Looks like was in and I agree that hardcoding is not a good idea but the presence of feels like a hack too. What is ts purpose? If the string imports are generated by the build system, I would expect them to be found without any extra flags. And if they are generated us during bootstrapping, I would expect them to be in a separate derivation, making referencing them work without variable interpolation. If we cannot get rid of the , we should move the flag to until we can.
Looks like the flag is needed for Could we copy the file to a build system’s natural directory like or something, so that the flag could be omitted?
The flag is the only possibility to get the tzdata path into the library. See for the code in the library. Where the file is doesn't matter but I don't see any better location as $PWD for now.
Is not it possible to put it to directory or something?
Yes but I still need to get the full path to it for -J and there is no default directory so you could omit the -J if you mean that. See point 3 in .
Change:
wrapProgram $out/bin/tailscaled  --prefix PATH : ${lib.makeBinPath [ iproute2 iptables getent shadow ]}  --suffix PATH : ${lib.makeBinPath [ procps ]} <ins> sed -i -e "s#/usr/sbin#$out/bin#" -e "/^EnvironmentFile/d" ./cmd/tailscaled/tailscaled.service install -D -m0444 -t $out/lib/systemd/system ./cmd/tailscaled/tailscaled.service '' + lib.optionalString (stdenv.buildPlatform.canExecute stdenv.hostPlatform) '' </ins> local INSTALL="$out/bin/tailscale" installShellCompletion --cmd tailscale  --bash <($out/bin/tailscale completion bash)  --fish <($out/bin/tailscale completion fish)  --zsh <($out/bin/tailscale completion zsh) <del> sed -i -e "s#/usr/sbin#$out/bin#" -e "/^EnvironmentFile/d" ./cmd/tailscaled/tailscaled.service install -D -m0444 -t $out/lib/systemd/system ./cmd/tailscaled/tailscaled.service </del> ''; passthru.tests = {

Discussion:
fails: see: cc: 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. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
(Fixed the title, my bad)
The current () tailscale builds fine for me on , but I gave it a try to be more "correct" anyway. I attempted to change to the following as a fix: However I seem to get the following error: I also tried running itself in the just to see what happens, and got an exec format error, presumably that's the cause of not having a completion in the first place.
Change:
wayland-proxy-virtwl = callPackage ../tools/wayland/wayland-proxy-virtwl { }; <ins> waylogout = callPackage ../tools/wayland/waylogout { }; </ins> waynergy = callPackage ../tools/wayland/waynergy { }; wayout = callPackage ../tools/wayland/wayout { };

Discussion:
waylogout is graphical logout/suspend/reboot/shutdown dialog for wayland. It is inspired by and based on code from . Metadata license: mit platforms: linux
Change:
gem 'idn-ruby' gem 'jbuilder' gem 'jekyll' <ins> gem 'jekyll-favicon' </ins> gem 'jmespath' gem 'jwt' gem 'kramdown-rfc2629'

Discussion:
Project description Metadata license: MIT platforms: Any
I guess the issue can be closed due to . Reopen if I am incorrect
Oh, weird. The " in wasn't applied automatically. Thank you!
Change:
''); specialisation = rec { <ins> brokenInitInterface.configuration.config.system.extraSystemBuilderCmds = '' echo "systemd 0" > $out/init-interface-version ''; modifiedSystemConf.configuration.systemd.extraConfig = '' # Hello world! ''; addedMount.configuration.virtualisation.fileSystems."/test" = { device = "tmpfs"; fsType = "tmpfs"; }; addedMountOptsModified.configuration = { imports = [ addedMount.configuration ]; virtualisation.fileSystems."/test".options = [ "x-test" ]; }; addedMountDevModified.configuration = { imports = [ addedMountOptsModified.configuration ]; virtualisation.fileSystems."/test".device = lib.mkForce "ramfs"; }; storeMountModified.configuration = { virtualisation.fileSystems."/".device = lib.mkForce "auto"; }; swap.configuration.swapDevices = lib.mkVMOverride [ { device = "/swapfile"; size = 1; } ]; </ins> simpleService.configuration = { systemd.services.test = { wantedBy = [ "multi-user.target" ];

Discussion:
The script is apparently trying to stop and start changed .mount units, presumably to cause a ? If that happens the script fails and the new configuration is not activated. Worse, the system is left in a broken state with some of the stopped (as part of the switch) units never restarted. Steps to reproduce the behavior: the value of , for example from to . The unit should probably not be stopped and the switch should succeed. If using remotely also the SSH connection drops. NixOS version: 23.05.1194. (Stoat) The filesystem entry is: cc:
I just ran into this error myself. I am unsure of which configuration change caused this. But I was changing config and I think was saying some setting conflicts with my , which was at . So I updated to and then flashed me this error: before giving me a black screen and send me to the login prompt.
were you ever able to fix your issue?
No fix, I'm pretty sure changing the unit will still trigger a stop.
Unfortunately, you are correct. I do have a fix in the pipeline though. improves the handling of mount units () and I plan to adapt this to fstab mounts as well (). This is currently being blocked by the fstab parser not having any tests but I plan on writing them. Will keep this issue in mind.
Now that I look at the code again… it already looks correct. Can someone with this issue post a diff of their fstab? Something like should do.
Change:
maintainers = with maintainers; [ _1000101 ]; platforms = platforms.linux; }; <del> } </del> <ins> }) </ins>

Discussion:
Package name: Stretchly Latest released version: 1.15.1 <!-- 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. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Change:
(mkRemovedOptionModule [ "services" "nextcloud" "disableImagemagick" ] '' Use services.nextcloud.enableImagemagick instead. '') <ins> (mkRemovedOptionModule [ "services" "nextcloud" "config" "dbport" ] '' Add port to services.nextcloud.config.dbhost instead. '') </ins> (mkRenamedOptionModule [ "services" "nextcloud" "logLevel" ] [ "services" "nextcloud" "extraOptions" "loglevel" ]) (mkRenamedOptionModule

Discussion:
The configuration is ignored by when setting up the database as it is a configuration no longer used in the latest versions of See Steps to reproduce the behavior: up "dbhost" to "/run/postgresql", and "dbport" to anything else than 5432 (default pgsql port), let's say 5435 for example -setup.service will fail saying the file is not found In , the value should be set as instead, any field is ignored (and should then be deleted)
FYI
Change:
githubId = 2147649; name = "Euan Kemp"; }; <ins> eureka-cpu = { email = "github.eureka@gmail.com"; github = "eureka-cpu"; githubId = 57543709; name = "Chris O'Brien"; }; </ins> evalexpr = { name = "Jonathan Wilkins"; email = "nixos@wilkins.tech";

Discussion:
Project description Gruvbox Plus icon pack for Linux desktops based on Gruvbox color theme. Metadata homepage URL: source URL: license: GPL-3.0 platforms: linux
Change:
description = "Language Server Protocol (LSP) for Clojure"; homepage = "https://github.com/clojure-lsp/clojure-lsp"; license = licenses.mit; <del> maintainers = [ maintainers.ericdallo ]; </del> <ins> maintainers = with maintainers; [ ericdallo babariviere ]; </ins> platforms = graalvm11-ce.meta.platforms; }; }

Discussion:
Describe the bug When running I get the following error message: Looking at the executable the first line is: In fish does not return the name of the current executed file. It appear to work when running this using . Also as comparison look at the file generated via package manager: To Reproduce Steps to reproduce the behavior: Expected behavior should start the server Additional context So with . Notify maintainers Metadata Please run and paste the result. system: host os: multi-user?: sandbox: version: channels(yogsototh): nixpkgs: Maintainer information:
Hey this version is pretty outdated, could you try latest which is using graalvm binary?
Also the brew forumla you saw is outdated as well, the updated is
You are probably using the stable channel 20.09 channel, that should explain why you're still using the with JVM instead of GraalVM compiled binary. Switch to the unstable channel instead. I am not sure if it will work though since this package was never tested with macOS (and the fact that this package is broken in Hydra: ).
I just tested with latest master commit And if failed to build: I think the main bug is probably fixed. This is just another one :). This is late for me. I'll probably give it a look another day. Thanks for checking!
I think all GraalVM's packages build with Clojure are broken in macOS simply by the lack of people that has macOS systems to test/fix them. If you can fix this, a PR would be welcome :slightlysmilingface: .
Agreed If you have mac, using the homebrew official clojure-lsp formula should work as well: https://clojure-
Change:
''; postFixup = '' <del> makeWrapper ${electron_21}/bin/electron $out/bin/${pname}  </del> <ins> makeWrapper ${electron_24}/bin/electron $out/bin/todoist-electron  </ins> --add-flags $out/share/${pname}/resources/app.asar  --prefix LD_LIBRARY_PATH : "${lib.makeLibraryPath [ stdenv.cc.cc libsecret ]}"  --add-flags "''${NIXOS_OZONE_WL:+''${WAYLAND_DISPLAY:+--ozone-platform-hint=auto --enable-features=WaylandWindowDecorations}}"

Discussion:
Package name: todoist-electron Latest released version: 1.1.2 Current version on the unstable channel: 1.0.9 Current version on the stable/release channel: 1.0.9 currently depends on which is EOL. I don't know how to determine from the appimage which version of Electron upstream is using. 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.
, upstream is way behind, I checked the appimage with appimage-run: unfortunately, overriding electron21 with electron22 seems to break login. I opened a support ticket () asking if they have plans to update to a newer Electron version any time soon.
Change:
<ins> Excerpted from <https://git.savannah.gnu.org/cgit/bash.git/commit/?h=devel&id=055a4552c901e43e6a6007f5bc664a33698dbf85>. Original author: Chet Ramey <chet.ramey@case.edu> --- variables.c +++ variables.c @@ -5413,7 +5413,9 @@ pop_var_context () vcxt = shell_variables; if (vc_isfuncenv (vcxt) == 0) { -      internal_error (_("pop_var_context: head of shell_variables not a function context")); +      /* If we haven't flushed all of the local contexts already, flag an error */ +      if (shell_variables != global_variables || variable_context > 0) +	internal_error (_("pop_var_context: head of shell_variables not a function context")); return; } </ins>

Discussion:
Not a nixpkgs bug nor the cause of any failure
I ran into this when trying to build Bottles. In case anyone finds this issue and is trying to track down a potential source of it. There is a with a workout around for Bottles that is merged and to nixos-unstable.
Hi this issue's topic is unrelated to the error you're speaking of. See -- the line in this issue can be ignored. The actual issue is above that line in the pahelper build you're talking about:
:pray: thank you very much for clarifying that !
Is there some mitigation for this I can do? Because right now I'm getting this error when trying to build various Python packages and it is pretty annoying.
Either ignore it or backport the fix
How do I ignore it? It seems to break my builds.
No, your builds are failing for a different reason. The error in this issue occurs when the build fails at a certain point, you can just ignore it.
I still have this issue as of today. I'm recompiling to change shortcuts (that's how it is done). When invoking in the hook, I have the mentioned issue. I have had issues with (and the very same error message) in other derivations, too. This has probably nothing to do with . I just happen to use it regularly.
No surprise here, your grep command is failing (because ), so the build fails. Please try to keep on topic.
Ah, yes, you're right. It's the combination of the + grep failing. Thanks. Please try to be polite.
I backported the upstream fix in It looks like only one part of that commit was relevant to this bug, so it applies pretty cleanly.
Change:
let fetch_librusty_v8 = args: fetchurl { name = "librusty_v8-${args.version}"; <del> url = "https://github.com/denoland/rusty_v8/releases/download/v${args.version}/librusty_v8_release_${stdenv.hostPlatform.rust.rustcTarget}.a"; </del> <ins> url = "https://github.com/denoland/rusty_v8/releases/download/v${args.version}/librusty_v8_release_${stdenv.hostPlatform.rust.rustcTarget}.a.gz"; </ins> sha256 = args.shas.${stdenv.hostPlatform.system}; meta = { inherit (args) version; }; }; in fetch_librusty_v8 { <del> version = "0.85.0"; </del> <ins> version = "0.89.0"; </ins> shas = { <del> x86_64-linux = "sha256-Ma6JewYaHuPLihKnwwq8pAo+6sraXMghnl+wMvRfP1Y="; aarch64-linux = "sha256-Y55ZXuyB2kq2a/cJwIo7DxClg2juAsGYpyTmwYE2W3Q="; x86_64-darwin = "sha256-njP3obzJxr8I4G3jhDNbiVL8Cxa9D4KPGXW7VFrAZQY="; aarch64-darwin = "sha256-/8UFpUgdSKihxd4qsBoxYFrjEKUG3cDSkwJ5NSdmSQs="; </del> <ins> x86_64-linux = "sha256-XxX3x3LBiJK768gvzIsV7aKm6Yn5dLS3LINdDOUjDGU="; aarch64-linux = "sha256-ZetNxahe/XDp6OoGFkZS7VfOPQPbEGUkPNAaSJ0Y90M="; x86_64-darwin = "sha256-A047aVL2KSNWofPK2eH395iGPcdM+FjSxu5GkW9wJnI="; aarch64-darwin = "sha256-XN2JFL8Rs9hyTquVx6brjW15H54mhVIHqzkdEy9smqM="; </ins> }; }

Discussion:
Package name: deno Latest released version: 1.42.3 Current version on the unstable channel: 1.41.3 Current version on the stable/release channel: 1.38.2 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]:
Hi I'll look into why there hasn't been a PR opened yet by the bot. The update will probably only go into unstable, just to be clear upfront. There will be a new stable release in the next month or so for . Also I can't edit your issue but your versions for unstable/stable are backwards :)
, in case you didn't find it already. Fixed.
Change:
platforms = attrNames srcs; maintainers = with maintainers; [ offline matejc thoughtpolice joachifm hax404 KarlJoad ]; mainProgram = "tor-browser"; <del> hydraPlatforms = []; </del> # MPL2.0+, GPL+, &c.  While it's not entirely clear whether # the compound is "libre" in a strict sense (some components place certain # restrictions on redistribution), it's free enough for our purposes.

Discussion:
Steps to reproduce the behavior: Probably just has to be updated: ! Please run and paste the result.
I merged several days ago but looks like the channel is not updating , anyway maybe we need to find a fallback download url.
This is a recurring issue with the bundle. I believe there are already a few fallback URLs but perhaps they all adhere to the policy of removing all but the latest release? I understand that upstream strongly prefers users always run the latest version. To avoid build failures I suppose you could try re-enabling Hydra caching (if it's still disabled) but that incurs the risk of letting users run outdated versions for longer.
Why was it disabled? Maybe we should insert a comment with the explanation. Depending on the reason for the disablement, may or may not eliminate whatever the benefit of disabling it being fetched+cached by Hydra was.
In which delivers no good reason. Going to remove that.
Change:
) '' + pkgs.lib.optionalString pkgs.stdenv.hostPlatform.isAarch64 '' machine.succeed( <del> "grep 'devicetree .*dummy' /boot/loader/entries/nixos-generation-1-specialisation-something.conf" </del> <ins> r"grep 'devicetree /EFI/nixos/[a-z0-9]{32}.*dummy' /boot/loader/entries/nixos-generation-1-specialisation-something.conf" </ins> ) ''; };

Discussion:
Spent a fair bit debugging something. Came down to my DTB being out of sync. The lack of hash prefix should've warned me sooner. The issue is that the dtb is not copied with anything generation specific in the filename. The builder assumes the file is CA-addressed by parent store path, to avoid redundant copies. However, it also assumes it can make this path by taking basename of the specified file. This is file for initrd/kernel since they are second level in the derivation. However, this can't be assumed, and/or isn't true for the DTB. I would just send a PR but I can't think of a super easy/clean way to do this. The current approach (of assuming the depth of the file) is not great, IMO, but nicely avoids hashing the individual files, etc. Using a regex or chopping the prefix is not viable. The only idea I have -- use a regex to just capture the first instead of a b32 looking hash and hope that's good enough. I can do this depending on vibes. Steps to reproduce the behavior: two generation bug in older gen dtb from wherever it gets put (esp mount point or xbootldr), just to prove -install, which re-creates files for all generations, oldest first boot, notice old dtb, realize it lacks hash, realize this is fundamentally problematic. cc: A clear and concise description of what you expected to happen. If applicable, add screenshots to help explain your problem. Add any other context about the problem here. <!-- 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]: