gluster-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Niels de Vos
Subject: Re: [Gluster-devel] autobuild fails because of network
Date: Tue, 19 Nov 2013 10:41:39 +0100
User-agent: Mutt/1.5.20 (2009-12-10)

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.

Niels



reply via email to

[Prev in Thread] Current Thread [Next in Thread]