Question:
tpm2-tss is unable to resolve the tabrmd loader located in the tpm2-abrmd package throwing this error when Steps to reproduce the behavior: the abrmd daemon and set the tcti environment interface to tabrmd tool or package using the tpm2-tss library It resolves the loader dynamically and works. I have narrowed down the cause to this commit making the dynamic loader only resolve locally from the library output. Reverting this in an overlay seems to have fixed the issue, but I am unsure if this would cause regressions as I am unsure why the dynamic loading got patched in the first place.
I patched the tpm2-tss because when using tpm2 as a library, the modules would not be up in the dlopen load path which would break modules loading. A couple more details here:
This was a bit more tricky than I expected, while other python packages gets the dlopen library name patched with the exact path this is not possible in this case due to tpm2-tss doing the loading as far I understand. Unless I remember wrong I think it might be possible to dlopen with the exact path in python before calling tpm2-tss init and ld might be able to resolve the already library loaded library, but I might remember wrong. But this would also be undesirable since you cannot dynamically resolve loaders this way I assume.
Ha! So the issue would be that tabmd tries to look up libtss2-tcti- and this is provided by tpm2-abrmd. I completely missed that.

+        return TSS2_TCTI_RC_BAD_VALUE; +    } +    *handle = dlopen(file_xfrm, RTLD_NOW); <del> if (*handle != NULL) { return TSS2_RC_SUCCESS; } else { @@ -94,7 +102,7 @@ handle_from_name(const char *file, /* 'name' alone didn't work, try libtss2-tcti-<name>.so.0 */ size = snprintf(file_xfrm, sizeof (file_xfrm), -                    TCTI_NAME_TEMPLATE_0, </del> <ins> +    if (*handle != NULL) { +        return TSS2_RC_SUCCESS; +    } else { +        LOG_DEBUG("Could not load TCTI file: "%s": %s", file, dlerror()); +    } +    /* 'name' alone didn't work, try libtss2-tcti-<name>.so.0 */ +    size = snprintf(file_xfrm, +                    sizeof (file_xfrm), </ins> +                    "@PREFIX@" TCTI_NAME_TEMPLATE_0, <del> file); if (size >= sizeof (file_xfrm)) { LOG_ERROR("TCTI name truncated in transform."); @@ -109,7 +117,7 @@ handle_from_name(const char *file, /* libtss2-tcti-<name>.so.0 didn't work, try libtss2-tcti-<name>.so */ size = snprintf(file_xfrm, sizeof (file_xfrm), -                    TCTI_NAME_TEMPLATE, </del> <ins> +                    file); +    if (size >= sizeof (file_xfrm)) { +        LOG_ERROR("TCTI name truncated in transform."); +        return TSS2_TCTI_RC_BAD_VALUE; +    } +    *handle = dlopen(file_xfrm, RTLD_NOW); +    if (*handle != NULL) { +        return TSS2_RC_SUCCESS; +    } else { +        LOG_DEBUG("Could not load TCTI file "%s": %s", file, dlerror()); +    } +    /* libtss2-tcti-<name>.so.0 didn't work, try libtss2-tcti-<name>.so */ +    size = snprintf(file_xfrm, +                    sizeof (file_xfrm), </ins> +                    "@PREFIX@" TCTI_NAME_TEMPLATE, <del> file); if (size >= sizeof (file_xfrm)) { LOG_ERROR("TCTI name truncated in transform."); </del> <ins> +                    file); +    if (size >= sizeof (file_xfrm)) { +        LOG_ERROR("TCTI name truncated in transform."); +        return TSS2_TCTI_RC_BAD_VALUE; +    } +    *handle = dlopen(file_xfrm, RTLD_NOW); if (*handle == NULL) { LOG_DEBUG("Failed to load TCTI for name "%s": %s", file, dlerror()); return TSS2_TCTI_RC_NOT_SUPPORTED; diff --git a/test/unit/tctildr-dl.c b/test/unit/tctildr-dl.c index 873a4531..c17b939e 100644 --- a/test/unit/tctildr-dl.c +++ b/test/unit/tctildr-dl.c @@ -223,6 +223,18 @@ test_get_info_default_success (void **state) expect_value(__wrap_dlopen, flags, RTLD_NOW); will_return(__wrap_dlopen, NULL); +    expect_string(__wrap_dlopen, filename, "@PREFIX@/libtss2-tcti-default.so"); +    expect_value(__wrap_dlopen, flags, RTLD_NOW); +    will_return(__wrap_dlopen, NULL); + +    expect_string(__wrap_dlopen, filename, "@PREFIX@/libtss2-tcti-libtss2-tcti-default.so.so.0"); +    expect_value(__wrap_dlopen, flags, RTLD_NOW); +    will_return(__wrap_dlopen, NULL); + +    expect_string(__wrap_dlopen, filename, "@PREFIX@/libtss2-tcti-libtss2-tcti-default.so.so"); +    expect_value(__wrap_dlopen, flags, RTLD_NOW); +    will_return(__wrap_dlopen, NULL); + expect_string(__wrap_dlopen, filename, "libtss2-tcti-tabrmd.so.0"); expect_value(__wrap_dlopen, flags, RTLD_NOW); will_return(__wrap_dlopen, HANDLE); @@ -255,6 +267,18 @@ test_get_info_default_info_fail (void **state) expect_value(__wrap_dlopen, flags, RTLD_NOW); will_return(__wrap_dlopen, NULL); +    expect_string(__wrap_dlopen, filename, "@PREFIX@/libtss2-tcti-default.so"); +    expect_value(__wrap_dlopen, flags, RTLD_NOW); +    will_return(__wrap_dlopen, NULL); + +    expect_string(__wrap_dlopen, filename, "@PREFIX@/libtss2-tcti-libtss2-tcti-default.so.so.0"); +    expect_value(__wrap_dlopen, flags, RTLD_NOW); +    will_return(__wrap_dlopen, NULL); + +    expect_string(__wrap_dlopen, filename, "@PREFIX@/libtss2-tcti-libtss2-tcti-default.so.so"); +    expect_value(__wrap_dlopen, flags, RTLD_NOW); +    will_return(__wrap_dlopen, NULL); + expect_string(__wrap_dlopen, filename, "libtss2-tcti-tabrmd.so.0"); expect_value(__wrap_dlopen, flags, RTLD_NOW); will_return(__wrap_dlopen, HANDLE); @@ -407,6 +431,15 @@ test_tcti_fail_all (void **state) expect_string(__wrap_dlopen, filename, "libtss2-tcti-libtss2-tcti-default.so.so"); expect_value(__wrap_dlopen, flags, RTLD_NOW); will_return(__wrap_dlopen, NULL); +    expect_string(__wrap_dlopen, filename, "@PREFIX@/libtss2-tcti-default.so"); +    expect_value(__wrap_dlopen, flags, RTLD_NOW); +    will_return(__wrap_dlopen, NULL); +    expect_string(__wrap_dlopen, filename, "@PREFIX@/libtss2-tcti-libtss2-tcti-default.so.so.0"); +    expect_value(__wrap_dlopen, flags, RTLD_NOW); +    will_return(__wrap_dlopen, NULL); +    expect_string(__wrap_dlopen, filename, "@PREFIX@/libtss2-tcti-libtss2-tcti-default.so.so"); +    expect_value(__wrap_dlopen, flags, RTLD_NOW); +    will_return(__wrap_dlopen, NULL); /* Skip over libtss2-tcti-tabrmd.so */ expect_string(__wrap_dlopen, filename, "libtss2-tcti-tabrmd.so.0"); @@ -418,6 +451,15 @@ test_tcti_fail_all (void **state) expect_string(__wrap_dlopen, filename, "libtss2-tcti-libtss2-tcti-tabrmd.so.0.so"); expect_value(__wrap_dlopen, flags, RTLD_NOW); will_return(__wrap_dlopen, NULL); +    expect_string(__wrap_dlopen, filename, "@PREFIX@/libtss2-tcti-tabrmd.so.0"); +    expect_value(__wrap_dlopen, flags, RTLD_NOW); +    will_return(__wrap_dlopen, NULL); +    expect_string(__wrap_dlopen, filename, "@PREFIX@/libtss2-tcti-libtss2-tcti-tabrmd.so.0.so.0"); +    expect_value(__wrap_dlopen, flags, RTLD_NOW); +    will_return(__wrap_dlopen, NULL); +    expect_string(__wrap_dlopen, filename, "@PREFIX@/libtss2-tcti-libtss2-tcti-tabrmd.so.0.so"); +    expect_value(__wrap_dlopen, flags, RTLD_NOW); +    will_return(__wrap_dlopen, NULL); /* Skip over libtss2-tcti-device.so, /dev/tpmrm0 */ expect_string(__wrap_dlopen, filename, "libtss2-tcti-device.so.0"); @@ -429,6 +471,15 @@ test_tcti_fail_all (void **state) expect_string(__wrap_dlopen, filename, "libtss2-tcti-libtss2-tcti-device.so.0.so"); expect_value(__wrap_dlopen, flags, RTLD_NOW); will_return(__wrap_dlopen, NULL); +    expect_string(__wrap_dlopen, filename, "@PREFIX@/libtss2-tcti-device.so.0"); +    expect_value(__wrap_dlopen, flags, RTLD_NOW); +    will_return(__wrap_dlopen, NULL); +    expect_string(__wrap_dlopen, filename, "@PREFIX@/libtss2-tcti-libtss2-tcti-device.so.0.so.0"); +    expect_value(__wrap_dlopen, flags, RTLD_NOW); +    will_return(__wrap_dlopen, NULL); +    expect_string(__wrap_dlopen, filename, "@PREFIX@/libtss2-tcti-libtss2-tcti-device.so.0.so"); +    expect_value(__wrap_dlopen, flags, RTLD_NOW); +    will_return(__wrap_dlopen, NULL); /* Skip over libtss2-tcti-device.so, /dev/tpm0 */ expect_string(__wrap_dlopen, filename, "libtss2-tcti-device.so.0"); @@ -440,6 +491,15 @@ test_tcti_fail_all (void **state) expect_string(__wrap_dlopen, filename, "libtss2-tcti-libtss2-tcti-device.so.0.so"); expect_value(__wrap_dlopen, flags, RTLD_NOW); will_return(__wrap_dlopen, NULL); +    expect_string(__wrap_dlopen, filename, "@PREFIX@/libtss2-tcti-device.so.0"); +    expect_value(__wrap_dlopen, flags, RTLD_NOW); +    will_return(__wrap_dlopen, NULL); +    expect_string(__wrap_dlopen, filename, "@PREFIX@/libtss2-tcti-libtss2-tcti-device.so.0.so.0"); +    expect_value(__wrap_dlopen, flags, RTLD_NOW); +    will_return(__wrap_dlopen, NULL); +    expect_string(__wrap_dlopen, filename, "@PREFIX@/libtss2-tcti-libtss2-tcti-device.so.0.so"); +    expect_value(__wrap_dlopen, flags, RTLD_NOW); +    will_return(__wrap_dlopen, NULL); /* Skip over libtss2-tcti-swtpm.so */ expect_string(__wrap_dlopen, filename, "libtss2-tcti-swtpm.so.0"); @@ -451,6 +511,15 @@ test_tcti_fail_all (void **state) expect_string(__wrap_dlopen, filename, "libtss2-tcti-libtss2-tcti-swtpm.so.0.so"); expect_value(__wrap_dlopen, flags, RTLD_NOW); will_return(__wrap_dlopen, NULL); +    expect_string(__wrap_dlopen, filename, "@PREFIX@/libtss2-tcti-swtpm.so.0"); +    expect_value(__wrap_dlopen, flags, RTLD_NOW); +    will_return(__wrap_dlopen, NULL); +    expect_string(__wrap_dlopen, filename, "@PREFIX@/libtss2-tcti-libtss2-tcti-swtpm.so.0.so.0"); +    expect_value(__wrap_dlopen, flags, RTLD_NOW); +    will_return(__wrap_dlopen, NULL); +    expect_string(__wrap_dlopen, filename, "@PREFIX@/libtss2-tcti-libtss2-tcti-swtpm.so.0.so"); +    expect_value(__wrap_dlopen, flags, RTLD_NOW); +    will_return(__wrap_dlopen, NULL); /* Skip over libtss2-tcti-mssim.so */ expect_string(__wrap_dlopen, filename, "libtss2-tcti-mssim.so.0"); @@ -462,6 +531,15 @@ test_tcti_fail_all (void **state) expect_string(__wrap_dlopen, filename, "libtss2-tcti-libtss2-tcti-mssim.so.0.so"); expect_value(__wrap_dlopen, flags, RTLD_NOW); will_return(__wrap_dlopen, NULL); +    expect_string(__wrap_dlopen, filename, "@PREFIX@/libtss2-tcti-mssim.so.0"); +    expect_value(__wrap_dlopen, flags, RTLD_NOW); +    will_return(__wrap_dlopen, NULL); +    expect_string(__wrap_dlopen, filename, "@PREFIX@/libtss2-tcti-libtss2-tcti-mssim.so.0.so.0"); +    expect_value(__wrap_dlopen, flags, RTLD_NOW); +    will_return(__wrap_dlopen, NULL); +    expect_string(__wrap_dlopen, filename, "@PREFIX@/libtss2-tcti-libtss2-tcti-mssim.so.0.so"); +    expect_value(__wrap_dlopen, flags, RTLD_NOW); +    will_return(__wrap_dlopen, NULL); TSS2_RC r; TSS2_TCTI_CONTEXT *tcti; @@ -490,6 +568,15 @@ test_info_from_name_handle_fail (void **state) expect_string(__wrap_dlopen, filename, "libtss2-tcti-foo.so"); expect_value(__wrap_dlopen, flags, RTLD_NOW); will_return(__wrap_dlopen, NULL); +    expect_string(__wrap_dlopen, filename, "@PREFIX@/foo"); +    expect_value(__wrap_dlopen, flags, RTLD_NOW); +    will_return(__wrap_dlopen, NULL); +    expect_string(__wrap_dlopen, filename, "@PREFIX@/libtss2-tcti-foo.so.0"); +    expect_value(__wrap_dlopen, flags, RTLD_NOW); +    will_return(__wrap_dlopen, NULL); +    expect_string(__wrap_dlopen, filename, "@PREFIX@/libtss2-tcti-foo.so"); +    expect_value(__wrap_dlopen, flags, RTLD_NOW); +    will_return(__wrap_dlopen, NULL); TSS2_RC rc = info_from_name ("foo", &info, &data); assert_int_equal (rc, TSS2_TCTI_RC_NOT_SUPPORTED); @@ -606,6 +693,15 @@ test_tctildr_get_info_from_name (void **state) expect_string(__wrap_dlopen, filename, "libtss2-tcti-foo.so"); expect_value(__wrap_dlopen, flags, RTLD_NOW); will_return(__wrap_dlopen, NULL); +    expect_string(__wrap_dlopen, filename, "@PREFIX@/foo"); +    expect_value(__wrap_dlopen, flags, RTLD_NOW); +    will_return(__wrap_dlopen, NULL); +    expect_string(__wrap_dlopen, filename, "@PREFIX@/libtss2-tcti-foo.so.0"); +    expect_value(__wrap_dlopen, flags, RTLD_NOW); +    will_return(__wrap_dlopen, NULL); +    expect_string(__wrap_dlopen, filename, "@PREFIX@/libtss2-tcti-foo.so"); +    expect_value(__wrap_dlopen, flags, RTLD_NOW); +    will_return(__wrap_dlopen, NULL); TSS2_RC rc = tctildr_get_info ("foo", &info, &data); assert_int_equal (rc, TSS2_TCTI_RC_NOT_SUPPORTED); </ins>


Question:
When I try to open a file dialog in Bitwig Studio 4.1.0 I am getting that error: I can manually start from command line and I'm seeing the file dialog and it returns the selected file. Unsure if this is of any use but is the decompiled class that calls . Steps to reproduce the behavior: bitwig (or open any other file dialog in bitwig) GTK file dialog opens Maintainer information: EDIT: more information
I am not a maintainer of bitwig sudio. Just because I changed some lines does not make me knowledgeable about this issue.
Sorry for that. I just did what the bug report template told me:
I played a little bit around with that problem. It seems to be connected to a change of to . further references: As a quick workaround you can launch the application with: is using an embedded version of java 16.
/cc
The cause may be here: We must not wrap :
Two ways to fix: Fix the embedded JDK. Replace the embedded JDK with package.
Thanks for having a look into this. I guess we should fix the embedded JDK as it's the way how it is shipped and it should be a compatible version. I tried to add to which does not improve the situation.
I tried to do the same thing and I noticed that the exact error message changed to: but I can still run . Not sure what that means. EDIT: I've found in another package that they do run patchelf on jspawnhelper. I've also this to the postFixup: and that made it work. Not sure if this is the most elegant way to do it but I can open a PR and we can discuss that there. Thanks :)

-not -name '*.so.*'  -not -name '*.so'  -not -name '*.jar'  <ins> -not -name 'jspawnhelper'  </ins> -not -path '*/resources/*' |  while IFS= read -r f ; do patchelf --set-interpreter "${stdenv.cc.bintools.dynamicLinker}" $f


Question:
When I try to open a file dialog in Bitwig Studio 4.1.0 I am getting that error: I can manually start from command line and I'm seeing the file dialog and it returns the selected file. Unsure if this is of any use but is the decompiled class that calls . Steps to reproduce the behavior: bitwig (or open any other file dialog in bitwig) GTK file dialog opens Maintainer information: EDIT: more information
I am not a maintainer of bitwig sudio. Just because I changed some lines does not make me knowledgeable about this issue.
Sorry for that. I just did what the bug report template told me:
I played a little bit around with that problem. It seems to be connected to a change of to . further references: As a quick workaround you can launch the application with: is using an embedded version of java 16.
/cc
The cause may be here: We must not wrap :
Two ways to fix: Fix the embedded JDK. Replace the embedded JDK with package.
Thanks for having a look into this. I guess we should fix the embedded JDK as it's the way how it is shipped and it should be a compatible version. I tried to add to which does not improve the situation.
I tried to do the same thing and I noticed that the exact error message changed to: but I can still run . Not sure what that means. EDIT: I've found in another package that they do run patchelf on jspawnhelper. I've also this to the postFixup: and that made it work. Not sure if this is the most elegant way to do it but I can open a PR and we can discuss that there. Thanks :)

--suffix LD_LIBRARY_PATH : "${lib.strings.makeLibraryPath buildInputs}" done <ins> find $out -type f -executable -name 'jspawnhelper' |  while IFS= read -r f ; do patchelf --set-interpreter "${stdenv.cc.bintools.dynamicLinker}" $f done </ins> ''; meta = with lib; {


Question:
As explained also here: Steps to reproduce the behavior: Thunderbird 91 to install any extensions fail with "Thunderbird has prevented this site from installing an unverified add-on" Add on is instaalled successfully system: host os: multi-user?: sandbox: version: nixpkgs: Maintainer information:
I can't find any obvious explanation for this, since both Firefox 91 and Thunderbird 78 using the same build expression can install add-ons fine. As a workaround you can use thunderbird-78, which is still present on nixos-unstable and seems to work fine.
Yes, downgrading seems to be working. However I would still have an up to date thunderbird. Also are you reproducing this on TB 91?
I can reproduce the problem.
And installed ones can't be enabled. (except for themes and dictionaries)
Haven't tried my nixos instance yet but this is probably an upstream Thunderbird issue with linux - my test Ubuntu systems are all exhibiting the same problems with 91. Clean install or upgrade over 78 makes no difference. I can't even enable/disable themes. Predictably - and annoyingly - my Win10 Thunderbird 91 tests with addons all work fine.
yeah Downloading extensions from in Thunderbird 91 works for me as well. Just not
From the thread above, looks like: Thunderbird downloaded from works fine. Rebuilding with "" fixes add-ons and language packs verification issue.
Ok so why thunderbird does not trusts ?
Well, it does if the thunderbird binary is from So probably some changes to how things are built.
After rebuilding thunderbird with MOZREQUIRESIGNING= normal behaviour is only restored for new profiles I create - annoyingly my existing profile (the one I care about, obviously) is still unable to install or activate addons/themes. It's not a Mozilla issue as the tar ball of 91 direct from them works fine. It seems to be a common artefact introduced into the distro release by - that I know of so far - NixOS, Slackware, Fedora and Ubuntu. Which is pretty weird.
Here's the upstream bug report: In the mean time, distribution build changes are the only way to fix this.
Cannot, have never been able to add those tempting add-ons. Thunderbird says 'this add-on will have access to , etc. but clicking never does anything

<ins> diff --git a/comm/mail/config/mozconfigs/common b/comm/mail/config/mozconfigs/common --- a/comm/mail/config/mozconfigs/common +++ b/comm/mail/config/mozconfigs/common @@ -1,6 +1,3 @@ ac_add_options --enable-application=comm/mail -# Disable enforcing that add-ons are signed by the trusted root. -MOZ_REQUIRE_SIGNING= - . "$topsrcdir/build/mozconfig.common.override" diff --git a/comm/mail/moz.configure b/comm/mail/moz.configure --- a/comm/mail/moz.configure +++ b/comm/mail/moz.configure @@ -12,6 +12,7 @@ imply_option("MOZ_CRASHREPORTER_URL", "https://crash-reports.thunderbird.net/") imply_option("--enable-default-browser-agent", False) +imply_option("MOZ_REQUIRE_SIGNING", False) @depends(target_is_windows, target_is_linux) </ins>


Question:
As explained also here: Steps to reproduce the behavior: Thunderbird 91 to install any extensions fail with "Thunderbird has prevented this site from installing an unverified add-on" Add on is instaalled successfully system: host os: multi-user?: sandbox: version: nixpkgs: Maintainer information:
I can't find any obvious explanation for this, since both Firefox 91 and Thunderbird 78 using the same build expression can install add-ons fine. As a workaround you can use thunderbird-78, which is still present on nixos-unstable and seems to work fine.
Yes, downgrading seems to be working. However I would still have an up to date thunderbird. Also are you reproducing this on TB 91?
I can reproduce the problem.
And installed ones can't be enabled. (except for themes and dictionaries)
Haven't tried my nixos instance yet but this is probably an upstream Thunderbird issue with linux - my test Ubuntu systems are all exhibiting the same problems with 91. Clean install or upgrade over 78 makes no difference. I can't even enable/disable themes. Predictably - and annoyingly - my Win10 Thunderbird 91 tests with addons all work fine.
yeah Downloading extensions from in Thunderbird 91 works for me as well. Just not
From the thread above, looks like: Thunderbird downloaded from works fine. Rebuilding with "" fixes add-ons and language packs verification issue.
Ok so why thunderbird does not trusts ?
Well, it does if the thunderbird binary is from So probably some changes to how things are built.
After rebuilding thunderbird with MOZREQUIRESIGNING= normal behaviour is only restored for new profiles I create - annoyingly my existing profile (the one I care about, obviously) is still unable to install or activate addons/themes. It's not a Mozilla issue as the tar ball of 91 direct from them works fine. It seems to be a common artefact introduced into the distro release by - that I know of so far - NixOS, Slackware, Fedora and Ubuntu. Which is pretty weird.
Here's the upstream bug report: In the mean time, distribution build changes are the only way to fix this.
Cannot, have never been able to add those tempting add-ons. Thunderbird says 'this add-on will have access to , etc. but clicking never does anything

}; patches = [ ./no-buildconfig-90.patch <ins> # There is a bug in Thunderbird 91 where add-ons are required # to be signed when the build is run with default settings. # https://bugzilla.mozilla.org/show_bug.cgi?id=1727113 # https://phabricator.services.mozilla.com/D124361 ./D124361.diff </ins> ]; meta = with lib; {


Question:
Boto seems to be broken at least when brought in via the google-compute-image package. Steps to reproduce the behavior: the package in a derivation. to build the derivation. the error: I expect the build of the derivation to succeed. output forthe error: I'm not sure who the maintainers are. Please run and paste the result.
There's a PR to fix it by specifying a different Python version:

google-cloud-sdk = callPackage ../tools/admin/google-cloud-sdk { python = python3; }; <del> google-cloud-sdk-gce = google-cloud-sdk.override { with-gce = true; }; </del> <ins> google-cloud-sdk-gce = google-cloud-sdk.override { python = python38; with-gce = true; }; </ins> google-fonts = callPackage ../data/fonts/google-fonts { };


Question:
the nm-applet from current channel-nixos errors out with (.nm-applet-wrapped:4399): GLib-GIO-ERROR **: Settings schema '' is not installed zsh: trace trap nm-applet there is a open pull request which also wants to fix schemas. might this address the same problem? cheers, jonas
Unfortunately the schemas problem needs to be addressed per-package (we can't have one global directory containing all schemas in the system). I don't understand this case, as everything seems fine. The schemas are in , they are compiled, and is wrapped to have them in search path.
Same issue here - I just rolled back for the moment.
the culprit is pull request . strace shows that only compiled schemas are consulted and the pull request deleted those in preFixup (under the surmise of it being caches). pull request including a partial revert follows shortly.

''CFLAGS=-DMOBILE_BROADBAND_PROVIDER_INFO="${mobile_broadband_provider_info}/share/mobile-broadband-provider-info/serviceproviders.xml"'' ]; <del> preFixup = '' rm $out/share/glib-2.0/schemas/gschemas.compiled''; </del> postInstall = '' mkdir -p $out/etc/NetworkManager/VPN ln -s ${networkmanager_openvpn}/etc/NetworkManager/VPN/nm-openvpn-service.name $out/etc/NetworkManager/VPN/nm-openvpn-service.name


Question:
the nm-applet from current channel-nixos errors out with (.nm-applet-wrapped:4399): GLib-GIO-ERROR **: Settings schema '' is not installed zsh: trace trap nm-applet there is a open pull request which also wants to fix schemas. might this address the same problem? cheers, jonas
Unfortunately the schemas problem needs to be addressed per-package (we can't have one global directory containing all schemas in the system). I don't understand this case, as everything seems fine. The schemas are in , they are compiled, and is wrapped to have them in search path.
Same issue here - I just rolled back for the moment.
the culprit is pull request . strace shows that only compiled schemas are consulted and the pull request deleted those in preFixup (under the surmise of it being caches). pull request including a partial revert follows shortly.

license = licenses.gpl2; maintainers = with maintainers; [ phreedom urkud rickynils ]; platforms = platforms.linux; <ins> # resolve collision between evince and nm-applet for # gschemas.compiled priority = 6; </ins> }; }


Question:
cannot access (read/write) on first start. Steps to reproduce the behavior: systemd service Maintainer information:
Also reproducible on master. Looking into it.
Thank you :-)
contains a potential fix :)
Works perfectly! :+1:

# https://github.com/tulir/mautrix-telegram/issues/584 [ -f ${settingsFile} ] && rm -f ${settingsFile} old_umask=$(umask) <del> umask 0277 </del> <ins> umask 0177 </ins> ${pkgs.envsubst}/bin/envsubst  -o ${settingsFile}  -i ${settingsFileUnsubstituted}


Question:
When the option is toggled, Tweaks log the following error on startup: GNOME Tweaks General tab, toggle Suspend when lid is closed It should prevent laptop suspension. The binary needs a python wrapper. Additionally, the setting creates which contains a store path, which might break on garbage collection. cc
For me the error is because I have a file which causes the module to exist but not have anything in it. Doesn't it have one? My take was that needs a dependency on the python package.
Even if you have python modules linked to your system profile, Python still should not pick them up. Unless something is contaminating the environment variable. By default, only executables in package’s directory are wrapped:
Oh yeah, I forgot. It's me. I'm the one contaminating the . I did it on purpose a while ago and it didn't occur to me that that's why my exception was different than yours, or I wouldn't have left my previous comment in the first place. Oh, I see. Thanks.
Please test
in the built package this is in
I opened for this:

patchShebangs meson-postinstall.py ''; <ins> dontWrapGApps = true; preFixup = '' makeWrapperArgs+=("''${gappsWrapperArgs[@]}") ''; postFixup = '' wrapPythonProgramsIn "$out/libexec" "$out $pythonPath" ''; </ins> passthru = { updateScript = gnome.updateScript { packageName = pname;


Question: The gitlab service does rotate its log files which has potential of filling up the partition. Steps to reproduce the behavior: something that causes a lot of logs to be written. the partition runs full. Rotation of the logs similar to <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Please run and paste the result. Maintainer information:

''; }; <ins> logrotate = { enable = mkOption { type = types.bool; default = true; description = '' Enable rotation of log files. ''; }; frequency = mkOption { type = types.str; default = "daily"; description = "How often to rotate the logs."; }; keep = mkOption { type = types.int; default = 30; description = "How many rotations to keep."; }; extraConfig = mkOption { type = types.lines; default = '' copytruncate compress ''; description = '' Extra logrotate config options for this path. Refer to <link xlink:href="https://linux.die.net/man/8/logrotate"/> for details. ''; }; }; </ins> extraConfig = mkOption { type = types.attrs; default = {};


Question: The gitlab service does rotate its log files which has potential of filling up the partition. Steps to reproduce the behavior: something that causes a lot of logs to be written. the partition runs full. Rotation of the logs similar to <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Please run and paste the result. Maintainer information:

ensureUsers = singleton { name = cfg.databaseUsername; }; }; <ins> # Enable rotation of log files services.logrotate = { enable = cfg.logrotate.enable; paths = { gitlab = { path = "${cfg.statePath}/log/*.log"; user = cfg.user; group = cfg.group; frequency = cfg.logrotate.frequency; keep = cfg.logrotate.keep; extraConfig = cfg.logrotate.extraConfig; }; }; }; </ins> # The postgresql module doesn't currently support concepts like # objects owners and extensions; for now we tack on what's needed # here.


Question:
hangs when given a derivation because of infinite recursion either error or treat it as a string, which all other generators seem to do <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Maintainer information:
is there a context where a derivation would even be a valid input for this function? If not perhaps a simple fix would be to test for a derivation as input and simply throw a warning instead of continuing computation.
it shouldn't be possible to use derivation as a attrset for this function, but store paths could be useful which is similar to 's behavior
So this worked without error: I was able to reproduce the issue by just passing your example input above though, and in looks like nesting the derivation deeper also still causes the error. I guess we could map over the input at the start of the function and convert any unconverted derivations to strings before moving on. That should allow us to declare store paths and avoid this issue. Side note: you shouldn't have to restart your system to recover from the error condition; worked for me
I forgot SIGKILL existed. I removed the warning in the description
I have run into a very strange issue. I thought that the following patch should be all that is required to fix this: however even though I confirmed in repl that the conditional evaluates to false when passed `"${hello}", the codepath guarded by the conditional still seems to run anyway and fails with the following error: to add to the confusion, if I push the value one level deeper then it works fine:
i don't think ini support values at top level, or maybe its just the ini generator?
ah okay, then I guess my change is completely ineffective. I'll keep iterating :laughing:

("generators.mkValueStringDefault: " + "${t} not supported: ${toPretty {} v}"); in   if isInt      v then toString v <ins> # convert derivations to store paths else if lib.isDerivation v then toString v </ins> # we default to not quoting strings else if isString   v then v # isString returns "1", which is not a good default


Question:
hangs when given a derivation because of infinite recursion either error or treat it as a string, which all other generators seem to do <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Maintainer information:
is there a context where a derivation would even be a valid input for this function? If not perhaps a simple fix would be to test for a derivation as input and simply throw a warning instead of continuing computation.
it shouldn't be possible to use derivation as a attrset for this function, but store paths could be useful which is similar to 's behavior
So this worked without error: I was able to reproduce the issue by just passing your example input above though, and in looks like nesting the derivation deeper also still causes the error. I guess we could map over the input at the start of the function and convert any unconverted derivations to strings before moving on. That should allow us to declare store paths and avoid this issue. Side note: you shouldn't have to restart your system to recover from the error condition; worked for me
I forgot SIGKILL existed. I removed the warning in the description
I have run into a very strange issue. I thought that the following patch should be all that is required to fix this: however even though I confirmed in repl that the conditional evaluates to false when passed `"${hello}", the codepath guarded by the conditional still seems to run anyway and fails with the following error: to add to the confusion, if I push the value one level deeper then it works fine:
i don't think ini support values at top level, or maybe its just the ini generator?
ah okay, then I guess my change is completely ineffective. I'll keep iterating :laughing:

# converts { a.b.c = 5; } to { "a.b".c = 5; } for toINI gitFlattenAttrs = let recurse = path: value: <del> if isAttrs value then </del> <ins> if isAttrs value && !lib.isDerivation value then </ins> lib.mapAttrsToList (name: value: recurse ([ name ] ++ path) value) value else if length path > 1 then { ${concatStringsSep "." (lib.reverseList (tail path))}.${head path} = value;


Question:
<!-- Note that these are hard requirements --<!-- You can use the "Go to file" functionality on github to find the package Then you can go to the history for this package Find the latest "packagename: oldversion -newversion" commit The "newversion" is the the current version of the package --- <!-- Type the name of your package and try to find an open pull request for the package If you find an open pull request, you can review it! There's a high chance that you'll have the new version right away while helping the community! --- [x] I am a noob and tried to fulfill the above requirements to the best of my abilities and understanding of github name: pyradio <!-- 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: 0.8.7.2 desired version: 0.8.9.9 at least 0.8.8.5 (last of 0.8.8 chain) <!-- Search your package here: If no maintainer is listed for your package, tag the person that last updated the package --maintainers: Please tag this issue in your PR. The current version (0.8.7.2) is crashing for me when increasing/decreasing the volume. (Fixed in 0.8.8) The newest 0.8.9 versions feature a radio-browser-overlay, which would be very nice.
PR in

python3Packages.buildPythonApplication rec { pname = "pyradio"; <del> version = "0.8.7.2"; </del> <ins> version = "0.8.9.9"; </ins> src = fetchFromGitHub { owner = "coderholic"; repo = pname; rev = version; <del> sha256 = "0h2sxaqpmc1d1kpvpbcs9wymgzhx25x0x9p7dbyfw9r90i6123q1"; </del> <ins> sha256 = "04asw5alkkf2q5iixswarj6ddb0y4a6ixm7cckl6204jiyxpv6kc"; </ins> }; checkPhase = ''


Question:
Project description A terminal UI utility for using systemctl interactively via fzf. Metadata homepage URL: source URL: license: Unlicense platforms: linux, darwin
Submitted a PR

fingerprint = "D618 7A03 A40A 3D56 62F5  4B46 03EF BF83 9A5F DC15"; }]; }; <ins> hleboulanger = { email = "hleboulanger@protonmail.com"; name = "Harold Leboulanger"; github = "thbkrhsw"; githubId = 33122; }; </ins> hlolli = { email = "hlolli@gmail.com"; github = "hlolli";


Question:
Project description A terminal UI utility for using systemctl interactively via fzf. Metadata homepage URL: source URL: license: Unlicense platforms: linux, darwin
Submitted a PR

<ins> { lib, stdenvNoCC, fetchFromGitHub, makeWrapper, fzf, gawk }: stdenvNoCC.mkDerivation rec { pname = "sysz"; version = "1.3.0"; src = fetchFromGitHub { owner = "joehillen"; repo = pname; rev = version; sha256 = "HNwsYE1Cv90IDi3A5PmRv3uHANR3ya+VOGBQ3+zkBLM="; }; nativeBuildInputs = [ makeWrapper ]; dontBuild = true; installPhase = '' runHook preInstall install -Dm755 sysz $out/libexec/sysz makeWrapper $out/libexec/sysz $out/bin/sysz  --prefix PATH : ${lib.makeBinPath [ fzf gawk ]} runHook postInstall ''; meta = with lib; { homepage = "https://github.com/joehillen/sysz"; description = "A fzf terminal UI for systemctl"; license = licenses.unlicense; maintainers = with maintainers; [ hleboulanger ]; platforms = platforms.unix; changelog = "https://github.com/joehillen/sysz/blob/${version}/CHANGELOG.md"; }; } </ins>


Question:
Project description A terminal UI utility for using systemctl interactively via fzf. Metadata homepage URL: source URL: license: Unlicense platforms: linux, darwin
Submitted a PR

sumneko-lua-language-server = callPackage ../development/tools/sumneko-lua-language-server { }; <ins> sysz = callPackage  ../tools/misc/sysz { }; </ins> go-swag = callPackage ../development/tools/go-swag { }; go-swagger = callPackage ../development/tools/go-swagger { };


Question:
cc
Bisected to
This is an error when calling . We should fix git wrapper.

# fix up this call: # https://github.com/kaldi-asr/kaldi/blob/c9d8b9ad3fef89237ba5517617d977b7d70a7ed5/cmake/VersionHelper.cmake#L8 echo 0 <ins> elif [[ "$1" == "rev-parse" ]]; then echo ${openfst.rev} echo 0 </ins> fi true EOF


Question:
It doesn't work with nor with a flake. Works fine on my NixOS machine. I don't even know what means. With a flake I suspect that this is related to . I've had so many dynamic linking errors in the past week, especially from Rust stuff, that I no longer have the energy to look into this myself, hence the bug report. Please run and paste the result.
Could you (or anyone with access to aarch64-darwin) try another run against my branch?
$ nix-shell -p zola error: missing bootstrap url for platform aarch64-apple-darwin (use '--show-trace' to show detailed location information) is coming from and since the flake works you should update your channels
I'm trying your commit but it might take a while for things to compile. I'll probably ask about this on Discourse since it's unrelated to this issue but I was hoping that my Darwin machine would run the I install through the flake that makes up my dotfiles. So hopefully taking channels out of the equation, but I think that's not how it works, so I'll look into this, thanks.
that should be possible but uses channels while uses flakes. remove your channels to be sure that you're using flakes instead of channels
works, thanks! If someone needs this fix right now
Thanks Here's another way of applying the fix that doesn't require a overlay, which works for my use case:

<del> { lib, stdenv, fetchFromGitHub, rustPlatform, cmake, pkg-config, openssl, oniguruma, CoreServices, installShellFiles }: </del> <ins> { lib , stdenv , fetchFromGitHub , rustPlatform , cmake , pkg-config , openssl , oniguruma , CoreServices , installShellFiles , libsass }: </ins> rustPlatform.buildRustPackage rec { pname = "zola";


Question:
It doesn't work with nor with a flake. Works fine on my NixOS machine. I don't even know what means. With a flake I suspect that this is related to . I've had so many dynamic linking errors in the past week, especially from Rust stuff, that I no longer have the energy to look into this myself, hence the bug report. Please run and paste the result.
Could you (or anyone with access to aarch64-darwin) try another run against my branch?
$ nix-shell -p zola error: missing bootstrap url for platform aarch64-apple-darwin (use '--show-trace' to show detailed location information) is coming from and since the flake works you should update your channels
I'm trying your commit but it might take a while for things to compile. I'll probably ask about this on Discourse since it's unrelated to this issue but I was hoping that my Darwin machine would run the I install through the flake that makes up my dotfiles. So hopefully taking channels out of the equation, but I think that's not how it works, so I'll look into this, thanks.
that should be possible but uses channels while uses flakes. remove your channels to be sure that you're using flakes instead of channels
works, thanks! If someone needs this fix right now
Thanks Here's another way of applying the fix that doesn't require a overlay, which works for my use case:

cargoSha256 = "1hg8j9a8c6c3ap24jd96y07rlp4f0s2mkyx5034nlnkm3lj4q42n"; <del> nativeBuildInputs = [ cmake pkg-config installShellFiles]; buildInputs = [ openssl oniguruma ] ++ lib.optional stdenv.isDarwin CoreServices; </del> <ins> nativeBuildInputs = [ cmake pkg-config installShellFiles ]; buildInputs = [ openssl oniguruma ] ++ lib.optional stdenv.isDarwin [ CoreServices libsass ]; </ins> RUSTONIG_SYSTEM_LIBONIG = true;


Question:
Project description It seems that language packs can't be installed using . There are 14 languages in total available. I've tried to pack them myself but I am really new to NixOS and failed :) Metadata homepage URL: source URL: license: mit platforms: unix, linux, darwin
I have these on my fork and will cleanup/submit a PR soon.
(or someone with write permissions), you can close this issue. PR has been merged, but wasn't linked to this issue until after the merge so it didn't auto-close the issue.

}; }; <ins> ms-ceintl = callPackage ./language-packs.nix {}; # non-English language packs </ins> ms-dotnettools.csharp = callPackage ./ms-dotnettools-csharp { }; ms-kubernetes-tools.vscode-kubernetes-tools = buildVscodeMarketplaceExtension {


Question:
Project description It seems that language packs can't be installed using . There are 14 languages in total available. I've tried to pack them myself but I am really new to NixOS and failed :) Metadata homepage URL: source URL: license: mit platforms: unix, linux, darwin
I have these on my fork and will cleanup/submit a PR soon.
(or someone with write permissions), you can close this issue. PR has been merged, but wasn't linked to this issue until after the merge so it didn't auto-close the issue.

<ins> { lib, vscode-utils }: with vscode-utils; let buildVscodeLanguagePack = { language, sha256 }: buildVscodeMarketplaceExtension { mktplcRef = { name = "vscode-language-pack-${language}"; publisher = "MS-CEINTL"; version = "1.64.3"; inherit sha256; }; meta = { license = lib.licenses.mit; }; }; in # See list of core language packs at https://github.com/Microsoft/vscode-loc { # French vscode-language-pack-fr = buildVscodeLanguagePack { language = "fr"; sha256 = "sha256-6ynT1sbMgKO8iZReQ6KxFpR1VL3Nuo58MvXCtp+67vA="; }; # Italian vscode-language-pack-it = buildVscodeLanguagePack { language = "it"; sha256 = "sha256-5aNFpzNMZAZJH3n0rJevke9P6AW0au5i8+r4PXsb9Rg="; }; # German vscode-language-pack-de = buildVscodeLanguagePack { language = "de"; sha256 = "sha256-oEaWtsgktHKw52lnZTESkpzC/TTY8LO4yX11IgtMG5U="; }; # Spanish vscode-language-pack-es = buildVscodeLanguagePack { language = "es"; sha256 = "sha256-utLWbved3WCCk3XzqedbYzmyaKfbMrAmR0btT09GlxA="; }; # Russian vscode-language-pack-ru = buildVscodeLanguagePack { language = "ru"; sha256 = "sha256-0Wr2ICOiaaj4jZ555bxUJcmXO/yWDyn0UmdvxUF3WSQ="; }; # Chinese (Simplified) vscode-language-pack-zh-hans = buildVscodeLanguagePack { language = "zh-hans"; sha256 = "sha256-irTSQcVXf/V3MuZwfx4tFcvBk+xhbFZTnb7IG28s/p4="; }; # Chinese (Traditional) vscode-language-pack-zh-hant = buildVscodeLanguagePack { language = "zh-hant"; sha256 = "sha256-3IA/VTTTEqS6jrDYv50GnLXOTSC1XAMvqOVfOuvIdIs="; }; # Japanese vscode-language-pack-ja = buildVscodeLanguagePack { language = "ja"; sha256 = "sha256-rxod70ddrppEYYzukksVY1dTXR8osLFAsIPr1fSFZDg="; }; # Korean vscode-language-pack-ko = buildVscodeLanguagePack { language = "ko"; sha256 = "sha256-QYFaxJz1PqKKIiLosLQ8Tu3JNXzpxLFqgIHjjRLwjA4="; }; # Czech vscode-language-pack-cs = buildVscodeLanguagePack { language = "cs"; sha256 = "sha256-eMk+syy2h+Xb3k6QB8PqYaF4I1ydaY6eRsvOXmelh9Q="; }; # Portuguese (Brazil) vscode-language-pack-pt-br = buildVscodeLanguagePack { language = "pt-BR"; sha256 = "sha256-7Trz38KBl4sD7608MvTs02pUsdD05oHEj3Sp1LvtI7I="; }; # Turkish vscode-language-pack-tr = buildVscodeLanguagePack { language = "tr"; sha256 = "sha256-T4CTpbve3vrNdW4VDfHDg8U8cQEtuxPV5LvNdtKrqzA"; }; # Pseudo Language vscode-language-pack-qps-ploc = buildVscodeLanguagePack { language = "qps-ploc"; sha256 = "sha256-rPvCr3uQPfM8vwKoV7Un5aiMZClhf6TvG1PEe3xYNI0="; }; } </ins>


Question:
In , the patch was removed. Without this patch, trying to restart qtile just kills it and goes to the display manager, closing all of your apps. Steps to reproduce the behavior: into qtile any key combination to to press this combination Qtile restarts without closing any apps Qtile just quits and goes to the DM Maintainer information:
This patch can fix the issue
I think most of this can be done in the wrapper. I was hoping that buildenv would solve the issue as the python interpreter would have all of the dependencies it would need.
I dug a little deeper and found the cause to be the following: Qtile restarts with sys.executable, which leads to the following full command on my machine (ignore the package name, not important here): This results in a syntax error So it's trying to execute a bash script through python, which leads to a syntax error. I see some related issues on nixpkgs, , Do you have any idea how to continue? Edit: To add, we could re-introduce a patch like this (this is for current qtile master) But the whole idea was that we wanted to get rid of the patches :/
I'm okay with doing minor patches like that. It was just before were were modifying the entry point significantly. But I'm also not a qtile user, was just trying to get qtile to a more recent version. If you want to create a PR, I'll be happy to review it.

sha256 = "TRmul3t//izJRdViTvxFz29JZeGYsWc7WsJjagQ35nw="; }; <ins> patches = [ ./fix-restart.patch # https://github.com/NixOS/nixpkgs/issues/139568 ]; </ins> postPatch = '' substituteInPlace libqtile/pangocffi.py  --replace libgobject-2.0.so.0 ${glib.out}/lib/libgobject-2.0.so.0


Question:
In , the patch was removed. Without this patch, trying to restart qtile just kills it and goes to the display manager, closing all of your apps. Steps to reproduce the behavior: into qtile any key combination to to press this combination Qtile restarts without closing any apps Qtile just quits and goes to the DM Maintainer information:
This patch can fix the issue
I think most of this can be done in the wrapper. I was hoping that buildenv would solve the issue as the python interpreter would have all of the dependencies it would need.
I dug a little deeper and found the cause to be the following: Qtile restarts with sys.executable, which leads to the following full command on my machine (ignore the package name, not important here): This results in a syntax error So it's trying to execute a bash script through python, which leads to a syntax error. I see some related issues on nixpkgs, , Do you have any idea how to continue? Edit: To add, we could re-introduce a patch like this (this is for current qtile master) But the whole idea was that we wanted to get rid of the patches :/
I'm okay with doing minor patches like that. It was just before were were modifying the entry point significantly. But I'm also not a qtile user, was just trying to get qtile to a more recent version. If you want to create a PR, I'll be happy to review it.

<ins> diff --git a/libqtile/core/lifecycle.py b/libqtile/core/lifecycle.py index 0d4d119d..c37d1799 100644 --- a/libqtile/core/lifecycle.py +++ b/libqtile/core/lifecycle.py @@ -25,7 +25,7 @@ class LifeCycle: def _atexit(self) -> None: if self.behavior is Behavior.RESTART: -            argv = [sys.executable] + sys.argv +            argv = sys.argv if "--no-spawn" not in argv: argv.append("--no-spawn") argv = [s for s in argv if not s.startswith("--with-state")] @@ -33,7 +33,7 @@ class LifeCycle: argv.append("--with-state=" + self.state_file) logger.warning("Restarting Qtile with os.execv(...)") # No other code will execute after the following line does -            os.execv(sys.executable, argv) +            os.execv(sys.argv[0], argv) elif self.behavior is Behavior.TERMINATE: logger.warning("Qtile will now terminate") elif self.behavior is Behavior.NONE: </ins>


Question:
To make sure that we are on the same page: Kernel: (run ): System: (NixOS: , Ubuntu/Fedora: , ...): Nix version: (run ): Nixpkgs version: (run ): fails with Build succeeds Build fails
I have the same issue.

}; youcompleteme = buildVimPluginFrom2Nix { # created by nix#NixDerivation <del> name = "youcompleteme-2016-03-08"; </del> <ins> name = "youcompleteme-2016-03-10"; </ins> src = fetchgit { url = "git://github.com/valloric/youcompleteme"; <del> rev = "381b2132719a959f41e57ec0e6396fc1c3b6daf4"; sha256 = "1gski3s1960pmxisyq85awda0a3kb22ji9y76f67k1a4smy5q9xa"; </del> <ins> rev = "f44435b88ec98156d17869aa67ad15f38cfecbf3"; sha256 = "1y50ilyfwj6rvpvg50iq418maxvsfs54i202v7x0lfs5hmvcb4hi"; </ins> }; dependencies = []; buildInputs = [


Question:
To make sure that we are on the same page: Kernel: (run ): System: (NixOS: , Ubuntu/Fedora: , ...): Nix version: (run ): Nixpkgs version: (run ): fails with Build succeeds Build fails
I have the same issue.

mkdir build pushd build 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> make ycm_support_libs -j''${NIX_BUILD_CORES} -l''${NIX_BUILD_CORES}} </del> <ins> make ycm_core -j''${NIX_BUILD_CORES} -l''${NIX_BUILD_CORES}} </ins> ${python}/bin/python ../third_party/ycmd/build.py --gocode-completer --clang-completer --system-libclang popd '';


