> On 14 Aug 2019, at 11:30 pm, Ryan Schmidt <ryandes...@macports.org> wrote: > > > > On Aug 14, 2019, at 08:28, Christopher Jones wrote: > >>> As you can see from the cleanup step's output, there was 21GiB of space >>> available when the build failed. >>> >>> https://build.macports.org/builders/ports-10.7_x86_64_legacy-builder/builds/108375/steps/cleanup/logs/stdio >>> >>> How much free space does it need? >> >> I guess more than that… > > It looks like gcc9 did in the mean time build on that builder.
yeah, I triggered a rebuild to try again, and it worked that time. > > I've previously used Grand Perspective to examine the disk space usage of the > build machines and didn't see anything big, but it turns out Grand > Perspective doesn't include items whose names begin with a period, and that's > where the problem was: the .Spotlight-V100 directory on the 10.7 builder was > 36GiB the first time I looked and 26GiB the second time I looked, and on the > 10.8 builder it was 16GiB. I've deleted the Spotlight indexes on all the > builders and hopefully when they're done rebuilding they'll be smaller. I wouldn’t use applications like that for this sort of thing, for that very reason. Then tend to try and be just a bit too clever for my tastes. In the end, I tend to just rely on good old dumb ‘df -h’ … > > Maybe I should just exclude /opt/local and /Applications/MacPorts from the > Spotlight indexes on the builders, but I wasn't sure if that would have some > undesirable effect on some build system (Xcode?) that might use Spotlight to > find something? I guess given how frequently the data in these locations change, that’s part of the problem. The systems must be having to re-index all the time…. I cannot see what excluding these locations would break. I am sure there are some that already do this themselves. I have in the past (not right now, for reasons I forget but for sure not related to anything in MP breaking because of it. Chris
smime.p7s
Description: S/MIME cryptographic signature
