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