On Tue, Nov 19, 2013 at 01:19:05PM +0530, Vijay Bellur wrote: > On 11/19/2013 01:15 PM, Niels de Vos wrote: > >On Tue, Nov 19, 2013 at 12:19:04PM +0530, Vijay Bellur wrote: > >>On 11/19/2013 07:06 AM, Emmanuel Dreyfus wrote: > >>>Hi > >>> > >>>I have 3 changes that have failed, apparently for network connectivity > >>>problem on the build machine: > >>>http://review.gluster.org/6281 > >>>http://review.gluster.org/6283 > >>>http://review.gluster.org/6287 > >> > >>Seem to be failing because of rpm.t: > >> > >>Test Summary Report > >>------------------- > >>./tests/basic/rpm.t (Wstat: 0 Tests: 5 > >>Failed: 1) > >> Failed test: 5 > >> > >>Niels: Any idea on what might be causing the rpm.t failure? > > > >rpm.t uses "mock" to rebuild the rpms inside a new+clean chroot. It will > >download and cache the needed packages for setting up these chroots > >(both for Fedora EPEL 5 and 6). If there is a restriction on using the > >network while running "mock", we can do one of the following: > > > >a. setup a proxy on localhost > >b. setup a mirror on localhost > >c. run "mock" once for caching, and update the test to use "--offline" > > > >My personal preference goes to (a), but that may not be suitable in the > >environment? > > > > This failure happened in build.gluster.org. Could any changes in > autogen.sh trigger a failure in rpm.t on build.gluster.org? I looked > at the patches but did not find anything that looked very obvious to > me. rpm.t should run if there are changes in files that affect the build-system. So, yes, changes in autogen.sh can trigger failures in rpm.t. However, in this case, the failure is not due to the change (or, well I do not expect that), but due to the fact that there was a problem with the network or epel mirrors. http://build.gluster.org/job/regression/2634/consoleFull clearly shows some 404 errors while downloading the package-lists to setup the chroot... Any suggestions on how we should handle these? Niels
