package monodoc-base failed to install/upgrade: subprocess installed post-installation script returned error exit status 1

Bug #972751 reported by Fila Kolodny on 2012-04-03
This bug affects 1 person
Affects Status Importance Assigned to Milestone
mono (Ubuntu)
mono-tools (Ubuntu)

Bug Description

Just doing "apt-get upgrade"

ProblemType: Package
DistroRelease: Ubuntu 12.04
Package: monodoc-base
ProcVersionSignature: Ubuntu 3.2.0-21.34-generic 3.2.13
Uname: Linux 3.2.0-21-generic x86_64
NonfreeKernelModules: zfs zcommon znvpair zavl zunicode
ApportVersion: 2.0-0ubuntu4
Architecture: amd64
Date: Tue Apr 3 15:24:20 2012
ErrorMessage: subprocess installed post-installation script returned error exit status 1
InstallationMedia: Ubuntu 12.04 LTS "Precise Pangolin" - Alpha amd64 (20111129.1)
PackageArchitecture: all
SourcePackage: mono
Title: package monodoc-base failed to install/upgrade: subprocess installed post-installation script returned error exit status 1
UpgradeStatus: No upgrade log present (probably fresh install)

Fila Kolodny (fila) wrote :
tags: removed: need-duplicate-check
Iain Lane (laney) wrote :

Thanks. We've had this bug a ton of times, but your terminal log is minimal enough that I think I can see what's going on.

There's a trigger in monodoc-base to update the search index for the installed documentation. As you upgraded monodoc-gtk2.0-manual, this trigger was activated. That causes the postinst of monodoc-base to be called, which does:

  case "$1" in




and update-monodoc (shipped in monodoc-base) calls

  monodoc --make-index > /dev/null

which crashes because gtk-sharp has been removed from the GAC (you can see this earlier in the log)

  Preparing to replace libgtk2.0-cil 2.12.10-2ubuntu3 (using .../libgtk2.0-cil_2.12.10-2ubuntu4_amd64.deb) ...
  Removing libgtk2.0-cil from Mono

but the new version's postinst has not been run yet, because monodoc-base does not depend on libgtk2.0-cil.

The monodoc binary is in the monodoc-browser package, and ends up calling /usr/lib/mono/monodoc/browser.exe, which is also in monodoc-browser. monodoc-browser does correctly depend on libgtk2.0-cil.

I think we should just move the trigger across from monodoc-base to monodoc-browser, as we can't do anything if monodoc-browser is not installed anyway. AFAICS dpkg guarantees that the Depends are satisfied when processing triggers (quoting /usr/share/doc/dpkg-dev/triggers.txt.gz)

  Packages in t-awaited and t-pending demand satisfaction of their dependencies just like packages in installed.

The postinst in monodoc-base tries to take care of -browser not being available

  if [ ! -x /usr/lib/monodoc/browser.exe -o -z "$(dpkg-query -W -f='${Status}' monodoc-browser 2>/dev/null | grep "ok installed")" ]; then
        exit 0

but this clearly does not work, and the rationale for trying to keep it here is lost in the mists of time.

Iain Lane (laney) on 2012-04-04
Changed in mono (Ubuntu):
status: New → Triaged
importance: Undecided → High
milestone: none → ubuntu-12.04
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package mono -

mono ( precise; urgency=low

  * debian/monodoc-base.postinst: Add '|| true' to the update-monodoc call
    so that it doesn't cause upgrades to fail due to the trigger being called
    prior to GTK# being upgraded (LP: #972751)
 -- Andrew Mitchell <email address hidden> Wed, 04 Apr 2012 18:08:25 +1200

Changed in mono (Ubuntu):
status: Triaged → Fix Released
Iain Lane (laney) wrote :

Setting back to Triaged; although the above fix will resolve the upgrade failures, the more correct solution is as I outlined above: move the trigger from -base to -browser (in mono-tools). There will be another upload (not necessarily in Precise) to address this properly, if testing pans out.

Changed in mono (Ubuntu):
status: Fix Released → Triaged
Changed in mono-tools (Ubuntu):
status: New → Triaged
importance: Undecided → High
Changed in mono (Ubuntu):
milestone: ubuntu-12.04 → none
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package mono-tools - 2.10-3

mono-tools (2.10-3) unstable; urgency=low

  * [62da47c] Move update-monodoc trigger from monodoc-base (in mono)
    The commands being executed from the trigger are in monodoc-browser, so
    it makes sense for the trigger to be here too, then we don't have have
    base attempt to check if -browser is configured, which we could never
    get right.
    We need to have Replaces: and Breaks: monodoc-base (<< for
    the moved update-monodoc. -3 is the version which will stop shipping
    update-monodoc; we need to make sure that users don't have this on their
    system after the trigger has moved. (LP: #972751)

 -- Iain Lane <email address hidden> Wed, 04 Apr 2012 21:44:15 +0100

Changed in mono-tools (Ubuntu):
status: Triaged → Fix Released
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package mono -

mono ( unstable; urgency=low

  * [c934e01] Remove unused File::Basename import from runtime script.
    Having this present causes failures on release upgrades where perl-base
    and perl-modules are not in a consistent state (e.g. this can happen
    when upgrading across major Perl versions). (Closes: #665335) (LP:
  * [9e3cc40] Remove monodoc-base trigger.
    This trigger updated the monodoc search index. It ended up calling
    /usr/bin/monodoc, which is shipped in the monodoc-browser package
    (source package mono-tools). The script attempted to check that
    monodoc-browser was configured, but didn't get this right. This led to
    numerous upgrade failures when Depends of monodoc-browser were not
    satisfied when the trigger was invoked and calling monodoc to update the
    search index bombed out due to this. It's more correct to just have
    monodoc-browser ship this trigger itself. (LP: #972751)
  * [dd2925c] Standards-Version bump to 3.9.3, no changes required
  * [8299ee0] Remove duplicate Depends in mono-complete
  * [508c4f5] Revert "Merge branch 'master-patches/fix_crash_in_fixup_cattrs'"
    This reverts commit 86127dcf508213eac5b50a65c989cf5971b57378, reversing
    changes made to 55a1a20a4d858346ed8a8d840abc3f9230ea816e.
    This branch introduced regressions which caused both nant and mono-upnp
    (at least) to FTBFS. (Closes: #666623)
  * [61fbbe4] Fix ARM printf format problems.
    When building with -Werror=format-security on ARM, mono fails to build
    due to incorrect format strings in arm-dis.c
    (cherry picked from commit 32c1b70ad164640ff0a2739e66884d0279cfe7c7)
    Signed-off-by: Iain Lane <email address hidden>
  * [9883116] Pass CFLAGS and CPPFLAGS when building binfmt-detector.
    Ensures hardening support is enabled for this binary.
    Thanks to Simon Ruderich <email address hidden> (Closes: #657518)
  * [4bb0138] Ensure compiler flags are passed into build system.
    This issue was discovered when it was noted that Debian's hardening
    buildflags weren't being propogated to all binaries.
    The patch is from Simon Ruderich <email address hidden>
    (cherry picked from commit d6dcfb27fc6252352f6ad6f8bd9ef5cff206fd46)
    Also Closes: #657518

 -- Iain Lane <email address hidden> Wed, 04 Apr 2012 21:15:59 +0100

Changed in mono (Ubuntu):
status: Triaged → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers