[Gluster-devel] autobuild fails because of network

Niels de Vos ndevos at redhat.com
Tue Nov 19 08:53:06 UTC 2013

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?


More information about the Gluster-devel mailing list