jiebi/CodeConvo huggingface dataset:
Change:
buildPythonPackage rec { pname = "indexed_zstd"; version = "1.6.0"; <del> format = "setuptools"; </del> <ins> pyproject = true; </ins> disabled = pythonOlder "3.6";

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:
}; buildInputs = [ bzip2 ]; <del> patches = [ ./include-systypes.patch ]; </del> <ins> patches = [ (fetchpatch { url = "https://sources.debian.org/data/main/b/bsdiff/4.3-22/debian/patches/20-CVE-2014-9862.patch"; sha256 = "sha256-3UuUfNvShQ8fLqxCKUTb/n4BmjL4+Nl7aEqCxYrrERQ="; }) ./CVE-2020-14315.patch ./include-systypes.patch ] ++ lib.optional stdenv.hostPlatform.isLinux [ (fetchpatch { url = "https://sources.debian.org/data/main/b/bsdiff/4.3-22/debian/patches/30-bug-632585-mmap-src-file-instead-of-malloc-read-it.patch"; sha256 = "sha256-esbhz2/efUiuQDuF7LGfSeEn3/f1WbqCxQpTs2A0ulI="; }) (fetchpatch { url = "https://sources.debian.org/data/main/b/bsdiff/4.3-22/debian/patches/31-bug-632585-mmap-dst-file-instead-of-malloc-read-it.patch"; sha256 = "sha256-Of4aOcI0rsgdRzPqyw2VRn2p9wQuo3hdlgDTBdXGzoc="; }) (fetchpatch { url = "https://sources.debian.org/data/main/b/bsdiff/4.3-22/debian/patches/32-bug-632585-use-int32_t-instead-off_t-for-file-size.patch"; sha256 = "sha256-SooFnFK4uKNXvXQb/LEcH8GocnRtkryExI4b3BZTsAY="; }) ]; </ins> buildPhase = '' $CC -O3 -lbz2 bspatch.c -o bspatch

Discussion:
, CVSSv3=9.8 (nixos-20.03, nixos-20.09, nixos-unstable) Scanned versions: nixos-20.03: ; nixos-20.09: ; nixos-unstable: . Cc
Change:
name = "${s.name}.tar.bz2"; }; <ins> patches = [ (fetchpatch { name = "CVE-2020-17367.patch"; url = "https://github.com/netblue30/firejail/commit/2c734d6350ad321fccbefc5ef0382199ac331b37.patch"; sha256 = "1gxz4jxp80gxnn46195qxcpmikwqab9d0ylj9zkm62lycp84ij6n"; }) (fetchpatch { name = "CVE-2020-17368.patch"; url = "https://github.com/netblue30/firejail/commit/34193604fed04cad2b7b6b0f1a3a0428afd9ed5b.patch"; sha256 = "0n4ch3qykxx870201l8lz81f7h84vk93pzz77f5cjbd30cxnbddl"; }) ]; </ins> prePatch = '' # Allow whitelisting ~/.nix-profile substituteInPlace etc/firejail.config --replace 

Discussion:
, CVSSv3=9.8 (nixos-20.03) CVSSv3=7.8 (nixos-20.03) Scanned versions: nixos-20.03: . Cc
Resolved via .
Change:
[^footnote-stdenv-ignored-build-platform]: The build platform is ignored because it is a mere implementation detail of the package satisfying the dependency: As a general programming principle, dependencies are always *specified* as interfaces, not concrete implementation. [^footnote-stdenv-native-dependencies-in-path]: Currently, this means for native builds all dependencies are put on the `PATH`. But in the future that may not be the case for sake of matching cross: the platforms would be assumed to be unique for native and cross builds alike, so only the `depsBuild*` and `nativeBuildInputs` would be added to the `PATH`. <del> [^footnote-stdenv-propagated-dependencies]: Nix itself already takes a package’s transitive dependencies into account, but this propagation ensures nixpkgs-specific infrastructure like setup hooks (mentioned above) also are run as if the propagated dependency. </del> <ins> [^footnote-stdenv-propagated-dependencies]: Nix itself already takes a package’s transitive dependencies into account, but this propagation ensures nixpkgs-specific infrastructure like [setup hooks](#ssec-setup-hooks) also are run as if it were a propagated dependency. </ins> [^footnote-stdenv-find-inputs-location]: The `findInputs` function, currently residing in `pkgs/stdenv/generic/setup.sh`, implements the propagation logic. [^footnote-stdenv-sys-lib-search-path]: It clears the `sys_lib_*search_path` variables in the Libtool script to prevent Libtool from using libraries in `/usr/lib` and such. [^footnote-stdenv-build-time-guessing-impurity]: Eventually these will be passed building natively as well, to improve determinism: build-time guessing, as is done today, is a risk of impurity.

Discussion:
Project description
I marked this as stale due to inactivity. &rarr;
ping! Is this still an issue?
has been The command still does not have documentation in the Nixpkgs manual.
Is satisfying? Could use approval to get merged.
It's a good step, but it doesn't (yet?) tell me what the options are.
Now it does.
Change:
litehtml = callPackage ../development/libraries/litehtml { }; <del> live555 = callPackage ../development/libraries/live555 { }; </del> llhttp = callPackage ../development/libraries/llhttp { }; log4cpp = callPackage ../development/libraries/log4cpp { };

Discussion:
Steps to reproduce the behavior: Upstream source is gone. Has upstream rearranged their mirrors or removed an old version? Add any other context about the problem here. Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
It appears that live555 have prepared a new release, and remove the old tarballs when they do so. mirrors old versions, but not this release.
Live555 has two strange politics: provide no VCS, only tarballs remove older versions from existence Maybe using something like an automated script to populate a git repo would help.
I think that's what the project was trying to do, by mirroring each release tarball. But they seem to have missed this one. A repo might also work: I saw but am not sure if it's a pristine copy.
It doesn't look that they have all released tarballs. I will try to retrieve them via - however my script-fu is a bit rusted. Sometimes the date tag fails, but works. The files need to be saved too. After that, the repo can be populated.
It seems like that SlackBuilds archive is missing versions after , was this always the case? The build is failing with this error:
I am trying to keep a copy of that thing: SBo is not updating this since 2021.
Hello! Am I need to overlay this package to change it's url until the next version?
This should work:
Thank you! For my configuration (from nixpkgs/master) it still need previous version: Is it because I'm still with plasma 5?
And I have
It doesn't look like you applied the overlay; the name is still in the log when it should be .
but this works fine I'll check libvlc-3.0.20
And only after successful build with 02.23 it take you overlay with 02.28 Is it because of previous lock? Thank you!
Change:
<del> diff --git a/test/lsp.py b/test/lsp.py index 669951ca4..11007ae82 100755 --- a/test/lsp.py +++ b/test/lsp.py @@ -28,7 +28,8 @@ else: import tty # Turn off user input buffering so we get the input immediately, # not only after a line break -    tty.setcbreak(sys.stdin.fileno()) +    if os.isatty(sys.stdin.fileno()): +        tty.setcbreak(sys.stdin.fileno()) # Type for the pure test name without .sol suffix or sub directory </del>

Discussion:
Package name: solc Latest released version: 0.8.21Current version on the unstable channel: 0.8.19 Current version on the stable/release channel: 0.8.19 Notify maintainers Note for maintainers: Please tag this issue in your PR.
Change:
nix-build-uncached = callPackage ../development/tools/misc/nix-build-uncached { }; <del> nexus = callPackage ../development/tools/repository-managers/nexus { }; </del> <ins> nexus = callPackage ../development/tools/repository-managers/nexus { jre_headless = jre8_headless; }; </ins> nwjs = callPackage ../development/tools/nwjs { gconf = pkgs.gnome2.GConf;

Discussion:
Describe the bug Sonatype Nexus does not start on NixOS 21.05 To Reproduce nexus service service does not start and shows Expected behavior The service should run. Additional context The issue seems to be caused by the fact, that the nexus package requires exactly java 1.8. Adding the option fixes the issue for me. 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:
please test
see Java:
Change:
let # having the full version string here makes it easier to update <del> modDirVersion = "5.18.0-zen1"; </del> <ins> modDirVersion = "5.18.1-zen1"; </ins> parts = lib.splitString "-" modDirVersion; version = lib.elemAt parts 0; suffix = lib.elemAt parts 1;

Discussion:
The Zen kernel is failing to build for me since the update to 5.18, and so I thought I'd open an issue since I can't seem to find any existing info about it. Bisected to system: host os: multi-user?: sandbox: version: channels(root): channels(alex): nixpkgs:
Looks like it didn't build even in the CI of : But, we already have a new version: Cc (since you're always the one to bump it)
Unfortunately 5.18.1 doesn't seem to build either for me. :( Given that the file in question hasn't been touched in months, I'm wondering if this has something to do with the move to C11 for the 5.18 kernel. But that's just a guess. I can think of two possible quick solutions: Include a patch that adds a comment Ignore that warning everywhere in the kernel
Staging recently got change to avoid Werror-style failures.
Given that that change will take a bit to get to master, do you think it would make sense to set for just the zen kernel in the meantime? Or even just revert and move it to staging so that it gets merged when the change does? I'm asking because—while it's not too much trouble to add patches to my personal NixOS configuration—right now the zen kernel is broken for everyone, and so it might be a good idea to get it back to a working state in the meantime. I'm not sure how many people use the zen kernel though, it seems to be not very many, and so if it's better to just leave it as-is for a bit that's fine too; I don't really know how such things are usually handled in nixpkgs and am trying to learn. :)
I'd say setting for zen kernel is perfectly fine. Should be a matter of adding it to Do you want to give it a try and propose a PR? AFAIU you already run that kernel version and have a chance to validate it if still boots. You could also add a TODO to remove it once staging is merged.
should've gone to master and/or be merged with the next kernel bump or something if the rebuilds were that critical which I don't think they are. We could cherry-pick it if we need it now.

I made , but it's late here so I don't have time to test it properly and am waiting to open a PR until I can do so. It at least builds though. I figured while I was at it I should also bump the version to 5.18.1-zen1, but in hindsight maybe I should wait until the mainline kernel is updated to 5.18.1 in nixpkgs? Anyway, I'll test it when I have time tomorrow evening, make any necessary changes, and open a PR, unless we decide to cherry-pick ? That seems like a nicer solution to me personally, but I don't really have a strong preference.
I finally got around to testing this and opened a PR: :). I'm personally in favor of cherry-picking , though.
Change:
outputs = [ "out" "dev" "devdoc" ]; <del> separateDebugInfo = stdenv.isLinux; </del> <ins> # https://github.com/NixOS/nixpkgs/issues/153528 # Can't be linked within a 4GB address space. separateDebugInfo = stdenv.isLinux && !stdenv.is32bit; </ins> src = fetchurl { url = "https://webkitgtk.org/releases/webkitgtk-${finalAttrs.version}.tar.xz";

Discussion:
I think it should be marked as broken to avoid frustrating other people. This package is impossible to build without more than 4G address space due to linker memory exhaustion. It can be built only on 64-bit hosts (the same as Firefox). And that permanently breaks Gnome 3 on i686. It was possible to build it in the past using local modifications, though.
what modifications did you used in the past?
Only very few to some Gnome dependencies just to build Gnome itself, like . AFAIK, there were no modifications at all to webkitgtk. It just required huge swap and to free as much RAM as possible, e.g. running nix-build with only one thread. Last December I've tried to install NixOS 21.11 and it was impossible to build because of a linker exhausting all memory address space. I've tried both ld and gold. My investigations into other Linux distros revealed that they used cross-compiling tricks to build 32-bit webkitgtk on 64-bit host. I've spent a week before giving up. Right now I'm using only x86_64 arch because of that issue. I suppose it's impossible to fix on native 32-bit host just like Firefox.
I tried different configurations and was able to complete the building without any memory issue by setting separateDebugInfo to false.
I will now try to build firefox. Edit: it is markerd as broken on 32 bits.
Interesting. Thanks for trying this. It was very painful to experiment with different configurations as it required too many hours to build on my computer. AFAIK, Firefox had a different issue which didn't involve linker. It was probably a compiler. Do you think it's sustainable? I mean, will it still be possible to build next year? Because a year ago it didn't require that trick either. I'm quite pessimistic about browsers on 32-bit architecture as is already evident from Firefox :( Also, there were similar troubles with Haskell (Pandoc) and Qt. Considering that Hydra doesn't have most 32-bit software in a binary cache and that it's often required to set in order to build it, it's really a huge pain to install NixOS on i686 arch.
works great for me. Should we add a conditional for this derivation?
Change:
# a cabal flag with '--flag=myflag'. developPackage = { root <del> , name ? builtins.baseNameOf root </del> <ins> , name ? if builtins.typeOf root == "path" then builtins.baseNameOf root else "" </ins> , source-overrides ? {} , overrides ? self: super: {} , modifier ? drv: drv

Discussion:
At the moment this seems to be the neatest way: Sadly this doesn't work:
This is a bit better, neat enough for me to close the issue :)
Better yet: This doesn't generate the exact same derivation, but it's functionally the same:
Change:
been removed. </para> </listitem> <del> <listitem> <para> The <literal>rmilter</literal> package was removed with associated module and options due deprecation by upstream developer. Use <literal>rspamd</literal> in proxy mode instead. </para> </listitem> </del> <ins> <listitem> <para> The <literal>rmilter</literal> package was removed with associated module and options due deprecation by upstream developer. Use <literal>rspamd</literal> in proxy mode instead. </para> </listitem> <listitem> <para> systemd cgroup accounting via the <link linkend="opt-systemd.enableCgroupAccounting">systemd.enableCgroupAccounting</link> option is now enabled by default. It now also enables the more recent Block IO and IP accounting features. </para> </listitem> </ins> </itemizedlist> </section> </section>

