=== chihchun_afk is now known as chihchun [05:52] Saviq: yes, dbarth promised to keep on staring at the xenial part [05:53] and I did too [05:53] now it seems finally done, the queue was just again so freakingly big [08:34] cjwatson: sorry; here is the answer from yesterday: https://launchpad.net/~oxide-builds [08:38] cjwatson: Chris had left a question on https://answers.launchpad.net/launchpad/+question/287462 to get the ugprade [08:40] cjwatson: next week would be fine if you expect storage to arrive soon [08:41] sil2100, morning [08:42] sil2100, I need a new rc for frieza, using device tarball http://people.canonical.com/~abeato/avila/ubuntu/device_frieza-20160309.0.tar.xz , mind triggering that? [08:58] seb128: if you had the possibility, the libubuntutoolkit5/-dev at binNEW review would be still waiting (some bugs fixed in the same silo meanwhile) https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-050/+sourcepub/6183236/+listing-archive-extra [08:59] abeato: sure [08:59] thanks [08:59] Mirv, oh right, going to try to get to that this morning [09:00] ok, thanks === chihchun is now known as chihchun_afk [09:20] abeato: done :) [09:20] sil2100, thanks :) [09:38] sil2100: hey, back on the issue i had yesterday about the need to rebuild a silo or not [09:38] sil2100: https://requests.ci-train.ubuntu.com/#/ticket/893 [09:39] it's been tested and so on; but some commits short-circuited us [09:44] hmm === chihchun_afk is now known as chihchun [09:49] sil2100: yeah... [10:05] dbarth_: problematic, the directly-uploaded change for indicator-datetime looks like something we shouldn't overwrite [10:05] dbarth_: not sure what the train means by calendar-app having new commits - did anyone push to trunk in the meantime? [10:08] hm I am runnning the webbrowser autopilot tests as part of our mir release plan.. is there a known issue in rc-proposed? I get 64 failures with the plain ubuntu-touch/rc-proposed/ubuntu image [10:08] sil2100: yes there are new commits on trunk, if you click through to the Jenkins log it shows that [10:13] so that's a rebuild, and a re-qa :/ maybe fast tracked if possible [10:13] i'll trigger the new rebuild now [10:13] dbarth_: well, theoretically you could release the silo as is [10:13] dbarth_: yeah, for indicator-datetime I would also recomment re-including stgraber's change and adding it to one of the merges [10:13] dbarth_: https://launchpadlibrarian.net/247161942/indicator-datetime_15.10+16.04.20160129-0ubuntu1_15.10+16.04.20160129-0ubuntu2.diff.gz [10:14] dbarth_: the trunk commit would be included in the next release instead of this one [10:14] sil2100: dbarth_ no it doesn't work to add a distro upload to one of the MPs, you need to commit it direct to trunk [10:14] For calendar yeah, I suppose [10:15] robru: we could force-publish it then, overwriting it but the change would still be there [10:15] would it? [10:15] dbarth_: it would if you would include it in one of the MPs [10:16] dbarth_: or you can do it as robru said, so direct-push to trunk and then rebuild indicator-datetime [10:16] Any solution is fine for me, we don't really care that much about package history [10:16] dbarth_: sorry there's two things, I'm talking about calendar, the trunk commit will be built in the next build if you publish the current thing without it. Indicator of different, publishing will clobber the distro upload [10:16] right [10:16] so they need to be managed differently [10:17] i think we can deal more simply with the calendar part [10:17] the indicator-datetime part is where i need to take care [10:18] to double check; i need to modify one of the MPs to add the change from stgraber to it, and rebuild the silo with that updated MP, correct? [10:18] to make sure the commit won't conflict, on xenial specifically [10:20] bbiab, sorry === dbarth_ is now known as dbarth-afk [10:27] dbarth-afk: yeah i guess that would work but it didn't really make sense. Don't sully a good mp with an unrelated change, just commit direct to trunk, as the manual distro upload is conceptually similar to a direct trunk commit. [10:28] Anyways, gnight ;-) === dbarth-afk is now known as dbarth [11:26] Saviq: is you team responsible for the welcome wizard? [11:36] rvr: i will need some record of whether calendar-app and indicator-datetime are good to land from a qa perspective; re: silo 003 [11:37] right now the calendar-app changes have been merged already (xenial and vivid as trunk doesn't make a difference afaict) [11:38] dbarth: Silo 3, let me see [11:38] and indicator-datetime had been qa'ed and proved to work afaict as well, on vivid at least, where the packages and branches seem good [11:39] so i would request a qa waiver for xenial, to then ask charles to commit the branches to indicator-datetime trunk (xenial) [11:40] dbarth: Well, it seems it is still not ready "Destination version 15.10+16.04.20160129-0ubuntu2 is missing from changelog (indicator-datetime/xenial). Needs rebuild due to new commits (calendar-app/xenial)". But I don't know how bileto does those checks and how to fix them. You need to talk to sil2100 or robru. [11:40] rvr: i was having that discussion with them an hour ago [11:40] from their pov i could land, albeit with some contorsions [11:41] but before i go down that path, i also need a record from you about the silo being functionally good [11:42] dbarth: Ah, if they are ok, then I will unblock the card and move it to the ready for QA lane. [11:43] Done [11:43] rvr: ok cool; but you hadn't tested it already? or popey? [11:44] dbarth: I haven't [11:44] the calendar part got merged (and released on the store) === _salem is now known as salem_ [11:44] rvr: hmm, ok; then i'll let you double check on vivid that the i-datetime part works as expected with the new calendar-app click [11:45] ping me back when i can annoy everyone again about that landing [11:46] dbarth: Ack [11:49] Saviq: is you team responsible for the welcome wizard? first page of the welcome wizard is in blue text [11:54] thanks === chihchun is now known as chihchun_afk [12:20] davmor2, right, yes, please add a screenshot to bug #1554616 [12:20] bug 1554616 in unity8 (Ubuntu) "Shell and dash visual issues with new UITK and palette" [Critical,Triaged] https://launchpad.net/bugs/1554616 [12:26] Saviq: done thanks === chihchun_afk is now known as chihchun [13:22] jgdx: Silo 5 approved, happy to see all gmail notifications :) [13:22] rvr, thank you and I'm glad to hear it. [13:28] trainguards: could someone trigger a rebuild of silo 69 on vivid arm64 please? [13:42] Elleo: on it [13:43] Elleo: done [13:43] sil2100: thanks :) [13:49] robru: hi. there's something specifically wrong with https://requests.ci-train.ubuntu.com/static/britney/xenial/landing-045/excuses.html in that it hasn't been updated since the morning (2016.03.09 04:08:51 +0000) [14:19] cjwatson: hey! Do you think there would be a possibility for me to get some kind of write access to the public_html/click_packages ubuntu-archive directory on snakefruit? [14:19] cjwatson: to that dir exclusively [14:22] anpok_, morphis: hey! How's the silo 21 testing going? I see the emulator got tested, right? [14:27] sil2100: yes, jhodapp tested mako yesterday [14:27] Looking good so far? [14:27] sil2100: yes [14:27] We can't wait for the emulator unblock ;) [14:27] sil2100: yeah, I saw your mail :-) [14:28] stop fixing the emulator, sell moar phones ! [14:28] sil2100: btw. devel-proposed still doesn't boot, right? [14:28] morphis, sil2100 working on testing flo now [14:28] jhodapp: good [14:28] morphis: yeah, still down, ondra is assigned to it [14:28] jhodapp: excellent [14:28] sil2100, should the xenail dev image on mako be booting atm? For me it never gets past the Google logo [14:28] jhodapp: so lets skip xenial then :-) [14:29] jhodapp: sadly devel-proposed is busted right now, you'd have to test on devel [14:29] morphis, yeah not much I can do there anyway [14:29] jhodapp: https://bugs.launchpad.net/canonical-devices-system-image/+bug/1551150 [14:29] Launchpad bug 1551150 in Canonical System Image "devel-proposed - android lxc container fails to start" [Critical,Confirmed] [14:29] jhodapp: but devel is pretty recent, it's a few weeks old but at least boots ;) [14:29] sil2100, ok [14:29] (in case it has all the packages you need of course) [14:29] sil2100, worth testing these tarballs on? [14:30] I suppose would be nice to at least do a quick one [14:30] Just to make sure we won't make something unbootable or such after devel-proposed is unblocked [14:30] sil2100, sure, I'll test it after vivid then [14:31] Thanks :) [14:48] sil2100: that sounds technically challenging to arrange, but also unnecessary; that directory is maintained by a cron job [14:48] sil2100: the cron job in question lives in lp:~ubuntu-cdimage/click-sync/trunk [14:49] cjwatson: hmmmm... ok, so I have an idea how to workaround this without requiring this permission change, in case that is not viable [14:50] cjwatson: since we'll be doing some workarounds for locking down certain clicks, but now that I think of it it doesn't need to necessarily be in the same directory [14:50] cjwatson: anyway, thanks for pointing to the cronjob :) [14:50] This I didn't know and was actually wondering where that's stored [14:50] dbarth: I've left a comment on https://answers.launchpad.net/launchpad/+question/287462 - it will indeed need to wait until next week. [14:51] sil2100, you committed to it 33 min ago :P [14:51] Yeah, now I noticed, ok, so I'm actually looking for the crontab with cronjobs ;p [14:51] Not the actual script being run [14:52] cjwatson: do you know if the cron-line for executing click-sync is available somewhere? [14:53] i.e. would it be possible for me to change the click-sync arguments in the crontab by myself somehow or will I have to poke someone from ubuntu-archive? [14:54] 11,41 * * * * bzr up -q ~/click-sync && ~/click-sync/click-sync.py --credentials-file ~/.config/click-toolbelt/credentials.json https://jenkins.qa.ubuntu.com ~/public_html/click_packages [14:54] You won't be able to change those by yourself [14:57] Thanks [15:08] sil2100: heya, that arm64 rebuild on vivid for silo 69 doesn't seem to have rebuilt, it's still listed as just having failed 21 hours ago? [15:08] huh, maybe I got a timeout [15:08] Retrying... [15:08] thanks [15:14] cjwatson: ack === chihchun is now known as chihchun_afk [16:19] Mirv, those binNEW looks fine, feel free to publish it [16:20] sil2100, is it a known bug that audio recording isn't working at all on the latest rc-proposed images for mako and flo (and perhaps other devices)? [16:31] jhodapp: hm, didn't hear about it so far [16:31] jibel, davmor2: ^ ? [16:31] sil2100, I've just run into it was mako and flo last night and today [16:31] image 382 for both [16:32] sil2100, jhodapp: hmm should be unless the pulseaudio had some config left over in the silo, let me try hear [16:33] jhodapp: I get audio recording on latest on arale [16:33] sil2100: ^ [16:34] let me flash mako [16:36] davmor2, it may be mako flo specific as they're pretty much the same thing [16:36] jhodapp: I'll let you know shortly [16:36] ok [16:37] alex-abreu: Silo 16 approved [16:37] rvr, awesome thx ! [16:48] jhodapp: confirmed I blame morphis ;) [16:49] :) [16:49] davmor2, sil2100 same is true for the xenial image on both [16:50] jhodapp: you think xenial boots wow when did that get fixed [16:50] davmor2, hehe, the devel, not the proposed [16:51] jhodapp: devel is ancient [16:51] yeah, but seems to suffer the same recording issue [16:51] jhodapp: so that could be cpp issue a xenial issue or something else altogether [16:52] yeah [16:52] or a libhybris I guess [16:53] morphis: is it likely that mako and flo might need a libhybris update maybe? === chihchun_afk is now known as chihchun [17:12] davmor2, do you plan to have a verdict on UITK today? [17:13] Saviq: depends do you promise that you will fix the welcome wizard asap, hum hum hum ? ;) === chihchun is now known as chihchun_afk [17:14] davmor2, I will replace it https://requests.ci-train.ubuntu.com/#/ticket/255 [17:14] Saviq: should be any second I think I've found the only issues I'm going to find and I think they are all application bugs now rather than uitk so will pass it shortly [17:14] davmor2, ack, thanks! [17:26] Saviq, zsombi: any second [17:28] davmor2: one :) [17:28] w00t w00t! [17:29] * Saviq publishes [17:29] will probably faile due to missing privileges [17:29] -e [17:30] yay [17:30] Saviq: it's nice when the bot says you suck right ;) [17:30] mterry, can you please have a look at packaging ↑ [17:30] Saviq, sure [17:30] yeah, could be a bit more delicate [17:31] like I am [17:36] oops, we'll kinda skip the previous unity8 migration to xenial... oh well [17:39] mterry, thankies [17:55] Saviq: exciting times :) === alan_g is now known as alan_g|EOD [17:59] bzoltan_, and it only took two weeks ;P [18:00] bzoltan_, FWIW, unity8's autopilot and QML tests are meant to pass, sometimes not on first try (we're trying to eradicate flaky tests), but overall they need to pass - we'd have found the crashing wizard earlier if the results were looked at [18:01] Saviq: No stress anymore :) [18:01] bzoltan_, wow quite a silo that 50 [18:01] pmcgowan: tell me about it :) took two months to get it in [18:02] pmcgowan: comsulted with cardiologist few times during the time [18:02] landing drugs [18:13] pmcgowan: landing 9 OTA bugfixes feels like being on drugs...I guess :) [18:34] jhodapp: did you file a bug for the issue with recording? [18:35] davmor2, no [19:25] robru: I can't remember, if I remove one component from a silo, do I need to assign it again? [19:27] davmor2: not sure, but which audio recording is not working? as it could be the changed pulseaudio too :-) [19:29] davmor2, jhodapp: can one of you file a bug for that? [19:29] against pulseaudio would be a good start :-) [19:30] boiko: no but you need me to delete it from the ppa [19:31] robru: could you please remove history-service from silo 40 then? [19:32] morphis, sure [19:32] boiko: yeah gimme a minute, just need coffee [19:32] robru: sure, no rush, and coffee is always a good idea :) [19:36] morphis, davmor2: https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/1555307 [19:36] Launchpad bug 1555307 in pulseaudio (Ubuntu) "Audio recording does not work on flo and mako" [Undecided,New] [19:42] jhodapp: thanks dude [19:42] np [19:43] boiko: ok done [19:43] robru: thanks! [19:43] boiko: you're welcome [19:43] (it'll notice in a minute) [19:45] boiko: ^^ that did nothing btw [19:47] robru: yeah, I was not sure if my last commits to messaging-app were built (as the silo was still showing as failed because of history) [19:47] robru: I triggered a rebuild to be sure :) [19:48] boiko: if there were new commits it would say "needs rebuild due to new commits" [19:48] robru: yep ok, I'll wait next time :D [19:50] jhodapp: thanks! [19:51] np [19:51] morphis, btw, libhybris testing is complete [19:51] jhodapp: oh great you did that too! [19:51] yeah looks good to me [19:51] jhodapp: you're rocking, man! [19:52] thanks :) [19:52] jhodapp: then lets switch both to approved [19:52] morphis, do you have an MR for them? [19:52] jhodapp: no [19:52] everything already merged [19:52] right ok, you mean in the silo [19:52] set to approved [19:52] yeah [19:53] sure will do [19:53] jhodapp: https://git.launchpad.net/~libhybris-maintainers/libhybris/+git/libhybris/log/ is what it looks like [19:53] jhodapp: approved both requests already :-) [19:53] nice thanks [19:53] davmor2: more work for you :-) [19:53] morphis, I like the ubuntu screen for recovery [19:54] morphis: no no I refuse to believe that :p [19:54] davmor2: I think there are new cards on your board now :-) === salem_ is now known as _salem [22:41] robru, hey, think we could force merge https://requests.ci-train.ubuntu.com/#/ticket/905 ? It's the same situation as yesterday - armhf backed up and everything else passed fine (or at least didn't regress) - same as happened in the silo before [22:43] Saviq: OK [22:44] thanks [22:45] Saviq: yw === michi is now known as Guest78920