|
From: Stephen S. <rad...@gm...> - 2014-02-06 21:58:51
|
On Thu, Feb 6, 2014 at 9:17 PM, Felipe Sateler <fsa...@gm...> wrote: > On Wed, Feb 5, 2014 at 1:02 PM, Felipe Sateler <fsa...@gm...> wrote: >> Note that there is also a chance that the host setup might affect >> builds (say, firewall rules). > > OK, I tested running testlo in a private network namespace (that is, > no internet access other than localhost) and the test fails gracefuly > (ie, it doesn't hang forever). > > I think it could be that a firewall is dropping packets, is it > possible that liblo waits forever for a message to appear? I'm not aware of anywhere off the top of my head where it should do that (I explicitly programmed some timeouts in some places to avoid that kind of thing), however it definitely sounds like a possible explanation. The complexities of testing networking software! I think it's reasonable to give some flags to testlo to make it avoid any tests that don't use localhost, or even be able to run only the non-sending/receiving code. (Exercise the validation/serialisation paths for example, without actually inducing any network activity.) This will take a bit of work however. Ideally, something I've thought for a very long time but procrastinated on heavily, is that testlo should be split up into smaller programs or at least more modular subroutines. >From a package manager point of view, is the best way to just provide some configure options to allow a condition where "make test" is "firewall-safe"..? Steve |