[03:04] <imgbot> [04:09] <imgbot> [04:09] <imgbot> [06:45] <Mirv> SDK folks are reporting phablet-flash doesn't work for them
[06:46] <Mirv> I upgrade just by system-settings
[07:40] <bzoltan> Mirv: I have booted to the bootloader and flashed with ubuntu-device-flash --channel=devel --bootstrap successfully
[07:40] <Mirv> bzoltan: phew
[07:41] <bzoltan> Mirv: yes... relieved. But not a pleasant experience :)
[07:42] <Mirv> bzoltan: landing-009 for QtC plugins, click build when ready
[07:42] <bzoltan> Mirv:  thanks .. building right now
[08:18] <didrocks> cjwatson: hey! I think you read the phone ML and some people complaining of not being able to start some apps anymore. I'm not entirely familiar with the click layout, but it seems to me from latest email of Sam's bull that the installed version is latest one for music app (1.1.359) where his local desktop file is matching 1.3.389 which is… higher? (also look at the click list crash)
[08:19] <didrocks> Mirv: hi! mind doing psivaa_'s backup on the image status as he's not around this week? :)
[08:22] <sil2100> ah, right, he's not around this week
[08:22] <sil2100> didrocks: vila mentioned something he can fill up for psivaa_ if anything, not sure if that changed
[08:23] <didrocks> sil2100: excellent! he's going to do the image status then?
[08:24] <didrocks> maybe better to have 2 pairs of eyes, just in case :)
[08:24] <sil2100> didrocks: that's what I remember from Friday's morning meeting, but I guess that better being safe than sorry ;)
[08:27] <didrocks> heh
[08:27] <Mirv> didrocks: sil2100: sure, I can keep an eye on them too in addition to vila.. of course, if we'd have image testing working in the first place
[08:27] <thostr_> sil2100: could you check line 9 in ci sheet? apparently ted used the wrong ffe bug to document the ffe
[08:28] <didrocks> Mirv: yeah, I count on you guys to refresh me on the image testing story today :)
[08:30] <Mirv> didrocks: latest update is from Paul on ubuntu-qa mailing list
[08:30] <didrocks> Mirv: do you have a direct link? that would be easier (etoomanyemails)
[08:31] <Mirv> so hosts seem down. popey emailed ev and francis on the weekend and now they've kicked it a bit but getting a lot of failing.
[08:31] <didrocks> yeah 185…
[08:31] <Mirv> didrocks: direct link seems a bit problematic, search for "Upgrade of ADB hosts within the CI Lab"
[08:32] <Mirv> didrocks: sil2100: on the good news side, I've ran all AP tests this morning for 256 + updated UITK, and mostly everything passes 100%
[08:32] <Mirv> I've 1 gallery-app test and 1 address-book-app test that seem flaky or broken
[08:32] <didrocks> Mirv: did you try rerunning them then?
[08:32] <didrocks> and they pass?
[08:32] <sil2100> thostr_: checking...
[08:33] <didrocks> thostr_: thanks for updating the bug btw :)
[08:34] <thostr_> ffe bug?
[08:34] <didrocks> jibel: I've got another bug where rosa maria assigned himself
[08:34] <didrocks> thostr_: yep :)
[08:34] <didrocks> (this ffe bug)
[08:34] <Mirv> didrocks: address-book-app test passed individually at least, but gallery_app.tests.test_photo_viewer.TestPhotoViewer.test_photo_delete_works seems to fail consistently
[08:34] <didrocks> kicked him out
[08:34] <didrocks> Mirv: and with downgrading the sdk?
[08:34] <Mirv> and I just tested that those are not related to the UITK but are on #256 in general
[08:34] <didrocks> ok
[08:34] <didrocks> please not that down
[08:34] <Mirv> I mean, that, gallery-app
[08:34] <didrocks> Mirv: any gallery-app update recentaly?
[08:34] <Mirv> yes
[08:34] <didrocks> recently*
[08:35] <Mirv> how to check a 'changelog' for click package, ie upload log
[08:35] <sil2100> thostr_: yeah, I remember the core-dev discussions around Friday
[08:35] <sil2100> thostr_: let me see how we're standing with silos
[08:35] <thostr_> sil2100: thanks
[08:36] <didrocks> Mirv: I think start looking at the image content diff
[08:36] <Mirv> calendar is at 0.4.214, I believe that was also on #250 and passed
[08:36] <didrocks> generated in ogra's directory
[08:36] <Mirv> ok, looked at wrong app, sorry :)
[08:36] <Mirv> but, yes #256 had click:com.ubuntu.gallery from <IP_ADDRESS>7 to <IP_ADDRESS>1
[08:36] <Mirv> so that could explain it
[08:37] <Mirv> filing a bug, although it'd be nice if we would have also automated test results
[08:38] <sil2100> So, to make sure, sergio is currently the only one who can do a click-app landing to the store, right?
[08:38] <Mirv> bug #1296573
[08:40] <sil2100> Saviq: hi!  Ran 34 tests in 623.078s
[08:40] <sil2100> Saviq: good choice, thanks! Keep us updated if anything, and good luck
[08:41] <Saviq> sil2100, there's also upstream folk online today, so we'll be hitting them soon
[08:41] <Saviq> sil2100, will do
[08:41] <sil2100> Saviq: if you need any additional help, just ping
[08:42] <Mirv> popey: aha, aha, good to know
[08:43] <Mirv> I wonder why I'm hitting that, or is there something else on #256 (or before) that causes it
[08:43] <Mirv> ie what base image xnox was using
[09:06] <didrocks> sil2100: as it seems there is no-one from CI around, do you mind retrying the whole set of job?
[09:06] <didrocks> for the tests
[09:06] <didrocks> to see if that's going to fix it
[09:07] <didrocks> (the master job I pointed to all of you last week)
[09:08] <sil2100> didrocks: which set of jobs?
[09:09] <didrocks> sil2100: ah, you didn't write it down?
[09:09] <didrocks> let me refind it
[09:11] <sil2100> I don't seem to have it anywhere, hmm
[09:11] <didrocks> sil2100: http://q-jenkins.ubuntu-ci:8080/job/trusty-touch-mako-smoke-master/
[09:11] <didrocks> Mirv: please note it down too ^
[09:11] <didrocks> this is the master job to relaunch iso testing
[09:11] <Mirv> nice to know, thanks, bookmarking
[09:14] <sil2100> It seems it's waiting for the next available executor to start
[09:15] <didrocks> hum
[09:15] <didrocks> asac: so, we're stuck, no device available ^
[09:16] <sil2100> It seems the only one available is running touch_custom right now?
[09:16] <didrocks> yep
[09:22] <ogra_> apparmor.click.AppArmorException: "Could not find '/usr/share/autopilot-touch/apparmor/click.rules'"
[09:22] <ogra_> hmpf
[09:22] <vila> sil2100, didrocks, Mirv : Yes, only one mako available right now. Thanks to plars and fginther` efforts during the week-end 1 > 0
[09:22] <didrocks> vila: it's the same device than touch_custom and so we are blocked on those tests to finish?
[09:23] <didrocks> (for the rerun)
[09:23] <didrocks> vila: seems like we don't have the AP tests installed on the device on previous 256 run though, and I can't figure why we don't bzr branch the tests
[09:23] <didrocks> asac: FYI ^
[09:24] <asac> didrocks: probably sergio topic
[09:24] <didrocks> asac: or infra?
[09:24] <asac> didrocks: we could compare logs
[09:24] <davmor2> ogra_: what you broken now
[09:24] <didrocks> but yeah, basically all click apps didn't run tests
[09:24] <vila> didrocks: yeah leave it run I'd say
[09:24] <asac> ogra breaks everything
[09:24] <didrocks> ok
[09:24] <asac> single source of obstructions :)
[09:24] <ogra_> davmor2, nothing, thats the crash we have on all failing tests
[09:24] <didrocks> vila: well, I think we'll have the same issue on the rerun, don't you?
[09:24] <vila> didrocks: yeah, there seems to be a single common failure related to click apps not launching
[09:25] <asac> autopilot-touch from 1.4+14.04.20140319.1-0ubuntu1 to 1.4+14.04.20140319.1-0ubuntu2
[09:25] <ogra_> apparmor denies execution
[09:25] <asac> http://people.canonical.com/~ogra/touch-image-stats/20140323.changes
[09:25] <vila> didrocks: sounds likely but it's a wild guess, it's either a click/apparmor issue or some unforeseen fallout from re-provisioning the device
[09:26] <ogra_> .oO( we really need servers without BIOS in the lab )
[09:27] <ogra_> my DSL reconnect seems to have moved to 10:30 ... i might be a few mins late to the meeting btw
[09:27] <vila> ogra_: IIUC said server has a memory issue and the debug they attempted *locally* (i.e. physical access with a physical keyboard) didn't help
[09:28] <ogra_> vila, yep, i saw the mail
[09:28] <vila> ok, great
[09:31] <popey> bah, google talk crash
[09:31]  * popey restarts browser
[09:32] <popey> \o/ freed up 10GB RAM
[09:32] <ogra_> deleted your mail ?
[09:32] <popey> closed chromium
[09:32] <ogra_> hah
[09:33] <ogra_> apparmor.click.AppArmorException: "Could not find '/usr/share/autopilot-touch/apparmor/click.rules'"
[09:35] <didrocks> popey: once shutting down all those html5 games… :p
[09:35] <popey> didrocks: I still don't have the high score in Google Docs!
[09:38] <ogra_> |HELP
[09:38] <ogra_> |HELP
[09:38] <imgbot> I am the firendly image watchbot
[09:39] <ogra_> k
[09:39] <popey> !bots
[09:39] <popey> ogra_: should probably add your bot to that page
[09:39] <ogra_> :)
[09:39] <popey> so people know about it
[09:39] <vila> ogra_: fire ndly ? Put fire on all images ? :-p
[09:40] <ogra_> popey, thanks
[09:41] <ogra_> vila, it only kindles a little :P
[09:41] <vila> ;)
[09:41] <didrocks> popey: I can implement it in the CI train spreadsheet if you want… :p
[09:42] <popey> np
[09:52] <ogra_> autopilot (1.4+14.04.20140319.1-0ubuntu2) trusty; urgency=medium
[09:52] <ogra_>   * Add python-gi and python3-gi dependencies which provide gi.repository
[09:52] <ogra_>     modules. (since gir1.2-upstart-app-launch is accessed via
[09:52] <ogra_>     gi.repository)
[10:05] <sil2100> WTF
[10:05] <davmor2> sil2100: hahaha
[10:05] <sil2100> Now google hangouts won't start!
[10:06] <sil2100> didrocks: ok, it seems both my internet and google hate me today
[10:06] <sil2100> "Please wait"
[10:06] <sil2100> ...
[10:07] <sil2100> didrocks: as for landings, there is one content-hub landing that is ready for landing, but I need sergio around to publish the new gallery-app along with it
[10:07] <davmor2> sil2100: it's okay we pushed all the work over to you
[10:07] <sil2100> didrocks: no other were marked as 'testing done', but I will consult the scopes one I guess
[10:07] <ogra_> popey, did you mean the movies ?
[10:07] <popey> I have 12 items showing in gallery
[10:08] <popey> and 12 media items in the gallery database
[10:08] <didrocks> sil2100: ok, and new scopes?
[10:08] <ogra_> i think it is supposed to
[10:08] <didrocks> maybe mhr3 would know? ^
[10:08] <popey> http://paste.ubuntu.com/7145536/
[10:08] <didrocks> sil2100: yeah :)
[10:08] <didrocks> (sorry was bcklogging)
[10:09] <popey> I'll file a bug
[10:09] <sil2100> didrocks: yeah, will poke them about that :)
[10:09] <seb128> mhr3, can you maybe land/clean l23 (code cleanup in the clip scope)? it has been built and holding a silo for at least half of a week
[10:09] <didrocks> popey: ok, so I guess it's a bug for the apps team? (but if you can try the upgrade stuff…)
[10:09]  * sil2100 has lags so sorry if answering slow
[10:09] <didrocks> popey: maybe one version picked the videos that you have at some point and didn't flush it?
[10:09] <didrocks> sil2100: no worry
[10:10]  * popey shrugs
[10:10] <didrocks> popey: the videos name makes sense at least?
[10:10] <didrocks> like it's videos you had at any point on your device?
[10:10] <popey> they are on my device now
[10:10] <popey> those are the videos I test with
[10:11] <mhr3> seb128, it didn't pass testing last time
[10:11] <popey> maybe gallery is hooked up to mediascanner now, dunno, bug will reveal all
[10:11]  * popey files
[10:11] <seb128> mhr3, if so can you drop it and give back the silo and ask for one again once it's ready? ;-)
[10:12] <mhr3> seb128, fine, drop it
[10:12] <seb128> sil2100, Mirv, didrocks: it would be nice to keep some "desktop silos" with beta freeze today, so we don't block desktop changes to land because there are not silo left
[10:12] <seb128> mhr3, I don't have powers for that, just ^
[10:12] <mhr3> seb128, eh, sorry, i thought i'm talking to sil2100 :P
[10:13] <seb128> lol
[10:13] <seb128> mhr3, you need more coffee!
[10:13] <seb128> mhr3, btw there is a fix up for the manpages scope issue we discussed some days ago, if you want to review/approve that
[10:14] <mhr3> seb128, waiting for david to confirm
[10:15] <seb128> mhr3, you always have a good reason! ;-)
[10:15] <seb128> mhr3, thanks
[10:15] <Mirv> seb128: sil2100: I now went one below the set minimum of 3 free silos to have at least one for desktop, landing-018, and kicked a build
[10:15] <seb128> Mirv, thanks
[10:15] <didrocks> seb128: I agree with you and we can use silo-000 if you need anything
[10:15] <didrocks> Mirv: FYI ^
[10:15] <seb128> Mirv, don't worry about the desktop ones, I'm going to drive them through
[10:15] <Mirv> didrocks: seb128: aha, ok.
[10:16] <seb128> e.g they should be freed in a few hours every time, no days locking
[10:16] <seb128> didrocks, thanks
[10:16] <Mirv> seb128: maybe start from the second one and use 000 for that, while I check freeing up the 018 again
[10:17] <seb128> Mirv, your call, I don't think it's an issue to be down to 2 for an hour
[10:18] <popey> davmor2: didrocks bug 1296634
[10:19] <davmor2> popey: confirmed
[10:20] <Mirv> seb128: ok, you can have it, I just had a configuration messup but now it's building, for real this time.
[10:21] <Mirv> tvoss: can you see about landing the dbus-cpp ppc64el fix that has built in landing-001?
[10:21] <tvoss> Mirv, sure, flashing latest image right now
[10:21] <seb128> Mirv, thanks
[10:25] <didrocks> popey: thanks
[10:28] <davmor2> popey, didrocks: Oho  some of the apps are installing on 237
[10:29] <didrocks> davmor2: wdym?
[10:29] <popey> if they have the 13.10 framework, they will
[10:29] <popey> not every app bumped the framework in their latest updates
[10:30] <davmor2> popey, didrocks: they did for the qt5.2 rebuild I thought
[10:30] <popey> no. not all
[10:30] <popey> some
[10:30] <davmor2> popey: ah oky
[10:30] <popey> apps can still install post-qt5.2 if they have the older framework
[10:32] <davmor2> just leaving myself a list of app to try,  gallery, terminal, camera, music, notes all have command error,   calculator, calendar and sudoku all installed.
[10:35] <cjwatson> didrocks: Yeah, I have a data dump from sergiusens that looks like the same kind of thing - was planning to sit down and stare at it today.  I don't think it's a particularly recent regression, if it's a regression at all - it's the sort of thing that can build up as people install apps, upgrade images, etc.
[10:36] <didrocks> cjwatson: yeah, I was on same assumption, can be an upgrade before updating the image, or multiple upgrades + removal…
[10:37] <didrocks> Saviq: hum, just read kgunn's email? Was I implying it was Mir's fault? I was just explaining the bug…
[10:37] <cjwatson> didrocks: there's definitely something weird, can't tell you what yet
[10:38] <Saviq> didrocks, it read a little bit like it, don't worry
[10:38] <Saviq> didrocks, it might still be in the end ;)
[10:38] <didrocks> Saviq: argh, ok, sorry for that, I'll talk to kgunn
[10:39] <Saviq> not a bug per se, but an incompatibility between how Mir and Qt handle things
[10:39] <didrocks> cjwatson: yeah, I think it's worth having on the radar and see if we can get a clear reproducer
[10:39] <didrocks> but yeah, not anything that will block as probably not new but a followup of people upgrading manually some apps
[10:39] <cjwatson> didrocks: let's not have anyone spend effort on it right now, as I say I have a data dump
[10:40] <didrocks> Saviq: yeah, we do agree, I just tried to explain
[10:40] <didrocks> cjwatson: good :)
[10:57] <davmor2> didrocks: So I just flashed 237, updated all the apps that would, seen the command error issue on all the others.  I've then upgraded to 256 and everything works everything opens with no issues
[10:59] <didrocks> davmor2: ok, I think just concentrate on normal dogfooding until we have image test results now :)
[10:59] <didrocks> sil2100: progress on the gallery-app test failure?
[10:59] <davmor2> didrocks: that's my plan now i'm a work ;)
[10:59] <didrocks> thanks davmor2 :)
[10:59] <davmor2> Morning all
[11:00] <sil2100> didrocks: had to reflash with bootstrap, as it seems I had some deb version of gallery-app and the click one did not want to work
[11:00] <sil2100> didrocks: so I'll be running the real test just now
[11:00] <didrocks> sil2100: ok, let's see if the test failing is flaky or not…
[11:00] <didrocks> hey davmor2!
[11:14] <ogra_> hmm, to bad psivaa isnt around ... having a test run with rolled back AP would really be interesting
[11:16] <ogra_> grr
[11:16] <didrocks> ogra_: yeah, let's see with Mirv's first test result run
[11:16] <ogra_> webapps really misbehave on my phone
[11:17] <didrocks> with a clean bootstrap image
[11:17] <didrocks> ogra_: misbehaving like?
[11:17] <ogra_> didrocks, well, i always have like 5 open constantly ... flicking through them one or two always die
[11:17] <ogra_> randomly
[11:17] <ogra_> not sure when that started
[11:18] <ogra_> (i'm on 254 btw)
[11:18]  * ogra_ upgrades to 256
[11:20] <didrocks> ogra_: what webapps are you trying? so that I can try on latest
[11:21] <ogra_> heise, golem n-tv.de are the ones i have always open
[11:21] <ogra_> and G+
[11:21] <ogra_> i'll see after upgrade if it happens right from the start or only after a while ... havent rebooted since the last upgrade
[11:23] <ogra_> doesnt happen after upgrade/reboot yet ... i'll watch it over the day
[11:23] <ogra_> aha, now it did
[11:23] <ogra_> (and is fine again after the app restarted)
[11:24] <ogra_> i'll leave the phone alone for a while and re-check again later
[11:24] <didrocks> ogra_: yeah, I can't reproduce it until now here
[11:24] <ogra_> session restore would really be an awesome feature :)
[11:25] <ogra_> so you dont have to always re-open all your apps after upgrade
[11:28] <didrocks> yeah
[11:28] <ogra_> lol
[11:28] <ogra_> http://www.ebay.com/bhp/nexus-4-broken
[11:28] <ogra_> they even have a category for that
[11:29] <didrocks> waow
[11:29] <ogra_> we should buy all of these and put them in the lab :)
[11:29] <ogra_> (i use my broken one here for doing bootcharts ... works excellent)
[11:42] <davmor2> didrocks: one broken phone per test how quick would result be in then ;)
[11:42] <didrocks> heh :)
[11:46] <ogra_> davmor2, thats the idea
[11:46] <ogra_> parallelize all tests
[11:47] <davmor2> ogra_: No don't parallelize them, it's cruel to put tests in wheelchair
[11:47] <ogra_> :P
[11:52] <t1mp> is this the correct channel to request to trigger a CI run on this MR? https://code.launchpad.net/~andrew-hayzen/ubuntu-ui-toolkit/fix-swipe-delete-002/+merge/202171
[11:52] <didrocks> t1mp: it is, please ask the citeam (if no vanguard, just use cihelp) ^
[11:56] <t1mp> !cihelp
[11:56] <t1mp> ?
[11:56] <Mirv> t1mp: you just use it in hilight and they'll get it
[11:56] <Mirv> for hilight
[11:56] <Mirv> that magic string ci_help without underscore
[11:56] <t1mp> Mirv: ahh :)
[11:57] <josepht> t1mp: looking
[11:57] <t1mp> josepht: thank you.
[11:57] <Mirv> FWIW so far even after bootstrap I'm not getting test failures (in click packages)
[11:58] <Mirv> didrocks: ^ on #256
[11:58] <sil2100> Craaap
[11:59] <didrocks> Mirv: ok, so seems to be infra-side only… :(
[11:59] <didrocks> asac: FYI ^
[11:59] <Mirv> so it seems
[12:02] <seb128> sil2100, Mirv: I freed my 2 silos, if you want to give me 1 pack for some other desktop line ;-) (need to keep the ball rolling with beta freeze today)
[12:02] <ogra_> Mirv, no aa-click crashes ?
[12:02] <seb128> 1 back*
[12:03] <asac> didrocks: cant be long until they come on
[12:03] <sil2100> seb128: ;) Thanks!
[12:03] <sil2100> seb128: doing!
[12:03] <Mirv> ogra_: where they would be visible?
[12:03] <seb128> sil2100, thanks
[12:04] <ogra_> Mirv, in /var/crash
[12:04] <Mirv> ogra_: nope. I do have one _usr_lib_arm-linux-gnueabihf_upstart-app-launch_desktop-hook.32011.crash
[12:04] <Mirv> that seems to have happened during notes AP tests (which succeeded)
[12:07] <sil2100> seb128: ok, assigned - line 55 will have to wait as u-c-c is already locked by silo 11
[12:07] <sil2100> From bregma's landing
[12:07] <seb128> oh
[12:08] <seb128> sil2100, thanks for spotting that, and that's fine ;-)
[12:08] <davmor2> popey, didrocks: I just noticed that my 256 image has no oddities in the gallery app. That is on the upgrade from 237 to 256 so I wonder if it is something on the platform from 255 to 256 rather than gallery itself?
[12:08] <ogra_> Mirv, yeah, doesnt look like the one we get on the infra
[12:13] <mhr3> sil2100, you didn't free 002?
[12:13] <mhr3> sil2100, pinged you last week that i'm giving it up
[12:13] <mhr3> sil2100, and now i want silo for 57
[12:15] <asac> didrocks: ok thats semi-good news i think
[12:15] <asac> Mirv: do you use the phablet-flash command?
[12:16] <asac> or ubuntu-device-flash?
[12:16] <didrocks> asac: which news?
[12:16] <asac> didrocks: that its infra only
[12:16] <sil2100> mhr3: I freed it, I guess someone else assigned it?
[12:16] <didrocks> asac: yep…
[12:16] <asac> didrocks: on the bad side we are blind
[12:16] <asac> but maybe we are still good :P
[12:16] <didrocks> indeed
[12:16] <didrocks> or we are regressing
[12:16] <asac> as long as we produce enough images we are probably fine
[12:16] <asac> and maybe have someone once a day crunch all APs manually :(
[12:18] <ogra_> yeah, now having doanac's "run all AP tests like UTAH did" script would be nice to have
[12:18] <sil2100> mhr3: let me free it again then
[12:20] <didrocks> asac: that's what Mirv did for a sdk landing
[12:20] <sil2100> didrocks: no failures on my device on latest image for gallery... ran the whole test suite 4 times already
[12:20] <didrocks> sil2100: can you just upgrade from Mirv's silo and see if you get the gallery failure he has?
[12:48] <sil2100> didrocks: hmm, seems to look ok as well, 2 test runs and no failures
[12:48] <didrocks> not sure what Mirv is experiencing, maybe the phone doesn't like colder temperatures…
[12:48] <didrocks> or cats
[12:49] <didrocks> sil2100: thanks for looking at it!
[12:49]  * didrocks classes that at NOISSUETHERE for now
[12:50] <Mirv> cat is a possible explanation
[12:51] <sil2100> Waiting just in case for the third test suite run
[12:55] <Mirv> asac: too many highlights, so I used ubuntu-device-flash this time for the newest bootstrap, and I was using phablet-flash earlier
[12:56] <ogra_> i can definitely run the aa-clickhook command from the .crash manually and it properly works and finds the file
[12:57]  * ogra_ has no idea wh it wouldnt work during testing
[12:57] <ogra_> *why
[12:58] <Mirv> ok in my latest gallery-app rerun after bootstrap flash I got one fail, but it was different from before, so no I can't trustworthily reproduce the TestPhotoViewer.test_photo_delete_works ...
[12:59] <davmor2> Mirv: that might be the bug that appears on an initial install IIRC it is something to do with the icon on notes
[12:59] <davmor2> didrocks: 256 is looking similar to 250 for me
[12:59] <didrocks> davmor2: apart from the blank dates and photos, right?
[13:00] <davmor2> didrocks: see my message earlier I don't see that on the upgrade from 237 to 256
[13:00] <didrocks> davmor2: your first trial was a direct flash?
[13:01] <didrocks> and you did wipe when getting back to 237?
[13:01] <davmor2> didrocks: no upgrade from 255 or 254 whatever was released early on Sunday
[13:01] <didrocks> ok
[13:01] <didrocks> and on 237, you did wipe, imported some photos and upgrade?
[13:01] <davmor2> didrocks: I did a bootstrap to get 237 on
[13:02] <didrocks> and imported some photos/videos?
[13:02] <didrocks> or all blank and fresh?
[13:02] <davmor2> didrocks: blank and fresh I can add some images if you want and try again
[13:03] <didrocks> davmor2: yeah, let's see that
[13:03] <didrocks> so get 237
[13:03] <didrocks> import some photos and videos
[13:03] <didrocks> run the gallery-app
[13:03] <didrocks> and then update
[13:04] <davmor2> didrocks: will do I'll give you a ping in a bit
[13:06]  * sil2100 lunch
[13:07] <didrocks> great!
[13:09] <ogra_> not that this would help much with all tests failing :P
[13:10] <cjwatson> Sorry for the -proposed logjam, folks, having some problems with the x264 transition causing proposed-migration to take eons
[13:10] <ogra_> s/all tests/all click tests/
[13:11] <cjwatson> I *think* this run might sort it out
[13:21] <Mirv> balloons: with the new qtdeclarative 5.2.1-3ubuntu11 there's a fix for bug #1294181 from qtdeclarative side, ie the revert-212 could be reconsidered since it shouldn't be crashing anymore
[13:23] <balloons> Mirv, yes, did kunal re-propose the merge?
[13:23] <balloons> it should pass and yes, we should add it bacl
[13:28] <Mirv> balloons: I don't see such a branch that would revert the revert, but anyhow such could be proposed now
[13:29] <balloons> Mirv, would you mind doing it? I can help approve/review
[13:31] <Mirv> balloons: tried, a few problems. bzr merge -r 213..212 has conflicts in WeekView.qml and calendar.qml
[13:33] <Mirv> I might be able to cope with it even with my zero calendar knowledge
[13:33] <Mirv> just a minute
[13:34] <popey> Mirv: when you have 10 mins, we could do with a calendar release. lots of good UI stuff landed over the weekend.
[13:35] <bfiller> sil2100, didrocks: can we get silo14 released? it needs gallery app click to be released at same time
[13:36] <didrocks> bfiller: gallery-app is part of the silo 14 isn't it?
[13:37] <didrocks> bfiller: and please, ping all EU people, so that Mirv can help you as well if around :)
[13:37] <didrocks> (see /topic)
[13:37] <cyphermox> howdy
[13:37] <didrocks> bfiller: who is doing the gallery-app part from the click store, is that coordinated?
[13:37] <didrocks> hey cyphermox
[13:38] <bfiller> didrocks: I don't know, sergio usually does it but he's not here today
[13:38] <cyphermox> yo yo yo, how's everyone and everything doing?
[13:38] <popey> didrocks: sil2100 pinged me earlier, and I suggested xnox if he's about
[13:38]  * ogra_ is banging his head against the aa-clickhook crashers and doesnt get anywhere
[13:38] <popey> otherwise balloons is around and can upload to store too
[13:39] <bfiller> didrocks: yes gallery is part of silo 14 but needs a click release at the same time of deb release
[13:39] <didrocks> bfiller: please get xnox or balloons in though, so what we don't release in a broken state
[13:39] <didrocks> we don't have access to click store here
[13:40] <balloons> ty Mirv
[13:40] <bfiller> didrocks: this is going to be a common occurance in the next few weeks where we'll need coordination
[13:41] <bfiller> balloons: can you help get gallery-app click ready for release (using branch in silo-14)?
[13:41] <didrocks> bfiller: yeah, I expect the landers to coordinate on that. That's part of the issue of having your app in click
[13:41] <bfiller> didrocks: great
[13:41] <bfiller> didrocks: wishing we hadn't done that (:
[13:42] <bfiller> we really need the train to release both click and deb
[13:42] <didrocks> bfiller: I warned about it (not sure it was to you :))
[13:44] <bfiller> didrocks: is there a roadmap for having CI Train support both click and deb?
[13:44] <didrocks> bfiller: not with the current workload
[13:44] <Mirv> popey: um, should I know about publishing click apps?
[13:44] <didrocks> bfiller: the airline should have it, it's on the roadmap of it
[13:44] <didrocks> bfiller: not sure about the train
[13:44] <popey> Mirv: it wouldn't hurt if you did, xnox does. would be good to have more .eu people able to
[13:45] <Mirv> popey: sure, I'd love a guide to it
[13:45] <popey> (note: I don't have the power to publish clicks, and I don't want to, I am happy keeping the approval auth only)
[13:45] <popey> Mirv: if xnox isn't around, balloons may be able to help here ☻
[13:46] <bfiller> xnox is off today afaik
[13:46] <bfiller> so is sergio
[13:46] <popey> balloons: ^^ quick! Someone wanting to offload work from you! Snap it up!
[13:46] <bfiller> so balloons is the only click man
[13:46] <balloons> lol
[13:46]  * balloons is watching the dialog
[13:47] <balloons> building clicks is generally very easy if the project is setup with cmake
[13:49] <balloons> for things that get hard, francis has setup jenkins jobs, so in general it's fairly straightforward to do
[13:53] <bfiller> Mirv: can you get silo14 released then? and balloons can you release gallery app click? I really need to get that silo freed as it's blocking address book silo
[13:53] <Mirv> bfiller: yes, if balloons says yes in case it needs coordinated
[13:53] <Mirv> like it sounded like in the backlog
[13:53] <balloons> Mirv, bfiller yes I can help build the click
[13:54] <balloons> and push it
[13:54] <bfiller> balloons: great
[13:54] <bfiller> Mirv: lets do it
[13:54] <Mirv> ok
[13:54] <mhr3> sil2100, 002 tested, rdy to publish
[13:55] <balloons> bfiller, I assume we want a build of trunk?
[13:56] <bfiller> balloons: trunk + https://code.launchpad.net/~ken-vandine/gallery-app/content_hub/+merge/211091
[13:56] <bfiller> (that's what's in the silo that we need released)
[13:57] <cjwatson> bfiller: fwiw there'll be perhaps an extra half-hour delay to proposed-migration over the usual, in case that matters to you
[13:57] <cjwatson> still working through some issues from this morning
[13:57] <bfiller> cjwatson: thanks for the heads up, shouldn't be a problem
[13:59] <sil2100> mhr3: hoke! Sanks
[14:00] <Mirv> bfiller: publishing done
[14:01] <bfiller> Mirv: great, thank you
[14:01] <Mirv> balloons: https://code.launchpad.net/~timo-jyrinki/ubuntu-calendar-app/revert_213_that_reverted_212/+merge/212422
[14:02]  * didrocks is out for a run
[14:04] <didrocks> balloons: bfiller: FYI, you have the branch somewhere with the merge since it was published
[14:04] <sil2100> mhr3: hmm
[14:04] <sil2100> mhr3: so, just want to make sure - was the add() method always internal?
[14:05] <mhr3> sil2100, yes
[14:05] <mhr3> sil2100, you are looking at the diff, aren't you? :)
[14:05] <didrocks> bfiller: balloons: http://<IP_ADDRESS>/job/landing-014-2-publish/lastSuccessfulBuild/console says lp:~ps-jenkins/gallery-app/trusty-proposed for gallery-app
[14:06]  * didrocks really out now
[14:06] <balloons> I find it a bit odd you would release a random branch like that, and not something like lp:gallery-app/release
[14:06] <sil2100> Mirv, bfiller: remember about publishing gallery-app to the store now
[14:06] <mhr3> sil2100, now i'd like silo for 34 :)
[14:06] <Mirv> sil2100: happening with balloons
[14:06] <sil2100> ogra_: since didrocks is out, do you have a moment?
[14:07] <bfiller> balloons: I guess it will be trunk now that Mirv has published
[14:07] <sil2100> Mirv: balloons has the power to publish stuff to the store as well? :D
[14:07] <Mirv> sil2100: yes, apparently, newly found powers
[14:07] <sil2100> \o/
[14:07] <Mirv> bfiller: not yet merge & clean ran
[14:07] <sil2100> ogra_: I need a core dev for a packaging ACK ;)
[14:07] <sil2100> ogra_: http://<IP_ADDRESS>/job/landing-002-2-publish/60/artifact/packaging_changes_unity-scopes-api_0.4.0+14.04.20140324-0ubuntu1.diff
[14:08] <ogra_> sil2100, ack
[14:09] <sil2100> ogra_: thanks! :)
[14:11]  * Mirv published also UI Toolkit (thanks to my today's double testing I already did before they did their own testing) and Qt Creator plugins
[14:14] <sil2100> mhr3: will assign 34 once we free up some of the now publishing silos :)
[14:22] <plars> sil2100: I'm going to let the one you restarted run for a bit more, but if it still has problems, I want to kill it early and try a different device
[14:22] <Mirv> bfiller: I guess you as the lander will run the merge & clean for the landing-014, and only after that the changes are pushed to trunks
[14:23] <bfiller> Mirv: ack
[14:23] <plars> sil2100: right now, it's running webbrowser tests, which passed fine before, but in a little while it should start getting to the ap tests that had failed
[14:23] <sil2100> plars: ok, sure, thanks... let's just keep an eye on it if it starts having problems again
[14:24] <thostr_> sil2100: could you reassign silo15 to line item 8 of the ci sheet?
[14:24]  * Mirv needs to move to do some babysitting
[14:24] <sil2100> thostr_: let me see
[14:25] <sil2100> thostr_: so, you want to let go of silo 15 and assign line 8 instead, right?
[14:25] <Mirv> bfiller: and it needs the IGNORE_PACKAGES_NOTINDEST since they are not yet in reelase pocket, co-operate with sil2100
[14:25] <Mirv> sil2100: ^ possibly that flag to be used so that click can be built from the trunk?
[14:25] <Mirv> especially with proposed migration being slow today
[14:26] <thostr_> sil2100: yes. in the meantime ted can fix line 9 :)
[14:26] <sil2100> Mirv: hmm, I don't think we need to use any flags here?
[14:26] <plars> sil2100: I'm watching it right now
[14:26] <Mirv> sil2100: well, yes if wanting to run m&c before migration to release pocket?
[14:26] <sil2100> thostr_: ok ;) This will take some moments though
[14:26] <sil2100> Mirv: I guess so - can't we wait? :)
[14:27] <cjwatson> it shouldn't take *too* much longer now
[14:27] <Mirv> sil2100: that's up to bfiller + balloons, I'm not exactly sure how critical the click package copublishing is
[14:27] <cjwatson> 15mins more for this publisher run, then I'll be able to set p-m back to normal
[14:27] <cjwatson> (rough guess)
[14:28] <cjwatson> so there's probably no need to take special measures
[14:28] <sil2100> Mirv: I think that as long as we don't build a new image in the meantime, we're safe
[14:28] <sil2100> cjwatson: thanks!
[14:28] <bfiller> sil2100: yup, as long as we don't build a new image until the gallery-app click is released we should be fine
[14:28] <Mirv> sil2100: ok, then it's less critical time wise
[14:28] <Mirv> as long as balloons doesn't disappear or something
[14:28] <sil2100> Let's just keep this in mind though and not forget m&c'ing
[14:29] <Mirv> as we don't have sergio, x_nox etc
[14:29]  * Mirv runs
[14:30] <bfiller> Mirv sil2100 : I got this error doing merge and clean: http://<IP_ADDRESS>/job/landing-014-3-merge-clean/15/console
[14:30] <bfiller> is that related to issue cjwatson is describing?
[14:31] <sil2100> bfiller: this just means that we need to wait still for the packages to migrate from proposed to the archive
[14:31] <sil2100> bfiller: I guess we need to wait up to an hour still
[14:31] <bfiller> sil2100: ok thanks
[14:37] <cjwatson> bfiller: yes it is
[14:37] <cjwatson> Hm, maybe I underestimated the publisher runtime :-/  The domination phase is up to eight minutes now even just for one architecture
[14:38] <cjwatson> I don't have great intuition for this bit
[14:38] <bregma> sil2100, and when you get the chance, landing-011 is ready for a publish (desktop-only)
[14:38] <sil2100> thostr_: uh, sadly, it seems some of your components from line 8 are locked in a big silo 004 from Saviq
[14:39] <thostr_> sil2100: but that can be landed now, no?
[14:41] <sil2100> thostr_: yes, but it's still not built and tested
[14:42] <Saviq> sil2100, silo 004 is just for testing, wasn't it supposed to be disregarded for locking?
[14:42] <thostr_> sil2100: Saviq: if so, then just give us the override permission and everything should be good
[14:44] <cjwatson> ok, fortunately the 13 minutes that that took on amd64 didn't multiply up by the other architectures
[14:44] <sil2100> Saviq: ah, sure
[14:45] <sil2100> thostr_: ok, let me assign that silo then
[14:45] <sil2100> cjwatson: phew
[14:45] <thostr_> sil2100: thanks
[14:45] <Saviq> thostr_, sil2100, yeah, override away, we'll manage
[14:46] <sil2100> ogra_: another packaging ACK: http://<IP_ADDRESS>/job/landing-011-2-publish/lastSuccessfulBuild/artifact/packaging_changes_unity_7.1.2+14.04.20140321-0ubuntu1.diff <- the migration file looks ok, checked in the bzr branch
[14:48] <fginther> popey, hello. the changelog version for stock-ticker-mobile-app went backwards, causing the PPA upload problems. Is this something we can change?
[14:48] <popey> fginther: we can
[14:49] <ogra_> sil2100, looks fine, ACK
[14:49] <popey> fginther: what went backwards?
[14:49] <sil2100> ogra_: thank you again!
[14:49] <popey> 0.4.3 -> 1.0 -> 1.0ubuntu1 in the debian changelog fginther ?
[14:50] <sil2100> thostr_: line 8 assigned
[14:51] <popey> fginther: the .desktop file was fixed by balloons in rev 177.. is that it?
[14:52] <plars> sil2100: I'm still getting that error on your rerun, so I'm going to kill it
[14:52] <plars> sil2100: I've set up another device to try
[14:52] <plars> sil2100: and while that's running, I'll poke at some things on the first device we tried to see if I can find differences in it's behavior
[14:52] <fginther> popey, the debian/changelog went from '0.3.7ubuntu1' to '0.3.7'
[14:52] <plars> asac: ^
[14:53] <fginther> popey, http://bazaar.launchpad.net/~stock-ticker-dev/stock-ticker-mobile-app/trunk/revision/63
[14:53] <asac> plars: right
[14:54] <fginther> popey, you're comment makes me think I'm looking at the wrong branch :/
[14:54] <popey> oh, no, I am looking at the wrong thing
[14:54] <popey> i was looking at sudoku, sorry
[14:55] <ogra_> plars, so there is some weird behavior with all click tests ... resulting in an aa-click crash file ... that claims /usr/share/autopilot-touch/apparmor/click.rules does not exist ...
[14:55] <sil2100> plars: strange thing, thanks, keep us updated :)
[14:56] <ogra_> plars, do you have a chance to check on a device if that file is there (i think it makes all click tests fall over, but i see teh file on a fresh install)
[14:56] <plars> ogra_: sure, I'm just looking for /usr/share/autopilot-touch/apparmor/click.rules on the device itself?
[14:56] <popey> fginther: not been touched for ages. not sure why it would break now.
[14:57] <ogra_> plars, yeah
[14:57] <plars> ls: cannot access /usr/share/autopilot-touch: No such file or directory
[14:57] <plars> odd
[14:57] <ogra_> plars, https://jenkins.qa.ubuntu.com/job/trusty-touch-mako-smoke-daily/175/artifact/clientlogs/ubuntu_calculator_app/_usr_bin_aa-clickhook.0.crash/*view*/ is an example crash
[14:57] <ogra_> so thats why all our click tests fail
[14:58] <plars> ogra_: shouldn't autopilot put that there though?
[14:58] <ogra_> plars, yeah
[14:58] <ogra_> and it does so on my fresh install here
[14:59] <ogra_> so something must have removed it
[14:59] <fginther> popey, merging a changelog bump should get everything working again
[14:59] <ogra_> is my assumption
[14:59] <plars> ogra_: ok, so autopilot-touch is *not* installed on that device at the moment
[14:59] <asac> feels like autopilot-touch isnt installed?
[14:59] <plars> asac: right
[14:59] <asac> so a dependency change issue
[15:00] <ogra_> plars, asac, it is seeded
[15:00] <ogra_> its in the readonly image
[15:00] <ogra_> how can it be missing ?
[15:00] <asac> apparmore could hide it, no?
[15:00] <ogra_> not from root
[15:00] <asac> then i dont know
[15:00] <ogra_> i think
[15:01] <plars> aha!
[15:01] <plars> I found it
[15:01] <ogra_> wow, i spent nearly my whole day on this ... fun that the file simply doesnt exist
[15:01] <plars> + adb-shell sudo apt-get autoremove --purge -y python-gi url-dispatcher-tools
[15:02] <asac> ogra_: do we see anything like that in the logs?
[15:02] <asac> plars: who is doing that?
[15:02] <ogra_> plars, lol !
[15:02] <plars> ogra_, asac: so you remember that change that was made a while back to remove the deb packages that were installed for testing before going to the next test?
[15:02] <ogra_> asac, thats fine (well, was)
[15:02] <plars> that's the culprit
[15:02] <plars> but this isn't a new thing
[15:02] <ogra_> the last autopilot upload added a python-gi dep
[15:02] <asac> plars: right. we have to run apt-get install ^ubuntu-touch after i guess
[15:02] <plars> it's been like this for a while, so I guess something ... yeah
[15:02] <asac> otherwise might loose something
[15:02] <cjwatson> ok, proposed-migration should be back to normal now
[15:02] <ogra_> its AP
[15:03]  * ogra_ dances
[15:03] <ogra_> hooray
[15:03] <popey> fginther: https://code.launchpad.net/~popey/stock-ticker-mobile-app/fix-changelog sufficient? if so, I'll merge it
[15:03] <ogra_> plars, so can we drop python-gi from that line safely ? its preinstalkled on the image now
[15:03] <plars> I think so, hang on
[15:04] <ogra_> i even read that line today
[15:04] <ogra_> but it didnt strike me that it pulls AP as well
[15:04] <plars> ogra_: right, so we force python-gi for the unity8 tests,  because that was needed at one time. If it's preinstalled now then we can drop that. Of course this doesn't prevent some other package from doing this to us in the future
[15:04] <ogra_> indeed
[15:05] <plars> ogra_: it's a bit heavy-handed, but we could force reinstall of autopilot-touch after, if there's no better way. For now though, I'll just pull out the python-gi bit
[15:05] <ogra_> right
[15:05] <ogra_> i doubt it has ill sideefects
[15:05] <ogra_> we'll have to sort all that anyway once AP went off the image
[15:06] <fginther> popey, +1
[15:06] <fginther> If you propose an MP, I'll approve
[15:06] <asac> plars: cool. thx
[15:06] <asac> nice one
[15:06] <asac> (i assume this is really it)
[15:06] <ogra_> hard one though
[15:06] <ogra_> asac, it is
[15:06] <plars> ogra_: thanks for spotting that! that was the needle in the haystack we needed!
[15:07]  * ogra_ knows everything about that issue now ... plars only have me the missing piece of the puzzle
[15:07] <ogra_> *gave
[15:07] <asac> ogra_: thanks!
[15:08] <sil2100> \o/
[15:08] <asac> didrocks: plars has probably found the issue and is "fixing" it as we speak :)
[15:08] <asac> read above
[15:10] <sil2100> dbarth, mardy: hi! I think it would be nice if we could do a landing of signon and libaccounts-qt with the two merges 'working-around' the -dev cmake file install in the packaging
[15:10] <sil2100> dbarth, mardy: as the current versions in the archive are broken
[15:11] <sil2100> dbarth, mardy: I would say to land for now the workarounds, with moving the installation of cmake files only to the -qt4 versions (as per the 2 merges that are available)
[15:11] <dbarth> sil2100: hi
[15:11] <mardy> sil2100: do you think you could directly upload them, or do we need to pass through a silo?
[15:11] <popey> fginther: https://code.launchpad.net/~popey/stock-ticker-mobile-app/fix-changelog/+merge/212451
[15:11] <sil2100> We would land the proper fix later
[15:11] <sil2100> mardy: I would say doing it through a silo would be cleaner
[15:11] <mardy> sil2100: OK
[15:11] <sil2100> mardy: we won't have to do the whole testing, just a general install would be sufficient
[15:11] <dbarth> sil2100: on another note, i have line 33 with that pre-oxide set of MPs
[15:11] <sil2100> As we would be only landing the 2 packaging fixes
[15:12] <dbarth> sil2100: i've created a new request to distinguish between changes that require oxide as a build-dep
[15:12] <dbarth> and those which are fine to build / test with just fixes and optional runtime support
[15:12] <dbarth> sil2100: can you activate line 33, and we'll try to land that quickly before oxide is fully ready for a build dep
[15:12] <plars> asac, ogra_, didrocks: ok, that fix has been pushed in, and I expect it will work. This explains why when I tried just one of the tests by itself everything went fine, but had problems when going through the entire run. There is already a run in progress that hasn't gone far enough to hit this, so we can let it continue to run, and it will get around to the failed ones eventually
[15:13] <mardy> dbarth: so, we are talking about https://code.launchpad.net/~robru/signon/trunk/+merge/210917 and https://code.launchpad.net/~sil2100/libaccounts-qt/fix_dev_conflict/+merge/211058
[15:13] <mardy> dbarth: can you queue a silo for them?
[15:13] <sil2100> dbarth: dbarth thanks! I'll assign it pretty soon, we're low on silos but we published a lot of them now, and soon they should be free
[15:13] <asac> plars: thx
[15:13] <dbarth> sil2100: ok, keep us posted
[15:13] <sil2100> dbarth: so I suspect that in an hour we might have all the required bits assigned with silos
[15:13] <sil2100> Thanks guys!
[15:14] <dbarth> mardy: once silos become available; how much of a priority is that?
[15:14] <sil2100> plars: ah, so no re-run needed?
[15:14] <dbarth> if that's to unblock other packages, I guess we can have a silo more easily, but i wiuld recommend we give a final try at the webapps+oa one and free the silo one way or the other
[15:15] <mardy> dbarth: that's a question for sil2100; it's a packaging change, rather harmless, I'm not sure who requested it
[15:15] <plars> sil2100: I kicked one on a different device after I saw yours was hitting the same problem, and it's already started - so there *is* a rerun needed, but I don't have to kill the one in progress to do it
[15:15] <sil2100> mardy, dbarth: I would like to have it released as today while upgrading my system I encountered the conflict on my system first-hand
[15:15] <sil2100> So generally it's not a good thing to have brokenness in the archive ;)
[15:16] <sil2100> I wouldn't say it's high prio, but since it's a quick landing I thought we can quickly land it once some silos become available
[15:16] <fginther> popey, do you want to set the release to 'trusty' in that MP?
[15:17] <fginther> popey, I missed that when I looked a moment ago
[15:18] <popey> fginther: saucy and trusty are the only two we're said we're building for
[15:18] <fginther> popey, right. I mean change it from "UNRELEASED" to "trusty"
[15:19] <fginther> in the changelog entry
[15:19] <dbarth> sil2100: ok, hand over the silo when one is free and we'll do some quick regression testing on it
[15:19] <popey> i changed from raring to UNRELEASED
[15:21] <sil2100> dbarth: thanks :)
[15:28] <cjwatson> is there any hope of getting https://code.launchpad.net/~cjwatson/dee/multiarch/+merge/211463 landed soon?
[15:29] <stgraber> I just added a click landing to the spreadsheet, let me know when we can have a silo
[15:29] <cjwatson> (stgraber's request is also indirectly from me, and I'd rather that one come first if there's a shortage)
[15:32] <cjwatson> oh, click might fail to build until the python3-defaults/dh-python stuff in trusty is sorted
[15:32] <davmor2> didrocks: sorry for the delay now I get the odd dates
[15:32] <davmor2> didrocks: in gallery
[15:33] <didrocks> davmor2: so, existing data?
[15:33] <davmor2> didrocks: I added one image and 6 videos and I get 6 dates that are blank I'm assuming representing the videos
[15:33] <didrocks> cjwatson: I guess for dee, you need the lander or you can get that in a stgraber's silo
[15:34] <didrocks> which you will get once one is freed
[15:34] <didrocks> davmor2: mind updating the bug report, set it as critical and send that to bfiller?
[15:34] <didrocks> seems like an important one to me
[15:34] <didrocks> thanks plars
[15:39] <seb128> sil2100, Mirv: there are a bunch of silos that can be cleaned (so you can start attributing some backs ;-)
[15:40] <josepht> t1mp: the CI job has been run on the MP you mentioned.
[15:43] <sil2100> seb128: as Mirv is away, I'll m&c his silo ;p
[15:43] <seb128> sil2100, thanks
[15:43] <bfiller> davmor2: added videos how? via mtp? sounds like a missing codec if that's the case
[15:44] <seb128> bzoltan, tvoss, bfiller also have silos that are waiting to be cleaned
[15:44] <davmor2> bfiller: https://bugs.launchpad.net/ubuntu/+source/gallery-app/+bug/1296634
[15:45] <davmor2> bfiller: I added my steps below all of popey 's work
[15:46] <davmor2> bfiller: let me know if you are missing anything
[15:47] <bfiller> davmor2: what types of videos are they?
[15:48] <popey> mine are h264
[15:48] <davmor2> bfiller: the ones I copied across are the 6 mp4 I using in testing they all work fine on the device
[15:48] <popey> they all play fine in mediaplayer and have thumbnails in the dash
[15:48] <didrocks> davmor2: bug #1273781, did this ever worked or it was a regression?
[15:48] <bfiller> davmor2: which version of gallery click?
[15:49] <sil2100> bzoltan: hi! You can merge and clean silo 009 now :)
[15:49] <popey> didrocks: i dont think that ever worked
[15:49] <bfiller> davmor2: hopefully this will be fixed with pending version that is about to land - it uses libthumbnailer
[15:49] <popey> bfiller: i tried latest in store and previous
[15:49] <bzoltan> sil2100: thanks!
[15:49] <bfiller> popey: click list?
[15:50]  * cjwatson vaguely wonders why merge-and-clean isn't automatic
[15:50] <popey> bfiller: i have downgraded to 931
[15:50] <popey> com.ubuntu.gallery	<IP_ADDRESS>1
[15:50] <didrocks> thanks popey
[15:50] <popey> but kept the same database so unsurprising the blank thumbnails are still there
[15:52] <bfiller> popey: try mv ~/.cache/thumbnails to another location and restarting
[15:52] <popey> ok
[15:53] <sil2100> tvoss: you can merge and clean silo 008 if anything ;)
[15:54] <tvoss> sil2100, cool, thank you
[15:55] <tvoss> sil2100, triggered
[15:55] <popey> bfiller: same
[15:55] <popey> bfiller: http://popey.com/~alan/phablet/device-2014-03-24-155534.png
[15:55] <sil2100> tvoss: thanks
[15:56] <bfiller> popey: any chance you could upload a few of the videos and picture?
[15:56] <popey> sure
[15:56] <popey> most are ripped from youtube using youtube-dl
[16:06] <thostr_> didrocks: Saviq: what about landing new scopes today?
[16:07] <Saviq> thostr_, just running the fixed flaky test
[16:07] <didrocks> thostr_: I'm all for that :)
[16:07] <didrocks> thostr_: metapackage is ready and everything
[16:07] <thostr_> didrocks: cool
[16:07] <Saviq> thostr_, I'm +1 on it after that is confirmed fixed
[16:07] <didrocks> great!
[16:07] <Saviq> didrocks, so yeah, it's time for additional eyes
[16:07] <didrocks> sil2100: if you are around?
[16:08] <didrocks> stgraber: including dee request in the click one?
[16:08] <sil2100> \o/
[16:08] <sil2100> didrocks, Saviq: the scopes transition you mean?
[16:08] <cjwatson> didrocks: they're unrelated so probably shouldn't be in the same silo
[16:08] <didrocks> sil2100: yep
[16:09] <didrocks> cjwatson: it's just to avoid using 2 silos as we are quite low on free ones
[16:09] <cjwatson> well, ok, should be safe enough I guess
[16:09] <Saviq> sil2100, yup, landing-013, needs some bashing :)
[16:09] <didrocks> yeah, I don't think the dee part will break your landing :)
[16:09] <cjwatson> seems unlikely :)
[16:10] <didrocks> cjwatson: I'm adding it to the same request and configure it for you
[16:11] <didrocks> cjwatson: stgraber: assigned
[16:12] <t1mp> josepht: thanks!~
[16:13] <cjwatson> didrocks: ta
[16:13] <didrocks> yw
[16:14] <tvoss> sil2100, could you give silo 001 a spin, too?
[16:15] <sil2100> tvoss: sure ;) Getting to it!
[16:15] <stgraber> didrocks: thanks
[16:15] <tvoss> sil2100, thanks.
[16:18] <sil2100> didrocks: you have a moment for a packaging ACK? :) http://<IP_ADDRESS>/job/landing-001-2-publish/lastSuccessfulBuild/artifact/packaging_changes_dbus-cpp_2.0.0+14.04.20140322-0ubuntu1.diff <- seems a bit hacky, but I guess it's ok in this case
[16:19] <didrocks> sil2100: so, all the stack is building with gcc 4.8 on ppc64el?
[16:19] <didrocks> I think it's due to the stack protector thingy
[16:19] <davmor2> cyphermox: I've marked that bug as fixed I've not had issues with adb/mpt since ogra_ did all those update a few images ago
[16:20] <cyphermox> thanks, that's what I thought
[16:20] <ogra_> cyphermox, we seem to still have an issue with the mtp content not refreshing when files are added/removed though
[16:20] <cjwatson> didrocks: either it is, or it won't build at all there :)
[16:20] <cjwatson> didrocks: ppc64el doesn't have gcc-4.7
[16:20] <cyphermox> ogra_: yes I know
[16:21] <sil2100> didrocks: I need to check for other components, but I guess that's a start
[16:21] <didrocks> ok, so all the stack is built with 4.8 and we won't have the ABI mismatch with C++11
[16:21] <didrocks> thanks cjwatson
[16:21] <didrocks> sil2100: based on that +1 ^
[16:21] <ogra_> cyphermox, ah, good
[16:24] <asac> cyphermox: can you ping RichiH about modemmanager?
[16:24] <asac> thx
[16:26] <tvoss> didrocks, sil2100 for questions on the motivation for the dbus-cpp fix -> doko :)
[16:27] <cjwatson> tvoss: I think I've supplied the answers :)
[16:27] <davmor2> popey: https://bugs.launchpad.net/ubuntu/+source/dialer-app/+bug/1288692 can you confirm this is fixed too?
[16:28] <balloons> bfiller, popey Mirv gallery app is uploaded to store, ready for review
[16:28] <tvoss> cjwatson, oh yeah, sorry :)
[16:29] <popey> ack
[16:29] <bfiller> balloons: thanks
[16:29] <popey> balloons: [u'all'] that looks wrong
[16:29] <balloons> popey, scratch that, it built as _all
[16:29] <popey> haha
[16:29] <balloons> why did it do that?
[16:29] <balloons> :-(
[16:31] <cjwatson> because the manifest didn't have an "architecture" entry that said otherwise?
[16:33] <seb128> hum
[16:33] <seb128> jenkins down?
[16:33]  * balloons looks
[16:33] <cyphermox> so it is
[16:33] <mhr3> sil2100, 34 pls
[16:33] <Mirv> sil2100: thanks :)
[16:34] <sil2100> mhr3: suar
[16:34] <sil2100> Nooooo
[16:34] <asac> plars: were we able to confirmt hat the fix helped?
[16:35] <cyphermox> sil2100: didrocks: I'll restart jenkins...
[16:35] <sil2100> cyphermox: if you have the power, please do
[16:35] <cyphermox> done
[16:36] <plars> asac: I'm watching the current build, and it should hit one of the failed ones soon - when that happens I'll send out an email
[16:36] <asac> plars: ok so we didnt see it helping yet? ic
[16:36] <plars> asac: also, we have confirmation from IS that they got the previously dead device host back up and running
[16:36] <asac> nice
[16:36] <asac> so we have all the devices available again? /me thinks nothing can stop us now
[16:36] <ogra_> did they add a proper BIOS then ? :)
[16:36] <sil2100> mhr3: you have to wait some time, jenkins is restarting
[16:37] <mhr3> sigh
[16:38] <cyphermox> should be back up alredy
[16:38] <cyphermox> it only takes a minute
[16:48] <plars> asac: good news, notes-app was the fist one it got to that was failing before, and it's now passing :)
[16:49] <davmor2> popey: do you get a nice black screen for several seconds if you close a video?  Same as you get when you close accounts.   Makes me wonder if the 2 are called in a similar fashion and the call has changed
[16:49]  * ogra_ hugs plars
[16:49] <sil2100> mhr3: anyway, it's assigned ;)
[16:50] <popey> davmor2: lemme test
[16:50] <mhr3> sil2100, i'll call 002 my personal silo :)
[16:51] <plars> ogra_, asac: Also, the original host is back up - since mako seems to be running ok, I'm going to let it continue that job where it's at, but I did go ahead and kick off flo and manta on the original adb host
[16:51] <davmor2> popey: when I say close I mean hit the minimise button or whatever it is meant to be :)
[16:52] <popey> davmor2: yeah, goes black here. stays black
[16:52] <davmor2> popey: it goes eventually honest :)
[16:52] <popey> hah, *eventually*
[16:52] <popey> yes
[16:52] <ogra_> plars, yeah+
[16:53]  * plars watches image 256 gradually get a little more green
[16:54] <davmor2> okay hands up if you deal with accounts and mediaplayer
[16:56] <asac> plars: \o/
[16:57]  * davmor2 sees asac put his hands up and blames him for all the black windows when closing accounts and videos
[16:57] <davmor2> :D
[16:57] <ogra_> twice even
[16:57] <ogra_> that were two hands
[16:57] <davmor2> ogra_: one for each application obviously :)
[16:58] <ogra_> heh
[17:02] <ogra_> didrocks, heh, funny, so now my morning notification mail has a HO link, the evening one doesnt
[17:03] <ogra_> (well, it has it as text in "location" just not as link)
[17:03] <sil2100> didrocks: meeting :)
[17:04] <didrocks> yeah, was in a meeting
[17:04] <didrocks> coming, sorry
[17:05] <didrocks> cyphermox: coming?
[17:07] <fginther> popey, can you take a look at my comment here: https://code.launchpad.net/~popey/stock-ticker-mobile-app/fix-changelog/+merge/212451
[17:10] <ogra_> bfiller, messaging-app tests seem to fail in flames
[17:11] <ogra_> http://ci.ubuntu.com/smokeng/trusty/touch/mako/256:20140324:20140304/7337/messaging_app/
[17:13] <popey> fginther: fixed it to raring (like previous releases)
[17:13] <tvoss> sil2100, didrocks, Mirv could someone review the packaging changes in https://code.launchpad.net/~thomas-voss/process-cpp/fix-death-observer/+merge/211996
[17:13] <tvoss> I needed to bump the so name
[17:13] <dbarth> sil2100 or robru: I messed up the reconfig. of silo 007; the update to https://code.launchpad.net/~mardy/webbrowser-app/add-onlineaccount-support-for-container2/+merge/211701 is not getting in
[17:14] <dbarth> can you manually reconfig this one?
[17:14] <fginther> popey, thanks, approvedd
[17:14] <robru> dbarth, sure
[17:14] <bfiller> ogra_: must be the apps fault :)
[17:14] <ogra_> bfiller, dialer too it seems (that one just finished)
[17:15] <ogra_> 4 failures in 9 tests
[17:19] <robru> dbarth, ok, reconfigged
[17:20] <dbarth> robru: thank you!
[17:21] <robru> dbarth, you're welcome
[17:21] <dbarth> robru: and if a silo frees up, i also have this line 33 for later today
[17:22] <robru> dbarth, ok, i'll keep an eye
[17:32] <robru> dbarth, yeah, your line 33 has webbrowser-app which conflicts with your existing silo 7. but the good news is that there's no restrictions on landing, so if you can test silo 7, i can publish that, and then get you a silo for line 33
[17:34] <robru> mhr3, just published silo 2
[17:35] <mhr3> robru, ty
[17:35] <robru> mhr3, yw
[17:37] <robru> seb128, you got silos 11 and 12
[17:38] <mhr3> didrocks, something wrong with 013?
[17:38] <didrocks> mhr3: hum, why?
[17:39] <didrocks> seems "building"
[17:39] <mhr3> didrocks, cause it says it's building, but the link is dead
[17:39] <didrocks> interesting
[17:39] <didrocks> mhr3: weird weird weird
[17:40] <didrocks> seems jenkins "lost" this run
[17:40] <didrocks> I just rerun with watch onlly
[17:40] <robru> tvoss, you got silo 14
[17:40] <mhr3> didrocks, k
[17:41] <didrocks> mhr3: seems the right status is available now
[17:42] <didrocks> mhr3: however, not sure why the test plan is content-hub
[17:42] <didrocks> and not unity8 :)
[17:42] <mhr3> didrocks, clearly to make it pass :P
[17:44] <seb128> robru, thanks
[17:44] <robru> seb128, you're welcome
[17:47] <didrocks> mhr3: tsss ;)
[17:52] <ogra_> hmmm, sudoku-app fails too
[17:52] <ogra_> and it didnt change since 250
[17:59] <ogra_> argh
[18:00] <ogra_> and calculator-app looks awful as well
[18:00] <ogra_> heh, or not ... the dashboard is cheating :P
[18:01] <ogra_> it was cheating for sudoku too
[18:01] <ogra_> bah
[18:03] <asac> ogra_: arent the results still outdated on ci.ubuntu.com?
[18:04] <ogra_> asac, until the tests have run ... the dashboard shows the old tests until the new ones have run ... i looked to early at sudoku and calculator
[18:04] <ogra_> http://ci.ubuntu.com/smokeng/trusty/touch/mako/256:20140324:20140304/7337/
[18:04] <ogra_> sadly dialer and messaging failures are real
[18:05] <t1mp> for messaging they also failed on my mako (with a fresh 256 image): http://paste.ubuntu.com/7147199/
[18:07] <balloons> bfiller_afk, fyi, store changes are holding back gallery app from going on. The store folks are looking into fixing the issues. ETA is today
[18:08] <robru> ogra_, feel like kicking an image build? i've published a few things this morning, seems like a good time for a new image to me
[18:08] <ogra_> robru, i thought we shouldnt until all new sopes are in ?
[18:08] <ogra_> *scopes
[18:08] <ogra_> at least thats how i understood didier in the meeting
[18:09] <robru> ogra_, hmmm i published a few scopes already, let me check on that
[18:09] <ogra_> (i was distracted, but i think he said something like that)
[18:09] <robru> ogra_, oh yeah, I guess that's silo 13 then, with ubuntu-touch-meta
[18:10] <ogra_> right
[18:10] <ogra_> so lets wait until thats done
[18:10] <robru> ogra_, i already landed all the other scopes, so i think just silo 13. ok
[18:10] <asac> ogra_: hmm. ok. well, folks should fix it then
[18:11] <robru> Saviq, how's silo 13 testing going? need help?
[18:24] <t1mp> hello. I'm trying to run some AP tests for apps to test changes in ubuntu-ui-toolkit
[18:24] <t1mp> I cannot test with the autopilot packages that match the versions of apps in image 250, because they are no longer available
[18:25] <t1mp> I can do an apt-get update first and then get them, but then I will have mismatching versions of apps/libs
[18:25] <t1mp> and image 256 has some broken apps/tests
[18:25] <t1mp> so would it be useful to make sure that the -autopilot packages for the latest promoted image are still available somewhere?
[18:25] <t1mp> I don't know if it is feasible to arrange that
[18:26] <t1mp> at least then we can test our changes with the AP tests in the latest promoted image
[18:26] <ogra_> t1mp, as cjwatson suggested, we should copy them to some PPA when the image is built or so
[18:26] <t1mp> I missed that
[18:26] <t1mp> but that sounds like a good solution for me
[18:26] <t1mp> cjwatson: +1 :)
[18:27] <tedg> robru, There are some packaging changes that need acking for the silo 15 publish: http://<IP_ADDRESS>/job/landing-015-2-publish/9/
[18:28] <robru> tedg, yeah, cyphermox just acked those, will publish in a sec
[18:29] <tedg> robru, Cool, thanks!
[18:29] <tedg> cyphermox, Thanks!
[18:38] <robru> tedg, ok, silo 15 published
[18:38]  * tedg does a little dance
[18:40] <ogra_> asac, http://ci.ubuntu.com/smokeng/trusty/touch/mako/256:20140324:20140304/7337/
[18:40] <ogra_> looks great (apart from the known two apps)
[18:53] <fginther> robru, is lp:qtcreator-plugin-cmake now in ci-train? I see revisions indicating that it is - https://code.launchpad.net/~ubuntu-sdk-team/qtcreator-plugin-cmake/trunk.  but the spreadsheet doesn't list it: https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0Au6idq7TkpUUdC05a2ZQSmgwU2NFYnJQOE9qMDRYa3c&usp=drive_web#gid=1
[18:53] <robru> fginther, everything should be in citrain. spreadsheet is probably just stale, lemme check
[18:54] <fginther> robru, thanks. It's a new branch. I don't even have the ci jobs enabled in s-jenkins yet
[18:54] <robru> fginther, yeah, so assigning an official lander & test plan for that seems to have been forgotten, we should do that
[18:55] <robru> fginther, right, daily_release is dead, when adding new projects to ci make sure to have the three "use citrain" flags set (just like all the others)
[18:55] <fginther> robru, ack
[19:15] <asac> ogra_: yay. do we know whats up with those apps?
[19:15] <ogra_> asac, nope, but bfiller_afk is pinged
[19:15] <asac> ogra_: did we land them?
[19:15] <ogra_> yes
[19:15] <ogra_> in 253
[19:15] <asac> ogra_: reproducible locally?
[19:15] <ogra_> http://people.canonical.com/~ogra/touch-image-stats/253.changes
[19:16] <ogra_> asac, yeah, i think t1mp reproduced it, he pinged me about it even befoe we re-ran the tests on the infra
[19:16] <asac> bfiller_afk: sure you tested your silo for landing with proper attention :)? or maybe because of click you missed that?
[19:16] <asac> guess click can easily lead to such mistakes
[19:16] <ogra_> yeah
[19:16] <ogra_> though these two are unconfined ...
[19:16] <ogra_> so click shouldnt make a big difference
[19:18] <asac> ogra_: well, oversight
[19:18] <asac> using apt-get install
[19:18] <asac> but not updating the click package
[19:18] <asac> its all sergios fault :P
[19:18] <ogra_> yeah, might be
[19:18] <ogra_> (not the latter one :P )
[19:25] <robru> Saviq, i tried running unity8 AP on silo 13, got some funny errors: http://paste.ubuntu.com/7147801/ maybe a dep missing? any thoughts?
[19:27] <Saviq> robru, yeah, wrong tests
[19:27] <Saviq> robru, probably stale ~/autopilot or something?
[19:27] <robru> Saviq, oh, that's possible. let me blast that and try again
[19:28] <Saviq> robru, I'm +1 on it
[19:28] <robru> Saviq, ok great. it looked really good to me just playing with it briefly, will publish soon
[19:31] <Saviq> robru, awesome
[19:37] <popey> fginther: can you take a look at bug 1296610 ? The build for click has the key, but the desktop build in the ppa doesn't. -> var twcKey = "";
[19:38] <asac> ogra_: couldnt we revert the click things from store?
[19:38] <asac> sounds like one of the easier things to do
[19:38] <ogra_> dunno
[19:38] <ogra_> popey, ^^^
[19:39] <ogra_> iirc you did that already
[19:40] <popey> ogra_: revert what exactly?
[19:40] <ogra_> dialer and messaging
[19:41] <popey> have they been updated in the store?
[19:42] <ogra_> dunno how they get in
[19:42] <ogra_> http://people.canonical.com/~ogra/touch-image-stats/253.changes
[19:42] <popey> they get manually put in and then I test and either accept or reject them usually
[19:42] <ogra_> they were updated in 253
[19:42] <popey> dialer and messaging aren't clicks are tey?
[19:42] <popey> *they
[19:42] <ogra_> oh
[19:42] <ogra_> indeed they arent
[19:42] <popey> ii  dialer-app     0.1+14.04.20 armhf        Dialer application for Ubuntu
[19:42] <ogra_> yes
[19:42] <popey> ii  messaging-app  0.1+14.04.20 armhf        messaging application for Ubuntu
[19:43] <ogra_> the changelog tells us :P
[19:43] <popey> :D
[19:43]  * Saviq just read "dealer-app" WHA?!
[19:43]  * popey wanders off again
[19:43] <ogra_> asac, so not a store thing
[19:43] <ogra_> Saviq, ssshhh
[19:43]  * popey has a butt-clench every time I see dialer-app ☻  should be dialler ☻
[19:43] <Saviq> :D
[19:55] <bfiller> balloons: thanks
[19:55] <t1mp> popey: and dealer id dealler in britain?
[19:55] <asac> ogra_: ?
[19:55] <asac> ogra_: cant we just remove latest version from store and done?
[19:57] <asac> anyway out for now. happy that ci is back on image level
[19:58] <asac> and that the ashes server is also back (soon?)
[20:01] <thostr_> Saviq: robru: can you drop me a not if/when the scopes finally make it?
[20:01] <Saviq> thostr_, will do
[20:01] <pmcgowan> scopes landing?
[20:01] <thostr_> Saviq: thanks
[20:01] <pmcgowan> hoohaa
[20:01] <thostr_> pmcgowan: yes
[20:01] <robru> thostr_, Saviq: just getting packaging changes acked by core dev. should be good Real Soon
[20:02] <thostr_> robru: ok, then I leave it in your hands... should be a piece of cake now anyway :)
[20:02] <plars> bfiller: the 15 failures on messaging app appear to be reproducible on my setup at home also, have you seen these? http://ci.ubuntu.com/smokeng/trusty/touch/mako/256:20140324:20140304/7337/messaging_app/
[20:02] <plars> bfiller: there are dialer_app failures also
[20:02] <bfiller> plars: boiko was looking at them
[20:03] <plars> bfiller: ok, thanks
[20:03] <bfiller> boiko: any update on this?
[20:05] <t1mp> plars: I created a bug for it https://bugs.launchpad.net/messaging-app/+bug/1296826
[20:06] <robru> Saviq, ok, just hit publish on silo 13 now ;-)
[20:09] <mhr3> robru, \o/
[20:10] <robru> mhr3, ohhhhhh yeah
[20:10] <mhr3> robru, so 257 will have it?
[20:11] <robru> mhr3, heck yeah! we (ogra_?) are gonna kick 257 as soon as unity8 makes it through proposed, maybe in an hour
[20:13] <mhr3> think i'll take holiday just to celebrate that
[20:14] <robru> mhr3, yeah, I was testing the silo and it looked like a massive improvement. I'm excited too!
[20:15] <mhr3> oh were the old scopes that bad? i haven't been running them for too long :)
[20:16] <robru> mhr3, well, unity8 home screen used to just hard-code 9 apps with no way to change it. now that's gone, and the scopes-scope makes unity8 much more dynamic, almost like a real usable OS ;-)
[20:17] <mhr3> i do see the *almost* there ;P
[20:17] <boiko> bfiller: I flashed my nexus 4, installed messaging-app, and ran the tests, they were OK, but tiago managed to reproduce the problem, we are still checking what is going on
[20:21] <boiko> plars: did you run autopilot on the device, or did you use phablet-test-run, or even something else?
[20:23] <plars> boiko: something that runs phablet-test-run - we have ci infrastructure that sets everything up and runs through all the tests, but in the end, for autopilot tests, it's just running phablet-test-run
[20:25] <cjwatson> t1mp: nope, still dealer
[20:26] <cjwatson> robru: oh yeah, I should see whether it still has that bug where it shows those nine apps even if some of them have been removed :-)
[20:27] <robru> cjwatson, i think you'll be pleasantly surprised ;-)
[20:42] <boiko> plars: ok, trying that here
[20:47] <Saviq> robru, \o/
[20:49] <balloons> bfiller, popey is finishing the review now for gallery -> store
[20:50] <popey> balloons: running ap tests now
[20:50] <bfiller> popey, balloons: thanks
[20:51] <bfiller> popey: regarding that blank thumbnail, trying to track that down. Basically the gallery is now supposed to show thumbnails and allow playback of videos found in ~/Pictures or ~/Videos. Works fine on desktop. For some reason the image provider is crapping out on the device hence the blank spots where the videos shoul be
[20:52] <popey> right
[20:52] <pmcgowan> bfiller, any particular format?
[20:52] <bfiller> popey: trying to figure out what is causing that
[20:52] <bfiller> pmcgowan: I tried a bunch of different ones
[20:52] <pmcgowan> bfiller, I know a number do not work, even in the scope
[20:52] <pmcgowan> bfiller, do they show up in scope?
[20:52] <popey> yes
[20:52] <bfiller> pmcgowan: the weird thing is they all show up correctly in the scope and play in the mediaplayer
[20:52] <pmcgowan> hmm
[20:52] <popey> and play fine
[20:52] <pmcgowan> got it
[20:53] <bfiller> seeing this error in the log: Failed to get image from provider: image://thumbnailer/home/phablet/Pictures/Tears_of_Steel-Trailer.mp4
[20:53] <bfiller> for all videos
[20:53] <bfiller> it's got to be a codec thing, or bug with libthumbnailer on the device
[20:54] <pmcgowan> but they are there for the scope, thats thumbnailer
[20:54] <bfiller> maybe a permission thing
[20:54] <pmcgowan> btw is that the design, to show all in /Videos?
[20:54] <bfiller> as gallery is confined
[20:54] <bfiller> it is now :)
[20:54] <pmcgowan> I thought we just wanted to show stuff the camera recorded, but I cannot recall exactly
[20:55] <pmcgowan> bfiller, you may need a new profile for apparmor
[20:55] <popey> i see no apparmor DENies in dmesg
[20:56] <bfiller> pmcgowan: for desktop mode we needed to make videos show up and play, so it's a carry over. We can disable I suppose for the device. The camera doesn't support video recording yet.
[20:57] <pmcgowan> bfiller, may want to, I thought there was something in the gallery design
[20:58] <bfiller> pmcgowan: kind of strange to only show videos recorded with the camera - we had a hack in there to only look for the file extension saved by camera recorder but that was not good
[20:58] <pmcgowan> bfiller, it kinda makes sense, as camera vids are short and you really want to play the in a component, whereas movies are fullscreen in the player
[20:59] <pmcgowan> not sure, need to check
[20:59] <bfiller> pmcgowan: that's how it used to work, we'd need a better way to check if the vid was recorded by the camera not using file extension
[21:00] <bfiller> pmcgowan: what about on desktop?
[21:00] <pmcgowan> bfiller, same thing?
[21:00] <pmcgowan> lets check the original docs
[21:01] <bfiller> pmcgowan: maybe, I like that it shows me all of my vids
[21:01] <bfiller> so I can use one app
[21:01] <thomi> fginther: doanac: When you gentlemen have a moment, I wonder if you could update me with the dashboard subunit conversion  work please? Perhaps drop me an email?
[21:01] <pmcgowan> bfiller, wfm
[21:01] <popey> balloons: does gallery ap tests not delete the gallery database first?
[21:02] <balloons> popey, I've never really played with them
[21:02] <balloons> popey, I can look one sec
[21:03] <popey> oooh!
[21:03] <popey> running AP it just played one of my videos!
[21:03] <bfiller> popey: it's kind of strange, supposed to make a backup
[21:03] <popey> that's gonna fail
[21:03] <bfiller> popey: but think it doesn't work right. if any tests fail I see the test vids in my gallery aftwards
[21:04] <balloons> popey, yep, looking at the code bfiller is correct. It makes a backup, assuming other stuff is there
[21:08] <popey> ./gallery-app: unrecognized option '--pick-mode'
[21:08] <popey> saw that mid-test
[21:08] <popey> gonna start again, screen went blank mid-test
[21:09] <popey> haha, rogue __init__.py in my ~/Pictures directory
[21:11] <bfiller> popey: fwiw, I ran all the AP tests on the gallery click that was built from same version one you are testing
[21:11] <popey> ok
[21:11] <bfiller> popey: it did work for me after seeing some weirdness
[21:12] <bfiller> popey: I first moved my Pictures dir out of the way and then retried
[21:12] <popey> its better after clearing out the database and pictures and videos
[21:19] <fginther> thomi, aye.  I'll need to get the latest from doanac who is out of the office until tomorrow.
[21:20] <thomi> fginther: ok, can you email me please?
[21:21] <fginther> thomi, yes
[21:21] <thomi> thanks!
[21:23] <bfiller> plars: I think there is a serious problem with phablet-test-run
[21:23] <plars> Oh?
[21:23] <bfiller> plars, thomi : all the tests are failing with an Invalid application id
[21:24] <bfiller> and when running it from my desktop it's accessing files in local directory
[21:24] <popey> balloons: bfiller gallery <IP_ADDRESS>4 approved into store
[21:24] <thomi> bfiller: which test suite?
[21:24] <plars> bfiller: boiko was having trouble reproducing though
[21:24] <bfiller> thomi: http://ci.ubuntu.com/smokeng/trusty/touch/mako/256:20140324:20140304/7337/messaging_app/
[21:25] <bfiller> plars: well it's failing for me in the same way when using phablet-test-run
[21:25] <thomi> bfiller: hey, not *all* the tests are failing :P
[21:25] <bfiller> :)
[21:26] <thomi> bfiller: I note that it's launching it as a normal app, rather than as a click or upstart app. Is that what it's supposed to do?
[21:27] <thomi> I kind of expected all the touch apps to be click/upstart at this point?
[21:27] <bfiller> thomi: they are not all clicks
[21:27] <bfiller> messaging-app is not a click
[21:27] <thomi> bfiller: oh ok.
[21:27] <bfiller> thomi: check out this log when running phablet-test-run from my desktop http://pastebin.ubuntu.com/7148342/
[21:28] <bfiller> thomi: note the files before the invalid application id message - all from my local disk -- weird
[21:29] <thomi> hmm, "Neil Young songbook" - you sir, have good taste in music :)
[21:29] <bfiller> plars: when running autopilot run directly on the device the screen goes black
[21:29] <bfiller> while the tests are running
[21:30] <thomi> bfiller: I'm not sure what the message even means TBH
[21:30] <plars> bfiller: we do some things to prevent that in our scripts
[21:30] <plars> bfiller: assuming you are talking about screen timeout/blanking?
[21:30] <thomi> bfiller: perhaps someone from kgunn's team would be able to help out?
[21:30] <bfiller> plars: right
[21:30] <plars> bfiller: if you want to run it the same way we do:
[21:30] <plars> bzr branch lp:ubuntu-test-cases/touch
[21:31] <plars> cd touch/scripts
[21:31] <plars> export NETWORK_FILE=<path/to/nm/conf>
[21:31] <plars> ./run-smoke -a messaging_app
[21:31] <plars> Note: this will reprovision with the latest image
[21:33] <ToyKeeper> Can anyone verify bug 1292420?  It seems like it might be important...
[21:34] <ToyKeeper> I'd imagine that we care about headsets being usable for calls.
[21:35] <kgunn> thomi: bfiller whats the question ?
[21:35] <thomi> kgunn: what does the "invalid application id" message in http://pastebin.ubuntu.com/7148342/ mean?
[21:36] <thomi> kgunn: and why does it show files from bfiller's disk in the log message?
[21:36] <bfiller> I'm going to go out on a limb here and guess the 15/16 failures are not problems with the messaging app. we couldn't have broken it that badly
[21:38] <kgunn> i got nada
[21:41] <kgunn> for the AP test run and screen timeout, gonna need to "powerd-cli display on bright" on the device (as root)
[21:42] <kgunn> current problem of new qt 5.2 won't deliver signals when rendering loop is halted
[21:42] <kgunn> (which we're looking into)
[21:42] <bfiller> boiko, plars: the tests fail for me whether I run autopilot locally on the device or through phablet-test-run
[21:43] <plars> bfiller: they fail for me too, I think boiko was having trouble recreating at one point though
[21:47] <Saviq> robru, does unity8 have a problem migrating to release pocket? it's been in proposed for an hour already?
[21:47] <robru> Saviq, hmmm, i was waiting for the autopkgtest to finish, although i just see now that it passed
[21:48] <Saviq> robru, ah, ok, not like we have autopkgtests :)
[21:48] <robru> cjwatson, poke about unity8, we seem stuck on arm64/etc again
[21:48] <Saviq> uh, so that needs manual poking every time? :|
[21:49] <robru> Saviq, shouldn't need it, but we're just in this somewat transitory state where there's three new arches the release team is trying to bootstrap
[21:49] <Saviq> robru, mhm, understood
[21:56] <boiko> plars: bfiller: found the reason for the failures, cooking a fix here
[22:03] <plars> Bioko++
[22:12] <Saviq> robru, is there any place to grab -dbgsym packages other than ddebs? apparently armhf .ddeb for the latest unity8 didn't reach ddebs yet :/
[22:12] <Saviq> http://ddebs.ubuntu.com/pool/universe/u/unity8/
[22:15]  * Saviq says that's weird, it's been built a good few hours ago
[22:16] <robru> dunno
[22:33] <cjwatson> robru: oh right, that
[22:33] <cjwatson> Saviq: unity8 is a very special case here :-/
[22:33] <robru> cjwatson, yay, save us ;-)
[22:33] <cjwatson> done for next run
[22:34] <cjwatson> Saviq: (unity8 triggers the unity-scope-click autopkgtest, fwiw)
[22:43] <robru> ogra_, cyphermox, rsalveti: ok, anybody around to kick a new image build? we just landed unity8 ;-)
[22:44] <rsalveti> robru: I can do it
[22:44] <rsalveti> building
[22:44] <robru> rsalveti, thanks!
[22:47] <cjwatson> robru: you need to wait for rmadison to say it's landed
[22:47] <cjwatson> robru: so this image build won't actually have the new unity8
[22:47] <cjwatson> robru: when the LP UI ticks over, that means the publisher run has *started*, not finished
[22:47] <cjwatson> robru: rmadison updates at the end of the publisher run
[22:47] <robru> cjwatson, oh, usually the difference between lp and rmadison is only a few minutes, and also the image build takes an hour to download all the packages somehow
[22:48] <cjwatson> robru: a release pocket update typically takes at least 15 minutes, and the image build updates its indices near the start
[22:48] <cjwatson> robru: so you are walking on very thin ice
[22:48] <robru> cjwatson, hummm, i'm always told that it's not safe to publish packages during image build, and the build takes an hour
[22:49] <cjwatson> robru: I have no idea what that first thing is a mangled version of, but it's not true
[22:49] <cjwatson> please wait until rmadison updates before requesting image builds
[22:49] <rsalveti> hm, I thought you were checking with rmadison as well
[22:49] <robru> cjwatson, rsalveti i was just looking at the spreadsheet, which gets updated from lp i guess
[22:49] <cjwatson> I expect so
[22:50] <imgbot> [22:50] <cjwatson> the only leeway you have at the start of the image build is that it runs debootstrap first
[22:50] <rsalveti> yup
[22:51] <Saviq> cjwatson, yea, noticed that (re: u8 autopkgtest)
[22:51] <cjwatson> please can we find out where this notion that it's unsafe to publish packages during an image build comes from, and exterminate it
[22:52] <Saviq> cjwatson, on that note, I was planning to add actual unity8 autopkgtests (qml ui test in xvfb), do I need to do anything beyond what's written down in the manual, bearing in mind this click-scope "override"?
[22:52] <cjwatson> there we go, you lost the race
[22:52] <cjwatson> Get:530 http://ftpmaster.internal/ubuntu/ trusty/universe unity8 armhf 7.84+14.04.20140319.1-0ubuntu1 [3849 kB]
[22:52] <cjwatson> Saviq: shouldn't, but it'd be a good idea to use adt-run (or whatever advice is in the wiki) to test things before uploading, of course :-)
[22:53] <robru> cjwatson, so, at some point I asked ogra "i need to publish some packages, but i don't want them to be in the current image build, when can I do it?" and he said "when you see the image here" or whatever, and showed me the URL where the builds get uploaded to, which would be the last possible point in the build process
[22:53] <Saviq> cjwatson, yeah, of course
[22:54] <robru> rsalveti, ok, can you cancel the image build and restart it in 10 mins?
[22:54] <cjwatson> robru: well, to start with, that's quite different from "how can I guarantee that packages I've published will be in the next build"
[22:54] <cjwatson> robru: it's not cancellable
[22:54] <cjwatson> you lose
[22:54] <cjwatson> you just have to wait
[22:54] <rsalveti> yeah, will trigger another one once this is done
[22:54] <robru> can we at least disable the smoke run since we know this image is garbage?
[22:55] <cjwatson> robru: in fact it's possible to publish packages rather earlier, as soon as the relevant download phase has finished; it's just hard to get that information externally (at the moment, anyway)
[22:55] <rsalveti> robru: plars should know
[22:55] <robru> plars, please disable the smoke run for image 257, it's gonna have an inconsistent set of packages and can't possibly be any good
[22:55] <Saviq> robru, thanks for pressing "clean & merge", btw
[22:55] <cjwatson> robru: the only "unsafety", though, is that the packages you've published might end up in a build; they won't be inconsistent
[22:55] <robru> Saviq, you're welcome!
[22:56] <cjwatson> or at least no more inconsistent than the release pocket is
[22:56] <robru> cjwatson, oh but you're wrong! i published silo 13 and now image 257 has only one of the two packages from that silo. so very inconsistent state here
[22:56] <cjwatson> this run is only inconsistent because dependencies weren't strict enough to ensure that everything landed in the release pocket together
[22:56] <cjwatson> that is nothing to do with image build vs. package publication races or anything like that
[22:57] <cjwatson> it has everything to do with lazy metadata
[22:57] <robru> cjwatson, zuh? i hit the publish button on a silo and now an image is building that only has part of that silo
[22:57] <cjwatson> publishing a silo does not guarantee that it all hits the release pocket together!
[22:57] <cjwatson> it is vitally important that you educate yourself about how this actually works
[22:58] <cjwatson> https://wiki.ubuntu.com/ProposedMigration
[22:58] <cjwatson> publishing a silo puts it in the *input* to that process
[22:58] <cjwatson> this has zero to do with image build atomicity with respect to the archive
[23:01] <cyphermox> robru: didn't didrocks mention there was a pending change in the seeds to watch out for, specifically re: scopes for unity8?
[23:01] <cjwatson> one day, maybe it might not be terrible to figure out how we can communicate constraints from the CI system to proposed-migration to ensure that silo contents are migrated atomically
[23:01] <cjwatson> but that's vapourware today
[23:02] <robru> cyphermox, yep, i took care of that. the seed was in silo 13 that i just published. the thing to watch out for was that all the other scope silos needed to land, which they did
[23:02] <cyphermox> robru: alright
[23:02] <cjwatson> the system assumes that if packagers think it's important for things to migrate together, then they bother to say so in dependencies :)
[23:02] <cyphermox> robru: ping me if there are any reviews to do, but I'll be coding on personal stuff tonight
[23:03] <cyphermox> cjwatson: yeah
[23:03] <robru> cyphermox, i think we're pretty good here... i'm winding down on landings
[23:03] <robru> cjwatson, right, it would make a lot of sense for silos to be treated atomically
[23:04] <cyphermox> cjwatson: would it work for the silo publishing code to also push versioned blocks for each of the binary packages in the silo, which can then be explicitly removed?
[23:04] <cjwatson> I don't think that's the right approach
[23:05] <cyphermox> ok
[23:05] <cjwatson> Too much busywork
[23:05] <cjwatson> It needs to communicate a constraint; there's no syntax for that today
[23:05] <cyphermox> no, there isn't
[23:05] <cjwatson> And we would need to think about how this works if e.g. there's a subsequent manual upload to the archive which is needed to get things past p-m
[23:06] <cjwatson> It's not an entirely trivial problem
[23:07] <cyphermox> I'm not saying it is, just mentioning an idea in passing
[23:07] <cjwatson> Right; the problem with versioned blocks would be that remembering to lift them would be error-prone
[23:07] <robru> rsalveti, got you silo 7
[23:07] <cyphermox> I'm quite good at bad first ideas :)
[23:07] <cjwatson> And would introduce non-trivial delays
[23:07] <rsalveti> robru: thanks
[23:07] <robru> rsalveti, you're welcome
[23:08] <cyphermox> cjwatson: ah, I was actually thinking about some automation for lifting them as well
[23:08] <cjwatson> Not to mention non-atomicity, because something might go wrong between checking that they're safe to lift and the next run which processes the unblock
[23:08] <cjwatson> So in fact I think that just kicks the can down the road and doesn't actually help
[23:08] <cyphermox> probably yeah
[23:09] <robru> rsalveti, so, cron kicks an image in ~4 hours, and I don't think I'll be landing anything before then... do you think it's safe to just let cron kick it, or should we kick another one right after 257 finishes?
[23:09] <cyphermox> rsalveti: hey
[23:09] <rsalveti> robru: wait for cron
[23:09] <cyphermox> got a public presentation of ubuntu touch by any chance?
[23:09] <robru> rsalveti, sounds good
[23:10] <rsalveti> cyphermox: hm, not yet :-)
[23:10] <rsalveti> cyphermox: what do you need?
[23:10] <cyphermox> rsalveti: a local LUG is asking me to do a presentation soonish
[23:10] <cyphermox> I'll fix up slides at some point
[23:11] <rsalveti> cyphermox: right, I need to do that soon as well, will present ubuntu-touch on elc-us
[23:11] <cjwatson> robru: so, sorry if I was harsh above, but I really think it's important for the landing team to understand how -proposed works and its interaction with image building, since in some sense these are more CI components.  if there's anything I can do to document/explain things better, let me know
[23:11] <cjwatson> and I get unhappy when voodoo rules are passed around :-)
[23:11] <rsalveti> cyphermox: only slides I got atm are those I gave you a few months ago
[23:11] <robru> cjwatson, it's ok, i only know what people tell me.
[23:12] <cyphermox> rsalveti: alright :)
[23:13] <cyphermox> cjwatson: I guess that's my failure there, I should have better mentioned checking for rmadison output
[23:20] <boiko> plars: https://code.launchpad.net/~boiko/messaging-app/fix_autopilot_tests/+merge/212526
[23:20] <boiko> plars: I will be submitting a similar fix for dialer_app too
[23:29] <plars> robru: how bad would it be? are these package issues that would just cause a lot of failures, or package issues that would make it to where someone needs to manually recover the device?
[23:30] <plars> unless it would put the device out of commission, it would be better to just let it run
[23:31] <robru> plars, uhhhh well we got a seed update in there, without the associated unity8 update that went with it. most likely any unity8 and scopes tests are gonna fail... i guess it won't be "unrecoverable" but it won't be usable
[23:33] <plars> robru: let's just let it run then, I can't easily tell it "just skip the next one". I could disable the runs, but then if we got another one after that it would be disabled. I would have to know when this one is coming and I'd have a 5 minute window to stop it before it really gets going
[23:33] <plars> robru: if there's another fixed one right after though, and I'm still up and you want me to stop it so we can start tests on the newer one sooner, just let me know
[23:33] <robru> plars, hmmmm ok
[23:34] <robru> plars, we decided to let the next fixed one just get kicked by cron, which is ~3.5 hours away now... that one should be fine
[23:35] <plars> sounds good
[23:39] <boiko> plars: and the one for dialer-app: https://code.launchpad.net/~boiko/dialer-app/fix_autopilot_tests/+merge/212527
[23:39] <boiko> plars: I managed to reproduce the bug, but still it would be nice if you could give this one a try just in case
[23:40] <robru> Saviq, oh, don't forget to rebuild unity8 in silo4 so that it includes all the new stuff we just published.
[23:55] <Saviq> robru, right


[20:32] <rpadovani> Hey guys :-) Do you know which license has the new framework for Canonical for Ubuntu website?
[20:32] <rpadovani> http://design.ubuntu.com/web-style-guide
[20:33] <rpadovani> My team and I want to do a theme based on this for our loco website, but we don't know if we can license it under gplv2
[20:33] <rpadovani> mhall119, o/ ^^
[21:00] <mhall119> rpadovani: I can ask on Monday, I don't see any specific license on it
[21:00] <rpadovani> mhall119, thanks, hope is be gpl or similar
[21:02] <mhall119> rpadovani: can you just link to the files on assets.ubuntu.com?
[21:02] <mhall119> that's a dedicated CDN
[21:02] <rpadovani> mhall119, yes, sure, we will use it, but we will do a derivative work (always using your CDN)


[17:13] <rick_h_> marcoceppi: ping, does that answer make sense. We've tried to split "problem #1: charm development" from problem #2 "distributing your charm" by keying off a central point that there comes a time in development when you want to share it and get testing.
[17:14] <rick_h_> marcoceppi: the doc picks up from that point solving "prloblem #2: charm distribution"
[17:15] <rick_h_> marcoceppi: I'm happy to help think o nthe first part, but as the recent email thread brought up, that starts to hit upon VCS choices, patterns, and really we want to draw the line on the charmstore that it's not VCS aware, that's the dev's world.
[17:15] <rick_h_> marcoceppi: much as google's/chrome store and such you publish to it, and can publish alphas/betas, but don't hack directly in via vcs
[17:53] <marcoceppi> rick_h_: google and chrome's  store are end user, we're dealing with developers and operations
[17:54] <marcoceppi> rick_h_: designing a store for end users and expecting dev and ops to use it will continue to create conflict
[17:54] <marcoceppi> rick_h_: I want to discuss this more, for sure, if not before Oct then at that sprint
[17:58] <rick_h_> marcoceppi: I understand. Please let me know anytime and happy to talk through. The team is going to work on parts of this sooner than the sprint, but we can agree to work on parts that are a bit generic like juju store get/xx and such.
[17:59] <marcoceppi> rick_h_: sure, we're sprinting atm, so we'll collect our thoughts and hopefully have a hangout early next week to chat about our impressions/needs for things and discuss where the store is going
[18:00] <rick_h_> marcoceppi: sounds good, thanks for making the time to give it a first pass
[18:00] <marcoceppi> rick_h_: thanks for getting publish as priority still
[18:01] <rick_h_> marcoceppi: rgr, some work has started. Uploading now picks up git/bzr rev info
[18:01] <rick_h_> marcoceppi: the team did some work in our sprint a couple of weeks ago but got held up that I'd not finished that spec up yet.
[18:01] <rick_h_> and moved to some other things for a little bit


[00:24] <bdmurray> bug 922884
[00:24] <ubot2`> Launchpad bug 922884 in ubiquity "installer crash - Error: `/etc/resolv.conf` and `/target/etc/resolv.conf` are the same file" [Undecided,Confirmed] https://launchpad.net/bugs/922884
[00:34] <bdmurray> there are a few duplicates of that coming in
[00:37] <cjwatson> I already uploaded a fix for that
[00:37] <cjwatson> bug 922640
[00:37] <ubot2`> Launchpad bug 922640 in ubiquity "Precise Pangolin Installer crashed on Sony Vaio VGN-SR39VN" [High,Fix released] https://launchpad.net/bugs/922640
[00:38] <cjwatson> duped
[13:15] <dhana013> Hi guys i am new to ubiquity installer
[13:16] <dhana013> I want customize ubiquity and help regarding ie., change slideshow image