This is a bit of a sledgehammer to crack a walnut, but comes down to the fact that at least one std.process unittest fails when the Launchpad build system is running it, for LDC 1.5.0+ (i.e. phobos 2.075+):
391: Test command:
/build/ldc2-1.5/parts/ldc/build/runtime/phobos2-test-runner
"std.process"
391: Test timeout computed to be: 9.99988e+06
391: sh: 0: getcwd() failed: No such file or directory
391: /bin/sh: 0: Can't open /tmp/std.process temporary file
4c760c9b-f557-4216-a10f-a2c09428404a
391: ****** FAIL release64 std.process
391: core.exception.AssertError@std/process.d(1095): assertThrown
failed: No ProcessException was thrown.
391: ----------------
391: ??:? pure @safe void
std.exception.assertThrown!(std.process.ProcessException,
std.process.Pid).assertThrown(lazy std.process.Pid, immutable(char)[],
immutable(char)[], ulong) [0x4b0250c]
391: ??:? void std.process.__unittestL1075_11() [0x4b02e42]
391: ??:? [0x4b0efe0]
391: ??:? void test_runner.doTest(object.ModuleInfo*, ref bool)
[0x34351bf]
391: ??:? bool test_runner.testModules() [0x34350c8]
391: ??:? runModuleUnitTests [0x4b2ae1d]
391: ??:? _d_run_main [0x4b1b4ad]
391: ??:? __libc_start_main [0x34ad82f]
391: ??:? _start [0x3434e58]
391/1568 Test #391: std.process
..................................................................***Failed
0.68 sec
sh: 0: getcwd() failed: No such file or directory
/bin/sh: 0: Can't open /tmp/std.process temporary file
4c760c9b-f557-4216-a10f-a2c09428404a
****** FAIL release64 std.process
core.exception.AssertError@std/process.d(1095): assertThrown failed: No
ProcessException was thrown.
The failing getcwd() call appears to be being triggered by the call to std.process.uniqueTempPath() introduced in this patch:
dlang/phobos@8bc0ab6
... which under the hood calls std.file.tempDir(), which then calls getcwd().
This seems most likely to be failing because it clashes with permissions available in the Launchpad system (as the same tests pass just fine when run locally). For this reason it seems best, in the short term, to just disable std.process tests for the snap package for LDC 1.5 and higher.
Longer term, it may be worth looking into a CI/build system that is less picky about what a program can do.
This is a bit of a sledgehammer to crack a walnut, but comes down to the fact that at least one
std.processunittest fails when the Launchpad build system is running it, for LDC 1.5.0+ (i.e. phobos 2.075+):The failing
getcwd()call appears to be being triggered by the call tostd.process.uniqueTempPath()introduced in this patch: dlang/phobos@8bc0ab6... which under the hood calls
std.file.tempDir(), which then callsgetcwd().This seems most likely to be failing because it clashes with permissions available in the Launchpad system (as the same tests pass just fine when run locally). For this reason it seems best, in the short term, to just disable
std.processtests for the snap package for LDC 1.5 and higher.Longer term, it may be worth looking into a CI/build system that is less picky about what a program can do.