Bug 235468 - audio/logitechmediaserver: build IO::Socket::SSL so plugins work (e.g. RadioParadise)
Summary: audio/logitechmediaserver: build IO::Socket::SSL so plugins work (e.g. RadioP...
Status: New
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: amd64 Any
: --- Affects Some People
Assignee: freebsd-ports-bugs mailing list
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-02-03 19:44 UTC by hartzell
Modified: 2019-02-10 22:04 UTC (History)
1 user (show)

See Also:
bugzilla: maintainer-feedback? (mark)


Attachments
diff enabling IO::Socket::SSL and updating pkg-plist file (10.57 KB, patch)
2019-02-03 19:44 UTC, hartzell
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
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[2]: *** [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.