Question: <ins> # This file is automatically @generated by Cargo. # It is not intended for manual editing. version = 3 [[package]] name = "aho-corasick" version = "1.0.3" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "86b8f9420f797f2d9e935edf629310eb938a0d839f984e25327f3c7eed22300c" dependencies = [ "memchr", ] [[package]] name = "anyhow" version = "1.0.72" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "3b13c32d80ecc7ab747b80c3784bce54ee8a7a0cc4fbda9bf4cda2cf6fe90854" [[package]] name = "autocfg" version = "1.1.0" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "d468802bab17cbc0cc575e9b053f41e72aa36bfa6b7f55e3529ffa43161b97fa" [[package]] name = "bindgen" version = "0.64.0" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "c4243e6031260db77ede97ad86c27e501d646a27ab57b59a574f725d98ab1fb4" dependencies = [ "bitflags 1.3.2", "cexpr", "clang-sys", "lazy_static", "lazycell", "peeking_take_while", "proc-macro2", "quote", "regex", "rustc-hash", "shlex", "syn 1.0.109", ] [[package]] name = "bitflags" version = "1.3.2" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "bef38d45163c2f1dde094a7dfd33ccf595c92905c8f8f4fdc18d06fb1037718a" [[package]] name = "bitflags" version = "2.3.3" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "630be753d4e58660abd17930c71b647fe46c27ea6b63cc59e1e3851406972e42" [[package]] name = "bitmaps" version = "2.1.0" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "031043d04099746d8db04daf1fa424b2bc8bd69d92b25962dcde24da39ab64a2" dependencies = [ "typenum", ] [[package]] name = "block" version = "0.1.6" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "0d8c1fef690941d3e7788d328517591fecc684c084084702d6ff1641e993699a" [[package]] name = "cairo-rs" version = "0.18.0" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "d859b656775a6b1dd078d3e5924884e6ea88aa649a7fdde03d5b2ec56ffcc10b" dependencies = [ "bitflags 2.3.3", "cairo-sys-rs", "glib", "libc", "once_cell", "thiserror", ] [[package]] name = "cairo-sys-rs" version = "0.18.0" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "bd4d115132e01c0165e3bf5f56aedee8980b0b96ede4eb000b693c05a8adb8ff" dependencies = [ "glib-sys", "libc", "system-deps", ] [[package]] name = "cc" version = "1.0.82" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "305fe645edc1442a0fa8b6726ba61d422798d37a52e12eaecf4b022ebbb88f01" dependencies = [ "libc", ] [[package]] name = "cexpr" version = "0.6.0" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "6fac387a98bb7c37292057cffc56d62ecb629900026402633ae9160df93a8766" dependencies = [ "nom", ] [[package]] name = "cfg-expr" version = "0.15.4" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "b40ccee03b5175c18cde8f37e7d2a33bcef6f8ec8f7cc0d81090d1bb380949c9" dependencies = [ "smallvec", "target-lexicon", ] [[package]] name = "cfg-if" version = "1.0.0" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "baf1de4339761588bc0619e3cbc0120ee582ebb74b53b4efbf79117bd2da40fd" [[package]] name = "clang-sys" version = "1.6.1" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "c688fc74432808e3eb684cae8830a86be1d66a2bd58e1f248ed0960a590baf6f" dependencies = [ "glob", "libc", ] [[package]] name = "convert_case" version = "0.6.0" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "ec182b0ca2f35d8fc196cf3404988fd8b8c739a4d270ff118a398feb0cbec1ca" dependencies = [ "unicode-segmentation", ] [[package]] name = "cookie-factory" version = "0.3.2" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "396de984970346b0d9e93d1415082923c679e5ae5c3ee3dcbd104f5610af126b" [[package]] name = "equivalent" version = "1.0.1" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "5443807d6dff69373d433ab9ef5378ad8df50ca6298caf15de6e52e24aaf54d5" [[package]] name = "field-offset" version = "0.3.6" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "38e2275cc4e4fc009b0669731a1e5ab7ebf11f469eaede2bab9309a5b4d6057f" dependencies = [ "memoffset 0.9.0", "rustc_version", ] [[package]] name = "futures" version = "0.3.28" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "23342abe12aba583913b2e62f22225ff9c950774065e4bfb61a19cd9770fec40" dependencies = [ "futures-channel", "futures-core", "futures-executor", "futures-io", "futures-sink", "futures-task", "futures-util", ] [[package]] name = "futures-channel" version = "0.3.28" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "955518d47e09b25bbebc7a18df10b81f0c766eaf4c4f1cccef2fca5f2a4fb5f2" dependencies = [ "futures-core", "futures-sink", ] [[package]] name = "futures-core" version = "0.3.28" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "4bca583b7e26f571124fe5b7561d49cb2868d79116cfa0eefce955557c6fee8c" [[package]] name = "futures-executor" version = "0.3.28" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "ccecee823288125bd88b4d7f565c9e58e41858e47ab72e8ea2d64e93624386e0" dependencies = [ "futures-core", "futures-task", "futures-util", ] [[package]] name = "futures-io" version = "0.3.28" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "4fff74096e71ed47f8e023204cfd0aa1289cd54ae5430a9523be060cdb849964" [[package]] name = "futures-macro" version = "0.3.28" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "89ca545a94061b6365f2c7355b4b32bd20df3ff95f02da9329b34ccc3bd6ee72" dependencies = [ "proc-macro2", "quote", "syn 2.0.28", ] [[package]] name = "futures-sink" version = "0.3.28" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "f43be4fe21a13b9781a69afa4985b0f6ee0e1afab2c6f454a8cf30e2b2237b6e" [[package]] name = "futures-task" version = "0.3.28" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "76d3d132be6c0e6aa1534069c705a74a5997a356c0dc2f86a47765e5617c5b65" [[package]] name = "futures-util" version = "0.3.28" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "26b01e40b772d54cf6c6d721c1d1abd0647a0106a12ecaa1c186273392a69533" dependencies = [ "futures-channel", "futures-core", "futures-io", "futures-macro", "futures-sink", "futures-task", "memchr", "pin-project-lite", "pin-utils", "slab", ] [[package]] name = "gdk-pixbuf" version = "0.18.0" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "bbc9c2ed73a81d556b65d08879ba4ee58808a6b1927ce915262185d6d547c6f3" dependencies = [ "gdk-pixbuf-sys", "gio", "glib", "libc", "once_cell", ] [[package]] name = "gdk-pixbuf-sys" version = "0.18.0" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "3f9839ea644ed9c97a34d129ad56d38a25e6756f99f3a88e15cd39c20629caf7" dependencies = [ "gio-sys", "glib-sys", "gobject-sys", "libc", "system-deps", ] [[package]] name = "gdk4" version = "0.7.1" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "8965ed5455cbfa1eb45c14a3b971cbacb43481913a3a5b9078b2ef0d9a01bd4b" dependencies = [ "cairo-rs", "gdk-pixbuf", "gdk4-sys", "gio", "glib", "libc", "pango", ] [[package]] name = "gdk4-sys" version = "0.7.1" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "aeffd4a7d68046c28666d817071bf025254aaed4df35099443f0c306ca6177f3" dependencies = [ "cairo-sys-rs", "gdk-pixbuf-sys", "gio-sys", "glib-sys", "gobject-sys", "libc", "pango-sys", "pkg-config", "system-deps", ] [[package]] name = "gettext-rs" version = "0.7.0" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "e49ea8a8fad198aaa1f9655a2524b64b70eb06b2f3ff37da407566c93054f364" dependencies = [ "gettext-sys", "locale_config", ] [[package]] name = "gettext-sys" version = "0.21.3" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "c63ce2e00f56a206778276704bbe38564c8695249fdc8f354b4ef71c57c3839d" dependencies = [ "cc", "temp-dir", ] [[package]] name = "gio" version = "0.18.1" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "7884cba6b1c5db1607d970cadf44b14a43913d42bc68766eea6a5e2fe0891524" dependencies = [ "futures-channel", "futures-core", "futures-io", "futures-util", "gio-sys", "glib", "libc", "once_cell", "pin-project-lite", "smallvec", "thiserror", ] [[package]] name = "gio-sys" version = "0.18.1" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "37566df850baf5e4cb0dfb78af2e4b9898d817ed9263d1090a2df958c64737d2" dependencies = [ "glib-sys", "gobject-sys", "libc", "system-deps", "winapi", ] [[package]] name = "glib" version = "0.18.1" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "331156127e8166dd815cf8d2db3a5beb492610c716c03ee6db4f2d07092af0a7" dependencies = [ "bitflags 2.3.3", "futures-channel", "futures-core", "futures-executor", "futures-task", "futures-util", "gio-sys", "glib-macros", "glib-sys", "gobject-sys", "libc", "log", "memchr", "once_cell", "smallvec", "thiserror", ] [[package]] name = "glib-macros" version = "0.18.0" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "179643c50bf28d20d2f6eacd2531a88f2f5d9747dd0b86b8af1e8bb5dd0de3c0" dependencies = [ "heck", "proc-macro-crate", "proc-macro-error", "proc-macro2", "quote", "syn 2.0.28", ] [[package]] name = "glib-sys" version = "0.18.1" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "063ce2eb6a8d0ea93d2bf8ba1957e78dbab6be1c2220dd3daca57d5a9d869898" dependencies = [ "libc", "system-deps", ] [[package]] name = "glob" version = "0.3.1" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "d2fabcfbdc87f4758337ca535fb41a6d701b65693ce38287d856d1674551ec9b" [[package]] name = "gobject-sys" version = "0.18.0" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "0850127b514d1c4a4654ead6dedadb18198999985908e6ffe4436f53c785ce44" dependencies = [ "glib-sys", "libc", "system-deps", ] [[package]] name = "graphene-rs" version = "0.18.1" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "3b2228cda1505613a7a956cca69076892cfbda84fc2b7a62b94a41a272c0c401" dependencies = [ "glib", "graphene-sys", "libc", ] [[package]] name = "graphene-sys" version = "0.18.1" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "cc4144cee8fc8788f2a9b73dc5f1d4e1189d1f95305c4cb7bd9c1af1cfa31f59" dependencies = [ "glib-sys", "libc", "pkg-config", "system-deps", ] [[package]] name = "gsk4" version = "0.7.1" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "53b3b9e8090acb325d08cde84b30fc29b963a75fbac93160e9c5a30d2b335742" dependencies = [ "cairo-rs", "gdk4", "glib", "graphene-rs", "gsk4-sys", "libc", "pango", ] [[package]] name = "gsk4-sys" version = "0.7.0" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "0770d1ede7189092748c4ef5b6921264eb945fd2318a58e8f59dc273000810f8" dependencies = [ "cairo-sys-rs", "gdk4-sys", "glib-sys", "gobject-sys", "graphene-sys", "libc", "pango-sys", "system-deps", ] [[package]] name = "gtk4" version = "0.7.1" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "0973f9b9ade10fc22403810b7283d47b533033715f2aaa36288cd3bf90d63efc" dependencies = [ "cairo-rs", "field-offset", "futures-channel", "gdk-pixbuf", "gdk4", "gio", "glib", "graphene-rs", "gsk4", "gtk4-macros", "gtk4-sys", "libc", "pango", ] [[package]] name = "gtk4-macros" version = "0.7.1" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "ae9f2c4530f3168fe506b0be7bc15f7a93ef38d020edb27d81a921a26cbca851" dependencies = [ "anyhow", "proc-macro-crate", "proc-macro-error", "proc-macro2", "quote", "syn 1.0.109", ] [[package]] name = "gtk4-sys" version = "0.7.0" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "19fde71ef2e78ac8fb18073c345b5f29609048d4045a345613645aa1163243c1" dependencies = [ "cairo-sys-rs", "gdk-pixbuf-sys", "gdk4-sys", "gio-sys", "glib-sys", "gobject-sys", "graphene-sys", "gsk4-sys", "libc", "pango-sys", "system-deps", ] [[package]] name = "hashbrown" version = "0.14.0" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "2c6201b9ff9fd90a5a3bac2e56a830d0caa509576f0e503818ee82c181b3437a" [[package]] name = "heck" version = "0.4.1" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "95505c38b4572b2d910cecb0281560f54b440a19336cbbcb27bf6ce6adc6f5a8" [[package]] name = "im-rc" version = "15.1.0" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "af1955a75fa080c677d3972822ec4bad316169ab1cfc6c257a942c2265dbe5fe" dependencies = [ "bitmaps", "rand_core", "rand_xoshiro", "sized-chunks", "typenum", "version_check", ] [[package]] name = "indexmap" version = "2.0.0" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "d5477fe2230a79769d8dc68e0eabf5437907c0457a5614a9e8dddb67f65eb65d" dependencies = [ "equivalent", "hashbrown", ] [[package]] name = "lazy_static" version = "1.4.0" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "e2abad23fbc42b3700f2f279844dc832adb2b2eb069b2df918f455c4e18cc646" [[package]] name = "lazycell" version = "1.3.0" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "830d08ce1d1d941e6b30645f1a0eb5643013d835ce3779a5fc208261dbe10f55" [[package]] name = "libadwaita" version = "0.5.2" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "06444f4ca05a60693da6e9e2b591bd40a298e65a118a8d5e830771718b3e0253" dependencies = [ "gdk-pixbuf", "gdk4", "gio", "glib", "gtk4", "libadwaita-sys", "libc", "pango", ] [[package]] name = "libadwaita-sys" version = "0.5.2" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "021cfe3d1fcfa82411765a791f7e9b32f35dd98ce88d2e3fa10e7320f5cc8ce7" dependencies = [ "gdk4-sys", "gio-sys", "glib-sys", "gobject-sys", "gtk4-sys", "libc", "pango-sys", "system-deps", ] [[package]] name = "libc" version = "0.2.147" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "b4668fb0ea861c1df094127ac5f1da3409a82116a4ba74fca2e58ef927159bb3" [[package]] name = "libspa" version = "0.6.0" source = "git+https://gitlab.freedesktop.org/saivert/pipewire-rs?branch=misc_fixes#46bfbd8bdf0ad3ff1d25d02b2e36f97333c78e23" dependencies = [ "bitflags 2.3.3", "cc", "convert_case", "cookie-factory", "libc", "libspa-sys", "nix", "nom", "system-deps", ] [[package]] name = "libspa-sys" version = "0.6.0" source = "git+https://gitlab.freedesktop.org/saivert/pipewire-rs?branch=misc_fixes#46bfbd8bdf0ad3ff1d25d02b2e36f97333c78e23" dependencies = [ "bindgen", "cc", "system-deps", ] [[package]] name = "locale_config" version = "0.3.0" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "08d2c35b16f4483f6c26f0e4e9550717a2f6575bcd6f12a53ff0c490a94a6934" dependencies = [ "lazy_static", "objc", "objc-foundation", "regex", "winapi", ] [[package]] name = "log" version = "0.4.19" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "b06a4cde4c0f271a446782e3eff8de789548ce57dbc8eca9292c27f4a42004b4" [[package]] name = "malloc_buf" version = "0.0.6" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "62bb907fe88d54d8d9ce32a3cceab4218ed2f6b7d35617cafe9adf84e43919cb" dependencies = [ "libc", ] [[package]] name = "memchr" version = "2.5.0" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "2dffe52ecf27772e601905b7522cb4ef790d2cc203488bbd0e2fe85fcb74566d" [[package]] name = "memoffset" version = "0.7.1" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "5de893c32cde5f383baa4c04c5d6dbdd735cfd4a794b0debdb2bb1b421da5ff4" dependencies = [ "autocfg", ] [[package]] name = "memoffset" version = "0.9.0" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "5a634b1c61a95585bd15607c6ab0c4e5b226e695ff2800ba0cdccddf208c406c" dependencies = [ "autocfg", ] [[package]] name = "minimal-lexical" version = "0.2.1" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "68354c5c6bd36d73ff3feceb05efa59b6acb7626617f4962be322a825e61f79a" [[package]] name = "nix" version = "0.26.2" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "bfdda3d196821d6af13126e40375cdf7da646a96114af134d5f417a9a1dc8e1a" dependencies = [ "bitflags 1.3.2", "cfg-if", "libc", "memoffset 0.7.1", "pin-utils", "static_assertions", ] [[package]] name = "nom" version = "7.1.3" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "d273983c5a657a70a3e8f2a01329822f3b8c8172b73826411a55751e404a0a4a" dependencies = [ "memchr", "minimal-lexical", ] [[package]] name = "objc" version = "0.2.7" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "915b1b472bc21c53464d6c8461c9d3af805ba1ef837e1cac254428f4a77177b1" dependencies = [ "malloc_buf", ] [[package]] name = "objc-foundation" version = "0.1.1" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "1add1b659e36c9607c7aab864a76c7a4c2760cd0cd2e120f3fb8b952c7e22bf9" dependencies = [ "block", "objc", "objc_id", ] [[package]] name = "objc_id" version = "0.1.1" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "c92d4ddb4bd7b50d730c215ff871754d0da6b2178849f8a2a2ab69712d0c073b" dependencies = [ "objc", ] [[package]] name = "once_cell" version = "1.18.0" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "dd8b5dd2ae5ed71462c540258bedcb51965123ad7e7ccf4b9a8cafaa4a63576d" [[package]] name = "pango" version = "0.18.0" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "06a9e54b831d033206160096b825f2070cf5fda7e35167b1c01e9e774f9202d1" dependencies = [ "gio", "glib", "libc", "once_cell", "pango-sys", ] [[package]] name = "pango-sys" version = "0.18.0" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "436737e391a843e5933d6d9aa102cb126d501e815b83601365a948a518555dc5" dependencies = [ "glib-sys", "gobject-sys", "libc", "system-deps", ] [[package]] name = "peeking_take_while" version = "0.1.2" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "19b17cddbe7ec3f8bc800887bab5e717348c95ea2ca0b1bf0837fb964dc67099" [[package]] name = "pin-project-lite" version = "0.2.12" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "12cc1b0bf1727a77a54b6654e7b5f1af8604923edc8b81885f8ec92f9e3f0a05" [[package]] name = "pin-utils" version = "0.1.0" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "8b870d8c151b6f2fb93e84a13146138f05d02ed11c7e7c54f8826aaaf7c9f184" [[package]] name = "pipewire" version = "0.6.0" source = "git+https://gitlab.freedesktop.org/saivert/pipewire-rs?branch=misc_fixes#46bfbd8bdf0ad3ff1d25d02b2e36f97333c78e23" dependencies = [ "anyhow", "bitflags 2.3.3", "libc", "libspa", "libspa-sys", "nix", "once_cell", "pipewire-sys", "thiserror", ] [[package]] name = "pipewire-sys" version = "0.6.0" source = "git+https://gitlab.freedesktop.org/saivert/pipewire-rs?branch=misc_fixes#46bfbd8bdf0ad3ff1d25d02b2e36f97333c78e23" dependencies = [ "bindgen", "libspa-sys", "system-deps", ] [[package]] name = "pkg-config" version = "0.3.27" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "26072860ba924cbfa98ea39c8c19b4dd6a4a25423dbdf219c1eca91aa0cf6964" [[package]] name = "proc-macro-crate" version = "1.3.1" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "7f4c021e1093a56626774e81216a4ce732a735e5bad4868a03f3ed65ca0c3919" dependencies = [ "once_cell", "toml_edit", ] [[package]] name = "proc-macro-error" version = "1.0.4" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "da25490ff9892aab3fcf7c36f08cfb902dd3e71ca0f9f9517bea02a73a5ce38c" dependencies = [ "proc-macro-error-attr", "proc-macro2", "quote", "syn 1.0.109", "version_check", ] [[package]] name = "proc-macro-error-attr" version = "1.0.4" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "a1be40180e52ecc98ad80b184934baf3d0d29f979574e439af5a55274b35f869" dependencies = [ "proc-macro2", "quote", "version_check", ] [[package]] name = "proc-macro2" version = "1.0.66" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "18fb31db3f9bddb2ea821cde30a9f70117e3f119938b5ee630b7403aa6e2ead9" dependencies = [ "unicode-ident", ] [[package]] name = "pwvucontrol" version = "0.1.0" dependencies = [ "anyhow", "futures", "gettext-rs", "glib", "gtk4", "im-rc", "libadwaita", "log", "once_cell", "pipewire", "wireplumber", ] [[package]] name = "quote" version = "1.0.32" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "50f3b39ccfb720540debaa0164757101c08ecb8d326b15358ce76a62c7e85965" dependencies = [ "proc-macro2", ] [[package]] name = "rand_core" version = "0.6.4" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "ec0be4795e2f6a28069bec0b5ff3e2ac9bafc99e6a9a7dc3547996c5c816922c" [[package]] name = "rand_xoshiro" version = "0.6.0" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "6f97cdb2a36ed4183de61b2f824cc45c9f1037f28afe0a322e9fff4c108b5aaa" dependencies = [ "rand_core", ] [[package]] name = "regex" version = "1.9.3" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "81bc1d4caf89fac26a70747fe603c130093b53c773888797a6329091246d651a" dependencies = [ "aho-corasick", "memchr", "regex-automata", "regex-syntax", ] [[package]] name = "regex-automata" version = "0.3.6" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "fed1ceff11a1dddaee50c9dc8e4938bd106e9d89ae372f192311e7da498e3b69" dependencies = [ "aho-corasick", "memchr", "regex-syntax", ] [[package]] name = "regex-syntax" version = "0.7.4" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "e5ea92a5b6195c6ef2a0295ea818b312502c6fc94dde986c5553242e18fd4ce2" [[package]] name = "rustc-hash" version = "1.1.0" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "08d43f7aa6b08d49f382cde6a7982047c3426db949b1424bc4b7ec9ae12c6ce2" [[package]] name = "rustc_version" version = "0.4.0" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "bfa0f585226d2e68097d4f95d113b15b83a82e819ab25717ec0590d9584ef366" dependencies = [ "semver", ] [[package]] name = "semver" version = "1.0.18" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "b0293b4b29daaf487284529cc2f5675b8e57c61f70167ba415a463651fd6a918" [[package]] name = "serde" version = "1.0.183" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "32ac8da02677876d532745a130fc9d8e6edfa81a269b107c5b00829b91d8eb3c" [[package]] name = "serde_spanned" version = "0.6.3" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "96426c9936fd7a0124915f9185ea1d20aa9445cc9821142f0a73bc9207a2e186" dependencies = [ "serde", ] [[package]] name = "shlex" version = "1.1.0" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "43b2853a4d09f215c24cc5489c992ce46052d359b5109343cbafbf26bc62f8a3" [[package]] name = "sized-chunks" version = "0.6.5" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "16d69225bde7a69b235da73377861095455d298f2b970996eec25ddbb42b3d1e" dependencies = [ "bitmaps", "typenum", ] [[package]] name = "slab" version = "0.4.8" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "6528351c9bc8ab22353f9d776db39a20288e8d6c37ef8cfe3317cf875eecfc2d" dependencies = [ "autocfg", ] [[package]] name = "smallvec" version = "1.11.0" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "62bb4feee49fdd9f707ef802e22365a35de4b7b299de4763d44bfea899442ff9" [[package]] name = "static_assertions" version = "1.1.0" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "a2eb9349b6444b326872e140eb1cf5e7c522154d69e7a0ffb0fb81c06b37543f" [[package]] name = "syn" version = "1.0.109" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "72b64191b275b66ffe2469e8af2c1cfe3bafa67b529ead792a6d0160888b4237" dependencies = [ "proc-macro2", "quote", "unicode-ident", ] [[package]] name = "syn" version = "2.0.28" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "04361975b3f5e348b2189d8dc55bc942f278b2d482a6a0365de5bdd62d351567" dependencies = [ "proc-macro2", "quote", "unicode-ident", ] [[package]] name = "system-deps" version = "6.1.1" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "30c2de8a4d8f4b823d634affc9cd2a74ec98c53a756f317e529a48046cbf71f3" dependencies = [ "cfg-expr", "heck", "pkg-config", "toml", "version-compare", ] [[package]] name = "target-lexicon" version = "0.12.11" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "9d0e916b1148c8e263850e1ebcbd046f333e0683c724876bb0da63ea4373dc8a" [[package]] name = "temp-dir" version = "0.1.11" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "af547b166dd1ea4b472165569fc456cfb6818116f854690b0ff205e636523dab" [[package]] name = "thiserror" version = "1.0.44" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "611040a08a0439f8248d1990b111c95baa9c704c805fa1f62104b39655fd7f90" dependencies = [ "thiserror-impl", ] [[package]] name = "thiserror-impl" version = "1.0.44" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "090198534930841fab3a5d1bb637cde49e339654e606195f8d9c76eeb081dc96" dependencies = [ "proc-macro2", "quote", "syn 2.0.28", ] [[package]] name = "toml" version = "0.7.6" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "c17e963a819c331dcacd7ab957d80bc2b9a9c1e71c804826d2f283dd65306542" dependencies = [ "serde", "serde_spanned", "toml_datetime", "toml_edit", ] [[package]] name = "toml_datetime" version = "0.6.3" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "7cda73e2f1397b1262d6dfdcef8aafae14d1de7748d66822d3bfeeb6d03e5e4b" dependencies = [ "serde", ] [[package]] name = "toml_edit" version = "0.19.14" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "f8123f27e969974a3dfba720fdb560be359f57b44302d280ba72e76a74480e8a" dependencies = [ "indexmap", "serde", "serde_spanned", "toml_datetime", "winnow", ] [[package]] name = "typenum" version = "1.16.0" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "497961ef93d974e23eb6f433eb5fe1b7930b659f06d12dec6fc44a8f554c0bba" [[package]] name = "unicode-ident" version = "1.0.11" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "301abaae475aa91687eb82514b328ab47a211a533026cb25fc3e519b86adfc3c" [[package]] name = "unicode-segmentation" version = "1.10.1" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "1dd624098567895118886609431a7c3b8f516e41d30e0643f03d94592a147e36" [[package]] name = "version-compare" version = "0.1.1" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "579a42fc0b8e0c63b76519a339be31bed574929511fa53c1a3acae26eb258f29" [[package]] name = "version_check" version = "0.9.4" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "49874b5167b65d7193b8aba1567f5c7d93d001cafc34600cee003eda787e483f" [[package]] name = "winapi" version = "0.3.9" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "5c839a674fcd7a98952e593242ea400abe93992746761e38641405d28b00f419" dependencies = [ "winapi-i686-pc-windows-gnu", "winapi-x86_64-pc-windows-gnu", ] [[package]] name = "winapi-i686-pc-windows-gnu" version = "0.4.0" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "ac3b87c63620426dd9b991e5ce0329eff545bccbbb34f3be09ff6fb6ab51b7b6" [[package]] name = "winapi-x86_64-pc-windows-gnu" version = "0.4.0" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "712e227841d057c1ee1cd2fb22fa7e5a5461ae8e48fa2ca79ec42cfc1931183f" [[package]] name = "winnow" version = "0.5.4" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "acaaa1190073b2b101e15083c38ee8ec891b5e05cbee516521e94ec008f61e64" dependencies = [ "memchr", ] [[package]] name = "wireplumber" version = "0.1.0" source = "git+https://github.com/saivert/wireplumber.rs.git?branch=use_pipewire_from_git#8dbf383ce54dee7b8d578b87c13f3507a65291f8" dependencies = [ "bitflags 1.3.2", "gio", "glib", "libc", "libspa-sys", "pipewire-sys", "pkg-config", "semver", "wireplumber-sys", ] [[package]] name = "wireplumber-sys" version = "0.1.0" source = "git+https://github.com/saivert/wireplumber.rs.git?branch=use_pipewire_from_git#8dbf383ce54dee7b8d578b87c13f3507a65291f8" dependencies = [ "gio-sys", "glib-sys", "gobject-sys", "libc", "libspa-sys", "pipewire-sys", "system-deps", ] </ins>

Project description Volume control applet for Pipewire, written in Rust. <!-- Describe the project a little: --Metadata homepage URL: source URL: license: mit, bsd, gpl2+ , ... platforms: unix, linux, darwin, ...


Question: sha256 = "add96ad3509d4d5c6d8658b005dfd046963cd6bb0a4e1f3e88f726a86c05810f"; }; <ins> passthru.tests = nixosTests.freetube; </ins> appimageContents = appimageTools.extractType2 { name = "${pname}-${version}"; inherit src;

Steps to reproduce the behavior: system configuration with Freetube in it. See and for the exact same issue with Morgen. Electron version lock seems to have been introduced with . Upstream seems to be at Electron 27: . and
Maybe we could add the patches from It looks like they were waiting for a nixos user to test it and eventually gave up on us.
are you able to test ?
Looks good as far as I can tell.
fails on this branch, for whatever reason.


Question: aarch64-darwin = "97adf13306c9b3b304d3e9ddf68f5f7fb9b79c9a1342114e3671182f3cc9e808"; headers = "0gl30q2igr9c8sjlhyj5w57dm5navpkas5hnz9yl7sasbx66v10v"; }; <ins> electron_19 = mkElectron "19.0.7" { armv7l-linux = "d6a6d2d7c0d658695783137d032a50f20843cdfe6582ef985451d741eef4dd32"; aarch64-linux = "58685d21bb92c2667d20063ab12aabc2e5c2518f3eda84e98a0fa2306456ce57"; x86_64-linux = "a4c20a068c54c238ae8c440ab8f46d39eda4168d6aa8cffcaae406800b539983"; x86_64-darwin = "2709dd94e22ecfc8e7de0c7a7009160ed79e95ba91618c7307e24c26a33e978b"; aarch64-darwin = "f9042bce83fe8446e22f6885285dd5fc2dca048d0b89cbf7f326a46102ffc440"; headers = "09dbx4qh0rgp5mdm6srz6fgx12zq6b9jqq1k6l3gzyvwigi3wny1"; }; </ins> }

