Re: [liblo] [ANN] liblo version 0.28 released

On Mon, Feb 10, 2014 at 5:56 PM, Felipe Sateler <fsa...@gm...> wrote:
> On Sun, Feb 9, 2014 at 12:44 PM, Stephen Sinclair <rad...@gm...> wrote:
>> Hello,
>>
>> I added a couple of patches to ignore errors from SO_REUSEPORT, and to
>> refactor testlo, and allow disabling of network-based tests using a
>> configure flag, --disable-network-tests
>>
>> I added a bunch of other flags while I was at it.
>> (--disable-examples, --disable-tools, etc)
>>
>> While working on testlo I did come across a couple of places that
>> might have stalled forever if messages got blocked by a firewall, so I
>> added timeouts to these places.
>
> Excellent. I picked the patches and uploaded disabling the network
> tests. Now liblo is building everywhere except sparc (intentional) and
> ia64 (no longer a release architecture, has old gcc) so far.

Great news.  Yeah I guess since the changes are strictly to testlo and
configure, and don't affect installed headers or the ABI, it should be
fine to just include it as a patch on the source package.  I guess I'd
rather see if any other issues crop up when it gets into Debian and
people start using it with real software, before stamping out a 0.29
just for this change.

On the other hand the "fix" for SO_REUSEPORT might be significant
enough to warrant it, if it truly is an issue on Linux.  It might be
worth adding an explicit configure flag to disable it if we can't come
up with a cleaner way to detect whether it is needed, or just enable
it explicitly for Darwin (via uname).

There seems to be little information out there available regarding
guidelines for SO_REUSEPORT in the context of multicast.

>>  I wish I knew how to reproduce the
>> network-restricted setup of the buildd machines though.
>
> Yes, unfortunately it seems to be difficult to reproduce.

Yeah.. still I'm pretty curious what aspect of the software changed,
since 0.26 was passing without issues. There have been a lot of
changes, including to TCP and multicast support, so it's hard to
guess.  The only sane approach would be to do a kind of "git bisect"
type of testing but this doesn't seem feasible with buildd.

Oh well, I think our solution makes sense anyways, given the network
restrictions on buildd.  It would be nice to add more tests to testlo
that exercise more code paths without triggering network system calls.
 But that might have to wait for a major cleanup/refactoring some time
in the future.

Steve