Question:
Describe the bug In , the path /usr/share/applications is hardcoded, the only way to change it would be to patch the package. However, from I see that the Debian package is used, so fixing this in the source code would require not to use a binary version (I guess). To Reproduce Steps to reproduce the behavior (tested with the package from the channel): the GUI client using the command the following error be thrown in the console: Expected behavior The autostart file is properly symlinked to the nix store package. Additional context I found a dirty fix for this issue, enable the preference and run: However, note that disabling this preference will replace the symlink with the one throwing the error. Notify maintainers Metadata Maintainer information:
I always use sway and just started it that way on launch so I didn't notice. This will probably, as you said, need a change away from the pre-built package. Right now I'm quite busy, but I'll do it soon. Will tag you in the PR so you can test (as I can't...). Did the dir exist before changing the setting?
Hey, I'm working on the client daily, and I'm doing so on NixOS, so maybe I can help with this. Building the package might be a bit involved, since our is a bit involved ,and it relies on a rust toolchain installed by , although this could be worked around with some bash magic to just drop the argument. I personally just have a somewhat involved for building the daemon and then separate FSH environments for running electron builder, but that's because I'm also trying to build for Android and do weird debuggy stuff.
Yes it did since other packages created their own entries beforehand.
Thanks for the insight, So, is this an issue that might make sense to fix in the mullvad-vpn project itself? If not, could you please send me your so I have some guidance when building it?
I must apologize for the hiatus, but life happened. I've been playing around with a somewhat cleaned up nix shell for building all the things for a proper nix package, but there's still some manual labor required. The shell that I use is somewhat similar to , but mine has far more cruft to also do android stuff. And this one could very well be slimmed down further too. The FSH environment for node is a vain attempt at making and work better, but to make things work, there's still some manual labor involved. The weird wrapping of is there because all the app's build scripts expect rust to be installed via rustup, whereas I use an overlay - so the nix script could be simplified. As long as the rust compiler is new enough, I think the app should build. To build the app, there are 6 parts that need to be built: for when the kernel module is not loaded, built via . Just executing that script on Linux should work just fine. the daemon, the CLI, problem report tool and OpenVPN plugin, should be buildable via , but the binaries end up being quite chonky, so they should all be stripped. Shell completions, the following snippet is copied verbatim from script. Download the relay list via Download the API address list via the electron GUI, built with an gulp that eventually invokes listed is basically a list of things that you must build or adjust so that they work in NixOS. Ideally, one would be able to just invoke , but due to  not building on nixOS (fails due to a node-gyp builder failing to find python) and producing an and a package, some patching would be required. It'd be great if a nix-npm wizard would apply some arcane knowledge to make build, otherwise it can just be removed from , as it's strictly a macOS dependency. Another change you'd probably want to make is to make make an unpacked build rather than producing RPMs and DEBs. The electron binary that's downloaded via will also not run. A dirty hack that I use to make it work is to just replace it with NixOS's one - , but this is not what the app developers are testing against, so there most certainly will be dragons. We build statically linked OpenVPN and Shadowsocks binaries, and those are found in  submodule. I assume these should be patchelf'ed so that they can be used on NixOS, but it seems like just using is not good enough, but doing what the current derivation does will most likely do the trick. These binaries may be substituted with NixOS native counterparts, but they wouldn't necessarily be equivalent - Mullvad's OpenVPN binaries have some patches that upstream are not interested in and we also try to build the minimal amount of features along with a minimal build of OpenSSL supporting only the ciphersuites that Mullvad servers use. I don't believe we have published the keys we use for signing commits currently, I'll see if we can make that happen. Currently, all the release commits are always signed by the same person - but this may change arbitrarily. After having written all of the above, I'm not entirely sure if making a native package would be worth the effort, given that I can't guarantee that any of the above won't change often. Maybe the best bet would be to make a minimal patch to get electron builder so that can just run. It seems to me that it's only electron/node related scripts that fail on nixOS: the GRPC buildscript fails because it expects to be able to call a downloaded binary from building fails when running probably some other electron quirk The commits are signed by individual developers, the keys are available , one should also make sure to check if the signatures are valid.

