jiebi/CodeConvo huggingface dataset:
Change:
release announcement</link> for more information. </para> </listitem> <ins> <listitem> <para> <literal>PRETTY_NAME</literal> in <literal>/etc/os-release</literal> uses the release now instead of full version to be more suitable for presentation to the user </para> </listitem> </ins> </itemizedlist> </section> </section>

Discussion:
Describe the bug The NixOS version number is very long. It's good to know from which nixpkgs commit it was built. Needed for issues here. But a user don't have to know the exact version. One rather uses the release version like used in the when talking about it. The long version also leads to UI breaking. For example in the Pantheon settings about panel: ! That looks broken. I would like to have just "NixOS 19.09 (Loris)" there. I propose to use the release version in end-user facing places and the full version which includes the revision for developers and debug tools. That would mean: nixos version = "19.09" nixos full version = "19.09.1320." Use nixos version in: /etc/os-release lsb-release script Use full nixos version in: nixos-version nix-info What do you think?
Maybe just shorten the field in ?
Yes, that would be enough. is the right place: A pretty operating system name in a format suitable for presentation to the user. May or may not contain a release code name or OS version of some kind, as suitable. If not set, defaults to "PRETTYNAME="Linux"". Example: "PRETTYNAME="Fedora 17 (Beefy Miracle)"". Our lsb-release script uses that too: That should improve Pantheon about panel, Mumble and Steam (and thereby Protondb).
Change:
"--set HSA_PATH ${rocm-runtime}" "--set ROCM_PATH $out" ]; <ins> # https://github.com/NixOS/nixpkgs/issues/305641 # Not needed when 3.29.2 is in unstable cmake' = cmake.overrideAttrs(old: rec { version = "3.29.2"; src = fetchurl { url = "https://cmake.org/files/v${lib.versions.majorMinor version}/cmake-${version}.tar.gz"; hash = "sha256-NttLaSaqt0G6bksuotmckZMiITIwi03IJNQSPLcwNS4="; }; }); </ins> in stdenv.mkDerivation (finalAttrs: { pname = "clr"; version = "5.7.1";

Discussion:
The build for a lot of ROCm components broke with , which updated CMake from 3.29.0 to 3.29.1, basically breaking all of ROCm. This commit was merged via and recently made its way from staging into unstable in the last few days. Steps to reproduce the behavior: The builds for a number of ROCm components now fail with error messages like the following: This is possible related to how ROCm uses of CMake incorrectly. See , , and I have posted about this issue on the CMake discourse to verify if this is considered a bug in CMake, as suggested by <!-- 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 first recommendation we got from CMake was updating to 3.29.2, which has already been merged to staging:
I was able to confirm that with that commit that updates CMake to 3.29.2 builds again. I will leave this issue open until the relevant changes make it into unstable.
is there an easy way to temporarily use the cmake version from staging in my configuration for a specific package, without using staging for every dependency of that package?
A workaround could be to apply this as patch:
One possible fix would be overriding the CMake version that is used inside of ROCm to update to the newer version, and merging that with a PR to master. The advantage of this compared to would be that we do not need to worry about the fix actually breaking the build once the version update lands (I have not tested that this happens, but I could imagine it does). It might be a good idea to do this by making the overridden version of a part of , and removing extra dependency on elsewhere in ROCm. Also ROCm 5.7 and 6.0 are both broken, so if we want to merge a fix before the CMake version update lands in unstable, we should fix both. I am not working on a fix for this, and I couldn't merge one, but I'm happy to review PRs.
Change:
<del> { callPackage, glib, libao, intltool, libmirage }: </del> <ins> { callPackage, glib, libao, intltool, libmirage, coreutils }: </ins> let pkg = import ./base.nix { version = "3.2.5"; pname = "cdemu-daemon";

Discussion:
There is no Dbus service file in the derivation outputs. This prevents from starting on demand. It works if it was started manually beforehand. Steps to reproduce the behavior: There should be a message about device slot 0 not loaded. But instead there is an error: This is a regression from at least NixOS 20.09 where this file was present. Apparently some defaults were changed since then.
Thanks for the report, I've also already wondered what broke ... I think what may have changed is that cdemu has stopped installing a service file. See Section 14 in Fortunately, it still provides , so it shouldn't be too hard to generate a service file on our own. From a quick glance, I see two ways: 1) rely on the nixos module, to have dbus activate a systemd service, as in the example 2) come up with a dbus - only solution, similar as before
Yes, according to its git history it was removed in cdemu-daemon 3.2.5. I believe this should be the most straightforward and flexible solution. Also, this is actually recommended by upstream.
Also an issue on my machine. !
Experiencing this as well. New to NixOS, so I'm not sure how much I could contribute to resolve this.
Just in case somebody stumbles upon this, to whom the workaround is not apparent, before a contributor got around to fixing this: After running in a separate terminal, you can use CDEmu normally.
I just got this problem too, tried starting cdemu-deamon manually, but then got: Not really sure what to try next :sweat:
that looks like you don't have the cdemu kernel module loaded. Do you have  and yourself to the group? Also check
Hey! Yes, I have and And: Not sure what this tells me though? Does that look OK?
Interesting. shows the module to be loaded, that's fine. So the command already shows you as part of and also is owned by group cdrom? And you still get permission denied?
should be owned by group and_ also have group permissions .
would appreciate if anybody could test the PR. there are issues with the tray icon not showing, due to xdg resources, but the dbus service should be functional now.

