Lucas Nussbaum wrote: > On 01/03/10 at 23:00 +0100, Reto Buerki wrote: >> Is there a policy which defines the network setup and firewall rules for >> an official build host? If every host is different, we better disable >> the MIOP test because testing multicast functionality cannot work reliably. >> >> [1] - http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=568814 > > I don't think that there's any policy about that. A build that fail when > internet access is not available is usually a serious issue, because it might > make it impossible to rebuild the package from source in the future.
Yes this is obvious. A build cannot rely on network access. The CORBA/MIOP test case does not need either network or internet access though, because the kernel delivers the multicast traffic locally if there is an active subscriber for the multicast group used in the test case on one of the interfaces. The client part of the test joins the group in question on an interface chosen by the kernel so this condition is met. Nevertheless, the mcast sender must be allowed to send multicast traffic even though this traffic never reaches anyone besides the test client. This does not work if a firewall rule in the output path blocks these packets (resulting in an 'operation not permitted' error on the sending socket). > However, I don't know of any restrictions about the loopback network, > or sending broadcast or multicast packets. > > Are you sure that the sparc build fails because of that? If that's the > case, yes, it's probably a good idea to just drop that test. Xavier was not able to reproduce the failure with his own sparc hardware, so it's probably also network related or has something to do with the setup of this particular build host. > In other news, the package built fine on a similar system, but without > any firewall configuration. Thanks for testing! I will disable the CORBA/MIOP test in the next upload because running this test as part of the polyorb test suite does not work reliably on the various build hosts. - reto -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
