Release proposal: v1.45.0

[vtjnash]

There have been lots of features (and a few bug fixes), so I propose we make a new release. Anything we should still try to get in first however?

• unix: DRY and fix tcp bind error path #3904
• uv_barrier_wait does not always drain waiting threads #3872

[vtjnash]

CI: https://ci.nodejs.org/view/libuv/job/libuv-test-commit/

[vtjnash]

Some observations on these results

on freebsd:
CI host seems broken (fails to start, too old)

on smartos:

not ok 148 - ip6_addr_link_local
# exit code 6
# Output from process `ip6_addr_link_local`:
# Assertion failed in test/test-ip6-addr.c on line 75: 0 == uv_if_indextoname(iface_index, scoped_addr, &scoped_addr_len)

not ok 205 - pipe_try_write_1 (and pipe_try_write_2)
# exit code 134
# Output from process `pipe_try_write_1`:
# Assertion failed in test/test-pipe-try-write.c on line 44: `nread == (ssize_t)buf->len` (4 == 256)

on aix72-xlc-ppc64, platform lacks support for C11 and should be removed from the build matrix

"src/unix/async.c", line 29.10: 1506-296 (S) #include file <stdatomic.h> not found.

IBMI

• root (0) user is not named qsecofr
• libc returns an error when querying information about the current user's group

VS2015 and older platforms are deprecated (afaik) and should be removed from the build matrix

18:03:53 C:\workspace\libuv-test-commit-windows-cmake\test\test-fs.c(1562): error C2065: 'S_IFIFO': undeclared identifier [C:\workspace\libuv-test-commit-windows-cmake\out\uv_run_tests_a.vcxproj]

AIX, seems to have a linker error, doing something non-obvious with the -l:libuv.a flag that I cannot quite interpret here:

2/2 Test #2: uv_test_a ........................***Failed    0.03 sec
Could not load program /home/iojs/build/workspace/libuv-test-commit-aix-cmake/nodes/aix71-ppc64/out/cmake/uv_run_tests_a:
	Dependent module libuv.a(libuv.so.1) could not be loaded.
Could not load module libuv.a(libuv.so.1).
System error: No such file or directory

[vtjnash]

Hm, actually VS2015 should still be supported. But seems like #3811 might have an issue with the polyfill on that constant for the test file.

[bnoordhuis]

The C11 issue is #3714 but that seems to have stalled, cc @richardlau (also for the link error.)

cc @libuv/ibmi and @libuv/illumos for the test failures on those platforms. Tier 2 and 3 resp. so neither needs to hold up the release.

The freebsd error happens during the autoconf step. I'm declaring it "not our bug."

ld-elf.so.1: /usr/local/lib/perl5/5.32/mach/CORE/libperl.so.5.32: Undefined symbol "strerror_l@FBSD_1.6"

I'll take a look at the vs2015 build error (edit: #3918)

[citrus-it]

Thanks for the ping, I've confirmed the illumos test failures on OmniOS, and I'll take a look at them today:

not ok 148 - ip6_addr_link_local
not ok 205 - pipe_try_write_1
not ok 206 - pipe_try_write_2

[citrus-it]

The first one (ip6_addr_link_local) seems to be a bug in illumos, or at least a difference between illumos and other platforms that we should remove. I opened https://www.illumos.org/issues/15465 to address this.

[bnoordhuis]

@vtjnash can we do the release sometime this week?

[thynson]

Since Ubuntu 18.04 will be EOL soon. Probably it's time to merge #3841? @vtjnash

[santigimeno]

Are we ready for the release or do we want to wait for some other issues/PR? I'm thinking about #3970 and or #3969.

As a side note, I haven't made any release yet but would love to give it a try if that helps moving this forward (is just following https://github.com/libuv/libuv-release-tool/blob/master/README.md, right?)

[vtjnash]

#3969 would be good, or we should release without the bad set of commits, so this does not have a temporary correctness regression there for the sake of performance

#3970 seems worth waiting for, as it sounds quick, but no more than a couple days.

Yes, the release checklist should contain everything required (it is a fairly automated process), just be sure you have an up-to-date autotools installed (it will check), the build is working okay on your machine, and you have your GPG key handy to sign it (it will be automatic too, but may stall without much prompting while waiting for it).

[kadler]

IBMI

• root (0) user is not named qsecofr
• libc returns an error when querying information about the current user's group

