Re: Update on state of Mono for Wheezy
On Wed, 2012-08-08 at 18:38 +0100, Jo Shields wrote:
> =====
> Bug#682284: mono-runtime: SIGSEGV while executing native code on armhf[0]
> =====
This got solved via:
> 2) remove armhf as an architecture for Mono,
in the end. CVE-2012-3543 came along just afterwards and things seem to
have fallen off the radar a little after that. :-( Currently, wheezy
still has a version of mono that generates armhf binaries.
> requiring a sourceful
> upload of src:mono plus an arch-specific removal on a bunch of arch:any
> packages plus some sourceful uploads on packages maintained by other
> teams which generate Mono-related packages, typically very large messy
> packages from the -med or -science teams.
I've been having a look this afternoon at what would be required to
migrate the "new" mono package. britney says that a number of binary
packages get broken on armhf:
source activiz.net: libactiviz.net-cil
source fsgateway: fsgateway
source mod-mono: libapache2-mod-mono
source gdcm: libgdcm-cil
libvtkgdcm-cil
source mummy: libkitware-mummy-runtime1.0-cil
source mono-fuse: libmono-fuse-cil
source virtuoso-opensource: libvirtuoso5.5-cil
A dak rm dry run reveals no runtime issues which removals for the above
would cause, but:
Checking reverse dependencies...
# Broken Build-Depends:
activiz.net: libkitware-mummy-runtime1.0-cil
gdcm: libactiviz.net-cil
The packages listed above are the only non-arch:all packages produced by
activiz.net, fsgateway, mod-mono and mono-fuse so a straight binary
removal should work okay; the build-dependencies should ensure the
binaries don't re-appear.
virtuoso-opensource produces a bunch of other binaries, but a simple
architecture changing sourceful upload (as for s390) should suffice.
mummy also produces the "mummy" binary, so would need a sourceful upload
to drop the -cil package. It has a libunwind dependency so would also
need a tpu due to the libunwind8 mess. :-( For added fun, the package is
in sync between testing and unstable, so would need an unstable upload
first followed by an appropriately versioned tpu.
gdcm has a new upstream in unstable so would also need an eventual fix
to go via tpu.
Regards,
Adam
Reply to: