Arch Linux User Repository

@yataro, thanks for the clarification. That helps!

@andgeno, while repo in the source is not pinned, it is pinned by the Git submodule, this is a common way to handle Git sumbodules in Arch packaging world. The maintainer of AvaloniaEdit fork is the maintainer of SourceGit, so if you trust SourceGit, you can trust their AvaloniaEdit fork.

Is there a chance we will get rid of the external and unpinned AvalaoniaEdit submodule?

I blocked updating this package after version 2026.04-1 when it was first introduced.

I absolutely don't want to imply any bad intents. However, it's a red flag for me in general if a package wants to use/install something with unpinned (re)sources. As far as I understand it is a workaround because upstream is slow/unwilling to fix something with Asian character inputs or methods iirc.

Do a clean rebuild, apparently upstream rewrote git history for Avalonia edit module, regular git update will fail.

Upstream probably did a hard-reset in their AvaloniaEdit fork, I suppose recent Avalonia version change and then more recent revert has do to do something with it. This would be gone when I push new version to AUR, I'm not pushing 2026.13 because it is buggy.

I get an error during build, that the commit of the submodule is unknown. That makes sense, since the commit seems to be no longer present in the AvaloniaEdit fork. This can be checked by clicking on the submodule representative in the SourceGit repo for the version 2026.12. Here is a link to the folder, that contains the submodule: https://github.com/sourcegit-scm/sourcegit/tree/d67c995d91eb7eb98a636d05ed84f99937478b5a/depends

The submodule opens and shows a hint on top, that the commit is not found in this repo.

I wonder how this seems to be no problem for everyone, except of me.

I found a way around this by loading the sources as archives instead of cloning them. If this is a general problem to everyone I can share my (PKDBUILD) for integration.

@jogai there was no dotnet 10 in repos when I updated it to 2025.39, there's a patch to use dotnet 9 in PKGBUILD.

@andgeno This error is expected, that's how Arch dotnet packaging works. dotnet-runtime points to latest available dotnet runtime in repos, you shall update with pacman -Syu dotnet-runtime-9.0, this is NOT sourcegit package issue.

And about dotnet 10, I will update package accordingly today, my apologies if there's any inconvenience regarding this.

Can't upgrade due to a dotnet dependency conflict. Please update the package when you find the time. Thanks!

$ paru
no new news
:: Synchronizing package databases...
 core is up to date
 extra is up to date
 multilib is up to date
:: Starting full system upgrade...
resolving dependencies...
looking for conflicting packages...
error: failed to prepare transaction (could not satisfy dependencies)
:: installing dotnet-runtime (10.0.0.sdk100-1) breaks dependency 'dotnet-runtime-9.0' required by sourcegit

The changelog of 2025.39 mentions an upgrade to dotnet 10. Yet this is depending specifically on dotnet-runtime-9.0.

Upstream re-released 2025.08, if you getting hash validation error do a clean build