[0.5.0-rc1] Exception running test replutil: There was an error during testing

[petercolberg]

Exception running test replutil :
On worker 14:
LoadError: There was an error during testing
 in record at ./test.jl:397
 in do_test at ./test.jl:281
 in macro expansion at ./util.jl:226 [inlined]
 in runtests at /usr/share/julia/test/testdefs.jl:7
 in #16 at /usr/share/julia/test/runtests.jl:44
 in #503 at ./multi.jl:1410
 in run_work_thunk at ./multi.jl:996
 in macro expansion at ./multi.jl:1410 [inlined]
 in #502 at ./event.jl:46
while loading /usr/share/julia/test/replutil.jl, in expression starting on line 261

Julia Version 0.5.0-rc1+0
Commit cede539 (2016-08-04 08:48 UTC)
Platform Info:
  System: Linux (x86_64-linux-gnu)
  CPU: Intel(R) Xeon(R) CPU E3-1245 V2 @ 3.40GHz
  WORD_SIZE: 64
  BLAS: libopenblas (NO_LAPACKE DYNAMIC_ARCH NO_AFFINITY Sandybridge)
  LAPACK: libopenblas
  LIBM: libopenlibm
  LLVM: libLLVM-3.8.1 (ORCJIT, ivybridge)

[yuyichao]

Same as #17831

[petercolberg]

The test suite was run in a pristine Debian unstable chroot using a system-wide installation of julia.

Test-Command: env JULIA_TEST_MAXRSS_MB=500 HOME=/tmp julia --check-bounds=yes --startup-file=no -e "Base.runtests([\"all\"], max(Sys.CPU_CORES, 2))"

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.6.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages julia depends on:
ii  libamd2                1:4.5.3-1
ii  libarpack2             3.4.0-1
ii  libc6                  2.23-4
ii  libcamd2               1:4.5.3-1
ii  libcholmod3            1:4.5.3-1
ii  libcolamd2             1:4.5.3-1
ii  libdsfmt-19937-1       2.2.3+dfsg-3
ii  libfftw3-double3       3.3.4-2+b1
ii  libfftw3-single3       3.3.4-2+b1
ii  libgcc1                1:6.1.1-10
ii  libgit2-24             0.24.1-3
ii  libgmp10               2:6.1.1+dfsg-1
ii  libjulia0.5            0.5.0~rc1-1
ii  libmpfr4               3.1.4-2
ii  libopenblas-base       0.2.18-1
ii  libopenlibm2           0.5.1+dfsg-1
ii  libopenspecfun1        0.5.3-1
ii  libpcre2-8-0           10.22-2
ii  libspqr2               1:4.5.3-1
ii  libstdc++6             6.1.1-10
ii  libsuitesparseconfig4  1:4.5.3-1
ii  libumfpack5            1:4.5.3-1

Versions of packages libjulia0.5 depends on:
ii  libarpack2             3.4.0-1
ii  libc6                  2.23-4
ii  libcholmod3            1:4.5.3-1
ii  libdsfmt-19937-1       2.2.3+dfsg-3
ii  libfftw3-double3       3.3.4-2+b1
ii  libfftw3-single3       3.3.4-2+b1
ii  libgcc1                1:6.1.1-10
ii  libgit2-24             0.24.1-3
ii  libgmp10               2:6.1.1+dfsg-1
ii  libllvm3.8             1:3.8.1-5
ii  libmpfr4               3.1.4-2
ii  libopenblas-base       0.2.18-1
ii  libopenlibm2           0.5.1+dfsg-1
ii  libopenspecfun1        0.5.3-1
ii  libpcre2-8-0           10.22-2
ii  libspqr2               1:4.5.3-1
ii  libstdc++6             6.1.1-10
ii  libsuitesparseconfig4  1:4.5.3-1
ii  libumfpack5            1:4.5.3-1
ii  libunwind8             1.1-4.1
ii  libutf8proc2           2.0.2-1

[yuyichao]

Please comment for reopening if this is still happening when the binary is not stripped AND with the git master of libunwind.

[tkelman]

this is why I tell people not to use distribution packages of julia. your build configuration is breaking functionality.

[tkelman]

upstreams that are unmaintained and broken and don't merge any fixes sent to them. not like we haven't tried to send them every patch we're carrying.

[petercolberg]

On Thu, Aug 04, 2016 at 11:33:08PM -0700, Tony Kelman wrote:

this is why I tell people not to use distribution packages of julia. your build configuration is breaking functionality.

@tkelman, please file a bug report with the Debian or Ubuntu bug tracker pointing to the specific code(s) that are not working for you, using the most recent version of either the Debian julia package or the Ubuntu julia package. The Debian Julia team, formerly @sebastien-villemot, now @ginggs and @petercolberg, and with them many contributing Debian developers and Debian/Ubuntu users, are putting significant effort into the julia package. The package is tested on a continuous basis with success.

