On Tue, Dec 13, 2016 at 01:32:31PM +0100, Fabian Greffrath wrote: > Jonathan Dowland wrote: > > Sure, done (and VCS updated). Let's hope I haven't screwed it up :> > > Thanks for that! Let's see what it brings...
I've just refreshed my understanding of the issue and I'm afraid I doubt this upload will help. The problem is that our source package produces binary packages for different suites: main for chocolate-doom (and related), but contrib for chocolate-heretic/hexen/strife. (both the engine packages and the corresponding dbgsym packages) The bug is in the ftp.d.o infrastructure, and the symptom is that it crashes when processing our package. To prevent the bug (which would cause a lot of problems for all Debian packages) our package is manually blocked from migrating to testing. A workaround that *might* work would be if we did a release entirely in one suite only: i.e. temporarily delete the contrib binary packages. I'm not sure whether you would be happy to try that, it's pretty drastic. But we'd still need the release team (or jcristau specifically) to lift the block manually after we did that, and I guess put it back again once we had re-added the contrib binary packages to our control file. The proper fix is to fix dak itself I think (probably ./dak/control_suite.py) but I have no familiarity with that whatsoever and I think even reproducing the problem on different infrastructure might be a lot of work. -- Jonathan Dowland
signature.asc
Description: Digital signature
