Hi, On Mon, Oct 28, 2013 at 12:09:44PM +0100, Niels Thykier wrote: > I kindly ask you to resolve this situation within 14 days or I may end > up removing one or more of your packages from testing to reduce the > number of RC bugs in testing. > Once the packages can be decrufted without any adverse affects to > other (non-broken packages), please let us know so we can have the FTP > masters decruft your packages. It seems all fso daemons can migrate to testing without further problems once libfsoframework migrates. libfsoframework on the other hand has some problems migrating: Updating libfsoframework makes 4 non-depending packages uninstallable on i386: libfsoresource-dev, libfsotransport-dbg, libfsotransport-dev, libgsm0710mux-dev I'm not 100% sure why the list looks like this, but libfsoframework0 is removed by the migration and this breaks at least libfsoresource0. In short: Migration of new FSO packages depends on removal of deprecated source packages and removal of deprecated source packages without breaking anything else depends on migration of new FSO packages. I see the following solutions to allow migration: a) Remove the old FSO stack from testing and let the new one migrate b) Ignore the uninstallable problem for libfsoframework, so that it migrates (and everything that depends on it). Afterwards remove the deprecated source packages. Removal of those source packages fixes the remaining uninstallable problems (Some of them need libfsoframework0). c) Remove deprecated libfsobasics, libfsoresource, libfsosystem, libfsotransport, libgsm0710mux from testing (they are already removed in sid) and ignore the install problems for fso daemons. The following migration of the new FSO packages will fix installability of the daemons. -- Sebastian
Attachment:
signature.asc
Description: Digital signature