On 26/09/23 at 10:55 -0600, Sam Hartman wrote: > >>>>> "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.
Hi, As an additional data point, I can still reproduce this failure. Lucas
