[01:10] <cjwatson> robru: I'm working on the unity bzr issues
[01:10] <cjwatson> branch surgery
[01:26] <robru> cjwatson: oh cool. What was wrong with it? Never seen that before on any project
[01:28] <cjwatson> robru: branch corrupted due to not entirely known root causes, possibly botched recovery from an uncommit failure and related to stacking issues
[01:28] <robru> Huh
[01:28] <cjwatson> robru: but lp:unity was/is corrupted as well, I'm working on reconciling it
[01:29] <robru> cjwatson: yeah the "readonly transport" bit was particularly confusing as it's the same transport everything else uses
[01:29] <cjwatson> yeah that's just misleading
[01:29] <cjwatson> but really, this is going to happen from time to time with bzr and the root causes are unlikely to be fixed
[01:29] <cjwatson> train needs some git
[01:30] <robru> cjwatson: yeah we have a bug for that unfortunately it might take a while
[01:30] <cjwatson> sure
[01:30] <robru> It's not a drop in replacement, train has a lot of bzr knowledge
[01:30] <cjwatson> doesn't surprise me
[01:31] <robru> Including building with "bzr bd", sigh
[01:31] <robru> cjwatson: i don't suppose anybody's made a "git bd" yet ;-)
[01:31] <cjwatson> git-buildpackage
[01:31] <robru> Ooh?
[01:31] <cjwatson> I mean it's not like it gains much
[01:32] <cjwatson> for your purposes, you could just build the thing with dpkg-buildpackage assuming we don't do ridiculous split branch things for git
[01:33] <cjwatson> but gbp *can* I think cope with having a packaging-only tree
[01:33] <cjwatson> dunno, I never use that mode since git has way better tools for dealing with patches anyway
[01:33] <robru> cjwatson: not sure what you mean by split branch but we do split packaging (build orig.tar by dropping debian/ from source tree)
[01:34] <cjwatson> I mean that
[01:34] <robru> Right
[01:34] <cjwatson> but in part it's to cope with bzr not having as good tools
[01:34] <robru> cjwatson: oh yeah and the best part is that we have train users commit bzr bd specific bits to their source trees
[01:34] <cjwatson> like with git you can just have a branch in the repository that holds your pristine-tar metadata, etc.
[01:34] <cjwatson> sure, any switch would involve tree migrations
[01:35] <robru> True
[01:35] <robru> Lots to think about, and other priorities too. I'm trying to do ephemeral PPAs first then git after
[01:36] <cjwatson> right.  I just want to avoid the situation down the line a year or two when we have weird data corruption in toolsets we totally depend on that nobody knows how to fix any more
[01:37] <cjwatson> thanks, lag, your insertion of a stray character in the middle of the words "data corruption" was apposite
[01:37] <robru> cjwatson: yeah for sure. I doubt it'll be a whole year before i get git in there
[01:37] <cjwatson> cool
[06:37] <Mirv> robru: do you happen to have any visibility on why some silo autopkgtests seem to be aabaout eternally in progress? https://requests.ci-train.ubuntu.com/static/britney/xenial/landing-023/excuses.html the main autopkgtests page does not show any queue
[06:40] <robru> Mirv: something looks really wrong with that running.shtml, it's very short and there's not a single entry for any silo at all. You should ping pitti about that
[06:41] <robru> Mirv: one thing to be aware of is that silo britney runs currently take an hour due to high load, so there's some possibility that if a test just finished, depending on the timing it could take bileto up to 2 hours to notice
[07:01] <Mirv> robru: ok
[07:02] <Mirv> robru: that has been there for 5 days or so
[07:02] <robru> Hmmmmmmm
[07:02] <Mirv> the silo untouched
[07:02] <Mirv> I managed to now get the failing tests to pass by rerunning but there are some of those blues in there
[07:02] <Mirv> but some of the blue ones also yesterday turned green
[07:02] <robru> Mirv: yeah you need pitti to dig into that, all i can tell you is that britney is running
[07:02] <robru> Not what it's doing
[07:03] <Mirv> robru: thank you!
[07:03] <robru> Yw
[09:40] <Saviq> jibel, morning, Allan was unable to get adb on frieza re: silo 57 https://trello.com/c/IaTmnfWq/2748-963-ubuntu-landing-057-unity8-qtmir-saviq - how can we continue? I confirmed this to work on my laptop and on nexus7 FWIW
[09:46] <jibel> rvr, can you take 57?  ^
[09:57] <pete-woods> trainguards: hey guys, the (frustratingly "always failed") downstream autopkgtests for silo 70 have been running for like a whole day now
[09:57] <pete-woods> is there any way I can just push past this part of the process?
[10:11] <rvr> jibel: Yup
[10:16] <Mirv> robru: https://requests.ci-train.ubuntu.com/static/britney/xenial/landing-023/excuses.html says now finally valid candidate but the ticket still says Failed
[10:17] <Mirv> robru: not sure how it parses the results (or reparses or not reparses), maybe the overrides are not considered and it "greps for Regression"?
[10:17] <robru> pete-woods: pls email me, I'll fix it so it doesn't block on those, for now just ping qa to move it along
[10:17] <Mirv> this would be the final hurdle in this two week long "get a working silo into QA queue" quest (since I still don't see silo 023 manually inserted to Trello)
[10:19] <robru> Mirv: yes it greps for REGRESSION, exactly
[10:19] <Mirv> but meanwhile the train has gotten a lot better so it's worth the wait
[10:19] <Mirv> robru: may instead grep for "Not considered"?
[10:19] <pete-woods> robru: do you mean "please have emailed me yesterday?" as I guess you already know now?
[10:20] <Mirv> pete-woods: I guess robert means "please insert an item to my to-do queue while I'm way past bedtime and might forget" :)
[10:20] <pete-woods> ah, yeah, he's on the wrong tz
[10:20] <pete-woods> go to bed!
[10:20] <Mirv> "wrong" :D
[10:21] <robru> pete-woods: yeah what Mirv said, 2am here
[10:22] <robru> pete-woods: I fixed this once but had to revert for other reasons, can fix it again, it's literally two characters difference in one line of code
[10:22] <pete-woods> FWIW, I don't mean to complain about this tool, you've done an astounding one-man job where others have failed
[10:22] <robru> pete-woods: though you and Mirv are complaining about the same thing here
[10:22] <pete-woods> this is literally the first time it's ever done something annoying
[10:22] <Mirv> pete-woods: +1 to that
[10:23] <robru> pete-woods: Haha thanks. Pitti deserves most credit for autopkgtests I just connected the dots
[10:23] <pete-woods> well I'm less keen on the implementation side of autopkgtests to be honest, as they all just seem to fail for me
[10:23] <pete-woods> making me needlessly wait for failures
[10:24] <pete-woods> but maybe that'll get better
[10:25] <pete-woods> "all" is probably a bit dramatic :)
[10:25] <robru> Mirv: http://bazaar.launchpad.net/+branch/bileto/view/head:/britney/iterate.py#L101 I guess I'll just drop the check for REGRESSION as it already checks for "Not considered" so I guess that's redundant. Will fix within 12 hrs ;-)
[10:33] <Mirv> robru: cool! :)
[11:06] <sil2100> michi: moving here so that we don't spam the -release channel - I don't even know where the generic-lander nodes are actually running normally
[11:06] <sil2100> michi: and webops said they have no knowledge and no access besides to the power switches
[11:07] <michi> that’s wonderful :(
[11:07] <michi> So, where are the people who do know?
[11:07] <michi> I would have thought that Evan and Francis should know.
[11:09] <davmor2> michi: and both states side timezones right
[11:10] <michi> davmor2: I think so :(
[11:10] <michi> So, it might another two or three hours.
[11:10] <michi> davmor2, sil2100: will you guys be around long enough to ping someone?
[11:10] <michi> It’s getting a little late Down Under...
[11:10] <sil2100> michi: yeah, will try to get this pushed further...
[11:11] <davmor2> sil2100: I will be but I don't care about it or understand the issue so might be better for you to push :)
[11:12] <michi> thanks guys!
[11:13] <michi> We need s-jenkins to limp along for a few more weeks.
[11:13] <michi> We are trying hard to migrate our stuff over to jenkaas.
[11:13] <michi> but there are around 30 projects to migrate.
[11:13] <michi> And it took nearly four weeks for us to even get our jenkaas provisioned...
[11:13] <sil2100> Yeah, I know what you mean
[11:13] <sil2100> The tarball team has ~8 projects and they can't really get them working yet
[11:22] <Mirv> we've managed to disable all our s-jenkins jobs a few weeks ago, and have a little more features now than what we used to have in s-jenkins
[11:23] <Mirv> some hard work, though, was needed
[11:56] <Mirv> davmor2: jibel: I still haven't gotten a clear idea if you plan to test silo 23 because of my pleas when it's good to review OTA-10 landings, since I don't see it manually inserted into the Trello queue. it's a pre-requirement for SDK OTA-10 bug fix so time is getting a bit short for them to work on their stuff on top of it.
[11:57] <Mirv> davmor2: jibel: if you don't have time for it today, then it should be ok because the last fix to train + britney is going to go in late today and then it would appear finally automatically into the QA queue, but the silo has been ready for over a week now like communicated earlier.
[11:58] <Mirv> it has been good to get the train robust, it will help in the next Qt landings
[12:00] <jibel> Mirv, I'll force the creation of the card but we won't have time today
[12:04] <Mirv> jibel: ok if you don't have time today anyway then no need as it _should_ appear when robert applies one more fix to train code in the evening
[12:05] <Mirv> I can reping tomorrow if there's still an issue
[12:05] <pstolowski> jibel, hello! can we get silo 64 ack'ed and landed as a matter of urgency? no code change, only temporarily disabled abi check (full explanation in the description https://requests.ci-train.ubuntu.com/#/ticket/983)
[12:09] <jibel> pstolowski, Hey, sure, not sure when though, we'll do our best.
[12:13] <pstolowski> jibel, ack, thanks. this currently blocks builds for our entire scopes stack
[12:14] <jibel> pstolowski, I understand, I'll prioritize the request but there are already lot of urgent things to land
[12:15] <pstolowski> jibel, understood, ty
[12:17] <davmor2> jibel, john-mcaleely, morphis: 15 passed
[12:23] <jibel> davmor2, Excellent \o/
[12:23] <jibel> davmor2, very good job!
[12:35] <Mirv> hmmph
[12:54] <morphis> davmor2: awesome!
[13:26] <john-mcaleely> davmor2, \o/
[13:26] <Saviq> trainguards, I can has publish on https://requests.ci-train.ubuntu.com/#/ticket/963 please?
[13:28] <sil2100> Looking
[13:29] <Mirv> looked already
[13:29] <sil2100> Oh, timo is on it ;)
[13:29] <sil2100> Thanks!
[14:28] <Saviq> omg now that's a busy britney...
[14:47] <pstolowski> hey trainguards, what does 'automated signoff: failed' for silo 64 mean?
[14:53] <jibel> pstolowski, it means there are some failures in https://requests.ci-train.ubuntu.com/static/britney/vivid/landing-064/excuses.html
[14:54] <jibel> pstolowski, http://paste.ubuntu.com/15002165/ fails on amd64 and i386
[14:55] <pstolowski> jibel, this is a flakiness in scope harness, unrelated to anything in silo 64
[14:56] <dobey> jibel, pstolowski: we can't land unity-scopes-api by itself
[14:56] <dobey> pstolowski: it's not entirely unrelated
[14:58] <pstolowski> dobey, ?
[14:58] <dobey> pstolowski: jsoncpp broke ABI
[14:59] <pstolowski> dobey, but jsoncpp is internal to scopes-api, we don't expose it.. so should be enough to rebuild unity-scopes-api?
[15:00] <dobey> pstolowski: no, because it can't link to one jsoncpp and then the scopes link to a differnt jsoncpp; stuff will just crash
[15:01] <pstolowski> dobey, btw, that error with games department in click scope is not new, i saw it when i looked at the flaky scopeharness tests a week ago
[15:01] <pstolowski> dobey, ah.. i didn't know click scope links to jsoncpp
[15:01] <dobey> pstolowski: yes i know that. but on xenial stuff is going to break much worse
[15:01] <dobey> pstolowski: mediascanner does too
[15:01] <rvr> jgdx: ping
[15:02] <pstolowski> dobey, won't do any harm to do no-change rebuilds in same silo?
[15:03] <dobey> pstolowski: well we already have some other silos. it's better to reduce number of silos and no-change rebuilds if we can.
[15:04] <pstolowski> dobey, i'd prefer to keep features in separate silos
[15:04] <dobey> pstolowski: you mean the mediascanner thing?
[15:04] <pstolowski> dobey, one silo (filters) is for user testing... the other needs design ack etc.
[15:05] <dobey> pstolowski: anyway, since my day is just getting started now, let me do some consolidation of the silos here and get this landed
[15:05] <pstolowski> dobey, yes, mediascanner thing
[15:05] <dobey> i'll make an empty MP for mediascanner since it doesn't have a small silo with only a simple bug fix already
[15:06] <pstolowski> dobey, only silo 24 and 64 should land, please don't consolidate the others
[15:07] <dobey> pstolowski: and my unity-scope-click silo which is only bug fixes
[15:11] <jgdx> rvr, pong
[15:11] <rvr> jgdx: Hi
[15:12] <rvr> jgdx: I'm testing silo 21
[15:12] <rvr> jgdx: The background looks wrong in not-windowed mode on the tablet
[15:12] <rvr> jgdx: http://people.canonical.com/~vrruiz/system-settings-background-landscape.jpg
[15:13] <rvr> jgdx: In windowed mode, looks fine, the background is displayed with the landscape ratio
[15:16] <jgdx> rvr, I think you want to talk to ken about that. kenvandine was anything changed in the USS background panel? ^
[15:18] <dobey> pstolowski: ok, i merged things into the silo where i already had unity-scope-click, and abandoned 64 and 24; and 37 is now rebuilding
[15:18] <rvr> jgdx: Oh, probably
[15:18] <rvr> kenvandine: ^
[15:19] <pstolowski> dobey, great, thanks for that!
[15:20] <kenvandine> rvr, we haven't changed anything
[15:20] <kenvandine> rvr, that url gives a 404
[15:20] <dobey> hopefully it rebuilds fine now as-is
[15:21] <rvr> kenvandine: Yeah, removed, uploading to private server, one moment
[15:21] <kenvandine> ok
[15:22] <rvr> kenvandine: https://chinstrap.canonical.com/~vrruiz/system-settings-background-landscape.jpg
[15:22] <kenvandine> rvr 404 there too
[15:23] <kenvandine> chinstrap redirects to private-fileshare
[15:23] <rvr> Weird
[15:24] <pmcgowan> kenvandine, you might need the vpn on
[15:25] <kenvandine> i've gotten to private-fileshare before
[15:25] <kenvandine> and am now, just getting a 404
[15:25] <kenvandine> https://private-fileshare.canonical.com/~vrruiz/system-settings-background-landscape.jpg
[15:26] <rvr> kenvandine: Can you ssh to chinstrap?
[15:26] <kenvandine> yup
[15:27] <kenvandine> wtf
[15:27] <kenvandine> rvr so there is some diagram showing there?
[15:27] <rvr> kenvandine: If you ssh, the file is in /home/vrruiz/
[15:27] <kenvandine> rvr, and that's on the app switcher?
[15:28] <kenvandine> i got the file
[15:28] <kenvandine> the background we set in system-settings is only used for the greeter
[15:28] <kenvandine> so what you're seeing shouldn't have anything to do with that
[15:29] <rvr> kenvandine: So, the description of the silo is that it's a fix for landscape, and in windowed mode, the background has a landscape ratio
[15:29] <kenvandine> no, nothing to do with landscape
[15:29] <rvr> kenvandine: But when system settings is in the side panel, this large background is shown
[15:29] <kenvandine> it sets a fixed width to be used in windowed mode
[15:30] <kenvandine> yeah, but that isn't from settings
[15:30] <kenvandine> i don't see that on my flo
[15:30] <rvr> kenvandine: Background Ensure default for images is landscape
[15:30] <kenvandine> i see the app scope
[15:30] <rvr> https://bugs.launchpad.net/ubuntu/+source/ubuntu-system-settings/+bug/1541588
[15:30] <ubot5`> Launchpad bug 1541588 in ubuntu-system-settings (Ubuntu) "[System Settings] Changes needed for the UI on a tablet device" [Critical,In progress]
[15:30] <kenvandine> oh, that part isn't fixed :)
[15:31] <kenvandine> that's not in the silo
[15:31] <rvr> kenvandine: https://trello.com/c/8xdSGk8F/2747-969-ubuntu-landing-021-ubuntu-system-settings-kenvandine
[15:31] <kenvandine> we tackled what we could in that bug
[15:31] <rvr> Bug #1541588: [System Settings] Changes needed for the UI on a tablet device
[15:31] <rvr> Bug #1542050: don't allow window to be resized (not the shell doesn't handle this properly yet)
[15:31] <ubot5`> bug 1542050 in ubuntu-system-settings (Ubuntu) "don't allow window to be resized" [Medium,In progress] https://launchpad.net/bugs/1542050
[15:31] <kenvandine> since settings doesn't do any resizing or cropping we didn't do that
[15:32] <kenvandine> that should be "note the shell..."
[15:32] <kenvandine> rvr, what you are seeing is very strange, must be a shell bug
[15:32] <kenvandine> settings doesn't touch that, it only sets the background to be used for the greeter
[15:35] <kenvandine> rvr, the only things changed are listed in the testplan
[15:35] <rvr> kenvandine: Take a look to the other screenshot that I shared in /home/vrruiz/
[15:36] <kenvandine> rvr, what's really odd in your screenshot is the image is not only displayed behind the app but over top of it
[15:36] <kenvandine> rvr filename?
[15:36] <rvr> kenvandine: system-settings-background-landscape-2.jpg
[15:36] <kenvandine> so it looks like rendered artifacts
[15:37] <kenvandine> is that a pdf or something that's being showed?  like some quick start guide?
[15:37] <rvr> kenvandine: So I expected to see landscape background in both modes (panel and windowed)
[15:37] <kenvandine> yeah, but that's not something we've worked on
[15:38] <rvr> kenvandine: That's a photo with krillin :P
[15:38] <kenvandine> and i think we need some design guidance there, because what do when in phone mode but later connected to an external display?
[15:38] <kenvandine> we need to use different images i think
[15:39] <rvr> kenvandine: So that part wasn't changed with the silo, right?
[15:39] <kenvandine> right
[15:39] <rvr> Ok, I'll fill a bug
[15:39] <kenvandine> only what's listed in the testplan section
[15:39] <kenvandine> rvr, i'm more concerned with that krillin image being displayed there... why is that?
[15:40] <kenvandine> rvr, about the fixed width, unity8 doesn't honor that yet so you'll still be able to make it wider in windowed mode on the tablet
[15:40] <kenvandine> but on the desktop you can confirm it doesn't
[15:41] <rvr> kenvandine: Ok, I'm just testing in the tablet.
[15:41] <rvr> kenvandine: Max/minimized worked, no regressions
[15:41] <kenvandine> cool
[15:42] <kenvandine> when it's fixed in unity8 you won't be able to maximize it
[15:44] <rvr> kenvandine: By the way, I can still launch mobile data panel from the indicator network, although it only shows the spinner.
[15:44] <kenvandine> yeah
[15:44] <kenvandine> that needs a fix in the indicator
[15:45] <kenvandine> rvr,  there's a indicator-network task for the bug
[15:45] <rvr> kenvandine: I was about to search for it, thanks!
[15:45] <kenvandine> np
[15:45] <rvr> Ok, now I will take a look to the silo with krillin
[15:45] <kenvandine> cool
[15:46] <sil2100> \o/
[15:56] <alex-abreu> trainguards could you retry britney for unity8 aptests https://requests.ci-train.ubuntu.com/static/britney/xenial/landing-016/excuses.html ?
[15:58] <sil2100> alex-abreu: the unity8 parts?
[15:58] <alex-abreu> sil2100, yes pls
[15:59] <sil2100> alex-abreu: retried the failed unity8 test
[15:59] <sil2100> :)
[15:59] <alex-abreu> thx
[15:59] <sil2100> yw
[16:25] <Trevinho> robru, sil2100: any reason why https://requests.ci-train.ubuntu.com/static/britney/xenial/landing-025/excuses.html states unity8, although it's unity7?
[16:27] <Mirv> Trevinho: unity or part of it is reverse dependency of unity8, thus autopkgtest for u8 are run
[16:27] <Trevinho> mh, okkk
[17:51] <dobey> go go gadget britney
[18:10] <dobey> aaaand now i have to rebuild my other silo yet again
[19:30] <robru> Mirv: http://bazaar.launchpad.net/+branch/bileto/revision/418#britney/iterate.py ok next britney run should have correct results ;-)
[20:42]  * robru sees silo 80 in use
[20:42] <robru> "are you shitting me?!"
[20:42]  * robru forgot for a sec that they're assigned in random order
[20:51] <sil2100> hah, I see you had a moment of horror
[20:52] <robru> yes, my heart jumped
[20:53] <robru> brb
[21:07] <dobey> what the heck
[21:08] <dobey> oh i guess kenvandine's silo hasn't quite landed yet
[21:11] <kenvandine> dobey, need me to force merge it?
[21:11] <dobey> kenvandine: probably not. seems like it should go through fine once britney passes it
[21:11] <kenvandine> yeah
[21:11] <kenvandine> if it's holding you up building something i can merge it
[21:12] <dobey> well it's not the only thing being slow that's annoying me right now, so no worries :)
[21:12] <dobey> i'll just have to wait another 6 hours after that lands, for the autopkgtests for my other silo, anyway
[21:13] <dobey> and then probably bug qa to ignore the failed tests again
[21:13] <kenvandine> good times
[21:14] <dobey> maybe i should just go watch another episode of star trek
[21:26] <robru> dobey: I landed the fix that makes it ignore ALWAYSFAILED so hopefully you'll be waiting slightly less
[21:33] <dobey> robru: cool
[21:34] <dobey> robru: proposed-migration still waits for the always failed to complete though, right?
[21:35] <robru> dobey: no? if the package only has RUNNING-ALWAYSFAIL and no RUNNING, it's marked as Valid candidate.
[21:37] <dobey> hmm, ok
[21:45] <dobey> oh ffs
[21:45] <dobey> the britney queue on xenial is bonkers
[21:47] <dobey> thanks perl and python-numpy and qt
[21:47] <dobey> this probably won't even be finished by the time i'm back on-line tomorrow :(
[21:49] <robru> yikes
[21:50] <dobey> robru: yeah, and some of them are probably going to just fail anyway, until silo 37 lands