[Python-modules-team] Bug#892221: python-jpype: FTBFS on hurd-i386: jni_md_platform is not defined

[James Clarke]

Control: clone -1 -2
Control: reassign -2 gcj-6 6.4.0-12
Control: retitle -2 gcj-6: jawt_md.h and jni_md.h are in linux subdirectory on 
kFreeBSD and GNU/Hurd

On 6 Mar 2018, at 22:50, Aaron M. Ucko  wrote:
> 
> Source: python-jpype
> Version: 0.6.2+dfsg-2
> Severity: normal
> Tags: upstream
> User: debian-h...@lists.debian.org
> Usertags: hurd
> 
> Builds of python-jpype for hurd-i386 (admittedly not a release
> architecture) have been failing, as most recently seen in [1]:
> 
>  setup.py:91: UserWarning: Your platform is not being handled explicitly. It 
> may work or not!
>" It may work or not!", UserWarning)
>  Traceback (most recent call last):
>File "setup.py", line 95, in 
>  [os.path.join(java_home, 'include', jni_md_platform)]
>  NameError: name 'jni_md_platform' is not defined
> 
> Per [2], the appropriate directory name here appears to be linux(!).
> Also, sys.platform starts with "gnu" on the Hurd.

I personally think this is a bug in GCJ. OpenJDK puts them in the
$(OPENJDK_TARGET_OS) subdirectory[0] (except Windows uses win32 and macOS uses
darwin), so if it were ported to the Hurd it would presumably use either "gnu"
or "hurd" as the subdirectory name. FreeBSD's fork of OpenJDK uses "freebsd"
for the directory name[1], but GCJ also puts the files in "linux" there[2]. I
guess GCJ should be patched (and the Hurd porters should decide on a directory
name to use).

Regards,
James

[0] 
http://hg.openjdk.java.net/jdk10/jdk10/jdk/file/777356696811/make/copy/CopyCommon.gmk#l31
[1] 
https://svnweb.freebsd.org/ports/head/java/openjdk8/files/patch-bsd?view=markup=460849#l8874
[2] https://github.com/gcc-mirror/gcc/blob/gcc-6-branch/libjava/Makefile.am#L907

https://github.com/gcc-mirror/gcc/blob/gcc-6-branch/libjava/Makefile.am#L942-L945

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Bug#844233: python-passlib: FTBFS with probability of 0.22% due to non-deterministic testsuite

[James Clarke]

Control: retitle -1 python-passlib: FTBFS with probability of 0.46% due to 
non-deterministic testsuite

On Sun, Nov 13, 2016 at 04:25:30PM +, Chris Lamb wrote:
> Whilst working on the Reproducible Builds effort [0], we noticed
> that python-passlib's testsuite will non-determinstically FTBFS:
>
> ==
> FAIL: test_getrandstr (passlib.tests.test_utils.MiscTest)
> --
> Traceback (most recent call last):
>   File "/build/python-passlib-1.6.5/2nd/passlib/tests/test_utils.py", line 
> 129, in test_getrandstr
> self.assertEqual(sorted(set(x)), [u('a'),u('b'),u('c')])
> AssertionError: Lists differ: [u'a', u'b'] != [u'a', u'b', u'c']
>
> Second list contains 1 additional elements.
> First extra element 2:
> u'c'
>
> - [u'a', u'b']
> + [u'a', u'b', u'c']
> ?++
>
> This is because of:
>
> 125 x = f(u('abc'), 16)
> 126 y = f(u('abc'), 16)
> 127 self.assertIsInstance(x, unicode)
> 128 self.assertNotEqual(x,y)
> 129 self.assertEqual(sorted(set(x)), [u('a'),u('b'),u('c')])
>
> If the random string ``x`` doesn't contain a certain character, the
> assertion will fail. By my quick calculation this will happen with a
> probability of (2/3)^(16-1).

I believe it's actually (3C2)*(2/3)^16 - (3C1)*(1/3)^16 ~= 0.46% (the
subtracted value is negligible).

> It will also FTBFS if it generates the exact same random string, but
> that seems a little more unlikely.

P = (1/3)^16 = 2.3e-8 or 0.023%, which isn't quite as absurdly small
as you might think.

Regards,
James

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team