=== JanC is now known as Guest65907
=== JanC_ is now known as JanC
=== cjwatson changed the topic of #launchpad to: git.launchpad.net emergency maintenance | Help contact: @pappacena (12:00-21:00 UTC Mon-Fri) | Launchpad is an open source project: https://dev.launchpad.net/ | This channel is logged: http://irclogs.ubuntu.com/ | User Guide: https://help.launchpad.net/ | Support and spam reporting: https://answers.launchpad.net/launchpad
=== cjwatson changed the topic of #launchpad to: Help contact: @pappacena (12:00-21:00 UTC Mon-Fri) | Launchpad is an open source project: https://dev.launchpad.net/ | This channel is logged: http://irclogs.ubuntu.com/ | User Guide: https://help.launchpad.net/ | Support and spam reporting: https://answers.launchpad.net/launchpad
[14:18] <cjwatson> Apologies for the git disruption there.  Hopefully things will be a bit smoother now
[17:39] <pmjdebruijn> https://launchpadlibrarian.net/534741323/buildlog_ubuntu-focal-amd64.prusa-slicer_2.3.1-0pmjdebruijn1~20.04_BUILDING.txt.gz am I reading that right, that my package build failed because of a lack of diskspace?
[17:41] <pmjdebruijn> a local builddir does end up taking ~14GB
[17:47] <pappacena> pmjdebruijn If I'm not wrong, the builders are provisioned with 30gb disks. Are you sure it doesn't use more than 14GB at any given time during the build?
[18:00] <pmjdebruijn> not sure
[18:00] <pmjdebruijn> but presumably on those 30GB disks, part of that is taken with the build environment
[18:01] <pappacena> Yes, for sure. BTW, did you try to build again? I'm not seeing explicit disk space errors during the build process.
[18:01] <pmjdebruijn> I have enabled the debug symbols, which in local builds results in a 300MB ddeb
[18:02] <pmjdebruijn> I can ask to rebuild, np
[18:02] <pmjdebruijn> so let's wait and see
[18:05] <pappacena> It seems to be failing for some other reason, not disk space. The only place where "disk space" is mentioned is the final summary...
[18:53] <cjwatson> They're 60GB disks
[18:54] <cjwatson> And agreed, disk space is not the problem here
[18:55] <cjwatson> It's just absurdly buried in a gigantic log
[18:55] <cjwatson> But if you search for the *first* occurrence of "Error 2" (matching the final error code from make) then you'll find it
[18:55] <cjwatson> virtual memory exhausted: Cannot allocate memory
[18:55] <cjwatson> make[3]: *** [tests/libslic3r/CMakeFiles/libslic3r_tests.dir/build.make:261: tests/libslic3r/CMakeFiles/libslic3r_tests.dir/test_voronoi.cpp.o] Error 1
[18:56] <cjwatson> So single absurdly large translation unit I guess
[18:56] <cjwatson> Maybe try a lower optimization level at least for that file
[18:57] <cjwatson> I shouldn't think tests critically need to be built with -O3, so that might help.  Or there are typically various other approaches to make compilers use less memory
[19:16] <sarnold> I saw discussion recently about some projects trying to bundle multiple source files into a single translation unit for some reason, and this causinga  huge amount of memory use