Bug#695201: Bug#704222: release.debian.org: Request for wheezy-ignore tag: bug #693577 (libfso-glib: not properly built from source)
[Ugh, apologies for not having got back to this sooner]
On Fri, 2013-03-29 at 21:20 +0100, Sebastian Reichel wrote:
> 1. uploading an older fso-specs version to sid, which should avoid
> the API change. Let fso-specs migrate to wheezy and ignore the
> bug in libfso-glib.
> 2. uploading an older fso-specs version to sid, which should avoid
> the API change. Then fix the libfso-glib package. Then both
> should be able to migrate to testing.
> 3. use the new API, and binNMU all packages depending on it.
> 4. ignore everything for wheezy
> 5. remove the FSO/SHR stack from testing (libfso-glib is a reverse
> dependency for almost all components)
>
> Option 1 doesn't make much sense, since fixing the bug in
> libfso-glib should be easy with a matching fso-specs.
Well, it would mean we had the source for the files in libfso-glib, even
if we weren't actually using it?
> I guess it's too late in the release process for option 3.
Yes.
> Personally I would prefer solution 4. It's not like there is no
> source at all - upstream delivers libfso-glib with the pregenerated
> code. Previously this kind of code had been written by hand without
> the xml abstraction anyway.
>
> Option 5 is also a possibility. The FSO/SHR stack is not that
> popular. According to popcon there are 10 users.
For the record, that appears to mean the removal of:
fso-specs libfso-glib fso-datad fso-deviced fso-gsmd fso-usaged
libfsoresource libphone-ui libphone-ui-shr phonefsod phoneuid
fso-frameworkd phoneui-apps libshr-glib fso-gpsd openbmap-logger
Regards,
Adam
Reply to: