[00:29] <robru> oh holy jesus
[00:30] <tedg> robru: yes?
[00:30] <robru> tedg: I just did something like rm -rf $HOME on the production train
[00:31] <tedg> Ah, that sucks.
[00:32] <robru> tedg: will check with webops for backups, seems a lot of people might need to rebuild silos
[00:33] <tedg> robru: Good luck!
[00:42] <robru> tedg: hm actually it looks like I cancelled it before it deleted more than a couple silos... will try to figure out which silos got nuked and which are expected to be empty...
[00:43] <tedg> When you play with silos, sometimes the nukes go off.
[00:44] <robru> tedg: I'm literally implementing a new way to abandon silos. some variable got set wrong and it started deleting all silos instead of just one.
[00:48] <tedg> robru: http://www.quickmeme.com/img/d6/d689b760f2debdb9d4cad9b7f755f8113d041875f98d7f2e8f1a755e6dc239ed.jpg
[00:48] <tedg> ;-)
[00:48] <robru> tedg: I have unit tests and I tested this in staging! It's just a Monday, that's all
[00:49] <tedg> Well, it's also one of my favorite memes :-)
=== chihchun_afk is now known as chihchun
=== chihchun is now known as chihchun_afk
[04:07] <Mirv> morning
=== chihchun_afk is now known as chihchun
[04:46] <oSoMoN> robru, why on earth did you trigger a new build for silo 35?
[04:46] <robru> oSoMoN: I just sent out an email about that
[04:46] <robru> oSoMoN: TL;DR: that silo got deleted so I had to rebuild it
[04:47] <oSoMoN> robru, it took me 6 attempts to get it to build successfully last night, and with your build it failed again
[04:47] <robru> oSoMoN: ohhh nooooo
[04:47] <robru> oSoMoN: I'm sorry dude.
[04:48] <robru> oSoMoN: I had no choice, the silo was accidentally deleted so there would be no way to publish it
[04:48] <oSoMoN> understood
[04:50] <robru> oSoMoN: is there anything I can do to help get it back into a good state? since I broke it and all
[04:51] <oSoMoN> robru, not much I’m afraid, there is one unit test in the webbrowser-app test suite that started failing randomly yesterday, with no related change, and of course a normal PPA build doesn’t give any useful output, so I don’t know why it fails
[04:51] <oSoMoN> that specific unit test (like all the others) had been rock-solid before yesterday
[04:51] <oSoMoN> it’s a complete mistery
[04:51] <Mirv> oSoMoN: stop trying random rebuilds, let me (/robru) retry individual archs until it succeeds
[04:51] <oSoMoN> robru, do you know by any chance if the pbuilders for the silos have been upgraded very recently?
[04:52] <oSoMoN> Mirv, ah, that would be awesome, I didn’t know you could do that
[04:52] <Mirv> so wily ok already, now just amd i386 for vivid
[04:52] <oSoMoN> Mirv, yes please
[04:52] <Mirv> oSoMoN: we try to advertise every time possible that pleeease don't rerun build job for all archs when some archs fail, just get us to retry :)
[04:52] <robru> oSoMoN: not that I know of, but I only know about the train side (which only builds source packages) actual PPA builds would be a question for LP people
[04:53] <oSoMoN> Mirv, sorry I must have missed all those announcements, I guess that’s because my silos never failed to build before yesterday :)
[04:53] <robru> oSoMoN: and actually colin has been poking at the builders I think... ;-)
[04:53] <Mirv> oSoMoN: that's a good reason :)
[04:54] <oSoMoN> Mirv, so you re-triggered both i386 and amd64 for vivid?
[04:55] <Mirv> oSoMoN: yes
[04:58] <oSoMoN> Mirv, both failed…
[04:59] <Mirv> oSoMoN: I'm afraid it might be because of this https://launchpadlibrarian.net/218473113/qtbase-opensource-src_5.4.1%2Bdfsg-2ubuntu8_5.4.1%2Bdfsg-2ubuntu9.diff.gz - I'd need to know if it needs to be rolled back, but it seemed an important fix fixing a previous (very important) fix that was https://codereview.qt-project.org/#/c/110150/
[05:00] <Mirv> oSoMoN: the retries are cheap, but it'd be very useful to know if the behavior is ~correct or not. all webbrowser AP:s passed among else.
[05:01] <oSoMoN> Mirv, ah, thanks for pointing at that, I’ll see if I can reproduce locally with this patch
[05:01] <oSoMoN> Mirv, in the meantime, can you please retry the failing jobs? they will eventually pass…
[05:02] <Mirv> oSoMoN: yes, it's in overlay PPA now. see also the patch description if it helps you understand what has changed. the patch is fixing reported Connection Closed / etc problems leading to for example missing images on web pages (on another browser)
[05:02] <Mirv> oSoMoN: sure
[05:12] <Mirv> oSoMoN: the good news of course is that it always succeeded on armhf
[05:15] <oSoMoN> Mirv, yes, the failures are only on amd64 and i386, never on armhf, and they are random
[05:16] <oSoMoN> Mirv, both failed again :/
[05:26] <oSoMoN> Mirv, it looks like the i386 build succeeded, can you retry the amd64 one only?
[05:30] <Mirv> oSoMoN: yes, you don't need to poll it, I handle it :)
[05:31] <oSoMoN> Mirv, awesome, thanks
[05:31] <oSoMoN> Mirv, I’ll be offline for the rest of the morning, back online this afternoon, if anything comes up please send me an e-mail. Thanks!
[05:32] <Mirv> ok
[06:17] <robru> well that looks good
[06:17] <robru> Mirv: thanks for doing those rebuilds, that was really my mess
[06:58] <robru> oooh, ticket 400
[07:00] <Mirv> :)
[07:05] <robru> at one point I was like "I dunno man, what about integer overflow?" and then I realized you'd have to create a new ticket every second for 80 years for that to be an issue.
[07:08] <brendand> robru, careful that's what they said about storing dates
[07:10] <robru> brendand: I made sure to use more than 2 digits ;-)
[07:16] <dbarth_> good morning
[07:16] <dbarth_> i made proper merge proposals for https://requests.ci-train.ubuntu.com/#/ticket/396 but assign still does not like me
[07:19] <Mirv> dbarth_: I think we have a ghost silo, just a moment
[07:20] <Mirv> robru: I noticed the ONLY_FREE_SILO does not work anymore
[07:21] <robru> Mirv: it... doesn't work? it shouldn't exist. I covered that in my recent mail
[07:23] <robru> Mirv: are you trying to free dbarth_'s request? because it can be fixed in bileto without freeing
[07:23] <robru> errr
[07:23] <Mirv> robru: it's there, the option, but it seems to try normal merge&clean instead. the problem is that if the bileto doesn't know of a silo, like I think is the case with silo 041, I can't free it up any way https://ci-train.ubuntu.com/job/ubuntu-landing-041-3-merge-clean/6/console
[07:23] <Mirv> so https://ci-train.ubuntu.com/job/prepare-silo/6222/console lead me to think of another ghost silo
[07:24] <Mirv> hmm, no, that's a normal silo
[07:24] <Mirv> oh, now it has a silo
[07:24] <Mirv> soooo... I think just confusion after confusion, but no actual problem :)
[07:24] <robru> Mirv: "ghost silo" is not a ghost, it is really fully assigned in jenkins for 100% real and solid. it just doesn't say so in bileto.
[07:25] <robru> Mirv: I'm not sure why merge&clean job still has ONLY_FREE_SILO option, that should not be there at all
[07:25] <Mirv> robru: yeah, it shouldn't have it since it's just ignored
[07:25] <Mirv> and now we have the abandon job
[07:27] <robru> Mirv: ugh, just missed the auto-rollout cutoff
[07:27] <robru> Mirv: that option will go away in an hour
[07:28] <Mirv> good! :)
[07:28] <Mirv> dbarth_: so in short, you have a silo
[07:28] <robru> Mirv: if you see any ghost silos again, do the prepare, and it'll say "request found in /whatever/silo", just copy&paste the ubuntu/landing-NNN into the siloname field in bileto.
[07:30] <Mirv> right, indeed
[07:32] <dbarth_> robru: Mirv: thanks!
[07:32] <robru> dbarth_: you're welcome
[08:32] <robru> hm
[08:49] <cjwatson> robru: I see that it's been handled, but anyway, we haven't deployed any new buildd code for a month and a half
[08:49] <cjwatson> aside from the new ppc64el virt builders, but silos aren't using those yet
[08:50] <robru> cjwatson: ah OK, just knew you were working on "stuff"
[08:50] <cjwatson> I do that sometimes
[08:51] <cjwatson> Also things
[08:52] <robru> cjwatson: do you always read all the scrollback it so you have a highlight on "colin"? ;-)
[08:52] <robru> "Or do you have"
[08:52] <robru> (On phone)
[08:53] <cjwatson> I don't read all scrollback in every channel I'm in, but I often page through a fair bit of it quickly
[08:54] <cjwatson> I don't highlight on "colin", no :)
[09:22] <sil2100> Colin gets highlight pings on 'stuff' and 'things' though ;)
[09:32] <robru> Mirv: ok I finally killed ONLY_FREE_SILO, and with that I'm going to go pass out. goodnight!
[09:48] <Mirv> robru: thanks!
[09:55] <jgdx> fginther, hey, ci runs takes 4-8 hours just to start. What's up? :)
=== chihchun is now known as chihchun_afk
[11:17] <rvr> pstolowski: ping
[11:17] <pstolowski> rvr, pong
[11:19] <rvr> pstolowski: Silo 25
[11:19] <pstolowski> rvr, yes?
[11:19] <rvr> pstolowski: Is there anything to check?
[11:19] <rvr> "Scopes API fix: Loop through each argument of the custom scope runner command and ensure that all path arguments are absolute."
[11:19] <pstolowski> marcustomlinson, ^ ?
[11:23] <pstolowski> rvr, in general - not really, but perhaps marcustomlinson has an idea
[12:02] <marcustomlinson> rvr: hey, the fix in silo 25 is really for the SDK, it allows debugging of scopes who's runner executable is relative to the click path
[12:02] <marcustomlinson> rvr: little tricky to test, but running through the test plan is good enough
=== alan_g is now known as alan_g|lunch
[12:03] <marcustomlinson> rvr: which I did yesterday on krillin 128 and looked good
[12:10] <rvr> marcustomlinson: Ack
[12:17] <marcustomlinson> rvr: fyi, here's a test to confirm it works: http://paste.ubuntu.com/12520739/
[12:17] <marcustomlinson> rvr: but like I said its tricky. I just tried this test myself (now on krillin 129) and works just fine
=== alan_g|lunch is now known as alan_g
[13:38] <fginther> jgdx, do you have any more context, such as an MP that was slow? I don't see anything unusually right now although jobs requiring makos have been delayed due to a shortage of devices
[13:39] <jgdx> fginther, yeah, it was the shortage of devices I was referring to. Any plans for more devices?
[13:41] <fginther> jgdx, we've already requested more. Just waiting now on the approval/installation process to move forward. Sorry that I don't have an ETA on when things might be better.
[13:42] <jgdx> fginther, okay. More makos or other devices too?
[13:42] <fginther> jgdx, Other devices
[13:42] <fginther> jgdx, makos are getting harder to find
[13:43] <fginther> but not impossible
[13:43] <jgdx> fginther, thank you.
[14:17] <pstolowski> Mirv, hey, silo 24 has been in proposed pocket for several hours and not merged yet, any idea when is it going to actually land?
=== pat_ is now known as Guest18418
[14:29] <cjwatson> pstolowski: it's awaiting an autopkgtest on armhf: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#unity-scopes-shell
[14:29] <cjwatson> 13:41 <pitti> Riddell: see scrollback from 1.5 h ago; I retried them, queues are catching up
[14:29] <cjwatson> 13:41 <pitti> but ARM still has some ~ 290 tests to grind through
[14:29] <cjwatson> pstolowski: ^-
[14:31] <pstolowski> cjwatson, ah, i see, thanks for the info!
[14:31] <pstolowski> alecu, ^
[14:42] <oSoMoN> Mirv, I’m looking at the unit test failure for webbrowser-app in silo builds, I was hoping that the changes you pointed me to in QNAM would be the culprit, but I can’t reproduce the failure locally :/
[14:45] <Saviq> cihelp, hey, our only remaining failing jobs on s-jenkins are wily autopilot for unity8, and it falls over completely https://jenkins.qa.ubuntu.com/job/generic-deb-autopilot-runner-wily-mako/417/console
[14:46] <Saviq> looking at the log it failed to unlock the screen in the first place (couldn't connect to dbus)
[14:47] <Saviq> it looks as if it can't even talk to the session upstart
[14:49] <fginther> Saviq, hey
[14:50] <fginther> Saviq, it looks like the screen unlock has been failing for a while
[14:51] <fginther> mterry, Is there a known issue with the automated screen unlock on wily? ^
[14:51] <mterry> fginther, not known, no
[14:53] <bzoltan> Mirv:  do you know what is the state of the silo38?
[14:54] <fginther> mterry, are you still the best contact for the screen unlock? If so, shall we just open a bug report to track this?
[14:58] <mterry> fginther, uh I suppose I am
[14:58] <oSoMoN> Mirv, I finally managed to reproduce the failure locally, looking into it now
[14:58] <mterry> fginther, yes please open bug.  I assume that's a pain point with some urgency?  I'm in the middle of something else now though
[14:59] <fginther> mterry, Saviq pointed out the issue and it's mostly hitting unity8. I'll defer to him on the urgency of this problem.
[15:04] <Mirv> oSoMoN: thanks!
[15:04] <Mirv> bzoltan: well wily part is broken because of the GCC bug, vivid ok
[15:04] <Mirv> bzoltan: robert just accidentally deleted the silo so it was rebuilt by him as announced in e-mail
[15:05] <bzoltan> Mirv:  I have read the mail. That was not causing any problem for us. I just wonder if the silo could be released now.
[15:09] <Saviq> fginther, mterry, it'd be good to have, but truthfully I don't think the problem is in the unlock code, there seems to be something wrong in the environment maybe, in a way that nothing can access the session upstart (or session dbus for that matter)
[15:11] <oSoMoN> Mirv, and FYI, I filed bug #1498539 to track the issue
[15:11] <ubot5> bug 1498539 in webbrowser-app (Ubuntu) "FaviconFetcherTests random failures in silo builds" [Critical,In progress] https://launchpad.net/bugs/1498539
[15:11] <fginther> Saviq, mterry, for reference, the bug report is https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1498541
[15:11] <ubot5> Ubuntu bug 1498541 in unity8 (Ubuntu) "Automated screen unlock not working on wily images" [Undecided,New]
[15:15] <mterry> fginther, thanks.  will put on my list to look at
[15:16] <fginther> mterry, thanks
=== Guest18418 is now known as pmgowan
=== alan_g is now known as alan_g|EOD
[17:28] <Saviq> fginther, I followed http://ubuntu-test-cases-touch.readthedocs.org/en/latest/ on wily and it's fine, not sure what jenkins runs might be doing different, but evidently the shell env is broken https://bugs.launchpad.net/ubuntu-test-cases/+bug/1498541/comments/3
[17:28] <ubot5> Ubuntu bug 1498541 in unity8 (Ubuntu) "Automated screen unlock not working on wily images" [High,Incomplete]
[17:31] <Saviq> hmm --revision=276?
[17:32] <Saviq> fginther, jenkins is hardcoded at ↑
[17:32]  * Saviq tries
[17:36] <fginther> Saviq, looking
[17:37] <fginther> Saviq, ugh... good catch. I'll remove that and give this another try
[17:40]  * Saviq can't shake the feeling this is not the first time...
[17:41] <Saviq> we need a better process for this (I imagine you hardcoded an image because there was breakage in further versions?)
[17:45] <fginther> Saviq, indeed, this was done to workaround an unbootable image. I usually set a reminder to revisit and remove the hardcoded version, but I failed in this case.
[18:06] <Saviq> fginther, just realized, current image might not be good to use either, it doesn't reboot
[18:06] <Saviq> gets stuck after stopping services (so adb is gone, and won't be back until you forcefully reboot the device)
[18:35] <fginther> Saviq, :-(
[18:37] <fginther> Saviq, it appears to be working here (with image 311) - http://s-jenkins.ubuntu-ci:8080/job/generic-deb-autopilot-runner-wily-mako/421/console
[18:37] <fginther> unlock too
[18:43] <Saviq>  fginther, oh good
[18:43] <Saviq> that looks promising then
[18:49] <Saviq> jeez system-image is slow recently :/
[18:49] <Saviq> and it timed out @ 97% for me...
[19:44] <bfiller> robru: can you publish silo 53, just pot file changes
[19:44] <bfiller> for string freeze
[19:45] <robru> bfiller: sure can't! You need a core dev for that
[19:46] <bfiller> robru: how is it different than a normal silo that qa approves?
[19:47] <robru> bfiller: it isn't, the rules changed. I no longer have any special publishing powers over what you have, as per the email i sent out last night
[19:47]  * bfiller reads email
[19:47] <robru> bfiller: also there's packaging changes, so it's not "just pot files"
[20:08] <robru> mterry: kenvandine: either of you around? https://ci-train.ubuntu.com/job/ubuntu-landing-025-2-publish/65/ needs ack, has new binary packages & symbols, huge diff too.
[20:11] <robru> bfiller: oh you're rebuilding 53?
[20:13] <bfiller> robru: yes, then will hand it to QA. let them verify it and publish
[20:13] <robru> bfiller: well, QA can't publish either. it has to be a core dev.
[20:13] <kenvandine> robru, i'm confused... silo 25 looks like a diff i already reviewed :)
[20:14] <bfiller> robru: ok, now I'm confused. whatever the process is for publishing silos.. this one should be no different
[20:14] <robru> kenvandine: it's possible, I accidentally deleted some silos recently, and then when I was restoring them I potentially restored extra ones by mistake.
[20:15] <kenvandine> we even had quite a bit of discussion over the breaks and replaces... etc
[20:15] <kenvandine> -Depends: libunity-scopes1.0 (= ${binary:Version}),
[20:15] <kenvandine> +Depends: libunity-scopes3 (= ${binary:Version}),
[20:15] <robru> bfiller: right, the process is that it's your responsibility to find a core dev to publish. if you need help I have a couple go-to guys (ken & mike) but generally publishing is your responsibility. you are empowered!
[20:16] <bfiller> robru: hmnn, sounds like a step backwards. I just want to hand it off and when QA passes it should happen autoamtically
[20:16] <bfiller> not have to find someone to do it
[20:18] <robru> bfiller: no, it's the same. previously you had trainguards publishing, now you have core devs publishing. it's still a manual step
[20:18] <bfiller> robru: ok
[20:18] <robru> kenvandine: well if you approved it in the past, it seems it was never published
[20:18] <kenvandine> maybe there was an issue then... i really don't recall
[20:19] <robru> kenvandine: please re-review & publish then? ;-)
[20:20] <kenvandine> i'm not convinced it wasn't published
[20:20] <kenvandine> -Package: libunity-scopes1.0
[20:20] <kenvandine> +Package: libunity-scopes3
[20:20] <kenvandine> and the package in the overlay ppa has a libunity-scopes3 binary
[20:20] <robru> kenvandine: huh? the silo version is days ahead of the wily version or the overlay ppa version
[20:20] <robru> kenvandine: the diff is against wily
[20:20] <kenvandine> robru, yeah... i see that
[20:21] <kenvandine> the debian/changelog version is
[20:21] <kenvandine> but the diff shows binary package renames
[20:21] <kenvandine> that have already landed
[20:22] <kenvandine> robru, and shouldn't that diff be from the package in the overlay ppa?
[20:22] <kenvandine> --- unity-scopes-api-1.0.1+15.10.20150915.1/debian/changelog
[20:22] <kenvandine> +++ unity-scopes-api-1.0.2+15.04.20150921/debian/changelog
[20:22] <kenvandine> looks like it is
[20:22] <kenvandine> but... again... that new binary package is already in the latest build in the overlay ppa
[20:22] <robru> kenvandine: no dual silos should be diffing against wily as far as I know...
[20:22] <kenvandine> oh this is a dual landing
[20:22] <kenvandine> i think we landed this same thing for vivid last week
[20:23] <robru> kenvandine: maybe they landed in overlay on the 15th and are re-syncing dual today?
[20:23] <kenvandine> yeah
[20:23] <kenvandine> that's what i'm thinking now
[20:24] <robru> kenvandine: hang on a second don't publish yet
[20:24] <robru> ohtoo late, nevermind
[20:24] <robru> let it go
[20:25] <kenvandine> yeah... i did :)
[20:25] <kenvandine> i spent a bunch of time reviewing this once
[20:25] <kenvandine> for a vivid only landing
[20:26] <robru> kenvandine: it seems like there's a bug in the diff generation, it seems to be diffing the vivid local build against the wily version, that's definitely wrong. I guess it was never an issue before because the only thing that should be different between wily & vivid in a dual silo is the first line of the changelog. but now they're doing this "different
[20:26] <robru> binary package names depending on what release we build for" thing and the diff is more complicated.
[20:28] <robru> uh, that's really weird, that it would say Publishing, then Migration, then Publishing. wtf
[20:28] <fginther> mterry, https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1498541 may be a non-issue. The unlock is working on a more up-to-date image
[20:28] <ubot5> Ubuntu bug 1498541 in unity8 (Ubuntu) "Automated screen unlock not working on wily images" [High,Incomplete]
[20:28] <robru> 'Publishing' is the last status from the publish job, it shouldn't go back to that after Migration starts
[20:29] <mterry> fginther, oh..  good.  I love bugs that fix themselves  :)
[20:29] <mterry> robru, kenvandine: sorry I didn't see your ping earlier, but looks like it was just as well
[20:29] <kenvandine> solved it :)
[20:30] <robru> mterry: no worries
[20:34] <Saviq> elopio, hey, is there a canonical way to detect ubuntu release (vivid vs. wily) in a autopilot test?
[20:41] <robru> kenvandine: hey, I need to test some code that involves 'epoch versions' in an ubuntu package, can you think of one off the top of your head?
[20:41] <robru> kenvandine: nm, compiz
[20:45] <robru> kenvandine: one more? https://ci-train.ubuntu.com/job/ubuntu-landing-010-2-publish/82/ ;-)
[20:48] <kenvandine> mterry, can you take silo 10?  i'm trying to finish something up here and still working on getting 53 published too
[20:48] <kenvandine> he ran like hell :)
[20:49] <kenvandine> +Depends: @,
[20:49] <robru> hm
[20:49] <kenvandine> anyone know if that's valid in the package tests?
[20:49] <cjwatson> that's an autopkgtest thing
[20:49] <cjwatson> yes it is
[20:49] <kenvandine> cool
[20:50] <cjwatson> means "all binaries produced by this source"
[20:50] <cjwatson> https://anonscm.debian.org/gitweb/?p=autopkgtest/autopkgtest.git;a=blob_plain;f=doc/README.package-tests.rst;hb=HEAD
[20:50] <robru> oh
[20:50] <kenvandine> cjwatson, you had that handy :)
[20:50] <cjwatson> well, not directly, but http://dep.debian.net/deps/dep8/ is rather easier to remember ...
[20:52] <kenvandine> robru, grr... silo 10 has unapproved branches
[20:53] <robru> bah
[20:53] <robru> Saviq: kgunn: please approve the two merges listed here: https://ci-train.ubuntu.com/job/ubuntu-landing-010-2-publish/83/consoleFull
[20:56] <Saviq> robru, sry, done
[20:56] <robru> kenvandine: please publish again ^
[20:56] <Saviq> didn't know it got under testing already
[20:57] <robru> Saviq: yep, qa granted
[21:01] <kenvandine> ok
[21:02] <kenvandine> bfiller, silo 53 is published
[21:02] <bfiller> kenvandine: nice, thanks
[21:02] <kenvandine> np
[21:04] <kenvandine> robru, Saviq: silo 10 published
[21:04] <robru> kenvandine: thanks a bunch
[21:04] <kenvandine> np
[21:05] <Saviq> thank you
[21:32] <robru> kenvandine: LAWL, yeah there's a huge bug in the diff generation. here's the real diff for that silo: https://ci-train.staging.ubuntu.com/job/ubuntu-landing-002-2-publish/2/artifact/unity-scopes-api_packaging_changes.diff/*view*/
[21:40] <robru> anyway, that fix will hit trunk & production shortly
[21:40] <robru> bbl, lunch
[22:01] <dobey> trainguards: hi, can someone please click retry on https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-026/+build/7930359 ? thanks.
[22:09] <robru> dobey: sorry I'm afk. kenvandine can you ^ ?
[22:10] <cjwatson> dobey: done
[22:10] <cjwatson> kenvandine: ^-
[22:11] <robru> cjwatson: thanks
[22:11] <dobey> thanks
[22:11] <robru> I gotta find my otg cable so i can use my yubikey on my phone, then i can work anywhere ;-)
[22:12]  * robru is a raging workaholic
[23:03] <robru> 404, request not found