This is information I could look up, but would take time, so let's see if you already have the answers 😉 Does this fail 100% of the time now, and since when? Or when did it become flaky? We noticed on our servers, that when we moved the VMs to run on different physical machines in different facilities, the ETH0 became ETH1, despite being the same VM. They are still in the same vsphere and all, but for some reason that changed. It could be that this happened to the VMs running the builds and tests as well, but I would imagine this happening then 100% of the time, and everything would have been blocked since we moved. And that we would have noticed here. Odd..
-Tony -----Original Message----- From: Development [mailto:[email protected]] On Behalf Of Thiago Macieira Sent: lauantai 17. kesäkuuta 2017 0.21 To: [email protected] Subject: Re: [Development] What changed in the RHEL 6.6 machines that cause tst_QUdpSocket::linkLocalIPv6 to fail? On Friday, 16 June 2017 13:23:07 PDT Thiago Macieira wrote: > QDEBUG : tst_QUdpSocket::linkLocalIPv6(WithoutProxy) > QHostAddress("fe80::250:56ff:feab:4818%eth1") > FAIL! : tst_QUdpSocket::linkLocalIPv6(WithoutProxy) > '(neutralReadSpy.count() > > 0)' returned FALSE. () > > Loc: [../tst_qudpsocket.cpp(1600)] Emergency workaround: https://codereview.qt-project.org/197753 (compiles and works for me on bare metal, no test on a VM) This commit basically disables the test entirely on virtual machines. If any QtNetwork developers use virtual machines, please make sure you get bare-metal hardware for all three platforms. You won't be doing your job if you continue with VMs. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
