[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
