00:29:41  * node-ghjoined
00:29:41  * node-ghpart
00:54:22  * Fishrock123joined
00:58:53  * Fishrock123quit (Ping timeout: 250 seconds)
01:18:12  * Fishrock123joined
01:31:09  * node-ghjoined
01:31:09  * node-ghpart
01:50:19  * Fishrock123quit (Quit: Leaving...)
02:05:24  * node-ghjoined
02:05:24  * node-ghpart
02:39:10  * xadillaxjoined
02:40:55  * gibfahn_quit (Quit: Connection closed for inactivity)
04:12:22  * xadillaxquit (Remote host closed the connection)
04:42:46  * xadillaxjoined
04:47:05  * xadillaxquit (Ping timeout: 240 seconds)
05:24:38  * xadillaxjoined
05:37:05  * xadillaxquit (Ping timeout: 250 seconds)
05:38:41  * xadillaxjoined
07:17:11  * seishunjoined
07:52:04  * seishunquit (Ping timeout: 258 seconds)
08:24:30  * gibfahn_joined
09:06:05  * xadillaxquit (Remote host closed the connection)
09:18:57  * sgimeno_changed nick to sgimeno
09:42:50  <Trott>test-requireio_continuationlabs-debian7-arm_pi1p-1 has 9 consecutive build failures. Example: https://ci.nodejs.org/job/node-test-binary-arm/RUN_SUBSET=4,label=pi1-raspbian-wheezy/11622/console
09:42:57  <Trott>rvagg: joaocgreis ^^^
09:43:14  <Trott>https://www.irccloud.com/pastebin/T4d4dHfU/
09:43:24  * zkatquit (*.net *.split)
09:43:24  * orangemochaquit (*.net *.split)
09:43:25  * ofrobotsquit (*.net *.split)
09:43:25  * thefourtheyequit (*.net *.split)
09:43:46  <Trott>I've taken it offline.
09:43:53  <rvagg>Looks like a zombie. Will fix, thanks Trott.
09:45:27  * tniessenquit (Ping timeout: 240 seconds)
09:45:46  * tniessenjoined
09:46:01  <rvagg>yeah, zombie, killed, cleaning workspace and will bring it back online
09:49:03  * zkatjoined
09:49:04  * orangemochajoined
09:49:04  * ofrobotsjoined
09:49:04  * thefourtheyejoined
10:06:29  * xadillaxjoined
10:10:36  <Trott>It looks like we may have a problem with test-rackspace-freebsd10-x64-1. It's last three builds have stalled. jbergstroem
10:11:03  <Trott>Most recent build was https://ci.nodejs.org/job/node-test-linter/13348/ which ran for 22 hours before I cancelled it.
10:11:10  * xadillaxquit (Ping timeout: 264 seconds)
10:11:20  <Trott>Here's the console output:
10:11:23  <Trott>https://www.irccloud.com/pastebin/5nFJuOjP/
10:11:53  <Trott>Prior to that https://ci.nodejs.org/job/node-test-linter/13341/ ran for over an hour before being canceled. Similar console output there too.
10:12:25  <Trott>And prior to that https://ci.nodejs.org/job/node-test-linter/13330/ ran for over 6 hours before being canceled.
10:12:48  <Trott>Console log is a tiny bit different there, I think:
10:12:50  <Trott>https://www.irccloud.com/pastebin/sfwdsuNT/
10:13:21  <Trott>Might be a hung process or something? Anyway, I'm going to take it offline, but if someone could take a look at it, that would be awesome.
10:15:35  * xadillaxjoined
10:26:32  <Trott>Hmmm....now everything is failing hard on git immediately. I hope that host I just took offline wasn't special. ???
10:26:54  * xadillaxquit (Ping timeout: 246 seconds)
10:28:31  <Trott>I'll bring it back online and see if that fixes anything....
10:29:27  <Trott>Nope, everything is still on fire.
10:29:51  <rvagg>refack: test-rackspace-win2012r2-x64-1 is offline for "testing", that's still current status? just checking that it wasn't forgotten
10:30:01  <Trott>All (or nearly all) CI hosts are unable to do git checkouts and therefore failing hard.
10:30:49  <rvagg>Trott: link? my jobs are looking ok
10:31:14  <Trott>rvagg: This started within the last 5 or 10 minutes.
10:31:22  <Trott>Here's a node-daily-master I just kicked off: https://ci.nodejs.org/job/node-test-commit/13859/
10:31:32  <rvagg>whoa
10:32:05  <rvagg>problems local to test-packetnet-ubuntu1604-x64-1 I think
10:34:41  <rvagg>ugh, nvm has been "installed" on this host
10:34:47  <rvagg>some citgm job perhaps
10:34:52  <rvagg>it's messing stuff up
10:34:55  <rvagg>cause it's in .bashrc
10:36:35  * node-ghjoined
10:36:36  * node-ghpart
10:55:15  * gibfahn_quit (Quit: Connection closed for inactivity)
10:59:17  <rvagg>crud, accidentally upgraded jenkins before the existing jobs finished
10:59:22  <rvagg>sorry if you're missing jobs now
11:04:28  * xadillaxjoined
11:08:38  <Trott>:-D
11:13:19  <rvagg>Trott: reran your node-daily-master @ https://ci.nodejs.org/job/node-test-commit/13862/
11:13:40  <Trott>👍
11:18:15  * xadillaxquit (Remote host closed the connection)
11:25:12  * mylesborinsquit (Quit: farewell for now)
11:25:42  * mylesborinsjoined
11:29:40  * node-ghjoined
11:29:41  * node-ghpart
11:29:55  * node-ghjoined
11:29:55  * node-ghpart
11:30:44  * node-ghjoined
11:30:44  * node-ghpart
11:31:14  * node-ghjoined
11:31:14  * node-ghpart
11:33:02  * node-ghjoined
11:33:02  * node-ghpart
11:34:02  * node-ghjoined
11:34:02  * node-ghpart
11:34:31  * node-ghjoined
11:34:31  * node-ghpart
11:34:45  * node-ghjoined
11:34:45  * node-ghpart
11:35:50  * node-ghjoined
11:35:51  * node-ghpart
11:36:15  * node-ghjoined
11:36:15  * node-ghpart
11:48:55  * xadillaxjoined
11:53:31  * xadillaxquit (Ping timeout: 268 seconds)
12:02:19  <Trott>rvagg: Since you were reminding refack of an offline machine... You've seen this thing that maclover7 set up, right? Not sure if it's useful to you, but I sure find it helpful: http://node-build-monitor.herokuapp.com/ I imagine if I understood Jenkins better, I might know how to quickly/easily get that info in Jenkins. Or maybe not. But I just go there....
12:02:48  <rvagg>nope, haven't seen that
12:03:13  <rvagg>there's a script in build/tools/jenkins-status that I run regularly to find out what the status of workers is
12:05:58  <Trott>It's pretty cool to go to the web page, see on the left that the build queue for Foo OS is really big, and be able to scan on the right to see how many Foo OS machines are offline.
12:22:02  * node-ghjoined
12:22:02  * node-ghpart
12:32:15  <rvagg>Trott: not seeing anything on the left, no links except for the "fork on github" one: Build Queue () Offline Machines (). Perhaps it's busted?
12:33:30  <rvagg>💤 for me
12:59:01  * node-ghjoined
12:59:02  * node-ghpart
14:23:07  * evanlucasjoined
14:29:13  * node-ghjoined
14:29:13  * node-ghpart
14:38:05  * Guest1466joined
14:48:11  <maclover7>rvagg: it uses jenkins api, which can sometimes be pretty slow
14:50:29  * Guest1466quit (Ping timeout: 252 seconds)
14:50:51  <maclover7>jenkins sec release today: https://jenkins.io/security/advisory/2017-11-08/
14:51:03  <maclover7>doesn't look too bad, but probably worth it to upgrade at some point
15:41:41  * seishunjoined
15:49:11  * node-ghjoined
15:49:11  * node-ghpart
16:07:28  * seishunquit (Ping timeout: 248 seconds)
16:31:06  * Fishrock123joined
16:40:21  * seishunjoined
17:39:21  * gibfahn_joined
17:45:21  * apapirovskijoined
17:45:34  <apapirovski>Could someone look at the benchmark machine? Seems to be down or something... https://ci.nodejs.org/computer/test-nearform_intel-ubuntu1604-x64-1/ — no clue how to interpret that
17:45:54  <refack>Checking
17:47:29  <apapirovski>thanks refack
18:10:11  * Fishrock123quit (Remote host closed the connection)
18:10:48  * Fishrock123joined
18:14:59  * Fishrock123quit (Ping timeout: 250 seconds)
18:28:25  <refack>apapirovski: it's working now... (I didn't do anything except login as `ps` to see that the Jenkins agent _was_ running)
18:29:26  <ljharb>rvagg: hm, why would nvm being simply installed mess anything up?
18:30:33  <ljharb>(commented on the issue)
18:30:41  * node-ghjoined
18:30:41  * node-ghpart
18:30:57  <refack>rvagg: RE test-rackspace-win2012r2-x64-1 test is done, machine back online
18:31:21  * node-ghjoined
18:31:21  * node-ghpart
18:33:11  <ljharb>(sorry for the double-comment, deleted the second one)
18:37:47  * node-ghjoined
18:37:48  * node-ghpart
18:40:18  * Fishrock123joined
18:42:41  * node-ghjoined
18:42:41  * node-ghpart
18:43:18  <ljharb>refack: are you setting -e or something?
18:43:33  <refack>yes since it's CI
18:43:47  <refack>Just posted a PR for nvm
18:44:03  <ljharb>that shouldn't be set until after nvm is sourced.
18:44:06  <ljharb>there's no way around that.
18:44:32  <refack>sure, but we don't want it lingering after job is completed
18:45:27  <refack>the case was
18:45:28  <refack>1) just installs nvm (touches global profile)
18:45:28  <refack>2) cleanup (nvm directory removed)
18:45:28  <refack>3) new job borkes because profile return 1
18:45:34  <refack>1) *job
18:45:44  <ljharb>right, but i'm saying the issue is that "-e should not be set"
18:45:56  <ljharb>if you want to set -e, you have to do it after those nvm sourcing lines.
18:46:49  <ljharb>"it's CI so -e should be set" isn't necessarily an automatic thing. setting -e is a blunt instrument.
18:47:00  <refack>True
18:47:10  <refack>So the job that uses nvm works fine
18:47:15  <ljharb>so the fix isn't to change nvm; it's to set -e at the appropriate time
18:47:20  <ljharb>right but where is set -e set?
18:47:23  <gibfahn_>Why can't you use nvm with set -e ?
18:47:25  <ljharb>if anywhere, it should be the last line
18:47:34  <gibfahn_>Jenkins runs all scripts with `/bin/sh -ex` by default
18:47:44  <ljharb>ok so theoretically, even with set -e, those lines should never exit 1
18:47:44  <refack>But we don't want jobs to change global machine state
18:47:55  <ljharb>because they're in conditions; set -e ignores those.
18:47:56  <refack>And yes we use blunt tools, cause we're lazy
18:48:07  <ljharb>Mac OS's stock bash in particular has a known bug around that
18:48:14  <ljharb>i'm not sure why any other OS would be running into it tho
18:48:31  <ljharb>`set -e; [ -s "nonexistent-dir/some-file" ]` should work just fine.
18:48:43  <ljharb>(based on my understanding of posix -e)
18:49:15  <refack>I don't think there's a problem in nvm, we were using it wrong
18:49:18  <ljharb>but either way, if your global machine state has -e enabled, i'd say that's an incorrect thing - it comes with caveats
18:49:36  <ljharb>refack: right but having those lines in your profile, with a nonexistent nvm dir, isn't wrong - those lines have (for years) been designed to no-op in that scenario.
18:49:50  <refack>the PR is extra safty if you do `[ -e 'foo'] && bar.sh || true`
18:50:03  <refack>no -e is per job
18:50:21  <ljharb>yes but i don't want to clutter up everyone's profile files, and complicate the code that detects if those lines are already present or not, just because *one user on the internet* has this specific problem
18:50:50  <ljharb>i get lots of set -e bug reports, and fix them (since i don't use set -e but many do) but i've never once had this one; so i'm particularly confused :-/
18:51:06  <refack>np, PR's are meant to be review and rejected if not congruent with project goals
18:52:06  <refack>Jan fixed the job anyway
18:52:15  <ljharb>well i don't want to cause issues with node :-p
18:53:28  <refack>I just pinged you cause I'm too lazy to RTFM
18:53:41  <refack>But Jan knows what he is doing
18:53:58  <ljharb>lol np
18:54:43  <gibfahn_>ljharb: sounds like it's all sorted from our end, but I think if those two lines had an `|| true` that would fix the "doesn't work with -e" problem.
18:55:28  <gibfahn_>It's the difference between `if [ -s 'foo' ]; then bar; fi`, and `[ -s foo ] && bar`
18:56:57  <refack>but if ljharb doesn't get a lot of issues with that I wouldn't change it. being a minimalist with installer script is very prudent
18:57:31  <refack>BTW we are such purists that we don't have npm or even node installed on the CI bots
18:57:46  <gibfahn_>That's to save us from accidentally testing the wrong node though
18:58:06  <gibfahn_>Which we would otherwise do all the time 😁
19:01:30  <ljharb>gibfahn_: right, but the || true isn't even necessary, because by POSIX, set -e *ignores* conditional checks.
19:01:36  <ljharb>ahhh hm
19:01:51  <ljharb>are you saying that set -e ignores it in `if`, but not in the `&&` scenario?
19:01:54  <gibfahn_>Yes, but `[ -s blah ]` isn't a conditional check
19:01:55  <gibfahn_>YEah
19:01:57  <ljharb>hmm
19:02:02  <gibfahn_>That's caught me out like six times...
19:02:05  <ljharb>that would explain this, but that doesn't mesh with my understanding
19:02:12  <gibfahn_>Because `[` is just an alias for `test`
19:02:14  <ljharb>it also wouldn't explain why i've never once had this report
19:02:23  <ljharb>right, i thought that set -e ignored `test`
19:02:24  <ljharb>not `if`
19:03:52  <gibfahn_>I guess most people don't set -e before running their ~/.bashrc
19:04:33  <gibfahn_>If I do `bash; set -e; [ "" ]`, it kills the bash shell
19:12:29  <ljharb>gotcha
19:12:35  <ljharb>perhaps node's CI should do what most people do? :-p
19:12:56  <gibfahn_>Definitely
19:13:22  <refack>We're a little limited by Jenkins. I'd say we should not use `~/.bashrc` at all
19:13:42  <refack>If needed source it directly
19:14:03  <gibfahn_>Well we can do that, just make ~/.bashrc non-readable by the `iojs` user
19:14:31  <refack>then we can't source it
19:14:43  <refack>I think we can /etc/bashrc it away
19:14:57  <gibfahn_>But when do we need to source it?
19:15:30  <refack>🤷 keeping our options open
19:15:43  <refack>maybe if we install nvm or npm
19:16:09  <ljharb>you should be able to install nvm everywhere and just opt not to use it, but that might not be palatable
19:16:40  <gibfahn_>My issue is that nvm is too easy to use
19:16:48  <ljharb>lol, thanks?
19:16:52  <gibfahn_>So I feel like we'd end up with an nvm node in the path when we didn't mean to
19:17:01  <gibfahn_>Yeah, definitely a compliment, I use nvm myself
19:17:02  <refack>We tend to keep the global state of the machine to a minimum, and jobs be self sufficient
19:17:15  <ljharb>well, i mean, you could install it everywhere but make NVM_DIR world-non-writable, with no installed nodes
19:17:16  <refack>MAybe now that we have the setup documented we can change that
19:17:24  <ljharb>then `nvm install` would fail and `nvm use` wouldn't do anything
19:17:50  <gibfahn_>But then how would we use it?
19:17:53  <refack>I mean the more steps that are done once per machine are easy to forget
19:18:09  <ljharb>gibfahn_: it'd be writable for the jobs that needed it
19:18:19  <ljharb>but the default would be "you can't use it"
19:18:23  <refack>I just found one, that the AIX machine have never run the tests in parallel, only 1 proc at a time
19:30:36  <gibfahn_>ljharb: yeah, something for us to consider
19:31:09  <gibfahn_>And actually I'm totally wrong about `set -e` and `[ foo ] && bar`, it doesn't fail if `[ foo ]` fails: https://unix.stackexchange.com/questions/312631/bash-script-with-set-e-doesnt-stop-on-command
19:31:15  * apapirovskiquit (Remote host closed the connection)
19:32:10  * apapirovskijoined
19:35:11  <gibfahn_>It's actually a bit mental, basically the `[ foo ] && bar` doesn't exit the shell when you have `set -e`, but it does return `1`.
19:35:11  <gibfahn_>So if you have `[ "" ] && foo` as the last line of a script you execute (e.g. your bashrc), and the parent shell has `set -e`, then the parent shell will exit as the subshell returned 1.
19:38:45  * chorrelljoined
19:40:40  <ljharb>(-‸ლ)
19:40:50  <ljharb>ok so the issue here was just that the nvm lines were the last lines in bashrc?
19:40:55  <gibfahn_>Yes
19:41:13  <ljharb>aha, ok thank you. that makes *so much* more sense
19:41:26  <ljharb>so the fix is to add `?:` as the last line in bashrc, or something :-p
19:42:03  * Fishrock123quit (Remote host closed the connection)
19:42:40  * Fishrock123joined
19:46:51  * Fishrock123quit (Ping timeout: 250 seconds)
19:47:53  * apapirovskiquit (Remote host closed the connection)
19:52:53  * Fishrock123joined
19:57:46  <gibfahn_>Yeah, something like that
19:58:05  <gibfahn_>Actually I raised it as a PR, more so it's written down in case I forget in the future than because it should land: https://github.com/ljharb/nvm/pull/3
19:58:35  <gibfahn_>And of course I raised it against your fork 🤦‍♂️
19:59:04  <ljharb>lol yeah
19:59:08  <ljharb>and refack already opened that PR against the main one
19:59:12  <gibfahn_>Great
19:59:36  <ljharb>but i still don't think that's a good solution.
20:00:05  <gibfahn_>Why not (out of curiosity)?
20:00:20  * chorrellquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
20:00:25  <ljharb>10:50:21 AM <ljharb> yes but i don't want to clutter up everyone's profile files, and complicate the code that detects if those lines are already present or not, just because *one user on the internet* has this specific problem
20:00:39  <ljharb>mainly that the format of those lines hasn't changed in a long time
20:00:48  <gibfahn_>Yeah okay, that makes sense
20:00:49  <ljharb>and changing them will add a lot of complexity, or churn for users, to nvm
20:01:03  * apapirovskijoined
20:02:00  <gibfahn_>Yeah, makes sense.
20:02:17  <refack>I'm learning also... That's why everything you want to expose from `.bashrc` has to use `export`... Since it's run as a subsshell
20:03:48  <gibfahn_>If I do `a=1` in my `~/.bashrc`, then `bash`, then `echo $a`, I get 1
20:04:32  <refack>Ok kill me now
20:05:09  <refack>And I thought `cmd` was cray-cray
20:05:12  <gibfahn_>Look how simple it is: https://www.gnu.org/software/bash/manual/html_node/Bash-Startup-Files.html
20:28:59  * chorrelljoined
20:53:04  * node-ghjoined
20:53:04  * node-ghpart
21:20:29  * Fishrock123quit (Remote host closed the connection)
21:26:21  * evanlucasquit (Remote host closed the connection)
21:32:34  * seishunquit (Ping timeout: 268 seconds)
21:35:15  * seishunjoined
21:59:52  * Fishrock123joined
22:08:50  * chorrellquit (Quit: Textual IRC Client: www.textualapp.com)
22:12:13  * node-ghjoined
22:12:13  * node-ghpart
22:30:28  * Fishrock123quit (Remote host closed the connection)
22:33:44  * node-ghjoined
22:33:44  * node-ghpart
22:36:32  * node-ghjoined
22:36:32  * node-ghpart
22:38:48  * Fishrock123joined
22:45:15  <refack>@rvagg you mentioned at one of the meeting some lightweight hosts we could use for various tasks.
22:46:09  <refack>Are they easy to purge/recycle? I'm thinking we should only use such hosts for beta testing jobs.
22:48:03  <rvagg>refack: umm, perhaps I was talking about the jenkins-workspace hosts? they're just atom machines
22:48:15  <rvagg>refack: I could fire up something extra just for testing if you want
22:49:29  <rvagg>not as easy to purge and reprovision on packet.net where the jenkins-workspace machines are cause they are bare-metal so you have to delete & reprovision from scratch. Perhaps DO though, we could have a host we can re-apply original image to if needed
22:49:37  <rvagg>depends on what you're actually looking for
22:49:48  <refack>I'm thinking something like a docker container that's easy even for people with `test` access to recycle, something we can call `jenkins-beta` so that testing won't affect real bots
22:54:11  * node-ghjoined
22:54:12  * node-ghpart
23:17:02  * seishunquit (Ping timeout: 260 seconds)
23:22:18  * node-ghjoined
23:22:18  * node-ghpart
23:28:28  * node-ghjoined
23:28:28  * node-ghpart
23:40:11  * apapirovskiquit (Remote host closed the connection)
23:55:12  * apapirovskijoined