Starting the program ends with:

Gtk not found (missing LD_LIBRARY_PATH to libgtk-x11-2.0.so.0?), using built-in colorscheme

Unhandled Exception:
System.TypeLoadException: Could not load type of field 'RepetierHost.view.ThreeDControl:startViewCenter' (8) due to: Could not load file or assembly 'OpenTK, Version=1.1.0.0, Culture=neutral, PublicKeyToken=bad199fe84eb3df4' or one of its dependencies.
  at (wrapper remoting-invoke-with-check) RepetierHost.Main..ctor()
  at RepetierHost.Program.Main () [0x00011] in <e4cb5da6455b421d90e18a27e20f7310>:0
[ERROR] FATAL UNHANDLED EXCEPTION: System.TypeLoadException: Could not load type of field 'RepetierHost.view.ThreeDControl:startViewCenter' (8) due to: Could not load file or assembly 'OpenTK, Version=1.1.0.0, Culture=neutral, PublicKeyToken=bad199fe84eb3df4' or one of its dependencies.
  at (wrapper remoting-invoke-with-check) RepetierHost.Main..ctor()
  at RepetierHost.Program.Main () [0x00011] in <e4cb5da6455b421d90e18a27e20f7310>:0

Hi Bastian,


This seems to be a mono bug.

Previously we have libmono-system-* packages which did depends on
libgtk2 through some

dependencies.

But now it becomes mono-libraries. And didn't have any relationship with
libgtk2.

Anyway, if mono is unmaintained, then this package will no longer work.


Yours,

Paul

Hi,

I investigated this in a clean unstable schroot and can reproduce the
bug with a freshly built repetier-host_0.85+dfsg-6.

The package builds successfully, but running it under xvfb-run fails
immediately with the reported OpenTK TypeLoadException. Installing
libgtk2.0-0t64 removes the "Gtk not found" warning, but it does not fix
the OpenTK failure, so GTK appears to be secondary here.

The more important finding is that in the failing sid environment
libopentk1.1-cil and cli-common are both installed, and the OpenTK
assemblies are present on disk under /usr/lib/cli/OpenTK-*, but they are
not installed in the GAC. In that state, "gacutil -l OpenTK" reports
zero items.

I then compared this with the older packaging. In trixie, mono-gac
shipped /usr/share/cli-common/runtimes.d/mono [1]. In current sid,
mono-runtime replaces mono-gac [2] and ships gacutil [3], but that
runtime hook is no longer present. libopentk1.1-cil still runs the
cli-common GAC registration helper in its postinst, but with an empty
/usr/share/cli-common/runtimes.d/ directory there is no Mono backend for
that helper to invoke.

I also tested this directly with an A/B run in the sid chroot. With no
/usr/share/cli-common/runtimes.d/mono hook, rerunning the real
libopentk1.1-cil.postinst leaves the GAC empty and repetier-host still
fails immediately with the same OpenTK TypeLoadException. After adding a
temporary compatibility hook at that path and rerunning the same
postinst unchanged, cli-common installs OpenTK, OpenTK.GLControl, and
OpenTK.Compatibility into the GAC, and the original TypeLoadException
disappears. The program then gets into later WinForms/OpenTK startup and
fails further on, which is a different problem from the original loader
failure.

So at this point the primary issue does not look like a simple missing
Depends line in repetier-host. It looks more like a regression in the
Mono-side runtime registration path in sid, with repetier-host as a
clear reproducer. The likely regression boundary seems to be the mono
transition that reached unstable in 6.14.1+ds-4, where the changelog
says "Drop integration with cli-common" [4]. That also matches
#1111276, "mono: Drop integration with cli-common" [5].

I am deliberately not reassigning this based on one message, since
repetier-host is still the concrete package that currently fails for
users. But if it would be useful, I can file a linked bug against
src:mono / mono-runtime referencing this report, or help test a proposed
fix there.


[1] https://sources.debian.org/src/mono/6.12.0.199+dfsg-6/debian/rules/#L262
[2] https://sources.debian.org/src/mono/6.14.1+ds2-2/debian/control/
[3] https://sources.debian.org/src/mono/6.14.1+ds2-2/debian/mono-runtime.install/
[4] https://sources.debian.org/src/mono/6.14.1+ds2-2/debian/changelog/#L62
[5] https://bugs.debian.org/1111276

Best,
James