haskellPackages: support template-haskell and test suites when cross compiling by alexfmpe · Pull Request #445672 · NixOS/nixpkgs

alexfmpe · 2025-09-24T00:32:36Z

Adapted from
https://github.com/input-output-hk/haskell.nix/blob/c0454391b7b026387623289d3deb4ce9b431a528/overlays/linux-cross.nix

~~Also unblocks meaningful work on cross testing since TH is used in every other suite for test discovery, including QuickCheck's~~
~~EDIT: Also run test suites ( pkgsCross.ghcjs ones need #451527 )~~ Moved to #451928

Building/running haskell.packages.ghc912.aeson-gadt-th on x86_64-linux:

✔️ pkgsStatic
✔️ pkgsCross.aarch64-multiplatform
✔️ pkgsCross.aarch64-multiplatform-musl
❌ pkgsCross.aarch64-android-prebuilt
❌ pkgsCross.ucrt64

Note aarch64-android-prebuilt.pkgsStatic builds for the wrong reasons as

nix-repl> with pkgsCross.aarch64-android-prebuilt.pkgsStatic.stdenv.hostPlatform; { inherit isAarch isMusl isStatic isAndroid useAndroidPrebuilt; }                       
{
  isAarch = true;
  isAndroid = false;
  isMusl = true;
  isStatic = true;
  useAndroidPrebuilt = false;
}

which leads to problems down the line (e.g when trying to add system tools). However, trying

{
  isAarch = true;
  isAndroid = true;
  isMusl = false;
  isStatic = true;
  useAndroidPrebuilt = true;
}

fails when building TH with iserv-proxy-interpreter: internal error: ASSERTION FAILED: file rts/linker/Elf.c, line 812
which is https://gitlab.haskell.org/ghc/ghc/-/blob/ghc-9.12.2-release/rts/linker/Elf.c#L812

Example run

$ uname -mo
x86_64 GNU/Linux

$ nix-build -A pkgsCross.aarch64-multiplatform.haskell.packages.ghc912.th-orphans   
...
Running phase: buildPhase
Preprocessing library for th-orphans-0.13.16...
Building library for th-orphans-0.13.16...
[1 of 2] Compiling Language.Haskell.TH.Instances.Internal ( src/Language/Haskell/TH/Instances/Internal.hs, dist/build/Language/Haskell/TH/Instances/Internal.o, dist/build/Language/Haskell/TH/Instances/Internal.dyn_o )
[2 of 2] Compiling Language.Haskell.TH.Instances ( src/Language/Haskell/TH/Instances.hs, dist/build/Language/Haskell/TH/Instances.o, dist/build/Language/Haskell/TH/Instances.dyn_o )
---> Starting interpreter on port 6151
---| interpreter should have started on 6151
Listening on port 6151
---> killing interpreter...
[1 of 2] Compiling Language.Haskell.TH.Instances.Internal ( src/Language/Haskell/TH/Instances/Internal.hs, dist/build/Language/Haskell/TH/Instances/Internal.p_o )
[2 of 2] Compiling Language.Haskell.TH.Instances ( src/Language/Haskell/TH/Instances.hs, dist/build/Language/Haskell/TH/Instances.p_o )
---> Starting interpreter on port 5830
---| interpreter should have started on 5830
Listening on port 5830
---> killing interpreter...
buildPhase completed in 3 minutes 32 seconds
...

> $(nix-build -A qemu-user)/bin/qemu-aarch64 $(nix-build -A pkgsCross.aarch64-multiplatform.haskell.packages.ghc912.aeson-gadt-th)/bin/readme
Encoding of A_a:
"[\"A_a\",[]]"
Decoding of encoded A_a:
Just (Some A_a)

Encoding of (A_b 1):
"[\"A_b\",1]"
Decoding of encoded (A_b 1):
Just (Some (A_b 1))

Encoding of (B_a 'a' (A_b 1)):
"[\"B_a\",[\"a\",[\"A_b\",1]]]"
Decoding of encoded (B_a 'a' (A_b 1)):
Succeeded

Things done

Add a 👍 reaction to pull requests you find important.

pkgs/development/haskell-modules/configuration-ghc-9.10.x.nix

pkgs/development/haskell-modules/generic-builder.nix

alexfmpe · 2025-09-24T00:44:28Z

pkgs/development/tools/haskell/iserv-proxy/default.nix

+  pname = "iserv-proxy";
+  version = "9.3";
+
+  # https://github.com/stable-haskell/iserv-proxy/pull/1


The official looking one is still on 9.3?
https://gitlab.haskell.org/ghc/iserv-proxy/-/blob/123190b28ec4b4c7c0b0a7e5ecd1d083f0b57830/iserv-proxy.cabal#L83-L84

Should probably talk to the stable haskell/haskell.nix folks what the state is there, but given that haskell.nix depends on it in some capacity, I'm not worried it will go away suddenly?

pkgs/development/haskell-modules/generic-builder.nix

alexfmpe · 2025-10-07T19:28:25Z

Am I holding it wrong?

Hmm no, I am actually. Here's where we stand

Besides the basic machinery added here, there's a bunch of per-config tweaks that will be needed (e.g. env flags for wine).
I'm mostly been testing with a few x86_64-linux -> aarch64-linux because those require minimal tweaking.

https://github.com/NixOS/nixpkgs/blob/5a49a581d1e4be1bb422c3f332ecbfe8d7043dc6/pkgs/development/haskell-modules/generic-builder.nix#L26-L47

The reason I special cased aarch64-linux hosts for now is that only relying on emulatorAvailable can be a regression, as was recently the case for pkgsCross.ucrt64 since executables couldn't be built, meaning iserv-proxy couldn't be built, meaning no packages could be built at all since eval doesn't know ahead of time which need template haskell.

On my x86_64-linux, when relaxing the restriction to isLinux

pkgsStatic.haskell.packages.ghc96.th-orphans fails as this libiserv approach is > 9.6
pkgsStatic.haskell.packages.ghc910.th-orphans fails with some error about gmp/ghc-bignum I haven't looked into yet
pkgsStatic.haskell.packages.native-bignum.ghc910.th-orphans builds
pkgsStatic.haskell.packages.native-bignum.ghc912.th-orphans builds

After looking at #383165, I'd say that it works for pkgsStatic accidentally because emulatorAvailable also looks at canExecute. I don't think we need nor want the whole iserv-proxy dance for the static "native-cross".

Seems to me the concerns on my PR and yours interact in subtle ways so I'd say we ought to get at least one of them merged so they can then be addressed together. Plently of layers on this onion to peel anyway.

sternenseemann · 2025-11-25T11:32:00Z

pkgs/development/haskell-modules/make-package-set.nix

+    iserv-proxy = {
+      build = buildHaskellPackages.iserv-proxy;
+      host = self.iserv-proxy;
+    };


You can add iserv-proxy to nativeBuildInputs, so the iserv-proxy in path will be executable. ${emulator} ${iserv-proxy} will use the host one. This is also a little confusing, but more in line with how nixpkgs usually works. Alternatively, you can use __spliced explicitly. (Replying to https://github.com/NixOS/nixpkgs/pull/445672/files#r2426707459 which github doesn't allow me)

Hm though this does not work with the inline overrides and symlinkJoin too well, ideally we'd add that to the package set probably.

sternenseemann · 2025-11-25T11:38:04Z

Oh, keep in mind this all works with 9.10.

Aren't there some conditionals gating on >= 9.12?

sternenseemann · 2025-11-25T11:41:22Z

LGTM, but I agree with @wolfgangwalther that the iserv-proxy = { … } argument is awkward and best redesigned. I think I have an idea on how to do it. In principle, I'd be fine with merging this, and I try to implement that in a follow up. We are going to be on unstable for a while now, so we can afford to do that :)

WDYT @wolfgangwalther?

wolfgangwalther · 2025-11-25T11:42:28Z

I'm happy with that approach, too.

alexfmpe · 2025-11-25T11:49:13Z

Aren't there some conditionals gating on >= 9.12?

I don't think so? Only thing I can find is that the aarch-multiplatform jobset is for ghc912, but that can be changed to ghc910 or probably just haskellPackages?
I've been defaulting to 9.12 because several platforms are in a better shape there than 9.10 and it was easier to just stick to one version. Will become moot point anyway once LTS is bumped

alexfmpe · 2025-11-27T20:19:18Z

I just noticed the dependency on iserv-proxy introduces two regressions on pkgsCross.ucrt64.haskell.packages.ghc912.hello.
Pushing a few simple commits to fix that

alexfmpe · 2025-11-27T20:30:19Z

pkgs/development/haskell-modules/configuration-cross.nix

+    libiserv
+    network
+    ;
+}


While not strictly needed, I grabbed this change ahead of time from #451928 since it allows keeping all 'iserv-proxy-closure' overrides in one place. The trigger being the following commit adding splitmix to the bunch but configuration-nix.nix already had a splitmix override

wolfgangwalther

I worked through this PR and rebased. Here are some notes on what I did and noticed:

I rebased the branch on very latest haskell-updates, which I bumped hackage on ~~today~~ yesterday.
The last commit was to bump iserv-proxy - I squashed that into the first commit and also adjusted the version number with the correct unstable date.
At the first commit, I can build iserv-proxy for GHC 9.8, 9.10 and 9.12 - which seems reasonable: The default version + one version in both directions. I can't build iserv-proxy for GHC 9.4, GHC 9.6 or GHC HEAD, the latter fails somewhere in the dependencies.
The second commit contained changes specifically for GHC 9.6 and libiserv. But iserv-proxy does not build with or without these changes for GHC 9.6, so I backed these out and put them into a fixup to look at later, if at all. We can be happy to be able to do this for GHC 9.8+, I think.
The second commit also contained changes to use the external interpreter for test suites. This contained the following line exec ${if (isCross && crossSupport.canCheck) then "node" else crossSupport.emulator} "$@". This seems wrong, because why should we always use node when in a cross setting - and if not fallback to the cross emulator? I think the condition should rather be on isGhcjs or so? I removed this for now, to reduce scope a bit - and to prevent rebuild of the default non-cross compiler. This can be introduced in a follow up again, to enable testing with the external interpreter - let's focus on TH as the first step. I kept the relevant changes as a fixup commit for future reference.
With the second commit, I am able to build th-orphans, which was not possible in any cross setting before:
- aarch64 -> x86_64 (gnu)
- aarch64 -> x86_64 (musl)
- x86_64 -> aarch64 (gnu)
- (did not test musl for x86 -> aarch64)
Notably the things that didn't work on the second commit were:
- pkgsStatic - which failed with error: Dynamic loading not supported - I believe this is fixed by the third commit, but the conditions (android || musl) seem wrong. I think this should be conditioned on isStatic.
- aarch64-darwin fails to build the compiler. Haven't looked deeper into that, yet.
- pkgsCross.aarch64-android-prebuilt failed with: qemu-aarch64: Could not open '/system/bin/linker64': No such file or directory.

I just pushed my current state. I will let some builds finish and then plan to push the first few commits to haskell-updates already, but not merge the full PR, yet. We can then iterate on the remaining commits, where I still have question marks for me.

wolfgangwalther · 2025-11-30T11:31:27Z

pkgs/development/haskell-modules/configuration-nix.nix

-  # Compiling the readme throws errors and has no purpose in nixpkgs
-  aeson-gadt-th = disableCabalFlag "build-readme" super.aeson-gadt-th;
-


This change doesn't make sense to me. Building the readme is still not required and we have plenty of other packages to build to verify that TH works, right?

This is one package I know of where the executable uses TH, so I was using it as a sanity check.
Haven't found a case where TH libs work but an executable doesn't so I don't feel strongly about it.

wolfgangwalther · 2025-11-30T11:32:59Z

pkgs/development/haskell-modules/generic-builder.nix

    fi

-    exec "$@"
+    exec ${if (isCross && crossSupport.canCheck) then "node" else crossSupport.emulator} "$@"


This condition seems very wrong - it will use node in a regular cross setting. Shouldn't this have some component of checking for isGhcjs or so?

Huh yeah stuff got lost in the last rebase

pkgs/top-level/release-haskell.nix

wolfgangwalther · 2025-11-30T12:03:11Z

pkgs/development/compilers/ghc/common-hadrian.nix

+      lib.optionals
+        (targetPlatform.isAndroid || (targetPlatform.isMusl && hostPlatform != targetPlatform))
+        [
+          "*.ghc.cabal.configure.opts += --flags=-dynamic-system-linker"


The condition here is wrong, according to my experiments. Cross with musl works fine, but once we do isStatic it doesn't. Quite obviously.

I'm not sure whether we should just check isStatic - or whether we should actually check enableShared, which includes isStatic and more.

Given that the error message for android is:

qemu-aarch64: Could not open '/system/bin/linker64': No such file or directory

... I wonder whether we should actually add the isAndroid condition to enableShared to begin with?

I tried the other cases in enableShared, i.e. windows, iOSPrebuilt, ghcjs - but I can't even get to a sensible error message for the first two and ghcjs works regardless. So I guess we can keep it at isStatic here for now.

pkgs/development/haskell-modules/configuration-cross.nix

Fixes error: "iserv-proxy-interpreter: Failed to lookup symbol: __gmpn_cmp" This comes up when building `pkgsStatic.haskell.packages.ghc...`, aka without `.native-bignum` modifier.

These changes were split from the commit before, keeping for future reference for now.

wolfgangwalther · 2025-11-30T18:16:22Z

OK, I pushed a good chunk of this to haskell-updates already. This should make regular cross (x86 -> aarch64) and pkgsStatic work. Will look into the other / remaining bits here next - still building a ton of stuff right now.

wolfgangwalther

I tested more stuff again and I don't think any of the remaining bits are ready to merge right now.

How should we proceed - would you like to take these and open separate PRs for them, with more detailed reasoning and showing how they help? Or should we keep them together in this PR?

wolfgangwalther · 2025-12-02T14:34:51Z

pkgs/development/compilers/ghc/common-hadrian.nix

    ]
    # Inform GHC that we can't load dynamic libraries which forces iserv-proxy to load static libraries.
-    ++ lib.optionals targetPlatform.isStatic [
+    ++ lib.optionals (targetPlatform.isAndroid || targetPlatform.isStatic) [


You had the android condition here, but I didn't merge it, yet and instead put it into a separate commit.

I can't make android work with it, I still always get:

qemu-aarch64: Could not open '/system/bin/linker64': No such file or directory

I tried:

NIXPKGS_ALLOW_UNFREE=1 nix-build -A pkgsCross.aarch64-android-prebuilt.haskell.packages.native-bignum.ghc910.th-orphans

And the same for GHC 9.12 - it fails with the same error.

GHC 9.8 fails because it can't apply an android related patch, I doubt you had been testing with that before.

What did you do that made the isAndroid condition here an improvement?

qemu-aarch64: Could not open '/system/bin/linker64': No such file or directory

That happens with any android build that requires the dynamic linker, unless you run it on an android system

$ NIXPKGS_ALLOW_UNFREE=1 nix-build -A pkgsCross.aarch64-android-prebuilt.hello /nix/store/f60sv415dxv7am0f06lm956jn2ni4nja-hello-aarch64-unknown-linux-android-2.12.2 $ file result/bin/hello result/bin/hello: ELF 64-bit LSB pie executable, ARM aarch64, version 1 (SYSV), dynamically linked, interpreter /system/bin/linker64, not stripped $ ./result-qemu-user/bin/qemu-aarch64 result/bin/hello qemu-aarch64: Could not open '/system/bin/linker64': No such file or directory $ NIXPKGS_ALLOW_UNFREE=1 nix-build -A pkgsCross.aarch64-android-prebuilt.pkgsStatic.hello /nix/store/5jzni4r3gyi0aj7hbx9w39xwn9c523sh-hello-static-aarch64-unknown-linux-musl-2.12.2 $ file result/bin/hello result/bin/hello: ELF 64-bit LSB executable, ARM aarch64, version 1 (SYSV), statically linked, not stripped $ ./result-qemu-user/bin/qemu-aarch64 result/bin/hello Hello, world!

What did you do that made the isAndroid condition here an improvement?

IIRC it made TH work for pkgsCross.aarch64-android-prebuilt.pkgsStatic but that config is a strange creature, as stated in the PR description.

GHC 9.8 fails because it can't apply an android related patch, I doubt you had been testing with that before.

Yeah, I only got android to work on 9.10+. I think something on GHC configure would need backporting for 9.8

IIRC it made TH work for pkgsCross.aarch64-android-prebuilt.pkgsStatic but that config is a strange creature, as stated in the PR description.

Yeah these things (pkgsCross + pkgsStatic) don't compose, so that is not a relevant result. See #380342 and related PRs.

That happens with any android build that requires the dynamic linker, unless you run it on an android system

Right, so this means that iserv-proxy TH will only ever work this way, if we're building with isStatic = true. Which in turn means, that we don't need the isAndroid condition here anymore, because we already condition on isStatic.

wolfgangwalther · 2025-12-02T14:37:44Z

pkgs/development/compilers/ghc/common-hadrian.nix

      "--with-ffi-libraries=${targetLibs.libffi.out}/lib"
    ]
-    ++ lib.optionals (targetPlatform == hostPlatform && !enableNativeBignum) [
+    ++ lib.optionals (!enableNativeBignum) [


I tested this, and I believe this makes pkgsStatic.haskell.packages.ghc98.th-orphans (same for 9.10 and 9.12, i.e. without native-bignum) work - but only on x86_64. It still failed for me on aarch64 with similar errors as before (not exactly the same, but similar).

I believe we should never enable gmp when linking statically, due to licensing issues. I'd say we should even default pkgsStatic.haskell.packages.ghc[...] to the native-bignum variants, without the modifier present.

Thus, I'm not keen on merging this change right now.

alexfmpe · 2025-12-04T02:03:34Z

How should we proceed - would you like to take these and open separate PRs for them, with more detailed reasoning and showing how they help? Or should we keep them together in this PR?

Yeah better to open separate PRs for the remaining concerns, I've been sitting on a dozen commits for weeks waiting for the main stuff to be merged anyway as it wasn't feasible to throw more stuff on this one nor open dependent PRs and having cascading rebases.
I'd still keep this PR as draft for now as a reminder of unfinished things.

wolfgangwalther · 2026-02-07T11:44:39Z

The second commit contained changes specifically for GHC 9.6 and libiserv. But iserv-proxy does not build with or without these changes for GHC 9.6, so I backed these out and put them into a fixup to look at later

Just noted that the upstream iserv-proxy PR now contains https://github.com/stable-haskell/iserv-proxy/pull/1/changes/dc144516464d3b4f4107b1765873473758aae1dc..91ef7ffdeedfb141a4d69dcf9e550abe3e1160c6, which seems to fix something for GHC < 9.7, so it might be worth looking into 9.6 again here.

alexfmpe · 2026-02-07T20:16:19Z

The second commit contained changes specifically for GHC 9.6 and libiserv. But iserv-proxy does not build with or without these changes for GHC 9.6, so I backed these out and put them into a fixup to look at later

Just noted that the upstream iserv-proxy PR now contains https://github.com/stable-haskell/iserv-proxy/pull/1/changes/dc144516464d3b4f4107b1765873473758aae1dc..91ef7ffdeedfb141a4d69dcf9e550abe3e1160c6, which seems to fix something for GHC < 9.7, so it might be worth looking into 9.6 again here.

#488080

alexfmpe · 2026-02-16T22:25:46Z

pkgsCross.ucrt64.haskell.packages.ghc912.th-orphans builds as of #479902
pkgsCross.raspberryPi.haskell.packages.ghc912.th-orphans also builds, though 9.10 and 9.14 output LLVM errors

alexfmpe requested review from maralorn, sternenseemann and wolfgangwalther September 24, 2025 00:32

ofborg bot added the 6.topic: cross-compilation Building packages on a different platform than they will be used on label Sep 24, 2025

alexfmpe marked this pull request as draft September 24, 2025 00:32

alexfmpe force-pushed the cross-template-haskell branch from d163368 to 2110df8 Compare September 24, 2025 00:51

alexfmpe commented Sep 24, 2025

View reviewed changes

alexfmpe mentioned this pull request Sep 25, 2025

Modernize Android support reflex-frp/reflex-platform#850

Open

6 tasks

nixpkgs-ci bot added the 2.status: merge conflict This PR has merge conflicts with the target branch label Sep 27, 2025

alexfmpe marked this pull request as ready for review October 2, 2025 03:04

alexfmpe force-pushed the cross-template-haskell branch 2 times, most recently from 73bd537 to 0122493 Compare October 2, 2025 03:07

nixpkgs-ci bot removed the 2.status: merge conflict This PR has merge conflicts with the target branch label Oct 2, 2025

alexfmpe force-pushed the cross-template-haskell branch 3 times, most recently from 4840be1 to 3938e32 Compare October 7, 2025 03:27

alexfmpe marked this pull request as draft October 7, 2025 03:29

alexfmpe force-pushed the cross-template-haskell branch from 3938e32 to 46474da Compare October 7, 2025 04:08

alexfmpe marked this pull request as ready for review October 7, 2025 05:29

alexfmpe commented Oct 7, 2025

View reviewed changes

pkgs/development/haskell-modules/generic-builder.nix Outdated Show resolved Hide resolved

alexfmpe changed the title ~~haskellPackages: use iserv-proxy for cross template-haskell~~ haskellPackages: support template-haskell and test suites when cross compiling Oct 7, 2025

This comment was marked as outdated.

Sign in to view

alexfmpe force-pushed the cross-template-haskell branch from 7f57666 to 5a49a58 Compare October 7, 2025 06:21

alexfmpe commented Oct 7, 2025

View reviewed changes

pkgs/development/haskell-modules/generic-builder.nix Outdated Show resolved Hide resolved

This comment was marked as resolved.

Sign in to view

nixpkgs-ci bot added the 10.rebuild-linux: 5001+ This PR causes many rebuilds on Linux and must target the staging branches. label Nov 24, 2025

sternenseemann reviewed Nov 25, 2025

View reviewed changes

alexfmpe commented Nov 27, 2025

View reviewed changes

wolfgangwalther self-assigned this Nov 29, 2025

wolfgangwalther force-pushed the cross-template-haskell branch from 1bc395f to 0f4ffa9 Compare November 30, 2025 12:15

wolfgangwalther reviewed Nov 30, 2025

View reviewed changes

wolfgangwalther force-pushed the cross-template-haskell branch from 0f4ffa9 to b613cdb Compare November 30, 2025 18:06

alexfmpe and others added 4 commits November 30, 2025 19:14

haskellPackages: when requested, configure gmp even if cross compiling

92492a7

Fixes error: "iserv-proxy-interpreter: Failed to lookup symbol: __gmpn_cmp" This comes up when building `pkgsStatic.haskell.packages.ghc...`, aka without `.native-bignum` modifier.

WIP: haskellPackages: support Template Haskell when cross compiling

ec6331e

These changes were split from the commit before, keeping for future reference for now.

haskellPackages.ghc: disable dynamic linker for android

95de67a

haskellPackages.aeson-gadt-th: re-enable readme executable

87ba7fb

wolfgangwalther force-pushed the cross-template-haskell branch from b613cdb to 87ba7fb Compare November 30, 2025 18:15

wolfgangwalther reviewed Dec 2, 2025

View reviewed changes

wolfgangwalther marked this pull request as draft December 2, 2025 14:39

wolfgangwalther mentioned this pull request Dec 8, 2025

haskellPackages: stackage LTS 24.21 -> LTS 24.23 #466258

Merged

wolfgangwalther removed their assignment Dec 11, 2025

wolfgangwalther mentioned this pull request Dec 14, 2025

pkgsStatic.haskellPackages.ghc: 9.4 -> 9.12 #467571

Merged

3 tasks

alexfmpe mentioned this pull request Jan 18, 2026

haskellPackages: allow configuring gmp when cross compiling #481162

Merged

13 tasks

alexfmpe mentioned this pull request Jan 28, 2026

haskellPackages: fix pkgsStatic on aarch64-darwin #484571

Merged

13 tasks

nixpkgs-ci bot added the 2.status: merge conflict This PR has merge conflicts with the target branch label Feb 26, 2026

		# Compiling the readme throws errors and has no purpose in nixpkgs
		aeson-gadt-th = disableCabalFlag "build-readme" super.aeson-gadt-th;

Uh oh!

Conversation

alexfmpe commented Sep 24, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Things done

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

This comment was marked as outdated.

Uh oh!

This comment was marked as resolved.

alexfmpe commented Oct 7, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

sternenseemann commented Nov 25, 2025

Uh oh!

sternenseemann commented Nov 25, 2025

Uh oh!

wolfgangwalther commented Nov 25, 2025

Uh oh!

alexfmpe commented Nov 25, 2025

Uh oh!

alexfmpe commented Nov 27, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

alexfmpe Nov 27, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

wolfgangwalther left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

alexfmpe Dec 4, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

wolfgangwalther commented Nov 30, 2025

Uh oh!

wolfgangwalther left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

alexfmpe Dec 4, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

alexfmpe commented Dec 4, 2025

Uh oh!

alexfmpe commented Sep 24, 2025 •

edited

Loading

alexfmpe commented Oct 7, 2025 •

edited

Loading

alexfmpe commented Nov 27, 2025 •

edited

Loading

alexfmpe Nov 27, 2025 •

edited

Loading

wolfgangwalther left a comment •

edited

Loading

alexfmpe Dec 4, 2025 •

edited

Loading

alexfmpe Dec 4, 2025 •

edited

Loading