Discussion:
I want to see systemd services in netdata monitoring. For that "cgroup accounting" is needed. The question is if enabling it on all systems would have any negative effect. In that case i would activate it only when netdata service is enabled. Arch Linux, Ubuntu and Fedora seem to have it enabled by default. debian not. shows no resources for services. System: NixOS 17.03.1700. (Gorilla) Nix version: nix-env (Nix) 1.11.13 Nixpkgs version: "17.03.1700." Sandboxing enabled: build-use-sandbox = true
I will implement it as option, that is enabled by default and for netdata service.
I believe you can set this with: And maybe also: (ideas from )
sure, that is how i do it right now. But i want to propose it to be enabled by default, so you have it when you need it for debugging. But also a single option to disable it when you have reasons to.
Is this still open for the discussion about defaulting to or is this still open simply because it wasn't closed? Unless something else than the PR is required? (
I created this issue to have this enabled for netdata. So an additional PR needs to be created to enable the new option when netdata is enabled. In addition it could be discussed to enable the option by default when a desktopManager is enabled (for desktop users). It should not be enabled by default on servers because it could have a little impact on performance.
Nowadays, this might already be enabled per default half-way: from my `systemd- (latest master right now) Are there any recent figures about performance implications when enabling the rest? If Fedora enables it, we could probably do so too.
this might already be enabled per default half-way thanks for noticing! can you create an issue or PR to change ? Are there any recent figures about performance implications when enabling the rest? i don't know any. i have no issues on my servers where i set it manually
Change:
containers cryptohash-sha1 data-default deepseq directory extra filepath fuzzy ghc ghc-boot ghc-boot-th ghc-check ghc-paths haddock-library hashable haskell-lsp haskell-lsp-types hie-bios <del> hslogger mtl network-uri opentelemetry prettyprinter prettyprinter-ansi-terminal regex-tdfa rope-utf16-splay safe safe-exceptions shake sorted-list stm syb text time transformers unix unordered-containers utf8-string </del> <ins> hslogger mtl network-uri prettyprinter prettyprinter-ansi-terminal regex-tdfa rope-utf16-splay safe safe-exceptions shake sorted-list stm syb text time transformers unix unordered-containers utf8-string </ins> ]; executableHaskellDepends = [ aeson base bytestring containers data-default directory extra

Discussion:
Describe the bug , a nested dependency, requires < 4.1.14. To Reproduce
Can probably be closed now?
Yes, I thought that would happen automatically.
I just bumped on (something very similar to?) this:
Change:
packageJSON = ./riot-desktop-package.json; yarnNix = ./riot-desktop-yarndeps.nix; <del> nativeBuildInputs = [ makeWrapper ]; </del> <ins> nativeBuildInputs = [ makeWrapper gtk3 ]; </ins> installPhase = '' # resources

Discussion:
Describe the bug The riot-desktop package crashes on NixOS systems where KDE is the only explicitly installed desktop environment. To Reproduce Steps to reproduce the behavior: KDE and riot-desktop riot-desktop, sign in and join a room the paperclip to attach a file Expected behavior The KDE file chooser should pop up allowing you to select a file Additional context My best guess based on the terminal output is that Matrix is trying to use some kind of GTK library to determine the file chooser and does not list it as a dependency. Terminal output of the crashing program:
This is a somewhat common error and it goes undetected because package testers have these gsettings schemas installed on their system. For me, on NixOS, I this to my : If you don't use NixOS, try to follow what's explained .
This is an electron program, it probably needs to be wrapped manually, the standard hook won't work.
Backported to 20.03 in .
Now riot-desktop crashes here with the following error:
there has been a new PR that fixes up this one: . Can you check that out?
Yes, I'm on master with the latest commits. The shows at the top:
Change:
sha256 = "03kj15cf1pbd11mxsik96m5w1m6p0fbdc4ia5ihzmq8rz28razpq"; }; <ins> propagatedBuildInputs = [ setuptools ]; </ins> checkInputs = [ pytestCheckHook ];

Discussion:
upon importing Cerberus. Steps to reproduce the behavior: Because was introduced in Python 3.7 I suspected this might only affect some Python versions but from the above example it is clear this is more widespread. runs without error. 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.
nixos-21.11 is affected
Change:
youki = callPackage ../applications/virtualization/youki { }; <del> yt-dlp = with python3Packages; toPythonApplication yt-dlp; yt-dlp-light = with python3Packages; toPythonApplication yt-dlp-light; </del> <ins> yt-dlp-light = yt-dlp.override { atomicparsleySupport = false; ffmpegSupport = false; rtmpSupport = false; }; </ins> youtube-viewer = perlPackages.WWWYoutubeViewer;

Discussion:
yt-dlp doesnt work with curl-impersonate Steps to reproduce the behavior: my to see targets available n/a the example in curl-impersonate repository works Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Change:
{ mkDerivation, lib, fetchurl, autoPatchelfHook, makeWrapper, xdg_utils, dbus <del> , qtbase, qtwebkit, qtx11extras, qtquickcontrols, glibc, libXrandr, libX11 </del> <ins> , qtbase, qtwebkit, qtx11extras, qtquickcontrols, glibc , libXrandr, libX11, libXext, libXdamage, libXtst, libSM, libXfixes </ins> , wrapQtAppsHook }: mkDerivation rec { name = "teamviewer-${version}"; version = "14.5.1691";

Discussion:
Connect TO teamviewer 14 on Nixos 19.03 Koi - it shows black screen with control elements, similar to this: providing no control. Connecting OS plays no role (connected FROM teamviewer 14 on Nixos 19.03 Koi and FROM teamviewer 14 on Ubuntu 16.04; to teamviewer 14 on Nixos 19.03 Koi - same result). There are no errors or warnings in the log, except this entry: StartServiceByName: com.teamviewer.TeamViewer.Desktop - DBus: 'org.freedesktop.DBus.Error.ServiceUnknown' (The name com.teamviewer.TeamViewer.Desktop was not provided by any .service files) when calling 'org.freedesktop.DBus.StartServiceByName' on '/org/freedesktop/DBus', Errorcode=11 in = true; ... environment.systemPackages = with pkgs; [ ... teamviewer ]; Please run and paste the results. nix-shell -p nix-info --run "nix-info -m" system: host os: multi-user?: sandbox: version: channels(userp): channels(root): nixpkgs:
Fix now available in .
/ Would you mind closing this issue? Seems solved.
Thank you! Because of mentioned problem I had to switch to alternative software, thus was distracted from issue. Beautiful work, thank you very much for your time and support!! Closing issue.
Change:
nativeBuildInputs = [ makeWrapper ]; installPhase = '' <del> mkdir -p $out/bin </del> <ins> mkdir -p $out/bin $out/lib </ins> cp -r geekbench.plar geekbench5 geekbench_x86_64 $out/bin <ins> # needed for compute benchmark ln -s ${linuxPackages.nvidia_x11}/lib/libcuda.so $out/lib/ ln -s ${ocl-icd}/lib/libOpenCL.so $out/lib/ ln -s ${ocl-icd}/lib/libOpenCL.so.1 $out/lib/ ln -s ${vulkan-loader}/lib/libvulkan.so $out/lib/ ln -s ${vulkan-loader}/lib/libvulkan.so.1 $out/lib/ </ins> for f in geekbench5 geekbench_x86_64 ; do patchelf --set-interpreter $(cat ${stdenv.cc}/nix-support/dynamic-linker) $out/bin/$f <del> wrapProgram $out/bin/$f --prefix LD_LIBRARY_PATH : "${stdenv.lib.makeLibraryPath [ stdenv.cc.cc.lib ]}" </del> <ins> wrapProgram $out/bin/$f --prefix LD_LIBRARY_PATH : "${stdenv.lib.makeLibraryPath [ stdenv.cc.cc.lib ]}:$out/lib/" </ins> done '';

Discussion:
Describe the bug don't list compute devices Expected behavior I have a Radeon RX 480 and use PR to have OpenCL support in Mesa. BOINC and detects the GPU as OpenCL device. And even Vulkan seems to work: Same with Nvidia: Notify maintainers Metadata system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Maintainer information:
My next step would be to add as dependency and to the PATH. It works in BOINC.
That would be too easy... further debugging. So we need , , , and in the PATH. I figured it out!