On 24 Jul, Damjan Jovanovic wrote: > On Fri, Jul 22, 2016 at 9:39 PM, Don Lewis <truck...@apache.org> wrote: > >> On 22 Jul, Damjan Jovanovic wrote: >> > I've progressed much further, and openoffice-fbsd-nightly, >> > openoffice-linux32-nightly, openoffice-linux64-nightly, and >> > openoffice-linux64-rat are now building, while >> openoffice-linux32-snapshot >> > is only temporarily breaking due to SourceForge issues. I've also made >> some >> > interesting discoveries about the Windows buildbots. >> >> FreeBSD still needs LWP::Protocol::https. It's only working because of >> the non-https fallback to a specific SourceForge mirror. >> >> > No, it's only working because of --with-system-<everything>
The FreeBSD buildbot uses more --with-system stuff that the other buildbots, but not as much as the FreeBSD port. It was still getting LWP::Protocol::https failures, but they weren't fatal because of the fallback to a specific http SourceForge mirror. Most recently it was only succeeding while the Linux buildbots were failing to download openssl because thate version wasn't present on the SourceForge mirror and the FreeBSD buildbot used --with-system-openssl. BTW, the FreeBSD port doesn't rely on bootstrap to download anything. Bootstrap is run during the build stage, and when building FreeBSD packages, there is no network connectivity during the build stage. Instead, everything is downloaded and stashed in ext_sources before configure is run. > Also LWP::Protocol::https is dead now, please see my upcoming email. Ding, dong, the witch is dead ... >> > That buildbot is currently running out of disk space, and it doesn't help >> > that we "svn co" and then "svn export" a second copy. Originally the >> > buildbot script used other tricks, like "svn switch", or keeping an SVN >> > checkout across builds that was just updated and then exported from for >> > each build, but some time ago I switched to a full "svn co" because it >> was >> > too unreliable (eg. files can get locked and need "svn cleanup"). With a >> > full checkout there is no need to export, as we get a fresh copy each >> time. >> > I'll overhaul that buildbot script and try make it simpler and cleaner. >> >> Doing an update followed by an export of that would be less resource >> intensive, though it adds 50% (since .svn isn't copied) to the space >> consumed by the source. The write-locked file problem should only occur >> if the update is interrupted, and since there is so little activity in >> the repo, the updates should be pretty fast have a low probability of >> failing. A full checkout would be much more likely to fail in the >> middle. You could always run "svn cleanup" before "svn update". >> >> A checked out source tree for 4.1.2 is about 725 MB. A second exported >> copy would bring the total up to about 1090 MB, which is still fairly >> small compared to the overall build size. If space is an issue and load >> on the svn server is not, then doing a fresh export (vs a checkout) from >> the server each time would be the best. >> >> > Space was an issue because I was using the small C: drive instead of E:. > > As the buildbots run automatically and we usually don't initiate builds and > wait for results, little is lost by doing SVN update the slowest way, and > much is gained through the increased reliability and simplicity. Doing svn export direct from the repo would be just as reliable as svn co. It would be quicker and more spece efficient because it wouldn't create a second copy of the source under .svn that we don't use since we aren't doing incremental updates and we are just going to delete at the start of the next build. Thanks for spending the time on this! It'll be awesome having working buildbots again. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