{ stdenv, fetchurl, buildPythonPackage, pythonPackages, pygtk }: buildPythonPackage { <del> name = "keepnote-0.6.5"; </del> <ins> name = "keepnote-0.7.8"; </ins> namePrefix = ""; src = fetchurl { <del> url = http://rasm.ods.org/keepnote/download/keepnote-0.6.5.tar.gz; sha256 = "0kipcy90r50z4m9p8pyy9wi4dknsiwdrgy974xgakris2rh4lafw"; </del> <ins> url = "http://keepnote.org/download/keepnote-0.7.8.tar.gz"; sha256 = "0nhkkv1n0lqf3zn17pxg5cgryv1wwlj4hfmhixwd76rcy8gs45dh"; </ins> }; propagatedBuildInputs = [ pythonPackages.sqlite3 pygtk ];


Question:
Project description On some installations this simple text editor even has syntax highlightning, but it might require non-trivial amounts of work to get that part to work. Metadata homepage URL: source URL: Gitlab, , tag = or alternatively: latest current version: 1.2.2 license: MIT (according to the ebuild in the Gentoo repository) platforms: at least linux, but might also support other platforms with X11 support
I marked this as stale due to inactivity. →
I still need this.

<ins> { lib , stdenv , fetchFromGitLab , autoreconfHook , pkg-config , utilmacros , libX11 , libXaw , libXmu , libXt }: stdenv.mkDerivation rec { pname = "xedit"; version = "1.2.2"; src = fetchFromGitLab { domain = "gitlab.freedesktop.org"; owner = "xorg/app"; repo = "xedit"; rev = "${pname}-${version}"; sha256 = "0b5ic13aasv6zh20v2k7zyxsqbnsxfq5rs3w8nwzl1gklmgrjxa3"; }; nativeBuildInputs = [ autoreconfHook pkg-config utilmacros ]; buildInputs = [ libX11 libXaw libXmu libXt ]; configureFlags = [ "--with-lispdir=$out/share/X11/xedit/lisp" "--with-appdefaultdir=$out/share/X11/app-defaults" ]; meta = with lib; { description = "Simple graphical text editor using Athena Widgets (Xaw)"; homepage = "https://gitlab.freedesktop.org/xorg/app/xedit"; license = with licenses; [ mit ]; maintainers = with maintainers; [ shamilton ]; platforms = platforms.linux; }; } </ins>


Question:
Project description On some installations this simple text editor even has syntax highlightning, but it might require non-trivial amounts of work to get that part to work. Metadata homepage URL: source URL: Gitlab, , tag = or alternatively: latest current version: 1.2.2 license: MIT (according to the ebuild in the Gentoo repository) platforms: at least linux, but might also support other platforms with X11 support
I marked this as stale due to inactivity. →
I still need this.

xed = callPackage ../development/libraries/xed { }; <ins> xedit = callPackage ../applications/editors/xedit { }; </ins> xine-lib = callPackage ../development/libraries/xine-lib { }; xautolock = callPackage ../misc/screensavers/xautolock { };


Question:
The package hard-codes various X11 libraries as dependencies while making many other features optional, including GUIs. It would be nice to have an option to disable the X11 feature and the related . The use case I have in mind is installing a custom Vim on a remote server. Pulling X libraries, even without enabling a GUI, adds a few dozen megabytes for something essentially useless. An approach is doing something like this: but it doesn't feel very clean... Any thoughts from or ?
I agree. It would have been nice if these X dependencies would have been to only if is or .
/me whispers neovim~~~
I'm all for testing new things and neovim is on my list. But according to , the neovim package pulls 428MiB of dependencies, half of which for Ruby, the other half for both Python 3 and Python 2 (seriously?). Is there a way, by any chance, to configure neovim to avoid this bloat ?
admittedly I've never tried to configure a mininmal version but one can unselect these ecosystems:
See .

patches = [ ./cflags-prune.diff ] ++ lib.optional ftNixSupport ./ft-nix-support.patch; configureFlags = [ <del> "--enable-gui=${guiSupport}" </del> "--with-features=${features}" "--disable-xsmp"              # XSMP session management "--disable-xsmp_interact"     # XSMP interaction


Question:
The package hard-codes various X11 libraries as dependencies while making many other features optional, including GUIs. It would be nice to have an option to disable the X11 feature and the related . The use case I have in mind is installing a custom Vim on a remote server. Pulling X libraries, even without enabling a GUI, adds a few dozen megabytes for something essentially useless. An approach is doing something like this: but it doesn't feel very clean... Any thoughts from or ?
I agree. It would have been nice if these X dependencies would have been to only if is or .
/me whispers neovim~~~
I'm all for testing new things and neovim is on my list. But according to , the neovim package pulls 428MiB of dependencies, half of which for Ruby, the other half for both Python 3 and Python 2 (seriously?). Is there a way, by any chance, to configure neovim to avoid this bloat ?
admittedly I've never tried to configure a mininmal version but one can unselect these ecosystems:
See .

"--disable-carbon_check" "--disable-gtktest" ] <ins> ++ lib.optional (guiSupport == "gtk2" || guiSupport == "gtk3") "--enable-gui=${guiSupport}" </ins> ++ lib.optional stdenv.isDarwin (if darwinSupport then "--enable-darwin" else "--disable-darwin") ++ lib.optionals luaSupport [


Question:
The package hard-codes various X11 libraries as dependencies while making many other features optional, including GUIs. It would be nice to have an option to disable the X11 feature and the related . The use case I have in mind is installing a custom Vim on a remote server. Pulling X libraries, even without enabling a GUI, adds a few dozen megabytes for something essentially useless. An approach is doing something like this: but it doesn't feel very clean... Any thoughts from or ?
I agree. It would have been nice if these X dependencies would have been to only if is or .
/me whispers neovim~~~
I'm all for testing new things and neovim is on my list. But according to , the neovim package pulls 428MiB of dependencies, half of which for Ruby, the other half for both Python 3 and Python 2 (seriously?). Is there a way, by any chance, to configure neovim to avoid this bloat ?
admittedly I've never tried to configure a mininmal version but one can unselect these ecosystems:
See .

++ lib.optional (guiSupport == "gtk3") wrapGAppsHook ; <del> buildInputs = [ ncurses libX11 libXext libSM libXpm libXt libXaw libXau libXmu glib libICE ] </del> <ins> buildInputs = [ ncurses glib ] # All X related dependencies ++ lib.optionals (guiSupport == "gtk2" || guiSupport == "gtk3") [ libSM libICE libX11 libXext libXpm libXt libXaw libXau libXmu ] </ins> ++ lib.optional (guiSupport == "gtk2") gtk2-x11 ++ lib.optional (guiSupport == "gtk3") gtk3-x11 ++ lib.optionals darwinSupport [ CoreServices CoreData Cocoa Foundation libobjc ]


Question: Project description a mining pool, maintains a fork of XMRig which adds the benefit of automatic algorithm switching. I have created following overlay which seems to work fine. The question is if anyone is interested in having it implemented as a separate package, replace the , or if it should be integrated as an option to a new XMRig systemd service (which would also be a nice-to-have, such as ) Notify Maintainers: Metadata homepage URL: source URL: license: gpl3 platforms: linux, darwin

<ins> { fetchFromGitHub, lib, xmrig }: xmrig.overrideAttrs (oldAttrs: rec { pname = "xmrig-mo"; version = "6.14.1-mo1"; src = fetchFromGitHub { owner = "MoneroOcean"; repo = "xmrig"; rev = "v${version}"; sha256 = "sha256-1YG0llNv1VR8ocNFxYLZFXMzowNNqpqSyIu7iCr/rfM="; }; meta = with lib; { description = "A fork of the XMRig CPU miner with support for algorithm switching"; homepage = "https://github.com/MoneroOcean/xmrig"; license = licenses.gpl3Plus; platforms = [ "x86_64-linux" "x86_64-darwin" ]; maintainers = with maintainers; [ j0hax ]; }; }) </ins>


Question: Project description a mining pool, maintains a fork of XMRig which adds the benefit of automatic algorithm switching. I have created following overlay which seems to work fine. The question is if anyone is interested in having it implemented as a separate package, replace the , or if it should be integrated as an option to a new XMRig systemd service (which would also be a nice-to-have, such as ) Notify Maintainers: Metadata homepage URL: source URL: license: gpl3 platforms: linux, darwin

xmrig = callPackage ../applications/misc/xmrig { }; <ins> xmrig-mo = callPackage ../applications/misc/xmrig/moneroocean.nix { }; </ins> xmrig-proxy = callPackage ../applications/misc/xmrig/proxy.nix { }; molot-lite = callPackage ../applications/audio/molot-lite { };


Question:
Describe the bug creates a defect as the block is defined two times. To Reproduce Steps to reproduce the behavior: Enable and Expected behavior and should be merged to one block. Additional context I'm on zfs. Notify maintainers Metadata system: host os: multi-user?: sandbox: version: channels(plumps): channels(root): nixpkgs: Maintainer information:
I have a PR up to fix this

inherit (lib) mkOption types; <del> # Once https://github.com/NixOS/nixpkgs/pull/75584 is merged we can use the TOML generator toTOML = name: value: pkgs.runCommandNoCC name { nativeBuildInputs = [ pkgs.remarshal ]; value = builtins.toJSON value; passAsFile = [ "value" ]; } '' json2toml "$valuePath" "$out" ''; </del> <ins> toml = pkgs.formats.toml { }; </ins> in { meta = {


Question:
Describe the bug creates a defect as the block is defined two times. To Reproduce Steps to reproduce the behavior: Enable and Expected behavior and should be merged to one block. Additional context I'm on zfs. Notify maintainers Metadata system: host os: multi-user?: sandbox: version: channels(plumps): channels(root): nixpkgs: Maintainer information:
I have a PR up to fix this

[ "virtualisation" "containers" "users" ] "All users with `isNormalUser = true` set now get appropriate subuid/subgid mappings." ) <ins> ( lib.mkRemovedOptionModule [ "virtualisation" "containers" "containersConf" "extraConfig" ] "Use virtualisation.containers.containersConf.settings instead." ) </ins> ]; options.virtualisation.containers = {


Question:
Describe the bug creates a defect as the block is defined two times. To Reproduce Steps to reproduce the behavior: Enable and Expected behavior and should be merged to one block. Additional context I'm on zfs. Notify maintainers Metadata system: host os: multi-user?: sandbox: version: channels(plumps): channels(root): nixpkgs: Maintainer information:
I have a PR up to fix this

description = "Enable the OCI seccomp BPF hook"; }; <del> containersConf = mkOption { default = {}; </del> <ins> containersConf.settings = mkOption { type = toml.type; default = { }; </ins> description = "containers.conf configuration"; <del> type = types.submodule { options = { extraConfig = mkOption { type = types.lines; default = ""; description = '' Extra configuration that should be put in the containers.conf configuration file ''; }; }; }; </del> }; registries = {


Question:
Describe the bug creates a defect as the block is defined two times. To Reproduce Steps to reproduce the behavior: Enable and Expected behavior and should be merged to one block. Additional context I'm on zfs. Notify maintainers Metadata system: host os: multi-user?: sandbox: version: channels(plumps): channels(root): nixpkgs: Maintainer information:
I have a PR up to fix this

}; config = lib.mkIf cfg.enable { <ins> virtualisation.containers.containersConf.settings = { network.cni_plugin_dirs = [ "${pkgs.cni-plugins}/bin/" ]; engine = { init_path = "${pkgs.catatonit}/bin/catatonit"; } // lib.optionalAttrs cfg.ociSeccompBpfHook.enable { hooks_dir = [ config.boot.kernelPackages.oci-seccomp-bpf-hook ]; }; }; </ins> <del> environment.etc."containers/containers.conf".text = '' [network] cni_plugin_dirs = ["${pkgs.cni-plugins}/bin/"] [engine] init_path = "${pkgs.catatonit}/bin/catatonit" ${lib.optionalString (cfg.ociSeccompBpfHook.enable) '' hooks_dir = [ "${config.boot.kernelPackages.oci-seccomp-bpf-hook}", ] ''} '' + cfg.containersConf.extraConfig; </del> <ins> environment.etc."containers/containers.conf".source = toml.generate "containers.conf" cfg.containersConf.settings; </ins> <del> environment.etc."containers/registries.conf".source = toTOML "registries.conf" { </del> <ins> environment.etc."containers/registries.conf".source = toml.generate "registries.conf" { </ins> registries = lib.mapAttrs (n: v: { registries = v; }) cfg.registries; };


Question:
Describe the bug creates a defect as the block is defined two times. To Reproduce Steps to reproduce the behavior: Enable and Expected behavior and should be merged to one block. Additional context I'm on zfs. Notify maintainers Metadata system: host os: multi-user?: sandbox: version: channels(plumps): channels(root): nixpkgs: Maintainer information:
I have a PR up to fix this

virtualisation.containers = { enable = true; # Enable common /etc/containers configuration <del> containersConf.extraConfig = lib.optionalString cfg.enableNvidia (builtins.readFile (toml.generate "podman.nvidia.containers.conf" { engine = { conmon_env_vars = [ "PATH=${lib.makeBinPath [ pkgs.nvidia-podman ]}" ]; runtimes.nvidia = [ "${pkgs.nvidia-podman}/bin/nvidia-container-runtime" ]; }; })); </del> <ins> containersConf.settings = lib.optionalAttrs cfg.enableNvidia { engine = { conmon_env_vars = [ "PATH=${lib.makeBinPath [ pkgs.nvidia-podman ]}" ]; runtimes.nvidia = [ "${pkgs.nvidia-podman}/bin/nvidia-container-runtime" ]; }; }; </ins> }; systemd.packages = [ cfg.package ];


Question: Describe the bug failed to build on master. To Reproduce Steps to reproduce the behavior: nixpkgs master Expected behavior It builds. Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Metadata Please run and paste the result. system: host os: multi-user?: sandbox: version: channels(root): channels(oxa): nixpkgs: Maintainer information:

python3Packages.buildPythonApplication rec { pname = "electron-cash"; <del> version = "4.2.0"; </del> <ins> version = "4.2.4"; </ins> src = fetchFromGitHub { owner = "Electron-Cash"; repo = "Electron-Cash"; rev = version; <del> sha256 = "0ixsx4224jilc5zis6wbsbxqxv10mm5sksrzq15xp30zz0bzb6md"; </del> <ins> sha256 = "sha256-hiOS0cTaPqllb31p+6nU4GYvw/E1Hdn8yd3sppzGkqg="; </ins> }; propagatedBuildInputs = with python3Packages; [ <del> dnspython </del> <ins> # requirements pyaes </ins> ecdsa <ins> requests qrcode protobuf </ins> jsonrpclib-pelix <del> matplotlib pbkdf2 pyaes pycrypto pyqt5 </del> pysocks <del> qrcode requests tlslite-ng </del> qdarkstyle <ins> python-dateutil </ins> stem <ins> certifi pathvalidate dnspython </ins> <del> # plugins keepkey </del> <ins> # requirements-binaries pyqt5 psutil pycryptodomex cryptography # requirements-hw cython </ins> trezor <ins> keepkey </ins> btchip <ins> hidapi pyscard pysatochip </ins> ]; nativeBuildInputs = [ wrapQtAppsHook ];


Question: Describe the bug failed to build on master. To Reproduce Steps to reproduce the behavior: nixpkgs master Expected behavior It builds. Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Metadata Please run and paste the result. system: host os: multi-user?: sandbox: version: channels(root): channels(oxa): nixpkgs: Maintainer information:

''; homepage = "https://www.electroncash.org/"; platforms = platforms.linux; <del> maintainers = with maintainers; [ lassulus nyanloutre ]; </del> <ins> maintainers = with maintainers; [ lassulus nyanloutre oxalica ]; </ins> license = licenses.mit; }; }


Question: Describe the bug failed to build on master. To Reproduce Steps to reproduce the behavior: nixpkgs master Expected behavior It builds. Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Metadata Please run and paste the result. system: host os: multi-user?: sandbox: version: channels(root): channels(oxa): nixpkgs: Maintainer information:

<ins> { lib, buildPythonPackage, fetchPypi, pythonOlder }: buildPythonPackage rec { pname = "pathvalidate"; version = "2.4.1"; disabled = pythonOlder "3.5"; src = fetchPypi { inherit pname version; sha256 = "sha256-PJvZTH7CPpz7IR/741audfl51sCZosdF7pSQ9STzJGg="; }; # Requires `pytest-md-report`, causing infinite recursion. doCheck = false; pythonImportsCheck = [ "pathvalidate" ]; meta = with lib; { description = "A Python library to sanitize/validate a string such as filenames/file-paths/etc"; homepage = "https://github.com/thombashi/pathvalidate"; license = licenses.mit; maintainers = with maintainers; [ oxalica ]; }; } </ins>


Question: Describe the bug failed to build on master. To Reproduce Steps to reproduce the behavior: nixpkgs master Expected behavior It builds. Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Metadata Please run and paste the result. system: host os: multi-user?: sandbox: version: channels(root): channels(oxa): nixpkgs: Maintainer information:

<ins> { lib, buildPythonPackage, fetchPypi, pyscard, ecdsa, pyaes , pythonOlder }: buildPythonPackage rec { pname = "pysatochip"; version = "0.11.4"; disabled = pythonOlder "3.6"; src = fetchPypi { inherit pname version; sha256 = "sha256-Jj/zZIS9aXmZ2xdi29Eun7iRIrIk9oBlrtN9+6opIMo="; }; propagatedBuildInputs = [ pyscard ecdsa pyaes ]; pythonImportsCheck = [ "pysatochip" ]; meta = with lib; { description = "Simple python library to communicate with a Satochip hardware wallet"; homepage = "https://github.com/Toporin/pysatochip"; license = licenses.lgpl3Only; maintainers = with maintainers; [ oxalica ]; }; } </ins>


Question: Describe the bug failed to build on master. To Reproduce Steps to reproduce the behavior: nixpkgs master Expected behavior It builds. Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Metadata Please run and paste the result. system: host os: multi-user?: sandbox: version: channels(root): channels(oxa): nixpkgs: Maintainer information:

pathtools = callPackage ../development/python-modules/pathtools { }; <ins> pathvalidate = callPackage ../development/python-modules/pathvalidate { }; </ins> patiencediff = callPackage ../development/python-modules/patiencediff { }; patool = callPackage ../development/python-modules/patool { };


Question: Describe the bug failed to build on master. To Reproduce Steps to reproduce the behavior: nixpkgs master Expected behavior It builds. Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Metadata Please run and paste the result. system: host os: multi-user?: sandbox: version: channels(root): channels(oxa): nixpkgs: Maintainer information:

inherit (pkgs) xmlsec; }; <ins> pysatochip = callPackage ../development/python-modules/pysatochip { }; </ins> pysc2 = callPackage ../development/python-modules/pysc2 { }; pyscard = callPackage ../development/python-modules/pyscard {


Question: Describe the bug Browser page fails to open if no installed on the system. To Reproduce Steps to reproduce the behavior: teleport using SAML (might need enterprise license) using tsh + SAML errors thrown, but the browser page doesn't open Expected behavior Browser page should open and ask for credentials. 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:

# This file was generated by https://github.com/kamilchm/go2nix v2.0-dev <del> { lib, buildGoPackage, zip, fetchFromGitHub }: </del> <ins> { lib, buildGoPackage, zip, fetchFromGitHub, makeWrapper, xdg-utils }: </ins> let webassets = fetchFromGitHub { owner = "gravitational"; repo = "webassets"; <del> rev = "2d79788dbcd005bdcfe5b5120007d0faf8f1fc82"; sha256 = "001a3bx8yyx1hq8y5yiy1jzp122q8gcl369lj0609gaxp6dk5bdw"; </del> <ins> rev = "8ace0cfcc6867651bed3fd5b5f35aaa2a80e1106"; sha256 = "sha256-mzvYysCFMvWHo8Y4cmhAju62jjpe92j564gc12BSdZA="; </ins> }; in buildGoPackage rec { pname = "teleport"; <del> version = "5.1.2"; </del> <ins> version = "5.2.1"; </ins> # This repo has a private submodule "e" which fetchgit cannot handle without failing. src = fetchFromGitHub { owner = "gravitational"; repo = "teleport"; rev = "v${version}"; <del> sha256 = "0h1hn2dpdsmhxac06gn6787z2mnfcwb3wn0c2l7l2qhw6iqpgmvh"; </del> <ins> sha256 = "sha256-8WEVH+04y1/s9KpBlK/LrgHG7qTpu2LqtanKKdi9N08="; </ins> }; goPackagePath = "github.com/gravitational/teleport"; subPackages = [ "tool/tctl" "tool/teleport" "tool/tsh" ]; <del> nativeBuildInputs = [ zip ]; </del> <ins> nativeBuildInputs = [ zip makeWrapper ]; </ins> postBuild = '' pushd .


Question: Describe the bug Browser page fails to open if no installed on the system. To Reproduce Steps to reproduce the behavior: teleport using SAML (might need enterprise license) using tsh + SAML errors thrown, but the browser page doesn't open Expected behavior Browser page should open and ask for credentials. 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:

postInstall = '' install -Dm755 -t $client/bin $out/bin/tsh <ins> wrapProgram $out/bin/tsh --prefix PATH : ${xdg-utils}/bin </ins> ''; doInstallCheck = true;


Question: Describe the bug A clear and concise description of what the bug is. The and python scripts in need their interpreter to be patched (and the module available). To Reproduce Steps to reproduce the behavior: Expected behavior A clear and concise description of what you expected to happen. They should work :stuckouttongue:. Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Metadata Please run and paste the result. system: host os: multi-user?: sandbox: version: channels(bt1cn): nixpkgs: Maintainer information:

{ mkDerivation , cmake , fetchFromGitLab <ins> , nix-update-script </ins> , gst_all_1 , lib , libpulseaudio


Question: Describe the bug A clear and concise description of what the bug is. The and python scripts in need their interpreter to be patched (and the module available). To Reproduce Steps to reproduce the behavior: Expected behavior A clear and concise description of what you expected to happen. They should work :stuckouttongue:. Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Metadata Please run and paste the result. system: host os: multi-user?: sandbox: version: channels(bt1cn): nixpkgs: Maintainer information:

, qttools , taglib , zlib <ins> , python3 </ins> }: <ins> let py = python3.withPackages (ps: with ps; [ pydbus ]); in </ins> mkDerivation rec { <del> pname = "sayonara-player"; version = "1.6.0-beta6"; </del> <ins> pname = "sayonara"; version = "1.6.0-beta7"; </ins> src = fetchFromGitLab { owner = "luciocarreras"; repo = "sayonara-player"; rev = version; <del> sha256 = "sha256-SbJS0DQvbW++CNXbuDHQxFlLRb1kTtDdIdHOqu0YxeQ="; </del> <ins> sha256 = "14svszfldx32vn937rszd21rgl31vb5kzs0hnrg41ygx0br61rvd"; </ins> }; nativeBuildInputs = [ cmake ninja pkg-config qttools ];


Question: Describe the bug A clear and concise description of what the bug is. The and python scripts in need their interpreter to be patched (and the module available). To Reproduce Steps to reproduce the behavior: Expected behavior A clear and concise description of what you expected to happen. They should work :stuckouttongue:. Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Metadata Please run and paste the result. system: host os: multi-user?: sandbox: version: channels(bt1cn): nixpkgs: Maintainer information:

qtbase taglib zlib <ins> py </ins> ] ++ (with gst_all_1; [ gstreamer


Question: Describe the bug A clear and concise description of what the bug is. The and python scripts in need their interpreter to be patched (and the module available). To Reproduce Steps to reproduce the behavior: Expected behavior A clear and concise description of what you expected to happen. They should work :stuckouttongue:. Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Metadata Please run and paste the result. system: host os: multi-user?: sandbox: version: channels(bt1cn): nixpkgs: Maintainer information:

qtWrapperArgs+=(--prefix GST_PLUGIN_SYSTEM_PATH_1_0 : "$GST_PLUGIN_SYSTEM_PATH_1_0") ''; <ins> passthru = { updateScript = nix-update-script { attrPath = pname; }; }; </ins> meta = with lib; { description = "Sayonara music player"; homepage = "https://sayonara-player.com/";


Question:
Describe the bug wendy, one of the big-parallel build hosts used by , cannot successfully build This blocks advancing nixos-unstable. To Reproduce Steps to reproduce the behavior: wendy to build Observe :( or, more realistically: the attached CMOV16rm-, and run (a reduced commandline that produces the same assertion failure is ) Expected behavior A clear and concise description of what you expected to happen. Additional context The assertion that's tripped by this YAML file is: 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:
is the CMOV16rm- (can't upload it here because it's not a supported GitHub filetype, apparently). To be more precise, the test that is failing is this one:
This has primarily become apparent because the configuration was changed in NixOS/nixos-org-configurations to make wendy only build big-parallel jobs. Since llvm is big-parallel, this means that wendy will now usually get selected for building llvm, since the load is otherwise pretty low. Previous successful builds of have been using one of the packet builders instead, which are using a newer CPU for which LLVM has a scheduling machine model.
FWIW, this probably affects other LLVM versions as well, but they have current versions in the cache. If wendy rebuilds the other packages (e.g. stdenv bump or something), they'll likely start failing as well.
If you spin up a VM using the CPU profile that at least virt-manager calls "OpteronG1", then you can reproduce this using the LLVM tests. That's not quite the same as the CPU reported on wendy (OpteronG1: k8-sse3; wendy: amdfam10), but it exhibits the same problem.
I don't know why, but wendy as disabled now.
it's probably late for you (I hope I didn't confuse names), but you this issue some time ago.
uh, same full name but this GitHub name is in .
Filed upstream for this.

propagatedBuildInputs = [ ncurses zlib ]; <ins> patches = [ # Force a test to evaluate the saved benchmark for a CPU for which LLVM has # an execution model. See NixOS/nixpkgs#119673. ../../exegesis-force-bdver2.patch ]; </ins> postPatch = optionalString stdenv.isDarwin '' substituteInPlace cmake/modules/AddLLVM.cmake  --replace 'set(_install_name_dir INSTALL_NAME_DIR "@rpath")' "set(_install_name_dir)"


Question:
Describe the bug wendy, one of the big-parallel build hosts used by , cannot successfully build This blocks advancing nixos-unstable. To Reproduce Steps to reproduce the behavior: wendy to build Observe :( or, more realistically: the attached CMOV16rm-, and run (a reduced commandline that produces the same assertion failure is ) Expected behavior A clear and concise description of what you expected to happen. Additional context The assertion that's tripped by this YAML file is: 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:
is the CMOV16rm- (can't upload it here because it's not a supported GitHub filetype, apparently). To be more precise, the test that is failing is this one:
This has primarily become apparent because the configuration was changed in NixOS/nixos-org-configurations to make wendy only build big-parallel jobs. Since llvm is big-parallel, this means that wendy will now usually get selected for building llvm, since the load is otherwise pretty low. Previous successful builds of have been using one of the packet builders instead, which are using a newer CPU for which LLVM has a scheduling machine model.
FWIW, this probably affects other LLVM versions as well, but they have current versions in the cache. If wendy rebuilds the other packages (e.g. stdenv bump or something), they'll likely start failing as well.
If you spin up a VM using the CPU profile that at least virt-manager calls "OpteronG1", then you can reproduce this using the LLVM tests. That's not quite the same as the CPU reported on wendy (OpteronG1: k8-sse3; wendy: amdfam10), but it exhibits the same problem.
I don't know why, but wendy as disabled now.
it's probably late for you (I hope I didn't confuse names), but you this issue some time ago.
uh, same full name but this GitHub name is in .
Filed upstream for this.

<ins> diff --git a/test/tools/llvm-exegesis/X86/uops-CMOV16rm-noreg.s b/test/tools/llvm-exegesis/X86/uops-CMOV16rm-noreg.s index 3fc1f31d54dc..a4c9bdd92131 100644 --- a/test/tools/llvm-exegesis/X86/uops-CMOV16rm-noreg.s +++ b/test/tools/llvm-exegesis/X86/uops-CMOV16rm-noreg.s @@ -1,5 +1,6 @@ # RUN: llvm-exegesis -mode=uops -opcode-name=CMOV16rm  -benchmarks-file=%t.CMOV16rm-uops.yaml # RUN: FileCheck -check-prefixes=CHECK-YAML -input-file=%t.CMOV16rm-uops.yaml %s +# RUN: sed -i 's,cpu_name:.*,cpu_name: bdver2,g' %t.CMOV16rm-uops.yaml # RUN: llvm-exegesis -mcpu=bdver2 -mode=analysis -benchmarks-file=%t.CMOV16rm-uops.yaml -analysis-clusters-output-file=- -analysis-clustering-epsilon=0.1 -analysis-inconsistency-epsilon=0.1 -analysis-numpoints=1 -analysis-clustering=naive | FileCheck -check-prefixes=CHECK-CLUSTERS %s # https://bugs.llvm.org/show_bug.cgi?id=41448 </ins>


Question: Describe the bug when using , only gets set on linux. This seems to be done very much on purpose, so I don't know if there's some good reason for it: This causes problems for instance when cross-compiling to windows and then using pkgsStatic, some packages wrongly think they are not compiling statically. I can't remember what packages I've encountered this in, and right now I'm encountering it in a change that I'm trying to make, not something that already exists. To Reproduce Steps to reproduce the behavior: Expected behavior would be true on all platforms if using Notify maintainers seems to have this code / created Metadata system: host os: multi-user?: sandbox: version: channels(root): channels(qolen): nixpkgs: Maintainer information:

# This file is autogenerated from update.sh in the same directory. <del> # VHASH: 545cfbcd1fc31d037d1e6b5382995075d2a875a51d181cc26851e49dbd2227d8 </del> <ins> # VHASH: c9500486764a2433d0f059134a981eb9adccd3546a6f779bc0e05cdcb26d2ae6 </ins> { dev = { <del> version = "22.0.1207.1"; url = "http://commondatastorage.googleapis.com/chromium-browser-official/chromium-22.0.1207.1.tar.bz2"; sha256 = "1kzzaaczz1mwsfw7fn8la6h4yls2wy537ypabqgwyim01jhfmilp"; </del> <ins> version = "22.0.1221.1"; url = "http://commondatastorage.googleapis.com/chromium-browser-official/chromium-22.0.1221.1.tar.bz2"; sha256 = "08cx2im0ng1dg83mk8jlx4in7v8f5vsf9y2ild0i22jb20c7h31s"; </ins> }; beta = { <del> version = "21.0.1180.41"; url = "http://commondatastorage.googleapis.com/chromium-browser-official/chromium-21.0.1180.41.tar.bz2"; sha256 = "1225ny7y5msyk44lb5dspd4aq0yiaawsb5xi9g8iimiv80j4h34a"; </del> <ins> version = "21.0.1180.57"; url = "http://commondatastorage.googleapis.com/chromium-browser-official/chromium-21.0.1180.57.tar.bz2"; sha256 = "0idimvkrhs09x93hl8p7rddyb0ymk9f8i5jm6m3lg6ga959aj6ri"; </ins> }; stable = { <del> version = "20.0.1132.57"; url = "http://commondatastorage.googleapis.com/chromium-browser-official/chromium-20.0.1132.57.tar.bz2"; sha256 = "06v4ybvaj3gx1v4visfyfzbq2q3xasa8xlf05f4wi2bf62vcc98j"; </del> <ins> version = "21.0.1180.57"; url = "http://commondatastorage.googleapis.com/chromium-browser-official/chromium-21.0.1180.57.tar.bz2"; sha256 = "0idimvkrhs09x93hl8p7rddyb0ymk9f8i5jm6m3lg6ga959aj6ri"; </ins> }; }


Question: Describe the bug On current nixos-unstable (), fails to build To Reproduce Steps to reproduce the behavior: -shell -p ophis Notify maintainers

sha256 = "2x8vwLTSngqQqmVrVh/mM4peATgaRqOSwrfm5XCkg/g="; }; <del> sourceRoot = "./src"; </del> <ins> sourceRoot = "${src.name}/src"; </ins> meta = with lib; { homepage = "http://michaelcmartin.github.io/Ophis/";


Question: Describe the bug The Airsonic service fails to start. To Reproduce Steps to reproduce the behavior: = true; to your config. reveals the following error: Cannot load configuration class: which causes the application to enter a restart loop. <details<summaryError trace</summary<p</p</detailsExpected behavior It doesn't error, and instead runs successfully. Additional context It doesn't seem to be due to an Airsonic update that this started to fail, so my guess is that something got changed with the JRE. I think Airsonic will only work with JDK 8 (see: ), but I'm not very familiar with how Java works, so I'm not sure. Notify maintainers Metadata Fails on both of the following systems: Maintainer information:

''; serviceConfig = { ExecStart = '' <del> ${pkgs.jre}/bin/java -Xmx${toString cfg.maxMemory}m  </del> <ins> ${pkgs.jre8}/bin/java -Xmx${toString cfg.maxMemory}m  </ins> -Dairsonic.home=${cfg.home}  -Dserver.address=${cfg.listenAddress}  -Dserver.port=${toString cfg.port}


Question: Describe the bug The Airsonic service fails to start. To Reproduce Steps to reproduce the behavior: = true; to your config. reveals the following error: Cannot load configuration class: which causes the application to enter a restart loop. <details<summaryError trace</summary<p</p</detailsExpected behavior It doesn't error, and instead runs successfully. Additional context It doesn't seem to be due to an Airsonic update that this started to fail, so my guess is that something got changed with the JRE. I think Airsonic will only work with JDK 8 (see: ), but I'm not very familiar with how Java works, so I'm not sure. Notify maintainers Metadata Fails on both of the following systems: Maintainer information:

<ins> import ./make-test-python.nix ({ pkgs, ... }: { name = "airsonic"; meta = with pkgs.lib.maintainers; { maintainers = [ sumnerevans ]; }; machine = { pkgs, ... }: { services.airsonic = { enable = true; maxMemory = 800; }; # Airsonic is a Java application, and unfortunately requires a significant # amount of memory. virtualisation.memorySize = 1024; }; testScript = '' def airsonic_is_up(_) -> bool: return machine.succeed("curl --fail http://localhost:4040/login") machine.start() machine.wait_for_unit("airsonic.service") machine.wait_for_open_port(4040) with machine.nested("Waiting for UI to work"): retry(airsonic_is_up) ''; }) </ins>


Question: Describe the bug The Airsonic service fails to start. To Reproduce Steps to reproduce the behavior: = true; to your config. reveals the following error: Cannot load configuration class: which causes the application to enter a restart loop. <details<summaryError trace</summary<p</p</detailsExpected behavior It doesn't error, and instead runs successfully. Additional context It doesn't seem to be due to an Airsonic update that this started to fail, so my guess is that something got changed with the JRE. I think Airsonic will only work with JDK 8 (see: ), but I'm not very familiar with how Java works, so I'm not sure. Notify maintainers Metadata Fails on both of the following systems: Maintainer information:

_3proxy = handleTest ./3proxy.nix {}; acme = handleTest ./acme.nix {}; agda = handleTest ./agda.nix {}; <ins> airsonic = handleTest ./airsonic.nix {}; </ins> amazon-init-shell = handleTest ./amazon-init-shell.nix {}; ammonite = handleTest ./ammonite.nix {}; atd = handleTest ./atd.nix {};


Question: Describe the bug The Airsonic service fails to start. To Reproduce Steps to reproduce the behavior: = true; to your config. reveals the following error: Cannot load configuration class: which causes the application to enter a restart loop. <details<summaryError trace</summary<p</p</detailsExpected behavior It doesn't error, and instead runs successfully. Additional context It doesn't seem to be due to an Airsonic update that this started to fail, so my guess is that something got changed with the JRE. I think Airsonic will only work with JDK 8 (see: ), but I'm not very familiar with how Java works, so I'm not sure. Notify maintainers Metadata Fails on both of the following systems: Maintainer information:

<del> { lib, stdenv, fetchurl }: </del> <ins> { lib, stdenv, fetchurl, nixosTests }: </ins> stdenv.mkDerivation rec { pname = "airsonic";


Question: Describe the bug The Airsonic service fails to start. To Reproduce Steps to reproduce the behavior: = true; to your config. reveals the following error: Cannot load configuration class: which causes the application to enter a restart loop. <details<summaryError trace</summary<p</p</detailsExpected behavior It doesn't error, and instead runs successfully. Additional context It doesn't seem to be due to an Airsonic update that this started to fail, so my guess is that something got changed with the JRE. I think Airsonic will only work with JDK 8 (see: ), but I'm not very familiar with how Java works, so I'm not sure. Notify maintainers Metadata Fails on both of the following systems: Maintainer information:

cp "$src" "$out/webapps/airsonic.war" ''; <ins> passthru.tests = { airsonic-starts = nixosTests.airsonic; }; </ins> meta = with lib; { description = "Personal media streamer"; homepage = "https://airsonic.github.io";


Question:
Describe the bug Unbound allows the "include" directive to appear more than once. : However the type definition of is too strict. This code raises an error: Notify maintainers Metadata Maintainer information:
Could you provide me with the value you set the option to?
An example has been provided above. Simply set to a list of string. The service will fail, but it should work. You can try
Ah yes indeed, sorry I didn't see that. I'll open a PR that fixes this.

freeformType = let validSettingsPrimitiveTypes = oneOf [ int str bool float ]; validSettingsTypes = oneOf [ validSettingsPrimitiveTypes (listOf validSettingsPrimitiveTypes) ]; <del> settingsType = (attrsOf validSettingsTypes); in attrsOf (oneOf [ string settingsType (listOf settingsType) ]) </del> <ins> settingsType = oneOf [ str (attrsOf validSettingsTypes) ]; in attrsOf (oneOf [ settingsType (listOf settingsType) ]) </ins> // { description = '' unbound.conf configuration type. The format consist of an attribute set of settings. Each settings can be either one value, a list of


Question: Project description Add Youtube Music Desktop player Metadata homepage URL: source URL: license: Creative Commons Zero v1.0 Universal platforms: linux, MacOS Similar application to Google Play Music Desktop:

githubId = 6652840; name = "Jade"; }; <ins> lgcl = { email = "dev@lgcl.de"; name = "Leon Vack"; github = "LogicalOverflow"; githubId = 5919957; }; </ins> lheckemann = { email = "git@sphalerite.org"; github = "lheckemann";


Question: Project description Add Youtube Music Desktop player Metadata homepage URL: source URL: license: Creative Commons Zero v1.0 Universal platforms: linux, MacOS Similar application to Google Play Music Desktop:

<ins> { lib, fetchurl, appimageTools, }: let pname = "ytmdesktop"; version = "1.13.0"; name = "${pname}-${version}"; src = fetchurl { url = "https://github.com/ytmdesktop/ytmdesktop/releases/download/v${version}/YouTube-Music-Desktop-App-${version}.AppImage"; sha256 = "0f5l7hra3m3q9zd0ngc9dj4mh1lk0rgicvh9idpd27wr808vy28v"; }; appimageContents = appimageTools.extract { inherit name src; }; in appimageTools.wrapType2 rec { inherit name src; extraInstallCommands = '' mv $out/bin/{${name},${pname}} install -m 444  -D ${appimageContents}/youtube-music-desktop-app.desktop  -t $out/share/applications substituteInPlace  $out/share/applications/youtube-music-desktop-app.desktop  --replace 'Exec=AppRun' 'Exec=${pname}' cp -r ${appimageContents}/usr/share/icons $out/share ''; meta = with lib; { description = "A Desktop App for YouTube Music"; homepage = "https://ytmdesktop.app/"; license = licenses.cc0; platforms = platforms.linux; maintainers = [ maintainers.lgcl ]; }; } </ins>


Question: Project description Add Youtube Music Desktop player Metadata homepage URL: source URL: license: Creative Commons Zero v1.0 Universal platforms: linux, MacOS Similar application to Google Play Music Desktop:

ytcc = callPackage ../tools/networking/ytcc { }; <ins> ytmdesktop = callPackage ../applications/audio/ytmdesktop { }; </ins> zam-plugins = callPackage ../applications/audio/zam-plugins { }; zanshin = libsForQt5.callPackage ../applications/office/zanshin {


Question:
On NixOS 20.09, steps to reproduce the behavior: setting up wireguard, change to another port still shows the old port:
This seems to be fixed by my PR

</listitem> <listitem> <para> <ins> The WireGuard module gained a new option <option>networking.wireguard.interfaces.<name>.peers.*.dynamicEndpointRefreshSeconds</option> that implements refreshing the IP of DNS-based endpoints periodically (which WireGuard itself <link xlink:href="https://lists.zx2c4.com/pipermail/wireguard/2017-November/002028.html">cannot do</link>). </para> </listitem> <listitem> <para> </ins> MariaDB has been updated to 10.5. Before you upgrade, it would be best to take a backup of your database and read <link xlink:href="https://mariadb.com/kb/en/upgrading-from-mariadb-104-to-mariadb-105/#incompatible-changes-between-104-and-105">


Question:
On NixOS 20.09, steps to reproduce the behavior: setting up wireguard, change to another port still shows the old port:
This seems to be fixed by my PR

example = "demo.wireguard.io:12913"; type = with types; nullOr str; description = ''Endpoint IP or hostname of the peer, followed by a colon, <del> and then a port number of the peer.''; </del> <ins> and then a port number of the peer. Warning for endpoints with changing IPs: The WireGuard kernel side cannot perform DNS resolution. Thus DNS resolution is done once by the <literal>wg</literal> userspace utility, when setting up WireGuard. Consequently, if the IP address behind the name changes, WireGuard will not notice. This is especially common for dynamic-DNS setups, but also applies to any other DNS-based setup. If you do not use IP endpoints, you likely want to set <option>networking.wireguard.dynamicEndpointRefreshSeconds</option> to refresh the IPs periodically. ''; }; dynamicEndpointRefreshSeconds = mkOption { default = 0; example = 5; type = with types; int; description = '' Periodically re-execute the <literal>wg</literal> utility every this many seconds in order to let WireGuard notice DNS / hostname changes. Setting this to <literal>0</literal> disables periodic reexecution. ''; </ins> }; persistentKeepalive = mkOption {


Question:
On NixOS 20.09, steps to reproduce the behavior: setting up wireguard, change to another port still shows the old port:
This seems to be fixed by my PR

''; }; <del> generatePeerUnit = { interfaceName, interfaceCfg, peer }: </del> <ins> peerUnitServiceName = interfaceName: publicKey: dynamicRefreshEnabled: </ins> let keyToUnitName = replaceChars [ "/" "-"    " "     "+"     "="      ] [ "-" "x2d" "x20" "x2b" "x3d" ]; <del> unitName = keyToUnitName peer.publicKey; </del> <ins> unitName = keyToUnitName publicKey; refreshSuffix = optionalString dynamicRefreshEnabled "-refresh"; in "wireguard-${interfaceName}-peer-${unitName}${refreshSuffix}"; generatePeerUnit = { interfaceName, interfaceCfg, peer }: let </ins> psk = if peer.presharedKey != null then pkgs.writeText "wg-psk" peer.presharedKey


Question:
On NixOS 20.09, steps to reproduce the behavior: setting up wireguard, change to another port still shows the old port:
This seems to be fixed by my PR

dst = interfaceCfg.interfaceNamespace; ip = nsWrap "ip" src dst; wg = nsWrap "wg" src dst; <del> in nameValuePair "wireguard-${interfaceName}-peer-${unitName}" </del> <ins> dynamicRefreshEnabled = peer.dynamicEndpointRefreshSeconds != 0; # We generate a different name (a `-refresh` suffix) when `dynamicEndpointRefreshSeconds` # to avoid that the same service switches `Type` (`oneshot` vs `simple`), # with the intent to make scripting more obvious. serviceName = peerUnitServiceName interfaceName peer.publicKey dynamicRefreshEnabled; in nameValuePair serviceName </ins> { description = "WireGuard Peer - ${interfaceName} - ${peer.publicKey}"; requires = [ "wireguard-${interfaceName}.service" ];


Question:
On NixOS 20.09, steps to reproduce the behavior: setting up wireguard, change to another port still shows the old port:
This seems to be fixed by my PR

environment.WG_ENDPOINT_RESOLUTION_RETRIES = "infinity"; path = with pkgs; [ iproute2 wireguard-tools ]; <del> serviceConfig = { Type = "oneshot"; RemainAfterExit = true; }; </del> <ins> serviceConfig = if !dynamicRefreshEnabled then { Type = "oneshot"; RemainAfterExit = true; } else { Type = "simple"; # re-executes 'wg' indefinitely # Note that `Type = "oneshot"` services with `RemainAfterExit = true` # cannot be used with systemd timers (see `man systemd.timer`), # which is why `simple` with a loop is the best choice here. # It also makes starting and stopping easiest. }; </ins> script = let <del> wg_setup = "${wg} set ${interfaceName} peer ${peer.publicKey}" + optionalString (psk != null) " preshared-key ${psk}" + optionalString (peer.endpoint != null) " endpoint ${peer.endpoint}" + optionalString (peer.persistentKeepalive != null) " persistent-keepalive ${toString peer.persistentKeepalive}" + optionalString (peer.allowedIPs != []) " allowed-ips ${concatStringsSep "," peer.allowedIPs}"; </del> <ins> wg_setup = concatStringsSep " " ( [ ''${wg} set ${interfaceName} peer "${peer.publicKey}"'' ] ++ optional (psk != null) ''preshared-key "${psk}"'' ++ optional (peer.endpoint != null) ''endpoint "${peer.endpoint}"'' ++ optional (peer.persistentKeepalive != null) ''persistent-keepalive "${toString peer.persistentKeepalive}"'' ++ optional (peer.allowedIPs != []) ''allowed-ips "${concatStringsSep "," peer.allowedIPs}"'' ); </ins> route_setup = optionalString interfaceCfg.allowedIPsAsRoutes (concatMapStringsSep "n" (allowedIP: <del> "${ip} route replace ${allowedIP} dev ${interfaceName} table ${interfaceCfg.table}" </del> <ins> ''${ip} route replace "${allowedIP}" dev "${interfaceName}" table "${interfaceCfg.table}"'' </ins> ) peer.allowedIPs); in '' ${wg_setup} ${route_setup} <ins> ${optionalString (peer.dynamicEndpointRefreshSeconds != 0) '' # Re-execute 'wg' periodically to notice DNS / hostname changes. # Note this will not time out on transient DNS failures such as DNS names # because we have set 'WG_ENDPOINT_RESOLUTION_RETRIES=infinity'. # Also note that 'wg' limits its maximum retry delay to 20 seconds as of writing. while ${wg_setup}; do sleep "${toString peer.dynamicEndpointRefreshSeconds}"; done ''} </ins> ''; postStop = let route_destroy = optionalString interfaceCfg.allowedIPsAsRoutes (concatMapStringsSep "n" (allowedIP: <del> "${ip} route delete ${allowedIP} dev ${interfaceName} table ${interfaceCfg.table}" </del> <ins> ''${ip} route delete "${allowedIP}" dev "${interfaceName}" table "${interfaceCfg.table}"'' </ins> ) peer.allowedIPs); in '' <del> ${wg} set ${interfaceName} peer ${peer.publicKey} remove </del> <ins> ${wg} set "${interfaceName}" peer "${peer.publicKey}" remove </ins> ${route_destroy} ''; };


Question:
On NixOS 20.09, steps to reproduce the behavior: setting up wireguard, change to another port still shows the old port:
This seems to be fixed by my PR

${values.preSetup} <del> ${ipPreMove} link add dev ${name} type wireguard ${optionalString (values.interfaceNamespace != null && values.interfaceNamespace != values.socketNamespace) "${ipPreMove} link set ${name} netns ${ns}"} </del> <ins> ${ipPreMove} link add dev "${name}" type wireguard ${optionalString (values.interfaceNamespace != null && values.interfaceNamespace != values.socketNamespace) ''${ipPreMove} link set "${name}" netns "${ns}"''} </ins> ${concatMapStringsSep "n" (ip: <del> "${ipPostMove} address add ${ip} dev ${name}" </del> <ins> ''${ipPostMove} address add "${ip}" dev "${name}"'' </ins> ) values.ips} <del> ${wg} set ${name} private-key ${privKey} ${ optionalString (values.listenPort != null) " listen-port ${toString values.listenPort}"} </del> <ins> ${concatStringsSep " " ( [ ''${wg} set "${name}" private-key "${privKey}"'' ] ++ optional (values.listenPort != null) ''listen-port "${toString values.listenPort}"'' )} </ins> <del> ${ipPostMove} link set up dev ${name} </del> <ins> ${ipPostMove} link set up dev "${name}" </ins> ${values.postSetup} ''; postStop = '' <del> ${ipPostMove} link del dev ${name} </del> <ins> ${ipPostMove} link del dev "${name}" </ins> ${values.postShutdown} ''; };


Question:
On NixOS 20.09, steps to reproduce the behavior: setting up wireguard, change to another port still shows the old port:
This seems to be fixed by my PR

nsList = filter (ns: ns != null) [ src dst ]; ns = last nsList; in <del> if (length nsList > 0 && ns != "init") then "ip netns exec ${ns} ${cmd}" else cmd; </del> <ins> if (length nsList > 0 && ns != "init") then ''ip netns exec "${ns}" "${cmd}"'' else cmd; </ins> in {


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

let # Release calendar: https://www.mesa3d.org/release-calendar.html # Release frequency: https://www.mesa3d.org/releasing.html#schedule <del> version = "21.0.1"; </del> <ins> version = "21.0.3"; </ins> branch  = versions.major version; self = stdenv.mkDerivation {


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

"ftp://ftp.freedesktop.org/pub/mesa/${version}/mesa-${version}.tar.xz" "ftp://ftp.freedesktop.org/pub/mesa/older-versions/${branch}.x/${version}/mesa-${version}.tar.xz" ]; <del> sha256 = "1fqj2xhhd1ary0pfg31jq6fqcnd6qgyrw1445nmz554k8n2ck7rp"; </del> <ins> sha256 = "0awiyvicvcn3b18x0vx5ik3ly0k3k51ivz2ljj8pnx6ms95nyp2n"; </ins> }; prePatch = "patchShebangs .";


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

, expat, libdrm, xorg, wayland, wayland-protocols, openssl , llvmPackages, libffi, libomxil-bellagio, libva-minimal , libelf, libvdpau <del> , libglvnd , enableRadv ? true </del> <ins> , libglvnd, libunwind </ins> , galliumDrivers ? ["auto"] , driDrivers ? ["auto"] , vulkanDrivers ? ["auto"]


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

let # Release calendar: https://www.mesa3d.org/release-calendar.html # Release frequency: https://www.mesa3d.org/releasing.html#schedule <del> version = "21.0.1"; </del> <ins> version = "21.1.4"; </ins> branch  = versions.major version; self = stdenv.mkDerivation {


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

"ftp://ftp.freedesktop.org/pub/mesa/${version}/mesa-${version}.tar.xz" "ftp://ftp.freedesktop.org/pub/mesa/older-versions/${branch}.x/${version}/mesa-${version}.tar.xz" ]; <del> sha256 = "1fqj2xhhd1ary0pfg31jq6fqcnd6qgyrw1445nmz554k8n2ck7rp"; </del> <ins> sha256 = "02z9g6zpkg1p1sm8f84xdi7v2n7x534x9pn565bvcr411527y5qz"; </ins> }; prePatch = "patchShebangs .";


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

url = "https://gitlab.freedesktop.org/mesa/mesa/commit/aebbf819df6d1e.patch"; sha256 = "17248hyzg43d73c86p077m4lv1pkncaycr3l27hwv9k4ija9zl8q"; }) <ins> # For RISC-V support: (fetchpatch { name = "add-riscv-default-selections.patch"; url = "https://gitlab.freedesktop.org/mesa/mesa/-/commit/9908da1b7a5eaf0156d458e0e24b694c070ba345.patch"; sha256 = "036gv95m5gzzs6qpgkydf5fwgdlm7kpbdfalg8vmayghd260rw1w"; }) </ins> ] ++ optionals (stdenv.isDarwin && stdenv.isAarch64) [ # Fix aarch64-darwin build, remove when upstreaam supports it out of the box. # See: https://gitlab.freedesktop.org/mesa/mesa/-/issues/1020


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

libpthreadstubs openssl /*or another sha1 provider*/ ] ++ lib.optionals (elem "wayland" eglPlatforms) [ wayland wayland-protocols ] ++ lib.optionals stdenv.isLinux [ libomxil-bellagio libva-minimal ] <ins> ++ lib.optionals stdenv.isDarwin [ libunwind ] </ins> ++ lib.optional withValgrind valgrind-light; depsBuildBuild = [ pkg-config ];


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

#include "pipe/p_compiler.h" #include "pipe/p_state.h" <del> --- ./src/amd/vulkan/winsys/amdgpu/radv_amdgpu_winsys.h +++ ./src/amd/vulkan/winsys/amdgpu/radv_amdgpu_winsys.h </del> <ins> --- a/src/amd/vulkan/winsys/amdgpu/radv_amdgpu_winsys.h +++ b/src/amd/vulkan/winsys/amdgpu/radv_amdgpu_winsys.h </ins> @@ -28,6 +28,8 @@ #ifndef RADV_AMDGPU_WINSYS_H #define RADV_AMDGPU_WINSYS_H +#include <sys/types.h> + <del> #include "radv_radeon_winsys.h" #include "ac_gpu_info.h" #include "addrlib/addrinterface.h"<Paste> </del> <ins> #include <amdgpu.h> #include <pthread.h> #include "util/list.h" </ins>


Question: Drone 2.0 has been released: <!-- Note that these are hard requirements --- name: <!-- The current version can be found easily with the same process than above for checking the master branch If an open PR is present for the package, take this version as the current one and link to the PR --current version: 1.10.0 desired version: 2.0.0 Please tag this issue in your PR.

buildGoModule rec { pname = "drone.io${lib.optionalString (!enableUnfree) "-oss"}"; <del> version = "1.10.0"; </del> <ins> version = "2.0.0"; </ins> <del> vendorSha256 = "sha256-cKHX/GnvGELQBfoo0/1UmDQ4Z66GGnnHG7+1CzjinL0="; </del> <ins> vendorSha256 = "sha256-cnbZSnHU+ORm7/dV+U9NfM18Zrzi24vf7qITPJsusU8="; </ins> doCheck = false;


Question: Drone 2.0 has been released: <!-- Note that these are hard requirements --- name: <!-- The current version can be found easily with the same process than above for checking the master branch If an open PR is present for the package, take this version as the current one and link to the PR --current version: 1.10.0 desired version: 2.0.0 Please tag this issue in your PR.

owner = "drone"; repo = "drone"; rev = "v${version}"; <del> sha256 = "sha256-12Jac+mXWdUX8gWvmpdO9ROv7Bi0YzvyqnNDVNJOr34="; </del> <ins> sha256 = "sha256-BxwCJf3uY34rqegZJ6H/zb63orELhq41trOgzGXQe80="; </ins> }; preBuild = ''


Question:
[ ] It's likely that kodi/xbmc remains vulnerable. [ ] Audacity on 15.09 is older, so the patch used on master doesn't apply and wouldn't be enough anyway.
Well, the two minor issues above remain, so I'll leave this open ATM.
Closing as 15.09 has now been superseded by 16.03 and kodi is using ffmpeg 2.8.6 since

{stdenv, fetchurl}: stdenv.mkDerivation rec { <del> name = "ncompress-4.2.4.3"; </del> <ins> name = "ncompress-4.2.4.4"; </ins> builder = ./builder.sh;


Question:
[ ] It's likely that kodi/xbmc remains vulnerable. [ ] Audacity on 15.09 is older, so the patch used on master doesn't apply and wouldn't be enough anyway.
Well, the two minor issues above remain, so I'll leave this open ATM.
Closing as 15.09 has now been superseded by 16.03 and kodi is using ffmpeg 2.8.6 since

src = fetchurl { url = "mirror://sourceforge/project/ncompress/${name}.tar.gz"; <del> sha256 = "1y44ixc1w2vfvj1lm4dkcljlwv882ynrvm5i6l0lg1gf883j246l"; </del> <ins> sha256 = "0yjiwv1hwb253x3m6r1dq2k7m5c9nz0ib2j7fnm3hark7y6s42xh"; </ins> }; meta = {


Question:
Describe the bug On NixOS and some other Linux distributions like Fedora is world-read-writable: This is not the case on other systems like Ubuntu and others from the Debian family, which instruct their users to get access to by adding user accounts to the group: When building a derivation that uses , like for example NixOS Tests or on such systems with Multi-User Nix and KVM installed, the build fails with an error message similar to this when booting the VM: To fix this users might try to add the users to the group, which has no effect because of the build sandbox. The only effective fix seems to be changing the permissions for to be world-read-writable: This fix is difficult to find for users that are not already very familiar with KVM (like me). Proposed fix Nix should detect the situation where a build is run in the sandbox and the permissions for are going to lead to a failure and emit a warning or build error that points people towards a working fix they can manually run. Potentially it would even be possible/desirable for the build to proceed without KVM/hardware acceleration, but I'm not sure because of the terrible performance impact. To Reproduce Steps to reproduce the behavior: a system that supports hardware virtualization ubuntu or another affected distro KVM (see for example ) Multi-User Nix a derivation that uses You can also manually change the permissions to to reproduce the issue. Expected behavior A more user-friendly failure mode, like what I wrote under proposed fix. Additional context There are also documented examples of other users running into this: and maybe also There is some relevant discussion here about the security impact of that permission change: Notify maintainers There are a lot of other people in git blame. I you two for now. Hope that's OK. Maintainer information:
VMs already proceed without hardware acceleration if KVM is not installed at all. I tested this with NixOS Tests on with NixOS. At least for that case the relevant code I found is this: I will submit a PR which fixes this check so that VMs also proceed without KVM in the scenario described above. I am not 100 % sure if that is the best fix and if it should close this issue, because firstly I think it would be good to make users aware when KVM is not enabled, when the hardware/software support would allow it: because it's not installed or because the permissions are broken. What would be a good way to emit such warnings? Secondly I am also a bit confused about there being flags for hardware acceleration here as well: This makes it seem like is treated inconsistently with other architectures and I don't understand why.

else throw "Unknown QEMU serial device for system '${pkgs.stdenv.hostPlatform.system}'"; qemuBinary = qemuPkg: { <del> x86_64-linux = "${qemuPkg}/bin/qemu-kvm -cpu max"; </del> <ins> x86_64-linux = "${qemuPkg}/bin/qemu-kvm -cpu qemu64"; </ins> armv7l-linux = "${qemuPkg}/bin/qemu-system-arm -enable-kvm -machine virt -cpu host"; aarch64-linux = "${qemuPkg}/bin/qemu-system-aarch64 -enable-kvm -machine virt,gic-version=host -cpu host"; powerpc64le-linux = "${qemuPkg}/bin/qemu-system-ppc64 -machine powernv";


Question:
, CVSSv3=7.8 (nixos-20.09, nixos-unstable) Scanned versions: nixos-20.09: ; nixos-unstable: . Cc Cc
09 is still vulnerable
09 is EOL

buildCommand = "sed s/dot_root/agroot/g ${raw_patch} > $out"; }; # 2.42 has the patch included <del> patches = optional (lib.versionOlder version "2.42") patchToUse; </del> <ins> patches = optional (lib.versionOlder version "2.42") patchToUse ++ optionals (lib.versionOlder version "2.46.0") [ (fetchpatch { name = "CVE-2020-18032.patch"; url = "https://gitlab.com/graphviz/graphviz/-/commit/784411ca3655c80da0f6025ab20634b2a6ff696b.patch"; sha256 = "1nkw9ism8lkfvxsp5fh95i2l5s5cbjsidbb3g1kjfv10rxkyb41m"; }) ]; </ins> in stdenv.mkDerivation {


Question:
Describe the bug Papermc crashes due to an incompatible Java version To Reproduce Steps to reproduce the behavior: Set Log Excerpt Additional context The vanilla package runs without issues. 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 system: host os: multi-user?: sandbox: version: channels(johannes): channels(root): nixpkgs: Maintainer information:
I couldn't reproduce with this test driver : <details</details
I also get this. I think papermc starts supporting java 16 with build 668 (at least it seems to start working for me after that build), but the current build in nixpkgs is 488 building the latest build (771) works for me. the test you defined doesn't wait long enough to actually start the server Which I think you need to run with since it requires networking to download the vanilla minecraft jar it will then patch. Now the test fails as expected complaining about the java version. But if you overwrite the papermc package with: the test will succeed. (btw is there a smarter way to overwrite these variables?) Metadata: system: host os: multi-user?: sandbox: version: channels(root): channels(kaine): nixpkgs:
Same thing happens with multimc and the new version

{ lib, stdenv, fetchurl, bash, jre }: let mcVersion = "1.16.5"; <del> buildNum = "488"; </del> <ins> buildNum = "771"; </ins> jar = fetchurl { <del> url = "https://papermc.io/api/v1/paper/${mcVersion}/${buildNum}/download"; sha256 = "07zgq6pfgwd9a9daqv1dab0q8cwgidsn6sszn7bpr37y457a4ka8"; </del> <ins> url = "https://papermc.io/api/v1/paper/${mcVersion}/${buildNum}/download"; sha256 = "1lmlfhigbzbkgzfq6knglka0ccf4i32ch25gkny0c5fllmsnm08l"; </ins> }; in stdenv.mkDerivation { pname = "papermc";


Question: Project description A system for automatically configuring mutt and isync with a simple interface and safe passwords Metadata homepage URL: source URL: license: gpl3 platforms: unix, linux, darwin

<ins> { lib , stdenvNoCC , fetchFromGitHub }: stdenvNoCC.mkDerivation rec { pname = "mutt-wizard"; version = "3.2.1"; src = fetchFromGitHub { owner = "LukeSmithxyz"; repo = "mutt-wizard"; rev = "v${version}"; sha256 = "1m4s0vj57hh38rdgdc28p10vnsq80dh708imvdgxbj1i96nq41r8"; }; makeFlags = [ "PREFIX=$(out)" ]; meta = with lib; { description = "System for automatically configuring mutt and isync"; homepage = "https://github.com/LukeSmithxyz/mutt-wizard"; license = licenses.gpl3Plus; maintainers = with maintainers; [ shamilton ]; platforms = platforms.unix; }; } </ins>


Question: Project description A system for automatically configuring mutt and isync with a simple interface and safe passwords Metadata homepage URL: source URL: license: gpl3 platforms: unix, linux, darwin

mutt-with-sidebar = mutt.override { withSidebar = true; }; <ins> mutt-wizard = callPackage ../tools/misc/mutt-wizard { }; </ins> mwic = callPackage ../applications/misc/mwic { pythonPackages = python3Packages;


Question:
Project description The terminal is already packaged in nixpkgs. As foot uses its own terminfo, this terminfo is needed on any remote servers you connect to using foot. It would be useful to have this terminfo packaged as its own output as with other terminals: alacritty, kitty, rxvt-unicode to name a few. ping foot maintainer for feedback Metadata homepage URL: source URL: license: mit platforms: linux
That is a very good idea! Unfortunately it doesn't seem to be possible to specify a separate install directory for foot's terminfo so far (it is installed to along with the license etc.). I'll open an upstream ticket, they are usually very helpful, and then we'll be hopefully be able to set this pretty soon.

, tllist , wayland-protocols , pkg-config <ins> , utf8proc </ins> , allowPgo ? true , python3  # for PGO # for clang stdenv check


Question:
Project description The terminal is already packaged in nixpkgs. As foot uses its own terminfo, this terminfo is needed on any remote servers you connect to using foot. It would be useful to have this terminfo packaged as its own output as with other terminals: alacritty, kitty, rxvt-unicode to name a few. ping foot maintainer for feedback Metadata homepage URL: source URL: license: mit platforms: linux
That is a very good idea! Unfortunately it doesn't seem to be possible to specify a separate install directory for foot's terminfo so far (it is installed to along with the license etc.). I'll open an upstream ticket, they are usually very helpful, and then we'll be hopefully be able to set this pretty soon.

}: let <del> version = "1.7.2"; </del> <ins> version = "1.8.0"; </ins> # build stimuli file for PGO build and the script to generate it # independently of the foot's build, so we can cache the result


Question:
Project description The terminal is already packaged in nixpkgs. As foot uses its own terminfo, this terminfo is needed on any remote servers you connect to using foot. It would be useful to have this terminfo packaged as its own output as with other terminals: alacritty, kitty, rxvt-unicode to name a few. ping foot maintainer for feedback Metadata homepage URL: source URL: license: mit platforms: linux
That is a very good idea! Unfortunately it doesn't seem to be possible to specify a separate install directory for foot's terminfo so far (it is installed to along with the license etc.). I'll open an upstream ticket, they are usually very helpful, and then we'll be hopefully be able to set this pretty soon.

src = fetchurl { url = "https://codeberg.org/dnkl/foot/raw/tag/${version}/scripts/generate-alt-random-writes.py"; <del> sha256 = "019bdiqfi3wx2lwrv3nhq83knc1r3lmqd5zgisa33wwshm2kyv7p"; </del> <ins> sha256 = "0w4d0rxi54p8lvbynypcywqqwbbzmyyzc0svjab27ngmdj1034ii"; </ins> }; dontUnpack = true;


Question:
Project description The terminal is already packaged in nixpkgs. As foot uses its own terminfo, this terminfo is needed on any remote servers you connect to using foot. It would be useful to have this terminfo packaged as its own output as with other terminals: alacritty, kitty, rxvt-unicode to name a few. ping foot maintainer for feedback Metadata homepage URL: source URL: license: mit platforms: linux
That is a very good idea! Unfortunately it doesn't seem to be possible to specify a separate install directory for foot's terminfo so far (it is installed to along with the license etc.). I'll open an upstream ticket, they are usually very helpful, and then we'll be hopefully be able to set this pretty soon.

src = fetchzip { url = "https://codeberg.org/dnkl/${pname}/archive/${version}.tar.gz"; <del> sha256 = "0iabj9c0dj1r0m89i5gk2jdmwj4wfsai8na54x2w4fq406q6g9nh"; </del> <ins> sha256 = "07irlhkvziv51cp5zn1yz8ljfnrnfjcykv5pgfwmpslw3nl5szxv"; </ins> }; nativeBuildInputs = [


Question:
Project description The terminal is already packaged in nixpkgs. As foot uses its own terminfo, this terminfo is needed on any remote servers you connect to using foot. It would be useful to have this terminfo packaged as its own output as with other terminals: alacritty, kitty, rxvt-unicode to name a few. ping foot maintainer for feedback Metadata homepage URL: source URL: license: mit platforms: linux
That is a very good idea! Unfortunately it doesn't seem to be possible to specify a separate install directory for foot's terminfo so far (it is installed to along with the license etc.). I'll open an upstream ticket, they are usually very helpful, and then we'll be hopefully be able to set this pretty soon.

wayland libxkbcommon fcft <ins> utf8proc </ins> ]; # recommended build flags for performance optimized foot builds


Question:
Project description The terminal is already packaged in nixpkgs. As foot uses its own terminfo, this terminfo is needed on any remote servers you connect to using foot. It would be useful to have this terminfo packaged as its own output as with other terminals: alacritty, kitty, rxvt-unicode to name a few. ping foot maintainer for feedback Metadata homepage URL: source URL: license: mit platforms: linux
That is a very good idea! Unfortunately it doesn't seem to be possible to specify a separate install directory for foot's terminfo so far (it is installed to along with the license etc.). I'll open an upstream ticket, they are usually very helpful, and then we'll be hopefully be able to set this pretty soon.

export AR="${ar}" ''; <del> mesonFlags = [ "--buildtype=release" "-Db_lto=true" ]; </del> <ins> mesonFlags = [ "--buildtype=release" "-Db_lto=true" "-Dterminfo-install-location=${placeholder "terminfo"}/share/terminfo" ]; </ins> # build and run binary generating PGO profiles, # then reconfigure to build the normal foot binary utilizing PGO


Question:
Project description The terminal is already packaged in nixpkgs. As foot uses its own terminfo, this terminfo is needed on any remote servers you connect to using foot. It would be useful to have this terminfo packaged as its own output as with other terminals: alacritty, kitty, rxvt-unicode to name a few. ping foot maintainer for feedback Metadata homepage URL: source URL: license: mit platforms: linux
That is a very good idea! Unfortunately it doesn't seem to be possible to specify a separate install directory for foot's terminfo so far (it is installed to along with the license etc.). I'll open an upstream ticket, they are usually very helpful, and then we'll be hopefully be able to set this pretty soon.

llvm-profdata merge default_*profraw --output=default.profdata ''; <ins> outputs = [ "out" "terminfo" ]; # make sure nix-env and buildEnv also include the # terminfo output when the package is installed postInstall = '' mkdir -p "$out/nix-support" echo "$terminfo" >> "$out/nix-support/propagated-user-env-packages" ''; </ins> passthru.tests = { clang-default-compilation = foot.override { inherit (llvmPackages) stdenv;


Question: Describe the bug Building or fails with: To Reproduce Steps to reproduce the behavior: until approximately 70% (sometimes a few percent earlier) Additional context Compilation log for with only : Compilation log for with only : I had this problem with Sierra with XCode 9.2 also. I just upgraded to Mojave 10.14.6 and XCode 11.13.1. 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 system: host os: multi-user?: sandbox: version: channels(peterhil): channels(root): nixpkgs: Maintainer information:

<ins> diff --git a/lib/sanitizer_common/sanitizer_mac.cpp b/lib/sanitizer_common/sanitizer_mac.cpp --- a/lib/sanitizer_common/sanitizer_mac.cpp +++ b/lib/sanitizer_common/sanitizer_mac.cpp @@ -613,9 +613,15 @@ HandleSignalMode GetHandleSignalMode(int signum) { // Offset example: // XNU 17 -- macOS 10.13 -- iOS 11 -- tvOS 11 -- watchOS 4 constexpr u16 GetOSMajorKernelOffset() { -  if (TARGET_OS_OSX) return 4; -  if (TARGET_OS_IOS || TARGET_OS_TV) return 6; -  if (TARGET_OS_WATCH) return 13; +#if TARGET_OS_OSX +  return 4; +#endif +#if TARGET_OS_IOS || TARGET_OS_TV +  return 6; +#endif +#if TARGET_OS_WATCH +  return 13; +#endif } using VersStr = char[64]; @@ -627,13 +633,13 @@ static uptr ApproximateOSVersionViaKernelVersion(VersStr vers) { u16 os_major = kernel_major - offset; const char *format = "%d.0"; -  if (TARGET_OS_OSX) { -    if (os_major >= 16) {  // macOS 11+ -      os_major -= 5; -    } else {  // macOS 10.15 and below -      format = "10.%d"; -    } +#if TARGET_OS_OSX +  if (os_major >= 16) {  // macOS 11+ +    os_major -= 5; +  } else {  // macOS 10.15 and below +    format = "10.%d"; } +#endif return internal_snprintf(vers, sizeof(VersStr), format, os_major); } @@ -681,15 +687,14 @@ void ParseVersion(const char *vers, u16 *major, u16 *minor) { // Aligned versions example: // macOS 10.15 -- iOS 13 -- tvOS 13 -- watchOS 6 static void MapToMacos(u16 *major, u16 *minor) { -  if (TARGET_OS_OSX) -    return; - -  if (TARGET_OS_IOS || TARGET_OS_TV) +#if !TARGET_OS_OSX +#if TARGET_OS_IOS || TARGET_OS_TV *major += 2; -  else if (TARGET_OS_WATCH) +#elif TARGET_OS_WATCH *major += 9; -  else +#else UNREACHABLE("unsupported platform"); +#endif if (*major >= 16) {  // macOS 11+ *major -= 5; @@ -697,6 +702,7 @@ static void MapToMacos(u16 *major, u16 *minor) { *minor = *major; *major = 10; } +#endif } static MacosVersion GetMacosAlignedVersionInternal() { </ins>


Question: Describe the bug Building or fails with: To Reproduce Steps to reproduce the behavior: until approximately 70% (sometimes a few percent earlier) Additional context Compilation log for with only : Compilation log for with only : I had this problem with Sierra with XCode 9.2 also. I just upgraded to Mojave 10.14.6 and XCode 11.13.1. 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 system: host os: multi-user?: sandbox: version: channels(peterhil): channels(root): nixpkgs: Maintainer information:

# extra `/`. ./normalize-var.patch ]# ++ lib.optional stdenv.hostPlatform.isMusl ./sanitizers-nongnu.patch <ins> # Prevent a compilation error on darwin ++ lib.optional stdenv.hostPlatform.isDarwin ./darwin-targetconditionals.patch </ins> ++ lib.optional stdenv.hostPlatform.isAarch32 ./armv7l.patch; # TSAN requires XPC on Darwin, which we have no public/free source files for. We can depend on the Apple frameworks


Question: <!-- Note that these are hard requirements --<!-- You can use the "Go to file" functionality on github to find the package Then you can go to the history for this package Find the latest "packagename: oldversion -newversion" commit The "newversion" is the the current version of the package --- <!-- Type the name of your package and try to find an open pull request for the package If you find an open pull request, you can review it! There's a high chance that you'll have the new version right away while helping the community! --- name: nixos.poppler <!-- The current version can be found easily with the same process than above for checking the master branch If an open PR is present for the package, take this version as the current one and link to the PR --current version: 21.05.0 desired version: 21.06.01 <!-- Search your package here: If no maintainer is listed for your package, tag the person that last updated the package --maintainers: Please tag this issue in your PR. The current version of is causing evince to crash frequently:

<del> { stdenv, lib, fetchurl, cmake, ninja, pkg-config, libiconv, libintl , zlib, curl, cairo, freetype, fontconfig, lcms, libjpeg, openjpeg, fetchpatch </del> <ins> { stdenv , lib , fetchurl , fetchpatch , cairo , cmake , curl , fontconfig , freetype , lcms , libiconv , libintl , libjpeg , ninja , openjpeg , pkg-config , zlib </ins> , withData ? true, poppler_data , qt5Support ? false, qtbase ? null , introspectionSupport ? false, gobject-introspection ? null


Question: <!-- Note that these are hard requirements --<!-- You can use the "Go to file" functionality on github to find the package Then you can go to the history for this package Find the latest "packagename: oldversion -newversion" commit The "newversion" is the the current version of the package --- <!-- Type the name of your package and try to find an open pull request for the package If you find an open pull request, you can review it! There's a high chance that you'll have the new version right away while helping the community! --- name: nixos.poppler <!-- The current version can be found easily with the same process than above for checking the master branch If an open PR is present for the package, take this version as the current one and link to the PR --current version: 21.05.0 desired version: 21.06.01 <!-- Search your package here: If no maintainer is listed for your package, tag the person that last updated the package --maintainers: Please tag this issue in your PR. The current version of is causing evince to crash frequently:

mkFlag = optset: flag: "-DENABLE_${flag}=${if optset then "on" else "off"}"; in stdenv.mkDerivation rec { <del> name = "poppler-${suffix}-${version}"; </del> <ins> pname = "poppler-${suffix}"; inherit version; </ins> src = fetchurl { <del> url = "${meta.homepage}/poppler-${version}.tar.xz"; </del> <ins> url = "https://poppler.freedesktop.org/poppler-${version}.tar.xz"; </ins> sha256 = "1afdrxxkaivvviazxkg5blsf2x24sjkfj92ib0d3q5pm8dihjrhj"; }; outputs = [ "out" "dev" ]; patches = [ <ins> # Fix internal crash: a negative number that should not be </ins> (fetchpatch { name = "CVE-2018-13988"; url = "https://cgit.freedesktop.org/poppler/poppler/patch/?id=004e3c10df0abda214f0c293f9e269fdd979c5ee"; sha256 = "1l8713s57xc6g81bldw934rsfm140fqc7ggd50ha5mxdl1b3app2"; }) <ins> # Fix internal crash: a negative number that should not be (not the above!) </ins> ./0.61-CVE-2019-9959.patch ]; <del> buildInputs = [ libiconv libintl ] ++ lib.optional withData poppler_data; </del> <ins> nativeBuildInputs = [ cmake ninja pkg-config ]; buildInputs = [ libiconv libintl ] ++ lib.optional withData poppler_data; </ins> # TODO: reduce propagation to necessary libs propagatedBuildInputs = with lib;


Question: <!-- Note that these are hard requirements --<!-- You can use the "Go to file" functionality on github to find the package Then you can go to the history for this package Find the latest "packagename: oldversion -newversion" commit The "newversion" is the the current version of the package --- <!-- Type the name of your package and try to find an open pull request for the package If you find an open pull request, you can review it! There's a high chance that you'll have the new version right away while helping the community! --- name: nixos.poppler <!-- The current version can be found easily with the same process than above for checking the master branch If an open PR is present for the package, take this version as the current one and link to the PR --current version: 21.05.0 desired version: 21.06.01 <!-- Search your package here: If no maintainer is listed for your package, tag the person that last updated the package --maintainers: Please tag this issue in your PR. The current version of is causing evince to crash frequently:

++ optional qt5Support qtbase ++ optional introspectionSupport gobject-introspection; <del> nativeBuildInputs = [ cmake ninja pkg-config ]; </del> # Not sure when and how to pass it.  It seems an upstream bug anyway. CXXFLAGS = lib.optionalString stdenv.cc.isClang "-std=c++11";