00:25:26  * wyattjoined
00:29:29  * wyattquit (Ping timeout: 240 seconds)
01:16:41  * wyattjoined
01:21:23  * wyattquit (Ping timeout: 255 seconds)
01:23:41  * jenkins-monitorquit (Remote host closed the connection)
01:23:52  * jenkins-monitorjoined
01:36:18  * wyattjoined
01:46:36  * wyattquit (Remote host closed the connection)
01:53:02  * node-ghjoined
01:53:02  * node-ghpart
01:56:48  * wyattjoined
01:57:37  * wyattquit (Client Quit)
03:55:26  * 10UAABD8Ojoined
03:55:26  * 10UAABD8Opart
03:55:26  * node-ghjoined
03:55:26  * node-ghpart
04:01:28  * node-ghjoined
04:01:29  * node-ghpart
04:15:49  * node-ghjoined
04:15:49  * node-ghpart
05:58:54  <mylesborins>jbergstroem you around?
06:03:51  * node-ghjoined
06:03:51  * node-ghpart
06:05:10  * node-ghjoined
06:05:10  * node-ghpart
06:05:41  * node-ghjoined
06:05:41  * node-ghpart
06:47:48  * not-an-aardvarkjoined
07:57:49  * node-ghjoined
07:57:50  * node-ghpart
09:04:19  * not-an-aardvarkquit (Quit: Connection closed for inactivity)
11:19:04  <jbergstroem>mylesborins: now
11:23:19  * node-ghjoined
11:23:19  * node-ghpart
11:25:09  * mylesborinsquit (Quit: farewell for now)
11:25:40  * mylesborinsjoined
11:40:22  * node-ghjoined
11:40:22  * node-ghpart
11:41:52  * node-ghjoined
11:41:52  * node-ghpart
11:45:19  * node-ghjoined
11:45:19  * node-ghpart
11:46:09  * node-ghjoined
11:46:09  * node-ghpart
11:47:54  * node-ghjoined
11:47:54  * node-ghpart
11:51:27  * node-ghjoined
11:51:27  * node-ghpart
11:52:07  * node-ghjoined
11:52:07  * node-ghpart
11:55:44  * orangemocha_quit (*.net *.split)
11:57:22  * node-ghjoined
11:57:22  * node-ghpart
11:57:45  * orangemocha_joined
13:48:18  * node-ghjoined
13:48:18  * node-ghpart
14:00:27  * node-ghjoined
14:00:28  * node-ghpart
14:35:47  * node-ghjoined
14:35:48  * node-ghpart
14:47:20  * node-ghjoined
14:47:20  * node-ghpart
15:20:48  * node-ghjoined
15:20:49  * node-ghpart
17:14:38  <mylesborins>jbergstroem you around?
17:30:50  * node-ghjoined
17:30:51  * node-ghpart
17:36:34  <mylesborins>rvagg / jbergstroem the replacement builds have the wrong permissions and I cannot promote them. Also found out the hard way that the release team, or at least myself, do not have ssh access to staging
17:36:40  <mylesborins>(the user(
18:07:26  * node-ghjoined
18:07:26  * node-ghpart
18:31:49  * node-ghjoined
18:31:50  * node-ghpart
19:33:20  * node-ghjoined
19:33:20  * node-ghpart
19:34:10  * node-ghjoined
19:34:10  * node-ghpart
20:09:06  <mylesborins>so should these new releases go out today
20:10:31  <jbergstroem>i guess my question woudl be why not
20:16:46  <mylesborins>I'll start the build :P
20:47:30  * node-ghjoined
20:47:30  * node-ghpart
21:23:48  <rvagg>sorry ... no perms for staging but perms for dist
21:30:54  <mylesborins>rvagg worked with jbergstroem to fix it
21:31:01  <mylesborins>all the other releases are fixed
21:31:08  <mylesborins>the two latest are still borked
21:31:14  <mylesborins>building new patch releases to replace them
21:31:56  <mylesborins>would you be willing to throw an LGTM in the thread, I can then get the releases promoted (almost done building)
22:21:52  * node-ghjoined
22:21:52  * node-ghpart
22:32:22  * node-ghjoined
22:32:22  * node-ghpart
22:44:10  * lanceballchanged nick to lance|afk
23:11:12  <mylesborins>jbergstroem it would appear that that sunos stuff is still being glitchy
23:19:25  * not-an-aardvarkjoined
23:20:25  <mylesborins>https://ci-release.nodejs.org/job/iojs+release/nodes=smartos13-release/1452/console
23:21:07  <rvagg>smartos13 are intentionally skipped for >= v4
23:21:11  <rvagg>that's expected behaviour
23:21:16  <rvagg>it's the smartos15 ones that should build
23:21:38  <rvagg>https://ci-release.nodejs.org/job/iojs+release/nodes=smartos15-release/1452/console
23:23:42  <mylesborins>ok
23:23:50  <mylesborins>are we expecting both x64 and x86 from there?
23:24:30  <mylesborins>I didn't get the x86 assets for the v6 build (just noticed when makign the blog post)
23:25:30  <rvagg>not sure, is there a thread somewhere about fixing the sunos builds? I noticed the same thing when I did the last 0.12 but couldn't figure out what the problem was
23:25:48  <rvagg>like ... didn't we used to have two smartos builders to do this?
23:27:25  <rvagg>jbergstroem: ^ ?
23:27:28  <mylesborins>tbqh I'm pretty confused. Just a bit annoying if after ALL of this we still don't have the sunos builds :P
23:29:40  <rvagg>jbergstroem, joaocgreis: I feel like I'm missing context here, has there been any movement on figuring out this smartos problem over the last few weeks or are we still equally confused about why we're not getting two builds each time from smartos?
23:30:05  * node-ghjoined
23:30:05  * 08IAABMONjoined
23:30:05  * node-ghpart
23:30:05  * 08IAABMONpart
23:30:19  <rvagg>jbergstroem, joaocgreis: I'm pretty sure we had an x86 and an x64 builder for both smartos13 and smartos15 to spit out both of these, but we only have one now afaik, shouldn't we fire up new machines to fill this out?
23:32:20  <mylesborins>it built x86 this time ¯\_(ツ)_/¯ https://ci-release.nodejs.org/job/iojs+release/1454/nodes=smartos15-release/console
23:32:50  <rvagg>so maybe we have one of each but they get chosen at random
23:33:33  <mylesborins>they do the two back to back
23:33:41  <mylesborins>I killed the job before it built the x64 version
23:34:20  <mylesborins>so the issue is that if one fails and the other passes the build still reports as successful
23:38:04  <rvagg>ok, so if you rebuild then you'll get them both?
23:38:20  <rvagg>how about you do that then and I'll clean out staging so you only promote those ones that are missing
23:38:39  <rvagg>we've done that plenty of times with the armv6 binaries
23:38:43  <mylesborins>already fixed it :D
23:40:15  <joaocgreis>rvagg: I don't know if we had two machines sometime in the past. As far back as I went in job config, it's all released from the same machine. First it builds x86, then x64
23:40:51  <joaocgreis>mylesborins: do you need the build artifacts? I'm to blame for x86 not appearing there, figured only the upload was needed
23:41:01  * node-ghjoined
23:41:01  * node-ghpart
23:41:10  <mylesborins>the build artifacts are good to have to see that it has indeed built
23:41:15  <rvagg>joaocgreis: ok, good to know
23:41:21  <mylesborins>I manually got everything working right now for the current release
23:41:29  <joaocgreis>I added a git clean in between x86 and x64 when I was debugging, but I can remove it if you need
23:41:45  <rvagg>seems like a reasonable thing to do
23:41:47  <mylesborins>The biggest issue for me rn is that we have no sanity check in place to make sure all assets have built
23:42:16  <joaocgreis>mylesborins: the console log is always the best way to see that
23:42:20  <mylesborins>so if CI was green I've been going ahead with the release... not verifying all the binaries
23:42:21  <mylesborins>I think we likely need an extra step in CI that can check that all the expected built assets are in staging after the run
23:42:23  <rvagg>mylesborins: right, and I've been thinking more about this publish-over-existing problems, since we seem to be agreeing that it shouldn't be done we should probably make it so it _can't_ be done
23:42:38  <mylesborins>+1 to that rvagg
23:42:57  <mylesborins>could CI check to see if assets exist in release and Skip if they do?
23:43:10  <joaocgreis>mylesborins, rvagg, jbergstroem: I added -ex to #!/bin/bash , this way the job will fail if anything fails
23:43:11  <mylesborins>so it will just avoid rebuilding something into staging that exists in release
23:43:21  <mylesborins>thanks joaocgreis !
23:43:36  <rvagg>mylesborins: yeah, that's an interesting option we could certainly put in place, since the builders have all the access they need to check that
23:44:20  <mylesborins>that's what I was thinking... if something has been promoted we will NEVER be promoting again (hopefully)
23:44:34  <mylesborins>although jbergstroem and I wanted to dig into why the build / tar was not deterministic and resulted in a different sha
23:44:35  <joaocgreis>rvagg: sorry, you meant git clean is a reasonable thing to do, or is removing it?
23:45:16  <joaocgreis>mylesborins: tar stores file timestamp right?
23:45:17  <rvagg>joaocgreis: git clean
23:45:24  <mylesborins>AHHHHH
23:45:27  <mylesborins>that makes sense
23:45:39  <mylesborins>I had an inkling it might have been time related
23:46:00  <rvagg>mylesborins, jbergstroem: cause deterministing builds are _really hard_, one of the primary problems is timestamps, unless you start with identical timestamps compilers will produce different binaries.
23:46:45  <mylesborins>fair enough... I've definitely learned my lesson on assuming compilers will do the same thing twice ಠ_ಠ
23:48:06  <rvagg>https://reproducible-builds.org/
23:48:28  <rvagg>could be something we want to focus on tho, no reason other than people-time that we couldn't make this a thing
23:50:20  <mylesborins>seems like the kind of thing we could write a white paper on :P
23:50:21  <mylesborins>IEEE here I come :P
23:59:21  <joaocgreis>mylesborins: are you going to use iojs+release now? I've sketched a way to save the x86 artifacts but need a test run
23:59:32  <mylesborins>I can hold off
23:59:39  <mylesborins>was likely going to have to build one or two things though
23:59:44  <joaocgreis>ok, launching test
23:59:51  <mylesborins>ping me when done :D