Hi,
On 20-06-18 12:50, Ian Jackson wrote:
> Paul Gevers writes ("Re: "Always failed" ? Doesn't seem to be true"):
>> On 20-06-18 01:00, Ian Jackson wrote:
>>> I happened to look at
>>> https://ci.debian.net/packages/d/dgit/testing/amd64/
>>> and noticed that there is a version of git which breaks something in
>>> dgit or dgit's test suite.
>>>
>>> It says "This package is failing and has 5.0 passed." but the package
>>> is not failing.
>>
>> Well, the last run failed, didn't it? This page (testing) of ci.d.n is
>> not compatible with how it's used. I.e. this page just reports the
>> status of the last test that gets processed during the generation of the
>> page (which is in > 95% of cases the top one). I think that for testing,
>> we should remove this text.
>
> Yes. Also the summary page is wrong for testing too, for the same
> reason:
> https://ci.debian.net/packages/d/dgit/
>
> It would be better to report the baseline status. Is that available
> here ?
No, that is something from britney internals.
>>> But actually my tests pass in testing.
>>
>> I am afraid there is a bug in britney somewhere in the case it never
>> ever generated a migration-reference/0 trigger for a package (it does
>> that only when it find no previous results at all). The idea is (but
>> apparently it doesn't properly work in that case) is that the internal
>> reference in britney is build up by previous results.
>>
>> I triggered a migration-reference/0 on britneys behalf. Git should get a
>> 10 days additional age on top of the 5 days by default.
>
> Thanks for fixing my case so promptly.
>
> I am a bit confused. I confess don't really understand all this
> business with `a migration-reference/0 trigger'. But maybe one should
> be created if there is no such `migration-reference/0 trigger' rather
> than if there are no tests ?
This migration-reference/0 is a hack to avoid needing to run baseline
tests all the time and basically doubling the amount of tests on
testing. Britney internally keeps track of the history state of the
package in testing. If a test passes in testing (but not if it is the
version of the package itself that is only available in unstable) than
the baseline state set to PASS. To enable the situation where the
baseline really goes from PASS to FAIL, brintey treats
migration-reference/0 special. If it sees that trigger, the baseline is
updated with that result. The idea is that even without a
migration-reference/0 trigger seen the internal state would still be
updated with historical data. Apparently there is a bug in that code
path. Britney triggers a migration-reference/0 if it doesn't have a
reference yet, but during the bootstrapping phase, the real britney did
see results from my testing britney version and as such for high volume
packages it never requested one itself. I'll fix that today, i.e. I'll
trigger those migration-references/0 for all packages that haven't seen
one in the last month.
>> A side note: for urgency high or higher, the results for autopkgtest are
>> ignored.
>
> Even if they show regressions ? Interesting. I guess that's a
> reasonable guess at what is best...
That's a feature of urgency high on request of the release team. And
what's worse for the git case, urgencies are sticky (see also 831699)
where the urgency of experimental is inherited in unstable. This
*probably* explains why git gets 2 days now, as the 2 days are NOT
coming from autopkgtest.
git is now blocked by:
- your RC bug
- failing build on ppc64el
Paul
Attachment:
signature.asc
Description: OpenPGP digital signature