jiebi/CodeConvo huggingface dataset:
Change:
, esbuild , pkg-config , libsecret <ins> , stdenv , darwin </ins> , setDefaultServerPath ? true }:

Discussion:
has been broken on since with build log failures that look like (excerpting from ): Another patch , fixed a related issue but did not fix the keytar dependency on Darwin. Fortunately, adding the necessary frameworks as conditional-on-darwin nativeBuildInputs in a manner similar to the way that is by fixes things here too. (PR incoming once I finish writing it up.) (and as a courtesy, though I know she has recently stepped down from maintaining the vscode extension)
Change:
optifine = optifinePackages.optifine-latest; <del> optipng = callPackage ../tools/graphics/optipng { libpng = libpng12; }; </del> <ins> optipng = callPackage ../tools/graphics/optipng { }; </ins> olsrd = callPackage ../tools/networking/olsrd { };

Discussion:
when trying to optimize a file larger than 8MB, then invoking OptiPNG on it again (such as from an "all files" script", it fails with a Warning with random text. trying to said warning results in the image getting permanently corrupted. this is probably because pulls in that uses libpng 1.2.59 and not which uses libpng 1.6.39 Steps to reproduce the behavior: a very large PNG file - 8MB or higher should work. to optimize the file using OptiPNG to optimize the file again. has a "recoverable error". says libpng 1.2.59, instead of a newer version. files to not be corrupted, optipng -v outputing a version of libpng newer than 1.2.59 how about logshots see i suspect the file too large causing problems part will apply to any software that uses this libpng. maybe deprecate the package? Please run and paste the result.
This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
goshdarnit where's my :wave: emote
Change:
certifi = callPackage ../development/python-modules/certifi { }; certipy = callPackage ../development/python-modules/certipy {}; characteristic = callPackage ../development/python-modules/characteristic { }; chart-studio = callPackage ../development/python-modules/chart-studio { };

Discussion:
The soapysdr package contains a Python binding, but it is not possible to use it normally (e.g. via ) because it is not registered as a Python package in nixpkgs. I am not sure what is the proper way of handling this case, since soapysdr is both a regular library and a Python package, and nixpkgs makes a distinction between the two. A workaround is to add. Cc
See the section "15.17.2.2.4. toPythonModule function" in the Nixpkgs manual.
Change:
''; }; <del> memoryMax = mkOption { </del> <ins> memoryMax = lib.mkOption { </ins> default = null; <del> type = with types; nullOr int; </del> <ins> type = with lib.types; nullOr int; </ins> description = lib.mdDoc '' Maximum total amount of memory (in bytes) that can be stored in the zram swap devices.

Discussion:
Project description In the author says, In 2020 the zram-generator doesn't seem to have had any releases. In the meantime, it's gone from initial release version 0.2.0 up to the somewhat-mature version 1.1.2. It's probably a good time to port this to zram-generator. Metadata homepage URL: source URL: license: mit platforms: linux
Change:
libmysofa = callPackage ../development/libraries/audio/libmysofa { }; <del> libmysqlconnectorcpp = callPackage ../development/libraries/libmysqlconnectorcpp { mysql = mysql57; }; </del> <ins> libmysqlconnectorcpp = callPackage ../development/libraries/libmysqlconnectorcpp { }; </ins> libnatpmp = callPackage ../development/libraries/libnatpmp { };

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:
}; cmp-git = super.cmp-git.overrideAttrs { <del> dependencies = with self; [ nvim-cmp curl git ]; </del> <ins> dependencies = with self; [ nvim-cmp ]; </ins> }; cmp-greek = super.cmp-greek.overrideAttrs {

Discussion:
Many cmp-* plugins have dependencies like curl, fish, tmux etc. But those are not plugins. In result those programs are to nvim runtimepath. Looks like it was introduced by Steps to reproduce the behavior: package e.g. -pack-dir now contains curl and git directories. Binaries should not be linked to runtimepath. Paths to binaries should be replaced in plugin source code or to nvim's PATH (does it work with propagatedBuildInputs?). If applicable, add screenshots to help explain your problem. Add any other context about the problem here. <!-- 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.
Change:
, nixosTests }: let <del> # Seahub 8.x.x does not support django-webpack-loader >=1.x.x </del> python = python3.override { packageOverrides = self: super: { <del> django-webpack-loader = super.django-webpack-loader.overridePythonAttrs (old: rec { version = "0.7.0"; src = old.src.override { inherit version; hash = "sha256-ejyIIBqlRIH5OZRlYVy+e5rs6AgUlqbQKHt8uOIy9Ec="; }; }); </del> <ins> django = super.django_3; </ins> }; }; in python.pkgs.buildPythonApplication rec { pname = "seahub"; <del> version = "9.0.10"; </del> <ins> version = "10.0.1"; </ins> pyproject = false; src = fetchFromGitHub { owner = "haiwen"; repo = "seahub"; <del> rev = "5971bf25fe67d94ec4d9f53b785c15a098113620"; # using a fixed revision because upstream may re-tag releases :/ sha256 = "sha256-7Exvm3EShb/1EqwA4wzWB9zCdv0P/ISmjKSoqtOMnqk="; </del> <ins> rev = "e8c02236c0eaca6dde009872745f089da4b77e6e"; # using a fixed revision because upstream may re-tag releases :/ sha256 = "sha256-7JXWKEFqCsC+ZByhvyP8AmDpajT3hpgyYDNUqc3wXyg="; </ins> }; patches = [

Discussion:
I upgraded to NixOS 23.11 from 23.05 and I didn't touch seafile configuration files. Now Seahub doesn't start anymore. Steps to reproduce the behavior: to NixOS 23.11 fails Seahub should start normally, the same as NixOS 23.05. <!-- 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]:
After searching more about this issue, I found , which should solve this once merged.
Change:
}); <ins> sphinxcontrib_plantuml = buildPythonPackage (rec { name = "sphinxcontrib-plantuml-0.5"; # See issue #6548 disabled = isPyPy; src = pkgs.fetchurl { url = "https://pypi.python.org/packages/source/s/sphinxcontrib-plantuml/${name}.tar.gz"; md5 = "4a8840fe3475a19c2af3fa877ab9d296"; }; propagatedBuildInputs = with self; [sphinx plantuml]; meta = { description = "Provides a Sphinx domain for embedding UML diagram with PlantUML"; homepage = http://bitbucket.org/birkenfeld/sphinx-contrib; license = "BSD"; }; }); </ins> sphinx_pypi_upload = buildPythonPackage (rec { name = "Sphinx-PyPI-upload-0.2.1";

Discussion:
The package pypy2.4-Sphinx-1.2.3 appears to be broken in the stable channel (as well as in the master branch of the repository with pypy 2.5). My $ load-env-pypySphinx $ sphinx-quickstart
Interesting, only happens on pypy. Wrapper is not generated.
Fixed hopefully.
Tested with pypy 2.5. The sphinx-quickstart works and building a non trivial set of documentation also. Thank you.
Change:
<ins> --- a/libgnome-desktop/gnome-desktop-thumbnail-script.c +++ b/libgnome-desktop/gnome-desktop-thumbnail-script.c @@ -504,14 +504,10 @@ g_return_val_if_fail (script->s_infile != NULL, FALSE); add_args (array, -	    "bwrap", -	    "--ro-bind", "/usr", "/usr", -	    "--ro-bind", "/lib", "/lib", -	    "--ro-bind", "/lib64", "/lib64", +	    "@BUBBLEWRAP_BIN@", +      "--ro-bind", "/nix/store", "/nix/store", "--proc", "/proc", "--dev", "/dev", -	    "--symlink", "usr/bin", "/bin", -	    "--symlink", "usr/sbin", "/sbin", "--chdir", "/", "--setenv", "GIO_USE_VFS", "local", "--unshare-all", </ins>

Discussion:
Once you take a video with cheese (as webm), a few strange things happen: No thumbnails for images or videos will load. Cheese will refuse to close without a 'kill/killall .cheese-wrapped' Errors: video in cheese. cheese via 'Quit' button OR by closing the window Check (cheese will still be running) and taking up quite a bit of CPU. Normal behavior is returned once webm file is moved or deleted. Cheese doesn't understand webm yet tries to record as webm. Then every attempt at loading the webm in the preview pane causes an error. Maybe a dependency issue and we should depend on some webm support library? Or an upstream issue with Cheese itself? System: 16.09.1445. (Flounder); 16.03.885. (Emu) Nix version: nix-env (Nix) 1.11.4; nix-env (Nix) 1.11.2 Nixpkgs version: 16.09.1445.; 16.03.885. Cheese version: 3.20.2; 3.18.1
Updated. Still an issue in 16.09.
I can reproduce the problems with thumbnails and webm-related issues on 17.03 and master. It doesn't seem to crash on exit in my testing. Playing with gets problems with missing to disappear, adding gstreamer bits (like is done in totem or sushi) doesn't seem to be sufficient (I'm no expert here). Related: (?).
I opened an upstream issue:
Running cheese with environment variable revealed missing path to bubblewrap. After patching , user still needs to have thumbnailers ( and ) installed, for now I have them as dependencies like I did in . The infinite loop is still an upstream bug but with thumbnailers, it at least should not appear.
Change:
in stdenv.mkDerivation rec { pname = "mattermost-desktop"; <del> version = "4.5.0"; </del> <ins> version = "4.5.2"; </ins> src = if stdenv.hostPlatform.system == "x86_64-linux" then fetchurl { url = "https://releases.mattermost.com/desktop/${version}/${pname}-${version}-linux-x64.tar.gz"; <del> sha256 = "1p44vxs7i9f15h4xjyr99g8x73qygv909a32lfkqip1fh8lk7sf4"; </del> <ins> sha256 = "0r9xmhzif1ia1m53yr59q6p3niyq3jv3vgv4703x68jmd46f91n6"; </ins> } else if stdenv.hostPlatform.system == "i686-linux" then fetchurl { url = "https://releases.mattermost.com/desktop/${version}/${pname}-${version}-linux-ia32.tar.gz"; <del> sha256 = "03pn853z2famqxcsrwayqb94pzghlpfb0qs2nfi8mc5zzsgcic7z"; </del> <ins> sha256 = "1h8lw06p3cqz9dkgbhfmzcrzjsir5cfhx28xm4zrmvkj4yfzbcnv"; </ins> } else throw "Mattermost-Desktop is not currently supported on ${stdenv.hostPlatform.system}";

Discussion:
Mattermost fixed a security issue in 4.5.1:
cc
thanks for bringing this up. I'll create the necessary PRs.
Change:
vendorSha256 = "sha256-y3WiQuoQn6SdwTgtPWuB6EBtsJC+YleQPzownZQNkno="; passthru.tests.nomad = nixosTests.nomad; preCheck = '' <del> export PATH="$PATH:/build/go/bin" </del> <ins> export PATH="$PATH:$NIX_BUILD_TOP/go/bin" </ins> ''; };

Discussion:
Steps to reproduce the behavior: -env -i nomad-1.5.8 Build fails for both nomad-1.5.8 and nomad-1.6.1. nomad-1.4.6 installs without build. Please run and paste the result.
thank you!
Change:
license = licenses.gpl3Plus; platforms = platforms.linux; }; <del> } </del> <ins> }) </ins>

