Bug 1078834

Summary: FTBFS: openSUSE:Factory/gloox fails to build
Product: [openSUSE] openSUSE Tumbleweed Reporter: Dominique Leuenberger <dimstar>
Component: OtherAssignee: Philip Taylor <excors>
Status: RESOLVED FIXED QA Contact: E-mail List <qa-bugs>
Severity: Normal    
Priority: P5 - None CC: dap.darkness, dimstar, elexis1987, na.itms76, opensuse, pascal.bleser, prusnak, rpm, vcizek, werner
Version: Current   
Target Milestone: ---   
Hardware: Other   
OS: Other   
Whiteboard:
Found By: --- Services Priority:
Business Priority: Blocker: ---
Marketing QA Status: --- IT Deployment: ---

Description Dominique Leuenberger 2018-02-01 16:57:02 UTC
The package gloox fails to build in openSUSE:Factory. Earlier notifications by email to the bugowner and Maintainer have remained without reaction / fix. If the package is not being fixed within 2 weeks, it will be scheduled for removal from Tumbleweed
Comment 1 Dominique Leuenberger 2018-02-12 12:29:19 UTC
Assigning to philiptaylor

Pascal is no longer active in the openSUSE community and will only unlikely be providing a fix for gloox.

Philip otoh is active and is the maintainer of 0ad, the only package inside the distribution making use of gloox (so a removal of gloox would imply a removal of 0ad - and thus I think there might be some interest in finding a fix)
Comment 2 Alexander Heinsius 2018-02-12 17:26:07 UTC
Hello there.

I'm one of Wildfire Games developers and we haven't heard about this problem until today. Philip has been retired since some years.

Most of us follow newly created bugreports at http://trac.wildfiregames.com/ and certainly we pay attention to those reports on the milestone of the next release. :-)

Some further information like the failed build output would speed up the debugging, but I guess we can reproduce in a VM too.
Comment 3 Dominique Leuenberger 2018-02-12 17:35:38 UTC
Hi ALexander,

Thanks for looking into the case
An up-to-date build log can be found at

https://build.opensuse.org/package/live_build_log/openSUSE:Factory/gloox/standard/x86_64

It's failing in one of the test suites

[  291s] Tag: OK
[  291s] GnuTLS error: Error decoding the received TLS packet.
[  291s] test 'anon client/server handshake test' failed
[29099s] qemu-system-x86_64: terminating on signal 15 from pid 1795 (<unknown process>)


>I'm one of Wildfire Games developers and we haven't heard about this problem >until today. Philip has been retired since some years.

that's sad to hear - do you know who will be taking care of the openSUSE packages in this case? So far, Philip was assigned bugowner for 0ad (and I gave this gloox bug to him, as 0ad is the only consumer of it)
Comment 4 Nicolas Auvray 2018-02-12 18:53:00 UTC
Hello, I am the project leader of 0 A.D. and I usually take care of pinging the packagers upon new releases (so far I didn't have a contact for OpenSuse though). You can safely contact me in case of issues like this one, but I cannot take care of packages myself, and I do not think we have anybody in the development team who uses OpenSuse.

We can announce on our forums that you are looking for a new package maintainer, if that helps. Please let me know when somebody is designated.

In the meantime I am taking a closer look at the gloox issue. Is the "two weeks from 2018-02-01" a hard deadline?
Comment 5 Nicolas Auvray 2018-02-12 22:06:07 UTC
I can reproduce the failure. I am also seeing this error in the build logs of other distributions, like Debian [1]. The failing test is a handshake performed with the gnutls library; the next test hangs indefinitely.

I see two workarounds: (a) patching the gloox test suite so that all gnutls tests are ignored after the first one fails (b) not using gnutls and replacing the libgnutls-devel dependency by libopenssl-devel. I can write (a) if desired; (b) seems to work locally but there doesn't seem to be anything in the gloox test suite that tests the openssl bindings, so maybe TLS support is broken when doing that. It should be easy to test whether 0ad built with gloox built with openssl works correctly, I can also test that.

Let me know what would be the preferred fix on your end (patching or changing the deps) and as long as 0ad works and stays in Tumbleweed, we will be happy. :-)

[1] https://buildd.debian.org/status/fetch.php?pkg=gloox&arch=amd64&ver=1.0.18-1&stamp=1478848773&raw=0
Comment 6 Dominique Leuenberger 2018-02-12 22:47:33 UTC
(In reply to Nicolas Auvray from comment #4)
> In the meantime I am taking a closer look at the gloox issue. Is the "two
> weeks from 2018-02-01" a hard deadline?

No, the two weeks is a safety net in case nobody even gets back to us with at least an intent to work on things. If more time is needed, I will certainly offer that (and help, where possible)

(In reply to Nicolas Auvray from comment #5)
> I see two workarounds: (a) patching the gloox test suite so that all gnutls
> tests are ignored after the first one fails (b) not using gnutls and
> replacing the libgnutls-devel dependency by libopenssl-devel. I can write
> (a) if desired; (b) seems to work locally but there doesn't seem to be
> anything in the gloox test suite that tests the openssl bindings, so maybe
> TLS support is broken when doing that. It should be easy to test whether 0ad
> built with gloox built with openssl works correctly, I can also test that.

a( suunds a bit scary - just skipping the test suite in worst case just means we move the problem to the users, who are then facing hangs in their apps. 

b) sounds good; keep in mind that 'openssl-devel' is openssl 1.1; I'm not sure if gloox is 'ready' for that (or if there are even plans toi move oit); not testing it of course just means we are as good as with option a and just hope for the best.

The "best thing"™ would be a fix of either the test suite (in case the test code is broken) or a report about a broken, underlying library

With 0ad benig the only consumer, it basically boils down to what you think makes 0ad most reliably workable to the users~ this is the top-most important argument
Comment 7 Dominique Leuenberger 2018-02-13 11:40:27 UTC
I think I can offer some more information as to what contributes to the stall:

trying to build gloox against a gnutls reverted to version 3.5.15 seems to work; this implies that we are falling victim of the upgrade to gnutls 3.6 here

Let's CC also the gnutls maintainer, who might have some insights here
@Viteslav: the issue at hand is 'gloox' test suite is stalling when built against gnutls 3.6, but worked fine against gnutls 3.5.15 (I have a TW branch with gnutls downgraded to 3.5.15, and gloox builds fine there)

Your extra pair of eyes on the gloox/gnutls test suite would be appreciated
Comment 8 Nicolas Auvray 2018-02-13 13:18:24 UTC
(In reply to Dominique Leuenberger from comment #7)
> trying to build gloox against a gnutls reverted to version 3.5.15 seems to
> work; this implies that we are falling victim of the upgrade to gnutls 3.6
> here

Ah, that is very interesting. I had started contacting the author of gloox for more information about the failing test (their bugtracker and code repository are redirecting to some strange website ATM, which is a bit worrying) and now I will have a more precise idea of the issue that we are facing.

(In reply to Dominique Leuenberger from comment #6)
> b) sounds good; keep in mind that 'openssl-devel' is openssl 1.1; I'm not
> sure if gloox is 'ready' for that (or if there are even plans toi move oit);
> not testing it of course just means we are as good as with option a and just
> hope for the best.

Let's keep plan b) as a fallback in case we are blocked on the gnutls front. I should be able to write a copycat of the gloox test for openssl, to be sure. The gloox author claims to support openssl "1.0.2 or above" so there is no explicit statement that 1.1.x is unsupported.
Comment 9 Vítězslav Čížek 2018-02-13 22:25:48 UTC
The handshake was failing in the tlsgnutls test.
The client sent an empty cipher suite list and the server then aborted the handshake.

Because nothing was ever decrypted, the test then got stuck in an infinite loop at:
183   while( m_clientDecrypted.empty() )
184     loop();

tlsgnutls tests TLS connection with an anonymous DH key exchange, which resulted in an empty client cipher suite.
The default priority string likely changed in gnutls 3.6.0, because ANON key exchange algorithms have to be requested explicitly now.
Adding ANON_DH to the priority string in gloox's GnuTLS*Anon classes makes the test work again.

I've submitted request https://build.opensuse.org/request/show/576407 with the fix.
Comment 10 Nicolas Auvray 2018-02-14 10:44:54 UTC
Thank you very much for the fix! Let's hope the gloox bugtracker gets back online so that patch can be sent upstream.
Comment 11 Vítězslav Čížek 2018-02-14 11:01:54 UTC
I did try to send it upstream, but the bug tracker is still offline, as well as the mailing list page.
So I ended up emailing the patch directly to Jakob Schröter who's listed at the among the contacts.
I mentioned the website problems as well.
Yeah, let's hope it'll get fixed soon.
Comment 12 Alexander Heinsius 2018-08-24 12:05:40 UTC
Reported the gloox test failure and patch at https://bugs.camaya.net/ticket/?id=279