I have this exact issue on the Steam Deck...
Aight, so I thought I might chime into this issue for all those poor souls that have problems with this exact problem: And when you check with : Notice that is empty when it should be mapped to: Solution that worked for me: Check if you have any .conf files in that block , , , , modules from loading. This is common problem nowadays, because of kernel hardening and stuff, so people/distro packagers could disable those for this reason. Sorry for necrobumping, but this is the only github issue that somewhat references this error above.
Change:
{ stdenv, buildPythonPackage, fetchPypi , pytest, pytestcov, pytestpep8, pytest_xdist , six, numpy, scipy, pyyaml, h5py <ins> , keras-applications, keras-preprocessing </ins> }: buildPythonPackage rec { pname = "Keras"; <del> version = "2.2.0"; </del> <ins> version = "2.2.2"; </ins> src = fetchPypi { inherit pname version; <del> sha256 = "5b8499d157af217f1a5ee33589e774127ebc3e266c833c22cb5afbb0ed1734bf"; </del> <ins> sha256 = "468d98da104ec5c3dbb10c2ef6bb345ab154f6ca2d722d4c250ef4d6105de17a"; </ins> }; checkInputs = [

Discussion:
seem the Keras preprocessing routines were split off into their own package in 2.0. The Nix version was then updated to 2.0 in commit without verifying that it worked. This broke the package as it is now necessary to also package the new package and provide it as a dependency to
We do semi-automatic batch upgrades to the Python packages because not all of them are well maintained. This also means we cannot fix all breakage that occurs during these batch upgrades, however we try to fix as much as possible. If you have the time, please package the new dependency and make a pull request.
Thanks for taking care of that.
Change:
mkdir -p $out/{bin,include,lib,${executable}-c} cp -R {include,lib_pypy,lib-python,${executable}-c} $out/${executable}-c <del> cp lib${executable}-c.so $out/lib/ </del> <ins> cp lib${executable}-c${stdenv.hostPlatform.extensions.sharedLibrary} $out/lib/ </ins> ln -s $out/${executable}-c/${executable}-c $out/bin/${executable} # other packages expect to find stuff according to libPrefix ln -s $out/${executable}/include $out/include/${libPrefix} ln -s $out/${executable}-c/lib-python/${if isPy3k then "3" else pythonVersion} $out/lib/${libPrefix} <ins> ${stdenv.lib.optionalString stdenv.isDarwin '' install_name_tool -change @rpath/libpypy${optionalString isPy3k "3"}-c.dylib $out/lib/libpypy${optionalString isPy3k "3"}-c.dylib $out/bin/${executable} ''} </ins> # verify cffi modules $out/bin/${executable} -c ${if isPy3k then "'import tkinter;import sqlite3;import curses;import lzma'" else "'import Tkinter;import sqlite3;import curses'"}

Discussion:
Describe the bug pypy3 cannot be installed using on macOS. The package fails to build from source. To Reproduce Steps to reproduce the behavior: latest macOS (Catalina 10.15, but same error on previous version) latest (master) to home.packages ( from binary cache does work/does not have this problem) Expected behavior pypy3 package builds successfully (including all needed deps). Output/Errors Error encountered during compilation: Metadata
I am also not sure why from binary cache is not used (for pypy's dependency, it is compiled from source), but that could be my misunderstanding of normal behaviour -- I'm new!
Change:
'' + bin.cleanBrokenLinks ; <del> } </del> <ins> }).overrideAttrs (_: { allowSubstitutes = true; }) </ins> # TODO: make TeX fonts visible by fontconfig: it should be enough to install an appropriate file #       similarly, deal with xe(la)tex font visibility?

Discussion:
Describe the bug A clear and concise description of what the bug is. Since I've to my system's , it's compiling some tex related packages manually whenever I'm updating my system. Why is it not cached on hydra? Biber is broken for me with anything other than . Notify maintainers Metadata Please run and paste the result. Maintainer information:
Not fixed. edit: nevermind, there was an unrelated regression for
I can't tell personally because I use the stable 20.03 branch of nix and the fixes went into master. looking forward to nix 20.09 fixing it!
I marked this as stale due to inactivity. &rarr;
For some reason the issue still persists, I see tons of tex related packages being rebuilt at updates. From a feeling though, the issue has lessened.
Just had another idea...
Change:
mkdir -p $out/share/pixmaps cp $out/lib/vscode/resources/app/resources/linux/code.png $out/share/pixmaps/code.png <ins> # Override the previously determined VSCODE_PATH with the one we know to be correct sed -i "/ELECTRON=/iVSCODE_PATH='$out/lib/vscode'" $out/bin/code grep -q "VSCODE_PATH='$out/lib/vscode'" $out/bin/code # check if sed succeeded </ins> ''; preFixup = lib.optionalString (system == "i686-linux" || system == "x86_64-linux") ''

Discussion:
I have the latest version of VSCode installed ( channel). I tried running in my shells (zsh, bash, sh) and all of them failed with this error: My version: . However, runs fine. What could possibly be interfering?
cc
I've ran into this before, and I thought I had fixed it: . This fix didn't actually work it turns out, but the gist of it is correct: you want to set to a predetermined value instead of "deducing" it.
Unable to replicate this, my output derivation is .
strange, I ran and my vscode version remains . if this isn't reproducible, any pointers to restoring the environment's integrity?
Yeah, it seems to be kinda finicky, it also randomly fixed itself again on my device. However, I still think this is a problem we should solve. I opened , could you check if that fixes your problem?
This feels like a recurring design issue in Nix from personal experience. A similar situation for me is occurring with my LaTeX path interacting with Anki in . Are there any broader discussions about conflicts between environments being at odds with reproducibility and declarativeness? What's the heuristic for solving issues where packages launch perfectly fine in , and fail in ? thanks, will try soon--probably tomorrow.
In terms of conflicts, could be used, though it would be better to figure out which packages are causing the conflict before adding the attribute randomly.
Change:
]; # autoreconfHook does not work <del> nativeBuildInputs = [ autoconf automake libtool ]; </del> <ins> nativeBuildInputs = [ autoconf automake libtool ]; </ins> enableParallelBuilding = true; <ins> postPatch = '' substituteInPlace bootstrap --replace-fail glibtoolize libtoolize ''; </ins> preConfigure = '' ./bootstrap '';

