[06:07] * Mirv manages to work on Qt still as jenkins doesn't respond [07:18] didrocks: FYI I'm continuing with Qt related work for now, good progress over there at least while no news about CI yet [07:21] Mirv: yeah, I was trying to fetch news :) [07:21] Mirv: what are you doing on Qt btw? [07:21] (just curious ;)) [07:22] didrocks: the 5.2beta1 packages I made earlier had some problems with docs&co, but I spotted the problem now and trying to get more proper packages built. lots of modules not updated yet, too, and then getting QtC + plugin sponsored to trusty now. [07:23] excellent! [07:23] plugin as upstream Qt plugins? [07:23] I'm also happy that I've somewhat updated build machine (haswell CPU), eases up [07:23] upstream QtC plugin? [07:23] didrocks: Qt Creator Ubuntu plugin [07:23] didrocks: not upstreamed, unfortunately :( [07:23] Mirv: well, this one will work through dailies, right? [07:24] didrocks: it'd work, yes, but I find that some tests would be needed. although now we're in manual mode anyhow so in that sense the daily build could be enabled too. [07:24] there's currently no tests at all for QtC + plugin functionality [07:25] Mirv: yeah, please enable daily build [07:25] as we are in manual mode [07:27] didrocks: ok. [07:29] it'll need this QtC update as well since it only builds against newer QtC, but now it's therefore a correct time to remove the disabling of daily build from config [07:31] yeah [08:14] hi guys, still a bit sick but back nonetheless [08:14] o [08:14] o/ [08:15] I managed to brick my phone yesterday [08:15] vila: hey! [08:15] didrocks: o/ [08:15] morning sil2100 [08:15] sil2100: o/ [08:15] it first failed to download image #20 several times [08:15] Morning! [08:15] then succeeded in downloading image #17 (wow, how come ?) [08:16] and installing that led to the 'ggogle' logo at boot and stayed there [08:16] before I attempt phablet-flash again, is there something I need to know ? [08:17] vila: system update? [08:18] didrocks: yeah, bricked while using OTA [08:18] system update [08:18] vila: ok, ogra knows more what happened, system update was broken yesterday: https://bugs.launchpad.net/ubuntu/+source/system-image/+bug/1250181 [08:18] Ubuntu bug 1250181 in system-image (Ubuntu) "Duplicate files in winning path should prevent updates" [Critical,Confirmed] [08:18] then, I saw that stgraber discussed about it [08:18] and remove some files, regenerate some signatures [08:18] I guess that's why you downgraded to image 17 ;) [08:19] can you keep it broken for the meeting? [08:19] so that we can discuss it [08:19] sure [08:19] it's not as if it was my main phone... err wait [08:19] :p [08:20] ha yeah, looking at the bug, I saw many ... interesting numbers in the progress bar ;) The "oops, far more than 100, let's go back so more reasonable number" was entertaining [08:20] *to more [08:21] vila: I can just testify it's not the UI :) [08:25] * sil2100 is saddened by cu2d not being accessible still [08:25] At least appmenu-qt5 will be happy ;) [08:30] sil2100: how is it going? something we can test for you? [08:38] didrocks: also, images are still created despite ci being down ? [08:45] vila: we did some, but without test results, there is little use [08:45] vila: it's easily fixed, by downloading the boot file and manually pushing it to the phone when in recovery mode via fastboot [08:49] popey: what boot file are you talking about ? [08:50] trusty-preinstalled-boot-armhf+mako.img [08:50] popey: will that wipe the data ? [08:50] no [08:52] popey: and where is that ? It seems I can't find it on system-image.ubuntu.com [08:53] http://cdimage.ubuntu.com/ubuntu-touch/daily-preinstalled/20131107.1/trusty-preinstalled-boot-armhf+mako.img [08:53] popey: thanks [08:54] np [08:58] popey: can't 'adb reboot fastboot', 'ad reboot recovery' is ok but fastboot seem to be stucked at the google logo [08:59] popey: i.e. fastboot boot stays at '< waiting for device >' [09:04] hmm [09:05] popey: hmm, may be I'm not using the right commands >-/ [09:05] hmm, does adb push work? [09:05] i thought i used fastboot but it's gone from my history [09:05] ah no, i still have the historty [09:05] fastboot flash boot trusty-preinstalled-boot-armhf+mako.img [09:06] vila: ^ [09:06] popey: right, I was missing 'flash', trying [09:06] same, waiting for device [09:07] popey: may be I need the device to be in the "right" state ? Which state is that and how do I get there :) [09:08] adb reboot-bootloader [09:08] fastboot flash boot trusty-preinstalled-boot-armhf+mako.img [09:08] is what I did I think [09:09] popey: works far better, and now 'Start' [09:10] hmm, no better, still stucked at the google logo [09:12] hm [09:13] vila, when was that, that you got r17 ? [09:13] hold on ! [09:13] this should be fixed since tonight [09:13] ogra_: yesterday [09:13] ogra_: so I should be able to OTA update mine? [09:13] popey: just needed to be a bit patient, it finally booted [09:13] popey, yes, it should give you r20 [09:14] 307MB! [09:14] vila, ah, then i'm fine ... [09:14] popey, yes, the screwup on the server actually enforces a full image upgrade [09:14] ah okay, thats cool [09:14] i love this whole OTA thing [09:15] popey, ogra_ : So, now that it booted, I'm at image #17 [09:15] adb shell system-image-cli -i [09:15] will tell you [09:15] ogra_: any explanation for the bricked behaviour after the upgrade to #17 ? [09:15] vila: known bug [09:15] popey: good (well sort of ;) [09:15] vila: bug 1250181 [09:15] bug 1250181 in system-image (Ubuntu) "Duplicate files in winning path should prevent updates" [Critical,Confirmed] https://launchpad.net/bugs/1250181 [09:16] vila, the same as for 16,18 and 19 ... broken udev upload [09:16] oh, well, thats related but not the cause [09:16] ogra_: so upgrading to #20 is fine ? [09:16] and that you even got r17 was the bug popey points to [09:16] * popey updates to #20 [09:16] ack [09:16] we had actually backed it out, but this bug kind of screwed that up [09:19] ogra_: reformulating to ensure I understand: #17 was buggy and shouldn't have been proposed as an update but the bug above screwed that and I got it nevertheless and bricked my device [09:20] vila, right [09:21] (16, 18 and 19 still had the same bug, you should have gotten #20 from yesterday afternoon on ... ) [09:21] I guess the question is why you got proposed image 17 today [09:21] and not #20 [09:21] he didnt [09:21] yesterday [09:21] ah, ok [09:21] thats why i asked when he got it as my first question ;) [09:22] yesterday, I got #17 proposed yesterday after having #20 proposed (see my comment on bug #1250181) [09:22] bug 1250181 in system-image (Ubuntu) "Duplicate files in winning path should prevent updates" [Critical,Confirmed] https://launchpad.net/bugs/1250181 [09:22] looks like you upgraded in the middle of stephane fixing the server [09:23] being almost offline (in my bed toying with the phone the few times I was awake ;) I hoped something has been fixed server side and that I was fine upgrading to #17 [09:23] (jumping from 20 to 17 kind of indicates that he was actively shuffling images around at that time) [09:23] when the phone got stucked at the google logo, I just fall asleep again [09:24] interestingly 20 on my phone is running but I just have a google logo [09:24] with full confidence the issue will be sorted out when I'll wake up ;) [09:24] but adb shell shows unity8 is running [09:24] runs fine for me [09:24] popey: that's the new screen saver maybe ? [09:24] hah [09:24] oh, it's not rebooted properly [09:25] 09:25:01 up 1 day, 7:47, 1 user, load average: 1.32, 1.32, 1.34 [09:25] also.. I have two phones and I'm adb shell'ed into the wrong one [09:25] * popey starts again. [09:25] /ignore popey [09:25] oh, i like the new click scope [09:26] * popey makes a cup of tea for the call [09:26] * ogra_ goes for fresh coffee, brb [09:48] ogra_, popey: using adb shell s-i-c seems to find #20, going that route [09:48] vila, note that on the bug too please [09:49] ogra_: on it [09:49] thx [09:49] === Image #21 building === [09:56] \o/ [09:58] lol, just got #20 installed, rebooting [09:58] ogra_, popey: there shouldn't be any difference in upgrade paths between UI and system-image-cli right ? [09:58] the UI only attaches to s-i-c afaik [09:59] ogra_: ack, hopefully [10:00] anyway, I've put the s-i-c output in the bug report, not sure the UI uses exactly that or some d-bus interface but they may find a difference [10:00] otherwise, it's not the first time the UI is capricious for me which may be caused by some local network glitch (dunno why the -cli won't run into that though) [11:16] upgraded to image #21 via UI, all went well [11:18] vila: the UI uses the d-bus interface of s-i-c [11:22] didrocks: ack. === gatox is now known as gatox_brb === gatox_brb is now known as gatox [11:57] whoops [11:57] === Image #21 DONE === [11:57] (since ages, sorry) [11:58] hehe === MacSlow is now known as MacSlow|lunch [12:03] I was wondering too :) === alan_g is now known as alan_g|afk [12:21] didrocks: you changed the time of landing standup from next tue? [12:21] (just saying in case you wanted to change it starting today) [12:21] asac: I only changed it during UDS [12:22] ic [12:22] removed the afternoon one and started it a little bit before UDS [12:22] kk [12:22] makes sense === alan_g|afk is now known as alan_g === alan_g is now known as alan_g|lunch === MacSlow|lunch is now known as MacSlow [13:25] ev: didrocks: this charting tool you use, is that also available for other chart types? === alan_g|lunch is now known as alan_g [13:57] morning [14:22] asac: no, this one is only a very light online javascript thing for this kind of diagrams [14:22] thx === greyback is now known as greyback|away === alan_g is now known as alan_g|tea === alan_g|tea is now known as alan_g === greyback|away is now known as greyback [16:20] cihelp, can the landing bot reject an MP if it doesn't have a given number of approvals by the members of a team? [16:20] elopio, I would guess that's a feature request [16:21] It seems like it wouldn't reject it, just that it wouldn't accept it [16:21] though I don't know what it actually does in practice [16:22] cjohnston, it uses lanchpad lib to get the approver list; once you have that, it shouldn't be hard [16:22] probably even enforce certain review types [16:22] with reject, I meant: move from approved to needs fixing. [16:22] I get that, but why would it be moved to needs fixing? [16:23] I am not a fan of that; whoever happroves has a certain responsibility there [16:23] this seems like a social problem that is trying to be fixed with code [16:23] cjohnston, +1 [16:23] can it be setup to require 3 reviews, yes its possible (I don't know if it is available currently, but it would be possible to add if it isnt) [16:23] if my MR is one line of code that just fixes a README I would certainly not want 10+ reviewers [16:24] we'd end up bundling MRs all in one [16:24] I would like that we have a strict policy that all the code be reviewed at least by one member of the team. [16:24] I believe it should already be setup that way [16:24] on the tarmac of u1, that's checked when the branch is marked as approved. [16:25] and it's moved to needs fixing so you can tell the bot when the branch is ready again by approving. [16:25] I believe that MPs currently require a proper team member to approve it [16:26] sergiusens: I think that even one-liners should need one review. There are typos in a big number of the cases. [16:26] but 10, of course not. I'm talking of enforcing one review. [16:26] elopio, sure, but it's variable [16:26] again, its a social problem.. if the person who marks the top as approved doesn't ensure that there has been an approved review then there is another problem [16:26] elopio, most of the type the person doing the top approve is the one doing the review [16:27] cjohnston: yes, sometimes it's the same person that writes the code the one that top approves. That's mostly when we are in a hurry, but it happens. [16:27] elopio, so people just do that [16:27] elopio: 1) social problem 2) that person should still ensure that a review has been done [16:27] so, I agree that we can just talk to the teams to avoid that, and we will do it. [16:27] elopio, not necessarily; sometimes it's an autoland gone bad (infra issues) and the same author just doing what he's already been green lighted to do [16:28] as long as it doesn't merge without a review, isn't that what is needed? [16:28] it would be nice to have jenkins making sure that they follow the policy, so we don't have to keep an eye on every project to check that. [16:28] elopio: I believe it does require a review [16:28] by a person on the proper team [16:28] elopio, cjohnston what is the policy? Nothing prevents you from just merging manually into trunk either [16:29] sergiusens: I believe that jenkins requires one approval [16:29] cjohnston, not really; if autolanding passes it just changes the vote for ps-jenkins to be of Approved [16:29] is ps-jenkins a member of the proper team? [16:30] cjohnston, yeah, ps-jenkins is a member of everything under upstream merger [16:30] sergiusens: yes, you are right, you can always merge manually. [16:30] we are in a call right now, but possibly fginther could provide a little more insight on the setup [16:31] but if we agree that we need at least one review, and never to merge manually into trunk, then what the jenkins bot would be doing is just a reminder that you are missing one review. [16:32] it would make more sense to have a comment rather than mark it as needs review [16:32] or needs fixing or whatever it is [16:32] cjohnston: yes, I agree to that. But then how will you tell jenkins to pick the branch again when you got the review? [16:33] again though, this is trying to solve a social problem with code [16:33] I'd be interested in knowing how often this problem happens? [16:34] cjohnston: agree to that too :) We'll try to solve the social problem talking with the team managers to follow the policy. But it would be nice to have an automatic reminder when you don't follow it. [16:34] elopio: who is doing the happrove though? [16:37] cjohnston: I can't give you numbers. For what I've seen, it's not common, but it tends to increase when we are in running, which can makes things worse. [16:37] the happrove is done by a member of the team, not necessarily different from the committer. [16:37] didrocks, i'm wondering, do we actually need a meeting today ? seems CI is still mostly idling [16:38] (nothing exciting about images either) [16:38] ok, so if they are happroving why aren't they reviewing (if it isn't the comitter) or if it is the comitter, why are they happroving without reviews? [16:40] ogra_: I think we don't [16:40] yeah [16:40] sil2100: vila: fginther: ev: cyphermox: kenvandine: as long as CI isn't up, I think we don't need a meeting anymore, we can skip that one ^ [16:40] didrocks, +1 [16:40] (would be nice to have a status on the infra though) [16:40] +1 [16:41] +2 [16:41] elopio, cjohnston fwiw this topic comes back every now and then [16:41] didrocks, I don't have any status yet [16:41] there was supposed to be an email coming out soon [16:41] re: status [16:41] ok [16:41] I'll provide a status shortly [16:41] * ogra_ goes back to play with his new laptoy [16:41] cjohnston: I haven't seen a happrove from without a review, but it can happen. [16:41] cjohnston: I have seen a self happrove with no reviews when the change is considered trivial or too important to wait for a review. [16:41] elopio, I believe there is a bug already for your original request (or something very similar0 [16:42] I'm just waiting for Larry to provide me a few more details so it's less "we have 80% of the racks cabled" and more "we're having m-o back up at foo PM Boston time" [16:42] elopio, will look it up in a moment [16:43] thanks fginther. [16:43] ogra_: oh! new laptop :) [16:44] yeah [16:45] x86 even! [16:46] didrocks: ok, less interuptions for me then :) [16:46] ev: awesome [16:47] sergiusens: that's why we are trying to define the details we expect from our projects [16:47] it's here, in case somebody is courious: https://docs.google.com/a/canonical.com/document/d/1D3G62wd1wMAH9zoHiHYXkabnHqelqz8Upffi0d_6iaA/edit#heading=h.nzp18cbqfdgy [16:47] comments are still welcome. === gatox is now known as gatox_lunch [17:01] didrocks: landing call? [17:01] oh sorry, didn't ping popey :) [17:01] popey: as long as CI isn't up, I think we don't need a meeting anymore, we can skip that one [17:01] kk [17:01] thanks [17:01] * didrocks pitti phew, 2 hours of discussion to push hard for dep8 in the way CI should describe the tests [17:01] :) [17:01] we'll have a happy Martin! === gatox_lunch is now known as gatox === alan_g is now known as alan_g|EOD [18:27] elopio, I finally found the bug report: https://bugs.launchpad.net/jenkins-launchpad-plugin/+bug/1134435 [18:27] Ubuntu bug 1134435 in jenkins-launchpad-plugin "Allow for only limited folk to HApprove MRs" [High,New] [18:27] elopio, it's specifically for rules around top approve, but it's a similar concept. [18:28] elopio, So the short answer is that it is not supported now, but we're planning to build it into the CI Airline system [18:28] thanks fginther, that will do for. === fginther changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: use 'fginther' for assistance | Landing instructions: http://paste.ubuntu.com/6292280/ | Known issues: All services are down (1SS move) === fginther changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: use 'cihelp' for assistance | Landing instructions: http://paste.ubuntu.com/6292280/ | Known issues: All services are down (1SS move)