Daniel P. Berrange <berra...@redhat.com> writes: > On Tue, Jul 25, 2017 at 03:15:07PM +0100, Alex Bennée wrote: >> >> Philippe Mathieu-Daudé <f4...@amsat.org> writes: >> >> > Signed-off-by: Philippe Mathieu-Daudé <f4...@amsat.org> >> > --- >> > .../docker/dockerfiles/debian-bleeding-dev.docker | 94 >> > ++++++++++++++++++++++ >> > 1 file changed, 94 insertions(+) >> > create mode 100644 tests/docker/dockerfiles/debian-bleeding-dev.docker >> > >> > diff --git a/tests/docker/dockerfiles/debian-bleeding-dev.docker >> > b/tests/docker/dockerfiles/debian-bleeding-dev.docker >> > new file mode 100644 >> > index 0000000000..d6ae20692c >> > --- /dev/null >> > +++ b/tests/docker/dockerfiles/debian-bleeding-dev.docker > > >> > +RUN git clone git://anongit.freedesktop.org/virglrenderer >> > /usr/src/virglrenderer >> > +RUN cd /usr/src/virglrenderer && ./autogen.sh && ./configure >> > --with-glx --disable-tests && make install >> >> There are a lot of moving parts basing this in debian unstable and >> compiling extra bleeding edge stuff. What does this buy that the clang >> and toolchain builds in Travis don't already cover? > > FWIW, the clang version in Travis is somewhat old compared to the version > that Peter uses during merge testing. I recently had a pull request that > passed travis tests, but failed with modern clang. > > Doesn't neccessarily mean we need debian bleeding edge though - a Fedora > 26 image would have detected that since it has new clang.
Yeah I think from a compiler testing point of view it would be nice to have two images, one for latest clang, one for latest gcc that are pre-set up to build with them for QEMU_CONFIGURE_OPTS. I'd rather those on a stable base distro than taking a potshot on the status of a rolling distro on any given day. The virgl and other tip of tree installs are done once and probably don't need repeating in other trees. -- Alex Bennée
