Question: has two forms of input for the field. and . I personally use the latter as it is the output of and better than having cleartext passphrases. (This also works with a random AES key - so long that it is shared) The current implementation lacks the distinction and only works with passphrases. I believe this should be .

${optionalString cfg.userControlled.enable '' ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=${cfg.userControlled.group} update_config=1''} <del> ${concatStringsSep "n" (mapAttrsToList (ssid: networkConfig: '' </del> <ins> ${concatStringsSep "n" (mapAttrsToList (ssid: networkConfig: let psk = if networkConfig.psk != null then ''"${networkConfig.psk}"'' else networkConfig.pskRaw; in '' </ins> network={ ssid="${ssid}" <del> ${optionalString (networkConfig.psk != null) ''psk="${networkConfig.psk}"''} ${optionalString (networkConfig.psk == null) ''key_mgmt=NONE''} </del> <ins> ${optionalString (psk != null) ''psk=${psk}''} ${optionalString (psk == null) ''key_mgmt=NONE''} </ins> } '') cfg.networks)} '' else "/etc/wpa_supplicant.conf";


Question: has two forms of input for the field. and . I personally use the latter as it is the output of and better than having cleartext passphrases. (This also works with a random AES key - so long that it is shared) The current implementation lacks the distinction and only works with passphrases. I believe this should be .

Be aware that these will be written to the nix store in plaintext! <ins> Mutually exclusive with <varname>pskRaw</varname>. ''; }; pskRaw = mkOption { type = types.nullOr types.str; default = null; description = '' The network's pre-shared key in hex defaulting to being a network without any authentication. Mutually exclusive with <varname>psk</varname>. </ins> ''; }; };


Question: has two forms of input for the field. and . I personally use the latter as it is the output of and better than having cleartext passphrases. (This also works with a random AES key - so long that it is shared) The current implementation lacks the distinction and only works with passphrases. I believe this should be .

config = mkMerge [ (mkIf cfg.enable { <ins> assertions = flip mapAttrsToList cfg.networks (name: cfg: { assertion = cfg.psk == null || cfg.pskRaw == null; message = ''networking.wireless."${name}".psk and networking.wireless."${name}".pskRaw are mutually exclusive''; }); </ins> environment.systemPackages =  [ pkgs.wpa_supplicant ]; services.dbus.packages = [ pkgs.wpa_supplicant ];


Question:
Project description
I marked this as stale due to inactivity. →
ping! Is this still an issue?
has been The command still does not have documentation in the Nixpkgs manual.
Is satisfying? Could use approval to get merged.
It's a good step, but it doesn't (yet?) tell me what the options are.
Now it does.

source $stdenv/setup ``` <del> to let `stdenv` set up the environment (e.g., process the `buildInputs`). If you want, you can still use `stdenv`’s generic builder: </del> <ins> to let `stdenv` set up the environment (e.g. by resetting `PATH` and populating it from build inputs). If you want, you can still use `stdenv`’s generic builder: </ins> ```bash source $stdenv/setup


Question:
Project description
I marked this as stale due to inactivity. →
ping! Is this still an issue?
has been The command still does not have documentation in the Nixpkgs manual.
Is satisfying? Could use approval to get merged.
It's a good step, but it doesn't (yet?) tell me what the options are.
Now it does.

### The fixup phase {#ssec-fixup-phase} <del> The fixup phase performs some (Nix-specific) post-processing actions on the files installed under `$out` by the install phase. The default `fixupPhase` does the following: </del> <ins> The fixup phase performs (Nix-specific) post-processing actions on the files installed under `$out` by the install phase. The default `fixupPhase` does the following: </ins> - It moves the `man/`, `doc/` and `info/` subdirectories of `$out` to `share/`. - It strips libraries and executables of debug information. - On Linux, it applies the `patchelf` command to ELF executables and libraries to remove unused directories from the `RPATH` in order to prevent unnecessary runtime dependencies. <del> - It rewrites the interpreter paths of shell scripts to paths found in `PATH`. E.g., `/usr/bin/perl` will be rewritten to `/nix/store/some-perl/bin/perl` found in `PATH`. </del> <ins> - It rewrites the interpreter paths of shell scripts to paths found in `PATH`. E.g., `/usr/bin/perl` will be rewritten to `/nix/store/some-perl/bin/perl` found in `PATH`. See [](#patch-shebangs.sh) for details. </ins> #### Variables controlling the fixup phase {#variables-controlling-the-fixup-phase}


Question:
Project description
I marked this as stale due to inactivity. →
ping! Is this still an issue?
has been The command still does not have documentation in the Nixpkgs manual.
Is satisfying? Could use approval to get merged.
It's a good step, but it doesn't (yet?) tell me what the options are.
Now it does.

##### `dontPatchShebangs` {#var-stdenv-dontPatchShebangs} <del> If set, scripts starting with `#!` do not have their interpreter paths rewritten to paths in the Nix store. </del> <ins> If set, scripts starting with `#!` do not have their interpreter paths rewritten to paths in the Nix store. See [](#patch-shebangs.sh) on how patching shebangs works. </ins> ##### `dontPruneLibtoolFiles` {#var-stdenv-dontPruneLibtoolFiles}


Question:
Project description
I marked this as stale due to inactivity. →
ping! Is this still an issue?
has been The command still does not have documentation in the Nixpkgs manual.
Is satisfying? Could use approval to get merged.
It's a good step, but it doesn't (yet?) tell me what the options are.
Now it does.

The *existence* of setups hooks has long been documented and packages inside Nixpkgs are free to use this mechanism. Other packages, however, should not rely on these mechanisms not changing between Nixpkgs versions. Because of the existing issues with this system, there’s little benefit from mandating it be stable for any period of time. <del> First, let’s cover some setup hooks that are part of Nixpkgs default stdenv. This means that they are run for every package built using `stdenv.mkDerivation`. Some of these are platform specific, so they may run on Linux but not Darwin or vice-versa. </del> <ins> First, let’s cover some setup hooks that are part of Nixpkgs default `stdenv`. This means that they are run for every package built using `stdenv.mkDerivation` or when using a custom builder that has `source $stdenv/setup`. Some of these are platform specific, so they may run on Linux but not Darwin or vice-versa. </ins> ### `move-docs.sh` {#move-docs.sh}


Question:
Project description
I marked this as stale due to inactivity. →
ping! Is this still an issue?
has been The command still does not have documentation in the Nixpkgs manual.
Is satisfying? Could use approval to get merged.
It's a good step, but it doesn't (yet?) tell me what the options are.
Now it does.

### `patch-shebangs.sh` {#patch-shebangs.sh} <del> This setup hook patches installed scripts to use the full path to the shebang interpreter. A shebang interpreter is the first commented line of a script telling the operating system which program will run the script (e.g `#!/bin/bash`). In Nix, we want an exact path to that interpreter to be used. This often replaces `/bin/sh` with a path in the Nix store. </del> <ins> This setup hook patches installed scripts to add Nix store paths to their shebang interpreter as found in the build environment. The [shebang](https://en.wikipedia.org/wiki/Shebang_(Unix)) line tells a Unix-like operating system which interpreter to use to execute the script's contents. ::: note The [generic builder][generic-builder] populates `PATH` from inputs of the derivation. ::: [generic-builder]: https://github.com/NixOS/nixpkgs/blob/19d4f7dc485f74109bd66ef74231285ff797a823/pkgs/stdenv/generic/builder.sh #### Invocation {#patch-shebangs.sh-invocation} Multiple paths can be specified. ``` patchShebangs [--build | --host] PATH... ``` ##### Flags `--build` : Look up commands available at build time `--host` : Look up commands available at run time ##### Examples ```sh patchShebangs --host /nix/store/<hash>-hello-1.0/bin ``` ```sh patchShebangs --build configure ``` `#!/bin/sh` will be rewritten to `#!/nix/store/<hash>-some-bash/bin/sh`. `#!/usr/bin/env` gets special treatment: `#!/usr/bin/env python` is rewritten to `/nix/store/<hash>/bin/python`. Interpreter paths that point to a valid Nix store location are not changed. ::: note A script file must be marked as executable, otherwise it will not be considered. ::: This mechanism ensures that the interpreter for a given script is always found and is exactly the one specified by the build. It can be disabled by setting [`dontPatchShebangs`](#var-stdenv-dontPatchShebangs): ```nix stdenv.mkDerivation { # ... dontPatchShebangs = true; # ... } ``` The file [`patch-shebangs.sh`][patch-shebangs.sh] defines the [`patchShebangs`][patchShebangs] function. It is used to implement [`patchShebangsAuto`][patchShebangsAuto], the [setup hook](#ssec-setup-hooks) that is registered to run during the [fixup phase](#ssec-fixup-phase) by default. If you need to run `patchShebangs` at build time, it must be called explicitly within [one of the build phases](#sec-stdenv-phases). [patch-shebangs.sh]: https://github.com/NixOS/nixpkgs/blob/19d4f7dc485f74109bd66ef74231285ff797a823/pkgs/build-support/setup-hooks/patch-shebangs.sh [patchShebangs]: https://github.com/NixOS/nixpkgs/blob/19d4f7dc485f74109bd66ef74231285ff797a823/pkgs/build-support/setup-hooks/patch-shebangs.sh#L24-L105 [patchShebangsAuto]: https://github.com/NixOS/nixpkgs/blob/19d4f7dc485f74109bd66ef74231285ff797a823/pkgs/build-support/setup-hooks/patch-shebangs.sh#L107-L119 </ins> ### `audit-tmpdir.sh` {#audit-tmpdir.sh}


Question:
Project description
I marked this as stale due to inactivity. →
ping! Is this still an issue?
has been The command still does not have documentation in the Nixpkgs manual.
Is satisfying? Could use approval to get merged.
It's a good step, but it doesn't (yet?) tell me what the options are.
Now it does.

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


Question: Project description Emote is a modern emoji picker for Linux rocket. Written in GTK3, Emote is lightweight and stays out of your way. Metadata homepage URL: source URL: license: gpl3 platforms: linux

<ins> { lib, fetchFromGitHub, python3Packages, wrapGAppsHook, gobject-introspection, gtk3, keybinder3, xdotool, pango, gdk-pixbuf, atk, librsvg }: python3Packages.buildPythonApplication rec { pname = "emote"; version = "2.0.0"; src = fetchFromGitHub { owner = "tom-james-watson"; repo = "Emote"; rev = "v${version}"; sha256 = "kYXFD6VBnuEZ0ZMsF6ZmN4V0JN83puxRILpNlllVsKQ="; }; postPatch = '' substituteInPlace setup.py --replace "pygobject==3.36.0" "pygobject" substituteInPlace emote/config.py --replace 'os.environ.get("SNAP")' "'$out/share/emote'" substituteInPlace snap/gui/emote.desktop --replace "Icon=''${SNAP}/usr/share/icons/emote.svg" "Icon=emote.svg" ''; nativeBuildInputs = [ wrapGAppsHook gobject-introspection keybinder3 pango gdk-pixbuf atk ]; propagatedBuildInputs = [ python3Packages.pygobject3 gtk3 xdotool librsvg ]; postInstall = '' install -D snap/gui/emote.desktop $out/share/applications/emote.desktop install -D snap/gui/emote.svg $out/share/pixmaps/emote.svg install -D -t $out/share/emote/static static/{emojis.json,logo.svg,style.css} ''; dontWrapGApps = true; preFixup = '' makeWrapperArgs+=("''${gappsWrapperArgs[@]}") ''; doCheck = false; meta = with lib; { description = "A modern emoji picker for Linux"; homepage = "https://github.com/tom-james-watson/emote"; license = licenses.gpl3Plus; maintainers = with maintainers; [ angustrau ]; platforms = platforms.linux; }; } </ins>


Question: Project description Emote is a modern emoji picker for Linux rocket. Written in GTK3, Emote is lightweight and stays out of your way. Metadata homepage URL: source URL: license: gpl3 platforms: linux

autoreconfHook = buildPackages.autoreconfHook269; }; <ins> emote = callPackage ../tools/inputmethods/emote { }; </ins> engauge-digitizer = libsForQt5.callPackage ../applications/science/math/engauge-digitizer { }; epubcheck = callPackage ../tools/text/epubcheck { };


Question:
Looks like it is missing python3Packages.setuptools...
works for me - please provide output from
fixes that, but then you will be running into
I have informed the author of archivy, and he's looking into it.
This is because in the version requirements are loosened and an incompatible new version of flask is used to run archivy. Removing this change to the version constraints for flask would fix the problem.

<del> { lib , buildPythonApplication , fetchPypi , appdirs , attrs , beautifulsoup4 , click-plugins , elasticsearch , flask-compress , flask_login , flask_wtf , html2text , python-dotenv , python-frontmatter , requests , tinydb , validators , werkzeug , wtforms }: </del> <ins> { lib, stdenv, python3, fetchPypi }: let defaultOverrides = [ (self: super: { flask = super.flask.overridePythonAttrs (oldAttrs: rec { version = "1.1.2"; pname = "Flask"; src = super.fetchPypi { inherit pname version; sha256 = "sha256-Tvoa4tfJhlr0iYbeiuuFBL8yx/PW/ck1PTSyH0sScGA="; }; checkInputs = [ self.pytest ]; propagatedBuildInputs = with self; [ itsdangerous click werkzeug jinja2 ]; doCheck = false; }); }) (self: super: { flask_login = super.flask_login.overridePythonAttrs (oldAttrs: rec { pname = "Flask"; version = "0.5.0"; src = fetchPypi { inherit pname version; sha256 = "6d33aef15b5bcead780acc339464aae8a6e28f13c90d8b1cf9de8b549d1c0b4b"; }; doCheck = false; }); }) ]; mkOverride = attrname: version: sha256: self: super: { ${attrname} = super.${attrname}.overridePythonAttrs (oldAttrs: { inherit version; src = oldAttrs.src.override { inherit version sha256; }; }); }; py = python3.override { # Put packageOverrides at the start so they are applied after defaultOverrides packageOverrides = lib.foldr lib.composeExtensions (self: super: { }) (defaultOverrides); }; in with py.pkgs; </ins> buildPythonApplication rec { pname = "archivy";


Question:
Looks like it is missing python3Packages.setuptools...
works for me - please provide output from
fixes that, but then you will be running into
I have informed the author of archivy, and he's looking into it.
This is because in the version requirements are loosened and an incompatible new version of flask is used to run archivy. Removing this change to the version constraints for flask would fix the problem.

--replace 'validators ==' 'validators >='  --replace 'tinydb ==' 'tinydb >='  --replace 'Flask_WTF == 0.14.3' 'Flask_WTF'  <del> --replace 'Werkzeug ==' 'Werkzeug >='  --replace 'Flask ==' 'Flask >=' </del> <ins> --replace 'Werkzeug ==' 'Werkzeug >=' </ins> ''; propagatedBuildInputs = [


Question:
Looks like it is missing python3Packages.setuptools...
works for me - please provide output from
fixes that, but then you will be running into
I have informed the author of archivy, and he's looking into it.
This is because in the version requirements are loosened and an incompatible new version of flask is used to run archivy. Removing this change to the version constraints for flask would fix the problem.

python-dotenv python-frontmatter requests <ins> setuptools </ins> tinydb validators werkzeug


Question:
gPodder crashes and dumps core when trying to import an OPML file: Steps to reproduce the behavior: "Subscriptions -Import from OPML file" the crash I'm using KDE Plasma, not Gnome as a desktop, in case that's related to GSettings discovery. gdb backtrace from the coredump: <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Please run and paste the result. Maintainer information:
This crash does not appear in the flatpak verision of gPodder, so I assume it is related to our Nix packaging.
Looks like something on my system sets the right environment variable to prevent this crash: I tried to add dconf, gsettings-desktop-schemas and hicolor-icon-theme but nothing seems to be picked up by the . Maybe has a better idea? The crash only happens when I do with nix-shell.
That would be schemas from gtk3 if it crashes on trying to open file chooser.
Yeah but gtk3 is already in so something is off here with
If it is Python package, it needs strictDeps false
indeed fixes this issue, see PR
This is quite a footgun, can we disable from somehow?

glibcLocales ]; <ins> # as of 2021-07, the gobject-introspection setup hook does not # work with `strictDeps` enabled, thus for proper `wrapGAppsHook` # it needs to be disabled explicitly. https://github.com/NixOS/nixpkgs/issues/56943 strictDeps = false; </ins> buildInputs = [ python3 <ins> gtk3 </ins> gobject-introspection gnome.adwaita-icon-theme ];


Question:
gPodder crashes and dumps core when trying to import an OPML file: Steps to reproduce the behavior: "Subscriptions -Import from OPML file" the crash I'm using KDE Plasma, not Gnome as a desktop, in case that's related to GSettings discovery. gdb backtrace from the coredump: <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Please run and paste the result. Maintainer information:
This crash does not appear in the flatpak verision of gPodder, so I assume it is related to our Nix packaging.
Looks like something on my system sets the right environment variable to prevent this crash: I tried to add dconf, gsettings-desktop-schemas and hicolor-icon-theme but nothing seems to be picked up by the . Maybe has a better idea? The crash only happens when I do with nix-shell.
That would be schemas from gtk3 if it crashes on trying to open file chooser.
Yeah but gtk3 is already in so something is off here with
If it is Python package, it needs strictDeps false
indeed fixes this issue, see PR
This is quite a footgun, can we disable from somehow?

eyeD3 podcastparser html5lib <del> gtk3 </del> ]; makeFlags = [


Question:
See the : the options aren't declared by any file (it's actually , but that's stripped at some point). I think this is most likely because they are declared inside a : but I don't know the module system well enough to troubleshoot this. This was causing the unstable channel import to because of an which should be fixed by This is an issue of the module system, so pinging
fixes this, thanks for the report!

}; _module.freeformType = mkOption { <del> # Disallow merging for now, but could be implemented nicely with a `types.optionType` type = types.nullOr (types.uniq types.attrs); </del> <ins> type = types.nullOr types.optionType; </ins> internal = true; default = null; description = ''


Question:
See the : the options aren't declared by any file (it's actually , but that's stripped at some point). I think this is most likely because they are declared inside a : but I don't know the module system well enough to troubleshoot this. This was causing the unstable channel import to because of an which should be fixed by This is an issue of the module system, so pinging
fixes this, thanks for the report!

checkConfigError 'infinite recursion encountered' config.foo ./freeform-attrsOf.nix ./freeform-unstr-dep-str.nix checkConfigError 'The option .* is used but not defined' config.foo ./freeform-lazyAttrsOf.nix ./freeform-unstr-dep-str.nix checkConfigOutput '^"24"$' config.foo ./freeform-lazyAttrsOf.nix ./freeform-unstr-dep-str.nix ./define-value-string.nix <ins> # submodules in freeformTypes should have their locations annotated checkConfigOutput '/freeform-submodules.nix"$' config.fooDeclarations.0 ./freeform-submodules.nix # freeformTypes can get merged using `types.type`, including submodules checkConfigOutput '^10$' config.free.xxx.foo ./freeform-submodules.nix checkConfigOutput '^10$' config.free.yyy.bar ./freeform-submodules.nix </ins> ## types.anything # Check that attribute sets are merged recursively


Question:
See the : the options aren't declared by any file (it's actually , but that's stripped at some point). I think this is most likely because they are declared inside a : but I don't know the module system well enough to troubleshoot this. This was causing the unstable channel import to because of an which should be fixed by This is an issue of the module system, so pinging
fixes this, thanks for the report!

checkConfigError "The option .multiple. is defined multiple times" config.multiple ./raw.nix checkConfigOutput "bar" config.priorities ./raw.nix <ins> # Test that types.optionType merges types correctly checkConfigOutput '^10$' config.theOption.int ./optionTypeMerging.nix checkConfigOutput '^"hello"$' config.theOption.str ./optionTypeMerging.nix # Test that types.optionType correctly annotates option locations checkConfigError 'The option .theOption.nested. in .other.nix. is already declared in .optionTypeFile.nix.' config.theOption.nested ./optionTypeFile.nix </ins> cat <<EOF ====== module tests ====== $pass Pass


Question:
See the : the options aren't declared by any file (it's actually , but that's stripped at some point). I think this is most likely because they are declared inside a : but I don't know the module system well enough to troubleshoot this. This was causing the unstable channel import to because of an which should be fixed by This is an issue of the module system, so pinging
fixes this, thanks for the report!

<ins> { lib, options, ... }: with lib.types; { options.fooDeclarations = lib.mkOption { default = (options.free.type.getSubOptions [])._freeformOptions.foo.declarations; }; options.free = lib.mkOption { type = submodule { config._module.freeformType = lib.mkMerge [ (attrsOf (submodule { options.foo = lib.mkOption {}; })) (attrsOf (submodule { options.bar = lib.mkOption {}; })) ]; }; }; config.free.xxx.foo = 10; config.free.yyy.bar = 10; } </ins>


Question:
See the : the options aren't declared by any file (it's actually , but that's stripped at some point). I think this is most likely because they are declared inside a : but I don't know the module system well enough to troubleshoot this. This was causing the unstable channel import to because of an which should be fixed by This is an issue of the module system, so pinging
fixes this, thanks for the report!

<ins> { config, lib, ... }: { _file = "optionTypeFile.nix"; options.theType = lib.mkOption { type = lib.types.optionType; }; options.theOption = lib.mkOption { type = config.theType; default = {}; }; config.theType = lib.mkMerge [ (lib.types.submodule { options.nested = lib.mkOption { type = lib.types.int; }; }) (lib.types.submodule { _file = "other.nix"; options.nested = lib.mkOption { type = lib.types.str; }; }) ]; } </ins>


Question:
See the : the options aren't declared by any file (it's actually , but that's stripped at some point). I think this is most likely because they are declared inside a : but I don't know the module system well enough to troubleshoot this. This was causing the unstable channel import to because of an which should be fixed by This is an issue of the module system, so pinging
fixes this, thanks for the report!

<ins> { config, lib, ... }: { options.theType = lib.mkOption { type = lib.types.optionType; }; options.theOption = lib.mkOption { type = config.theType; }; config.theType = lib.mkMerge [ (lib.types.submodule { options.int = lib.mkOption { type = lib.types.int; default = 10; }; }) (lib.types.submodule { options.str = lib.mkOption { type = lib.types.str; }; }) ]; config.theOption.str = "hello"; } </ins>


Question:
See the : the options aren't declared by any file (it's actually , but that's stripped at some point). I think this is most likely because they are declared inside a : but I don't know the module system well enough to troubleshoot this. This was causing the unstable channel import to because of an which should be fixed by This is an issue of the module system, so pinging
fixes this, thanks for the report!

boolToString ; <del> inherit (lib.modules) mergeDefinitions; </del> <ins> inherit (lib.modules) mergeDefinitions fixupOptionType mergeOptionDecls ; </ins> outer_types = rec { isType = type: x: (x._type or "") == type;


Question:
See the : the options aren't declared by any file (it's actually , but that's stripped at some point). I think this is most likely because they are declared inside a : but I don't know the module system well enough to troubleshoot this. This was causing the unstable channel import to because of an which should be fixed by This is an issue of the module system, so pinging
fixes this, thanks for the report!

modules = toList modules; }; <ins> # The type of a type! optionType = mkOptionType { name = "optionType"; description = "optionType"; check = value: value._type or null == "option-type"; merge = loc: defs: let # Prepares the type definitions for mergeOptionDecls, which # annotates submodules types with file locations optionModules = map ({ value, file }: { _file = file; # There's no way to merge types directly from the module system, # but we can cheat a bit by just declaring an option with the type options = lib.mkOption { type = value; }; } ) defs; # Merges all the types into a single one, including submodule merging. # This also propagates file information to all submodules mergedOption = fixupOptionType loc (mergeOptionDecls loc optionModules); in mergedOption.type; }; </ins> submoduleWith = { modules , specialArgs ? {}


Question:
See the : the options aren't declared by any file (it's actually , but that's stripped at some point). I think this is most likely because they are declared inside a : but I don't know the module system well enough to troubleshoot this. This was causing the unstable channel import to because of an which should be fixed by This is an issue of the module system, so pinging
fixes this, thanks for the report!

should only be used when checking, merging and nested evaluation are not desirable. <ins> `types.optionType` :   The type of an option's type. Its merging operation ensures that nested options have the correct file location annotated, and that if possible, multiple option definitions are correctly merged together. The main use case is as the type of the `_module.freeformType` option. </ins> `types.attrs` :   A free-form attribute set.


Question:
See the : the options aren't declared by any file (it's actually , but that's stripped at some point). I think this is most likely because they are declared inside a : but I don't know the module system well enough to troubleshoot this. This was causing the unstable channel import to because of an which should be fixed by This is an issue of the module system, so pinging
fixes this, thanks for the report!

</varlistentry> <varlistentry> <term> <ins> <literal>types.optionType</literal> </term> <listitem> <para> The type of an option’s type. Its merging operation ensures that nested options have the correct file location annotated, and that if possible, multiple option definitions are correctly merged together. The main use case is as the type of the <literal>_module.freeformType</literal> option. </para> </listitem> </varlistentry> <varlistentry> <term> </ins> <literal>types.attrs</literal> </term> <listitem>


Question:
This project is no longer activily maintained! there is a spiritual successor, so maybe package that instead cc maintainer
I marked this as stale due to inactivity. →

<del> { lib, stdenv, fetchFromGitHub, nix-update-script, meson, ninja, pkg-config, vala, gettext, python3 , appstream-glib, desktop-file-utils, wrapGAppsHook, gnome-online-accounts , gtk3, libgee, libpeas, librest, webkitgtk, gsettings-desktop-schemas , curl, glib, gnome, gst_all_1, json-glib, libnotify, libsecret, sqlite, gumbo, libxml2 }: stdenv.mkDerivation rec { pname = "feedreader"; version = "2.11.0"; src = fetchFromGitHub { owner = "jangernert"; repo = pname; rev = "v${version}"; sha256 = "1agy1nkpkdsy2kbrrc8nrwphj5n86rikjjvwkr8klbf88mzl6civ"; }; nativeBuildInputs = [ meson ninja pkg-config vala gettext appstream-glib desktop-file-utils libxml2 python3 wrapGAppsHook ]; buildInputs = [ curl glib json-glib libnotify libsecret sqlite gumbo gtk3 libgee libpeas gnome.libsoup librest webkitgtk gsettings-desktop-schemas gnome-online-accounts ] ++ (with gst_all_1; [ gstreamer gst-plugins-base gst-plugins-good ]); postPatch = '' patchShebangs build-aux/meson_post_install.py ''; passthru = { updateScript = nix-update-script { attrPath = pname; }; }; meta = with lib; { description = "A modern desktop application designed to complement existing web-based RSS accounts"; homepage = "https://jangernert.github.io/FeedReader/"; license = licenses.gpl3Plus; maintainers = with maintainers; [ edwtjo ]; platforms = platforms.linux; }; } </del>


Question:
This project is no longer activily maintained! there is a spiritual successor, so maybe package that instead cc maintainer
I marked this as stale due to inactivity. →

fast-neural-doodle = throw "fast-neural-doodle has been removed, as the upstream project has been abandoned"; # Added 2020-03-28 fastnlo = fastnlo_toolkit; # Added 2021-04-24 fedora-coreos-config-transpiler = throw "fedora-coreos-config-transpiler has been renamed to 'butane'"; # Added 2021-04-13 <ins> feedreader = throw "feedreader is no longer activily maintained since 2019. The developer is working on a spiritual successor called NewsFlash."; # Added 2022-05-03 </ins> fetchFromGithub = throw "You meant fetchFromGitHub, with a capital H"; ffadoFull = throw "'ffadoFull' has been renamed to/replaced by 'ffado'"; # Converted to throw 2022-02-22 ffmpeg-sixel = throw "ffmpeg-sixel has been removed, because it was an outdated/unmaintained fork of ffmpeg"; # Added 2022-03-23";


Question:
This project is no longer activily maintained! there is a spiritual successor, so maybe package that instead cc maintainer
I marked this as stale due to inactivity. →

featherpad = qt5.callPackage ../applications/editors/featherpad {}; <del> feedreader = callPackage ../applications/networking/feedreaders/feedreader {}; </del> fend = callPackage ../tools/misc/fend { }; ferm = callPackage ../tools/networking/ferm { };


Question:
NixOS's wrappers for gcc also apply for gcj, which is a Java compiler. The wrappers add the flag to gcj's command line, however the Java language does not have a preprocessor, and means a different thing for gcj. This means that gcj cannot compile anything. Another issue is that gcj links to zlib by default, but does not pull zlib into the environment. This means that, even if the former issue is silenced with , compilation still wouldn't work.
A similar problem for gfortran:
I marked this as stale due to inactivity. →

''; strictDeps = true; <del> propagatedBuildInputs = [ bintools ] ++ extraTools ++ optionals cc.langD or false [ zlib ]; </del> <ins> propagatedBuildInputs = [ bintools ] ++ extraTools ++ optionals cc.langD or cc.langJava or false [ zlib ]; </ins> depsTargetTargetPropagated = optional (libcxx != null) libcxx ++ extraPackages; setupHooks = [


Question:
NixOS's wrappers for gcc also apply for gcj, which is a Java compiler. The wrappers add the flag to gcj's command line, however the Java language does not have a preprocessor, and means a different thing for gcj. This means that gcj cannot compile anything. Another issue is that gcj links to zlib by default, but does not pull zlib into the environment. This means that, even if the former issue is silenced with , compilation still wouldn't work.
A similar problem for gfortran:
I marked this as stale due to inactivity. →

+ optionalString propagateDoc '' ln -s ${cc.man} $man ln -s ${cc.info} $info <del> '' + optionalString (cc.langD or false) '' </del> <ins> '' + optionalString (cc.langD or cc.langJava or false) '' </ins> echo "-B${zlib}${zlib.libdir or "/lib/"}" >> $out/nix-support/libc-cflags ''


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: <!-- 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: 4.6.3 desired version: 4.11.2 <!-- 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.

buildGoModule rec { pname = "yq-go"; <del> version = "4.6.3"; </del> <ins> version = "4.11.2"; </ins> src = fetchFromGitHub { owner = "mikefarah"; <del> rev = "v${version}"; </del> repo = "yq"; <del> sha256 = "sha256-+qSGdskv8qUZRl7wYKn8WsgAcD8DYw1BwZnVKK6g/sI="; </del> <ins> rev = "v${version}"; sha256 = "sha256-IzsI0jS+chm/xOdL1O11qxQTstKcUeZ9YxL7RtKHBZw="; </ins> }; <del> vendorSha256 = "sha256-vpvIl1lfaziuoHs+oDEIztufH1somphiBAn6qTaQaZw="; </del> <ins> vendorSha256 = "sha256-X162NQ+NgOUbwEA6xdnuy0u18/GQLhR3zzi+TVgzMIc="; </ins> doCheck = false;


Question: After enabling the GNUnet service with , it prints a lot of errors at startup: Additionally, attempting to stop the deamon with reveals that it is apparently not even running: Please run and paste the result.

cfg = config.services.gnunet; <del> homeDir = "/var/lib/gnunet"; </del> <ins> stateDir = "/var/lib/gnunet"; </ins> <del> configFile = with cfg; pkgs.writeText "gnunetd.conf" </del> <ins> configFile = with cfg; </ins> '' [PATHS] <del> SERVICEHOME = ${homeDir} </del> <ins> GNUNET_HOME = ${stateDir} GNUNET_RUNTIME_DIR = /run/gnunet GNUNET_USER_RUNTIME_DIR = /run/gnunet GNUNET_DATA_HOME = ${stateDir}/data </ins> [ats] WAN_QUOTA_IN = ${toString load.maxNetDownBandwidth} b


Question: After enabling the GNUnet service with , it prints a lot of errors at startup: Additionally, attempting to stop the deamon with reveals that it is apparently not even running: Please run and paste the result.

users.users.gnunet = { group = "gnunet"; description = "GNUnet User"; <del> home = homeDir; createHome = true; </del> uid = config.ids.uids.gnunet; };


Question: After enabling the GNUnet service with , it prints a lot of errors at startup: Additionally, attempting to stop the deamon with reveals that it is apparently not even running: Please run and paste the result.

# so install them globally. environment.systemPackages = [ cfg.package ]; <ins> environment.etc."gnunet.conf".text = configFile; </ins> systemd.services.gnunet = { description = "GNUnet"; after = [ "network.target" ]; wantedBy = [ "multi-user.target" ]; <ins> restartTriggers = [ configFile ]; </ins> path = [ cfg.package pkgs.miniupnpc ]; <del> environment.TMPDIR = "/tmp"; serviceConfig.PrivateTmp = true; serviceConfig.ExecStart = "${cfg.package}/lib/gnunet/libexec/gnunet-service-arm -c ${configFile}"; </del> <ins> serviceConfig.ExecStart = "${cfg.package}/lib/gnunet/libexec/gnunet-service-arm -c /etc/gnunet.conf"; </ins> serviceConfig.User = "gnunet"; serviceConfig.UMask = "0007"; <del> serviceConfig.WorkingDirectory = homeDir; </del> <ins> serviceConfig.WorkingDirectory = stateDir; serviceConfig.RuntimeDirectory = "gnunet"; serviceConfig.StateDirectory = "gnunet"; </ins> }; };


Question:
When adding to and running , emacs 25 builds and fails with 4 unexpected TRAMP mode test errors: The full output contains null bytes and weird control characters that don't let me paste this into a gist easily. Is that part of the test or indicative of the problem? cc
ok... i think this will contain the build output? again if i open it in emacs there are lots of control characters. had to zip so github wouldn't complain.
I disabled for emacs25pre, for now, on my system. I hope this will be resolved upstream before next release ...
It's quite possible that tramp-related tests fail because there is no proper networking support in the build chroot, i.e. it's not possible to resolve host names or service names. Another source of trouble could be the lack of an UTF-8 capable locale in our default build environment. Anyhow, it would be really good to report those errors upstream to make sure that the next Emacs release has them fixed in one way or another.
I've been working with the Tramp author for the past several days about these failures, and we've identified that the problem is somewhere in the environment that the tests are presented with, but we don't yet know what exactly. I'm still digging into it.

mv nextstep/Emacs.app $out/Applications ''; <del> # https://github.com/NixOS/nixpkgs/issues/13573 doCheck = false; </del> meta = with stdenv.lib; { description = "GNU Emacs 25 (pre), the extensible, customizable text editor"; homepage    = http://www.gnu.org/software/emacs/;


Question:
I tried updating it, but no luck. I think the new glibc 2.23 is the reason for configure fail: I've only been able to find arch having the same issue, no patch yet. cc
This is strange. I do reproduce the build problem, but when I compile the configure test and run it myself, it succeeds (and measures bytes). (Of course I do compile it with the stdenv from 16.03.)
Comments on note a workaround.
Temporary workaround on arch:
Fixed then?
FYI the fix to Xen build system is committed. See ;a=commit;h=

# TODO add plugins having various licenses, see http://www.vamp-plugins.org/download.html <del> { stdenv, fetchurl, alsaLib, bzip2, fftw, jackaudio, libX11, liblo, libmad, libogg, librdf, librdf_raptor, librdf_rasqal, libsamplerate, libsndfile, makeWrapper, pulseaudio, qt4, redland, rubberband, vampSDK </del> <ins> { stdenv, fetchurl, alsaLib, bzip2, fftw, jackaudio, libX11, liblo , libmad, libogg, librdf, librdf_raptor, librdf_rasqal, libsamplerate , libsndfile, makeWrapper, pkgconfig, pulseaudio, qt4, redland , rubberband, vampSDK </ins> }: <del> stdenv.mkDerivation { name = "sonic-visualiser-1.8"; </del> <ins> stdenv.mkDerivation rec { name = "sonic-visualiser-${version}"; version = "1.9"; </ins> src = fetchurl { <del> url = http://downloads.sourceforge.net/sv1/sonic-visualiser-1.8.tar.gz; sha256 = "16ik6q9n92wljvnqcv7hyzb9v3yp3ixxp6df9kasf53fii973dh7"; </del> <ins> url = "http://code.soundsoftware.ac.uk/attachments/download/194/${name}.tar.gz"; sha256 = "00igf7j6s8xfyxnlkbqma0yby9pknxqzy8cmh0aw95ix80cw56fq"; </ins> }; buildInputs = [ libsndfile qt4 fftw /* should be fftw3f ??*/ bzip2 librdf rubberband libsamplerate vampSDK alsaLib librdf_raptor librdf_rasqal redland <ins> pkgconfig </ins> # optional jackaudio # portaudio


Question:
I tried updating it, but no luck. I think the new glibc 2.23 is the reason for configure fail: I've only been able to find arch having the same issue, no patch yet. cc
This is strange. I do reproduce the build problem, but when I compile the configure test and run it myself, it succeeds (and measures bytes). (Of course I do compile it with the stdenv from 16.03.)
Comments on note a workaround.
Temporary workaround on arch:
Fixed then?
FYI the fix to Xen build system is committed. See ;a=commit;h=

description = "View and analyse contents of music audio files"; homepage = http://www.sonicvisualiser.org/; license = "GPLv2"; <del> maintainers = [ stdenv.lib.maintainers.marcweber stdenv.lib.maintainers.goibhniu ]; </del> <ins> maintainers = [ stdenv.lib.maintainers.marcweber stdenv.lib.maintainers.goibhniu ]; </ins> platforms = stdenv.lib.platforms.linux; }; }


Question:
I want to use the TTS Mimic on a Debian 11. After installation, I Tried reading a text. Cli usage give me an "alsa lib error". Steps to reproduce the behavior: -env -iA -t "hello world" A clear and concise description of what you expected to happen. If applicable, add screenshots to help explain your problem. Add any other context about the problem here. Please run and paste the result. Maintainer information:
works perfectly on NixOS 21.05. Can you elaborate more about your sound setup? While geared toward NixOS, this thread might give useful information to debug further: Also try running ALSA tools or CLI audio applications natively from Debian and via to observe any differences in behaviour.
The above works for me too on NixOS, at least. I'm not familiar with how ALSA and PulseAudio in nixpkgs integrate with non-NixOS systems; perhaps a thread on Discourse might be of more help.
I was able to reproduce your issue on Ubuntu 20.04. It seems this is . A few workarounds are mentioned in the linked issue.
It seems mimic just needs a proper wrapper: should give you some output.
Ok, I found a solution with inspiration. alsa-lib-1.2.4 doesn't containt but if i installed alsaPlugin (nix-build -A alsaPlugins '<nixpkgs'), this works for me : However, not really user friendly.

<del> { config, lib, stdenv, autoreconfHook, fetchFromGitHub, pkg-config , alsa-lib, libtool, icu </del> <ins> { config, lib, stdenv, autoreconfHook, fetchFromGitHub, pkg-config, makeWrapper , alsa-lib, alsa-plugins, libtool, icu, pcre2 </ins> , pulseaudioSupport ? config.pulseaudio or false, libpulseaudio }: stdenv.mkDerivation rec { pname = "mimic"; <del> version = "1.2.0.2"; </del> <ins> version = "1.3.0.1"; </ins> src = fetchFromGitHub { rev = version; <del> repo = "mimic"; </del> <ins> repo = "mimic1"; </ins> owner = "MycroftAI"; <del> sha256 = "1wkpbwk88lsahzkc7pzbznmyy0lc02vsp0vkj8f1ags1gh0lc52j"; </del> <ins> sha256 = "1agwgby9ql8r3x5rd1rgx3xp9y4cdg4pi3kqlz3vanv9na8nf3id"; </ins> }; nativeBuildInputs = [ autoreconfHook pkg-config <ins> makeWrapper </ins> ]; buildInputs = [ alsa-lib <ins> alsa-plugins </ins> libtool icu <ins> pcre2 </ins> ] ++ lib.optional pulseaudioSupport libpulseaudio; <ins> postInstall = '' wrapProgram $out/bin/mimic  --run "export ALSA_PLUGIN_DIR=${alsa-plugins}/lib/alsa-lib" ''; </ins> meta = { description = "Mycroft's TTS engine, based on CMU's Flite (Festival Lite)"; homepage = "https://mimic.mycroft.ai/";


Question: Project description A cross-platform TUI database management tool written in Rust Metadata homepage URL: source URL: license: mit platforms: unix

<ins> { lib, rustPlatform, fetchFromGitHub }: rustPlatform.buildRustPackage rec { pname = "gobang"; version = "0.1.0-alpha.5"; src = fetchFromGitHub { owner = "tako8ki"; repo = pname; rev = "v${version}"; sha256 = "02glb3hlprpdc72ji0248a7g0vr36yxr0gfbbms2m25v251dyaa6"; }; cargoSha256 = "sha256-Tiefet5gLpiuYY6Scg5fjnaPiZfVl5Gy2oZFdhgNRxY="; meta = with lib; { description = "A cross-platform TUI database management tool written in Rust"; homepage = "https://github.com/tako8ki/gobang"; license = licenses.mit; maintainers = with maintainers; [ figsoda ]; }; } </ins>


Question: Project description A cross-platform TUI database management tool written in Rust Metadata homepage URL: source URL: license: mit platforms: unix

go-junit-report = callPackage ../development/tools/go-junit-report { }; <ins> gobang = callPackage ../development/tools/database/gobang { }; </ins> gogetdoc = callPackage ../development/tools/gogetdoc { }; gox = callPackage ../development/tools/gox { };


Question:
After upgrading to Firefox 92 on NixOS unstable, anything that requires a menu or a tooltip in the browser (hamburger menu, right click context menus, tooltips on tabs, etc.) stopped working. The menu itself isn't rendered, the whole UI freezes and sometimes the cursor changes to a hand, indicating a clickable button, but nothing happens when clicking where the button should be. Clicking outside the area where the menu should appear restores Firefox to a usable state, until another menu button is pressed. Steps to reproduce the behavior: Firefox the hamburger menu button on the top right corner The main settings menu for Firefox should appear. The hamburger button remains in a "clicked" state and the entire UI freezes, the mouse cursor might change to a hand, but no menu is rendered. Running Firefox on Sway with and Maintainer information:
I can reproduce this too, but I don't think it's NixOS' fault; we ought to report this upstream to sway and Firefox.
You can manually apply this patch to firefox to fix the issue: I'm testing that now.
~You should be able to use this overlay to work around the issue for now:~ This partially fixes it
Alright, this overlay fully fixes the issues while we wait on a new release: I'm going to make a PR adding this to our pkg for now.
The two patches applied, menus and form overlays are visible again and the freezing is gone. Thank you
Unfortunately, it seems the fix has not worked for me. It may be due to using the home-manager module; however, I have overriden its to use the patched version and the only noticeable difference is that now a tiny vertical line appears where the context menus should be. The freezing caused by it and the fact that the menu itself is still unusable are still present, though.
There were multiple similar bugs, perhaps?
As a data point: I'm running Firefox 92.0 with the above mentioned patches on Sway on NixOS unstable and everything works great.
Do you happen to use the home-manager module or do you run Firefox as a regular system package? That may be a differentiating factor and may point towards an issue with my home-manager configuration instead.
Through home-manager.
I have tried to add your method of explicitly wrapping the package and yet, the same behavior remains, unfortunately:
I wonder if this could differ based on GPU model. (different rendering code paths on driver side)
Interesting. It is working for me on amdgpu, but I saw the issue yesterday on an i915 gpu, didn't investigate much, whether the patch already made it onto the unstable channel.
Yes, it is in already but not in yet.
I have tested this on amdgpu, nouveau, and i915 without problems. I'm wondering whether is actually using the patched version? Try to clone the repo, do and see if it works correctly. Alternatively, this should give you a firefox with the patch so you can make sure:
Ah, I managed to reproduce it on i915 now. It's not immediate for me, after a bit the menus seem to break. Amazing.
Maybe we also need this GTK patch:
Also worth trying:
Interestingly, the firefox-unwrapped package in my system has a different hash, namely . Compiling from the nixpkgs repo as you suggested does give me the version with the hash as you stated, and this version does behave correctly in regards to the menus. Something really strange is happening with my system updates then. Adding to this, I only got the version with the "black vertical line" as I described above (I attached a screenshot for reference) after I garbage collected a few generations of testing, which really shouldn't happen if I'm understanding the way nix works correctly. In any case, this is not an issue related to the Firefox package itself. !
I successfully have this working with firefox from mozilla's pkgs.
So I was able to fix this by removing the package from my home-manager config and adding it to my nixos-config. Not sure if this helps anyone here debug the issue, but it's worth a look. EDIT: Well, menus are fixed. Tooltips are still messed up.
I've been running Firefox out of a local nixpkgs build but I haven't tried messing around with the system config yet since then, I'll try your suggestion. One thing of note is that some sites' dropdown boxes are still broken, even with the patches, while everything else has been working fine.
I don't know what exactly is wrong but I am getting the random flickers on Firefox 93 as well. Has anybody found a solution?
I still get this issue sometimes. It's odd because it's very hit-or-miss for me; restarting Firefox often fixes it, and restarting it again results in it being "broken" again. The same thing happened for a long time with the screenshot tool in Firefox: sometimes it works, sometimes it doesn't, and restarting Firefox sometimes "toggles" if it does or doesn't work. I haven't been able to debug any further, though.
I haven't experienced this issue anymore since Firefox 93; both the Bugzilla issue and the GTK merge request report this issue as fixed, does anyone else still have this problem?
Can you share your exact config related to Firefox so that I can try it? Last time I checked I still had the same problems in 93.
In , add to the list of packages. Then, in : EDIT: shouldn't make a difference, but for completeness' sake, I also have this in :
Thanks! Do you use any environment variables such as ?
I actually didn't use that, but maybe I should. is set by using the package.
Oh no. The flickers are still here for me with the following config.
That is troubling... might it be a GPU-related issue?
I marked this as stale due to inactivity. →
I think this can be closed as it has been fixed for me since 94 or something.

sha256 = "0qc62di5823r7ly2lxkclzj9rhg2z7ms81igz44nv0fzv3dszdab"; }) <ins> # These fix Firefox on sway and other non-Gnome wayland WMs. They should be # removed whenever the following two patches make it onto a release: # 1. https://hg.mozilla.org/mozilla-central/rev/51c13987d1b8 # 2. https://hg.mozilla.org/integration/autoland/rev/3b856ecc00e4 # This will probably happen in the next point release, but let's be careful # and double check whether it's working on sway on the next v bump. ++ lib.optionals (lib.versionAtLeast version "92") [ (fetchpatch { url = "https://hg.mozilla.org/integration/autoland/raw-rev/3b856ecc00e4"; sha256 = "sha256-d8IRJD6ELC3ZgEs1ES/gy2kTNu/ivoUkUNGMEUoq8r8="; }) (fetchpatch { url = "https://hg.mozilla.org/mozilla-central/raw-rev/51c13987d1b8"; sha256 = "sha256-C2jcoWLuxW0Ic+Mbh3UpEzxTKZInljqVdcuA9WjspoA="; }) ] </ins> ++ patches;


Question:
Currently we have two expressions that both build the kernel, whose only interface differences are in whether or not the .config is generated or provided. These builds should be merged with the two different interfaces simply being two ways to call the same underlying function, reducing code duplication and allowing the generic kernel builds to benefit from the IMO better structure of the newer manual kernel builds.
+1 on getting rid of duplication What is the "better structure"?
Structure may have been the wrong word, but the manual kernel build uses multiple outputs (suboptimally currently, which was part of the problem with the old PR) and uses the official kernel build system for building and installing, while the generic one (last I checked) had a manually maintained shell script to handle the install and parts of the build.
Fixed by

in assert lib.all (p: p.enabled -> ! (builtins.elem null p.buildInputs)) plugins; stdenv.mkDerivation rec { <del> version = "2.6"; </del> <ins> version = "2.7"; </ins> pname = "weechat"; src = fetchurl { url = "https://weechat.org/files/src/weechat-${version}.tar.bz2"; <del> sha256 = "1narazk28m7lmn1vqi7bhyvnr8apjrmaa4w1hbadn64hwr8ya1hb"; </del> <ins> sha256 = "00hzchzw1w2181kczcrrnj8ngml3bwk7qciha3higxq3qynf0h8c"; </ins> }; outputs = [ "out" "man" ] ++ map (p: p.name) enabledPlugins;


Question:
Currently we have two expressions that both build the kernel, whose only interface differences are in whether or not the .config is generated or provided. These builds should be merged with the two different interfaces simply being two ways to call the same underlying function, reducing code duplication and allowing the generic kernel builds to benefit from the IMO better structure of the newer manual kernel builds.
+1 on getting rid of duplication What is the "better structure"?
Structure may have been the wrong word, but the manual kernel build uses multiple outputs (suboptimally currently, which was part of the problem with the old PR) and uses the official kernel build system for building and installing, while the generic one (last I checked) had a manually maintained shell script to handle the install and parts of the build.
Fixed by

cmakeFlags = with stdenv.lib; [ "-DENABLE_MAN=ON" "-DENABLE_DOC=ON" <ins> "-DENABLE_JAVASCRIPT=OFF"  # Requires v8 <= 3.24.3, https://github.com/weechat/weechat/issues/360 "-DENABLE_PHP=OFF" </ins> ] ++ optionals stdenv.isDarwin ["-DICONV_LIBRARY=${libiconv}/lib/libiconv.dylib" "-DCMAKE_FIND_FRAMEWORK=LAST"] ++ map (p: "-D${p.cmakeFlag}=" + (if p.enabled then "ON" else "OFF")) plugins


Question:
Currently we have two expressions that both build the kernel, whose only interface differences are in whether or not the .config is generated or provided. These builds should be merged with the two different interfaces simply being two ways to call the same underlying function, reducing code duplication and allowing the generic kernel builds to benefit from the IMO better structure of the newer manual kernel builds.
+1 on getting rid of duplication What is the "better structure"?
Structure may have been the wrong word, but the manual kernel build uses multiple outputs (suboptimally currently, which was part of the problem with the old PR) and uses the official kernel build system for building and installing, while the generic one (last I checked) had a manually maintained shell script to handle the install and parts of the build.
Fixed by

in assert lib.all (p: p.enabled -> ! (builtins.elem null p.buildInputs)) plugins; stdenv.mkDerivation rec { <del> version = "2.6"; </del> <ins> version = "2.7.1"; </ins> pname = "weechat"; src = fetchurl { url = "https://weechat.org/files/src/weechat-${version}.tar.bz2"; <del> sha256 = "1narazk28m7lmn1vqi7bhyvnr8apjrmaa4w1hbadn64hwr8ya1hb"; </del> <ins> sha256 = "0acz41jg7lmipni9z2agfqw4dhmx5hf6k9w4pvr4zih1fhkldva2"; </ins> }; outputs = [ "out" "man" ] ++ map (p: p.name) enabledPlugins;


Question:
Currently we have two expressions that both build the kernel, whose only interface differences are in whether or not the .config is generated or provided. These builds should be merged with the two different interfaces simply being two ways to call the same underlying function, reducing code duplication and allowing the generic kernel builds to benefit from the IMO better structure of the newer manual kernel builds.
+1 on getting rid of duplication What is the "better structure"?
Structure may have been the wrong word, but the manual kernel build uses multiple outputs (suboptimally currently, which was part of the problem with the old PR) and uses the official kernel build system for building and installing, while the generic one (last I checked) had a manually maintained shell script to handle the install and parts of the build.
Fixed by


Question:
Practical consequence: with (this log snippet is cleaner thanks to ) I checked that it really is the patch by applying Some bugs are discussed in the upstream ML thread: I'm not sure about the best approach for us so far; the rebuild amounts complicate this. Perhaps just temporarily fixup the kernel build and get a properly fixed cpio with the next iteration? I expect that three to five upstream commits will be needed; maybe just the whole diff since the last release.
I think we should just fix this in master; the channel isn't going to advance anyway, and I'd rather not ship a known-buggy version of by fixing just the cpio used by the kernel. Is that reasonable?
Maybe the current channel version with public code-execution exploit (linked above) is a worse bug than this, but I don't know how commonly this bug manifests. ( channel has advanced, by the way)

{ lib, stdenv, fetchurl, fetchpatch }: <del> let </del> <ins> stdenv.mkDerivation rec { pname = "cpio"; </ins> version = "2.13"; <del> name = "cpio-${version}"; in stdenv.mkDerivation { inherit name; </del> src = fetchurl { <del> url = "mirror://gnu/cpio/${name}.tar.bz2"; </del> <ins> url = "mirror://gnu/cpio/cpio-${version}.tar.bz2"; </ins> sha256 = "0vbgnhkawdllgnkdn6zn1f56fczwk0518krakz2qbwhxmv2vvdga"; }; <del> patches = [ (fetchpatch { name = "CVE-2021-38185.patch"; url = "https://git.savannah.gnu.org/cgit/cpio.git/patch/?id=dd96882877721703e19272fe25034560b794061b"; sha256 = "0vmr0qjwj2ldnzsvccl105ckwgx3ssvn9mp3f27ss0kiyigrzz32"; }) </del> <ins> patches = let fp = suffix: rev: sha256: fetchpatch { name = "CVE-2021-38185-${suffix}.patch"; url = "https://git.savannah.gnu.org/cgit/cpio.git/patch/?id=${rev}"; inherit sha256; }; in [ (fp "1" "dd96882877721703e19272fe25034560b794061b" "0vmr0qjwj2ldnzsvccl105ckwgx3ssvn9mp3f27ss0kiyigrzz32") (fp "2" "dfc801c44a93bed7b3951905b188823d6a0432c8" "1qkrhi3lbxk6hflp6w3h4sgssc0wblv8r0qgxqzbjrm36pqwxiwh") (fp "3" "236684f6deb3178043fe72a8e2faca538fa2aae1" "0pidkbxalpj5yz4fr95x8h0rizgjij0xgvjgirfkjk460giawwg6") </ins> ]; <del> preConfigure = if stdenv.isCygwin then '' </del> <ins> preConfigure = lib.optionalString stdenv.isCygwin '' </ins> sed -i gnu/fpending.h -e 's,include <stdio_ext.h>,,' <del> '' else null; </del> <ins> ''; </ins> enableParallelBuilding = true;


Question:
fails to build as There is an invasive change that fixed it in newer version: . But maybe it's a good time to remove old version? Maintainer information:
Started with commit
Is there a reason to still keep Ardour 5.x in nixpkgs? Edit: The reads: Is that still the case ?
Yes it is, but I'm not sure it's worth the effort to fix Ardour 5.
I prepared a PR which drops ardour_5 if we decide to go this way:

<del> { lib, stdenv , fetchgit , alsa-lib , aubio , boost , cairomm , curl , doxygen , fftwSinglePrec , flac , glibmm , graphviz , gtkmm2 , libjack2 , liblo , libogg , libsamplerate , libsigcxx , libsndfile , libusb1 , fluidsynth_1 , hidapi , libltc , qm-dsp , libxml2 , lilv , lrdf , lv2 , perl , pkg-config , itstool , python2 , rubberband , serd , sord , sratom , taglib , vamp-plugin-sdk , dbus , fftw , pango , suil , libarchive , wafHook }: let # Ardour git repo uses a mix of annotated and lightweight tags. Annotated # tags are used for MAJOR.MINOR versioning, and lightweight tags are used # in-between; MAJOR.MINOR.REV where REV is the number of commits since the # last annotated tag. A slightly different version string format is needed # for the 'revision' info that is built into the binary; it is the format of # "git describe" when _not_ on an annotated tag(!): MAJOR.MINOR-REV-HASH. # Version to build. tag = "5.12"; in stdenv.mkDerivation rec { pname = "ardour_5"; version = "5.12"; src = fetchgit { url = "git://git.ardour.org/ardour/ardour.git"; rev = "ae0dcdc0c5d13483271065c360e378202d20170a"; sha256 = "0mla5lm51ryikc2rrk53max2m7a5ds6i1ai921l2h95wrha45nkr"; }; nativeBuildInputs = [ wafHook pkg-config itstool doxygen graphviz # for dot perl python2 ]; buildInputs = [ alsa-lib aubio boost cairomm curl dbus fftw fftwSinglePrec flac glibmm gtkmm2 libjack2 liblo libogg libsamplerate libsigcxx libsndfile libusb1 fluidsynth_1 hidapi libltc qm-dsp libxml2 lilv lrdf lv2 pango rubberband serd sord sratom suil taglib vamp-plugin-sdk libarchive ]; wafConfigureFlags = [ "--optimize" "--docs" "--use-external-libs" "--freedesktop" "--with-backends=jack,alsa,dummy" ]; NIX_CFLAGS_COMPILE = "-I${qm-dsp}/include/qm-dsp"; # ardour's wscript has a "tarball" target but that required the git revision # be available. Since this is an unzipped tarball fetched from github we # have to do that ourself. postPatch = '' printf '#include "libs/ardour/ardour/revision.h"nnamespace ARDOUR { const char* revision = "${tag}-${builtins.substring 0 8 src.rev}"; }n' > libs/ardour/revision.cc patchShebangs ./tools/ ''; postInstall = '' # wscript does not install these for some reason install -vDm 644 "build/gtk2_ardour/ardour.xml"  -t "$out/share/mime/packages" install -vDm 644 "build/gtk2_ardour/ardour5.desktop"  -t "$out/share/applications" for size in 16 22 32 48 256 512; do install -vDm 644 "gtk2_ardour/resources/Ardour-icon_''${size}px.png"  "$out/share/icons/hicolor/''${size}x''${size}/apps/ardour5.png" done install -vDm 644 "ardour.1"* -t "$out/share/man/man1" ''; meta = with lib; { description = "Multi-track hard disk recording software"; longDescription = '' Ardour is a digital audio workstation (DAW), You can use it to record, edit and mix multi-track audio and midi. Produce your own CDs. Mix video soundtracks. Experiment with new ideas about music and sound. Please consider supporting the ardour project financially: https://community.ardour.org/donate ''; homepage = "https://ardour.org/"; license = licenses.gpl2; platforms = platforms.linux; maintainers = with maintainers; [ goibhniu fps ]; }; } </del>


Question:
fails to build as There is an invasive change that fixed it in newer version: . But maybe it's a good time to remove old version? Maintainer information:
Started with commit
Is there a reason to still keep Ardour 5.x in nixpkgs? Edit: The reads: Is that still the case ?
Yes it is, but I'm not sure it's worth the effort to fix Ardour 5.
I prepared a PR which drops ardour_5 if we decide to go this way:

amsn = throw "amsn has been removed due to being unmaintained."; # added 2020-12-09 antimicro = throw "antimicro has been removed as it was broken, see antimicroX instead."; # added 2020-08-06 arduino_core = arduino-core;  # added 2015-02-04 <ins> ardour_5 = throw "ardour_5 has been removed. see https://github.com/NixOS/nixpkgs/issues/139549"; # added 2021-09-28 </ins> arora = throw "arora has been removed."; # added 2020-09-09 asciidocFull = asciidoc-full;  # added 2014-06-22 asterisk_15 = throw "asterisk_15: Asterisk 15 is end of life and has been removed."; # added 2020-10-07


Question:
fails to build as There is an invasive change that fixed it in newer version: . But maybe it's a good time to remove old version? Maintainer information:
Started with commit
Is there a reason to still keep Ardour 5.x in nixpkgs? Edit: The reads: Is that still the case ?
Yes it is, but I'm not sure it's worth the effort to fix Ardour 5.
I prepared a PR which drops ardour_5 if we decide to go this way:

ardour = callPackage ../applications/audio/ardour { }; <del> ardour_5 = lowPrio (callPackage ../applications/audio/ardour/5.nix { }); </del> arelle = with python3Packages; toPythonApplication arelle; argo = callPackage ../applications/networking/cluster/argo { };


Question:
insync-v3 server doesn't seem to start. See that there is no insync process running. Please run and paste the result.
I believe this is caused by the Insync binaries expecting specific versions of some system libraries like glib. A similar problem has been reported on the Insync forums by a few Gentoo users. See and Since Insync releases are pegged to Ubuntu/Debian/Fedora releases, I'm not sure there's a good fix for this. Fortunately, I was able to get insync v3 working in a nix-shell environment that is pinned to an earlier commit of nixpkgs (). I uploaded a reproducible flake here: The system icon shows up as a red circle, and native Wayland support doesn't work, but it seems fully functional other than that.
Using nixpkgs pinned at , I've been able to successfully run insync version (the version currently in nixpkgs) and version (latest available version). This suggests that there was an update elsewhere in nixpkgs that wasn't backwards-compatible with insync. Pinning nixpkgs works for now, but it's not a long-term fix. Maybe we can try to identify which libraries need to be pinned and explicitly pin those? Or maybe use binaries targeting a distribution which is more up-to-date?
I've noticed this as well a while ago, and even figured out what the issue was, but was too lazy to report it until now. Sorry about that. When you run it should tell you why it can't start. In my case it had some issues harfbuzz, which most likely comes from the upgrate to version 3 . Harfbuzz removed some functions that were not officially documented, but are used by qt webview, which is why it fails. I think this is going to be fixed automatically at some point with either an insync update or an update of qt webview in nixpkgs. But until then, your best bet is to use insync from an older nixpkgs commit. It might even be a better idea to completely remove insync from nixpkgs and providing it as a flake, that has a working nixpkgs version pinned to it.
For me just produces :(
Hi how can I test this pinned version? Thanks!
Any fix for this? insync start --no-daemon Traceback (most recent call last): File "", line 19, in <moduleFile "site-", line 829, in call File "site-", line 782, in main File "site-", line 1259, in invoke File "site-", line 1066, in invoke File "site-", line 610, in invoke File "", line 87, in start File "/usr/local/lib/python3.7/site-", line 627, in execmodule File "", line 11, in <moduleFile "/usr/local/lib/python3.7/site-", line 627, in execmodule File "", line 7, in <moduleImportError: /nix/store/41ms51yaqhqwfp83z8dms55g4abfzihp-insync- version `GLIBCXX3.4.29' not found (required by /nix/store/z8hz4nlh48niad995hs4w33wwryc3lkr-qtbase-) [2847] Failed to execute script insync
I'm afraid it has been a while since I used Insync because I couldn't find a fix for this type of issue. Instead I have been using which is
I reached out to insync back when I made my last post and begged them to look into the issue. I offered to pay for a fix. I was told it was to the developer backlog. I've switched to using .
Yeah, it is frustrating that the Insync developers don't seem to be interested in providing a distro-agnostic version of their product. A flatpak or appimage distribution of insync seems like it should be an obvious win for them, but they haven't committed to anything. Here's hoping; I liked using Insync when I was able to.
are you achieving continuous (real-time) sync with those tools? Neither of the two tools supports that by itself , . If you're achieving it by using the tool as part of a more elaborate solution, would you mind sharing how you're doing that?
I wrote an overlay to pass by the error 403 of url down and I get it installed. But doesn't open yet The error:
Update about . It worked when i pinned a rev from github. To fix the broken URL I created an overlay to override the version and URL of current version on nixpkgs.
I am trying to fix it for the latest insync binary... But it doesn't work, it crashes, badly If I don't do these: Insync will crash with: Something about GLIBC_2.36, while nixos is still at glibc 2.35. But it shouldn't be a issue, otherwise insync would only work for distro that is glibc 2.35... Hope it gives some hints, if anyone wants to continue from here, feel free!
I made build and insync-v3 run again, but it would need to patch two more python packages... to continued.
Update from , the package should be resuscitated soon, coming to unstable and hopefully in time for 23.05!
thank you for persevering on this and getting insync working again!
thanks for this package! Could you also please add the .desktop file and icons? The base insync package has them but they are not to the wrapper package and are not currently user visible. Thanks again!
Also the insync binary is currently named insync-${version}. Can you please strip the version from the binary name? Otherwise the desktop file won't work. Thanks!
No problems. I will look into these!
Might have the desktop files solved.

<del> { lib, stdenv, fetchurl, makeWrapper, autoPatchelfHook }: </del> <ins> { lib , writeShellScript , buildFHSEnv , stdenv , fetchurl , autoPatchelfHook , dpkg , nss , libvorbis , libdrm , libGL , wayland , libthai }: </ins> <del> stdenv.mkDerivation rec { </del> <ins> let </ins> pname = "insync"; <del> version = "1.5.7.37371"; src = if stdenv.hostPlatform.system == "x86_64-linux" then fetchurl { url = "http://s.insynchq.com/builds/insync-portable_${version}_amd64.tar.bz2"; sha256 = "1cm3q6y2crw6pcsvh21sbkmh1hin7xl4fyslc96nbyql8rxsky5n"; } else throw "${pname}-${version} is not supported on ${stdenv.hostPlatform.system}"; nativeBuildInputs = [ makeWrapper autoPatchelfHook ]; postPatch = '' patchelf --interpreter "$(cat $NIX_CC/nix-support/dynamic-linker)" client/insync-portable ''; installPhase = '' mkdir -p $out/bin cp -a client $out/client makeWrapper $out/client/insync-portable $out/bin/insync --set LC_TIME C ''; meta = { </del> <ins> version = "3.8.5.50499"; meta = with lib; { </ins> platforms = ["x86_64-linux"]; sourceProvenance = with lib.sourceTypes; [ binaryNativeCode ]; <del> license = lib.licenses.unfree; maintainers = [ ]; </del> <ins> license = licenses.unfree; maintainers = with maintainers; [ hellwolf ]; </ins> homepage = "https://www.insynchq.com"; description = "Google Drive sync and backup with multiple account support"; longDescription = ''


Question:
insync-v3 server doesn't seem to start. See that there is no insync process running. Please run and paste the result.
I believe this is caused by the Insync binaries expecting specific versions of some system libraries like glib. A similar problem has been reported on the Insync forums by a few Gentoo users. See and Since Insync releases are pegged to Ubuntu/Debian/Fedora releases, I'm not sure there's a good fix for this. Fortunately, I was able to get insync v3 working in a nix-shell environment that is pinned to an earlier commit of nixpkgs (). I uploaded a reproducible flake here: The system icon shows up as a red circle, and native Wayland support doesn't work, but it seems fully functional other than that.
Using nixpkgs pinned at , I've been able to successfully run insync version (the version currently in nixpkgs) and version (latest available version). This suggests that there was an update elsewhere in nixpkgs that wasn't backwards-compatible with insync. Pinning nixpkgs works for now, but it's not a long-term fix. Maybe we can try to identify which libraries need to be pinned and explicitly pin those? Or maybe use binaries targeting a distribution which is more up-to-date?
I've noticed this as well a while ago, and even figured out what the issue was, but was too lazy to report it until now. Sorry about that. When you run it should tell you why it can't start. In my case it had some issues harfbuzz, which most likely comes from the upgrate to version 3 . Harfbuzz removed some functions that were not officially documented, but are used by qt webview, which is why it fails. I think this is going to be fixed automatically at some point with either an insync update or an update of qt webview in nixpkgs. But until then, your best bet is to use insync from an older nixpkgs commit. It might even be a better idea to completely remove insync from nixpkgs and providing it as a flake, that has a working nixpkgs version pinned to it.
For me just produces :(
Hi how can I test this pinned version? Thanks!
Any fix for this? insync start --no-daemon Traceback (most recent call last): File "", line 19, in <moduleFile "site-", line 829, in call File "site-", line 782, in main File "site-", line 1259, in invoke File "site-", line 1066, in invoke File "site-", line 610, in invoke File "", line 87, in start File "/usr/local/lib/python3.7/site-", line 627, in execmodule File "", line 11, in <moduleFile "/usr/local/lib/python3.7/site-", line 627, in execmodule File "", line 7, in <moduleImportError: /nix/store/41ms51yaqhqwfp83z8dms55g4abfzihp-insync- version `GLIBCXX3.4.29' not found (required by /nix/store/z8hz4nlh48niad995hs4w33wwryc3lkr-qtbase-) [2847] Failed to execute script insync
I'm afraid it has been a while since I used Insync because I couldn't find a fix for this type of issue. Instead I have been using which is
I reached out to insync back when I made my last post and begged them to look into the issue. I offered to pay for a fix. I was told it was to the developer backlog. I've switched to using .
Yeah, it is frustrating that the Insync developers don't seem to be interested in providing a distro-agnostic version of their product. A flatpak or appimage distribution of insync seems like it should be an obvious win for them, but they haven't committed to anything. Here's hoping; I liked using Insync when I was able to.
are you achieving continuous (real-time) sync with those tools? Neither of the two tools supports that by itself , . If you're achieving it by using the tool as part of a more elaborate solution, would you mind sharing how you're doing that?
I wrote an overlay to pass by the error 403 of url down and I get it installed. But doesn't open yet The error:
Update about . It worked when i pinned a rev from github. To fix the broken URL I created an overlay to override the version and URL of current version on nixpkgs.
I am trying to fix it for the latest insync binary... But it doesn't work, it crashes, badly If I don't do these: Insync will crash with: Something about GLIBC_2.36, while nixos is still at glibc 2.35. But it shouldn't be a issue, otherwise insync would only work for distro that is glibc 2.35... Hope it gives some hints, if anyone wants to continue from here, feel free!
I made build and insync-v3 run again, but it would need to patch two more python packages... to continued.
Update from , the package should be resuscitated soon, coming to unstable and hopefully in time for 23.05!
thank you for persevering on this and getting insync working again!
thanks for this package! Could you also please add the .desktop file and icons? The base insync package has them but they are not to the wrapper package and are not currently user visible. Thanks again!
Also the insync binary is currently named insync-${version}. Can you please strip the version from the binary name? Otherwise the desktop file won't work. Thanks!
No problems. I will look into these!
Might have the desktop files solved.

and built in sharing. There is a 15-day free trial, and it is a paid application after that. <ins> Known bug(s): 1) Currently the system try icon does not render correctly. 2) libqtvirtualkeyboardplugin does not have necessary Qt library shipped from vendor. ''; }; insync-pkg = stdenv.mkDerivation { inherit pname version; src = fetchurl { # Find a binary from https://www.insynchq.com/downloads/linux#ubuntu. url = "https://cdn.insynchq.com/builds/linux/${pname}_${version}-lunar_amd64.deb"; sha256 = "sha256-mpMJe8LAmO9OrqRIEWuxfVNeh5ANvjZIEHFz8cXYObY="; }; buildInputs = [ nss libvorbis libdrm libGL wayland libthai ]; nativeBuildInputs = [ autoPatchelfHook dpkg ]; unpackPhase = '' dpkg-deb --fsys-tarfile $src | tar -x --no-same-permissions --no-same-owner ''; installPhase = '' runHook preInstall mkdir -p $out/bin $out/lib $out/share cp -R usr/* $out/ # use system glibc rm -f $out/lib/insync/{libgcc_s.so.1,libstdc++.so.6} # remove badly packaged plugins rm $out/lib/insync/PySide2/plugins/platforminputcontexts/libqtvirtualkeyboardplugin.so runHook postInstall </ins> ''; <del> # download URL removed broken = true; </del> <ins> dontConfigure = true; dontBuild = true; # NB! This did the trick, otherwise it segfaults! However I don't understand why! dontStrip = true; inherit meta; </ins> }; <ins> in buildFHSEnv { # ref: pkgs/build-support/build-fhsenv-bubblewrap/default.nix name = "${pname}-${version}"; inherit meta; # for including insync's xdg data dirs extraOutputsToInstall = [ "share" ]; targetPkgs = pkgs: [ insync-pkg ]; multiPkgs = pkgs: with pkgs; [ # apparently only package needed for the FHS :) libudev0-shim ]; runScript = writeShellScript "insync-wrapper.sh" '' # QT_STYLE_OVERRIDE was used to suppress a QT warning, it should have no actual effect for this binary. export QT_STYLE_OVERRIDE=Fusion exec "${insync-pkg.outPath}/lib/insync/insync" "$@" ''; # "insync start" command starts a daemon. dieWithParent = false; </ins> }


Question:
insync-v3 server doesn't seem to start. See that there is no insync process running. Please run and paste the result.
I believe this is caused by the Insync binaries expecting specific versions of some system libraries like glib. A similar problem has been reported on the Insync forums by a few Gentoo users. See and Since Insync releases are pegged to Ubuntu/Debian/Fedora releases, I'm not sure there's a good fix for this. Fortunately, I was able to get insync v3 working in a nix-shell environment that is pinned to an earlier commit of nixpkgs (). I uploaded a reproducible flake here: The system icon shows up as a red circle, and native Wayland support doesn't work, but it seems fully functional other than that.
Using nixpkgs pinned at , I've been able to successfully run insync version (the version currently in nixpkgs) and version (latest available version). This suggests that there was an update elsewhere in nixpkgs that wasn't backwards-compatible with insync. Pinning nixpkgs works for now, but it's not a long-term fix. Maybe we can try to identify which libraries need to be pinned and explicitly pin those? Or maybe use binaries targeting a distribution which is more up-to-date?
I've noticed this as well a while ago, and even figured out what the issue was, but was too lazy to report it until now. Sorry about that. When you run it should tell you why it can't start. In my case it had some issues harfbuzz, which most likely comes from the upgrate to version 3 . Harfbuzz removed some functions that were not officially documented, but are used by qt webview, which is why it fails. I think this is going to be fixed automatically at some point with either an insync update or an update of qt webview in nixpkgs. But until then, your best bet is to use insync from an older nixpkgs commit. It might even be a better idea to completely remove insync from nixpkgs and providing it as a flake, that has a working nixpkgs version pinned to it.
For me just produces :(
Hi how can I test this pinned version? Thanks!
Any fix for this? insync start --no-daemon Traceback (most recent call last): File "", line 19, in <moduleFile "site-", line 829, in call File "site-", line 782, in main File "site-", line 1259, in invoke File "site-", line 1066, in invoke File "site-", line 610, in invoke File "", line 87, in start File "/usr/local/lib/python3.7/site-", line 627, in execmodule File "", line 11, in <moduleFile "/usr/local/lib/python3.7/site-", line 627, in execmodule File "", line 7, in <moduleImportError: /nix/store/41ms51yaqhqwfp83z8dms55g4abfzihp-insync- version `GLIBCXX3.4.29' not found (required by /nix/store/z8hz4nlh48niad995hs4w33wwryc3lkr-qtbase-) [2847] Failed to execute script insync
I'm afraid it has been a while since I used Insync because I couldn't find a fix for this type of issue. Instead I have been using which is
I reached out to insync back when I made my last post and begged them to look into the issue. I offered to pay for a fix. I was told it was to the developer backlog. I've switched to using .
Yeah, it is frustrating that the Insync developers don't seem to be interested in providing a distro-agnostic version of their product. A flatpak or appimage distribution of insync seems like it should be an obvious win for them, but they haven't committed to anything. Here's hoping; I liked using Insync when I was able to.
are you achieving continuous (real-time) sync with those tools? Neither of the two tools supports that by itself , . If you're achieving it by using the tool as part of a more elaborate solution, would you mind sharing how you're doing that?
I wrote an overlay to pass by the error 403 of url down and I get it installed. But doesn't open yet The error:
Update about . It worked when i pinned a rev from github. To fix the broken URL I created an overlay to override the version and URL of current version on nixpkgs.
I am trying to fix it for the latest insync binary... But it doesn't work, it crashes, badly If I don't do these: Insync will crash with: Something about GLIBC_2.36, while nixos is still at glibc 2.35. But it shouldn't be a issue, otherwise insync would only work for distro that is glibc 2.35... Hope it gives some hints, if anyone wants to continue from here, feel free!
I made build and insync-v3 run again, but it would need to patch two more python packages... to continued.
Update from , the package should be resuscitated soon, coming to unstable and hopefully in time for 23.05!
thank you for persevering on this and getting insync working again!
thanks for this package! Could you also please add the .desktop file and icons? The base insync package has them but they are not to the wrapper package and are not currently user visible. Thanks again!
Also the insync binary is currently named insync-${version}. Can you please strip the version from the binary name? Otherwise the desktop file won't work. Thanks!
No problems. I will look into these!
Might have the desktop files solved.

<del> { stdenv , lib , fetchurl , makeWrapper , dpkg , libxcb , libGL , nss , libthai , wayland , alsa-lib , qtvirtualkeyboard , qtwebchannel , qtwebsockets , qtlocation , qtwebengine , autoPatchelfHook , wrapQtAppsHook }: stdenv.mkDerivation rec { pname = "insync"; version = "3.8.5.50499"; src = fetchurl { url = "https://cdn.insynchq.com/builds/linux/${pname}_${version}-focal_amd64.deb"; hash = "sha256-CtDwU0Cey12kDjEX+Y9x7pfKNARfKDopWsDVRaA1Zts="; }; postPatch = '' substituteInPlace usr/bin/insync --replace /usr/lib/insync $out/usr/lib/insync ''; buildInputs = [ alsa-lib libGL libthai libxcb nss qtlocation qtvirtualkeyboard qtwebchannel qtwebengine qtwebsockets wayland ]; nativeBuildInputs = [ autoPatchelfHook dpkg makeWrapper wrapQtAppsHook ]; unpackPhase = '' dpkg-deb --fsys-tarfile $src | tar -x --no-same-permissions --no-same-owner ''; installPhase = '' mkdir -p $out/bin $out/lib $out/share cp -R usr/* $out/ rm $out/lib/insync/libGLX.so.0 rm $out/lib/insync/libQt5* sed -i 's|/usr/lib/insync|/lib/insync|' "$out/bin/insync" wrapQtApp "$out/lib/insync/insync" ''; dontConfigure = true; dontBuild = true; meta = with lib; { platforms = ["x86_64-linux"]; sourceProvenance = with lib.sourceTypes; [ binaryNativeCode ]; license = licenses.unfree; maintainers = with maintainers; [ ]; homepage = "https://www.insynchq.com"; description = "Google Drive sync and backup with multiple account support"; longDescription = '' Insync is a commercial application that syncs your Drive files to your computer.  It has more advanced features than Google's official client such as multiple account support, Google Doc conversion, symlink support, and built in sharing. There is a 15-day free trial, and it is a paid application after that. ''; }; } </del>


Question:
insync-v3 server doesn't seem to start. See that there is no insync process running. Please run and paste the result.
I believe this is caused by the Insync binaries expecting specific versions of some system libraries like glib. A similar problem has been reported on the Insync forums by a few Gentoo users. See and Since Insync releases are pegged to Ubuntu/Debian/Fedora releases, I'm not sure there's a good fix for this. Fortunately, I was able to get insync v3 working in a nix-shell environment that is pinned to an earlier commit of nixpkgs (). I uploaded a reproducible flake here: The system icon shows up as a red circle, and native Wayland support doesn't work, but it seems fully functional other than that.
Using nixpkgs pinned at , I've been able to successfully run insync version (the version currently in nixpkgs) and version (latest available version). This suggests that there was an update elsewhere in nixpkgs that wasn't backwards-compatible with insync. Pinning nixpkgs works for now, but it's not a long-term fix. Maybe we can try to identify which libraries need to be pinned and explicitly pin those? Or maybe use binaries targeting a distribution which is more up-to-date?
I've noticed this as well a while ago, and even figured out what the issue was, but was too lazy to report it until now. Sorry about that. When you run it should tell you why it can't start. In my case it had some issues harfbuzz, which most likely comes from the upgrate to version 3 . Harfbuzz removed some functions that were not officially documented, but are used by qt webview, which is why it fails. I think this is going to be fixed automatically at some point with either an insync update or an update of qt webview in nixpkgs. But until then, your best bet is to use insync from an older nixpkgs commit. It might even be a better idea to completely remove insync from nixpkgs and providing it as a flake, that has a working nixpkgs version pinned to it.
For me just produces :(
Hi how can I test this pinned version? Thanks!
Any fix for this? insync start --no-daemon Traceback (most recent call last): File "", line 19, in <moduleFile "site-", line 829, in call File "site-", line 782, in main File "site-", line 1259, in invoke File "site-", line 1066, in invoke File "site-", line 610, in invoke File "", line 87, in start File "/usr/local/lib/python3.7/site-", line 627, in execmodule File "", line 11, in <moduleFile "/usr/local/lib/python3.7/site-", line 627, in execmodule File "", line 7, in <moduleImportError: /nix/store/41ms51yaqhqwfp83z8dms55g4abfzihp-insync- version `GLIBCXX3.4.29' not found (required by /nix/store/z8hz4nlh48niad995hs4w33wwryc3lkr-qtbase-) [2847] Failed to execute script insync
I'm afraid it has been a while since I used Insync because I couldn't find a fix for this type of issue. Instead I have been using which is
I reached out to insync back when I made my last post and begged them to look into the issue. I offered to pay for a fix. I was told it was to the developer backlog. I've switched to using .
Yeah, it is frustrating that the Insync developers don't seem to be interested in providing a distro-agnostic version of their product. A flatpak or appimage distribution of insync seems like it should be an obvious win for them, but they haven't committed to anything. Here's hoping; I liked using Insync when I was able to.
are you achieving continuous (real-time) sync with those tools? Neither of the two tools supports that by itself , . If you're achieving it by using the tool as part of a more elaborate solution, would you mind sharing how you're doing that?
I wrote an overlay to pass by the error 403 of url down and I get it installed. But doesn't open yet The error:
Update about . It worked when i pinned a rev from github. To fix the broken URL I created an overlay to override the version and URL of current version on nixpkgs.
I am trying to fix it for the latest insync binary... But it doesn't work, it crashes, badly If I don't do these: Insync will crash with: Something about GLIBC_2.36, while nixos is still at glibc 2.35. But it shouldn't be a issue, otherwise insync would only work for distro that is glibc 2.35... Hope it gives some hints, if anyone wants to continue from here, feel free!
I made build and insync-v3 run again, but it would need to patch two more python packages... to continued.
Update from , the package should be resuscitated soon, coming to unstable and hopefully in time for 23.05!
thank you for persevering on this and getting insync working again!
thanks for this package! Could you also please add the .desktop file and icons? The base insync package has them but they are not to the wrapper package and are not currently user visible. Thanks again!
Also the insync binary is currently named insync-${version}. Can you please strip the version from the binary name? Otherwise the desktop file won't work. Thanks!
No problems. I will look into these!
Might have the desktop files solved.

imagemagick7_light = imagemagick_light; # Added 2021-02-22 imlib = throw "imlib has been dropped due to the lack of maintenance from upstream since 2004"; # Added 2023-01-04 impressive = throw "impressive has been removed due to lack of released python 2 support and maintainership in nixpkgs"; # Added 2022-01-27 <ins> insync-v3 = throw "insync-v3 has been merged into the insync package; use insync instead"; #Added 2023-05-13 </ins> i-score = throw "i-score has been removed: abandoned upstream"; # Added 2020-11-21 inboxer = throw "inboxer has been removed as it is no longer maintained and no longer works as Google shut down the inbox service this package wrapped"; index-fm = libsForQt5.mauiPackages.index; # added 2022-05-17


Question:
insync-v3 server doesn't seem to start. See that there is no insync process running. Please run and paste the result.
I believe this is caused by the Insync binaries expecting specific versions of some system libraries like glib. A similar problem has been reported on the Insync forums by a few Gentoo users. See and Since Insync releases are pegged to Ubuntu/Debian/Fedora releases, I'm not sure there's a good fix for this. Fortunately, I was able to get insync v3 working in a nix-shell environment that is pinned to an earlier commit of nixpkgs (). I uploaded a reproducible flake here: The system icon shows up as a red circle, and native Wayland support doesn't work, but it seems fully functional other than that.
Using nixpkgs pinned at , I've been able to successfully run insync version (the version currently in nixpkgs) and version (latest available version). This suggests that there was an update elsewhere in nixpkgs that wasn't backwards-compatible with insync. Pinning nixpkgs works for now, but it's not a long-term fix. Maybe we can try to identify which libraries need to be pinned and explicitly pin those? Or maybe use binaries targeting a distribution which is more up-to-date?
I've noticed this as well a while ago, and even figured out what the issue was, but was too lazy to report it until now. Sorry about that. When you run it should tell you why it can't start. In my case it had some issues harfbuzz, which most likely comes from the upgrate to version 3 . Harfbuzz removed some functions that were not officially documented, but are used by qt webview, which is why it fails. I think this is going to be fixed automatically at some point with either an insync update or an update of qt webview in nixpkgs. But until then, your best bet is to use insync from an older nixpkgs commit. It might even be a better idea to completely remove insync from nixpkgs and providing it as a flake, that has a working nixpkgs version pinned to it.
For me just produces :(
Hi how can I test this pinned version? Thanks!
Any fix for this? insync start --no-daemon Traceback (most recent call last): File "", line 19, in <moduleFile "site-", line 829, in call File "site-", line 782, in main File "site-", line 1259, in invoke File "site-", line 1066, in invoke File "site-", line 610, in invoke File "", line 87, in start File "/usr/local/lib/python3.7/site-", line 627, in execmodule File "", line 11, in <moduleFile "/usr/local/lib/python3.7/site-", line 627, in execmodule File "", line 7, in <moduleImportError: /nix/store/41ms51yaqhqwfp83z8dms55g4abfzihp-insync- version `GLIBCXX3.4.29' not found (required by /nix/store/z8hz4nlh48niad995hs4w33wwryc3lkr-qtbase-) [2847] Failed to execute script insync
I'm afraid it has been a while since I used Insync because I couldn't find a fix for this type of issue. Instead I have been using which is
I reached out to insync back when I made my last post and begged them to look into the issue. I offered to pay for a fix. I was told it was to the developer backlog. I've switched to using .
Yeah, it is frustrating that the Insync developers don't seem to be interested in providing a distro-agnostic version of their product. A flatpak or appimage distribution of insync seems like it should be an obvious win for them, but they haven't committed to anything. Here's hoping; I liked using Insync when I was able to.
are you achieving continuous (real-time) sync with those tools? Neither of the two tools supports that by itself , . If you're achieving it by using the tool as part of a more elaborate solution, would you mind sharing how you're doing that?
I wrote an overlay to pass by the error 403 of url down and I get it installed. But doesn't open yet The error:
Update about . It worked when i pinned a rev from github. To fix the broken URL I created an overlay to override the version and URL of current version on nixpkgs.
I am trying to fix it for the latest insync binary... But it doesn't work, it crashes, badly If I don't do these: Insync will crash with: Something about GLIBC_2.36, while nixos is still at glibc 2.35. But it shouldn't be a issue, otherwise insync would only work for distro that is glibc 2.35... Hope it gives some hints, if anyone wants to continue from here, feel free!
I made build and insync-v3 run again, but it would need to patch two more python packages... to continued.
Update from , the package should be resuscitated soon, coming to unstable and hopefully in time for 23.05!
thank you for persevering on this and getting insync working again!
thanks for this package! Could you also please add the .desktop file and icons? The base insync package has them but they are not to the wrapper package and are not currently user visible. Thanks again!
Also the insync binary is currently named insync-${version}. Can you please strip the version from the binary name? Otherwise the desktop file won't work. Thanks!
No problems. I will look into these!
Might have the desktop files solved.

insync = callPackage ../applications/networking/insync { }; <del> insync-v3 = libsForQt5.callPackage ../applications/networking/insync/v3.nix { }; </del> libstrangle = callPackage ../tools/X11/libstrangle { stdenv = stdenv_32bit; };


Question:
"Source" link in search result on for Poetry package is pointing to poetry2nix source code instead of poetry. Steps to reproduce the behavior: on "Source" link in "poetry" package. This will point you to instead of When clicking on "Source" link in "poetry" package search results I want to get to "poetry" source code If applicable, add screenshots to help explain your problem. Add any other context about the problem here. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Please run and paste the result. Maintainer information:
This is really a bigger issue in how source code locations are extracted and it isn't unique to Poetry/Poetry2nix. The root cause is related to how is extracted: In this case is resolved to where Poetry2nix inherits descriptions from /. You can explicitly pass to which I just implemented in :
This issue has been mentioned on NixOS Discourse. There might be relevant details there:

}: let # Poetry2nix version <del> version = "1.20.0"; </del> <ins> version = "1.21.0"; </ins> inherit (poetryLib) isCompatible readTOML moduleName;


Question:
"Source" link in search result on for Poetry package is pointing to poetry2nix source code instead of poetry. Steps to reproduce the behavior: on "Source" link in "poetry" package. This will point you to instead of When clicking on "Source" link in "poetry" package search results I want to get to "poetry" source code If applicable, add screenshots to help explain your problem. Add any other context about the problem here. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Please run and paste the result. Maintainer information:
This is really a bigger issue in how source code locations are extracted and it isn't unique to Poetry/Poetry2nix. The root cause is related to how is extracted: In this case is resolved to where Poetry2nix inherits descriptions from /. You can explicitly pass to which I just implemented in :
This issue has been mentioned on NixOS Discourse. There might be relevant details there:

) { inherit app; }; }; <ins> # Extract position from explicitly passed attrs so meta.position won't point to poetry2nix internals pos = builtins.unsafeGetAttrPos (lib.elemAt (lib.attrNames attrs) 0) attrs; </ins> meta = lib.optionalAttrs (lib.hasAttr "description" pyProject.tool.poetry) { inherit (pyProject.tool.poetry) description;


Question:
"Source" link in search result on for Poetry package is pointing to poetry2nix source code instead of poetry. Steps to reproduce the behavior: on "Source" link in "poetry" package. This will point you to instead of When clicking on "Source" link in "poetry" package search results I want to get to "poetry" source code If applicable, add screenshots to help explain your problem. Add any other context about the problem here. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Please run and paste the result. Maintainer information:
This is really a bigger issue in how source code locations are extracted and it isn't unique to Poetry/Poetry2nix. The root cause is related to how is extracted: In this case is resolved to where Poetry2nix inherits descriptions from /. You can explicitly pass to which I just implemented in :
This issue has been mentioned on NixOS Discourse. There might be relevant details there:

} ); <ins> cheroot = super.cheroot.overridePythonAttrs ( old: { dontPreferSetupPy = true; } ); </ins> colour = super.colour.overridePythonAttrs ( old: { buildInputs = (old.buildInputs or [ ]) ++ [ self.d2to1 ];