On 01/03/10 at 23:00 +0100, Reto Buerki wrote: > Lucas Nussbaum wrote: > > On 28/02/10 at 14:02 +0100, Reto Buerki wrote: > >> The relevant part of the build log is: > >> > >>>> ///////////// Begin of Scenario CORBA_MIOP > >>>> > >>>> Scenario CORBA_MIOP > >>>> Description: CORBA/MIOP test > >>>> Starting scenario CORBA_MIOP > >>>> > >>>> -- Begin of Test CORBA_MIOP_0 > >>>> > >>>> Read : test CORBA_MIOP_0 > >>>> Id : Simple test > >>>> Type : client_server > >>>> Exec_In_Base_Dir :FALSE > >>>> Timeout : (default) 100000 > >>>> > >>>> Launching test: Simple test > >>>> > >>>> Setting environment: > >>>> /build/user-polyorb_2.6.0~20090423-5-amd64-ViNnul/polyorb-2.6.0~20090423/testsuite/scenarios/polyorb_conf/miop.conf > >>>> Running: ./../examples/corba/send/listener > >>>> > >>>> Group length : 3 > >>>> Objects in group : > >>>> 1 - RootGOA/000000011Tfa42d42011957539 > >>>> 2 - RootGOA/000000012Tfa42d42011957539 > >>>> 3 - RootGOA/000000013Tfa42d42011957539 > >>>> > >>>> IOR of the test controller > >>>> 'IOR:010000001800000049444c3a546573742f436f6e74726f6c6c65723a312e300002000000000000005c000000010102000a0000003132372e302e302e3100cab41b0000002f30303030303030313454666134326434323031313935373533390001000000010000001c0000000100000001000100000000000001010002000000010101000201010003004f503c000000010100000d0000003137322e32382e35342e33380000ae941b0000002f30303030303030313454666134326434323031313935373533390000000000' > >>>> Setting environment: > >>>> /build/user-polyorb_2.6.0~20090423-5-amd64-ViNnul/polyorb-2.6.0~20090423/testsuite/scenarios/polyorb_conf/miop.conf > >>>> Running: ./../examples/corba/send/send > >>>> > >>>> > >>>> ==> Begin test CORBA/MIOP <== > >>>> polyorb.transport.datagram.sockets_out: send failed: Exception name: > >>>> GNAT.SOCKETS.SOCKET_ERROR > >>>> Message: [1] Operation not permitted > >>>> > >>>> > >>>> raised SYSTEM.ASSERTIONS.ASSERT_FAILURE : polyorb-components.adb:118 > >>>> ==> Process terminated abnormally <== > >>>> > >>>> ----------------------------- > >>>> > >>>> FAILED: 0 out of 1 tests passed, with 0 expected failed tests > >>>> Scenario CORBA_MIOP.........................................: FAILED > >> The "Operation not permitted" error indicates a firewall rule which is > >> blocking the multicast traffic to the mcast group used in this test > >> scenario (239.239.239.18). > >> > >> I can reproduce the test failure by inserting the following rule on my > >> system: > >> > >> ~$ sudo iptables -I OUTPUT --dst 239.239.239.18 -j DROP > >> > >> What is the firewall policy for build hosts? As it seems firewall rules > >> are not identical since this test passes on other build hosts without > >> problems. > >> > >> Is there a multicast group we could use which is allowed on all build > >> hosts for test purposes? The other solution would be to disable the > >> CORBA_MIOP test ... > >> > >> Note: This test *does not* need network/internet access. > > > > Those rebuild tests are not executed on the official buildd network. And > > you might very well have found a misconfiguration in my setup. > > The problem is that the CORBA/MIOP test also fails on some official > build hosts [1]. > > > Do you think that it would be enough to allow outgoing multicast with: > > iptables -A OUTPUT -p udp --dst 224.0.0.0/4 -j ACCEPT > > ? > > This depends on your current rule set. If outgoing multicast traffic is > dropped, this rule would most probably fix our test case. Can you easily > run a polyorb build with this rule active? > > 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. 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. In other news, the package built fine on a similar system, but without any firewall configuration. -- | Lucas Nussbaum | lu...@lucas-nussbaum.net http://www.lucas-nussbaum.net/ | | jabber: lu...@nussbaum.fr GPG: 1024D/023B3F4F | -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