Discussion:
Package name: Latest released version: 46.0 <!-- Search your package here: --- Current version on the unstable channel: 46.0 Current version on the stable/release channel: 46.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: Please tag this issue in your PR. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]: Fixes very annoying bug for users with nvidia dGPU notebooks on gnome using external displays. Reports of the Bug:
Change:
optionalString hasBonds "options bonding max_bonds=0"; boot.kernel.sysctl = { <ins> "net.ipv4.conf.all.forwarding" = mkDefault (any (i: i.proxyARP) interfaces); </ins> "net.ipv6.conf.all.disable_ipv6" = mkDefault (!cfg.enableIPv6); "net.ipv6.conf.default.disable_ipv6" = mkDefault (!cfg.enableIPv6); <del> "net.ipv6.conf.all.forwarding" = mkDefault (any (i: i.proxyARP) interfaces); </del> } // listToAttrs (flip concatMap (filter (i: i.proxyARP) interfaces) <del> (i: forEach [ "4" "6" ] (v: nameValuePair "net.ipv${v}.conf.${replaceChars ["."] ["/"] i.name}.proxy_arp" true))) </del> <ins> (i: [(nameValuePair "net.ipv4.conf.${replaceChars ["."] ["/"] i.name}.proxy_arp" true)])) </ins> // listToAttrs (forEach interfaces (i: let opt = i.tempAddress;

