Hello James,
Thanks for all the details.
In short, no, currently those VM's are not running Perl blead, but the
standard perl that comes with OpenBSD, which means that all this mess
regarding IO::Socket::SSL is not an issue per see (but I can see that
all recent versions of IO::Socket::SSL are failing in OpenBSD:
http://matrix.cpantesters.org/?dist=IO-Socket-SSL%202.074;os=openbsd;reports=1).
It is not the first time that I see regular things about Perl that don't
work on OpenBSD or tests that need to be skipped.
That doesn't look good for your use case.
On the other hand, you might be able to separate the tests execution
from the submission of the reports.
Recently I decided to exclusively use
https://hub.docker.com/r/alceu/metabase-relayd to send my reports, while
configuring CPAN::Reporter to use
http://search.cpan.org/dist/Test-Reporter-Transport-Socket/ (or even
https://metacpan.org/pod/Test::Reporter::Transport::File). Installing
metabase-relayd is a time consuming task AND TLS will not be available
(because the TLS implementation for POE is currently broken), but by
changing it's configuration to use HTTP instead of HTTPS, things just
work (not ideal, but that's what we got so far). See also
https://metacpan.org/release/ARFREITAS/CPAN-Reporter-Smoker-OpenBSD-0.019/source/bin/send_reports.
Since you're using a FreeBSD (where Docker is not available AFAIK) as a
VM server, you might be able to provide a running metabase-relayd there
as well.
I've been planning to write a Test::Reporter::Transport subclass to
support gRPC and a metabase-relayd clone wrote in *whatever*, but didn't
have the time to do it so far.
Another possibility (that I didn't experiment with) is to apply to Perl
blead those same patches that are applied to OpenBSD's perl:
https://github.com/afresh1/OpenBSD-perl.
Hope that helps.
Regards,
Alceu
On 18/05/2022 11:26, James E Keenan wrote:
Alceu,
Let me describe my own OpenBSD needs and see if you can comment on them.
For the ongoing development of Perl itself ("Perl 5 Porters" or
"P5P"), I do considerable smoke-testing on the *BSDs. While I'm
primarily concerned with FreeBSD, I also do some smoke-testing of Perl
5 blead on OpenBSD.
I have available a FreeBSD-12 server provided by New York City BSD
Users Group. On that server I have installed VMs for more advanced
versions of FreeBSD, for OpenBSD and occasionally for NetBSD. I have
gotten best results by going to vagrantup.com and downloading
virtualbox versions of VMs presented under the "generic" name.
Currently I have installed an OpenBSD-6.9 VM from which I generate
smoke-test reports such as this:
http://perl5.test-smoke.org/search?selected_osnm=openbsd&report_osnm=openbsd&selected_perl=all&selected_host=perl-reporter-11.
In the normal course of events, I would soon be looking to upgrade to
OpenBSD-7.1 by installing this VM:
https://app.vagrantup.com/generic/boxes/openbsd7/versions/3.6.14.
Now, here's where things get complicated.
While smoke-testing of Perl 5 blead is my primary concern, there are
also times when I need to install blead perl on my VMs for the purpose
of investigating reports that changes in blead have begun to cause
failures to build or test CPAN distributions. In P5P we refer to this
as the "Blead Breaks CPAN" ("BBC") problem. BBC issues often require
some kind of modification both in Perl 5 core and in the CPAN
distribution in order to be deemed resolved. For thorough
verification, we need to test on Perl 5 blead on a wide variety of
platforms, including OpenBSD. And while we're at it, it makes sense
to generate a CPANtesters report which provides public documentation
that the BBC issue has been fixed. So that means that in my OpenBSD
VM, I typically want to install Perl 5 blead, then install a
CPANtesters stack against that blead perl, and then test the CPAN
distribution in a way that generates a CPANtesters report.
Roughly speaking, that means this sequence of commands:
#####
$ sh ./Configure -des -Dusedevel -Uversiononly
-Dprefix=${SOME_TEMPDIR} -Dman1dir=none -Dman3dir=none
$ make install
$ cd ${SOME_TEMPDIR}
# get and install 'cpanm'
$ ./bin/cpanm Task::CPAN::Reporter
$ ./bin/cpan -i Some::Module
#####
The problem I've been encountering recently is that the
Task-CPAN-Reporter stack includes IO-Socket-SSL, and the CPAN
maintainer of IO-Socket-SSL has given up on trying to maintain that
module on OpenBSD. See, for example,
https://github.com/noxxi/p5-io-socket-ssl/issues/115. While the
OpenBSD people do a good job of maintaining their *port* of
IO-Socket-SSL via patches, that port is only intended to work with the
*system* perl in a given version of OpenBSD. If you try to use 'cpan'
or 'cpanm' to install something that has IO::Socket::SSL in its
dependency chain (e.g., Task::CPAN::Reporter), you will get test
failures.
So I'm wondering how your OpenBSD VM, which is specifically intended
to serve as the basis for CPANtesters reporting, work around this
problem?
Thank you very much.
Jim Keenan
