Hi,

this looks like a regression in the Mono-side runtime registration path
after the old mono-gac / cli-common integration was dropped.

I investigated this while reproducing #1133410 in a clean unstable
schroot with a freshly built repetier-host_0.85+dfsg-6.

The user-visible failure there is:

  System.TypeLoadException: Could not load file or assembly 'OpenTK,
  Version=1.1.0.0, ...'

The key point is that this does not appear to be just a repetier-host
dependency issue.

In the failing sid environment:

  - libopentk1.1-cil is installed
  - cli-common is installed
  - the OpenTK assemblies are present on disk under /usr/lib/cli/OpenTK-*
  - but "gacutil -l OpenTK" reports no installed items

So the assemblies are present, but the normal package installation path
does not make them usable through the expected GAC resolution path.

The strongest evidence is a direct A/B test in the sid chroot.

Without any /usr/share/cli-common/runtimes.d/mono hook:

  - removing OpenTK from the GAC
  - ensuring /usr/share/cli-common/runtimes.d/mono is absent
  - rerunning the real libopentk1.1-cil.postinst unchanged

leaves the GAC empty, and repetier-host still fails immediately with the
same OpenTK TypeLoadException.

After adding a temporary compatibility hook at:

  /usr/share/cli-common/runtimes.d/mono

and rerunning the same libopentk1.1-cil.postinst unchanged:

  - cli-common installs OpenTK, OpenTK.GLControl, and
    OpenTK.Compatibility into the GAC
  - "gacutil -l" then shows those assemblies
  - the original TypeLoadException disappears
  - repetier-host gets further into WinForms / OpenTK startup and then
    fails later for a different reason

That strongly suggests the original loader failure is caused by the
missing cli-common runtime backend, not by GTK and not by a mere missing
Depends line in repetier-host.

The likely regression boundary seems to be the packaging transition that
reached unstable in mono 6.14.1+ds-4:

  - 6.14.1+ds-3 merged several packages into mono-runtime
  - 6.14.1+ds-4 explicitly dropped integration with cli-common

In trixie, mono-gac shipped:

  /usr/share/cli-common/runtimes.d/mono

In current sid:

  - mono-runtime ships gacutil
  - libopentk1.1-cil still invokes
    /usr/share/cli-common/gac-package-install in postinst
  - but /usr/share/cli-common/runtimes.d/ is empty

So cli-common is still being asked to perform GAC registration, but it no
longer has any Mono runtime backend to invoke.

At least one concrete reproducer is #1133410 (repetier-host), but this
may affect other CLI packages using the same registration path.

I have not tried to propose a patch yet because I first wanted to report
the regression with a clear reproducer and the A/B evidence above.

Relevant bug:

  - #1133410: repetier-host: Could not load file or assembly

Possible fix directions seem to be either:

  - restore /usr/share/cli-common/runtimes.d/mono, or
  - provide an equivalent supported mechanism so cli-common-driven GAC
    registration still works for packages such as libopentk1.1-cil

Regards,
James

Hi,

I prepared a tested packaging fix for this regression and have attached
both a debdiff and a git-format-patch.

Summary of the fix:

It restores the cli-common runtime backend hook in mono-runtime at
/usr/share/cli-common/runtimes.d/mono, re-adds Recommends: cli-common
for mono-runtime, and adds an autopkgtest smoke check for the restored
backend.

The clean-room results are:

  - the package builds successfully in a clean unstable-amd64-sbuild
    schroot
  - in a clean sid schroot, libopentk1.1-cil.postinst again installs
    the OpenTK assemblies into the Mono GAC through the normal
    cli-common path
  - gacutil -l OpenTK then shows the OpenTK assembly after normal
    package installation
  - repetier-host under xvfb-run gets past the original
    System.TypeLoadException / missing OpenTK failure from #1133410

The QA-upload candidate is 6.14.1+ds2-3.

I also reran lintian on the refreshed source upload set. It exits 0 with
warnings only:

  autotools-pkg-config-macro-not-cross-compilation-safe
  obsolete-url-in-packaging
  orphaned-package-maintained-in-private-space
  unknown-architecture kfreebsd-amd64
  unknown-architecture kfreebsd-i386

Those warnings appear unrelated to this change.

Since mono is already orphaned and maintained by the Debian QA Group,
this is prepared as a QA-upload candidate rather than an NMU. I do not
have upload rights, so the immediate goal here is review and, if
acceptable, sponsorship.

Regards,
James

Since filing this report I've started to take over maintenance of
src:mono (#1133397) and discussed the cli-common situation with the
previous maintainer, Antoine Le Gonidec.

He confirmed that the removal of /usr/share/cli-common/runtimes.d/mono
in 6.14.1+ds2-2 was intentional. It is part of a coordinated effort to
remove cli-common from Debian entirely (#1079871, #1111276). Restoring
the hook, as the patch I submitted proposes, would work against that
direction. I am withdrawing that patch.

The correct path forward for packages that register .NET assemblies via
the cli-common helper (libopentk1.1-cil and others) is to migrate away
from the cli-common registration mechanism and ship direct gacutil calls
in their own maintainer scripts. The cli-common removal in src:mono is
expected to complete in 6.14.1+ds2-4.

This bug is tagged wontfix accordingly. The block on #1133410 has also
been removed; the OpenTK TypeLoadException in repetier-host will need to
be resolved at the libopentk1.1-cil or repetier-host level, not in mono.

Regards,
James