Discussion:
Steps to reproduce the behavior: quickfix The package does not build on macos (darwin) Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Change:
inherit (beam.packages.erlang) erlang-ls erlfmt elvis-erlang rebar rebar3 rebar3WithPlugins <del> fetchHex beamPackages; inherit (beam.packages.erlang_21) lfe lfe_1_3; </del> <ins> fetchHex beamPackages lfe lfe_2_1; </ins> gnudatalanguage = callPackage ../development/interpreters/gnudatalanguage { inherit (llvmPackages) openmp;

Discussion:
Package name: lfe (Lisp Flavored Erlang) Latest released version: 2.1.1 <!-- Search your package here: --- Current version on the unstable channel: 1.3 Current version on the stable/release channel: 1.3 <!-- 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.
Please test. Tracking: But you can use nixpkgs-review too. At nixpkgs git directory: -
Change:
import subprocess import sys import toml <ins> from urllib.parse import urlparse </ins> import yaml import dag <ins> # This should match the behavior of the default unpackPhase. # See https://github.com/NixOS/nixpkgs/blob/59fa082abdbf462515facc8800d517f5728c909d/pkgs/stdenv/generic/setup.sh#L1044 archive_extensions = [ # xz extensions ".tar.xz", ".tar.lzma", ".txz", # *.tar or *.tar.* ".tar", ".tar.Z", ".tar.bz2", ".tar.gz", # Other tar extensions ".tgz", ".tbz2", ".tbz", ".zip" ] </ins> dependencies_path = Path(sys.argv[1]) closure_yaml_path = Path(sys.argv[2]) julia_path = Path(sys.argv[3])

Discussion:
I'm trying out the new Julia framework, but the following command fails Am I doing it wrong? If I only ask for the "Plots" package it works. <!-- 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]:
Are you doing any overrides?
Hmm, this is arising from a Julia artifact in here: The artifact URL is given as The Nix code we generate as part of the Julia machinery looks like this: The URL seems to be valid. The problem seems to be that it doesn't end in . So the Nix derivation downloads it, but doesn't unzip or untar it, which is why we run into a problem in the . I'm thinking we need to stick a into the call. I'll try this in a bit.
This works for this example if I add a name ending with . The problem, of course, is that Julia artifacts are not necessarily tarballs, but can be arbitrary files. I think what we need to do is parse the artifact URL and determine if it's an archive that the default knows how to handle. If so, we keep using the current derivation, and otherwise replace it with a plain call. Per the , the supported archive extensions are: ? The manual may not perfectly match the actual code; the relevant part of the default is .
No
Unfortunately I've found another failing case, unrelated to the previous (it fails with PR ) It fails to build , likely for the reason I reported in PR
Hi should I open another issue for ?
Or just reopen this one and use it as a tracker for future issues?
Let's reopen this one for the known issues.
This problem is due to the upstream issue where it can't precompile in a headless environment, as discussed originally in . It's also mentioned in the . The workaround is to use . Maybe we could open a Nixpkgs issue to track the upstream issue, but I view this primarily as an upstream problem.
You are right, I forgot about the workaround. Disabling pre-compilation works indeed.
Change:
<del> { lib, stdenv, fetchFromGitHub, cmake, ninja, libuuid, libossp_uuid, gtest }: </del> <ins> { lib, stdenv, fetchFromGitHub, cmake, ninja, automaticcomponenttoolkit , pkg-config, libzip, gtest, openssl, libuuid, libossp_uuid }: </ins> stdenv.mkDerivation rec { pname = "lib3mf"; <del> version = "2.0.0"; </del> <ins> version = "2.1.1"; </ins> src = fetchFromGitHub { owner = "3MFConsortium"; repo = pname; rev = "v${version}"; <del> sha256 = "0w4d9zvl95g1x3r5nyd6cr27g6fwhhwaivh8a5r1xs5l6if21x19"; </del> <ins> sha256 = "1417xlxc1y5jnipixhbjfrrjgkrprbbraj8647sff9051m3hpxc3"; </ins> }; <del> nativeBuildInputs = [ cmake ninja ]; </del> <ins> nativeBuildInputs = [ cmake ninja pkg-config ]; </ins> <del> buildInputs = if stdenv.isDarwin then [ libossp_uuid ] else [ libuuid ]; </del> <ins> outputs = [ "out" "dev" ]; </ins> <del> postPatch = '' rmdir Tests/googletest ln -s ${gtest.src} Tests/googletest </del> <ins> cmakeFlags = [ "-DCMAKE_INSTALL_INCLUDEDIR=${placeholder "out"}/include/lib3mf" "-DUSE_INCLUDED_ZLIB=OFF" "-DUSE_INCLUDED_LIBZIP=OFF" "-DUSE_INCLUDED_GTEST=OFF" "-DUSE_INCLUDED_SSL=OFF" ]; buildInputs = [ libzip gtest openssl ] ++ (if stdenv.isDarwin then [ libossp_uuid ] else [ libuuid ]); postPatch = '' </ins> # fix libdir=''${exec_prefix}/@CMAKE_INSTALL_LIBDIR@ <del> sed -i 's,=''${(exec_)?prefix}/,=,' lib3MF.pc.in </del> <ins> sed -i 's,=''${(exec_)?prefix}/,=,' lib3mf.pc.in # replace bundled binaries for i in AutomaticComponentToolkit/bin/act.*; do ln -sf ${automaticcomponenttoolkit}/bin/act $i done </ins> ''; meta = with lib; {

Discussion:
, CVSSv3=8.1 (nixos-unstable) Scanned versions: nixos-unstable: . Cc
Change:
--arg nixpkgsPath "./."  --argstr revision ${nixpkgs.rev or "master"}  --argstr libsetsJSON ${lib.escapeShellArg (builtins.toJSON libsets)}  <ins> --store $(mktemp -d)  </ins> > locations.json function docgen {

Discussion:
Steps to reproduce the behavior: (nixpkgs is currently at ) Seems to be a sandbox issue: Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
I don't reproduce this, either with the sandbox option or without. I suspect this has nothing to do with and something to do with your Nix installation. I tried on with both Lix 2.90 and Nix 2.18, and on with Nix 2.24.
Huh. It's been an issue for the last several days, originally noted when I was building the manual (and an opener script) like so: Searching for issues is how I discovered your new package (thank you) but building the new package gives me the same error, so I assumed the issue was somewhere in the docs -- When I omit these from my configuration, it builds normally. I've tried removing and rebuilding and have also tried rebooting, and I get the same error regardless. I'm on nix 2.18.5. I'm sure you've already done / considered this, but: Is your sandbox set to or just ? Did you happen to build with the sandbox off first (because then it will succeed on successive attempts due to cache unless you )
Looks like it may be actually the attribute:
Still getting this with current master. Could anyone from confirm whether this is a "me" issue? (You'll only need the if you've built it before.) With sandbox enabled:
Disable automatic store optimization in .
Thanks for your thoughts -- I assume this builds without error for you? I disabled automatic store optimization last week in trying to troubleshoot this issue, and tried ing and re-running. I did enable the timer-based optimization however, since the thread seemed to suggest people were not having issues with that route. I'll try disabling that as well I guess?
I'm seeing the same error with the sandbox enabled ( is disabled)
Thank you -- glad to know it's not just me.
Same issue on my wife's machine: Her machine does have : Mine does not: did you ever have enabled? Just wondering because I used to (before last week), so wondering if there is some kind of residual impurity after disabling it that gives me this persisting error, or if it's something else entirely.

Contextual issue for comment:
Also, my error seems a little different: Abbreviated from the linked issue: vs above:
I don't think so, because enabling it breaks builds for me (linked issue above).
I have disabled and am deleting that directory completely and it still gives the same error. I know you have your hands full with a million projects, but if you or or any of the darwin magicians have any ideas I'd appreciate it.
It’s going to be something to do with the docs generation code running a nested Nix that’s trying to look at the host store for some reason, I think.
Yep: I’m guessing you have the sandbox on, right? (edit: yep, you do.) I’m not sure why it’s looking at the store, but perhaps would help.
Wow, you are amazing. Thank you.
Change:
<ins> { config, pkgs, lib, ... }: let cfg = config.programs.wayland.miracle-wm; in { options.programs.wayland.miracle-wm = { enable = lib.mkEnableOption '' miracle-wm, a tiling Mir based Wayland compositor. You can manually launch miracle-wm by executing "exec miracle-wm" on a TTY, or launch it from a display manager. Consult the USERGUIDE.md at <https://github.com/mattkae/miracle-wm> for information on how to use & configure it ''; }; config = lib.mkIf cfg.enable ( lib.mkMerge [ { environment = { systemPackages = [ pkgs.miracle-wm ]; }; # To make the miracle-wm session available if a display manager like SDDM is enabled: services.displayManager.sessionPackages = [ pkgs.miracle-wm ]; } (import ./wayland-session.nix { inherit lib pkgs; # Hardcoded path in Mir, not really possible to disable enableXWayland = true; # No portal support yet: https://github.com/mattkae/miracle-wm/issues/164 enableWlrPortal = false; }) ] ); meta.maintainers = with lib.maintainers; [ OPNA2608 ]; } </ins>

Discussion:
Project description A Mir-based Wayland compositor like , but tiling instead of floating. ! More Mir testers, more better. Requesting this from myself so I don't forget about this. Needs a very new Mir, newer than we currently provide (depends on ). Metadata homepage URL: source URL: license: gpl3+ platforms: linux Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Change:
url = "https://github.com/xbmc/FFmpeg/archive/3.1.6-${rel}.tar.gz"; sha256 = "14jicb26s20nr3qmfpazszpc892yjwjn81zbsb8szy3a5xs19y81"; }; <ins> # Usage of kodi fork of libdvdnav and libdvdread is necessary for functional dvd playback: libdvdnav_src = fetchurl { url = "https://github.com/xbmc/libdvdnav/archive/981488f.tar.gz"; sha256 = "312b3d15bc448d24e92f4b2e7248409525eccc4e75776026d805478e51c5ef3d"; }; libdvdread_src = fetchurl { url = "https://github.com/xbmc/libdvdread/archive/17d99db.tar.gz"; sha256 = "e7179b2054163652596a56301c9f025515cb08c6d6310b42b897c3ad11c0199b"; }; </ins> in stdenv.mkDerivation rec { name = "kodi-${version}"; version = "17.1";

Discussion:
Kodi has forked libdvdnav and other libs (libdvdcss and libdvdread). It needs to be built against those fork (eg.: ) otherwise functionalities like reading dvd fail. Try to play a dvd with kodi. Observe in the logs Will try to submit a patch later this week. System: NixOS: 17-03