jiebi/CodeConvo huggingface dataset:
Change:
{ lib, fetchFromGitHub, makeDesktopItem, bambu-studio }: bambu-studio.overrideAttrs (finalAttrs: previousAttrs: { <del> version = "1.9.1"; </del> <ins> version = "2.0.0"; </ins> pname = "orca-slicer"; # Don't inherit patches from bambu-studio

Discussion:
Package name: orca-slicer Latest released version: 2.0 <!-- Search your package here: --- Current version on the unstable channel: 1.9.1 Current version on the stable/release channel: n/a <!-- 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]:
Also the current version is failing to build:
That is a beta version. I think we should follow official releases. What version are you trying to build? Building from nixpkgs master builds fine for me
The orca-slicer team has it linked as latest stable release. All I am doing with the one in unstable is just adding it to I have it set up so I can properly install unstable packages. There is no version of orca-slicer in nix stable.
I guess the "need" for the new version originates from stable slicer advertising a new release (2.0 beta) on startup - and the pretty neat new features in that beta release. (Scarf joint seams and Small area flow compensation work like a charm!) In any case, at least a the beta is easily built using
So are you telling me to build it myself or are you going to update the one in ? I ask because that code gives me an "anonymous lambda" error (whatever that is).
I was building the version in unstable but I am on 23.11 and it is throwing mesa errors. There is a PR to backport it and Bambu Studio to 23.11 to resolve this, but if they procrastinate another month+, the issue may go away with the release of 24.05.
The official 2.0 release is out :-)
I have updated the title and the details to reflect this.
A back port to 23.11 would be highly appreciated.
Update PR is out. I'll add a backport PR when it's merged
Change:
rm ldc-${version}-src/tests/d2/dmd-testsuite/fail_compilation/mixin_gc.d rm ldc-${version}-src/tests/d2/dmd-testsuite/runnable/xtest46_gc.d rm ldc-${version}-src/tests/d2/dmd-testsuite/runnable/testptrref_gc.d <ins> # test depends on current year rm ldc-${version}-src/tests/d2/dmd-testsuite/compilable/ddocYear.d </ins> '' + stdenv.lib.optionalString (!bootstrapVersion && stdenv.hostPlatform.isDarwin) '' # https://github.com/NixOS/nixpkgs/issues/34817 rm -r ldc-${version}-src/tests/plugins/addFuncEntryCall <del> '' + stdenv.lib.optionalString (!bootstrapVersion) '' echo ${tzdata}/share/zoneinfo/ > ldc-${version}-src/TZDatabaseDirFile echo ${curl.out}/lib/libcurl${stdenv.hostPlatform.extensions.sharedLibrary} > ldc-${version}-src/LibcurlPathFile </del> ''; postPatch = ''