Question:
I set up an box and want to set using , but I get an error: . outputs nothing. outputs: If is enabled, will be enabled by default. It will be great to enable for the default kernel so that people don't need to build their own kernel to use . Maybe this is related. Steps to reproduce the behavior: up an box to enable using get an error no error appears and is enabled My related config is as follows: no maintainer for Maybe is interested. Maintainer information:
Hah - I am definitely interested in this - AFAICT this keeps alternating - i.e. I've seen that sometimes the kernel enables it and sometimes it doesn't - I think the critical bit is actually to add a test to nixpkgs to ensure this is enabled, then fix the kernel config.
I also set up an box with the same config and find that I can set bbr. It's wired. I tried to nixpkgs but didn't find out what cause the difference.
It turns out that the default kernel config generated by on does not enable . And on , is enabled by default: .
I think your still has great value. Would you like to reopen it?

XDP_SOCKETS        = whenAtLeast "4.19" yes; XDP_SOCKETS_DIAG   = whenAtLeast "5.1" yes; WAN                = yes; <ins> TCP_CONG_ADVANCED  = yes; </ins> TCP_CONG_CUBIC     = yes; # This is the default congestion control algorithm since 2.6.19 # Required by systemd per-cgroup firewalling CGROUP_BPF                  = option yes;


