jiebi/CodeConvo huggingface dataset:
Change:
PKCS#11 modules in such a way that they're discoverable. ''; homepage = "https://p11-glue.github.io/p11-glue/p11-kit.html"; <ins> changelog = [ "https://github.com/p11-glue/p11-kit/raw/${version}/NEWS" "https://github.com/p11-glue/p11-kit/releases/tag/${version}" ]; </ins> platforms = platforms.all; license = licenses.bsd3; };

Discussion:
Describe the bug does not provide the binary, while I would expect it to. To Reproduce Steps to reproduce the behavior: in Expected behavior (and ) are installed for operator usage of p11-kit. Screenshots See step 3. Additional context It turns out the binaries are present when I do . Debian ships the binaries as part of the base non-dev package. RHEL/CentOS ship the binary as part of and have separated out into . Notify maintainers (based on git history, there is no meta.maintainers for p11-kit) Metadata Please run and paste the result. Maintainer information:
p11-kit is a library as well, so it makes sense to have headers, library, and binaries in separate outputs. I think we can fixed this by setting: in the derivation.
If we do this we need to fix it in flatpak's patch to hardcode the path to the p11-kit binary.
I marked this as stale due to inactivity. &rarr;
Any updates on this?
I marked this as stale due to inactivity. &rarr;
Change:
moveToOutput libexec "$dev" # fixup .pc file (where to find 'moc' etc.) <del> sed -i "$dev/lib/pkgconfig/Qt6Core.pc"  -e "/^bindir=/ c bindir=$dev/bin" </del> <ins> if [ -f "$dev/lib/pkgconfig/Qt6Core.pc" ]; then sed -i "$dev/lib/pkgconfig/Qt6Core.pc"  -e "/^bindir=/ c bindir=$dev/bin" fi </ins> patchShebangs $out $dev # QTEST_ASSERT and other macros keeps runtime reference to qtbase.dev <del> substituteInPlace "$dev/include/QtTest/qtestassert.h" --replace "__FILE__" "__BASE_FILE__" </del> <ins> if [ -f "$dev/include/QtTest/qtestassert.h" ]; then substituteInPlace "$dev/include/QtTest/qtestassert.h" --replace "__FILE__" "__BASE_FILE__" fi </ins> ''; dontStrip = debugSymbols;

Discussion:
Steps to reproduce the behavior: The regression is due to , which forgot to maintain the guard on darwin. While it is straightforward to fix the aarch64-darwin build, it isn't enough for x86_64-darwin due 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.
Change:
<ins> { stdenv, fetchurl, makeDesktopItem, makeWrapper, patchelf, p7zip , coreutils, gnugrep, which, git, python, unzip }: { name, product, version, src, wmClass, jdk, meta } @ attrs: with stdenv.lib; let loName = toLower product; hiName = toUpper product; execName = concatStringsSep "-" (init (splitString "-" name)); in with stdenv; lib.makeOverridable mkDerivation rec { inherit name src meta; desktopItem = makeDesktopItem { name = execName; exec = execName; comment = lib.replaceChars ["n"] [" "] meta.longDescription; desktopName = product; genericName = meta.description; categories = "Application;Development;"; icon = execName; extraEntries = '' StartupWMClass=${wmClass} ''; }; buildInputs = [ makeWrapper patchelf p7zip unzip ]; patchPhase = '' get_file_size() { local fname="$1" echo $(ls -l $fname | cut -d ' ' -f5) } munge_size_hack() { local fname="$1" local size="$2" strip $fname truncate --size=$size $fname } interpreter=$(echo ${stdenv.glibc.out}/lib/ld-linux*.so.2) if [ "${stdenv.system}" == "x86_64-linux" ]; then target_size=$(get_file_size bin/fsnotifier64) patchelf --set-interpreter "$interpreter" bin/fsnotifier64 munge_size_hack bin/fsnotifier64 $target_size else target_size=$(get_file_size bin/fsnotifier) patchelf --set-interpreter "$interpreter" bin/fsnotifier munge_size_hack bin/fsnotifier $target_size fi ''; installPhase = '' mkdir -p $out/{bin,$name,share/pixmaps,libexec/${name}} cp -a . $out/$name ln -s $out/$name/bin/${loName}.png $out/share/pixmaps/${execName}.png mv bin/fsnotifier* $out/libexec/${name}/. jdk=${jdk.home} item=${desktopItem} makeWrapper "$out/$name/bin/${loName}.sh" "$out/bin/${execName}"  --prefix PATH : "$out/libexec/${name}:${stdenv.lib.makeBinPath [ jdk coreutils gnugrep which git ]}"  --prefix LD_LIBRARY_PATH : "${stdenv.lib.makeLibraryPath [ # Some internals want libstdc++.so.6 stdenv.cc.cc.lib ]}"  --set JDK_HOME "$jdk"  --set ${hiName}_JDK "$jdk"  --set ANDROID_JAVA_HOME "$jdk"  --set JAVA_HOME "$jdk" ln -s "$item/share/applications" $out/share ''; } </ins>

Discussion:
JetBrains IDEs are currently at which is kind of confusing because the packages here aren't all under name. For example WebStorm, PhpStorm, PyCharm and so on - these are properties of JetBrains. Therefore I think it will be good to move all them under and rename to .
Do you want to make a pull request?
Change:
<ins> diff --git a/common/gnomehintssettings.cpp b/common/gnomehintssettings.cpp index 9860e57..40fa6ec 100644 --- a/common/gnomehintssettings.cpp +++ b/common/gnomehintssettings.cpp @@ -80,9 +80,17 @@ void gtkMessageHandler(const gchar *log_domain, GnomeHintsSettings::GnomeHintsSettings() : QObject(0) , m_usePortal(checkUsePortalSupport()) -    , m_gnomeDesktopSettings(g_settings_new("org.gnome.desktop.wm.preferences")) -    , m_settings(g_settings_new("org.gnome.desktop.interface")) { +    g_autoptr(GSettingsSchemaSource) schemaSource = nullptr; +    g_autoptr(GSettingsSchema) gnomeDesktopSchema = nullptr; +    g_autoptr(GSettingsSchema) settingsSchema = nullptr; + +    schemaSource = g_settings_schema_source_new_from_directory("@gds_gsettings_path@", g_settings_schema_source_get_default(), true, nullptr); +    gnomeDesktopSchema = g_settings_schema_source_lookup(schemaSource, "org.gnome.desktop.wm.preferences", false); +    m_gnomeDesktopSettings = g_settings_new_full(gnomeDesktopSchema, nullptr, nullptr); +    settingsSchema = g_settings_schema_source_lookup(schemaSource, "org.gnome.desktop.interface", false); +    m_settings = g_settings_new_full(settingsSchema, nullptr, nullptr); + gtk_init(nullptr, nullptr); // Set log handler to suppress false GtkDialog warnings </ins>

Discussion:
Following the last couple, I can now reproduce the issue again. I'm running NixOS off of , which is just with the previous too patches, that were still in staging`, applied. With that branch I get the following when I try to launch zoom: Edit: See
cc
I think this is a non-issue and was due to being an absolute pain in my ass. I'm testing and will update soon.
Alright, I can confirm that this is an issue, but seems to only affect zoom. cc.
What actions did you take? For me, on , it shows login page without an error (running ).
I'm running Zoom from recent master () and it doesn't crash. can you reproduce crash on that revision?
I later isolated the issue with jtojnar on the IRC. Try adding this clause to your configuration and see if you can repro the issue:
no crash for me, though I don't have an error "(process:): GLib-GIO-ERROR **: 21:32:14.611: No GSettings schemas are installed on the system" in a log. Maybe that's because I run gnome-shell, which has the ?
Maybe? I could/can consistently repro with the above
There must be some gsettings related code in the platform theme that needs to be patched/hardcoded.
Yeah, it wants the gnome hints which requires gsettings-desktop-schemas We can do a hardcode-gsettings patch like , to make it depend on gsettings-desktop-schemas since we can't wrap it. The issue doesn't appear in gnome because the global environment will have gsettings-desktop-schemas. You use sway right? Even there these should be available...
That is correct; I use sway configured with home-manager. Relevant configs:
This , should probably pull in , , and also.
cc. who, IIRC, worked on the sway Gtk wrapper.
Same issue for me under i3+dmenu
Change:
{ stdenv , lib , fetchzip <ins> , fetchpatch </ins> , rustPlatform # native build inputs

Discussion:
Package name: meli Latest released version: 0.8.7 <!-- Search your package here: --- Current version on the unstable channel: 0.8.6 Current version on the stable/release channel: 0.8.5 <!-- 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! --- Notify maintainers <!-- If the result shows no maintainers, tag the person that last updated the package. -- Note for maintainers: Please tag this issue in your PR. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Release notes: This will not fix , since is still at in meli 0.8.7. It was only updated in , which is not part of any release yet.
Sure, do you want to PR an update?
I created It builds, but tests failed locally with " executable not found in PATH". In addition to fixing that I also need to work through
is done from my point of view, apart from some error in the ofborg-eval-darwin job that I can't explain and don't know how to solve:
Change:
sha256 = "sha256-5XCrvyrDEqH3JryPMoOXSlVVDLQ+PdYBqwGYxkExdvk="; includes = [ "hyperkitty/*" ]; }) <ins> # Fix for Python >=3.9.13 (fetchpatch { url = "https://gitlab.com/mailman/hyperkitty/-/commit/3efe7507944dbdbfcfa4c182d332528712476b28.patch"; sha256 = "sha256-yXuhTbmfDiYEXEsnz+zp+xLHRqI4GtkOhGHN+37W0iQ="; }) </ins> ]; postPatch = ''

Discussion:
(or ) fails during install tests (only test phase shown) seems to have broken on may 9, starting at may 10 we have seen this failure
Thanks for the report, starting a bisect.
Oof: That's going to be fun :D
commit Author: Miss Islington (bot) <+miss- Sat Apr 30 05:31:37 2022 -0700 bpo-: Fix UnicodeEncodeError in the email module (GH-) It was raised if the charset itself contains characters not encodable in UTF-8 (in particular udcxx characters representing non-decodable bytes in the source). (cherry picked from commit ) Co-authored-by: Serhiy Storchaka
diff diff --git index .. --- +++ -364,6 +364,10 msg1 def testunconvertablemessage(self): # This message can't be converted to an email.message.EmailMessage. # This fails with Python=3.9.13 because # is fixed. if sys.hexversion = 0x3090df0: raise SkipTest mbox = ((, "")) # We have to do it this way to see the exception. with open(gettestfile(""), "rb") as emfile:
Ohh, sorry, didn't have sufficient time during the last days, so thanks a lot for doing further research :) Do you want to file a PR with this diff against nixpkgs? Otherwise I can take care of it tonight.
Change:
stdenv.mkDerivation (finalAttrs: { pname = "cimg"; <del> version = "3.3.4"; </del> <ins> version = "3.3.5"; </ins> src = fetchFromGitHub { owner = "GreycLab"; repo = "CImg"; rev = "v.${finalAttrs.version}"; <del> hash = "sha256-qo/k5NpTqu+o2WUEOThozuBJVPMMy8OvIMo2DfJUE8g="; </del> <ins> hash = "sha256-QdQhMEY6Zl3qdvRIeDv/12TL4HMrNJSAQ66vQymOrBU="; </ins> }; outputs = [ "out" "doc" ];

Discussion:
Package name: gmic Latest released version: 3.3.5 Current version on the unstable channel: 3.3.1 Current version on the stable/release channel: 3.3.1 Notify maintainers Note for maintainers: Please tag this issue in your PR. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Change:
# Enable libfabric support (necessary for Omnipath networks) on x86_64 linux , fabricSupport ? stdenv.isLinux && stdenv.isx86_64 <ins> # Enable Fortran support , fortranSupport ? !(stdenv.isDarwin && stdenv.isAarch64) </ins> }: assert !cudaSupport || cudatoolkit != null; let <del> version = "4.1.1"; </del> cudatoolkit_joined = symlinkJoin { name = "${cudatoolkit.name}-unsplit"; paths = [ cudatoolkit.out cudatoolkit.lib ]; }; in stdenv.mkDerivation rec { pname = "openmpi"; <del> inherit version; </del> <ins> version = "4.1.1"; </ins> src = with lib.versions; fetchurl { url = "https://www.open-mpi.org/software/ompi/v${major version}.${minor version}/downloads/${pname}-${version}.tar.bz2";

Discussion:
Describe the bug I'm on a mission to get (and thence ) compiling on M1 Macs, and having fixed , the next stumbling block is 4.1.1. Sadly, the build fails with , presumably related to . To Reproduce Steps to reproduce the behavior: Expected behavior A clear and concise description of what you expected to happen. Screenshots Additional context This works fine when built for x8664 on the same machine. Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Metadata system: host os: multi-user?: sandbox: version: channels(steve): nixpkgs: Maintainer information:
Submitted PR which disables Fortran support for OpenMPI on aarch64-darwin. Would that fix the issue for you or do you require Fortran?
This seems to be the build failure:
I actually have no idea if I require Fortran. I mean, presumably it's enabled for some reason, so I'm a little wary of disabling it on only one platform/arch combination: that feels like an atypical workaround.
To reproduce: I wonder if the gcc maintainers can offer any insight?
seems to hint at the stack-protector hardening, so perhaps something like could work around that? (no idea what's the real cause though, and I have no Darwin machine at hand)
You were right! Sent a PR in
Change:
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",

Discussion:
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.
Change:
patches = [ ./cups-filter-ppd-dirs.patch ]; buildInputs = [ cups ]; <del> nativeBuildInputs = [ busybox ]; </del> <ins> nativeBuildInputs = [ rpm cpio ]; </ins> meta = with lib; { homepage = "http://download.ebz.epson.net/dsc/search/01/search/";

Discussion:
When updating my NixOS I got the following error because of the printer driver: I expect the problem to be fixed so that I can continue to use my printer.
Change:
async = callPackage ../development/tools/async { }; <del> async-profiler = callPackage ../development/tools/async-profiler { }; </del> atheme = callPackage ../servers/irc/atheme { }; atinout = callPackage ../tools/networking/atinout { };

Discussion:
Hi all, Sorry if I'm missing something, I'm new at this so please say if you need any more info, thanks Steps to reproduce the behavior: async-profiler-2.9 Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
So after some research I've found that this is happening cause jdk21 is now default java and previously it was jd19. This async-profiler is used in jetbrains intellij package. I was not able to override version as I lack knowledge how to do it, perhaps someone will be about to help with it? Thank you
I was able to apply temporary fix I've created an overlay to use jdk19 instead of jdk21 that is used by default but I think in future async-profiler needs to be upgraded as there is a version 3 in git repo and repo link is now a bit different Just in case some one will need it. Here is an overlay And here is snippet from
Looks related to async-profiler/async-profiler. I'll look into maybe fixing it as a part of ZHF
This is actually fixed upstream in v3.0. Will package that instead
Change:
}; nativeBuildInputs = [ pkgs.buildPackages.makeWrapper ]; postInstall = let <del> # Needed to fix Node.js 16+ - PR svanderburg/node2nix#302 npmPatch = fetchpatch { name = "emit-lockfile-v2-and-fix-bin-links-with-npmv7.patch"; url = "https://github.com/svanderburg/node2nix/commit/375a055041b5ee49ca5fb3f74a58ca197c90c7d5.patch"; hash = "sha256-uVYrXptJILojeur9s2O+J/f2vyPNCaZMn1GM/NoC5n8="; }; </del> <ins> patches = [ # Needed to fix Node.js 16+ - PR svanderburg/node2nix#302 (fetchpatch { name = "emit-lockfile-v2-and-fix-bin-links-with-npmv7.patch"; url = "https://github.com/svanderburg/node2nix/commit/375a055041b5ee49ca5fb3f74a58ca197c90c7d5.patch"; hash = "sha256-uVYrXptJILojeur9s2O+J/f2vyPNCaZMn1GM/NoC5n8="; }) # Needed to fix packages with DOS line-endings after above patch - PR svanderburg/node2nix#314 (fetchpatch { name = "convert-crlf-for-script-bin-files.patch"; url = "https://github.com/svanderburg/node2nix/commit/91aa511fe7107938b0409a02ab8c457a6de2d8ca.patch"; hash = "sha256-ISiKYkur/o8enKDzJ8mQndkkSC4yrTNlheqyH+LiXlU="; }) ]; </ins> in '' <del> patch -d $out/lib/node_modules/node2nix -p1 < ${npmPatch} </del> <ins> ${lib.concatStringsSep "n" (map (patch: "patch -d $out/lib/node_modules/node2nix -p1 < ${patch}") patches)} </ins> wrapProgram "$out/bin/node2nix" --prefix PATH : ${lib.makeBinPath [ pkgs.nix ]} ''; };

Discussion:
When building the resulting binary contains in the shebang line. This causes the binary to fail to execute. The bug was introduced between 22.05 and 22.11: The binary runs and doesn't die on a broken shebang. <!-- 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.
This looks fun
I wonder if this was a regression from me making node2nix manually handle bin stuff instead of letting npm (not) handle it I can maybe make a quick patch to node2nix's node-env to dos2unix all bin scripts with shebangs in a line right after this one:
I've opened with a fix
Change:
{ stdenv , lib , fetchurl <ins> , fetchpatch </ins> , asciidoc , docbook-xsl-nons , docbook_xml_dtd_45

Discussion:
Package name: tracker-miners Latest released version: 3.5.1 Current version on the unstable channel: 3.5.0 <p</p- The package update itself is trivial, but I got stuck at addressing . There is now a ioctl check that runs: The program seems to build fine, but does not exit with 0: This makes the Btrfs subvolume feature disabled: I am not sure where to get start to enable this since in they decide this will be a hard check on next major bump (well, it should be possible to opt-out but it should be possible I guess). :seeno_evil: Note for maintainers: Please tag this issue in your PR.
I am getting , even though I do not use BTRFS so I assume this depends on the kernel version of the builder? (I am using .) That does not really sound like a good idea since users can use completely different kernel version than Hydra. Maybe it should be an and the check performed only when it is . Though I am not sure what the consequences are when incorrectly configured is used. Maybe it will need to be a runtime check instead?
I saved the program as a separate and compiled & ran with as root user and it exits with 1 for me as well. says I am on 6.3.0. I use btrfs so as root runs fine for me (if that matters). Hmmm then this is weird since it sounds like is introduced (is this the correct place to check such info?). But later I found in the BTRFS subvolumes feature is disabled as well :thinking: Edit: Looks like the fedora link is broken,
Apparently, it falls back to success since I do not use BTRFS: (both inside and outside the sandbox) <details<summaryModified <codetest.c</code</summary</detailsSo that does not really sound like a good test. Edit: I .
Hmmm now I wonder if their original idea is to check whether the code , probably knowing is there is already enough? (I assume they are not supporting < 2.6.34 kernels then I expect all linux should have it?) It looks like they already has some .
Could you try running the modified in build sandbox to find out why specifically it fails for you?
This is using and putting in : This is not in builder sandbox and run as root:
The fix is now merged upstream:
Change:
<del> { lib, stdenv, fetchFromGitHub, kernel, bc }: </del> <ins> { lib, stdenv, fetchFromGitHub, kernel, bc, }: </ins> stdenv.mkDerivation { pname = "rtl88x2bu"; <del> version = "${kernel.version}-unstable-2023-11-29"; </del> <ins> version = "${kernel.version}-unstable-2024-06-09"; </ins> src = fetchFromGitHub { owner = "morrownr"; repo = "88x2bu-20210702"; <del> rev = "cd2b6cbd9c8fbfebee8a1f28fab8e4434450456c"; sha256 = "sha256-t1lLJSEDzY2zvgcKYaxUq/umrlLpxu4+4zWmG8R0Wz4="; </del> <ins> rev = "62f3a86a2687fe98bd441e0aff5adf87d95c238a"; hash = "sha256-gQWk1nhtT0W2dY5uQitWabBGEDfZpmJAoJg+j2ndO00="; </ins> }; hardeningDisable = [ "pic" ];

Discussion:
Steps to reproduce the behavior: rtl88x2bu None <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Fixed in
Change:
melpaBuild { pname = "consult-gh"; <del> version = "1.0-unstable-2024-08-11"; </del> <ins> version = "1.0-unstable-2024-08-24"; </ins> src = fetchFromGitHub { owner = "armindarvish"; repo = "consult-gh"; <del> rev = "640d4b9c71aa6dfff4f29c0207cc02316f1d61c8"; hash = "sha256-hFHex4cUAP1U5aK1bfa+va1jiWS8tRqtnMGxr17NWio="; </del> <ins> rev = "b1d85d179438e4b6469e1b78906a7dde8f07c822"; hash = "sha256-VmxuXvO0nl0h9IKU+XWfjW90KG/1B+qHoOVhvYJ8XTs="; </ins> }; packageRequires = [ consult <del> embark </del> <ins> embark-consult </ins> forge markdown-mode ]; propagatedUserEnvPkgs = [ gh ]; <ins> ignoreCompilationError = false; </ins> passthru.updateScript = unstableGitUpdater { }; meta = {

Discussion:
part of No errors in native compliation of emacsPackages.consult-gh <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]: