jiebi/CodeConvo huggingface dataset:
Change:
"DatabaseAdminClientTest.VersionRetentionPeriodCreateFailure", "DatabaseAdminClientTest.VersionRetentionPeriodUpdate", "DatabaseAdminClientTest.VersionRetentionPeriodUpdateFailure", <ins> "ErrorParsingIntegrationTest.FailureContainsErrorInfo", "GrpcServiceAccountIntegrationTest.GetServiceAccount", "GrpcBucketMetadataIntegrationTest.ObjectMetadataCRUD", </ins> "InstanceAdminClientTest.InstanceConfig", "InstanceAdminClientTest.InstanceIam", "InstanceAdminClientTest.InstanceReadOperations", "LoggingIntegrationTest.ListMonitoredResourceDescriptors", "LoggingIntegrationTest.WriteLogEntries", "ObjectFileMultiThreadedTest.Download", <ins> "ObjectReadLargeIntegrationTest.LimitedMemoryGrowth", </ins> "SubscriberIntegrationTest.FireAndForget", "SubscriberIntegrationTest.PublishOrdered", "SubscriberIntegrationTest.PublishPullAck",

Discussion:
name: google-cloud-cpp current version: 1.38.0 desired version: 1.42.0 maintainers: who did the last update Please tag this issue in your PR.
I don't have time to work on this at the moment.
Change:
checkPhase = '' runHook preCheck <del> meson test --no-rebuild --verbose --timeout-multiplier 6 </del> <ins> meson test --no-rebuild --verbose --timeout-multiplier 12 </ins> runHook postCheck '';

Discussion:
Steps to reproduce the behavior: and test gst-plugins-rs on Hydra Tests time out when building gst-plugins-rs on Hydra. This was reported to occur on Darwin in , but also occurs on Linux as well. Currently, there is no up-to-date build for aarch64-linux in See intermittent Hydra failures
Oof the tests timed out on aarch64 on one and livesync plugin test failed on the other. I guess I'll make that timeout longer and disabled livesync on aarch64. PR incoming in the next hour or so Darwin timed out in ofborg on the PR for other reasons (ofborg's internal timeout, not the timeout I set on the tests). It successfully built on Hydra after merging and I had tested it locally
For reference, this was the test failure on livesync on aarch64: I'll follow-up with the gstreamer folks later and figure out what's going on with the livesync test (more uninitialized memory usage in like in maybe )
Oh hey it's actually already been reported upstream. I'll just disable it across all platforms then and will re-enable when that issue is resolved
I've opened Thank you for reporting! (I've been checking every couple days, but hadn't in several days so missed the failure)
Change:
<del> { stdenv, fetchurl, fetchpatch, autoreconfHook, libunwind }: </del> <ins> { stdenv, lib, fetchurl, fetchpatch, autoreconfHook, libunwind }: </ins> stdenv.mkDerivation rec { name = "gperftools-2.8";

Discussion:
Describe the bug A clear and concise description of what the bug is. I can't install mongodb in mac OS. I get the following errors when using nix shell and the following if I do a vanilla install To Reproduce try installing mongodb by and observe the error. Expected behavior Should be able to install mongodb on mac os. Screenshots If applicable, add screenshots to help explain your problem. Additional context Add any other context about the problem here. 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. system: host os: multi-user?: sandbox: version: channels(root): channels(ashkanaleali): nixpkgs:
I'm not an expert but the error message seems to mean that the underlying issue is building gperftools. Also I don't have darwin so yeah.
Yes, this is a build failure of gperftools - assigning (maintainer)
I don't use macOS, gperftools or MongoDB so I don't know why I was tagged. I'm going to unsubscribe but feel free to tag me back in if I can somehow be of assistance.
It to be a recent regression. I don't have any macOS and don't know the platform well. If you add to the nix command, perhaps that will be helpful.
Can you/someone test?
I confirm that removing from fixes the build of on Darwin.
Change:
(fetchpatch { name = "fix-grayscale-anialias.patch"; url = "https://gitlab.freedesktop.org/cairo/cairo/-/commit/4f4d89506f58a64b4829b1bb239bab9e46d63727.diff"; <del> sha256 = "sha256-mbTg67e7APfdELsuMAgXdY3xokWbGtHF7VDD5UyYqKM="; </del> <ins> hash = "sha256-mbTg67e7APfdELsuMAgXdY3xokWbGtHF7VDD5UyYqKM="; </ins> }) ];

