jiebi/CodeConvo huggingface dataset:
Change:
Describe the bug Apps packaged as AppImage don't seem to respect the system's fontconfig and cursor. Additionally, opening URLs is broken as it seems that doesn't work. To Reproduce Steps to reproduce the behavior: AppImage a URL Expected behavior It should open a browser at the given URL. Screenshots Proper cursor "outside" AppImage: ! Default X11 cursor "inside" AppImage: ! 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:
CC: (seems to be the people that did the most significant work here, sorry if you don't have enough context).
BTW, are you using unstable or you're using with backports? Asking this because I had a similar issue with Discord not opening links, and using the proper Discord from instead of using a backport did the trick: .
I'm using unstable. Updated the issue with metadata.
Fixed in . I suppose you are installing stuff globally and hence why you didn't have the issues I did.
I had this problem too, but I thought it was because the difference between and . Reviewing and testing it ASAP.
Was this also fixed? for me (zettlr uses appimage)

Discussion:
"unshareUser" "unshareCgroup" "unshareUts" "unshareNet" "unsharePid" "unshareIpc" ]); <del> chrootenv = callPackage ./chrootenv {}; </del> etcBindFlags = let files = [ # NixOS Compatibility

"hosts" "resolv.conf" "nsswitch.conf" <ins> # User profiles "profiles" </ins> # Sudo & Su "login.defs" "sudoers"

if [[ -d ${env}/etc ]]; then for i in ${env}/etc/*; do path="/''${i##*/}" <ins> # NOTE: we're binding /etc/fonts from the host so we don't want to # override it with a path from the FHS environment. if [[ $path == '/fonts' ]]; then continue fi </ins> ro_mounts+=(--ro-bind "$i" "/etc$path") done fi

ln -s /host/etc/resolv.conf resolv.conf ln -s /host/etc/nsswitch.conf nsswitch.conf <ins> # symlink user profiles ln -s /host/etc/profiles profiles </ins> # symlink sudo and su stuff ln -s /host/etc/login.defs login.defs ln -s /host/etc/sudoers sudoers
Change:
Project description Engine for Hexen 2 Metadata homepage URL: source URL: license: gpl2 platforms: unix, linux, darwin, windows, dos, aros, morphos, amigaos

Discussion:
<ins> { lib, fetchgit, SDL, stdenv, libogg, libvorbis, libmad, xdelta }: stdenv.mkDerivation rec { name = "uhexen2"; version = "1.5.9"; src = fetchgit { url = "https://git.code.sf.net/p/uhexen2/uhexen2"; sha256 = "0crdihbnb92awkikn15mzdpkj1x9s34xixf1r7fxxf762m60niks"; rev = "4ef664bc41e3998b0d2a55ff1166dadf34c936be"; }; buildInputs = [ SDL libogg libvorbis libmad xdelta ]; preBuild = '' makeFiles=( "engine/hexen2 glh2" "engine/hexen2 clean" "engine/hexen2 h2" "engine/hexen2/server" "engine/hexenworld/client glhw" "engine/hexenworld/client clean" "engine/hexenworld/client hw" "engine/hexenworld/server" "h2patch" ) ''; buildPhase = '' runHook preBuild for makefile in "''${makeFiles[@]}"; do local flagsArray=( -j$NIX_BUILD_CORES -l$NIX_BUILD_CORES SHELL=$SHELL $makeFlags "''${makeFlagsArray[@]}" $buildFlags "''${buildFlagsArray[@]}" ) echoCmd 'build flags' ""''${flagsArray[@]}"" make  -C $makefile ""''${flagsArray[@]}"" unset flagsArray done runHook postBuild ''; installPhase = '' runHook preInstall install -Dm755 engine/hexen2/{glhexen2,hexen2,server/h2ded} -t $out/bin install -Dm755 engine/hexenworld/{client/glhwcl,client/hwcl,server/hwsv} -t $out/bin install -Dm755 h2patch/h2patch -t $out/bin runHook postInstall ''; meta = with lib; { description = "A cross-platform port of Hexen II game"; longDescription = '' Hammer of Thyrion (uHexen2) is a cross-platform port of Raven Software's Hexen II source. It is based on an older linux port, Anvil of Thyrion. HoT includes countless bug fixes, improved music, sound and video modes, opengl improvements, support for many operating systems and architectures, and documentation among many others. ''; homepage = "http://uhexen2.sourceforge.net/"; license = licenses.gpl2Plus; maintainers = with maintainers; [ xdhampus ]; platforms = platforms.all; }; } </ins>

ufoai = callPackage ../games/ufoai { }; <ins> uhexen2 = callPackage ../games/uhexen2 { }; </ins> ultimatestunts = callPackage ../games/ultimatestunts { }; ultrastar-creator = libsForQt5.callPackage ../tools/misc/ultrastar-creator { };
Change:
Describe the bug fails to build this is a dependency of this prevents building nixos with rocm openCL support To Reproduce Steps to reproduce the behavior: alternatively the following (from ) to a nixos config and try to build nixos from (this is my use case and may catch additional issues) Expected behavior to build, and nothing else to fail towards building my nixos Notify maintainers (thanks for upstreaming btw) Metadata Maintainer information:

Discussion:
echo "$VCSVersion" > lib/Basic/VCSVersion.inc ''; <ins> passthru = { isClang = true; inherit llvm; }; </ins> meta = with lib; { description = "ROCm fork of the clang C/C++/Objective-C/Objective-C++ LLVM compiler frontend"; homepage = "https://llvm.org/";
Change:
Project description Connect to Plan9 CPU servers from other operating systems. Metadata homepage URL: source URL: license: mit platforms: unix, linux, darwin, windows
I marked this as stale due to inactivity. &rarr;

Discussion:
<ins> { stdenv , lib , fetchgit , xorg }: stdenv.mkDerivation rec { pname = "drawterm"; version = "unstable-2021-08-02"; src = fetchgit { url = "git://git.9front.org/plan9front/drawterm"; rev = "a130d441722ac3f759d2d83b98eb6aef7e84f97e"; sha256 = "R+W1XMqQqCrMwgX9lHRhxJPG6ZOvtQrU6HUsKfvfrBQ="; }; buildInputs = [ xorg.libX11 xorg.libXt ]; # TODO: macos makeFlags = [ "CONF=unix" ]; installPhase = '' install -Dm755 -t $out/bin/ drawterm install -Dm644 -t $out/man/man1/ drawterm.1 ''; meta = with lib; { description = "Connect to Plan9 CPU servers from other operating systems."; homepage = "https://drawterm.9front.org/"; license = licenses.mit; maintainers = with maintainers; [ luc65r ]; platforms = platforms.linux; }; } </ins>

buildServerGui = false; }; <ins> drawterm = callPackage ../tools/admin/drawterm { }; </ins> droopy = python3Packages.callPackage ../applications/networking/droopy { }; drumgizmo = callPackage ../applications/audio/drumgizmo { };
Change:
Describe the bug seems to be failing consistently on master now by timing out. I wasn’t able to figure out where this problem was introduced, since it fails locally for me in the same way even on commits where Hydra has marked it successful. To Reproduce Notify maintainers Metadata system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Maintainer information:
On the other hand I can't reproduce this locally at all. I can see the number of VM cores was increased from 1 to 8 about 2 weeks ago. Could be some kind of race condition?
I've tried two attempts and both kept hanging, probably the same way as on Hydra.
I've tested it 3 times with the latest master and it worked every single time. One thing I noticed though is that I don't see "Passphrase for" (which the test successfully waits for) anywhere in the log. Not in failed hydra logs or successful local runs. So it looks like it's not printing everything to the build log. When I changed the passphrase so it was incorrect, the test hanged just like on Hydra. It should at least show an error message that the passphrase is incorrect. How come we're not getting the complete output log? My best guess is that it failed to unlock the partition for some unknown reason (e.g. maybe the device is not available yet), but it's eating the error message so we have no idea why.
Although the latest Hydra build , a local build on the same commit () still fails. This provides further evidence for the race condition theory, and that we haven’t seen the last of this bug. I’m on a Ryzen 7 1800X (8 cores/16 threads). To test the number-of-cores theory, I tried this patch, and it succeeded:
Could you try adding before and see if that helps?
No, that did not help: <details(hangs forever) </detailsEdit: Of course that doesn’t work, since needs a shell first. But doesn’t work either: <details(hangs forever) </details
I tried to run the test and ran into a different problem: Further investigation shows this Python shell to be severely broken: This seems to be caused by prompt-toolkit/ptpython.
Well that's unfortunate. Though looking at it looks like it shouldn't be a problem to move those variables into the function itself as they don't seem to be used by any other functions.
I think I found a better workaround for the ptpython problem: .
With , and doing before starting (to work around another bug where the test assumes that is in the current directory), I was able to observe the real error: ! “Not enough available memory to open a keyslot.”
And this succeeds: Opened .

Discussion:
def assemble_qemu_flags(): flags = "-cpu max" ${if system == "x86_64-linux" <del> then ''flags += " -m 768"'' else ''flags += " -m 512 -enable-kvm -machine virt,gic-version=host"'' </del> <ins> then ''flags += " -m 1024"'' else ''flags += " -m 768 -enable-kvm -machine virt,gic-version=host"'' </ins> } return flags
Change:
crashes when attempting to open any file dialog, such as saving an attachment. mailspring the menu bar select Edit Install Theme... Expected behavior A "Choose Directory" file dialog should open Actual Behaviour Mailspring crashes with the following output: Adding to resolves the issue: I have mailspring to in my system's file. Notify maintainers Metadata Results of : system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Maintainer information:
I tried installing from unstable but to no avail.
This package is missing in . See the gnome section of the nixpkgs manual

Discussion:
, dpkg , glib , gtk3 <ins> , wrapGAppsHook </ins> , libkrb5 , libsecret , nss

nativeBuildInputs = [ autoPatchelfHook dpkg <ins> wrapGAppsHook </ins> ]; buildInputs = [
Change:
Describe the bug Apparently this bug was already caught in the original PR , but for some reason the fix got later reverted in The error message from systemd is: To Reproduce Expected behavior docker should start Additional context fixes it Notify maintainers Metadata Please run and paste the result.
See reason for the fix: This issue was originally caused by build misconfiguration (Moby build flags in wrong place perhaps).
Unable to reproduce this on my system with following configuration:
Just tried with an explicit , this fixes the issue. Looking at logs of : This happened the first time it tried to start docker. I think this is a race in startup, docker starts before the socket, prevents from starting, then start fails with this error. According to systemd docs: So perhaps we just need to add a line to ?
Seems like this is exactly the case.

Discussion:
systemd.services.docker = { wantedBy = optional cfg.enableOnBoot "multi-user.target"; <ins> requires = [ "docker.socket" ]; </ins> environment = proxy_env; serviceConfig = { Type = "notify";
Change:
Describe the bug nixpkgs has moved to unified cgroups (woo :tada:) as of recently (). Unfortunately, k3s fails to start correctly with unified cgroups without , which isn't included in a release yet. Until that lands in a release and nixpkgs is updated, it can be worked around by setting I intend to work on fixing this; I'll drop any notes along the way in this issue.
I've updated the title to be more specific, since my actual errors are coming from using k3s with , and the error is specifically about kubelet and docker's cgroup driver mismatching. I see that the unified cgroup PR did disable unified cgroups in the k3s module, so that probably should work before adding in the docker runtime. I need to do a little more investigation here.
Please let me know, if this is related: I'm trying to follow the wiki article on kubernetes on nixos: With the configs shown there I run into an error when starting The full error is very long, I've uploaded it here:
Thanks for looking into this.
Just tried the workaround mentioned above: Setting also fixes the problem for the kubernetes service
We have observed that unified cgroups also breaks Kubernetes-in-Docker for node images prior to 1.19. The observed behavior is that the kubelet fails to start, with the message: Also able to work around with
For k3s, the v1.20.4+k3s1 release includes unified cgroups support. It fixes my use of k3s, though I also had to set a flag in the nixos module ( to make docker+kubelet match). I've opened up a PR to bump the package (), and I'll make a separate PR to fix the nixos module to pass that arg. I think those two changes together should fix this issue. It sounds like there's other work to be done for other ways of running kubernetes on nixos too, but I think we should open separate issues for those to avoid conflating too many issues at once.
This would be the fix: I was not invested enough at the time to also write release notes, but if you want you can pick up the change.
see
This PR should also help:
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
This issue has been mentioned on NixOS Discourse. There might be relevant details there:

Discussion:
# supporting it, or their bundled containerd systemd.enableUnifiedCgroupHierarchy = false; <ins> environment.systemPackages = [ config.services.k3s.package ]; </ins> systemd.services.k3s = { description = "k3s service"; after = mkIf cfg.docker [ "docker.service" ]; wantedBy = [ "multi-user.target" ]; <ins> path = optional config.boot.zfs.enabled config.boot.zfs.package; </ins> serviceConfig = { # See: https://github.com/rancher/k3s/blob/dddbd16305284ae4bd14c0aade892412310d7edc/install.sh#L197 Type = if cfg.role == "agent" then "exec" else "notify";
Change:
<!-- You can use the "Go to file" functionality on github to find the package Then you can go to the history for this package Find the latest "packagename: oldversion -newversion" commit The "newversion" is the the current version of the package --- <!-- 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! --- name: tootle <!-- The current version can be found easily with the same process than above for checking the master branch If an open PR is present for the package, take this version as the current one and link to the PR --current version: 0.2.0 desired version: 1.0 maintainers: Please tag this issue in your PR.

Discussion:
, json-glib , glib , glib-networking <ins> , libhandy </ins> }: stdenv.mkDerivation rec { pname = "tootle"; <del> version = "0.2.0"; </del> <ins> version = "1.0"; </ins> src = fetchFromGitHub { owner = "bleakgrey"; repo = pname; rev = version; <del> sha256 = "1z3wyx316nns6gi7vlvcfmalhvxncmvcmmlgclbv6b6hwl5x2ysi"; </del> <ins> sha256 = "NRM7GiJA8c5z9AvXpGXtMl4ZaYN2GauEIbjBmoY4pdo="; </ins> }; nativeBuildInputs = [

json-glib libgee pantheon.granite <del> ]; patches = [ # Fix build with Vala 0.46 # https://github.com/bleakgrey/tootle/pull/164 (fetchpatch { url = "https://github.com/worldofpeace/tootle/commit/0a88bdad6d969ead1e4058b1a19675c9d6857b16.patch"; sha256 = "0xyx00pgswnhxxbsxngsm6khvlbfcl6ic5wv5n64x7klk8rzh6cm"; }) </del> <ins> libhandy </ins> ]; postPatch = ''
Change:
Describe the bug I am trying to cross-compile nixos for the raspberry pi. Trying to do so leads to an error while trying to build . The error is this: I am using the nix expression from this repository: To Reproduce Steps to reproduce the behavior: Expected behavior Everything builds without error.
This is the same problem reported in , but a fix still hasn't been found. I'll try to bisect the commit that introduced this regression.
I narrowed down the regression to . It looks like the new are the cause of the failure. Before that wasn't a dependency.
Hi! was reverted by (in ) it's currently in staging-next. I hope this fixes the issue.
Thanks for the heads up I was able cross compile with reverted, so it should be fixed once it's merged to master.
This also affects aarch64 cross compilation:
It seems that reintroduced the breakage. That commit was immediately followed by which is a security update, so I'm assuming it's not a good idea to revert. I'm poking at this now but I'm very unfamiliar with Perl, so I opened to follow up.

Discussion:
HTTPDaemon = buildPerlPackage { pname = "HTTP-Daemon"; <del> version = "6.12"; </del> <ins> version = "6.01"; </ins> src = fetchurl { <del> url = "mirror://cpan/authors/id/O/OA/OALDERS/HTTP-Daemon-6.12.tar.gz"; sha256 = "19hz9r6f1p406fk1pqyd99h96ipxsmknh4fh1xw0qrrq1k8vwiyz"; </del> <ins> url = "mirror://cpan/authors/id/G/GA/GAAS/HTTP-Daemon-6.01.tar.gz"; sha256 = "1hmd2isrkilf0q0nkxms1q64kikjmcw9imbvrjgky6kh89vqdza3"; </ins> }; <del> buildInputs = [ CPANMetaCheck ModuleBuildTiny TestNeeds ]; </del> propagatedBuildInputs = [ HTTPMessage ]; meta = { description = "A simple http server class";
Change:
fails on Ubuntu Linux 14.04.2. with messages about MASS like: and in other cases with messages related to invalid sha256 hashes. Is R meant to be broken or known to be broken? IIRC, it has been this like at least 6 months.
And ? I have the impression you haven't updated your channel.
On master we have 7.3.45 and it downloads fine (maybe not in the channel yet), but on 15.09 it gets just 404. what's the general strategy about backporting updates to stable releases?
BTW, having a stable URL is always preferred, I believe. Perhaps we can get such for this package?
Upstream edits and removes published versions of R modules at will, so it's near impossible to provide a stable release of R unless we mirror all source tarballs. I suppose this means that we must update in our release branches, because otherwise they just won't build after a couple of weeks.
I've enabled Hydra builds for R in the branch in . Hopefully, that will make those source tarballs available in our cache and mitigate those kind of problems in the future.
FWIW, there's an awesome MRAN (Managed R...) with daily complete CRAN snapshots available from Revolution Analytics [1]. I've sent them an e-mail asking for permission to use their mirror as our main source of package sources nearly two months ago, but got no answer. All the rhetoric on the website suggest that this mirror is "open" and "available to the R community" but I don't know if we should use it without a permission... 1:
I think we totally should! Tracking this issue at

Discussion:
{stdenv, fetchurl}: stdenv.mkDerivation rec { <del> name = "ncompress-4.2.4.3"; </del> <ins> name = "ncompress-4.2.4.4"; </ins> builder = ./builder.sh;

src = fetchurl { url = "mirror://sourceforge/project/ncompress/${name}.tar.gz"; <del> sha256 = "1y44ixc1w2vfvj1lm4dkcljlwv882ynrvm5i6l0lg1gf883j246l"; </del> <ins> sha256 = "0yjiwv1hwb253x3m6r1dq2k7m5c9nz0ib2j7fnm3hark7y6s42xh"; </ins> }; meta = {
Change:
Describe the bug Cannot build tickrs on darwin: To Reproduce Steps to reproduce the behavior: nixpkgs -build . -A tickrs Expected behavior Success Screenshots N/A 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(zdai): nixpkgs: Maintainer information:

Discussion:
<del> { lib, rustPlatform, fetchFromGitHub, perl }: </del> <ins> { lib, stdenv, rustPlatform, fetchFromGitHub, perl, Security }: </ins> rustPlatform.buildRustPackage rec { pname = "tickrs";

nativeBuildInputs = [ perl ]; <ins> buildInputs = lib.optionals stdenv.isDarwin [ Security ]; </ins> meta = with lib; { description = "Realtime ticker data in your terminal"; homepage = "https://github.com/tarkah/tickrs";

ticpp = callPackage ../development/libraries/ticpp { }; <del> tickrs = callPackage ../applications/misc/tickrs { }; </del> <ins> tickrs = callPackage ../applications/misc/tickrs { inherit (darwin.apple_sdk.frameworks) Security; }; </ins> tig = callPackage ../applications/version-management/git-and-tools/tig { };
Change:
Describe the bug 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): channels(user): nixpkgs: Maintainer information:
Seems like updating to 0.9.64.4 is the way to go?
Can be closed?!

Discussion:
<del> {stdenv, fetchurl, fetchpatch, which, nixosTests}: let s = # Generated upstream information rec { baseName="firejail"; version="0.9.62"; name="${baseName}-${version}"; url="mirror://sourceforge/firejail/firejail/firejail-${version}.tar.xz"; sha256="1q2silgy882fl61p5qa9f9jqkxcqnwa71jig3c729iahx4f0hs05"; }; buildInputs = [ which ]; in stdenv.mkDerivation { inherit (s) name version; inherit buildInputs; src = fetchurl { inherit (s) url sha256; name = "${s.name}.tar.bz2"; </del> <ins> { lib, stdenv, fetchFromGitHub, fetchpatch, which, xdg-dbus-proxy, nixosTests }: stdenv.mkDerivation rec { pname = "firejail"; version = "0.9.64.4"; src = fetchFromGitHub { owner = "netblue30"; repo = "firejail"; rev = version; sha256 = "sha256-q/XL8cznHlUXdubUEptEAVma1jRUqFb5XcLAV0RVCzs="; </ins> }; <ins> buildInputs = [ which ]; </ins> patches = [ <del> (fetchpatch { name = "CVE-2020-17367.patch"; url = "https://github.com/netblue30/firejail/commit/2c734d6350ad321fccbefc5ef0382199ac331b37.patch"; sha256 = "1gxz4jxp80gxnn46195qxcpmikwqab9d0ylj9zkm62lycp84ij6n"; }) (fetchpatch { name = "CVE-2020-17368.patch"; url = "https://github.com/netblue30/firejail/commit/34193604fed04cad2b7b6b0f1a3a0428afd9ed5b.patch"; sha256 = "0n4ch3qykxx870201l8lz81f7h84vk93pzz77f5cjbd30cxnbddl"; }) </del> # Adds the /nix directory when using an overlay. # Required to run any programs under this mode. ./mount-nix-dir-on-overlay.patch

substituteInPlace etc/firejail.config --replace  '# follow-symlink-as-user yes'  'follow-symlink-as-user no' <ins> # Fix the path to 'xdg-dbus-proxy' hardcoded in the 'common.h' file substituteInPlace src/include/common.h  --replace '/usr/bin/xdg-dbus-proxy' '${xdg-dbus-proxy}/bin/xdg-dbus-proxy' </ins> ''; preConfigure = ''

passthru.tests = nixosTests.firejail; meta = { <del> inherit (s) version; description = ''Namespace-based sandboxing tool for Linux''; license = stdenv.lib.licenses.gpl2Plus ; maintainers = [stdenv.lib.maintainers.raskin]; platforms = stdenv.lib.platforms.linux; </del> <ins> description = "Namespace-based sandboxing tool for Linux"; license = lib.licenses.gpl2Plus; maintainers = [ lib.maintainers.raskin ]; platforms = lib.platforms.linux; </ins> homepage = "https://firejail.wordpress.com/"; <del> downloadPage = "https://sourceforge.net/projects/firejail/files/firejail/"; </del> }; }

<del> url https://sourceforge.net/projects/firejail/files/firejail/ version_link '[-][0-9.]+[.]tar[.][a-z0-9]+/download$' SF_redirect </del>
Change:
Describe the bug cmake-gui doesn't launch it shows an error like:- 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 Please run and paste the result. Maintainer information:

Discussion:
, useSharedLibraries ? (!isBootstrap && !stdenv.isCygwin) , useOpenSSL ? !isBootstrap, openssl , useNcurses ? false, ncurses <del> , withQt5 ? false, qtbase </del> <ins> , withQt5 ? false, qtbase, wrapQtAppsHook </ins> , buildDocs ? (!isBootstrap && (useNcurses || withQt5)), sphinx, texinfo }: <del> stdenv.mkDerivation (rec { </del> <ins> stdenv.mkDerivation rec { </ins> pname = "cmake" + lib.optionalString isBootstrap "-boot" + lib.optionalString useNcurses "-cursesUI"

depsBuildBuild = [ buildPackages.stdenv.cc ]; nativeBuildInputs = [ setupHook pkg-config ] <del> ++ lib.optionals buildDocs [ texinfo ]; </del> <ins> ++ lib.optionals buildDocs [ texinfo ] ++ lib.optionals withQt5 [ wrapQtAppsHook ]; </ins> buildInputs = [] ++ lib.optionals useSharedLibraries [ bzip2 curlMinimal expat libarchive xz zlib libuv rhash ]

maintainers = with maintainers; [ ttuegel lnl7 ]; license = licenses.bsd3; }; <del> } // (if withQt5 then { dontWrapQtApps = true; } else {}) ) </del> <ins> } </ins>