GNU bug report logs - #28616
disable failing bluez test

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 28616 in the body.
You can then email your comments to 28616 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Thomas Danckaert <post <at> thomasdanckaert.be>
To: guix-patches <at> gnu.org
Subject: disable failing bluez test
Date: Wed, 27 Sep 2017 09:21:05 +0200 (CEST)

[Message part 1 (text/plain, inline)]

A test for the bluez package that previously failed only (?) on ARM, 
now seems to fail more widely.

It seems the same problem was discussed on the linux-bluetooth 
mailing list here. https://marc.info/?t=149578476300002&r=1&w=2  
Apparently the test fails when no network is available.

I suggest to disable the test for now...

Thomas

[0001-gnu-bluez-Mark-segfaulting-test-with-XFAIL.patch (text/x-patch, inline)]

From 6a1a2c0e437552109be72ff257fbd9ae410774c1 Mon Sep 17 00:00:00 2001
From: Thomas Danckaert <post <at> thomasdanckaert.be>
Date: Wed, 27 Sep 2017 09:14:02 +0200
Subject: [PATCH] gnu: bluez: Mark segfaulting test with XFAIL.

 * gnu/packages/linux.scm (bluez): [arguments] Mark test-gatt with XFAIL.
---
 gnu/packages/linux.scm | 7 +++----
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/gnu/packages/linux.scm b/gnu/packages/linux.scm
index 2a3a40801..a50e465f1 100644
--- a/gnu/packages/linux.scm
+++ b/gnu/packages/linux.scm
@@ -3090,10 +3090,9 @@ Bluetooth audio output devices like headphones or loudspeakers.")
                   (string-append (assoc-ref inputs "eudev") "/bin/udevadm")))
                #t))))
 
-       ;; FIXME: Skip one test that segfaults on ARM.
-       ,@(if (string=? (%current-system) "armhf-linux")
-             '(#:make-flags '("XFAIL_TESTS=unit/test-gatt"))
-             '())))
+       ;; FIXME: Skip one test that segfaults.
+       #:make-flags '("XFAIL_TESTS=unit/test-gatt")))
+
     (native-inputs
      `(("pkg-config" ,pkg-config)
        ("gettext" ,gettext-minimal)))
-- 
2.14.1

Message #8 received at 28616 <at> debbugs.gnu.org (full text, mbox):

From: Marius Bakke <mbakke <at> fastmail.com>
To: Thomas Danckaert <post <at> thomasdanckaert.be>, 28616 <at> debbugs.gnu.org
Subject: Re: [bug#28616] disable failing bluez test
Date: Wed, 27 Sep 2017 21:30:13 +0200

[Message part 1 (text/plain, inline)]

Thomas Danckaert <post <at> thomasdanckaert.be> writes:

> A test for the bluez package that previously failed only (?) on ARM, 
> now seems to fail more widely.
>
> It seems the same problem was discussed on the linux-bluetooth 
> mailing list here. https://marc.info/?t=149578476300002&r=1&w=2  
> Apparently the test fails when no network is available.
>
> I suggest to disable the test for now...

I can not reproduce this on GuixSD.

--8<---------------cut here---------------start------------->8---
PASS: unit/test-gobex-transfer                                                                                                                                                                         
PASS: unit/test-avrcp                                                                                                                                                                                    CCLD     unit/test-gatt                                                                          
PASS: unit/test-gatt                                                                                                                                                                                   
make --no-print-directory all-am                 
============================================================================                       
Testsuite summary for bluez 5.47                 
============================================================================
# TOTAL: 25                                                                                        
# PASS:  25 
--8<---------------cut here---------------end--------------->8---

Network is not available in the build container, so I wonder what's
going on here.

[signature.asc (application/pgp-signature, inline)]

Message #11 received at 28616 <at> debbugs.gnu.org (full text, mbox):

From: Thomas Danckaert <post <at> thomasdanckaert.be>
To: mbakke <at> fastmail.com
Cc: 28616 <at> debbugs.gnu.org
Subject: Re: [bug#28616] disable failing bluez test
Date: Wed, 27 Sep 2017 22:59:11 +0200 (CEST)

From: Marius Bakke <mbakke <at> fastmail.com>
Subject: Re: [bug#28616] disable failing bluez test
Date: Wed, 27 Sep 2017 21:30:13 +0200

> Thomas Danckaert <post <at> thomasdanckaert.be> writes:
>
>> A test for the bluez package that previously failed only (?) on 
>> ARM,
>> now seems to fail more widely.
>>
>> It seems the same problem was discussed on the linux-bluetooth
>> mailing list here. https://marc.info/?t=149578476300002&r=1&w=2
>> Apparently the test fails when no network is available.
>>
>> I suggest to disable the test for now...
>
> I can not reproduce this on GuixSD.
>
> [...]
>
> Network is not available in the build container, so I wonder what's
> going on here.

Hmm, I now also get a substitute...  Earlier I didn't get a 
substitute and the build failed on my system, so I assumed the error 
was general (but couldn't check the build status on hydra due to the 
web frontend's unresponsiveness -- now it's available again).

I'll try to build it again a few times and will close this if i find 
no more issues (or move the issue to guix bugs).  Now it's getting 
late (and I'm getting a hash mismatch for the pcre source from 
sourceforge while trying to build bluez from source...  I'm not going 
down this rabbit hole tonight :-) ).

Thomas

Message #14 received at 28616 <at> debbugs.gnu.org (full text, mbox):

From: Thomas Danckaert <post <at> thomasdanckaert.be>
To: mbakke <at> fastmail.com
Cc: 28616 <at> debbugs.gnu.org
Subject: Re: [bug#28616] disable failing bluez test
Date: Thu, 28 Sep 2017 08:42:25 +0200 (CEST)

From: Thomas Danckaert <post <at> thomasdanckaert.be>
Subject: Re: [bug#28616] disable failing bluez test
Date: Wed, 27 Sep 2017 22:59:11 +0200 (CEST)

>> Thomas Danckaert <post <at> thomasdanckaert.be> writes:
>>
>>> A test for the bluez package that previously failed only (?) on
>>> ARM,
>>> now seems to fail more widely.
>>>
>>> It seems the same problem was discussed on the linux-bluetooth
>>> mailing list here. https://marc.info/?t=149578476300002&r=1&w=2
>>> Apparently the test fails when no network is available.
>>>
>>> I suggest to disable the test for now...
>>
>> I can not reproduce this on GuixSD.
>>
>> [...]
>>
>> Network is not available in the build container, so I wonder
>> what's
>> going on here.
>
> Hmm, I now also get a substitute...  Earlier I didn't get a
> substitute and the build failed on my system, so I assumed the error
> was general (but couldn't check the build status on hydra due to the
> web frontend's unresponsiveness -- now it's available again).

The reason I didn't get a substitute earlier, was that I had other 
patches on that branch that triggered a rebuild.

Now I checked properly, and the test still fails on this laptop.  
From the thread I linked, I understand it's also a timing/time-out 
issue, so perhaps the performance of the build host plays a role.

Thomas

Message #17 received at 28616 <at> debbugs.gnu.org (full text, mbox):

From: Thomas Danckaert <post <at> thomasdanckaert.be>
To: mbakke <at> fastmail.com
Cc: 28616 <at> debbugs.gnu.org
Subject: Re: [bug#28616] disable failing bluez test
Date: Sun, 01 Oct 2017 12:02:26 +0200

Thomas Danckaert <post <at> thomasdanckaert.be> writes:

> Now I checked properly, and the test still fails on this laptop.  From
> the thread I linked, I understand it's also a timing/time-out issue,
> so perhaps the performance of the build host plays a role.

On another (faster) machine, I also manage to build bluez.  As the issue
doesn't seem to affect many people (most use substitutes anyway), maybe
we can keep the package as it this for now, and hope upstream improves
the situation at some point (it's been reported, after all).

Thomas

Message #20 received at 28616 <at> debbugs.gnu.org (full text, mbox):

From: Marius Bakke <mbakke <at> fastmail.com>
To: Thomas Danckaert <post <at> thomasdanckaert.be>
Cc: 28616 <at> debbugs.gnu.org
Subject: Re: [bug#28616] disable failing bluez test
Date: Tue, 03 Oct 2017 23:50:56 +0200

[Message part 1 (text/plain, inline)]

Thomas Danckaert <post <at> thomasdanckaert.be> writes:

> Thomas Danckaert <post <at> thomasdanckaert.be> writes:
>
>> Now I checked properly, and the test still fails on this laptop.  From
>> the thread I linked, I understand it's also a timing/time-out issue,
>> so perhaps the performance of the build host plays a role.
>
> On another (faster) machine, I also manage to build bluez.  As the issue
> doesn't seem to affect many people (most use substitutes anyway), maybe
> we can keep the package as it this for now, and hope upstream improves
> the situation at some point (it's been reported, after all).

I think we should apply the patch regardless (on 'core-updates'), with a
link to the upstream discussion.  IMO it's more important to be able to
build from source regardless of hardware, than running this one unit
test.  What do you think?

[signature.asc (application/pgp-signature, inline)]

Message #23 received at 28616 <at> debbugs.gnu.org (full text, mbox):

From: Thomas Danckaert <post <at> thomasdanckaert.be>
To: mbakke <at> fastmail.com
Cc: 28616 <at> debbugs.gnu.org
Subject: Re: [bug#28616] disable failing bluez test
Date: Wed, 04 Oct 2017 20:04:54 +0200 (CEST)

From: Marius Bakke <mbakke <at> fastmail.com>
Subject: Re: [bug#28616] disable failing bluez test
Date: Tue, 03 Oct 2017 23:50:56 +0200

> I think we should apply the patch regardless (on 'core-updates'), with a
> link to the upstream discussion.  IMO it's more important to be able to
> build from source regardless of hardware, than running this one unit
> test.  What do you think?

I agree.

I'll push this to core-updates then.

Thomas

Message #28 received at 28616-done <at> debbugs.gnu.org (full text, mbox):

From: Thomas Danckaert <post <at> thomasdanckaert.be>
To: mbakke <at> fastmail.com, 28616-done <at> debbugs.gnu.org
Subject: Re: [bug#28616] disable failing bluez test
Date: Sat, 07 Oct 2017 21:53:32 +0200 (CEST)

From: Marius Bakke <mbakke <at> fastmail.com>
Subject: Re: [bug#28616] disable failing bluez test
Date: Tue, 03 Oct 2017 23:50:56 +0200

> I think we should apply the patch regardless (on 'core-updates'), with a
> link to the upstream discussion.  IMO it's more important to be able to
> build from source regardless of hardware, than running this one unit
> test.  What do you think?

done!

Thomas

Message #31 received at 28616 <at> debbugs.gnu.org (full text, mbox):

From: Marius Bakke <mbakke <at> fastmail.com>
To: Thomas Danckaert <post <at> thomasdanckaert.be>
Cc: 28616 <at> debbugs.gnu.org
Subject: Re: [bug#28616] disable failing bluez test
Date: Tue, 10 Oct 2017 23:40:39 +0200

[Message part 1 (text/plain, inline)]

Thomas Danckaert <post <at> thomasdanckaert.be> writes:

> From: Marius Bakke <mbakke <at> fastmail.com>
> Subject: Re: [bug#28616] disable failing bluez test
> Date: Tue, 03 Oct 2017 23:50:56 +0200
>
>> I think we should apply the patch regardless (on 'core-updates'), with a
>> link to the upstream discussion.  IMO it's more important to be able to
>> build from source regardless of hardware, than running this one unit
>> test.  What do you think?
>
> I agree.
>
> I'll push this to core-updates then.

On second thought, "bluez" is currently failing on armhf, seemingly due
to the original patch: <https://hydra.gnu.org/build/2304811/nixlog/4/raw>

Excerpt:

--8<---------------cut here---------------start------------->8---
  CCLD     unit/test-gatt
XPASS: unit/test-gatt
make --no-print-directory all-am
============================================================================
Testsuite summary for bluez 5.47
============================================================================
# TOTAL: 25
# PASS:  24
# SKIP:  0
# XFAIL: 0
# FAIL:  0
# XPASS: 1
# ERROR: 0
============================================================================
See ./test-suite.log
============================================================================
make[3]: *** [Makefile:8597: test-suite.log] Error 1
make[2]: *** [Makefile:8705: check-TESTS] Error 2
make[1]: *** [Makefile:9089: check-am] Error 2
make: *** [Makefile:9091: check] Error 2
phase `check' failed after 331.2 seconds
--8<---------------cut here---------------end--------------->8---

XPASS is "unexpected pass" according to
<https://www.gnu.org/software/automake/manual/html_node/Generalities-about-Testing.html>.

I found the autotools documentation sparse on this, how do we make it
skip this test instead of expecting a failure?

[signature.asc (application/pgp-signature, inline)]

Message #34 received at 28616 <at> debbugs.gnu.org (full text, mbox):

From: Thomas Danckaert <post <at> thomasdanckaert.be>
To: mbakke <at> fastmail.com
Cc: 28616 <at> debbugs.gnu.org
Subject: Re: [bug#28616] disable failing bluez test
Date: Wed, 11 Oct 2017 08:52:12 +0200 (CEST)

From: Marius Bakke <mbakke <at> fastmail.com>
Subject: Re: [bug#28616] disable failing bluez test
Date: Tue, 10 Oct 2017 23:40:39 +0200

>> I agree.
>>
>> I'll push this to core-updates then.
>
> On second thought, "bluez" is currently failing on armhf, seemingly 
> due
> to the original patch: 
> <https://hydra.gnu.org/build/2304811/nixlog/4/raw>
>
> [...]
>
> I found the autotools documentation sparse on this, how do we make 
> it
> skip this test instead of expecting a failure?

How annoying :-)  I couldn't find a way either.  What we can do is 
pass all 24 other tests as a make TESTS="..." flag..., or modify the 
'test-gatt' file itself so it returns '77', which is SKIP (we could 
use substitute* to insert a “return 77;” in main()).  Neither is very 
elegant...

Thomas

Message #37 received at 28616 <at> debbugs.gnu.org (full text, mbox):

From: Thomas Danckaert <post <at> thomasdanckaert.be>
To: mbakke <at> fastmail.com
Cc: 28616 <at> debbugs.gnu.org
Subject: Re: [bug#28616] disable failing bluez test
Date: Wed, 11 Oct 2017 18:10:58 +0200 (CEST)

[Message part 1 (text/plain, inline)]

From: Marius Bakke <mbakke <at> fastmail.com>
Subject: Re: [bug#28616] disable failing bluez test
Date: Tue, 10 Oct 2017 23:40:39 +0200

> Thomas Danckaert <post <at> thomasdanckaert.be> writes:
> 
>> From: Marius Bakke <mbakke <at> fastmail.com>
>> Subject: Re: [bug#28616] disable failing bluez test
>> Date: Tue, 03 Oct 2017 23:50:56 +0200
>>
>>> I think we should apply the patch regardless (on 'core-updates'), with a
>>> link to the upstream discussion.  IMO it's more important to be able to
>>> build from source regardless of hardware, than running this one unit
>>> test.  What do you think?
>>
>> I agree.
>>
>> I'll push this to core-updates then.
> 
> On second thought, "bluez" is currently failing on armhf, seemingly due
> to the original patch: <https://hydra.gnu.org/build/2304811/nixlog/4/raw>

I believe attached patch does the job for master, just touching armhf
and leaving other architectures alone.  I tested it by replacing
armhf-linux with x86_64-linux, and then it skips the test ...

WDYT?

Thomas

[0001-WIP-fix-bluez.patch (text/x-patch, inline)]

From 89eb8efeb650d53085fa36f42b5615f6cf4717b6 Mon Sep 17 00:00:00 2001
From: Thomas Danckaert <thomas.danckaert <at> gmail.com>
Date: Wed, 11 Oct 2017 18:05:24 +0200
Subject: [PATCH] WIP fix bluez.

---
 gnu/packages/linux.scm | 17 +++++++++++------
 1 file changed, 11 insertions(+), 6 deletions(-)

diff --git a/gnu/packages/linux.scm b/gnu/packages/linux.scm
index 8ef7a105d..34230cd15 100644
--- a/gnu/packages/linux.scm
+++ b/gnu/packages/linux.scm
@@ -3049,6 +3049,16 @@ Bluetooth audio output devices like headphones or loudspeakers.")
                (string-append "--with-udevdir=" out "/lib/udev")))
        #:phases
        (modify-phases %standard-phases
+         ,@(if (string=? (%current-system) "armhf-linux")
+               ;; This test fails unpredictably.
+               ;; TODO: skip it for all architectures.
+               `((add-before 'check 'skip-wonky-test
+                  (lambda _
+                    (substitute* "unit/test-gatt.c"
+                      (("tester_init\\(&argc, &argv\\);") "return 77;"))
+                    #t)))
+               `())
+
          (add-after 'install 'post-install
            (lambda* (#:key inputs outputs #:allow-other-keys)
              (let* ((out        (assoc-ref outputs "out"))
@@ -3067,12 +3077,7 @@ Bluetooth audio output devices like headphones or loudspeakers.")
                   (string-append out "/lib/udev/hid2hci --method"))
                  (("/sbin/udevadm")
                   (string-append (assoc-ref inputs "eudev") "/bin/udevadm")))
-               #t))))
-
-       ;; FIXME: Skip one test that segfaults on ARM.
-       ,@(if (string=? (%current-system) "armhf-linux")
-             '(#:make-flags '("XFAIL_TESTS=unit/test-gatt"))
-             '())))
+               #t))))))
     (native-inputs
      `(("pkg-config" ,pkg-config)
        ("gettext" ,gettext-minimal)))
-- 
2.14.2

Message #40 received at 28616 <at> debbugs.gnu.org (full text, mbox):

From: Marius Bakke <mbakke <at> fastmail.com>
To: Thomas Danckaert <post <at> thomasdanckaert.be>
Cc: 28616 <at> debbugs.gnu.org
Subject: Re: [bug#28616] disable failing bluez test
Date: Wed, 11 Oct 2017 18:23:20 +0200

On 11 October 2017 18:10:58 CEST, Thomas Danckaert <post <at> thomasdanckaert.be> wrote:
>From: Marius Bakke <mbakke <at> fastmail.com>
>Subject: Re: [bug#28616] disable failing bluez test
>Date: Tue, 10 Oct 2017 23:40:39 +0200
>
>> Thomas Danckaert <post <at> thomasdanckaert.be> writes:
>> 
>>> From: Marius Bakke <mbakke <at> fastmail.com>
>>> Subject: Re: [bug#28616] disable failing bluez test
>>> Date: Tue, 03 Oct 2017 23:50:56 +0200
>>>
>>>> I think we should apply the patch regardless (on 'core-updates'),
>with a
>>>> link to the upstream discussion.  IMO it's more important to be
>able to
>>>> build from source regardless of hardware, than running this one
>unit
>>>> test.  What do you think?
>>>
>>> I agree.
>>>
>>> I'll push this to core-updates then.
>> 
>> On second thought, "bluez" is currently failing on armhf, seemingly
>due
>> to the original patch:
><https://hydra.gnu.org/build/2304811/nixlog/4/raw>
>
>I believe attached patch does the job for master, just touching armhf
>and leaving other architectures alone.  I tested it by replacing
>armhf-linux with x86_64-linux, and then it skips the test ...
>
>WDYT?

Yay! I am unable to test it right now, but if you've verified that this doesn't change the derivation on other architectures this LGTM.

Thank you!

PS: feel free to merge it to core-updates after pushing and modify it to apply on all arches there. If you're not comfortable I can do this later.


-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Message #43 received at 28616 <at> debbugs.gnu.org (full text, mbox):

From: Thomas Danckaert <post <at> thomasdanckaert.be>
To: mbakke <at> fastmail.com
Cc: 28616 <at> debbugs.gnu.org
Subject: Re: [bug#28616] disable failing bluez test
Date: Wed, 11 Oct 2017 21:53:42 +0200 (CEST)

From: Marius Bakke <mbakke <at> fastmail.com>
Subject: Re: [bug#28616] disable failing bluez test
Date: Wed, 11 Oct 2017 18:23:20 +0200

>>> On second thought, "bluez" is currently failing on armhf, 
>>> seemingly
>>> due
>>> to the original patch:
>>> <https://hydra.gnu.org/build/2304811/nixlog/4/raw>
>>
>>I believe attached patch does the job for master, just touching 
>>armhf
>>and leaving other architectures alone.  I tested it by replacing
>>armhf-linux with x86_64-linux, and then it skips the test ...
>>
>>WDYT?
>
> Yay! I am unable to test it right now, but if you've verified that 
> this doesn't change the derivation on other architectures this LGTM.

I've pushed it.

> PS: feel free to merge it to core-updates after pushing and modify 
> it to apply on all arches there. If you're not comfortable I can do 
> this later.

I probably won't have time for this until the weekend, but if you 
don't beat me to it, I'll try that :).

cheers,

Thomas

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.