jiebi/CodeConvo huggingface dataset:
Change:
ln -s "$soname" "$libdir/$unversioned" fi fi <ins> # FIXME: libglxserver_nvidia does not have a soname, but must still be symlinked if [[ "$unversioned" == "libglxserver_nvidia.so" ]]; then ln -s "$libbase" "$libdir/$unversioned" fi </ins> done if [ -n "$bin" ]; then

Discussion:
When updating to nixos-unstable commit and rebooting, my GNOME desktop using Xorg was not rendering as I previously remembered it. For example, switching workspaces didn't show the sliding animation that one would expect to see, rather the workspace changed as if there was no animation at all. The xorg.xdriinfo utility reports that swrast was being used for direct rendering. Yes, I am ware the NVIDIA drivers do not use DRI, and xorg.xdriinfo normally reports as such when the NVIDIA drivers are fully functioning. Steps to reproduce the behavior: recent NVIDIA hardware present in your system, Update to , making sure your configuration installs and uses the nvidia-x11 driver as per the Nix OS wiki. to use an application that uses OpenGL for rendering. a 3D rendered desktop like GNOME or KDE should be sufficient. a nix shell with "nix-shell -p xorg.xdriinfo", and run xdriinfo to see that software rasterization is being used. OpenGL applications render correctly. After looking through the nixos-unstable branch commit history, I found commit . I created a local branch, reverted that commit, and updated my flake to use the newly created branch. After a reboot, GNOME behaves correctly, and xdriinfo reports no direct rendering support, as it should. Please run and paste the result.
I should probably add that I have the same problem both on production and latest driver versions.
Same for me, shows only an xorg-server process that doesn't use any resources.
Hello would you be able to link the commit that you reverted or share the commands that you used so that people with this issue can use up-to-date packages without the issue for the time being? Thanks for your help!
The commit I reverted is In order to prepare a branch with the reverted commit, this is what I did. sure you have a local clone of nixpkgs. out the nixos-unstable branch under a different local name to be used in your flake. "git checkout -b nixos-unstable-nvidia-revert origin/nixos-unstable" the above commit. "git revert ". your to point to the local copy of nixpkgs. "

= "git+file:///home/themuso/git/nixos/nixpkgs";" "nix flake lock --update-input nixpkgs" your flake.
Looking at the diff that created before it was merged, I suspect the root problem is this: The nvidia installer manifest includes that last symlink: So presumably the nvidia xorg driver cannot load the extension, thus breaking libGLX support and causing the problem you're seeing.
Hmm, I thought I unversioned symlinks for all dylibs.
Oh, I guess it doesn't have a soname. Wow, this is messed up.
Same for me, additionally blue and red color channels in are switched for me.
Please test
This fix works for me
Works for me too. Also the colors are normal once again. Thanks!
The fix works for me too. Thanks.
Change:
rmdir = "${coreutils}/bin/rmdir"; sudo = "${sudo}/bin/sudo"; }) <ins> # Fix swig not being able to find headers # https://github.com/NixOS/nixpkgs/pull/82362#issuecomment-597948461 (substituteAll { src = ./fix-swig-build.patch; cairoDev = "${cairo.dev}"; }) </ins> ]; # have it look for 4.7.2 instead of 4.7.1

Discussion:
Describe the bug On , fails to build because there are lots of compiler warnings and those are treated as errors. To Reproduce Steps to reproduce the behavior: out the branch of the repo's root directory, run Expected behavior Build succeeds and a symlink is created pointing to the build result. Observed behavior <details<summaryBuild fails with the following output (click to expand)</summary</detailsand with exit code . Screenshots n/a Additional context n/a Metadata system: host os: multi-user?: sandbox: version: channels(root): channels(das-g): nixpkgs: Maintainer information:
Change:
homepage = https://gnunet.org/; <del> license = stdenv.lib.licenses.gpl2Plus; </del> <ins> license = licenses.agpl3Plus; </ins> maintainers = with stdenv.lib.maintainers; [ ]; <del> platforms = stdenv.lib.platforms.gnu ++ stdenv.lib.platforms.linux; </del> <ins> platforms = platforms.gnu ++ platforms.linux; </ins> }; }

