>>>>> "Santiago" == Santiago Vila <sanv...@debian.org> writes:
Santiago> This could be simply a race condition.
Santiago> I've seen many packages to fail their tests randomly
Santiago> because of that.
It could be a race, but given what I know of the tests, I doubt it is.
Take a look at util/k5test.py in _start_daemon
In particular, it waits for a particular string to be printed before
declaring the service running.
Santiago> However, you seem to be automatically assuming that the
Santiago> failure is due to some of those things you enumerated,
Santiago> i.e. a "difference of build environments".
Santiago> But such thing is not necessarily true.
Agreed.
Based on a long history with the package and the tests in question I am
making some assumptions.
You're absolutely right that these assumption may end up being
inaccurate.
Certainly if I do see failures on a buildd that suggest a race, I will
be very concerned.
If there is a race on the buildds, I think that will become clear over
time.
>> So, unless I'm violating some written policy somewhere, my claim
>> is that this is all good.
Santiago> I think you forgot Policy 4.2, which is also "written
Santiago> policy somewhere". This is what it says:
I'm aware of policy 4.2.
I'm also aware that there has been some disagreement over the years
about what that means for things beyond packaged dependencies.
In particular, how that relates to available memory, cpu, etc.
And for example related to where builds can write, etc, etc.
And some of that has been resolved, and I suspect some issues have not.
It would not surprise me if there are some corner cases surrounding what
builds can do with regard to the network on the local system are
ambiguous.
We all agree that builds cannot access the internet, but beyond that I
think there is ambiguity.
But yes, if this ends up being a race, I will absolutely be interested
in fixing the race or disabling the tests.
--Sam
