Question: , libxkbcommon, xcbutilxrm, hicolor-icon-theme , asciidoctor , fontsConf <ins> , gtk3Support ? false, gtk3 ? null </ins> }: <ins> # needed for beautiful.gtk to work assert gtk3Support -> gtk3 != null; </ins> with luaPackages; stdenv.mkDerivation rec { name = "awesome-${version}"; version = "4.3";

Cc: First of all, thanks to everyone for working on NixOS. Awesome 4.3 has a module called , it allows It can be used for theming, as shown in . However, the current build does not include the typelib files needed by the module making it unusable. The  implementation uses lgi to obtain via gobject-introspec return require('lgi').Gtk Since the current build does not include the typelib files needed, the above call fails. After some experimentation, I found out that both and are needed. For example: and try to load Gtk: fails with (the package that actually includes the typelib file) and add the folder to the environment variable: fails with and add it to and finally loads. Awesome as window manager to load the example gtk theme awesome the warnings issues by Awesome: I suggest that both and are as build inputs to the awesome package, I tried this out and it actually works. The catch is that the closure size increases by 123.9M: build awesome without gtk3-x11 and atk -99.6M build awesome with gtk3-x11 and atk -223.4M So, instead of adding the packages unconditionally, we could add an optional flag, like e.g. , defaulting to false. In this way, one could always build awesome and add it to . Ideally one could even add something like to the top level , a bit like : If a decision is made, I'd be happy to submit a PR. system: host os: multi-user?: sandbox: version: channels(root): channels(user): nixpkgs: awesome 4.3 (Too long) Compiled against Lua 5.2.4 (running with Lua 5.2) D-Bus support: execinfo support: xcb-randr version: 1.6 LGI version: 0.9.2
It should not be necessary to use , should work just fine. See for docs on , which will populate the environment variable automatically.
Thanks, I'll have a look. For the record, I used because that's where told be the typelib files where. I am still keen on hearing what the correct solution would be regarding how to add support (closure size, optional arguments etc.). Thanks.
thanks for our suggestions.


Question: , libxkbcommon, xcbutilxrm, hicolor-icon-theme , asciidoctor , fontsConf <ins> , gtk3Support ? false, gtk3 ? null </ins> }: <ins> # needed for beautiful.gtk to work assert gtk3Support -> gtk3 != null; </ins> with luaPackages; stdenv.mkDerivation rec { name = "awesome-${version}"; version = "4.3";

Here are my thoughts: seems to work as well, the closure size is 222.9M instead of 223.4M seems quite conveniet, but awesome needs additional options in the wrapper and it's unclear to me whether we could do that after introducint uses that seems to have negative effects, see so we may have to look for alternative solutions anyway (Awesome does not seem to use much of GTK anyway as it's not a GTK app)
how could it shrink? can use as described in the doc PR to add more options. , I am aware of that but other than hardcoding the typelibs like we do in GNOME Shell extensions, we do not have anything better at the moment. See for deeper analysis.
¯()/¯ maybe it's got less dependencies built than the one? I see, I somehow missed that. It seems that works OK (I am using this in an overlay on NixOS waiting for the patches to land in the stable channel): In the end, AwesomeWM should not need the whole of gtk, I think that gtk should be made optional so one can turn it on or off. Thanks, I did notice that and I'll keep an eye on it


Question: <del> { lib, stdenv, fetchurl, appimageTools, makeWrapper, electron, libsecret }: </del> <ins> { lib, stdenv, fetchurl, appimageTools, makeWrapper, electron_11, libsecret }: </ins> stdenv.mkDerivation rec { pname = "todoist-electron";

Describe the bug After electron 12 came out, adding in home-manager succeeds, but trying to start the app fails mentioning a missing javascript function from an older version of electron. To Reproduce Steps to reproduce the behavior: to home-manager's app from terminal with Expected behavior Expected the application start as it had before. Additional context I was able to get it working locally by providing an overlay to home-manager: I would have created a PR myself, but I'm still new to nix and not sure entirely how to require a different electron version in the package derivation. Notify maintainers Metadata Please run and paste the result. system: host os: multi-user?: sandbox: version: channels(jon): nixpkgs: Maintainer information:
thanks for catching this! Just fixed in the PR above.


Question: <ins> { lib , stdenv , fetchurl }: stdenv.mkDerivation (finalAttrs: { pname = "fleng"; version = "14"; src = fetchurl { url = "http://www.call-with-current-continuation.org/fleng/fleng-${finalAttrs.version}.tgz"; hash = "sha256-Js9bllX/399t9oeiRrqJNUFyYJwJVb/xSzwrcMrdi08="; }; doCheck = true; meta = { homepage = "http://www.call-with-current-continuation.org/fleng/fleng.html"; description = "A low level concurrent logic programming language descended from Prolog"; license = lib.licenses.publicDomain; maintainers = with lib.maintainers; [ AndersonTorres ]; platforms = lib.platforms.unix; }; }) # TODO: bootstrap </ins>

Project description From the home page: Metadata homepage URL: URL: public domain with two files under 3 clause BSD () platforms: "The system is known to run on Linux and BSD-based UNIX systems. Supported target architectures are x86-64 armv6 (hardfp), AArch64, Apple M1 and riscv64 (R64IMAFD)."


Question: afio = callPackage ../tools/archivers/afio { }; <del> afl = callPackage ../tools/security/afl { stdenv = clangStdenv; }; </del> honggfuzz = callPackage ../tools/security/honggfuzz { clang = clang_16; llvm = llvm_16;

Steps to reproduce the behavior: afl <!-- 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]:
If you are planing to open a PR, you don't need to create an issue first.
I wasn't sure, thanks for clarification


Question: { stdenv , python3 , fetchPypi <ins> , fetchpatch </ins> , src , version }:

Steps to reproduce the behavior: azure-cli 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.
For now, changing python used to seems to fix the build:
Made a PR that fixes the failure.
Will investigate this failure and try to fix it (by using Python 3.11), but the build was working before (We may temporarily fix it using as a workaround), some dependencies must have been changed, from before, not sure which one is causing this failure, I'd need to bisect commits on master branch, I guess...
The failure is because of python3.11, the tests didn't work properly on 3.11. Upstream fixed those tests for a future release. For now we can either rollback the python used to 3.10, or back port the tests fixed. From what I tested, nothing is broken on 3.11 except for those tests.
Thanks a lot for those clarifications and appreciating a lot your help in fixing all this However, we can't really make sure that those tests won't break again, unless we pin a patch on those ? And this is what you've done in your fix PR. I'll be trying the latest release 2.53.1 with the dependencies cleanup.


Question: stdenv.mkDerivation { name = "perf-linux-${kernel.version}"; <del> inherit (kernel) src makeFlags; </del> <ins> inherit (kernel) src; </ins> preConfigure = '' cd tools/perf

First failing build (4.9.76, but not always): Latest (4.9.77): Looking through the changes for any obvious culprits...
bisected to (as the first "bad commit"). cc
Reverting the commit on master fixes the build, but need to replace with to at least fix evaluation on cross. Since doesn't seem to build on cross (at least not on any architectures I've tried) I can't tell if this "works", but would be good to fix this on non-cross regardless.
See corresponding PR, this has been handled. Thanks!


Question: owner = "plymouth"; repo = "plymouth"; rev = finalAttrs.version; <del> hash = "sha256-Uun4KtrbkFCiGq3WpZlZ8NKKCOnM+jcgYa8qoqAYdaw="; </del> <ins> hash = "sha256-9JmZCm8bjteJTQrMSJeL4x2CAI6RpKowFUDSCcMS4MM="; </ins> }; patches = [

For a few days, when booting my amd computer with plymouth enabled I can't enter my passphrase anymore. Pushing keys multiple times eventually end up in one key-press being accepted. Booting with instead of suddenly has no more issues with keyboard entries. Steps to reproduce the behavior: NixOS Unstable to and with a LUKS/ZFS Passphrase -presses are omitted Every key I hit will be used. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- ? system: host os: multi-user?: sandbox: version: channels(pl): channels(root): nixpkgs: Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Upstream bug report Fixed in upstream already


Question: rm -rf $out/var rm -rf $siteVersionDir <ins> nuke-refs $out/libexec/emacs/*/*/emacs.pdmp </ins> '' + lib.optionalString withCsrc '' for srcdir in src lisp lwlib ; do dstdir=$siteVersionDir/$srcdir

Describe the bug In NixOS 20.09, Emacs now has the output of gtk+ in its closure, which in turn causes it to pull in stuff like mesa-drivers (424 MiB): This caused the closure size of Emacs to increase from 339 MiB in NixOS 20.03 to 1324 MiB in 20.09. Metadata NixOS 20.09..
cc
This was reverted in
This issue has been mentioned on NixOS Discourse. There might be relevant details there:


Question: ] ++ lib.optionals stdenv.isDarwin [ "-DWITH_OPENCL=OFF" "-DWITH_LAPACK=OFF" <del> "-DBUILD_opencv_videoio=OFF" </del> ] ++ lib.optionals enablePython [ "-DOPENCV_SKIP_PYTHON_LOADER=ON" ];

Describe the issue In the opencv build for mac, why is off by default? What needs to be done to enable it? (either development work, dependencies that aren't yet nixpkgs, or, if possible, how to manually override the argument and simply set to ) To Reproduce See above Expected behavior There may be a good reason it's disabled, so I can't say that I'd expect videoio to be enabled by default. Notify maintainers Metadata Please run and paste the result. Maintainer information:
It was removed here 15 months ago: See this PR: due to apple removing most of QTkit in 10.12 Brew does not use this option. You can use an overlay or a nixpkgs checkout with this patch to build with videoio The following will drop you into a nix-shell with the patched opencv, which you can use for testing. I'm not sure if it builds. FWIW, I get the following build failure which indicates the upstream issue might not be resolved, or we're missing some thing in our derivation.
I was originally attempting to use an overlay. After getting nowhere, I made a , which is what redirected me to the nix build. So if you want to help me close that thread, that'd be awesome cause both me and the person that helped me still don't know how to access/change the from an overlay.


Question: DataInfo(), "" ); MethodBase *method = (dynamic_cast<MethodBase*>(im)); <del> diff -aru a/core/base/inc/TString.h b/core/base/inc/TString.h --- a/core/base/inc/TString.h +++ b/core/base/inc/TString.h @@ -106,7 +106,7 @@ char          operator[](Ssiz_t i) const;     // Index with bounds checking operator std::string_view() const { return std::string_view(Data(),fExtent); } -   operator std::string() const { return std::string_view(Data(),fExtent).to_string(); } +   operator std::string() const { return static_cast<std::string>(std::string_view(Data(),fExtent)); } const char   *Data() const; Ssiz_t        Length() const          { return fExtent; } </del>

I have a system without Command Line Tools or XCode and nix'es cmake can't find headers and tries to pick up system frameworks. Try to build this: On my system I get: System: Darwin Nix version: nix-env (Nix) 1.11.9 Nixpkgs version: 17.09pre-git () Sandboxing enabled: no
Related to


Question: , libXtst , zlib , maven <ins> , webkitgtk , glib-networking </ins> }: stdenv.mkDerivation rec {

DBeaver has support to show spatial data on a map when the database is capable (e.g. postgres + postgis) but opening "spatial" tab gives this error: Steps to reproduce the behavior: dbeaver to a table that has a geometry, show data "Spatial" on the left A map should be shown This happens on master and 21.05-release, didn't test on 21.11 but I suppose it's the same Maintainer information:
I was able to reproduce the error and have fixed it. This is how the map now looks with a sample polygon taken from !
Wow that was quick! Thank you a lot!


Question: nixnote2 = libsForQt514.callPackage ../applications/misc/nixnote2 { }; <ins> nodenv = callPackage ../development/tools/nodenv { }; </ins> nodejs = hiPrio nodejs-16_x; nodejs-slim = nodejs-slim-16_x;

Project description nodenv is one of version managers. I know you can manege with Nix itself, but majority of people in the frontend world assume everyone uses version managers which respect files like or , so you have to use them when you're working with them. Metadata homepage URL: source URL: license: MIT platforms: I'm not sure actually, but it's distributed as a homebrew formula
Hello, please check the merged pull request for notes on the package. The package works, but might need some changes or be extended to work better in the future.
Wow, thanks a lot for your help!


Question: , cairo , git , hyprland-protocols <ins> , hyprlang </ins> , jq , libGL , libdrm

Package name: hyprland Latest released version: 0.36.0 <!-- Search your package here: --- Current version on the unstable channel: 0.35.0 Current version on the stable/release channel: 0.32.3 <!-- 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]: The 035.0 has a bug that makes my system crash very often (nullptr when monitor is disconnected) the issue is supposed to be fixed in 0.36.0.


Question: patches = [ ./urw-font-files.patch ./doc-no-ref.diff <ins> (fetchpatch { name = "CVE-2019-6116"; url = "http://git.ghostscript.com/?p=ghostpdl.git;a=patch;h=d3537a54740d78c5895ec83694a07b3e4f616f61"; sha256 = "1hr8bpi87bbg1kvv28kflmfh1dhzxw66p9q0ddvbrj72qd86p3kx"; }) </ins> ]; outputs = [ "out" "man" "doc" ];

, (nixos-unstable, nixos-19.03, nixos-18.09) Scanned versions: nixos-unstable: ; nixos-19.03: ; nixos-18.09: . May contain false positives.


Question: patches = [ ./urw-font-files.patch ./doc-no-ref.diff <ins> (fetchpatch { name = "CVE-2019-6116"; url = "http://git.ghostscript.com/?p=ghostpdl.git;a=patch;h=d3537a54740d78c5895ec83694a07b3e4f616f61"; sha256 = "1hr8bpi87bbg1kvv28kflmfh1dhzxw66p9q0ddvbrj72qd86p3kx"; }) </ins> ]; outputs = [ "out" "man" "doc" ];

Can't simply apply the upstream commits, unfortunately (AFAICT). This looks pretty serious!
Thank you!! :sparkle:


Question: strictDeps = true; <del> installPhase = '' DESTDIR=$out PREFIX=/ make install wrapProgram $out/bin/clerk  --prefix PATH : "${lib.makeBinPath [ rofi mpc_cli perl util-linux libnotify ]}" ''; </del> <ins> installPhase = let binPath = lib.makeBinPath [ libnotify mpc-cli perl rofi util-linux ]; in '' runHook preInstall DESTDIR=$out PREFIX=/ make install wrapProgram $out/bin/clerk --prefix PATH : "${binPath}" runHook postInstall ''; </ins> meta = with lib; { description = "An MPD client built on top of rofi";

The mpccli package is missing bashcompletion, even though a bash completion file is in the upstream repo under contrib/mpc- . Steps to reproduce the behavior: the package a terminal and type It tries only to complete with the contents of the current directory mpc should be completed with the mpc subcomands like , , etc. On a regular system, the file would have to be installed under /etc/bashcompletion.d/ . I don't know whats the nix(os) equivalent to this.
First, I am not the maintainer of this package. Nonetheless I will review this. Second, in Nixpkgs we do "almost" the same: we use a special hook that installs those extra files at the . Now I need to sleep; please wait a bit more.


Question: stripLen = 1; hash = "sha256-wfIjdPhdUYAvbK5XyE1o2OtFOlJRj0X5mh7QQRjdyP0="; }) <ins> # Remove distutils for Python 3.12 compatibility # https://github.com/onionshare/onionshare/pull/1907 (fetchpatch { url = "https://github.com/onionshare/onionshare/commit/1fb1a470df20d8a7576c8cf51213e5928528d59a.patch"; includes = [ "onionshare/update_checker.py" ]; stripLen = 1; hash = "sha256-mRRj9cALZVHw86CgU17sp9EglKhkRRcGfROyQpsXVfU="; }) </ins> ]; <del> propagatedBuildInputs = [ </del> <ins> dependencies = with python3.pkgs; [ </ins> onionshare pyside6 qrcode

Steps to reproduce the behavior: onionshare <!-- 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 package distutils was remove in Python 3.12. Depends on upsteam. I raised a PR for the fix:


Question: atlassian-cli = callPackage ../applications/office/atlassian-cli { }; <del> pulsar = callPackage ../applications/editors/pulsar { }; </del> asap = callPackage ../tools/audio/asap { }; aseprite = callPackage ../applications/editors/aseprite { };

Package name: pulsar Latest released version: 1.117.0 Current version on the unstable channel: 1.114.0 Current version on the stable/release channel: 1.117.0 Notify maintainers


