Hi.

I'm packaging ldc-1.1.0-beta6 for guix, which does not allow for network access when building the package, leading to errors, and timeouts when the tests are run.

Is there a way to deactivate such tests, say a flag passed to the build system or such? I would be grateful if you'd point me to one.

In the meantime, I have had to make use of huge patches to deactivate the tests to make the builds pass, which does not seem sustainable

On Wednesday, 4 January 2017 at 18:40:57 UTC, fredmanglis wrote:
> Hi.
>
> I'm packaging ldc-1.1.0-beta6 for guix, which does not allow for network access when building the package, leading to errors, and timeouts when the tests are run.
>
> Is there a way to deactivate such tests, say a flag passed to the build system or such? I would be grateful if you'd point me to one.
>
> In the meantime, I have had to make use of huge patches to deactivate the tests to make the builds pass, which does not seem sustainable

Why are you running the tests at all for building a package?

The command

make ldmd2 druntime-ldc phobos2-ldc

will just build the compiler and standard library, along with the dmd-compatible driver. I assume you are running make alone, which might run the tests too.  Add druntime-ldc-debug and phobos2-ldc-debug to the list to get everything that normally comes with an ldc release.

On Wednesday, 4 January 2017 at 19:15:09 UTC, Joakim wrote:
> Why are you running the tests at all for building a package?
>

Well, as a principle, the Guix package manager runs tests while building the package as part of ensuring that the package was built correctly. To ensure reproducibility of the builds, however, the environment set up cuts away anything that introduces variations, network access being one of the major ones.

