Re: buildd dependency problems?
On Thu, 2013-07-18 at 22:59 +0200, Daniel Pocock wrote:
>
> On 18/07/13 22:44, Adam D. Barratt wrote:
> > On Thu, 2013-07-18 at 12:46 +0200, Daniel Pocock wrote:
> >> I notice one of my package fails on hurd-i386, kfreebsd-* and sparc due
> >> to various dependencies:
> >> https://buildd.debian.org/status/package.php?p=resiprocate&suite=sid
[...]
> > Of the architectures you suggested were blocking "urgent fixes", neither
> > hurd-i386 nor sparc appear in that list - both because the failures are
> > not regressions and because hurd isn't a release architecture.
>
> Ok, I had simply been looking at the buildd status page and trying to
> get it into shape (things are looking better after today's third
> upload). Given the long list of failures I hadn't been comparing the
> items on the different lists one by one.
It could just be me, but your mail read as if you were suggesting that
the build failures on the four architectures you mentioned were the only
things blocking testing transition, rather than the eight affected in
total.
> Maybe the buildd status could differentiate the blocking failures? Or
> is there another way I can view all of that in one place?
The buildd status pages do clearly indicate whether the failure is a
regression ("uncompiled" versus "out-of-date"). In terms of whether the
architecture is a release architecture, that's not something the buildd
system should need to know about; it's not something that changes very
often though, and the excuses output will indicate whether it's an issue
(you'll note that there's no mention of hurd-i386 anywhere in the
excuses).
> > Indeed, the above output clearly indicates that the actual problems were
> > the build failures on eight previously supported architectures. (and the
> > two RC bugs which were still open despite apparently having been fixed.)
>
> The quality of the code has actually improved, but so have the test
> cases and they are catching bugs that were there before, especially on
> big endian.
That's good, and we like bugs being fixed. :-) It also points to 100%
more issues than your original mail suggested, however.
Regards,
Adam
Reply to: