jiebi/CodeConvo huggingface dataset:
Change:
<ins> { lib , stdenv , fetchFromGitHub , cmake , pkg-config , libGL , libxkbcommon , hyprlang , pam , wayland , wayland-protocols , cairo , pango , libdrm , mesa , nix-update-script , expat , libXdmcp , pcre2 , util-linux , libselinux , libsepol , pcre , fribidi , libthai , libdatrie }: stdenv.mkDerivation (finalAttrs: { pname = "hyprlock"; version = "0.1.0"; src = fetchFromGitHub { owner = "hyprwm"; repo = "hyprlock"; rev = "v${finalAttrs.version}"; hash = "sha256-SX3VRcewkqeAIY6ptgfk9+C6KB9aCEUOacb2pKl3kO0="; }; strictDeps = true; nativeBuildInputs = [ cmake pkg-config ]; buildInputs = [ cairo expat fribidi hyprlang libdatrie libdrm libGL libselinux libsepol libthai libXdmcp libxkbcommon mesa pam pango pcre pcre2 util-linux wayland wayland-protocols ]; passthru.updateScript = nix-update-script { }; meta = { description = "Hyprland's GPU-accelerated screen locking utility"; homepage = "https://github.com/hyprwm/hyprlock"; license = lib.licenses.bsd3; maintainers = with lib.maintainers; [ eclairevoyant ]; mainProgram = "hyprlock"; platforms = [ "aarch64-linux" "x86_64-linux" ]; }; }) </ins>

