[Gluster-devel] autobuild fails because of network

Vijay Bellur vbellur at redhat.com
Tue Nov 19 09:02:51 UTC 2013

On 11/19/2013 02:23 PM, Niels de Vos wrote:
> 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?

We seem to be looking for 

but most mirrors don't seem to have that and are hence returning 404.

Could it be anyway related to:

"Not using downloaded repomd.xml because it is older than what we have:
   Current   : Thu Oct 17 10:00:15 2013
   Downloaded: Mon Oct 14 08:24:27 2013"


More information about the Gluster-devel mailing list