jiebi/CodeConvo huggingface dataset:
Change:
<del> { lib, fetchFromGitHub, rustPlatform }: </del> <ins> { lib, fetchFromGitHub, rustPlatform, ncurses, stdenv, python3 }: </ins> <del> rustPlatform.buildRustPackage rec { </del> <ins> rustPlatform.buildRustPackage { </ins> pname = "tere"; <del> version = "1.5.0"; </del> <ins> version = "1.5.1-unstable-2024-04-01"; </ins> src = fetchFromGitHub { owner = "mgunyho"; repo = "tere"; <del> rev = "v${version}"; sha256 = "sha256-xqbFBRzBfTwSdkC8e85yANdVA45G6E1FYlTXP8QfVIk="; </del> <ins> rev = "659422ecb2810f91446a71e52b82524d4f1755d8"; sha256 = "sha256-CH8gcfkjSAknG6kKHp0aODcrjEJjzHbgeVaE/PK1zRA="; </ins> }; <del> cargoHash = "sha256-Y2Zgo/VAJxzQd2cXxyiJS5AqcVRClAuUsEogivK3EJw="; </del> <ins> cargoHash = "sha256-GtGWuvYdxP3dgGekoXYaM+lnZJBgJX1UIWe0EH+/52M="; </ins> <del> postPatch = '' rm .cargo/config.toml; ''; </del> <ins> nativeBuildInputs = [ # ncurses provides the tput command needed for integration tests # https://github.com/mgunyho/tere/issues/93#issuecomment-2029624187 ncurses ]; checkFlags = lib.optionals stdenv.isDarwin [ # Unexplained fail # https://github.com/NixOS/nixpkgs/pull/298527#issuecomment-2053758845 "--skip=first_run_prompt_accept" ]; # NOTE: workaround for build fail on aarch64 # See https://github.com/NixOS/nixpkgs/issues/145726#issuecomment-971331986 preBuild = let python-with-toml = python3.withPackages (ps: [ps.toml]); script = builtins.toFile "clear_linkers.py" '' from os import path import toml if path.exists(".cargo/config.toml"): config = toml.load(open(".cargo/config.toml")) for target in config.get("target",{}).values(): if "linker" in target: del target["linker"] toml.dump(config,open(".cargo/config.toml", "w")) else: print(__file__, ":  CONFIG.TOML EXPECTED") exit(1) ''; in "${python-with-toml}/bin/python3 ${script}"; </ins> meta = with lib; { description = "A faster alternative to cd + ls";

Discussion:
Steps to reproduce the behavior: tere after Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
This bug was apparently , but upgrading to the latest release (or git commit) just gives new errors, which have been . I assume that these errors starting, especially in the Nix build system, show that it's some kind of issue with upgrades to dependencies.
Will be fixed by
Change:
(assertByteFormat "BitsPerSecond") (assertValueOneOf "Duplex" ["half" "full"]) (assertValueOneOf "AutoNegotiation" boolValues) <del> (assertValueOneOf "WakeOnLan" ["phy" "unicast" "multicast" "broadcast" "arp" "magic" "secureon" "off"]) </del> <ins> (assertValuesSomeOfOr "WakeOnLan" ["phy" "unicast" "multicast" "broadcast" "arp" "magic" "secureon"] "off") </ins> (assertValueOneOf "Port" ["tp" "aui" "bnc" "mii" "fibre"]) (assertValueOneOf "ReceiveChecksumOffload" boolValues) (assertValueOneOf "TransmitChecksumOffload" boolValues)

Discussion:
Currently when is for an interface, it automatically sets it to . The line which sets it is at - Currently there's no way to set it to another value, like , , etc. Earlier this was possible with service, which was removed in favor of this boolean on network interfaces. Instead, I use a custom service for my current setup Add a option along with , which by default could be , but allows other values to be set.
Change:
callPackage (import ./generic.nix (rec { version = "4.5.5"; <ins> meta = { knownVulnerabilities = [ "Security support ended in January 2018" ]; }; </ins> src = fetchurl { url = "https://downloads.xenproject.org/release/xen/${version}/xen-${version}.tar.gz"; sha256 = "1y74ms4yc3znf8jc3fgyq94va2y0pf7jh8m9pfqnpgklywqnw8g2";

Discussion:
Security support for Xen 4.5 (our current default version) ended January 2018, so we should change the default to 4.8 in 18.03 (and remove 4.5 in the future).
what's your opinion on this?
See .
Change:
fluidsynth = callPackage ../applications/audio/fluidsynth { inherit (darwin.apple_sdk.frameworks) AudioUnit CoreAudio CoreMIDI CoreServices; }; <del> fluidsynth_1 = fluidsynth.override { version = "1"; }; </del> fmit = libsForQt5.callPackage ../applications/audio/fmit { };

Discussion:
no longer compiles with GLib 2.70: The failure looks patchable: We'd need to replace the use of in by an equivalent call to . However I'm not quite confident about the right place to call it, since we need to avoid calling it twice (which is UB according to the GLib documentation) and it looks like there are two different intialization routines that'd need to initialize the lock, and . Therefore I think should try to make an effort to finally get rid of this vulnerable version of fluidsynth (). Remaining uses: [x] , fixed in [x] (cc fixed in [x] (cc fixed in
Change:
<ins> { lib , buildFHSUserEnvBubblewrap , symlinkJoin , bottles-unwrapped , extraPkgs ? pkgs: [ ] , extraLibraries ? pkgs: [ ] }: let fhsEnv = { targetPkgs = pkgs: with pkgs; [ bottles-unwrapped vkbasalt ] ++ extraPkgs pkgs; multiPkgs = let xorgDeps = pkgs: with pkgs.xorg; [ libpthreadstubs libSM libX11 libXaw libxcb libXcomposite libXcursor libXdmcp libXext libXi libXinerama libXmu libXrandr libXrender libXv libXxf86vm ]; in pkgs: with pkgs; [ # https://wiki.winehq.org/Building_Wine alsa-lib cups dbus fontconfig freetype glib gnutls libglvnd gsm gst_all_1.gstreamer gst_all_1.gst-plugins-base libgphoto2 libjpeg_turbo libkrb5 libpcap libpng libpulseaudio libtiff libunwind libusb1 libv4l libxml2 mpg123 ocl-icd openldap samba4 sane-backends SDL2 udev vulkan-loader # https://www.gloriouseggroll.tv/how-to-get-out-of-wine-dependency-hell/ alsa-plugins dosbox giflib gtk3 libva libxslt ncurses openal # Steam runtime libgcrypt libgpg-error p11-kit zlib # Freetype ] ++ xorgDeps pkgs ++ extraLibraries pkgs; }; in symlinkJoin { name = "bottles"; paths = [ (buildFHSUserEnvBubblewrap (fhsEnv // { name = "bottles"; runScript = "bottles"; })) (buildFHSUserEnvBubblewrap (fhsEnv // { name = "bottles-cli"; runScript = "bottles-cli"; })) ]; postBuild = '' mkdir -p $out/share ln -s ${bottles-unwrapped}/share/applications $out/share ln -s ${bottles-unwrapped}/share/icons $out/share ''; inherit (bottles-unwrapped) meta; } </ins>

Discussion:
error when creating a bottle Steps to reproduce the behavior: bottles to create a new bottle during dxvk installation process with the following error message No error when trying to create a bottle ! I'm pretty new to nixos so it might be a configuration error on my part I apologize in advanced if I tagged the wrong maintainers
It should be fixed in (I don't reproduce it there). (I think it's caused by the fact I )
gotcha. feel free to close if you think it's gonna be fixed in next release. thanks :)
Change:
++ data.extraLegoRenewFlags ); <ins> # We need to collect all the ACME webroots to grant them write # access in the systemd service. webroots = lib.remove null (lib.unique (builtins.map (certAttrs: certAttrs.webroot) (lib.attrValues config.security.acme.certs))); </ins> in { inherit accountHash cert selfsignedDeps;

Discussion:
Since , all except gets mounted in a read-only fashion. This behaviour will break the existing acme deployments having a set outside of . In my personal case, I have the webroot served by my main nginx service. Meaning: After , the cert renewal fails with: The fix I personally went with was to add my webroot to the by overriding the service config. That's however not a proper fix for NixPkgs. As it is, we'll silently break some already existing deployments. While that's something acceptable for nixos-unstable, I feel like we have to adopt a better migration path before the next stable release. I have three options in mind: could revert the hardening option to . could add the webroots to the config. Could this backfire in some way? could trigger a assertion error warning the user that some of their webroots are not in the s and instruct them about how to fix the issue. I did not manage do decide which of these solutions is the best. What do you think? cc
I think we should go that route, I can't imagine this to backfire, since it could write to that location before, too.
I think suggestion 2 is what I'd go for. is not an ideal option as we would rather keep the module as secure as possible. Adding all the unique webroots not under /var/lib/acme should be pretty easy to automate.
:+1: ack. I'll send a PR shortly.
Oh cool ok!
Thanks for your work, but I have a similar issue. Seems a regression occurs. Here is the log: Here is my config: If I set to , it works well. But if I set to a non-existing dir like , error occurs. In addition, a non-existing will make all other services whose is under fail. The reason may be that all services have due to .
Change:
owner = "SWI-Prolog"; repo = "swipl"; rev = "V${version}"; <del> hash = "sha256-FgEn+Ht45++GFpfcdaJ5In5x+NyIOopSlSAs+t7sPDE="; </del> <ins> hash = "sha256-O9ogltcbBST111FA85jEVW6jGOLJSt/5PeBABtMu2Ws="; </ins> fetchSubmodules = true; };

Discussion:
It seems that errors with when attempting to have in . There has been no updates in the lspserver. I came across this while trying to update my systems. Currently, says , so that was the last build I had with the lsp not causing a build failure. Steps to reproduce the behavior: this expression: It seems this started happening in . Works fine on the parent commit. Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
It seems adding to allows it to build, it is not clear to me how is being used here as I am not familiar with how packs work in swiProlog and why made this necessary. From looking at that commit in , it appears to be something that changed upstream. This builds:
I can confirm that with 9.1.21, swi-prolog + lsp-server builds just fine, even with the latest packaging. Something must indeed have changed upstream. 9.1.22 is the first version that stops building for me. The notes that the pack system got a refactor at that point, so that's probably what is going on here, but nothing indicates a sudden need for git. If git is now necessary for pack installation (even if we already pre-cloned everything) it should be a dependency. any idea why git became necessary here?
We can resolve this with a patch to SWI-Prolog to respect in the options, then adding that option to our invocation. I submitted a PR to SWI-Prolog (SWI-Prolog/swipl-devel). If upstream merges this, we can just apply the same patch to stable.
swi-prolog 9.2.7 backported the PR mentioned above. I've modified the package definition to supply the proper flag which suppresses git use during extraPacks install.
Change:
<ins> From 5c5d878bf49bae5920c330482217477819ba9bc2 Mon Sep 17 00:00:00 2001 From: Bernardo Meurer <bernardo@meurer.org> Date: Fri, 15 Oct 2021 23:22:50 -0700 Subject: [PATCH 1/2] makefile: correctly sed paths The default Makefile for tlp makes a mess with catenating `DESTDIR` to everything, but then not actualy using the catenated (_ prefixed) variables to sed it's `.in` files. This patch makes sure that it correctly sets the paths, taking `DESTDIR` in account where it makes sense (e.g. /bin where we want $out/bin) but not where it doesn't (/etc/tlp.conf should be just that). The reason DESTDIR is used at all, as opposed to the more appropriate PREFIX, is covered in the nix formula, and is (also) due to the Makefile being a bit "different." --- Makefile | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/Makefile b/Makefile index e9bbab4..ab05720 100644 --- a/Makefile +++ b/Makefile @@ -51,19 +51,19 @@ _TPACPIBAT = $(DESTDIR)$(TPACPIBAT) SED = sed  -e "s|@TLPVER@|$(TLPVER)|g"  -	-e "s|@TLP_SBIN@|$(TLP_SBIN)|g"  -	-e "s|@TLP_TLIB@|$(TLP_TLIB)|g"  -	-e "s|@TLP_FLIB@|$(TLP_FLIB)|g"  -	-e "s|@TLP_ULIB@|$(TLP_ULIB)|g"  -	-e "s|@TLP_BATD@|$(TLP_BATD)|g"  +	-e "s|@TLP_SBIN@|$(_SBIN)|g"  +	-e "s|@TLP_TLIB@|$(_TLIB)|g"  +	-e "s|@TLP_FLIB@|$(_FLIB)|g"  +	-e "s|@TLP_ULIB@|$(_ULIB)|g"  +	-e "s|@TLP_BATD@|$(_BATD)|g"  -e "s|@TLP_CONFUSR@|$(TLP_CONFUSR)|g"  -e "s|@TLP_CONFDIR@|$(TLP_CONFDIR)|g"  -	-e "s|@TLP_CONFDEF@|$(TLP_CONFDEF)|g"  -	-e "s|@TLP_CONFREN@|$(TLP_CONFREN)|g"  -	-e "s|@TLP_CONF@|$(TLP_CONF)|g"  +	-e "s|@TLP_CONFDEF@|$(_CONFDEF)|g"  +	-e "s|@TLP_CONFREN@|$(_CONFREN)|g"  +	-e "s|@TLP_CONF@|$(_CONF)|g"  -e "s|@TLP_RUN@|$(TLP_RUN)|g"    -e "s|@TLP_VAR@|$(TLP_VAR)|g"    -	-e "s|@TPACPIBAT@|$(TPACPIBAT)|g" +	-e "s|@TPACPIBAT@|$(_TPACPIBAT)|g" INFILES =  tlp  -- 2.33.0 </ins>

Discussion:
<!-- Note that these are hard requirements --<!-- You can use the "Go to file" functionality on github to find the package Then you can go to the history for this package Find the latest "packagename: oldversion -newversion" commit The "newversion" is the the current version of the package --- <!-- Type the name of your package and try to find an open pull request for the package If you find an open pull request, you can review it! There's a high chance that you'll have the new version right away while helping the community! --- name: <!-- The current version can be found easily with the same process than above for checking the master branch If an open PR is present for the package, take this version as the current one and link to the PR --current version: 1.3.1 desired version: 1.4.0 <!-- 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.
Change:
(fetchpatch { name = "0001-only-plugin-update.patch"; url = "https://raw.githubusercontent.com/debian-calibre/calibre/debian/${finalAttrs.version}+ds-1/debian/patches/0001-only-plugin-update.patch"; <del> hash = "sha256-uL1mSjgCl5ZRLbSuKxJM6XTfvVwog70F7vgKtQzQNEQ="; </del> <ins> hash = "sha256-mHZkUoVcoVi9XBOSvM5jyvpOTCcM91g9+Pa/lY6L5p8="; </ins> }) (fetchpatch { name = "0007-Hardening-Qt-code.patch";

Discussion:
Package name: calibre Latest released version: 7.9.0 Current version on the unstable channel: 7.8.0 Current version on the stable/release channel: 7.0.0 Notify maintainers https://calibre- 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:
sha256 = "bda0ef48e6a44c091399b12ab4a7e580d2dd8294c222b301f88d7d57f47ba142"; }; <ins> patches = [ # Fix tests for pytest>=4.2.0. Remove with the next release (fetchpatch { url = "https://github.com/RKrahl/pytest-dependency/commit/089395bf77e629ee789666361ee12395d840252c.patch"; sha256 = "1nkha2gndrr3mx11kx2ipxhphqd6wr25hvkrfwzyrispqfhgl0wm"; excludes = [ "doc/src/changelog.rst" ]; }) ]; </ins> propagatedBuildInputs = [ pytest ]; <ins> checkInputs = [ pytest ]; </ins> checkPhase = '' pytest '';

Discussion:
This expression fails to build on 19.03: The problem is that its checkPhase is not correct as the command cannot be found. I believe that should be in the for it to succeed. Run the below inside The error is: Please run and paste the results.
It can be put in as is usual for pytest because we have multiple versions of it within . However, the tests fail:
Not sure what is causing that error, but I use it fine for my purposes.
How do you use it if it doesn't build? Would you mind making a PR with the fix?
It does build, I use a custom pytest- because I was using it before asking it for inclusion in nixpkgs. Anyway it's now being addressed in:
Change:
<del> diff --git a/src/sdl/i_system.c b/src/sdl/i_system.c index 10c0747bf..861f00728 100644 --- a/src/sdl/i_system.c +++ b/src/sdl/i_system.c @@ -145,13 +145,7 @@ int TimeFunction(int requested_frequency); // Locations for searching the srb2.pk3 #if defined (__unix__) || defined(__APPLE__) || defined (UNIXCOMMON) -#define DEFAULTWADLOCATION1 "/usr/local/share/games/SRB2" -#define DEFAULTWADLOCATION2 "/usr/local/games/SRB2" -#define DEFAULTWADLOCATION3 "/usr/share/games/SRB2" -#define DEFAULTWADLOCATION4 "/usr/games/SRB2" -#define DEFAULTSEARCHPATH1 "/usr/local/games" -#define DEFAULTSEARCHPATH2 "/usr/games" -#define DEFAULTSEARCHPATH3 "/usr/local" +#define DEFAULTWADLOCATION1 "@wadlocation@" #elif defined (_WIN32) #define DEFAULTWADLOCATION1 "c:gamessrb2" #define DEFAULTWADLOCATION2 "gamessrb2" @@ -2812,34 +2806,6 @@ static const char *locateWad(void) if (((envstr = I_GetEnv("SRB2WADDIR")) != NULL) && isWadPathOk(envstr)) return envstr; -#ifndef NOCWD -	I_OutputMsg(",."); -	// examine current dir -	strcpy(returnWadPath, "."); -	if (isWadPathOk(returnWadPath)) -		return NULL; -#endif - - -#ifdef CMAKECONFIG -#ifndef NDEBUG -	I_OutputMsg(","CMAKE_ASSETS_DIR); -	strcpy(returnWadPath, CMAKE_ASSETS_DIR); -	if (isWadPathOk(returnWadPath)) -	{ -		return returnWadPath; -	} -#endif -#endif - -#ifdef __APPLE__ -	OSX_GetResourcesPath(returnWadPath); -	I_OutputMsg(",%s", returnWadPath); -	if (isWadPathOk(returnWadPath)) -	{ -		return returnWadPath; -	} -#endif // examine default dirs #ifdef DEFAULTWADLOCATION1 @@ -2884,16 +2850,7 @@ static const char *locateWad(void) if (isWadPathOk(returnWadPath)) return returnWadPath; #endif -#ifndef NOHOME -	// find in $HOME -	I_OutputMsg(",HOME"); -	if ((envstr = I_GetEnv("HOME")) != NULL) -	{ -		WadPath = searchWad(envstr); -		if (WadPath) -			return WadPath; -	} -#endif + #ifdef DEFAULTSEARCHPATH1 // find in /usr/local I_OutputMsg(", in:"DEFAULTSEARCHPATH1); </del>

Discussion:
The srb2 assets are outdated. Steps to reproduce the behaviour: the game or run the command while in game The that the assets are being downloaded from hasn't been updated since 2020
I just noticed this pr, but it seems to have gone dead 3 months ago
closing as I'm making a new issue
Change:
be forced as follows: <programlisting><xref linkend="opt-hardware.opengl.extraPackages"/> = [ <del> <package>amdvlk</package> </del> <ins> pkgs.<package>amdvlk</package> ]; # To enable Vulkan support for 32-bit applications, also add: <xref linkend="opt-hardware.opengl.extraPackages32"/> = [ pkgs.driversi686Linux.<package>amdvlk</package> </ins> ]; # For amdvlk

Discussion:
Project description introduced amdvlk to nixos already, but afaict this only works with 64bit application, but since a lot of especially games are still 32bit it really would be nice to also be able to run those with amdvlk. I currently have this: In my nixos configuration to make sure that if possible amdvlk is used but also to make sure 32bit applications can still run Metadata should be the same
What would be the right way to do this with nix? The possibilities I see are: with the nix i686 toolchain (working amdvlk here: , can be used as ) A disadvantage of 2. is that it does not support lto.
Change:
buildGoModule rec { pname = "kubecolor"; <del> version = "0.0.20"; </del> <ins> version = "0.0.21"; </ins> src = fetchFromGitHub { <del> owner = "hidetatz"; </del> <ins> owner = pname; </ins> repo = pname; rev = "v${version}"; <del> sha256 = "sha256-bKHEp9AxH1CcObhNzD3BkNOdyWZu7JrEdsXpo49wEcI="; </del> <ins> sha256 = "sha256-d1gtbpeK9vp8bwhsMOPVKmohfyEZtQuvRB36VZCB3sY="; </ins> }; <del> vendorSha256 = "sha256-C1K7iEugA4HBLthcOI7EZ6H4YHW6el8X6FjVN1BeJR0="; </del> <ins> vendorSha256 = "sha256-g5bLi0HQ7LQM+DKn5x8enXn8/9j3LFhgDjQ+YN0M7dM="; </ins> ldflags = [ "-s" "-w" "-X main.Version=${version}" ]; meta = with lib; { description = "Colorizes kubectl output"; <del> homepage = "https://github.com/hidetatz/kubecolor"; changelog = "https://github.com/hidetatz/kubecolor/releases/tag/v${version}"; </del> <ins> homepage = "https://github.com/kubecolor/kubecolor"; changelog = "https://github.com/kubecolor/kubecolor/releases/tag/v${version}"; </ins> license = licenses.mit; maintainers = with maintainers; [ ivankovnatsky SuperSandro2000 ]; };

Discussion:
name: kubecolor current version: 0.0.20 desired version: 0.0.21 maintainers: new repo maintainer : Original repo remains unmaintained and current version () faces few behavior problems, for example alias completion is half-broken on Zsh. A fork is working on these issues, that seems to be fixed for me in the new release . Maybe switching to the main kubecolor fork could be considered a good mid-long term solution ? Thanks alot :pray:
Do I have to do anything for this to happen ?
No, thanks Update in PR
Refined GitHub messed up that fixed
Change:
<del> { lib, stdenv, fetchFromGitHub }: </del> <ins> { lib , stdenv , fetchFromGitHub }: </ins> stdenv.mkDerivation { pname = "google-fonts"; <del> version = "2019-07-14"; </del> <ins> version = "unstable-2021-01-19"; </ins> outputs = [ "out" "adobeBlank" ]; src = fetchFromGitHub { owner = "google"; repo = "fonts"; <del> rev = "f113126dc4b9b1473d9354a86129c9d7b837aa1a"; sha256 = "0safw5prpa63mqcyfw3gr3a535w4c9hg5ayw5pkppiwil7n3pyxs"; </del> <ins> rev = "a3a831f0fe44cd58465c6937ea06873728f2ba0d"; sha256 = "19abx2bj7mkysv2ihr43m3kpyf6kv6v2qjlm1skxc82rb72xqhix"; </ins> }; phases = [ "unpackPhase" "patchPhase" "installPhase" ];

Discussion:
<!-- 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: google-fonts <!-- 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: 2019-07-14 desired version: 2021-01-?? (see ) <!-- Search your package here: If no maintainer is listed for your package, tag the person that last updated the package --maintainers: (the most recent committer here) Please tag this issue in your PR.
Change:
makeWrapper = makeBinaryWrapper; }; <del> wrapGAppsHook4 = wrapGAppsHook.override { gtk3 = gtk4; }; </del> <ins> wrapGAppsHook4 = wrapGAppsHook.override { gtk3 = __splicedPackages.gtk4; }; </ins> wrapGAppsNoGuiHook = wrapGAppsHook.override { isGraphical = false; };

Discussion:
Appear on nixpkgs nixos-23.05 branch ( revision)
greetings I know this is not cross compiling can you provide step to reproduce
I created a almost minimal flake to do x86_64 to aarch64 cross.
even much simpler way to reproduce (but it build alot in process before fail)
Well, my research show that it pull graphene into the build from wrong (builder) architecture But have no idea how it happens
sorry for lack of communication I can indeed reproduce the issue. Good/bad news is that it affects other packages as well. I also dont know whats causing apart from the fact that something is pulling in x86 dependency. I am currently bisecting a range of commits that also has 2 other falures, so I am not sure what the result will be. I'll post here as soon as I find out
I'd pretty sure, that problematic dependencies -- is a gtk4 . (I tried to build package which depends on gtk4 only, and it have same issue, so we can exclude libadwaita). So probably is a generic gtk4 problem, and we need mention anyone from gnome' team
It looks like generic gtk4 problem
It's a issue with wrapGAppsHook4,, fixing