Question:
Describe the bug I've tried building two packages from source on my new MacBook Air running macOS 10.15/Catalina ( and a custom expression for ), and both times I get the same set of errors involving Xcode/iOS simulator/permissions/etc. It never seems to start to the build. Example: I don't know for sure whether it has to do with Catalina, but I never received these errors when using 10.14/Mojave. To Reproduce Steps to reproduce the behavior: Nix on a Mac running Catalina. I used the instructions . to install a package that has a source-based build for Darwin such as . Expected behavior The package should install or at least give me errors related to the build rather than Xcode/iOS simulator/permissions/etc. errors. Metadata Maintainer information:
iterm2 is currently broken on Catalina. I remember to have it fixed locally months ago but didn't find the time to open a pull request.
I was just using iterm2 as an example. The errors I'm receiving are generic and occur for any source build using Xcode on my new computer running Catalina. Separately, I also remember iterm2 being broken while I was using Mojave. These are different errors.
Could you test my pull request that should fix this issue (at least for iterm2)?
just tested and it works, thanks! But what are and ? I can't find those documented anywhere.

{ stdenv, fetchFromGitHub }: <ins> /* This derivation is impure: it relies on an Xcode toolchain being installed and available in the expected place. The values of sandboxProfile are copied pretty directly from the MacVim derivation, which is also impure. In order to build you at least need the `sandbox` option set to `relaxed` or `false`. */ </ins> stdenv.mkDerivation rec { pname = "iterm2"; <del> version = "3.0.14"; </del> <ins> version = "3.3.9"; </ins> src = fetchFromGitHub { owner = "gnachman"; repo = "iTerm2"; rev = "v${version}"; <del> sha256 = "03m0ja11w9910z96yi8fzq3436y8xl14q031rdb2w3sapjd54qrj"; </del> <ins> sha256 = "06mq3gfjgy8jw2f3fzdsi3pbfkdijfzzlhlw6ixa5bfb4hbcgn5j"; </ins> }; patches = [ ./disable_updates.patch ]; postPatch = '' sed -i -e 's/CODE_SIGN_IDENTITY = "Developer ID Application"/CODE_SIGN_IDENTITY = ""/g' ./iTerm2.xcodeproj/project.pbxproj ''; preConfigure = "LD=$CC"; <del> makeFlagsArray = ["Deployment"]; </del> <ins> makeFlagsArray = ["Nix"]; </ins> installPhase = '' <del> mkdir -p "$out/Applications" mv "build/Deployment/iTerm2.app" "$out/Applications/iTerm.app" </del> <ins> mkdir -p $out/Applications mv Build/Products/Deployment/iTerm2.app $out/Applications/iTerm.app ''; sandboxProfile = '' (allow file-read* file-write* process-exec mach-lookup) ; block homebrew dependencies (deny file-read* file-write* process-exec mach-lookup (subpath "/usr/local") (with no-log)) </ins> ''; <del> meta = { </del> <ins> meta = with stdenv.lib; { </ins> description = "A replacement for Terminal and the successor to iTerm"; homepage = https://www.iterm2.com/; <del> license = stdenv.lib.licenses.gpl2; platforms = stdenv.lib.platforms.darwin; </del> <ins> license = licenses.gpl2; maintainers = with maintainers; [ tricktron ]; platforms = platforms.darwin; hydraPlatforms = []; </ins> }; }


Question:
Update certbot Current packaged version is 0.39.0, upstream version is 1.2.0.
Fix in

1 file changed, 1 insertion(+), 14 deletions(-) diff --git a/certbot/setup.py b/certbot/setup.py <del> index c1bf914..7456bf2 100644 </del> <ins> index d19327e5e..ac1524793 100644 </ins> --- a/certbot/setup.py +++ b/certbot/setup.py <del> @@ -3,7 +3,6 @@ import os </del> <ins> @@ -1,5 +1,4 @@ import codecs -from distutils.version import StrictVersion import os </ins> import re import sys <del> -from distutils.version import StrictVersion from setuptools import find_packages, setup, __version__ as setuptools_version from setuptools.command.test import test as TestCommand @@ -56,20 +55,8 @@ install_requires = [ </del> <ins> @@ -58,20 +57,8 @@ install_requires = [ </ins> # Add pywin32 on Windows platforms to handle low-level system calls. # This dependency needs to be added using environment markers to avoid its installation on Linux.


Question:
Update certbot Current packaged version is 0.39.0, upstream version is 1.2.0.
Fix in

+install_requires.append(pywin32_req + " ; sys_platform == 'win32'") dev_extras = [ <del> 'astroid==1.6.5', </del> <ins> 'coverage', </ins> -- 2.24.1


Question:
Update certbot Current packaged version is 0.39.0, upstream version is 1.2.0.
Fix in

<del> { stdenv, python37Packages, fetchFromGitHub, fetchurl, dialog, autoPatchelfHook }: </del> <ins> { lib , buildPythonApplication , fetchFromGitHub , ConfigArgParse, acme, configobj, cryptography, distro, josepy, parsedatetime, pyRFC3339, pyopenssl, pytz, requests, six, zope_component, zope_interface , dialog, mock, gnureadline , pytest_xdist, pytest, dateutil }: </ins> <del> python37Packages.buildPythonApplication rec { </del> <ins> buildPythonApplication rec { </ins> pname = "certbot"; <del> version = "1.0.0"; </del> <ins> version = "1.3.0"; </ins> src = fetchFromGitHub { owner = pname; repo = pname; rev = "v${version}"; <del> sha256 = "180x7gcpfbrzw8k654s7b5nxdy2yg61lq513dykyn3wz4gssw465"; </del> <ins> sha256 = "1nzp1l63f64qqp89y1vyd4lgfhykfp5dkr6iwfiyf273y7sjwpsa"; </ins> }; patches = [ ./0001-Don-t-use-distutils.StrictVersion-that-cannot-handle.patch ]; <del> propagatedBuildInputs = with python37Packages; [ </del> <ins> propagatedBuildInputs = [ </ins> ConfigArgParse acme configobj


Question:
Update certbot Current packaged version is 0.39.0, upstream version is 1.2.0.
Fix in

distro josepy parsedatetime <del> psutil </del> pyRFC3339 pyopenssl pytz <ins> requests </ins> six zope_component zope_interface ]; <del> buildInputs = [ dialog ] ++ (with python37Packages; [ mock gnureadline ]); </del> <ins> buildInputs = [ dialog mock gnureadline ]; </ins> <del> checkInputs = with python37Packages; [ pytest_xdist pytest dateutil ]; </del> <ins> checkInputs = [ pytest_xdist pytest dateutil ]; </ins> <del> postPatch = '' </del> <ins> preBuild = '' </ins> cd certbot <del> substituteInPlace certbot/_internal/notify.py --replace "/usr/sbin/sendmail" "/run/wrappers/bin/sendmail" </del> ''; postInstall = ''


Question:
Update certbot Current packaged version is 0.39.0, upstream version is 1.2.0.
Fix in

doCheck = true; <del> meta = with stdenv.lib; { </del> <ins> meta = with lib; { </ins> homepage = src.meta.homepage; description = "ACME client that can obtain certs and extensibly update server configurations"; platforms = platforms.unix; <del> maintainers = [ maintainers.domenkozar ]; license = licenses.asl20; </del> <ins> maintainers = with maintainers; [ domenkozar ]; license = with licenses; [ asl20 ]; </ins> }; }


Question:
Update certbot Current packaged version is 0.39.0, upstream version is 1.2.0.
Fix in

ogre = ogre1_10; }; <del> certbot = callPackage ../tools/admin/certbot { }; </del> <ins> certbot = python3Packages.callPackage ../tools/admin/certbot { }; </ins> caf = callPackage ../development/libraries/caf {};


Question:
I'm thinking of bringing this line back: and getting rid of nixos/modules/misc/extra- Does anyone have objections? I fully buy the ability to pass arguments in the module system using , but if it doesn't work (and breaks in a horrible way) for the most common use case ( in imports), that seems bad and the cost of restoring the old way seems pretty low. Anyone have objections? I can make the change if nobody objects. Ideally, I'd like it in 15.06, since it's getting in the way of some work I'm trying to squeeze into 15.06. cc
IMO our only choices are to do this or to set as a prerequisite (perhaps enforced using ) that points there. No strong preference either way.
Yeah, this is probably the best solution.
Cool! Do any of you know of VM tests that would suitably make sure I don't break anything too obvious by making that change? I'd obviously rather not make the change and then discover a week from now that I broke someone's key use case :smile: I'll be making the change this evening at this rate.
Any thoughts on having set using scopedImport? That way stays NixOS-independent. But not a huge difference IMO.
I don't see how adding back could break anything.
Famous last words! :grinning: But I agree, as long as it evaluates at all it's almost certainly fine.
That sounds more complicated than the one-liner suggested by

evalModules) and the less declarative the module set is. */ evalModules = { modules , prefix ? [] <ins> , # This should only be used for special arguments that need to be evaluated # when resolving module structure (like in imports). For everything else, # there's _module.args. specialArgs ? {} </ins> , # This would be remove in the future, Prefer _module.args option instead. args ? {} , # This would be remove in the future, Prefer _module.check option instead.


Question:
I'm thinking of bringing this line back: and getting rid of nixos/modules/misc/extra- Does anyone have objections? I fully buy the ability to pass arguments in the module system using , but if it doesn't work (and breaks in a horrible way) for the most common use case ( in imports), that seems bad and the cost of restoring the old way seems pretty low. Anyone have objections? I can make the change if nobody objects. Ideally, I'd like it in 15.06, since it's getting in the way of some work I'm trying to squeeze into 15.06. cc
IMO our only choices are to do this or to set as a prerequisite (perhaps enforced using ) that points there. No strong preference either way.
Yeah, this is probably the best solution.
Cool! Do any of you know of VM tests that would suitably make sure I don't break anything too obvious by making that change? I'd obviously rather not make the change and then discover a week from now that I broke someone's key use case :smile: I'll be making the change this evening at this rate.
Any thoughts on having set using scopedImport? That way stays NixOS-independent. But not a huge difference IMO.
I don't see how adding back could break anything.
Famous last words! :grinning: But I agree, as long as it evaluates at all it's almost certainly fine.
That sounds more complicated than the one-liner suggested by

}; }; <del> closed = closeModules (modules ++ [ internalModule ]) { inherit config options; lib = import ./.; }; </del> <ins> closed = closeModules (modules ++ [ internalModule ]) (specialArgs // { inherit config options; lib = import ./.; }); </ins> # Note: the list of modules is reversed to maintain backward # compatibility with the old module system.  Not sure if this is


Question:
I'm thinking of bringing this line back: and getting rid of nixos/modules/misc/extra- Does anyone have objections? I fully buy the ability to pass arguments in the module system using , but if it doesn't work (and breaks in a horrible way) for the most common use case ( in imports), that seems bad and the cost of restoring the old way seems pretty low. Anyone have objections? I can make the change if nobody objects. Ideally, I'd like it in 15.06, since it's getting in the way of some work I'm trying to squeeze into 15.06. cc
IMO our only choices are to do this or to set as a prerequisite (perhaps enforced using ) that points there. No strong preference either way.
Yeah, this is probably the best solution.
Cool! Do any of you know of VM tests that would suitably make sure I don't break anything too obvious by making that change? I'd obviously rather not make the change and then discover a week from now that I broke someone's key use case :smile: I'll be making the change this evening at this rate.
Any thoughts on having set using scopedImport? That way stays NixOS-independent. But not a huge difference IMO.
I don't see how adding back could break anything.
Famous last words! :grinning: But I agree, as long as it evaluates at all it's almost certainly fine.
That sounds more complicated than the one-liner suggested by

config = removeAttrs m ["key" "_file" "require" "imports"]; }; <del> applyIfFunction = f: arg@{ config, options, lib }: if isFunction f then </del> <ins> applyIfFunction = f: arg@{ config, options, lib, ... }: if isFunction f then </ins> let # Module arguments are resolved in a strict manner when attribute set # deconstruction is used.  As the arguments are now defined with the


Question:
I'm thinking of bringing this line back: and getting rid of nixos/modules/misc/extra- Does anyone have objections? I fully buy the ability to pass arguments in the module system using , but if it doesn't work (and breaks in a horrible way) for the most common use case ( in imports), that seems bad and the cost of restoring the old way seems pretty low. Anyone have objections? I can make the change if nobody objects. Ideally, I'd like it in 15.06, since it's getting in the way of some work I'm trying to squeeze into 15.06. cc
IMO our only choices are to do this or to set as a prerequisite (perhaps enforced using ) that points there. No strong preference either way.
Yeah, this is probably the best solution.
Cool! Do any of you know of VM tests that would suitably make sure I don't break anything too obvious by making that change? I'd obviously rather not make the change and then discover a week from now that I broke someone's key use case :smile: I'll be making the change this evening at this rate.
Any thoughts on having set using scopedImport? That way stays NixOS-independent. But not a huge difference IMO.
I don't see how adding back could break anything.
Famous last words! :grinning: But I agree, as long as it evaluates at all it's almost certainly fine.
That sounds more complicated than the one-liner suggested by

inherit prefix check; modules = modules ++ extraModules ++ baseModules ++ [ pkgsModule ]; args = extraArgs; <ins> specialArgs = { modulesPath = ../modules; }; </ins> }) config options; # These are the extra arguments passed to every module.  In


Question:
I'm thinking of bringing this line back: and getting rid of nixos/modules/misc/extra- Does anyone have objections? I fully buy the ability to pass arguments in the module system using , but if it doesn't work (and breaks in a horrible way) for the most common use case ( in imports), that seems bad and the cost of restoring the old way seems pretty low. Anyone have objections? I can make the change if nobody objects. Ideally, I'd like it in 15.06, since it's getting in the way of some work I'm trying to squeeze into 15.06. cc
IMO our only choices are to do this or to set as a prerequisite (perhaps enforced using ) that points there. No strong preference either way.
Yeah, this is probably the best solution.
Cool! Do any of you know of VM tests that would suitably make sure I don't break anything too obvious by making that change? I'd obviously rather not make the change and then discover a week from now that I broke someone's key use case :smile: I'll be making the change this evening at this rate.
Any thoughts on having set using scopedImport? That way stays NixOS-independent. But not a huge difference IMO.
I don't see how adding back could break anything.
Famous last words! :grinning: But I agree, as long as it evaluates at all it's almost certainly fine.
That sounds more complicated than the one-liner suggested by

{ _module.args = { <del> modulesPath = ../.; </del> pkgs_i686 = import ../../lib/nixpkgs.nix { system = "i686-linux"; config.allowUnfree = true;


Question:
Describe the bug The description of is: Path to the unix socket file on which to accept FastCGI requests. This option is read-only and managed by NixOS. So i can't set it. But how can i figure out how the socket path is now? Please add an example to the description! To Reproduce Steps to reproduce the behavior: option desciption Expected behavior Useful description. Metadata same in 19.09 and 20.03 Maintainer information:
The point of the option is that you don't need to find out, just reference it. That being said I agree with your issue and it would be helpful to set an example
The point of the option is that you don't need to find out, just reference it. Sure, that works in but i have that path explicitely in my webserver config which is next to the content, e.g. . For reference: The path is actually as i set it before: So i can just remove the option from my .

Path to the unix socket file on which to accept FastCGI requests. <note><para>This option is read-only and managed by NixOS.</para></note> ''; <ins> example = "${runtimeDir}/<name>.sock"; </ins> }; listen = mkOption {


Question: Describe the bug Trying to build a combined TexLive that includes Biber (e.g. ) results in failure on darwin. This seems to be the relevant error: To Reproduce Steps to reproduce the behavior: , where Expected behavior The build should succeed. Additional context The build succeeds in the example above if is omitted. Other schemes that include Biber, like , fail with the same error. Metadata system: host os: multi-user?: sandbox: version: channels(matt): nixpkgs: Maintainer information:

install_name_tool -change "$oldPath" "$newPath" "$out/bin/biblex" install_name_tool -change "$oldPath" "$newPath" "$out/bin/bibparse" install_name_tool -change "$oldPath" "$newPath" "$out/bin/dumpnames" <del> install_name_tool -change "$oldPath" "$newPath" "$out/${perl.libPrefix}/${perl.version}/darwin-2level/auto/Text/BibTeX/BibTeX.bundle" </del> <ins> install_name_tool -change "$oldPath" "$newPath" "$out/${perl.libPrefix}/${perl.version}/darwin"*"-2level/auto/Text/BibTeX/BibTeX.bundle" </ins> ''; meta = { description = "Interface to read and parse BibTeX files";


Question:
Describe the bug Haskell derivations: behaviour of in regards to changed in 20.03. Projects relying on the old behaviour will break. A number of Haskell projects I work on use to make test dependencies and build tools available in the environment when invoking . PR changed the implementation of the attribute which subtly changes the effect has. Using instead is a workaround for this (or possibly the function I should've been using all along). I believe I was using incorrectly but it is difficult to be sure, because the expected usage of and is not documented (AFAIK). Using In 19.09, ( ++ ) produces: In 20.03, ( ++ ) produces: is present in 19.09 but not 20.03. Interestingly, is not present in either. If we instead use : we get the following results in 19.09: and in 20.03: and are present in both. So, using in and does exactly what I want (with the version being a bit cleaner). The "fix" for this issue might just be to document the intended usage of: , , , , , , , and a bit more clearly (if not already - sorry, I couldn't find any). To Reproduce Steps to reproduce the behavior: (). it and cd into the directory. the following commands in a : where the invocation is one of: number of convenience make targets are available too. Expected behavior I expected to make and available in my shell.
cc as the author of , (who I think wrote the original version), and (who did an extensive review) We should probably have documentation for this, or at the very least a note in the release notes for 20.03.
Side question: how did you print the result of in the context of your actual package?
So I created a small nix file something like: Then:
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
I think this looks correct to me. Nevermind the build-time vs run-time distinctions I am usually harping about. The most important thing to understand for this is just like the regular generic builder always did, the now respects the different type of inputs parameters stating Haskell vs non-Haskell, and uses that instead of the predicate it used to sift between the combination of everything before. tl;dr and items always don't become in env, and instead get passed on to the , while and do become . On the build-time deps side, including the tools, whether or not something was written in Haskell doesn't matter, so they all become .

</listitem> <listitem> <para> <ins> Haskell <varname>env</varname> and <varname>shellFor</varname> dev shell environments now organized dependencies the same way as regular builds. In particular, rather than receiving all the different lists of dependencies master together as one big lists, and then partitioning into Haskell and non-Hakell dependencies, they work from the original many different dependency parameters and don't need to algorithmically partition anything. </para> <para> This means that if you incorrectly categorize a dependency, e.g. non-Haskell library dependency as a <varname>buildDepends</varname> or run-time Haskell dependency as a <varname>setupDepends</varname>, whereas things would have worked before they may not work now. </para> </listitem> <listitem> <para> </ins> The <package>gcc-snapshot</package>-package has been removed. It's marked as broken for >2 years and used to point to a fairly old snapshot  from the <package>gcc7</package>-branch. </para>


Question:
Project description A modification of the Mesa Vulkan overlay. Including GUI improvements, temperature reporting, and logging capabilities. Metadata homepage URL: source URL: license: gpl3 platforms: linux
I tried myself at this and have a working package now for NUR based on But I haven't yet figured out how to create a 32 and 64-bit version. Depending on the game both are necessary. To just get a 32bit version I currently just use: instead of just
It might make sense to just build the 32bit and 64bit packages separately and then merge them together in a wrapper.
okay I did something similar, though not with a wrapper which is probably a little hackish I am not sure: but this allows me now to use mangohud with 64 and 32 bit applications
That seems like a reasonable solution, although it is a little bit hackish. I'm running into a similar issue with , and it's not really clear what the best approach is. recommended keeping the two builds separate for vkBasalt. However, to ensure we can install both builds we would have to do extra patching, and use separate names for the 32bit and 64bit build. Users might also expect to have both builds in one package like on other distros. I'm leaning towards something like this or like what I've done in my .
was just released but that changed quite a few things around. instead of using two different binaries it now uses  to decide where the 32/64bit libaries are, but it seems to me that this always expands to 'lib' on NixOS This is what I have so far. Having to ignore collisions is also not really that cool. Well having a running 0.4.1 version would be nice enough, just thought I write about this somewhere
The commit in question:
I marked this as stale due to inactivity. →
Still important to me.

<ins> { stdenv, pkgs, lib , libXNVCtrl }: let mangohud_64 = pkgs.callPackage ./default.nix { inherit libXNVCtrl; }; mangohud_32 = pkgs.pkgsi686Linux.callPackage ./default.nix { inherit libXNVCtrl; }; in pkgs.buildEnv rec { name = "mangohud-${mangohud_64.version}"; paths = [ mangohud_32 ] ++ lib.optionals stdenv.is64bit [ mangohud_64 ]; meta = mangohud_64.meta; } </ins>


Question:
Project description A modification of the Mesa Vulkan overlay. Including GUI improvements, temperature reporting, and logging capabilities. Metadata homepage URL: source URL: license: gpl3 platforms: linux
I tried myself at this and have a working package now for NUR based on But I haven't yet figured out how to create a 32 and 64-bit version. Depending on the game both are necessary. To just get a 32bit version I currently just use: instead of just
It might make sense to just build the 32bit and 64bit packages separately and then merge them together in a wrapper.
okay I did something similar, though not with a wrapper which is probably a little hackish I am not sure: but this allows me now to use mangohud with 64 and 32 bit applications
That seems like a reasonable solution, although it is a little bit hackish. I'm running into a similar issue with , and it's not really clear what the best approach is. recommended keeping the two builds separate for vkBasalt. However, to ensure we can install both builds we would have to do extra patching, and use separate names for the 32bit and 64bit build. Users might also expect to have both builds in one package like on other distros. I'm leaning towards something like this or like what I've done in my .
was just released but that changed quite a few things around. instead of using two different binaries it now uses  to decide where the 32/64bit libaries are, but it seems to me that this always expands to 'lib' on NixOS This is what I have so far. Having to ignore collisions is also not really that cool. Well having a running 0.4.1 version would be nice enough, just thought I write about this somewhere
The commit in question:
I marked this as stale due to inactivity. →
Still important to me.

<ins> { stdenv , lib , fetchFromGitHub , fetchpatch , meson , ninja , pkg-config , python3Packages , dbus , glslang , libglvnd , libXNVCtrl , mesa , vulkan-headers , vulkan-loader , xorg }: stdenv.mkDerivation rec { pname = "mangohud${lib.optionalString stdenv.is32bit "_32"}"; version = "0.4.1"; src = fetchFromGitHub { owner = "flightlessmango"; repo = "MangoHud"; rev = "v${version}"; sha256 = "04v2ps8n15ph2smjgnssax5hq88bszw2kbcff37cnd5c8yysvfi6"; fetchSubmodules = true; }; patches = [ (fetchpatch { # FIXME obsolete in >=0.5.0 url = "https://patch-diff.githubusercontent.com/raw/flightlessmango/MangoHud/pull/208.patch"; sha256 = "1i6x6sr4az1zv0p6vpw99n947c7awgbbv087fghjlczhry676nmh"; }) ]; mesonFlags = [ "-Dappend_libdir_mangohud=false" "-Duse_system_vulkan=enabled" "--libdir=lib${lib.optionalString stdenv.is32bit "32"}" ]; buildInputs = [ dbus glslang libglvnd libXNVCtrl mesa python3Packages.Mako vulkan-headers vulkan-loader xorg.libX11 ]; nativeBuildInputs = [ meson ninja pkg-config python3Packages.Mako python3Packages.python ]; preConfigure = '' mkdir -p "$out/share/vulkan/" ln -sf "${vulkan-headers}/share/vulkan/registry/" $out/share/vulkan/ ln -sf "${vulkan-headers}/include" $out ''; meta = with lib; { description = "A Vulkan and OpenGL overlay for monitoring FPS, temperatures, CPU/GPU load and more"; homepage = "https://github.com/flightlessmango/MangoHud"; platforms = platforms.linux; license = licenses.mit; maintainers = with maintainers; [ zeratax ]; }; } </ins>


Question:
Project description A modification of the Mesa Vulkan overlay. Including GUI improvements, temperature reporting, and logging capabilities. Metadata homepage URL: source URL: license: gpl3 platforms: linux
I tried myself at this and have a working package now for NUR based on But I haven't yet figured out how to create a 32 and 64-bit version. Depending on the game both are necessary. To just get a 32bit version I currently just use: instead of just
It might make sense to just build the 32bit and 64bit packages separately and then merge them together in a wrapper.
okay I did something similar, though not with a wrapper which is probably a little hackish I am not sure: but this allows me now to use mangohud with 64 and 32 bit applications
That seems like a reasonable solution, although it is a little bit hackish. I'm running into a similar issue with , and it's not really clear what the best approach is. recommended keeping the two builds separate for vkBasalt. However, to ensure we can install both builds we would have to do extra patching, and use separate names for the 32bit and 64bit build. Users might also expect to have both builds in one package like on other distros. I'm leaning towards something like this or like what I've done in my .
was just released but that changed quite a few things around. instead of using two different binaries it now uses  to decide where the 32/64bit libaries are, but it seems to me that this always expands to 'lib' on NixOS This is what I have so far. Having to ignore collisions is also not really that cool. Well having a running 0.4.1 version would be nice enough, just thought I write about this somewhere
The commit in question:
I marked this as stale due to inactivity. →
Still important to me.

mandoc = callPackage ../tools/misc/mandoc { }; <ins> mangohud = callPackage ../tools/graphics/mangohud/combined.nix { libXNVCtrl = linuxPackages.nvidia_x11.settings.libXNVCtrl; }; </ins> manix = callPackage ../tools/nix/manix { inherit (darwin.apple_sdk.frameworks) Security; };


Question:
Describe the bug When writing , it was important to ensure that the .lego state directory was common to all certs to ensure that new accounts were not being created for every certificate. The rate limit on new accounts is 10 every 3 hours. This is fine for most cases, but in my deployment I have 30 different domains to request certificates for, and that's after a lot of deduplication and grouping of domains. As of this has been changed such that all certificates get their own state directories, and thus their own account credentials. As pointed out, the account directory can be symlinked using preStart scripts if necessary. I feel this isn't a matter of migrating user data but more about maintaining compatibility with existing setups like my own and also avoiding rate limits in LE's service. This should be part of the module's configuration by default.
cc and whoever else I'm missing...
I have been focused on getting a mail stack in Nixos working over the past week and I missed that PR and other things :/ sorry about that. I would've commented if I had seen it sooner.
Seems like reverting for now would probably be for the best; multiple certs for the same domain seems like a less important feature than not spamming LE with account creations. It should be possible to reuse the same account while keeping the certificates split, but maybe we'll have to make some ugly symlink forests? I wish lego's CLI was more explicit.
Well that or, we can patch in symlinking of accounts directories back a folder. I think it wouldn't be too hard, I can prepare a PR now
You before self-merging the PR and backporting it to 20.03; could you please subject your changes to critical infrastructure to wider review in future? It's quite frustrating to work with Let's Encrypt engineers to make the NixOS service well-behaved, only to have a change merged and backported that runs roughshod over rate limits and can potentially result in hundreds of certificates being renewed at once on upgrade just to avoid incorporating , with less than three hours between the PR being opened and merged, and only one recent contributor to the service being pinged. It's a lot easier to fix issues before merge than it is to rush to fight fires after something's hit the channels...
: merging every certificates in a single directory leads to this issue: It was considered blocking for 20.03 because it broke a behavior that was authorized and expected in simp_le’s age. (The idea of symlinking the account folder was proposed, but since noone reacted noone implemented it I guess)
I saw that issue and I don't intend to reintroduce it, but sharing just the accounts folder would fix this issue without regression. Of course, I will test and ensure that is the case on my system first but rest assured I have no intention to completely undo
Thanks :bow:
I created a I still don't fully understand the use case behind having multiple certs for the same domain? Surely, on a single system, you would only want one certificate per domain, even if they are for different services? Also I did think of an issue with the .lego folder as a whole... if a user uses different user and group for 2 certificates then 1 of them will own the directory and the other will not be able to write to it. I don't know if we want to support that sort of configuration? It would certainly prevent us optimising around rate limits, but it is solvable if the .lego directory is under
You can use different key types (to serve both RSA and ECDSA certificates for the same domain), or perhaps set other alternate names. In terms of directory sharing, I increasingly think that the only permissions option that makes sense from a privilege separation point of view is to have unconditionally owned by and just selectively add other services like nginx to the acme group for read access (per ).
Yeah I had read that earlier and I agree that an user + group would make sense. How do people feel about a PR for a complete revamp of the module? This was suggested back when I finished DNS-01 due to the number of changes and the complexity of the module at this stage. I would be tempted to at least try and do this (now that I have the time again), and see what can be simplified. It's becoming quite the monster.
: if you want to completely rewrite the module, you might be interested in my recently listing of some issues regarding ACME: I think the last one might be very annoying: once a certificate is created, changing the list of domains in the certificate won’t work (in other words, in the current state of the module you cannot add or delete domains from a certificate after it’s generated)
Yep also started tracking that issue already :) I think that one is resolvable by writing some file that hashes the domains + extraDomains, and takes action accordingly, but RemainAfterExit is a bigger bummer. I'll continue conversations about a rewrite over in that issue.
It was reviewed by and Catching ratelimits is not something one can easily test or fix. If one has 30 certificates they will run into certificate creation limits, in which only SAN certificates would help. The needed migration code was posted on Discourse and the Github issue for those that run unstable (Lego in ACME was never part of any stable release).
PLEASE backport this to 20.03, since it's a serious bug, with effectively completely breaks the lets-encrypt-certificate-renewal in 20.03 if more than 10 certificates are used on a server.
It was backported already. Are you actually experiencing issues? If so; please open a new bug for that
I've updated a server to 20.03 today, and I'm experiencing exactly this issue.

User = data.user; Group = data.group; PrivateTmp = true; <del> StateDirectory = "acme/.lego/${cert} ${lpath}"; </del> <ins> StateDirectory = "acme/.lego/${cert} acme/.lego/accounts ${lpath}"; </ins> StateDirectoryMode = if data.allowKeysForGroup then "750" else "700"; WorkingDirectory = spath; # Only try loading the credentialsFile if the dns challenge is enabled EnvironmentFile = if data.dnsProvider != null then data.credentialsFile else null; ExecStart = pkgs.writeScript "acme-start" '' #!${pkgs.runtimeShell} -e <ins> test -L ${spath}/accounts -o -d ${spath}/accounts || ln -s ../accounts ${spath}/accounts </ins> ${pkgs.lego}/bin/lego ${renewOpts} || ${pkgs.lego}/bin/lego ${runOpts} ''; ExecStartPost =


Question:
Describe the bug Systemd ships dbus system services (in ), which are used for dbus system activation (see ) This includes some of the units shipped with systemd itself: We currently don't have the proper tooling ready to make these available in NixOS. Also, we shouldn't blindly enable all. For example, we might not want to enable `share/dbus-1/system-services/org.freedesktop.resolve1.service, if resolved is enabled. Originally discovered in , but it always hasn't worked, so it's not a regression. Notify maintainers
I wonder if that's why every program I have that uses dBus in some way or another, spits from time to time:
Can you tell me which programs those are?
Sure, from , prints: I'm using as my display manager and I'm using as my desktop environment but I don't use . Not sure if that matters.. EDIT: Currently I can't identify another program that spits this message, although IIRC I saw it coming out of other programs as well. This could be an upstream issue as well.
It does seem that somehow picks up the systemd configuration; though I do not fully understand how it's just missing the when is enabled
Ah apparently all applications are loaded into dbus by default? Not sure how I feel about that ... so the only reason why resolved wasn't working is because we didnt included unit file in Easy fix! All the other services already work!
It seems we do, but we shouldn't do that. If we try to not restart , changes in there don't get propagated. It should just use nscd like everything else. can you file a PR removing this?
reopened, as got reverted.
I've found another example for: prints:
Another symptom is:
I'm not sure if that is a symptom of what I am solving here. I recall recently running into the same issue and I think it's a problem with how we set up user environment in certain desktop managers.
Should I open a distinct issue then?

systemd.additionalUpstreamSystemUnits = [ "systemd-resolved.service" <ins> "dbus-org.freedesktop.resolve1.service" </ins> ]; systemd.services.systemd-resolved = {


Question:
Describe the bug Systemd ships dbus system services (in ), which are used for dbus system activation (see ) This includes some of the units shipped with systemd itself: We currently don't have the proper tooling ready to make these available in NixOS. Also, we shouldn't blindly enable all. For example, we might not want to enable `share/dbus-1/system-services/org.freedesktop.resolve1.service, if resolved is enabled. Originally discovered in , but it always hasn't worked, so it's not a regression. Notify maintainers
I wonder if that's why every program I have that uses dBus in some way or another, spits from time to time:
Can you tell me which programs those are?
Sure, from , prints: I'm using as my display manager and I'm using as my desktop environment but I don't use . Not sure if that matters.. EDIT: Currently I can't identify another program that spits this message, although IIRC I saw it coming out of other programs as well. This could be an upstream issue as well.
It does seem that somehow picks up the systemd configuration; though I do not fully understand how it's just missing the when is enabled
Ah apparently all applications are loaded into dbus by default? Not sure how I feel about that ... so the only reason why resolved wasn't working is because we didnt included unit file in Easy fix! All the other services already work!
It seems we do, but we shouldn't do that. If we try to not restart , changes in there don't get propagated. It should just use nscd like everything else. can you file a PR removing this?
reopened, as got reverted.
I've found another example for: prints:
Another symptom is:
I'm not sure if that is a symptom of what I am solving here. I recall recently running into the same issue and I think it's a problem with how we set up user environment in certain desktop managers.
Should I open a distinct issue then?

users.users.systemd-network.group = "systemd-network"; systemd.additionalUpstreamSystemUnits = [ <del> "systemd-networkd.service" "systemd-networkd-wait-online.service" </del> <ins> "systemd-networkd-wait-online.service" "systemd-networkd.service" "systemd-networkd.socket" </ins> ]; systemd.network.units = mapAttrs' (n: v: nameValuePair "${n}.netdev" (netdevToUnit n v)) cfg.netdevs // mapAttrs' (n: v: nameValuePair "${n}.network" (networkToUnit n v)) cfg.networks; <ins> # systemd-networkd is socket-activated by kernel netlink route change # messages. It is important to have systemd buffer those on behalf of # networkd. systemd.sockets.systemd-networkd.wantedBy = [ "sockets.target" ]; </ins> systemd.services.systemd-networkd = { wantedBy = [ "multi-user.target" ]; <ins> aliases = [ "dbus-org.freedesktop.network1.service" ]; </ins> restartTriggers = map (x: x.source) (attrValues unitFiles); # prevent race condition with interface renaming (#39069) requires = [ "systemd-udev-settle.service" ];


Question:
Describe the bug Systemd ships dbus system services (in ), which are used for dbus system activation (see ) This includes some of the units shipped with systemd itself: We currently don't have the proper tooling ready to make these available in NixOS. Also, we shouldn't blindly enable all. For example, we might not want to enable `share/dbus-1/system-services/org.freedesktop.resolve1.service, if resolved is enabled. Originally discovered in , but it always hasn't worked, so it's not a regression. Notify maintainers
I wonder if that's why every program I have that uses dBus in some way or another, spits from time to time:
Can you tell me which programs those are?
Sure, from , prints: I'm using as my display manager and I'm using as my desktop environment but I don't use . Not sure if that matters.. EDIT: Currently I can't identify another program that spits this message, although IIRC I saw it coming out of other programs as well. This could be an upstream issue as well.
It does seem that somehow picks up the systemd configuration; though I do not fully understand how it's just missing the when is enabled
Ah apparently all applications are loaded into dbus by default? Not sure how I feel about that ... so the only reason why resolved wasn't working is because we didnt included unit file in Easy fix! All the other services already work!
It seems we do, but we shouldn't do that. If we try to not restart , changes in there don't get propagated. It should just use nscd like everything else. can you file a PR removing this?
reopened, as got reverted.
I've found another example for: prints:
Another symptom is:
I'm not sure if that is a symptom of what I am solving here. I recall recently running into the same issue and I think it's a problem with how we set up user environment in certain desktop managers.
Should I open a distinct issue then?

systemd.services.systemd-resolved = { wantedBy = [ "multi-user.target" ]; <ins> aliases = [ "dbus-org.freedesktop.resolve1.service" ]; </ins> restartTriggers = [ config.environment.etc."systemd/resolved.conf".source ]; };


Question:
Describe the bug Systemd ships dbus system services (in ), which are used for dbus system activation (see ) This includes some of the units shipped with systemd itself: We currently don't have the proper tooling ready to make these available in NixOS. Also, we shouldn't blindly enable all. For example, we might not want to enable `share/dbus-1/system-services/org.freedesktop.resolve1.service, if resolved is enabled. Originally discovered in , but it always hasn't worked, so it's not a regression. Notify maintainers
I wonder if that's why every program I have that uses dBus in some way or another, spits from time to time:
Can you tell me which programs those are?
Sure, from , prints: I'm using as my display manager and I'm using as my desktop environment but I don't use . Not sure if that matters.. EDIT: Currently I can't identify another program that spits this message, although IIRC I saw it coming out of other programs as well. This could be an upstream issue as well.
It does seem that somehow picks up the systemd configuration; though I do not fully understand how it's just missing the when is enabled
Ah apparently all applications are loaded into dbus by default? Not sure how I feel about that ... so the only reason why resolved wasn't working is because we didnt included unit file in Easy fix! All the other services already work!
It seems we do, but we shouldn't do that. If we try to not restart , changes in there don't get propagated. It should just use nscd like everything else. can you file a PR removing this?
reopened, as got reverted.
I've found another example for: prints:
Another symptom is:
I'm not sure if that is a symptom of what I am solving here. I recall recently running into the same issue and I think it's a problem with how we set up user environment in certain desktop managers.
Should I open a distinct issue then?

systemd.services.systemd-timesyncd = { wantedBy = [ "sysinit.target" ]; <ins> aliases = [ "dbus-org.freedesktop.timesync1.service" ]; </ins> restartTriggers = [ config.environment.etc."systemd/timesyncd.conf".source ]; };


Question:
Describe the bug There is no AWS AMI for NixOS 20.03 To Reproduce Steps to reproduce the behavior: Check or Try find it in AWS AMI console Expected behavior 03 is created and uploaded to AWS
CC I think knows how to do this part.
Yep, I have no idea how to do this for NixOS, so I'd need someone in the know with AWS AMI for 20.03. This actually was one of my concerns for 20.03.
I know how to build the release AMI and put it on a personal AWS S3 bucket (I'm using one now for my NixOps AWS cluster), but do not have the permissions to upload it on the official account. about 2 months ago I followed this process, which you can use if you're looking to unblock yourself: then follow these instructions to upload using : Then on NixOps you set to your custom AMI. You can also use this to bake in pkgs to the AMI so there's less startup time if you know you'll be downloading specific things on provisioning startup otherwise.

"19.09".ap-east-1.hvm-ebs = "ami-055b2348db2827ff1"; "19.09".sa-east-1.hvm-ebs = "ami-018aab68377227e06"; <del> latest = self."19.09"; </del> <ins> # 20.03.1554.94e39623a49 "20.03".eu-west-1.hvm-ebs = "ami-02c34db5766cc7013"; "20.03".eu-west-2.hvm-ebs = "ami-0e32bd8c7853883f1"; "20.03".eu-west-3.hvm-ebs = "ami-061edb1356c1d69fd"; "20.03".eu-central-1.hvm-ebs = "ami-0a1a94722dcbff94c"; "20.03".eu-north-1.hvm-ebs = "ami-02699abfacbb6464b"; "20.03".us-east-1.hvm-ebs = "ami-0c5e7760748b74e85"; "20.03".us-east-2.hvm-ebs = "ami-030296bb256764655"; "20.03".us-west-1.hvm-ebs = "ami-050be818e0266b741"; "20.03".us-west-2.hvm-ebs = "ami-06562f78dca68eda2"; "20.03".ca-central-1.hvm-ebs = "ami-02365684a173255c7"; "20.03".ap-southeast-1.hvm-ebs = "ami-0dbf353e168d155f7"; "20.03".ap-southeast-2.hvm-ebs = "ami-04c0f3a75f63daddd"; "20.03".ap-northeast-1.hvm-ebs = "ami-093d9cc49c191eb6c"; "20.03".ap-northeast-2.hvm-ebs = "ami-0087df91a7b6ebd45"; "20.03".ap-south-1.hvm-ebs = "ami-0a1a6b569af04af9d"; "20.03".ap-east-1.hvm-ebs = "ami-0d18fdd309cdefa86"; "20.03".sa-east-1.hvm-ebs = "ami-09859378158ae971d"; latest = self."20.03"; </ins> }; in self


Question:
Describe the bug A clear and concise description of what the bug is. The package fails to build. It errors out during the installation of bash completions with "Permissions denied". To Reproduce Steps to reproduce the behavior: -build -A mosh Expected behavior Successful build Notify maintainers Metadata on Maintainer information:
The breaking commit is the bash-completion update from 2.9 to 2.10: . Any idea how to resolve this?
I think you meant to link . Seems to be a regression from incorrectly dropping by ( in ). The "wrong" prefix comes from . A possible alternative would be to drop the dependency on for (if there's a correct fallback - since we don't actually the prefix from anyway).
I think removing this patch was correct, as the functionality introduced in that patch was to 2.10, however a program needs to define instead of when reading variable, which may necessitate patches (which could be upstreamed). It's unfortunate that the upstream decided on different approach than what was done previously, but trying to preserve the old behaviour would cause more issues in long-term. Let's not overcomplicate things when some of upstream projects already have code that uses when using = 2.10. I imagine this is the line that needs changing:
sorry, my assumption about the patch was wrong then :o And thanks for the fix :) Edit: And I agree that we should follow upstream then.

<ins> diff --git a/configure.ac b/configure.ac index 3ad983d..ff8ff96 100644 --- a/configure.ac +++ b/configure.ac @@ -476,13 +476,7 @@ AS_IF([echo "$protobuf_LIBS" | grep -q -- -pthread], # Bash completion needs to ask where it goes if >= 2.0 is installed. AS_IF([test "$install_completion" != no], -  [PKG_CHECK_MODULES([BASH_COMPLETION], [bash-completion >= 2.0], -     [if test "$prefix" = "NONE"; then -        completions="`pkg-config --variable=completionsdir bash-completion`" -      else -        completions="`pkg-config --define-variable=prefix=$prefix --variable=completionsdir bash-completion`" -      fi], -     [completions="${sysconfdir}/bash_completion.d"]) +   [completions="`pkg-config --define-variable=datadir=$datadir --variable=completionsdir bash-completion`"] AC_SUBST([completions])]) AC_CONFIG_FILES([ </ins>


Question:
Describe the bug A clear and concise description of what the bug is. The package fails to build. It errors out during the installation of bash completions with "Permissions denied". To Reproduce Steps to reproduce the behavior: -build -A mosh Expected behavior Successful build Notify maintainers Metadata on Maintainer information:
The breaking commit is the bash-completion update from 2.9 to 2.10: . Any idea how to resolve this?
I think you meant to link . Seems to be a regression from incorrectly dropping by ( in ). The "wrong" prefix comes from . A possible alternative would be to drop the dependency on for (if there's a correct fallback - since we don't actually the prefix from anyway).
I think removing this patch was correct, as the functionality introduced in that patch was to 2.10, however a program needs to define instead of when reading variable, which may necessitate patches (which could be upstreamed). It's unfortunate that the upstream decided on different approach than what was done previously, but trying to preserve the old behaviour would cause more issues in long-term. Let's not overcomplicate things when some of upstream projects already have code that uses when using = 2.10. I imagine this is the line that needs changing:
sorry, my assumption about the patch was wrong then :o And thanks for the fix :) Edit: And I agree that we should follow upstream then.

url = "https://github.com/mobile-shell/mosh/commit/e5f8a826ef9ff5da4cfce3bb8151f9526ec19db0.patch"; sha256 = "15518rb0r5w1zn4s6981bf1sz6ins6gpn2saizfzhmr13hw4gmhm"; }) <ins> # Fix build with bash-completion 2.10 ./bash_completion_datadir.patch </ins> ]; postPatch = '' substituteInPlace scripts/mosh.pl


Question:
Describe the bug do not run. To Reproduce 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:
meets the same error.
I think I might have the same issue with solargraph: The same command from nixpkgs-19.09 seems fine: Possibly due to the bundler changes in ? EDIT: Hm. But in a docker container (lnl7/nix:2020-03-07), runs fine. Something in my environment? Or darwin weirdness?
I had a similar issue and I found that my global bundler config was the problem. changed the generated binstubs so that the environment variable is no longer set which I think means that bundler will now use from the global config if it exists. This seems to result in bundler looking for gems in the wrong location. A possible workaround is to set using an environment variable instead of using the global config since this value will be unset by the generated binstubs but will still have an effect when bundler is used from somewhere else. There is also the environment variable which causes bundler to ignore all configuration but that might have other unwanted effects.
I marked this as stale due to inactivity. →
Do you still experience the issue? nixos tests of the service are passing and I'm unable to replicate on the current nixpkgs or even in commit
Yes. and don't run. I'm in nixos-unstable .
I removed in then both programs run fine.
Hopefully or a similar change will get merged and prevent these problems. I've seen a few issues like this get reported.

ENV["BUNDLE_GEMFILE"] = #{gemfile.dump} ENV.delete 'BUNDLE_PATH' ENV['BUNDLE_FROZEN'] = '1' <ins> ENV['BUNDLE_IGNORE_CONFIG'] = '1' </ins> Gem.paths = { 'GEM_HOME' => #{bundle_path.dump} }


Question:
Hi, i need to use open-zwave as a dependency for a build, but the version built in the Nix package is a specific fork for supporting home-assistant, which does not work for my package build due to linking errors. I will happily contribute a new package, but I'm not sure how to proceed, with regards to how it would fit in with this package, or if indeed the best way would be to modify this package to use the upstream repo. Pinging people who have maintained the package, apologies for the noise!
Hello, I'm a bot and I thank you in the name of the community for opening this issue. To help our human contributors focus on the most-relevant reports, I check up on old issues to see if they're still relevant. This issue has had no activity for 180 days, and so I marked it as stale, but you can rest assured it will never be closed by a non-human. The community would appreciate your effort in checking if the issue is still valid. If it isn't, please close it. If the issue persists, and you'd like to remove the stale label, you simply need to leave a comment. Your comment can be as simple as "still important to me". If you'd like it to get more attention, you can ask for help by searching for maintainers and people that previously touched related code and @ mention them in a comment. You can use or on the relevant files to find them. Lastly, you can always ask for help at or at .
We should replace the package with an official version and make use the fork.

<del> { lib, stdenv, fetchFromGitHub </del> <ins> { lib, stdenv, fetchFromGitHub, fetchpatch </ins> , doxygen, fontconfig, graphviz-nox, libxml2, pkg-config, which , systemd }: <del> let version = "2019-12-08"; in stdenv.mkDerivation { </del> <ins> stdenv.mkDerivation rec { </ins> pname = "openzwave"; <del> inherit version; </del> <ins> version = "1.6"; </ins> <del> # Use fork by Home Assistant because this package is mainly used for python.pkgs.homeassistant-pyozw. # See https://github.com/OpenZWave/open-zwave/compare/master...home-assistant:hass for the difference. </del> src = fetchFromGitHub { <del> owner = "home-assistant"; </del> <ins> owner = "OpenZWave"; </ins> repo = "open-zwave"; <del> rev = "2cd2137025c529835e4893a7b87c3d56605b2681"; sha256 = "04g8fb4f4ihakvvsmzcnncgfdd2ikmki7s22i9c6layzdwavbwf1"; </del> <ins> rev = "v${version}"; sha256 = "0xgs4mmr0480c269wx9xkk67ikjzxkh8xcssrdx0f5xcl1lyd333"; </ins> }; <ins> patches = [ (fetchpatch { name = "fix-strncat-build-failure.patch"; url = "https://github.com/OpenZWave/open-zwave/commit/601e5fb16232a7984885e67fdddaf5b9c9dd8105.patch"; sha256 = "1n1k5arwk1dyc12xz6xl4n8yw28vghzhv27j65z1nca4zqsxgza1"; }) (fetchpatch { name = "fix-text-uninitialized.patch"; url = "https://github.com/OpenZWave/open-zwave/commit/3b029a467e83bc7f0054e4dbba1e77e6eac7bc7f.patch"; sha256 = "183mrzjh1zx2b2wzkj4jisiw8br7g7bbs167afls4li0fm01d638"; }) ]; outputs = [ "out" "doc" ]; </ins> nativeBuildInputs = [ doxygen fontconfig graphviz-nox libxml2 pkg-config which ]; buildInputs = [ systemd ];


Question:
Hi, i need to use open-zwave as a dependency for a build, but the version built in the Nix package is a specific fork for supporting home-assistant, which does not work for my package build due to linking errors. I will happily contribute a new package, but I'm not sure how to proceed, with regards to how it would fit in with this package, or if indeed the best way would be to modify this package to use the upstream repo. Pinging people who have maintained the package, apologies for the noise!
Hello, I'm a bot and I thank you in the name of the community for opening this issue. To help our human contributors focus on the most-relevant reports, I check up on old issues to see if they're still relevant. This issue has had no activity for 180 days, and so I marked it as stale, but you can rest assured it will never be closed by a non-human. The community would appreciate your effort in checking if the issue is still valid. If it isn't, please close it. If the issue persists, and you'd like to remove the stale label, you simply need to leave a comment. Your comment can be as simple as "still important to me". If you'd like it to get more attention, you can ask for help by searching for maintainers and people that previously touched related code and @ mention them in a comment. You can use or on the relevant files to find them. Lastly, you can always ask for help at or at .
We should replace the package with an official version and make use the fork.

enableParallelBuilding = true; <del> installPhase = '' runHook preInstall DESTDIR=$out PREFIX= pkgconfigdir=lib/pkgconfig make install $installFlags runHook postInstall ''; </del> <ins> makeFlags = [ "PREFIX=${placeholder "out"}" ]; </ins> FONTCONFIG_FILE="${fontconfig.out}/etc/fonts/fonts.conf"; FONTCONFIG_PATH="${fontconfig.out}/etc/fonts/";


Question:
Hi, i need to use open-zwave as a dependency for a build, but the version built in the Nix package is a specific fork for supporting home-assistant, which does not work for my package build due to linking errors. I will happily contribute a new package, but I'm not sure how to proceed, with regards to how it would fit in with this package, or if indeed the best way would be to modify this package to use the upstream repo. Pinging people who have maintained the package, apologies for the noise!
Hello, I'm a bot and I thank you in the name of the community for opening this issue. To help our human contributors focus on the most-relevant reports, I check up on old issues to see if they're still relevant. This issue has had no activity for 180 days, and so I marked it as stale, but you can rest assured it will never be closed by a non-human. The community would appreciate your effort in checking if the issue is still valid. If it isn't, please close it. If the issue persists, and you'd like to remove the stale label, you simply need to leave a comment. Your comment can be as simple as "still important to me". If you'd like it to get more attention, you can ask for help by searching for maintainers and people that previously touched related code and @ mention them in a comment. You can use or on the relevant files to find them. Lastly, you can always ask for help at or at .
We should replace the package with an official version and make use the fork.

--replace /etc/openzwave $out/etc/openzwave ''; <del> fixupPhase = '' substituteInPlace $out/lib/pkgconfig/libopenzwave.pc  --replace prefix= prefix=$out  --replace dir=    dir=$out substituteInPlace $out/bin/ozw_config  --replace pcfile=${pkg-config} pcfile=$out ''; </del> meta = with lib; { description = "C++ library to control Z-Wave Networks via a USB Z-Wave Controller"; homepage = "http://www.openzwave.net/";


Question:
Hi, i need to use open-zwave as a dependency for a build, but the version built in the Nix package is a specific fork for supporting home-assistant, which does not work for my package build due to linking errors. I will happily contribute a new package, but I'm not sure how to proceed, with regards to how it would fit in with this package, or if indeed the best way would be to modify this package to use the upstream repo. Pinging people who have maintained the package, apologies for the noise!
Hello, I'm a bot and I thank you in the name of the community for opening this issue. To help our human contributors focus on the most-relevant reports, I check up on old issues to see if they're still relevant. This issue has had no activity for 180 days, and so I marked it as stale, but you can rest assured it will never be closed by a non-human. The community would appreciate your effort in checking if the issue is still valid. If it isn't, please close it. If the issue persists, and you'd like to remove the stale label, you simply need to leave a comment. Your comment can be as simple as "still important to me". If you'd like it to get more attention, you can ask for help by searching for maintainers and people that previously touched related code and @ mention them in a comment. You can use or on the relevant files to find them. Lastly, you can always ask for help at or at .
We should replace the package with an official version and make use the fork.

<del> { python_openzwave, fetchPypi }: </del> <ins> { python_openzwave, fetchPypi, openzwave, fetchFromGitHub }: </ins> <del> python_openzwave.overridePythonAttrs (oldAttrs: rec { </del> <ins> (python_openzwave.override { openzwave = openzwave.overrideAttrs (oldAttrs: { version = "unstable-2020-03-24"; src = fetchFromGitHub { owner = "home-assistant"; repo = "open-zwave"; rev = "94267fa298c1882f0dc73c0fd08f1f755ba83e83"; sha256 = "0p2869fwidz1wcqzfm52cwm9ab96pmwkna3d4yvvh21nh09cvmwk"; }; patches = [ ]; }); }).overridePythonAttrs (oldAttrs: rec { </ins> pname = "homeassistant_pyozw"; version = "0.1.10";


Question: Describe the bug KDE has trouble with some SVGs, particularly the one bundled in alacritty. To Reproduce Steps to reproduce the behavior: alacritty Expected behavior The icon was properly rendered. Screenshots See picture of gwenview vs. inkscape vs icon in my taskbar. ! Additional context It seems alacritty bundles a png for KDE, as well as a high compat svg, I'm currently trying to make an overlay to fix this. See:

cp -r $releaseDir/osx/Alacritty.app $out/Applications/Alacritty.app '' else '' install -D extra/linux/Alacritty.desktop -t $out/share/applications/ <del> install -D extra/logo/alacritty-term.svg $out/share/icons/hicolor/scalable/apps/Alacritty.svg </del> <ins> install -D extra/logo/compat/alacritty-term.svg $out/share/icons/hicolor/scalable/apps/Alacritty.svg </ins> # patchelf generates an ELF that binutils' "strip" doesn't like: #    strip: not enough room for program headers, try linking with -N


Question:
Describe the bug Since switching from to I needed to switch from to , otherwise the system does not boot anymore. To Reproduce Steps to reproduce the behavior: system on lvm-inside-luks using either or channel password - gets accepted correctly - LUKS seems to be working does not boot - complains about missing root device Expected behavior Would boot :) Screenshots : ! : ! Additional context All my config for this machine starts from - I link this file in place of Notify maintainers maybe ? <!-- 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. ^ using channel with kernel right now Happy to help debug this if needed :)
What filesystem are you using? If it's a mainlined filesystem, I don't believe hardened should've broken that. But it's probably depending on which is disabled in hardened.
Thanks so much for the reponse :) It's for , hopefully still mainlined ? ;) I can try to compile the kernel with set but otherwise with hardened settings enabled and see if it helps ?
Sorry, this is my fault! Yeah, my guess is that we need to re-enable AIO. I did notice some additional harmless-seeming warnings at boot that seemed AIO-related when writing (which switched to a patchset that disables AIO by default), but I guess it didn't affect any of my systems because they use ZFS. I was hoping AIO was only required by marginal things (like Oracle...), but LVM is pretty important. Given that nginx also uses AIO per , it might be worth explicitly turning it on in the default shared Kconfig (as I did for System V IPC in the original PR). I'm not sure if the AIO code is known to be particularly crufty by Linux standards or if it's just a general attack surface reduction thing; a few of the linux-hardened defaults are a bit better-suited to the Android environment than a desktop Linux distro. credits to the original linux-hardened author's Android-based which makes me suspect this might be the case here. Here's a nixpkgs diff to re-enable AIO: It'd definitely be good to know if this fixes things for you. should be enough to test this. If you don't want to use a custom nixpkgs then you can do a fiddly thing like the definition of  in .
Also, this would be pretty easy to test for, so if this change fixes it then we should also update the hardened test to use LVM.
Heya, good news ! One kernel compilation later - I'm back to running thanks to you :) I tried the route and indeed it worked. For the test - I think that would be awesome, to catch things like this in the future :)

SYSVIPC            = yes;  # System-V IPC <ins> AIO                = yes;  # POSIX asynchronous I/O </ins> UNIX               = yes;  # Unix domain sockets. MD                 = yes;     # Device mapper (RAID, LVM, etc.)


Question:
Describe the bug Riot-Desktop -Security & Privacy Under the "Message search" heading, observe: Riot is missing some components required for securely caching encrypted messages locally. If you'd like to experiment with this feature, build a custom Riot Desktop with search components . it links to here: Notify maintainers cc: Metadata Maintainer information:
Would be fantastic to have built with . I tried building it myself but couldn't do it. :cry:
Just stumbled across this myself. What's the current state on this? What needs to be done before this can be fixed?
So, element seems to use its own build system to build these native dependencies. It tries to download and build those itself with cargo and stuff. Seems quite complicated to package.
I would like to add that support for desktop notifications would be also appreciated. (They showed up on Arch's version, at least) Edit: This problem has been resolved since
I made some progress. This solves the issue of downloading the hakDependencies. Unfortunately they are not locked in any way, so we need to lock them at packaging-time (is that even a term?) by adding them to and Since yarn2nix always runs yarn with , we can safely ignore the upstream reasoning for fetching them outside of yarn dependencies. I'm now at the point where it tries to build seshat in the element-desktop derivation, but unfortunately they don't provide a Cargo lockfile. I'm working on resolving this problem upstream: <details</details
It turns out to be much more complicated, because the cargo build of seshat-node-native calls , so we have multiple layers of npm calling yarn calling cargo calling npm. With lots of things being downloaded and executed. It's a huge shitshow.
Is there anything we could do to help fix building with encrypted chat search working on NixOS?
I poured some (many) more hours into this today. I can build the two native modules, matrix-seshat and keytar, both in a seperate derivation and as part of the element-desktop build. However, I can not build them correctly against electron's node lib, so when starting the compiled thing, it refuses to load the module. Attempting to build against electron gives a mystic error. Or the second approach, with everything in one derivation using the hak tool: <details</details<rantHonestly it's just a horrible build system. hak and neon and so on don't give any consideration to users who want to build the libraries in an environment without an internet connection. </rant If you can find a fix for the error, there shouldn't be much work left.
I think I found the solution to that error: Upstream is using Electron 12.x while we are using Electron 13.x.
! PR incoming :sparkles:

{ lib, fetchFromGitHub , makeWrapper, makeDesktopItem, mkYarnPackage , electron, element-web <ins> , callPackage </ins> }: # Notes for maintainers: # * versions of `element-web` and `element-desktop` should be kept in sync.


Question:
Describe the bug Riot-Desktop -Security & Privacy Under the "Message search" heading, observe: Riot is missing some components required for securely caching encrypted messages locally. If you'd like to experiment with this feature, build a custom Riot Desktop with search components . it links to here: Notify maintainers cc: Metadata Maintainer information:
Would be fantastic to have built with . I tried building it myself but couldn't do it. :cry:
Just stumbled across this myself. What's the current state on this? What needs to be done before this can be fixed?
So, element seems to use its own build system to build these native dependencies. It tries to download and build those itself with cargo and stuff. Seems quite complicated to package.
I would like to add that support for desktop notifications would be also appreciated. (They showed up on Arch's version, at least) Edit: This problem has been resolved since
I made some progress. This solves the issue of downloading the hakDependencies. Unfortunately they are not locked in any way, so we need to lock them at packaging-time (is that even a term?) by adding them to and Since yarn2nix always runs yarn with , we can safely ignore the upstream reasoning for fetching them outside of yarn dependencies. I'm now at the point where it tries to build seshat in the element-desktop derivation, but unfortunately they don't provide a Cargo lockfile. I'm working on resolving this problem upstream: <details</details
It turns out to be much more complicated, because the cargo build of seshat-node-native calls , so we have multiple layers of npm calling yarn calling cargo calling npm. With lots of things being downloaded and executed. It's a huge shitshow.
Is there anything we could do to help fix building with encrypted chat search working on NixOS?
I poured some (many) more hours into this today. I can build the two native modules, matrix-seshat and keytar, both in a seperate derivation and as part of the element-desktop build. However, I can not build them correctly against electron's node lib, so when starting the compiled thing, it refuses to load the module. Attempting to build against electron gives a mystic error. Or the second approach, with everything in one derivation using the hak tool: <details</details<rantHonestly it's just a horrible build system. hak and neon and so on don't give any consideration to users who want to build the libraries in an environment without an internet connection. </rant If you can find a fix for the error, there shouldn't be much work left.
I think I found the solution to that error: Upstream is using Electron 12.x while we are using Electron 13.x.
! PR incoming :sparkles:

nativeBuildInputs = [ makeWrapper ]; <ins> seshat = callPackage ./seshat {}; keytar = callPackage ./keytar {}; </ins> buildPhase = '' runHook preBuild export HOME=$(mktemp -d)


Question:
Describe the bug Riot-Desktop -Security & Privacy Under the "Message search" heading, observe: Riot is missing some components required for securely caching encrypted messages locally. If you'd like to experiment with this feature, build a custom Riot Desktop with search components . it links to here: Notify maintainers cc: Metadata Maintainer information:
Would be fantastic to have built with . I tried building it myself but couldn't do it. :cry:
Just stumbled across this myself. What's the current state on this? What needs to be done before this can be fixed?
So, element seems to use its own build system to build these native dependencies. It tries to download and build those itself with cargo and stuff. Seems quite complicated to package.
I would like to add that support for desktop notifications would be also appreciated. (They showed up on Arch's version, at least) Edit: This problem has been resolved since
I made some progress. This solves the issue of downloading the hakDependencies. Unfortunately they are not locked in any way, so we need to lock them at packaging-time (is that even a term?) by adding them to and Since yarn2nix always runs yarn with , we can safely ignore the upstream reasoning for fetching them outside of yarn dependencies. I'm now at the point where it tries to build seshat in the element-desktop derivation, but unfortunately they don't provide a Cargo lockfile. I'm working on resolving this problem upstream: <details</details
It turns out to be much more complicated, because the cargo build of seshat-node-native calls , so we have multiple layers of npm calling yarn calling cargo calling npm. With lots of things being downloaded and executed. It's a huge shitshow.
Is there anything we could do to help fix building with encrypted chat search working on NixOS?
I poured some (many) more hours into this today. I can build the two native modules, matrix-seshat and keytar, both in a seperate derivation and as part of the element-desktop build. However, I can not build them correctly against electron's node lib, so when starting the compiled thing, it refuses to load the module. Attempting to build against electron gives a mystic error. Or the second approach, with everything in one derivation using the hak tool: <details</details<rantHonestly it's just a horrible build system. hak and neon and so on don't give any consideration to users who want to build the libraries in an environment without an internet connection. </rant If you can find a fix for the error, there shouldn't be much work left.
I think I found the solution to that error: Upstream is using Electron 12.x while we are using Electron 13.x.
! PR incoming :sparkles:

yarn run i18n node ./scripts/copy-res.js popd <ins> rm -rf node_modules/matrix-seshat node_modules/keytar ln -s $keytar node_modules/keytar ln -s $seshat node_modules/matrix-seshat </ins> runHook postBuild '';


Question:
Describe the bug Riot-Desktop -Security & Privacy Under the "Message search" heading, observe: Riot is missing some components required for securely caching encrypted messages locally. If you'd like to experiment with this feature, build a custom Riot Desktop with search components . it links to here: Notify maintainers cc: Metadata Maintainer information:
Would be fantastic to have built with . I tried building it myself but couldn't do it. :cry:
Just stumbled across this myself. What's the current state on this? What needs to be done before this can be fixed?
So, element seems to use its own build system to build these native dependencies. It tries to download and build those itself with cargo and stuff. Seems quite complicated to package.
I would like to add that support for desktop notifications would be also appreciated. (They showed up on Arch's version, at least) Edit: This problem has been resolved since
I made some progress. This solves the issue of downloading the hakDependencies. Unfortunately they are not locked in any way, so we need to lock them at packaging-time (is that even a term?) by adding them to and Since yarn2nix always runs yarn with , we can safely ignore the upstream reasoning for fetching them outside of yarn dependencies. I'm now at the point where it tries to build seshat in the element-desktop derivation, but unfortunately they don't provide a Cargo lockfile. I'm working on resolving this problem upstream: <details</details
It turns out to be much more complicated, because the cargo build of seshat-node-native calls , so we have multiple layers of npm calling yarn calling cargo calling npm. With lots of things being downloaded and executed. It's a huge shitshow.
Is there anything we could do to help fix building with encrypted chat search working on NixOS?
I poured some (many) more hours into this today. I can build the two native modules, matrix-seshat and keytar, both in a seperate derivation and as part of the element-desktop build. However, I can not build them correctly against electron's node lib, so when starting the compiled thing, it refuses to load the module. Attempting to build against electron gives a mystic error. Or the second approach, with everything in one derivation using the hak tool: <details</details<rantHonestly it's just a horrible build system. hak and neon and so on don't give any consideration to users who want to build the libraries in an environment without an internet connection. </rant If you can find a fix for the error, there shouldn't be much work left.
I think I found the solution to that error: Upstream is using Electron 12.x while we are using Electron 13.x.
! PR incoming :sparkles:

<ins> { stdenv, fetchFromGitHub, nodejs-14_x, python3, callPackage, fixup_yarn_lock, yarn, pkg-config, libsecret }: stdenv.mkDerivation rec { pname = "keytar"; version = "7.7.0"; src = fetchFromGitHub { owner = "atom"; repo = "node-keytar"; rev = "v${version}"; sha256 = "0ajvr4kjbyw2shb1y14c0dsghdlnq30f19hk2sbzj6n9y3xa3pmi"; }; nativeBuildInputs = [ nodejs-14_x python3 yarn pkg-config]; buildInputs = [ libsecret ]; npm_config_nodedir = nodejs-14_x; yarnOfflineCache = (callPackage ./yarn.nix {}).offline_cache; buildPhase = '' cp ${./yarn.lock} ./yarn.lock chmod u+w . ./yarn.lock export HOME=/tmp yarn config --offline set yarn-offline-mirror ${yarnOfflineCache} ${fixup_yarn_lock}/bin/fixup_yarn_lock yarn.lock yarn install --offline --frozen-lockfile --ignore-platform --ignore-scripts --no-progress --non-interactive patchShebangs node_modules/ node_modules/.bin/node-gyp rebuild ''; doCheck = false; installPhase = '' shopt -s extglob rm -rf node_modules mkdir -p $out cp -r ./!(build) $out install -D -t $out/build/Release build/Release/keytar.node ''; } </ins>


Question:
Describe the bug Riot-Desktop -Security & Privacy Under the "Message search" heading, observe: Riot is missing some components required for securely caching encrypted messages locally. If you'd like to experiment with this feature, build a custom Riot Desktop with search components . it links to here: Notify maintainers cc: Metadata Maintainer information:
Would be fantastic to have built with . I tried building it myself but couldn't do it. :cry:
Just stumbled across this myself. What's the current state on this? What needs to be done before this can be fixed?
So, element seems to use its own build system to build these native dependencies. It tries to download and build those itself with cargo and stuff. Seems quite complicated to package.
I would like to add that support for desktop notifications would be also appreciated. (They showed up on Arch's version, at least) Edit: This problem has been resolved since
I made some progress. This solves the issue of downloading the hakDependencies. Unfortunately they are not locked in any way, so we need to lock them at packaging-time (is that even a term?) by adding them to and Since yarn2nix always runs yarn with , we can safely ignore the upstream reasoning for fetching them outside of yarn dependencies. I'm now at the point where it tries to build seshat in the element-desktop derivation, but unfortunately they don't provide a Cargo lockfile. I'm working on resolving this problem upstream: <details</details
It turns out to be much more complicated, because the cargo build of seshat-node-native calls , so we have multiple layers of npm calling yarn calling cargo calling npm. With lots of things being downloaded and executed. It's a huge shitshow.
Is there anything we could do to help fix building with encrypted chat search working on NixOS?
I poured some (many) more hours into this today. I can build the two native modules, matrix-seshat and keytar, both in a seperate derivation and as part of the element-desktop build. However, I can not build them correctly against electron's node lib, so when starting the compiled thing, it refuses to load the module. Attempting to build against electron gives a mystic error. Or the second approach, with everything in one derivation using the hak tool: <details</details<rantHonestly it's just a horrible build system. hak and neon and so on don't give any consideration to users who want to build the libraries in an environment without an internet connection. </rant If you can find a fix for the error, there shouldn't be much work left.
I think I found the solution to that error: Upstream is using Electron 12.x while we are using Electron 13.x.
! PR incoming :sparkles:

<ins> #!/usr/bin/env nix-shell #!nix-shell -I nixpkgs=../ -i bash -p wget yarn2nix yarn set -euo pipefail if [ "$#" -ne 1 ] || [[ "$1" == -* ]]; then echo "Regenerates the Yarn dependency lock files." echo "Usage: $0 <git release tag>" exit 1 fi SRC="https://raw.githubusercontent.com/atom/node-keytar/$1" wget "$SRC/package-lock.json" wget "$SRC/package.json" rm -f yarn.lock yarn import yarn2nix > yarn.nix rm -rf node_modules package.json package-lock.json </ins>