jiebi/CodeConvo huggingface dataset:
Change:
./purity.patch # https://reviews.llvm.org/D51899 ./gnu-install-dirs.patch <ins> # Revert of https://reviews.llvm.org/D100879 # The malloc alignment assumption is incorrect for jemalloc and causes # mis-compilation in firefox. # See: https://bugzilla.mozilla.org/show_bug.cgi?id=1741454 ./revert-malloc-alignment-assumption.patch </ins> (substituteAll { src = ../../clang-11-12-LLVMgold-path.patch; libllvmLibdir = "${libllvm.lib}/lib";

Discussion:
Over time, memory consumption increases to about 1 - 1.5 GB per parent process, and does not decrease even after closing all tabs. If you select and close all these tabs, and then open them again, it will easily raise consumption to ~ 800 MB, after that growth slows down. The easiest and fastest way to reproduce this is to open several heavy tabs at the same time. (This list will take up more than six gigabytes at a time after the pages are fully loaded, so be careful). The official nightly build launched via lxd in debian 11, as well as the current version installed via flatpak, is not affected by this problem, in them the main process after the end of loading tabs decreases back to ~300 MB. Here is a fragment of the output to make it clearer what it is about. In this case, you need to pay attention to the consumption of the process. In this case, it is a process . This browser run through flatpak and now it have some opened tabs. Steps to reproduce the behavior: heavy tabs A browser installed via nix should not consume more memory than via flapak or lxd.
Can confirm. Comparing and by opening and closing one of those habr links, the latter eats 600M and doesn't give it back whereas the former frees that memory. I suppose using can be a workaround in some circumstances.
Thanks for reporting this. I assume this is related to our source builds having disabled jemalloc quite recently. I submitted a PR to rectify that. PTAL.
memory consumption went back down for me.
I believe Firefox does not immediately free the memory if you are not under memory pressure so I think this is only a problem if it also causes issues with high system memory usage.
Resolved by , currently on staging-next.
The fix made it into and so I consider this resolved.
Change:
installTargets = [ "install-tlp" "install-man" ] ++ lib.optionals enableRDW [ "install-rdw" "install-man-rdw" ]; <del> # XXX: This is disabled because it's basically just noise since upstream # itself does not seem to care about the zillion shellcheck errors. doCheck = false; checkInputs = [ checkbashisms shellcheck ]; </del> <ins> doCheck = true; checkInputs = [ checkbashisms perlcritic shellcheck ]; </ins> checkTarget = [ "checkall" ]; <ins> # TODO: Consider using resholve here </ins> postInstall = let paths = lib.makeBinPath ( [

Discussion:
<!-- Note that these are hard requirements --<!-- 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: <!-- 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: 1.3.1 desired version: 1.4.0 <!-- Search your package here: If no maintainer is listed for your package, tag the person that last updated the package --maintainers: Please tag this issue in your PR.
Change:
<ins> { fetchFromGitHub, lib, stdenv, gtk2, pkg-config, qmake, qtbase }: stdenv.mkDerivation (finalAttrs: { pname = "qt6gtk2"; version = "0.2"; src = fetchFromGitHub { owner = "trialuser02"; repo = finalAttrs.pname; rev = finalAttrs.version; hash = "sha256-g5ZCwTnNEJJ57zEwNqMxrl0EWYJMt3PquZ2IsmxQYqk="; }; buildInputs = [ gtk2 qtbase ]; nativeBuildInputs = [ pkg-config qmake ]; dontWrapQtApps = true; installPhase = '' runHook preInstall mkdir -p $out/lib/qt-6/plugins/{platformthemes,styles} cp -pr src/qt6gtk2-qtplugin/libqt6gtk2.so $out/lib/qt-6/plugins/platformthemes cp -pr src/qt6gtk2-style/libqt6gtk2-style.so $out/lib/qt-6/plugins/styles runHook postInstall ''; meta = { description = "GTK+2.0 integration plugins for Qt6"; license = lib.licenses.gpl2Plus; homepage = "https://github.com/trialuser02/qt6gtk2"; maintainers = [ lib.maintainers.misterio77 ]; platforms = lib.platforms.linux; }; }) </ins>

Discussion:
I've followed the instructions described in the , but Qt applications are not using my GTK theme. Running will yield the following error: Qt applications should properly detect the style. Please run and paste the result.
Yeah qalculate-qt (and anki) are Qt 6 applications, I expect the gtk2 style not working before someone package (theming for Qt 5 should work since we have though :upsidedownface:)
Here's qt6gtk2: With that PR merged, this issue should be fixed right out of the box when using NixOS to manage qt.
Thank you for the PR!
Change:
stdenv.mkDerivation rec { pname = "morgen"; <del> version = "2.7.5"; </del> <ins> version = "3.0.0"; </ins> src = fetchurl { url = "https://download.todesktop.com/210203cqcj00tw1/morgen-${version}.deb"; <del> sha256 = "sha256-gsH+KJt0d1Xe1JhgXuqot/vrMw9eBzIpCGlGeaeVJ+k="; </del> <ins> sha256 = "sha256-6d1KYUlXv+bHPITt2zs++AtyaAT8SSCG9T8ZsgOKDiw="; </ins> }; nativeBuildInputs = [

Discussion:
Package name: morgen (nixpkgs ) Latest released version: 3.0.0 Current version on the unstable channel: 2.7.5 Current version on the stable/release channel: 2.7.0 ! Notify maintainers Note for maintainers: Please tag this issue in your PR.
That's a bot account and certainly not the maintainer.
Oops. I'll have to look into that once back at the computer. I was going by the commit history (seen many recommend that as a way to get the maintainer).
looks like this might be for you as per in the Morgen thank you.
I've created a branch at if you want to take a look.
Change:
in '' runHook preInstall <ins> mv build/linux-x86_64-server-${buildType}/images/jdk/man build/linux-x86_64-server-${buildType}/images/jbrsdk${jcefSuffix}-${javaVersion}-linux-x64${debugSuffix}-b${build} </ins> rm -rf build/linux-x86_64-server-${buildType}/images/jdk mv build/linux-x86_64-server-${buildType}/images/jbrsdk${jcefSuffix}-${javaVersion}-linux-x64${debugSuffix}-b${build} build/linux-x86_64-server-${buildType}/images/jdk '' + oldAttrs.installPhase + "runHook postInstall";

Discussion:
Seems to be related to PR Steps to reproduce the behavior: from master branch () the result share directory () the state of the man link () This will result into build error if used on nixos system with enabled man pages last line of trying to rebuild the system Either working link to man page or at non at all.
Change:
nativeBuildInputs = [ qmake qttools wrapQtAppsHook ]; <del> # HACK `propagatedSandboxProfile` does not appear to actually propagate the sandbox profile from `qt5.qtbase` sandboxProfile = toString qtbase.__propagatedSandboxProfile; </del> qmakeFlags = [ # setup hook only sets QMAKE_LRELEASE, set QMAKE_LUPDATE too: "QMAKE_LUPDATE=${qttools.dev}/bin/lupdate"

Discussion:
While working on , I attempted to use in the derivation. Unfortunately, it did not appear to propagate to qtpass or other Qt-using packages that would require the profile. They still experienced the error until I manually sandbox profiles to the other packages. Steps to reproduce the behavior: a to a package for something it needs (e.g., ). that package as a or to another package (e.g., qtpass). the other package. The build should succeed (allowing whatever is permitted by the profile), but it fails (due to the lack of the sandbox profile). n/a This requires the sandbox on Darwin to be set to or . <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --
Change:
<del> { "elm/browser" = { version = "1.0.0"; sha256 = "1apmvyax93nvmagwj00y16zx10kfv640cxpi64xgqbgy7d2wphy4"; }; "elm/core" = { version = "1.0.0"; sha256 = "10kr86h4v5h4p0586q406a5wbl8xvr1jyrf6097zp2wb8sv21ylw"; }; "elm/html" = { version = "1.0.0"; sha256 = "1n3gpzmpqqdsldys4ipgyl1zacn0kbpc3g4v3hdpiyfjlgh8bf3k"; }; "elm/http" = { version = "1.0.0"; sha256 = "1igmm89ialzrjib1j8xagkxalq1x2gj4l0hfxcd66mpwmvg7psl8"; }; "elm/json" = { version = "1.0.0"; sha256 = "1g0hafkqf2q633r7ir9wxpb1lnlzskhpsyi0h5bkzj0gl072zfnb"; }; "elm/project-metadata-utils" = { version = "1.0.0"; sha256 = "1d4rd4grrnbdvj9gf00h7dr6hbkjzawgkzpizfrkp1z1pyr3mvq9"; }; "elm/svg" = { version = "1.0.0"; sha256 = "08x0v8p9wm699jjmsnbq69pxv3jh60j4f6fg7y6hyr7xxj85y390"; }; "elm-explorations/markdown" = { version = "1.0.0"; sha256 = "0k3110ixa4wwf3vkkdplagwah9ypr965qxr1y147rnsc1xsxmr6y"; }; "elm/parser" = { version = "1.0.0"; sha256 = "0k4zlq30lrvawqvzwbvsl0hrmwf9s832mb41z7fdspm4549dj7wc"; }; "elm/time" = { version = "1.0.0"; sha256 = "0vch7i86vn0x8b850w1p69vplll1bnbkp8s383z7pinyg94cm2z1"; }; "elm/url" = { version = "1.0.0"; sha256 = "0av8x5syid40sgpl5vd7pry2rq0q4pga28b4yykn9gd9v12rs3l4"; }; "elm/virtual-dom" = { version = "1.0.0"; sha256 = "0hm8g92h7z39km325dlnhk8n00nlyjkqp3r3jppr37k2k13md6aq"; }; } </del>

Discussion:
Not sure whether this is darwin-specific. I cannot install next to , because both want link . It seems wrong for either of the packages to link shared libraries. I suspect this is because e.g. sets . I'd be happy to submit a patch to change this, but there seems to be a stack of scripts that's meant to generate this that's too deep for me. nix-env -iA nix-env -iA system: host os: multi-user?: sandbox: version: channels(rob): nixpkgs:
Usually we need a for these to work currently. Not sure if that is currently possible? You can also set meta.priority to a different number for each (default is 5). /cc
I think this must be darwin-specific; I have these packages happily coexisting alongside each other in on NixOS:
Yes, looks darwin-specific, via
Fixed in
Change:
platforms = platforms.unix; license = licenses.asl20; maintainers = [ maintainers.roberth ]; <del> }; </del> <ins> } // extraMeta; </ins> }

Discussion:
, CVSSv3=7.5 (nixos-20.09, nixos-unstable) Scanned versions: nixos-20.09: ; nixos-unstable: . Cc

, CVSSv3=7.5 (nixos-20.09, nixos-unstable) Scanned versions: nixos-20.09: ; nixos-unstable: . Cc

, CVSSv3=7.5 (nixos-20.09, nixos-unstable) Scanned versions: nixos-20.09: ; nixos-unstable: . Cc

, CVSSv3=7.5 (nixos-20.09, nixos-unstable) Scanned versions: nixos-20.09: ; nixos-unstable: . Cc
See also , ,
Change:
, libjpeg , libtiff , libxml2 <del> , mkDerivation </del> , pixman , pkg-config , podofo , poppler , poppler_data , python3 <del> , qtbase , qtimageformats , qttools </del> , lib <ins> , stdenv , qt5 </ins> }: let

Discussion:
Package name: scribus Latest released version: 1.6.0 Current version on the unstable channel: 1.5.8 Current version on the stable/release channel: 1.4.8 Notify maintainers Note for maintainers: Please tag this issue in your PR. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
The version on the stable channel is also 1.5.8, 1.4 existed only on the old NixOS 23.05 release and got removed since.
Change:
<del> { lib, stdenv, fetchurl, haskell, spass }: stdenv.mkDerivation rec { pname = "system-for-automated-deduction"; version = "2.3.25"; src = fetchurl { url = "http://nevidal.org/download/sad-${version}.tar.gz"; sha256 = "10jd93xgarik7xwys5lq7fx4vqp7c0yg1gfin9cqfch1k1v8ap4b"; }; buildInputs = [ haskell.compiler.ghc844 spass ]; patches = [ ./patch.patch # Since the LTS 12.0 update, <> is an operator in Prelude, colliding with # the <> operator with a different meaning defined by this package ./monoid.patch ]; postPatch = '' substituteInPlace Alice/Main.hs --replace init.opt $out/init.opt ''; installPhase = '' mkdir -p $out/{bin,provers} install alice $out/bin install provers/moses $out/provers substituteAll provers/provers.dat $out/provers/provers.dat substituteAll init.opt $out/init.opt cp -r examples $out ''; inherit spass; meta = { description = "A program for automated proving of mathematical texts"; longDescription = '' The system for automated deduction is intended for automated processing of formal mathematical texts written in a special language called ForTheL (FORmal THEory Language) or in a traditional first-order language ''; license = lib.licenses.gpl3Plus; maintainers = [ lib.maintainers.schmitthenner ]; homepage = "http://nevidal.org/sad.en.html"; platforms = lib.platforms.linux; broken = true; # ghc-8.4.4 is gone from Nixpkgs }; } </del>

Discussion:
There's two "sad" packages, with one being not used at-all top-level/all- in a text-editor (as of writing but beware this will lag, so open it locally) at this comment: at this what happened Should be just one We should just drop the old pkg's nix files after notifying the maintainer of the old package, but I'm opening this issue for discussion, because there might be more left to cleanup. Perhaps we should check if we have files in-tree that are no longer being referenced and do a prune of those files (and maybe check it in ci afterwards, or at least occasionally during hydra builds). <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --
The package of which I'm the maintainer has nothing to do with the other package, these are completely different packages. I am not using this application anymore, it is commented (and probably broken) since at least and , which were committed in July 2020. This is nearly 3 years ago. I'm not maintaining it anymore. So yes, let's remove it. I think deleting the folder and the commented reference in all- should remove all references to it.
Change:
<del> From 1f83963f59960150e8c46112daa8411324c1f209 Mon Sep 17 00:00:00 2001 From: Jiri Slaby <jslaby@suse.cz> Date: Fri, 18 Aug 2023 08:26:20 +0200 Subject: [PATCH] exclude: fix crashes with fortified strlcpy() Fortified (-D_FORTIFY_SOURCE=2 for gcc) builds make strlcpy() crash when its third parameter (size) is larger than the buffer: $ rsync -FFXHav '--filter=merge global-rsync-filter' Align-37-43/ xxx sending incremental file list *** buffer overflow detected ***: terminated It's in the exclude code in setup_merge_file(): strlcpy(y, save, MAXPATHLEN); Note the 'y' pointer was incremented, so it no longer points to memory with MAXPATHLEN "owned" bytes. Fix it by remembering the number of copied bytes into the 'save' buffer and use that instead of MAXPATHLEN which is clearly incorrect. Fixes #511. --- exclude.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/exclude.c b/exclude.c index ffe55b167..1a5de3b9e 100644 --- a/exclude.c +++ b/exclude.c @@ -720,7 +720,8 @@ static BOOL setup_merge_file(int mergelist_num, filter_rule *ex, parent_dirscan = True; while (*y) { char save[MAXPATHLEN]; -		strlcpy(save, y, MAXPATHLEN); +		/* copylen is strlen(y) which is < MAXPATHLEN. +1 for 0 */ +		size_t copylen = strlcpy(save, y, MAXPATHLEN) + 1; *y = '0'; dirbuf_len = y - dirbuf; strlcpy(x, ex->pattern, MAXPATHLEN - (x - buf)); @@ -734,7 +735,7 @@ static BOOL setup_merge_file(int mergelist_num, filter_rule *ex, lp->head = NULL; } lp->tail = NULL; -		strlcpy(y, save, MAXPATHLEN); +		strlcpy(y, save, copylen); while ((*x++ = *y++) != '/') {} } parent_dirscan = False; </del>

Discussion:
Package name: Latest released version: <!-- Search your package here: --- Current version on the unstable channel: Current version on the stable/release channel: <!-- Type the name of your package and try to find an open pull request for the package If you find an open pull request, you can review it! There's a high chance that you'll have the new version right away while helping the community! --- Notify maintainers <!-- If the result shows no maintainers, tag the person that last updated the package. --Note for maintainers: Please tag this issue in your PR. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
done in
Change:
<ins> /* This is a minimal/manual luarocks derivation used by `buildLuarocksPackage` to install lua packages. As a nix user, you should use the generated lua.pkgs.luarocks that contains a luarocks manifest which makes it recognizable to luarocks. Generating the manifest for luarocks_bootstrap seemed too hackish, which is why we end up with two "luarocks" derivations. */ </ins> { lib , stdenv , fetchFromGitHub

Discussion:
luarocks exists that other luarocks packages can depend on. When trying to build a rockspec that depends on luarocks with , it fails. The entry in the generated luarocks config contains an entry for luarocks, but luarocks doesn't recognise it and tries to download the package instead. I have created a repository to reproduce it with: Run A workaround is to use to generate a expression for luarocks (), and to add that package to the 's instead of the package from nixpkgs. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
thanks for creating the test repo, it's helpful. I've looked at the generated LUAROCKSCONFIG and all looks good and I think luarocks just doesn't recognize the installed luarocks because of My first thought would have been to rename the current luarocks into a luarocksbootstrap and add a generated derivation, for which we could run the tests without the cyclic dependency luarocks -busted -luarocks. While this might be the best outcome longterm, I am looking into the quickfix which would be to generate the manifest for the current luarocks
Change:
in buildNodejs { inherit enableNpm; <del> version = "16.6.0"; sha256 = "1ndrqx3k5m62r7nzl5za59m33bx10541n7xbaxxz7088ifh18msw"; </del> <ins> version = "16.5.0"; sha256 = "16dapj5pm2y1m3ldrjjlz8rq9axk85nn316iz02nk6qjs66y6drz"; patches = [ # Fix CVE-2021-22930 https://github.com/nodejs/node/pull/39423. # It should be fixed by Node.js 16.6.0, but currently it fails to build on Darwin (fetchpatch { url = "https://github.com/nodejs/node/commit/9d950a0956bf2c3dd87bacb56807f37e16a91db4.patch"; sha256 = "1narhk5dqdkbndh9hg0dn5ghhgrd6gsamjqszpivmp33nl5hgsx3"; }) ]; </ins> }

Discussion:
trying to build nodejs 16.6 on darwin I get the following error This error seems to be fixed by adding as a buildinput. however trying to build after that I get another error which I think is coming from the warning darwin is still on llvm 7. There is an effort at the moment to update it to llvm 11, but it might take some more time. I don't understand how to fix the c++ compiler version. Should it not be fixed to something higher than 7 rather than relying on the default stdenv one? I'm happy to test whatever ideas you have Please run and paste the result. Maintainer information:
There is an issue that was opened on nodejs for this actually it basically says that this requires xcode 11 to build. I noticed we are using xcbuild which is read only at this point. I wonder if it's just a matter of updating to the latest os version. I will try that this weekend.
Change:
<del> { libsForQt5 , stdenv , lib , fetchFromGitHub , cmake , nix-update-script , fetchpatch , grim , makeBinaryWrapper , enableWlrSupport ? false </del> <ins> { stdenv, lib, overrideSDK, darwin, fetchFromGitHub, fetchpatch, cmake, imagemagick, libicns, libsForQt5, grim, makeBinaryWrapper, nix-update-script, enableWlrSupport ? false, enableMonochromeIcon ? false, </ins> }: <del> stdenv.mkDerivation { </del> <ins> assert stdenv.isDarwin -> (!enableWlrSupport); let stdenv' = if stdenv.isDarwin then overrideSDK stdenv "11.0" else stdenv; in stdenv'.mkDerivation { </ins> pname = "flameshot"; # wlr screenshotting is currently only available on unstable version (>12.1.0) version = "12.1.0-unstable-2024-08-02";

Discussion:
Steps to reproduce the behavior: on Darwin flameshot Happy to test fixes or provide any other information that I can
relevant excerpt:
Within the directory I just see rather than the binary itself. Perhaps we need something like this in the installPhase?
Change:
{ lib , stdenv , fetchFromGitHub <ins> , fetchpatch </ins> , nix-update-script , pkg-config , meson

Discussion:
After updating to 21.11, the animation for directly switching between workspaces looks really bad. (I hope this isn't normal behaviour with Pantheon 6?) Steps to reproduce the behavior: NixOS 21.05 w/ Pantheon workspace switching NixOS 21.11 w/ Pantheon workspace switching Smooth workspace switching like on 21.05. Before: After: Add any other context about the problem here. Please run and paste the result. Maintainer information:
I can reproduce this on NixOS 21.11: you mean the grey space between the workspaces, right? ! can you reproduce this too? I think the best way forward would be an upstream issue, since we can't do much about this (i think).
Sorry for not being more specific, I was in a hurry to get some assignments done until midnight. I meant the way the workspace doesn't finish smoothly sliding in, instead opting to jump into place once it reaches the last sixth of the screen. This jumpiness is also present in your recording. But maybe this grey space is caused by the same underlying problem, I don't know. This looks very distracting coming from 21.05 where it was fully smooth. And it looks even more wrong because going to the workspace overview first (<kbdSuper</kbd+ <kbd↓</kbd) and then switching workspaces shows a completely smooth animation as expected. That's why I reported it here, because I assumed they wouldn't have shipped that in their own distro considering all the other animations are smooth.
Yes, that's quiet a difference.
FYI there is , not sure if that is the problem described here. When doing Pantheon 7 upgrade, I guess I will be more careful when choosing mutter versions and just use what elementary is using :-(
I doubt they will fix it anytime soon. Focal might be stuck with mutter3.36.
36.4 should be pretty same story as this so just replacing it would fix it gonna give it try