[00:50] <robru> Saviq, was it you that mentioned the MP hover urls are hard to click in the dashboard? I changed it so the hover behavior only appears when there's no search term in use. If you search for something, all MPs unhide for easier clicking. http://people.canonical.com/~platform/citrain_dashboard/#?q=mir
[01:21] <robru> stgraber, hey, can you set up the lp project so that lp:queuebot points at the right place?
[01:23] <stgraber> robru: sure
[01:23] <robru> stgraber, also it looks like lp:~ubuntu-archive/queuebot/queuebot doesn't have the latest code that's in production? it seems like you pushed the revert but then didn't push the final code that went into production
[01:23] <robru> stgraber, thanks
[01:24] <stgraber> robru: should be all fixed now
[01:24] <balloons> bah popey you're asleep by now. i'll push fm
[01:24] <robru> stgraber, sweet, thanks. I'm about to make a small tweak to help future-proof it a bit
[01:27] <balloons> popey, mmm.. scratch that.. the version is 	com.ubuntu.filemanager_0.3.latest_armhf.click. I don't like that, not going to push it
[02:05] <imgbot> [02:09] <stgraber> I'm assuming that's some kind of test? :)
[02:10] <robru> yep ;-)
[02:10] <robru> testing my queuebot changes actually
[02:12] <robru> hehe, ok, looks good.
[02:18] <robru> stgraber, https://code.launchpad.net/~robru/queuebot/future-proofing/+merge/226948 when you get some time ;-)
[02:27] <stgraber> robru: yep, got the e-mail, will look at it tomorrow
[02:27] <robru> stgraber, cool, thanks
[02:37] <xnox> ogra_: popey: in the ubuntu/silo-003 there is new upstart. Can you please install upstart from it onto mako & flo and check that things generally work? e.g. try out a few auto-pilot tests, starting/killing apps, booting etc.
[02:37] <xnox> the testing has passed everywhere, so testing on normal flo and normal mako are the last things to try out.
[02:37] <xnox> i've tested on mako - dualboot install already.
[02:38] <xnox> plars: psivaa-off: if you can try out upstart from ubuntu/landing-003 on phones that would be great.
[02:57] <veebers> d'oh
[02:57]  * veebers fixes
[03:40] <imgbot> [03:40] <imgbot> [07:34] <kalikiana> robru: can you get this landed? https://code.launchpad.net/~pete-woods/u1db-qt/transaction-around-schema-init/+merge/226221
[07:48] <Mirv> kalikiana: I guess u1db-qt is a bit special case with rare landings and no designated lander. let's start by me adding a line for that, and putting you as the lander by name
[07:48] <Mirv> kalikiana: what kind of test plan there would be for u1db-qt?
[07:49] <kalikiana> Mirv: running the unit tests. there's no gui bit, any known bugs are added as unit tests
[07:50] <Mirv> kalikiana: it seems archive is not in sync with trunk, build failed
[07:50] <kalikiana> oh wow, it hasn't changed in a while, though
[07:50] <Mirv> fixing, just some small direct upload
[07:52] <Mirv> fixed, rebuilding
[07:52] <kalikiana> much appreciated!
[07:53] <Mirv> kalikiana: there are certainly some gui bits that use u1db-qt? manual testing of those would sound like a good idea, so that there wouldn't be surprises.
[07:54] <kalikiana> Mirv: oh apps yes, such as clock app
[07:54] <kalikiana> sorry for the confusion
[07:54] <Mirv> it seems there is no formal test plan for clock either :( (looking at https://wiki.ubuntu.com/Process/Merges/TestPlan/)
[07:54] <kalikiana> but it might be the  only one core app; not sure if community stuff can be used for testing
[07:55] <Mirv> ok. manual testing of clock app at least should be done, then.
[07:57]  * cjwatson yawns
[07:57] <kalikiana> (unity is also making use of u1db now but… not sure if I want to suggest that as a test case :-o)
[07:58] <cjwatson> So how's image 134 looking?
[07:58] <cjwatson> Oh, Selene wasn't too happy with it, hmm
[07:58] <Mirv> it looks bad, for whatever reasons
[07:59] <Mirv> 133 was almost normal
[07:59] <cjwatson> And only one free silo
[07:59] <Mirv> qtcreator plugin should probably migrate soon
[08:00] <cjwatson> Well, 9 will free up shortly, yeah
[08:00] <cjwatson> Was just checking that
[08:03] <Mirv> bzoltan1: ran it for you
[08:04] <bzoltan1> Mirv: thanks!
[08:10] <sil2100> What the heck happened with 134?!
[08:10] <sil2100> psivaa: do you have any idea what's going on with the smoketesting there?
[08:11] <psivaa> sil2100: yea.. looking at that. one flashing failed (adb wait-for-device dint comeback detecting the device)
[08:12] <psivaa> sil2100: the other is with dropping-letters tests. the step 'Selecting objects of type QQuickRectangle with attributes: {'objectName': 'gametilebox'} is repeating infinitely
[08:13] <ogra_> it got addicted and cant stop playing ;)
[08:13] <ogra_> sil2100, there is also the mail from ToyKeeper
[08:13] <sil2100> :|
[08:14] <sil2100> I give up :|
[08:14] <sil2100> ;)
[08:14] <ogra_> what she describes looks suspiciously like an oversight in https://launchpad.net/ubuntu/utopic/+source/unity-system-compositor/0.0.4+14.10.20140715-0ubuntu1
[08:14] <ogra_> iirc the dailer-app has "special access" to power mgmt
[08:19] <sil2100> I think we need someone looking at it ASAP
[08:20] <sil2100> It's like damn, can't we get an image that doesn't get stuff broken?
[08:20] <sil2100> When did we have that unity-system-compositor upload?
[08:20]  * sil2100 checks
[08:22] <sil2100> It was in 134
[08:22] <sil2100> So I would suppose we can still think of 133 as a promotion candidate, in case it's free of this regression
[08:22] <sil2100> ToyKeeper: hey! Are you still around? :)
[08:23] <cjwatson> Wasn't there a blocker in 133?
[08:23] <cjwatson> Tablet support?
[08:23] <sil2100> cjwatson: it got fixed in 133
[08:23] <cjwatson> Ah, right
[08:24] <sil2100> cjwatson: 133 had the fix for the tablets already, then 134 landed unity-system-compositor that 'might' be responsible, we need to check that and maybe revert/have someone working on it
[08:31] <sil2100> ogra_: I'll be there in a moment
[08:58] <cjwatson> Any objection to publishing 11?
[08:59] <popey> sil2100: https://bugs.launchpad.net/ubuntu/+source/telephony-service/+bug/1342602
[09:01] <sil2100> popey: thanks! :)
[09:01] <sil2100> ricmm: hey!
[09:02] <sil2100> ricmm: we noticed strange stuff happening on 134, we're thinking if your unity-system-compositor upload is not to blame
[09:03] <popey> sil2100: i can flash back to a previous image if you like, to see how far back it goes before phone calls work...
[09:03] <popey> if so, do you have a suggested image to start from?
[09:03] <brendand> sil2100, a lot of the failing suites seem to have an associated unity8 crash
[09:05] <sil2100> popey: could you maybe revert back one more image then?
[09:05] <sil2100> popey: like, to 132?
[09:06] <popey> ok
[09:06] <sil2100> We'll know then if telephony-service was at fault
[09:08] <cjwatson> sil2100: silo 11 isn't likely to interfere with this, is it?  it looks fairly innocuous aside from being a transition
[09:09] <cjwatson> And I'm sure it'd be nice to have one less big silo to conflict with
[09:11] <sil2100> cjwatson: hm, I'm always weary of big landings with many components, but I guess in this case it's just a lot of rebuilds against the new dbus-cpp, right?
[09:12] <cjwatson> Right
[09:12] <sil2100> cjwatson: the change in dbus-cpp itself doesn't seem to be super risky, just hope they rebuilt all rdeps
[09:12] <sil2100> cjwatson: I would say publish
[09:12] <psivaa> sil2100: brendand: i saw 'Selecting objects of type QQuickRectangle with attributes: {'objectName': 'gametilebox'}' being repeated in the dropping letters test on manta too..
[09:12] <psivaa> so this doesn't look like a one off one
[09:12] <sil2100> uh
[09:12] <cjwatson> Not really sure why because it only added ABI, it wasn't a soname change
[09:13] <cjwatson> But C++ :-P
[09:17] <popey> sil2100: #132 broken too
[09:17] <sil2100> What the...
[09:17] <sil2100> Ok, let me try getting a sim card for my phone maybe
[09:17] <sil2100> Since it obviously worked for Selene
[09:18] <cjwatson> wut
[09:18] <cjwatson> oh, arm64.  I think that test is flaky, will retry
[09:18] <popey> sil2100: going back further, to 127
[09:18] <sil2100> ogra_: I'll have to jump out for a train in some moments (and will not have connection for some time) - if Omer appears, could you ask him to check if 133 works connectivity-wise?
[09:18] <popey> sil2100: before urfkill was updated
[09:18] <cjwatson> mandel: I'll coordinate publishing of 11, will just take a little while
[09:19] <sil2100> cjwatson: thanks o/
[09:19] <sil2100> popey: good idea, thanks :)
[09:19] <mandel> cjwatson, you are my hero!
[09:20] <mandel> cjwatson, I need to take a look at those flaky tests, we cannot be dealing with them all the time
[09:20] <cjwatson> Yeah
[09:21] <mandel> cjwatson, lord.. it looks like conectivity api was not built.. again :-/
[09:21] <cjwatson> Right, I've retried and am waiting
[09:21] <mandel> cjwatson, ah, ok, I can see the following => https://ci-train.ubuntu.com/job/landing-011-1-build/120/console
[09:21] <mandel> cjwatson, looks like it was built, right?
[09:22] <cjwatson> I don't know why that didn't notice, but it's lying
[09:22]  * sil2100 goes for the train
[09:23] <cjwatson> https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-011/+build/6184387 is the previously-failed build in question, currently retrying
[09:24] <mandel> cjwatson, ack
[10:01] <ogra_> cjwatson, i think keeping access to proposed blocking vs image building distinct through different teams makes sense ... even if it is extra ovehead
[10:04] <popey> ogra_: any idea how to debug the modem issue on my device, until awe wakes?
[10:04] <cjwatson> ogra_: I'm fine with that, just needs Stéphane to mangle the tracker
[10:04] <popey> i reverted all the way back to #119 and it's still broken
[10:04] <ogra_> popey, check the urfkill states ...
[10:04] <popey> I suspect I broke the modem by flipping flight mode on/off too agressively
[10:04] <ogra_> (now dont ask me how, the package ships some scripts somewhere)
[10:04] <popey> k
[10:06] <ogra_> bah
[10:06] <popey> name: Fake Manufacturer Fake Modem Model
[10:06] <popey> that looks wrong
[10:06] <ogra_> just got my flo lightdm die
[10:16] <ogra_> boom ... and again
[10:17] <ogra_> doesnt look very stable :(
[10:17] <cjwatson> gar
[10:18] <cjwatson> anyone know why even a watch-only build (https://ci-train.ubuntu.com/job/landing-011-1-build/121/console) doesn't want to see connectivity-api in that silo?
[10:18] <cjwatson> the backend seems to have the right contents according to http://people.canonical.com/~platform/citrain/landing-011
[10:21] <xnox> ogra_: how about the new upstart on flo? =)
[10:21] <ogra_> xnox, well, with that crashyness i doubt i can tell much about the quality of upstart ... i can indeed check if it still boots
[10:21] <ogra_> (in case thats enough for you)
[10:22] <xnox> ogra_: that would be more than enough. E.g. boots and can open any click based app.
[10:22] <ogra_> ok
[10:25] <ogra_> rebooting ...
[10:25] <ogra_> session starts fine
[10:26] <ogra_> running dekko annd g* works fine too
[10:26] <ogra_> xnox, looks ok to me
[10:26] <ogra_> (G+)
[10:27] <xnox> ogra_: \o/
[10:27] <xnox> ogra_: do you have a mako as well?
[10:27] <ogra_> only a production one atm ... not writable
[10:27] <ogra_> probably popey has some time to test ... or om256er (once he is here)
[10:29] <popey> am debugging my phone issue here at the moment
[10:29] <popey> still can't get it working
[10:30] <ogra_> wow
[10:30] <ogra_> i can only run one app at a time it seems
[10:30] <popey> i dont know what I've done to break it.
[10:30] <ogra_> xnox, ^^
[10:30] <cjwatson> argh
[10:30] <ogra_> popey, try a wipe flash ?
[10:31] <popey> ☹
[10:31] <cjwatson> attempted a no-op reconfigure on 11 to unconfuse it, and now it thinks *none* of those packages are built, and a watch-only build does nothing, even though they're blatantly all in the PPA
[10:31] <cjwatson> can anyone dig me out of this hole?
[10:31] <popey> was avoiding wiping
[10:31]  * ogra_ cant ... i guess you need to wait for eil2100
[10:31] <popey> lose all my installed apps and data
[10:31] <ogra_> *sil
[10:32] <ogra_> popey, anything blocked in /var/lib/urfkill/saved-states ?
[10:33] <xnox> popey: ogra_: well i tested on my mako, but it's in writable & dual-boot install.
[10:33] <popey> http://paste.ubuntu.com/7802816/
[10:33] <ogra_> xnox, yeah, i dont think it is upstarts fault ... seems the backgrounded apps just die very fast ...
[10:33] <popey> what does that even mean? ☻
[10:33] <camako> o/
[10:33] <ogra_> popey, that you blocked GSM and BT
[10:33] <cjwatson> I also tried a watch-only build with an explicit package list, but that caused it to try to rebuild everything so I was all NOPE DO NOT WANT NOPE NOPE NOPE
[10:34] <popey> ogra_: how do I unblock?
[10:34] <camako> If I wanted to drop an MP from a silo, what is the process?
[10:34] <ogra_> popey, looks like a flight-mode flaw ... not sure if oyu can, but i would try to edit the file and reboot
[10:34]  * popey tries
[10:35] <ogra_> cjwatson, might be that the versions need to be bumped to have it pick them up
[10:35] <popey> uh, read only file
[10:35] <cjwatson> ogra_: bah, no, badness
[10:35] <ogra_> popey, shouldnt
[10:35] <cjwatson> ogra_: it's been tested, definitely don't want to rebuild
[10:35] <popey> "/var/lib/urfkill/saved-states" [readonly] 26 lines, 168 characters
[10:35] <ogra_> cjwatson, only guessing though
[10:35] <cjwatson> yeah, thanks but that's not an acceptable solution in my book
[10:36] <cjwatson> camako: sorry, this is a bit of citrain I'm fuzzy on - I *think* the answer is just reconfigure and build, but would rather wait for somebody more experienced
[10:36] <ogra_> popey,
[10:36] <ogra_> root@ubuntu-phablet:~# grep urfkill /etc/system-image/writable-paths
[10:36] <ogra_> # needed for urfkill persistance
[10:36] <ogra_> /var/lib/urfkill                         auto                    persistent  transition  none
[10:36] <ogra_> popey, it should be writable  ... :/
[10:36] <popey> on #119?
[10:36] <popey> -r--r--r-- 1 root root 168 Jul 16 10:25 saved-states
[10:36] <ogra_> root@ubuntu-phablet:~# mount|grep urfkill
[10:36] <ogra_> /dev/mmcblk0p30 on /var/lib/urfkill type ext4 (rw,relatime,discard,data=ordered)
[10:36] <popey> that's probably why then?
[10:37] <popey> i can touch files in that directory
[10:37] <ogra_> root@ubuntu-phablet:~# ls -l /var/lib/urfkill/saved-states
[10:37] <ogra_> -r--r--r-- 1 root root 152 Jul 16 12:25 /var/lib/urfkill/saved-states
[10:37] <popey> hmm
[10:37] <ogra_> hmm, i got the same
[10:37] <popey> can you edit it?
[10:37] <ogra_> no
[10:37] <camako> cjwatson, I guess, equivalent to getting a new silo... not surprisingly...
[10:37] <ogra_> let me see if it changes when i switch on flight mode
[10:38] <cjwatson> camako: well, no, shouldn't need to be that drastic
[10:38] <ogra_> popey, toggling flight mode toggles the content (al items have soft=true)
[10:38] <camako> cjwatson, so basically requires a reconfigure, rebuild, retest
[10:39] <ogra_> nt sure how it does that
[10:39] <cjwatson> camako: I would hope that it does not require rebuilding other packages in the silo, if there's more than one
[10:39] <cjwatson> Well, unless they build-depend on the changed package
[10:40] <popey> ogra_: i am on 19 now so i dont have flight mode button ☻
[10:40] <popey> *119
[10:40] <popey> will upgrade
[10:41] <ogra_> /usr/share/urfkill/scripts/flight-mode 1
[10:41] <ogra_> or
[10:41] <ogra_> /usr/share/urfkill/scripts/flight-mode 0
[10:41]  * cjwatson tries praying re silo 11 (i.e. asking didrocks for help)
[10:41] <ogra_> that should toggle it
[10:41] <ogra_> and fix the file
[10:41] <camako> cjwatson, ok that sounds a bit better than a new silo, thanks
[10:42] <cjwatson> camako: this is silo 18?  which MP do you want to drop?
[10:43] <camako> cjwatson, yes 18... But don't wanna drop at this time... Just in case it came to that, I wanted to know, how much the setback would be..
[10:55] <t1mp> who is working on qtubuntu and can confirm this bug? https://bugs.launchpad.net/ubuntu-app-launch/+bug/1329141
[10:57] <sil2100> popey: hey! How did the back-tracing go with the cellular issue?
[10:57] <sil2100> Oh, I don't see Omer around still
[10:58] <ogra_> he isnt ... and popey has urfkill issues
[11:01] <popey> flipping flight mode on and off makes no difference
[11:03] <sil2100> Strange, since last urfkill upload was 5 days ago, so it should have been broken for longer
[11:04] <ogra_> sil2100, i'm pretty sure it is an issue with upgraded systems only ...
[11:04] <ogra_> leaving some devices in a weird state
[11:05] <ogra_> popey, "no difference" as in the file contents did not change ?
[11:05] <popey> yeah, updated the bug
[11:05] <ogra_> are you still on 119 ?
[11:05] <popey> if i enable flight mode the file changes so everything is "true"
[11:05] <popey> no, moved to 134
[11:06] <popey> if i disable flight mode they all go false except WWAN and BLUETOOTH which stay true
[11:06] <ogra_> this is weird ... i fear we need cyphermox_
[11:06] <popey> ya
[11:13] <cjwatson> sil2100: Ah, you're around.  Can you help me with silo 11?  The publish step incorrectly didn't think connectivity-api was built, so after fiddling around a bit I tried a no-op reconfigure, but now it thinks nothing is built, and a watch-only rebuild doesn't find anything
[11:13] <cjwatson> sil2100: There must be a way to dig out of this without having to unnecessarily rebuild and retest everything?  The contents of the silo are good, I just need to convince citrain that they're all there
[11:18] <Mirv> cjwatson: maybe you'd need to run the prepare-silo job with reconfigure instead?
[11:19] <cjwatson> Is that different from running the reconfigure job?
[11:19] <Mirv> cjwatson: yes
[11:19] <cjwatson> OK - how do I run that job?
[11:19] <Mirv> reconfigure job is meant for landers, so that the can't do a "full" reconfigure
[11:20] <Mirv> cjwatson: https://ci-train.ubuntu.com/job/prepare-silo/ , in build insert the request_id from spreadsheet, series to utopic, and tick RECONFIGURE_SILO
[11:20] <Mirv> after that probably the watch_only build will succeed
[11:20] <sil2100> cjwatson: one moment
[11:21] <sil2100> Ah, right, Mirv might be right
[11:21] <cjwatson> OK, I'll give that a go ...
[11:21] <sil2100> But I'm afraid that the state of the silo might have been swiped
[11:21] <sil2100> Let's first try a full reconfigure though
[11:21] <cjwatson> I guess if all else fails I can copy the packages into -proposed manually
[11:22] <Mirv> so in this case it'd be 1404215234499
[11:22] <cjwatson> Trying
[11:22] <Mirv> cjwatson: ok, you'll need the same again but with ignore_conflicts
[11:23] <cjwatson> Yeah, just noticed
[11:23] <Mirv> because of dbus-cpp in landing-002. so, reconfigure_silo + ignore_conflicts
[11:23] <cjwatson> Half-expected
[11:24] <Mirv> ok, now a watch only build should probably work. (at least it often does in these problem cases)
[11:25] <cjwatson> https://ci-train.ubuntu.com/job/landing-011-1-build/125/console doesn't look right, sadly
[11:25] <Mirv> but nope it didn't...
[11:25] <cjwatson> I think I'll just copy manually to -proposed
[11:25] <cjwatson> Any objections?
[11:25] <Mirv> no objections if the packages are right, merge & clean can be run with ignore_step
[11:25] <cjwatson> Yeah
[11:26] <cjwatson> Merge and clean won't know which packages to merge, though, will it?
[11:26] <Mirv> sil2100: is it possible the so called "lesser" reconfigure actually requires a rebuild after using it?
[11:26] <Mirv> ah..
[11:26] <cjwatson> I suspect this is just that the project config file is wrong and if we could only write to it directly ...
[11:28] <ogra_> om26er, we are looking for someone who can compare ToyKeeper's issues (see the ML) with image 134 and check if 133 behaves properly
[11:28] <ogra_> s/compare/confirm/
[11:28] <om26er> ogra_, ok I'll flash to 133 and will see
[11:29] <Mirv> at worst we can to manual sync of the packages from archives and mark the branches as merged
[11:29] <Mirv> s/to/do/
[11:29] <cjwatson> Will somebody be able to help me with the manual merge if necessary?
[11:30] <Mirv> sure, I can or sil2100 can
[11:31] <sil2100> cjwatson: yeah, so the state files must have gotten all wrong, we can't really edit them manually though ;/
[11:31] <sil2100> cjwatson: the only way to do that is hacking through jenkins jobs and running commands from there, as we have no access to the citrain machine
[11:31] <sil2100> (it's in prodstack)
[11:32] <sil2100> cjwatson: let me take a quick look on what happened
[11:32] <cjwatson> sil2100: I have the copy-package command queued up - let me know when I'm safe to run it
[11:32] <sil2100> hmmm
[11:35] <camako> sil2100, finished testing landing-018 - tested well. Do we have any blockers before Mir 0.5.0 can land?
[11:36] <sil2100> camako: I would wait for us to get a promotable image, and there seem to be some regressions that we need to fend off first
[11:36] <sil2100> om26er: hi!
[11:36] <om26er> sil2100, ho ho
[11:36] <sil2100> om26er: how's the testing proceeding?
[11:36] <om26er> sil2100, I am downloading 133
[11:38] <sil2100> cjwatson: ok, so it seems that something went wrong and the reconfigure wiped the whole silo build state, sadly...
[11:39] <sil2100> cjwatson: I just hope that the packages are all up-to-date in the PPA?
[11:39] <cjwatson> Yeah
[11:39] <sil2100> cjwatson: i.e. no missing versions etc.?
[11:39] <cjwatson> So I'll just copy-package it and we'll merge
[11:40] <Mirv> ok
[11:40] <sil2100> If that's so then let's do that, it will be a dirty job but yeah, easiest
[11:40] <sil2100> We could, of course, just re-build those instead, but then probably some retesting would be needed or such
[11:40] <cjwatson> I've done worse things to the archive
[11:41] <sil2100> hah ;)
[11:41] <cjwatson> Yeah, I don't want to do unnecessary rebuilding if I can possibly help it
[11:41] <sil2100> Ok, need to change locations, will soon be back from a different place
[11:41] <Mirv> I'm happy to do the manual syncing plus merges
[11:42] <cjwatson> I've done the syncing; we'll see if m&c works by itself, otherwise I'll ask
[11:42] <Mirv> ok
[11:42] <cjwatson> I think most of the branches in question are already on ~ps-jenkins/<component>/utopic-proposed, but possibly not all
[11:44] <cjwatson> Everything except connectivity-api is there
[11:45] <cjwatson> Which is to be expected since that's the one for which the first publish attempt failed
[12:09] <om26er> ogra_, which email were you referring to ?
[12:10] <om26er> Landing team 10.07.14 or Landing team 15.07.14
[12:10] <ogra_> the last one she sent ... about the screen not turning on in 134 on incoming calls
[12:10] <ogra_> we see that there was a unity-system-compositor change that touched display wakeup stuff ... we want to nail it down to this package but for that we need to know if it works on 133
[12:10] <cjwatson> om26er: https://lists.launchpad.net/ubuntu-phone/msg09068.html
[12:30] <tvoss> cjwatson, hey there :) do we have debug symbols for silos available somewhere?
[12:31] <cjwatson> tvoss: They should be on ddebs.ubuntu.com
[12:33] <popey> cprov: do you know why filemanager on s-jenkins is using a screwy version number (other click packages use bzr build in the version number) see http://s-jenkins.ubuntu-ci:8080/job/filemanager-app-click/ versus http://s-jenkins.ubuntu-ci:8080/job/clock-app-click/ ?
[12:34] <cjwatson> tvoss: (if not there, then nowhere else)
[12:36] <tvoss> cjwatson, only archive version symbols available there
[12:38] <cjwatson> tvoss: -> pitti.  this should work, the PPAs seem to be configured properly
[12:39] <cjwatson> That is, their debug symbols configuration matches that for ~ubuntu-security-proposed/ppa, which should be a good reference here
[12:39] <tvoss> cjohnston, hah, apparently just got synced :)
[12:39] <ogra_> that will make cjohnston happy :P
[12:39] <tvoss> cjwatson, cancel that, queried policy for wrong package :/
[12:40] <cjwatson> tvoss: Please can you give me details?
[12:41] <cprov> popey: no, I don't, but I can figure out why
[12:42] <tvoss> cjwatson, so I've got the packages from silo 18 installed and would need the debug symbols for libmirclient8
[12:43] <tvoss> cjwatson, I followed https://wiki.ubuntu.com/DebuggingProgramCrash
[12:43] <tvoss> cjwatson, but apt-cache policy libmirclient8-dbgsym only shows the archive version
[12:45] <popey> cprov: thank you. I'd like to push a new file manager to the store, but can't with the wonky version number
[12:47]  * cjwatson checks whether he has his idea of the *_debug_symbols options backwards
[12:47] <om26er> ogra_, it only happens on 134
[12:48] <om26er> 133 does not have this issue
[12:48] <om26er> cjwatson, ^
[12:48] <ogra_> om26er, could you try to roll back unity-system-compositor to 0.0.4+14.10.20140703.1-0ubuntu1 ?
[12:48] <ogra_> and see if that fixes it
[12:48] <ogra_> heh
[12:48] <ogra_> om26er, could you try to roll back unity-system-compositor to 0.0.4+14.10.20140703.1-0ubuntu1 ?
[12:48] <ogra_> and see if that fixes it
[12:49] <om26er> ogra_, ok
[12:49] <ogra_> https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-003/+build/6153271
[12:49] <ogra_> there is the deb
[12:54] <om26er> ogra_, that helps
[12:54] <ogra_> om26er, thanks
[12:54] <ogra_> bah, no sil2100 ...
[12:55] <cjwatson> tvoss: It's in http://ddebs.ubuntu.com/pool/main/m/mir/, it's just not in the indexes
[12:56] <cjwatson> tvoss: (Because we don't publish indexes for things only in PPAs at the moment, apparently)
[12:57] <tvoss> cjwatson, ack, so that would be libmirclient8-dbgsym_1.0+1771-mirdevstaged~1771~ubuntu14.10.1_armhf.ddeb then?
[12:57] <cprov> popey: fginther pointed that the 'version' key was changed in manifest.json from "0.3.@BZR_REVNO@" to "0.3.latest" in revno 224 of filemanager.
[12:57] <tvoss> cjwatson, ah no: libmirclient8-dbgsym_0.5.0+14.10.20140715-0ubuntu1_armhf.ddeb seems to be the one
[12:57] <cjwatson> tvoss: I would have thought that libmirclient8-dbgsym_0.5.0+14.10.20140715-0ubuntu1_armhf.ddeb would be more appropriate
[12:57] <cjwatson> Yes
[12:57] <cprov> popey: you can take the opportunity and *fix* it too in your new upload.
[12:58] <cjwatson> tvoss: So you have to do apt by hand, I'm afraid, but looks like all the data is there for you
[12:58] <tvoss> cjohnston, yup, got it
[12:58] <popey> cprov: aha!
[12:59] <popey> cprov: thanks for looking
[12:59] <fginther> popey, cprov, I have an MP if you need one - https://code.launchpad.net/~fginther/ubuntu-filemanager-app/use-bzr-revno-in-version/+merge/227018
[12:59] <popey> check you out!
[12:59] <cprov> popey: fginther is the star on this ;-)
[13:00] <popey> indeed
[13:00] <popey> you can go now ㋛
[13:00]  * cprov leaves, heads down
[13:01] <popey> thanks cprov
[13:01] <cprov> no no, too late, I mean it! ;-)
[13:04] <ogra_> AlbertA, hey
[13:05] <AlbertA> ogra_: hi
[13:05] <ogra_> AlbertA, seems your last u-s-c upload causes some trouble https://lists.launchpad.net/ubuntu-phone/msg09068.html
[13:06] <ogra_> AlbertA, we just confirmed that rolling back to the former u-s-c fixes that behavior
[13:07] <AlbertA> ogra_: oh, I'll take a look
[13:07] <ogra_> thanks :)
[13:08] <cjwatson> Mirv: OK, the seven packages from silo 11 have all been migrated to the release pocket and are publishing.  M&C fails as predicted.  Could you please merge by hand?  For all but connectivity-api, the ~ps-jenkins/FOO/utopic-proposed branches are up to date and can just be pulled; you might have to be a little more creative for connectivity-api as I'm not sure if the silo branch is available anywhere.
[13:08] <popey> fginther: will jenkins merge that?
[13:09] <Mirv> cjwatson: ok, handling those
[13:09] <cjwatson> Thanks
[13:09] <cjwatson> Let me know when that's done and I'll forcibly clean
[13:13] <fginther> popey, lets try it. I top approved it
[13:13] <popey> thanks
[13:23] <popey> fginther: looks like it passed, but not merged.. https://code.launchpad.net/~fginther/ubuntu-filemanager-app/use-bzr-revno-in-version/+merge/227018
[13:24] <fginther> popey, the autolanding tests are still running
[13:25] <popey> I should get some patience ☻
[13:28] <Mirv> cjwatson: trunks updated, tagged and branches marked as merged
[13:28] <ogra_> sil2100, yo
[13:28] <sil2100> o/
[13:29] <sil2100> I'm home now, so stable connection all around
[13:29] <ogra_> sil2100, so om26er confirmed it is the u-s-c package that breaks incoming calls ...
[13:29] <sil2100> ogra_: excellent
[13:29] <sil2100> ricmm: ^
[13:29] <ogra_> sil2100, and AlbertA is already looking into it
[13:29] <sil2100> Ah
[13:29] <ogra_> if we cant get a fix today i would say we roll back
[13:29] <sil2100> ogra_: awesome, thanks - I would even consider a roll-back if we won't get a fix in ~1 hour
[13:29] <ogra_> to avoid TRAINCON-0
[13:30] <sil2100> Yeah
[13:30] <ogra_> well, ask AlbertA if he can fix it in 1h :)
[13:30] <ogra_> looking at the 134 smoketests it seems to affect a lot more than just dialer
[13:32] <cjwatson> Mirv: Great, thanks
[13:32] <sil2100> Right, just in case I would try looking at 133 as a promotion candidate, in case something else is broken
[13:32] <ricmm> ogra_: sil2100 we are looking into it
[13:32] <ricmm> will fix in under 1h
[13:32] <ogra_> cool
[13:32] <ogra_> !
[13:33]  * cjwatson cleans 11
[13:33] <sil2100> #133 looked 'okayish' from the smoketesting side, and if popey identified the problem being urfkill (which seems to be aorund since longer), I would say it should be good as well
[13:33] <stgraber> ogra_: give me a team name and I can update the tracker config
[13:33] <sil2100> Oh
[13:33] <sil2100> cjwatson, Mirv: thanks guys!
[13:33] <ogra_> stgraber, dunno, ubuntu-touch-isobuilders ?
[13:33] <sil2100> cjwatson: btw. I checked the citrain code and only small modifications will be needed to support ubuntu-rtm, I have them prepared here locally
[13:33] <cjwatson> ogra_: Probably needs to exist ;-)
[13:33] <cjwatson> sil2100: Oh, awesome, thanks
[13:34] <cjwatson> mandel: OK, so ignore that message, that's successfully landed
[13:34] <ogra_> cjwatson, oh, i thought he wanted to create it :)
[13:34] <cjwatson> sil2100: Oh, will there be a way to force the spreadsheet to regard this as landed?
[13:34] <cjwatson> We couldn't clean it normally so it regards it as given up
[13:34] <cjwatson> Or will, I think
[13:35] <sil2100> cjwatson: hm, so, just clean the silo and I'll fill in the missing gaps - I'll just have to fetch the list of versions that landed in the archive
[13:35] <sil2100> Since we keep track of those in the spreadsheet
[13:35] <ogra_> stgraber, https://launchpad.net/~ubuntu-touch-imagebuilders
[13:36] <ogra_> cjwatson, can you accept the invite i just sent to ubuntu-cdimage ?
[13:37] <cjwatson> ogra_: Why does ubuntu-cdimage need to be in this team?
[13:37] <ogra_> cjwatson, so cdimage members can build as well ?
[13:37] <cjwatson> Seems unnecessary
[13:37] <cjwatson> I'm pretty sure we have blanket perms
[13:37] <ogra_> oh
[13:37] <cjwatson> And anyway the test is usually ubuntu-release, which definitely does have blanket perms
[13:37] <ogra_> cjwatson, well, rsalveti is in cdimage
[13:37] <cjwatson> rsalveti should just be in this team directly
[13:38] <ogra_> cjwatson, and he didnt get any build buttons on the iso tracker yesterday
[13:38] <cjwatson> ok, maybe ubuntu-release
[13:38] <cjwatson> But adding ubuntu-cdimage to this team is the wrong thing anyway :)
[13:38] <ogra_> ok
[13:38] <ogra_> reject it then
[13:38] <cjwatson> ogra_: This should contain ubuntu-touch-release, though
[13:39] <cjwatson> Then stgraber only has to set a single team rather than two (which I think is impossible)
[13:39] <ogra_> invited
[13:39] <cjwatson> OK, I'll accept that one once the invite hits my mailbox, thanks
[13:40] <mandel> cjwatson, really!!! awesome!
[13:40] <ogra_> rsalveti, i made you and admin of https://launchpad.net/~ubuntu-touch-imagebuilders (so in case that potential bus hits me you can maintain it)
[13:41] <cjwatson> sil2100: OK, done, versions are in http://paste.ubuntu.com/7803504/
[13:41] <sil2100> Oh! Convinent :)
[13:41] <popey> gatox: fginther payui 0.2.9 failed again, differently. http://paste.ubuntu.com/7803506/
[13:41] <sil2100> cjwatson: and I just started gathering those manually - thanks!
[13:42] <cjwatson> I had it in my terminal history anyway ...
[13:43] <cjwatson> ogra_: OK, that's all set up now
[13:43] <cjwatson> stgraber: ^-
[13:43] <ogra_> cool
[13:45] <sil2100> cjwatson: ok, done, should be all good from the spreadsheet side
[13:45] <stgraber> cjwatson: we can easily have multiple teams for a single tracker role
[13:46] <fginther> popey, ack
[13:46] <ogra_> stgraber, well, now it is sorted on team level :)
[13:47] <stgraber> ogra_: acl updated
[13:47] <ogra_> thx
[13:47] <gatox> popey, it has always been unconfined... and it needs to be this way until we have trusted sessions... can you manually approve that?
[13:47] <ogra_> sil2100, robru, you guys should now be able to build images through the iso tracker
[13:47] <ogra_> rsalveti, ^^^
[13:47] <cjwatson> stgraber: ah, ok, still I think it's clearer if it's one
[13:48] <popey> gatox: no, its got the wrong security policy version
[13:48] <sil2100> ogra_: \o/
[13:49] <gatox> popey, which one should be?
[13:49] <popey> gatox: -dev2 means you need policy version 1.2
[13:49] <popey> as it says ☻
[13:49] <gatox> popey, ah ok
[13:50] <gatox> popey, fginther just sent a new click version to frances to fix this
[13:50] <gatox> s/frances/francis
[13:52] <fginther> gatox, "The uploaded version (0.2.9) is not newer than the current version (0.2.9)."
[13:52] <sil2100> ogra_: how can I find some 'button' to build an image on the iso tracker?
[13:52] <ogra_> sil2100, http://iso.qa.ubuntu.com/qatracker/milestones/315/builds
[13:53] <ogra_> uncheck all but touch on the left
[13:53] <gatox> fginther, there 0.3
[13:53] <ogra_> that should leave you with two entries and checkboxes next to them ... if you check these and scroll down there should be a "update rebuild status" button
[13:54]  * sil2100 bookmarks
[13:54] <sil2100> ogra_: thanks :)
[13:54] <fginther> gatox, it's uploaded and appears to be ready for review
[13:54] <gatox> fginther, thanks!!
[13:54] <gatox> fginther, popey, could you please let me know if it fails or succeed?
[13:55] <popey> sure
[13:55] <gatox> popey, thx
[13:55] <popey> gatox: fyi, you can run the exact same tests yourself, before uploading, to confirm yourself if it's okay ☻
[13:56] <popey> lp:click-reviewers-tools is all I run
[13:56] <gatox> popey, ack... didn't know that
[13:56] <popey> gatox: ok, thats better, only the unconfined error. jdstrand are we okay with payui being unconfined?
[13:57] <popey> (I assume so given what it does)
[13:57] <gatox> popey, that will change once we have trusted sessions
[13:57] <gatox> popey, but we need it for now
[14:01] <cjwatson> You shouldn't need to uncheck all but touch, should be unchecked when you load the page
[14:01] <cjwatson> Just check the one to the left of "Product (Ubuntu Touch)" and that automatically checks everything in that section
[14:02] <ogra_> i think i had to uncheck all products i dont want to see initially
[14:02] <cjwatson> They're definitely all unchecked when I load the page
[14:02] <ogra_> but i did that ages ago ... since then it stayed checked
[14:02] <ogra_> ah
[14:02] <ogra_> right, then you need to check the one you want :)
[14:04] <seb128> hum, the landing table refuses to load
[14:04] <seb128> too many requests, try again later
[14:05] <seb128> oh, works now, weird
[14:06] <sil2100> Yeah, happens sometimes...
[14:06] <kgunn> sil2100: quick one, i heard a rumor, tested landings arent landing ?
[14:06] <kgunn> kinda need mir to land to get other stuff up in silos
[14:07] <sil2100> kgunn: yeah, so as mentioned, we would like to have a promoted image before landing Mir - which is always a bit more risky that other smaller landings
[14:07] <sil2100> kgunn: currently our images are still broken due to some unity-system-compositor problems...
[14:08] <sil2100> kgunn: but I suppose we'll be able to land Mir today still, but later
[14:08] <sil2100> om26er: hey! Are you busy right now?
[14:08] <jdstrand> popey: payui was previously accepted in the store as unconfined. it needs to be based on a conversation I had with ted
[14:08] <sil2100> om26er: since we're anyway waiting for the fix to be finished, could you maybe take a look at #133 promotion-wise?
[14:09] <jdstrand> tedg: speaking of which-- can you explain how pay-service.hook works?
[14:09] <tedg> jdstrand, Right now it doesn't :-)
[14:09] <jdstrand> tedg: I know we talked briefly about it before, but the pattern is: ${home}/.local/share/applications/${id}.desktop
[14:10] <om26er> sil2100, ok, I can start after dinner. In 30mins if thats fine ?
[14:10] <tedg> jdstrand, It's a dummy right now, will be fixed as we land the trusted sessions branch.
[14:10] <jdstrand> tedg: which conveys to me that this hook will be run on all desktop files, along with the ual one
[14:10] <popey> jdstrand: ok
[14:11] <sil2100> om26er: ok
[14:11] <jdstrand> tedg: right, I see that the exec does nothing
[14:11] <jdstrand> tedg: I'm more thinking about what we are moving to
[14:11] <sil2100> I guess the new image will need around 2h anyway until it's ready, if anything
[14:11] <sil2100> So we can use the time to dogfood 133 in the meantime
[14:14] <jdstrand> tedg: basically, I need to add a check to the review tools to make sure that an app store app can't specify the pay-ui hook. currently, it seems that the click manifest just uses the "desktop" hook, then relies on the pay-ui hook to take care of it when it runs over all the desktop files on install
[14:15] <jdstrand> tedg: I'm guessing you were planning to shove a field into the .desktop file that the pay-ui hook would look for
[14:15] <jdstrand> tedg: is that the intent?
[14:17] <tedg> jdstrand, correct, so the pay-ui hook would point to the desktop file.
[14:18] <tedg> jdstrand, Then we'll execute that in pay-service
[14:18] <jdstrand> tedg: and what are you going to shove in to the desktop file?
[14:20] <tedg> jdstrand, Mostly just an Exec line
[14:20] <tedg> jdstrand, Or at least, that's all I expect to use in it.
[14:22] <jdstrand> tedg: I suppose I could examine the Exec line to see if it is using the pay-service, but I'm concerned that blacklisting in this matter is not future-proof (eg, if you change the name of the binary)
[14:22] <ricmm> sil2100: line 31 needs a silo for the USC fix
[14:22] <tedg> jdstrand, No, no. It doesn't use pay-service, pay-service calls that exec line.
[14:22] <sil2100> !
[14:23] <tedg> jdstrand, So it is probably qmlscene or something like that.
[14:23] <sil2100> cjwatson: assigning line 31
[14:23] <jdstrand> tedg: ok, let me ask this. if you were a malicious developer, what would you do to abuse this?
[14:23] <sil2100> ricmm: thanks, assigned 009
[14:24] <fginther> gatox, latest version is approved
[14:24] <gatox> fginther, great!
[14:25] <tedg> jdstrand, If I knew of a way, I would have fixed it :-) The biggest issue I could see is that we don't want more than on pay-ui on the system. So we don't want people to generally publish them.
[14:26] <jdstrand> tedg: well, that is what I mean
[14:26] <tedg> jdstrand, It's very constrained, we run it. It exits. We don't trust anything it does, we just ask the server if the pay completed.
[14:26] <jdstrand> tedg: I'm guessing if I'm malicious and I write a malicious pay-ui, then I could sniff stuff, no?
[14:27] <tedg> jdstrand, You'd only get the app-id and item-id of the item that the user wished to purchase when they go to purchase it.
[14:27] <cjwatson> sil2100: ah, sorry, was distracted
[14:27] <jdstrand> tedg: yet, you only want one pay-ui?
[14:28] <tedg> jdstrand, We don't want the user to have to choose. It puts another step in the payment process, which means "likely point to not buy something."
[14:28] <jdstrand> tedg: based on what you've described, I can't see how the click review tools could prevent someone from shipping an alternative pay-ui, because of how the desktop hook is being 'reused'
[14:28] <tedg> There's no security issue, just a UX issue, with having more than one.
[14:29] <jdstrand> s/hook/file/
[14:29] <tedg> jdstrand, Sorry, no, we don't expect there to be an application hook in an entry with pay-ui.
[14:29] <tedg> jdstrand, one or the other.
[14:30] <tedg> jdstrand, I think the review tools should, by default, reject anything that has a pay-ui hook.
[14:30] <jdstrand> tedg: but I can't. let me show you what I mean
[14:31] <jdstrand> tedg: http://paste.ubuntu.com/7803728/
[14:32] <jdstrand> tedg: the "payui" entry looks identical to a normal app
[14:32] <tedg> jdstrand, So, in the future (hopefully by the end of the week) the "desktop" there will change to "pay-ui"
[14:32] <jdstrand> tedg: a-ha!
[14:32] <jdstrand> tedg: that is what I was hoping for
[14:32] <tedg> jdstrand, So com.canonical.payui will not have a hooks.payui.desktop entry.
[14:33] <jdstrand> I can then easily block on use of that hook
[14:33] <jdstrand> tedg: ok, thanks, that is both illuminating and encouraging
[14:33] <Laney> does CI get run on WIP MPs or do I need to set it to Needs Review?
[14:33] <jdstrand> tedg: the hook will be "pay-ui"? I will just add it now
[14:34] <tedg> jdstrand, Yes, that'd be great!
[14:35] <tedg> jdstrand, Looking we don't have info about the click hook really in the arch: https://wiki.ubuntu.com/Pay/Architecture
[14:41] <brendand> sil2100, was anyone able to reproduce any of the failures from 133? i couldn't
[14:41] <sil2100> brendand: didn't hear that anyone could, om26er will dogfood the image in overall soon
[14:42] <sil2100> ricmm: should I press build for your silo?
[14:43] <jdstrand> tedg: to be totally clear. even though you will use a hook named "pay-ui" that I can filter on, a malicious dev won't be able to sneak in a pay-ui via the "desktop" hook? (ie, by putting a .desktop file in ~/.local/share/applications)?
[14:43] <tedg> jdstrand, No, they won't. We won't be calling UAL's application code, so there's no legacy fallback issues.
[14:44] <jhodapp> robru: can I get a silo for line 32?
[14:44] <cjwatson> jhodapp: I just assigned that
[14:44] <om26er> sil2100, on it now.
[14:44] <jhodapp> cjwatson: awesome thanks
[14:44] <cjwatson> jhodapp: (see the "Need CI Train help?" entry in the topic for the current sheriff)
[14:45] <jhodapp> cjwatson: k
[14:46] <jdstrand> tedg: so, if they use a "desktop" hook in their click app, and they specially format the .desktop file to hook in to pay-service, and that .desktop file gets put in ~/.local/share/applications (which it would, cause the click is pretending to be an application), that is not a problem?
[14:46] <jdstrand> tedg: the pay service isn't going to be looking in ~/.local/share/applications/*.desktop for stuff?
[14:46] <brendand> tedg, can you chip in to this review: https://code.launchpad.net/~canonical-platform-qa/url-dispatcher/fake_dispatcher/+merge/226829
[14:47] <cjwatson> BTW I made the primary archive publisher go about three minutes faster today for any of the cases where it was publishing the release pocket
[14:47] <tedg> jdstrand, Not at the end of the week. We move the hook into ~/.cache/pay-service/pay-ui/
[14:47] <jdstrand> tedg: ah, perfect. ok. thanks again
[14:47] <jdstrand> tedg: test added to click review tools :)
[14:47] <jdstrand> well, pending a merge review
[14:47] <cjwatson> In fact possibly just when publishing utopic at all
[14:48] <tedg> brendand, I don't think you can build-dep on your own binary package.
[14:48] <tedg> Or if you can, it's a bad idea :-)
[14:48] <cjwatson> No, you can't.  You should just use the binary from the build tree
[14:49] <cjwatson> Well you can but nobody will ever be able to bootstrap your package on new architectures and you'll get very peculiar results because you'll end up using the version from the previous upload
[14:49] <tedg> brendand, dbus-launch shouldn't be in the debian/rules file. Use dbus-test-runner in the tests that need it.
[14:50] <cjwatson> That test should probably set PATH so that it uses the built version
[14:50] <tedg> cjwatson, I believe all the architectures that will ever be invented already have been invented :-)
[14:50] <cjwatson> Although bear in mind that that will break cross-compilation
[14:50] <cjwatson> tedg: x32 is a plausible future port
[14:50] <cjwatson> No immediate plans or anything but it's a reasonable thing we might want to do
[14:51] <tedg> cjwatson, x32 ?
[14:51] <brendand> tedg, you mean just replace dbus-launch directly with dbus-test-runner?
[14:51] <cjwatson> It's like amd64 but without absolutely everything being 64 bits wide
[14:51] <cjwatson> So it's more efficient
[14:51] <cjwatson> Quite a lot for some workloads
[14:51] <tedg> Huh, interesting.
[14:52] <tedg> brendand, No, per test, not everything. If you have one dbus daemon for all the tests you can't really trust the results of individual tests.
[14:52] <cjwatson> You'd probably use it with amd64 as a partial architecture via multiarch, or similar, so you only have the can-use-more-than-4GB property where you actually need it, not for /bin/ls or whatever
[14:53] <cjwatson> I guess cross-building isn't an issue here because you turn off tests for that anyway, typically
[14:53] <brendand> tedg, i think the only way i can do that then is by not using nosetests and just running the suite directly with dbus-test-runner
[14:55] <tedg> brendand, No. You should add your tests to CTest, not run them in debian/rules
[14:57] <tedg> brendand, You can then also pass the path to the url-dispatcher tool on the command line as well.
[14:58] <brendand> tedg, CTest is not something i'm that familiar with - got any guidance for me?
[14:58] <brendand> tedg, i assume i should derive something from what's already in tests/CMakeLists.txt
[14:59] <tedg> brendand, Yeah, basically. There's lots of docs too: http://www.cmake.org/cmake/help/cmake2.6docs.html#command:add_test
[15:08] <jhodapp> cjwatson: silo 11 is ready to land
[15:08] <cjwatson> jhodapp: you've tested it on a device?  that was quick
[15:08] <jhodapp> cjwatson: yes
[15:08] <cjwatson> jhodapp: if you've tested, please mark it as such in the spreadsheet
[15:09] <jhodapp> cjwatson: I did
[15:09] <cjwatson> jhodapp: then we get told about it automatically
[15:09] <cjwatson> jhodapp: ah, it's just lagging then
[15:09] <jhodapp> cjwatson: ok...it's a very tiny change...very quick to test
[15:09] <cjwatson> it'll catch up shortly
[15:09] <jhodapp> thanks
[15:13] <jhodapp> cjwatson: what does this message mean? ^
[15:13] <cjwatson> jhodapp: "please wait"
[15:14] <jhodapp> cjwatson: lol, ok :)
[15:14] <cjwatson> it basically just means that it's queued the copy to the primary archive but it hasn't actually been performed yet
[15:15] <cjwatson> it'll get there
[15:15] <jhodapp> cjwatson: so it's just being verbose
[15:15] <cjwatson> pretty much.  it would be a problem if it stayed in that state for too long
[15:15] <jhodapp> ok
[15:15] <cjwatson> but it's not going to since the copy's been done
[15:21] <sil2100> om26er: how's the dogfooding proceeding?
[15:21] <om26er> sil2100, so far so good, I have updated the doc. I had a crash in unity8 which I am trying to report
[15:22] <om26er> also the alarm does not turn on the screen. I am not sure if thats new
[15:23] <popey> fginther: uh, this didn't work out http://s-jenkins.ubuntu-ci:8080/job/filemanager-app-click/ - com.ubuntu.filemanager_0.3.@BZR_REVNO@_armhf.click
[15:23] <fginther> popey, crap
[15:23] <popey> ☻
[15:24] <fginther> popey, I probably missed reverting another change, let me poke
[15:24] <popey> thanks
[15:24] <ogra_> sil2100, it seems hangouts are broken for many people ... not sure we can do our meeting today
[15:24] <sil2100> ugh
[15:25] <sil2100> ogra_: well, in case it's badly broken, let's just do a quick update through IRC then
[15:25] <ogra_> right, just a warning since i cant join my daily team standup ... and mandel seems to have the same issue
[15:25] <ogra_> (and we are the only euro people there)
[15:26] <om26er> sil2100, https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1342784
[15:26] <om26er> the stacktrace mostly looks useless
[15:26] <sil2100> om26er: does this crash happen often?
[15:26] <om26er> sil2100, no, only once.
[15:27] <ogra_> om26er, alarm never turned on the screen ... i would expect there is a bug open from popey or davmor2
[15:27] <popey> ogra_: been that way forever
[15:27] <ogra_> popey, yes
[15:27] <ogra_> but do we have a bug ? :)
[15:28] <AlbertA> ogra_: the USC fix is in landing-009, can you check the incoming calls wake the screen?
[15:28] <brendand> tedg, how to get better output from make test? my test is failing but i've no idea why
[15:28] <popey> well, no, its a work item which I believe others have.. rsalveti ?
[15:29] <ogra_> AlbertA, i dont have a test device, om26er or popey shoudl be able to
[15:29] <Saviq> rsalveti, hmm hmm, is snapshot functionality working for ubuntu-emulator?
[15:29] <rsalveti> popey: for alarms charles is implementing that
[15:29] <om26er> AlbertA, I can, let me first upgrade to 134
[15:29] <rsalveti> Saviq: afaik yes, sergiusens would know better
[15:29] <rsalveti> Saviq: what is the issue?
[15:29] <popey> rsalveti: thats right, charles...
[15:29] <brendand> tedg, ah i guess it must be because the directory with the code i want to test is not copied into the build directory
[15:30] <Saviq> rsalveti, doesn't work ;)
[15:30] <sergiusens> I never use it and it hasn't changed
[15:30] <Saviq> rsalveti, well, for one I can't see a way to list snapshots
[15:30] <tedg> brendand, Yes, paths. There's a LastTest file that CMake writes out with the stdout for it.
[15:30] <Saviq> for two I go `ubuntu-emulator snapshot --revert-pristine` and nothing happens
[15:30] <Saviq> nor for `ubuntu-emulator snapshot --create=blah` and subsequent --revert=blah
[15:31] <sergiusens> Saviq: the emulator is running when you do this?
[15:31] <Saviq> sergiusens, no
[15:31] <sergiusens> Saviq: can you ubuntu-bug ubuntu-emulator ... I'll take a look
[15:31] <Saviq> sergiusens, k will do
[15:31] <sergiusens> just assign to me
[15:32] <rsalveti> yeah, not working here either
[15:32] <rsalveti> and list would indeed help :-)
[15:32] <sergiusens> rsalveti: I recall it once upon a time worked; not sure what changed
[15:32] <brendand> tedg, how do i include a directory - add_subdirectory?
[15:32] <sergiusens> that code has been there forever
[15:32] <Saviq> sergiusens, rsalveti, while I have you, is it expected that creating a i386 emulator is so IO heavy? my machine grinds to a halt when doing that, and it takes like 10 minutes
[15:33] <Saviq> (btrfs here if it matters)
[15:33] <rsalveti> yeah, same here, using --use-raw-disk helps a bit it seems
[15:33] <Saviq> oh check that bug #1320307
[15:33] <sil2100> om26er: how do you think does 133 look like in overall in your opinion? Is it worthy of promotion?
[15:33] <rsalveti> because it converts the image as well
[15:33] <sergiusens> Saviq: yeah, I want to look into that as well
[15:34] <sergiusens> would want raw disks by default
[15:34] <sergiusens> and i386
[15:34] <sergiusens> and autoscale
[15:34] <tedg> brendand, Yup, http://cmake.org/cmake/help/cmake2.6docs.html#command:add_subdirectory
[15:34] <Saviq> sergiusens, can't assign you to the above bug, but sounds like what I have
[15:35] <brendand> :wq
[15:35] <brendand> what? my irc client didn't close :P
[15:35] <om26er> sil2100, the image looks good but I would prefer if someone else gave it a spin as well.
[15:35] <rsalveti> sergiusens: sounds good
[15:35] <Saviq> sergiusens, bug #1342792 too
[15:35] <sergiusens> Saviq: assigned; no idea why it didn't hit my inbox
[15:36] <cjwatson> ricmm: How's silo 9 looking?
[15:36] <AlbertA> cjwatson: I'm about to test
[15:36] <cjwatson> Cool
[15:36] <sil2100> popey: hey! Were you able to resolve your connectivity issues in 133?
[15:36] <popey> yes
[15:37] <elopio> ping Ursinha: can you give us an ETA for this? https://bugs.launchpad.net/ubuntu-ci-services-itself/+bug/1334767
[15:37] <Ursinha> elopio: I've seen the latest comments, I'll have a look today.
[15:39] <elopio> Ursinha: thanks. Please set the bug as triaged and assign an importance. And it would be great if you can leave a comment with an ETA.
[15:40] <Ursinha> elopio: sure, once I get enough context to estimate that I'll triage and comment accordingly
[15:40] <elopio> ack.
[15:43] <sil2100> popey: did you have a moment to briefly use 133 by any chance? ;)
[15:47] <Saviq> sergiusens, bug #1342795 too
[15:48] <brendand> tedg, how do you get the file in the directory to be copied into the build directory?
[15:48] <tedg> brendand, By installing it: http://cmake.org/cmake/help/cmake2.6docs.html#command:install
[15:48] <rsalveti> ogra_: thanks (for the image builder groups setup and permission fixes)
[15:49] <ogra_> rsalveti, i hope it works now
[15:50] <rsalveti> ogra_: lovely, I can see the checkbox now
[15:50] <ogra_> yay !
[15:52] <charles> popey, screen wakeup + inhibiting sleep while alarms are going off is 2nd on my TODO after indicator-power's low battery notifications, so should happen this week
[15:55] <om26er> AlbertA, that fixes the issue.
[15:55] <ogra_> land it !
[15:55] <popey> charles: great!
[15:56] <AlbertA> so same here, I tested calls and texts
[15:56] <ogra_> cool
[15:56] <AlbertA> powerd-cli dispay on works
[15:56] <AlbertA> everything seems good in n4
[15:56] <ogra_> yeah ... you wont get calls on N7 or N10 :)
[15:57] <cjwatson> great, marking as tested and will publish
[15:57] <ogra_> \o/
[15:57] <sil2100> o/
[15:57] <sil2100> SHIP IT
[15:58] <fginther> popey, I think I have the revno problem fixed. I did a test build here: http://s-jenkins.ubuntu-ci:8080/view/click/job/generic-click-builder-trusty-armhf/140/ and installed the click. on my phone 'click info com.ubuntu.filemanager' produced: http://paste.ubuntu.com/7804078/
[15:58] <ricmm> pushed it
[15:58] <cjwatson> how late can we get dogfooding?  would be nice to get a promotion tonight
[15:59] <ogra_> cjwatson, we as i understood 133 was already approved ...
[15:59] <fginther> popey, gahh!, let me try again with the utopic chroot, just in case
[15:59] <ogra_> (but i guess the answer depends on om26er )
[15:59] <cjwatson> ah, well, hopefully
[16:00] <sil2100> cjwatson: so, om26er said it's ok to him, but wanted someone else to +1 as well
[16:00] <sil2100> So I would say let's give 133 a try
[16:02] <fginther> popey, if it builds successfully, here's the MP: https://code.launchpad.net/~fginther/ubuntu-filemanager-app/use-bzr-revno-in-version/+merge/227055
[16:02] <elopio> sil2100: are we having a landing meeting today?
[16:03] <ogra_> elopio, already running
[16:03] <elopio> the hangout says to me: This party is over.
[16:03] <ogra_> https://plus.google.com/hangouts/_/canonical.com/landing-meeting
[16:03] <elopio> ogra_: that's the one I'm trying.
[16:03] <ogra_> i had massive issue with hangouts for the last hour
[16:04] <ogra_> just sorted itself
[16:04] <ogra_> but it didnt talk about the party being over, i got a proper error
[16:05] <cjwatson> seb128: ^- sorry for the delay, I didn't notice queuebot's comment earlier
[16:08] <seb128> cjwatson, thanks, no worry
[16:18] <elopio> plars: can I please get a silo to land a new version of the mediaplayer tests?
[16:19] <plars> elopio: I think you'll need to talk to trainguards about that
[16:20] <robru> elopio, add your request in the spreadsheet
[16:20] <elopio> plars: and who's that?
[16:20] <elopio> robru: ok.
[16:22] <jhodapp> cjwatson: should I merge and clean my silo or do you/team do that?
[16:22] <balloons> fginther, in regards to https://code.launchpad.net/~fginther/ubuntu-test-cases/add-reminders/+merge/226281, is it possible to have the tests run with adt-run?
[16:22] <robru> jhodapp, you can do it
[16:22] <jhodapp> robru: ok
[16:23] <cjwatson> jhodapp: I'll do it
[16:23] <jhodapp> ok great
[16:24] <cjwatson> I mean, you can in general, but you don't need to
[16:24] <cjwatson> running now
[16:24] <cjwatson> elopio: yeah, put in in the spreadsheet, put "Yes" in the "Ready?" column, and we'll be notified
[16:24] <jhodapp> cjwatson: that was my question...thanks
[16:24] <elopio> robru: I don't have permissions.
[16:25] <elopio> I can't add a line to the pending tab.
[16:26] <cjwatson> elopio: one sec, will give you edit permissions
[16:26] <elopio> cjwatson: thanks.
[16:27] <cjwatson> elopio: (you should have that now)
[16:30] <elopio> cjwatson: yes, it works now.
[16:30] <elopio> the MP guidelines are the project's checklist, or are there some special guidelines for CI train?
[16:32] <robru> elopio, in this case the guidelines mostly just means "did you make sure to actually put the MP urls and not the branch URLs, which don't work"
[16:33] <elopio> got it.
[16:34] <elopio> ah, crap, there will be one conflict getting all the branches to trunk.
[16:34] <elopio> brendand: can you please use barry's branch as a prerequisite for yours and merge with it?
[16:35] <brendand> elopio, for mediaplayer-app?
[16:35] <elopio> brendand: yup.
[16:35] <brendand> elopio, you want me to actually merge it to mine?
[16:35] <elopio> brendand: merge it to yours and solve the conflict.
[16:35] <elopio> that way all the three branches can merge cleanly to trunk.
[16:36] <brendand> elopio, where's barry's branch?
[16:36] <elopio> brendand: https://code.launchpad.net/~barry/mediaplayer-app/py3autopilo
[16:36] <elopio> wait, I missed a t
[16:36] <elopio> lp:~barry/mediaplayer-app/py3autopilot
[16:40] <brendand> elopio, are you sure that was right? now i have conflicts with trunk
[16:45] <elopio> brendand: I think so. If mine is a prerequisite for barry's, and barry's is a prerequisite of yours, then they will no longer conflict with each other.
[16:46] <brendand> elopio, i could resolve the conflicts by merging from trunk, not sure if that's the right thing to do here though
[16:48] <elopio> brendand: I can merge yours with barry's. And then merge yours with trunk without issues.
[16:48] <popey> sil2100: #133 is good to promote, confirming what om26er said
[16:48] <sil2100> popey: YAY
[16:48] <om26er> \o/
[16:48] <sil2100> popey, om26er: thanks guys!
[16:48] <popey> np
[16:48] <sil2100> ogra_: prrrromote #133 o/
[16:49] <ogra_> rrrroooaaarrr
[16:49] <ogra_> running ....
[16:49] <fginther> balloons, I'm investigating exactly that
[16:49] <brendand> elopio, you can see the conflicts there in the merge proposal
[16:50] <balloons> fginther, ok excellent. I'm working to land the branch to add support for reminders to run this way. If it can run in CI using adt-run, I think we should be good to land it
[16:50] <ogra_> [16:51] <fginther> balloons, it might be the only app to run this way initial. We ultimately need to make sure we have the same artifacts etc. otherwise a switch could introduce regressions in the data presented on the dashboard
[16:51] <fginther> balloons, s/only app/only this app/
[16:51] <elopio> brendand: would they go again if you change the prerequisite on the MP?
[16:52] <brendand> elopio, oh maybe
[16:53] <brendand> elopio, yes!
[16:53] <elopio> phew.
[16:53] <elopio> this process is complex.
[16:53] <cjwatson> sil2100: yay
[16:54] <brendand> elopio, anything else. i need to eod now?
[16:54] <popey> fginther: https://code.launchpad.net/~fginther/ubuntu-filemanager-app/use-bzr-revno-in-version/+merge/227055 looks good
[16:54] <sil2100> cjwatson: ok, so I'll have to make a few more tests regarding the new distro support in ci-train, as it seems I had to do a bit more changes for it to work
[16:54] <elopio> brendand: I'm not sure. But enjoy your rest, I think that if there are problems, we can fix them on the other two branches.
[16:54] <elopio> thanks.
[16:54] <sil2100> cjwatson: especially that testing this locally usually involves some hackeries
[16:54] <robru> xnox, elopio: why does QA need to signoff for upstart in silo 3? we're not in traincon
[16:54] <sil2100> cjwatson: but I think I've got almost everything ready
[16:55] <cjwatson> sil2100: right, I'll probably be spending the rest of the week on the other client side of this, but fantastic, really appreciate the help.  William thinks we should be able to do a dogfooding run next week
[16:55] <elopio> robru: I don't know.
[16:55] <fginther> popey, ack, the second build also worked, top-approving
[16:55] <cjwatson> sil2100: (so I gather from the CI team's weekly report)
[16:55] <xnox> robru: elopio: because I requested it =) I would like to request for CI infrastructure itself to be validate for the upstart update.
[16:55] <sil2100> cjwatson: excellent, that would be useful for me as well then
[16:55] <robru> xnox, you want a round of smoketesting on that silo before publishing?
[16:56] <xnox> robru: elopio: such that operational issues are not hit, like e.g. we had previously when lxc output was changed.
[16:56] <xnox> robru: yeah, something that runs / deployes phones and runs autopilot tests on it the way ci.ubuntu.com does & general tools used in testing to be excercised against it.
[16:57] <robru> plars, are you able to trigger a round of smokeng with silo 3 enabled? without publishing it into a built image first?
[16:57] <xnox> robru: it's entirely in the hands of the CI/Landing to define what smoketesting / validation you want to run.
[16:57] <elopio> barry: a new version landed to the mediaplayer trunk and it changes the debian changelog. After merging your branch with trunk, your log comment is no longer at the top
[16:57] <xnox> robru: from my point of view as a lander, it's ready to go into the archive, but I don't know all the implications of the ci.ubuntu.com there might be.
[16:58] <elopio> barry: so, you should merge with trunk, right?
[16:58] <elopio> barry: or should I do it on my branch, and you should merge again with mine?
[16:58] <elopio> it's hard to get everything to trunk at once.
[16:59] <plars> robru: not really
[16:59] <plars> robru: what's in silo 3?
[16:59] <xnox> robru: elopio: so please "verify that it doesn't break the test infrastructure" =)
[16:59] <robru> plars, upstart, but read the scrollback with xnox here ^^, he wants us to test it to make sure it doesn't break ci
[17:00] <cjwatson> bfiller: heads-up re bug 1342840; would be great if somebody could have a look at that pretty soon
[17:00] <cjwatson> slightly misleading title, just reworded it
[17:00] <plars> robru: I could probably manually hack something together and run locally
[17:00] <plars> not sure we have an easy way to do that.. I can look though.
[17:01] <balloons> popey, so we should be able to push fm after that mp
[17:01] <xnox> plars: silo 3 has new upstream release of upstart, which affects all products and e.g. adds new command line options to initctl. It is backwards compatible, but a lot has changed it in, and many corner details are slightly different now.
[17:02] <popey> balloons: super
[17:02] <popey> be good to get it in the next image
[17:03] <robru> plars, I'll try to poke at it locally as well but yeah, if we could ensure that releasing it doesn't break the world that'd be nice
[17:03] <plars> Yep
[17:07] <barry> elopio: whatever is easiest for you.
[17:09] <ogra_> sil2100, hmm
[17:09] <sil2100> ogra_: uh?
[17:09] <sil2100> ogra_: what's up?
[17:09] <ogra_> sil2100, 133 doesnt look so good here ... 90sec after upgrade and reboot i still see the google logo
[17:09] <slangasek> plars: hi, so wrt xnox's comment above - we'd like to make sure that this upstart update is not going to regress the test infrastructure itself.  We're satisfied with the manual testing that it's not breaking anything for production use, but given past experience with lxc we would also like to make sure the test infrastructure itself copes with it
[17:09] <sil2100> ogra_: on flo?
[17:09] <ogra_> on my production mako
[17:09] <sil2100> oh
[17:09] <sil2100> hmmm
[17:10] <elopio> barry: so I merged mine with trunk. Please merge yours with mine and check that your changelog is on the top.
[17:10] <slangasek> plars: do you think such testing is necessary before we land it, and do you have a notion of how such testing should be done?
[17:10]  * ogra_ twiddles thumbs glaring at the google logo
[17:11] <ogra_> and another minute passes
[17:11] <plars> slangasek: ah, the lxc stuff is entirely different from the smoke tests that run on the devices. I thought you were concerned it would break the smoke tests
[17:12] <barry> elopio: merged and pushed
[17:12] <ogra_> sil2100, ok, now it moved ... looks like apparmor took really long :/
[17:12] <plars> As I see it, from the smoke tests, we just run the autopilot tests with phablet-test-run
[17:12] <slangasek> plars: well, we're concerned about making sure there's no testing-specific breakage
[17:12] <elopio> barry: thanks.
[17:12] <elopio> So I think we are ready.
[17:12] <sil2100> ogra_: phew... well, I would be more worried if it wouldn't move at all
[17:12] <slangasek> plars: I don't have a feel for what's most likely to break, since we think *nothing* should break :)
[17:13] <plars> So if that works, we should be ok
[17:13] <ogra_> sil2100, yeah, all find now, but its a pretty bad user experience
[17:13] <ogra_> *fine
[17:14] <sil2100> popey, om26er: did you notice the same thing while dogfooding? ^
[17:14] <ogra_> sil2100, i doubt they upgraded and i doubt they have any non-preinstalled click packages on their dogfood devices
[17:15] <ogra_> i think it is the ~50 apps i have installed that made apparmor take s long
[17:15] <ogra_> s/s/so/
[17:15] <popey> sil2100: what thing?
[17:15] <ogra_> popey, i had the google logo after upgrade for about 4min on screen
[17:15] <ogra_> before the boot actually moved on
[17:16] <om26er> sil2100, I flashed clean, didn't had that issue.
[17:16] <popey> ok, not updated my devel phone yet, will do that now and time it
[17:17] <ogra_> i think its the amount of clicks i have installed ... though it definitely didnt take that long the last upgrades
[17:18] <ogra_> and i didnt install any new packages
[17:18] <popey> 18:18, clicked install
[17:18] <popey> google logo
[17:18] <popey> ubuntu spinny logo
[17:18] <ogra_> yeah, not what i had here
[17:19] <ogra_> 4min google logo ... when i attached via adb after that time i could briefly see apparmor run ... then it switched to the spinner
[17:19] <popey> oh, mine is in recovery at the moment
[17:19] <ogra_> oh
[17:19] <ogra_> heh
[17:19] <popey> doing the unxz
[17:19] <ogra_> we have to many spinning logos :P
[17:19] <popey> hah
[17:20] <popey> rebooting
[17:20] <popey> google logo
[17:20] <ogra_> my unpack took also significantly longer
[17:20] <popey> yeah, i have some apparmor stuff going
[17:20] <ogra_> did you come from 113 ?
[17:20] <popey> an upowerd at 100% cpu
[17:20] <popey> whatever last devel was
[17:20] <popey> 119 iirc
[17:21] <ogra_> yeah, thats what i mean
[17:21] <ogra_> weird ... my unxz definitely took a lt longer
[17:22] <rsalveti> popey: next image should be faster on mako
[17:22] <popey> say that more often please
[17:22] <popey> ☻
[17:22] <rsalveti> I need to land 2 small things first
[17:22] <ogra_> rsalveti, it wont help with third party click packages
[17:22] <popey> hmm, got disconnected from the phone
[17:22] <ogra_> apparmor needs to reprofile
[17:22] <popey> still got an apparmor chugging away
[17:22] <rsalveti> ogra_: indeed, but that will be consumed while installing, right?
[17:23] <ogra_> rsalveti, and reprofiled after upgrades
[17:23] <rsalveti> hm, it shouldn't reprofile it at ever upgrade
[17:23] <ogra_> it will not profile the system bits
[17:23] <rsalveti> if so, probably a bu
[17:23] <rsalveti> bug
[17:23] <rsalveti> system image upgrade I mean
[17:23] <rsalveti> app upgrade, sure
[17:23] <ogra_> but will profile the additional click packages you installed
[17:24] <ogra_> hmm, did the browser scrolling get smoother ?
[17:24] <ogra_> or is that just me liking to think that
[17:25] <rsalveti> ogra_: your brain might be slower
[17:25] <rsalveti> so you think it's faster
[17:25] <ogra_> lol
[17:26] <rsalveti> relaxed now after wcup
[17:26] <ogra_> yeah
[17:26] <ogra_> that might actually be
[17:33] <cjwatson> robru: want to use your new power to kick an image build?  new unity-system-compositor is in
[17:33] <robru> cjwatson, hell yes
[17:34] <cjwatson> I was gonna do it but I have to go for dinner and you might as well try :)
[17:34] <robru> cjwatson, should I typically do just touch armhf or both armhf and i386?
[17:34] <ogra_> always both please
[17:34] <robru> ok
[17:35] <robru> ogra_, ok, I clicked request rebuild, how do I know if it worked?
[17:35] <popey> the bot should announce it shortly after
[17:36] <ogra_> the entries for the products should have changed, there should be something like:  (rebuild in progress)
[17:36] <robru> popey, how shortly? I was under the impression there was a ~10min lag on the bot pings, either that or people are just really slow when I ask them to kick builds ;-)
[17:36] <ogra_> the watch process for the bot runs every ten min
[17:37] <popey> heh
[17:37] <robru> ogra_, I don't see "rebuild in progress"... where does it say that?
[17:37] <ogra_> robru, next to the armhf and i386 thingies ... where you did set the checkboxes
[17:37] <plars> robru: so is there a ppa/package I can easily add to tell it to pull in the new upstart from that silo?
[17:37] <robru> hmmm, yeah, not seeing it
[17:37] <ogra_> stgraber, ^^^
[17:38] <robru> plars, yeah, silo 3, package 'upstart'
[17:38] <ogra_> robru, i also dont see a build running on the builder
[17:38] <plars> robru: do you happen to have a link to the ppa? that might be easier
[17:38] <robru> plars, https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-003
[17:38] <plars> robru: I don't mess with the train stuff much, so I don't know where to find them off the top of my head. Thanks!
[17:38] <ogra_> stgraber, looks like the isotracker has issues ...
[17:39] <robru> plars, the bit.ly link in the channel topic is the dashboard page with all the PPA links
[17:39] <robru> ogra_, should I try again?
[17:39] <plars> cool, thanks
[17:39] <stgraber> robru: what did you do exactly?
[17:40] <ogra_> stgraber, just trying to trigger a touch build the usual way
[17:40] <robru> stgraber, ok, so I hit the checkbox next to 'Ubuntu Touch', which selected both i386 and armhf, then I went to the bottom of the page and clicked 'Update rebuild status' (with 'Request a rebuild' selected in the drop-down)
[17:40] <stgraber> ogra_: sure but seeing how it works fine for me, I want to know exactly what he ticked and what he clicked :)
[17:40] <ogra_> stgraber, but seems that didnt get through to nusakan (and the UI doesnt seem to say "(rebuilding)" or whatever that says after you clicked
[17:41] <ogra_> stgraber, it didnt work for me either in the recent past
[17:41] <stgraber> ogra_: can you make me a member of whatever your fancy new team is? otherwise I can't really debug this...
[17:41] <ogra_> one sec
[17:42] <ogra_> stgraber, done
[17:43] <ogra_> stgraber, but i remember i had the same issue even with the old teams a while ago (one or two weeks)
[17:43] <robru> stgraber, did I do the right steps? it seemed pretty obvious to me...
[17:43] <ogra_> robru, you checked the checkboxes before clicking at the bottom, right ?
[17:44] <robru> ogra_, yep
[17:44] <ogra_> yeah, there isnt much you can do wrong beyond that
[17:46] <stgraber> robru: try now
[17:51] <robru> stgraber, aha, it says rebuilding ;-)
[17:52] <ogra_> yay
[17:52] <stgraber> good, that was caused by some DB/admin UI bug... I fixed it in trunk now and I'll see if I can't just patch the db for now so that this doesn't hit us until we deploy next (basically ubuntu-touch and xubuntu get swapped in the admin UI... so the xubuntu guys had rights on touch and you had rights on xubuntu...)
[17:53] <ogra_> lol
[17:53] <robru> stgraber, awesome, I'll go trigger some xubuntu builds for fun
[17:55] <stgraber> alright, db tweaked so that the issue won't be visible for now (it was a missing order-by and the role table being out of order, so I've tweaked it now so it gets returned in the right order for the time being)
[17:58] <ogra_> stgraber, hmm, i dont see a build on nusakan, whats the time schedule this gets picked up on ?
[17:59] <stgraber> ogra_: it sure is running at the moment
[17:59] <stgraber> root     18593  0.0  0.0  41908  1868 ?        S    17:55   0:00  \_ CRON
[17:59] <stgraber> cdimage  18595  0.0  0.0   4404   612 ?        Ss   17:55   0:00      \_ /bin/sh -c rebuild-requests -b -q utopic iso
[17:59] <stgraber> cdimage  18598  0.0  0.0  54400 11700 ?        S    17:55   0:00          \_ /usr/bin/python /srv/cdimage.ubuntu.com/bin/rebuild-requests -b -q utopic iso
[17:59] <stgraber> cdimage  18602  0.2  0.3  97984 41380 ?        S    17:55   0:00              \_ /usr/bin/python /srv/cdimage.ubuntu.com/bin/cron.daily-preinstalled --live
[18:00] <imgbot> [18:00] <ogra_> lol
[18:00] <ogra_> the bot agrees with you :)
[18:00] <ogra_> i did
[18:00] <ogra_> gra@nusakan:~$ ps ax|grep for-project|grep touch
[18:00] <ogra_> ogra@nusakan:~$
[18:00] <sil2100> \o/
[18:00] <stgraber> yeah, ps doesn't show environment variables
[18:00] <ogra_> need to change my habits i guess
[18:01] <ogra_> stgraber, no, but i am used to see a "for-project" line for it
[18:02] <ogra_> i.e.
[18:02] <ogra_> ogra@nusakan:~$ ps ax|grep for-project|grep studio
[18:02] <ogra_>  3410 ?        Ss     0:00 /bin/sh -c DIST=trusty for-project ubuntustudio cron.dvd --live
[18:13] <robru> bregma, can I get an ack on this one-liner? https://code.launchpad.net/~robru/libunity/drop-friends/+merge/226714
[18:13] <ogra_> you are getting rid of all your friends :/
[18:13] <plars> xnox, slangasek: I'm running through the ci scripts that we use for smoke locally with upstart 1.13-0ubuntu1 from silo3 and it all looks pretty normal
[18:14] <robru> ogra_, I never had any friends, it was all a sham
[18:14] <ogra_> lol
[18:14] <plars> robru, ogra_: we already dropped friends from smoke
[18:14] <robru> plars, yeah, same here, just running AP tests locally they look good
[18:14] <robru> plars, saw that, thanks
[18:15] <ogra_> plars, yup
[18:16] <slangasek> plars: great!  does that mean you're happy for us to publish, or do you want to do more testing yet?
[18:17] <plars> slangasek: +1 from me
[18:17] <sil2100> robru: ok, so I moved the unapproved check to the publish job - but I'm still testing that in preprod, so I'll deploy it properly tomorrow :)
[18:17] <robru> sil2100, sweeeeet, thanks!
[18:18] <robru> slangasek, I ran unity8 and address-book AP tests, all looks good, +1 from me too
[18:19] <slangasek> ok; publishing then
[18:19] <slangasek> plars, robru: thanks
[18:20] <popey> balloons: want to upload http://s-jenkins.ubuntu-ci:8080/job/filemanager-app-click/lastSuccessfulBuild/artifact/out/com.ubuntu.filemanager_0.3.228_armhf.click ?
[18:20] <popey> suspect we're too late for image #135
[18:21] <balloons> popey, certainlyu
[18:22] <robru> popey, yep, 135 started without you
[18:22] <popey> well, dunno how long into the image it starts pulling clicks...
[18:23] <ogra_> at the end of the rootfs build ...
[18:23] <ogra_> 30min i'd say
[18:23] <ogra_> or a little more
[18:23] <popey> balloons: go go go!
[18:23] <balloons> it's uploaded
[18:23] <sil2100> popey, balloons: go go GOOO!
[18:23] <sil2100> \o/
[18:23] <sil2100> phew
[18:23] <sil2100> :)
[18:23] <ogra_> we'll see :)
[18:23] <balloons> lol
[18:23] <sil2100> o/
[18:23] <balloons> popey, https://myapps.developer.ubuntu.com/dev/click-apps/159/changerequest/
[18:23] <ogra_> i never stopwatched the builds :)
[18:24] <ogra_> just a guess from my gutts
[18:24] <balloons> machines are too slow.. we've got it
[18:24] <popey> approved
[18:25] <popey> thanks balloons
[18:25] <slangasek> xnox: fyi, in case you missed it, I've published silo 003
[18:30] <cjwatson> stgraber: ah, possibly I compounded this problem the other day by noticing them swapped in the admin UI and "fixing" them ...
[18:30] <cjwatson> + usermod -a -G tty,sudo,adm,dialout,cdrom,plugdev,audio,dip,video,gps,radio,bluetooth,android_net,android_net2,android_net3,android_graphics,android_input,sdcard_rw,android_media,android_nvram, android_cache phablet
[18:30] <cjwatson> usermod: group '' does not exist
[18:31] <cjwatson> somebody broke livecd-rootfs
[18:31] <ogra_> eeek !
[18:31] <ogra_> that must have been me :(
[18:31] <plars> Saviq: was it you that did the unity unlock script, or was that mterry I'm thinking of? IIRC, you were both working on it at one point
[18:31] <ogra_> weird since it was a simple copy/paste job
[18:31] <cjwatson> right, extra space
[18:31]  * ogra_ checks 
[18:31] <cjwatson> -DEFGROUPS="tty,sudo,adm,dialout,cdrom,plugdev,audio,dip,video,gps,radio,bluetooth,android_net,android_net2,android_net3,android_graphics,android_input,sdcard_rw,android_media,android_nvram"
[18:31] <cjwatson> +DEFGROUPS="tty,sudo,adm,dialout,cdrom,plugdev,audio,dip,video,gps,radio,bluetooth,android_net,android_net2,android_net3,android_graphics,android_input,sdcard_rw,android_media,android_nvram, android_cache"
[18:31] <mterry> plars, I've edited it in the past
[18:31] <ogra_> ugh
[18:32] <plars> mterry: I'm spotting some cases where it seems to fail quite badly, taking the world with it because of some dbus error
[18:33] <cjwatson> ogra_: want me to fix or are you on it?
[18:33] <ogra_> on it
[18:33] <cjwatson> ok
[18:35] <ogra_> uploaded ...
[18:36] <plars> mterry: http://q-jenkins.ubuntu-ci:8080/view/Touch/view/Ubuntu%20Touch%20Smoke/job/utopic-touch-mako-smoke-daily/495/console is an example
[18:36] <cjwatson> gar, I make the publisher faster and people keep uploading giant piles of kernels so I don't see the benefit straight away
[18:39] <mterry> plars, that's odd.  Permission denied for the dbus call?  Saviq, have you noticed that error before ^
[18:39] <plars> mterry: doesn't happen every time of course, so it could just be racy
[18:40] <mterry> plars, but permission denied?  I'd expect a race would be some sort of timeout or some such.  This seems final
[18:47] <Saviq> mterry, looks like apparmor denied this for some reason
[18:47] <Saviq> mterry, maybe some setup didn't finish, you'd have to ask security folk
[18:48] <mterry> plars, ^
[19:00] <robru> stgraber, will you have time today to review my queuebot branch? I think it's looking really good
[19:04] <stgraber> robru: yeah, I should have the time
[19:04] <robru> stgraber, thanks!
[19:23] <robru> brb
[20:10] <kgunn> robru: lovin' the train dashboard
[20:10] <robru> kgunn, thanks!
[20:11] <kgunn> robru: question...if i add a new project mp to a silo, and hit reconfig....can i just build that project? or does it require the packages of the other projects get blown away ?
[20:11] <robru> kgunn, you should be able to just build that one. reconfig doesn't delete the packages, and the next build job should notice the packages are still there
[20:12] <robru> kgunn, *should* ;-)
[20:15] <kgunn> robru: should....thanks!
[20:15] <robru> kgunn, let me know if that fails for any reason
[20:16] <kgunn> yep
[21:09] <seb128> silo 13 can be published if somebody want to do that (not on a machine to do it myself there)
[21:11] <cjwatson> doing 13
[21:11] <robru> cjwatson, beat you ;-)
[21:11] <cjwatson> ok :)
[21:21] <ogra_> hmm
[21:22] <ogra_> so livecd-rootfs migrated ...
[21:22] <ogra_> but the tracker didnt notice that the image buid failed
[21:26] <cjwatson> it appears to be building via the tracker now
[21:26] <cjwatson> I don't know if that was you or me
[21:26] <ogra_> heh
[21:27] <cjwatson> (I hit cancel then rebuild)
[21:27] <ogra_> same here
[21:28] <ogra_> as long as one of us got through :)
[21:42] <cyphermox_> ogra_: if you might have time later to try out some bluetooth UI fun with your speaker...
[21:43] <cyphermox_> the cool part is that things go in a2dp by themselves now, and you can play music straight to bluetooth
[21:44] <ogra_> nice ... but i wont survive much longer today i fear (nearly twelve here) can you send me instructions so i can test in the morning ?
[21:46] <ogra_> cyphermox_, what about dual mode devices ? my jabra headset can do both, hsp and a2dp
[21:46] <ogra_> (and i never tried it with the phone yet actually)
[21:46] <cyphermox_> should go straight to a2dp
[21:47] <cyphermox_> for now, anyway, until rsalveti finishes his part with pulse-droid or whatnot
[21:47] <cyphermox_> ogra_: sure, I'll email you the details
[21:47] <ogra_> thanks :)
[21:47] <cyphermox_> can I help with anything?
[22:06] <popey> cyphermox_: any chance you could take a look at bug 1330471 at some point
[22:06] <popey> cyphermox_: it's quite annoying that my phone _always_ connects to the furthest access point
[23:25] <slangasek> robru: ah, you've cleaned -003 for me I guess - thanks :)
[23:26] <jdstrand> so, I updated to r133. things seemed fine, then the messaging app didn't pick up a text the I sent via the messaging indicator. I rebooted and networking does not work and the keyboard won't show up
[23:27] <jdstrand> I rebooted 3 times now to no avail
[23:34] <jdstrand> ok, 6th reboot worked
[23:34]  * jdstrand will not reboot again
[23:35] <robru> slangasek, you're welcome!
[23:38] <robru> brb, gotta run to the store
[23:39] <slangasek> awe_: ping
[23:39] <awe_> slangasek, pong
[23:39] <slangasek> awe_: hi - re: bug #1341356
[23:40] <slangasek> awe_: I'm confused by your comments about cleaning up the bad state file
[23:40] <awe_> well I guess I wasn't sure if you wanted to just upgrade or where going to flash a new image
[23:41] <awe_> I'm not sure whether cyphermox_'s fix takes into consideration saved-state files that are out-of-sync
[23:41] <awe_> does that make sense?
[23:41] <slangasek> awe_: er, I certainly have no intention of re-flashing with phablet-flash, and don't think anyone else should have to either :)
[23:41] <slangasek> fwiw my /var/lib/urfkill/saved-states currently lists soft=false for all sections
[23:42] <awe_> then you should be OK to upgrade
[23:42] <slangasek> ok
[23:42] <awe_> I was just warning you that if it was incorrect, that some direct fixing might be involved
[23:43] <slangasek> well, if that were the case, considering this was on the devel channel, I think there's more we should do to support people in this situation... at minimum an announcement telling people how to fix it via adb
[23:43] <slangasek> but, I don't know that anything else is actually needed, since I managed to fix my own system
[23:59] <awe_> slangasek, the original bug had pretty explicit instructions, and it's been discussed on the ML quite extensively