[3.9 Release] Release Candidate 2 has been tagged

Project Infrastructure Release Testers
#1

Dear testers,

3.9.0-rc2 was just tagged from the 3.9 branch at r279183.

This is a release candidate in the very real sense that if nothing new
comes up, this is be what the final release looks like. There are
currently no open release blockers, and no patches in my merge-queue.

Please build, test, and upload binaries to the sftp. Let me know how
everything goes.

From this point, the branch is only open for fixing critical problems

(bad enough to warrant another test cycle) and release notes.

Thanks,
Hans

#2

Hi,

All good on AArch64 - we've uploaded the binaries.

Regards,
Diana

#3

Thanks! Can you post the sha1's for the files you uploaded?

Windows and Mac look good. Uploaded:
ca26fbfabb54ac1f70776ab3a5503313ec518f18
clang+llvm-3.9.0-rc2-x86_64-apple-darwin.tar.xz
26d616e1355dc0802f90babbd5ea0b72abc0c0bb LLVM-3.9.0-rc2-win32.exe
42363aeaff395d442f418d77b542a088b5b0658b LLVM-3.9.0-rc2-win64.exe

Thanks,
Hans

#4

When I tested rc1 I found that some of the test suite wouldn’t build on SLES11.3 as a consequence of changes to the tests. At least some of the msan tests have been changed leverage features of glibc newer than is available on this platform.

I asked about a minimum-required glibc but didn’t hear back. Is the minimum required glibc for 3.9 different from 3.8?

When I tried rc1 on sles11.3 x86_64, msan’s getrlimit test fails to build for lack of prlimit(). SLES11.3 has glibc 2.11.3. Is there a minimum required glibc? I think this test implementation previously used getrlimit(), which is present on glibc2.11.3.

#5

+Evgenii for msan.

I suspect the community simply doesn't keep track of what glibc
version is required :-/

#6

$ sha1sum
ecd0387db850c1382839dec11c60806f3829953f
clang+llvm-3.9.0-rc2-aarch64-linux-gnu.tar.xz

#7

It's a test for the new interceptor for prlimit.
It could be disabled with __GLIBC_PREREQ for 2.13+.

#8

r279352

#9

ARM binaries good, uploaded.

$ sha1sum
2de75ce9a302df58bbfc0e96583c2ba4f12fc0ce
clang+llvm-3.9.0-rc2-armv7a-linux-gnueabihf.tar.xz

cheers,
--renato

#10

Hi,

built successfully and passed initial tests on OpenMandriva x86_64, aarch64, i586 and armv7hnl.

ttyl

bero

#11

Compiled everything just fine on FreeBSD 10 now, testing went OK except
for the two threadsanitizer failures (hangs) I already reported for rc1.
These aren't going to fixed before the release, so I'll ignore them.

Uploaded:

SHA256 (clang+llvm-3.9.0-rc2-i386-unknown-freebsd10.tar.xz) = eb529244055e45d0781b4259e286b5be3b8f044e6d3e65dbf67b597441292ef4
SHA256 (clang+llvm-3.9.0-rc2-amd64-unknown-freebsd10.tar.xz) = 367ce05bea07be6697418518445c8dc5156f6dd288a4e3397ff7f17b2d009abf

-Dimitry

#12

Seems to work great on Debian.
https://buildd.debian.org/status/package.php?p=llvm-toolchain-3.9&suite=experimental
A bit surprised to see include fixer coming in the second rc but why not.

However, still the same issue on armel:
http://lists.llvm.org/pipermail/llvm-dev/2016-August/103457.html

Sylvestre

#13

Everything looks fine on x86_64 Ubuntu 16.04:
084c2a9e5cf29cb5e68a48596a0c0232 clang+llvm-3.9.0-rc2-x86_64-linux-gnu-ubuntu-16.04.tar.xz

I had some issues running LNT, so I updated everything, but I still get this error:

--- Tested: 2490 tests --
2016-08-22 10:36:13 ERROR: Subprocess failed with:Traceback (most recent call last):
   File "/home/ben/development/llvm/lnt/lnt/util/async_ops.py", line 125, in async_wrapper
     _v4db = current_app.old_config.get_database(ts_args['db'])
   File "/home/ben/development/llvm/sandbox/lib/python2.7/site-packages/Werkzeug-0.9.4-py2.7.egg/werkzeug/local.py", line 338, in __getattr__
     return getattr(self._get_current_object(), name)
   File "/home/ben/development/llvm/sandbox/lib/python2.7/site-packages/Werkzeug-0.9.4-py2.7.egg/werkzeug/local.py", line 297, in _get_current_object
     return self.__local()
   File "/home/ben/development/llvm/sandbox/lib/python2.7/site-packages/Flask-0.10.1-py2.7.egg/flask/globals.py", line 34, in _find_app
     raise RuntimeError('working outside of application context')
RuntimeError: working outside of application context

It doesn't seem to have prevented the LNT results from being stored.

Ben

#14

Fedora and openSUSE binaries uploaded.

f97ac971c1ef746d108068dec971fff0c77dd304 clang+llvm-3.9.0-rc2-i586-opensuse13.2.tar.xz
6863cb1a14dd51c6a6c2bb7fa8774d93de34204d clang+llvm-3.9.0-rc2-i686-fedora23.tar.xz
7cdc68541fba273b459b6f3b0c8dda5f9ec2a033 clang+llvm-3.9.0-rc2-x86_64-fedora22.tar.xz
5480f4a87515cc2e22bd0e3d38b6bb8f75826ee9 clang+llvm-3.9.0-rc2-x86_64-opensuse13.2.tar.xz

#15

Awesome, thanks!

#16

Dear testers,

3.9.0-rc2 was just tagged from the 3.9 branch at r279183.

This is a release candidate in the very real sense that if nothing new
comes up, this is be what the final release looks like. There are
currently no open release blockers, and no patches in my merge-queue.

Please build, test, and upload binaries to the sftp. Let me know how
everything goes.

From this point, the branch is only open for fixing critical problems
(bad enough to warrant another test cycle) and release notes.

Seems to work great on Debian.
https://buildd.debian.org/status/package.php?p=llvm-toolchain-3.9&suite=experimental
A bit surprised to see include fixer coming in the second rc but why not.

It was already being built, tested and in the release notes, but the
binary wasn't part of the 'install' target so we just fixed that part.

However, still the same issue on armel:
http://lists.llvm.org/pipermail/llvm-dev/2016-August/103457.html

:frowning: Not a 3.9 regression though.

#17

I can't find this on the sftp; only rc1 seems to be there:

pwd

Remote working directory: /uploads

ls *3.9.0*aarch*

clang+llvm-3.9.0-rc1-aarch64-linux-gnu.tar.xz

#18

Thanks!

Is there a reason the x86_64 fedora package is for Fedora 22 instead of 23?

- Hans

#19

Good catch, that was my bad, I’ll upload the new one soon.

#20

Fixed 519dc6b9825578c00475463158e0a7181a946b23 clang+llvm-3.9.0-rc2-x86_64-fedora23.tar.xz