Bug#648775: Re: Bug#648775: transition: mono 2.10
On Dec 22, 2011 23:27 "Iain Lane" <laney@debian.org> wrote:
> Hi there,
>
> On Tue, Dec 20, 2011 at 10:58:50PM +0100, Niels Thykier wrote:
> > […]
> > If you haven't already done so, please head to [1] (or [2]) to
> > verify
> > the list of affected source packages.
>
> I think that's right.
>
Good, :)
> > > […]
> > > * Upload all of mono & cli-common from experimental to unstable
> > > * Upload build tools (nant)
> > > * Remove mono-debugger
> > > * Get LO bindings disabled
> > > * No-change rebuild / binNMU all applications against the 4.0
> > > profile
> > > * No-change rebuild / binNMU all libraries against the 4.0
> > > profile, in
> > > leaf-first order
> > >
> >
> > Do you have a list/table of the ~30 binNMUable packages that tells
> > us
> > which of them are libs and which are not? Alternatively can we just
> > go
> > by "dependency level" from the transition tracker package (starting
> > with
> > the bottom/level 10)?
>
> No, but here is one:
>
> libraries
> ---------
> libindicate
> libgwibber
> gstreamer-sharp
> gdata-sharp
> gnome-desktop-sharp2
> libgpod (U)
> gnome-sharp2
> gnome-keyring-sharp
> gmime2.4
> activiz.net (U)
> zeroc-ice
> libkarma (U)
> gtk-sharp2
> mummy (U)
>
> plugins
> -------
> banshee-community-extensions
>
> applications
> ------------
> fsgateway
> ikvm
> antlr
> tangerine
> gnome-do
> banshee
> tomboy
> mistelix
> longomatch
> gnome-subtitles
> f-spot
> bareftp
> gdcm
>
> There were some unclear cases, but you should be able to rebuild all
> applications once mono and nant are uploaded, the plugins after their
> applications are rebuilt and then finally the libraries, in leaf-first
> order (with the exception below). The main thing to remember is that
> once stuff has been rebuilt it will be 4.0, and 2.0 code cannot load
> 4.0.
>
> As an additional complication, some libraries are packaged 'unstable',
> (marked as (U) above) meaning that they are copied by their consumers
> at build time. These libraries should be rebuilt /before/ their library
> rdeps, otherwise you'll get 2.0 copies inside 4.0 libraries and have
> to do a second rebuild. This will be unavoidable in some cases where
> applications depend on unstable libraries.
>
> We can let you know when binNMUs should be issued if you like, as
> we'll be doing the no-change source uploads at the same time.
>
I will take you up on that offer. :)
> Also I just noticed that mummy FTBFS with 2.10, and filed this as
> #652976. This is a new package since we prepared the transition. If
> not fixed by the maintainer, I'll look at NMUing.
>
> > […]
>
> Cheers,
>
We will need a couple of days more to sort out the vtk8.5 transition
and then I will get back to you. :)
~Niels
Reply to: