new releases of cpan-openbsd-smoker

[Alceu Rodrigues de Freitas Junior via cpan-testers-discuss]

Hello folks,

I released yesterday (a little bit late, to be honest) newer versions of
the CPAN Smoker for OpenBSD Vagrant boxes:

https://app.vagrantup.com/arfreitas/boxes/openbsd-7.0-cpan-smoker-i386

https://app.vagrantup.com/arfreitas/boxes/openbsd-7.0-cpan-smoker-amd64

OpenBSD 7.1 is already available and I should release boxes for it as
well in the next few days;

As a reference, the newer boxes are managed with Ansible, so please
refer to the "ansible" on the Github repository for now:

https://github.com/glasswalk3r/cpan-openbsd-smoker/tree/ansible

Regards,

Alceu

[James E Keenan]

On 5/10/22 07:17, Alceu Rodrigues de Freitas Junior via

cpan-testers-discuss wrote:
> Hello folks,
>
> I released yesterday (a little bit late, to be honest) newer versions of
> the CPAN Smoker for OpenBSD Vagrant boxes:
>
> https://app.vagrantup.com/arfreitas/boxes/openbsd-7.0-cpan-smoker-i386
>
> https://app.vagrantup.com/arfreitas/boxes/openbsd-7.0-cpan-smoker-amd64
>
> OpenBSD 7.1 is already available and I should release boxes for it as
> well in the next few days;
>

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

[Alceu Rodrigues de Freitas Junior via cpan-testers-discuss]

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

[James E Keenan]

On 5/18/22 16:12, Slaven Rezic wrote:
>> James E Keenan <jke...@pobox.com <mailto:jke...@pobox.com>> hat am
>> 18.05.2022 16:26 geschrieben:
>>
> [...]

>> 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

>> <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.

> Actually I think there's no need to use Task::CPAN::Reporter. Just
> install plain CPAN::Reporter and make sure to use a http URL in your
> .cpanreporter/config.ini.
>

Slaven to the rescue once again!

Going back a decade or more, when I was first attempting to submit
reports to CPANtesters, I found CPAN::Reporter very difficult to use
consistently. Granted, that probably reflected my own ignorance more
than the module. Nonetheless, I held off on CPANtesters for many years.

In recent years, when I've had access to this FreeBSD server, I've
installed quite a few VMs and -- on the FreeBSD servers in particular --
I found that Task::CPAN::Reporter Just Worked(TM). So that's why I
tried it in my OpenBSD VMs as well, and for several years it Just Worked
there, too. So I never had reason to think that I should "downgrade"
from https to http in my .cpanreporter/config.ini.

http://metabase.cpantesters.org/tail/log.txt is now being populated with
reports from this OpenBSD-6.9 VM and a perl somewhere between 5.35.10
and 5.35.11. So I look forward to submitting several hundred CPANtester
reports once perl-5.36.0-RC0 comes out.

[Alceu Rodrigues de Freitas Junior via cpan-testers-discuss]

On 18/05/2022 17:12, Slaven Rezic wrote:
> Actually I think there's no need to use Task::CPAN::Reporter. Just
> install plain CPAN::Reporter and make sure to use a http URL in your
> .cpanreporter/config.ini.
>

This should do it, but it's not ideal since we cannot verify the
identity of the reports destination.

Is there any alternative to metabase-relayd?

[David Cantrell]

On 19/05/2022 13:52, Alceu Rodrigues de Freitas Junior via

cpan-testers-discuss wrote:
> On 18/05/2022 17:12, Slaven Rezic wrote:
>> Actually I think there's no need to use Task::CPAN::Reporter. Just
>> install plain CPAN::Reporter and make sure to use a http URL in your
>> .cpanreporter/config.ini.
> This should do it, but it's not ideal since we cannot verify the
> identity of the reports destination.

Oh how awful! Someone other than CPANtesters might find out whether some
piece of software works or not!

--
David Cantrell

[Alceu Rodrigues de Freitas Junior via cpan-testers-discuss]

And what is your point then?

[Alceu Rodrigues de Freitas Junior via cpan-testers-discuss]

On 20/05/2022 10:50, Alceu Rodrigues de Freitas Junior via

cpan-testers-discuss wrote:
>
> On 20/05/2022 07:44, David Cantrell wrote:
>> On 19/05/2022 13:52, Alceu Rodrigues de Freitas Junior via
>> cpan-testers-discuss wrote:
>>> On 18/05/2022 17:12, Slaven Rezic wrote:
>>>> Actually I think there's no need to use Task::CPAN::Reporter. Just
>>>> install plain CPAN::Reporter and make sure to use a http URL in
>>>> your .cpanreporter/config.ini.
>>> This should do it, but it's not ideal since we cannot verify the
>>> identity of the reports destination.
>>
>> Oh how awful! Someone other than CPANtesters might find out whether
>> some piece of software works or not!
> And what is your point then?

Unless the point is that you misunderstood the fact that a TLS is not
only useful to encrypt data between two points but also to guarantee the
receiver is actually the intended one, not a fake metabase replacement
that you reached because of DNS poisoning or something like that.

Not sure why someone would do this, but hell, it's a crazy world out there.