[01:10] robru: I'm working on the unity bzr issues [01:10] branch surgery [01:26] cjwatson: oh cool. What was wrong with it? Never seen that before on any project [01:28] robru: branch corrupted due to not entirely known root causes, possibly botched recovery from an uncommit failure and related to stacking issues [01:28] Huh [01:28] robru: but lp:unity was/is corrupted as well, I'm working on reconciling it [01:29] cjwatson: yeah the "readonly transport" bit was particularly confusing as it's the same transport everything else uses [01:29] yeah that's just misleading [01:29] but really, this is going to happen from time to time with bzr and the root causes are unlikely to be fixed [01:29] train needs some git [01:30] cjwatson: yeah we have a bug for that unfortunately it might take a while [01:30] sure [01:30] It's not a drop in replacement, train has a lot of bzr knowledge [01:30] doesn't surprise me [01:31] Including building with "bzr bd", sigh [01:31] cjwatson: i don't suppose anybody's made a "git bd" yet ;-) [01:31] git-buildpackage [01:31] Ooh? [01:31] I mean it's not like it gains much [01:32] 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] but gbp *can* I think cope with having a packaging-only tree [01:33] dunno, I never use that mode since git has way better tools for dealing with patches anyway [01:33] 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] I mean that [01:34] Right [01:34] but in part it's to cope with bzr not having as good tools [01:34] cjwatson: oh yeah and the best part is that we have train users commit bzr bd specific bits to their source trees [01:34] like with git you can just have a branch in the repository that holds your pristine-tar metadata, etc. [01:34] sure, any switch would involve tree migrations [01:35] True [01:35] Lots to think about, and other priorities too. I'm trying to do ephemeral PPAs first then git after [01:36] 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] thanks, lag, your insertion of a stray character in the middle of the words "data corruption" was apposite [01:37] cjwatson: yeah for sure. I doubt it'll be a whole year before i get git in there [01:37] cool [06:37] 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] 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] 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] robru: ok [07:02] robru: that has been there for 5 days or so [07:02] Hmmmmmmm [07:02] the silo untouched [07:02] I managed to now get the failing tests to pass by rerunning but there are some of those blues in there [07:02] but some of the blue ones also yesterday turned green [07:02] Mirv: yeah you need pitti to dig into that, all i can tell you is that britney is running [07:02] Not what it's doing [07:03] robru: thank you! [07:03] Yw [09:40] 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] rvr, can you take 57? ^ [09:57] trainguards: hey guys, the (frustratingly "always failed") downstream autopkgtests for silo 70 have been running for like a whole day now [09:57] is there any way I can just push past this part of the process? [10:11] jibel: Yup [10:16] 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] 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] 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] 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] Mirv: yes it greps for REGRESSION, exactly [10:19] but meanwhile the train has gotten a lot better so it's worth the wait [10:19] robru: may instead grep for "Not considered"? [10:19] robru: do you mean "please have emailed me yesterday?" as I guess you already know now? [10:20] 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] ah, yeah, he's on the wrong tz [10:20] go to bed! [10:20] "wrong" :D [10:21] pete-woods: yeah what Mirv said, 2am here [10:22] 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] FWIW, I don't mean to complain about this tool, you've done an astounding one-man job where others have failed [10:22] pete-woods: though you and Mirv are complaining about the same thing here [10:22] this is literally the first time it's ever done something annoying [10:22] pete-woods: +1 to that [10:23] pete-woods: Haha thanks. Pitti deserves most credit for autopkgtests I just connected the dots [10:23] 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] making me needlessly wait for failures [10:24] but maybe that'll get better [10:25] "all" is probably a bit dramatic :) [10:25] 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] robru: cool! :) [11:06] 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] michi: and webops said they have no knowledge and no access besides to the power switches [11:07] that’s wonderful :( [11:07] So, where are the people who do know? [11:07] I would have thought that Evan and Francis should know. [11:09] michi: and both states side timezones right [11:10] davmor2: I think so :( [11:10] So, it might another two or three hours. [11:10] davmor2, sil2100: will you guys be around long enough to ping someone? [11:10] It’s getting a little late Down Under... [11:10] michi: yeah, will try to get this pushed further... [11:11] 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] thanks guys! [11:13] We need s-jenkins to limp along for a few more weeks. [11:13] We are trying hard to migrate our stuff over to jenkaas. [11:13] but there are around 30 projects to migrate. [11:13] And it took nearly four weeks for us to even get our jenkaas provisioned... [11:13] Yeah, I know what you mean [11:13] The tarball team has ~8 projects and they can't really get them working yet [11:22] 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] some hard work, though, was needed [11:56] 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] 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] it has been good to get the train robust, it will help in the next Qt landings [12:00] Mirv, I'll force the creation of the card but we won't have time today [12:04] 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] I can reping tomorrow if there's still an issue [12:05] 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] pstolowski, Hey, sure, not sure when though, we'll do our best. [12:13] jibel, ack, thanks. this currently blocks builds for our entire scopes stack [12:14] pstolowski, I understand, I'll prioritize the request but there are already lot of urgent things to land [12:15] jibel, understood, ty [12:17] jibel, john-mcaleely, morphis: 15 passed [12:23] davmor2, Excellent \o/ [12:23] davmor2, very good job! === vrruiz_ is now known as rvr [12:35] hmmph [12:54] davmor2: awesome! === alan_g is now known as alan_g|lunch [13:26] davmor2, \o/ [13:26] trainguards, I can has publish on https://requests.ci-train.ubuntu.com/#/ticket/963 please? [13:28] Looking [13:29] looked already [13:29] Oh, timo is on it ;) [13:29] Thanks! === marcusto_ is now known as marcustomlinson === alan_g|lunch is now known as alan_g [14:28] omg now that's a busy britney... [14:47] hey trainguards, what does 'automated signoff: failed' for silo 64 mean? [14:53] pstolowski, it means there are some failures in https://requests.ci-train.ubuntu.com/static/britney/vivid/landing-064/excuses.html [14:54] pstolowski, http://paste.ubuntu.com/15002165/ fails on amd64 and i386 [14:55] jibel, this is a flakiness in scope harness, unrelated to anything in silo 64 [14:56] jibel, pstolowski: we can't land unity-scopes-api by itself [14:56] pstolowski: it's not entirely unrelated [14:58] dobey, ? [14:58] pstolowski: jsoncpp broke ABI [14:59] dobey, but jsoncpp is internal to scopes-api, we don't expose it.. so should be enough to rebuild unity-scopes-api? [15:00] 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] 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] dobey, ah.. i didn't know click scope links to jsoncpp [15:01] pstolowski: yes i know that. but on xenial stuff is going to break much worse [15:01] pstolowski: mediascanner does too [15:01] jgdx: ping [15:02] dobey, won't do any harm to do no-change rebuilds in same silo? [15:03] 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] dobey, i'd prefer to keep features in separate silos [15:04] pstolowski: you mean the mediascanner thing? [15:04] dobey, one silo (filters) is for user testing... the other needs design ack etc. [15:05] 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] dobey, yes, mediascanner thing [15:05] 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] dobey, only silo 24 and 64 should land, please don't consolidate the others [15:07] pstolowski: and my unity-scope-click silo which is only bug fixes [15:11] rvr, pong [15:11] jgdx: Hi [15:12] jgdx: I'm testing silo 21 [15:12] jgdx: The background looks wrong in not-windowed mode on the tablet [15:12] jgdx: http://people.canonical.com/~vrruiz/system-settings-background-landscape.jpg [15:13] jgdx: In windowed mode, looks fine, the background is displayed with the landscape ratio [15:16] rvr, I think you want to talk to ken about that. kenvandine was anything changed in the USS background panel? ^ [15:18] 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] jgdx: Oh, probably [15:18] kenvandine: ^ [15:19] dobey, great, thanks for that! [15:20] rvr, we haven't changed anything [15:20] rvr, that url gives a 404 [15:20] hopefully it rebuilds fine now as-is [15:21] kenvandine: Yeah, removed, uploading to private server, one moment [15:21] ok [15:22] kenvandine: https://chinstrap.canonical.com/~vrruiz/system-settings-background-landscape.jpg [15:22] rvr 404 there too [15:23] chinstrap redirects to private-fileshare [15:23] Weird [15:24] kenvandine, you might need the vpn on [15:25] i've gotten to private-fileshare before [15:25] and am now, just getting a 404 [15:25] https://private-fileshare.canonical.com/~vrruiz/system-settings-background-landscape.jpg [15:26] kenvandine: Can you ssh to chinstrap? [15:26] yup [15:27] wtf [15:27] rvr so there is some diagram showing there? [15:27] kenvandine: If you ssh, the file is in /home/vrruiz/ [15:27] rvr, and that's on the app switcher? [15:28] i got the file [15:28] the background we set in system-settings is only used for the greeter [15:28] so what you're seeing shouldn't have anything to do with that [15:29] 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] no, nothing to do with landscape [15:29] kenvandine: But when system settings is in the side panel, this large background is shown [15:29] it sets a fixed width to be used in windowed mode [15:30] yeah, but that isn't from settings [15:30] i don't see that on my flo [15:30] kenvandine: Background Ensure default for images is landscape [15:30] i see the app scope [15:30] https://bugs.launchpad.net/ubuntu/+source/ubuntu-system-settings/+bug/1541588 [15:30] Launchpad bug 1541588 in ubuntu-system-settings (Ubuntu) "[System Settings] Changes needed for the UI on a tablet device" [Critical,In progress] [15:30] oh, that part isn't fixed :) [15:31] that's not in the silo [15:31] kenvandine: https://trello.com/c/8xdSGk8F/2747-969-ubuntu-landing-021-ubuntu-system-settings-kenvandine [15:31] we tackled what we could in that bug [15:31] Bug #1541588: [System Settings] Changes needed for the UI on a tablet device [15:31] Bug #1542050: don't allow window to be resized (not the shell doesn't handle this properly yet) [15:31] bug 1542050 in ubuntu-system-settings (Ubuntu) "don't allow window to be resized" [Medium,In progress] https://launchpad.net/bugs/1542050 [15:31] since settings doesn't do any resizing or cropping we didn't do that [15:32] that should be "note the shell..." [15:32] rvr, what you are seeing is very strange, must be a shell bug [15:32] settings doesn't touch that, it only sets the background to be used for the greeter [15:35] rvr, the only things changed are listed in the testplan [15:35] kenvandine: Take a look to the other screenshot that I shared in /home/vrruiz/ [15:36] 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] rvr filename? [15:36] kenvandine: system-settings-background-landscape-2.jpg [15:36] so it looks like rendered artifacts [15:37] is that a pdf or something that's being showed? like some quick start guide? [15:37] kenvandine: So I expected to see landscape background in both modes (panel and windowed) [15:37] yeah, but that's not something we've worked on [15:38] kenvandine: That's a photo with krillin :P [15:38] 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] we need to use different images i think [15:39] kenvandine: So that part wasn't changed with the silo, right? [15:39] right [15:39] Ok, I'll fill a bug [15:39] only what's listed in the testplan section [15:39] rvr, i'm more concerned with that krillin image being displayed there... why is that? [15:40] 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] but on the desktop you can confirm it doesn't [15:41] kenvandine: Ok, I'm just testing in the tablet. [15:41] kenvandine: Max/minimized worked, no regressions [15:41] cool [15:42] when it's fixed in unity8 you won't be able to maximize it [15:44] kenvandine: By the way, I can still launch mobile data panel from the indicator network, although it only shows the spinner. [15:44] yeah [15:44] that needs a fix in the indicator [15:45] rvr, there's a indicator-network task for the bug [15:45] kenvandine: I was about to search for it, thanks! [15:45] np [15:45] Ok, now I will take a look to the silo with krillin [15:45] cool [15:46] \o/ [15:56] trainguards could you retry britney for unity8 aptests https://requests.ci-train.ubuntu.com/static/britney/xenial/landing-016/excuses.html ? [15:58] alex-abreu: the unity8 parts? [15:58] sil2100, yes pls [15:59] alex-abreu: retried the failed unity8 test [15:59] :) [15:59] thx [15:59] yw [16:25] 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] Trevinho: unity or part of it is reverse dependency of unity8, thus autopkgtest for u8 are run [16:27] mh, okkk [17:51] go go gadget britney === alan_g is now known as alan_g|EOD [18:10] aaaand now i have to rebuild my other silo yet again [19:30] 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] "are you shitting me?!" [20:42] * robru forgot for a sec that they're assigned in random order [20:51] hah, I see you had a moment of horror [20:52] yes, my heart jumped [20:53] brb [21:07] what the heck [21:08] oh i guess kenvandine's silo hasn't quite landed yet [21:11] dobey, need me to force merge it? [21:11] kenvandine: probably not. seems like it should go through fine once britney passes it [21:11] yeah [21:11] if it's holding you up building something i can merge it [21:12] well it's not the only thing being slow that's annoying me right now, so no worries :) [21:12] i'll just have to wait another 6 hours after that lands, for the autopkgtests for my other silo, anyway [21:13] and then probably bug qa to ignore the failed tests again [21:13] good times [21:14] maybe i should just go watch another episode of star trek [21:26] dobey: I landed the fix that makes it ignore ALWAYSFAILED so hopefully you'll be waiting slightly less [21:33] robru: cool [21:34] robru: proposed-migration still waits for the always failed to complete though, right? [21:35] dobey: no? if the package only has RUNNING-ALWAYSFAIL and no RUNNING, it's marked as Valid candidate. [21:37] hmm, ok [21:45] oh ffs [21:45] the britney queue on xenial is bonkers [21:47] thanks perl and python-numpy and qt [21:47] this probably won't even be finished by the time i'm back on-line tomorrow :( [21:49] yikes [21:50] robru: yeah, and some of them are probably going to just fail anyway, until silo 37 lands