Re: Bug#903211: release.debian.org: How to handle unbuildable packages in buster
Santiago Vila wrote:
>> 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.
[...]
Would it be better to catch these bugs using dose-builddebcheck that simply
looks at whether the build-deps are installable? If packages are prescreened
before giving them to your sbuild to try, you are not flooded by the trivial
cases and can concentrate on the ones that need human involvement.
$ dose-builddebcheck --deb-native-arch amd64 -f Packages Sources
[...]
-
package: diffoscope
version: 99
architecture: all
type: src
status: broken
[...]
binary-packages: 82115
source-packages: 27292
broken-packages: 90
(alternatively, only test successes not failures by replacing -f with -s;
add -e to get the explanatory report seen in the sbuild log)
In terms of comparing with excuses, I'm not sure how to programmatically
interpret the state
migration-policy-verdict: REJECTED_BLOCKED_BY_ANOTHER_ITEM
While not permanent, manual checking shows that it has been in that state
for three weeks, and the root cause is an FTBFS bug that has seen no
maintainer reply since it was filed 19 months ago.
I thought testing with dose-builddebcheck already happened routinely but
can't find it. Any historical perspective on that?
cheers
Stuart
--
Stuart Prescott http://www.nanonanonano.net/ stuart@nanonanonano.net
Debian Developer http://www.debian.org/ stuart@debian.org
GPG fingerprint 90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7
Reply to: