Fix formula by kdunn926 · Pull Request #17 · ElmerCSC/homebrew-elmerfem

kdunn926 · 2026-01-08T21:58:42Z

Refactored to work on modern macOS, ensure devel branch builds (with ElmerGUI), allow using GCC or Clang

All tests for both devel and release-9.0 are passing in Clang (default) and GCC builds on Apple Silicon in MacOS 15.3.1.

…UI), allow using GCC or Clang

kdunn926 · 2026-01-20T05:36:15Z

@raback - I think this PR makes Elmer more accessible on macos (again). If testing is helpful I can also add a GitHub actions to this repo...

mmuetzel · 2026-06-17T05:53:03Z

Thank you very much for looking into this. 🙏

Maybe, you could take the opportunity and update the stable build to version 26.2.
That would likely allow to simplify the build and packaging rules.

Bump the stable build from release-9.0 to release-26.2: - Update url/sha256 to the release-26.2 tarball. - Drop the six commit-based patches; all are merged upstream into 26.2 (each commit is an ancestor of the tag) and would now fail to apply. - Drop the __END__ DATA patch; its targets no longer exist in 26.2 (the hard-coded /usr/local/bin compiler block is gone and the OpenMP FIND_PACKAGE/SET ordering is already correct upstream). - Use the current "gcc" dependency for stable instead of the release-9.0-era "gcc@11" pin, so the build uses the gfortran that the "gcc" dependency actually provides. Verified: stable (26.2) and HEAD both configure, build, and run (ElmerSolver reports v26.2). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

kdunn926 · 2026-06-21T14:10:27Z

@mmuetzel I updated it to version 26.2 and confirm both that version and head build on my mac

mmuetzel

Thanks for updating to the latest release.

Can the parts about Qt5 be dropped with that now?

kdunn926 · 2026-06-24T07:07:42Z

Thanks for reviewing this and offering suggestions. I think I address all the comments and I re-ran the build again locally to confirm everything is in order.

mmuetzel · 2026-06-24T08:07:34Z

The rules look good to me now. 👍
I don't have access to macOS. So, I can't test myself. But you already ran tests locally.

@raback: Ok to merge?

mmuetzel

I don't know exactly how Homebrew handles optional dependencies. But by looking at other Homebrew packages I assume that they are treated as optional at runtime.
Optional build dependencies need to be handled differently afaict.

kdunn926 · 2026-07-03T05:27:57Z

I don't know exactly how Homebrew handles optional dependencies. But by looking at other Homebrew packages I assume that they are treated as optional at runtime. Optional build dependencies need to be handled differently afaict.

Honestly, I'm not certain what the correct convention is. Even after reading the docs, it seems a bit vague. My understanding is that it is compile-time, rather than runtime. The formula is written to link the dependencies to the actual compilation flags.

PR suggestion Co-authored-by: Markus Mützel <markus.muetzel@gmx.de>

mmuetzel · 2026-07-03T06:02:55Z

