jiebi/CodeConvo huggingface dataset:
Change:
"--enable-debug=no" ]; }); <del> openvdb_tbb_2021_8 = openvdb.overrideAttrs (old: rec { </del> <ins> openvdb_tbb_2021_8 = openvdb.overrideAttrs (old: { </ins> buildInputs = [ openexr boost179

Discussion:
Package name: orca-slicer Latest released version: 2.1.1 <!-- Search your package here: --- Current version on the unstable channel: 2.0.0 Current version on the stable/release channel: 2.0.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! --- <!-- 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]:
please change update from 2.0.0 to 2.1.1 due to some major bugs in 2.1.0
Change:
aspell audiofile cups gmp gnutls <del> libffi </del> <ins> libffi libbfd </ins> libjpeg libtiff libpng giflib libungif libxml2 libxslt libiconv libobjc libgcrypt

Discussion:
i ran today and got this error: Please run and paste the results.
looks like has changed:
For future debugging, you should always include when the configure script fails. Reproducing it, this is the error: The breaking commit appears to be: not sure what is going on though.
FWIW, I came to the same conclusion via git bisect (starting based on hydra builds ) Isn't nixos-unstable supposed to receive updates from master only after the build succeeds on hydra?
I don't think it's actually libffi that broke... It's just the way gnustep-base is tesing libffi, namely In particular, note on the first line without a corresponding . Rather strangely, earlier tests specifically for bfd seem to have succeeded. Eg: I'm not sure how...
Nice work! I suspect that libbfd is hardcoded into clang somewhere. For whatever reason it does not pick up the right location though. This is true for certain things that are blocking jobs (or dependencies of those jobs). They are listed here: but right now we don't have gnustep or unar in any of these.
Oh ok, I suppose blocking only on "important" things makes sense. Also, thinking about it a little more, I'm not entirely sure libbfd needs to be in (vs ). Running ldd on an older unar, doesn't show up anywhere. That could be either because it was being statically linked, or because it was only used at build time. (I'm somewhat familiar with libbdf from work I did years ago, but not at all familiar with libffi.)
hi, i'm still getting this error, what can i do to debug/fix this?
fwiw, I have this error when building via (i.e. ).
Change:
Example: ```nix <del> testEqualDerivation </del> <ins> testers.testEqualDerivation </ins> "The hello package must stay the same when enabling checks." hello (hello.overrideAttrs(o: { doCheck = true; }))

Discussion:
The example from the manual: Literally all instances in nixpkgs use : The manual and nixpkgs should be consistent. As a contributor, i should be able to use examples from the manual (it does not even work).
To make the example from the manual work, you have to add: which adds 3 lines instead of i think it is more readable, idiomatic and elegant, but also clutters the derivation... so the version used in nixpkgs seems to be pragmatic. i suggest we update the manual to reflect nixpkgs. do you agree? we should have a general decision for ONE style. inherit vs
I would prefer the version. Inherits in a let block should only be used, when the attribute is need many times and is a common well known attribute, e.g. lib, version, ...
used to be it's own attribute before it got moved to , I'm guessing the manual was just forgotten to be updated.
Opened a PR that updates the documentation:
yup I forgot
Change:
url = "https://developer.download.nvidia.com/compute/cuda/12.1.1/local_installers/cuda_12.1.1_530.30.02_linux.run" sha256 = "sha256-10Ai1B2AEFMZ36Ib7qObd6W5kZU5wEh6BcqvJEbWpw4=" gcc = "gcc12" <ins> ["12.2"] version = "12.2.0" url = "https://developer.download.nvidia.com/compute/cuda/12.2.0/local_installers/cuda_12.2.0_535.54.03_linux.run" sha256 = "sha256-7PPSr63LrAKfD0UFeFgQ1S0AbkuHunn/P5hDNqK79Rg=" gcc = "gcc12" </ins>

Discussion:
Some cuda packages come with vendored copies of libraries that are already available in nixpkgs. These vendored libraries still require patching their Runpaths, their presence reduces determinism, and breaks "deep replacement" (i.e. nixpkgs' feature allowing to ensure that everything in a package set uses the same revision of a dependency). For instance, ships , which otherwise is available as: Cf. Tasks [ ] Look into deleting these vendored libraries and re-linking their reverse dependencies against nixpkgs alternatives
Change:
rubyEnv = bundlerEnv rec { name = "gitlab-env-${version}"; <del> inherit ruby; </del> <ins> # GitLab doesn't support Ruby 3 https://gitlab.com/groups/gitlab-org/-/epics/5149 ruby = ruby_2_7; </ins> gemdir = ./rubyEnv; gemset = let x = import (gemdir + "/gemset.nix") src;

Discussion:
So we'll have an EOL for a few months on 22.11, which isn't ideal, but we really shouldn't go into 23.05 like that. Also, does not support , which is why I noticed this when looking into stuff for
Ruby 2.7 support status ended yesterday.
The default is with the merge of :partyingface: Thanks for taking care of this Now… do we want to mark as EOL e.g. through ?
Change:
libpthreadstubs openssl /*or another sha1 provider*/ ] ++ lib.optionals (elem "wayland" eglPlatforms) [ wayland wayland-protocols ] ++ lib.optionals stdenv.isLinux [ libomxil-bellagio libva-minimal ] <ins> ++ lib.optionals stdenv.isDarwin [ libunwind ] </ins> ++ lib.optional withValgrind valgrind-light; depsBuildBuild = [ pkg-config ];

Discussion:
Describe the bug VAAPI records repeated frames (see upstream bug report). upstream fix: To Reproduce Steps to reproduce the behavior: ... open OBS ... try recording using VAAPI (possible AMD hardware required?) ... watch replay Expected behavior full FPS. Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Maintainer information:
As for 21.0, the fix contained in upstream release = 21.0.2 so e.g. PR
Sadly a look at that thread, it's blocked because something broke, and they're not pushing it to 21.05, so this bug is going to exist until someone figures this out the regression, this patch is only one line of code, maybe it can be supplied as a patch until they get 21.0.3 working? Is there a way to build a patched mesa without rebuilding my entire desktop stack? It's currently stupidly slow on my computer when doing a packageOverride.
This will not be the only bug people will have to deal with on 21.05 unless we backport a more recent mesa (=21.1). Alternative we could also start to includes as well. Without it, this will lead to crashes in wine (incl. steam proton) when on some hardware ( for reference). While one can set as a workaround, it is hardly ideal and difficult to diagnose from within steam alone. Would it be possible to backport the mesa update currently in staging-next () once it is merged?
I don't know... this is hard. Maybe after a version has been a couple weeks in , we might be sufficiently confident that it won't make things worse overall.
I'm okay with backporting it, but probably as its own job set, just to get a better idea of regressions.
I'm not afraid of build-time regressions in this case. Those would be easy (to find). And mesa isn't such a big rebuild now anyway.
If it's been on unstable for a while, I guess I'm okay with it as well
I guess we can close this now, I haven't noticed any problems recently.
Change:
defaultShellPath = lib.makeBinPath defaultShellUtils; <ins> bashWithDefaultShellUtils = writeShellApplication { name = "bash"; runtimeInputs = defaultShellUtils; text = '' if [[ "$PATH" == "/no-such-path" ]]; then export PATH=${defaultShellPath} fi exec ${bash}/bin/bash "$@" ''; }; </ins> platforms = lib.platforms.linux ++ lib.platforms.darwin; system = if stdenv.hostPlatform.isDarwin then "darwin" else "linux";

Discussion:
I'm trying to use from nixpkgs on my laptop and use remote builders (buildbarn). This fails due to patches that are applied in nixpkgs. Vanilla Bazel has a hardcoded fallback path for bash () . This has the downside of not producing a working fallback for (bash from nixpkgs will default initialize as ). The workaround for this is to default initialize the path variables somewhere else. Currently, this is done . This works fine for local execution, since this is where this function is called. However, this function is never called for remote execution (it is a hack to override things for the local execution environment only). So when using Bazel from nixpkgs locally and enabling remote execution, the shell is set to a bash from nixpkgs during the analysis phase but the variable is explicitly left unset by many actions, leading to the PATH in bash being and resulting in errors when executing tools in a script. I think there are two possible solutions: when using remote execution, do not replace the hardcoded (this is probably not a great fix since it only works for FHS executors) instead of replacing with a regular bash from nixpkgs, add a little helper script that adds shell utils to . This way, any shell rule created by bazel has a minimal set of tools. use when turning on remote execution. This has the downside of only working when the remote builder has a shell in that path. See this for a detailed reproducer: Using bazel from nixpkgs should work with remote execution. Using this version of bazel with remote execution is becoming more viable due to <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- [^1]: [^2]:
got reverted, I'll reopen it.
Could we also remove the related patch here -, or is it still needed for some reason ?
To the best of my understanding, it should be sufficient to use a prepared bash (with tools in the PATH) and remove the patch you mentioned. Probably still a good idea to test this in practice!
Change:
defaultSource = lib.findFirst (sourceMatches "en-US") {} sources; <del> source = lib.findFirst (sourceMatches systemLocale) defaultSource sources; </del> <ins> mozLocale = if systemLocale == "ca_ES@valencia" then "ca-valencia" else lib.replaceStrings ["_"] ["-"] systemLocale; source = lib.findFirst (sourceMatches mozLocale) defaultSource sources; </ins> pname = "firefox-${channel}-bin-unwrapped";

Discussion:
The package does not detect the locale for the package to download. The source code attempts to use , but does not detect it, and automatically falls back to . There is also no package option to override the locale. Install , either with nix-env as a normal user, or with , while the locale is set to something other than Please run and paste the results. I made a rather hacky patch to add a locale option to the firefox-bin package (replacing the literal string "en-US", but I would not consider it mergable.
this is related and this PR
The PR was a cleaner version of what I implemented, so I'll mark this as closed when it gets merged. Am So, 24. Mär 2019, um 04:55, schrieb Tomas Hlavaty:
This has been bug for me forever, thank you for reporting. Firefox is always in en-US, regardless of locale for me.
Thank you for your contributions. This has been automatically marked as stale because it has had no activity for 180 days. If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity. Here are suggestions that might help resolve this more quickly: for maintainers and people that previously touched the related code and @ mention them in a comment. on the . on the on .
This is still an issue today.
I marked this as stale due to inactivity. &rarr;
Change:
sha256 = "sha256-BJDaDokyHgmyl+bGqCwG1J7iOvu0E3P3iYZ1/krot8s="; }; <del> installPhase = '' mkdir -p $out/include/CL cp CL/* $out/include/CL ''; </del> <ins> nativeBuildInputs = [ cmake ]; </ins> meta = with lib; { description = "Khronos OpenCL headers version ${version}";

Discussion:
llama build uses pkg-config to discover the include path of opencl-header. Sadly, the current package only copies the headers files, not the pc file. It is supposed to be generated by cmake from a , but we currently do not call it. I would happily propose a patch but the interactions between cmake, nix and pkg-config is out of my league :) Thanks for looking into it!
Change:
xfce4-dockbarx-plugin = callPackage ./panel-plugins/xfce4-dockbarx-plugin { }; <ins> xfce4-docklike-plugin = callPackage ./panel-plugins/xfce4-docklike-plugin { }; </ins> xfce4-embed-plugin = callPackage ./panel-plugins/xfce4-embed-plugin { }; xfce4-eyes-plugin = callPackage ./panel-plugins/xfce4-eyes-plugin { };

Discussion:
Project description A modern, minimalist taskbar for Xfce. Docklike Taskbar behaves similarly to many other desktop environments and operating systems. Wherein all application windows are grouped together as an icon and can be pinned to act as a launcher when the application is not running. Commonly referred to as a dock. Metadata homepage URL: source URL: license: gpl3 platforms: linux
Hi I submitted xfce4-docklike-plugin for review. Feel free to provide feedback.
Change:
UMask = "0007"; CPUSchedulingPolicy = "idle"; IOSchedulingClass = "idle"; <del> ExecStart = "${cfg.package}/bin/matomo-console core:archive --url=https://${user}.${fqdn}"; </del> <ins> ExecStart = "${cfg.package}/bin/matomo-console core:archive --url=https://${cfg.periodicArchiveProcessingUrl}"; </ins> }; };

Discussion:
The mamoto service is a self-hosted and open source alternative to google analytics. I managed to make the almost work except for a constrained url in the nix module. Expected behavior When archiving requests. I would expect the matomo service to allow me to configure the url of the service, for instance intsead I am constrained to this and is grosso modo IIUC. Additional context I know that the default config using NGINX should make the choice of the url for me, but I want to use the caddy server, since it is already running on the machine. There is an option in the matomo module anyway and the url of the service is free so the functioning is misleading right now. Here is my config and the caddy config with The package of matomo is a bit outdated, but has recent updates. Suggestion Maybe we could add an option in the module that would set the url used when archiving.
This problem also affects me. Also, I don't even understand how it makes sense to prefix a "user" component on the hostname. If is "matomo" and is "" then the Matomo service computes a URL of which is just wrong. I'm not trying to use caddy. I just have a straightforward Matomo / nginx configuration - but it seems broken out of the box to me. I'm currently working around this using this line in my configuration:
Agreed. When using nginx, this should probably be: with maybe some logic for http/https. cc
Change:
sizeMB = mkOption { type = with types; either (enum [ "auto" ]) int; <del> default = "auto"; </del> <ins> # TODO(lukegb): this should be "auto"; see #120473 default = if config.ec2.hvm then 2048 else 8192; </ins> example = 8192; description = "The size in MB of the image"; };

Discussion:
The nixos-unstable and nixos-unstable-small channels are currently blocked because the "auto" disk image size calculation underestimates the required space in certain situations. This causes the disk to be sized to small for its contents when building the Amazon EC2 image.
Downgrading from channel blocker
I guess this is fixed now?
I marked this as stale due to inactivity. &rarr;
Change:
mlir = callPackage ./mlir { }; libclc = callPackage ./libclc.nix { }; } <ins> // lib.optionalAttrs (lib.versionAtLeast metadata.release_version "19") { bolt = callPackage ./bolt { patches = lib.optionals (lib.versions.major metadata.release_version == "19") [ (fetchpatch { url = "https://github.com/llvm/llvm-project/commit/abc2eae68290c453e1899a94eccc4ed5ea3b69c1.patch"; hash = "sha256-oxCxOjhi5BhNBEraWalEwa1rS3Mx9CuQgRVZ2hrbd7M="; }) ]; }; } </ins> ); libraries = lib.makeExtensible (

Discussion:
This project should be part of the , but it's missing. BOLT is a post-link optimizer developed to speed up large applications. It achieves the improvements by optimizing application's code layout based on execution profile gathered by sampling profiler, such as Linux perf tool. An overview of the ideas implemented in BOLT along with a discussion of its potential and current results is available in . Metadata homepage URL: source URL: license: Apache License v2.0 with LLVM Exceptions platforms: unix, linux, darwin.
OK I managed to build this on NixOS, but with tons of patches. I think the upstream bolt is not ready for separate compilation yet, so I need to copy a bunch of stuff from elsewhere, but here is the build: the patch: <details</detailsThe patch is really ugly and there are some things that are specific to NixOS (I integrated the in other llvm packages). Not sure if we want to try to get the changes upstreamed before opening a PR. The build is successful, but I haven't yet tested it. Patching this is quite painful and consumed me 4 hours already...
it seems that it works directly without the need for wrapping.
The upstream patch which makes packaging bolt possible in Nix has been merged. We'll have things here merged in not too long from now.
Change:
<ins> diff --git a/data/CMakeLists.txt b/data/CMakeLists.txt index 71a110a7b..e69880d46 100644 --- a/data/CMakeLists.txt +++ b/data/CMakeLists.txt @@ -38,11 +38,6 @@ if(NOT WIN32) # find the correct file. set(DESKTOP_ANSEL_BINARY "ansel") set(DESKTOP_ANSEL_ICON "ansel") -  if(NOT CMAKE_INSTALL_PREFIX STREQUAL "/usr") -    set(DESKTOP_ANSEL_BINARY "${CMAKE_INSTALL_PREFIX}/${CMAKE_INSTALL_BINDIR}/ansel") -    # `hicolor` is always available. -    set(DESKTOP_ANSEL_ICON "${CMAKE_INSTALL_PREFIX}/${CMAKE_INSTALL_DATAROOTDIR}/icons/hicolor/scalable/apps/ansel.svg") -  endif() # Append supported MIME types dynamically. if("avif" IN_LIST DT_SUPPORTED_EXTENSIONS) </ins>

Discussion:
Ansel installs well, and can be launch from console with … but it does not appear in Gnome’s application menu, nor it cannot be find in Gnome launcher search Steps to reproduce the behavior: to from channel 24.05 or from unstable to launch it or to find it in applications menu Like every other application (and Darktable), I expect to find Ansel in the application menu, launcher search, and so on
I don't know anything about gnome, but there's definitely a desktop file in the correct spot: also, is a bot, FYI Probably try rebooting or something.
The desktop file is broken: Sounds like the upstream build system is broken – see
Good catch, thanks. I've sent a PR
Change:
{ stdenv, fetchPypi, buildPythonPackage , more-itertools, six <del> , coverage, codecov, pytest, pytestcov, pytest-sugar, portend </del> <ins> , pytest, pytestcov, portend </ins> , backports_unittest-mock, setuptools_scm }: buildPythonPackage rec {

Discussion:
has a test failure and won't install.
That's a known upstream issue:
I guess you didn't initially try to build pytest-sugar but some other package. That one should build fine once is merged.
thanks for looking into this. :)
Change:
{ lib , buildPythonPackage <del> , fetchgit </del> <ins> , fetchFromGitHub </ins> , pythonOlder , pytestCheckHook , indexed-bzip2 , indexed-gzip , indexed-zstd , python-xz <ins> , setuptools </ins> , rapidgzip , rarfile , zstandard     # Python bindings

Discussion:
Steps to reproduce the behavior: python3Packages.ratarmountcore This first occurs after updates to and itself. The failure is not actually in a test, and occurs after the tests run. This indicates that some difference in the way the derivation is executing tests compared to upstream's CI is causing the error. Please run and paste the result. Not relevant; the log is on Hydra. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
It seems that only the rapidgzip backend got updated but not ratarmountcore. Either downgrade rapidgzip or update ratarmountcore to 0.6.3 if possible. I'll have to see to get the latter update merged, it seems the auto-update bot does not work for ratarmountcore. This should fix the and output. I have no idea about the last 2 error lines. I cannot reproduce it with nix 2.16.1 on Ubuntu. The command runs fine:
Change:
<del> { lib, fetchPypi, buildPythonApplication, EditorConfig, pytest, six }: </del> <ins> { lib, fetchPypi, buildPythonApplication, EditorConfig, fetchpatch, pytest, six }: </ins> buildPythonApplication rec { pname = "jsbeautifier"; <del> version = "1.8.9"; </del> <ins> version = "1.9.1"; </ins> <del> propagatedBuildInputs = [ six ]; buildInputs = [ EditorConfig pytest ]; </del> <ins> propagatedBuildInputs = [ six EditorConfig ]; checkInputs = [ pytest ]; </ins> src = fetchPypi { inherit pname version; <del> sha256 = "7d02baa9b0459bf9c5407c1b99ad5566de04a3b664b18a58ac64f52832034204"; </del> <ins> sha256 = "0q8ld072dkccssagjxyvc9633fb6ynflvz70924phgp3zxmim960"; </ins> }; <ins> patches = [ (fetchpatch { url = "https://github.com/beautify-web/js-beautify/commit/78e35a11cbb805fc044241d6465800ee2bd57ebc.patch"; sha256 = "1ah7nshk96yljy37i20v4fga834dix9cdbhkdc3flfm4904n4523"; }) ]; patchFlags = [ "-p2" ]; </ins> meta = with lib; { homepage    = "http://jsbeautifier.org"; description = "JavaScript unobfuscator and beautifier.";

Discussion:
python36Packages.jsbeautifier build is failing, the same error occurs on master and 19.03. Updating the package does not solve the problem. system: host os: multi-user?: sandbox: version: channels(root): channels(kalbasit): channels(yl): nixpkgs:
/cc maintainer of this package.
This was not happening back in . I believe this started happening with version 1.8.0rc2 when test-packer was introduced upstream.
fixed via
Change:
hash = "sha256-b0TO2dWp2iyH2bL/8wu1MIVAwGV2BeTVzeftMnW7rVA="; }; <del> patches = [ # https://github.com/lmcinnes/pynndescent/pull/224 (fetchpatch { url = "https://github.com/lmcinnes/pynndescent/commit/86e0d716a3a4d5f4e6a0a3c2952f6fe339524e96.patch"; hash = "sha256-dfnT5P9Qsn/nSAr4Ysqo/olbLLfoZXvBRz33yzhN3J4="; }) </del> <ins> nativeBuildInputs = [ setuptools </ins> ]; propagatedBuildInputs = [

Discussion:
Steps to reproduce the behavior: pythonPackages.pynndescent Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Change:
"textnets" ]; <ins> # Enables the package to find the cythonized .so files during testing. See #255262 preCheck = '' rm -r textnets ''; </ins> disabledTests = [ <del> # Test fails: A warning is triggered because of a deprecation notice by pandas. # TODO: Try to re-enable it when pandas is updated to 2.1.1 "test_corpus_czech" </del> <ins> # Test fails: Throws a UserWarning asking the user to install `textnets[fca]`. "test_context" </ins> ]; meta = with lib; {

Discussion:
, it will fail when it can't find check hydra: works, but also generates deprecation warnings. 0.9.3 (as used by Hydra) isn't an official release at Github. 0.9.4 fixes the deprecation warnings (save for flagging a future dependency and one other future.) Bump to version 0.9.4 coming momentarily. Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Change:
nativeBuildInputs = [ makeWrapper ]; buildInputs = [ jre_headless util-linux ] <del> ++ optional enableUnfree zlib; </del> <ins> ++ optional enableUnfree [ zlib libxcrypt ]; </ins> installPhase = '' mkdir -p $out

Discussion:
Steps to reproduce the behavior: = true; If services.elasticsearch.package is set to pkgs.elasticsearch-oss it works. <!-- 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.