Question:
Project description A minimal Matrix chat client, focused on performance, offline functionality, and broad browser support. Metadata homepage URL: source URL: license: Apache platforms: Browser Deer matrix-team maintainers:
I marked this as stale due to inactivity. →
No reaction, but still interresting for me.
ftfy:

<ins> { lib , stdenv , fetchFromGitHub , fetchYarnDeps , yarn , fixup_yarn_lock , nodejs }: stdenv.mkDerivation (finalAttrs: { pname = "hydrogen-web"; version = "0.4.0"; src = fetchFromGitHub { owner = "vector-im"; repo = finalAttrs.pname; rev = "v${finalAttrs.version}"; hash = "sha256-u8Yex3r7EZH+JztQHJbfncYeyyl6hgb1ZNFIg//wcb0="; }; offlineCache = fetchYarnDeps { yarnLock = finalAttrs.src + "/yarn.lock"; hash = "sha256-N9lUAhfYLlEAIaWSNS3Ecq+aBTz+f7Z22Sclwj9rp6w="; }; nativeBuildInputs = [ yarn fixup_yarn_lock nodejs ]; configurePhase = '' runHook preConfigure export HOME=$PWD/tmp mkdir -p $HOME fixup_yarn_lock yarn.lock yarn config --offline set yarn-offline-mirror $offlineCache yarn install --offline --frozen-lockfile --ignore-platform --ignore-scripts --no-progress --non-interactive patchShebangs node_modules runHook postConfigure ''; buildPhase = '' runHook preBuild yarn build --offline runHook postBuild ''; installPhase = '' runHook preInstall cp -R target $out runHook postInstall ''; meta = { description = "Lightweight matrix client with legacy and mobile browser support"; homepage = "https://github.com/vector-im/hydrogen-web"; maintainers = lib.teams.matrix.members; license = lib.licenses.asl20; platforms = lib.platforms.all; }; }) </ins>


Question:
Project description A minimal Matrix chat client, focused on performance, offline functionality, and broad browser support. Metadata homepage URL: source URL: license: Apache platforms: Browser Deer matrix-team maintainers:
I marked this as stale due to inactivity. →
No reaction, but still interresting for me.
ftfy:

<ins> { stdenv , jq , hydrogen-web-unwrapped , conf ? { } }: if (conf == { }) then hydrogen-web-unwrapped else stdenv.mkDerivation { pname = "${hydrogen-web-unwrapped.pname}-wrapped"; inherit (hydrogen-web-unwrapped) version meta; dontUnpack = true; nativeBuildInputs = [ jq ]; installPhase = '' runHook preInstall mkdir -p $out ln -s ${hydrogen-web-unwrapped}/* $out rm $out/config.json jq -s '.[0] * $conf' "${hydrogen-web-unwrapped}/config.json" --argjson "conf" '${builtins.toJSON conf}' > "$out/config.json" runHook postInstall ''; } </ins>


Question:
Project description A minimal Matrix chat client, focused on performance, offline functionality, and broad browser support. Metadata homepage URL: source URL: license: Apache platforms: Browser Deer matrix-team maintainers:
I marked this as stale due to inactivity. →
No reaction, but still interresting for me.
ftfy:

hipchat = callPackage ../applications/networking/instant-messengers/hipchat { }; <ins> hydrogen-web-unwrapped = callPackage ../applications/networking/instant-messengers/hydrogen-web/unwrapped.nix { }; hydrogen-web = callPackage ../applications/networking/instant-messengers/hydrogen-web/wrapper.nix { conf = config.hydrogen-web.conf or { }; }; </ins> hivelytracker = callPackage ../applications/audio/hivelytracker { }; hledger = haskell.lib.compose.justStaticExecutables haskellPackages.hledger;


Question: <!-- Note that these are hard requirements --<!-- You can use the "Go to file" functionality on github to find the package Then you can go to the history for this package Find the latest "packagename: oldversion -newversion" commit The "newversion" is the the current version of the package --- <!-- Type the name of your package and try to find an open pull request for the package If you find an open pull request, you can review it! There's a high chance that you'll have the new version right away while helping the community! --- name: whitesur-gtk-theme <!-- 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: "2021-07-27" desired version: 2021-09-24 <!-- 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.

stdenv.mkDerivation rec { pname = "whitesur-gtk-theme"; <del> version = "2021-07-27"; </del> <ins> version = "2021-09-24"; </ins> src = fetchFromGitHub { owner = "vinceliuice"; repo = pname; rev = version; <del> sha256 = "17x4lqlv6whx8vg0c1nm89j7671l033apn4alqyhjb9qx5w2fa43"; </del> <ins> sha256 = "12dwmgq0kadjfky5bjm62vwgdlw3nmrrhqqs5iw15w0pn3mbmd5c"; </ins> }; nativeBuildInputs = [


Question:
Neovide fails to install via Steps to reproduce the behavior: up a terminal (currently I'm on aarch64-darwin, but I think this should be reproducible on different platforms) (or use home-manager/nix-darwin/nixOS) for it to give the mentioned error Neovide should install and run as expected <img width="1398" alt="image" src="https://user-"(text form) Might be a result of this: Please run and paste the result. Maintainer information:
Can you try this?

, makeFontsConf , libglvnd , libxkbcommon <ins> , stdenv , enableWayland ? stdenv.isLinux </ins> , wayland , xorg }:


Question:
Neovide fails to install via Steps to reproduce the behavior: up a terminal (currently I'm on aarch64-darwin, but I think this should be reproducible on different platforms) (or use home-manager/nix-darwin/nixOS) for it to give the mentioned error Neovide should install and run as expected <img width="1398" alt="image" src="https://user-"(text form) Might be a result of this: Please run and paste the result. Maintainer information:
Can you try this?

})) ]; <del> postFixup = '' </del> <ins> postFixup = let libPath = lib.makeLibraryPath ([ libglvnd libxkbcommon xorg.libXcursor xorg.libXext xorg.libXrandr xorg.libXi ] ++ lib.optionals enableWayland [ wayland ]); in '' </ins> wrapProgram $out/bin/neovide  <del> --prefix LD_LIBRARY_PATH : ${lib.makeLibraryPath [ libglvnd libxkbcommon wayland xorg.libXcursor xorg.libXext xorg.libXrandr xorg.libXi ]} </del> <ins> --prefix LD_LIBRARY_PATH : ${libPath} </ins> ''; postInstall = ''


Question:
Neovide fails to install via Steps to reproduce the behavior: up a terminal (currently I'm on aarch64-darwin, but I think this should be reproducible on different platforms) (or use home-manager/nix-darwin/nixOS) for it to give the mentioned error Neovide should install and run as expected <img width="1398" alt="image" src="https://user-"(text form) Might be a result of this: Please run and paste the result. Maintainer information:
Can you try this?

homepage = "https://github.com/Kethku/neovide"; license = with licenses; [ mit ]; maintainers = with maintainers; [ ck3d ]; <del> platforms = platforms.linux; </del> <ins> platforms = platforms.unix; </ins> mainProgram = "neovide"; }; }


Question:
Whenever I open a file chooser dialog in Nicotine+, it crashes with this error: Steps to reproduce the behavior: X environment without a DE and run a file dialog I saw a similar issue on Chromium: Maintainers (thanks!): system: host os: multi-user?: sandbox: version: channels(root): channels(ao): nixpkgs:
It looks like the glib setup hook isn't setting for some reason (maybe it's not running?) The wrapped file looks something like () So the packages is being to , which happens here: Right above it, gets to if it's present, but that doesn't show in the wrapper, so the variable is not getting set.

python3Packages.buildPythonApplication rec { pname = "nicotine-plus"; <del> version = "3.1.1"; </del> <ins> version = "3.2.0"; </ins> src = fetchFromGitHub { owner = "Nicotine-Plus"; repo = "nicotine-plus"; rev = version; <del> hash = "sha256-NfI2RfxAYhA1qefml1ayfYWjbkrzUL4l9p2Rm/ROnzQ="; </del> <ins> hash = "sha256-E8b2VRlnMWmBHu919QDPBYuMbrjov9t//bHi1Y/F0Ak="; </ins> }; nativeBuildInputs = [ gettext wrapGAppsHook ];


Question:
When I update nix I can't copy to our binay cache anymore. All I get is I bisected nixpkgs and found that the bug was introduced by . Run The parent commit works: This error here is fine because our cache has a different name of course. Please run and paste the result.
Just wondered if here is the right place for the issue but I’m quite lost on this. Maybe this is a nix bug?
No you're correct to open this here, this is a good place to start. I'll try to bisect further to see which aws-sdk-cpp commit broke this functionality, hopefully that will tell us more about how to proceed.
Bisected to , but unfortunately the commit is very large so I don't see an obvious cause. Maybe it's best to take this upstream to the Nix repo now.
Thanks for reporting, and sorry if this broke your workflow. I've bookmarked this issue and I'm going to look into adding an installCheck regression test to ensure s3 stays functional on future updates.
Thank you all for the quick response. This was a really sneaky one. Luckily nix allows rollbacks. That would be great. I’m sorry I cannot think of anything better than checking the error message of . When I do I let you know.

nativeBuildInputs = [ cmake curl ]; buildInputs = [ <del> aws-crt-cpp </del> curl openssl zlib ] ++ lib.optionals (stdenv.isDarwin && ((builtins.elem "text-to-speech" apis) ||


Question:
When I update nix I can't copy to our binay cache anymore. All I get is I bisected nixpkgs and found that the bug was introduced by . Run The parent commit works: This error here is fine because our cache has a different name of course. Please run and paste the result.
Just wondered if here is the right place for the issue but I’m quite lost on this. Maybe this is a nix bug?
No you're correct to open this here, this is a good place to start. I'll try to bisect further to see which aws-sdk-cpp commit broke this functionality, hopefully that will tell us more about how to proceed.
Bisected to , but unfortunately the commit is very large so I don't see an obvious cause. Maybe it's best to take this upstream to the Nix repo now.
Thanks for reporting, and sorry if this broke your workflow. I've bookmarked this issue and I'm going to look into adding an installCheck regression test to ensure s3 stays functional on future updates.
Thank you all for the quick response. This was a really sneaky one. Luckily nix allows rollbacks. That would be great. I’m sorry I cannot think of anything better than checking the error message of . When I do I let you know.

[ CoreAudio AudioToolbox ]; # propagation is needed for Security.framework to be available when linking <del> propagatedBuildInputs = [ aws-c-cal aws-c-event-stream aws-c-io aws-c-common aws-checksums s2n-tls ]; </del> <ins> propagatedBuildInputs = [ aws-crt-cpp ]; </ins> cmakeFlags = [ "-DBUILD_DEPS=OFF"


Question: Usage of flag without , and it is known in the Clojure community that its usage causes issues. This is because without the binaries are statically linked with , and I tried to create a GraalVM derivation compatible with . The result is here: However, this can't be upstreamed since it brokes all compilations with (including dynamically linked programs as used in nixpkgs). The major issue is that, to make compilation work, . This approach works fine for when we have only one lib C, however if we have two separate lib C we will have name conflicts and either we will have a compilation with glibc symbols on musl libraries or vice-versa. So, what are the options? One approach I can think is extend the wrapper from binary to conditionally include either or depending on the context (e.g.: if the flag is passed or not). We can do this using the flag, as below: For this to work we also need to remove the symbolic links to glibc library, otherwise this can conflict with musl libraries. This should also fix this . However, this looks like a very ugly solution, and I am open for better ones. Steps to reproduce the behavior: . Keep in mind after , it expects binary as . You can create a symbolic link and add it to your a file with contents: (segfaults) It should compile and run successfully. N/A Add any other context about the problem here. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Please run and paste the result. Maintainer information:

<del> { version, javaVersion, platforms, hashes ? import ./hashes.nix }: { stdenv, lib, fetchurl, autoPatchelfHook, setJavaClassPath, makeWrapper # minimum dependencies , Foundation, alsa-lib, fontconfig, freetype, glibc, openssl, perl, unzip, xorg </del> <ins> { version , javaVersion , platforms , hashes ? import ./hashes.nix , useMusl ? false }: { stdenv , lib , autoPatchelfHook , fetchurl , makeWrapper , setJavaClassPath , writeShellScriptBin # minimum dependencies , alsa-lib , fontconfig , Foundation , freetype , glibc , openssl , perl , unzip , xorg </ins> , zlib <del> # runtime dependencies </del> <ins> # runtime dependencies , binutils </ins> , cups <del> # runtime dependencies for GTK+ Look and Feel , gtkSupport ? true, cairo, glib, gtk3 }: </del> <ins> , gcc , musl # runtime dependencies for GTK+ Look and Feel , gtkSupport ? stdenv.isLinux , cairo , glib , gtk3 }: assert useMusl -> stdenv.isLinux; </ins> let platform = {


Question: Usage of flag without , and it is known in the Clojure community that its usage causes issues. This is because without the binaries are statically linked with , and I tried to create a GraalVM derivation compatible with . The result is here: However, this can't be upstreamed since it brokes all compilations with (including dynamically linked programs as used in nixpkgs). The major issue is that, to make compilation work, . This approach works fine for when we have only one lib C, however if we have two separate lib C we will have name conflicts and either we will have a compilation with glibc symbols on musl libraries or vice-versa. So, what are the options? One approach I can think is extend the wrapper from binary to conditionally include either or depending on the context (e.g.: if the flag is passed or not). We can do this using the flag, as below: For this to work we also need to remove the symbolic links to glibc library, otherwise this can conflict with musl libraries. This should also fix this . However, this looks like a very ugly solution, and I am open for better ones. Steps to reproduce the behavior: . Keep in mind after , it expects binary as . You can create a symbolic link and add it to your a file with contents: (segfaults) It should compile and run successfully. N/A Add any other context about the problem here. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Please run and paste the result. Maintainer information:

x86_64-darwin = "darwin-amd64"; }.${stdenv.system} or (throw "Unsupported system: ${stdenv.system}"); <del> runtimeDependencies = [ cups ] ++ lib.optionals gtkSupport [ cairo glib gtk3 ]; </del> <ins> runtimeLibraryPath = lib.makeLibraryPath ([ cups ] ++ lib.optionals gtkSupport [ cairo glib gtk3 ]); </ins> <del> runtimeLibraryPath = lib.makeLibraryPath runtimeDependencies; </del> <ins> runtimeDependencies = lib.makeBinPath ([ binutils stdenv.cc ] ++ lib.optionals useMusl [ (lib.getDev musl) # GraalVM 21.3.0+ expects musl-gcc as <system>-musl-gcc (writeShellScriptBin "${stdenv.system}-musl-gcc" ''${lib.getDev musl}/bin/musl-gcc "$@"'') ]); </ins> javaVersionPlatform = "${javaVersion}-${platform}";


Question: Usage of flag without , and it is known in the Clojure community that its usage causes issues. This is because without the binaries are statically linked with , and I tried to create a GraalVM derivation compatible with . The result is here: However, this can't be upstreamed since it brokes all compilations with (including dynamically linked programs as used in nixpkgs). The major issue is that, to make compilation work, . This approach works fine for when we have only one lib C, however if we have two separate lib C we will have name conflicts and either we will have a compilation with glibc symbols on musl libraries or vice-versa. So, what are the options? One approach I can think is extend the wrapper from binary to conditionally include either or depending on the context (e.g.: if the flag is passed or not). We can do this using the flag, as below: For this to work we also need to remove the symbolic links to glibc library, otherwise this can conflict with musl libraries. This should also fix this . However, this looks like a very ugly solution, and I am open for better ones. Steps to reproduce the behavior: . Keep in mind after , it expects binary as . You can create a symbolic link and add it to your a file with contents: (segfaults) It should compile and run successfully. N/A Add any other context about the problem here. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Please run and paste the result. Maintainer information:

zlib ]; <del> # Workaround for libssl.so.10 wanted by TruffleRuby # Resulting TruffleRuby cannot use `openssl` library. autoPatchelfIgnoreMissingDeps = true; </del> nativeBuildInputs = [ unzip perl autoPatchelfHook makeWrapper ]; unpackPhase = ''


Question: Usage of flag without , and it is known in the Clojure community that its usage causes issues. This is because without the binaries are statically linked with , and I tried to create a GraalVM derivation compatible with . The result is here: However, this can't be upstreamed since it brokes all compilations with (including dynamically linked programs as used in nixpkgs). The major issue is that, to make compilation work, . This approach works fine for when we have only one lib C, however if we have two separate lib C we will have name conflicts and either we will have a compilation with glibc symbols on musl libraries or vice-versa. So, what are the options? One approach I can think is extend the wrapper from binary to conditionally include either or depending on the context (e.g.: if the flag is passed or not). We can do this using the flag, as below: For this to work we also need to remove the symbolic links to glibc library, otherwise this can conflict with musl libraries. This should also fix this . However, this looks like a very ugly solution, and I am open for better ones. Steps to reproduce the behavior: . Keep in mind after , it expects binary as . You can create a symbolic link and add it to your a file with contents: (segfaults) It should compile and run successfully. N/A Add any other context about the problem here. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Please run and paste the result. Maintainer information:

outputs = [ "out" "lib" ]; <del> installPhase = let copyClibrariesToOut = basepath: '' # provide libraries needed for static compilation for f in ${glibc}/lib/* ${glibc.static}/lib/* ${zlib.static}/lib/*; do ln -s $f ${basepath}/${platform}/$(basename $f) done ''; copyClibrariesToLib = '' # add those libraries to $lib output too, so we can use them with # `native-image -H:CLibraryPath=''${graalvm11-ce.lib}/lib ...` and reduce # closure size by not depending on GraalVM $out (that is much bigger) </del> <ins> installPhase = let copyClibrariesToOut = basepath: '' # provide libraries needed for static compilation ${ if useMusl then "for f in ${musl.stdenv.cc.cc}/lib/* ${musl}/lib/* ${zlib.static}/lib/*; do" else "for f in ${glibc}/lib/* ${glibc.static}/lib/* ${zlib.static}/lib/*; do" } ln -s $f ${basepath}/${platform}/$(basename $f) done ''; copyClibrariesToLib = '' # add those libraries to $lib output too, so we can use them with # `native-image -H:CLibraryPath=''${lib.getLib graalvm11-ce}/lib ...` and reduce # closure size by not depending on GraalVM $out (that is much bigger) mkdir -p $lib/lib for f in ${glibc}/lib/*; do ln -s $f $lib/lib/$(basename $f) done ''; in { "11-linux-amd64" = '' ${copyClibrariesToOut "$out/lib/svm/clibraries"} ${copyClibrariesToLib} ''; "17-linux-amd64" = '' ${copyClibrariesToOut "$out/lib/svm/clibraries"} ${copyClibrariesToLib} ''; "11-linux-aarch64" = '' ${copyClibrariesToOut "$out/lib/svm/clibraries"} ${copyClibrariesToLib} ''; "17-linux-aarch64" = '' ${copyClibrariesToOut "$out/lib/svm/clibraries"} ${copyClibrariesToLib} ''; "11-darwin-amd64" = ""; "17-darwin-amd64" = ""; }.${javaVersionPlatform} + '' # ensure that $lib/lib exists to avoid breaking builds </ins> mkdir -p $lib/lib <del> for f in ${glibc}/lib/*; do ln -s $f $lib/lib/$(basename $f) done ''; in { "11-linux-amd64" = '' ${copyClibrariesToOut "$out/lib/svm/clibraries"} ${copyClibrariesToLib} ''; "17-linux-amd64" = '' ${copyClibrariesToOut "$out/lib/svm/clibraries"} ${copyClibrariesToLib} ''; "11-linux-aarch64" = '' ${copyClibrariesToOut "$out/lib/svm/clibraries"} ${copyClibrariesToLib} </del> <ins> # jni.h expects jni_md.h to be in the header search path. ln -s $out/include/linux/*_md.h $out/include/ # copy-paste openjdk's preFixup # Set JAVA_HOME automatically. mkdir -p $out/nix-support cat <<EOF > $out/nix-support/setup-hook if [ -z "''${JAVA_HOME-}" ]; then export JAVA_HOME=$out; fi EOF </ins> ''; <del> "17-linux-aarch64" = '' ${copyClibrariesToOut "$out/lib/svm/clibraries"} ${copyClibrariesToLib} ''; "11-darwin-amd64" = ""; "17-darwin-amd64" = ""; }.${javaVersionPlatform} + '' # ensure that $lib/lib exists to avoid breaking builds mkdir -p $lib/lib # jni.h expects jni_md.h to be in the header search path. ln -s $out/include/linux/*_md.h $out/include/ ''; </del> dontStrip = true; <del> preFixup = '' </del> <ins> # Workaround for libssl.so.10 wanted by TruffleRuby # Resulting TruffleRuby cannot use `openssl` library. autoPatchelfIgnoreMissingDeps = stdenv.isDarwin; preFixup = lib.optionalString (stdenv.isLinux) '' </ins> # We cannot use -exec since wrapProgram is a function but not a # command. #


Question: Usage of flag without , and it is known in the Clojure community that its usage causes issues. This is because without the binaries are statically linked with , and I tried to create a GraalVM derivation compatible with . The result is here: However, this can't be upstreamed since it brokes all compilations with (including dynamically linked programs as used in nixpkgs). The major issue is that, to make compilation work, . This approach works fine for when we have only one lib C, however if we have two separate lib C we will have name conflicts and either we will have a compilation with glibc symbols on musl libraries or vice-versa. So, what are the options? One approach I can think is extend the wrapper from binary to conditionally include either or depending on the context (e.g.: if the flag is passed or not). We can do this using the flag, as below: For this to work we also need to remove the symbolic links to glibc library, otherwise this can conflict with musl libraries. This should also fix this . However, this looks like a very ugly solution, and I am open for better ones. Steps to reproduce the behavior: . Keep in mind after , it expects binary as . You can create a symbolic link and add it to your a file with contents: (segfaults) It should compile and run successfully. N/A Add any other context about the problem here. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Please run and paste the result. Maintainer information:

for bin in $( find "$out" -executable -type f -not -path '*/languages/ruby/lib/gems/*' -not -name jspawnhelper ); do if patchelf --print-interpreter "$bin" &> /dev/null || head -n 1 "$bin" | grep '^#!' -q; then wrapProgram "$bin"  <del> --prefix LD_LIBRARY_PATH : "${runtimeLibraryPath}" </del> <ins> --prefix LD_LIBRARY_PATH : "${runtimeLibraryPath}"  --prefix PATH : "${runtimeDependencies}" </ins> fi done <del> # copy-paste openjdk's preFixup # Set JAVA_HOME automatically. mkdir -p $out/nix-support cat <<EOF > $out/nix-support/setup-hook if [ -z "''${JAVA_HOME-}" ]; then export JAVA_HOME=$out; fi EOF </del> find "$out" -name libfontmanager.so -exec  patchelf --add-needed libfontconfig.so {} ; <ins> # Workaround for libssl.so.10/libcrypto.so.10 wanted by TruffleRuby patchelf $out/languages/ruby/lib/mri/openssl.so  --replace-needed libssl.so.10 libssl.so  --replace-needed libcrypto.so.10 libcrypto.so </ins> ''; # $out/bin/native-image needs zlib to build native executables.


Question: Usage of flag without , and it is known in the Clojure community that its usage causes issues. This is because without the binaries are statically linked with , and I tried to create a GraalVM derivation compatible with . The result is here: However, this can't be upstreamed since it brokes all compilations with (including dynamically linked programs as used in nixpkgs). The major issue is that, to make compilation work, . This approach works fine for when we have only one lib C, however if we have two separate lib C we will have name conflicts and either we will have a compilation with glibc symbols on musl libraries or vice-versa. So, what are the options? One approach I can think is extend the wrapper from binary to conditionally include either or depending on the context (e.g.: if the flag is passed or not). We can do this using the flag, as below: For this to work we also need to remove the symbolic links to glibc library, otherwise this can conflict with musl libraries. This should also fix this . However, this looks like a very ugly solution, and I am open for better ones. Steps to reproduce the behavior: . Keep in mind after , it expects binary as . You can create a symbolic link and add it to your a file with contents: (segfaults) It should compile and run successfully. N/A Add any other context about the problem here. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Please run and paste the result. Maintainer information:

# run on JVM with Graal Compiler $out/bin/java -XX:+UnlockExperimentalVMOptions -XX:+EnableJVMCI -XX:+UseJVMCICompiler HelloWorld | fgrep 'Hello World' <del> # Ahead-Of-Time compilation $out/bin/native-image -H:-CheckToolchain -H:+ReportExceptionStackTraces --no-server HelloWorld ./helloworld | fgrep 'Hello World' </del> <ins> ${# --static flag doesn't work for darwin lib.optionalString (stdenv.isLinux && !useMusl) '' echo "Ahead-Of-Time compilation" $out/bin/native-image -H:-CheckToolchain -H:+ReportExceptionStackTraces --no-server HelloWorld ./helloworld | fgrep 'Hello World' </ins> <del> ${ lib.optionalString stdenv.isLinux '' # Ahead-Of-Time compilation with --static # --static flag doesn't work for darwin </del> <ins> echo "Ahead-Of-Time compilation with --static" </ins> $out/bin/native-image --no-server --static HelloWorld ./helloworld | fgrep 'Hello World' '' } <ins> ${# --static flag doesn't work for darwin lib.optionalString (stdenv.isLinux && useMusl) '' echo "Ahead-Of-Time compilation with --static and --libc=musl" $out/bin/native-image --no-server --libc=musl --static HelloWorld ./helloworld | fgrep 'Hello World' '' } </ins> ${# TODO: Doesn't work on MacOS, we have this error: # "Launching JShell execution engine threw: Operation not permitted (Bind failed)" lib.optionalString (stdenv.isLinux) ''


Question: Usage of flag without , and it is known in the Clojure community that its usage causes issues. This is because without the binaries are statically linked with , and I tried to create a GraalVM derivation compatible with . The result is here: However, this can't be upstreamed since it brokes all compilations with (including dynamically linked programs as used in nixpkgs). The major issue is that, to make compilation work, . This approach works fine for when we have only one lib C, however if we have two separate lib C we will have name conflicts and either we will have a compilation with glibc symbols on musl libraries or vice-versa. So, what are the options? One approach I can think is extend the wrapper from binary to conditionally include either or depending on the context (e.g.: if the flag is passed or not). We can do this using the flag, as below: For this to work we also need to remove the symbolic links to glibc library, otherwise this can conflict with musl libraries. This should also fix this . However, this looks like a very ugly solution, and I am open for better ones. Steps to reproduce the behavior: . Keep in mind after , it expects binary as . You can create a symbolic link and add it to your a file with contents: (segfaults) It should compile and run successfully. N/A Add any other context about the problem here. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Please run and paste the result. Maintainer information:

]; }; }; <del> in graalvmXXX-ce </del> <ins> in graalvmXXX-ce </ins>


Question:
I updated today my distribution on latest unstable (I was already on unstable before). And it turned out that many things suddently broke (the clock is broken, my does not work anymore (of course), Carla's software does not have anymore a "Canvas" menu, NSM can't run Carla or it gets an error, Giada also fails to connect to Jack...). I quickly realized that I was running Wayland instead of X11, while I was always running X11 before on KDE Plasma. Moreover, the KDE clock and calendar is now broken (negative numbers+hour does not appear at all+what is this ): ! So here are my questions: it normal that Wayland is the default now? I can't find any documentation on Wayland vs X11, and it seems a bit risky to use Wayland by default given all the bugs I encountered... yes, how can I configure X11 to be the default? (I mean in the configuration file, not by just changing at connection time) can I get the clock and calendar back? idea why Carla, Giada and NSM are also not working properly with Wayland? (I'm using pipewire) Steps to reproduce the behavior: the system and reboot Please run and paste the result.
Same issue here. On top of that, I'm unable to share my screen with tools such as Google Meet, Teams, Jitsi. To fix: , then in SDDM select on the bottom left:
There's not supposed to be any changes to the default. If you don't set one via , you might get the wayland version. This should/must be fixed. Others have mentioned the issue with the clock although I'm not seeing that here. As for the screen sharing question, applications need wayland support. That really has nothing to do with Plasma or NixOS.
Thanks for your answer. How can I find a list of valid ? I tried to put an absurd value but it does not give any error. In my case I'm running sddm, plasma5 and x11. Concerning the clock, I'm not sure what I've that you don't. If it helps, the language of the system is french . and in X11 my clock looks like: ! The is replaced with octobre, so that's why I'm thinking it may be linked with the language.
Or well, pipewire support. However screensharing/recording on plasma wayland seems to be broken at the moment (even in OBS which does have explicit support for wayland). Judging from what gets logged in the journal it seems like is not agreeing with kwin about the supported wayland protocols or something.
Same, I also get the broken clock, unless I remove the timezone setting from and get UTC. I saw some people saying Plasma's systemd startup fixes it? Altho IIRC the PR for that was merged but the systemd service isn't running by default.
I have which should be the most standard one... and.
Maybe NixOs does not like people with European timezone…
I notice that the env var is somehow missing for . I run with correctly set, and the clock widget just works. Running it with empty reproduces the same broken clock. I checked that , have , but , and don't. Since is the session entrance started by (so it's not 's fault), we can know the envvar somehow gets dropped during the plasma starting chain. EDIT: Another issue is that, we used to be able to workaround the clock issue by . But after , as I mentioned in , and the option DO NOT work anymore. Session is now always booted without systemd.
By comparing between , exactly is dropped when the wrapper running , no other environment variable are , removed or modified. is wrapped to gain CAPSYSNICE, I'm not sure how the work, but simply removing this wrapper just fix the clock widget issue. But it's definitely not a good idea since is expecting to be real time scheduled. cc
I have nothing to do with KDE, but I made a few changes to in . I don't see how this could possibly have affected the clock, but you could try reverting my commits if you think this is related.
That may be unrelated. I found the related upstream issue The cause here is that rejects , and some other env vars in secure-excution mode, including programs with or capabilities. See In our case, has capabilities set. But I'm still not sure how we could workaround this. Currently my thought is to patch and to let the wrapper pass these envvars in other ways, like renaming envvar name or passing through arguments. If there's a better way to workaround, please point it out.
The "Wayland by default" thing was introduced here: as part of KDE Wayland support in NixOS in general. Mb shouldn't be default yet or at least not to override previous preference of X11 during upgrade. +1 about the clock - same issue. I'm on locale.
Current status: The clock issue can be workaround by setting since which is already in . It will be fixed (without ) in The default session will be set back to X11 on SDDM in Currently, you can manually switch to X11 and login once, and SDDM will remember your last choice (hopefully, it may be reset if you change available desktop sessions. It's an issue of SDDM and I'll look into it later).
This fix didn't work for me. The clock is still broken in exactly the same way as reported in this bug. Even after logging into fresh user. (Again, I'm on Wayland)
Are you sure on nixpkgs and that option is enabled? Please check if the plasma systemd service is started by . If it's not running, please open another issue for not working. If it's running, then there may be some issue of . Since will load PAM environment, which must contain , and it will be propagated to other units. In this case please open an issue about "systemd user units not picking PAM environment".
Thanks for your advice! Yes indeed I'm on master (last synced yesterday) and have this option enabled: Though it says "dead" for some reason (and I'm writing this from an active KDE session), process is a child of systemd according to pstree TZDIR is defined as well: Do you have any other ideas?
Looking at 's process env, indeed env is not defined there. Is that the issue you are trying to point out? (The above returns nothing)
Please open an issue about not working, and provide there.
Did another update from unstable (it updated LOTs of packages) and after reboot, the clock is working again! (and TZDIR env is indeed known to plasma). thanks again for jumping on this!
Could this be the same root cause for issues with IMEs, screen capturing and Flameshot simply not working at all? IME (fcitx) does not activate, screen capturing in browsers and OBS does not show a source selection dialog, Flameshot does not react to its DBus invocation (Spectacle works although it is dog slow -- not sure what their internal differences are) See and I don't know much about DBus but the bit about it not finding services dirs sounds like it could be caused by something like this. I also remember seeing some logs from Flameshot where it thinks it has been started already but actually invoking its screenshot function does not do anything -- wrong DBus instance? ... Or am I the only one with these problems on plasma/wayland? :D
I have 4k 14" laptop display and 2k 27" external display. Flameshot doesn't work for me at all on KDE+Wayland: Spectacle kind of works - about every second time; plus, when trying to annotate, the resolution of the image gets absolutely trashed if I the screenshot was taken from non-hidpi screen.
For the issue, see
This issue has been mentioned on NixOS Discourse. There might be relevant details there:

{ mkDerivation, lib, <del> extra-cmake-modules, kdoctools, </del> <ins> extra-cmake-modules, kdoctools, fetchpatch, </ins> epoxy, lcms2, libICE, libSM, libcap, libdrm, libinput, libxkbcommon, mesa, pipewire, udev, wayland, xcb-util-cursor, xwayland,


Question:
I updated today my distribution on latest unstable (I was already on unstable before). And it turned out that many things suddently broke (the clock is broken, my does not work anymore (of course), Carla's software does not have anymore a "Canvas" menu, NSM can't run Carla or it gets an error, Giada also fails to connect to Jack...). I quickly realized that I was running Wayland instead of X11, while I was always running X11 before on KDE Plasma. Moreover, the KDE clock and calendar is now broken (negative numbers+hour does not appear at all+what is this ): ! So here are my questions: it normal that Wayland is the default now? I can't find any documentation on Wayland vs X11, and it seems a bit risky to use Wayland by default given all the bugs I encountered... yes, how can I configure X11 to be the default? (I mean in the configuration file, not by just changing at connection time) can I get the clock and calendar back? idea why Carla, Giada and NSM are also not working properly with Wayland? (I'm using pipewire) Steps to reproduce the behavior: the system and reboot Please run and paste the result.
Same issue here. On top of that, I'm unable to share my screen with tools such as Google Meet, Teams, Jitsi. To fix: , then in SDDM select on the bottom left:
There's not supposed to be any changes to the default. If you don't set one via , you might get the wayland version. This should/must be fixed. Others have mentioned the issue with the clock although I'm not seeing that here. As for the screen sharing question, applications need wayland support. That really has nothing to do with Plasma or NixOS.
Thanks for your answer. How can I find a list of valid ? I tried to put an absurd value but it does not give any error. In my case I'm running sddm, plasma5 and x11. Concerning the clock, I'm not sure what I've that you don't. If it helps, the language of the system is french . and in X11 my clock looks like: ! The is replaced with octobre, so that's why I'm thinking it may be linked with the language.
Or well, pipewire support. However screensharing/recording on plasma wayland seems to be broken at the moment (even in OBS which does have explicit support for wayland). Judging from what gets logged in the journal it seems like is not agreeing with kwin about the supported wayland protocols or something.
Same, I also get the broken clock, unless I remove the timezone setting from and get UTC. I saw some people saying Plasma's systemd startup fixes it? Altho IIRC the PR for that was merged but the systemd service isn't running by default.
I have which should be the most standard one... and.
Maybe NixOs does not like people with European timezone…
I notice that the env var is somehow missing for . I run with correctly set, and the clock widget just works. Running it with empty reproduces the same broken clock. I checked that , have , but , and don't. Since is the session entrance started by (so it's not 's fault), we can know the envvar somehow gets dropped during the plasma starting chain. EDIT: Another issue is that, we used to be able to workaround the clock issue by . But after , as I mentioned in , and the option DO NOT work anymore. Session is now always booted without systemd.
By comparing between , exactly is dropped when the wrapper running , no other environment variable are , removed or modified. is wrapped to gain CAPSYSNICE, I'm not sure how the work, but simply removing this wrapper just fix the clock widget issue. But it's definitely not a good idea since is expecting to be real time scheduled. cc
I have nothing to do with KDE, but I made a few changes to in . I don't see how this could possibly have affected the clock, but you could try reverting my commits if you think this is related.
That may be unrelated. I found the related upstream issue The cause here is that rejects , and some other env vars in secure-excution mode, including programs with or capabilities. See In our case, has capabilities set. But I'm still not sure how we could workaround this. Currently my thought is to patch and to let the wrapper pass these envvars in other ways, like renaming envvar name or passing through arguments. If there's a better way to workaround, please point it out.
The "Wayland by default" thing was introduced here: as part of KDE Wayland support in NixOS in general. Mb shouldn't be default yet or at least not to override previous preference of X11 during upgrade. +1 about the clock - same issue. I'm on locale.
Current status: The clock issue can be workaround by setting since which is already in . It will be fixed (without ) in The default session will be set back to X11 on SDDM in Currently, you can manually switch to X11 and login once, and SDDM will remember your last choice (hopefully, it may be reset if you change available desktop sessions. It's an issue of SDDM and I'll look into it later).
This fix didn't work for me. The clock is still broken in exactly the same way as reported in this bug. Even after logging into fresh user. (Again, I'm on Wayland)
Are you sure on nixpkgs and that option is enabled? Please check if the plasma systemd service is started by . If it's not running, please open another issue for not working. If it's running, then there may be some issue of . Since will load PAM environment, which must contain , and it will be propagated to other units. In this case please open an issue about "systemd user units not picking PAM environment".
Thanks for your advice! Yes indeed I'm on master (last synced yesterday) and have this option enabled: Though it says "dead" for some reason (and I'm writing this from an active KDE session), process is a child of systemd according to pstree TZDIR is defined as well: Do you have any other ideas?
Looking at 's process env, indeed env is not defined there. Is that the issue you are trying to point out? (The above returns nothing)
Please open an issue about not working, and provide there.
Did another update from unstable (it updated LOTs of packages) and after reboot, the clock is working again! (and TZDIR env is indeed known to plasma). thanks again for jumping on this!
Could this be the same root cause for issues with IMEs, screen capturing and Flameshot simply not working at all? IME (fcitx) does not activate, screen capturing in browsers and OBS does not show a source selection dialog, Flameshot does not react to its DBus invocation (Spectacle works although it is dog slow -- not sure what their internal differences are) See and I don't know much about DBus but the bit about it not finding services dirs sounds like it could be caused by something like this. I also remember seeing some logs from Flameshot where it thinks it has been started already but actually invoking its screenshot function does not do anything -- wrong DBus instance? ... Or am I the only one with these problems on plasma/wayland? :D
I have 4k 14" laptop display and 2k 27" external display. Flameshot doesn't work for me at all on KDE+Wayland: Spectacle kind of works - about every second time; plus, when trying to annotate, the resolution of the image gets absolutely trashed if I the screenshot was taken from non-hidpi screen.
For the issue, see
This issue has been mentioned on NixOS Discourse. There might be relevant details there:

./0002-xwayland.patch ./0003-plugins-qpa-allow-using-nixos-wrapper.patch ./0001-NixOS-Unwrap-executable-name-for-.desktop-search.patch <ins> # Pass special environments through arguemnts to `kwin_wayland`, bypassing # ld.so(8) environment stripping due to `kwin_wayland`'s capabilities. # We need this to have `TZDIR` correctly set for `plasmashell`, or # everything related to timezone, like clock widgets, will be broken. # https://invent.kde.org/plasma/kwin/-/merge_requests/1590 (fetchpatch { url = "https://invent.kde.org/plasma/kwin/-/commit/9a008b223ad696db3bf5692750f2b74e578e08b8.diff"; sha256 = "sha256-f35G+g2MVABLDbAkCed3ZmtDWrzYn1rdD08mEx35j4k="; }) </ins> ]; CXXFLAGS = [ ''-DNIXPKGS_XWAYLAND="${lib.getBin xwayland}/bin/Xwayland"''


Question:
It seems that all of a sudden a few dependencies are missing to . As a start, I found the need to add . The problem is with which also makes the impression it's needed: But our build of doesn't provide cmake files. Building with cmake instead of autoconf might help, but they don't use the cmake module there which makes the transition harder. cc (maintainers) and .
The new requirements come from thrift since
I have an idea of how to fix this. Will put a PR up shortly

"-DARROW_BUILD_TESTS=ON" "-DARROW_VERBOSE_THIRDPARTY_BUILD=ON" "-DARROW_DEPENDENCY_SOURCE=SYSTEM" <ins> "-DThrift_SOURCE=AUTO" # search for Thrift using pkg-config (ThriftConfig.cmake requires OpenSSL and libevent) </ins> "-DARROW_DEPENDENCY_USE_SHARED=${if enableShared then "ON" else "OFF"}" "-DARROW_COMPUTE=ON" "-DARROW_CSV=ON"


Question:
Except from If the main module specifies go 1.17 or higher, go mod vendor now omits and files for vendored dependencies, which can otherwise interfere with the ability of the go command to identify the correct module root when invoked within the vendor tree. This may change the hashes of vendorSha256 in existing packages that are using buildGoModule. Originally posted by in
go 1.17 may not be portable across different go versions, but go 1.16 will be EOL next month (when 1.18 releases). 15 is EOL and should be removed. There isn't a remediation for this problem correct? The only answer I see is to move the versions forward with breaking changes.
Yeah - Regenning the hashes isn't that hard - I'm going to confirm they're stable, and then stack a PR using the infra I used for the og hashes. Walking through the cases vendorSha256 = null Fine - no vendoring happens Go 1.16 to 1.17, not go1.17 No module change - testcase clipman. go 1.16 to go1.17, is go1.17
I'm already working on this.
- Do you have an ETA? I expect I can get this pounded out this weekend, but if you don't want me to I won't.
Also any objection to me trying to clean out the go1.15 deps? I think some of them (i.e. terraform / prometheus), might not be updateable, but the rest probably are.
Hopefully in the coming week. We need to handle the hashes and the usual breakage from the update so I really don't want to push something though quickly in case it turns into a mess. I'm also avoiding normalizing any of the vendor hashes so we aren't needlessly adding noise to the git history. I've been moving some things to 1.16 or 1.17 in advance to limit diff and rebuilds and checking that the updated hashes still build on darwin+linux. If you don't mind doing the hashes in smaller batches like in that would be helpful? Fixing or pinning any broken packages would also help. No that should be fine, only looks like a few packages plus the pinned which needs to be either unpinned or removed.
I'm happy to cut small PRs - How many hashes do you want them batched to? 10 hash updates per PR, 100? I have no strong opinion on how to batch these (and normally my tooling generates a commit per package, so its' real easy for me to batch arbitrarily). I'll probably try and clean out most of the easy stuff (i.e. everything with a null vendorSha, everything which doesn't have a changed vendorSha), then deal with the stuff which causes mod vendor changes, but if you want I can start on the gnarlier stuff first (modules with vendorSha changes + the non module stuff).
20 or less per PR would make merges simple as we can let test it. Unless the needs to be updated or it's broken on 1.17 I'm leaving these for the final PR when the default is changed. Also anything that causes more than a few rebuilds is probably easier left for the final PR as well. I'm not planning to fixing every first before the final PR when the default gets changed but if we can get it down to 50-100 hashes it'll make it easier to test and also avoid conflicts with other PRs.
Got it - so focus on the changed hashes - or anything which breaks. I also just pushed out working PRs for every go1.15 package except one (mostly to go1.17), so we might be able to get rid of go1.15 before go1.18 lands.
Should be under 100 now but I'll keep going until there is only a few left (basically just stuff that should stay in sync with the default or causes a few rebuilds) as I've found some with broken vendoring on 1.17 and it's easier to address that first so the final PR is fairly simple.

mv $out/bin/gocode $out/bin/gocode-gomod ''; <ins> doCheck = false; # fails on go 1.17 </ins> meta = with lib; { description = "An autocompletion daemon for the Go programming language"; longDescription = ''