[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: buildd dependency problems?




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
>>
>> and it appears these dependencies have been unavailable for a long time.
>>
>> The bottom line is that urgent fixes in the package are not propagating
>> to testing at all because of these other packages on the least used
>> architectures
> 
> I was tempted to reply with simply "codswallop", but that seemed
> unhelpful so I'll expand on how you're mistaken.
> 
> It's a little more difficult than it might have been to check the
> situation now, as there have been three uploads of resiprocate since you
> sent the mail to which I'm replying.
> 
> However, one can still easily look at the grep-excuses output for the
> previous upload:
> 
>     24 days old (needed 10 days)
>     out of date on armel: librecon-1.8, librecon-1.8-dev, libresiprocate-1.8, libresiprocate-1.8-dev, libresiprocate-turn-client-1.8, libresiprocate-turn-client-1.8-dev, repro, resiprocate-turn-server, sipdialer (from 1.8.8-2)
>     out of date on kfreebsd-amd64: libresiprocate-1.8, libresiprocate-1.8-dev, libresiprocate-turn-client-1.8, libresiprocate-turn-client-1.8-dev, repro, resiprocate-turn-server, sipdialer (from 1.8.5-4)
>     out of date on kfreebsd-i386: libresiprocate-1.8, libresiprocate-1.8-dev, libresiprocate-turn-client-1.8, libresiprocate-turn-client-1.8-dev, repro, resiprocate-turn-server, sipdialer (from 1.8.5-4)
>     out of date on mips: librecon-1.8, librecon-1.8-dev, libresiprocate-1.8, libresiprocate-1.8-dev, libresiprocate-turn-client-1.8, libresiprocate-turn-client-1.8-dev, repro, resiprocate-turn-server, sipdialer (from 1.8.10-2)
>     out of date on mipsel: librecon-1.8, librecon-1.8-dev, libresiprocate-1.8, libresiprocate-1.8-dev, libresiprocate-turn-client-1.8, libresiprocate-turn-client-1.8-dev, repro, resiprocate-turn-server, sipdialer (from 1.8.8-2)
>     out of date on powerpc: librecon-1.8, librecon-1.8-dev, libresiprocate-1.8, libresiprocate-1.8-dev, libresiprocate-turn-client-1.8, libresiprocate-turn-client-1.8-dev, repro, resiprocate-turn-server, sipdialer (from 1.8.10-2)
>     out of date on s390: librecon-1.8, librecon-1.8-dev, libresiprocate-1.8, libresiprocate-1.8-dev, libresiprocate-turn-client-1.8, libresiprocate-turn-client-1.8-dev, repro, resiprocate-turn-server, sipdialer (from 1.8.10-2)
>     out of date on s390x: librecon-1.8, librecon-1.8-dev, libresiprocate-1.8, libresiprocate-1.8-dev, libresiprocate-turn-client-1.8, libresiprocate-turn-client-1.8-dev, repro, resiprocate-turn-server, sipdialer (from 1.8.10-2)
>     resiprocate (source) has new bugs!
>     Updating resiprocate introduces new bugs: #713634, #713865
> 
> 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.

Maybe the buildd status could differentiate the blocking failures?  Or
is there another way I can view all of that in one place?

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

Various upstream issues have been found in big endian and other
non-Intel architectures - obviously all the upstream team are very
grateful to Debian for providing a platform where we could make these
improvements.

On the other hand, we've simultaneously fixed some unrelated issues on
the most popular architectures too


Reply to: