[Gluster-devel] autobuild fails because of network

[Vijay Bellur]

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 
8e8d889d66198e3345e4a442621391938c859c477042f107f65f99dc7242e037-primary.sqlite.bz2

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"

-Vijay