0.6 is around the corner!

0.6 is around the corner!

[Ludovic Courtès]

Hello,

0.6 is getting ready!  The remaining items are Mark’s new union.scm, and
Nikita’s signed-substitutes support.
  
I think we can expect to have them in shape within a few days, hopefully.
So it’s definitely time to report any issues you may have.

Comments welcome!

Ludo’.

Re: 0.6 is around the corner!

[Mark H Weaver]

ludo@gnu.org (Ludovic Courtès) writes:

> 0.6 is getting ready!  The remaining items are Mark’s new union.scm, and
> Nikita’s signed-substitutes support.
>   
> I think we can expect to have them in shape within a few days, hopefully.
> So it’s definitely time to report any issues you may have.

I've run into a build issue with recent master on x86_64 and Loongson 3A
(both hosted on Debian wheezy).  Python 3 fails in the tests with
"OSError: out of pty devices" and then the guix-daemon sometimes gets
stuck in a sleeping state and hangs indefinitely.

My Loongson 2F system, based on 1eefbb2693f0f29f8f095af9f067240b85e735aa
with some cherry-picks and local patches, did not run into this problem.
My guess is that a commit since 1eefbb2 broke things.  Alternatively,
maybe the difference is that my Loongson 2F is not based on Debian, but
rather on my home-built custom system based on CLFS.

For completeness, here are the patches I added to 1eefbb2, so the
problem isn't in any of these:

--8<---------------cut here---------------start------------->8---
727c3ed * [mhw] gnu: pulseaudio: Increase timeouts for tests.
b669aae * PRELIMINARY Rewrite union.scm.
a633e16 * TEMPORARY HACK: Disable binary-substitute script.
9c717c8 * gnu: gnutls: Configure location of system-wide trust store.
a44bec8 * PRELIMINARY Upgrade sqlite to 3.8.4, and apply large page size fix.
b749814 * TEMPORARY HACK: Disable tests for gdb.
4f662d7 * daemon: Add tests for substitutes and --no-substitutes.
df4775e * daemon: Clear $NIX_SUBSTITUTERS when passed '--no-substitutes'.
895905a * daemon: Change some options via 'settings.set'.
3e67ad4 * Add (guix svn-download).
59e7456 * gnu: gnu-pw-mgr: Fix download location.
4807dba * gnu: tcl: Install man pages in share/man.
5f156d1 * gnu: tor: Upgrade to 0.2.4.21.
1eefbb2 * [origin/core-updates] Merge branch 'master' into core-updates
--8<---------------cut here---------------end--------------->8---

Beyond that, here are some things that I'd ideally like to get into 0.6:

* New union.scm.

* Fix more packages to install man pages in share/man: expect, lua, zip,
  pth, bazaar, ocaml, indent, netpbm.

* Look into security updates for mutt, file, and libssh:
  file: https://github.com/file/file/commit/c0c0032b9e9eb57b91fefef905a3b018bab492d9
  mutt: Debian Security Advisory DSA-2874-1
  libssh: Debian Security Advisory DSA-2879-1

     Mark

Re: 0.6 is around the corner!

[Mark H Weaver]

Mark H Weaver <mhw@netris.org> writes:

> I've run into a build issue with recent master on x86_64 and Loongson 3A
> (both hosted on Debian wheezy).  Python 3 fails in the tests with
> "OSError: out of pty devices" and then the guix-daemon sometimes gets
> stuck in a sleeping state and hangs indefinitely.
>
> My Loongson 2F system, based on 1eefbb2693f0f29f8f095af9f067240b85e735aa
> with some cherry-picks and local patches, did not run into this problem.

Actually, the reason it worked on my Loongson 2F is that the Python 3
tests weren't run at all.  They've been enabled since then.

On the subject of things I want to get into 0.6, I forgot these:

> a44bec8 * PRELIMINARY Upgrade sqlite to 3.8.4, and apply large page size fix.

Dan Kennedy, who I guess is an sqlite dev, gave me a patch to fix the
problems with sqlite on systems with 64K pages, such as my YeeLoong.
I'd like to get this in, along with an upgrade to 3.8.4, or 3.8.4.1 if
it's on the sourceforge mirror now (it wasn't the last time I checked).

> b749814 * TEMPORARY HACK: Disable tests for gdb.

gdb-7.7 seems to work for me, but the test suite consistently fails for
me on MIPS, and apparently also i686 judging from hydra, last I checked.

> Beyond that, here are some things that I'd ideally like to get into 0.6:
>
> * New union.scm.
>
> * Fix more packages to install man pages in share/man: expect, lua, zip,
>   pth, bazaar, ocaml, indent, netpbm.
>
> * Look into security updates for mutt, file, and libssh:
>   file: https://github.com/file/file/commit/c0c0032b9e9eb57b91fefef905a3b018bab492d9
>   mutt: Debian Security Advisory DSA-2874-1
>   libssh: Debian Security Advisory DSA-2879-1
>
>      Mark

Re: 0.6 is around the corner!

[Ludovic Courtès]

Mark H Weaver <mhw@netris.org> skribis:

> ludo@gnu.org (Ludovic Courtès) writes:
>
>> 0.6 is getting ready!  The remaining items are Mark’s new union.scm, and
>> Nikita’s signed-substitutes support.
>>   
>> I think we can expect to have them in shape within a few days, hopefully.
>> So it’s definitely time to report any issues you may have.
>
> I've run into a build issue with recent master on x86_64 and Loongson 3A
> (both hosted on Debian wheezy).  Python 3 fails in the tests with
> "OSError: out of pty devices"

Any idea what this test is doing?  (Maybe Cyril knows?)

> and then the guix-daemon sometimes gets stuck in a sleeping state and
> hangs indefinitely.

How does that happen?  Could you get a backtrace next time it shows up,
and ideally a way to reproduce?

> My Loongson 2F system, based on 1eefbb2693f0f29f8f095af9f067240b85e735aa
> with some cherry-picks and local patches, did not run into this problem.
> My guess is that a commit since 1eefbb2 broke things.

One candidate is 9a9a3ad (“Enable tests in Python 3.”).

> Beyond that, here are some things that I'd ideally like to get into 0.6:
>
> * New union.scm.

Definitely.  The last draft you posted looked OK to me; I can write test
sometime before or after you push it.

> * Fix more packages to install man pages in share/man: expect, lua, zip,
>   pth, bazaar, ocaml, indent, netpbm.

OK, but that shouldn’t be blocking.

> * Look into security updates for mutt, file, and libssh:
>   file: https://github.com/file/file/commit/c0c0032b9e9eb57b91fefef905a3b018bab492d9
>   mutt: Debian Security Advisory DSA-2874-1
>   libssh: Debian Security Advisory DSA-2879-1

Yes, makes sense.  Thanks for keeping track of that!

Ludo’.

Re: 0.6 is around the corner!

[Ludovic Courtès]

Mark H Weaver <mhw@netris.org> skribis:

> Mark H Weaver <mhw@netris.org> writes:
>
>> I've run into a build issue with recent master on x86_64 and Loongson 3A
>> (both hosted on Debian wheezy).  Python 3 fails in the tests with
>> "OSError: out of pty devices" and then the guix-daemon sometimes gets
>> stuck in a sleeping state and hangs indefinitely.
>>
>> My Loongson 2F system, based on 1eefbb2693f0f29f8f095af9f067240b85e735aa
>> with some cherry-picks and local patches, did not run into this problem.
>
> Actually, the reason it worked on my Loongson 2F is that the Python 3
> tests weren't run at all.  They've been enabled since then.

Heh.

> On the subject of things I want to get into 0.6, I forgot these:
>
>> a44bec8 * PRELIMINARY Upgrade sqlite to 3.8.4, and apply large page size fix.
>
> Dan Kennedy, who I guess is an sqlite dev, gave me a patch to fix the
> problems with sqlite on systems with 64K pages, such as my YeeLoong.
> I'd like to get this in, along with an upgrade to 3.8.4, or 3.8.4.1 if
> it's on the sourceforge mirror now (it wasn't the last time I checked).

Fine.

>> b749814 * TEMPORARY HACK: Disable tests for gdb.
>
> gdb-7.7 seems to work for me, but the test suite consistently fails for
> me on MIPS, and apparently also i686 judging from hydra, last I checked.

The problem is that there are always tests in GDB’s test suite that may
fail on some platform, and I don’t really know how we’re supposed to
interpret that (well, I haven’t investigated.)

Ludo’.

Re: 0.6 is around the corner!

[Mark H Weaver]

ludo@gnu.org (Ludovic Courtès) writes:

> Mark H Weaver <mhw@netris.org> skribis:
>
>> I've run into a build issue with recent master on x86_64 and Loongson 3A
>> (both hosted on Debian wheezy).  Python 3 fails in the tests with
>> "OSError: out of pty devices"
>
> Any idea what this test is doing?  (Maybe Cyril knows?)

Cyril is apparently unable to reproduce the problem on his system, which
he tells me is Debian Sid running in a VM.

Eric Bavier reported seeing the same problem on x86_64 Trisquel 6.0.

See below for the tail of my build log.

     Mark


--8<---------------cut here---------------start------------->8---
Re-running test 'test_pty' in verbose mode
test__copy_eof_on_all (test.test_pty.SmallPtyTests)
Test the empty read EOF case on both master_fd and stdin. ... ok
test__copy_to_each (test.test_pty.SmallPtyTests)
Test the normal data case on both master_fd and stdin. ... ok
test_basic (test.test_pty.PtyTest) ... Calling master_open()
skipped 'Pseudo-terminals (seemingly) not functional.'
test_fork (test.test_pty.PtyTest) ... test test_pty failed
calling pty.fork()
ERROR

======================================================================
ERROR: test_fork (test.test_pty.PtyTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/tmp/nix-build-python-3.3.3.drv-13/Python-3.3.3/Lib/test/test_pty.py", line 116, in test_fork
    pid, master_fd = pty.fork()
  File "/tmp/nix-build-python-3.3.3.drv-13/Python-3.3.3/Lib/pty.py", line 107, in fork
    master_fd, slave_fd = openpty()
  File "/tmp/nix-build-python-3.3.3.drv-13/Python-3.3.3/Lib/pty.py", line 29, in openpty
    master_fd, slave_name = _open_terminal()
  File "/tmp/nix-build-python-3.3.3.drv-13/Python-3.3.3/Lib/pty.py", line 70, in _open_terminal
    raise os.error('out of pty devices')
OSError: out of pty devices

----------------------------------------------------------------------
Ran 4 tests in 0.020s

FAILED (errors=1, skipped=1)
Makefile:881: recipe for target 'test' failed
make: *** [test] Error 1
phase `check' failed after 563 seconds
note: keeping build directory `/tmp/nix-build-python-3.3.3.drv-13'
builder for `/gnu/store/7a9dv96kb1z7547ms4k9bcywg4c0pf0j-python-3.3.3.drv' failed with exit code 1
@ build-failed /gnu/store/7a9dv96kb1z7547ms4k9bcywg4c0pf0j-python-3.3.3.drv - 1 builder for `/gnu/store/7a9dv96kb1z7547ms4k9bcywg4c0pf0j-python-3.3.3.drv' failed with exit code 1
cannot build derivation `/gnu/store/02xs98dh962srhs71hgiq046d9jgsk8z-python-wrapper-3.3.3.drv': 1 dependencies couldn't be built
cannot build derivation `/gnu/store/dlwvzvnpmprmlgw9b7bccidd1fw8gawg-glib-2.39.1.drv': 1 dependencies couldn't be built
cannot build derivation `/gnu/store/500mhfzdk6kr344y3hwhi2i5y61w7bn5-ghostscript-9.06.0.drv': 1 dependencies couldn't be built
cannot build derivation `/gnu/store/bbwqs6s4c2bzqi24r1wfh3vyh1q6q1v1-emacs-24.3.drv': 1 dependencies couldn't be built
--8<---------------cut here---------------end--------------->8---

Python 3 test failures

[Ludovic Courtès]

[-- Attachment #1: Type: text/plain, Size: 2922 bytes --]

Mark H Weaver <mhw@netris.org> skribis:

> ======================================================================
> ERROR: test_fork (test.test_pty.PtyTest)
> ----------------------------------------------------------------------
> Traceback (most recent call last):
>   File "/tmp/nix-build-python-3.3.3.drv-13/Python-3.3.3/Lib/test/test_pty.py", line 116, in test_fork
>     pid, master_fd = pty.fork()
>   File "/tmp/nix-build-python-3.3.3.drv-13/Python-3.3.3/Lib/pty.py", line 107, in fork
>     master_fd, slave_fd = openpty()
>   File "/tmp/nix-build-python-3.3.3.drv-13/Python-3.3.3/Lib/pty.py", line 29, in openpty
>     master_fd, slave_name = _open_terminal()
>   File "/tmp/nix-build-python-3.3.3.drv-13/Python-3.3.3/Lib/pty.py", line 70, in _open_terminal
>     raise os.error('out of pty devices')
> OSError: out of pty devices

This particular test is fixed by the daemon patch I posted, which makes
sure /dev/pts/ptmx is 0666 (I’ll update nix-upstream.)

Now I see one remaining failure:

--8<---------------cut here---------------start------------->8---
[374/374/1] test_multiprocessing
/tmp/nix-build-python-3.3.3.drv-1/Python-3.3.3/Lib/multiprocessing/process.py:95: ResourceWarning: unclosed <socket.socket object, fd=7, family=1, type=1, proto=0>
  self._target(*self._args, **self._kwargs)
Warning -- multiprocessing.process._dangling was modified by test_multiprocessing
test test_multiprocessing failed -- Traceback (most recent call last):
  File "/tmp/nix-build-python-3.3.3.drv-1/Python-3.3.3/Lib/test/test_multiprocessing.py", line 1035, in test_wait_result
    self.assertRaises(KeyboardInterrupt, c.wait, 10)
AssertionError: KeyboardInterrupt not raised by wait
--8<---------------cut here---------------end--------------->8---

This test exercises the ‘Condition’ API, which implements an
inter-process synchronization primitive similar to condition variables,
on top of semaphores (sem_open):

--8<---------------cut here---------------start------------->8---
    def _test_wait_result(cls, c, pid):
        with c:
            c.notify()
        time.sleep(1)
        if pid is not None:
            os.kill(pid, signal.SIGINT)

    def test_wait_result(self):
        if isinstance(self, ProcessesMixin) and sys.platform != 'win32':
            pid = os.getpid()
        else:
            pid = None

        c = self.Condition()
        with c:
            self.assertFalse(c.wait(0))
            self.assertFalse(c.wait(0.1))

            p = self.Process(target=self._test_wait_result, args=(c, pid))
            p.start()

            self.assertTrue(c.wait(10))
            if pid is not None:
                self.assertRaises(KeyboardInterrupt, c.wait, 10)

            p.join()
--8<---------------cut here---------------end--------------->8---

I thought that the test might be racy, so I tried this patch:


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: text/x-patch, Size: 697 bytes --]

--- Lib/test/test_multiprocessing.py	2014-04-03 18:04:55.000000000 +0200
+++ Lib/test/test_multiprocessing.py	2014-04-03 18:05:08.000000000 +0200
@@ -1012,7 +1012,7 @@ class _TestCondition(BaseTestCase):
     def _test_wait_result(cls, c, pid):
         with c:
             c.notify()
-        time.sleep(1)
+        time.sleep(20)
         if pid is not None:
             os.kill(pid, signal.SIGINT)
 
@@ -1032,7 +1032,7 @@ class _TestCondition(BaseTestCase):
 
             self.assertTrue(c.wait(10))
             if pid is not None:
-                self.assertRaises(KeyboardInterrupt, c.wait, 10)
+                self.assertRaises(KeyboardInterrupt, c.wait, 60)
 
             p.join()
 

[-- Attachment #3: Type: text/plain, Size: 137 bytes --]


It doesn’t help, though.

The test passes outside of the chroot.  I haven’t tried stracing it yet.

Help welcome!

Ludo’.

Re: Python 3 test failures

[Mark H Weaver]

ludo@gnu.org (Ludovic Courtès) writes:

> Mark H Weaver <mhw@netris.org> skribis:
>
>> ======================================================================
>> ERROR: test_fork (test.test_pty.PtyTest)
>> ----------------------------------------------------------------------
>> Traceback (most recent call last):
>>   File "/tmp/nix-build-python-3.3.3.drv-13/Python-3.3.3/Lib/test/test_pty.py", line 116, in test_fork
>>     pid, master_fd = pty.fork()
>>   File "/tmp/nix-build-python-3.3.3.drv-13/Python-3.3.3/Lib/pty.py", line 107, in fork
>>     master_fd, slave_fd = openpty()
>>   File "/tmp/nix-build-python-3.3.3.drv-13/Python-3.3.3/Lib/pty.py", line 29, in openpty
>>     master_fd, slave_name = _open_terminal()
>>   File "/tmp/nix-build-python-3.3.3.drv-13/Python-3.3.3/Lib/pty.py", line 70, in _open_terminal
>>     raise os.error('out of pty devices')
>> OSError: out of pty devices
>
> This particular test is fixed by the daemon patch I posted, which makes
> sure /dev/pts/ptmx is 0666 (I’ll update nix-upstream.)

What are the security implications of this?  Why do you suppose that
Debian (or Linux, the kernel?) uses perms 0000 for /dev/pts/ptmx, and
how it is that these tests normally work outside of guix-daemon, when
the perms are 0000?

      Mark

Re: Python 3 test failures

[Ludovic Courtès]

Mark H Weaver <mhw@netris.org> skribis:

> ludo@gnu.org (Ludovic Courtès) writes:
>
>> Mark H Weaver <mhw@netris.org> skribis:
>>
>>> ======================================================================
>>> ERROR: test_fork (test.test_pty.PtyTest)
>>> ----------------------------------------------------------------------
>>> Traceback (most recent call last):
>>>   File "/tmp/nix-build-python-3.3.3.drv-13/Python-3.3.3/Lib/test/test_pty.py", line 116, in test_fork
>>>     pid, master_fd = pty.fork()
>>>   File "/tmp/nix-build-python-3.3.3.drv-13/Python-3.3.3/Lib/pty.py", line 107, in fork
>>>     master_fd, slave_fd = openpty()
>>>   File "/tmp/nix-build-python-3.3.3.drv-13/Python-3.3.3/Lib/pty.py", line 29, in openpty
>>>     master_fd, slave_name = _open_terminal()
>>>   File "/tmp/nix-build-python-3.3.3.drv-13/Python-3.3.3/Lib/pty.py", line 70, in _open_terminal
>>>     raise os.error('out of pty devices')
>>> OSError: out of pty devices
>>
>> This particular test is fixed by the daemon patch I posted, which makes
>> sure /dev/pts/ptmx is 0666 (I’ll update nix-upstream.)
>
> What are the security implications of this?  Why do you suppose that
> Debian (or Linux, the kernel?) uses perms 0000 for /dev/pts/ptmx, 

The devpts file system of Linux creates this file with perms 000 by
default:

  https://www.kernel.org/doc/Documentation/filesystems/devpts.txt

> and how it is that these tests normally work outside of guix-daemon,
> when the perms are 0000?

Often, outside the chroot, /dev/ptmx is directly a character device,
with perms 0666.  Conversely, inside the chroot it’s a symlink to
/dev/pts/ptmx (as suggested in devpts.txt), but until this patch was
applied, it had perms 000.

Ludo’.

Re: 0.6 is around the corner!

[Ludovic Courtès]

Looks like the important things are in place.  We still need to do
something about Python 3’s failing test (Cyril?).  I was also thinking
of preparing a QEMU image with X.

I’d like to push the release by Wednesday, so please test, and let’s fix
packages that fail to build!

Ludo’.

[PATCH] gnu: Python: disable test_wait_result() as it fails on some setups

[Cyril Roelandt]

* gnu/packages/patches/python-fix-tests.patch: disable a failing test.
---
 gnu/packages/patches/python-fix-tests.patch | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/gnu/packages/patches/python-fix-tests.patch b/gnu/packages/patches/python-fix-tests.patch
index fecebda..eed4f36 100644
--- a/gnu/packages/patches/python-fix-tests.patch
+++ b/gnu/packages/patches/python-fix-tests.patch
@@ -64,3 +64,13 @@ http://bugs.python.org/issue20868 .
      @unittest.skipUnless(support.is_resource_enabled('network'),
                           'network is not enabled')
      def test_idna(self):
+--- Lib/test/test_multiprocessing.py	2014-04-06 23:12:27.575235000 +0200
++++ Lib/test/test_multiprocessing.py	2014-04-06 23:13:04.827235000 +0200
+@@ -1016,6 +1016,7 @@
+         if pid is not None:
+             os.kill(pid, signal.SIGINT)
+ 
++    @unittest.skipIf(True, "This fails for unknown reasons on Guix")
+     def test_wait_result(self):
+         if isinstance(self, ProcessesMixin) and sys.platform != 'win32':
+             pid = os.getpid()
-- 
1.8.4.rc3

Re: [PATCH] gnu: Python: disable test_wait_result() as it fails on some setups

[Mark H Weaver]

Cyril Roelandt <tipecaml@gmail.com> writes:

> * gnu/packages/patches/python-fix-tests.patch: disable a failing test.
> ---
>  gnu/packages/patches/python-fix-tests.patch | 10 ++++++++++
>  1 file changed, 10 insertions(+)
>
> diff --git a/gnu/packages/patches/python-fix-tests.patch b/gnu/packages/patches/python-fix-tests.patch
> index fecebda..eed4f36 100644
> --- a/gnu/packages/patches/python-fix-tests.patch
> +++ b/gnu/packages/patches/python-fix-tests.patch
> @@ -64,3 +64,13 @@ http://bugs.python.org/issue20868 .
>       @unittest.skipUnless(support.is_resource_enabled('network'),
>                            'network is not enabled')
>       def test_idna(self):
> +--- Lib/test/test_multiprocessing.py	2014-04-06 23:12:27.575235000 +0200
> ++++ Lib/test/test_multiprocessing.py	2014-04-06 23:13:04.827235000 +0200
> +@@ -1016,6 +1016,7 @@
> +         if pid is not None:
> +             os.kill(pid, signal.SIGINT)
> + 
> ++    @unittest.skipIf(True, "This fails for unknown reasons on Guix")
> +     def test_wait_result(self):
> +         if isinstance(self, ProcessesMixin) and sys.platform != 'win32':
> +             pid = os.getpid()

This fixes the build on x86_64 for me, but there are still test failures
on MIPS:

--8<---------------cut here---------------start------------->8---
======================================================================
FAIL: test_issue_8959_a (ctypes.test.test_callbacks.SampleCallbacksTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/tmp/nix-build-python-3.3.3.drv-0/Python-3.3.3/Lib/ctypes/test/test_callbacks.py", line 191, in test_issue_8959_a
    self.assertEqual(array[:], [1, 5, 7, 33, 99])
AssertionError: Lists differ: [33, 7, 99, 1, 5] != [1, 5, 7, 33, 99]

First differing element 0:
33
1

- [33, 7, 99, 1, 5]
+ [1, 5, 7, 33, 99]

======================================================================
FAIL: test_qsort (ctypes.test.test_libc.LibTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/tmp/nix-build-python-3.3.3.drv-0/Python-3.3.3/Lib/ctypes/test/test_libc.py", line 30, in test_qsort
    self.assertEqual(chars.raw, b"   ,,aaaadmmmnpppsss\x00")
AssertionError: b'mmaappss  dna ,,maps\x00' != b'   ,,aaaadmmmnpppsss\x00'

----------------------------------------------------------------------
Ran 346 tests in 4.092s

FAILED (failures=2, skipped=1)
Makefile:881: recipe for target 'test' failed
make: *** [test] Error 1
phase `check' failed after 661 seconds
--8<---------------cut here---------------end--------------->8---

I suppose that these are genuine bugs in the ctypes module for MIPS.

     Mark

Re: [PATCH] gnu: Python: disable test_wait_result() as it fails on some setups

[Ludovic Courtès]

Cyril Roelandt <tipecaml@gmail.com> skribis:

> * gnu/packages/patches/python-fix-tests.patch: disable a failing test.

Thanks!

What would you think of pushing an upgrade to 3.3.5 at the same time?

(Plus a MIPS fix or workaround, which Mark is looking at.)

Ludo’.

Re: [PATCH] gnu: Python: disable test_wait_result() as it fails on some setups

[Ludovic Courtès]

Cyril Roelandt <tipecaml@gmail.com> skribis:

> * gnu/packages/patches/python-fix-tests.patch: disable a failing test.

I pushed it on your behalf, thanks.

Ludo’.

[PATCH] gnu: Python: disable failing tests on MIPS64.

[Cyril Roelandt]

* gnu/packages/patches/python-fix-tests.patch: disable two failing tests on
  MIPS64.
---
 gnu/packages/patches/python-fix-tests.patch | 38 +++++++++++++++++++++++++++++
 1 file changed, 38 insertions(+)

diff --git a/gnu/packages/patches/python-fix-tests.patch b/gnu/packages/patches/python-fix-tests.patch
index eed4f36..70e4aa0 100644
--- a/gnu/packages/patches/python-fix-tests.patch
+++ b/gnu/packages/patches/python-fix-tests.patch
@@ -74,3 +74,41 @@ http://bugs.python.org/issue20868 .
      def test_wait_result(self):
          if isinstance(self, ProcessesMixin) and sys.platform != 'win32':
              pid = os.getpid()
+--- Lib/ctypes/test/test_libc.py	2014-04-07 23:17:41.351235000 +0200
++++ Lib/ctypes/test/test_libc.py	2014-04-07 23:32:18.799235000 +0200
+@@ -2,6 +2,7 @@
+ 
+ from ctypes import *
+ import _ctypes_test
++import platform
+ 
+ lib = CDLL(_ctypes_test.__file__)
+ 
+@@ -17,6 +18,8 @@
+         import math
+         self.assertEqual(lib.my_sqrt(2.0), math.sqrt(2.0))
+ 
++    @unittest.skipIf(platform.machine() in ['mips64'],
++                     "This test fails on this platform")
+     def test_qsort(self):
+         comparefunc = CFUNCTYPE(c_int, POINTER(c_char), POINTER(c_char))
+         lib.my_qsort.argtypes = c_void_p, c_size_t, c_size_t, comparefunc
+--- Lib/ctypes/test/test_callbacks.py	2014-04-07 23:15:42.835235000 +0200
++++ Lib/ctypes/test/test_callbacks.py	2014-04-07 23:32:42.035235000 +0200
+@@ -1,6 +1,7 @@
+ import unittest
+ from ctypes import *
+ import _ctypes_test
++import platform
+ 
+ class Callbacks(unittest.TestCase):
+     functype = CFUNCTYPE
+@@ -174,6 +175,8 @@
+ 
+         self.assertLess(diff, 0.01, "%s not less than 0.01" % diff)
+ 
++    @unittest.skipIf(platform.machine() in ['mips64'],
++                     "This test fails on this platform")
+     def test_issue_8959_a(self):
+         from ctypes.util import find_library
+         libc_path = find_library("c")
-- 
1.8.4.rc3

Re: [PATCH] gnu: Python: disable failing tests on MIPS64.

[Mark H Weaver]

Cyril Roelandt <tipecaml@gmail.com> writes:

> * gnu/packages/patches/python-fix-tests.patch: disable two failing tests on
>   MIPS64.
> ---
>  gnu/packages/patches/python-fix-tests.patch | 38 +++++++++++++++++++++++++++++
>  1 file changed, 38 insertions(+)
>
> diff --git a/gnu/packages/patches/python-fix-tests.patch b/gnu/packages/patches/python-fix-tests.patch
> index eed4f36..70e4aa0 100644
> --- a/gnu/packages/patches/python-fix-tests.patch
> +++ b/gnu/packages/patches/python-fix-tests.patch
> @@ -74,3 +74,41 @@ http://bugs.python.org/issue20868 .
>       def test_wait_result(self):
>           if isinstance(self, ProcessesMixin) and sys.platform != 'win32':
>               pid = os.getpid()
> +--- Lib/ctypes/test/test_libc.py	2014-04-07 23:17:41.351235000 +0200
> ++++ Lib/ctypes/test/test_libc.py	2014-04-07 23:32:18.799235000 +0200
> +@@ -2,6 +2,7 @@
> + 
> + from ctypes import *
> + import _ctypes_test
> ++import platform
> + 
> + lib = CDLL(_ctypes_test.__file__)
> + 
> +@@ -17,6 +18,8 @@
> +         import math
> +         self.assertEqual(lib.my_sqrt(2.0), math.sqrt(2.0))
> + 
> ++    @unittest.skipIf(platform.machine() in ['mips64'],
> ++                     "This test fails on this platform")
> +     def test_qsort(self):
> +         comparefunc = CFUNCTYPE(c_int, POINTER(c_char), POINTER(c_char))
> +         lib.my_qsort.argtypes = c_void_p, c_size_t, c_size_t, comparefunc
> +--- Lib/ctypes/test/test_callbacks.py	2014-04-07 23:15:42.835235000 +0200
> ++++ Lib/ctypes/test/test_callbacks.py	2014-04-07 23:32:42.035235000 +0200
> +@@ -1,6 +1,7 @@
> + import unittest
> + from ctypes import *
> + import _ctypes_test
> ++import platform
> + 
> + class Callbacks(unittest.TestCase):
> +     functype = CFUNCTYPE
> +@@ -174,6 +175,8 @@
> + 
> +         self.assertLess(diff, 0.01, "%s not less than 0.01" % diff)
> + 
> ++    @unittest.skipIf(platform.machine() in ['mips64'],
> ++                     "This test fails on this platform")
> +     def test_issue_8959_a(self):
> +         from ctypes.util import find_library
> +         libc_path = find_library("c")

I've tested this on the Loongson 3A machine, and it works as expected.

    Thanks!
      Mark

Re: [PATCH] gnu: Python: disable failing tests on MIPS64.

[Mark H Weaver]

Cyril Roelandt <tipecaml@gmail.com> writes:
> * gnu/packages/patches/python-fix-tests.patch: disable two failing tests on
>   MIPS64.

I pushed this on your behalf.

    Mark

Re: [PATCH] gnu: Python: disable failing tests on MIPS64.

[Nikita Karetnikov]

[-- Attachment #1: Type: text/plain, Size: 1865 bytes --]

> I've tested this on the Loongson 3A machine, and it works as expected.

Python fails for me on Lemote YeeLoong.

$ git rev-parse HEAD
32d5c729522d02fe973cb245fe26262f040e0c13

======================================================================
FAIL: test_issue_8959_a (ctypes.test.test_callbacks.SampleCallbacksTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/tmp/nix-build-python-3.3.5.drv-0/Python-3.3.5/Lib/ctypes/test/test_callbacks.py", line 191, in test_issue_8959_a
    self.assertEqual(array[:], [1, 5, 7, 33, 99])
AssertionError: Lists differ: [33, 7, 99, 1, 5] != [1, 5, 7, 33, 99]

First differing element 0:
33
1

- [33, 7, 99, 1, 5]
+ [1, 5, 7, 33, 99]

======================================================================
FAIL: test_qsort (ctypes.test.test_libc.LibTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/tmp/nix-build-python-3.3.5.drv-0/Python-3.3.5/Lib/ctypes/test/test_libc.py", line 30, in test_qsort
    self.assertEqual(chars.raw, b"   ,,aaaadmmmnpppsss\x00")
AssertionError: b'mmaappss  dna ,,maps\x00' != b'   ,,aaaadmmmnpppsss\x00'

----------------------------------------------------------------------
Ran 346 tests in 6.696s

FAILED (failures=2, skipped=1)
Makefile:882: recipe for target 'test' failed
make: *** [test] Error 1
phase `check' failed after 3765 seconds
builder for `/gnu/store/1sryxkz1hbvvw38c86miw14xydbjzv0i-python-3.3.5.drv' failed with exit code 1
@ build-failed /gnu/store/1sryxkz1hbvvw38c86miw14xydbjzv0i-python-3.3.5.drv - 1 builder for `/gnu/store/1sryxkz1hbvvw38c86miw14xydbjzv0i-python-3.3.5.drv' failed with exit code 1
cannot build derivation `/gnu/store/h05a7j9f7p21m1jkkyy48vg3zn5wikb7-python-wrapper-3.3.5.drv': 1 dependencies couldn't be built

[-- Attachment #2: Type: application/pgp-signature, Size: 835 bytes --]

Re: [PATCH] gnu: Python: disable failing tests on MIPS64.

[Cyril Roelandt]

On 04/09/2014 02:40 AM, Nikita Karetnikov wrote:
>> I've tested this on the Loongson 3A machine, and it works as expected.
>
> Python fails for me on Lemote YeeLoong.
>

What does 'python -c "import platform; print(platform.machine())"' 
return on your machine ? The tests that fail are now disabled on mips64.


Cyril.

Re: [PATCH] gnu: Python: disable failing tests on MIPS64.

[Nikita Karetnikov]

[-- Attachment #1: Type: text/plain, Size: 247 bytes --]

> What does 'python -c "import platform; print(platform.machine())"'
> return on your machine ? 

‘mips64’.

> The tests that fail are now disabled on mips64.

I ran ‘make clean’ & co., rebuilt Python; and the tests succeeded.



[-- Attachment #2: Type: application/pgp-signature, Size: 835 bytes --]