Discussion:
Project description <!-- Describe the project a little: --Hyprland lock screen utility Metadata homepage URL: source URL: license: BSD3 platforms: unix, linux, darwin, ... Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
The repository does already include a I'm using flakes and was able to get this up and running by adding hyprlock as a flake input, using the home-manager import mechanism, and then setting . In other words, my file has: Then I've got a NixOS system defined: That was enough for to work.
oh nice, thanks !
This was closed as completed but hyprlock is not available via pkgs, maybe I am misunderstanding but I believe OP was asking for hyprlock to be available via pkgs.
Hey! It is available on :
Change:
}: let <del> inherit (python2.pkgs) buildPythonApplication wxPython numpy; in buildPythonApplication { </del> <ins> inherit (python2.pkgs) buildPythonApplication wxPython numpy dbus-python; in buildPythonApplication rec { </ins> pname = "displaycal"; <del> version = "3.5.0.0"; </del> <ins> version = "3.8.9.3"; </ins> enableParallelBuilding = true; src = fetchurl { <del> url = "mirror://sourceforge/project/dispcalgui/release/3.5.0.0/DisplayCAL-3.5.0.0.tar.gz"; sha256 = "1j496sv8pbhby5hkkbp07k6bs3f7mb1l3dijmn2iga3kmix0fn5q"; </del> <ins> url = "mirror://sourceforge/project/dispcalgui/release/${version}/DisplayCAL-${version}.tar.gz"; sha256 = "1sivi4q7sqsrc95qg5gh37bsm2761md4mpl89hflzwk6kyyxyd3w"; </ins> }; propagatedBuildInputs = [

Discussion:
Describe the bug DisplayCal, an application for calibrating one's monitor, is not functional in 20.03, though it builds. To Reproduce Steps to reproduce the behavior: displaycal in a calibration device the "Profile and Calibrate" button near the bottom of the GUI can not find the package and refuses to continue. Expected behavior DisplayCal should move to the next screen and start the calibration process. Additional context The package builds, but does not function. The 3.5 version that is packaged is pretty far out of date, so I've started to try and update the package , but the compilation fails. I have a calibration device and am looking for help to get this working. Notify maintainers
sampson in IRC suggested the following patch, but the build still fails at the same point for me: The error when building the package is:
I can get the package to build now, but it doesn't run:
It says , i guess you have to add to the , like you have done with .
you are correct. Now DisplayCal builds, launches, and finds my calibraiton devices. I'll have to test this on my full NixOS install, instead of my Ubuntu machine with nixpkg. Thank you for your help!
Change:
<del> { newScope, stdenv, cmake, libxml2, python2, isl, fetchurl, overrideCC, wrapCC, ccWrapperFun }: </del> <ins> { newScope, stdenv, libstdcxxHook, cmake, libxml2, python2, isl, fetchurl , overrideCC, wrapCC, ccWrapperFun, darwin }: </ins> let callPackage = newScope (self // { inherit stdenv cmake libxml2 python2 isl version fetch; });

Discussion:
In Nixpkgs 17.09, 3.9 cannot find libstdc++ headers: This does work correctly with Clang 4.0 in 17.09, or Clang 3.9 in 17.03. Setting shows that the cc-wrapper is not adding the appropriate flags pointing to libstdc++ in gcc. See above. System: NixOS 17.03 Nix version: 1.12pre Nixpkgs version: 17.09beta285. Sandboxing enabled: no
According to git-bisect, one of the following commits is causing the issue (all by
Hmm, was supposed to have fixed this, but I guess only fixed 4.0. any idea?
Really thought I already applied those changes to the other versions, must have forgotten to push or something.
Ah I see now---I should have noticed when reviewing that. While we're at it, maybe we should inject it in cc-wrapper instead of stdenv? This mirrors and keeps slimmer.
Change:
creating the image in the first place. As a result it allows users to edit and rebuild the live-system. </para> <ins> <para> On images where the installation media also becomes an installation target, copying over <literal>configuration.nix</literal> should be disabled by setting <literal>installer.cloneConfig</literal> to <literal>false</literal>. This is already done in <literal>sd-image.nix</literal>. </para> </ins> </section>

Discussion:
When downloading the aarch64 sdcard image, the provided there imports , which imports , which (among others) enables the nixos manual on tty8, force-enables the documentation, disabes sudo and udisks, disables sshd on bootup and enables automatic login as root without password. We probably want to provide a different in not importing installer-related things (or at least make it easy to disable them). Download the aarch64 sdcard image flash it to a raspberry pi3 edit (add for example) call wonder why it's not started cc
The idea here is that a using that would be identical from the first generation, since it's expected that a system is installed in-place. The end-user should as one would from the installation media. Though, I guess that shipping no configuration might be better in that optic; would not make it likely that users consider that line as being needed for their system to work. Probably, also, the motd should better explain that is already installed, merely disabled by default. That would be an improvement for the installer iso too. Thoughts?
I agree not shipping the configuration in that case might be better, if is sufficient. Is it for aarch64 already, and generates all the magic options properly, like extlinux etc.? Motd can be a bit more helpful, yeah. Also, we should probably add the information about the manual on tty8, if we don't already do.
. The just as . Looks like we're not far off :).

1: 2: 3: Create virtual machine and run with nixos iso. SSH Daemon doesn't work. It's loaded, but not active. 4: But it's working with ... and show this warnings: System: (Hummingbird) Nix version: nix-env (Nix) 1.11.11 Nixpkgs version: Sandboxing enabled: build-use-sandbox = false
And why is it wrong? It's even documented: (7.)
He provided , so it should work without setting a root password. We even have doing exactly that, but without the installer CD , so I'm guessing the real issue here could be the latter.
The actual problem here is , so adding the following line in your configuration should fix that: For the installer image it makes sense to remove from , because it allows the user to optionally enable at runtime via .
To be clear, I meant the fact that you have to start sshd manually on an installation system. I can see nothing wrong about that. (Perhaps I misunderstood.)
No, I was wrong about that, I only read point 7 regarding setting the root passwd.
This example should work:
The warnings when using can be ignored. I would say it is not a bug, but intended behavior.
, maybe not a bug, but an error.
, thank you. work very well without any problems.
Close as answered?
I don't know. is it fixed in documentation?
Probably not.
works flawlessly.
A fix for this is in progress at .
Change:
buildPythonPackage rec { pname = "chromadb"; <del> version = "0.5.4"; </del> <ins> version = "0.5.5"; </ins> pyproject = true; disabled = pythonOlder "3.9";

Discussion:
Steps to reproduce the behavior: the chromadb python package for python310. [1/7/9 built] building python3.10-chromadb-0.5.0 (pytestCheckPhase): chromadb/test/auth/testbasicauth[1/7/9 built] building python3.10-chromadb-0.5.0 (pytestCheckPhase): chromadb/test/aut[1/7/9 built] building python3.10-chromadb-0.5.0 (pytestCheckPhase): ... [ 4%] [1/7/9 built] building python3.10-chromadb-0.5.0 (pytestCheckPhase): ... [ 4%] [1/7/9 built] building python3.10-chromadb-0.5.0 (pytestCheckPhase): ... [ 4%] This is not the complete log but it is all that is visible in my terminal since only keeps the latest however many lines. The build reaches this test at 4% every time and then stalls there. I was able to fix the issue by adding an overlay to disable pytestCheckPhase, but this is obviously a workaround. <!-- 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]:
The are flaky. I will ship an update later.
Change:
+#include <sys/stat.h> +#include <sys/socket.h> +#include <sys/un.h> <del> +#include <sys/fcntl.h> </del> +#include <netinet/in.h> +#include <stdlib.h> <ins> +#include <fcntl.h> </ins> +#include <errno.h> +#include <unistd.h> +#include <string.h>

Discussion:
Describe the bug sysklogd fails to build when built against musl-libc To Reproduce Steps to reproduce the behavior: Expected behavior Package should build. Notify maintainers no maintainers, because apparently this is ancient. Metadata Maintainer information:
Change:
<ins> diff --git a/portablemc/standard.py b/portablemc/standard.py index f59c55d..0f017e1 100644 --- a/portablemc/standard.py +++ b/portablemc/standard.py @@ -843,6 +843,8 @@ class Version: if jvm_major_version is not None and not isinstance(jvm_major_version, int): raise ValueError("metadata: /javaVersion/majorVersion must be an integer") +        return self._resolve_builtin_jvm(watcher, JvmNotFoundError.UNSUPPORTED_ARCH, jvm_major_version) + if platform.system() == "Linux" and platform.libc_ver()[0] != "glibc": return self._resolve_builtin_jvm(watcher, JvmNotFoundError.UNSUPPORTED_LIBC, jvm_major_version) @@ -926,31 +928,10 @@ class Version: builtin_path = shutil.which(jvm_bin_filename) if builtin_path is None: raise JvmNotFoundError(reason) - -        try: - -            # Get version of the JVM. -            process = Popen([builtin_path, "-version"], bufsize=1, stdout=PIPE, stderr=STDOUT, universal_newlines=True) -            stdout, _stderr = process.communicate(timeout=1) - -            version_start = stdout.index(f"1.{major_version}" if major_version <= 8 else str(major_version)) -            version = None - -            # Parse version by getting all character that are numeric or '.'. -            for i, ch in enumerate(stdout[version_start:]): -                if not ch.isnumeric() and ch not in (".", "_"): -                    version = stdout[version_start:i] -                    break - -            if version is None: -                raise ValueError() - -        except (TimeoutExpired, ValueError): -            raise JvmNotFoundError(JvmNotFoundError.BUILTIN_INVALID_VERSION) self._jvm_path = Path(builtin_path) -        self._jvm_version = version -        watcher.handle(JvmLoadedEvent(version, JvmLoadedEvent.BUILTIN)) +        self._jvm_version = "nixpkgs" +        watcher.handle(JvmLoadedEvent("nixpkgs", JvmLoadedEvent.BUILTIN)) def _download(self, watcher: Watcher) -> None: </ins>

Discussion:
Project description A fast, reliable and cross-platform command-line Minecraft launcher Metadata homepage URL: source URL: license: GPL-3.0 platforms: linux, windows (I can't test darwin) Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Change:
<ins> { lib, stdenv, buildGoModule, fetchFromGitHub }: buildGoModule rec { pname = "phlare"; version = "0.3.0"; src = fetchFromGitHub { rev = "v${version}"; owner = "grafana"; repo = "phlare"; sha256 = "sha256-z1PT5chkpHQJPziY7bGf6W1X5uezL6E2GUV6w/NlyFk="; }; proxyVendor = true; vendorSha256 = "sha256-KJbh+M9jYxUW9akVBHZoB/mtOHWpMPtlwIgC9fu+NYY="; ldflags = let prefix = "github.com/grafana/phlare/pkg/util/build"; in [ "-s" "-w" # https://github.com/grafana/phlare/blob/v0.3.0/Makefile#L32 "-X ${prefix}.Version=${version}" "-X ${prefix}.Branch=v${version}" "-X ${prefix}.Revision=v${version}" "-X ${prefix}.BuildUser=nix" "-X ${prefix}.BuildDate=1980-01-01T00:00:00Z" ]; subPackages = [ "cmd/phlare" "cmd/profilecli" ]; meta = with lib; { description = "Grafana Phlare is an open source database that provides fast, scalable, highly available, and efficient storage and querying of profiling data."; license = licenses.agpl3; homepage = "https://grafana.com/oss/phlare"; maintainers = with maintainers; [ cathalmullan ]; }; } </ins>

Discussion:
Project description is an open source database that provides fast, scalable, highly available, and efficient storage and querying of profiling data. Metadata homepage URL: source URL: license: AGPL-3.0 platforms: unix
Change:
# since rustc 1.42 the "proc_macro" crate is part of the default crate prelude # https://github.com/rust-lang/cargo/commit/4d64eb99a4#diff-7f98585dbf9d30aa100c8318e2c77e79R1021-R1022 ++ lib.optional (lib.elem "proc-macro" crateType) "--extern proc_macro" <del> ++ lib.optional (stdenv.hostPlatform.linker == "lld") # Needed when building for targets that use lld. e.g. 'wasm32-unknown-unknown' </del> <ins> ++ lib.optional (stdenv.hostPlatform.linker == "lld" && rustc ? llvmPackages.lld) # Needed when building for targets that use lld. e.g. 'wasm32-unknown-unknown' </ins> "-C linker=${rustc.llvmPackages.lld}/bin/lld" ++ lib.optional (stdenv.hasCC && stdenv.hostPlatform.linker != "lld") "-C linker=${stdenv.cc}/bin/${stdenv.cc.targetPrefix}cc"

Discussion:
I'm running an issue with overriding the rust toolchain since , I pass the following to crate2nix: to set the toolchain when building something, since I don't want to override the toolchain globally. But after this PR it doesn't work because it uses the toolchain in instead of the one I'm passing in. Now I don't really know how to override the rust toolchain to the version I want. is a nightly version I got from This problem is caused by this optimization: Another issue is that the attribute is missing in rust-overlay:
I'm having this issue as well. I've overridden my input to my flake to as a workaround for now.
Hi, sorry for the delay, I'm back home now from "holiday". Can any of you give me a minimal flake that reproduces the issue so I can experiment and find the best way to fix it?
I'm also hitting this. I don't have a minimal flake but I can at least offer the error message which seems to be missing from the OP.
Let me know if this fixes it.
unfortunately it does not, because it still defaults to for the rustc compiler. I've created a reproduction here: As you can see in I'm overriding rustc and cargo to the specific nightly version I want, but when I run I get the following output: This is the rustc version that's current in nixpkgs, not the nightly I specified. Thanks a lot for looking into this
One problem with your reproducer is that it uses the for which takes an arg called not . I think that still wouldn't have solved it. I made some changes in the PR that would allow passing a custom toolchain via the but also using . I did some refactoring to get rid of the and variables.
Change:
meta = with lib; { description = "Tools for maintaining UEFI signature databases"; homepage    = "http://jk.ozlabs.org/docs/sbkeysync-maintaing-uefi-key-databases"; <del> maintainers = [ maintainers.tstrobel ]; </del> <ins> maintainers = with maintainers; [ hmenke tstrobel ]; </ins> platforms   = [ "x86_64-linux" ]; # Broken on i686 license     = licenses.gpl3; };

Discussion:
The systemd-boot image built in nixpkgs has gaps in the section table. This leads to signature verification failure with some UEFI Secure Boot implementations (e.g. Dell XPS 13 9310) Using NixOS 22.05 @ Using some old version from NixOS 21.11 that I still have in the store: N/A Allegedly something like this was fixed in systemd upstream and the commit is present in v250.4 but for some reason it still appears and Secure Boot fails. <!-- 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. system: host os: multi-user?: sandbox: version: nixpkgs:
Relevant:
This commit might be the culprit: I will try confirm this, but since it requires rebuilding systemd, it'll take a while.
It's more likely a problem of sbsigntools:
Does your hardware still correctly validate the signature with this patch applied?
Yes, signature verification works with this patch (and only with this patch). Hardware is Dell XPS 13 9310. See also
Change:
nodes.machine = { config, pkgs, ... }: { boot.initrd.systemd.enable = true; <del> boot.initrd.availableKernelModules = [ "overlay" ]; </del> virtualisation.fileSystems = { "/initrd-overlay" = {

Discussion:
systemd doesn't respect the option for file systems. Usually this is ok because systemd will mount file systems in the correct topological ordering. The option is useful because it allows you to express dependencies on e.g. the file systems that an FS's lower/upper/work directories exist on. This test should hang forever. Instead, it exits cleanly. The service never exits, so is never mounted, and therefore should never be mounted. So the test should hang. This is also a problem for systemd stage 1, but it's worse because we also have to account for the prefix. We can fix this by adding options for every dependency, and prefixing for the systemd stage 1 file systems.
Do we even need the option? I don't think it's particularly useful. The overlay also shouldn't be a concern since anymore.
Well, currently literally only does anything in scripted stage 1. In stage 2 and in systemd stage 1, you have to use , which is what the stuff does. That's fine, but it's an incompatibility between scripted and systemd stage 1. So we need to either deprecate it or implement it, and it's really easy to implement (I just need to fixup ). It's a handy convenience for people I guess, though far from a necessary one.
Change:
let cfg = config.services.greetd; tty = "tty${toString cfg.vt}"; <del> settingsFormat = pkgs.formats.toml {}; </del> <ins> settingsFormat = pkgs.formats.toml { }; </ins> in { options.services.greetd = {

Discussion:
requires in order to store persistent information about the last session and user for the flags. remembers the session I picked. Basically the same as . My hotfix so far: <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --
Pinging as greetd module maintainer. I'm not sure about the best way to fix this. Maybe we can add to the systemd unit of the greed module?
Change:
}; }; }; <ins> moonscript = buildLuarocksPackage { pname = "moonscript"; version = "0.5.0-1"; src = fetchurl { url    = https://raw.githubusercontent.com/rocks-moonscript-org/moonrocks-mirror/master/moonscript-0.5.0-1.src.rock; sha256 = "09vv3ayzg94bjnzv5fw50r683ma0x3lb7sym297145zig9aqb9q9"; }; disabled = (luaOlder "5.1"); propagatedBuildInputs = [ lua lpeg alt-getopt luafilesystem ]; meta = with stdenv.lib; { homepage = "http://moonscript.org"; description = "A programmer friendly language that compiles to Lua"; maintainers = with maintainers; [ arobyn ]; license = { fullName = "MIT"; }; }; }; </ins> nvim-client = buildLuarocksPackage { pname = "nvim-client"; version = "0.2.0-1";

Discussion:
In the process of trying to install pgmoon, I discovered than moonc wasn't available. Indeed, I can't find any reference in nixpkgs to except for an emacs mode. I can probably package this up, but I'm shocked to find that it's not already available; it's fairly obscure, but Nix has pretty good coverage. So I'll check to see if I'm just missing it (or if anyone has a nix expression for it handy) before spending the effort on it. Please run and paste the results. Odd....
Change:
openssh_gssapi = common rec { pname = "openssh-with-gssapi"; <del> version = "8.4p1"; </del> <ins> version = "9.0p1"; </ins> extraDesc = " with GSSAPI support"; src = fetchurl { url = "mirror://openbsd/OpenSSH/portable/openssh-${version}.tar.gz"; <del> sha256 = "091b3pxdlj47scxx6kkf4agkx8c8sdacdxx8m1dw1cby80pd40as"; </del> <ins> sha256 = "12m2f9czvgmi7akp7xah6y7mrrpi280a3ksk47iwr7hy2q1475q3"; </ins> }; extraPatches = [ <del> ./ssh-keysign-8.4.patch # See https://github.com/openssh/openssh-portable/pull/206 ./ssh-copy-id-fix-eof.patch </del> <ins> ./ssh-keysign-8.5.patch </ins> (fetchpatch { name = "openssh-gssapi.patch"; <del> url = "https://salsa.debian.org/ssh-team/openssh/raw/debian/1%25${version}-2/debian/patches/gssapi.patch"; sha256 = "1z1ckzimlkm1dmr9f5fqjnjg28gsqcwx6xka0klak857548d2lp2"; </del> <ins> url = "https://salsa.debian.org/ssh-team/openssh/raw/debian/1%25${version}-1/debian/patches/gssapi.patch"; sha256 = "sha256-VG7+2dfu09nvHWuSAB6sLGMmjRCDCysl/9FR1WSF21k="; </ins> }) ]; extraNativeBuildInputs = [ autoreconfHook ]; <del> extraMeta.knownVulnerabilities = [ "CVE-2021-28041" "CVE-2021-41617" ]; </del> }; }

Discussion:
, CVSSv3=7.0 (nixos-21.05) CVSSv3=5.3 (nixos-21.05) sshd in OpenSSH 6.2 through 8.x before 8.8, when certain non-default configurations are used, allows privilege escalation because supplemental groups are not initialized as expected. Helper programs for AuthorizedKeysCommand and AuthorizedPrincipalsCommand may run with privileges associated with group memberships of the sshd process, if the configuration specifies running the command as a different user. OpenSSH through 8.7 allows remote attackers, who have a suspicion that a certain combination of username and public key is known to an SSH server, to test whether this suspicion is correct. This occurs because a challenge is sent only when that combination could be valid for a login session. Scanned versions: nixos-21.05: . Cc Cc