Discussion:
Steps to reproduce the behavior: (My is rooted at so it cannot use prebuilt binaries.) Relevant excerpt: The URL of CVE-2020- is now dead. See Added by in Please run and paste the result.
Change:
peer1 = { privateKey = "uO8JVo/sanx2DOM0L9GUEtzKZ82RGkRnYgpaYc7iXmg="; <del> publicKey = "Ks9yRJIi/0vYgRmn14mIOQRwkcUGBujYINbMpik2SBI="; </del> <ins> # readFile'd keys may have trailing newlines, emulate this publicKey = "Ks9yRJIi/0vYgRmn14mIOQRwkcUGBujYINbMpik2SBI=n"; </ins> }; }

Discussion:
If a contains newlines, e.g. when using , this bit of code in doesn't substitute the newline, and nix fails with an error like "store path contains illegal character ' '". Steps to reproduce the behavior: newline is replaced with some useful character maybe
May be related to

Describe the bug If a has a linebreak (), then it will fail when building with the following To Reproduce Use something like Expected behavior Somewhat expect it to remove suffix "n", but not entirely sure if this should be fixed. Screenshots If applicable, add screenshots to help explain your problem. Additional context Add any other context about the problem here. Fixed by doing Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Hope it is OK I tag you, just to have a discussion about it: Metadata Please run and paste the result. Maintainer information:
I don't think that the wireguard module should concern itself with this kind of thing, attempting to santise or modify user input here seems like a somewhat sisyphean task that will result in unexpected behaviour and unnesscessary maintaince overhead. As a side note are you aware of ?
But shouldn't the type just not allow linebreaks?
Which one of the would you use for this?
Hmm. well it should be OK I guess. I thought str would not allow newlines. However a option could be to add to this :) Or assert a error if it contains newlines, so that it does not fail silently.
Change:
export MOZILLA_OFFICIAL=1 '' + lib.optionalString stdenv.hostPlatform.isMusl '' # linking firefox hits the vm.max_map_count kernel limit with the default musl allocator <ins> # TODO: Default vm.max_map_count has been increased, retest without this </ins> export LD_PRELOAD=${mimalloc}/lib/libmimalloc.so '';

Discussion:
Applications are starting to allocate more times than allowed by the default value of vm.maxmapcount, . For instance, this situation arises in applications such as Ryujinx () and newer Windows games like Hogwarts Legacy (). SteamOS has already addressed this matter by augmenting the aforementioned value, while Fedora intends to implement the same modification in Fedora 39 (, ).
Please feel free to send PRs, it's hard to track those issues as you don't mention any owner.
The line to add is: The questions are: How big should n be? ? ? In which file should I add it? At the bottom of
You mentioned other distros were thinking about bumping it, let's follow Fedora lead In the relevant file, a quick grep shows indeed that sysctl is one of the best candidate. :)
For the policy discussion: I'm all in favor of doing this soon(m). It is not really dangerous and as people have explained to me the previous default has been there for historical reasons and 32 bit systems.
Change:
<ins> { lib, buildNimPackage, fetchFromGitHub, }: buildNimPackage (finalAttrs: { pname = "nph"; version = "0.6.0"; src = fetchFromGitHub { owner = "arnetheduck"; repo = "nph"; rev = "v${finalAttrs.version}"; hash = "sha256-9t5VeGsxyytGdu7+Uv/J+x6bmeB5+eQapbyp30iPxqs="; }; lockFile = ./lock.json; checkPhase = '' runHook preCheck $out/bin/nph tests/before diff tests/before tests/after -x "*.yaml" runHook postCheck ''; meta = { description = "Opinionated code formatter for Nim"; homepage = "https://github.com/arnetheduck/nph"; license = lib.licenses.mit; maintainers = with lib.maintainers; [ sigmanificient ]; mainProgram = "nph"; }; }) </ins>