Discussion:
When setting proxyARP currently ip-routing is only set for ipv6, but not for ipv4. Set proxyARP on an interface and check wether ` is set to 1. system: host os: multi-user?: sandbox: version: channels(root): channels(louis): nixpkgs:
The description states the following: and also: But the implementation seems to neither enable forwarding for IPv6 nor for IPv6 (form ): is missing since which also broke IPv4 forwarding (completely removed since ).
It would be interesting to know the reason behind removing this in the first place. seems to state that the intention of this commit seems to have been to remove non-existent sysctl options, but clearly exists as sysctl option, so maybe something is going on here, that I'm not seeing at the moment.
I'm pretty sure that it was removed accidentally ( was a pretty big change, which can be difficult to review properly). There was a minor typo in there that is unfortunately pretty easy to miss but very important. The correct kernel parameter is (vs. with an underscore instead of a dot). Feel free to make a PR to fix this (i.e. enabling IPv4 forwarding and for IPv6, instead of ), if you have time (if you don't have time for it I can probably do this in a few days, but unfortunately I cannot test this probably at the moment).
Ok. This shouldn't take to long, so I think I can send something later.
I assume was a typo, and should have been renamed to in .
Change:
<del> { lib, stdenv, fetchurl, pkg-config, lua5, curl, quvi_scripts, libproxy, libgcrypt, glib }: stdenv.mkDerivation rec { pname = "libquvi"; version="0.9.4"; src = fetchurl { url = "mirror://sourceforge/quvi/libquvi-${version}.tar.xz"; sha256 = "1cl1kbgxl1jnx2nwx4z90l0lap09lnnj1fg7hxsxk3m6aj4y4grd"; }; nativeBuildInputs = [ pkg-config ]; buildInputs = [ lua5 curl quvi_scripts libproxy libgcrypt glib ]; meta = { description = "Web video downloader"; homepage = "http://quvi.sf.net"; license = lib.licenses.lgpl21Plus; platforms = lib.platforms.linux; maintainers = [ ]; broken = true; # missing glibc-2.34 support, no upstream activity }; } </del>

Discussion:
installs but is unusable. System: Nix version: Nixpkgs version:
I just tried to look at this a bunch and effectively got nowhere fast. Made both the lib and the tool use Lua 5.1 and the 5.1 sockets lib. Oddly in Googling around it there seems to be others elsewhere having issues with this particular combination.
Are there any updates on this issue, please?
While I'm not sure whether this solves this issue in its entirety, two things brought me a bit closer fixing it: Adding to the : Using instead of . In : I don't have any experience with Lua, though, so there might be a better solution. After doing this, I get a very different error which I had not yet the time to investigate (and which is why I didn't open a PR yet):
Hello, I'm a bot and I thank you in the name of the community for opening this issue. To help our human contributors focus on the most-relevant reports, I check up on old issues to see if they're still relevant. This issue has had no activity for 180 days, and so I marked it as stale, but you can rest assured it will never be closed by a non-human. The community would appreciate your effort in checking if the issue is still valid. If it isn't, please close it. If the issue persists, and you'd like to remove the stale label, you simply need to leave a comment. Your comment can be as simple as "still important to me". If you'd like it to get more attention, you can ask for help by searching for maintainers and people that previously touched related code and @ mention them in a comment. You can use or on the relevant files to find them. Lastly, you can always ask for help at or at .
This issue persists exactly as originally described. Unfortunately, I did not get around to investigating any further than as described by my last comment.
I marked this as stale due to inactivity. &rarr;
Change:
nativeBuildInputs = [ makeWrapper <del> cmake </del> <ins> cmake' </ins> perl python3Packages.python python3Packages.cppheaderparser

Discussion:
The build for a lot of ROCm components broke with , which updated CMake from 3.29.0 to 3.29.1, basically breaking all of ROCm. This commit was merged via and recently made its way from staging into unstable in the last few days. Steps to reproduce the behavior: The builds for a number of ROCm components now fail with error messages like the following: This is possible related to how ROCm uses of CMake incorrectly. See , , and I have posted about this issue on the CMake discourse to verify if this is considered a bug in CMake, as suggested by <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
The first recommendation we got from CMake was updating to 3.29.2, which has already been merged to staging:
I was able to confirm that with that commit that updates CMake to 3.29.2 builds again. I will leave this issue open until the relevant changes make it into unstable.
is there an easy way to temporarily use the cmake version from staging in my configuration for a specific package, without using staging for every dependency of that package?
A workaround could be to apply this as patch:
One possible fix would be overriding the CMake version that is used inside of ROCm to update to the newer version, and merging that with a PR to master. The advantage of this compared to would be that we do not need to worry about the fix actually breaking the build once the version update lands (I have not tested that this happens, but I could imagine it does). It might be a good idea to do this by making the overridden version of a part of , and removing extra dependency on elsewhere in ROCm. Also ROCm 5.7 and 6.0 are both broken, so if we want to merge a fix before the CMake version update lands in unstable, we should fix both. I am not working on a fix for this, and I couldn't merge one, but I'm happy to review PRs.
Change:
umount /tmp/shared ''; <ins> systemd.services.oncalendar-test = { description = "calendar test"; # Japan does not have DST which makes the test a little bit simpler startAt = "Wed 10:00 Asia/Tokyo"; script = "true"; }; </ins> systemd.services.testservice1 = { description = "Test Service 1"; wantedBy = [ "multi-user.target" ];

Discussion:
Describe the bug The field of systemd timer units is treated as UTC, even if a different timezone is specified. To Reproduce a trivial service and make it start at midnight on some non-UTC timezone: and observe that the field says midnight UTC (in my case, ). Expected behavior In this case, the field should say (or ). Additional context I have tested this with two different non-UTC timezones. on the same machine gives the correct result, so this is linked to timer units. I am using the systemd package from the NixOS 20.09 release, version 246. I could not reproduce the issue on an Arch Linux server (systemd 246.4-1-arch), so it's (probably) a NixOS problem. Notify maintainers Metadata
Maybe our patch in (from ) isn't sufficient and this needs to be patched in another location, too?
Note that if I specify a timezone that doesn't exist, I get an error on activation. So presumably it can find the timezone info, it just doesn't respect it.
Can you reproduce on non-NixOS?
Nope, see the fourth bullet point under Additional context.
I was able to reproduce this on NixOS, and verified it works correctly on Archlinux. I still don't understand why it behaves the way it does (it seems we did properly patch all occurences this might touch). This might require some deeper digging into the codebase, and adding some logs along the way to see what's going on.
I marked this as stale due to inactivity. &rarr;
Not stale, but help welcome ;-)
I haven't had time to test this but a cursory reading of the systemd code shows that it uses : tzset uses TZDIR. On a normal nixos system I get this: but pid 1 doesn't set TZDIR:
I confirmed TZDIR is the issue by applying the following patch. I think my fix is wrong but I couldn't figure out where in systemd pid 1 I should set env vars so I did id in a function that I know will be called. without patch: with patch: unit used:
I wonder if this is related to and
Yeah, this looks about right. Maybe we should see if we can steer glibc to look for zoneinfo in these two paths by default, instead of in the glibc output directly.
Change:
rustPlatform.buildRustPackage rec { pname = "rust-analyzer-unwrapped"; <del> version = "2021-04-19"; cargoSha256 = "sha256-CXkI3CQ/v6RBMM2Dpp2u+qnRwba+nqzeaPSJGBiQUoY="; </del> <ins> version = "2021-05-10"; cargoSha256 = "sha256-PUecBFdYIJFZa5IwwNnuXOkuxtyrzWhxy3C+2jv/hvU="; </ins> src = fetchFromGitHub { owner = "rust-analyzer"; repo = "rust-analyzer"; rev = version; <del> sha256 = "sha256-W/cUwZEvlUXzqQ/futeNFwDWR/cTL/RLZaW2srIs83Q="; </del> <ins> sha256 = "sha256-oz6FqRMEUUTS4X2XhpWjp2JIgl1A6wQv2OU8auwUoVM="; </ins> }; <ins> patches = [ # Revert updates which require rust 1.52.0. # We currently have rust 1.51.0 in nixpkgs. # https://github.com/rust-analyzer/rust-analyzer/pull/8718 (fetchpatch { url = "https://github.com/rust-analyzer/rust-analyzer/pull/8718/commits/607d8a2f61e56fabb7a3bc5132592917fcdca970.patch"; sha256 = "sha256-g1yyq/XSwGxftnqSW1bR5UeMW4gW28f4JciGvwQ/n08="; revert = true; }) (fetchpatch { url = "https://github.com/rust-analyzer/rust-analyzer/pull/8718/commits/6a16ec52aa0d91945577c99cdf421b303b59301e.patch"; sha256 = "sha256-n7Ew/0fG8zPaMFCi8FVLjQZwJSaczI/QoehC6pDLrAk="; revert = true; }) ]; </ins> buildAndTestSubdir = "crates/rust-analyzer"; cargoBuildFlags = lib.optional useMimalloc "--features=mimalloc";

Discussion:
Describe the bug There seems to be a bug currently with the package in the unstable channel. It seems like it was fixed in later versions. So, this bug report is intended to shed light on it, in the hopes that it gets updated. Right now, rust-analyzer will produce the following error (in version 2021-04-19): To Reproduce Steps to reproduce the behavior: to channel run in a rust project, or use the vscode extension and watch the output Expected behavior It shouldn't produce the error, and work as intended. Screenshots If applicable, add screenshots to help explain your problem. Additional context I asked in the zulip, and they said that it's a bug that has been fixed in newer versions. 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: