00:00:02  * jenkins-monitorquit (Remote host closed the connection)
00:00:18  * jenkins-monitorjoined
00:04:06  * trottquit (Quit: Leaving.)
01:00:01  * jenkins-monitorquit (Remote host closed the connection)
01:00:08  * jenkins-monitorjoined
01:15:28  * jgiquit (Quit: jgi)
01:16:35  * jgijoined
01:25:02  * jgiquit (Quit: jgi)
01:27:12  * jgijoined
01:44:44  * bnoordhuisquit (Ping timeout: 245 seconds)
02:00:01  * jenkins-monitorquit (Remote host closed the connection)
02:00:09  * jenkins-monitorjoined
02:39:53  * jgiquit (Quit: jgi)
02:56:09  * trottjoined
03:00:01  * jenkins-monitorquit (Remote host closed the connection)
03:00:09  * jenkins-monitorjoined
03:33:55  <jbergstroem>so, all osuosl machines down?
03:34:51  <jbergstroem>looked at that admin yesterday, looks like we have a vcpu and ram quota. most of them are 4vcpu/8g ram; how about we make smaller vm's instead? this way we can have more vm's.
03:43:58  <jbergstroem>url was incorrect
03:44:00  <jbergstroem>will fix all
03:45:04  * trottquit (Ping timeout: 250 seconds)
03:53:50  <jbergstroem>our monitor still seems to not work
03:55:51  <jbergstroem>now that we soon (hopefully) can land my patch for changing where tests are stored we need to figure out how we want to pass this. My suggestion is that we set that environment variable per slave. default will Just Work and it should really only have be set if you have path issues
03:58:10  <jbergstroem>if we for instance consistently assume /tmp i reckon we might run into issues with symlinking over multiple filesystems, etc
04:00:02  * jenkins-monitorquit (Remote host closed the connection)
04:00:08  * jenkins-monitorjoined
04:05:55  <jbergstroem>getting timeouts against ci again :/
04:36:22  * trottjoined
04:46:16  * jgijoined
05:00:01  * jenkins-monitorquit (Remote host closed the connection)
05:00:07  * jgiquit (Quit: jgi)
05:00:08  * jenkins-monitorjoined
05:04:50  * trottquit (Ping timeout: 246 seconds)
05:10:29  * jgijoined
05:22:29  * jgiquit (Quit: jgi)
05:42:17  * rmg_joined
05:44:19  * rmgquit (Ping timeout: 245 seconds)
05:47:39  * rmg_quit (Ping timeout: 245 seconds)
05:48:54  * rmgjoined
06:00:01  * jenkins-monitorquit (Remote host closed the connection)
06:00:08  * jenkins-monitorjoined
07:00:02  * jenkins-monitorquit (Remote host closed the connection)
07:00:19  * jenkins-monitorjoined
07:19:49  * rmgquit (Remote host closed the connection)
07:26:50  * rmgjoined
07:31:24  * rmgquit (Ping timeout: 245 seconds)
08:00:01  * jenkins-monitorquit (Remote host closed the connection)
08:00:08  * jenkins-monitorjoined
08:27:31  * rmgjoined
08:32:14  * rmgquit (Ping timeout: 245 seconds)
09:00:01  * jenkins-monitorquit (Remote host closed the connection)
09:00:15  * jenkins-monitorjoined
10:00:02  * jenkins-monitorquit (Remote host closed the connection)
10:00:08  * jenkins-monitorjoined
10:27:36  * bnoordhuisjoined
11:00:02  * jenkins-monitorquit (Remote host closed the connection)
11:00:08  * jenkins-monitorjoined
12:00:02  * jenkins-monitorquit (Remote host closed the connection)
12:00:15  * jenkins-monitorjoined
12:07:54  * bnoordhuisquit (Ping timeout: 260 seconds)
12:29:02  * rmgjoined
12:33:32  * rmgquit (Ping timeout: 246 seconds)
13:00:01  * jenkins-monitorquit (Remote host closed the connection)
13:00:13  * jenkins-monitorjoined
13:25:39  <rvagg>here's a new one: Caused by: java.lang.InternalError: Currency data format is incorrect
13:52:33  <orangemocha>Currency?
14:00:02  * jenkins-monitorquit (Remote host closed the connection)
14:00:14  * jenkins-monitorjoined
14:00:40  <rvagg>restarted jenkins slave on that computer and it seems to have resolved
14:46:59  * chorrelljoined
15:00:01  * jenkins-monitorquit (Remote host closed the connection)
15:00:15  * jenkins-monitorjoined
15:11:51  * bnoordhuisjoined
15:34:29  * bnoordhuisquit (Ping timeout: 246 seconds)
16:00:01  * jenkins-monitorquit (Remote host closed the connection)
16:00:17  * jenkins-monitorjoined
16:09:07  * rmgjoined
16:18:14  * chorrellquit (Quit: My Mac has gone to sleep. ZZZzzz…)
16:40:53  * bnoordhuisjoined
16:45:34  * bnoordhuisquit (Ping timeout: 260 seconds)
16:56:36  * jgijoined
17:00:01  * jenkins-monitorquit (Remote host closed the connection)
17:00:08  * jenkins-monitorjoined
17:13:35  * jgiquit (Quit: jgi)
17:40:38  * jgijoined
17:51:11  * trottjoined
18:00:01  * jenkins-monitorquit (Remote host closed the connection)
18:00:14  * jenkins-monitorjoined
18:01:00  * jgiquit (Quit: jgi)
18:02:15  <rvagg>linter job is very unhappy with v0.10, has this always been the case?
18:05:36  * jgijoined
18:15:04  * bnoordhuisjoined
18:56:34  <orangemocha>rvagg: looking at the same :)
18:56:50  <orangemocha>I know what's going on
18:57:11  <orangemocha>linting was always broken on v0.10, it's something that we never went back to fix
18:57:48  <rvagg>k, I suspected so, just wondering why I'm only seeing it now and I guess it's cause we're not running CI on 0.10 much
18:57:50  <orangemocha>node-test-linter was doing a skip on v0.10, but this was implemented with a combination filter and the NODES_SUBSET argument
18:58:06  <rvagg>ahh
18:58:10  <orangemocha>but at some point, we probably made node-test-linter a non-matrix job..
18:58:14  <orangemocha>to remove one click
18:58:18  <orangemocha>and lost the combination filter
18:58:29  <orangemocha>jbergstroem ^
18:59:04  <orangemocha>so we should look at fixing it either with an explicit skip inside the job, or a check at the node-test-commit level, or making it again a matrix job
18:59:06  <jbergstroem>orangemocha: yes i remember that was suggested
18:59:21  <orangemocha>anyway, it doesn't seem to be a critical issue...
18:59:51  <jbergstroem>argh playback seems broken on my irc setup :(
19:00:01  * jenkins-monitorquit (Remote host closed the connection)
19:00:15  * jenkins-monitorjoined
19:01:01  <orangemocha>probably easiest to modify the script that calls "gmake lint"
19:01:02  * jbergstroemtopic: we're the nodejs build group. https://ci.nodejs.org https://github.com/nodejs/build -- irc logs: http://logs.libuv.org/node-build/latest
19:01:12  <jbergstroem>i can look at it soon
19:01:40  <orangemocha>and if NODES_SUBSET is 0.10 print a message that says "no linting on 0.10" and succeed
19:01:54  <orangemocha>whatever works
19:06:04  <orangemocha>joaocgreis: does the test matrix look right to you on this job run: https://ci.nodejs.org/job/node-test-binary-windows/208/
19:06:34  <orangemocha>all elements in the 1,2,3 columns are "skipped"
19:08:07  <joaocgreis>orangemocha: looks ok. v0.10 and v0.12 do not support the --run option, so it does not make sense to run the same thing 4 times
19:08:22  * chorrelljoined
19:08:27  <orangemocha>ah ok
19:09:23  <orangemocha>some flaky tests not marked as such, otherwise looks good
19:10:45  <jbergstroem>now that we wont have clang-format i'll look at landing my patch that gives cclint fails as tap output
19:13:29  * rmgquit (Ping timeout: 245 seconds)
19:14:03  * rmgjoined
19:22:16  <rvagg>I don't believe jbergstroem sleeps
19:22:56  <jbergstroem>rvagg: just borrowed a few of your clones
19:24:16  <rvagg>bazinga
19:31:52  <orangemocha>rvagg I left some comments on the v0.10 PR. Mostly, it seems that v0.10-staging is missing some commits that are already in v0.10
19:32:11  <rvagg>really?
19:32:14  <rvagg>ugh
19:32:16  <orangemocha>yep
19:32:25  <orangemocha>it doesn't seem right
19:32:41  <orangemocha>the staging branch should be ahead, not behind, right?
19:32:44  <rvagg>yeah
19:33:00  <orangemocha>yes it's wrong
19:33:55  <orangemocha>let me check that I am not doing something wrong on my clone
19:42:21  <rvagg>orangemocha: fixed build_release, checked v0.10 and v0.10-staging and it seems in order to me, I've rebased my PR ontop of v0.10-staging
19:42:41  <rvagg>rebasing v0.10-staging on v0.10 results in no changes, in my clone anyway
19:42:46  <orangemocha>yes sorry, v0.10 and v0.10-staging are fine
19:43:12  <orangemocha>but when I pulled your PR locally, it was missing some changes from v0.10 and v0.10-staging
19:43:18  <orangemocha>I guess it just needed to be rebased
20:00:01  * jenkins-monitorquit (Remote host closed the connection)
20:00:16  * jenkins-monitorjoined
20:11:41  <jbergstroem>reviewing pr now
20:21:57  <rvagg>joaocgreis: trying to get windows-fanned working for the node-private repo and am having credentials problems, could you have a look at this when you have time please? https://ci.nodejs.org/job/git-rebase/1265/console
20:27:04  <joaocgreis>rvagg: two issues
20:27:15  <rvagg>can't have two ssh keys for git ...
20:27:24  <rvagg>should I just add ci@iojs.org to node-private?
20:28:13  <joaocgreis>1) that error is because https://github.com/nodejs-ci does not have read access, you should add him as a collaborator (read access, or write to push temporaries)
20:29:09  <joaocgreis>2) in your job, you're using the default tmp repo, janeasystems/node_binary_tmp, that is public.. you should change it if the sources should remain private
20:29:19  <joaocgreis>it's a parameter in test-commit
20:30:10  <joaocgreis>see you're using a different job, test-commit-private, it should pass TEMP_REPO as some private repo
20:30:24  <joaocgreis>where nodejs-ci has write access
20:31:26  <rvagg>ok, what about making node_binary_tmp private?
20:31:41  <jbergstroem>+1 to that
20:33:25  <rvagg>for now I'm just going to roll with node_binary_tmp, it's a small leakage but the window is equally small
20:33:28  <jbergstroem>another way could be using jenkins itself; we already firewall all runners meaning we can control acl for who gets to download a file
20:39:48  <jbergstroem>rvagg: have you tried building 0.10.x on the smartos-13 machine?
20:40:01  <rvagg>yes, I believe so
20:40:06  <jbergstroem>sweet
20:40:32  <rvagg>pretty sure this comes off smartos-13 https://nodejs.org/download/nightly/v0.10.41-nightly20151203036580393d/
20:40:53  <rvagg>yerp https://ci.nodejs.org/job/iojs+release/307/nodes=smartos13-release/
20:40:53  <jbergstroem>the pre-1-release label i assume
20:40:57  <rvagg>yeah
20:41:05  <jbergstroem>gotcha
20:41:11  <jbergstroem>will add to my ansible inventory
20:42:41  <jbergstroem>if pre-1-release is a minority, perhaps just have post-1-release as default and use "where not pre-1-release"?
20:42:50  <jbergstroem>would remove one label
20:43:06  <jbergstroem>or is the logic more complicated
20:46:56  <rvagg>smartos15 can't be run on pre-1, smartos13 can't be run on post-1, that's the most complicated, I suppose that could be achieved with just one label
20:48:16  <jbergstroem>sweet
20:50:30  <jbergstroem>starting to document all our jenkins labels: https://gist.github.com/jbergstroem/d6e43be07e1d3f0f228e
20:51:42  <jbergstroem>the node will be added to jenkins by ansible, including labels; so one label would be centos6-x64 and one centos6-x64-gcc44.
20:51:55  <jbergstroem>might have to do some exception for pre-1-release then
21:00:01  * jenkins-monitorquit (Remote host closed the connection)
21:00:08  * jenkins-monitorjoined
21:22:52  <rvagg>https://ci.nodejs.org/job/node-test-commit-linux/1404/nodes=centos5-32/console & https://ci.nodejs.org/job/node-test-commit-linux/1404/nodes=centos5-64/console - can't find commit on private git repo, works on all other 0.12 compatible slaves, something's up with centos5
21:28:28  * jgiquit (Quit: jgi)
21:33:22  * trott1joined
21:33:22  * trottquit (Read error: Connection reset by peer)
21:58:34  * chorrellquit (Quit: My Mac has gone to sleep. ZZZzzz…)
22:00:01  * jenkins-monitorquit (Remote host closed the connection)
22:00:07  * jenkins-monitorjoined
22:20:09  * jgijoined
22:41:48  * trott1quit (Quit: Leaving.)
23:00:02  * jenkins-monitorquit (Remote host closed the connection)
23:00:16  * jenkins-monitorjoined
23:12:15  <jbergstroem>rvagg: i'll have a look
23:15:33  <jbergstroem>is it perhaps a git version thing?
23:17:36  <jbergstroem>git version
23:19:06  <jbergstroem>doesn't look like it
23:52:22  <jbergstroem>jgi: hey, have you come to any conclusion regarding using base14 or 15 for smartos releases?
23:53:55  <jgi>jbergstroem: was the question really about base14 vs base15, or about which compiler to use?
23:54:06  <jbergstroem>jgi: both i guess
23:54:36  <jbergstroem>jgi: the older the better imo?
23:54:46  <jgi>jbergstroem: yes, the older the better
23:54:53  <jbergstroem>jgi: so gcc48 on base14?
23:54:56  <jgi>jbergstroem: did you have time to read https://gist.github.com/misterdjules/eae9ec70dc1d91fb8dd1?
23:54:59  <jgi>jbergstroem: yes
23:55:06  <jbergstroem>jgi: yes, i have
23:55:20  <jgi>jbergstroem: ok, if you have any feedback, it’s more than welcome
23:55:33  <jgi>jbergstroem: I’m trying to get a consensus within Joyent on what to do next
23:55:47  <jbergstroem>jgi: my feedback is that we get hold of a solaris machine as quick as possible and separate smartos releases from solaris ones
23:55:59  <jbergstroem>jgi: i've asked a few vm providers out there for a trial
23:56:18  * jenkins-monitorquit (Ping timeout: 260 seconds)
23:56:20  <jbergstroem>jgi: i'll make room on my freebsd vm host just to play around otherwise
23:56:23  <jgi>jbergstroem: right, there’s no question about separating smartos and solaris binaries
23:56:26  * jenkins-monitorjoined
23:56:33  <jgi>jbergstroem: it makes no sense to build solaris binaries on SmartOS
23:56:49  <jbergstroem>jgi: nope, especially with that gist as reference
23:57:36  <jgi>jbergstroem: my remaining question is more about what to do for SmartOS, and I would currently lean towards not shipping binaries for smartos from nodejs.org, and instead provide only pkgsrc packages
23:57:49  <jbergstroem>jgi: ok.
23:58:12  <jgi>jbergstroem: but again, I’m trying to reach out to other people at joyent (packagers, and developers of the C/C++ runtime) to get some feedback on that proposal