> 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.