Discussion:
The release and git versions show gpl2+. It should be Affero GPL v3 or later. GNUnet is free software released under the GNU Affero General Public License (v3 or later).
Change:
] ++ lib.optional cfg.gamescopeSession.enable steam-gamescope; networking.firewall = lib.mkMerge [ <ins> (mkIf (cfg.remotePlay.openFirewall || cfg.localNetworkGameTransfers.openFirewall) { allowedUDPPorts = [ 27036 ]; # Peer discovery }) </ins> (mkIf cfg.remotePlay.openFirewall { allowedTCPPorts = [ 27036 ]; <del> allowedUDPPortRanges = [ { from = 27031; to = 27036; } ]; </del> <ins> allowedUDPPortRanges = [ { from = 27031; to = 27035; } ]; </ins> }) (mkIf cfg.dedicatedServer.openFirewall { allowedTCPPorts = [ 27015 ]; # SRCDS Rcon port allowedUDPPorts = [ 27015 ]; # Gameplay traffic }) <ins> (mkIf cfg.localNetworkGameTransfers.openFirewall { allowedTCPPorts = [ 27040 ]; # Data transfers }) </ins> ]; };

Discussion:
Valve has the ability to send game installs from one machine to another on the same network. This newer functionality requires port /TCP to be open on the host machine. describes the feature and mentions the port. Steps to reproduce the behavior: two computers running Steam. host Steam on NixOS needs to have the game fully downloaded. client Steam needs to be on the same network as the host. network transfer feature has to be enabled on both machines. downloading the game on the client that is downloaded on the host. tries to establish the transfer but never sends data. Either enabling Steam via should open this new port automatically or a new setting of = true; should be created to open the port.
I did some testing and it seems that it requires at least one other Steam TCP/UDP port to be open besides the /TCP, as just opening that port had the same transfer failure. I ended up opening ports: TCP , - UDP 3478, 4379-4380, - It works with those ports open. I will try to find which other port is required for it to function.
The following makes local transfers work on my machine: The port was taken from this Steam community comment:
Change:
binutils = binutils; }; <del> dive = callPackage ../development/tools/dive { }; </del> <ins> dive = callPackage ../development/tools/dive { buildGoModule = buildGo117Module; }; </ins> doclifter = callPackage ../development/tools/misc/doclifter { };

Discussion:
Dive now fails to build on darwin. This was working up until maybe a week ago. I poked at the vendor code that is failing. Looks like there some failed symbol references that look like: I saw some ramblings about libSystem updates, iirc. Is this related? Please run and paste the result.
Looks like dive doesn't build with go 1.18 yet. You can fix it with:
dive needs to update its vendoring, not reverting back to golang 1.17. Please don't pin programs needlessly to go 1.17 just because of this.
That is only true for aarch64-darwin, not any other platform.
Change:
PKG_CONFIG_PURPLE_PLUGINDIR = "${placeholder "out"}/lib/purple-2"; PKG_CONFIG_PURPLE_DATADIR = "${placeholder "out"}/share"; <del> installFlags = [ "DESTDIR=$(out)" ]; </del> <ins> PKG_CONFIG_PIDGIN_DATADIR = "${placeholder "out"}/share"; </ins> meta = with lib; { homepage = "https://github.com/hoehermann/libpurple-signald";

Discussion:
Steps to reproduce the behavior: purple-signal this as plugin for pidgin. Pidgin will not find it, as the output of the derivation are not as expected. First hydra build: Last hydra build: The generated output is within the wrong folder. It is expected to have folders and , but actually everything is within a subfolder . The expected structure can be compared with Got via: Please run and paste the result.
Change:
gfshare = callPackage ../tools/security/gfshare { }; <ins> glooctl = callPackage ../applications/networking/cluster/glooctl { }; </ins> gobgp = callPackage ../tools/networking/gobgp { }; gofu = callPackage ../applications/misc/gofu { };

Discussion:
add glooctl is the official cli tool to manage it Metadata homepage URL: source URL: license: Apache-2.0 License platforms: linux, darwin
Change:
url = "https://git.taler.net/exchange.git"; rev = "v${version}"; fetchSubmodules = true; <del> sha256 = "sha256-NgDZF6LNeJI4ZuXEwoRdFG6g0S9xNTVhszzlfAnzVOs="; </del> <ins> hash = "sha256-SKnMep8bMQaJt4r3u0SrzwYSuFbzv4RnflbutSqwtPg="; </ins> # When fetching submodules without the .git folder we get the following error: # "Server does not allow request for unadvertised object"

Discussion:
Package name: gnunet Latest released version: 0.21.0 Current version on the unstable channel: 0.20.0 Current version on the stable/release channel: 0.20.0 Notify maintainers Changelog: 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:
<del> { stdenv, fetchurl, texinfo, libXext, xorgproto, libX11 </del> <ins> { stdenv, fetchurl, texinfo6_5, libXext, xorgproto, libX11 </ins> , libXpm, libXt, libXcursor, alsaLib, cmake, zlib, libpng, libvorbis , libXxf86dga, libXxf86misc , libXxf86vm, openal, libGLU, libGL }:

Discussion:
Describe the bug To Reproduce Steps to reproduce the behavior: ~/nixpkgs -build -A lutris <details<summarylog</summary</detailsExpected behavior Screenshots Additional context 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(root): nixpkgs: Maintainer information:
thanks !!
Change:
import ./generic.nix (rec { version = "28.1"; <del> sha256 = "sha256-KLGz0JkDegiPCkyiUdfnJi6rXqFneqv/psRCaWGtdeE="; </del> <ins> sha256 = "sha256-D33wnlxhx0LyG9WZaQDj2II3tG0HcJdZTC4dSA3lrgY="; </ins> patches = _: [ ]; })

Discussion:
The issue is what the title says. By half, I mean and for my previously used from emacs-overlay to your system the eln cache in your home, e.g. to open emacs for the manual for by and inputing the eln cache in your home: , you will find together other eln cache. I think this is a bug since is builtin for emacs and it's eln cache should be distributed together with . Uses of will not need to native-compile builtin libraries themselves. does distributed together with from emacs-overlay I used before. It's . might be related to the bump of 28 , so
The difference between the two versions is that one is built from the tarball, while the other is built from Git. The tarball includes byte-compiled () files but not native-compiled () files. The build notices the files and does not rebuild them, but native-compilation is a side-effect of byte-compilation and so the files aren't built either. (Almost all of the files you see for the new version are trampolines, there are only 3 non-trampoline files.)
ideally we'd run , which is the expected way of deleting such things (or perhaps even ). But the tarball only has a , so we'd need to run , then , then again, which is super ugly. Hopefully deleting the files the naïve way is enough?
I think maybe we should just skip the tarball entirely and fetch it from git instead.
There are other side-effects caused by skipping the tarball. This claims, for example, that bootstrapping is only expected to happen to emacs developers. Part of bootstrapping is converting the Japanese input method dictionaries, and this takes some amount of time. They're in the tarball at , but are absent in the git checkout.
That's a good point, I would still rather inflate build times a bit and exercise bootstrapping as a part of our regular build though to completely avoid these types of issues.
I'm hesitant about building things in a way that upstream doesn't expect, unless necessary to adapt for nixpkgs. For a related example, using the repo instead of the tar distribution for Ruby caused a subtle problem where the commit hash was not propagated, which broke the bootsnap gem's cache invalidation (fixed in , by using the tarball).

The real question here, I think, is how upstream expects native compilation to be used if their tarball doesn't support it.
Change:
<del> { lib, mkDerivation, fetchurl, extra-cmake-modules, qtx11extras, </del> <ins> { lib, mkDerivation, fetchurl, fetchpatch, extra-cmake-modules, qtx11extras, </ins> plasma-workspace, libwacom, xf86_input_wacom }:

Discussion:
Describe the bug The KDE Wacom configuration module is not working, showing "The shared library was not found": To Reproduce Steps to reproduce the behavior: KDE KDE system settings Expected behavior The configuration module should work Screenshots ! Additional context Add any other context about the problem here. Notify maintainers Metadata system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Maintainer information:
can confirm ! system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: (was not mentioned before)
not sure if this is related to
This is still be a problem on 20.09
According to strace, the missing library file is either or . The latter is provided by , so it somehow needs to be made discoverable in the environment of kcmshell5.
Running into same problem now on 20.09.
Just to clarify, does just need backporting to 20.09, or are people still experiencing issues on master after was merged?
I think it just needs backporting, but I'm not yet familiar enough with NixOS to say for sure. I just upgraded my system to unstable and is working as expected (which I'm assuming is because of ). !
I marked this as stale due to inactivity. &rarr;
There was a PR to backport it to 20.09, but nobody reviewed it and it was closed when 20.09 went end-of-life, so I'm assuming everybody using kcm-wacomtablet is now happily running 21.05 or unstable and we can close this.
Yes, I can confirm it is working again in 21.05.
Change:
<ins> { lib, appimageTools, fetchurl, pkgs }: let pname = "spacedrive"; version = "0.1.4"; src = fetchurl { url = "https://github.com/spacedriveapp/spacedrive/releases/download/${version}/Spacedrive-linux-x86_64.AppImage"; hash = "sha256-iBdW8iPuvztP0L5xLyVs7/K8yFe7kD7QwdTuKJLhB+c="; }; appimageContents = appimageTools.extractType2 { inherit pname version src; }; in appimageTools.wrapType2 { inherit pname version src; extraPkgs = pkgs: (appimageTools.defaultFhsEnvArgs.multiPkgs pkgs) ++ [ pkgs.libthai ]; extraInstallCommands = '' # Remove version from entrypoint mv $out/bin/spacedrive-"${version}" $out/bin/spacedrive # Install .desktop files install -Dm444 ${appimageContents}/spacedrive.desktop -t $out/share/applications install -Dm444 ${appimageContents}/spacedrive.png -t $out/share/pixmaps substituteInPlace $out/share/applications/spacedrive.desktop  --replace 'Exec=AppRun --no-sandbox %U' 'Exec=spacedrive' ''; meta = with lib; { description = "An open source file manager, powered by a virtual distributed filesystem"; homepage = "https://www.spacedrive.com/"; platforms = [ "x86_64-linux" ]; license = licenses.agpl3Plus; sourceProvenance = with sourceTypes; [ binaryNativeCode ]; maintainers = with maintainers; [ mikaelfangel heisfer ]; mainProgram = "spacedrive"; }; } </ins>

Discussion:
Project description Cross platform file manager supporting cloud providers Metadata homepage URL: source URL: license: GPL-3.0 platforms: linux, darwin
Clicking "Download" on the website shows
They don't ship binaries yet since its in beta, but the repo is ready and has instructions to compile (cargo + pnpm)
It seems we can use binaries from
Alpha 0.1.0 was released 2h ago:
I've the binary version to my
haven't done nixpkgs contribution but appimage version plus it needs to add meta field too.
Combine the two above derivations, and it would be a quick merge into nixpkgs :+1:
Change:
''; configurePhase = '' <del> export GYP_DEFINES="document_dir=$out/share/doc/mozc use_libzinnia=1 use_libprotobuf=1" </del> <ins> export GYP_DEFINES="document_dir=$out/share/doc/mozc use_libzinnia=1 use_libprotobuf=1 use_fcitx5=0" </ins> cd src && python build_mozc.py gyp --gypdir=${gyp}/bin --server_dir=$out/lib/mozc '';

Discussion:
Describe the bug I was trying to upgrade my system to latest unstable when I encountered this error: error: --- Error
--------------------- nix-build builder for '/nix/store/4akxpw50h059071m68rm96qi3jmdv7zi-ibus-mozc-' failed with exit code 1; last 10 log lines: File "", line 854, in BuildMain BuildWithNinja(options, targets) File "", line 828, in BuildWithNinja RunOrDie([ninja, '-C', buildarg] + ninjatargets) File "", line 99, in RunOrDie '=========='])) ERROR: ninja -C outlinux/Release ibusmozc mozcemacshelper mozcserver mozctool mozc_renderer
cc: because of .
likewsie fcitx-mozc stopped working. Seems like there is this fork of google-mozc with more recent commits but changing upstream would require more changes:
Change:
propagatedBuildInputs = stdenv.lib.optionals stdenv.isDarwin [ libobjc IOKit ]; <del> # Fixes Cgo related build failures (see https://github.com/NixOS/nixpkgs/issues/25959 ) hardeningDisable = [ "fortify" ]; </del> src = fetchFromGitHub { owner = "ethereum"; repo = pname;

Discussion:
Using go + I am unable to build a simple Go program that makes use of C bindings. The program is a testcase from the Go compiler repository ( ) . The build fails with an error message like this: Another example is geth, the go ethereum client, in version 1.6.1: Switching to clang instead seems to be a workaround for the problem: This last command builds successfully. System: (Hummingbird) Nix version: nix-env (Nix) 1.11.9 Nixpkgs version: Sandboxing enabled: false
I think this has to do with how Go handles GOROOT. It expects to be able to write to $GOROOT even though it's a read-only path. Could you try the buildCommand in go-ethereum:
Aw, I was wondering how to get rid of that warning. The warning is gone, but it doesn't seem to have helped: I originally ran into this issue when I tried to upgrade that linked Nix expression. Version 1.4.7 of go-ethereum compiles just fine, but 1.6.1 doesn't, because now one of the dependencies makes use of some kind of C bindings. While playing around with it I also switched over to using in the Nix expression, but that also didn't help. Switching to clang helped in the end. That version can be found here: But that's just a workaround and I would assume that other Go packages will at some point also run into this problem when they just use or .
I ran into this problem adding seccomp support to the docker package. It's caused by the -O2 optimization flag which is being by the fortify hardening flag. A possible fix would be to add hardeningDisable = [ "fortify" ]; to the buildGoPackage.
I can't no longer reproduce this on my system so I guess the issue is fixed? I created a PR to get rid of the workarounds:
I can confirm that I also cannot reproduce this anymore on my system. I am closing this - thanks!
Change:
, systemd , taglib , unzip <del> , xlibsWrapper </del> , xorg , zlib , chromecastSupport ? true, libmicrodns, protobuf

Discussion:
In I noticed unusual behaviour of when is overridden. That PR handles override part. But I think should just disappear. Where should be no reason (for example) for to depend on at build time. is just the wrapper around a few libraries. Quoting : Mechanically we can replace with the list of packages it provides. Even better would be to audit needed libraries for each user and use only a subset of them. Example fix: [x] perlPackages.X11Protocol: [x] pulseaudio: More packages to fix: [x] Xaw3d: [x] emacs: [x] fox16: [x] geant4: [x] [x] gtk2: [x] [x] haskellPackages.greenclip: [x] [x] lesstif: [x] monotoneViz: [x] motif: [x] mythtv: [x] ocaml- [x] [x] [x] pypy2, pypy3: [x] qgis: [x] qgis-ltr: [x] [x] qt6Packages.qtwayland: [x] rPackages.Cairo: [x] rPackages.devEMF: [x] [x] rPackages,rgl: [x] tightvnc: [x] weston: Fixed packages: [x] astromenace: [x] catclock: [x] clanlib: [x] conky: [x] elinks: [x] fox: [x] freeglut: [x] ghostscript, ghostscriptX: [x] gnome2.libgnomeui: [x] glbinding: [x] glew, glew-egl: [x] glew110: [x] imhex: [x] imlib2,

imlib2Full: [x] ion3: [x] libagar: [x] libstroke: [x] lirc: [x] mitschemeX11: [x] ncview: [x] nedit: [x] notion: [x] oneko: [x] openrw: [x] pasystray: [x] pcb: [x] povray: [x] pythonFull: [x] qemacs: [x] qmmp: [x] rss-glx: [x] scrot: [x] soxt: [x] survex: [x] synergy: [x] ted: [x] unclutter: [x] unclutter-xfixes: [x] vlc: [x] voxelands: [x] wordnet: [x] xautolock: [x] xfe: [x] x11sshaskpass: [x] xfig: [x] xidlehook: [x] xine-ui: [x] xinputcalibrator: [x] xmountains: [x] xspim: [x] xtrlock-pam: [x] xwinwrap: [x] xxgdb: [x] zoom:
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Change:
assert stdenv.system != "powerpc-linux"; stdenv.mkDerivation rec { <del> ver = "1.21.3"; </del> <ins> ver = "1.23.1"; </ins> name = "recoll-${ver}"; src = fetchurl { url = "http://www.lesbonscomptes.com/recoll/${name}.tar.gz"; <del> sha256 = "66f039f08b149d5e4840664d4a636f6b55145b02072f87aab83282ebe0cd593a"; </del> <ins> sha256 = "0si407qm47ndy0l6zv57lqb5za4aiv0lyghnzb211g03szjkfpg8"; </ins> }; <del> patches = [ ./nodeblayout.patch ./versionawk.patch ]; </del> configureFlags = [ "--with-inotify" ]; buildInputs = [ qt4 xapian file python bison];

Discussion:
Describe the bug texlive on master fails to build since : This commit upgraded the poppler library, and upstream they "modernized the headers", including instead of in the . texlive includes this file in a plain C program, so is not available. To Reproduce Expected behavior Should build. Additional context Gentoo had this issue too: I'm not familiar enough with gentoo to understand what the fix is doing, but it looks like they fixed it by moving to an r6 version of texlive? Metadata Maintainer information: cc
No, that's versioning of gentoo-specific tarball with patches, currently and their workaround is in texlive-core-2019- inside.
The patch was applied in . I believe poppler should be blamed instead, but it should work now at least.
Change:
rustPlatform.buildRustPackage rec { pname = "vaultwarden"; <del> version = "1.30.5"; </del> <ins> version = "1.31.0"; </ins> src = fetchFromGitHub { owner = "dani-garcia"; <del> repo = pname; </del> <ins> repo = "vaultwarden"; </ins> rev = version; <del> hash = "sha256-OwFB5ULWBefDHSkUM3nT0v2jcc5vHUvs8Ex0JauDu8w="; </del> <ins> hash = "sha256-fQjTSLPJQk1byjX+HADtQvQRqEaEiCmWjgA1WIMLBu4="; </ins> }; <del> cargoHash = "sha256-K0T0uTERjxlI3bGG/Tz6sJ0A08J0ROAhpppdZcdQPB8="; </del> <ins> cargoHash = "sha256-VWKkZvuv+B9V6pgxZRGlLIRUdLEh61RpOfEnOtEBKU0="; </ins> # used for "Server Installed" version in admin panel env.VW_VERSION = version;

Discussion:
Package name: vaultwarden Latest released version: 1.31.0 (, ) <!-- Search your package here: --- Current version on the unstable channel: 1.30.5 Current version on the stable/release channel: 1.30.5 <!-- 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]:
Damn someone beat me to it lol
vaultwarden seems borken to me, at least in aarch builds. anyone else seeing this?
it should be fixed in