FYI UID 0 on IBM i is called QSECOFR and not all users are members of groups (and there's no gid 0). This looks like the tests need to be adjusted for proper expectations on IBM i.

@abmusse can you look in to updating these tests? The second test will be more tricky to fix since it would require adding the user to a group (not sure which user it's checking) on the test systems. If it's QSECOFR, IIRC you can't add it to a group so we'd have to just skip the test.

[abmusse]

@kadler

Got your ping. I will look into fixing these up

[santigimeno]

Yes, the release checklist should contain everything required (it is a fairly automated process), just be sure you have an up-to-date autotools installed (it will check), the build is working okay on your machine, and you have your GPG key handy to sign it (it will be automatic too, but may stall without much prompting while waiting for it).

Thanks for the info. Let's see if we can have those issues solved by the end of the week and I'll proceed with the release.

[sivadeilra]

It would be great if #3973 could make it into this release. It's a simple fix for a crashing issue.

[santigimeno]

It would be great if #3973 could make it into this release. It's a simple fix for a crashing issue.

Yes, that's the plan

[santigimeno]

I'm almost done with this but got this error:

Command failed: ssh libuv@dist.libuv.org mkdir -p ~/www/dist/v1.45.0
ssh: connect to host dist.libuv.org port 22: Network is unreachable

Any idea what's going on? /cc @cjihrig @vtjnash

[cjihrig]

I'm getting the same error. @richardlau is this something managed by the Node Build WG?

[richardlau]

I'm getting the same error. @richardlau is this something managed by the Node Build WG?

I wasn't sure, but searching build's repo shows we have an nginx config for dist.libuv.org so it would seem it is. My guess is that it's the firewall we had to put around the nodejs.org download server a while ago to mitigate DDOS and this is the first libuv release that has been done since then. If that's the case then someone from Node.js' build-infra team will either need to add @santigimeno 's (or whoever is doing the release) IP address to the firewall or provide the name of the jump host that was set up (Node.js' release team should be aware of the jump host name) -- I'm not on my work laptop so can't log into the server/look up the jump host name at the moment.

[santigimeno]

Ok, we have identified the jump machine and now I can reach dist.libuv.org. The problem now seems we need to add my key to the server so I can get access. Any idea what was the process used in the past to do this? /cc @libuv/collaborators

[bnoordhuis]

I suspect @cjihrig or @vtjnash can copy over your key. (Maybe I can too but it's been a really long time.)

[santigimeno]

For transparency sake, neither Ben nor Colin could access the dist host via the jump machine. I'm going to open an issue in the nodejs build repo to see if we can move this forward.

Aside this, has it been considered to publish our assets somewhere else (I'm thinking github specifically)?

[santigimeno]

Opened nodejs/build#3353

[santigimeno]

On top of the infra issue I think it might be a good idea to wait for #3952 (comment) to be solved.

[santigimeno]

I think we're good now. Unless there are objections I'll cut the release tomorrow.

[santigimeno]

CI: https://ci.nodejs.org/view/libuv/job/libuv-test-commit/2267/
https://ci.nodejs.org/view/libuv/job/libuv-in-node/221/

[vtjnash]

It looks like some of the bots are still using the leaked github keys, so those are failing:

17:44:05 ERROR: Error cloning remote repo 'origin'
17:44:05 hudson.plugins.git.GitException: Command "git fetch --tags --force --progress -- git@github.com:libuv/libuv.git +refs/heads/*:refs/remotes/origin/*" returned status code 128:
17:44:05 stdout: 
17:44:05 stderr: @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
17:44:05 @    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
17:44:05 @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
17:44:05 IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
17:44:05 Someone could be eavesdropping on you right now (man-in-the-middle attack)!
17:44:05 It is also possible that a host key has just been changed.
17:44:05 The fingerprint for the RSA key sent by the remote host is
17:44:05 SHA256:uNiVztksCsDhcc0u9e8BujQXVUpKZIDTMczCvj3tD2s.
17:44:05 Please contact your system administrator.
17:44:05 Add correct host key in /c/Users/Administrator/.ssh/known_hosts to get rid of this message.
17:44:05 Offending RSA key in /c/Users/Administrator/.ssh/known_hosts:1
17:44:05 Host key for github.com has changed and you have requested strict checking.
17:44:05 Host key verification failed.
17:44:05 fatal: Could not read from remote repository.

[santigimeno]

/cc @richardlau ☝️

[santigimeno]

Ok, I re-run the libuv-in-node modifying the gyp files so it actually worked: https://ci.nodejs.org/view/libuv/job/libuv-in-node/222/. It looks mostly ok. Some things to notice:

• On Windows it fails to build because of undefined reference to a couple of functions: CoTaskMemFree and GetSystemTimePreciseAsFileTime (the latter only happens on nodes=win-vs2019-x86. My guess is that those bots are running unsupported windows versions, but wanted to confirm first. https://ci.nodejs.org/job/node-compile-windows/50882/
• Interestingly on most of the arm bots known_issues/test-vm-timeout-escape-nexttick doesn't fail 🤷‍♂️ https://ci.nodejs.org/job/node-test-binary-armv7l/5836/ , https://ci.nodejs.org/job/node-test-commit-arm-debug/nodes=ubuntu2004_debug-arm64/7760/ and https://ci.nodejs.org/job/node-test-commit-arm/47439/
• On freebsd12 test_uv_errno and test_uv_errmap are failing. Taking a look at those right now. https://ci.nodejs.org/job/node-test-commit-freebsd/49758/

Thoughts?

[richardlau]

It looks like some of the bots are still using the leaked github keys, so those are failing:

17:44:05 ERROR: Error cloning remote repo 'origin'
17:44:05 hudson.plugins.git.GitException: Command "git fetch --tags --force --progress -- git@github.com:libuv/libuv.git +refs/heads/*:refs/remotes/origin/*" returned status code 128:
17:44:05 stdout: 
17:44:05 stderr: @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
17:44:05 @    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
17:44:05 @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
17:44:05 IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
17:44:05 Someone could be eavesdropping on you right now (man-in-the-middle attack)!
17:44:05 It is also possible that a host key has just been changed.
17:44:05 The fingerprint for the RSA key sent by the remote host is
17:44:05 SHA256:uNiVztksCsDhcc0u9e8BujQXVUpKZIDTMczCvj3tD2s.
17:44:05 Please contact your system administrator.
17:44:05 Add correct host key in /c/Users/Administrator/.ssh/known_hosts to get rid of this message.
17:44:05 Offending RSA key in /c/Users/Administrator/.ssh/known_hosts:1
17:44:05 Host key for github.com has changed and you have requested strict checking.
17:44:05 Host key verification failed.
17:44:05 fatal: Could not read from remote repository.

I only found a single host from https://ci.nodejs.org/view/libuv/job/libuv-test-commit/2267/ failing in this way. That's now fixed, but the build is now failing with #3992:
https://ci.nodejs.org/job/libuv-test-commit-windows-cmake/471/nodes=win2012r2-vs2015/console

11:50:39 C:\workspace\libuv-test-commit-windows-cmake\src\win\process.c(1292): error C2065: 'MiniDumpWithAvxXStateContext': undeclared identifier [C:\workspace\libuv-test-commit-windows-cmake\out\uv.vcxproj]

[santigimeno]

I only found a single host from https://ci.nodejs.org/view/libuv/job/libuv-test-commit/2267/ failing in this way. That's now fixed, but the build is now failing with #3992: https://ci.nodejs.org/job/libuv-test-commit-windows-cmake/471/nodes=win2012r2-vs2015/console

11:50:39 C:\workspace\libuv-test-commit-windows-cmake\src\win\process.c(1292): error C2065: 'MiniDumpWithAvxXStateContext': undeclared identifier [C:\workspace\libuv-test-commit-windows-cmake\out\uv.vcxproj]

Do we know what windows version that host is running?

[richardlau]

Windows Server 2012r2.

[santigimeno]

Fix for the FreeBSD issues: #3999

[santigimeno]

CI: https://ci.nodejs.org/view/libuv/job/libuv-test-commit/2268/
and https://ci.nodejs.org/view/libuv/job/libuv-in-node/223/

[vtjnash]

16:20:34 libuv.lib(process.obj) : error LNK2019: unresolved external symbol __imp_CoTaskMemFree referenced in function uv__kill [C:\workspace\node-compile-windows\node\embedtest.vcxproj]

This is nodejs missing some libraries: https://github.com/libuv/libuv/pull/3840/files#diff-49473dca262eeab3b4a43002adb08b4db31020d190caaad1594b47f1d5daa810R76

[vtjnash]

16:19:47 libuv.lib(util.obj) : error LNK2019: unresolved external symbol _GetSystemTimePreciseAsFileTime referenced in function _uv_clock_gettime [C:\workspace\node-compile-windows\node\embedtest.vcxproj]

This name is mangled incorrectly. It makes me suspect the nodejs build is using the wrong macro definition:

https://github.com/libuv/libuv/pull/2821/files#diff-1e7de1ae2d059d21e1dd75d5812d5a34b0222cef273b7c3a2af62eb747f9d20aR101

Someday nodejs needs to stop managing their own copy of the libuv build system, since it leads to a lot of unnecessary problems for them.

[santigimeno]

Thanks @vtjnash. Will try to fix those

[santigimeno]

CI: https://ci.nodejs.org/view/libuv/job/libuv-in-node/226/

[santigimeno]

wasi tests are failing with UVWASI_EINVAL when creating the WASI instance on node-test-commit-windows-fanned. Any ideas? Is this to be expected? @cjihrig

[cjihrig]

No, that is not expected as far as I know.

[santigimeno]

Possible uvwasi fix: nodejs/uvwasi#207

[santigimeno]

Let's see how it goes now: https://ci.nodejs.org/view/libuv/job/libuv-in-node/227/

[santigimeno]

For some reason the artifacts have not been uploaded to the dist server. Looking into fixing that

[santigimeno]

Done

[bnoordhuis]

Nice work, Santi!