|Summary:||audio/logitechmediaserver: build IO::Socket::SSL so plugins work (e.g. RadioParadise)|
|Product:||Ports & Packages||Reporter:||hartzell|
|Component:||Individual Port(s)||Assignee:||freebsd-ports-bugs mailing list <ports-bugs>|
|Severity:||Affects Some People||CC:||mark|
Description hartzell 2019-02-03 19:44:44 UTC
Created attachment 201692 [details] diff enabling IO::Socket::SSL and updating pkg-plist file Various plugins, e.g. the [RadioParadise plugin][radioparadise] require IO::Socket::SSL. That module is commented out in the buildme.sh script the port uses. This change uncomments it in the buildme.sh script and adds the various installed files to the pkg-plist file. The change to `files/vendorpatch-CPAN_buildme.sh` is a handcrafted addition to the existing patch. The change to the pkg-plist file is the result of hand-merging the output from `make makeplist` and touching up various AMD64ONLY bits. The indirect dependency `Net::SSLeay/SSLeay.so` ends up linking against the base system's SSL library. ``` root@moose:/usr/ports/audio/logitechmediaserver # ldd /usr/local/lib/perl5/site_perl/mach/5.28/auto/Net/SSLeay/SSLeay.so /usr/local/lib/perl5/site_perl/mach/5.28/auto/Net/SSLeay/SSLeay.so: libperl.so.5.28 => /usr/local/lib/perl5/5.28/mach/CORE/libperl.so.5.28 (0x801400000) libssl.so.8 => /usr/lib/libssl.so.8 (0x80191a000) libcrypto.so.8 => /lib/libcrypto.so.8 (0x801c00000) libz.so.6 => /lib/libz.so.6 (0x80206f000) libc.so.7 => /lib/libc.so.7 (0x800823000) libthr.so.3 => /lib/libthr.so.3 (0x802287000) libm.so.5 => /lib/libm.so.5 (0x8024af000) libcrypt.so.5 => /lib/libcrypt.so.5 (0x8026dc000) libutil.so.9 => /lib/libutil.so.9 (0x8028fb000) ``` I'm unsure if there should be an option to use the PORTS version (I'm out of the loop on proper PORTS SSL behavior). [radioparadise]: https://forums.slimdevices.com/showthread.php?108189-Announce-Radio-Paradise-Lossless-Streaming-(Plugin-v2)
Comment 1 Mark Dixon 2019-02-08 14:48:06 UTC
This hangs for me running the SSL tests; rm -f blib/arch/auto/Net/SSLeay/SSLeay.so LD_RUN_PATH="/usr/lib" cc -shared -L/usr -L/usr/lib -L/usr/local/lib/perl5/5.28/mach/CORE -lperl -L/usr/local/lib -fstack-protector-strong SSLeay.o -o blib/arch/auto/Net/SSLeay/SSLeay.so \ -L/usr -L/usr/lib -lssl -lcrypto -lz \ chmod 755 blib/arch/auto/Net/SSLeay/SSLeay.so Skip blib/lib/Net/SSLeay/Handle.pm (unchanged) Skip blib/lib/Net/SSLeay.pm (unchanged) Skip blib/lib/Net/SSLeay.pod (unchanged) PERL_DL_NONLAZY=1 "/usr/local/bin/perl" "-MExtUtils::Command::MM" "-MTest::Harness" "-e" "undef *Test::Harness::Switches; test_harness(0, 'inc', 'blib/lib', 'blib/arch')" t/local/*.t t/handle/local/*.t t/handle/local/05_use.t ................ ok t/local/01_pod.t ....................... skipped: Test::Pod 1.00 required for testing POD t/local/02_pod_coverage.t .............. skipped: these tests are for only for release candidate testing. Enable with RELEASE_TESTING=1 t/local/03_use.t ....................... ok t/local/04_basic.t ..................... ok t/local/05_passwd_cb.t ................. ok t/local/06_tcpecho.t ................... ok t/local/07_sslecho.t ................... 1/78 ^Cgmake: *** [Makefile:984: test_dynamic] Interrupt *** Signal 2 *** Signal 2
Comment 2 hartzell 2019-02-08 17:10:09 UTC
@Mark -- thanks for taking it for a test drive. It works for me(tm). I'm using it in a FreeNAS 11.2 jail on amd64. Can you tell me more about your test environment? It looks like that test is starting up a test service listening on 127.0.0.1 and then talking to it. Is there any firewalling or ... in place that would get in the way of that? g.
Comment 3 Mark Dixon 2019-02-10 21:09:06 UTC
I had a quick look - the test seems to assume localhost is equivalent to 127.0.0.1 (which it may not be in an ipv6 world), so it might be as simple as that. It's a pain to test because it seems to overwrite the files every build. I'd need to spend more time. I'm also on a VM, FreeBSD 12 running on KVM/Qemu on my Linux box. I can maybe try on bare metal FreeBSD another time. Adding SSL out of the box is definitely something we should do though.
Comment 4 hartzell 2019-02-10 22:04:21 UTC
Let me know how I can help. I haven't tried it on a DO droplet, but it should work (famous last words...). If you like, I can give it a run there, or an AWS instance. Are you running an IPv6 system? Is there anything in your KVM setup that would prevent a loop-back style test from working (are all ports available by default?)? g.