On 2018-03-14 07:40, Paul Gevers wrote: > Hi Aurelien, > > On 14-03-18 00:15, Aurelien Jarno wrote: > > On 2018-03-13 21:13, Paul Gevers wrote: > >> On Mon, 18 May 2015 15:47:34 -0300 Antonio Terceiro > >> <terceiro@debian.org> wrote: > >>> The glibc test runs times out at ci.debian.net after running for ~3h, > >>> apparently since they were introduced: > >>> https://ci.debian.net/packages/g/glibc/unstable/amd64/ > >> > >> Is there any hope to have this fixed? > > > > I can drop the autopkg tests entries in the next upload if that can help. > > No, that doesn't help anything, as the current situation already > achieves the same thing. > > We are on the verge of enabling autopkgtest influence on > unstable-to-testing migration and only a working autopkgtest changes > anything there. Having glibc autopkgtest appears to me like a > very-nice-to-have. Ok. > Do you know why the autopkgtest runs so long? As Antonio mentioned in > other similar bug reports, the time out only counts for individual test > cases, so if you can break down the autopkgtest into smaller fragments, > the time out may not be an issue. I have no idea. On a fast 4-cores amd64 machine and for the 3 flavours built on amd64, the glibc takes around 20 minutes to build and the testsuite around 2h to run. I am not sure the testsuite is ran in parallel on ci.debian.net. > I haven't checked if glibc does, but remember that the idea is to test > as-installed packages, so rebuilding should be avoided unless needed for > the test itself. Even then, when test need binaries/artifacts that > aren't build by default, one could create a binary package containing > these artifacts in the regular build and depend on it while > autopkgtesting. E.g. MariaDB/MySQL do that. This is not something possible with the current upstream build system. Patches are welcomed though. Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurelien@aurel32.net http://www.aurel32.net
Attachment:
signature.asc
Description: PGP signature