Question: dontWrapQtApps = true; <ins> postInstall = '' ln -s ${vgmstream.override { buildAudaciousPlugin = true; }}/lib/audacious/Input/* $out/lib/audacious/Input ''; </ins> meta = audacious.meta // { description = "Plugins for Audacious music player"; };

The audacious package imports audacious-plugins to build most of the common plugins and then link them into the audacious lib path. However, this makes it hard to add more audacious plugins, like vgmstream. The vgmstream package currently has its , because importing the audacious package causes an infinite recursion error. Steps to reproduce the behavior: vgmstream to audacious-plugins buildInputs audacious to vgmstream's buildInputs and comment out the disable configure flag -shell -p audacious-plugins I expected that adding vgmstream to audacious-plugins would enable the plugin. Instead, the build crashes with an infinite recursion. How is it currently working for audacious to import audacious-plugins and audacious-plugins to import audacious? Can this same magic be extended to other plugins? This about how fcitx is packaged shows that fcitx-addons imports fcitx with no reverse import, should the audacious package be refactored to be similar? Should the audacious package gain an extra parameter to take extra plugin derivations, which can be created outside of the audacious-plugins derivation? Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Instead of adding , did you try to add instead? is without as input, and it is used to break the loop.
Thank you for the quick response! That would be elegant, but I don't see any result in my grep of nixpkgs or in the .
Sorry, it is here: Basically you need to do and this should do the trick. Considering that we are going to use this in more than one place it probably makes sense to introduce it as a , but the result is the same regardless.
Oh that's a neat trick! I'll try that approach out next. Thank you so much! I tried out the extra-plugins approach here, seems to work but is not ergonomic:
I , and it's a lot easier to use as a user! If it looks good as an approach, please provide some review feedback and I'll squash it down for a PR :)
Shall I send a PR for a final review?


Question: default = true; description = "Enable the XFWM (default) window manager."; }; <ins> screenLock = mkOption { type = types.enum [ "xscreensaver" "xlockmore" "slock" ]; default = "xlockmore"; description = "Application used by XFCE to lock the screen."; }; </ins> }; };

It's not possible to lock screen in xfce unless "xlockmore" is installed. in in XFCE and try to lock without success and then retry to lock System: NixOS Emu Nix version: 1.11.2 Nixpkgs version: "16.03.973."
I think that's because there is no blessed lock screen for XFCE. tries XScreenSaver, GNOME Screensaver, XLock and SLock -- in that order.
Has a situation like this (multiple optional but at least one required dependency on an executable) already been handled in NixOS?
I think this is generally resolved by some kind of switch, but we have to add one. Something like of ...
I kept as-is: see
I think the issue may be resolved. At least with (as of 2023-09-17) lock screen is possible without having installed.


Question: stdenv.mkDerivation (finalAttrs: { pname = "juce"; <del> version = "7.0.9"; </del> <ins> version = "7.0.10"; </ins> src = fetchFromGitHub { owner = "juce-framework"; repo = "juce"; rev = finalAttrs.version; <del> hash = "sha256-k8cNTPH9OgOav4dsSLqrd5PlJ1rqO0PLt6Lwmumc2Gg="; </del> <ins> hash = "sha256-CAHhHPTUvIyDOh2CdvNmw26HfoWWtbqRRiR+3Ky4GYA="; </ins> }; patches = [

Package name: juce Latest released version: 7.0.10 Current version on the unstable channel: 7.0.9 Current version on the stable/release channel: 7.0.7 Notify maintainers Note for maintainers: Please tag this issue in your PR. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:


Question: <ins> { config, pkgs, lib, ... }: with lib; let pkg = [ pkgs.switcheroo-control ]; cfg = config.services.switcherooControl; in { options.services.switcherooControl = { enable = mkEnableOption "switcheroo-control, a D-Bus service to check the availability of dual-GPU"; }; config = mkIf cfg.enable { services.dbus.packages = pkg; environment.systemPackages = pkg; systemd.packages = pkg; systemd.targets.multi-user.wants = [ "switcheroo-control.service" ]; }; } </ins>

Project description A dbus api to start programs on a different GPU Metadata homepage URL: source license: gpl3 platforms: linux
Duplicate


Question: typing-extensions ]; <del> pytestFlagsArray = [ # Pass -c /dev/null so that pytest does not use the bundled pytest.ini, which adds # options to run additional integration tests that are overkill for our purposes. "-c" "/dev/null" ]; </del> <ins> # Remove the bundled pytest.ini, which adds options to run additional integration # tests that are overkill for our purposes. preCheck = '' rm pytest.ini ''; </ins> pythonImportsCheck = [ "bidict" ];

Steps to reproduce the behavior: hydra build: build logs: 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. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Not sure why this suddenly started failing after it worked fine for the last 11 days. Reproduced this and submitted a patch in that fixed it for me locally.
Thanks, I can confirm that the patch does work.
In my observation, it only breaks on , the works just fine. That's extremely weird.
I logged the test phase on the latest commit and the one before that, here’s what’s changed: Looks like it is to do with the
Nice work, It looks like is the commit that upgraded to pytest 8, but that was two weeks ago. So I'm not sure how this passed for 4 days ago.
The build that passed 4 days ago used as and the also wasn’t pointing to , here’s a snippet from the logs: The log file: But the latest build which failed, had set to and set to .


Question: "pillow" "httpx" "packaging" <ins> "typer" </ins> ]; propagatedBuildInputs = with python3Packages; [

Steps to reproduce the behavior: oterm 0.2.7 unstable (I'm doing via home-manager on rev ) Fails finding a typer version Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
I will check on my NixOS host later in the day to see if I can replicate.
There's a quick way to fix it:
Also, a PR in upstream:


Question: hash = "sha256-bHEBzl0aBXsHOhSWJUz428pG5M6L0s/Q6acKO+2oMXo="; }; <ins> patches = [ (substituteAll { src = ./fix-paths.patch; zenity = gnome.zenity; }) # compositor: Fix crash when restarting Cinnamon # https://github.com/linuxmint/muffin/pull/655 (fetchpatch { url = "https://github.com/linuxmint/muffin/commit/1a941ec603a1565dbd2f943f7da6e877d1541bcb.patch"; sha256 = "sha256-6x64rWQ20ZjM9z79Pg6QMDPeFN5VNdDHBueRvy2kA6c="; }) ]; </ins> nativeBuildInputs = [ desktop-file-utils mesa # needed for gbm

Restart cinnamon from the panel freezes the desktop, from the journal you will find cinnamon crashes. click the panel trouble shooting cinnamon No crash.
Okay, I guess I need upstream help for this, going to forward this to upstream...


Question: }; # grab the plugin sdk for the desktop icon <del> pluginsdk = fetchurl { url = "http://dl.4players.de/ts/client/pluginsdk/pluginsdk_3.1.1.1.zip"; sha256 = "1bywmdj54glzd0kffvr27r84n4dsd0pskkbmh59mllbxvj0qwy7f"; </del> <ins> pluginsdk = fetchzip { url = "https://files.teamspeak-services.com/releases/sdk/3.3.1/ts_sdk_3.3.1.zip"; hash = "sha256-wx4pBZHpFPoNvEe4xYE80KnXGVda9XcX35ho4R8QxrQ="; </ins> }; nativeBuildInputs = [ makeWrapper which <del> unzip </del> perl # Installer script needs `shasum` ];

Steps to reproduce the behavior: try to install/build the package using nix-shell or nixos the Domain is no longer configured. Teamspeak Download Pages redirects to this place: Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
You might want to check out
Not merged yet
As a workaround, until this is fixed in nixpkgs: The file is still available at the Internet Archive. You can fetch it from there and write it into the store, with something like this:


Question: }; }; in <del> python.pkgs.buildPythonApplication { </del> <ins> python.pkgs.buildPythonApplication rec { </ins> pname = "immich-machine-learning"; inherit (immich) version; src = "${immich.src}/machine-learning";

Build on () and when running I find the following in the runtime closure: pytest shouldn't be a runtime dependency Seems to be a regression, did not have this issue Might be able to bisect this one, but it'll take a while <!-- 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 bisecting, first bad commit is (


Question: daphne = callPackage ../development/python-modules/daphne { }; <ins> daqp = callPackage ../development/python-modules/daqp { }; </ins> dasbus = callPackage ../development/python-modules/dasbus { }; dash = callPackage ../development/python-modules/dash { };

Project description qpsolvers is python library for solving quadratic programming problems. It contains wrappers for multiple solvers like osqp, cvxopt, quadprog and much more. Metadata homepage URL: source URL: license: LGPLv3 platforms: platform independent (python3.10)
This package wants new version of and new package - . I will try add PR today, but now you can use my NUR repo if you want:


Question: appimageContents = appimageTools.extractType2 { inherit name src; }; <del> in appimageTools.wrapType2 rec { </del> <ins> # Hotplug events from udevd are fired into the kernel, which then re-broadcasts them over a # special socket, to every libudev client listening for hotplug when the kernel does that. It will # try to preserve the uid of the sender but a non-root namespace (like the fhs-env) cant map root # to a uid, for security reasons, so the uid of the sender becomes nobody and libudev actively # rejects such messages. This patch disables that bit of security in libudev. # See: https://github.com/NixOS/nixpkgs/issues/116361 systemdPatched = systemd.overrideAttrs ({ patches ? [ ], ... }: { patches = patches ++ [ ./systemd.patch ]; }); in appimageTools.wrapType2 rec { </ins> inherit name src; <ins> extraPkgs = pkgs: [ systemdPatched ]; </ins> extraInstallCommands = '' mv $out/bin/${name} $out/bin/${pname} install -m 444 -D ${appimageContents}/ledger-live-desktop.desktop $out/share/applications/ledger-live-desktop.desktop

Describe the bug From IRC: ; Looks like we currently just use their appimage: and our appimage tooling uses buildUserFHSEnv: It seems like we can either: using (build from source, maybe?) similar to how iohk patches Daedalus.
I tried packaging it with yarn2nix, but stumbled upon , unfortunately.
I don't know much about the appimage architecture. Why exactly can we not run appimages natively without FhsUserEnv? Is it just because binaries linking against fhs paths? In this case we probably could run autoPatchelfHook on the contents of the appimage and produce a new image that links against nix libs. EDIT: I just tried this. Extracted the appimage contents, patched all binaries, but then when executing ledger-live-desktop, I'm getting: Currently I'm running ledger live via qemu + usb device passthru via . That works fine.
how difficult would it be to lift Daedalus's patch and use it for the libudev inside the fhs? I've never worked with FHS before, but also don't want to build ledger live from source...
I tried to build ledger live from source and it didn't work because of the issue that mentioned. Patching libudev worked though.
can you link to the patch? It would be great to be able to use my more-trusted nixos machines for these types of activities.
I already created a PR for it and it's referenced above. This one:
Feel free to comment in the PR whether it actually works for you :)
The patch had to be re-done in Should this problem probably be communicated to upstream, so we can think about how to fix this long-term in a more sustainable fashion?


Question: # cross-compiling. ./always-search-rpath.patch <del> ] ++ lib.optionals (!stdenv.targetPlatform.isVc4) [ # https://sourceware.org/bugzilla/show_bug.cgi?id=22868 ./gold-symbol-visibility.patch # https://sourceware.org/bugzilla/show_bug.cgi?id=23428 # un-break features so linking against musl doesn't produce crash-only binaries ./0001-x86-Add-a-GNU_PROPERTY_X86_ISA_1_USED-note-if-needed.patch ./0001-x86-Properly-merge-GNU_PROPERTY_X86_ISA_1_USED.patch ./0001-x86-Properly-add-X86_ISA_1_NEEDED-property.patch </del> ] ++ lib.optional stdenv.targetPlatform.isiOS ./support-ios.patch; outputs = [ "out" "info" "man" ];

Describe the bug is currently in nixpkgs master. It was released in July 2018. was released in October 2019. It contains a few improvements and may also contains fix for some vulnerabilities: Is there a reason to keep the old version in nixpkgs, other than a lack of manpower? I'd be happy to do this work, but I just want to be sure that I was not starting a long, difficult and redundant work. I already tried a "naive" bump of the and but it does not work, mostly because most of the patchs are not valid anymore.
This was solved by cc.
Thank you for continuing this work!


Question: # code here, we'll cause an infinite recursion. Since a set with # clang as its default compiler always means libc++, we can infer this # decision statically. <del> then buildPackages.llvmPackages.libcxxClang </del> <ins> then buildPackages.pkgsBuildTarget.llvmPackages.libcxxClang </ins> else buildPackages.gcc else # This will blow up if anything uses it, but that's OK. The `if

Steps to reproduce the behavior: something which uses (easily ) 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. --No maintainers, blame says last made a modification. Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
No maintainers, blame says last made a modification. Hm, I can’t recall changing anything remotely related to LLVM and/or wrapper stuff recently. Which file(s) are you referring to?


Question: - The `hardware.pulseaudio` module now sets permission of pulse user home directory to 755 when running in "systemWide" mode. It fixes [issue 114399](https://github.com/NixOS/nixpkgs/issues/114399). <ins> - The `services.networkmanager.extraConfig` was renamed to `services.networkmanager.settings` and was changed to use the ini type instead of using a multiline string. </ins> - The module `services.github-runner` has been removed. To configure a single GitHub Actions Runner refer to `services.github-runners.*`. Note that this will trigger a new runner registration. - The `services.slskd` has been refactored to include more configuation options in

Describe the bug NetworkManager is a particularly important component and we don't have any tests for it that could block a channel advance. In particular, a change can happen on nixos-unstable leaving users without functioning networking, and while rollbacks are possible it isn't an excuse to allow that to reach production systems. NixOS doesn't produce either. Manual testing is also cumbersome if we want to make a new stable release. Upstream NetworkManager does have some integration testing but obviously not useful to us. I think to start, if we at least had a test that verifies the services start without issues would be great.
Agreed. While developing tests for the multipath TCP module I was surprised to see no networkmanager module. I had some difficulties with the nixos test infrastructure at first because the test infra will by default install a slirp interface () and it messed up the interface naming. Like I would clear but interfaces would still be named starting from instead of . Just thought I would mention it in case the brave soul writing the test is interested in multihoming. (but that's more a concern I have with the test infra).
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 . 3. Ask on the on .
Bleh.
I marked this as stale due to inactivity. →
consequences of our inactions


Question: <ins> diff --git a/src/builder-context.c b/src/builder-context.c index dde12790..3a379297 100644 </ins> --- a/src/builder-context.c +++ b/src/builder-context.c <ins> @@ -256,7 +256,7 @@ builder_context_init (BuilderContext *self) g_autofree char *path = NULL; self->rofiles_file_lock = init; -  path = g_find_program_in_path ("rofiles-fuse"); +  path = g_find_program_in_path ("@rofilesfuse@"); self->have_rofiles = path != NULL; } </ins> @@ -800,7 +800,7 @@ builder_context_enable_rofiles (BuilderContext *self, g_autoptr(GFile) rofiles_base = NULL; g_autoptr(GFile) rofiles_dir = NULL;

Describe the bug flatpak-builder for some reasons can't use rofiles-fuse To Reproduce Steps to reproduce the behavior: build any app using flatpak-builder Expected behavior flatpak-builder should use rofiles-fuse. Screenshots Additional context Metadata system: host os: multi-user?: sandbox: version: channels(root): channels(piotrek): nixpkgs: Maintainer information:
installing solve this problem so maybe should be ?
We patch the paths to the executables to be hardcoded, so the program doesn't have to rely on something like ostree being installed. I believe one path isn't hardcoded with the current patch That looks it up in PATH, probably why it was working once you installed it.
cc
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 . 3. Ask on the on .
should fix that issue.


Question: <ins> --- a/Build.PL +++ b/Build.PL @@ -88,7 +88,7 @@ if ( $^O =~ /mswin32/i ) { } } else { -    if ( $Config{archname} =~ /^x86_64|^ppc64|^s390x|^aarch64|^riscv64/ ) { +    if ( 0 ) { $libdir =~ s/bbinb/lib64/; if ( !-d $libdir ) { my $test = $libdir; </ins>

Steps to reproduce the behavior: Confirmed locally against recent master () system: host os: multi-user?: sandbox: version: nixpkgs:
There's already a PR fixing this build failure:
looks like this is being addressed in
Can confirm, fixes build-issues on unstable :)
Fix has been merged. Feel free to reopen if the issue persists after the next channel bump


Question: <ins> diff --git a/thirdparty/CMakeLists.txt b/thirdparty/CMakeLists.txt index f33b3bf3f..1214f179c 100644 --- a/thirdparty/CMakeLists.txt +++ b/thirdparty/CMakeLists.txt @@ -16,6 +16,5 @@ if(NOT "${SRB2_CONFIG_SYSTEM_LIBRARIES}") include("cpm-png.cmake") include("cpm-curl.cmake") include("cpm-openmpt.cmake") +	include("cpm-libgme.cmake") endif() - -include("cpm-libgme.cmake") </ins>

use instead of pulling the windows zip from github releases
I can review if you want to PR this
upstream has said that they'd rather us use the github mirror that they're going to set up
the github mirror has been created
Sorry, I have to delete the github mirror, due to bandwidth limits. Please use
the "SRB22.2" branch and/or "SRB2release_2.2.13" tag
Getting 500 errors when trying to access
does this work for you?
The link works however the download buttons don't. PRs welcome if anyone can get it working, but wait for to be merged first to avoid merge conflicts.
i have had another look, and have found that it might be better to pull directly from branch
Thanks, was able to get it to work with :+1:


Question: url = "https://git.archlinux.org/svntogit/packages.git/plain/trunk/qtbug-77037-workaround.patch?h=packages/qt5-webengine&id=fc77d6b3d5ec74e421b58f199efceb2593cbf951"; sha256 = "1gv733qfdn9746nbqqxzyjx4ijjqkkb7zb71nxax49nna5bri3am"; }) <ins> # Fix build with bison-3.7: https://code.qt.io/cgit/qt/qtwebengine-chromium.git/commit/?id=1a53f599 (fetchpatch { name = "qtwebengine-bison-3.7-build.patch"; url = "https://code.qt.io/cgit/qt/qtwebengine-chromium.git/patch/?id=1a53f599"; sha256 = "1nqpyn5fq37q7i9nasag6i14lnz0d7sld5ikqhlm8qwq9d7gbmjy"; stripLen = 1; extraPrefix = "src/3rdparty/"; }) </ins> ] ++ optionals stdenv.isDarwin [ ./qtwebengine-darwin-no-platform-check.patch ./qtwebengine-darwin-fix-failed-static-assertion.patch

Describe the bug qtwebengine fails just after successfully configuring with error message To Reproduce ` Expected behavior should compile Notify maintainers Metadata
Pull request works on my machine. Thx.


Question: springLobby = callPackage ../games/spring/springlobby.nix { }; <del> srb2 = callPackage ../games/srb2 { }; </del> ssl-cert-check = callPackage ../tools/admin/ssl-cert-check { }; stardust = callPackage ../games/stardust { };


Question: <del> { lib , fetchFromGitLab , fetchPypi , apksigner , buildPythonApplication , python3 , installShellFiles , androguard , babel , clint , defusedxml , gitpython , libcloud , mwclient , paramiko , pillow , pyasn1 , pyasn1-modules , python-vagrant , pyyaml , qrcode , requests , ruamel-yaml , yamllint </del> <ins> { lib, fetchFromGitLab, fetchPypi, apksigner, appdirs, buildPythonApplication, python3, installShellFiles, androguard, babel, clint, defusedxml, gitpython, libcloud, mwclient, oscrypto, paramiko, pillow, pyasn1, pyasn1-modules, python-vagrant, pyyaml, qrcode, requests, ruamel-yaml, sdkmanager, yamllint, </ins> }: <del> buildPythonApplication rec { </del> <ins> let version = "2.3a1"; in buildPythonApplication { </ins> pname = "fdroidserver"; <del> version = "unstable-2023-10-23"; format = "setuptools"; </del> <ins> inherit version; pyproject = true; </ins> src = fetchFromGitLab { owner = "fdroid"; repo = "fdroidserver"; <del> rev = "f4b10cf83935432d19948dac669964384bef0728"; hash = "sha256-GmR6Td5pScwEKK9W6m26xQV4XxBdZ7frN2UvwUGY4Dw="; </del> <ins> rev = "2.3a1"; hash = "sha256-K6P5yGx2ZXHJZ/VyHTbQAObsvcfnOatrpwiW+ixLTuA="; </ins> }; pythonRelaxDeps = [ <ins> "androguard" </ins> "pyasn1" "pyasn1-modules" ]; postPatch = '' substituteInPlace fdroidserver/common.py  <del> --replace "FDROID_PATH = os.path.realpath(os.path.join(os.path.dirname(__file__), '..'))" "FDROID_PATH = '$out/bin'" </del> <ins> --replace-fail "FDROID_PATH = os.path.realpath(os.path.join(os.path.dirname(__file__), '..'))" "FDROID_PATH = '$out/bin'" </ins> ''; preConfigure = ''

Steps to reproduce the behavior: build .#fdroidserver Git bisect predictably found the culprit as , so it is related to the Python 3.12 upgrade. I suspect that all setuptools-based modules are broken; e.g. also stops building. Interestingly, built before, but not after. Not sure what that implies. (Originally I had notified the Python team, but I removed them from this list because I am suspecting this regression may not be the result of any problem with the version flip itself, but the broken packages instead. Sorry.) Notifying from fdroidserver maintainers. Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:


Question: python3.pkgs.buildPythonApplication rec { pname = "fava"; <del> version = "1.18"; </del> <ins> version = "1.19"; </ins> src = python3.pkgs.fetchPypi { inherit pname version; <del> sha256 = "21336b695708497e6f00cab77135b174c51feb2713b657e0e208282960885bf5"; </del> <ins> sha256 = "def7c0210bf0ce8dfffdb46ce21b3efcf71eba5a4e903565258419e4c53c2d43"; </ins> }; nativeBuildInputs = with python3.pkgs; [ setuptools-scm ];

Describe the bug nixos-unstable-small's package is broken: Seems related to beancount/fava To Reproduce Steps to reproduce the behavior: Expected behavior Fava builds correctly 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:
I suspect this isn't the only app that broke with the switch from flask 1.2 to 2.0 and jinja 2 to 3.0.1
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
You can use in the expression for to pin and to compatible versions.


Question: ocl-icd glib libarchive <ins> libxcrypt # provides libcrypt.so.1 </ins> xdg-utils # xdg-open needed to open URLs python2 # currently they want python 3.6 which is EOL

it does not start anymore Steps to reproduce the behavior: davinci-resolve davinci-resolve Working Program. Installed from unstable 22.11pre420742.. system: host os: multi-user?: sandbox: version: channels(root): nixpkgs:


Question: <ins> #!/usr/bin/env nix-shell #! nix-shell -i bash -p node2nix MONGOSH_ROOT="$( cd "$(dirname "$0")" pwd )" pushd $MONGOSH_ROOT 1>/dev/null rm -rf gen && mkdir -p gen node2nix  --no-copy-node-env  --node-env ../../node-packages/node-env.nix  --input packages.json  --output gen/packages.nix  --composition gen/composition.nix  --strip-optional-dependencies  --nodejs-14 popd 1>/dev/null </ins>

Project description The MongoDB Shell Metadata homepage URL: source URL: license: APACHE LICENSE, VERSION 2.0 platforms: linux, darwin
I will like to have it on too but fyi there is a NUR package.
Thanks, I haven't searched in NUR


Question: buildPythonPackage rec { pname = "osqp"; <del> version = "0.6.2.post8"; </del> <ins> version = "0.6.3"; </ins> format = "setuptools"; disabled = pythonOlder "3.7"; src = fetchPypi { inherit pname version; <del> hash = "sha256-I9a65KNhL2DV9lLQ5fpLLq1QfKv/9dkw2CIFeubtZnc="; </del> <ins> hash = "sha256-A+Rg5oPsLOD4OTU936PEyP+lCauM9qKyr7tYb6RT4YA="; </ins> }; <del> postPatch = '' sed -i 's/sp.random/np.random/g' src/osqp/tests/*.py ''; </del> SETUPTOOLS_SCM_PRETEND_VERSION = version; dontUseCmakeConfigure = true;


Question: (fetchNuGet { pname = "runtime.any.System.Threading.Tasks"; version = "4.3.0"; sha256 = "03mnvkhskbzxddz4hm113zsch1jyzh2cs450dk3rgfjp8crlw1va"; }) (fetchNuGet { pname = "runtime.any.System.Threading.Timer"; version = "4.3.0"; sha256 = "0aw4phrhwqz9m61r79vyfl5la64bjxj8l34qnrcwb28v49fg2086"; }) (fetchNuGet { pname = "runtime.debian.8-x64.runtime.native.System.Security.Cryptography.OpenSsl"; version = "4.3.0"; sha256 = "16rnxzpk5dpbbl1x354yrlsbvwylrq456xzpsha1n9y3glnhyx9d"; }) <del> (fetchNuGet { pname = "runtime.debian.8-x64.runtime.native.System.Security.Cryptography.OpenSsl"; version = "4.3.2"; sha256 = "0rwpqngkqiapqc5c2cpkj7idhngrgss5qpnqg0yh40mbyflcxf8i"; }) </del> (fetchNuGet { pname = "runtime.fedora.23-x64.runtime.native.System.Security.Cryptography.OpenSsl"; version = "4.3.0"; sha256 = "0hkg03sgm2wyq8nqk6dbm9jh5vcq57ry42lkqdmfklrw89lsmr59"; }) <del> (fetchNuGet { pname = "runtime.fedora.23-x64.runtime.native.System.Security.Cryptography.OpenSsl"; version = "4.3.2"; sha256 = "1n06gxwlinhs0w7s8a94r1q3lwqzvynxwd3mp10ws9bg6gck8n4r"; }) </del> (fetchNuGet { pname = "runtime.fedora.24-x64.runtime.native.System.Security.Cryptography.OpenSsl"; version = "4.3.0"; sha256 = "0c2p354hjx58xhhz7wv6div8xpi90sc6ibdm40qin21bvi7ymcaa"; }) <del> (fetchNuGet { pname = "runtime.fedora.24-x64.runtime.native.System.Security.Cryptography.OpenSsl"; version = "4.3.2"; sha256 = "0404wqrc7f2yc0wxv71y3nnybvqx8v4j9d47hlscxy759a525mc3"; }) </del> (fetchNuGet { pname = "runtime.native.System"; version = "4.0.0"; sha256 = "1ppk69xk59ggacj9n7g6fyxvzmk1g5p4fkijm0d7xqfkig98qrkf"; }) (fetchNuGet { pname = "runtime.native.System"; version = "4.3.0"; sha256 = "15hgf6zaq9b8br2wi1i3x0zvmk410nlmsmva9p0bbg73v6hml5k4"; }) (fetchNuGet { pname = "runtime.native.System.IO.Compression"; version = "4.3.0"; sha256 = "1vvivbqsk6y4hzcid27pqpm5bsi6sc50hvqwbcx8aap5ifrxfs8d"; })

Package name: Latest released version: <!-- Search your package here: --- Current version on the unstable channel: Current version on the stable/release channel: <!-- 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]:


Question: pygments ]; <ins> in stdenv.mkDerivation rec { pname = "pwndbg"; version = "2019.01.25"; format = "other"; src = fetchFromGitHub { owner = "pwndbg"; repo = "pwndbg"; rev = version; sha256 = "0k7n6pcrj62ccag801yzf04a9mj9znghpkbnqwrzz0qn3rs42vgs"; }; nativeBuildInputs = [ makeWrapper ]; </ins> installPhase = '' mkdir -p $out/share/pwndbg cp -r *.py pwndbg $out/share/pwndbg <ins> chmod +x $out/share/pwndbg/gdbinit.py </ins> makeWrapper ${gdb}/bin/gdb $out/bin/pwndbg  <del> --add-flags "-q -x $out/share/pwndbg/gdbinit.py" ''; preFixup = '' sed -i "/import sys/a import sys; sys.path[0:0] = '$PYTHONPATH'.split(':')"  $out/share/pwndbg/gdbinit.py </del> <ins> --add-flags "-q -x $out/share/pwndbg/gdbinit.py"  --set NIX_PYTHONPATH ${pythonPath} </ins> ''; meta = with stdenv.lib; {

Describe the bug fails to run because setuptools is no longer propagated implictly. If were purely a python application built with then we would just need to add to propagatedBuildInputs and be done. However, is not simply a Python application, but a wrapper around , and isn't built using. The derivation patches the script as follows: This does result in the site-packages directories from all python packages ending up in , including setuptools (e.g. ). I'm not that familiar with Python packaging but from experimenting I found that the full path to the Python egg needs to be included (e.g. ) in order for this method to work. I made an attempt at resolving the issue but being new to Python packaging in Nix, neither are likely to be ideal: We could use buildPythonPackage in place of mkDerivation, using and use Or continue to use mkDerivation and manually set for patchPythonScript: I'm happy to submit a PR but I'm not sure what the recommended solution is here. To Reproduce Steps to reproduce the behavior: Expected behavior should launch with the extension loaded: Metadata system: host os: multi-user?: sandbox: version: nixpkgs: Maintainer information:
It seems is normally used by adding a to , or calling with (what the wrapper registered in does). This script then just does some addition calculations to register itself (we probably don't that at all) and some python 2 specific fixups, and then calls , which starts executing some code on import. I'd suggest to package it as a regular python application first (via ), so you can successfully import it inside a . The python tooling should automatically take care of patching the python shebang properly if you make script executable.
proposed fix


Question: <del> {stdenv, fetchurl, autoconf, automake, libtool}: </del> <ins> {stdenv, lib, fetchFromGitLab, autoconf, automake, libtool}: </ins> stdenv.mkDerivation rec { <del> pName = "soundtouch"; name = "${pName}-2.0.0"; src = fetchurl { url = "https://www.surina.net/soundtouch/${name}.tar.gz"; sha256 = "09cxr02mfyj2bg731bj0i9hh565x8l9p91aclxs8wpqv8b8zf96j"; </del> <ins> pname = "soundtouch"; version = "2.1.2"; src = fetchFromGitLab { owner = pname; repo = pname; rev = version; sha256 = "174wgm3s0inmbnkrlnspxjwm2014qhjhkbdqa5r8rbfi0nzqxzsz"; </ins> }; <del> buildInputs = [ autoconf automake libtool ]; </del> <ins> nativeBuildInputs = [ autoconf automake libtool ]; </ins> preConfigure = "./bootstrap"; <del> meta = { description = "A program and library for changing the tempo, pitch and playback rate of audio"; homepage = http://www.surina.net/soundtouch/; downloadPage = http://www.surina.net/soundtouch/sourcecode.html; license = stdenv.lib.licenses.lgpl21; platforms = stdenv.lib.platforms.all; </del> <ins> meta = with lib; { description = "A program and library for changing the tempo, pitch and playback rate of audio"; homepage = "http://www.surina.net/soundtouch/"; license = licenses.lgpl21; platforms = platforms.all; </ins> }; }

, (nixos-unstable) (nixos-unstable) (nixos-unstable) Scanned versions: nixos-unstable: . May contain false positives.
See also


Question: }; }; <del> makeLuksRootTest = name: luksFormatOpts: makeInstallerTest "luksroot-format2" </del> <ins> makeLuksRootTest = name: luksFormatOpts: makeInstallerTest name </ins> { createPartitions = '' $machine->succeed( "flock /dev/vda parted --script /dev/vda -- mklabel msdos"

See:
I've been using cryptsetup with an SSD and without kernel crypto to run my entire NixOS and didn't noted any performance issues, but I agree that my patch was a temporary workaround, so enabling the crypto module would be a better solution.
The option also breaks the feature of that can be used when installing nixos to reason about the speed of disk encryption
The NixOS test works with and the kernel userapace crypto API enabled in on at least 19.03. was updated to 2.0.6 in the meantime, maybe the bug was fixed? Haven't noticed anything in release notes. This API shouldn't in fact be need for LUKS, only for tcrypt and the benchmark. Did you also run the test or did you just notice that on your local machine? Do you have any non-standard config concerning the initrd?
Hmm, even with the test succeeds. We need more information.
I haven't ran any tests, I just tested it in my work laptop and in a VM used to isolate the issue. I used a non-standard initrd config only for debugging, but after finding the problem I used the standard one. The only strange thing I did was to have a LUKS2 encrypted volume, which isn't very common (or at least it wasn't at the moment I experienced the issue). In a few days I will try to boot my system both with and without kernel crypto to check whether it is necessary or not.
I can confirm that I still have problems booting my system when kernel crypto is enabled. I put this in my , in an updated unstable NixOS: With this configuration, my system boots. If I uncomment the line, it doesn't because it fails to unencrypt my root partition. I'm using LVM inside a LUKS2 partition.
Here is the result of using when mounting my LUKS2 volume with kernel crypto enabled. The last image is the most important. Sorry for pasting screenshots, I didn't have a flash drive to copy the logs. ! ! ! ! !
Thank you very much for your detailed analysis. :+1: Oh, LUKS2! Seems the userspace API is indeed needed for LUKS2 but not LUKS1. I'll try to adapt the test and fix this issue. There are probably just some modules missing.


Question: }; }; <del> makeLuksRootTest = name: luksFormatOpts: makeInstallerTest "luksroot-format2" </del> <ins> makeLuksRootTest = name: luksFormatOpts: makeInstallerTest name </ins> { createPartitions = '' $machine->succeed( "flock /dev/vda parted --script /dev/vda -- mklabel msdos"

Commit introduced to the configuration of . This causes to no longer work, with the following message: Run , where is a truecrypt volume. system: host os: multi-user?: sandbox: version: channels(root): nixpkgs:
The issue for re-enabling kernel_crypto is
It also breaks
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 .
still important to me
I marked this as stale due to inactivity. →
are you sure this is still an issue? This seems to have been solved by . e.g. cryptsetup benchmark works just fine on my machine.
I did not check and do not care anymore. Thanks!


Question: substituteInPlace ./src/3rdparty/chromium/v8/gypfiles/standalone.gypi  --replace /bin/echo ${coreutils}/bin/echo '' <ins> # Prevent Chromium build script from making the path to `clang` relative to # the build directory.  `clang_base_path` is the value of `QMAKE_CLANG_DIR` # from `src/core/config/mac_osx.pri`. + optionalString stdenv.isDarwin '' substituteInPlace ./src/3rdparty/chromium/build/toolchain/mac/BUILD.gn  --replace 'prefix = rebase_path("$clang_base_path/bin/", root_build_dir)' 'prefix = "$clang_base_path/bin/"' '' </ins> # Patch library paths in Qt sources + '' sed -i

The component of the derivation fails to compile on MacOS. But in two ways, and I can't tell what causes one or the other to trigger. On command: On command: the channel compilation failure Compiles.
It has been broken for a while now for different reasons. Maintaining it for darwin is a lot of work and nobody has stepped up to do that. Also, this is a duplicate of
By the way, what is your use case for ?
We're building a desktop version of mobile application and we need for our in-app browser with Ethereum support.


Question: substituteInPlace ./src/3rdparty/chromium/v8/gypfiles/standalone.gypi  --replace /bin/echo ${coreutils}/bin/echo '' <ins> # Prevent Chromium build script from making the path to `clang` relative to # the build directory.  `clang_base_path` is the value of `QMAKE_CLANG_DIR` # from `src/core/config/mac_osx.pri`. + optionalString stdenv.isDarwin '' substituteInPlace ./src/3rdparty/chromium/build/toolchain/mac/BUILD.gn  --replace 'prefix = rebase_path("$clang_base_path/bin/", root_build_dir)' 'prefix = "$clang_base_path/bin/"' '' </ins> # Patch library paths in Qt sources + '' sed -i

Full log: Error message: That's the result I get from my macOS remote builder. When I run the build on my desktop Mac, it builds fine and uses the impure SDK from my Catalina install (10.15.1): However, the local build displays this warning repeatedly: I assume this is related to the macOS patches and hopefully gives some clue as to why it's broken.
qtbase builds fine on hydra: qtwebengine fails:
Those links point to the same thing. Anyway, strictly speaking I'm trying to build , but it's failing in .
Can you explain what do you mean? How are you using ?
It's a dependency of . edit: sorry, I see what you mean now. is a dependency of . I was confused by the message from the build saying that QT would be installed in .
Sure, depends on . Realistically, your best bet for now is to just use anki from an old version of nixpkgs. You see, doesn't have a darwin maintainer. I think, I was the last person to fix it around last January. The problem is that it's hard to keep up with all the updates. Every "minor" Qt version bump brings serious breaking changes for on darwin (like they might not even support our version of SDK anymore...). To make things worse we port all those bumps to the stable branch, so it quickly breaks there too.
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 .
Still important to me, many qt apps are broken on darwin due to this one.


Question: reaper = callPackage ../applications/audio/reaper { }; <ins> recapp = callPackage ../applications/video/recapp { }; </ins> recode = callPackage ../tools/text/recode { }; reddsaver = callPackage ../applications/misc/reddsaver {

Project description simplescreenrecorder is not that user-friendly and has problems (). right now i use OBS, but it's overkill for the task. maybe this is a good alternative Metadata homepage URL: source URL: license: GPL-3.0-or-later () platforms: linux, more?


Question: <ins> diff --git a/mat2 b/mat2 index 3b77e1e..b99a633 100755 --- a/mat2 +++ b/mat2 @@ -46,7 +46,7 @@ def __check_file(filename: str, mode: int = os.R_OK) -> bool: def create_arg_parser() -> argparse.ArgumentParser: -    parser = argparse.ArgumentParser(description='Metadata anonymisation toolkit 2') +    parser = argparse.ArgumentParser(description='Metadata anonymisation toolkit 2', prog='mat2') parser.add_argument('-V', '--verbose', action='store_true', help='show more verbose status information') </ins>

Project description Metadata proposed package name: homepage source URL: license: platforms: probably portable to all platforms which Nix supports. requires python3, exiftool, gobject introspection


Question: sha256 = "0h2rplc76r82b8smk61zci1ijj9xkjmf20pdqa8fc2lz4zicjxh4"; }; <del> nativeBuildInputs = [ cmake extra-cmake-modules python3Packages.sip ]; </del> <ins> nativeBuildInputs = [ cmake extra-cmake-modules python3Packages.sip makeWrapper ]; </ins> buildInputs = [ karchive kconfig kwidgetsaddons kcompletion kcoreaddons kguiaddons

the python binding for krita are not build correctly. Please run and paste the results.
more details wouldn't hurt...
well I don't exactly know what is happening here, to build the python binding, it requires and . So when are to the buildInputs, cmake finds all the dependencies correctly; however, at around 98% the compilation fails due to not finding some sip bindings. Alternatively, if is to the buildInputs, everything works fine as intended. But the python interpreter overwrite the python interpreter in the nix-env, so that doesn't seem to be the right fix.
also tried setting the variable, but that didn't work either.
cc who worked on / in


Question: sha256 = "sha256-uhVRO9aiYJbUmwDp1+LIYF3wNBbVduVpTtVzaS0oUMU="; }; <ins> patches = [ # Fix Exec= path in runtime-generated # ~/.config/autostart/syncthingtray.desktop file - this is required because # we are wrapping the executable. We can't use `substituteAll` because we # can't use `${placeholder "out"}` because that will produce the $out of # the patch derivation itself, and not of syncthing's "out" placeholder. # Hence we use a C definition with NIX_CFLAGS_COMPILE ./use-nix-path-in-autostart.patch ]; NIX_CFLAGS_COMPILE = "-DEXEC_NIX_PATH="${placeholder "out"}/bin/syncthingtray""; </ins> buildInputs = [ qtbase cpp-utilities

The tray icon appears, but he according window shows: Steps to reproduce the behavior: syncthingtray (through home.packages in home-manager in my case) on the tray icon The proper GUI with shiny buttons and stuff
Didn't have time to do actual digging yet, but seems like it's actually a matter of launching it / nixos weirdness rather then the package itself at fault: if I run manually from the terminal it actually works as expected. if I have it launched by plasma's autostart it sits in the tray failed with the message above. if I have it launched as user systemd service through the according home-manager option, it fails to launch because it can not find the tray altogether (probably launched before plasma is ready). So the question is, why is it different when launched from autostart... The message shows the right path in after all... (Disclaimer: total nixos noob here. Maybe it's obvious for a more experienced user...)
I'd investigate this by comparing the environment of your terminal to the environment of autostart's file - try to override the line to something like:
Oh I see what's the problem.. the file generates is pointing in to the unwrapped executable.. This needs to be patched locally in nixpkgs!
That would explain it. What do you mean by "patched locally"?
I mean this:
you are invited to test the fix for your issue in .
I'm really sorry it took me forever to actually test it - had issues with the system I use it on. Anyway, the desktop file wasn't my issue either - I didn't realize the thing in tray is not the autostarted desktop file / syncthingtray process, but the plasmoid which is apparently a completely different beast running within the plasmashell process rather then a separate one. It appears automatically in tray unless I use syncthingtray with and can not be removed from there through plasma controls. Launching the process actually creates a second icon, which behaves properly.
I'm not sure I followed.. Does it work if you set ? has landed in so the environment issue fixed there should affect you somehow I think. Feel free to reopen the issue.
No, the plasmoid is what fails. The plasmoid seems to be launched in a different way, independent from the desktop file.


Question: sha256 = "sha256-uhVRO9aiYJbUmwDp1+LIYF3wNBbVduVpTtVzaS0oUMU="; }; <ins> patches = [ # Fix Exec= path in runtime-generated # ~/.config/autostart/syncthingtray.desktop file - this is required because # we are wrapping the executable. We can't use `substituteAll` because we # can't use `${placeholder "out"}` because that will produce the $out of # the patch derivation itself, and not of syncthing's "out" placeholder. # Hence we use a C definition with NIX_CFLAGS_COMPILE ./use-nix-path-in-autostart.patch ]; NIX_CFLAGS_COMPILE = "-DEXEC_NIX_PATH="${placeholder "out"}/bin/syncthingtray""; </ins> buildInputs = [ qtbase cpp-utilities

Whenever I include syncthingtray in the home manager with (which is default), the plasmoid appears in tray on next login - but no process exists. It seems to run as part of plasmashell instead and is not in the autostart at this point. Autostart seems to be a different way to start it as an alternative to the plasmoid stuff, the plasmoid is however what is running by default with the current syncthingtray package. Doesn't seem like I have permissions to reopen it in place.
According to the initially reported issue description it is indeed the Plasmoid that's causing problems here. On Plasma the Plasmoid is supposedly the preferred UI. So the goal should be to fix it. If you nevertheless want to use the executable instead you can do that of course as well. Then you can simply disable the Plasmoid by removing it from all panels/screen as usual. If the Plasmoid is shown as part of Plasma's system tray Plasmoid, you can disable it via the settings of the system tray Plasmoid. To fix the actual issue of the Plasmoid: Supposedly a file is missing in the package. The full list of files to be contained by the package should currently look like this: Of course the exact paths depend on your install prefix and paths of your Qt and Plasma installation. Maybe something is not missing but installed to the wrong directory. Did the Plasmoid (not the stand-alone executable) ever work with your packaging? If it did then I'd try to compare the last working package with the first bad.
Note that an override for the executable path (via a CMake option that then sets a define which is used if present like in your patch) could be upstreamed.
I was thinking about it just today, since usually you'd want it to be the permanent symlink and not the path (to the wrapped executable) that might be removed after a garbage collection.. Let's continue this discussion in
What is the status on this?


Question: sha256 = "sha256-uhVRO9aiYJbUmwDp1+LIYF3wNBbVduVpTtVzaS0oUMU="; }; <ins> patches = [ # Fix Exec= path in runtime-generated # ~/.config/autostart/syncthingtray.desktop file - this is required because # we are wrapping the executable. We can't use `substituteAll` because we # can't use `${placeholder "out"}` because that will produce the $out of # the patch derivation itself, and not of syncthing's "out" placeholder. # Hence we use a C definition with NIX_CFLAGS_COMPILE ./use-nix-path-in-autostart.patch ]; NIX_CFLAGS_COMPILE = "-DEXEC_NIX_PATH="${placeholder "out"}/bin/syncthingtray""; </ins> buildInputs = [ qtbase cpp-utilities

I'm still encountering this issue on my machine
I'm not sure what more could I do here.. I will report here after comment that there are no much differences between the files installed by our package and what should be installed: <details<summary<codediff our- upstream-</code</summary</details
Is this a problem affecting all NixOS users or is it just reproducible in the setup of a few people. For debugging it might help to start with the env variable set.
I'd only compare the packaging with how other Plasmoids for NixOS are packaged. Maybe there actually needs to be a difference compared to my "upstream packaging".
I don't experience this issue, here on Gnome, naturally. Other packages in Nixpkgs, like , and also put files in , according to .
Yes, you would obviously need to start a Plasma session to reproduce the issue. (Or just launch or in another session. I suppose will work in any X11 session and in any X11 or Wayland session.) Maybe it makes more sense if the users that actually use Plasma would do further debugging on their side, though. By the way, how do you use Syncthing Tray under GNOME? Last time I've checked whether it works there was no general support for system tray icons at all and issues like suggest that GNOME has no generic system tray icon support at all right now. If there are any workarounds those might be worth documenting under and could be extended with a remark to the workaround section.
As a note, I'm a pretty new NixOS user, but I switched yesterday to the unstable channel, and syncthingtray is working completely fine now.
Using .
Thanks for the report. I wonder what was the problem... I'll close this in the meantime, unless someone from the stable channels will give a detailed bug report.


Question: , gmp , libGL , libGLU <ins> , libSM </ins> , mpfr , proj , python3

Unable to launch gplates on NixOS. A shared object file appears to be missing. Steps to reproduce the behavior: : gplates is expected to launch and be usable. N/A N/A No listed maintainers on Nix Packages but was the last to touch the source for this application. Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Probably adding to and/or adding to might help, but I'm too tired to debug tonight. I'll look into it in the next few days.
Thank you, I was reading about the first option you suggested being a potential fix. I'll see if I can wrap my head around doing it on my own as well this week, though I don't have a lot of experience contributing to projects likes this.


Question: nativeBuildInputs = [ cmake <ins> ] ++ lib.optionals withCUDA [ cudaPackages.cuda_nvcc </ins> ]; cmakeFlags = [

After setting up faster-whisper for my Home Assistant instance, I learned that my CPU (i5-6500) isn't quite as fast as I'd like for this, so I am now trying to test a GPU (NVIDIA Quadro M2000). My configuration for it is the following: I expected it to then run on my GPU using CUDA, but unless my GPU and CPU are continually equally performant, it is not working. (Also, no processes are shown in ) Steps to reproduce the behavior: NVIDIA GPU, and then configure it accordingly in , add , , , and to faster-whisper in configuration, configure it to work with device = "cuda" for STT to be faster, instead same speed I'm not totally sure what to expect because this is my first time using this, but I expected a Python3 process to appear in and for my STT to be quicker. My config is the following: The following (seemingly) NVIDIA related items are at /dev/ ! ! works, but I am not totally sure that my CUDA is configured correctly, for all I know possibly CUDA isn't configured properly, but I think I have everything correct.
I eyeballed CUDA support, but have no hardware to test or reproduce. I appreciate help in fixing the module to make it work with CUDA.
I am not overly proficient in Nix or anything like this, but I would be willing to help if you have ideas.
Well, for one we're not passing in . Can you try setting ?
Ok, I that and now when looking at the logs, I get this: It then exits.
That looks actionable. We did indeed not build ctranslate2 with CUDA support. I can try to set that up, but it won't be the default, because that would make the package unfree. We possibly need multiple ctranslate2 attributes.
Is it possible to have the package be free unless an option is passed that enables CUDA and then makes it unfree, or would two different packages be needed. There could be a package, I think that could work.
Yeah, that would also work.
If you want to try and build it with CUDA support, I can test it out and report back.
fixes the module, so it passes as expected. It also adds CUDA support to .


Question: nativeBuildInputs = [ cmake <ins> ] ++ lib.optionals withCUDA [ cudaPackages.cuda_nvcc </ins> ]; cmakeFlags = [

Check the description of the PR on how to opt into CUDA support in nixpkgs.
Hi Just to clarify, you only need in your (or in your 's ) if you're setting up a development environment to write cuda programs. If you only want to use packages with cuda support enabled, you just use them directly (e.g. ), no need to add anywhere manually. If you want to enable cuda in every package that supports it, you can set in your (nb: this triggers a massive rebuild). Instead of adding , you want to use (this way if you switch e.g. -, you'd be still using for the correct kernel), but also instead of you can take (keeps working if you switch e.g. -) Sorry we didn't get this documented yet
Wow, thank you! I assume I still need in my , right? About enabling , I've already enabled that and let it go through that whole process, so I think I'll just leave it enabled. About changing the , how is that to be done exactly? Do I just swap for in the exact same spot?
Also, is there an easy way for me to test out this updated package before it gets merged?
Depends on how you deploy your machine and what nixos version you are on.
I'm on Unstable and use Flakes.
You could replace your nixpkgs input with a fork of nixos-unstable and pick the commits from that PR on top. I'm sure there is a better solution, but I'm not well versed in flakes.
No, is the old version of , and you don't need it in Yes, except it's just , without at the end. This refers to "whatever graphics driver is in use". But also you can just remove this if you use and (both options are badly named, they're not really specific to neither of opengl or x11)
I have , but I don't have xserver enabled because this is a headless server. Do I even need nvidia_x11 if it's headless with no DE?
is where comes from; I don't recall now if it's ok to use on a headless machine, but if you like to just be explicit, you can keep P.S.


Question: nativeBuildInputs = [ cmake <ins> ] ++ lib.optionals withCUDA [ cudaPackages.cuda_nvcc </ins> ]; cmakeFlags = [

Discourse and NixOS matrix channels provide venues for Q&A discussions
With the changes made to ctranslate2, and the fixes to th , I fully expect this could work. If not, please get back to me with some error messages, e.g. the hardening of the systemd unit might cause problems.
No problem. I attempted to use just the new packages, but it became a little difficult because my old nixpkgs didn't think that ctranslate2 could have CUDA enabled, so I'll just wait for master to get pushed to NixOS-Unstable (Hopefully soon!)
The package now fails with . My system may not be correctly configured for CUDA support, or the SystemD Service is not passing through the NVIDIA device correctly. Just a reminder, the following devices are available at : (I'm not sure if is an NVIDIA thing, but it exists if that's of importance.)
Then we're at least missing . What's the content of ? nix DeviceAllow = if [ "cuda" "auto" ] then [ # "/dev/nvidia1" "/dev/nvidia2" "/dev/nvidia3" "/dev/nvidia4" "/dev/nvidia-caps/nvidia-cap1" "/dev/nvidia-caps/nvidia-cap2" "/dev/nvidiactl" "/dev/nvidia-modeset" "/dev/nvidia-uvm" "/dev/nvidia-uvm-tools" ] else "";
I modified the SystemD service to include , and it didn't help at all. The contents of are . Also, I just discovered something new. When running I get So possibly updating this system now broke NVIDIA support and it just so happened to be at the same time I tried to get Whisper working.
Did you also check which is in ? There are two things you need to maintain: 1) your driver should be newer than the cuda libraries used to build your program, 2) your should come from the same (version of) package as the kernel modules (in other words, currently you have to reboot if you update your nixos and get a newer - the new kernel module is only loaded on the next boot)
shows the following for Also, I just rebooted and is working.
from what I listed is accessible from , should my system have functional CUDA support? I tried using some testing parts from , but it seems to be out of date.


Question: nativeBuildInputs = [ cmake <ins> ] ++ lib.optionals withCUDA [ cudaPackages.cuda_nvcc </ins> ]; cmakeFlags = [

PS: Should this conversation be continued somewhere else, or is it fine to continue it here because it is somewhat pertinent to the issue?
Yes please, e.g. in or , or on You can just post the final update here once you get things to work, for discoverability purposes. Thanks!


Question: batctl = callPackage ../os-specific/linux/batman-adv/batctl.nix { }; <ins> beefi = callPackage ../os-specific/linux/beefi { }; </ins> blktrace = callPackage ../os-specific/linux/blktrace { }; bluez5 = callPackage ../os-specific/linux/bluez { };

Project description Converts Linux images and kernels into UEFI images. Metadata homepage URL: source URL: license: GPL3 platforms: Linux


Question: hash = "sha256-g5OqdnPtGGV4wBwPRAjH3lweguwlfVcgpNLlq54OHKA="; }; <del> postPatch = '' substituteInPlace pyproject.toml  --replace "attrs~=21.4" "attrs>=21.4" ''; </del> nativeBuildInputs = with python3.pkgs; [ flit-core <ins> pythonRelaxDepsHook </ins> ]; <ins> pythonRelaxDeps = true; </ins> propagatedBuildInputs = with python3.pkgs; [ attrs <del> ipython </del> jinja2 lxml pypubsub pyyaml <ins> termcolor </ins> ]; # Project has no tests

Steps to reproduce the behavior: trueseeing dependency check fails due to missing termcolor. Full logs : <summary<details<preSourcing python-remove-tests-dir-hook Sourcing python-catch-conflicts- Sourcing python-remove-bin-bytecode- Sourcing pypa-build-hook Using pypaBuildPhase Sourcing python-runtime-deps-check-hook Using pythonRuntimeDepsCheckHook Sourcing pypa-install-hook Using pypaInstallPhase Sourcing python-imports-check- Using pythonImportsCheckPhase Sourcing python-namespaces-hook Sourcing python-catch-conflicts- { "action": "setPhase", "phase": "unpackPhase" } Running phase: unpackPhase unpacking source archive /nix/store/p05bg72wb6ihkj9jjmdgzsnjifd0m0ar-source source root is source setting SOURCEDATEEPOCH to timestamp of file { "action": "setPhase", "phase": "patchPhase" } Running phase: patchPhase { "action": "setPhase", "phase": "updateAutotoolsGnuConfigScriptsPhase" } Running phase: updateAutotoolsGnuConfigScriptsPhase { "action": "setPhase", "phase": "configurePhase" } Running phase: configurePhase no configure script, doing nothing { "action": "setPhase", "phase": "buildPhase" } Running phase: buildPhase Executing pypaBuildPhase Creating a wheel... Getting build dependencies for wheel... Building wheel... Successfully built trueseeing-2.1.9-py3-none- Finished creating a wheel... Finished executing pypaBuildPhase { "action": "setPhase", "phase": "pythonRuntimeDepsCheckHook" } Running phase: pythonRuntimeDepsCheckHook Executing pythonRuntimeDepsCheck Checking runtime dependencies for trueseeing-2.1.9-py3-none- termcolor not installed </pre</details</summaryAdd 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. system: host os: multi-user?: sandbox: version: channels(root): channels(user): nixpkgs: I believe trueseeing is missing the termcolor dependency hence the failure happening during the build.


Question: hash = "sha256-g5OqdnPtGGV4wBwPRAjH3lweguwlfVcgpNLlq54OHKA="; }; <del> postPatch = '' substituteInPlace pyproject.toml  --replace "attrs~=21.4" "attrs>=21.4" ''; </del> nativeBuildInputs = with python3.pkgs; [ flit-core <ins> pythonRelaxDepsHook </ins> ]; <ins> pythonRelaxDeps = true; </ins> propagatedBuildInputs = with python3.pkgs; [ attrs <del> ipython </del> jinja2 lxml pypubsub pyyaml <ins> termcolor </ins> ]; # Project has no tests

I can try and PR a fix but I did not try and reproduce the bug under NixOS. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Seems a lot of other packages have broken in similar ways, mitmproxy, ioccheck, theharvester but they all fail due to missing runtime dependencies or version of modules that are not meeting constraints.
I had the same issue with mitmproxy and found this issue because you've mentioned it here. ~git bisect for mitmproxy pointed to this commit for me: ~ Edit: apologies, I used git bisect wrongly. The first bad commit seems to be .
This seems relevant:
That shouldn't change whether or not a package builds.
Yeah, my nightly session of bisecting for pointed to , which is from . I guess affected packages do have to be fixed one-by-one manually.


Question: hy3 = { fetchFromGitHub, cmake, hyprland }: mkHyprlandPlugin rec { pluginName = "hy3"; <del> version = "0.35.0"; </del> <ins> version = "unstable-2024-02-23"; </ins> src = fetchFromGitHub { owner = "outfoxxed"; repo = "hy3"; <del> rev = "hl${version}"; hash = "sha256-lFe7Lf0K5ePTh4gflnvBohOGH4ayGDtNkbg/XtoNqRo="; </del> <ins> rev = "029a2001361d2a4cbbe7447968dee5d1b1880298"; hash = "sha256-8LKCXwNU6wA8o6O7s9T2sLWbYNHaI1tYU4YMjHkNLZQ="; </ins> }; nativeBuildInputs = [ cmake ];

Package name: hyprland Latest released version: 0.36.0 <!-- Search your package here: --- Current version on the unstable channel: 0.35.0 Current version on the stable/release channel: 0.32.3 <!-- 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]: The 035.0 has a bug that makes my system crash very often (nullptr when monitor is disconnected) the issue is supposed to be fixed in 0.36.0.


Question: hash = "sha256-iUmnzrItTFM98w3mpadzrmtI3t0fucpSujAg/6qxCGk="; stripLen = 2; }) <ins> (fetchpatch { # https://github.com/apache/beam/pull/24573 name = "relax-httplib2-version.patch"; url = "https://github.com/apache/beam/commit/4045503575ae5ccef3de8d7b868c54e37fef658b.patch"; hash = "sha256-YqT+sHaa1R9vLQnEQN2K0lYoCdnGoPY9qduGBpXPaek="; stripLen = 2; }) </ins> ]; pythonRelaxDeps = [

Build of failed on x86_64-linux as of . This is currently breaking . python39Packages.tensorflow-datasets maintainers cc: maintainers cc: Other cc: n/a nixpkgs at commit This issue was automatically generated by . that created this issue. Internal tags: -


Question: buildGoModule rec { pname = "shadowsocks-v2ray-plugin"; <del> version = "1.3.2"; </del> <ins> version = "1.3.1"; </ins> src = fetchFromGitHub { owner = "shadowsocks"; repo = "v2ray-plugin"; rev = "v${version}"; <del> sha256 = "sha256-sGsGdJp20mXvJ6Ov1QjztbJxNpDaDEERcRAAyGgenVk="; </del> <ins> sha256 = "0aq445gnqk9dxs1hkw7rvk86wg0iyiy0h740lvyh6d9zsqhf61wb"; </ins> }; <del> vendorHash = "sha256-vW8790Z4BacbdqANWO41l5bH5ac/TSZIdVNvOFVTsZ8="; </del> <ins> vendorSha256 = "0vzd9v33p4a32f5ic9ir4g5ckis06wpdf07a649h9qalimxnvzfz"; </ins> meta = with lib; { description = "Yet another SIP003 plugin for shadowsocks, based on v2ray";

shadowsocks-v2ray-plugin doesn't work anymore in nixos-unstable. Try to use it with shadowsocks-rust. Here what I have in logs: It works. If applicable, add screenshots to help explain your problem. Add any other context about the problem here.
Version from works.
Looks like it got updated again: :)
cc
Just a note - it seems v2ray plugin is not maintained, but maybe can be used instead.


Question: <del> --- a/Build.PL +++ b/Build.PL @@ -88,7 +88,7 @@ if ( $^O =~ /mswin32/i ) { } } else { -    if ( $Config{archname} =~ /^x86_64|^ppc64|^s390x|^aarch64|^riscv64/ ) { +    if ( $Config{archname} =~ /^x86_64|^ppc64|^s390x|^riscv64/ ) { $libdir =~ s/bbinb/lib64/; if ( !-d $libdir ) { my $test = $libdir; </del>

Steps to reproduce the behavior: Confirmed locally against recent master () system: host os: multi-user?: sandbox: version: nixpkgs:
There's already a PR fixing this build failure:
looks like this is being addressed in
Can confirm, fixes build-issues on unstable :)
Fix has been merged. Feel free to reopen if the issue persists after the next channel bump


Question: <del> { lib, stdenv, fetchurl, makeWrapper, jre8, which, gawk }: </del> <ins> { lib, stdenv, fetchurl, makeWrapper, jre, which, gawk }: </ins> with lib;

Describe the bug Neo4j does not start because it cannot locate a Java Runtime. To Reproduce On my system, I installed with: Then, running shows: "The operation couldn’t be completed. Unable to locate a Java Runtime." Expected behavior Neo4j should start. Additional context Note that shows Note the line that sets to . 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:


Question: configureFlags = [ "--enable-srt" # Explicit enable srt to ensure the patch is applied. "--with-kde-solid=$out/share/apps/solid/actions" <del> ] ++ optional onlyLibVLC "--disable-vlc" ++ optional skins2Support "--enable-skins2" ++ optionals chromecastSupport [ </del> <ins> ] ++ optional onlyLibVLC "--disable-vlc" ++ optional skins2Support "--enable-skins2" ++ optional waylandSupport "--enable-wayland" ++ optionals chromecastSupport [ </ins> "--enable-sout" "--enable-chromecast" "--enable-microdns"

Packaged VLC does not seem to support wayland. Steps to reproduce the behavior: vlc with on e.g. sway opens as a XWayland window VLC opens as a Wayland native window Not applicable Possibly related to VLC not depending on qtwayland. Please run and paste the result. EDIT: Typo
It is strange. I built it and verified, it is not linked with QT libraries even if they are put as inputs.
Is also pulled in as an input?
Nope. Working on it now. First encounter: Wayland is considered experimental and disabled by default.
Can you test the patch?
Works like a charm, thanks a lot! :)
I'm on NixOS 23.05 and discovered that vlc prefers to use XWayland if var is set. If I unset then vlc starts in Wayland mode. Does anyone know how to make it to start on Wayland by default?
For now I hacked it with: Special thanks to
Well, if this is hardcoded on VLC, there is nothing to do (besides maybe searching some hidden commandline flag).
The "use QTQPAPLATFORM be damned" behavior is apparently just what QT does, and is not specific to VLC
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Here is the updated wrap that also addresses the desktop file


Question: qt5.wrapQtAppsHook ]; buildInputs = [ libjack2 bash ]; <del> propagatedBuildInputs = [ pydbus pyliblo pyqt5 ]; </del> <ins> propagatedBuildInputs = [ pyliblo pyqt5 ]; </ins> dontWrapQtApps = true; # The program is a python script.

Package name: raysession Latest released version: 0.14.2 Current version on the unstable channel: 0.13.1 Current version on the stable/release channel: 0.13.1 Notify maintainers Note for maintainers: Please tag this issue in your PR.
Update PR: