Bug#903211: release.debian.org: How to handle unbuildable packages in buster

[Santiago Vila <sanvila@unex.es>]

> I wish I could say unconditionally yes, but I am not sure we are ready
> for it yet.  If your testing can trivially say which relation in
> Build-Depends/Build-Depends-Arch is broken, you could cross reference it
> with the [excuses] and see if they are permanently rejected due (and why).
> 
> I am not sure how feasible that is for you, but it might enable you to
> file RC bugs for a subset of the issues already now.

What I have is a bunch of build logs made by sbuild.

Those build logs always have a line at the end like this one:

E: Package build dependencies not satisfied; skipping

I could of course use grep and extract some information, but I don't
see how that would reduce the number of reports.

Let's take "diffoscope" as an example. In the build log we can see this:

The following packages have unmet dependencies:
 sbuild-build-depends-diffoscope-dummy : Depends: apktool but it is not installable
                                         Depends: oggvideotools but it is not installable

and later, this:
					       
report:
 -
  package: sbuild-build-depends-diffoscope-dummy
  version: 0.invalid.0
  architecture: amd64
  status: broken
  reasons:
   -
    missing:
     pkg:
      package: sbuild-build-depends-diffoscope-dummy
      version: 0.invalid.0
      architecture: amd64
      unsat-dependency: apktool:amd64


In which cases an unbuildable package like this one would not force us
to remove the package from buster immediately if we were to release
buster as stable tomorrow?

[ I fear that if I'm required to investigate all the issues myself,
then I will probably not report anything at all because of lack of
time. In this example, the diffoscope maintainers should be in a much
better position to investigate the issue than me ].

Would be ok, for example, to report any package which has been
unbuildable for more than one week? (or some other sensible amount of
time)

Thanks.