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

Re: Bug#886450: tracker.debian.org: Separate subscription for official and non-official architectures builds


On 08.01.2018 15:41, Raphael Hertzog wrote:
> On Sat, 06 Jan 2018, Mike Hommey wrote:
>> I like to subscribe to the `build` keyword for some of my packages,
>> essentially to get notifications of build failures. The sad result is
>> that because some buildds are dumb, I'm being spammed by them trying
>> and failing to build over and over. Which would be kind of okay if those
>> were builds for official architectures supported by debian, but they
>> aren't.
>> So I would very much be interested by a separation between build for
>> official architectures and build for unofficial architectures.
> Thanks for the report, but I doubt that this will be implemented
> in tracker.debian.org anytime soon. I would suggest that the buildd should
> add headers so that people with very specific requirements can filter out
> some mails with procmail or similar.
> I'm putting debian-wb-team@lists.debian.org in copy to hear their thoughts
> about this. Do you think it's possible to add headers like:
>     X-Debian: buildd.debian.org
>     X-Debian-Architecture: powerpc
>     X-Debian-Suite: sid
>     X-Debian-State: failed

this is trivial. We can lift anything that's in the body of the email to
the headers.

>> PS: In case you're interested: see all the Maybe-Failed on this page:
>> https://buildd.debian.org/status/logs.php?pkg=firefox&arch=powerpc
>> I received a mail for every single one of them. And they are mostly failed
>> because of disk space...
> Maybe the behaviour of the mail notification could also be rate-limited to
> one per day per version per arch...

That's harder because this would require a different mode of execution.
Although I wonder if there would be some way to attack this on the
buildd side. The retries are obviously way too often: The only reason
the spam isn't even more frequently sent is that the buildds back off
themselves if a build failed on them by keeping a list locally. So it's
a function of how many buildds exist for an arch.

Now in the case of firefox it's pretty sad across arches anyway:
https://packages.debian.org/unstable/firefox -- otherwise I would've
suggested that maybe we really should throttle new packages or
something. But the binaries are still there. I suppose what's happening
here is that buildd treats the exit of sbuild as an infrastructure
failure and hence keeps retrying. But none of the buildds can build it.
Did you file a bug somewhere to raise chroot disk space?

Kind regards
Philipp Kern

Reply to: