jiebi/CodeConvo huggingface dataset:
Code change:
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.

Related discussion:
text: diff --git a/src/tss2-tcti/tctildr-dl.c b/src/tss2-tcti/tctildr-dl.c <del> index b364695c..b13be3ef 100644 </del> <ins> index b364695c..d026de71 100644 </ins> --- a/src/tss2-tcti/tctildr-dl.c +++ b/src/tss2-tcti/tctildr-dl.c <del> @@ -85,7 +85,15 @@ handle_from_name(const char *file, if (handle == NULL) { return TSS2_TCTI_RC_BAD_REFERENCE; </del> <ins> @@ -116,6 +116,50 @@ handle_from_name(const char *file, return TSS2_TCTI_RC_BAD_VALUE; </ins> } <del> -    *handle = dlopen(file, RTLD_NOW); </del> <ins> *handle = dlopen(file_xfrm, RTLD_NOW); +    if (*handle != NULL) { +        return TSS2_RC_SUCCESS; +    } else { +        LOG_DEBUG("Failed to load TCTI for name "%s": %s", file, dlerror()); +    } </ins> +    size = snprintf(file_xfrm, +                    sizeof (file_xfrm), +                    "@PREFIX@%s",
Code change:
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 :)

Related discussion:
text: -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
Code change:
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 :)

Related discussion:
text: --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; {
Code change:
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

Related discussion:
text: <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>
Code change:
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

Related discussion:
text: }; 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; {
Code change:
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:

Related discussion:
text: 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 { };
Code change:
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.

Related discussion:
text: ''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
Code change:
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.

Related discussion:
text: 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> }; }
Code change:
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:

Related discussion:
text: # 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}
Code change:
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:

Related discussion:
text: patchShebangs meson-postinstall.py ''; <ins> dontWrapGApps = true; preFixup = '' makeWrapperArgs+=("''${gappsWrapperArgs[@]}") ''; postFixup = '' wrapPythonProgramsIn "$out/libexec" "$out $pythonPath" ''; </ins> passthru = { updateScript = gnome.updateScript { packageName = pname;
Code change:
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:

Related discussion:
text: ''; }; <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 = {};
Code change:
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:

Related discussion:
text: 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.
Code change:
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:

Related discussion:
text: ("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
Code change:
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:

Related discussion:
text: # 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;