Bug#710696: libsoup2.4: FTBFS with test failures
Version: 2.56.0-2 On Tue, 27 Dec 2016, Simon McVittie wrote: > On Tue, 27 Dec 2016 at 12:22:03 +0100, Santiago Vila wrote: > > Cc:ing also Simon McVittie: I have not tested version 2.56.0-2 yet, > > sorry. Is it likely or possible that the changes in such version make > > the failing tests I experience to disappear, or are they unrelated? > > Looking at the first couple of failures, a segmentation fault in a > test whose name mentions "async" seems like it might be the bug fixed > in 2.56.0-2. That bug was a lack of thread safety, and GLib APIs like > libsoup frequently use a worker thread to make a blocking operation > asynchronous; in particular it was one of at least two root causes > for ostree's tests intermittently failing. I confirm that this bug seems fixed after building the package 100 times today and not getting any failure (the previous failure rate was about 30% or 40%). Therefore I'm closing this report. Thanks a lot.
Bug#710696: libsoup2.4: FTBFS with test failures
On Tue, 27 Dec 2016 at 12:22:03 +0100, Santiago Vila wrote: > Cc:ing the submitter, who also happen to be a Release Manager. > I wish we would not lower our standards to allow packages like > this one to FTBFS as much as they want as a normal thing. Speaking as a maintainer of a package whose tests intermittently fail (ostree), I'd love to have a standard way to get test results recorded, without partial/intermittent test failures being treated as RC or preventing testing migration. The bugs that cause the test failure would often not qualify to be RC if the tests weren't run at build time or weren't hooked up to autopkgtest, but many packages' tests can only be run at build time or have better coverage when run at that time. > Cc:ing also Simon McVittie: I have not tested version 2.56.0-2 yet, > sorry. Is it likely or possible that the changes in such version make > the failing tests I experience to disappear, or are they unrelated? Looking at the first couple of failures, a segmentation fault in a test whose name mentions "async" seems like it might be the bug fixed in 2.56.0-2. That bug was a lack of thread safety, and GLib APIs like libsoup frequently use a worker thread to make a blocking operation asynchronous; in particular it was one of at least two root causes for ostree's tests intermittently failing. ostree's tests are *still* intermittently failing (with a timeout, so probably a deadlock or something, which I haven't been able to fix), but I've made them non-fatal at build time because that isn't a regression. I don't know whether the timeout is libsoup's fault or ostree's fault (or something else). S
Bug#710696: libsoup2.4: FTBFS with test failures
On Tue, 2016-12-27 at 12:22 +0100, Santiago Vila wrote: > Cc:ing the submitter, who also happen to be a Release Manager. Slight nitpick, but "only" a Stable Release Manager these days. Regards, Adam
Bug#710696: libsoup2.4: FTBFS with test failures
On Sat, 1 Jun 2013, Adam D. Barratt wrote: > Source: libsoup2.4 > Version: 2.42.2-4 > Tags: jessie sid > Severity: serious > > Hi, > > libsoup2.4 FTBFS on several architectures with test failures; [...] Still the case three years later: FTBFS randomly with test failures. I've built this package one hundred times yesterday and it failed 32 times. I've put all logs here (both successful and failed ones) for everybody to see: https://people.debian.org/~sanvila/libsoup2.4/ The builds were all made on single-CPU virtual machines. Maybe this may affect the statistics, but in any case, having two CPUs is still not part of the build-essential definition. Not Cc:ing the maintainer, because he said he does not care anymore. Cc:ing the submitter, who also happen to be a Release Manager. I wish we would not lower our standards to allow packages like this one to FTBFS as much as they want as a normal thing. Would be possible to have this as both "serious" and "stretch-ignore" instead of "important"? Cc:ing also Simon McVittie: I have not tested version 2.56.0-2 yet, sorry. Is it likely or possible that the changes in such version make the failing tests I experience to disappear, or are they unrelated? Thanks.
Bug#710696: libsoup2.4: FTBFS with test failures
tags 710696 + patch thanks Hi, I can no longer reproduce the test failures in current sid on kfreebsd-amd64. (Except, two test failures that I would expect due to my jail/chroot configuration). Please consider re-enabling the testsuite on non-Linux platforms, before closing this bug. Thanks! Regards, -- Steven Chamberlain ste...@pyro.eu.org --- debian/rules.orig 2013-06-20 08:31:57.0 +0100 +++ debian/rules 2014-07-21 11:58:01.862422240 +0100 @@ -22,9 +22,7 @@ common-build-arch common-build-indep:: debian/stamp-makefile-check debian/stamp-makefile-check: debian/stamp-makefile-build mkdir -p $(CHECK_HOME) -ifeq ($(DEB_HOST_ARCH_OS),linux) env HOME=$(CHECK_HOME) XDG_RUNTIME_DIR=$(CHECK_HOME) xvfb-run -s -noreset $(MAKE) check -endif touch $@ makefile-clean::
Bug#710696: libsoup2.4: FTBFS with test failures
severity 710696 important thanks Temporarily downgraded the severity as I disabled the test suite on !linux as this was blocking many packages from migrating to testing. I plan on re-enabling the test suite again so let's keep this open. Any help on investigating it is welcome. On 16/06/13 01:17, Emilio Pozuelo Monfort wrote: > On 15/06/13 23:53, Emilio Pozuelo Monfort wrote: >> On 11/06/13 22:28, Steven Chamberlain wrote: >>> Sometimes it completes the whole testsuite, in which case it (always) >>> returns 2 errors instead: >>> External helper support >>> Round 2: NTLM Connection, user=alice (S:sent) (S:alice) /noauth-> REQUEST CHALLENGE NTLM_RESPONSE -> OK ERROR: Not using built-in NTLM support, but authenticate signal was emitted >>> Round 3: NTLM Connection, user=bob (S:sent) (S:bob) /noauth-> REQUEST CHALLENGE NTLM_RESPONSE -> OK ERROR: Not using built-in NTLM support, but authenticate signal was emitted >> >> These need further investigation. They may be a bug in libsoup, if something >> in >> libsoup is what is emitting the 'authenticate' signal. I can't take a closer >> look right now though. > > OK had a quick look, this is either a bug in the test or a bug in libsoup. Can > you paste the whole ntlm-test output? Any chance to look at that? Thanks, Emilio -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#710696: libsoup2.4: FTBFS with test failures
On 15/06/13 23:53, Emilio Pozuelo Monfort wrote: > On 11/06/13 22:28, Steven Chamberlain wrote: >> Sometimes it completes the whole testsuite, in which case it (always) >> returns 2 errors instead: >> >>> External helper support >> >>> Round 2: NTLM Connection, user=alice >>> (S:sent) (S:alice) /noauth-> REQUEST CHALLENGE NTLM_RESPONSE -> OK >>> ERROR: Not using built-in NTLM support, but authenticate signal was >>> emitted >> >>> Round 3: NTLM Connection, user=bob >>> (S:sent) (S:bob) /noauth-> REQUEST CHALLENGE NTLM_RESPONSE -> OK >>> ERROR: Not using built-in NTLM support, but authenticate signal was >>> emitted > > These need further investigation. They may be a bug in libsoup, if something > in > libsoup is what is emitting the 'authenticate' signal. I can't take a closer > look right now though. OK had a quick look, this is either a bug in the test or a bug in libsoup. Can you paste the whole ntlm-test output? Emilio -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#710696: libsoup2.4: FTBFS with test failures
Hi, Thanks for the info! On 11/06/13 22:28, Steven Chamberlain wrote: > Hi, > > On kfreebsd-* arches it is the lt-ntlm-test that doesn't finish and > causes the build process to hang. > > In the buildd logs its output is not shown, probably being buffered > somehow, but running it manually it gets stuck here: > >> External -> fallback support >> Round 1: Non-NTLM Connection, no auth >> (S:unauth) /noauth-> -> OK >> (S:unauth) /alice -> NTLM_PROMPT BASIC_PROMPT -> Unauthorized >> (S:unauth) /alice/404 -> NTLM_PROMPT BASIC_PROMPT -> Unauthorized >> (S:unauth) /alice -> NTLM_PROMPT BASIC_PROMPT -> Unauthorized >> (S:unauth) /bob -> NTLM_PROMPT BASIC_PROMPT -> Unauthorized >> (S:unauth) /alice -> NTLM_PROMPT BASIC_PROMPT -> Unauthorized >> (S:unauth) /basic -> BASIC_PROMPT -> Unauthorized >> (S:unauth) /either-> NTLM_PROMPT BASIC_PROMPT -> Unauthorized >> Round 2: NTLM Connection, user=alice >> (S:sent) (S:alice) /noauth-> REQUEST CHALLENGE NTLM_RESPONSE -> OK >> (S:alice) /alice -> -> OK >> (S:alice) /alice/404 -> -> Not Found >> (S:alice) /alice -> -> OK >> (S:alice) /bob -> NTLM_PROMPT BASIC_PROMPT -> Unauthorized >> (S:sent) (S:alice) /alice -> REQUEST CHALLENGE NTLM_RESPONSE -> OK >> (S:alice) (S:alice) /basic -> BASIC_PROMPT BASIC_RESPONSE -> OK >> (S:alice) /either-> -> OK >> Round 3: NTLM Connection, user=bob > > It isn't always repeatable, it's some kind of thread race condition. When that happens, attach to the running process with gdb and get a bt with (gdb) t a a bt To see where it deadlocked. > Sometimes it completes the whole testsuite, in which case it (always) > returns 2 errors instead: > >> External helper support > >> Round 2: NTLM Connection, user=alice >> (S:sent) (S:alice) /noauth-> REQUEST CHALLENGE NTLM_RESPONSE -> OK >> ERROR: Not using built-in NTLM support, but authenticate signal was emitted > >> Round 3: NTLM Connection, user=bob >> (S:sent) (S:bob) /noauth-> REQUEST CHALLENGE NTLM_RESPONSE -> OK >> ERROR: Not using built-in NTLM support, but authenticate signal was emitted These need further investigation. They may be a bug in libsoup, if something in libsoup is what is emitting the 'authenticate' signal. I can't take a closer look right now though. Cheers, Emilio -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#710696: libsoup2.4: FTBFS with test failures
Hi, On kfreebsd-* arches it is the lt-ntlm-test that doesn't finish and causes the build process to hang. In the buildd logs its output is not shown, probably being buffered somehow, but running it manually it gets stuck here: > External -> fallback support > Round 1: Non-NTLM Connection, no auth > (S:unauth) /noauth-> -> OK > (S:unauth) /alice -> NTLM_PROMPT BASIC_PROMPT -> Unauthorized > (S:unauth) /alice/404 -> NTLM_PROMPT BASIC_PROMPT -> Unauthorized > (S:unauth) /alice -> NTLM_PROMPT BASIC_PROMPT -> Unauthorized > (S:unauth) /bob -> NTLM_PROMPT BASIC_PROMPT -> Unauthorized > (S:unauth) /alice -> NTLM_PROMPT BASIC_PROMPT -> Unauthorized > (S:unauth) /basic -> BASIC_PROMPT -> Unauthorized > (S:unauth) /either-> NTLM_PROMPT BASIC_PROMPT -> Unauthorized > Round 2: NTLM Connection, user=alice > (S:sent) (S:alice) /noauth-> REQUEST CHALLENGE NTLM_RESPONSE -> OK > (S:alice) /alice -> -> OK > (S:alice) /alice/404 -> -> Not Found > (S:alice) /alice -> -> OK > (S:alice) /bob -> NTLM_PROMPT BASIC_PROMPT -> Unauthorized > (S:sent) (S:alice) /alice -> REQUEST CHALLENGE NTLM_RESPONSE -> OK > (S:alice) (S:alice) /basic -> BASIC_PROMPT BASIC_RESPONSE -> OK > (S:alice) /either-> -> OK > Round 3: NTLM Connection, user=bob It isn't always repeatable, it's some kind of thread race condition. Sometimes it completes the whole testsuite, in which case it (always) returns 2 errors instead: > External helper support > Round 2: NTLM Connection, user=alice > (S:sent) (S:alice) /noauth-> REQUEST CHALLENGE NTLM_RESPONSE -> OK > ERROR: Not using built-in NTLM support, but authenticate signal was emitted > Round 3: NTLM Connection, user=bob > (S:sent) (S:bob) /noauth-> REQUEST CHALLENGE NTLM_RESPONSE -> OK > ERROR: Not using built-in NTLM support, but authenticate signal was emitted Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#710696: libsoup2.4: FTBFS with test failures
Emilio Pozuelo Monfort dixit: >I see timeout-test is failing there as well. That shouldn't be because the arch >is slow. There's probably a bug somewhere, maybe libsoup, that only manifests >in >sparc and m68k. See https://bugzilla.gnome.org/show_bug.cgi?id=660581 Ah okay. >I just tried today to debug it in sparc but there's no valgrind there and I >didn't get very far. Can you have a look at it and see if you figure what's >going on? Hm, I think valgrind isn’t ported to most platforms, but considering what it does… I see it says something about SSL handshakes. Does it use (non)gnutls for that? If so, there’s a known issue about that on m68k; basically, the handshake easily takes a minute or more in production (less if you don’t use the full ca-certificates list, but not much); upstream doesn’t seem to have any ideas, and the maintainers defer to upstream: http://thread.gmane.org/gmane.linux.debian.ports.68k/10653/focus=10757 Otherwise… I’ve never even *heard* of libsoup until I tried to break the Gtk-related circular-B-D cycles, last year, so I am afraid I’d not even know where to *begin* looking at it… bye, //mirabilos -- "Using Lynx is like wearing a really good pair of shades: cuts out the glare and harmful UV (ultra-vanity), and you feel so-o-o COOL." -- Henry Nelson, March 1999 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#710696: libsoup2.4: FTBFS with test failures
On 07/06/13 22:48, Thorsten Glaser wrote: > Hi, > > it also fails the testsuite on m68k, but only with timeouts > due to the slowness of the architecture I think. > > Please have a look at the build logs here too: > http://buildd.debian-ports.org/status/package.php?p=libsoup2.4 > > I’d be glad if you could just disable the two offending > tests on m68k. I see timeout-test is failing there as well. That shouldn't be because the arch is slow. There's probably a bug somewhere, maybe libsoup, that only manifests in sparc and m68k. See https://bugzilla.gnome.org/show_bug.cgi?id=660581 I just tried today to debug it in sparc but there's no valgrind there and I didn't get very far. Can you have a look at it and see if you figure what's going on? Emilio -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#710696: libsoup2.4: FTBFS with test failures
Hi, it also fails the testsuite on m68k, but only with timeouts due to the slowness of the architecture I think. Please have a look at the build logs here too: http://buildd.debian-ports.org/status/package.php?p=libsoup2.4 I’d be glad if you could just disable the two offending tests on m68k. Thanks in advance, //mirabilos -- 17:08⎜«Vutral» früher gabs keine packenden smartphones und so 17:08⎜«Vutral» heute gibts frauen die sind facebooksüchtig 17:10⎜«Vutral» aber auch traurig; früher warst du als nerd voll am arsch 17:10⎜«Vutral» heute bist du als nerd der einzige der wirklich damit klarkommt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#710696: libsoup2.4: FTBFS with test failures
Source: libsoup2.4 Version: 2.42.2-4 Tags: jessie sid Severity: serious Hi, libsoup2.4 FTBFS on several architectures with test failures; from the armel build log: soup_uri_new (NULL) Got expected warning: soup_uri_new_with_base: assertion `base == NULL || SOUP_URI_IS_VALID (base)' failed Got expected warning: (soup-uri.c:500):soup_uri_to_string_internal: runtime check failed: (SOUP_URI_IS_VALID (uri)) Got expected warning: (soup-uri.c:500):soup_uri_to_string_internal: runtime check failed: (SOUP_URI_IS_VALID (uri)) Got expected warning: (soup-uri.c:500):soup_uri_to_string_internal: runtime check failed: (SOUP_URI_IS_VALID (uri)) Got expected warning: (soup-uri.c:221):soup_uri_new_with_base: runtime check failed: (SOUP_URI_IS_VALID (base)) Got expected warning: (soup-uri.c:1099):soup_uri_set_path: runtime check failed: (path != NULL) [...] 1 of 25 tests failed (6 tests were not run) Please report to http://bugzilla.gnome.org/enter_bug.cgi?product=libsoup make[4]: *** [check-TESTS] Error 1 make[4]: Leaving directory `/«PKGBUILDDIR»/tests' make[3]: *** [check-am] Error 2 make[3]: Leaving directory `/«PKGBUILDDIR»/tests' make[2]: *** [check] Error 2 make[2]: Leaving directory `/«PKGBUILDDIR»/tests' make[1]: *** [check-recursive] Error 1 make[1]: Leaving directory `/«PKGBUILDDIR»' make: *** [debian/stamp-makefile-check] Error 2 dpkg-buildpackage: error: debian/rules build-arch gave error exit status 2 Full logs available via https://buildd.debian.org/status/package.php?p=libsoup2.4 Regards, Adam -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