As such, I need that the tests are run, otherwise the package definition will not be accepted (I can't simply cop-out and disable all the tests).

To be clear, the building phase completes successfully, but the testing phase fails, and Guix requires that all the stages pass successfully.

On Thursday, 5 January 2017 at 06:18:25 UTC, fredmanglis wrote:
> On Wednesday, 4 January 2017 at 19:15:09 UTC, Joakim wrote:
>> Why are you running the tests at all for building a package?
>>
>
> Well, as a principle, the Guix package manager runs tests while building the package as part of ensuring that the package was built correctly. To ensure reproducibility of the builds, however, the environment set up cuts away anything that introduces variations, network access being one of the major ones.
>
> As such, I need that the tests are run, otherwise the package definition will not be accepted (I can't simply cop-out and disable all the tests).
>
> To be clear, the building phase completes successfully, but the testing phase fails, and Guix requires that all the stages pass successfully.

I see, do you run all the ldc tests, including the dmd testsuite? Can you post the patch you're using now, so we can get an idea of what you had to disable?  I haven't had many problems running the tests even without network access, I believe they should just keep going.

This could be pulled upstream, especially since they seem to be focusing on getting into distros recently:

http://forum.dlang.org/thread/o3cdl9$ecs$1@digitalmars.com

Maybe we can get a PR in upstream to selectively disable tests that error out in your test environment, which other packagers might want too and might save you the trouble of maintaining a patch yourself.  Let me know and I can help you with that.

On Thursday, 5 January 2017 at 07:06:11 UTC, Joakim wrote:
> I see, do you run all the ldc tests, including the dmd testsuite? Can you post the patch you're using now, so we can get an idea of what you had to disable?  I haven't had many problems running the tests even without network access, I believe they should just keep going.
>

Yes. The system runs all the tests, including dmd-testsuite.

As for the patches, there are 2, one for phobos, and one for dmd. I do not see an attach file option, and I don't know if it is acceptable to just dump the patches here: what's a convenient way to send the patches?

On Thu, Jan 5, 2017 at 5:17 PM, fredmanglis via digitalmars-d-ldc <digitalmars-d-ldc@puremagic.com> wrote:
> As for the patches, there are 2, one for phobos, and one for dmd. I do not see an attach file option, and I don't know if it is acceptable to just dump the patches here: what's a convenient way to send the patches?

The way to submit them for inclusion would be as a PR at https://github.com/dlang/dmd and https://github.com/dlang/phobos.

For just sharing them here, you can either attach them when using the
email interface (they'll also show up in the web ui), or just paste
them somewhere (Gist, ...) and post the link here.

IIRC there is already something like PHOBOS_TEST_ALLOW_NET for Phobos, though? (Not on my dev machine right now.)

 — David

On Thursday, 5 January 2017 at 16:43:47 UTC, David Nadlinger wrote:
> On Thu, Jan 5, 2017 at 5:17 PM, fredmanglis via digitalmars-d-ldc <digitalmars-d-ldc@puremagic.com> wrote:
>> As for the patches, there are 2, one for phobos, and one for dmd. I do not see an attach file option, and I don't know if it is acceptable to just dump the patches here: what's a convenient way to send the patches?
>
> The way to submit them for inclusion would be as a PR at https://github.com/dlang/dmd and https://github.com/dlang/phobos.
>

For now, I am not submitting the patches for inclusion, since as the thread notes, they are a shim, to get Guix to pass the tests

> For just sharing them here, you can either attach them when using the
> email interface (they'll also show up in the web ui), or just paste
> them somewhere (Gist, ...) and post the link here.
>

The patch I made for phobos: https://gist.github.com/fredmanglis/02d5255feba18167aaa6b23942553928#file-ldc1-1-0-disable-phobos-tests-patch

The patch I made for dmd-testsuite: https://gist.github.com/fredmanglis/a423c18abad0bfd3b27be49aa722dcc5#file-ldc1-1-0-disable-dmd-tests-patch

> IIRC there is already something like PHOBOS_TEST_ALLOW_NET for Phobos, though? (Not on my dev machine right now.)
>

Okay. That seems promising. Let me look for that

On Thursday, 5 January 2017 at 17:31:38 UTC, fredmanglis wrote:
>> For just sharing them here, you can either attach them when using the
>> email interface (they'll also show up in the web ui), or just paste
>> them somewhere (Gist, ...) and post the link here.
>>
>
> The patch I made for phobos: https://gist.github.com/fredmanglis/02d5255feba18167aaa6b23942553928#file-ldc1-1-0-disable-phobos-tests-patch
>
> The patch I made for dmd-testsuite: https://gist.github.com/fredmanglis/a423c18abad0bfd3b27be49aa722dcc5#file-ldc1-1-0-disable-dmd-tests-patch

Seem fairly small, but I could see why you wouldn't want to maintain them yourself.  If you're up for it, we could probably add a version flag to the test suite to disable these sections for packagers.

>> IIRC there is already something like PHOBOS_TEST_ALLOW_NET for Phobos, though? (Not on my dev machine right now.)
>>
>
> Okay. That seems promising. Let me look for that

Never heard of it, may have been removed.

On Thursday, 5 January 2017 at 23:18:36 UTC, Joakim wrote:
> Seem fairly small, but I could see why you wouldn't want to maintain them yourself.  If you're up for it, we could probably add a version flag to the test suite to disable these sections for packagers.
>

I am up for adding the version flag, though I might have to learn D first.

>>> IIRC there is already something like PHOBOS_TEST_ALLOW_NET for Phobos, though? (Not on my dev machine right now.)
>>>
>>
>> Okay. That seems promising. Let me look for that
>
> Never heard of it, may have been removed.

Yeah, My searches for this do not seem to be conclusive yet. I will look at it some more though to ensure I am not missing anything.

On Friday, 6 January 2017 at 13:39:31 UTC, fredmanglis wrote:
> On Thursday, 5 January 2017 at 23:18:36 UTC, Joakim wrote:
>> Seem fairly small, but I could see why you wouldn't want to maintain them yourself.  If you're up for it, we could probably add a version flag to the test suite to disable these sections for packagers.

Similar to StdUnittest in https://github.com/dlang/phobos/pull/5927, I propose we
add version(StdNetworkunittest) and/or version(StdEnvUnittest) for those tests that require internet access or access to a directory outside the source tree (e.g. $TMPDIR) as these may not be available in containers and other restrictive build systems. Does that make sense?