+  def apply_gcc_qt6_patch
+    patch_content = <<~PATCH
+      --- ElmerGUI/CMakeLists.txt
+      +++ ElmerGUI/CMakeLists.txt
+      @@ -35,6 +35,10 @@
+         FOREACH(_pkg ${QT6_PKG_LIST})
+           FIND_PACKAGE(${_pkg} PATHS ${QT6_PATH} REQUIRED)
+         ENDFOREACH()
+      +  
+      +  IF(APPLE AND CMAKE_CXX_COMPILER_ID STREQUAL "GNU")
+      +    SET(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -D'QT_IGNORE_DEPRECATIONS\\(x\\)=x'")
+      +  ENDIF()
+
+         ADD_DEFINITIONS(-DWITH_QT6)
+         MESSAGE(STATUS "  [ElmerGUI] Qt6:               " ${Qt6_FOUND})
+    PATCH


If adding the flag in the formula works (see other suggestion), you can probably get rid of this patch.

Suggested change

def apply_gcc_qt6_patch

patch_content = <<~PATCH

--- ElmerGUI/CMakeLists.txt

+++ ElmerGUI/CMakeLists.txt

@@ -35,6 +35,10 @@

FOREACH(_pkg ${QT6_PKG_LIST})

FIND_PACKAGE(${_pkg} PATHS ${QT6_PATH} REQUIRED)

ENDFOREACH()

+

+ IF(APPLE AND CMAKE_CXX_COMPILER_ID STREQUAL "GNU")

+ SET(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -D'QT_IGNORE_DEPRECATIONS\$x\$=x'")

+ ENDIF()

ADD_DEFINITIONS(-DWITH_QT6)

MESSAGE(STATUS " [ElmerGUI] Qt6: " ${Qt6_FOUND})

PATCH

Oops. Missed a couple of lines further down that should also be removed in that case.
I don't know how to change that now though...

Thinking about the condition for which the patch is applied: Was it maybe only needed for (very?) old GCC versions?
Does it still fail to build without this patch with more or less recent versions of GCC?
If it fails, which error does that produce?

In my testing, I found the patch (or your cleaner cxx_flags workaround) is needed even with gcc 16.1.0. That said, I could only get gcc to link against Qt5, not Qt6, which is at least one good reason to keep the Qt5 stuff in the formula around.

Good point. 👍

Is defining that preprocessor macros only needed for GCC? Or does Qt5 also need it with Clang?

Never mind.
The build rules here make clear that GCC selects Qt5 and Clang selects Qt6. So, the combination I asked for is never an option for the user.

More basically: Why is there even an option to build ElmerFEM with GCC on macOS? Is that preferable in some ways compared to using their "system" compiler Clang?

- configure_elmergui: use Qt5 (qt@5/qwt-qt5) for --with-gcc, Qt6 for Clang. Homebrew's Qt6 is Clang/libc++ and exports std::-typed APIs (e.g. QDir::mkdir(std::optional<...>)) only with libc++ mangling, which GCC/libstdc++ can't link; Qt5's API doesn't cross that ABI boundary. - Set each Qt5 component _DIR (qt@5 is keg-only) and add Qt5Widgets to ElmerGUI's macOS Qt5 package list via inreplace. - Drop the forced older-SDK selection for stable+GCC; Homebrew GCC 16 can't parse MacOSX14.sdk headers, so use the current SDK.

kdunn926 · 2026-07-12T13:10:12Z

Thanks for updating to the latest release.

Can the parts about Qt5 be dropped with that now?

When compiling ElmerGUI with gcc, it will only link against Qt5, not Qt6, which is at least one good reason to keep the Qt5 stuff in the formula around.

mmuetzel · 2026-07-13T07:25:59Z

+    if build.with?("accelerate")
+      cmake_args << "-DBLAS_LIBRARIES:STRING=-framework Accelerate"
+      cmake_args << "-DLAPACK_LIBRARIES:STRING=-framework Accelerate"
+    else
+      blas_lib = Formula["openblas"].opt_lib/shared_library("libopenblas")
+      cmake_args << "-DBLAS_LIBRARIES:STRING=#{blas_lib};-lpthread"
+      cmake_args << "-DLAPACK_LIBRARIES:STRING=#{blas_lib};-lpthread"
+    end


Nice! 👍

I didn't know how to correctly build with Apple Accelerate when putting together some build rules for the CI on macOS. Nice to see how it is done. (I hope I'll be able to recall that should it ever come up again.)

If I understand correctly, Apple Accelerate can outperform OpenBLAS on macOS for some workloads.
But I also seem to remember that its interface is somewhat odd (i.e., partly incompatible with gfortran) compared to other implementations of the BLAS/LAPACK libraries. (I seem to recall something about single precision floating point function return arguments being returned as double precision.)
Does the test suite still pass with Apple Accelerate? (Maybe, the affected functions aren't actually being used.)

(It might be worth adding that as a variant to the CI workflows.)

I ran the "quick" test suite (formula flag --with-testing) and all of those pass when using Accelerate (after adding some extra fortran compatibility flags). I only recently learned it exists and was made aware the Elmer package in macports had it as an option, so I lifted that into this formula as well.

That ABI incompatibility is tricky indeed.
I have a feeling that you would need to go "all-in" if you deviate from the default Fortran ABI and rebuild all Fortran dependencies using that ABI.

How does MacPorts handle that?

Edit: It looks like it doesn't handle that at all:
https://github.com/macports/macports-ports/blob/578383b5b39697d1002002afdf00af884377782f/science/elmerfem/Portfile#L59-L63

} elseif {[variant_isset accelerate]} { configure.args-append \ -DBLAS_LIBRARIES="-framework Accelerate" \ -DLAPACK_LIBRARIES="-framework Accelerate" }

Or are there other newer build rules somewhere else that you were comparing to?

Alternatively, it might be possible to use a "BLAS shim" library (like FlexiBLAS).
I don't know how well that integrates into Homebrew though.

Thinking about this, the only more or less "clean" way of using Accelerate given the ABI incompatibility is probably via FlexiBLAS. Homebrew apparently already has a package for it:
https://github.com/Homebrew/homebrew-core/blob/main/Formula/f/flexiblas.rb

Or don't bother with Apple Accelerate for the time being to get this PR over the finish line. A variant with it could also be added in a follow-up change.

Another (potentially simpler) alternative for the --with-accelerate variant might be linking to vecLibFort instead of using the Accelerate framework directly:
https://formulae.brew.sh/formula/veclibfort

I went ahead and opened a PR adapting the upstream CI to test with Apple Accelerate using the vecLibFort library as shim: ElmerCSC/elmerfem#841

The essential part is probably this:

${{ matrix.blas == 'accelerate' && '-DBLAS_LIBRARIES="${VECLIBFORT_PREFIX}/lib/libvecLibFort.dylib" \ -DLAPACK_LIBRARIES="${VECLIBFORT_PREFIX}/lib/libvecLibFort.dylib"' || '' }} \

It's probably possible to translate that to the Ruby recipe some way (if you'd like to use the same here).
With that, you shouldn't need to switch the Fortran ABI (with -ff2c). It should be working with the default ABI of gfortran.

don't bother with Apple Accelerate for the time being

I'll drop this change for now and revisit later based on your suggestion for vecLibFort

@mmuetzel Apple Accelerate option reverted in b07753a

Run the quick test suite in a begin/rescue so test failures report a warning but do not abort the install; a fully-built keg is always produced. Add --output-on-failure so failing cases are diagnosable in the build log.

Apple's legacy Accelerate BLAS returns complex-valued results (ZDOTC, ZDOTU, CDOTC, CDOTU) via a hidden first argument (f2c convention), while gfortran's default ABI returns them in registers. Elmer's complex iterative/harmonic/eigen solvers that call these BLAS functions directly therefore crashed inside libBLAS ZDOTC (e.g. complex BiCGStab(l)) or produced wrong norms, failing 7 of the 427 quick tests under Accelerate. Compile the Fortran sources with -ff2c so gfortran uses the matching convention, paired with -fno-second-underscore to undo the implied -fsecond-underscore (which would rename symbols like zdotc__ and break linking against Accelerate and libgomp). With this, the full quick suite passes 427/427 under Accelerate, matching the OpenBLAS result.

mmuetzel · 2026-07-14T06:58:26Z

+      # Apple's legacy Accelerate BLAS uses the f2c calling convention for
+      # complex-valued functions: ZDOTC/ZDOTU/CDOTC/CDOTU return their result
+      # via a hidden first argument rather than in registers. gfortran's default
+      # ABI returns complex in registers, so Elmer's complex solvers that call
+      # these directly (e.g. complex BiCGStab(l), harmonic/eigen EM solvers)
+      # crash inside libBLAS ZDOTC or get wrong results. Building the Fortran
+      # sources with -ff2c switches gfortran to the matching convention.
+      # -ff2c implies -fsecond-underscore (which would rename symbols to e.g.
+      # zdotc__ and break linking against Accelerate and libgomp), so pair it
+      # with -fno-second-underscore to keep the standard single-underscore names.
+      fortran_flags += " -ff2c -fno-second-underscore"


Doesn't that mean that all other dependencies that use Fortran also need to be built using that ABI (e.g., MUMPS)? (Maybe, the same requirement would also hold for OpenMP and MPI.)

Should there be a conflict between --with-accelerate and --with-mumps (and potentially others)?

Here is what I found when running the quick tests with mumps:

Config (both): --HEAD --with-elmergui --with-accelerate --with-openmp --with-open-mpi --with-mumps --with-testing
Platform: macOS 15.3.1 (arm64), Xcode CLT 16.4 · gfortran-16 · Apple Accelerate · MUMPS 5.3.5 (brewsci/num) · open-mpi 5.0.9

Compiler C/C++ Fortran GUI toolkit BLAS/LAPACK MUMPS Quick tests Test time

Clang /usr/bin/clang(++) (libc++) gfortran-16 -ff2c Qt6 (qtbase) Accelerate 6 libs linked 435 / 435 (100%) 226.6 s

GCC gcc-16 / g++-16 (libstdc++) gfortran-16 -ff2c Qt5 (qt@5 + qwt-qt5) Accelerate 6 libs linked 435 / 435 (100%) 239.6 s

Notes

435 tests = 427 base quick suite + 8 MUMPS-specific tests; 0 failures in either config.

-ff2c -fno-second-underscore (auto-applied on the Accelerate path) fixes Apple Accelerate's f2c complex-BLAS calling convention — required for the complex solvers to pass.

GCC path builds ElmerGUI against Qt5 (Qt6 headers don't link under libstdc++); Clang path uses Qt6.

MUMPS wired via brewsci/num/brewsci-mumps with MUMPS_ROOT + SCALAPACK_ROOT + PARMETIS_ROOT + METIS_ROOT hints. It also needs to be patched, as documented here

Left installed: Clang + Qt6 GUI + Accelerate + OpenMP + MPI + MUMPS.

Given the patch requirement (and stale brewsci repo), it may be better to error out that config option with a notice of the issue, in case someone wants to compile it manually to be used with Elmer.

ElmerFEM allows "zmumps" (i.e., complex double-precision floating point) as the "Linear System Direct Method". But apparently, there is no test for it.

I bet, it would fail if you only build ElmerFEM with the f2c Fortran ABI (but not the Mumps libraries).

And even if it wouldn't fail, I still firmly believe that using a shim library for Apple Accelerate (instead of building parts with different Fortran ABIs) is the best way forward.

MUMPS is no longer in homebrew-core, so --with-mumps now pulls brewsci/num/brewsci-mumps and configure_mumps points Elmer's finders at the MUMPS, ScaLAPACK, ParMetis and Metis kegs (metis.h lives in brewsci-metis). With this, --with-mumps builds and the full quick suite passes 435/435 (8 mumps tests added). HYPRE is left on the default keg. The 3 mgdyn_airgap2 tests (HYPRE BiCGStab + BoomerAMG block preconditioning) abort with MPI_ABORT under both HYPRE 2.33.0 and 3.1.0 and under both Accelerate and OpenBLAS, so that is an upstream Elmer/HYPRE issue rather than a build-configuration one; a version pin does not help and only adds fragility.

Add a configuration to the build matrix for the workflow running on macOS that uses Apple Accelerate as the implementation of the BLAS and LAPACK libraries (using the vecLibFort library as a shim for ABI compatibility with gfortran). The implementation from Apple tends to perform better on macOS for some workloads compared OpenBLAS. This came up while reviewing the Homebrew recipe for ElmerFEM: ElmerCSC/homebrew-elmerfem#17

Add a configuration to the build matrix for the workflow running on macOS that uses Apple Accelerate as the implementation of the BLAS and LAPACK libraries (using the vecLibFort library as a shim for ABI compatibility with gfortran). The implementation from Apple might perform better on macOS for some workloads compared to OpenBLAS. This came up while reviewing the Homebrew recipe for ElmerFEM: ElmerCSC/homebrew-elmerfem#17

mmuetzel · 2026-08-03T06:15:30Z

+      # ElmerGUI's Qt5 package list only includes Qt5Widgets on WIN32; on macOS it is
+      # omitted, but the Application needs it (QT5_WRAP_UI). Add it to the list.
+      inreplace "ElmerGUI/CMakeLists.txt",
+                "SET(QT5_PKG_LIST Qt5OpenGL Qt5Xml Qt5Script Qt5Gui Qt5Core Qt5Svg Qt5PrintSupport)",
+                "SET(QT5_PKG_LIST Qt5OpenGL Qt5Xml Qt5Script Qt5Gui Qt5Core Qt5Svg Qt5Widgets Qt5PrintSupport)"


Not a blocker for this change: It might make sense to fix that upstream in the elmerfem repository.

mmuetzel · 2026-08-03T06:17:17Z

Thanks for your continuous work on this.

This looks mostly good to me now (bar the condition for the check for gfortran).

sbishop58 · 2026-08-03T15:14:24Z

Mutzel,I’m interest in giving Elmer a try on my Mac. I have Brew as my installer but is there a binary available?SteveSent from Steve's iPhoneM🍑47On Aug 3, 2026, at 2:17 AM, Markus Mützel ***@***.***> wrote:mmuetzel left a comment (ElmerCSC/homebrew-elmerfem#17) Thanks for your continuous work on this. This looks mostly good to me now (bar the condition for the check for gfortran). —Reply to this email directly, view it on GitHub, or unsubscribe.Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today! You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

Co-authored-by: Markus Mützel <markus.muetzel@gmx.de>

mmuetzel · 2026-08-04T05:28:07Z

@kdunn926: Thanks again for your contribution.
This is looking good to me now.

@raback: Can you merge these changes?

mmuetzel · 2026-08-04T05:35:55Z

is there a binary available?

I'm not aware of binary distributions of Elmer for macOS.

Maybe, the updated recipe here can serve as a template to try and get a recipe into Homebrew core.
But this should probably be done by someone who understands how Homebrew packages are created (and who has access to a macOS device).

@kdunn926: Would you be interested in selecting one of the configuration options of this recipe and upstreaming it to Homebrew?
(Maybe, we'll also get some valuable feedback from the Homebrew maintainers.)

kdunn926 · 2026-08-07T23:28:44Z

Would you be interested in selecting one of the configuration options of this recipe and upstreaming it to Homebrew?

I looked into this a bit. I did the first step of running the brew audit --strict and the changes from that are reflected in 8b7f19e. I think they will require a license to be defined as part of the PR and I noticed the original formula in the repo has no specified one. I don't know if I'm eligible to assign one, so it might be better left for yourself or one of the official Elmer authors/maintainers.

mmuetzel · 2026-08-11T12:59:13Z

Will they need a license for the recipe itself? Or a "field" with the license of the packaged software?
If it is the latter, that would probably be the GPLv2 with exceptions: https://github.com/ElmerCSC/elmerfem/blob/f66f5296260c969dddd1a98f5154af5dd02a7a44/LICENSE.md

I'm not a maintainer of Elmer. I'm just another contributor who is trying to help out here or there if I can.
I also assume that the Homebrew maintainers would like that any contributions are tested before submission. I can't test anything on macOS. (No hardware for that.)
I don't know if any of the maintainers of Elmer can test on macOS (or have time to do so).
Many open source projects rely on volunteers (like yourself) for some parts of their project. That is especially true for parts that don't directly relate to the core of the software. Packaging for different operating systems is probably one of those "more remotely related" parts of the project where volunteers can help out significantly.

Edit: Replaced link to license in my fork with a link to the upstream repository.

Add a configuration to the build matrix for the workflow running on macOS that uses Apple Accelerate as the implementation of the BLAS and LAPACK libraries (using the vecLibFort library as a shim for ABI compatibility with gfortran). The implementation from Apple might perform better on macOS for some workloads compared to OpenBLAS. This came up while reviewing the Homebrew recipe for ElmerFEM: ElmerCSC/homebrew-elmerfem#17

mmuetzel · 2026-08-19T06:51:52Z

Maybe, we should move the discussion about potentially upstreaming a variant of this formula to Homebrew to a new issue.
The changes for the formula in this repository are done if I understand correctly. And they look good to me (as a non-macOS user).

Refactor to work on modern macOS, ensure devel branch builds (wit G…

7b29a44

…UI), allow using GCC or Clang

kdunn926 mentioned this pull request Jan 8, 2026

Compile elmerFEM natively for apple silicon? ElmerCSC/elmerfem#503

Open

mmuetzel reviewed Jun 22, 2026

View reviewed changes

Comment thread elmer.rb Outdated

Comment thread elmer.rb Outdated

mmuetzel reviewed Jun 23, 2026

View reviewed changes

Comment thread elmer.rb Outdated

mmuetzel reviewed Jun 23, 2026

View reviewed changes

Comment thread elmer.rb Outdated

mmuetzel reviewed Jun 23, 2026

View reviewed changes

Comment thread elmer.rb Outdated

implement suggestions

9d24563

mmuetzel suggested changes Jun 29, 2026

View reviewed changes

Comment thread elmer.rb

mmuetzel reviewed Jun 30, 2026

View reviewed changes

Comment thread elmer.rb Outdated

mmuetzel reviewed Jun 30, 2026

View reviewed changes

Comment thread elmer.rb Outdated

kdunn926 commented Jul 3, 2026

View reviewed changes

Comment thread elmer.rb

Update elmer.rb

c60b5a2

PR suggestion Co-authored-by: Markus Mützel <markus.muetzel@gmx.de>

mmuetzel reviewed Jul 3, 2026

View reviewed changes

Comment thread elmer.rb Outdated

mmuetzel reviewed Jul 3, 2026

View reviewed changes

Comment thread elmer.rb Outdated

mmuetzel reviewed Jul 3, 2026

View reviewed changes

kdunn926 added 2 commits July 11, 2026 18:50

remove obsolete patches/flags, add accelerate option

7794a30

mmuetzel reviewed Jul 13, 2026

View reviewed changes

kdunn926 added 2 commits July 14, 2026 00:05

Make --with-testing non-fatal and add --output-on-failure

0a2db42

Run the quick test suite in a begin/rescue so test failures report a warning but do not abort the install; a fully-built keg is always produced. Add --output-on-failure so failing cases are diagnosable in the build log.

mmuetzel reviewed Jul 14, 2026

View reviewed changes

mmuetzel mentioned this pull request Jul 14, 2026

CI (macos): Add configuration using Apple Accelerate as BLAS/LAPACK ElmerCSC/elmerfem#841

Merged

revert apple accelerate option for now

b07753a

kdunn926 requested a review from mmuetzel August 3, 2026 05:24

mmuetzel reviewed Aug 3, 2026

View reviewed changes

Comment thread elmer.rb Outdated

mmuetzel reviewed Aug 3, 2026

View reviewed changes

Apply suggestion from @mmuetzel

25f2f39

Co-authored-by: Markus Mützel <markus.muetzel@gmx.de>

mmuetzel approved these changes Aug 6, 2026

View reviewed changes

apply brew audit --strict fixes

8b7f19e

Compiler	C/C++	Fortran	GUI toolkit	BLAS/LAPACK	MUMPS	Quick tests	Test time
Clang	`/usr/bin/clang(++)` (libc++)	gfortran-16 `-ff2c`	Qt6 (qtbase)	Accelerate	6 libs linked	435 / 435 (100%)	226.6 s
GCC	gcc-16 / g++-16 (libstdc++)	gfortran-16 `-ff2c`	Qt5 (qt@5 + qwt-qt5)	Accelerate	6 libs linked	435 / 435 (100%)	239.6 s

Uh oh!

Conversation

kdunn926 commented Jan 8, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

kdunn926 commented Jan 20, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

mmuetzel commented Jun 17, 2026

Uh oh!

kdunn926 commented Jun 21, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

mmuetzel left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

kdunn926 commented Jun 24, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

mmuetzel commented Jun 24, 2026

Uh oh!

mmuetzel 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!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

kdunn926 commented Jul 3, 2026

Uh oh!

Uh oh!

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!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

kdunn926 commented Jul 12, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

kdunn926 Jul 14, 2026 • 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!

mmuetzel Jul 14, 2026 • 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!

mmuetzel Jul 14, 2026 • 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!

mmuetzel Jul 14, 2026 • 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!

mmuetzel Jul 14, 2026 • 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!

kdunn926 commented Jan 8, 2026 •

edited

Loading

kdunn926 commented Jan 20, 2026 •

edited

Loading

kdunn926 commented Jun 21, 2026 •

edited

Loading

kdunn926 commented Jun 24, 2026 •

edited

Loading

mmuetzel left a comment •

edited

Loading

kdunn926 Jul 14, 2026 •

edited

Loading

mmuetzel Jul 14, 2026 •

edited

Loading

mmuetzel Jul 14, 2026 •

edited

Loading

mmuetzel Jul 14, 2026 •

edited

Loading

mmuetzel Jul 14, 2026 •

edited

Loading

mmuetzel Jul 15, 2026 •

edited

Loading

mmuetzel commented Aug 4, 2026 •

edited

Loading

mmuetzel commented Aug 11, 2026 •

edited

Loading