robru | oh holy jesus | 00:29 |
---|---|---|
tedg | robru: yes? | 00:30 |
robru | tedg: I just did something like rm -rf $HOME on the production train | 00:30 |
tedg | Ah, that sucks. | 00:31 |
robru | tedg: will check with webops for backups, seems a lot of people might need to rebuild silos | 00:32 |
tedg | robru: Good luck! | 00:33 |
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:42 |
tedg | When you play with silos, sometimes the nukes go off. | 00:43 |
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:44 |
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:48 |
tedg | Well, it's also one of my favorite memes :-) | 00:49 |
=== chihchun_afk is now known as chihchun | ||
=== chihchun is now known as chihchun_afk | ||
Mirv | morning | 04:07 |
=== chihchun_afk is now known as chihchun | ||
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:46 |
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:47 |
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:48 |
robru | oSoMoN: is there anything I can do to help get it back into a good state? since I broke it and all | 04:50 |
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:51 |
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:52 |
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:53 |
oSoMoN | Mirv, so you re-triggered both i386 and amd64 for vivid? | 04:54 |
Mirv | oSoMoN: yes | 04:55 |
oSoMoN | Mirv, both failed… | 04:58 |
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/ | 04:59 |
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:00 |
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:01 |
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:02 |
Mirv | oSoMoN: the good news of course is that it always succeeded on armhf | 05:12 |
oSoMoN | Mirv, yes, the failures are only on amd64 and i386, never on armhf, and they are random | 05:15 |
oSoMoN | Mirv, both failed again :/ | 05:16 |
oSoMoN | Mirv, it looks like the i386 build succeeded, can you retry the amd64 one only? | 05:26 |
Mirv | oSoMoN: yes, you don't need to poll it, I handle it :) | 05:30 |
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:31 |
Mirv | ok | 05:32 |
robru | well that looks good | 06:17 |
robru | Mirv: thanks for doing those rebuilds, that was really my mess | 06:17 |
robru | oooh, ticket 400 | 06:58 |
Mirv | :) | 07:00 |
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:05 |
brendand | robru, careful that's what they said about storing dates | 07:08 |
robru | brendand: I made sure to use more than 2 digits ;-) | 07:10 |
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:16 |
Mirv | dbarth_: I think we have a ghost silo, just a moment | 07:19 |
Mirv | robru: I noticed the ONLY_FREE_SILO does not work anymore | 07:20 |
robru | Mirv: it... doesn't work? it shouldn't exist. I covered that in my recent mail | 07:21 |
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:23 |
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:24 |
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:25 |
robru | Mirv: ugh, just missed the auto-rollout cutoff | 07:27 |
robru | Mirv: that option will go away in an hour | 07:27 |
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:28 |
Mirv | right, indeed | 07:30 |
dbarth_ | robru: Mirv: thanks! | 07:32 |
robru | dbarth_: you're welcome | 07:32 |
robru | hm | 08:32 |
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:49 |
robru | cjwatson: ah OK, just knew you were working on "stuff" | 08:50 |
cjwatson | I do that sometimes | 08:50 |
cjwatson | Also things | 08:51 |
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:52 |
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:53 |
cjwatson | I don't highlight on "colin", no :) | 08:54 |
sil2100 | Colin gets highlight pings on 'stuff' and 'things' though ;) | 09:22 |
robru | Mirv: ok I finally killed ONLY_FREE_SILO, and with that I'm going to go pass out. goodnight! | 09:32 |
Mirv | robru: thanks! | 09:48 |
jgdx | fginther, hey, ci runs takes 4-8 hours just to start. What's up? :) | 09:55 |
=== chihchun is now known as chihchun_afk | ||
rvr | pstolowski: ping | 11:17 |
pstolowski | rvr, pong | 11:17 |
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:19 |
pstolowski | rvr, in general - not really, but perhaps marcustomlinson has an idea | 11:23 |
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 | 12:02 |
=== alan_g is now known as alan_g|lunch | ||
marcustomlinson | rvr: which I did yesterday on krillin 128 and looked good | 12:03 |
rvr | marcustomlinson: Ack | 12:10 |
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 | 12:17 |
=== alan_g|lunch is now known as alan_g | ||
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:38 |
jgdx | fginther, yeah, it was the shortage of devices I was referring to. Any plans for more devices? | 13:39 |
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:41 |
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:42 |
fginther | but not impossible | 13:43 |
jgdx | fginther, thank you. | 13:43 |
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? | 14:17 |
=== pat_ is now known as Guest18418 | ||
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:29 |
pstolowski | cjwatson, ah, i see, thanks for the info! | 14:31 |
pstolowski | alecu, ^ | 14:31 |
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:42 |
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:45 |
Saviq | looking at the log it failed to unlock the screen in the first place (couldn't connect to dbus) | 14:46 |
Saviq | it looks as if it can't even talk to the session upstart | 14:47 |
fginther | Saviq, hey | 14:49 |
fginther | Saviq, it looks like the screen unlock has been failing for a while | 14:50 |
fginther | mterry, Is there a known issue with the automated screen unlock on wily? ^ | 14:51 |
mterry | fginther, not known, no | 14:51 |
bzoltan | Mirv: do you know what is the state of the silo38? | 14:53 |
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:54 |
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:58 |
fginther | mterry, Saviq pointed out the issue and it's mostly hitting unity8. I'll defer to him on the urgency of this problem. | 14:59 |
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:04 |
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:05 |
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:09 |
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:11 |
mterry | fginther, thanks. will put on my list to look at | 15:15 |
fginther | mterry, thanks | 15:16 |
=== Guest18418 is now known as pmgowan | ||
=== alan_g is now known as alan_g|EOD | ||
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:28 |
Saviq | hmm --revision=276? | 17:31 |
Saviq | fginther, jenkins is hardcoded at ↑ | 17:32 |
* Saviq tries | 17:32 | |
fginther | Saviq, looking | 17:36 |
fginther | Saviq, ugh... good catch. I'll remove that and give this another try | 17:37 |
* Saviq can't shake the feeling this is not the first time... | 17:40 | |
Saviq | we need a better process for this (I imagine you hardcoded an image because there was breakage in further versions?) | 17:41 |
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. | 17:45 |
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:06 |
fginther | Saviq, :-( | 18:35 |
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:37 |
Saviq | fginther, oh good | 18:43 |
Saviq | that looks promising then | 18:43 |
Saviq | jeez system-image is slow recently :/ | 18:49 |
Saviq | and it timed out @ 97% for me... | 18:49 |
bfiller | robru: can you publish silo 53, just pot file changes | 19:44 |
bfiller | for string freeze | 19:44 |
robru | bfiller: sure can't! You need a core dev for that | 19:45 |
bfiller | robru: how is it different than a normal silo that qa approves? | 19:46 |
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" | 19:47 |
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:08 |
robru | bfiller: oh you're rebuilding 53? | 20:11 |
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:13 |
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:14 |
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:15 |
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:16 |
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:18 |
robru | kenvandine: please re-review & publish then? ;-) | 20:19 |
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:20 |
kenvandine | the debian/changelog version is | 20:21 |
kenvandine | but the diff shows binary package renames | 20:21 |
kenvandine | that have already landed | 20:21 |
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:22 |
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:23 |
robru | kenvandine: hang on a second don't publish yet | 20:24 |
robru | ohtoo late, nevermind | 20:24 |
robru | let it go | 20:24 |
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:25 |
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:26 |
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:28 |
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:29 |
robru | mterry: no worries | 20:30 |
Saviq | elopio, hey, is there a canonical way to detect ubuntu release (vivid vs. wily) in a autopilot test? | 20:34 |
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:41 |
robru | kenvandine: one more? https://ci-train.ubuntu.com/job/ubuntu-landing-010-2-publish/82/ ;-) | 20:45 |
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:48 |
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:49 |
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:50 |
kenvandine | robru, grr... silo 10 has unapproved branches | 20:52 |
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:53 |
Saviq | robru, sry, done | 20:56 |
robru | kenvandine: please publish again ^ | 20:56 |
Saviq | didn't know it got under testing already | 20:56 |
robru | Saviq: yep, qa granted | 20:57 |
kenvandine | ok | 21:01 |
kenvandine | bfiller, silo 53 is published | 21:02 |
bfiller | kenvandine: nice, thanks | 21:02 |
kenvandine | np | 21:02 |
kenvandine | robru, Saviq: silo 10 published | 21:04 |
robru | kenvandine: thanks a bunch | 21:04 |
kenvandine | np | 21:04 |
Saviq | thank you | 21:05 |
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:32 |
robru | anyway, that fix will hit trunk & production shortly | 21:40 |
robru | bbl, lunch | 21:40 |
dobey | trainguards: hi, can someone please click retry on https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-026/+build/7930359 ? thanks. | 22:01 |
robru | dobey: sorry I'm afk. kenvandine can you ^ ? | 22:09 |
cjwatson | dobey: done | 22:10 |
cjwatson | kenvandine: ^- | 22:10 |
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:11 |
* robru is a raging workaholic | 22:12 | |
robru | 404, request not found | 23:03 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!