Re: 11_x86 build - build failures due to 'no space on device'
> > For some reason fseventsd was taking 14GB of memory. > Not really surprising, for a machine being used as a builder. The constant creation and deletion of files when compiling software is bound to be generating a ton of file system events. -- Jason Liu On Thu, Apr 8, 2021 at 1:58 PM Ryan Schmidt wrote: > > > On Apr 8, 2021, at 07:25, Ryan Schmidt wrote: > > > We now have 21GB free. > > 31GB free after rebooting. For some reason fseventsd was taking 14GB of > memory. The VM only has 8GB of real memory so a lot of swap was being used. > This is probably also the explanation for why that builder has gotten a > larger backlog of builds lately. > >
macmini colo m1
Hey I saw this offer of free access to m1 mini hardware from macmini colo for opensource projects. Not sure about who/what qualifies in regards to macports but figured I'd pass it along. https://www.macstadium.com/opensource Blake
Re: 11_x86 build - build failures due to 'no space on device'
Ryan Schmidt wrote: > Both copies of the simulator caches came back again. I filed FB9072613 with > Apple about this. We were down to 3GB free disk space which isn't a good > place to be. I deleted the caches again and marked the dyld directories chmod > 000. Let's see if that prevents Xcode from recreating the caches, hopefully > without causing error messages that cause builds to fail. We now have 21GB > free. I recently learned that 'xcrun simctl delete unavailable’ and 'xcrun simctl delete all’ exist. Those commands can be used to reclaim disk space in use by Xcode simulators. Not sure if they could be of use in this scenario. Nils.
Re: 11_x86 build - build failures due to 'no space on device'
On Apr 8, 2021, at 07:25, Ryan Schmidt wrote: > We now have 21GB free. 31GB free after rebooting. For some reason fseventsd was taking 14GB of memory. The VM only has 8GB of real memory so a lot of swap was being used. This is probably also the explanation for why that builder has gotten a larger backlog of builds lately.
Re: 11_x86 build - build failures due to 'no space on device'
On Mar 23, 2021, at 11:04, Ryan Schmidt wrote: > On Feb 11, 2021, at 04:21, Christopher Jones wrote: > >> I am seeing some large builds fail due to drive space issues >> >> https://build.macports.org/builders/ports-11_x86_64-builder/builds/21466/steps/install-port/logs/stdio >> error: >> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/install_name_tool: >> can't write output file: >> bazel-out/host/bin/tensorflow/python/_pywrap_tfcompile.so.XX (No space >> left on device) >> Could the space on the drive for this build be reviewed and purged / >> increased a bit ? >> >> cheers Chris > > I did make an additional change to mpbb to delete more unneeded ports: > > https://trac.macports.org/ticket/57464#comment:12 This change uninstalled more ports than I intended. This resulted in many ports needing to be reinstalled often. This slowed down builds and resulted in a backlog of builds. I fixed the problem which means more ports will remain installed now, which will take a little more disk space again. https://trac.macports.org/ticket/57464#comment:16 > And after updating to macOS 11.2.3 and Xcode 12.4 I deleted the simulator > directories again and I don't think they've come back. > > We have 26GB free at the moment. So let's let the next builds of > py-tensorflow* run without interrupting them and see if they complete now. Both copies of the simulator caches came back again. I filed FB9072613 with Apple about this. We were down to 3GB free disk space which isn't a good place to be. I deleted the caches again and marked the dyld directories chmod 000. Let's see if that prevents Xcode from recreating the caches, hopefully without causing error messages that cause builds to fail. We now have 21GB free.