Discussion:
Describe the bug The ldc package (1.17.0) is currently failing to build properly in the unstable branch. It looks like the following is the culprit: To Reproduce Steps to reproduce the behavior: done! Expected behavior The package should build and install cleanly. Metadata system: host os: multi-user?: sandbox: version: channels(root): channels(chrisaw): nixpkgs: cc
Right, looks like is commit introducing the failure. The relied on shell expansion which no longer happens, so we get this: Instead of this:
cc
is right. So a fix could be to use but I find the hardcoded /build quite ugly. The path doesn't need to be in /build but I put it there to make sure it's not a file used by some other process. Switching from /build to /tmp or whatever is for this reason not a good solution.
I'm not sure with the changes for structured attrs we could use shell expansion for like before. Perhaps could comment since the fix looks obvious.
Right CMake does not interpolate environment variable, this was oversight on our part. Looks like was in and I agree that hardcoding is not a good idea but the presence of feels like a hack too. What is ts purpose? If the string imports are generated by the build system, I would expect them to be found without any extra flags. And if they are generated us during bootstrapping, I would expect them to be in a separate derivation, making referencing them work without variable interpolation. If we cannot get rid of the , we should move the flag to until we can.
Looks like the flag is needed for Could we copy the file to a build system’s natural directory like or something, so that the flag could be omitted?
The flag is the only possibility to get the tzdata path into the library. See for the code in the library. Where the file is doesn't matter but I don't see any better location as $PWD for now.
Is not it possible to put it to directory or something?
Yes but I still need to get the full path to it for -J and there is no default directory so you could omit the -J if you mean that. See point 3 in .
Change:
"--enable-xml" ]; doCheck = false; <del> patches = lib.optionals (lib.versions.majorMinor php.version == "8.2" && lib.versionOlder php.version "8.2.22") [ </del> <ins> patches = lib.optionals (lib.versions.majorMinor php.version == "8.1") [ # Fix tests with libxml2 2.12 (fetchpatch { url = "https://github.com/php/php-src/commit/061058a9b1bbd90d27d97d79aebcf2b5029767b0.patch"; hash = "sha256-0hOlAG+pOYp/gUU0MUMZvzWpgr0ncJi5GB8IeNxxyEU="; excludes = [ "NEWS" ]; }) # Backport of PHP_LIBXML_IGNORE_DEPRECATIONS_START and PHP_LIBXML_IGNORE_DEPRECATIONS_END # Required for libxml2 2.13 compatibility patch. ../development/interpreters/php/php81-fix-libxml2-2.13-compatibility.patch # Fix build with libxml2 2.13+. Has to be applied after libxml2 2.12 patch. (fetchpatch { url = "https://github.com/php/php-src/commit/9b4f6b09d58a4e54ee60443bf9a8b166852c03e0.patch"; hash = "sha256-YC3I0BQi3o3+VmRu/UqpqPpaSC+ekPqzbORTHftbPvY="; }) ] ++ lib.optionals (lib.versions.majorMinor php.version == "8.2" && lib.versionOlder php.version "8.2.22") [ </ins> # Fixes compatibility with libxml2 2.13. Part of 8.3.10RC1+, 8.2.22RC1+ (fetchpatch { url = "https://github.com/php/php-src/commit/4fe821311cafb18ca8bdf20b9d796c48a13ba552.diff?full_index=1";

Discussion:
Steps to reproduce the behavior: php-simplexml-8.1.2 This happen after latest flake update Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Hydra build : and seem fine: Probably related: (fixes for 8.2 and 8.3 with same error) 1 is out of active support, so there was no backport for from upstream PS you did not ping any maintainers for that package, so they would need to notice this issue (which is unlikely)
Also causes an lsp-plugins build failure. Gonna ping maintainers.
this is fixed in master
forgive my ignorance, but what needs to happen for the fix on master to make its way to the unstable channel? I would love to be able to rebuild my system soon
fixed "lsp-plugins build failure" (it does not depend on php 8.1 version now) If your system update depends on in some other way it won't help. does not build on current master as of (2024-07-30T19:50:23Z)
Well if you only need to rebuild your system again and you don't necessarily care about the updates you're missing out on, you can try using a previous version of your file
Change:
./security/audit.nix ./security/ca.nix ./security/chromium-suid-sandbox.nix <ins> ./security/dhparams.nix </ins> ./security/duosec.nix ./security/grsecurity.nix ./security/hidepid.nix

Discussion:
Manually generating for services like nginx is error-prone and undermines the beautify of declarative configuration. It would be very helpful if services like nginx could generate their own on first initialization. This is especially helpful in the context of large deployments (with nixops, for example) where generating separate params for each server is very tedious. cc
Change:
<ins> { lib , buildPythonPackage , fetchFromGitHub , python-dateutil , ephem , pytz , pytestCheckHook }: buildPythonPackage rec { pname = "lunarcalendar"; version = "0.0.9"; format = "setuptools"; src = fetchFromGitHub { owner = "wolfhong"; repo = "LunarCalendar"; rev = "885418ea1a2a90b7e0bbe758919af9987fb2863b"; hash = "sha256-AhxCWWqCjlOroqs4pOSZTWoIQT8a1l/D2Rxuw1XUoU8="; }; propagatedBuildInputs = [ python-dateutil ephem pytz ]; nativeCheckInputs = [ pytestCheckHook ]; pythonImportsCheck = [ "lunarcalendar" ]; meta = { homepage = "https://github.com/wolfhong/LunarCalendar"; description = "A Lunar-Solar Converter, containing a number of lunar and solar festivals in China"; license = lib.licenses.mit; maintainers = with lib.maintainers; [ tomasajt ]; }; } </ins>

Discussion:
Project description Tool for producing high quality forecasts for time series data that has multiple seasonality with linear or non-linear growth. Metadata PyPI: homepage URL: source URL: license: mit platforms: x86_64-linux
Change:
src = fetchurl { # actually  https://cdist2.perforce.com/perforce/r21.2/bin.linux26x86_64/helix-core-server.tgz but upstream deletes releases url = "https://web.archive.org/web/20211118024943/https://cdist2.perforce.com/perforce/r21.2/bin.linux26x86_64/helix-core-server.tgz"; <del> sha256 = "sha256-cmIMVek4lwVYJQbW8ziABftPZ0iIoAoSpR7cKuN4I7M="; </del> <ins> sha256 = "sha256-SrfI2ZD7KDyttCd8+fo8g4UZKljYYO/SbzqrS9tAcC8="; </ins> }; sourceRoot = ".";

Discussion:
It seems there is a hash mismatch on . The current is using channel 21.05, but this is consistent in 21.11 and as well (although has a different version, but the hash mismatch exists there too). Please run and paste the result.
05 is EOL, but 21.11 and unstable can be fixed
Thanks for the quick turn-around. I'm curious why this hash changed (I'm assuming it was working prior)?
That's my concern as well. The webarchive should have made this stable.
Change:
name = "CVE-2019-12450.patch"; sha256 = "03ris8lllbb7i18qvbpqaf7xdwfz1dkskx8mb533dmwlp2ll69hg"; }) <ins> # https://gitlab.gnome.org/GNOME/glib/issues/1658 (fetchpatch { name = "CVE-2019-13012.patch"; url = "https://gitlab.gnome.org/GNOME/glib/commit/5e4da714f00f6bfb2ccd6d73d61329c6f3a08429.patch"; sha256 = "0ykfx9i1ipz06n7hvz27qw0l9hy9jslg5gqqxyfiivy81q4p7lnl"; }) </ins> ]; outputs = [ "bin" "out" "dev" "devdoc" ];

Discussion:
, (nixos-19.03) Scanned versions: nixos-19.03: . May contain false positives.
Change:
<del> <section xmlns="http://docbook.org/ns/docbook" xmlns:xlink="http://www.w3.org/1999/xlink" xml:id="sec-nginx"> <title>Nginx</title> <para> <link xlink:href="https://nginx.org/">Nginx</link> is a reverse proxy and lightweight webserver. </para> <section xml:id="sec-nginx-etag"> <title>ETags on static files served from the Nix store</title> <para> HTTP has a couple different mechanisms for caching to prevent clients from having to download the same content repeatedly if a resource has not changed since the last time it was requested. When nginx is used as a server for static files, it implements the caching mechanism based on the <link xlink:href="https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Last-Modified"><literal>Last-Modified</literal></link> response header automatically; unfortunately, it works by using filesystem timestamps to determine the value of the <literal>Last-Modified</literal> header. This doesn't give the desired behavior when the file is in the Nix store, because all file timestamps are set to 0 (for reasons related to build reproducibility). </para> <para> Fortunately, HTTP supports an alternative (and more effective) caching mechanism: the <link xlink:href="https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/ETag"><literal>ETag</literal></link> response header. The value of the <literal>ETag</literal> header specifies some identifier for the particular content that the server is sending (e.g. a hash). When a client makes a second request for the same resource, it sends that value back in an <literal>If-None-Match</literal> header. If the ETag value is unchanged, then the server does not need to resend the content. </para> <para> As of NixOS 19.09, the nginx package in Nixpkgs is patched such that when nginx serves a file out of <filename>/nix/store</filename>, the hash in the store path is used as the <literal>ETag</literal> header in the HTTP response, thus providing proper caching functionality. This happens automatically; you do not need to do modify any configuration to get this behavior. </para> </section> </section> </del>

Discussion:
This issue tracks the conversion of from Docbook to CommonMark per . If you intend to work on this conversion, please comment below! here that you intend to work on it. (Please also post if you stop working on it.) a new branch of nixpkgs master. : change to . to . the contents from Docbook to . Follow . Use existing sections for inspiration. from the folder to build the manual. the manual on your computer at after running from folder: it looks good, submit a PR and reference this issue.
Hey. I would like to work on this
Change:
runHook preInstall mkdir -p $out/Applications/Slack.app cp -R . $out/Applications/Slack.app <del> '' + lib.optionalString (!stdenv.isAarch64) '' # on aarch64-darwin we get: Could not write domain com.tinyspeck.slackmacgap; exiting /usr/bin/defaults write com.tinyspeck.slackmacgap SlackNoAutoUpdates -Bool YES '' + '' </del> runHook postInstall ''; };

Discussion:
When attempting to install , installation fails with the following error: As noted in , the call to is incorrectly using a capital B in the flag. It should be . The error coming from the matches the error when running the same command by itself: I searched for an existing issue which reports this, but didn't find any (aside from the comment linked earlier). Slack is installed successfully. 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.
Can you make a pr fixing it? I can merge.
I made a commit to do that in my fork here: However it still fails during the , this time with . This was also reported in but only on . However it seems the same issue is also present on and I'm not sure where to go from here on fixing it. I can run the same command from my terminal successfully. Is there anything different about running during the that might cause this?
I think I figured out the problem. writes to , but this isn't accessible to the user running the script (). I'm able to reproduce the problem now if I try to run the command as that user. Is there some way to make this file writable by the user as part of the ? I'll try to do some research on how other packages set property list attributes on darwin to see if there's some other workaround.
Change:
, withSQLite3 ? false , withCsrc ? true , withWebP ? false <del> , srcRepo ? false, autoreconfHook ? null, texinfo ? null </del> <ins> , srcRepo ? true, autoreconfHook ? null, texinfo ? null </ins> , siteStart ? ./site-start.el , nativeComp ? false , withAthena ? false

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

The real question here, I think, is how upstream expects native compilation to be used if their tarball doesn't support it.
Change:
githubId = 3747396; name = "Nathan Isom"; }; <ins> nelsonjeppesen = { email = "nix@jeppesen.io"; github = "NelsonJeppesen"; githubId = 50854675; name = "Nelson Jeppesen"; }; </ins> neonfuz = { email = "neonfuz@gmail.com"; github = "neonfuz";

Discussion:
kitty-themes Themes for the kitty terminal emulator Metadata homepage URL: source URL: license: gpl3 platforms: linux, darwin
Change:
<ins> { lib, pkg-config, cmake, libnotify, rustPlatform, fetchFromGitHub, }: rustPlatform.buildRustPackage rec { pname = "bato"; version = "0.1.7"; src = fetchFromGitHub { owner = "doums"; repo = "bato"; rev = "v${version}"; hash = "sha256-i2gw8vXiKutq26ACzkVXH3kED7jAngSv2mNo9P3qXnA="; }; cargoHash = "sha256-cqrSyZjfBSfF015nwOcRy2rkE4XzFPxJCQZGrqZXLEA="; nativeBuildInputs = [ pkg-config cmake ]; buildInputs = [ libnotify ]; meta = { description = "Small program to send battery notifications"; homepage = "https://github.com/doums/bato"; changelog = "https://github.com/doums/bato/releases/tag/v${version}"; license = lib.licenses.mpl20; maintainers = with lib.maintainers; [ HaskellHegemonie ]; platforms = lib.platforms.linux; mainProgram = "bato"; }; } </ins>

Discussion:
Battery status notifications <!-- Describe the project a little: --Metadata homepage URL: source URL: license: Mozilla Public License 2.0 platforms: linux Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Change:
, qttools , taglib , zlib <ins> , python3 </ins> }: <ins> let py = python3.withPackages (ps: with ps; [ pydbus ]); in </ins> mkDerivation rec { <del> pname = "sayonara-player"; version = "1.6.0-beta6"; </del> <ins> pname = "sayonara"; version = "1.6.0-beta7"; </ins> src = fetchFromGitLab { owner = "luciocarreras"; repo = "sayonara-player"; rev = version; <del> sha256 = "sha256-SbJS0DQvbW++CNXbuDHQxFlLRb1kTtDdIdHOqu0YxeQ="; </del> <ins> sha256 = "14svszfldx32vn937rszd21rgl31vb5kzs0hnrg41ygx0br61rvd"; </ins> }; nativeBuildInputs = [ cmake ninja pkg-config qttools ];

Discussion:
Describe the bug A clear and concise description of what the bug is. The and python scripts in need their interpreter to be patched (and the module available). To Reproduce Steps to reproduce the behavior: Expected behavior A clear and concise description of what you expected to happen. They should work :stuckouttongue:. 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(bt1cn): nixpkgs: Maintainer information:

<!-- 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: sayonara <!-- 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.6.0-beta6 desired version: 1.6.0-beta7 <!-- 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:
buildInputs = [ openssl protobuf ] ++ lib.optionals stdenv.isLinux [ libnsl ]; <del> cmakeFlags = [ "-DgRPC_ZLIB_PROVIDER=package" "-DgRPC_CARES_PROVIDER=package" "-DgRPC_RE2_PROVIDER=package" "-DgRPC_SSL_PROVIDER=package" "-DgRPC_PROTOBUF_PROVIDER=package" "-DgRPC_ABSL_PROVIDER=package" "-DBUILD_SHARED_LIBS=ON" ] ++ lib.optionals (stdenv.hostPlatform != stdenv.buildPlatform) [ "-D_gRPC_PROTOBUF_PROTOC_EXECUTABLE=${buildPackages.protobuf}/bin/protoc" ] ++ lib.optionals ((stdenv.hostPlatform.useLLVM or false) && lib.versionOlder stdenv.cc.cc.version "11.0") [ # Needs to be compiled with -std=c++11 for clang < 11. Interestingly this is # only an issue with the useLLVM stdenv, not the darwin stdenv… # https://github.com/grpc/grpc/issues/26473#issuecomment-860885484 "-DCMAKE_CXX_STANDARD=11" ]; </del> <ins> cmakeFlags = let # Needs to be compiled with -std=c++11 for clang < 11. Interestingly this is # only an issue with the useLLVM stdenv, not the darwin stdenv… # https://github.com/grpc/grpc/issues/26473#issuecomment-860885484 useLLVMAndOldCC = (stdenv.hostPlatform.useLLVM or false) && lib.versionOlder stdenv.cc.cc.version "11.0"; cxxStandard = if useLLVMAndOldCC then "11" else "17"; in [ "-DgRPC_ZLIB_PROVIDER=package" "-DgRPC_CARES_PROVIDER=package" "-DgRPC_RE2_PROVIDER=package" "-DgRPC_SSL_PROVIDER=package" "-DgRPC_PROTOBUF_PROVIDER=package" "-DgRPC_ABSL_PROVIDER=package" "-DBUILD_SHARED_LIBS=ON" "-DCMAKE_CXX_STANDARD=${cxxStandard}" ] ++ lib.optionals (stdenv.hostPlatform != stdenv.buildPlatform) [ "-D_gRPC_PROTOBUF_PROTOC_EXECUTABLE=${buildPackages.protobuf}/bin/protoc" ]; </ins> # CMake creates a build directory by default, this conflicts with the # basel BUILD file on case-insensitive filesystems.

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.