Discussion:
Project description An opinionated code formatter for Nim, following the great tradition of black, prettier, clang-format and more. Metadata homepage URL: source URL: license: mit platforms: unix, linux, darwin
Change:
fingerprint = "1127 F188 280A E312 3619  3329 87E1 7EEF 9B18 B6C9"; }]; }; <ins> zeorin = { name = "Xandor Schiefer"; email = "me@xandor.co.za"; matrix = "@zeorin:matrix.org"; github = "zeorin"; githubId = 1187078; keys = [{ fingerprint = "863F 093A CF82 D2C8 6FD7  FB74 5E1C 0971 FE4F 665A"; }]; }; </ins> zeratax = { email = "mail@zera.tax"; github = "zeratax";

Discussion:
Project description <!-- Describe the project a little: --A DAP-based JS debugger built for VSCode. Can be built standalone and used with other editors that support the Debug Adapter Protocol. Supercedes For example used standalone in Neovim via Metadata homepage URL: source URL: license: mit platforms: unix, linux, darwin Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
I created a PR: Your :+1:'s and reviews would be appreciated.
Change:
stdenv.mkDerivation rec { pname = "ibus-bamboo"; <del> version = "0.7.8"; </del> <ins> version = "0.8.2-rc18"; </ins> src = fetchFromGitHub { owner = "BambooEngine"; repo = pname; <del> rev = "v${version}"; sha256 = "sha256-H7me34KfhDD7BNEEKkhYXo9DLeclO7N19e961BOh1Ho="; </del> <ins> rev = "v" + lib.toUpper version; sha256 = "sha256-5FSGPUJtUdYyeqJenvKaMIJcvon91I//62fnTCXcdig="; </ins> }; nativeBuildInputs = [

Discussion:
Current version on NIXOS 0.7.7 New version from source 0.8.1-RC4
Ping to as maintainer. v0.8.1 is available.
hi will work on this on weekend
Thanks. :) But no pressure, I was just scrolling though older open issues.
This can be closed after this MR is merged.
Thanks! You can add to your PR description and the issue will be closed automatically on merge.
Change:
, wrapQtAppsHook , gst_all_1 , testers <del> , crow-translate </del> }: <del> stdenv.mkDerivation rec { </del> <ins> stdenv.mkDerivation (finalAttrs: { </ins> pname = "crow-translate"; <del> version = "2.11.1"; </del> <ins> version = "3.0.0"; </ins> <del> src = fetchzip { url = "https://github.com/${pname}/${pname}/releases/download/${version}/${pname}-${version}-source.tar.gz"; hash = "sha256-1rq1pF4tOaZNEaHflxlBuHta80EzD9m3O99geR1EPxE="; </del> <ins> src = fetchFromGitLab { domain = "invent.kde.org"; owner = "office"; repo = "crow-translate"; rev = "v${finalAttrs.version}"; hash = "sha256-hdrhxbv44DlxoF1JU1d2auP/vR8a3IJI+hN7PhdPMaY="; fetchSubmodules = true; </ins> }; postPatch = '' <del> substituteInPlace data/io.crow_translate.CrowTranslate.desktop  --replace "Exec=qdbus" "Exec=${lib.getBin qttools}/bin/qdbus" </del> <ins> substituteInPlace data/org.kde.CrowTranslate.desktop.in  --subst-var-by QT_BIN_DIR ${lib.getBin qttools}/bin </ins> ''; nativeBuildInputs = [

Discussion:
Package name:crow-translate Latest released version:3.0.0 <!-- Search your package here: --- Current version on the unstable channel:2.11.1 Current version on the stable/release channel:2.11.1 <!-- 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]:
Change:
, nspr , nss , systemd <ins> , which </ins> }: let drvName = "flutter-${version}";

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: legacyPackages.x86_64-linux.flutter <!-- 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: 2.2.1 desired version: 2.5.1 <!-- 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.
Besides updating it we could setup a to easily auto update it
I opened , it's not easy to create the updateScript though, I can try adding later in another PR
Change:
quadkonsole, etc. in that the main focus is arranging terminals in grids (tabs is the most common default method, which Terminator also supports). ''; <del> homepage = "https://gnometerminator.blogspot.no/p/introduction.html"; </del> <ins> homepage = "https://github.com/gnome-terminator/terminator"; </ins> license = licenses.gpl2; maintainers = with maintainers; [ bjornfor ]; platforms = platforms.linux;

Discussion:
Project description is already packaged in nixpkgs, but the upstream project has been taken over by new maintainers who have ported it to Python 3 and are continuing development. As far as I know this new version is also used by Debian/Ubuntu (it has python3 dependencies in those distros). I have a local attempt at a new derivation and it Works For Me, but it has a patch in it which I don't think it should need. Also, maybe the original maintainer may want to do the update? If desired I can open a PR with my current state of affairs. Metadata homepage URL: license: GPL2 platforms: Linux
I have limited spare time these days (months), so please be my guest
Change:
stdenv.mkDerivation rec { pname = "igv"; <del> version = "2.8.13"; </del> <ins> version = "2.13.2"; </ins> src = fetchzip { <del> url = "https://data.broadinstitute.org/igv/projects/downloads/2.8/IGV_${version}.zip"; sha256 = "0sab478jq96iw3fv0560hrrj8qbh40r8m4ncypdb7991j9haxl09"; </del> <ins> url = "https://data.broadinstitute.org/igv/projects/downloads/${lib.versions.majorMinor version}/IGV_${version}.zip"; sha256 = "sha256-S0EoZAqjElrM/bp1p69jLuclXeUzSIuH8VsgCO6F04U="; </ins> }; installPhase = ''

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 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 as 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: desired version: <!-- 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:
/* NOTE: fetchgit has one problem: git fetch only works for refs. <del> This is because fetching arbitrary (maybe dangling) commits may be a security risk </del> <ins> This is because fetching arbitrary (maybe dangling) commits creates garbage collection risks </ins> and checking whether a commit belongs to a ref is expensive. This may change in the future when some caching is added to git (?) Usually refs are either tags (refs/tags/*) or branches (refs/heads/*)

Discussion:
Can anybody provide a pointer on why allowing dangling commits to be fetched is a security risk? I can't seem to find any details on this. Is the risk because people assume "unreachable" means "deleted"?
There's a guess in is the original author of the documentation (see )
Hrm, that guess has to do with github's PRs, not with anything in git.
Well, I found a reason why git would want to prohibit this, but it isn't related to security. If you a branch, the commit that used to point to is still available in the repository -- at least until the next happens. If people are allowed to fetch commits by their hash even when those commits are unreachable, a force-push like this would put those commits at risk of being garbage collected. But nobody would notice the breakage until (potentially) much later, when a happened, and by then it will be too late to recover the lost commit. But since users are forced to mention a commit from which their desired ref is reachable, they will notice the breakage immediately. Most important of all, they will notice while there is probably still time to rescue the now-gc-able commit. I think this is the reason. If nobody else can come up with a security-related explanation I'm going to submit a PR to remove the word "security" in .
Change:
{ lib, stdenv, fetchFromGitHub, meson, ninja, pkg-config, scdoc <del> , systemd, pango, cairo, gdk-pixbuf, jq </del> <ins> , systemd, pango, cairo, gdk-pixbuf, jq, bash </ins> , wayland, wayland-protocols , wrapGAppsHook }:

Discussion:
Mako needs to have in while running in order to use the action after an event. From : Using mako the recommended way (installing the package and letting D-Bus start it when needed from the D-Bus service file included in the package) results in Mako unable to use the action because is not available. It should be to the runtime dependency list in the derivation. Steps to reproduce the behavior: to set-up a mako exec action: Mako should be able to commands. N/A N/A <!-- 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]:
Change:
}; nativeBuildInputs = [ <del> scfbuild </del> <ins> scfbuild-with-fontforge-20201107 </ins> nodejs nodePackages.glob nodePackages.lodash

Discussion:
openmoji-color and openmoji-black now both take 12h to build. They are timing out on hydra Steps to reproduce the behavior: -build -A openmoji-color
Could this be the same as ? Should we switch to prebuilt fonts here too?
It could be. But in the past the build only took a minute or 2. Now it takes basically forever. I'm trying to bisect when this was introduced but bisecting timeouts is slow and error-prone.
According to is the first bad commit. That isn't particularly helpful.
I did a better bisection and got () which is much more helpful. I saw that PR but thought it seemed too old. I guess I forgot how long a staging cycle can take. cc I don't know what the best approach here is. Report the bug upstream to fontforge or openmoji? There are a lot of warnings and errors in the build so I suspect that it may be an openmoji problem and fontforge was doing its best before and working but now is failing? The command I used for reference was:
after a brief look at this fontforge has a reported regression in its ability to remove overlaps () but if openmoji is the only font that is failing because of that, maybe they're relying too much on fontforge's abliity to fix things at build time (with the latest master commits from openmoji and fontforge, the openmoji build also hangs)
I tried diffing the logs but they are basically completely different once starts. In case they are helpful to anyone here are the builds before and after that commit. (The after obviously cuts off after the "infinite loop").
Great investigation! Maybe as a short-term fix we could override fontforge for this package?
That sounds like a reasonable mitigation until a patch is available.
Bump, would really love to have openmoji available when I upgrade 21.11 -22.05!
why the thumbs down?
Bumping issues is not a helpful thing to do.
In general yes, though in this case it reminded me to fix this before 22.05 :) Here you go
I tried running bisection on fontforge itself using after applying the patch below: Unfortunately, the automatic bisection did not work for some reason. Possibly because the does not match the error message:
needs to be reported upstream
Which one though? Openmoji or fontforge?
Change:
let thunderbird-unwrapped = thunderbirdPackages.thunderbird-102; <del> version = "102.14.0"; </del> <ins> version = "102.15.0"; </ins> majVer = lib.versions.major version; betterbird-patches = fetchFromGitHub { owner = "Betterbird"; repo = "thunderbird-patches"; <del> rev = "${version}-bb39"; </del> <ins> rev = "${version}-bb40"; </ins> postFetch = '' echo "Retrieving external patches"

Discussion:
Package name: betterbird Latest released version: 102.15.0-bb40 <!-- Search your package here: --- Current version on the unstable channel: 102.14.0 Current version on the stable/release channel: 102.12.0 <!-- 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: Can you please also backport to 23.05? Please tag this issue in your PR.
Anyone who is a maintainer can put that label on which would help me tremendously because I do not have a machine with NixOS stable and cannot verify if the graphical stack works.
Thank you!
Change:
}; gegl = callPackage ../development/libraries/gegl { <del> inherit (darwin.apple_sdk.frameworks) OpenGL; }; gegl_0_4 = callPackage ../development/libraries/gegl/4.0.nix { </del> inherit (darwin.apple_sdk.frameworks) OpenCL; };

Discussion:
Describe the bug I get this: It can also be seen on hydra: successful build: (revision ) First unsuccessful build: (revision ) To Reproduce Expected behavior It should build. Notify maintainers Maintainer information:
Considering it's abandonware since there's a new version, not resolving it and just setting it as broken is perhaps best.
Or removing arch from meta.platforms. Though really, nothing should be using such ancient version these days.
See for alternative solution (dropping gegl 0.2 completely)