[main] Source code updates from dotnet/dotnet #123100

dotnet-maestro · 2026-01-12T20:59:17Z

Note

This is a codeflow update. It may contain both source code changes from
the VMR
as well as dependency updates. Learn more here.

This pull request brings the following source code changes

From https://github.com/dotnet/dotnet

Subscription: f7901f87-9f24-40d6-9bc1-564863937237
Build: 20260112.1 (296906)
Date Produced: January 12, 2026 3:49:30 PM UTC
Commit: 7b9ad20ba1d45df5a99fdd9dedbf3bfe6a6fc24f
Commit Diff: 5661a2c...7b9ad20
Branch: main

New Dependencies

Added 11.0.0-beta.25574.4
- Microsoft.DotnetFuzzing.TestData

Updated Dependencies

From 5.3.0-1.25619.109 to 5.4.0-2.26062.101
- Microsoft.CodeAnalysis
- Microsoft.CodeAnalysis.Analyzers
- Microsoft.CodeAnalysis.CSharp
- Microsoft.Net.Compilers.Toolset
From 11.0.100-alpha.1.25619.109 to 11.0.100-alpha.1.26062.101
- Microsoft.CodeAnalysis.NetAnalyzers
- Microsoft.DotNet.ApiCompat.Task
- Microsoft.NET.Workload.Emscripten.Current.Manifest-11.0.100.Transport
From 11.0.0-beta.25619.109 to 11.0.0-beta.26062.101
- Microsoft.DotNet.Arcade.Sdk
- Microsoft.DotNet.Build.Tasks.Archives
- Microsoft.DotNet.Build.Tasks.Feed
- Microsoft.DotNet.Build.Tasks.Installers
- Microsoft.DotNet.Build.Tasks.Packaging
- Microsoft.DotNet.Build.Tasks.TargetFramework
- Microsoft.DotNet.Build.Tasks.Templating
- Microsoft.DotNet.Build.Tasks.Workloads
- Microsoft.DotNet.CodeAnalysis
- Microsoft.DotNet.GenAPI
- Microsoft.DotNet.GenFacades
- Microsoft.DotNet.Helix.Sdk
- Microsoft.DotNet.PackageTesting
- Microsoft.DotNet.RemoteExecutor
- Microsoft.DotNet.SharedFramework.Sdk
- Microsoft.DotNet.XliffTasks
- Microsoft.DotNet.XUnitExtensions
From 0.11.5-alpha.25619.109 to 0.11.5-alpha.26062.101
- Microsoft.DotNet.Cecil
From 2.9.3-beta.25619.109 to 2.9.3-beta.26062.101
- Microsoft.DotNet.XUnitAssert
- Microsoft.DotNet.XUnitConsoleRunner
From 11.0.0-alpha.1.25619.109 to 11.0.0-alpha.1.26062.101
- Microsoft.NET.Sdk.IL
- Microsoft.NETCore.App.Ref
- Microsoft.NETCore.ILAsm
- runtime.native.System.IO.Ports
- System.Reflection.Metadata
- System.Reflection.MetadataLoadContext
- System.Text.Json
From 7.3.0-preview.1.12009 to 7.3.0-preview.1.6301
- NuGet.Frameworks
- NuGet.Packaging
- NuGet.ProjectModel
- NuGet.Versioning
From 3.0.0-alpha.1.25619.109 to 3.0.0-alpha.1.26062.101
- System.CommandLine
From 11.0.0-alpha.1.25607.1 to 11.0.0-alpha.1.25628.1
- runtime.linux-arm64.Microsoft.NETCore.Runtime.Wasm.Node.Transport
- runtime.linux-musl-arm64.Microsoft.NETCore.Runtime.Wasm.Node.Transport
- runtime.linux-musl-x64.Microsoft.NETCore.Runtime.Wasm.Node.Transport
- runtime.linux-x64.Microsoft.NETCore.Runtime.Wasm.Node.Transport
- runtime.osx-arm64.Microsoft.NETCore.Runtime.Wasm.Node.Transport
- runtime.osx-x64.Microsoft.NETCore.Runtime.Wasm.Node.Transport
- runtime.win-arm64.Microsoft.NETCore.Runtime.Wasm.Node.Transport
- runtime.win-x64.Microsoft.NETCore.Runtime.Wasm.Node.Transport
From 19.1.0-alpha.1.25574.1 to 19.1.0-alpha.1.25625.2
- runtime.linux-arm64.Microsoft.NETCore.Runtime.JIT.Tools
- runtime.linux-arm64.Microsoft.NETCore.Runtime.Mono.LLVM.Libclang
- runtime.linux-arm64.Microsoft.NETCore.Runtime.Mono.LLVM.Sdk
- runtime.linux-arm64.Microsoft.NETCore.Runtime.Mono.LLVM.Tools
- runtime.linux-musl-arm64.Microsoft.NETCore.Runtime.JIT.Tools
- runtime.linux-musl-arm64.Microsoft.NETCore.Runtime.Mono.LLVM.Libclang
- runtime.linux-musl-arm64.Microsoft.NETCore.Runtime.Mono.LLVM.Sdk
- runtime.linux-musl-arm64.Microsoft.NETCore.Runtime.Mono.LLVM.Tools
- runtime.linux-musl-x64.Microsoft.NETCore.Runtime.JIT.Tools
- runtime.linux-musl-x64.Microsoft.NETCore.Runtime.Mono.LLVM.Libclang
- runtime.linux-musl-x64.Microsoft.NETCore.Runtime.Mono.LLVM.Sdk
- runtime.linux-musl-x64.Microsoft.NETCore.Runtime.Mono.LLVM.Tools
- runtime.linux-x64.Microsoft.NETCore.Runtime.JIT.Tools
- runtime.linux-x64.Microsoft.NETCore.Runtime.Mono.LLVM.Libclang
- runtime.linux-x64.Microsoft.NETCore.Runtime.Mono.LLVM.Sdk
- runtime.linux-x64.Microsoft.NETCore.Runtime.Mono.LLVM.Tools
- runtime.osx-arm64.Microsoft.NETCore.Runtime.JIT.Tools
- runtime.osx-arm64.Microsoft.NETCore.Runtime.Mono.LLVM.Libclang
- runtime.osx-arm64.Microsoft.NETCore.Runtime.Mono.LLVM.Sdk
- runtime.osx-arm64.Microsoft.NETCore.Runtime.Mono.LLVM.Tools
- runtime.osx-x64.Microsoft.NETCore.Runtime.JIT.Tools
- runtime.osx-x64.Microsoft.NETCore.Runtime.Mono.LLVM.Libclang
- runtime.osx-x64.Microsoft.NETCore.Runtime.Mono.LLVM.Sdk
- runtime.osx-x64.Microsoft.NETCore.Runtime.Mono.LLVM.Tools
- runtime.win-arm64.Microsoft.NETCore.Runtime.JIT.Tools
- runtime.win-x64.Microsoft.NETCore.Runtime.JIT.Tools
- runtime.win-x64.Microsoft.NETCore.Runtime.Mono.LLVM.Libclang
- runtime.win-x64.Microsoft.NETCore.Runtime.Mono.LLVM.Sdk
- runtime.win-x64.Microsoft.NETCore.Runtime.Mono.LLVM.Tools

Associated changes in source repos

Diff the source with this PR branch

darc vmr diff --name-only https://github.com/dotnet/dotnet:7b9ad20ba1d45df5a99fdd9dedbf3bfe6a6fc24f..https://github.com/dotnet/runtime:darc-main-b63de5a6-6934-4dd4-bfe1-d06f6ad1a2d3

dotnet-maestro · 2026-01-12T20:59:23Z

Caution

🚨 Action Required — Conflict detected

A conflict was detected when trying to update this PR with changes from build 296906 of https://github.com/dotnet/dotnet/tree/7b9ad20ba1d45df5a99fdd9dedbf3bfe6a6fc24f.

The conflicts in the following files need to be manually resolved:

src/tasks/Crossgen2Tasks/Crossgen2Tasks.csproj
🔍 View file in dotnet/runtime vs VMR
src/tasks/installer.tasks/installer.tasks.csproj
🔍 View file in dotnet/runtime vs VMR

ℹ️ To resolve the conflicts, please follow these steps:

Clone the current repository

git clone https://github.com/dotnet/runtime
cd runtime

Make sure your darc is up-to-date
(version 1.1.0-beta.26058.6 or higher)

# Linux / MacOS
./eng/common/darc-init.sh
# or on Windows
.\eng\common\darc-init.ps1

Run from repo's git clone and follow the instructions provided by the command to resolve the conflict locally
```
darc vmr resolve-conflict --subscription f7901f87-9f24-40d6-9bc1-564863937237
```
This should apply the build 296906 with sources from 7b9ad20
Commit & push the changes
Once pushed, the Codeflow verification check will turn green.
If not, a new build might have flown into the PR and you might need to run the command above again.

💡 You may consult the FAQ for more information or tag @dotnet/prodconsvcs for assistance.

Diff: https://github.com/dotnet/dotnet/compare/7b9ad20ba1d45df5a99fdd9dedbf3bfe6a6fc24f..7b9ad20ba1d45df5a99fdd9dedbf3bfe6a6fc24f From: dotnet/dotnet@7b9ad20 To: dotnet/dotnet@7b9ad20 The following files had conflicts that were resolved by a user: - src/tasks/Crossgen2Tasks/Crossgen2Tasks.csproj - src/tasks/installer.tasks/installer.tasks.csproj

eng/pipelines/extra-platforms/runtime-extra-platforms-ioslike.yml

ericstj · 2026-01-13T03:11:39Z

Two problems here with source build causing some of the task projects to fail to build.

The shape of the NuGet packages built against is different. In runtime these seem to still target net8.0 -- probably because runtime's source build is still using older packages than the live built ones in VMR? We could do what @ViktorHofer does in Update the stack to net11.0 dotnet#4130 or just wait for that to flow.

The targeting pack for net11 in the SDK being used by source build is older (still using 10.0 assembly versions) than the one used by the packages source build is using (built against 11.0 assembly versions). In this case the package is System.Reflection.MetadataLoadContext. Of course this would go away once we have a newer SDK, but this sort of torn state can cause issues later on when API is added. I think this problem stems from this hack

runtime/Directory.Build.targets

Lines 112 to 115 in 7ed6f1c

    
               <!-- when building from source we need to use the current version of various packages as the toolset version, but source-build imports 
        
                    another props file which overrides the versions from Version.props so we can't set it there --> 
        
               <SystemReflectionMetadataLoadContextToolsetVersion Condition="'$(DotNetBuildSourceOnly)' == 'true'">$(SystemReflectionMetadataLoadContextVersion)</SystemReflectionMetadataLoadContextToolsetVersion> 
        
               <SystemTextJsonToolsetVersion Condition="'$(DotNetBuildSourceOnly)' == 'true'">$(SystemTextJsonVersion)</SystemTextJsonToolsetVersion>

That looks to predate PackageDownloadAndReference, I can see we use PDaR with both of these, so I can remove that hack.
Still it's concerning to me that we backflow package versions that use newer framework API than the SDK we backflow... @ViktorHofer @MichaelSimons.

Both of these look like a symptom of source-build behavior in VMR not lining up with source-build behavior post backflow in product repos. @jkoritzinsky would your thinking to replace this job with VMR build instead of the old source-build help?

Backported from dotnet/dotnet#4130

The newer package versions referenced might be newer than what's in the SDK (even in source build).

jkoritzinsky · 2026-01-13T04:18:15Z

Yes, this is the job I wanted to replace with the VMR validation build. I believe it will fix these problems. (In fact, running the VMR validation job on backflow should always pass by definition).

ViktorHofer · 2026-01-13T08:34:10Z

I think there's still value in keeping the repo source-build job active.

jkoritzinsky · 2026-01-13T11:16:58Z

@ViktorHofer what value does the repo source-build provide that VMR validation of the source build stage 1 and 2 jobs doesn't?

My understanding is that the repo source-build job is in this halfway point of validating some source-build logic while not actually giving full validation that things will work in the VMR and having unique problems that aren't an issue for actual source build in the VMR.

ViktorHofer · 2026-01-13T11:21:40Z

Some source-build distro partners build this repository directly with the --source-build build entry point switch. I think it's useful to keep validating that the switch works in general and does the right thing. This isn't about prebuilt detection but about the general build infrastructure (different TFMs than a normal build and SB conditions).

premun

Please give me a bit more time to investigate the codeflow and whether there are not more reverted changes we didn't notice. I am interviewing today but should get some time later in the day to have a look.

Let's not merge until then.

jkoritzinsky · 2026-01-13T11:52:34Z

While I understand that some SB customers may use that flag during local development, the only time I have seen the repo source-build job break in a PR since moving to the VMR is this backflow during the rebranding. It hasn't caught any build breaks that would cause issues on flow into the VMR in my experience.

I really don't see any value in fixing rebranding issues in it that are purely artificial and will disappear after we finish the rebrand + rebootstrap.

ViktorHofer · 2026-01-13T12:41:05Z

It's your call, I'm just sharing my opinion. You probably haven't seen such failures because we operate on a well understood path. The moment something deviates from that, you see a source-build failure. That's what is observable right now in this PR. I don't understand what's happening here exactly but my gut reaction was telling me that this indicates a wrong configuration regardless of repo source-build vs product source-build in the VMR.

premun · 2026-01-13T13:31:45Z

I found the problem in the darc vmr resolve-conflict logic. I think I might have a fix soon but maybe we'd need to spawn a new PR and replay there the additional commits from here to be sure.
But please continue working here and making this mergeable and later we can check if there were more forgotten files and either merge here or replay these onto the other PR branch.

@ericstj thanks for reporting the fail logs - for future reference, there should be no errors logged in the tool, all should be info/warning max so it should behave like you expected it and these were real errors.

premun

Okay, I found the bug and re-ran with a fixed version of darc and there was only this ioslike.yml file extra so we are in a good state here now

ericstj · 2026-01-13T16:12:21Z

I really don't see any value in fixing rebranding issues in it that are purely artificial and will disappear after we finish the rebrand + rebootstrap.

FWIW this one 1a6c5af was a torn state problem that was good to fix regardless.

This one - b1a1903 seems more like the case where VMR source build is ahead of runtime source build and similar issues like this can crop up when make changes in VMR that impact sourcebuild but don't yet rebootstrap-sdk/update-packages in runtime.

It looks like both of those got fixed - we can make the call on replace vs add separately.

ericstj · 2026-01-13T16:17:18Z

Most of the failures here are in PInvokeTableGenerator tests:

      System.IO.DirectoryNotFoundException : Could not find tasks directory /root/helix/work/workitem/e/dotnet-latest/packs/Microsoft.NET.Runtime.WebAssembly.Sdk/11.0.0-ci/tasks/net11.0
      Stack Trace:
        /_/src/mono/wasm/Wasm.Build.Tests/PInvokeTableGeneratorTests.cs(250,0): at Wasm.Build.Tests.PInvokeTableGeneratorTests.IcallWithOverloadedParametersAndEnum(Configuration config, Boolean aot)
           at System.Reflection.MethodBaseInvoker.InterpretedInvoke_Method(Object obj, IntPtr* args)
           at System.Reflection.MethodBaseInvoker.InvokeDirectByRefWithFewArgs(Object obj, Span`1 copyOfArgs, BindingFlags invokeAttr)

        runtime pack tasks dir /root/helix/work/workitem/e/dotnet-latest/packs/Microsoft.NET.Runtime.WebAssembly.Sdk/11.0.0-ci/tasks/net11.0 contains subdirectories:
          - /root/helix/work/workitem/e/dotnet-latest/packs/Microsoft.NET.Runtime.WebAssembly.Sdk/11.0.0-ci/tasks/net10.0

One appears to be a flaky test:

System.IO.IOException : The process cannot access the file '\?\C:\helix\work\workitem\e\wbt artifacts\rebuild_flags_Release_False_mq1k5oqg_rbk_鿀蜒枛遫䡫煉\App\bin\Release\net11.0\publish\wwwroot' because it is being used by another process.

ericstj · 2026-01-13T16:28:06Z

@akoeplinger / @lewing -- what do you suggest. Looks like WASM tests assume that the task TFM matches

runtime/src/mono/wasm/Wasm.Build.Tests/BuildTestBase.cs

Line 33 in 0f30f5d

    
           public static readonly string TargetFrameworkForTasks = $"net{Environment.Version.Major}.0";

But those tasks haven't been retargeted yet. I'm not inclined to do so in this PR as that could involve more breaks -- would be better after the SDK is updated.

Is it really worth it for the tests to assert on the TFM of the tasks, or can they have more resilient probing?

Update: I'll just fix the test to find the task assembly rather than assert that it must be in some TFM specific folder that must be kept in sync. Something more "product-focused" would be to have props that could be imported by the generated project.

ericstj · 2026-01-13T17:48:35Z

Maestro auto-merge - Do not automerge downgrades
The following dependency updates appear to be downgrades or invalid versions: Dependency NuGet.Frameworks was downgraded from 7.3.0-preview.1.12009 to 7.3.0-preview.1.6301, Dependency NuGet.Packaging was downgraded from 7.3.0-preview.1.12009 to 7.3.0-preview.1.6301, Dependency NuGet.ProjectModel was downgraded from 7.3.0-preview.1.12009 to 7.3.0-preview.1.6301, Dependency NuGet.Versioning was downgraded from 7.3.0-preview.1.12009 to 7.3.0-preview.1.6301. Aborting auto-merge. Note that manual commits pushed to fix up the pull request won't cause the downgrade check to be re-evaluated, you can ignore the check in this case. If you think this PR should merge but lack permission to override this check, consider finding an admin or recreating the pull request manually. If you feel you are seeing this message in error, please contact the dnceng team.

Confirmed with @mmitche that this is expected.

jkoritzinsky · 2026-01-13T18:07:59Z

It's your call, I'm just sharing my opinion. You probably haven't seen such failures because we operate on a well understood path. The moment something deviates from that, you see a source-build failure. That's what is observable right now in this PR. I don't understand what's happening here exactly but my gut reaction was telling me that this indicates a wrong configuration regardless of repo source-build vs product source-build in the VMR.

We can keep it (remove the CI-only jobs though as the VMR validation will cover what that is supposed to cover), but I'd like to have a better understanding of the support story from Arcade for repo source-build going forward and why it makes sense for it to differ from the VMR's source build mode (ie having unique failures for repo source-build and not in the VMR feels like a shared infra problem to me, not a runtime repo problem).

lewing · 2026-01-13T20:51:22Z

@akoeplinger / @lewing -- what do you suggest. Looks like WASM tests assume that the task TFM matches

runtime/src/mono/wasm/Wasm.Build.Tests/BuildTestBase.cs

Line 33 in 0f30f5d

public static readonly string TargetFrameworkForTasks = $"net{Environment.Version.Major}.0";

But those tasks haven't been retargeted yet. I'm not inclined to do so in this PR as that could involve more breaks -- would be better after the SDK is updated.

Is it really worth it for the tests to assert on the TFM of the tasks, or can they have more resilient probing?

Update: I'll just fix the test to find the task assembly rather than assert that it must be in some TFM specific folder that must be kept in sync. Something more "product-focused" would be to have props that could be imported by the generated project.

It is testing a real thing that has been a problem with when updating the tfm, it is very difficult to keep working when when crossing a tfm boundry

ericstj · 2026-01-13T20:59:58Z

It is testing a real thing that has been a problem with when updating the tfm, it is very difficult to keep working when when crossing a tfm boundry

Why don't you test it the way the product actually works? You generate a targets file for the SDK with the right path in it. Have the test import that in it's generated project... That way when the test fails you find a real product bug. As it stands it's just annoying duplication that's going to get out of sync. It's not even testing a "user" gesture. They sure don't hardcode TFMs and probe paths in the SDK package layout. That's just test fragility...

Opened #123155 to track better cleanup here.

Initial commit for subscription f7901f87-9f24-40d6-9bc1-564863937237

7e21bd1

github-actions bot added the needs-area-label An area label is needed to ensure this gets routed to the appropriate area owners label Jan 12, 2026

dotnet-policy-service bot assigned dotnet-maestro[bot] Jan 12, 2026

ericstj added area-codeflow for labeling automated codeflow and removed needs-area-label An area label is needed to ensure this gets routed to the appropriate area owners labels Jan 12, 2026

ericstj requested a review from marek-safar as a code owner January 12, 2026 21:19

dotnet-policy-service bot added the linkable-framework Issues associated with delivering a linker friendly framework label Jan 12, 2026

ericstj mentioned this pull request Jan 12, 2026

[main] Source code updates from dotnet/dotnet #122911

Closed

Fix build of installer.tasks.

e244473

jkoritzinsky approved these changes Jan 12, 2026

View reviewed changes

ericstj reviewed Jan 12, 2026

View reviewed changes

eng/pipelines/extra-platforms/runtime-extra-platforms-ioslike.yml Outdated Show resolved Hide resolved

ericstj added 2 commits January 12, 2026 16:52

Fix condition adding KnownAppHostPack.

9789a3d

Fix regression caused by VMR codeflow

ff2c708

ericstj mentioned this pull request Jan 13, 2026

Backflow of VMR -> Runtime is undoing changes in runtime dotnet/arcade-services#5767

Open

ericstj added 2 commits January 12, 2026 19:45

Reference assemblies from SDK for some task projects

b1a1903

Backported from dotnet/dotnet#4130

Ensure Toolset packages are toolset versions

1a6c5af

The newer package versions referenced might be newer than what's in the SDK (even in source build).

build-analysis bot mentioned this pull request Jan 13, 2026

Helix workitem Workloads-ST-Wasm.Build.NativeRebuild.Tests.FlagsChangeRebuildTests failed with status BadExit #121134

Open

premun requested changes Jan 13, 2026

View reviewed changes

premun approved these changes Jan 13, 2026

View reviewed changes

Fix probing for WasmAppBuilder.dll

09e1062

ericstj requested review from ilonatommy and maraf as code owners January 13, 2026 17:36

Don't use nuget from Wasm.Build.Tests

3399b25

ericstj enabled auto-merge (squash) January 13, 2026 20:51

ericstj mentioned this pull request Jan 13, 2026

Remove hardcoding of TFMs in wasm tests #123155

Closed

ericstj merged commit d1de0f1 into main Jan 13, 2026
173 of 177 checks passed

dotnet-maestro bot deleted the darc-main-b63de5a6-6934-4dd4-bfe1-d06f6ad1a2d3 branch January 13, 2026 23:53

build-analysis bot mentioned this pull request Jan 14, 2026

"We stopped hearing from agent Azure Pipelines 32. Verify the agent machine is running and has a healthy network connection" dotnet/dnceng#1886

Open

3 tasks

dotnet-maestro bot mentioned this pull request Jan 14, 2026

[main] Source code updates from dotnet/runtime dotnet/dotnet#4196

Merged

[main] Source code updates from dotnet/dotnet #123100

[main] Source code updates from dotnet/dotnet #123100

Uh oh!

Conversation

dotnet-maestro bot commented Jan 12, 2026

From https://github.com/dotnet/dotnet

Associated changes in source repos

Uh oh!

dotnet-maestro bot commented Jan 12, 2026

🚨 Action Required — Conflict detected

ℹ️ To resolve the conflicts, please follow these steps:

Uh oh!

Uh oh!

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

Uh oh!

Uh oh!

jkoritzinsky commented Jan 13, 2026

Uh oh!

ViktorHofer commented Jan 13, 2026

Uh oh!

jkoritzinsky commented Jan 13, 2026

Uh oh!

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

Uh oh!

Uh oh!

premun left a comment

Choose a reason for hiding this comment

Uh oh!

jkoritzinsky commented Jan 13, 2026

Uh oh!

ViktorHofer commented Jan 13, 2026

Uh oh!

premun commented Jan 13, 2026

Uh oh!

premun left a comment

Choose a reason for hiding this comment

Uh oh!

ericstj commented Jan 13, 2026

Uh oh!

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

Uh oh!

Uh oh!

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

Uh oh!

Uh oh!

ericstj commented Jan 13, 2026

Uh oh!

jkoritzinsky commented Jan 13, 2026

Uh oh!

lewing commented Jan 13, 2026 • edited by ericstj Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

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

Uh oh!

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

ericstj commented Jan 13, 2026 •

edited

Loading

ViktorHofer commented Jan 13, 2026 •

edited

Loading

ericstj commented Jan 13, 2026 •

edited

Loading

ericstj commented Jan 13, 2026 •

edited

Loading

lewing commented Jan 13, 2026 •

edited by ericstj

Loading

ericstj commented Jan 13, 2026 •

edited

Loading