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.
