[01:04] kgunn, ping [01:11] fginther: hey [01:12] kgunn, so I can switch mir to build on it's own isolated instance, but it would be limited to only 2 builds at once [01:13] fginther: can we try that and see how we feel ?....cause at this point, we just keep cycling on failures [01:13] kgunn, which brings me to the question, does mir expect to build without any other builds in progress? For example, does it use common ports when testing that might be in use by another build? [01:13] kgunn, ack, let's see how it goes tomorrow [01:14] fginther: i'll ask the experts [07:21] thostr_: hey, how are we standing WRT to fixes we want to land in today's image? [07:22] thostr_: the upstart-app-launch ones should be ready and at least in PPA [07:23] Mirv: hey, around? [07:23] Mirv: first a quick question: why was this resnapshotted to PPA? https://launchpadlibrarian.net/151313681/upstart-app-launch_0.1%2B13.10.20130924-0ubuntu1_0.1%2B13.10.20130924.1-0ubuntu1.diff.gz [07:25] Mirv: and would you mind helping me publish upstart-app-launch from PPA to archive? [07:25] didrocks: Or if you're around already? ^ [07:26] didrocks: cu2d should theoretically be back up on snakefruit now [07:26] lool: we always resnapshot if the previous version wasn't in distro [07:26] cjwatson: excellent! as soon as we have something to release, I'll monitor this [07:27] lool: landing sheet line 76 [07:27] Still restoring some other bits and pieces [07:27] didrocks: but there's nothing to snapshot? [07:27] didrocks: I mean nothing you [07:27] *wow* [07:27] nothing *new* [07:27] this was an ugly brain fart [07:27] lool: I'm looking for another last fix, then we should have fixed more or less everything [07:28] lool: you mean, there is nothing new in trunk? [07:28] thostr_: ok; is this in a different source? [07:28] didrocks: yeah [07:28] didrocks: the diff is empty short of changelog [07:28] maybe a tag, but I dont see why [07:28] no tags [07:28] lool: https://code.launchpad.net/~indicator-applet-developers/upstart-app-launch/trunk.13.10 [07:28] I see rev 62 and 63 [07:28] not in distro [07:28] hence the resnapshot [07:28] didrocks: I mean these were already in PPA [07:29] lool: right, but as said, if it's not in distro, we rebuild [07:29] lool: because your upstream build-deps have changed [07:29] didrocks: ah so there might be up to 6 snapshots per day? [07:29] yeah [07:29] even if nothing changed [07:29] (it was one before, when it was only daily…) [07:29] hmm that's pretty heavy if we are in manual mode and holding a lot of packages back [07:29] then, we try to get everything out [07:29] yeah, it wasn't designed for that manual mode [07:29] I still disagree with it anyway… [07:29] so it's some kind of test build feature [07:30] lool: well, if an upstream component changed, you are not sure that you can build again our one [07:30] like if a dep changed its ABI… [07:30] so you need to rebuild it [07:30] yep [07:30] hence this [07:30] well, sometimes you do [07:30] ;-) [07:30] anyway, thanks for the confirmation that this is by design [07:30] I don't want to push to distro components that can't be built [07:30] yeah [07:31] don't look at the diff from ppa to ppa [07:31] look at the diff from distro to ppa [07:31] like in http://people.canonical.com/~platform/cu2d/results [07:32] lool: this is all in unity8. having a standup with the guys, latest and greatest in a couple of minutes then [07:33] thostr_: hmm who were you talking to about landing this yesterday? there's no PoC in the plan [07:34] thostr_: k [07:36] cjwatson: https://launchpad.net/~ubuntu-unity/+archive/daily-build/+build/5045318 says chroot problem but on multiple architectures [07:36] lool: yes, it's ok, working on it [07:36] known [07:36] ok [07:36] I'm about to retry all those [07:37] thanks, that's what I wanted to confirm, that the builds would be mass-rescheduled [07:37] lool: you are logging by a good 30 minutes :) [07:41] didrocks: logging or lagging? do your jogging instead of joking :-P [07:41] didrocks: mind pushing upstart-app-launch w/ binaries from PPA to archive? [07:41] lool: I do both in fact :p [07:42] lool: do you mind refering to which line in the spreasheet? [07:42] didrocks: 65 [07:44] I've retried everything in ppa:ubuntu-unity/daily-build. It's a bit awkward to find chrootwait builds across all archives. Any PPAs you especially care about? [07:44] I'll try to scrape for them but it'll take a while [07:45] lool: upstart-app-launch is part of the misc stack, which has tested fine on desktop and would be therefore ready to publish (sans touch testing) - phablet-tools, upstart-app-launch, url-dispatcher [07:45] lool: so, I can publish it when wished [07:46] releasing phablet-tools and url(dispatcher at the same time [07:47] Mirv: well, the misc stack has tested fine on desktop as there is no test on the misc stack [07:47] by definition :p [07:47] cjwatson: ppa:ubuntu-touch-coreapps-drivers/daily is pulled in images still, it might have some *-app snapshots pending build [07:47] not that I particularly wait on them, but I'd rather they are built too [07:47] didrocks: the Mir experimental is still used? [07:48] lool: no chrootwait builds in there [07:48] didrocks: what was the PPA name again? [07:48] lool: Mir experimental is dead [07:48] lool: today, I hope to have Mir in distro [07:48] but there are some complications [07:48] didrocks: ok, no other PPA cup2distro publishes to? [07:48] >>> len(lp.load("/~ubuntu-touch-coreapps-drivers/+archive/daily").getBuildRecords(build_state="Chroot problem")) [07:48] 0 [07:48] lool: right now, none [07:48] cjwatson: thanks for the rune :-) [07:48] didrocks: ha, good point! I just looked at all green... [07:49] so no autopilot tests there [07:49] Mirv: lool: misc published FYI [07:49] didrocks: so, it seems, thanks [07:49] didrocks: no tests > lol [07:49] Mirv, didrocks: Thanks [07:56] thostr_: so https://code.launchpad.net/~stolowski/unity8/results-nullptr-fix/+merge/187052 seems to need additional fixes, but seems less critical if we fix the other scope crashing; do you have a link to this one? [07:57] asac, i dont remember anything for system-settings but i know they wont work anyway without logind support from lightdm [07:59] didrocks: so I assume when you said "published" it actually means these have entered some kind of upstream testing process and will eventually be copied to archive [07:59] lool: no, it's under copy to the archive [08:01] * cjwatson writes a worryingly complicated scraper [08:01] cjwatson: hum, there is no launchpad cred again [08:01] though I guess not that bad as scrapers go, http://paste.ubuntu.com/6149097/ [08:01] so the copy is stuck [08:01] didrocks: link? [08:02] cjwatson: https://launchpad.net/+authorize-token?oauth_token=7bQZs7BSJqFk5f2D2tZD&allow_permission=DESKTOP_INTEGRATION [08:02] didrocks: oh, this is probably because of the fresh rsync [08:02] so we'll have lost the saved cred [08:02] yeah, it should have rewritten over it [08:03] didrocks: reauthed [08:03] cjwatson: perfect, working, thanks! [08:08] lool: regarding the scope crash: link/merge proposal will be up shortly which will hopefully fix this issue. [08:09] thostr_: do you want to land the unity8 side of the fix too? [08:09] thostr_: that is, the unity8 sometimes crashes when a scope crash one, fix-null-ptr branch [08:13] lool: yes, let's land the fix-null-ptr crash [08:14] asac: why are the wifi settings (line 55) not targeted for release 60? [08:17] thostr_: because build 60 is yesterdays build :) [08:18] asac: yes, but it has been ready since friday... [08:18] asac: anyway, if it's in today... [08:20] OK, I think the archive jobs are fully back up on snakefruit now [08:20] And the load is actually tolerable [08:22] cjwatson: confirming that the copy to archive works btw [08:22] cjwatson: rmadison is there now? [08:23] hmm rmadison returns empty results now [08:25] lool: Yeah, I just noticed the same thing [08:27] Investigating [08:29] thostr_: right, it didnt make the cut on friday and yesterday we were dealing with resurrection. [08:30] asac: ok, fair enough. if it's in today Jason will be happy. [08:30] thostr_: i already installed it yesterday locally. looked good from what i can tell [08:31] asac: HO [08:31] yay [08:32] ogra_: meeting? [08:32] on my way [08:39] lool: rmadison is back now [08:40] What does "Candidate" mean in landing asks #89? You're still thinking about it? [08:56] cjwatson: will raise this in hangout in a sec [08:57] ok [09:03] cjwatson: so asac says that for click itself and for click pk plugin, you have a blanket upload permission as long as you test it against what's staged in ~ubuntu-unity/daily-build PPA [09:05] so enable that PPA on a device, apt-get dist-upgrade, test? [09:05] cjwatson: So I guess: a) install latest image from proposed, b) mount -o remount,rw c) add-apt-repository above PPA + dist-upgrade to it d) test click [09:05] e) there is no step e) [09:05] ok, thanks - is that for present and future uploads/ [09:05] ? [09:06] cjwatson: apparently, yes; asac suggested you had already received this permission :-) [09:07] oh, I didn't get the message if so [09:08] thostr_: indicators seems to have no landing ask [09:10] asac: there was just a bug fix in datetime which I haven't added yet, otherwise it's about bluetooth and network for settings [09:10] asac: or why do you need/want indicators? [09:10] didrocks: I killed a copy2distro that had been running for nearly three hours - that would've been from before I reauthed [09:10] just in case you get cron mail about it [09:14] cjwatson: oh, I killed the run.sh blocked because of that, I didn't notice the copy2distro one, making sense, thanks! [09:18] thostr_: they are built and have changes in trunk it seems [09:18] thostr_: search for === indicators [09:19] asac: yes, but this is also desktop related stuff [09:19] asac: so basically, people having upload rights and don't use CI have a blanket exception if they test again the PPA? Doesn't seem to encourage CI [09:20] didrocks: i said that? [09:20] no [09:22] well, I see exceptions on and off, I'm puzzled now [09:22] seems not everyone has the same process [09:22] maybe [09:22] I really find all this bringing confusion TBH [09:23] cjwatson: so [09:24] didrocks: testing against the PPA is a lot of work, it's not exactly a free pass [09:24] cjwatson: so its not whenever you test you upload without coordination [09:24] cjwatson: that was miscommunicated [09:24] cjwatson: its just easy to get a landing slot... [09:24] if you do self service (involving the testing that is suggested) [09:25] e.g. we might be finalizing an image etc. that might make an upload unfortunate timing etc. [09:25] ok, just tell me what I need to put in landing asks as a general practice [09:27] ogra_: please wait for building image, I'm adding a hint for upstart-app-launch to transition [09:28] lool, i didnt planb toi just kick one off :) [09:33] lool: asac: seems we got the unity crash finally fixed https://code.launchpad.net/~mhr3/libunity/fix-1199715/+merge/187172 [09:34] thostr_: is that fixing everythign :)? [09:34] e.g. the scope and the unity crashes? [09:34] very nice [09:35] asac: well, the unity crash nobody could really reproduce. but since it was crashing because of scopes crash we should be fine now. and remember, this would not happen in production environment anyway [09:35] it always happens :) [09:35] always [09:35] i installed three times [09:35] ran the instructions and it always happened [09:36] but well [09:36] we can see [09:36] once your package is built i will try with that [09:37] well, it happens when you run autopilot, but it wouldn't if not running it [09:46] mornin [09:46] hey cjohnston [09:46] :-) [09:53] hi psivaa, looking at https://code.launchpad.net/~lool/music-app/unquote-desktop-file/+merge/187115 it seems Jenkins is not running tests and doing autolanding. Are there any known issues with it? Thanks. [09:54] dpm: let me take a look [09:55] cool, thanks [09:57] psivaa: http://91.189.93.70:8080/job/trigger-ci-and-autolanding-job/2945/ looks to be a little stuck [10:00] lool: asac: we got all approved now, so once it's merged can we get lines 76, 77 and 78 in today's image? [10:01] cjohnston: that is stuck indeed, but i dont have the permission on that jenkins instace to abort it [10:01] I doubt I do either... lemme look [10:03] didrocks: do you have perms on http://91.189.93.70:8080/job/trigger-ci-and-autolanding-job/2945/ ? [10:03] thostr_: first cut is already done, we try to do a second run [10:03] cjohnston: it doesn't seem I do either :( [10:04] didrocks: hrm.. interesting.. according to the people page it would look like you do. [10:04] cjohnston: people page? [10:04] maybe someone created an account for me on it [10:04] but I don't have the credentials/remember them [10:04] didrocks: http://91.189.93.70:8080/people/ <--- looks like you've modified stuff [10:05] 18h ago? [10:05] I clearly didn't touch that jenkins instance for ages [10:05] * didrocks looks at his chromium [10:05] maybe there's an imposter [10:05] ;-) [10:05] clearly someone stole my creds :p [10:06] no, no creds in chromium as well [10:07] dpm: i *think ps-jenkins should have been added as an approver for autolanding. but it was not. may be that's the reason why jenkins is not running on that [10:08] psivaa: I don't think those jobs use ps-jenkins because they are the community jobs... [10:08] dpm: either way, it looks like we will need to wait for fginther on this one since we don't seem to have access... which we also should get taken care of [10:13] cjohnston: grrr, no way to recover the password if needed :/ [10:24] ogra_: cool, I see touch-sesssion and upstart-app-launch are now both in archive [10:29] psivaa, cjohnston, ok, thanks. It seems we'll have to wait for fginther then [10:31] lool, great [10:34] ogra_: I hadn't thought about it this way, but I guess we could just kill the upstart-app-launch dep in unity-touch-session anyway [10:35] why ? is it seeded ? or doesnt something else pull it in [10:35] *does [10:48] ogra_: it's pulled by url-dispatcher which calls into it [10:49] ah [10:49] ogra_: not sure what else uses it, but basically things using it should depend on it I guess [10:49] yeah, then we can unseed it as long as it isnt a recommends [10:57] thostr_: do you have the commit rev for what is supposed to fix that unity8 crash? [11:01] lool: around? there is an interesting case for daily release with the Mir transition if you want to pair on what's going on here [11:04] psivaa: would be cool if you have time to run some unity8 tests [11:04] from the ppa [11:04] I can help you defining which packages are needed to be tested [11:05] didrocks: sure just a sec [11:06] psivaa: just ping me back ;) [11:07] popey: did a mail go out yesterday? [11:07] jibel: ^^ cant see the changes updated [11:07] asac: ya [11:07] asac: https://lists.launchpad.net/ubuntu-avengers/msg00015.html [11:07] hmm [11:07] jibel: can you give us the script to kick off your /current runs? [11:07] or maybe put a cron there :) [11:08] asac, hmm, might be he pulls from me ... seems i messed something up when adding current-vs-pending for lool [11:08] thostr_: i assume line 68 (music experience) is still coming together? [11:09] (e.g. not ready)? === vrruiz_ is now known as rvr [11:11] asac: is -v supposed to work with phablet-test-run? (I'm used to run autopilot directly on the phone) [11:11] I'm just getting: [11:11] Tests running... [11:11] __pthread_gettid -2 [11:11] and then nothing [11:11] I see the tests happening though [11:11] but no clue what it's testing [11:11] didrocks: if you run unity8 you have to run with -n [11:12] otherwise you have to run it without any argument (but unlock the screen by hand ) [11:12] didrocks: ah ... well, i dont know how to tell it to echo back what it tests [11:12] i only look at the final results that come out [11:12] it only does output at the end of the run [11:12] right [11:13] ogra_: lxc-android-config ... timezone selction [11:13] thats in landing plan ... idnt that land already? [11:13] hmm, not sure [11:13] * ogra_ checks [11:13] ogra_: so no real time? same issue than UTAH I guess… that's hard to follow though [11:13] its inarchive in any case [11:13] didrocks, send them patches :) [11:14] ogra_: I told doanac to look at what we did for otto, pretty simple things based on tail -F, so I guess patches sent :) [11:14] I'll rediscuss about those with him [11:14] asac, not in any image yet (timezone stuff) [11:14] ogra_: but uploaded? [11:15] asac, yeah [11:15] which line is it in landing plan? [11:15] will be in the next build [11:15] * ogra_ checks [11:15] ogra_: ok i see it [11:15] 55 [11:15] i am adding landing no.1 now [11:15] so i can refer to them in the landing asks [11:18] asac: so, who is the vanguard? [11:18] it seems we have one autopilot-intel machine down [11:19] (and nobody notices as we don't have anymore monitoring responsible) [11:19] so sdk is stuck for some hours [11:19] (and we miss ticks because of that) [11:20] the vanguard system was decided together with ev... i was hesitant to kick that off while he is away... next week we will knock that off when he is back [11:20] hum, ok, but for now, everything is then block [11:20] * didrocks will fix it [11:20] but this doesn't work it seems, nobody is feeling responsible :) [11:20] didrocks: so how did you find out about that? [11:21] didrocks: err... be realistic man :) [11:21] as i said, the vanguard duty was not implemented yet [11:21] asac: looking at http://10.97.0.1:8080/ [11:21] we can see that the sdk stack is running for long [11:21] (if people refresh the page) [11:21] I looked closer [11:22] and there is autopilot-saucy-daily_release » autopilot-intel waiting [11:22] hovering on it shows that the machine is offline [11:22] (confirmed when looking at the executors) [11:23] right. so there are two ways vanguards would start acting upon something [11:23] 1. a warning system shows a problem [11:23] 2. someone finds that there is a problem and escalates [11:23] in this case noone found the problem but you... [11:23] so you would have now informed the vanguard and they would have tried to act on this (and learn)... [11:23] now the tricky part is why was it you who found the problem? [11:23] I meant in the previous world, we would have someone finding about the problem ;) [11:24] not sure what you mean [11:24] you found it :) [11:24] I meant, way before [11:24] in previous world you or one of your team would have found about it [11:24] so its the same still :) [11:24] right [11:24] but now there is no more responsability for it [11:24] for that to change we have to teach more people about cu2d [11:24] etc. [11:25] didrocks: no responsiblilties were changed [11:25] everything stays the same until we change it [11:25] asac: crash fixes merged. so, lines 68, 70, 76, 77 and 78 should land in the next image [11:25] didrocks: so the fact that we havent managed to train and edcuate people is a blocker of moving the responsibility of your sole own shoulders to a broader basee [11:25] asac: that should give us the full music experience [11:26] asac: I wasn't the only one looking at this before, the consequence is that it seems I'm the only one now [11:26] didrocks: well, sil is sick :) [11:26] mirv is almost done with the day. [11:26] yeah, jibel would have covered otherwise [11:26] he also said he wouldnt drop the ball without transitioning it off [11:30] didrocks: just back from lunch [11:31] didrocks: sure, ready to follow on it :-) [11:31] lool: well, the intel machine is screwed, so no point for me [11:31] I just rebooted the intel AP machine [11:31] it doesn't come back [11:31] Mirv: I did that as well 5 minutes ago [11:31] oh, apparently doesn't help then [11:31] doesn't come on [11:31] up* [11:31] asac, it is updated when there is something new in ogra's current/ [11:31] ah back [11:32] maybe my reboot was better :) [11:32] Mirv: maybe as you rebooted while I was rebooting, it just make the second reboot longer [11:32] the script is here http://people.canonical.com/~j-lallement/touch/changes/ [11:32] Mirv: or maybe you did push stronger than I did :) [11:32] http://people.canonical.com/~j-lallement/touch/changes/touch-changes [11:32] yeah, i need to fix an issue ... [11:32] ok, machine back [11:32] let's see the jenkins node [11:32] and it's up again [11:33] lool: ok, want to deal with that in a hangout? [11:33] asac, by updated I mean updated automatically [11:33] didrocks: can we do it in 15-20 mn? [11:33] didrocks: Id like to do another quick hangout first, and hten I'm all yours til 3pm [11:33] lool: fine with me, I think Mir can wait a little bit more :) [11:33] didrocks: I'll put my nicest pair of glasses for the hangout [11:33] excellent plan! [11:37] asac: I did find about the stuckness in a similar way, as I'm trying to look at cu2d now throughout a day from time to time because sil2100 is sick. normally it'd be sil2100's turn at the moment. [11:40] asac: the key problem at the moment is probably that the moment I sign off there's a delay until ken/robert/mathieu are online, and they are now so uberbusy with other stuff that it is more like me the next morning that will fix the cu2d stuff. [11:40] if one considers cu2d part only [11:41] asac: normally we've had near-24h cu2d following, and the bottleneck has been hw breaking up and only US timezone people available to fix it [11:47] anyhow, on publishing front all (indicators, click-package, apps) now tested and published. waiting for asac on the settings, needs ack from core-dev like ogra on http://pastebin.ubuntu.com/6149724/ [11:51] Mirv, looks fine [12:03] asac: so, we can't release unity8 without Mir FYI [12:03] didrocks: ok good [12:03] didrocks: so lets work on MIR first [12:03] :) [12:05] hi kgunn_ [12:05] kgunn_: there were a few merges we were missing [12:05] on MIR [12:05] hm, so I tried to run the unity8 tests on a baseline 60 image upgraded to ubuntu-unity/daily-build (minus lxc-android-config), but even without my new click version the tests crash and burn [12:05] they get a little way in and then I get "Restoring shell" and "error: device not found" [12:05] asac, how is that ?...or what was missing [12:05] cjwatson: if you upgrade to everything you dont know what you get [12:06] asac: Well, sure, but I was told to upgrade to that PPA to test click [12:06] cjwatson: what you should do is take your rdepdends ... i was mostly interested in seeting to apt-get install the click related changs that are staged [12:06] Consistent instructions would be nice! [12:06] to see if that your change doesnt break them [12:06] hmmmm [12:07] So, fine, I'll take my rdepends, thanks [12:09] so started doing this: https://wiki.ubuntu.com/Touch/Testing#Testing_your_Ubuntu_Touch_Code_before_submission [12:09] i guess that should be improved to better cover the case [12:10] Mirv: do you have a phone where you can test with system-settings? mine just broke twice [12:10] * asac reinstalls [12:10] Mirv: just thinking maybe yours is just one apt-get install away [12:11] asac, can you elaborate on what has happened ? (i'm assuming mir didn't get updated in touch for some reason) [12:12] kgunn_: didrocks has the details... you didnt approve your the merges that were discussed afaik [12:12] topapprove [12:17] asac: in a hangout, dealt with Mir already thanks to greyback & co [12:17] didrocks, thank you [12:17] Mir is blocking unity8 fyi, I'll give more details later on [12:17] didrocks, i didn't want to bump build deps out of order ...so i held off [12:18] kgunn_: you needed though to top approve all the branches [12:18] (I did them this morning) === alan_g is now known as alan_g|lunch [12:18] didrocks, thanks...its clear now [12:18] i didn't realize it was my responsibiliity - but i know now [12:20] kgunn_: i think we want the build deps to be bumped before you merge your trunk afaik ... [12:22] didrocks, is that right? ^ i bump theirs before mine? [12:23] kgunn_: yeah, yours, then all the deps [12:23] committed to memory [12:26] asac: well I had at least, I can upgrade the system-settings as well [12:28] Mirv: thanks. i am still installing :) [12:29] * asac happy to move to the next, bigger task [12:35] asac: ok, installed, wifi section seems to work, I've browsed through the other sections and nothing seems to crash at least [12:38] asac: in case you don't want anything special tested, I'd like to publish settings. too bad there's no autopilot tests for it, but I looked through the changelog and used the changed panels more and everything seems correct. [12:42] Mirv: sunds good [12:42] thanks a lot [12:42] ogra_: after we want an image [12:47] asac, ok [12:51] morning [12:51] dpm, core apps jenkins is unstuck [12:59] awesome, thanks fginther. Do we need to retrigger any jobs, or will it happen automatically? === alan_g|lunch is now known as alan_g [13:00] dpm, it should be automatic [13:01] dpm, in this case, the trigger job was stuck, so nothing was getting started [13:13] ok, thanks fginther [13:34] didrocks: all yours again [13:34] didrocks: same HO? [13:34] didrocks: grabbing a coffee [13:35] lool: ok [13:35] fginther, my ubuntu-wallpapers branch is still failing CI [13:35] hudson.util.IOException2: remote file operation failed: /home/ubuntu/jenkins/workspace/ubuntu-wallpapers-saucy-amd64-ci at hudson.remoting.Channel@47d6afce:kinnara [13:37] ogra_: everyuthing in? [13:37] ready for kick and further landings? [13:38] kenvandine, sorry about the lack of status here. For some reason, this doesn't work through our tools (which use a recipe) but if I do it with a simple inline script, it works. I just need to finish this up and replace the existing jobs [13:39] asac, dunno, i couldnt really follow all landings today (and my own ones are rather complex) [13:39] asac, lool, are we ready ? [13:39] * ogra_ will happily kick a build [13:39] ogra_: checking thostr_ stuff [13:39] k [13:40] ogra_: are you about to promote or to build? [13:40] build todays image [13:40] we didnt have one yet [13:40] ok, then just a sec [13:40] right [13:40] so url-dispatcher and upstart-app-launch are what he needs [13:40] fginther, that's sort of funny [13:41] I know upstart-app-launch is in, without the tests which took forever to merge [13:41] or rather, got merged now but aren't in PPA [13:41] but it's ok [13:41] then url-dispatcher [13:41] sergiusens, funny in the it "annoys the heck out me" sense, right? [13:41] latest bzr changes are in [13:42] sergiusens, my theory is that the wallpapers project has files with unicode characters and that's somehow causing the odd behavior, the armhf build fails with what looks like a bzr bug [13:42] sergiusens, http://10.97.2.10:8080/job/ubuntu-wallpapers-saucy-armhf-ci/6/console [13:42] fginther, no, funny because we started using recipes (if it's pbuilderjenkins) out of kenvandine indirect suggestion [13:43] fginther, thanks, I'll look [13:43] fginther: send those bugs my way, if I can't fix them I should at least be able to provide a diagnostic [13:43] vila, thats right, we have a bzr guy now [13:43] fginther: urgh ! latin-1 ??? the locale on the host where this is executing should be set to utf-8 [13:44] encoding: 'iso8859-1', fsenc: 'ISO-8859-1', lang: 'en_US' clearly says the system is not configured as... expected ;) [13:45] vila, that might be easy fix then [13:45] fginther: is there a way for me to shadow you while you fix this ? [13:45] ogra_: so only thing out of sync is music-app *again* [13:46] awesome ... [13:46] i guess it just wants attention :P [13:46] ogra_: https://code.launchpad.net/~vthompson/music-app/fixes-1229153/+merge/187123 [13:46] vila, sure, I could probably use your help, one moment [13:47] lool, hnm, all approved ? [13:51] ogra_: yeah, the jenkins side keeps unsetting it because it fails [13:51] ;( [13:51] fginther: could you help landing https://code.launchpad.net/~vthompson/music-app/fixes-1229153/+merge/187123 like nowish? :-) [13:51] fginther: would like to have it in next image [13:51] fginther: needs to build in PPA too [13:52] ogra_: if not, will be tomorrow [13:52] well, it would be nice to have that done at some point [13:52] seems to be a constant wart we stumble over [13:53] lool, it has merge conflict. I can try to fix it [14:00] fginther: that would be cool [14:00] lool, https://code.launchpad.net/~fginther/music-app/fixes-1229153/+merge/187242 [14:01] dpm: Can you approve this new one ^ [14:01] dpm: fixes merge conflict with trunk [14:04] fginther: who else can help on this? can you see if vila an shadow you on these breakages maybe? [14:04] vila: ? [14:05] asac: yup, I already proposed shadowing on a previous one and waiting on fginther to appear in full light ;) [14:06] vila, sorry, this other thing seamed rather super urgent. almost ready [14:06] fginther: not complaining ! take the time you need ! [14:07] fginther: or pull me in your shadow for this new one, whatever works for you ;) [14:07] lool, fginther, looked good to me, happroved [14:07] lool, it passed ci, just need dpm or popey to approve [14:07] dpm, \o/ [14:08] ChickenCutlass: what is landing on the whitelisting from your side? [14:08] is there an ask? which component? [14:08] happroved == top approved ? Where is that idiom coming from ? [14:08] asac, there are MR's now -- need to add the ask [14:08] vila, hangout ok? [14:08] fginther: yup [14:08] ChickenCutlass: ok. [14:08] thanks let me know [14:11] ogra_: lool: asac: will no crash bug fix make it into today's image? [14:11] thostr_: unity8 is hooked up with the MIR landing we try to get ready for pushing to archive this afternoon [14:11] thostr_, dunno, i didnt start a build yet :) [14:11] thostr_: its a technical problem on how we ensure that everything uses the proper API/ABI [14:12] asac: ok, so we should get all automagically in [14:12] release technical [14:12] thostr_, right, but sounds like in a later build [14:12] thostr_: you have landing asks and we have that on our radar to take asap (as we are very keen on that fix :)) [14:12] so yeah. if its tested etc. and doesnt regress [14:12] you are pretty save [14:12] (unity8 that is) [14:12] we're keen on all fixes :) [14:12] well, just saying that all fixes are ready from our side [14:17] thostr_: the build started 20 minutes ago, I hope that all went in ;) [14:17] you can check on the result page if you have the commits you need listed [14:17] didrocks: keeping my fingers crossed [14:17] http://people.canonical.com/~platform/cu2d/results [14:19] I've tested click 0.4.8: it passes unity8 and the random autopilots I tried; I can still install and open click packages from the dash, (manually) remove them, and the update manager still appears to work although it's somewhat rough as yet [14:19] So is that OK for landing ask 90 or is now a bad time? [14:21] cjwatson: it's ok to land, please do [14:23] didrocks: uploaded, thanks [14:25] yw, thanks to you [14:30] music-app since 4 mn in PPA, I wonder whether it missed the boat already [14:30] i still havent started a build :) [14:30] oh cool [14:30] didrocks: the crash fix is missing [14:30] be assured i'll ping you and asac when i do :) [14:31] thostr_: so, it landed to trunk after the rebuild/tick, we can rebuild it [14:31] anyway, right now, Mir is blocking everything and we have a failure to build [14:31] ok [14:31] didrocks: which one is it now? :-) [14:31] looking [14:32] lool: look at #ubuntu-mir [14:36] lool: didrocks: asac: I need to call it a day... feeling too sick by now to concentrate [14:36] thostr_: sure, enjoy your evening (or how you can enjoy it ;)). Btw, add me the list of sick :p [14:36] lool: didrocks: asac: contact mhr3 if you need more info on the crash fixes [14:37] didrocks: yes, it seems irc spreads gems as well ;) [14:37] heh, probably :) [14:37] i wish it was spreading gems :) [14:37] germs... not so much [14:39] thostr_: ok [14:39] thostr_: as soon as we unblock Mir, we will be able to land updates in Unity8 stack [14:39] thostr_: yes. go away [14:39] thostr_: take good rest [14:39] lool: will do. [14:39] thostr_: in case you dont come back, is mhr3 also good for tomorrow morning check? [14:40] thostr_: who would know about indicators etc.? [14:41] asac: in worst case mhr3 knows, but I plan to be back. for indicators ask Ted/Charles, but there shouldn't be anything heavily crucial until tomorrow. [14:43] didrocks: https://code.launchpad.net/~lool/cupstream2distro-config/add-ubuntu-touch-customization-hooks/+merge/187257 [14:43] lool: was it preNEWed? [14:44] lool: as when we add it, we don't want to spam the NEW stack ;) [14:44] didrocks: it's already in archive [14:44] didrocks: I'd like it to be autolanded [14:44] ah ok, good then, approving [14:44] lool: you have the upstream merger working with it? [14:44] didrocks: don't think so, where do I configure that? [14:45] didrocks: I've requested https://launchpad.net/~ubuntu-unity to be added to the project acl [14:45] lool: fginther is the contact point for that [14:45] lool: also, I hope the package follow the daily release guidelines in term of packaging [14:45] maybe you didn't check, I should wait before merging [14:45] (packaging sanity check) [14:47] lool: you don't have a bootstrap commit message, it means that it will show all commits from the creation of the project, is that wanted? [14:47] you don't build with --parallel [14:47] even if it doesn't make sense, we try to have the same debian/rules everywhere [14:47] ah, and no split mode :) [14:47] lool, it looks good, I'll get it added once the MP merges [14:47] * didrocks looks for the page [14:48] lool: https://wiki.ubuntu.com/DailyRelease/InlinePackaging [14:48] this is starting to be quite old, but robru note what we do most of the time on a package === alan_g is now known as alan_g|tea [14:48] also looking at other packages help to get them on shape [14:48] in* [14:51] Mirv: hey [14:51] Mirv: did you do some manual testing of indicators on phone before landing? [14:51] Mirv: I see it's written no manual testing, but I was asked by asac to run some testing before landing, which I couldn't do yesterday [14:52] so I was a little surprised to see indicators land [14:52] didrocks: split mode? [14:52] lool: yeah, see the wiki page, it will be easier [14:56] fginther: thanks [14:59] asac: so, FYI, a lot of components are getting block on Mir/xmir due to other archive changes (probably toolchain or libs related), see #ubuntu-mir for more information [15:01] didrocks: hmm. ok [15:01] didrocks: can we do unity if we continue to ignore mir for a few [15:01] asac: we can with forcing and hacking up thogh [15:02] asac: we can't test it on desktop, because unity-mir isn't installable anymore in the ppa [15:02] so we have to bypass [15:09] lool, i'm just in a call with diwic, where does the N10 pulse fix stand ? [15:11] didrocks: right. thought about wiping the scene, disabling MIR and just building unity8 (like we did while mir was sprinting) [15:11] asac: this will make us loose 2 hours at least [15:11] ogra_: my understanding is that we are waiting for code on that one [15:11] asac: so trying to bypass rather [15:11] ok if you can do that in a controlled manner the better [15:11] asac: but yeah, all the rest will still be blocked until Mir exits [15:11] if I don't wipe the scene [15:11] ... didnt know we would be able to untangle it without a complete flush [15:11] asac, seems its all ready and waiting for a tester since a while [15:12] asac: for that case, I can [15:12] didrocks: right. so i think we have to clean sweap anyway at somet point [15:12] question is when the best time is [15:12] your call... [15:12] all i know is that mir - while important to get them back - is less important than the unity8 fixes we want :-P [15:12] ogra_: I think I had asked diwic to a) prepare a PPA with the changes (you saw that one) and b) find a tester with a N10 for the binaries [15:13] this is the last time I heard about it [15:13] ogra_: landing ask 66 apparently [15:13] lool, https://launchpad.net/~phablet-team/+archive/pulseaudio [15:13] I might have added the entry there for him not sure [15:13] ogra_: did he get that tested? [15:14] lool, i thought you had an N10 to test [15:17] ogra_: nope [15:17] lool, i think rsalveti can test for you then [15:18] lool: I'll take care of the testing & upload [15:18] rsalveti: thanks! [15:32] bfiller, just want to follow up from yesterday. The address-book-app and webbrowser-app upstream merger tests appear to be working well now. [15:32] fginther: the guys told me all seems well now, thanks for your help [15:35] lool: did we get a new image now? [15:35] ogra_: this morning the landing ask still had "waiting for code"... if folks dont update that i cant find it [15:35] i will surealy not look at bugs and search for patches in there etc. :) [15:36] asac, ? [15:36] ogra_: anyway... i wonder if we managed to build a new image kick [15:36] thats more important [15:36] ogra_: the N10 fix landing ask had "waiting for code" [15:36] asac, still waiting for lool's go [15:36] lool: can we just ignore your landing [15:36] ogra_: music-app is fine [15:36] its not a regression from yesterday [15:36] asac, its not my task [15:36] ok [15:36] asac, thats why i pinged lool about it [15:36] ogra_: the asks should be updated by the requestors [15:37] ogra_: ok can you build the image now? :) [15:37] ogra_: \o/ [15:37] asac, they dont have write abilities [15:37] * asac thinks about the idea of having earlier landings [15:37] err [15:37] * didrocks has one failure on unity8 [15:37] earlier image builds :) [15:37] psivaa: what about you? [15:37] lets try to set a hard cut time tomorrow [15:37] asac: I think there was enough in archive this morning to kick a build :-) [15:37] and dont wait for "more fixes that are close" [15:37] and promote it now [15:37] asac, we should just let cron do a morning build for us [15:37] timeout on the scope [15:37] lool: invoking the lool clause for http://paste.ubuntu.com/6150582/ (telepathy-mission-control-5) and http://paste.ubuntu.com/6150596/ (apparmor-easyprof-ubuntu) [15:37] ogra_: +1 [15:37] lool: maybe... lets kick. and land something tonight [15:37] lool, asac, so should i kick a build now ? [15:37] so we really have somtehing tomorrow morning to act upon [15:38] ogra_: lool said yes, and everything in the archive was long done, so yeah [15:38] lool: are these ok to upload? just adding apparmor accesses where they were denied before. apparmor profiles load. no risk of regression [15:38] jdstrand: looking [15:38] asac, lool running [15:38] ogra_: thanks [15:39] ogra_, asac: Sorry, my bad for not confirming clearly on music-app [15:39] I said something about it, but it wasn't very clear [15:39] then thostr stuff got stuck with Mir [15:39] so it will have to wait tomorrow at least [15:39] yeah no worries ... [15:39] no worriesw [15:39] : [15:39] ) [15:41] lool: I should also mention I ran an app and a webapp with the new profiles. worked fine [15:43] ogra_: tweaked description of the "android" landing [15:43] found the name super confusing, and "wakelock" too since we also need a screen wakelock [15:44] ogra_: also, we need to land platform-api too, right? [15:44] heh, well, we kind of emulate a kernel wakelock :) [15:44] rsalveti, ^^^ ? [15:44] ogra_: actually this is just application lifecycle no? [15:44] i dont think we do [15:44] right [15:45] ah dunno, I'm not sure what this whitelist does [15:45] it allows the app to connect to the service that keeps the app alive [15:45] asac: psivaa: I reran and still get one failure [15:45] maybe I'm not up to date or anything [15:46] didrocks: my second attempt is still running [15:46] it's still this timeout from the scope [15:46] first attempt worked with all 24 passes [15:47] mako or maguro? [15:49] didrocks: mine is maguro [15:49] ok, maybe a mako-only race [15:49] lool: ogra_: yes, for the android package rebuild, we need to land platform-api and spin a new package for it [15:49] jdstrand: you may go and upload [15:49] \o/ [15:49] that's a no risk for the package itself as it touches the android side-only [15:49] lool: thanks :) [15:49] rsalveti: could you confirm what it gives for music-app? [15:49] lool: then a rebuild of the android package [15:49] lool: doing atm [15:49] rsalveti: is it the screen turning off thing or the application lifecycle? [15:50] rsalveti, ok, thanks, adding it [15:50] ogra_: thanks [15:50] lool: yes and no :-) [15:50] rsalveti: lol [15:50] didrocks: second attempt also came back all 24 passing. http://pastebin.ubuntu.com/6150662/ is the exact version that i am running on, [15:51] it's part ot the lifecycle, but not part of platform-api [15:51] done by powerd [15:51] psivaa: ok, excellent, thanks! [15:51] yw :) [15:51] asac: so, I can hack up to send unity8 to distro [15:51] ricmm: I think your changes for media-app will not work when the device is suspended [15:51] rsalveti: my question was, does this merge proposal linked there against platform-api whitelisting music-app like phone-app give us a way to prevent device from sleeping, or a way to bypass application lifecycle SIGSTOPing it? [15:51] or when you press the power button [15:51] passing on psivaa's hw, I have a flacky test here [15:52] rsalveti: what changes? [15:52] ricmm: https://code.launchpad.net/~ricmm/platform-api/music-app-background-android/+merge/187135 [15:52] rsalveti: of course not, this is only the app manager part [15:52] that will let the app to work in background, but it'll still stop when suspending, right? [15:52] rsalveti: the app also needs to register with powerd [15:52] to prevent it from sleeping until the app acks the transition [15:53] so there are two parts to it [15:53] right [15:53] we need both [15:53] ok [15:53] makes sense now [15:53] the powerd part I saw mike discussing with mhall earlier [15:53] so I think he passed down the needed implementation [15:53] * didrocks does [15:53] so that's just the application lifecycle background part, ok [15:53] lool: yes, the second part is the music-app itself holding the system awake via powerd [15:54] ack [15:54] ricmm: do you know if we gave a contact to the upstream developers? [15:54] by means of registerClient (s) and ackStatechanged (i) [15:54] asac: unity8 published to proposed [15:54] ChickenCutlass: did you give mhall the API in your talks with him? [15:54] earlier today, I cant remember [15:54] ricmm: actually I think I see it on #ubuntu-touch [15:54] yea [15:55] ricmm: Yes, Chicken did already [15:55] cool [15:55] awesome [15:55] magnificient [15:57] cjwatson: your click landing didn't include packagekit, did it? [15:58] didrocks: ok cool. lets hope for a decent timing so we dont pick half in the current image :) [15:58] cjwatson: I mean, it had PK related changes, but you didn't want to land src:packagekit changes [15:58] didrocks: you think thats in proposed and needs hinting? if so, we might want to wait till the image is produced [15:58] (should be like 20 minutes) [15:58] asac: shouldn't need hinting, it's only part of touch [15:58] so shouldn't be blocked, right? [15:58] didrocks: not sure... maybe we should block it for 10 minutes until the image is done [15:58] ogra_: where is the image? [15:59] ogra_: can you see the logs? [15:59] asac, building, stop being imaptient :P [15:59] hum, I thought the image was based on a frozen package list? [15:59] ogra_: at which stage? [15:59] so we won't take half of anything [15:59] didrocks: its always the latest unfortunately :) [15:59] so, let's say it's proceeding unity8 [15:59] didrocks: proposed is supposed to protect us from dependency issues [15:59] and we copy a new version [16:00] it can take an unity8-private which doesn't match? [16:00] interesting… [16:00] didrocks: if proposed would let that through and dependency resolution allows it yes [16:00] i think we have two safety nets, but not perfect [16:00] ricmm, yes [16:00] asac, it is more than 2/3 done [16:01] ogra_: did it already get the packages files? [16:01] should be tarring upp soon [16:01] ok [16:01] yep [16:01] didrocks: guess its safe [16:01] whatever isnt in saucy by now wont be picked up [16:01] deps seem to be all fine [16:01] good ;) [16:01] so assuming proposed was not in super-pursuit mode today :) ... i am sure what you copied isnt in at all [16:01] so perfect tioming actyually :) [16:02] we might as well go ahead and go for the next landings :) [16:02] so tomorrows image has something good [16:02] yes ... [16:02] so let me do some food and then check if there is anything to do... i assume though that didrocks itself wont be around :/ [16:02] * asac thinks about pinging other random people :) [16:02] lol [16:03] * asac hopes the training goes well :) [16:03] like a snowball.. train one, that one trains two and so on :) [16:03] asac, well, we have enough big stuff now ... [16:03] after picking all the low hanging fruits for days [16:03] * didrocks has been called "random" :p [16:03] lool: I wasn't touching src:packagekit, no [16:04] asac, and i would prefer to land everything thats big tomorrow, then we have two days to roll back and fix if needed [16:04] lool, didrocks ^^^ opinions ? [16:04] lool: (haven't had to touch it directly for a while - most things are in the plugin) [16:05] * ogra_ thinks having more rollback time is aa good thing for the upcoming bigger landings (Mir, multimedia etc) [16:05] ogra_: I'm fine with this, it will mean that nothing will land today [16:05] until tomorrow [16:05] ogra_: we can pick more low hanging fruits [16:05] ok [16:05] asac: we can't easily [16:05] fine by me :) [16:05] due to Mir :p [16:05] plars: it was updated to "devel-proposed". [16:05] didrocks: a so we do clean sweap? [16:05] asac, yes, but the later we land stuff this week, the more likely it is that we have to work on the weekend or roll back everything on friday [16:06] didrocks: can we do the stack reshuffling maybe tomorrow? e.g. move unity-more and system-compositor in the same stack as mir? [16:06] at least we can keep them more isolated then [16:06] (is my feel) [16:06] Mir requires lightdm ... thats two big ones [16:06] didrocks: Q: is there a way to pull Mir out of landing, then land unity, then put Mir back in? [16:06] (and one not fixed yet) [16:06] multimedia ia also quite a big one === alan_g|tea is now known as alan_g [16:06] asac: system-compositor is already in the same stack as mir [16:07] I did that yesterday [16:07] but unity-mir can't be in the same stack for the reasons explained yesterday ;) [16:07] (and again, that won't fix anything) [16:09] didrocks: I added a WI for you here: https://blueprints.launchpad.net/ubuntu/+spec/ci-s-post-lexington-sprint [16:09] josepht: ok, it's a cron right now, so it doesnt' block you, but yeah, can do later [16:11] didrocks: do you have the link for the current results? [16:11] josepht: http://people.canonical.com/~platform/cu2d/results [16:12] didrocks: ty [16:13] yw ;) [16:15] err [16:15] someone deleted the whole requestor column [16:15] any idea? [16:15] lool: was that your changes? [16:16] no [16:16] omg [16:16] * ogra_ neither [16:16] at least not that i know of [16:16] doesnt gdocs have a timeline history ? [16:16] anyone has a chrome working? [16:16] it has [16:16] I hope it wasn't a typo or something [16:16] just have no browser to use it :) [16:16] hehe [16:16] I'm looking at history [16:16] or trying to rather [16:17] but "last edit was seconds ago by asac" ;-) [16:17] right [16:17] yeah [16:17] i am trying to look at revisions [16:17] i can totally imagine that it was me [16:17] I'm booting google-chrome [16:17] or a bad ffox bug [16:17] chromium doesnt work for me anymore [16:17] ffox never worked and is such a PITA [16:18] * ogra_ only has the arm chromium version here [16:18] ah [16:18] now i get the list filled [16:18] same here [16:18] but it wont load [16:18] it loads but i fear it will kill my chromebook ram [16:19] jfunk, can you make sure someone looks at this? https://bugs.launchpad.net/autopilot/+bug/1229034 [16:19] Ubuntu bug 1229034 in Autopilot "Failing tests with the 1.3 branch (Sep 23)" [Critical,New] [16:20] sigh [16:20] why are all times in PT [16:20] as if california was the navel of the world or something [16:20] so i can browse revisions but it takes about 10min to show them in the sheet [16:20] one revision loaded! [16:21] haha [16:21] my 8:48am change wsn't it! [16:21] yeah [16:21] mine is still loading for that one [16:22] I've switched to detailed [16:23] asac, lool: ask in row #58 has now code in trunk, it could use a slot to land tomorrow. That unblocks barry's image-update for using the download service [16:24] great news, it's either asac or bfiller who broke it! ;-) [16:24] phew [16:24] or so does google docs tell me [16:25] then it was me :) [16:25] * ogra_ goes for a smoke ... all that excitement [16:25] did we move rows around or can we copy stuff fromt he revision? [16:25] it was the last revision apparently [16:25] just revert it [16:25] detailed revision? [16:25] asac: it's near the top, we should revert to it [16:25] but I can't load [16:25] what changes were done in that revision? do you see that? [16:25] it takes ages [16:25] yeah i cant do anything :) [16:25] dunnno, still loading for me [16:26] but i see that the one lool referred to is the last one [16:28] so I think I'm going to revert to a recent revision [16:28] but that too is churning [16:29] wait [16:29] might take a week to do that :) [16:29] which revisionm is it? [16:29] if its just ralsina after me [16:29] with all the loadign times [16:29] just have him copy his styuff first and readd :) [16:29] i still see you and bfiller as last editors [16:29] ralsina edited since [16:29] if you look at detailed revisions [16:29] asac: I just added a few bugs in row #58 [16:30] we should have locked the spreadsheet first thing [16:30] asac, i do ... but i have a white screen and an idle cursor since 10min [16:30] ogra_: what's the problem? maybe I messed something up inadvertantly [16:30] balloons: ping [16:30] bfiller, either you or asac accidentially deleted a column [16:30] ignore [16:30] ogra_: don't think I did that [16:30] Nous sommes désolés, mais vous avez dépassé le nombre de demandes qu'il est possible d'envoyer. Veuillez réessayer ultérieurement. [16:31] bfiller, its not an issue except that the rollback function of gdocs acts up [16:31] google docs just kicked me out of thi sdoc [16:31] i am sure something happened due to the slowness here [16:31] lool: I got a brief mention that you reverted something [16:31] "Sie haben in letzter Zeit zu viele Anfragen gesendet. Bitte versuchen Sie es später erneut." [16:31] yeah see above [16:31] BAH ! [16:31] ogra_: dont be soo greedy :) [16:31] seems you are impatient [16:31] lol [16:31] asac: still fighting on the xorg-server FYI [16:31] asac, i just sat and watches the idle cursor ! [16:31] *watched [16:32] didrocks: right. we do that in the ppa as well? [16:32] vila: correct :-) [16:32] or where do we do that stuff? [16:32] now the asks aren't loading [16:32] * lool whistles [16:32] heh [16:32] didrocks: did we ever hire a maintainer for X? [16:32] lovely [16:32] lets move to a wiki [16:32] didrocks: i feel that one could maybe help with such transitions.? [16:32] itss also so much more fun to edit [16:32] asac: yeah, but he's not around [16:32] well the revert didn't work [16:32] didrocks: whats his name? [16:32] lool, fine for me again [16:32] mlankhorst [16:33] ic [16:33] ogra_: oh is it? [16:33] vacation>? [16:33] oh no it's fixed [16:33] lool, well, loading i mean [16:33] doanac, pong [16:33] lool, and the asks page is there ... not the missing column [16:33] cool [16:33] balloons: did you get a chance to look at those patches I sent you? I was wondering if you thought we could try and get them upstreamed? [16:33] doanac: https://code.launchpad.net/~pwlars/ubuntu-test-cases/devel-proposed/+merge/187279 is the only change that's needed still [16:33] * asac closed the spreadsheet to reduce the amount of viewers (which i suspect slows good down) [16:34] so we're missing changes from ralsina, bfiller, rsalveti and asac [16:34] lool, and the column [16:34] ralsina: sorry, but we had an incident with the spreadsheet... we reverted your changs done in last 2hours :/ [16:34] we still need to restore it [16:34] plars: approved [16:34] asac: np, I can redo :-) [16:34] ralsina: bfiller: they should still be in the detailed revision history if you dont know exactly anymore [16:34] why reverted? [16:34] *sigh* [16:34] doanac, yes I've looked at them, they are simple enough. My question is what's the status of migrating the core apps to click? [16:35] ralsina: because we had a data loss incident [16:35] err [16:35] rsalveti: ^^ [16:35] asac: there, readded :-) [16:35] thanks [16:35] balloons: sergiusens is looking into that [16:35] we wanted to convert these 3 community first and get them in our automation as a first phase [16:36] a kingdom for a browser that works with google spreadsheet :/ [16:36] balloons, the core apps are all already click [16:36] balloons, http://pad.ubuntu.com/click-move [16:37] balloons, only one that fails is music app [16:37] asac: gut feeling is that you're pushing google spreadsheet to its limits... (which would make sense given that value of the data currently captures there), remember didrocks birthday ? Same ;) [16:37] ogra_: oh it's still missing actually [16:37] balloons, so, the only thing I can't do, is get rid of debian in your ci pipeline [16:37] asac: do a backup :-D [16:37] it's weird, if I look at the revision history I see the requestors [16:37] so the ppa stays [16:38] lool, thats what i said (twice) [16:38] lool, could it be that it is just hidden ? [16:38] balloons, PPA stays, but the apps will be unseeded and ubuntu-touch won't add it in it's apt sources [16:38] vila: we had backups... we just were not able to extract the diff :) [16:39] ok, that was what lool asac and myself were discussing, but I never got heard a final word on what was happening [16:39] i dont think that manual backups would have helped :/ ... well it a bit because looading woudl be better [16:39] balloons: sergiusens: the fact is that we are doing a pilot with notes-app [16:39] I restored requestors! [16:39] well, some [16:39] actually I didn't restore anything [16:39] and then based on what we find (in particular on the infrastructure/process side), we decide if roll out to the rest [16:39] asac, it would be done if the autopilot tests weren't so flaky for notes [16:39] and I know now why we saw them in the revision history [16:39] asac: just kidding to appease the gremlins (they hate having their nasty jokes spoiled ;) [16:39] asac, https://code.launchpad.net/~sergiusens/notes-app/click/+merge/187036 [16:39] it's because the filtering was disabled in revision history [16:40] sergiusens: did you ever get a success ot of that? [16:40] vila: hehe. sure. [16:40] asac, yes [16:40] sergiusens: so its just flaki and annoying? [16:40] asac, https://code.launchpad.net/~sergiusens/notes-app/click/+merge/187036/comments/426762 [16:41] asac, yes, mako is flaky... devs have maguro's [16:41] is that a core app? [16:41] asac, yes [16:41] asac, it's the notes-app [16:41] asac, core canonical app [16:41] sergiusens: maybe try showing the test to someone like omer or thomi [16:41] they might tell us we are completely on crack and rather should do a,b,c [16:42] asac, I've been told omer has that task [16:42] bfiller: anything you can do about the test flakiness of notes? [16:42] i think we made good progress on two other apps that were pretty flaki [16:42] notes surely is one of the next candidates according to the level of annoyance :) (even on the image dashboard) [16:43] lets just drop it ... we have a terminal and vi preinstalled ... [16:43] sergiusens: anyway. nothing changes. lets get notes-app done, get the infrastructure proven and baked [16:43] all that duplication [16:43] asac: we need to look at it more to figure out what the races are, could use omer's help with that. we have looked at some and haven't made much progress [16:43] and then make a call about what else to do for this cycle [16:44] asac, I prefer to disable flaky tests, they prove nothing when they pass or don't pass [16:44] doanac, we can't merge those patches upstream as it would break the CI used by core apps [16:44] balloons, do it like I did [16:44] didrocks: so IIUC uploading a Mir workaround now to disable libunwind [16:44] sergiusens, that's what I'm looking at [16:44] sergiusens: the prove that the feature sometimes works in the way the test writer probably intended them to wrok - thats more than nothing. i want a test trade (good for bad one) or a real story why we believe we should reduce test coverage [16:44] balloons, line 156 here https://code.launchpad.net/~sergiusens/notes-app/click/+merge/187036 [16:45] lool: yeah, removing an upstream patch [16:45] ultimately you can just argue with the app owner... CI doesnt care so much about what tests. we just ensure that tests dont break [16:45] QA might come back complainig when they see drop of test coverage [16:45] so... :) [16:45] sergiusens, you basically add a third option to launch.. so that was the first idea [16:45] if that works, then we can certainly do it [16:45] balloons: sorry. so i guess if you add sergiusens snippet to my snippet you'd have a working patch? [16:46] balloons, it doesn't break autopilot with debs [16:46] and in an image where only the click package is installed, it would be used [16:46] best compromise [16:46] doanac, basically the patches replace the launch_test_installed, and sergiusens simply adds a launch_test_click alongside it [16:46] so you have 3 ways to launch, installed, click or local [16:46] yes [16:46] btw, this really needs to get into the base emulator [16:47] balloons, as part of AutopilotTest or whatever it's called these days? [16:48] UbuntuUIToolkitEmulator [16:48] we had plans to fix up the __init__.py messiness.. this adds onto it :-) [16:54] ogra_: lool: so you folks said we landed too many things after the image? [16:54] asac, no [16:54] no? [16:54] jdstrand: you need a FFE for telepathy-m-c-5; also you'll need a hint, can do the later once you have a FFE [16:54] asac, i said we buiuld to less images to keep a proper overview [16:54] jdstrand: currently in proposed [16:54] ogra_: you mean higher frequency of images, with less changes each? [16:54] asac, having more builds means we have smaller chunks [16:55] right [16:55] that makes identifying issues easier [16:55] lool: why do I need a FFe? it is a bug fix [16:55] hence, why dont we see if there are low hanging leave apps or something to put in as well [16:55] people are seeing denials where they shouldn't [16:55] so tomorrow morning image can be kicked at 9am [16:55] jdstrand: ok [16:55] asac, setting up cron for that then [16:55] wait :) [16:55] we dont even know [16:56] lool: these types of profile changes are typical in the dev cycle with the churn we get in the archive [16:56] let me look at what landed [16:56] i think it was only unity8 now [16:56] so lets update the spread to be INIMAGE etc. [16:56] lool: I don't know what you are referring to about the hint [16:56] jdstrand: ok; I thought it was an addition actually [16:56] doanac, so I guess I'll undertake patches to all the core apps in line with adding the third option for click [16:56] asac, as for Mir and MM ... i would say hold everything else land the stuff, have one image with the changes to test and then open the gates again [16:56] jdstrand: it's blocked from proposed to saucy migration [16:56] due to beta freeze [16:57] asac, meaning for each of MM, Mir and lightdm [16:57] they are big enough to justify their own image build imho [16:57] (and even if we have to roll back the teams have somethign they can work with) [16:57] we need to piggy back some apps or something on each of them i think [16:58] MIR i would put last... we need MM and lightdm first [16:58] but both have no final code :) [16:58] lool: well, any policy addition could be considered an addition, but I think that is a bit extreme. as for beta-- I don't particularly care if it is in beta, but I can request someone to let it through if you think that is best [16:58] MM should be ready tomorrow [16:58] its all hot air still :-P ... getting pretty hot though, yes [16:58] not sure about lightdm [16:58] seems mterty found an issue with the maguro kernel [16:58] jdstrand: that's ok, sorry, I said "ok" :-) [16:58] asac: ok, we do have Mir ready now. Anyway, it will be blocked in proposed due to beta freeze and new xserver, so I guess we can push to proposed [16:58] jdstrand: I did add a hint now [16:58] ogra_: the image is 61 [16:59] and call that done [16:59] jdstrand: it will transition from proposed soon [16:59] didrocks: when is xserver coming? [16:59] I can add an additional hint if needed [16:59] asac, so it is :) [16:59] asac: all is fixed [16:59] just what you need to know :p [16:59] didrocks: will we wake up and cant publish anything else tomorrow if there is an issue? otherwise, i would say go ahead [16:59] jdstrand: for non-touch specific packages, beta freeze applies, and I misrememberd your changes as being a new feature [16:59] didrocks: will this prevent us from publishing a new phone/app stack in case we want today? [16:59] asac: if we don't publish, it can, yeah === bfiller is now known as bfiller_food [17:00] if we publish, we are then free [17:00] look, and maguro is already at 100% ! [17:00] :P [17:00] didrocks: i mean... if we put the mir stuff into proposed until tomorrow, can i still shoot out a fresh app? [17:00] the only thing is that platform-api can't be in the image [17:00] or will that have to wait in proposed as well? [17:00] didrocks: right. platform-api is understood... so seems the rest can still go in [17:00] right [17:00] the rest == everything - platform, unity8 and mir [17:00] of course, if platform-api add a new feature [17:00] uhm [17:00] and apps dep on that new platform-api [17:01] it will be stuck in proposed [17:01] otherwise, we are fine ;) [17:01] we have another platform-api change that needs to land [17:01] didrocks: right. but you dont know about such a new feature? or did you see that? :) [17:01] together with an android upload [17:01] asac: no, just speculation ;) [17:01] ogra_: yeah. that thing surealy has to wait given the discusionm above :) [17:01] so that everyone is aware of what can happens [17:01] in practice, I didn't see this coming [17:01] didrocks: ok... so we push your stuff to proposed and all the easy stacks we can still process until tomorrow morning [17:01] asac, hmm, then MM takes a day longer [17:01] didrocks: sounds good [17:01] awesome work [17:01] ok, pushing [17:02] didrocks: lets see how we can now keep mir in a maintainable state [17:02] lets discuss tomorrow [17:02] kgunn_: pushing Mir as per ^ [17:02] yeah [17:02] rsalveti, ^^^ seems we cant upload android and platform-api today [17:02] ogra_: we can do both in one shot... just stage them together, test them together [17:02] i dont see why we need to do it step by step [17:02] because you want to be able to roll back step by step [17:02] well, we can roll back the whole thing then. its even better :) [17:03] and harm other people that didnt have anything to do with the breakage ? [17:03] no... roll back the combination you propose above [17:03] and just had their stuff land together with the breakage [17:03] MM + android + platform-api + a new MIR stack build on that [17:03] that can get its own, isolated slot [17:03] oh, thats not what i proposed [17:03] with nothing else ... except maybe one or two apps [17:04] i proposed one image for each big change [17:04] well, you say those components need to be changed [17:04] not one for all of them [17:04] for me its one shot and we have all the bits so close nearby that we can just do them together [17:04] adding the dee safe change as a bonus [17:04] in that way we avoid problems, know that everything works etc. [17:04] MM+Mir sounds like a massive landing [17:04] you will never be able to identify the breakage in there [17:05] mir goes in now [17:05] good [17:05] so next time it has zero changes ... just the transition [17:05] when we update platform-api and MM [17:05] anyway. mir is now in proposed... tomorrow we clear that [17:05] right, but we wont have an image to test Mir alone [17:05] and then things can move normal [17:06] right. we have to make compromises on what we risk and what not due to our inability to produce images en mass :) [17:06] lets see tomorrow [17:06] i am sure this is a non-argument [17:06] we'll see ... once we have to untangle :) [17:06] we dont have platform-api, nor android changes ready and tested from the look [17:06] so they are not really candidates for tomorrow morning imgae [17:06] balloons: thanks! [17:06] that has new unity8 and mir [17:07] asac, no, rsalveti wanted to upload tonight so i can pull it into the next image [17:07] i think we should leave it with that [17:07] it will not go in [17:07] due to proposed blockage [17:07] anyway [17:07] asac, we try to schedule our workjtime effectively [17:07] that just wastes a day of someone [17:07] rsalveti: cant we do android and platform-api together? imo its a nice immutable entity that you can test and when ready just upload [17:08] asac, we have to do platform-api and android together [17:08] andropid, platform-api and MM ... just prep all together if its just 1 day aehda [17:08] the change requires both [17:08] what proposed blockage? neither unity8 nor mir should be blocked [17:08] and android+platform-api is a prerequisite to MM [17:09] cjwatson: how I understood didrocks we expect mir to be blocked in proposed until tomorrow [17:09] if not we probably want to make it so [17:09] it will be blocked [17:09] but I added a hint for security [17:09] nice [17:09] cjwatson: mir needs new xserver [17:09] right [17:09] :) [17:09] and old libmirclient2 isn't coinstallable with libmirclient3 [17:09] and I think xserver-xorg is blocked by beta freeze [17:09] didrocks: oh right, that'll need to be post-beta then surely? [17:09] right? [17:10] yeah, post-beta I guess [17:10] friday then [17:10] :( [17:10] maybe mid-Thu [17:10] didrocks: hmm. [17:10] awkward day to land such a big thing [17:10] there'll be a point when we know we aren't respinning any more [17:10] cjwatson: the xserver-xorg change doesn't impact desktop [17:10] didrocks: we somehow need to be able to get platform-api in before... :/ [17:10] so we can maybe see to sneak it in if a respin is in order [17:10] that would be cooler :) [17:11] didrocks: well [17:11] jdstrand: so retrospectively I should NOT have seeded it [17:11] didrocks: you know what "doesn't affect " changes are like [17:11] two errors in a row [17:11] asac: well, this is way out of my hand if you didn't notice ;) [17:11] I think I'm done for today [17:11] asac: we can do both in one shot, yes [17:11] didrocks: I think you'd be wary if you had a major release in two days [17:11] cjwatson: yeah, I know about even a one character change ;) [17:11] lool: in a meeting, will be back in a minute [17:11] just trying to accomodate all requests incoming [17:11] people want to do foo with bar [17:11] asac, so, I need another settings landing, how do I queue for that? [17:11] when they are incompatible [17:12] anyway way [17:12] asac, we have some fixes and bluetooth settings that landed today [17:12] seb128: people.canonical.com/~platform/cu2d/results [17:12] seb128: if you see it there or expect it to show up soon there, just add a landing ask. [17:12] asac, that's in some google doc right? (I think I read about that in my thousand emails read post holidays today) [17:13] https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0Au6idq7TkpUUdGNWb0tTVmJLVzFZd0doV3dVOGpWemc#gid=1 [17:13] this one [17:13] seb128: if you want to accellerate and since you are a core-dev and we allow core-devs to do their own testing as we trust them, you can also help by running all autopilot tests that we identify before requesting and then we can just land it together with whatever the next image is [17:13] seb128: but its important that we coordinate the timing anyway - but in this case it will just help us to not test :) [17:13] so its faster [17:13] asac, how do I know what autopilot tests have been identified? [17:14] or to run [17:14] asac: we can't freeze some part of the distro and not the other thinking that things will still fly [17:14] and adding transitions on top of that ;) [17:14] didrocks: well, in this case we could continue working if we delist the mir transition again [17:14] asac: delisting it would mean 5 hours of work lost [17:14] thanks but no thanks [17:14] didrocks: lost? [17:15] yeah, then Mir continues [17:15] or the platform change [17:15] and again, you get FTBFS and other issues [17:16] cjwatson: so any final call on wehther we can let it in or not from release team perspective? i guess if we let it in, we should do that sooner rather than later [17:16] cjwatson: happy to wait for you guys to investigate etc. [17:16] didrocks: where is the debdiff in case? [17:17] http://paste.ubuntu.com/6150992/ [17:18] asac: best ask infinity, he's coordinating the beta and independent of what I think of the change it would need to be run past him to make sure it doesn't disrupt respins [17:18] infinity: ^^ [17:19] infinity: so we have an xserver-xorg update in the proposed net that touches exclusively mir stuff [17:19] infinity: http://paste.ubuntu.com/6150992/ [17:20] infinity: it would help unblock our multimedia work etc. to propagate into our images and archive etc. [17:20] (we will have, I have to push it once Mir is published in proposed) [17:21] asac: however, we want to unblock it to transition to the release pocket once we move Mir there as well [17:21] (tomorrow morning, right?) [17:21] didrocks: we want to unblock it [17:21] (I added a hint just in case to block Mir) [17:21] so we can continue to land our touch image stuff [17:21] ok, so Mir in the release pocket now? [17:21] * didrocks removes his hint then [17:21] didrocks: you say that you tested it? [17:21] if you feel its not well enough tested, then lets not unhint it [17:21] we do a run tomorrow [17:22] asac: I would prefer someone confirming tomorrow [17:22] didrocks: i didnt get that you switched topics. sorry [17:22] didrocks: right. then leave the safety belt in [17:22] asac: I didn't test it, we are using surfaceflingers [17:22] however, we need to unblock this xserver thing i guess [17:22] ok, I'm going off, see you guys tomorrow [17:22] lool: bye! [17:22] see you lool [17:22] didrocks: right. so the mir upload... could it be done in a manner that it doesnt depend on the latest xserver? [17:22] asac: Is it in -proposed yet? [17:22] didrocks: guess not [17:23] infinity: in a few minutes [17:23] asac: Once it's uploaded and built, we can talk about it. :P [17:23] infinity: if you say you are willing to consider it? [17:23] infinity: its built afaik... just binary copy [17:23] infinity, it comes from a CI PPA [17:23] asac: (I'm likely to let it slide in if we have Other Reasons for respins, which we likely will) [17:23] mir might be, I doubt xorg-server does? [17:23] asac: well, they broke the libmirclient ABI [17:23] and libmirclient2 isn't coinstallable with libmirclient3 [17:23] so no [17:23] infinity: can we land it in the archive and dont respin? e.g. we dont care if this is on the image [17:23] so only if you respin you pick it up [17:24] didrocks: is xserver built? [17:24] or does it need building? [17:24] desktop will see a bunch of respins soon i would guess [17:24] asac: xorg-server isn't daily releasing, it will rebuilt in the proposed pocket once I'll upload it [17:24] right [17:24] but RAOF didn't bump the build-dep, so I need to wait for Mir to be published in proposed [17:24] didrocks: so sounds infinity is willing to slip it in if its build [17:24] i believe he might slip it in the archvie and just pick it up in case a rebuild happens [17:24] so I should remove the Mir hint [17:25] (to block it) [17:25] didrocks: you can bump the build dep manually? [17:25] or are you using a tool for that? [17:25] asac: I can bump the build-dep manually, but not sure the xorg guys will like that [17:25] didrocks: proposed-migration almost certainly won't migrate mir to release until xorg-server is also ready [17:25] didrocks: so I doubt your hint makes any difference [17:26] right [17:26] cjwatson: yeah, as mentionned, it was just a second safety belt in case I missed anything [17:26] xserver-xorg-xmir is from xorg-server source and Depends: libmirclient2; as long as mir has stopped building libmirclient2, that'll be sufficient to block it [17:27] cjwatson: right, it's just as I'm not an expert on the britney side, I prefered to ensure another way. Let me remove the hint then [17:27] (done) [17:28] didrocks: can you check with ricmm on this platform-api changes? [17:28] maybe they are just adding a new symbol [17:28] cjwatson: it does block it because libmirclient3 and libmirclient2 are not coinstallable? [17:28] so they wouldnt even be blocked [17:28] asac: platform-api depends on latest Mir [17:28] didrocks: the new platform-api chagne coming for MM? [17:28] asac: we need Mir to be in to get any version of platform-api passing britney [17:29] didrocks: no, because Ubuntu's proposed-migration configuration requires all NBS to be removable before promoting something [17:29] cjwatson: ah, so all transitions need to be done? [17:29] didrocks: Yes [17:29] so that's what I was telling during the Boston sprint [17:29] and infinity yelled at me telling it wasn't the case :) [17:29] * didrocks not so crazy then [17:29] It's almost true. Build-Depends aren't considered for this purpose (though usually don't matter) [17:29] rsalveti: when is your platformn-api, android and MM pack ready? [17:29] And it's also possible to force things in cases where we disagree with the default rule [17:29] you think earliest tomorrow? [17:30] So infinity isn't entirely wrong - but the default is as I describe [17:30] cjwatson: ok, makes sense. So we do have to transition everything in proposed anyway in most of the case [17:30] (having the libs coinstallable or not don't change a thing) [17:30] If what you were saying is that proposed-migration is getting in your way because you have to resolve all transitions (a viewpoint which I've heard from desktop people before now), then infinity was right to call you out on it as an overstatement :) [17:30] didrocks: Having the libraries coinstallable is still very strongly recommended, because it makes upgrades saner [17:31] infinity: ok i take that as a "yes, we most likely slip this in at the first possible moment (either for a respin or for a landing without respin) once the binaries are there etc.... blah blah blah"... [17:31] :) [17:31] cjwatson: I question your view of reality. No one forced in corosync (for instance) did they, but it has NBS on the NBS report. [17:31] asac: in 2~3 hours [17:31] cjwatson: I was just mentionning that the transition needs to happen before migration, what infinity told me I was wrong on ;) [17:31] rsalveti: can you check with didrocks about your platform-api changes [17:31] rsalveti: he worried that this will reset his mir work done [17:31] he is [17:31] asac: it won't reset, it's in proposed already :p [17:31] infinity: I think that generally happens in cases of alternatives and recommendations and such, but there does seem to be the odd bug [17:32] didrocks: ah ok. then ok [17:32] infinity: But I've also definitely seen the code working as I intended when I wrote it :) [17:32] I'll do a heads up here once we're good to land them [17:32] rsalveti: right. might be that you guys are stuck until friday :) [17:32] in proposed [17:32] infinity: I should probably debug corosync et al [17:32] we try to sneak it in though [17:32] right [17:32] cjwatson: Sometimes it's alternatives but, yeah, that specific case doesn't look to be. [17:32] infinity: One thing that can sometimes happen is that proposed-migration decides that it can trade one uninstallable for another [17:32] at least, the rule is simple and understandable, finishing any transition first [17:33] cjwatson: Ahh, that could be. [17:33] infinity: Or, if a package is already uninstallable, swapping out an NBS binary from under it makes no odds [17:33] didrocks: Sure, regardless of the mechanics, doing transitions in proposed is the right thing to do. [17:33] This is why I tend to look very dimly upon suggestions that it's clever to force proposed-migration to have temporary uninstallables [17:33] Because it can make it take worse decisions elsewhere [17:34] And why we ought to get britney's view of uninstallables to zero :) [17:34] cjwatson: what page has those uninstallables? [17:35] http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt lists the count in a rather telegraphic form. I'm not actually sure we have a proper report of all of them, unfortunately. http://qa.ubuntuwire.com/debcheck/ used to work ... [17:35] I should sort that out and report it somewhere [17:36] Maybe snakefruit can manage a full britney report-only run on universe [17:36] Will try tomorrow [17:36] probably scary to see :) [17:36] hehe [17:36] That would be lovely. [17:36] or maybe not [17:36] It shouldn't be terrible. 82 on i386 [17:36] No, you're right, it'll be scary, but the more of those we fix, the better off we are going forward. [17:37] We still need the separate main/restricted-only run to ensure closure [17:37] When we first did this a couple of cycles ago, one goal was to make the release pocket entirely consistent, so britney could actually do its job correctly. [17:37] obviously useful, yes. [17:37] asac: ok, bumped the build-dep and pushed xorg-server [17:37] nice [17:37] (even if the xorg guys are not happy, anyway ;)) [17:37] so everything that needed to be in proposed is in proposed [17:37] didrocks: what is the ETA for build time you think? [17:37] in publication or building [17:38] asac: I would say once Mir is published in proposed, it's ~30 minutes [17:38] from what I saw on the actual build time on all archs [17:38] didrocks: for building? how about xorg? how long does that take on armhf? [17:38] cjwatson: Did we still want to try to teach britney about components and the ogre model, or just handwave until archive reorg solves all the world's problems? [17:38] asac: I'm talking about xorg [17:38] 30 minutes? nice [17:38] xorg build time [17:38] infinity: handwave. I looked at it and it was a right pain to implement. [17:39] ok, time to really EOD now [17:39] ogra_: dashboard sneak looks pretty good. well known unity8 crash (that is now fixed in archive) [17:39] see you guys [17:39] didrocks: mir is published [17:39] asac, i'm missing mako [17:39] cjwatson: great, nice timing! [17:39] didrocks: (bonus of switching to snakefruit today: rmadison is not intolerably slow) [17:40] cjwatson: yeah, I made the same remark on my side ;) [17:40] There should be many bonuses. [17:40] ogra_: well, thats a timing thing. who knows what mako was doing :) [17:40] probably drinking a beer or two :) [17:40] cjwatson: Say, now that we have snakefruit, should we switch britney to being a push trigger from the publisher instead of the bizarre polling of rsync? [17:40] plars: ^^ can you check if 61 image is going nicely? [17:41] cjwatson: Close that loop as tight as we can? [17:41] i see the known unity8 crash on maguro so far... just checking on mako and how its going [17:41] infinity: Yeah, we should do that [17:41] * asac likes the marketing sound of "make it push trigger" :) [17:42] cjwatson: If it's pushed literally right after the dists.new->dists copy, there's a fair chance it'll always finish-and-promote before the next publisher. [17:42] infinity: That'd require a bit of work [17:42] asac: odd, I didn't see the notification pop up on it [17:42] I think the triggers we have at the moment are after germinate [17:42] plars: notification? [17:42] asac: it's running on maguro, mako needed to be restarted [17:42] plars: you have that? [17:42] plars: ok thanks [17:42] cjwatson: The mirror triggers are, yeah. [17:42] plars: where do we expect notifications to go out about mako problems? [17:42] infinity: Well [17:43] infinity: There's finalize.d - we can put something before germinate though it'd still be after ls-lR [17:43] (yes yes I know you desperately want to kill that) [17:43] asac: I got a new traceback from phablet-network on mako, not clear why though [17:43] asac: it's retrying now though [17:43] that'd be about 2.5 minutes slower than necessary [17:43] with no loss of functionality we could move ls-lR into finalize.d and put a snakefruit trigger before it [17:44] cjwatson: Right before germinate would work for now. [17:44] asac: cjohnston has a script that looks for new images and sends out an email to a few of us that watch the jobs... nothing official. It's just something he has running at home, but it could be down since he's not at home right now. [17:44] 2013-09-24 17:38:06 DEBUG Moving the new dists into place... [17:44] 2013-09-24 17:38:06 DEBUG Creating ls-lR.gz... [17:44] cjwatson: And moving ls-LR too, sure. [17:44] so that would do the job [17:44] asac: I've always said it would be nice if we had real notifications when builds are triggered, but I've been told that's not easily done [17:45] huh, why is xorg-server/armhf failing [17:45] hmmmmm [17:45] ubuntu-archive@snakefruit:~$ chdist apt-get saucy-proposed-armhf build-dep xorg-server [17:45] is happy [17:45] cjwatson: Just arch skew? [17:45] plars, its not really hard either ... but it requires someone to have the time for it [17:45] plars: you ask for notifications from our image production server when we finished producing an image, correct? [17:45] * infinity checks on real hardware. [17:46] it's build-dep analysis, it shouldn't make a difference ... [17:46] asac, i read "triggered" as in started [17:46] infinity: I have to go for dinner, so I'll leave it with you [17:46] probably the omap4 hackery ? [17:46] ogra_: might be more interesting to know when it finished or failed imo :) [17:47] The omap4 hackery is about to die. [17:47] asac, we ahve mails for failures [17:47] infinity, ?? [17:47] But that shouldn't make a difference here, I'd think. [17:47] ogra_: and on successes? [17:47] infinity, panda desktop going away ? [17:47] i think we want mails going somewhere for those too :) [17:47] basically: we always get a mail at the end :) [17:47] asac, silence ... as every good unix program :) [17:47] ogra_: https://lists.ubuntu.com/archives/ubuntu-release/2013-September/002598.html [17:47] ogra_: chdist apt-get saucy-proposed-armhf build-dep should usually always match what the LP builders see ... [17:47] (as ubuntu-archive@snakefruit, because it has up-to-date dists) [17:48] anyway, food [17:48] Hrm. Works here too. [17:49] Cute, fails on all arches. [17:49] * infinity tries a cleaner chroot. :P [17:51] infinity, ah, sad ... [17:51] infinity, i wish we haad decided that earlier ... there were manweeks spent on making the setup work [17:51] Oh, derp. [17:52] cjwatson: Someone newed libmirclient3 to universe, that's all. [17:52] * infinity fixes. [17:52] asac: things are actually looking pretty great on maguro, only one failure so far (unity - systemsettle-after) http://reports.qa.ubuntu.com/smokeng/saucy/touch_ro/4425/ [17:52] asac: we still have a crash file there though [17:52] right. the fix landed after the image [17:52] so should be gone next time [17:53] cjwatson: "someone" being the autolander combined with copy bugs/misfeatures. [17:53] Anyhow, fixed now. [17:53] asac: so, unsurprisingly, apport was the cpu-eater :) [17:54] lool: ok, I'm back. what is the issue? [17:54] plars: i got an email about an hour ago [17:54] ogra_: I tried to push the decision before people spent time on it, and there was much handwaving and waffling. :/ [17:54] yeah [17:54] ogra_: This time around, I got my point across. Such is the life of software development, I suppose. If it wasn't for wasted time, half of us would be unemployed. [17:55] well, i saw how hard it was for mlankhorst to get it working [17:55] haha [17:55] yeah [18:02] sergiusens, I've got 2 of my team looking into it, if you want to join #ubuntu-quality they can keep you posted on updates [18:03] or they can post their results to the defect itself [18:07] asac: music-app and calendar still fail the same number of tests as before [18:08] plars: i think music-app regressed in two ways: a) tests and b) complete bustage [18:08] i think b) was fixed [18:09] at least we got an update [18:09] http://people.canonical.com/~ogra/touch-image-stats/20130924.changes [18:09] asac: yeah, it's the same failures on both [18:09] balloons: ^^ music-app tests seem to be still similarly unhappy [18:09] thanks [18:12] asac, ty. music app is a known breakage caused by app changes and is being worked on. calendar though makes me sad to see failing, but has had no changes [18:13] balloons: calendar app was broken since friday or thu [18:13] i think [18:13] afaik [18:13] plars knows for sure [18:14] yes, afaik it did go green for one run after being fixed, but maybe I'm dreaming === bfiller_food is now known as bfiller [18:17] balloons: yeah, we do occasionally see calendar go green, I think we decided they were just flaky or timing sensitive or something: http://jenkins.qa.ubuntu.com/job/saucy-touch_ro-mako-smoke-calendar-app-autopilot/99/console [18:18] plars, yes, but the 2 tests that are failing are different than before it went green.. anyway, it's running the same code.. swipe forward or backward.. so wild [18:31] cyphermox, the wallpapers mp has merged [18:35] balloons: so what does calendar app use? is there anything underneath that could hav chnaged and caused damage to it? [18:35] jfunk, thanks [18:36] asac, yea, that's kind of the question. I have to go find the old logs real quick, but it appears the initial timeout issue isn't the case any longer. 2 of the 4 tests pass, and they are identical code with only the parameter changing [18:37] balloons: when was last change of that package? [18:37] can we rule out that there was a landing after thu? [18:37] or on thu [18:38] balloons: http://people.canonical.com/~ogra/touch-image-stats/20130917.1.changes [18:38] there was an update [18:38] calendar-app from 0.4bzr114saucy0 to 0.4bzr117saucy0 [18:38] that was on thu ... so would fit in what i said above [18:39] fginther: ack [18:39] we can start thinking about landing it now [18:39] balloons: rss reader changd here: http://people.canonical.com/~ogra/touch-image-stats/20130919.changes [18:39] asac, the update on thursday was intended to fix things. Olivier figured out there was a long running query causing the screen to lock and the tests to fail :) That w as fixed in the thursday commit [18:40] my expectation was everything should work, but only having 2 fail is baffling [18:40] I've been looking at the music app though, not calendar [18:40] so since it's failing today too, I guess it must be something that will continue to happen [18:49] asac, manual test of 61 on maguro seems good ... the messaging indicator icon doesnt change color ... apart from that i has no issues [18:49] *had [18:58] ogra_: messaging indicator? [18:58] yeah, see -touch [18:59] popey verifies on mako [18:59] ogra_: let jfunk know... he has a better overview to make a relative prioritization [18:59] ogra_: guess he would liek a bug or sonmething with a screenshot :) [18:59] plars: a question about our setup_jenkins.py script. [18:59] well, a screenshot will be pointless :) [18:59] it simply doesnt change the icon if there is an SMS [19:00] or a missed call or whatever [19:00] alex-abreu: you are doing webapps right? [19:00] alex-abreu: the ones that we see staged here: http://people.canonical.com/~platform/cu2d/results [19:01] alex-abreu: 1. are they a) for desktop or b) touch or c) both ... and 2. are they good for landing? [19:01] (on image) [19:01] asac, yes [19:02] asac, desktop / yes [19:02] * jfunk waits to be asked [19:03] asac, unity-webapps-qml is for touch also though [19:03] alex-abreu: the desktop ones ... are they on the desktop image? or just in the archive? [19:04] asac, archive [19:05] ogra_: so we still dont have the requestors back :) [19:05] how bad [19:05] * asac wonders if his ffox deletes those automatically [19:06] jfunk, this one seems to be for you ... according to asac :) https://bugs.launchpad.net/ubuntu/+source/indicator-messages/+bug/1229898 [19:06] Ubuntu bug 1229898 in indicator-messages (Ubuntu) "does not update icon for missed calls or messages on image #61" [Undecided,New] [19:06] asac, yeah, thats really bad ... it must be possible to fish that out of the history somehoe [19:07] ogra_: if noone deleted or moved rows [19:07] we could probably copy the column [19:07] and just paste it :) [19:07] ogra_, asac - what does it mean - for me? If it's triage related perhaps not a good idea, if you need to confirm it then let's talk [19:07] and of course only if the revision thing works [19:07] jfunk, popey can confirm it, he is testing on mako ... [19:07] jfunk: not sure, thought you would be the one having the best overview of bugs found during testing and hence could take this into your list for relative prioritization :) [19:08] jfunk, i'm not sure why i was supposed to point you to it ... ask asac :) [19:08] not sure how to get a prioritization on this right now :) [19:08] confirmed [19:08] * asac tries to be the revision king [19:08] well, its not an awful bug per-se ... everything still works ... but its an awful bug for an enduser for sure [19:08] you'll get jono moaning he wont see texts from his wife ☻ [19:09] yeah [19:09] popey, https://bugs.launchpad.net/ubuntu/+source/indicator-messages/+bug/1229898 [19:09] Ubuntu bug 1229898 in indicator-messages (Ubuntu) "does not update icon for missed calls or messages on image #61" [Undecided,Confirmed] [19:09] didnt he complain on last build? [19:09] in case you missed it above [19:09] asac, dont you managers always complain ? [19:09] ogra_: i dont understan... even the very latest revision [19:09] still has the requestors [19:09] wow [19:09] maybe its my browser after all... :) [19:10] no [19:10] its gone here too [19:10] thats impossible :) [19:10] i see an empty column C [19:10] look at the revision history... there is NO change after the lats one... and that has all names :) [19:10] * asac senses a forever removed on top bug [19:10] asac, sure - I think we bit off more than anticipated when trying to create a list of defects for prioritization, I spent a day picking the ones that appeared important from avengers/qateam etc and reaslized it wasn't a scalable approach - so now I am encouraging defect discovered to get triaged immediately by the discoverers - perhaps this will not work either, but we need to do find a scalable approach, ideas? [19:11] ogra_: already done [19:11] * ogra_ hugs popey [19:12] launching music from the dash doesn't play it [19:12] it launches the music app, just doesn't play [19:12] lool, ^^^ [19:12] was that supposed to work ? [19:13] * ogra_ thought upstart-app=launch made it in [19:13] jfunk: i think its natural that you cant do prioritization suggestions after such a short time [19:14] and i dont think you can easily do it without developers [19:14] there must be some communication about them [19:15] popey: a regression? [19:15] jfunk: lets talk more about it [19:15] no [19:16] ok then its not worrying me so much [19:16] popey: for me it launches the music-app, but then the music-app toggles pause/play all the time [19:16] sad for the individual fate of music experience, but the train can keep going :) [19:17] popey: check running processes, do you see the cmdline which was used? [19:17] popey: sure its not a user not handling his device correct? :) [19:17] maybe you need to push harder :)| [19:17] I have to reflash, I had installed various crap to rebuild xorg-server [19:17] omg [19:18] phablet 2265 1.3 5.5 346844 106456 ? Tsl 19:06 0:08 /usr/lib/arm-linux-gnueabihf/qt5/bin/qmlscene /usr/share/music-app/music-app.qml --file=/home/phablet/Music/Tracy Chapman/Tracy Chapman/Tracy Chapman - Fast Car.mp3 --desktop_file_hint=/usr/share/applications/music-app.desktop [19:18] i didnt realize we are building xorg natively and that lool might use his phone for building it :/ [19:18] * asac will get nightmares aggain [19:18] popey: can you check /proc/2265/cmdline with vi [19:18] asac, dont get nightmares ... fix them, get lool a chromebook ;) [19:18] popey: you should see ^@ for \0 between args [19:18] i guess a burning phone that cant be used to test a critical landing will be in the nightmare :) [19:18] just because it built xorg :) [19:19] /usr/lib/arm-linux-gnueabihf/qt5/bin/qmlscene^@/usr/share/music-app/music-app.qm [19:19] l^@--file=/home/phablet/Music/Tracy Chapman/Tracy Chapman/Tracy Chapman - Fast C [19:19] ar.mp3^@--desktop_file_hint=/usr/share/applications/music-app.desktop^@ [19:19] popey: this should be ^@--file=/home/phablet/Music/Tracy Chapman/Tracy Chapman/Tracy Chapman - Fast Car.mp3^@ [19:19] popey: right, so that's all correct and problem is in music-app then [19:19] thanks lool [19:19] popey: I had to rever to an older music-app to test this recently [19:20] popey: maybe try downgrading to this one https://launchpad.net/~ubuntu-touch-coreapps-drivers/+archive/daily/+files/music-app_0.6bzr117saucy0_all.deb [19:20] it mostly worked for me [19:20] I'm reflashing [19:21] lool: didnt you say you wouldnt come back 2-3 hours ago? :) [19:21] asac: I had to pickup a device in my office, the laptop wasn't suspended [19:22] I thought I'd check if I had pings ;-) [19:22] pings == love [19:22] or sometimes pings == slaps [19:22] lesson learned: dont pick up devices that are in the office :) [19:22] now go away...nothing can be done on music in case its not fixed [19:22] most likely its just popey spreading confusion anyway :-P [19:23] nah [19:23] yeah [19:23] popey, just use rad.io and stop reporting bugs :P [19:23] hah [19:23] I can file you some rad.io bugs if you like ‽ [19:23] lol [19:25] bug 1229905 [19:25] bug 1229905 in Ubuntu Music App "Launch song from dash doesn't play the song" [Undecided,New] https://launchpad.net/bugs/1229905 [19:25] * popey runs away [19:25] heh [19:32] asac, 10 fails on maguro (just done with the tests it seems) [19:32] ogra_: yeah. the regressions are in community apps though [19:32] plars: did you give all of them a second chance already? [19:33] i have zero control over those [19:33] core apps [19:34] asac: still doing a few, and mako is still rerunning [19:34] asac: on maguro, I restarted rssreader and weather-app [19:34] plars: but on maguro we see final standings on dash? [19:34] kk [19:36] asac: unity *did* pass on mako, so I could retry and see what we get on maguro, but we know why the systemsettle there failed so I don't think it's that big of a deal really - I think the crash files are more important on that one === Ursinha is now known as Ursinha-afk [19:41] plars: unity is fine [19:41] we know the bug and its supposed to be fixed in trunk [19:43] asac: is it the "unity and homescope crashers" line on the pipeline? === Ursinha-afk is now known as Ursinha [19:53] fginther, https://code.launchpad.net/~robru/webapps-applications/stop-conflict-with-unity-asset-pool/+merge/187304 just wondering why there's a delay in landing this branch? other merges I've done today landed in less time, but this one is urgent. please take a look if you can, thanks. [19:55] robru, it's in the middle of the last build. should be done soon [19:55] fginther, great, thanks [20:14] plars: yeah.. thats the one [20:14] plars: so only core apps have regressions? [20:14] ogra_: guessw we want to release that [20:14] popey: & [20:15] yup [20:17] 263 ? [20:17] whats missing on mako [20:18] asac: weather and music on mako, on maguro it's unity (crashers), calendar (seen before), rssreader, and music/weather [20:25] asac, so release ? [20:26] wow, mako has 266 tests ? [20:26] thats new [20:32] ogra_: seems so [20:32] popey: bug 1229905 works after updating the music-app [20:32] bug 1229905 in Ubuntu Music App "Launch song from dash doesn't play the song" [Undecided,New] https://launchpad.net/bugs/1229905 [20:32] ogra_: do it [20:32] with latest version from the ppa [20:32] asac, ok, releasing then [20:32] we need to get the core apps somehow under control [20:32] but still, there's another bug that you can open quite many different music-apps in parallel [20:34] asac: You're not getting xorg-server in any time soon, unless people finish that transition. [20:34] Trying easy from autohinter: mir/0.0.11+13.10.20130924.1-0ubuntu1 unity-system-compositor/0.0.1+13.10.20130924.1-0ubuntu1 unity-mir/0.1+13.10.20130924-0ubuntu1 xorg-server/2:1.14.2.901-2ubuntu5 [20:34] leading: mir,unity-system-compositor,unity-mir,xorg-server [20:34] start: 408+0: i-82:a-38:a-32:p-42:a-214 [20:34] orig: 408+0: i-82:a-38:a-32:p-42:a-214 [20:34] easy: 439+0: i-94:a-48:a-41:p-42:a-214 [20:34] * i386: indicators-client, libplatform-api1-dev, libplatform-api1-doc, libubuntu-application-api-mirclient1, libubuntu-application-api-mirserver1, libubuntu-platform-api1-dev, libunity-mir-dev, libunity-mir1, qthybris, qtubuntu-android, unity8, unity8-autopilot [20:34] * amd64: indicators-client, libplatform-api1-dev, libubuntu-application-api-mirclient1, libubuntu-application-api-mirserver1, libunity-mir-dev, libunity-mir1, qthybris, qtubuntu-android, ubuntu-touch, unity8 [20:34] * armhf: indicators-client, libplatform-api1-dev, libubuntu-application-api-mirclient1, libubuntu-application-api-mirserver1, libunity-mir-dev, libunity-mir1, qthybris, qtubuntu-android, unity8 [20:34] infinity: from what i know didrocks uploadde the mir stuff [20:34] FAILED [20:34] (ie: updating mir and xorg causes a bunch of other stuff to become broken) [20:34] so we have build failures? [20:34] asac, done [20:35] rsalveti: sweet, look forward to that in the next image [20:35] infinity: maybe caused by something similar like we had with xorg (odd build-dep resolution?) [20:35] popey, can you announce 20130923/61 ? [20:35] err [20:35] popey, can you announce 20130924/61 ? [20:35] sorry [20:35] ogra_: can you check if the britney output [20:35] asac: I don't see any build failures here. Let me see if I can unwind this. [20:35] ogra_: sire [20:36] er [20:36] ogra_: indicates something that could easily be resolved [20:36] ? [20:36] sure [20:36] unity8-private : Depends: libdee-qt5-3 (>= 3.3+13.10.20130924.2) but 3.2+13.10.20130821.1-0ubuntu1 is to be installed [20:36] popey: ok, I've installed the image and my brain kicked into motion when I reread your symptoms [20:37] popey: your bug was actually known, but I didn't map to it because I thought it was yet another launch issue [20:37] asac, sorry, no clue about Mir deps and i dont want to mess it up more than it is [20:37] popey: try launching music files fomr the *Home* scope instead of Music scope [20:37] asac: Looks like this stack was built against a newer version of dee-qt that wasn't copied over from the PPA. [20:37] popey: the fix is even ready and in PPA, but we couldn't land it because we couldn't land Mir [20:37] popey: I'll dup your bug against hte right one [20:37] asac: Another fail for building in PPAs instead of the archive. :/ [20:37] lool, heh [20:37] lool: that was from home scope [20:37] lool, we still cant land Mir it seems [20:38] popey: it works for me from home scope, by home scope I mean the one also listing apps [20:38] 33333333 [20:38] infinity: is it just one thing that b-deps on that? [20:38] if so wemight want to do a zero-change upload [20:38] asac: It's not a build-dep, it's a runtime dep. [20:38] popey: I can open a regular flac file or a mp3 file with weird chars, both play [20:38] infinity: probably coming in from a -dev :) [20:38] not here ☹ [20:39] popey, use wrod chars ? [20:39] *weird [20:39] popey: what happens if you run the music-app cmd from ps yourself? [20:39] infinity: who depends on the libdee-dev i wonder... :) that one we could rebuild to resolve this, right? [20:39] spaces, nothing else odd [20:39] asac: It would make more sense to get them to copy dee-qt as well. [20:39] asac, we could possibly copy dee, but thats also used on desktop in unity7 [20:39] infinity: we havent tested that and dont know the impact [20:39] phablet 3354 3.0 4.1 378736 78788 ? Tsl 20:36 0:05 \_ /usr/lib/arm-linux-gnueabihf/qt5/bin/qmlscene /usr/share/music-app/music-app.qml --file=/home/phablet/Music/11 Novembre 1918-58'50''.mp3 --desktop_file_hint=/usr/share/applications/music-app.desktop [20:39] infinity: it might bust the desktop :) [20:39] I have spaces and single quotes [20:39] infinity: let me see [20:39] http://people.canonical.com/~platform/cu2d/results [20:40] asac: Only unity8 and qtdeclarative5-friends0.2 use dee-qt, hard to break the desktop with it. [20:40] popey: could be another upgrade bug then [20:40] this is a clean phone [20:40] ogra_: can you check if anything produced by dee-qt is on the touch? [20:40] for sure [20:40] * popey installs 61 on his main phone [20:41] blimey, only 16.5 MB [20:41] ogra_: for sure it is on or for sure i can check? [20:41] both ... [20:41] cant we ban those kind of things that have weird names :)? [20:41] i'm pretty sure its there [20:41] :-P [20:41] checking :) [20:41] asac: Of course something produced by dee-qt is on touch, unity8 depends on it. :P [20:41] root@ubuntu-phablet:/# dpkg -l |grep dee [20:41] ii gir1.2-dee-1.0 1.2.6+13.10.20130904-0ubuntu1 armhf GObject introspection data for the Dee library [20:41] ii libdee-1.0-4 1.2.6+13.10.20130904-0ubuntu1 armhf model to synchronize multiple instances over DBus - shared lib [20:41] ii libdee-qt5-3:armhf 3.2+13.10.20130821.1-0ubuntu1 armhf Qt5 binding for Dee - shared library [20:41] ii qtdeclarative5-dee-plugin 3.2+13.10.20130821.1-0ubuntu1 armhf Qt 5 QML plugin for Dee [20:42] but if infinity is sure it doesnt stretch into desktop. lets just do it [20:42] no [20:42] that will bust us [20:42] i am sure [20:42] i guess desktop only uses dee [20:42] not the qt one [20:42] without testing we cant take this [20:42] need unity8 autopilot suite [20:42] at least [20:43] unity8 was tested against the new dee-qt (obviously), not the old one. [20:43] Since it can't install with the old one. [20:43] right [20:43] i'm pretty sure whoever tested just installed the ppa [20:43] How the autolander is letting people land mismatched things like this, I don't know. Seems like a massive design flaw. [20:44] Or was someone trying to outsmart it and push individual components manually? [20:44] Can we again discuss how silly it is trying to break up landings into tiny sets? :) [20:44] it relies on a static hierarchic definition of stacks that should not allow this, but I guess the fact it's manually managed and that we land other things in other ways in the PPA and in the archive might break it too [20:45] so is that thing pulling in the ui-toolkit? [20:45] its int he same stack [20:45] infinity: is there a way that you can check that you can copy over just that dee-qt5 thing from https://launchpad.net/~ubuntu-unity/+archive/daily-build/+packages [20:46] and that we dont start pulling more stuff in afterwards? [20:46] like the whole ui-toolkit and stuff? [20:47] The easiest way for me to manually test that would be to just copy it and see what britney says. [20:47] Going through all the deps by hand would be time consuming. [20:47] do it ... [20:47] britney will shield us and it is messed up right now anyway [20:48] I wonder if doing a by-hand copy will confuse the autolanding thingee completely. [20:48] that might be indeed [20:48] We'll find out. [20:48] * ogra_ guesses an archive upload might be better [20:48] I'd rather hinder the autolander than have it hinder me. [20:48] ogra_: An archive upload will also stop the autolander, so meh. These binaries were the ones tested. [20:48] yeah [20:49] infinity: ok can we try? and throw it out if its not good? [20:50] thanks [20:50] Copied. [20:51] asac: There's no throwing out, per se. Version can't go backward. [20:51] On the other hand, it can't get more broken than it is. [20:52] popey: same on your phone? [20:54] hmm? [20:54] sorry, too many similar conversations in multiple channels is confusing my little brain [21:09] robru, with the target_branch change to cordova-ubuntu, we're no longer processing merge proposals on the main trunk. Is it ok to enable this in stacks/head/webapp.cfg? [21:10] fginther, yeah, should be fine. want me to do it? [21:10] robru, sure, if you have time :-) [21:10] fginther, I am just waiting for a sloow build, so I have lots of time ;-) [21:11] fginther, hey, can you later check why this hasn't reported back yet? https://code.launchpad.net/~sergiusens/notes-app/click/+merge/187036 [21:11] infinity: good to know ... did britney like the copy? [21:11] :) [21:12] oh its running autopkg tests ... it seems [21:12] asac, so ... cron ? [21:13] robru, there has been a huge spike in merge proposals lately, builders have been slammed [21:13] fginther, ahhh, ok. well the one i needed already landed, so that's good. thanks. [21:13] fginther, https://code.launchpad.net/~robru/cupstream2distro-config/autoland-cordova-trunk/+merge/187354 is this what you want? [21:14] ogra_: i dont know... i dont like cron. its an arbitraryt cut at a random non-predictable state [21:14] asac, oh, and on a sidenote, lightdm is fixed [21:14] ogra_: noone earlier awawke? [21:15] ogra_: i dont believe it until this has gone through testing by 4 eyes :) [21:15] we cant afford another broken landing attempt :-P [21:15] asac, well, whats the wors that happens ? we throw away the image and build a new one [21:15] ogra_: it could also be the last image we will be able to produce for a couple of days :) [21:15] ogra_: well, it might bust our phones for instance [21:15] asac: dee-qt at least fixed the mistake, and made unity8 happy. Harder to unsnag why mir/xorg don't want to migrate (could unwind to any number of other beta blocks, I suppose). [21:15] in lab [21:16] ogra_: and we have to wait half day before we can reset them :/ [21:16] asac: Can we get back to why it matters if something is in proposed for a couple of days? :) [21:17] infinity: because we want to work in the archive :) [21:17] asac: proposed is the archive. [21:17] I don't know why people seem to think it's not. [21:17] infinity, and asac wants to hold back stacks of SW [21:17] there isno way we can feed this from prposed back to our upstream mergers [21:17] infinity: its current reality [21:17] we have to tackle this in some way [21:17] infinity, which can require they sit there for a couple of days [21:18] infinity, to get away from the manually landing small stacks via PPAs habit [21:18] infinity: i have noted that we want to figure how to better life/survive/coexist/benefit from proposed :) [21:18] (i hope at least) [21:18] fginther, hmmm, does this mean anything to you? https://launchpadlibrarian.net/151372910/buildlog_ubuntu-saucy-amd64.libunity-webapps_2.5.0~%2B13.10.20130924-0ubuntu1_CHROOTWAIT.txt.gz [21:18] Well, this could unwind to things depending on the new qtwebkit that's FTBFS on ARM. Dunno. [21:19] infinity: who can understand and unwind this? can ogra do that? [21:19] robru: That means it needs a retry. Linking to builds is more helpful than logs, FWIW. [21:19] robru: Since I can't do much to a log. [21:19] asac, i dont think infinity means https://launchpad.net/ubuntu/saucy/+source/qtwebkit-opensource-src/5.1.1-1ubuntu2 [21:19] infinity, you mean this? http://10.97.0.1:8080/job/cu2d-webapp-saucy-2.1build/51/console [21:19] infinity: i mean if it boils down to landing something very big and intrusive i am happy to revisit ... it basically means to tell didrocks that all his hard work to bring MIR back into our normal archive is kind of lost and he is pissed :) [21:20] infinity, the log is the only thing that tells me anything ;-) [21:20] infinity, submitted the retry already though, thanks [21:20] robru, I see those hash sum mismatch errors during merge testing when apt-get catches the archive in transition. I've never seen in during a launchpad build. [21:20] robru: I meant the launchpad build that had that log linked from it... [21:20] infinity, oh, this? https://launchpad.net/~ubuntu-unity/+archive/daily-build/+build/5047108 [21:21] Yes. [21:21] * infinity retries that. [21:21] qtwebkit-source (2.3.2-0ubuntu1) saucy; urgency=low [21:21] * New upstream release LP: #1202425 [21:21] Launchpad bug 1202425 in qtwebkit-source (Ubuntu) "Please update qtwebkit-source to 2.3.2" [Undecided,Confirmed] https://launchpad.net/bugs/1202425 [21:21] hmpf [21:21] robru, I thought your webapp mp was good until I realized it needed a tweak to the ppa portion [21:22] ogra_: I'm not actually sure it has anything to do with that (though that obviously needs fixing), it was a stab in the dark with > 1000 packages involved here. :P [21:22] ogra_: It probably doesn't relate. [21:22] > 1000 ? [21:22] wow [21:22] But, more to the point, trying to unwind this while we're in a freeze is really painful. [21:22] 0 upgraded, 1054 newly installed, 0 to remove and 0 not upgraded. [21:23] Since that whole stack *is* installable in saucy+proposed, it's clearly failing to install because either something is being blocked by the freeze, or because of some other subtlety. But the former is far more likely. [21:23] yeah [21:24] :/ [21:24] I guess I'm going to keep harping on the point over and over again that not everything is an emergency, not everything needs to hit the release pocket as soon as it's committed, etc. [21:24] i think thats a bit of an idealisitic viewpoint... for us not having this land till friday [21:24] means a super big difference [21:24] asac: It's landed. Redefine what you mean by "land". [21:24] landed is what our infrastructure does [21:25] infinity, ready for image builds [21:25] Our development processes are WRONG if people can't move on until something is on an image. [21:25] yes, there might be an infrastructure or process bug looming [21:25] Period. [21:25] the image is the final product. nothing can be finally validated before its in [21:25] infinity, thats what you get when dropping packages and switching to readonly images ... a change is only a change once it landed in an image [21:25] fginther, lol, I was looking at a stale version of the page and re-approved after you marked it needs fixing. but I pushed a new commit. [21:25] so you cannot just ignore image production [21:26] asac: I'm not talking about ignoring image production, I'm talking about hyperbole that people can't move on to other tasks, that they're blocked, etc. [21:26] infinity: we can move on and we do that. but not for too long [21:26] we need a safe checkpoint [21:26] infinity, to many interdependencies [21:26] sergiusens, it's done, things are slow today due to a massive number of builds [21:26] When I upload a package, I happily ignore it until I notice something wrong with it. I don't babysit it until QA tells me that the new glibc didn't break an ISO. [21:26] that we can cash in... otherwise we build up a huge imaginary bubble of hopes and hot air [21:27] that might explode if we then finally move forward after a week of staging stuff [21:27] The closer you get to working in (and against) the real archive, the less this "we staged a bunch of stuff, but then it mysteriously broke" thing is an issue. [21:27] infinity: right. but glibc maintenance is different from developing hot new features and apps and libs under high pressure [21:28] asac: It's not the only package I maintain. :P [21:28] also its about experience and being able to understand better your cause and effect [21:28] infinity: right, but here we do a complete product rampup with the idea of 100+ engineeres continuously landing something against our archive [21:28] infinity, the point is that we need a way to gatekeep ... proposed is perfect for that ... we do it in the wrong place atm imho [21:29] and they need to first learn the effect of their doing on the final product: image [21:29] Anyhow. It wouldn't be hard for someone to turn on -proposed for a secondary set of touch images. Would that satisfy the need for rapid (but not final) validation? [21:29] robru, thanks. looks good now [21:29] infinity: i dont know. we dont understand how to effectively use proposed and surely cant pull that off in the hurry we are in [21:29] infinity, what i was thinking was to have a special build with a fixed PPA [21:29] infinity: howevever, we are thinking and brewing and growing ideas in that area [21:29] ogra_: The PPA thing doesn't help. We need to see the effect of things hitting the archive. [21:29] infinity, that gets triggered by a cdimage option [21:30] it surely needs to be tackled, but in the meantime we have loads of engineers hung up with the current system. [21:30] ogra_: Does none of it install anymore, does it install but turn your phone green? [21:30] infinity, we want to test selected packagesets against the actual image [21:30] infinity: anyway, lets see if ogra or someone can unwind it to something reasonable. if its a big thing that we need to pull as well, i will discuss [21:30] (or even single packages) [21:30] on tomorrow meeting [21:30] asac: I'm not sure that any of the induced panic since Boston has helped the situation. It seems like a lot more people milling around to solve a lot more problems that didn't seem to be nearly as big a deal three weeks earlier. [21:31] infinity: yeah, bad deadline is looming :) [21:31] (The spreadsheet being a prime example of this, it's a velocity killer) [21:32] thats a separate discussion [21:32] the spreadsheet has many uynderstood bads [21:32] The only way to work in a LARGE distributed project with hundreds/thousands of components is for everyone to land at their own pace, throw it all together, see what sticks, and fix. [21:32] You can't be proactive, because developers don't know the impact of every change on every component, or they flat out lie. [21:32] You have to throw it all against the wall and be reactive. [21:32] Rapidly reactive, but reactive nonetheless. [21:33] i am not even talking about understanding the whole impact on everything [21:33] that is why testing against images is a good thing [21:33] just about teaching the organization what it takes to deliver code ready for a reprodiclbe baseline [21:33] but that needs to happen in a comfortable and automated qay [21:33] *way [21:33] what i am doing here is not teaching the core devs to coordinate etc... i am helping the rest of the organization getting their stuff in shape for a landing... [21:34] ogra_: That assumes your baseline ("the image") won't change between when you tested and when you land tomorrow. With many people landing things in parallel, you have to let them land in parallel. [21:34] which it currently only does for one case and only a set of limited tests [21:34] ogra_: well, sure it should, but should we pack our things if the automation isnt there and go home? [21:34] i dont think so [21:34] And serializing that slows you down to the point where you may as well fire half your staff. [21:34] we can parallelize etc. [21:34] just need to be smart and controlled/precise at best [21:34] asac, no, but what we are doing is replace automation with manpower atm [21:34] manpower we lose elsewhere [21:34] ogra_: i am not replacing [21:34] there is NO AUTOMATION... [21:34] yes [21:35] we are bandaiding to keep the train moving as good as possible [21:35] thats different from replacing [21:35] There was automation... [21:35] right. aautomation that didnt block/consider our touch images [21:35] until we have our automationm improved so we test on touch as part of CI [21:36] we are currently doing the heroic act to replace that missing piece with hard work for the sake of giving everybody a chance for a fair landing [21:36] its paying off debt [21:36] Or have the touch people stop breaking their software every 23 minutes? :) [21:36] sure, just ask yourself how you would do that organizationally at the current time? [21:36] thats something that takes time [21:36] Anyhow. I can try unwinding this xorg-won't-migrate thing. It's going to need caffeine. [21:36] this manual landing approach helps everyone learning about that... calibrate their mindset [21:37] to understand what it means to land something useful :) [21:37] its painful for us... the ones doing the manual testing. but the majority of folks in UE benefit [21:37] infinity: you are awesome... happy to discuss all this at length at a later time :) [21:37] hehe [21:37] asac: Can there be weapons involved? [21:38] no... i think we agree :) [21:38] i know we agree actually [21:38] we have very similar goals [21:38] Agreeing is no excuse not to shoot each other. Thing American. [21:38] s/Thing/Think/ [21:38] just different ways to get the whole UE team there :) [21:47] * asac installs latest released image [21:48] ogra_: do you also feel a slow down of the shell somehow in latest maguro images? [21:48] i feel it was super snappy the last two weeks - all of a sudden [21:48] no, it was always that slow [21:48] imho [21:48] it was super fast in recent images for me [21:49] at least sliding screens etc. [21:49] those animation where super nice [21:49] there was no content :) [21:49] there was [21:49] its home and applications for me [21:49] that is now super slow to scroll [21:49] lets see how the fresh image looks like [21:50] maybe uniuty was still running with -testability enabled [21:50] * asac waits 30 minutes for a fresh install :) [21:50] heh [21:50] i really want to be able to lock my system from writable to factory default [21:50] so i can just update in UI [21:58] ogra_: how is location service going? [21:58] is that working? [21:58] *sigh* asac: a typo kept this from actually getting sent *much* earlier: asac: weather and music on mako, on maguro it's unity (crashers), calendar (seen before), rssreader, and music/weather [21:58] sorry, just realized [21:58] plars: i think i saw that [21:59] ok [21:59] asac, i think it is, but nothing is using it and i dont think the toggles in the indicator work until logind works [21:59] ok, it was still sitting waiting to be sent it looked like, not sure why [22:04] i guess you hit the up key accidentially [22:06] * ogra_ calls it a day [22:11] Hrm, I wonder if this is because of the libmirserver3 conflict with libmirserver1 ... [22:11] Why do people do these things? :/ [22:14] Ahh, no, it's because platform-api is blocked. [22:15] That technically touches the desktop image, but I'll let it slide in anyway. [22:21] cyphermox: asac: ricmm: ogra_: platform-api changes for the music-app just landed in trunk, can we spin a daily ci build for it? [22:22] so it can at least reach proposed [22:22] rsalveti: so our system will pick it up and stage it in the ppa [22:23] Copying: mir/0.0.11+13.10.20130924.1-0ubuntu1 [22:23] Copying: unity-system-compositor/0.0.1+13.10.20130924.1-0ubuntu1 [22:23] Copying: unity-mir/0.1+13.10.20130924-0ubuntu1 [22:23] Copying: platform-api/0.19+13.10.20130924-0ubuntu1 [22:23] Copying: xorg-server/2:1.14.2.901-2ubuntu5 [22:23] asac: ^ [22:23] rsalveti: i dont think its a good idea to push this in while we have mir etc. in proposed [22:23] asac: cool, thought that would be disabled as well by default [22:23] well, it shouldn't matter [22:23] rsalveti: no. it will auto pick up ... and what you have staged is in the ppa. you can see exactly whats staged and ready for copy here: http://people.canonical.com/~platform/cu2d/results [22:23] thats live [22:23] asac: mir just hit the release pocket. [22:23] infinity: wait. platform-api is blcoked? [22:24] i didnt know there was an update pending [22:24] asac: It's in the desktop seed, sadly. [22:24] * asac whips himself to not have fixed monitoring the proposed transition more carefully [22:24] rsalveti: so something just landed [22:24] do you know what that was? [22:24] right, but that was the previous upload [22:24] just a bump in the build-deps [22:24] ok [22:24] ic [22:24] yeah that was important [22:25] anyway, guess the path is in theory free for you guys [22:25] but i really would prefer to do an image spin with just those before goingn down another big chunk [22:25] rsalveti: can we stage and pick this up tomorrow morning? not sure if everythign is there already anyways [22:25] infinity: anyway. thanks a bunch! [22:25] super great [22:25] sure [22:26] i think we are happy [22:26] hope it isnt busted :-P [22:26] I can give you a new image build with this freshly-landed stuff once it publishes. [22:26] i believe thats what we want... let me check [22:27] infinity: i see something about "apparmor profile update for /custom-ization and telepathy-mission-control profile bugfix for desktop" in landing plan :) [22:27] infinity: thats status INPROPOSED ... do you see that? [22:28] * asac wonders why someone isn't putting a decent set of packages in there and spots that the title of that column is misleading [22:28] asac: tp-mc-5 landed in release 5h ago. Loic jammed it in before I yelled at him. :P [22:29] lol [22:29] I see no apparmor stuff in proposed. What source package was that? [22:29] right. thats what i wonder ... i know the title is misleading, but folks must know that its important to mention it :) [22:29] infinity: i guess telepathy-mission-control? [22:30] Like I said, that landed. [22:30] at least thats something package-name'ish mentioned in that verbose description :) [22:30] Oh, that was all one unit? [22:30] https://launchpad.net/ubuntu/+source/telepathy-mission-control-5 [22:30] ah cool [22:30] I thought the tp-mc thing and the apparmor thing were two things you were talking about. :) [22:30] no it was a separate land that still had INPROPOSED ... so had to fix book keeping [22:30] now book is clear [22:31] infinity: so yeah... we want image badly after this :) [22:31] it has unity and mir coming back from sprint in it :) [22:31] So yeah, if you're happy with the state of things, I'll spin up a new image for you in ~10m, and then happily ignore touch for a bit while I go back to the product that has users. *cough* [22:31] thanks [22:31] hehe [22:32] infinity: and thanks for holding the line in the desktop/server world as well :) [22:38] ogra_: so think we are happy [22:38] we get a quick fresh cut soon [22:38] plars: so i really think this apt-get update is really not good [22:39] plars: can we somehow keep a mirror of the archive with far more history? [22:39] so that we can rerun lets say a build from 10 days ago? [22:39] plars: e.g. mako succeeding just means that it picked up the unity fixes that landed _after_ [22:39] :) [22:39] we have to stop that ... its too fuzzy [22:41] Do we not know what versions of things we're testing? [22:41] infinity: yes, due to a bug [22:41] well we know [22:41] While history is good for bisecting, it's less good for automated testing. Testing the latest is always what one wants, surely. [22:41] however, if we look closer we will find that its not what it thought it was :) [22:42] e.g. its not reproducible/predictable... but its transparent in retrospect [22:42] infinity: i agree. however due to infrastruvcture and process mechanics we try to parallelize a bit... overlap is 2-3 images [22:42] just to go faster for the LIKELY_SUCCEED case [22:44] oh and also we should still be able to bisect :) [22:44] right now we cant because old images have packages gone in the archive :) [22:44] hehe [22:44] but thats not my primary concern ... i just want to ensure that we can recover frmo a failyre in the lab [22:45] and process the last 10 images etc. [22:54] infinity: image going? [22:54] asac: we might need to unblock unity-system-compositor as well (from daily CI) [22:54] * Bump build dependency on Mir, to rebuild against latest SONAME. [22:54] asac: Will be in a sec. mir took a second publisher cycle to love me. [22:54] rsalveti: for what? [22:55] rsalveti: unity-system-compositor is in. [22:55] rsalveti: my understanding is that we landed it [22:55] 00:23 < infinity> Copying: unity-system-compositor/0.0.1+13.10.20130924.1-0ubuntu1 [22:55] asac: not the latest [22:55] unity-system-compositor (0.0.1+13.10.20130924.2-0ubuntu1) saucy; urgency=low [22:55] this is the one I'm talking about [22:55] from http://people.canonical.com/~platform/cu2d/results [22:56] That is likely a no-op on the binary side. [22:57] Current one in the archive already depends on libmirserver3 (>= 0.0.11+13.10.20130924) [22:57] rsalveti: ah ok... well, not sure why we want that though [22:57] :) [22:57] rsalveti: if you feel you need it for MM just put it in your landing ask [22:57] oh, great then [22:57] :) [22:57] we will pull it [22:58] no, was just reading the changelog [22:58] ok [22:58] * asac reads too [22:58] rsalveti: well, i guess they want to land a new mir tomorrow :) [22:58] rsalveti: we told them to explicitley manage their soname at least [22:58] yeah, cool [22:59] afaik that involves first bumping build dep, and then shooting the mir update that solves the puzzle of building these :) [22:59] but who knows... i only care that mir made it together with xserver :) [22:59] As a general rule, we don't tend to bump build-deps to force building against newer libraries. We just build against newer libraries. [23:00] But for a tightly-coupled stack like this, I guess no one's going to try to backport one piece to an older version. :P [23:00] So, whatever. [23:00] Like I said, that change is effectively a no-op, since we already have the right libmir* versions in the archive. [23:00] infinity: yeah... so i try to get them merge all those indepdennt sources that talk through a completely unstable api into a single source thing, so i dont need to see this :) [23:01] i dont see why we want to keep them separate if it is super tigthly coupled ayway... just causes grief and pain [23:01] asac: I'd give good money for a stable API and ABI, but I imagine I won't win that battle any time soon. [23:01] well, if they do what i say above, we can get there :) [23:01] at least for mir :) [23:01] Not really, because of xmir and other bits that also need that API. [23:01] not super stable, but at least decent given its current state of maturity [23:02] If it was entirely private, I'd agree that bundling is the obvious way forward. [23:02] infinity: we have found a way to stabilize the client api ... so thats good news [23:02] its just the server api (which is not the one xmir uses) [23:02] asac: Is that way to stop changing it? :) [23:02] no ... they figured what it means it seems [23:02] (Or versioned symbols?) [23:03] at least they said they managed to nail down what their api really should contain and want to maintain it now properly. so big step [23:03] well. lets see. dont ask for miracles :) [23:03] just want to get to a state where we can move pieces reasonably decoupled [23:04] Fair enough. I just want to see a silhouette of Jesus on a piece of toast. [23:06] nice [23:06] thats easy :) [23:06] lol [23:07] ogra_: so i hate your semi dangling multimedia landing. [23:07] ogra_: the state "INARCHIVE (not seeded yet)" is really not looking nice :) [23:07] hehe [23:07] anyway, i think thats landing tomorrow now... so lets leave it [23:09] balloons: you asked for grilo? [23:09] there is nothing in trunk :) [23:09] infinity: Oh, duh. I should've used chdist-mainonly. [23:13] infinity: so image is going? :) [23:13] cjwatson: click-apparmor... that was also you who wanted to upload that? or was that jdstrand ? [23:13] you can go ahead after that image is built [23:14] on click and that [23:15] asac: Yes. [23:15] amaaazinglysupercool [23:16] jdstrand: do you own click-apparmor upload? [23:17] jdstrand: ask 91 [23:17] that one references a FFe and a bug for debdiff, but doesnt have a bugid [23:18] asac: that'd be jdstrand [23:18] asac: nothing in click itself is currently pending [23:18] kk [23:24] ralsina: ask 87 and 88 ... is there code for that? [23:24] ralsina: i couldnt find it staged or anywhere [23:24] ralsina: or was that fixed togehter with the landing we did? [23:42] rsalveti: please add to your android landing if you need a respin of mir [23:43] rsalveti: I can do a run for platform-api now if it hasn't been done yet [23:43] platform-api/android [23:45] asac: need stuff to be merged in mir still [23:45] ok [23:46] cyphermox: please [23:46] i changed status to waiting for code... just change it to candidate if all your bits are staged. thanks [23:56] rsalveti: was commit 154? [23:57] cyphermox: yes [23:57] seems like that one already landed in the ppa, some tests are failing [23:57] ricmm: ^ [23:57] not related with this change as this needs a rebuild in the android package [23:58] a test is failing on intel: http://10.97.0.1:8080/job/autopilot-saucy-daily_release/2104/label=autopilot-intel/testReport/unity.tests.test_dash/DashScopeResultsTests/test_results_message/