Element v1.11.0 updated to Electron 19, so we need this packaged in Nixpkgs: <!-- 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 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 as 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: 18.1.0 desired version: 19.0.7 <!-- 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.
When I run the script tries to download which does not exist. Do you know where to get the electron headers?
PR that brings electron19 but does not provide electron19 headers:
I believe that states that they migrated storage. So, I think the new url would be
Great find, thanks! Updated PR to include this change and electron_19 now provides the headers.
electrum_19 to master via - feel free to update your package


Question: mkdir -p $out/bin makeWrapper ${Agda}/bin/agda $out/bin/agda  --add-flags "--with-compiler=${ghc}/bin/ghc"  <del> --add-flags "--library-file=${library-file}"  --add-flags "--local-interfaces" </del> <ins> --add-flags "--library-file=${library-file}" </ins> ln -s ${Agda}/bin/agda-mode $out/bin/agda-mode <del> ''; # Local interfaces has been added for now: See https://github.com/agda/agda/issues/4526 </del> <ins> ''; </ins> withPackages = arg: if builtins.isAttrs arg then withPackages' arg else withPackages' { pkgs = arg; };

Describe the bug The new version of Agda is working fine on other systems, but not NixOS. I've reported a bit more about what is known at To Reproduce Steps to reproduce the behavior: Agda 2.6.1 any file (e.g, ) Expected behavior Agda checks the file quickly and exits. Additional context Issue in the Agda repository: agda/agda Metadata Maintainer information:
I believe that this is fixed by rework of our Agda setup ! (Which is included in the most recent nixos-unstable.) Can you confirm? :-) $ echo module Main where && time agda Checking Main (). real 0m0.132s user 0m0.104s sys 0m0.028s Looks reasonable!
I haven't had chance to test the new stuff, but this issue probably should be closed anyway, as it's being worked on upstream (). I'm doing fine now using the workaround of adding option .


Question: libgphoto2 libjpeg libpng librsvg libtiff openexr sqlite libxslt libsoup graphicsmagick json-glib openjpeg lua pugixml colord colord-gtk libwebp libsecret gnome3.adwaita-icon-theme <del> osm-gps-map </del> <ins> osm-gps-map ocl-icd </ins> ]; cmakeFlags = [ "-DBUILD_USERMANUAL=False" ];

Darktable can make use of OpenCL, but the nix package apparently isn't set up properly to allow this. Run : system: host os: multi-user?: sandbox: version: channels(root): channels(lukas): nixpkgs: OpenCL is set up properly on my system: cc darktable maintainers:
I'd been meaning to fix this for myself for awhile. Should be good now, pending review.
Thanks!
Sorry to revive this, but I am still having this problem in dartable 2.4.4 using intel OpenCL Neo driver. Should ti be already solved? Or the fix is still not present in 2.4.4? Thanks
Disregard (at least partially) my last comment. I was using the snap version in Ubuntu 18.10. Using the deb, OpenCl works. Where should I submit the bug for the snap version?


Question: githubId = 70191398; name = "Ryan Cao"; }; <ins> ryand56 = { email = "git@ryand.ca"; github = "ryand56"; githubId = 22267679; name = "Ryan Omasta"; }; </ins> ryane = { email = "ryanesc@gmail.com"; github = "ryane";

Project description A very small, very simple, yet very secure encryption tool. Metadata homepage URL: source URL: license: gpl3 platforms: unix, linux, darwin, windows


Question: lib.optional (coreutils != null) "PR_PROGRAM=${coreutils}/bin/pr" ++ lib.optional (stdenv.buildPlatform != stdenv.hostPlatform) "gl_cv_func_getopt_gnu=yes"; <del> doCheck = true; </del> <ins> # Test failure on QEMU only (#300550) doCheck = !stdenv.buildPlatform.isRiscV64; </ins> meta = with lib; { homepage = "https://www.gnu.org/software/diffutils/diffutils.html";

Steps to reproduce the behavior: diffutils-3.10-riscv64-linux i had suspended the system halfway through the build, and suspected that might have caused an issue, so i ran the build again and got the same result <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
I can't reproduce this failure on RISC-V hardware. With , the following command runs just fine: Could this be an issue with the emulator you're using or a result of ?
The following command also builds for me. Relevant excerpt of the logs: Could you try running this in your build environment to see whether it's an issue with your emulator or build machine? If it builds, could you improve the reproducing instructions you've given?
I ran that command on a seperate x86 machine and recieved the same build failure
I have successfully reproduced the issue by emulating RISC-V on an x86 machine. So this could be caused by a QEMU bug. I suggest you update the title to make it clear that it only happens with binfmt emulation.
Ok i edited the title
i'm curious why the gnugrep pr was merged, but not this one ? given that confirmed this build failure, but not the other one ?
The other one just got the attention of a committer a bit earlier


Question: ]; buildInputs = [ <del> llvmPackages_39.llvm llvmPackages_39.clang-unwrapped </del> <ins> llvmPackages_4.llvm llvmPackages_4.clang-unwrapped </ins> hiredis gtest ]; <ins> patches = [ ./cmake-fix.patch ]; </ins> enableParallelBuilding = true; preConfigure = ''

was recently updated to use LLVM 4.0, which is rather good news for my use cases. Can we update our version to use this? It also seems they now so perhaps we should switch to using that as well? (maintainer)--LMK your thoughts and if you want to tackle it or want me to (I'd probably get to it this weekend). Thanks!
I'm pretty busy these days but if you're interested in updating it feel free :+1:
Sure thing! Although actually we'll need to actually add LLVM 4.0 first, forgot that wasn't in-tree yet :innocent:. Maybe I'll give that a go as well :+1: (cc )


Question: preBuild = stdenv.lib.optionalString stdenv.isDarwin "unset AR"; <ins> GRPC_BUILD_WITH_BORING_SSL_ASM = ""; </ins> GRPC_PYTHON_BUILD_SYSTEM_OPENSSL = 1; GRPC_PYTHON_BUILD_SYSTEM_ZLIB = 1; GRPC_PYTHON_BUILD_SYSTEM_CARES = 1;

Describe the bug is broken in latest master To Reproduce Steps to reproduce the behavior: -build -A lieer cc
I reverted locally, and got it to build again - so it's definitely some incompatibility with the openssl we pass in.
that commit is from 4 years ago, I wonder why it's making an appearance now
This error seems to be present since (more specifically ), so is probably mostly unrelated to it.


Question: "network-online.target" ]; <del> path = lib.mkIf config.boot.zfs.enabled [ config.boot.zfs.package ]; </del> <ins> path = lib.mkIf config.boot.zfs.enabled [ config.boot.zfs.package "${config.boot.zfs.package}/lib/udev" ]; </ins> environment = { # Override Path to the LXC template configuration directory

Incus fails to find when launching a VM. (There is no problem launching a container.) It exits with the error message: Lines 1815-1824 of in the looks for it at or in the path. I think it means that there is a fixup that isn't being done. Steps to reproduce the behavior: (The specific image doesn't seem to matter.) while the VM is created... It exits with the error message above. that is installed at just not being found. Launching a VM should work as expected without the error message. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
While that path does appear to be hardcoded in Incus, I'm not able to recreate the error on my zfs storage pool. Can you provide more information about your storage setup, including the output of
Never mind I see the problem. Will take some time to get this reviewed, backported, and available to 23.11


Question: # Needs GCC rocprofiler = callPackage ./rocprofiler { <ins> inherit rocmUpdateScript clr rocm-core rocm-thunk rocm-device-libs roctracer rocdbgapi rocm-smi hsa-amd-aqlprofile-bin; </ins> inherit (llvm) clang; <del> inherit rocmUpdateScript clr rocm-thunk roctracer rocm-smi hsa-amd-aqlprofile-bin; </del> }; # Needs GCC

When trying to use rocprofv2: This might have something to do with some predefined paths in Steps to reproduce the behavior: an executable with hipcc it with rocprofv2 <!-- 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.
I need to do some work with . need to make a patch that strips. I need to fix itself. I wonder if it's because I'm stripping out the test directories? Also yes, it looks like you're right. You can fix that by prepending too, so I'm not entirely sure it'll work. Try setting `. You may just be able to run it from that as well.
I don't think that removing hsa-amd-aqlprofile-bin is a good idea, because without it, it loses performance counters support. I think there should at least be a rocprof derivation with aqlprofile.
My bad, I forgot to add that the patch is optional.
Right. Could you tell me your test environment and the source of the hip executable (or just some stub) so I can replicate this? I've never actually used rocprofiler.
You can try this, it just prints 10 numbers, it can be compiled with hipcc without any flag. I am using a radeon rx6600m(gfx1032).
see


Question: buildPythonPackage rec { pname = "libvirt"; <del> version = "8.5.0"; </del> <ins> version = "8.6.0"; </ins> src = fetchFromGitLab { owner = "libvirt"; repo = "libvirt-python"; rev = "v${version}"; <del> sha256 = "sha256-/OS+qBo0h9jshKDuxKX++cRPAjegImQROb7Uh+imOUA="; </del> <ins> sha256 = "sha256-eJ0RPxJ4Gm+VGs6NeTWP2FbvDnJy4mURPlFbgvkSgo0="; </ins> }; nativeBuildInputs = [ pkg-config ];

When attempting to create a volume on a physical node pool parted is not found. Steps to reproduce the behavior: Create a physical disk node pool. Attempt to create a volume using that node pool. In this case I have created a node pool called and I am attempting to create a volume called Volume is created normally. If applicable, add screenshots to help explain your problem. I have tried to add parted manually using and overriding the package in the libvirtd module: but this did not fix the issue.
That won't work, it seems like we need to wrap to include in its . I'll take a look.
You most likely need to add it to in because libvirtd will probably call it.


Question: buildPythonPackage rec { pname = "libvirt"; <del> version = "8.5.0"; </del> <ins> version = "8.6.0"; </ins> src = fetchFromGitLab { owner = "libvirt"; repo = "libvirt-python"; rev = "v${version}"; <del> sha256 = "sha256-/OS+qBo0h9jshKDuxKX++cRPAjegImQROb7Uh+imOUA="; </del> <ins> sha256 = "sha256-eJ0RPxJ4Gm+VGs6NeTWP2FbvDnJy4mURPlFbgvkSgo0="; </ins> }; nativeBuildInputs = [ pkg-config ];

I sometimes create a qemu VM in libvirt in "session mode", meaning that the libvirt daemon is running as my non-root user, and the system-wide libvirtd does not need to be running (). This VM has a network bridge, which libvirt apparently creates by calling , which in turn uses . The problem is that doesn't get fully populated until the system libvirtd gets started. Previously, in nixpkgs (from February), this wasn't noticeable because libvirtd.service was WantedBy libvirt-guests.service (which is WantedBy multi-), so libvirtd would always be started on boot to populate that directory. Now, with , this is no longer the case, and libvirtd.service does not get started (presumably, if libvirt-guests.service actually needed to start a VM, then libvirtd.service would be socket-activated, but for me this is not the case). As a result, doesn't get populated and my session-mode libvirt can't find . python: The VM's XML file defines a network bridge, which is why gets involved. the following output: The libvirt user session should be usable without first starting the system-wide libvirtd. If you start (and optionally stop) the system libvirtd.service before following the steps to reproduce, everything works fine, because the directory gets populated. Probably, should be put somewhere else, where session-mode daemons can use it without needing to have previously started system-mode libvirtd. (The same may be true of other stuff in too.) libvirt maintainers: Okay, but I'm using flakes and that channel looks old. See relevant commit hashes above.
Oof, happy to find this, it would have taken me a long time to figure out I needed to run first. Can't the sudo wrapper point to the file in the nix store?


Question: hash = "sha256-cyyxu/oj4QEFp3CVx2WeXa9T4OAUyynuBJHGkBZSxJI="; }; <ins> patches = [ # CMake formatting, required for the next two commits to cleanly apply (fetchpatch { url = "https://github.com/hyprwm/xdg-desktop-portal-hyprland/commit/5555f467f68ce7cdf1060991c24263073b95e9da.patch"; hash = "sha256-yNkg7GCXDPJdsE7M6J98YylnRxQWpcM5N3olix7Oc1A="; }) # removes wayland-scanner from deps, as it includes a pkg-config that # defines that it has a non-existent include directory which trips up CMake (fetchpatch { url = "https://github.com/hyprwm/xdg-desktop-portal-hyprland/commit/0dd9af698b9386bcf25d3ea9f5017eca721831c1.patch"; hash = "sha256-Y6eWASHoMXVN2rYJ1rs0jy2qP81/qbHsZU+6b7XNBBg="; }) # handle finding wayland-scanner more nicely (fetchpatch { url = "https://github.com/hyprwm/xdg-desktop-portal-hyprland/commit/2425e8f541525fa7409d9f26a8ffaf92a3767251.patch"; hash = "sha256-6dCg/U/SIjtvo07Z3tn0Hn8Xwx72nwVz6Q2cFnObonU="; }) ]; depsBuildBuild = [ pkg-config ]; </ins> nativeBuildInputs = [ cmake pkg-config

Steps to reproduce the behavior: xdg-desktop-portal-hyprland-1.3.3 This issue only recently occurred upon updating to the latest revision. My entire nix config is . <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
I suspect this is fixed by For some reason has a pkg-config that defines that it has a non-existent include directory, which cmake then later chokes on since it declares it has a dependency on as a package, not a tool.
Indeed. I'm cooking up a PR for this.


Question: ./qtbase.patch ./qtbase-darwin.patch ./qtbase-revert-no-macos10.10.patch <ins> ] ++ optionals stdenv.isDarwin [ ./qtbase-darwin-nseventtype.patch </ins> ]; qtdeclarative = [ ./qtdeclarative.patch ]; qtscript = [ ./qtscript.patch ];

It looks like Qt has broken support for SDK 10.10 in their latest release. Here is the log: Any ideas on how we can fix this?
fixes this.
We should probably keep this open tho, we can't keep using


Question: install -Dm644 ../packaging/linux/${pname}.desktop $out/share/applications/${pname}.desktop ''; <del> passthru.updateScript = ./updater.sh; </del> <ins> passthru = { tests.sunshine = nixosTests.sunshine; updateScript = ./updater.sh; }; </ins> meta = with lib; { description = "Sunshine is a Game stream host for Moonlight";

Project description <!-- Describe the project a little: --Sunshine has already been packaged here in nixpkgs: But it doesn't come out of the box just by , according to and and , at least it needs a and maybe . It would be better if we could add a NixOS module for it to make it availale just by sth. like or . CC maintainer Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
This has been on my to-do list for ages :) The module itself wouldn't be a huge deal, and I think I have a plan for tests, just need some time to work on it.
I actually started working on this a while ago. My module can create valid and files (i.e. they work when I start sunshine manually) and open the necessary ports, however I couldn't get the systemd service to function properly. If I recall correctly, the issue was related to getting access to the screen. Here is what I have so far, maybe it can help someone:
Thanks I used yours as inspiration and opened for this. It's still a draft -- I need to work on the tests -- but any testing or comments are welcome. I've tested on Plasma 6 + Wayland + AMD and seems to work, have not tested much with Xorg or NVIDIA.
Think it's got all the functionality I had planned -- marked as ready for review.


Question: <ins> getTargetRole getTargetRoleWrapper export FC${role_post}=@named_fc@ # If unset, assume the default hardening flags. # These are different for fortran. : ${NIX_HARDENING_ENABLE="stackprotector pic strictoverflow relro bindnow"} export NIX_HARDENING_ENABLE unset -v role_post </ins>

Describe the bug To Reproduce Expected behavior The derivation to build an executable called Additional context It fails with also but succeeds with but so 1.3 seems to be a recent addition even though julia is on 1.4 and about to move to 1.5. Notify maintainers Metadata Please run and paste the result.
Same issue here: system: host os: multi-user?: sandbox: version: channels(root): channels(jfelice): nixpkgs: This prevents installing GNU octave on MacOS.
FWIW I was able to work around this issue by creating a to disable the checks in arpack: I was able to build octave successfully with that. I had to hack around a runtime issue finding , will log that as a separate issue.


Question: <ins> getTargetRole getTargetRoleWrapper export FC${role_post}=@named_fc@ # If unset, assume the default hardening flags. # These are different for fortran. : ${NIX_HARDENING_ENABLE="stackprotector pic strictoverflow relro bindnow"} export NIX_HARDENING_ENABLE unset -v role_post </ins>

Describe the bug I'd like to build the python numpy package on an x86 machine for the armv7 architecture. numpy requires liblapack and blas, which require gfortran I already fixed one issue which is that liblapack couldn't find the gfortran compiler (see the overlay below) I'm trying to use the 20.03 release, latest commit. Here's what I'm running exactly: To Reproduce Steps to reproduce the behavior: -build here's the error I get Expected behavior The derivation builds Metadata Please run and paste the result. Maintainer information:
Maybe related to: ?
I'm not getting this in NixOS. It looks like a sandboxing issue. Can you try running this:
Thanks for responding! I launched this build on NixOs using an AMI on EC2 and I get the same result as in the issue report, here are the system details:
A similar issue exists on unstable when building for x86. Currently on: system: host os: multi-user?: sandbox: version: channels(root): channels(swflint): nixpkgs:


Question: , attr , bash , btrfs-progs <ins> , cdrkit </ins> , criu , dnsmasq <ins> , e2fsprogs , getent </ins> , gnutar , gptfdisk , gzip , iproute2 , iptables <ins> , kmod , lvm2 , minio , nftables </ins> , OVMF , qemu_kvm , qemu-utils , rsync , spice-gtk , squashfsTools <ins> , thin-provisioning-tools </ins> , util-linux , virtiofsd , xz

When tries to create a volume of type=block, it cannot be created due to the occurrence of . This is because is not registered in . Steps to reproduce the behavior: Create block type volume. If you check nixpkgs for lxd 5.20, you can see other package dependencies that are not present in incus. For example with lvm, this is expected to severely impact the lvm backend. (Currently, it cannot be confirmed because there is no lvm drive.) Can we change it in the same way as lxd? <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Opened a PR to fix. Sorry about that. Not sure why I dropped these...


Question: python3.pkgs.buildPythonApplication rec { pname = "gitless"; <del> version = "0.8.8"; </del> <ins> version = "0.9.17"; </ins> format = "setuptools"; src = fetchFromGitHub { <del> owner = "gitless-vcs"; </del> <ins> owner = "goldstar611"; </ins> repo = pname; <del> rev = "v${version}"; hash = "sha256-xo5EWtP2aN8YzP8ro3bnxZwUGUp0PHD0g8hk+Y+gExE="; </del> <ins> rev = version; hash = "sha256-XDB1i2b1reMCM6i1uK3IzTnsoLXO7jldYtNlYUo1AoQ="; </ins> }; nativeBuildInputs = [ python3.pkgs.pythonRelaxDepsHook ]; propagatedBuildInputs = with python3.pkgs; [ <del> sh </del> pygit2 <del> clint </del> <ins> argcomplete </ins> ]; pythonRelaxDeps = [ "pygit2" ];

The original author of gitless has not committed any code to it since 2021, and the version currently in nixpkgs errors out when trying to do anything useful with it. has forked and continued to develop it though: Package name: gitless Latest released version: 0.9.17 Current version on the unstable channel: 0.8.8 Current version on the stable/release channel: 0.8.8 Notify maintainers: <!-- If the result shows no maintainers, tag the person that last updated the package. --Note for maintainers: Please tag this issue in your PR.
Thanks for the tag! I'm glad that gitless can live on past the initial MIT research that was conducted. Although it's been a while since I've updated gitless, it has been very useful for my day to day work and I'm committed to fixing bugs in a timely manner.
Sure! I rediscovered gitless (and your fork) on the back of a recent Slack discussion with folks from about the best way to make version control as accessible as possible for newcomers in the research community.


Question: in stdenv.mkDerivation rec { pname = "mwprocapture"; <del> subVersion = "4373"; </del> <ins> subVersion = "4390"; </ins> version = "1.3.0.${subVersion}-${kernel.version}"; src = fetchurl { url = "https://www.magewell.com/files/drivers/ProCaptureForLinux_${subVersion}.tar.gz"; <del> sha256 = "sha256-/6q+6CTlgkHOgq1PF8dSPfl/xm/UFczr/AGkac2mXZ8="; </del> <ins> sha256 = "sha256-HOVAR9auc8ulENPLoI0scdCMZoSbDYkTaCLgZoFG7eU="; </ins> }; nativeBuildInputs = kernel.moduleBuildDependencies;

Version V1.3.0.4373 of mwprocapture (the Linux driver for the Magewell Pro Capture family) FTBFS when building against Linux 6.8 or newer. Steps to reproduce the behavior: Add to your Nix configuration. Add to your Nix configuration. Magewell has provided a revised driver update to address this issue. I am working on a pull request for nixpkgs. Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:


Question: clang, libbpf, bpftools, <ins> fetchurl, </ins> }: let <del> # Compare with https://github.com/draios/sysdig/blob/0.38.0/cmake/modules/falcosecurity-libs.cmake </del> <ins> # Compare with https://github.com/draios/sysdig/blob/0.38.1/cmake/modules/falcosecurity-libs.cmake </ins> libsRev = "0.17.2"; libsHash = "sha256-BTLXtdU7GjOJReaycHvXkSd2vtybnCn0rTR7OEsvaMQ=";

Steps to reproduce the behavior: sysdig Add any other context about the problem here. Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Can't repro on master () and the error isn't in the log output, can you provide additional info?
Hey, thanks for the response - checking again - it only happens if for me if I enable the sysdig-option in my config not building the sysdig-package - maybe this helps to reproduce and depends on the used kernel-version? I've uploaded the full build log:
Thanks, seems this is the error:
I guess this is already fixed upstream in the drivers () but needs to be to nixpkgs to fix 6.10-kernel builds.
fixes it for me
~Ah 0.38.1 - got released somehow oversaw it should check first if that includes the fix~ 38.1 does not include a driver-bump


Question: , pymongo , pytestCheckHook , python <del> , pythonAtLeast </del> , python-dateutil <ins> , pythonAtLeast , pythonRelaxDepsHook </ins> , pytz , pyyaml , requests , requests-mock <ins> , scikit-learn </ins> , setuptools , sqlalchemy , tenacity <del> , typing-extensions </del> , testcontainers <del> , scikit-learn }: </del> <ins> , typing-extensions }: </ins> buildPythonPackage rec { pname = "apache-beam";

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


Question: "--set LOCALE_ARCHIVE ${glibcLocales}/lib/locale/locale-archive" ]; <ins> # mixxx installs udev rules to DATADIR instead of SYSCONFDIR # let's disable this and install udev rules manually via postInstall # see https://github.com/mixxxdj/mixxx/blob/2.3.0/CMakeLists.txt#L1381-L1392 cmakeFlags = [ "-DINSTALL_USER_UDEV_RULES=OFF" ]; postInstall = lib.optionalString stdenv.isLinux '' rules="$src/res/linux/mixxx-usb-uaccess.rules" if [ ! -f "$rules" ]; then echo "$rules is missing, must update the Nix file." exit 1 fi mkdir -p "$out/lib/udev/rules.d" cp "$rules" "$out/lib/udev/rules.d/69-mixxx-usb-uaccess.rules" ''; </ins> meta = with lib; { homepage = "https://mixxx.org"; description = "Digital DJ mixing software";

Describe the bug When adding to the NixOS configuration the udev rules do not get installed. To Reproduce Steps to reproduce the behavior: mixxx with a DJ controller plugged in. controller is not recognized by mixxx Expected behavior The udev rules are in the correct folder i.e. or and therefore the udev service does not recognizes them. Additional context The fix in worked for me after a little modification (the rules file got renamed). Notify maintainers Metadata system: host os: multi-user?: sandbox: version: channels(root): nixpkgs:
Originally, mixxx did the right thing = install udev files to - see Later they changed the behaviour and they install to - see Sigh.


Question: <del> [ "de_DE" , "fr_FR" , "ro_RO" ] </del> <ins> { "de_DE": "gpl2Plus" , "fr_FR": "gpl2Plus" , "ro_RO": "gpl2Plus" } </ins>

The package with that are automatically fetched carry no license. ` cc
Poking upstream does not seem to yield anything. They did indicate they wouldn't support this use case, so what are you expecting from them?
I talked to the authors of wp4nix and they are happy for new contributions. It would be nice if the wp4nix script would somehow handle license informations, for example by manually defining them. Not quite sure yet how to implement it
If we don't know the licenses to these packages we honestly cannot keep them around. For example, it is absolutely unclear, whether we have a license to even redistribute them. Of course upstream will take patches, but they're not exactly in the same boat we are. I think your attitude towards the whole licensing situation around wp4nix/nc4nix and its resulting packages is alarming.
As written : Fixing this for Wordpress packages and themes (wp4nix) and Nextcloud apps (nc4nix) in a foreseeable time exceeds my skills and competence. Therefore I would like to offer to add a flag to these package sets and remove them for the next release 23.11 if it's not resolved by then.
Couldn't we mark them as unfree so they don't get cached on hydra but people can still use them if they want? Unfortunately it seems like the wordpress plugins repository doesn't seem to provide the license information in an easy manner. And I don't know whether it is stored somewhere else or can even be extracted from the derivation without import-from-derivation.
Actuallly we seem to be safe in theory. claims
In an ideal world, that would hold true, but it is up to the user and distributor to validate the final outcome. I therefore think this situation remains unresolved.


Question: sed -i '/TestDisasmExtld/areturn' src/cmd/objdump/objdump_test.go <ins> sed -i 's/unrecognized/unknown/' src/cmd/link/internal/ld/lib.go sed -i 's/unrecognized/unknown/' src/cmd/go/build.go </ins> touch $TMPDIR/group $TMPDIR/hosts $TMPDIR/passwd sed -i '1 aexit 0' misc/cgo/errors/test.bash

System: (macOS 10.11.6) Nix version: nix-env (Nix) 1.11.2 Nixpkgs version: 16.09pre-git
may fix this problem for you, though you may also wind up needing something like to get a functional set of go commands on darwin.


Question: mkdir build pushd build <del> cmake -G "Unix Makefiles" . ../third_party/ycmd/cpp -DPYTHON_LIBRARIES:PATH=${python}/lib/libpython2.7.so -DPYTHON_INCLUDE_DIR:PATH=${python}/include/python2.7 -DUSE_CLANG_COMPLETER=ON -DUSE_SYSTEM_LIBCLANG=ON </del> <ins> cmake -G "Unix Makefiles" . ../third_party/ycmd/cpp -DPYTHON_LIBRARIES:PATH=${python}/lib/libpython2.7.so -DPYTHON_INCLUDE_DIR:PATH=${python}/include/python2.7 -DUSE_CLANG_COMPLETER=ON  $EXTRA_CMAKE_ARGS </ins> make ycm_core -j''${NIX_BUILD_CORES} -l''${NIX_BUILD_CORES}} <del> ${python}/bin/python ../third_party/ycmd/build.py --gocode-completer --clang-completer --system-libclang </del> <ins> ${python}/bin/python ../third_party/ycmd/build.py --gocode-completer --clang-completer </ins> popd '';

Building on Darwin fails. The problem seems very similar to which was solved by —however I do not know how to apply that solution here.
Wasn't this fixed by merging
This issue is fixed, but it broke again recently. Same issue as but we use
Proposed
Fixed by


Question: c64-debugger = callPackage ../applications/emulators/c64-debugger { }; <ins> cameractrls-gtk4 = cameractrls.override { withGtk = 4; }; cameractrls-gtk3 = cameractrls.override { withGtk = 3; }; </ins> camunda-modeler = callPackage ../applications/misc/camunda-modeler { }; checkpointBuildTools = callPackage ../build-support/checkpoint-build.nix {};

Project description cameractrls is a UI for v4l camera settings, like pan/tilt/... on fancy Logitech cameras. Metadata homepage URL: source URL: license: MIT platforms: Linux
Here's a prototype:
I'm using this successfully with the latest version,
Is there any progress with this request?
Please test my PR I don't have the device.
Tbh, I would like to, but I don't know how to test a custom package...
For new CLI: Or
I executed and then nothing happened... I can also not find cameractrls
Check your current directory, there's a symlink to store, and the executable is in
I only tested the gui app and it seems to work fine!
Thanks! What about the others executables? Have you tested all the functionality of the app?
I can only test the the GUI, because I don't know how to use the CLI program. But the GUI is working fine, afaict.


Question: type = types.str; default = poolName; description = '' <del> Name of the phpfpm pool to use and setup. If not specified, a pool will be created </del> <ins> Name of the php-fpm pool to use and setup. If not specified, a pool will be created </ins> with default values. ''; };

When enabling freshrss and rebuilding, no freshrss systemd service is started. Steps to reproduce the behavior: (as well other requirements for minimal config) (with , for me) The only freshrss units are and . to in browser. Unable to connect. A service with (or something?) is created and runs automatically. The http server is accessible from a browser. I initially tried running in a container, but running on the host OS had the same result Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Freshrss doesn't run as a systemd service. It runs under php-fpm. The associated systemd service is . This is then exposed via nginx. I believe the default nginx configuration will expose freshrss on port 80, so http://localhost may work for your current configuration. The used by nginx for freshrss is . My guess is you'll need to configure it. If you want to access freshrss via "http://localhost:8080" you could use a config like:
Sorry I never responded to this! This worked, thank you.
i guess we can close this then? please report back if i am wrong.
I do agree with qyriad that this could be explicitly documented better, but I don't have any further issue to specifically track
any specific location where you want this documented? where would you look something like this up?
I would probably put in the description of the option.


Question: ''; }; }; specialisation.dns-01.configuration = {pkgs, config, nodes, lib, ...}: { security.acme.certs."example.test" = { domain = "*.example.test";

I use enabled. I also have a web server service that specifies: Because my web server is a bit long to start, the timeout and its systemd unit fails. To Reproduce Use the following example module: Expected behavior The acme systemd units created by  should wait that nginx is started before starting. Metadata Maintainer information:
Should adding to what is already to  fix the issue?
Making a note that has the same code and presumably the same issue so any fix on should likely be ported to .
Thank you for the issue and reproducer. I'll have a closer look at this today
what exactly do you mean by "timeout" here by the way. could you provide some journal logs of this failure? I can try reproduce when I'm home, but maybe the logs are enough to understand what is going wrong
I mean "Timeout during connect (likely firewall problem)" in the logs below. Note that the hostname, email and domain have been redacted. Also notice the long time between and . nginx was not started when the Let's Encrypt tried to retrieve the challenge:
I'm scared that won't work. The lack of here is very deliberate pulls in (Through and ) to create fake certs, as nginx crashes hard when certificate paths aren't present. We want to start up before the acme challenge is initiated, as nginx is responsible for serving the director to complete it. If starts before nginx, it will always fail. It's all a bit mind-boggling and the dependencies are a bit complicated. I wish it was a bit more simpler too. However; isn't what we want here instead? We want to guarentee that is running before the certificate request is fired off. So adding a to might work? I'll see if that fixes it..
Absolutely, that is what I meant but I wrote it wrongly.
Should we go for the solution proposed?
Yep. I have a PR in the works on my machine. I'll try to get it out this week


Question: maintainers = with maintainers; [ goibhniu gilligan cko marsam ]; platforms = platforms.linux ++ platforms.darwin; mainProgram = "node"; <del> knownVulnerabilities = optional (versionOlder version "12") "This NodeJS release has reached its end of life. See https://nodejs.org/en/about/releases/."; </del> <ins> knownVulnerabilities = optional (versionOlder version "14") "This NodeJS release has reached its end of life. See https://nodejs.org/en/about/releases/."; </ins> }; passthru.python = python; # to ensure nodeEnv uses the same version

The NodeJS 12 release goes end-of-life on 2022-04-30, which needs handling before the next release. Worst case we update like in .


Question: destination = mkOption { type = types.str; example = "10.0.0.1:80"; <del> description = "Forward tcp connection to destination ip:port"; </del> <ins> description = "Forward connection to destination ip:port"; }; proto = mkOption { type = types.str; default = "tcp"; example = "udp"; description = "Protocol of forwarded connection"; </ins> }; }; }); default = []; <del> example = [ { sourcePort = 8080; destination = "10.0.0.1:80"; } ]; </del> <ins> example = [ { sourcePort = 8080; destination = "10.0.0.1:80"; proto = "tcp"; } ]; </ins> description = '' List of forwarded ports from the external interface to

Should there be an ability to specify UDP port forwarding in the nat module? It would necessitate an extra property in the forwarding list specification, like .
Has done this!


Question: seexpr = callPackage ../development/compilers/seexpr { }; <ins> selectdefaultapplication = libsForQt5.callPackage ../applications/misc/selectdefaultapplication { }; </ins> semgrep = python3.pkgs.callPackage ../tools/security/semgrep { }; semgrep-core = callPackage ../tools/security/semgrep/semgrep-core.nix { };

Project description  Selectdefaultapplication is a very simple GUI application that lets you define default applications on Linux in a sane way. Basically it just loads all installed applications by reading their .desktop files, reads the MimeType fields to see what it supports, and updates with what the user wants. Not all desktop environments provide such a tool, prompting for an agnostic tool. Metadata homepage URL: source URL: license: gpl2 platforms: linux Additional info: AUR package:
You can try using this in an overlay, use .
Seems to work!


Question: libwnck sassc udisks2 <ins> libX11 libXext libXNVCtrl </ins> ]; <ins> # Force link against Xext, otherwise build fails with: # ld: /nix/store/...-libXNVCtrl-495.46/lib/libXNVCtrl.a(NVCtrl.o): undefined reference to symbol 'XextAddDisplay' # ld: /nix/store/...-libXext-1.3.4/lib/libXext.so.6: error adding symbols: DSO missing from command line # https://github.com/stsdc/monitor/issues/292 NIX_LDFLAGS = "-lXext"; mesonFlags = [ "-Dindicator-wingpanel=enabled" ]; </ins> postPatch = '' chmod +x meson/post_install.py patchShebangs meson/post_install.py

<!-- 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: desired version: <!-- Search your package here: If no maintainer is listed for your package, tag the person that last updated the package --maintainers: are you already working on it? if not i can do it
I have some exams to take tomorrow, so maybe I cannot open a PR in 17 hours. Feel free to open one if you have done the update.
I just wanted to make sure you haven't started to work on it, so we don't do duplicate work. I wish you great success with the exams!
Just also have a try on this, fails with . Actually I have no idea what happened so I just opened , downstream workaround should be something like , actually this seems to work, builds and launches. <img src="https://user-" width=50%Also I noticed that we maybe need in , haven't tested yet.
downstream workaround should be something like , actually this seems to work, builds and launches. i don't understand what it does, but it works Also I noticed that we maybe need in , haven't tested yet. I noticed before that the indicators do not work. I'll try it.


Question: options = { services.flatpak = { enable = mkEnableOption "flatpak"; <del> extraPortals = mkOption { type = types.listOf types.package; default = []; description = '' List of additional portals to add to path. Portals allow interaction with system, like choosing files or taking screenshots. At minimum, a desktop portal implementation should be listed. GNOME already adds <package>xdg-desktop-portal-gtk</package>; for KDE, there is <package>xdg-desktop-portal-kde</package>. Other desktop environments will probably want to do the same. ''; }; </del> }; }; ###### implementation config = mkIf cfg.enable { environment.systemPackages = [ pkgs.flatpak ]; <del> services.dbus.packages = [ pkgs.flatpak pkgs.xdg-desktop-portal ] ++ cfg.extraPortals; </del> <ins> services.dbus.packages = [ pkgs.flatpak ]; </ins> <del> systemd.packages = [ pkgs.flatpak pkgs.xdg-desktop-portal ] ++ cfg.extraPortals; </del> <ins> systemd.packages = [ pkgs.flatpak ]; </ins> environment.profiles = [ "$HOME/.local/share/flatpak/exports" "/var/lib/flatpak/exports" ]; <del> environment.variables = { XDG_DESKTOP_PORTAL_PATH = map (p: "${p}/share/xdg-desktop-portal/portals") cfg.extraPortals; }; </del> }; }

It is possible to use Plasma’s native file dialogues in Firefox 64 to open or save a file. Currently this feature is not working in NixOS, and it seems to me some small changes would need to be made to derivation in order to enable it. I propose we include this option together with as a Firefox option in NixOS (see also: ). I followed the explanation on how to enable this feature as it was published on : Firefox (64 is current stable) from a terminal emulator But it produces the following error: system: host os: multi-user?: sandbox: version: channels(root): channels(hook): nixpkgs:
You'll probably have to do something like this to expose the dbus service:
Where? In:
It needs to go into a nixos module or your .


Question: # Misc. stuff. "pcips2" "atkbd" <ins> # Temporary fix for https://github.com/NixOS/nixpkgs/issues/18451 # Remove as soon as upstream gets fixed - marking it: # TODO # FIXME "i8042" </ins> # To wait for SCSI devices to appear. "scsi_wait_scan"

Linux Kernel 4.7.3 seems broken, as my laptops keyboard doesn't work. experienced by the arch community too: update, reboot - 4.6 and 4.7.2 work, 4.7.3 doesn't nixos-version: (Gorilla) nix-env --version: nix-env (Nix) 1.11.4 nix-instantiate --eval github/nixpkgs -A lib.nixpkgsVersion: ""
Same issue with kernel 4.4.20 (lts). I can no longer enter my cryptsetup password. The reason is that i8042 is no longer integrated in initramfs, I suppose because of: Update: To fix this issue I had to add it to
Thanks, created a quick fix with your solution, which should fix it for everyone


Question: which wrapGAppsHook ] <ins> ++ lib.optionals crashreporterSupport [ dump_syms ] </ins> ++ lib.optionals pgoSupport [ xvfb-run ] ++ extraNativeBuildInputs;

Steps to reproduce the behavior: librewolf from nixpkgs master Add any other context about the problem here. Please run and paste the result.
I have the exact same issue but my machine is a little slower :|. Also this means (not just Git ) is now broken.
I also reproduced this on master.
I think it's related to . I'm guessing the crash reporter symbols aren't generated because we disable the crash reporter. Running some tests to confirm.
is the first broken commit on master.
I'm going to close this. The PR by fixes the problem.


Question: sha256 = "1cidki3av9wnkgwi7fklxbg3bh6kysf8w3fk2qadjr05a92mx3zp"; }; <del> patchPhase = '' patchShebangs ./src/shaders/gpp.py ''; preConfigure = '' sed -i -e "s,LIBVA_DRIVERS_PATH=.*,LIBVA_DRIVERS_PATH=$out/lib/dri," configure ''; </del> <ins> # Set the correct install path: LIBVA_DRIVERS_PATH = "${placeholder "out"}/lib/dri"; </ins> postInstall = stdenv.lib.optionalString enableHybridCodec '' ln -s ${vaapi-intel-hybrid}/lib/dri/* $out/lib/dri/ ''; configureFlags = [ <del> "--enable-drm" </del> "--enable-x11" "--enable-wayland" ] ++ stdenv.lib.optional enableHybridCodec "--enable-hybrid-codec"; <del> nativeBuildInputs = [ autoreconfHook gnum4 pkgconfig python2 ]; </del> <ins> nativeBuildInputs = [ autoreconfHook gnum4 pkg-config python3 ]; </ins> buildInputs = [ intel-gpu-tools libdrm libva libX11 libXext libGL wayland ] ++ stdenv.lib.optional enableHybridCodec vaapi-intel-hybrid;

Describe the bug Upstream intel-vaapi-driver removed the --enable-drm ./configure option. It is now turned on by default. Happened in commit To Reproduce Steps to reproduce the behavior: the package and read through compile log Additional context This is a warning, package builds just fine despite this. Metadata Please run and paste the result. Maintainer information: (I don't know if I am dealing with attribute or module. I think attribute, but just to cover all bases.)
Thank you for your contributions. This has been automatically marked as stale because it has had no activity for 180 days. If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity. Here are suggestions that might help resolve this more quickly: for maintainers and people that previously touched the related code and @ mention them in a comment. on the . 3. Ask on the on .


Question: (mkRenamedOptionModule [ "networking" "dnsExtensionMechanism" ] [ "networking" "resolvconf" "dnsExtensionMechanism" ]) (mkRenamedOptionModule [ "networking" "extraResolvconfConf" ] [ "networking" "resolvconf" "extraConfig" ]) (mkRenamedOptionModule [ "networking" "resolvconfOptions" ] [ "networking" "resolvconf" "extraOptions" ]) <ins> (mkRemovedOptionModule [ "networking" "resolvconf" "useHostResolvConf" ] "This option was never used for anything anyways") </ins> ]; options = {

Describe the bug seems to be unused in NixOS. Instead it seems to be a duplicate of . When greping for the option, only references of the later are found. Metadata Maintainer information:
This issue has been mentioned on NixOS Discourse. There might be relevant details there:


Question: url = "https://github.com/mquinson/po4a/releases/download/v${version}/po4a-${version}.tar.gz"; sha256 = "0eb510a66f59de68cf7a205342036cc9fc08b39334b91f1456421a5f3359e68b"; }; <ins> patches = [ (fetchpatch { # make devdoc output reproducible # https://github.com/mquinson/po4a/pull/387 url = "https://github.com/mquinson/po4a/commit/df7433b58f6570558d44b6aac885c2a8f7862e51.patch"; sha256 = "9MVkYiItR2P3PBCUc4OhEOUHQuLqTWUYtYlZ3L8miC8="; }) ]; </ins> nativeBuildInputs = [ docbook_xsl docbook_xsl_ns ModuleBuild ]; propagatedBuildInputs = lib.optional (!stdenv.hostPlatform.isMusl) TextWrapI18N ++ [ LocaleGettext SGMLSpm UnicodeLineBreak PodParser YAMLTiny ]; # TODO: TermReadKey was temporarily removed from propagatedBuildInputs to unfreeze the build

Building this package twice does not produce the bit-by-bit identical result each time, making it harder to detect CI breaches. You can read more about this at https://reproducible- . nix-build '<nixpkgs' -A --check --keep-failed You can use to analyze the differences in the output of the two builds. To view the build log of the build that produced the artifact in the binary cache: nix-store --read-log $(nix-instantiate '<nixpkgs' -A ) Tested on nixpkgs
PR was merged and made it to nixos-unstable, so this should be fixed


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

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


Question: systemd = handleTest ./systemd.nix {}; systemd-confinement = handleTest ./systemd-confinement.nix {}; systemd-timesyncd = handleTest ./systemd-timesyncd.nix {}; <ins> systemd-networkd-wireguard = handleTest ./systemd-networkd-wireguard.nix {}; </ins> pdns-recursor = handleTest ./pdns-recursor.nix {}; taskserver = handleTest ./taskserver.nix {}; telegraf = handleTest ./telegraf.nix {};

This configuration: If you poke around in the configuration I linked, you should see that I disable NetworkManager and use a static configuration for my main NIC. I can't think of anything special in my config or with this machine that would affect my usage of Wireguard, but I'm also new to using Wireguard. I'm currently on nixpkgs with a few of my own commits on top of . Please run and paste the results.
It doesn't seem happy when already exists... I have done two things, both of which were necessary, to resolve this: the link manually () sure the path to the private key exists (if not, you get a different failure in the journal, with failing). (It's possible that fixing the private key path and rebooting would have been sufficient). I'm leaving this open for two reasons: user should receive a better error message in both cases. that we're in NixOS, we should assume full control of the interface and just re-configure it, instead of failing in the setup script.
I ran into this issue after trying to debug my wireguard setup. My setup is essentialy identical and I get the same error message. Running the start script that is causing the error results in this output. The offending 2 lines are .
I had to go one step further than deleting the interface. I needed to stop the via then redeploy configuration. But this solved it for me. Nixos should handle this much more gracefully.
I had to remove the routes with etc.
The command is . You can build it in your conf as pre-setup command, but it has the nasty side effect that it possible interferes with other connections.
I am still running into this issue.


Question: runHook postInstall ''; <del> passthru.tests = testers.testVersion { package = quickemu; }; </del> <ins> passthru.tests = testers.testVersion { version = "4.9.5"; # required for passing tests, TODO: remove when release bump package = quickemu; }; </ins> meta = { description = "Quickly create and run optimised Windows, macOS and Linux virtual machines";

There is a bug in the latest release of quickemu (present in nixpkgs), that sends invalid flags to qemu and thus doesn't work for MacOS (maybe others too). The fix I was planning to PR was to simply move the src to point to the most current revision. I wasn't 100% sure if that was something that I should do however, given it would set the precedent that we follow revisions for this package instead of the version tag, which may add maintenance burden. Just wanted opinions before I made a PR, would it be acceptable to bump the revision temporarily to avoid this issue? It's niche but its real and could affect users of this package. Steps to reproduce the behavior: Pops open a Qemu window with the appropriate screens. Fails with a strange "macos-ventura/macos- file not found", but it is related to the bugged release. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Don't know of any official policy on this. My opinion: If it's a single commit that fixes the issue, you can add a patch. If it's spread out over multiple commits, use current unstable, but that may introduce other unknown regressions and breaking changes. And in any case we'd go back to the release tag on the next release.
Patching sounds like a good idea, hopefully it is just one commit. Though honestly from personal testing the newest release worked perfectly fine (I tested via an override).


Question: sha256 = "020gyl8zv83ag6gbcchmqiyx9rh2jca7j8n52zx1gk4rck7kwc01"; }; <del> sourceRoot = "source/OpenEXR"; </del> outputs = [ "bin" "dev" "out" "doc" ]; <del> # Needed because there are some generated sources. Solution: just run them under QEMU. postPatch = '' for file in b44ExpLogTable dwaLookups do # Ecape for both sh and Automake emu=${lib.escapeShellArg (lib.replaceStrings ["$"] ["$$"] emulator)} before="./$file > $file.h" after="$emu $before" substituteInPlace IlmImf/Makefile.am  --replace "$before" "$after" done # Make sure the patch succeeded [[ $(grep "$emu" IlmImf/Makefile.am | wc -l) = 2 ]] ''; preConfigure = '' patchShebangs ./bootstrap ./bootstrap ''; nativeBuildInputs = [ pkgconfig autoconf automake libtool ]; </del> <ins> nativeBuildInputs = [ cmake libtool ]; </ins> propagatedBuildInputs = [ ilmbase zlib ]; enableParallelBuilding = true; <del> doCheck = false; # fails 1 of 1 tests </del> meta = with stdenv.lib; { description = "A high dynamic-range (HDR) image file format";

Describe the bug build of OpenEXR fails to find -lImath24 To Reproduce Expected behavior Successful build. Screenshots Additional context Add any other context about the problem here. Notify maintainers Metadata system: host os: multi-user?: sandbox: version: channels(root): channels(jfelice): nixpkgs: Maintainer information:
Something seems to be mangling the library names incorrectly? The ilmbase package contains: Notice the periods.
cc.
I lack the hardware to debug this. any ideas?
Repro'd on 10.14
seems to indicate that autoconf-based builds are only supported on linux - we may want to switch this to cmake. Building outside of nix via cmake is working fine for me.
can you give a try?
I can confirm this still builds on at least.
appears to fix this for me (macos 10.14). Reopen if it's still a problem for you.


Question: headers = "1v7ap1v520hhghw358k41aahpnaif54qbg6a9dwgmg1di0qwn735"; }; <del> electron_26-bin = mkElectron "26.1.0" { armv7l-linux = "4a4a6587bddce4554657f40fd9d39645ede03a375a1c42455c9b8d556698e5f5"; aarch64-linux = "1ed0996a06e97f5c23ceb8ae767873915c432c0aca5ffd4b37ab5fb1002d9d65"; x86_64-linux = "de78aed71ce17395675a29dcd20c1370473713eb234143dd0fa3e4c5a39504eb"; x86_64-darwin = "39a336baca218058011f39c4fa9a4275348ec7f411789262799d23c9669060d9"; aarch64-darwin = "f39aafcf480ef581161d3dc0b89a91c556dcaed45927ee0b612368016afe7b89"; headers = "134iqsjg6b80jwywccrhkhlrk6vj12d1nmfqbvlcl0d6cyqw6hys"; </del> <ins> electron_26-bin = mkElectron "26.2.1" { armv7l-linux = "27469331e1b19f732f67e4b3ae01bba527b2744e31efec1ef76748c45fe7f262"; aarch64-linux = "fe634b9095120d5b5d2c389ca016c378d1c3ba4f49b33912f9a6d8eb46f76163"; x86_64-linux = "be4ca43f4dbc82cacb4c48a04f3c4589fd560a80a77dbb9bdf6c81721c0064df"; x86_64-darwin = "007413187793c94cd248f52d3e00e2d95ed73b7a3b2c5a618f22eba7af94cd1a"; aarch64-darwin = "4e095994525a0e97e897aad9c1940c8160ce2c9aaf7b6792f31720abc3e04ee6"; headers = "02z604nzcm8iw29s5lsgjlzwn666h3ikxpdfjg2h0mffm82d0wfk"; </ins> }; }

Filing this issue to track related actions in nixpkgs. Feel free to send questions my way and/or contribute via comments in this issue! A buffer overflow in which allows a malicious actor to potentially get code execution in software that displays a specially crafted image file. This impacts pretty much all web browsers, as well as other software which might process or display untrusted images (image editing software, email clients, chat clients, social media clients, etc.). Chrome has rated this vulnerability as critical severity and has indicated that they have evidence some actors are already exploiting it in the wild. This vulnerability was very shortly referred to as CVE-2023-5129, but that second CVE for the same vulnerability has since been withdrawn. Firefox and Chromium are not vulnerable anymore as of 2023-09-16 in and . Direct dependents of the system are also not vulnerable anymore. Some applications bundle their own version of libwebp instead of using the system version (including some other web browsers in nixpkgs: Brave, Tor Browser, etc.). Each of these need to be updated separately by nixpkgs maintainers. See below for a list of all the known applications that need an update and their status. Review/merge any nixpkgs PR that you see pending in the task list below. Help figure out a course of action for . Report your findings and suggested course of action in a comment here, and I'll update the sheet and the task list below. If you have an idea of how to fix/address the vulnerability in any of the packages listed in the task list below, don't hesitate to post a comment here and send pull requests! Feel free to cc me on PRs so I can make sure they're tracked and they don't get lost.[x] libwebp is updated in staging-next (unstable: , 23.05: ) [x] This will make it to master via - said likely this weekend. [x] We need to merge staging-23.05 to release-23.05. That should also finish this week: [x] electron is also vulnerable. Upstream is making new releases on all their supported branches to include the patch. [x] electron 26 bumped in master (). [x] electron 25 bumped in master (). [x] electron 24 bumped in master ().


Question: headers = "1v7ap1v520hhghw358k41aahpnaif54qbg6a9dwgmg1di0qwn735"; }; <del> electron_26-bin = mkElectron "26.1.0" { armv7l-linux = "4a4a6587bddce4554657f40fd9d39645ede03a375a1c42455c9b8d556698e5f5"; aarch64-linux = "1ed0996a06e97f5c23ceb8ae767873915c432c0aca5ffd4b37ab5fb1002d9d65"; x86_64-linux = "de78aed71ce17395675a29dcd20c1370473713eb234143dd0fa3e4c5a39504eb"; x86_64-darwin = "39a336baca218058011f39c4fa9a4275348ec7f411789262799d23c9669060d9"; aarch64-darwin = "f39aafcf480ef581161d3dc0b89a91c556dcaed45927ee0b612368016afe7b89"; headers = "134iqsjg6b80jwywccrhkhlrk6vj12d1nmfqbvlcl0d6cyqw6hys"; </del> <ins> electron_26-bin = mkElectron "26.2.1" { armv7l-linux = "27469331e1b19f732f67e4b3ae01bba527b2744e31efec1ef76748c45fe7f262"; aarch64-linux = "fe634b9095120d5b5d2c389ca016c378d1c3ba4f49b33912f9a6d8eb46f76163"; x86_64-linux = "be4ca43f4dbc82cacb4c48a04f3c4589fd560a80a77dbb9bdf6c81721c0064df"; x86_64-darwin = "007413187793c94cd248f52d3e00e2d95ed73b7a3b2c5a618f22eba7af94cd1a"; aarch64-darwin = "4e095994525a0e97e897aad9c1940c8160ce2c9aaf7b6792f31720abc3e04ee6"; headers = "02z604nzcm8iw29s5lsgjlzwn666h3ikxpdfjg2h0mffm82d0wfk"; </ins> }; }

[x] electron 22 bumped in master (). [x] electron 26 bumped in 23.05 (). [x] electron 25 bumped in 23.05 (). [x] electron 24 bumped in 23.05 (). [x] electron 22 bumped in 23.05 (). [ ] We should figure out what else might be vendoring libwebp. Not sure if there's tooling for this? List of derivations to investigate further and possibly patch: [x] High risk stuff (mail clients, IM clients, web browsers) [x] armcord [x] caprine-bin (, ) [x] discord (, ) [x] Darwin version: / [x] fluffychat () [x] gitter (, ) [x] mailspring [x] mattermost-desktop ( / ) [x] mautrix-whatsapp ( / 23.05 ) [x] microsoft-edge ( / ) [x] mullvad-browser ( / ) [x] palemoon-bin (, ) [x] rocketchat-desktop ( / ) [x] signal-desktop (, ) [x] signal-desktop-beta ( / ) [x] slack ( / ) [x] threema-desktop (embedded electron not used) [x] tor-browser-bundle-bin ( / ) [x] tutanota-desktop ( / ) [ ] Libs that other stuff might depend on [x] flutter [x] libcef ( / ) [x] opencv ( / ) [x] qt5.qtimageformats ( / ) [ ] qtwebengine (darwin only, maybe?) [x] smooth ( / ) [x] darktable () [x] golden-cheetah-bin: ships a vulnerable prebuilt libwebp (cc: [ ] koreader: ships a vulnerable prebuilt libwebp (cc: [x] libreoffice () [ ] localsend: ships a vulnerable prebuilt libwebp (cc: [ ] obs-studio () [ ] rigsofrods-bin (ships a vulnerable prebuilt libwebp (cc: [x] Anything Rust that depends (transitively or not) on libwebp-sys2 < v0.1.8 libwebp-sys2 might silently decide to build its vendored version, if it can't find system libwebp or if the crate feature is enabled.


Question: headers = "1v7ap1v520hhghw358k41aahpnaif54qbg6a9dwgmg1di0qwn735"; }; <del> electron_26-bin = mkElectron "26.1.0" { armv7l-linux = "4a4a6587bddce4554657f40fd9d39645ede03a375a1c42455c9b8d556698e5f5"; aarch64-linux = "1ed0996a06e97f5c23ceb8ae767873915c432c0aca5ffd4b37ab5fb1002d9d65"; x86_64-linux = "de78aed71ce17395675a29dcd20c1370473713eb234143dd0fa3e4c5a39504eb"; x86_64-darwin = "39a336baca218058011f39c4fa9a4275348ec7f411789262799d23c9669060d9"; aarch64-darwin = "f39aafcf480ef581161d3dc0b89a91c556dcaed45927ee0b612368016afe7b89"; headers = "134iqsjg6b80jwywccrhkhlrk6vj12d1nmfqbvlcl0d6cyqw6hys"; </del> <ins> electron_26-bin = mkElectron "26.2.1" { armv7l-linux = "27469331e1b19f732f67e4b3ae01bba527b2744e31efec1ef76748c45fe7f262"; aarch64-linux = "fe634b9095120d5b5d2c389ca016c378d1c3ba4f49b33912f9a6d8eb46f76163"; x86_64-linux = "be4ca43f4dbc82cacb4c48a04f3c4589fd560a80a77dbb9bdf6c81721c0064df"; x86_64-darwin = "007413187793c94cd248f52d3e00e2d95ed73b7a3b2c5a618f22eba7af94cd1a"; aarch64-darwin = "4e095994525a0e97e897aad9c1940c8160ce2c9aaf7b6792f31720abc3e04ee6"; headers = "02z604nzcm8iw29s5lsgjlzwn666h3ikxpdfjg2h0mffm82d0wfk"; </ins> }; }

[x] () [x] catppuccin-catwalk () [x] Anything Rust that depends (transitively or not) on libwebp-sys < v0.9.3 Linking against system webp is intentionally not supported: [x] oculante [ ] .NET software that uses SkiaSharp. Upstream has yet to release a fixed version. () [ ] avalonia-ilspy [ ] BeatSaberModManager [ ] denaro [ ] galaxy-buds-client [ ] jellyfin [ ] mission-planner [ ] mqttmultimeter [ ] opentracker [ ] openutau [ ] ryujinx [ ] scarab [ ] wasabiwallet [ ] Go software linking with (, ) - broken down per vulnerable lib [ ] (unmaintained, likely never getting patched - action should be getting upstream to migrate away) [x] hydron ( / ) [x] mautrix-whatsapp () [ ] () [ ] hugo [ ] Godot related derivations: these should be unvendored (capability already exists in the build system). [ ] godot4 [ ] godot3 [ ] godot3-server [ ] godot3-headless [ ] godot3-export-templates Built using Godot [ ] lorien [ ] oh-my-git [ ] Electron apps where we ship upstream binaries instead of using nixpkgs electron Best course of action: upstream should update to electron = 26.2.1, = 25.8.1, = 24.8.3, or = 22.3.24 and tag a new release [ ] atom [ ] hakuneko [ ] hyper [ ] indigenous-desktop [ ] joplin-desktop [ ] keeweb (unmaintained, mark as insecure?) [ ] keybase-gui [ ] insomnia [ ] mullvad-vpn [ ] simplenoteFor derivations that vendor a vulnerable libwebp, priority list of preferred action to take: De-vendor libwebp and use the version from nixpkgs. (Difficult/impossible for binary provenance derivations.) Update to a new version from upstream that has a more recent libwebp patched for the vulnerability (TODO: how to check?) Mark as at some point if upstream can't be convinced to make a new release.


Question: headers = "1v7ap1v520hhghw358k41aahpnaif54qbg6a9dwgmg1di0qwn735"; }; <del> electron_26-bin = mkElectron "26.1.0" { armv7l-linux = "4a4a6587bddce4554657f40fd9d39645ede03a375a1c42455c9b8d556698e5f5"; aarch64-linux = "1ed0996a06e97f5c23ceb8ae767873915c432c0aca5ffd4b37ab5fb1002d9d65"; x86_64-linux = "de78aed71ce17395675a29dcd20c1370473713eb234143dd0fa3e4c5a39504eb"; x86_64-darwin = "39a336baca218058011f39c4fa9a4275348ec7f411789262799d23c9669060d9"; aarch64-darwin = "f39aafcf480ef581161d3dc0b89a91c556dcaed45927ee0b612368016afe7b89"; headers = "134iqsjg6b80jwywccrhkhlrk6vj12d1nmfqbvlcl0d6cyqw6hys"; </del> <ins> electron_26-bin = mkElectron "26.2.1" { armv7l-linux = "27469331e1b19f732f67e4b3ae01bba527b2744e31efec1ef76748c45fe7f262"; aarch64-linux = "fe634b9095120d5b5d2c389ca016c378d1c3ba4f49b33912f9a6d8eb46f76163"; x86_64-linux = "be4ca43f4dbc82cacb4c48a04f3c4589fd560a80a77dbb9bdf6c81721c0064df"; x86_64-darwin = "007413187793c94cd248f52d3e00e2d95ed73b7a3b2c5a618f22eba7af94cd1a"; aarch64-darwin = "4e095994525a0e97e897aad9c1940c8160ce2c9aaf7b6792f31720abc3e04ee6"; headers = "02z604nzcm8iw29s5lsgjlzwn666h3ikxpdfjg2h0mffm82d0wfk"; </ins> }; }

List of all software in nixpkgs known to contain libwebp:
is now out
i think one way you could check for vendored webp is with nix-locate, searching for , for example darktable might be vulnerable : possibly also koreader the full output
Thanks, that's indeed useful! I think the most common case though would be bundling the code and linking statically with the lib, which wouldn't necessarily be found by this - but maybe I'm just too pessimistic :) EDIT: the ones you found to the tracking in the issue's first comment so we don't lose track of it.
darktable: links with libwebp, the is an internal plugin and is not a vendored version.
koreader: binary provenance, ships a vulnerable prebuilt libwebp (cc:
localsend: binary provenance, ships a vulnerable prebuilt libwebp (cc:
golden-cheetah-bin: binary provenance, ships a vulnerable prebuilt libwebp (cc:
libreoffice sources file lists a libwebp- (or libwebp- for libreoffice-still)
, vendor libwebp via the rust crate libwebp-sys2
Ugh, and good luck finding all the things that end up transitively depending on that crate I guess. I suggested they file a GHSA so dependabot can go and do its thing, but it might still take a while to trickle down through dependents. Anyway, libwebp-sys2 version 0.1.8 looks like it's fixed.
There's also and I can't seem to find the vendored code by grepping for strings in the binaries. Would need further checking, but I'm tempted to say libreoffice is fine?
The libwebp-sys2 crate also will link against the system libwebp if it is found. I'm currently compiling a list of rust packages that use libwebp-sys2.
But since it transparently falls back to the vendored source, I'm going to assume most Rust programs in nixpkgs haven't bothered declaring libwebp (and pkg-config?) as buildInputs... But at least that might give us a lever to patch without requiring an upstream cargo deps bump?