You are certainly free to give such a recommendation to your friends in private. But doing so in a public comment, from a core Julia developer, is not helping the goal of widespread adoption of Julia.

[yuyichao]

please file a bug report with the Debian or Ubuntu bug tracker pointing to the specific code(s) that are not working for you

Do you mean that it is possible to package patched LLVM 3.3 with julia 0.4.6, patched LLVM 3.7.1 with julia 0.5, libunwind master with julia 0.5?

Edit: i.e. such bug report can be accepted.

[tkelman]

I have no confidence that debian policies will be conducive to getting a version of julia that works properly packaged there. Distribution packages are not maintained by the core team and we can't support them if their build configuration differs by far enough from what we recommend that it's causing test failures.

I have an extreme opinion here, but I'd personally rather not have julia packaged in debian at all than have a version with regressions in functionality there. You're doing the best you can to get it packaged and working, but if people hit bugs that are caused by packaging constraints, that's not good for julia either.

[StefanKarpinski]

Although distro policies can be frustrating we should continue to do everything we can w.r.t. upstreaming and cooperating with Debian devs like @sebastien-villemot, @petercolberg, and @ginggs to make sure that debs for Julia are as good as possible. That said, the policy of insisting that Julia use versions of libraries that it depends on intimately that are either not the version or not the configuration that Julia needs is problematic. This policy has led to a situation where Julia debs are often broken, which is why @tkelman feels forced to recommend against using them. I'm not sure what the solution is, but hopefully you can understand the frustration.

[petercolberg]

Although distro policies can be frustrating we should continue to do everything we can w.r.t. upstreaming and cooperating with Debian devs like @sebastien-villemot, @petercolberg, and @ginggs to make sure that debs for Julia are as good as possible.

Thank you for the reassuring comment. I am positive that we can continue to work together constructively.

That said, the policy of insisting that Julia use versions of libraries that it depends on intimately that are either not the version or not the configuration that Julia needs is problematic. This policy has led to a situation where Julia debs are often broken, which is why @tkelman feels forced to recommend against using them. I'm not sure what the solution is, but hopefully you can understand the frustration.

Please keep in mind that this and related issues constitute the first attempt to get the 0.5 tests working in Debian (and Ubuntu). The package has not been uploaded to the Debian archive, and it won’t be uploaded until all issues with the test suite are resolved. This may simply mean waiting a bit until the llvm package has been updated to version 3.9, and the libgit2 package has been updated to include a TLS backend.

[tkelman]

This may simply mean waiting a bit until the llvm package has been updated to version 3.9

In the meantime, something that will be worth pushing on with the Debian LLVM maintainers is getting multiple versions packaged in parallel. This isn't purely a Julia issue, and a number of other distributions have started doing this. LLVM refactors so much of their C++ API between "minor" versions that parts of it are almost different libraries between versions. Getting everything in the entire Debian archive that uses LLVM in any way to agree on using the same version at all times is too hard to be worth doing.

[petercolberg]

In the meantime, something that will be worth pushing on with the Debian LLVM maintainers is getting multiple versions packaged in parallel. This isn't purely a Julia issue, and a number of other distributions have started doing this. LLVM refactors so much of their C++ API between "minor" versions that parts of it are almost different libraries between versions.

Debian already packages multiple versions of llvm, e.g., stretch includes llvm-3.6, llvm-3.7, and llvm-3.8.

The real issue is that older versions of llvm will be removed from Debian at some point because the maintainers do not have infinite capacity. I have suggested the proven solution to this problem before: Please propose upstream to maintain long-term support (LTS) releases of llvm that are chosen in two- or three-year intervals. Those would naturally be kept in distributions for the entire maintenance window.

[vtjnash]

LLVM refactors so much of their C++ API between "minor" versions

IIUC, LLVM is planning on abandoning this practice starting with the next release (4.0). They will Instead call them major releases ("you can expect LLVM 5.0 to be released ~6 months after LLVM 4.0" -Mehdi Amini on the llvm-dev list last week)

[tkelman]

Debian already packages multiple versions of llvm

Ah, sorry, I was not aware they had started doing this. That's good news.

The real issue is that older versions of llvm will be removed from Debian at some point because the maintainers do not have infinite capacity.

That's understandable, but that will have to mean also removing other software from Debian when switching to different versions of LLVM is not possible or undertested or not recommended.

I don't know what upstream will think about the idea of LTS releases. Other downstream projects might agree it would be a good idea, but if they're fine with vendoring a local copy with specific patches needed to fix project-dependent bugs (which nearly every downstream consumer of LLVM does today) then it's a question of who will volunteer to do the continued maintenance. Right now there's no formal "end of life" for LLVM releases as far as I know, they just move on to the next minor release after one, or maybe two, backport point releases.