Re: [Gluster-devel] autobuild fails because of network

[Niels de Vos]

On Tue, Nov 19, 2013 at 10:41:39AM +0100, Niels de Vos wrote:
> On Tue, Nov 19, 2013 at 02:32:51PM +0530, Vijay Bellur wrote:
> > 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"
> 
> I'm not sure... I've now moved the /var/cache/mock/* out of the way on 
> build.gluster.org. This should trigger a complete refresh of the 
> packages and repo-lists. http://build.gluster.org/job/regression/2637/ 
> has been scheduled and should start soon.

That did not work either... Manually downloading the repo.xml and other 
files works without issues.

There seems to be a proxy on build.gluster.org. I do not know if this is 
recently added to some environment that affects the regression tests?  
Using that proxy to download anything returns 404 errors to me too.

I've now disabled (hopefully) any proxy directives in 
/etc/mock/site-defaults.cfg.  
http://build.gluster.org/job/regression/2638/ should be the first run 
that explicitly disables any proxy servers.

/me crosses his fingers