openjdk team mailing list archive

[Matthias Klose <doko@xxxxxxxxxx>]

On 10/25/20 12:22 PM, Matthias Klose wrote:
> On 10/24/20 10:18 PM, Paul Gevers wrote:
>> Hi Matthias
>>
>> On 23-10-2020 13:31, Matthias Klose wrote:
>>> On 10/7/20 10:33 PM, Paul Gevers wrote:
>>>> Hi Matthias,
>>>>
>>>> On 21-09-2020 17:52, Paul Gevers wrote:
>>>>>> Apparently
>>>>>> the very same tests don't time out on the buildds.
>>>>>
>>>>> I don't know what timeouts apply to buildds, but indeed I think they are
>>>>> much higher to cope with *building* some extremely big packages.
>>>>
>>>> Do you know how much time these tests would take? If so, I wonder if we
>>>> should make it possible for individual packages to have a longer
>>>> timeout. It would be work on the debci/ci.d.n side of things, but not
>>>> impossible of course.
>>>
>>> For an upper bound, use the build time: The very same tests are run during the
>>> build.
>>
>> Ack. Side note: I see a hell load of errors and failures in the build
>> log, is that expected? And some builds took more than a day, is that
>> reasonable to do for these tests (if they're ignored anyways, your tests
>> are marked flaky)?
>>
>>> The other question is, if it's sensible to run the upstream test suite as an
>>> autopkg test, if it's already run during the build.  Ideally it should only run
>>> the autopkg tests which test on integration issues with run time dependencies,
>>> but this would require analyzing some 10000 tests and
>>>
>>> For now I just disabled the jdk tests as an autopkg test. So please clear the
>>> test results, to run it again, and let it migrate.
>>
>> Also the hotpot test times out, so only having the jdk tests disabled
>> doesn't really help at this stage.
> 
> where can I see this?
> https://ci.debian.net/data/autopkgtest/testing/amd64/o/openjdk-15/7738063/log.gz
> doesn't point to anywhere

instead I see
https://ci.debian.net/data/autopkgtest/unstable/amd64/o/openjdk-15/7725394/log.gz
which doesn't look like a timeout.

> and it doesn't really help to not let openjdk-15 migrate, so that we finally can
> remove openjdk-14.