Paweł Kraszewski

Ah yes, regression test... During weekend I'll prepare minimal example exhibiting unwanted behaviour (including RMQ config and all the necessary certs & keys). From _server's_ point of view it looks...

Checked. All the details are in my [other bug report](https://github.com/golang/go/issues/54221). I resolved the other problem by un-hiding `goroot` directory (from `.goroot`). It has no influence on the issue reported here.

If by a `upstream source tree` you mean one from the official manual: ``` git clone https://go.googlesource.com/go goroot cd goroot git checkout release-branch.go1.19 # This today still equals to tag...

**Nothing** special. - OS: `FreeBSD MaxBSD-1 13.1-RELEASE FreeBSD 13.1-RELEASE releng/13.1-n250148-fc952ac2212 MAXPHYS amd64` (That `MAXPHYS` is just two-line config tweak bumping up maximal DMA transfer size.) - x86_64 machine (2x 12C/24T...

## Got it! The `cmd/internal/moddeps` test fails, when the directory with go source is **hidden**!

And how about not using `exit()` at all, as God intended us to use Erlang? "And Joe said: _thou shalt not use catch/exit/try/throw for program flow control_".

Well, in my daily job, a failed TLS connection is nothing wrong from _programmers's_ point of view. In particular, it is nothing exceptional enough to pull the `exit()` gun. Just...

I'm open to cooperation. I suppose this issue might be closed for now. Best regards!

Yes, of course. ## Input files The source is unmodified `rebar3 new app`, except for `mylib.app.src`. ``` {application, mylib, [{description, "An OTP application"}, %% The following line is correct and...

What fascinates me the most, the troubleigiving fragment of the code is guarded by `if cfg!(target_os = "linux") { }` and should not be interpreted on FreeBSD in the first...