Steps 1-4 first delete the "source" directory, do a fresh SVN checkout (not update) into "source", delete the "build" directory, and copy "source" to "build". The build is then run in "build". This was the only robust way to get it working and fix all the errors and timeouts that were happening earlier. I think that's confusing you here.
On linux64-nightly I've changed the buildbot script to cache downloads across builds. In 9 builds, it hasn't helped one bit: all 14 missing tarballs must have failed every single time. The only thing that made a difference, getting it reduced from 15 missing tarballs to 14, is fixing the upstream URL for vigra in main/external_deps.lst. This tells me it's access to SourceForge that is the problem here. In r1731307 I patched main/solenv/bin/download_external_dependencies.pl to log the HTTP status line when a download fails, and it finally showed what's really wrong: download from http://sourceforge.net/projects/oooextras.mirror/files/067201ea8b126597670b5eff72e1f66c-mythes-1.2.0.tar.gz failed (501 Protocol scheme 'https' is not supported (LWP::Protocol::https not installed)) I've asked infra to get LWP::Protocol::https installed on all the buildbots and they're working on it. We also need to update our build instructions to install it when building. On Sat, Feb 20, 2016 at 12:06 AM, Kay Schenk <kay.sch...@gmail.com> wrote: > [top posting] > > hmmm...maybe I've figured out the problem? > > using Linux-32 nightly as the example. > > Take a look at the PWD variable in this listing: > > https://ci.apache.org/builders/openoffice-linux32-nightly/builds/191/steps/configure/logs/stdio > > and the corresponding TARFILE_LOCATION (which is correct for the PWD > specified) -- > > "The variable TARFILE_LOCATION is set to: > /home/buildslave20/slave20/openoffice-linux32-nightly/build/ext_sources" > > so conceptually NO downloads from 3rd party locations should happen > at all in normal building with the buildbots since they have the > correct local file info for 3rd party sources. This is the case for > our local builds as well. > > However, when you look at the output for the svn update for this > same run, look at where the update dumps -- > > PWD=/home/buildslave20/slave20/openoffice-linux32-nightly/source > > so, in my mind, it's not in > /home/buildslave20/slave20/openoffice-linux32-nightly/build/ > > where I think it should be to make the build work correctly. > > What do others think? > > > > On 02/17/2016 03:40 PM, Kay Schenk wrote: >> >> On Tue, Feb 16, 2016 at 2:47 PM, Andrea Pescetti >> <pesce...@apache.org <mailto:pesce...@apache.org>> wrote: >> >> Kay Schenk wrote: >> >> On 02/13/2016 11:45 AM, Andrea Pescetti wrote: >> >> it seems that buildbots are having issues with network >> in general >> >> Do we have any additional news on the download failures >> specifically >> from the buildbots to SourceForge downloads? >> >> >> Why SourceForge? Look at >> >> https://ci.apache.org/builders/openoffice-linux64-nightly/builds/243/steps/retry%20bootstrap/logs/stdio >> to see that ALL downloads in ./bootstrap are failing; sure, most >> of them are from SourceForge, but this is irrelevant, since >> downloads from Mozilla and other sources are failing too. >> >> The problem is most likely on the buildbot side. For some >> reason, be it a full disk or a firewall restriction, it can't >> download stuff, and this should be checked with someone who has >> shell access to that machine. >> >> The following, failed from buildbot, were OK with my test script >> >> >> I confirm I've run ./boostrap without any problems too last >> weekend. Again, the problem is on the buildbots and not elsewhere. >> >> >> Regards, >> Andrea. >> >> >> I got on HipChat a while ago and all that was suggested was we use >> "https" instead of "http" to SourceForge. But, given that my little >> stripped down download script worked fine without this, I doubt this >> is it. >> I didn't ask about filled up disk and perhaps I should have. :( >> >> We COULD get around this but just using the sources already in our >> trunk and changing the SVN call to that to just a file URL for the >> time being, and referencing that as URL1 for these, but I guess that >> might be considered bad. We don't distribute these with the source >> and we would need to remember to change this back for a release. But >> just a thought. >> >> -- >> ---------------------------------------------------------------------- >> MzK >> >> "Though no one can go back and make a brand new start, >> anyone can start from now and make a brand new ending." >> -- Carl Bard >> >> > > -- > -------------------------------------------- > MzK > > "Though no one can go back and make a brand new start, > anyone can start from now and make a brand new ending." > -- Carl Bard > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
