[00:34] <balloons> fginther, no rush, just something to look at. The testruns for this merge are showing 1 result, with blank xml files. Something isn't quite right: https://code.launchpad.net/~music-app-dev/music-app/use-mediascanner2.0/+merge/214140
[02:10] <tedg> robru, Do you have an extra silo? I'm curious if this pay test failure is because of a virtualized PPA, but I don't have a non-virtualized one handy.
[03:25] <imgbot> [03:25] <imgbot> [04:05] <rsalveti> Mirv: replied you back about qt53, let me know if that's enough
[04:05] <rsalveti> will try to spend some more time on this tomorrow
[04:52] <Mirv> rsalveti: thanks! I'll try to work on them today now. so indeed the main problem may have been a syncing error since I didn't know that rules block was removed intentionally
[04:52] <rsalveti> Mirv: right
[04:53] <rsalveti> with that removed, you just need to duplicate the packaging and make sure the symbols are properly in place
[04:53] <rsalveti> and then rebuild the rest of the packages
[04:54] <Mirv> rsalveti: ok, I'll try to build the normal qtbase now first without that block, and adding some comment that the section shouldn't be synced from Debian
[04:54] <rsalveti> not even sure if that is needed in debian though
[04:54] <rsalveti> afaik it was something done in the qt 4.x serions
[05:13] <camako> still seeing an error building mir on armhf in silo landing-016... gcc 4.8/4.9 on armhf issues not fully resolved?
[05:13] <camako> slangasek ^^ (if you're around)
[05:13] <camako> http://pastebin.ubuntu.com/7661926/
[05:46] <Mirv> lool: hey. regarding that -dev2 frameworks - if you didn't get an answer from other landers, it's landing-005 (https://launchpad.net/~ci-train-ppa-service/+archive/landing-005)
[05:58]  * Mirv now building uitk in the silo with t1mp's toolbar fix
[07:39] <camako> sil2100, trying to build mir in landing-016, still experiencing what looks like gcc 4.8/4.9 problems.
[07:39] <camako> http://pastebin.ubuntu.com/7661926/
[07:47] <sil2100> camako: let me see
[07:48] <sil2100> huh, funny
[07:49] <camako> sil2100, I'll fwd you the background email from robru, also..
[07:49] <camako> thanks by the way for looking into this.. :-)
[07:50] <sil2100> camako: ok ;) I guess this error is fixable somehow anyways, so at least now it doesn't seem to be something completely broken in the toolchain
[07:52]  * camako cannot really tell but takes sil2100's word for it..
[07:52] <sil2100> camako: thanks for the fwd, although strange since all silo PPAs already had -proposed enabled
[07:52] <sil2100> So not sure what robru did additionally
[07:53] <robru> sil2100, yeah I just enabled -proposed at the request of ogra... yesterday or so. they were all disabled last week
[07:53] <robru> (also I'm not here)
[07:53]  * ogra_ wonders whats up with the dashboard 
[07:54] <sil2100> robru: yeah, but the fwd e-mail is from the 17th, so -proposed has been already enabled yesterday, right?
[07:54] <sil2100> robru: so why did you have to  explicitly re-enable -proposed for those two silos?
[07:54] <robru> sil2100, yeah. also slangasek was digging deeper into this toolchain that I'm able to
[07:55] <sil2100> (I thought you enabled those yesterday already for all silo PPAs)
[07:55] <robru> sil2100, no, at the time I enabled them, they were not enabled, and then after that I enabled them for all silos
[07:55] <sil2100> robru: right, but as I say, the e-mail mentions that you enabled -proposed for 2 silos, while I thought you enabled it already for all of them the day before ;)
[07:56] <sil2100> Anyway, I guess all is fine now as long as it doesn't remove the -proposed channel somehow automagically again
[07:56] <robru> sil2100, hm, no, you have the times confused I guess. at the time that I enabled those two, they were *all* disabled. then ogra became involved in the discussion and made a strong suggestion that they should all be enabled, so I enabled all of them (actually I found half of them had already been enabled mysteriously, but then I enabled the rest)
[07:57] <ogra_> that was the night from monday to tuesday ...
[07:57] <ogra_> (EU TZ)
[07:57] <sil2100> Ok
[07:57] <sil2100> robru: right, I wanted to ask about that: they were all disabled? Like, all of them didn't use -proposed?
[07:58] <ogra_> psivaa, looks like the dashboard didnt finish updating for mako on 87
[07:58] <robru> sil2100, at some point last week, yes I checked, and they were ALL disabled, not one single one was using proposed
[07:58]  * ogra_ is sure it was enabled for silo 18 or 19 ... the one we touched exactly for this about a month ago
[07:58] <sil2100> robru: oh gosh, I wonder why it was like that - since I remember when doing the hack with Colin some time ago the one silo I was modifying had -propose enabled actually
[07:59] <robru> sil2100, sorry I can't remember more details, but last week this issue came up and somebody said to me "hey what? why isn't proposed enabled? that should be enabled" and I checked them all, all disabled, and then I almost enabled them all then but didn't because I didn't understand it well enough at the time.
[07:59] <ogra_> i forgot which one it was exactly
[07:59] <sil2100> And then I re-enabled it back again, then ogra_ had to re-enable it again
[07:59] <psivaa> ogra_: let me take a look
[07:59] <ogra_> lets keep an eye on this ...
[07:59] <sil2100> robru: it seems we're really haunted
[07:59] <sil2100> ;)
[08:01] <sil2100> camako: anyway, I will try investigating this in a moment, need to prepare my chroot for testing
[08:01] <camako> sil2100, ok thanks, I'll be here...
[08:05] <sil2100> mhr3_: hi! How's the testing of silo 18 proceeding?
[08:06] <mhr3_> sil2100, hey, now that it finally built, we can actually test it :)
[08:06] <mhr3_> sil2100, will wait for alecu to wake up
[08:15] <sil2100> ogra_: anyway... did you see the almost-completed results for 87? 2 failures!
[08:15] <sil2100> ogra_: I doubt that terminal app or the system-settings tests will fail
[08:16] <sil2100> So this is one of the best image results we got since the beginning of the cycle!
[08:16] <sil2100> The UITK bug will be gone with the silo landing, so the only problem left is the calendar
[08:16] <ogra_> sil2100, 3 tests did never finish
[08:17] <ogra_> and the dashboard never snyced crashers/logs
[08:18] <sil2100> Right, but so far it's looking great, and I don't see any additional failures to happen
[08:18] <sil2100> 86 worries me a bit though
[08:18] <sil2100> It has the new filemanager but we still had 1 failure there
[08:18] <ogra_> that filemanager still had one failure worries me there
[08:18] <dednick> sil2100: what is s-jenkins IP?
[08:18] <ogra_> heh, snap
[08:19] <popey> dednick: you should have dns setup in your vpn connection to resolve that host to ip for you
[08:19] <dednick> popey: er, yeah.... that doesnt seem to be working.
[08:19] <popey> wfm
[08:19] <popey> dns server 10.99.244.1, additional search domain ubuntu-ci
[08:19] <sil2100> WFM as well
[08:19] <popey> alan@deep-thought:~$ host s-jenkins.ubuntu-ci
[08:19] <popey> s-jenkins.ubuntu-ci is an alias for mayura.ubuntu-ci.
[08:19] <popey> mayura.ubuntu-ci has address 10.98.3.13
[08:20] <sil2100> ogra_: but actually looking at the failure, this time it seemed to be something different I guess
[08:21] <sil2100> ogra_: as the test launches fine but failed in some other place
[08:21] <dednick> Host s-jenkins.ubuntu-ci not found: 3(NXDOMAIN)
[08:21] <dednick> :/
[08:21] <dednick> but i can access by IP
[08:22] <dednick> sil2100: what's the dns server for ubuntu-ci?
[08:22] <ogra_> sil2100, well, what worries me is that it just passes on 87
[08:22] <sil2100> dednick: don't know exactly, but popey mentioned 10.99.244.1 right?
[08:23] <ogra_> that doesnt look very stable
[08:23] <sil2100> ogra_: yeah, but it seems like something fixable, like standard test flakyness because of the test not being well written I would say
[08:23] <brendand> sil2100, is it right that 87 is still running?
[08:23] <ogra_> sure, could be
[08:23] <brendand> sil2100, it seems to have been on clock_app for quite a while
[08:23] <sil2100> brendand: yes, but filemanager passed there ;)
[08:24] <ogra_> brendand, cant be
[08:24] <brendand> sil2100, \o/
[08:24] <sil2100> brendand: psivaa is looking into that
[08:24] <ogra_> brendand, it should have finished hours ago
[08:24] <ogra_> right
[08:25] <psivaa> ogra_: sil2100: brendand  the dashboard hang/ not finishing syncing results is being caused by a weird clock app test being running forever
[08:25] <psivaa> test_lap_button_must_create_stopwatch_lap is the test
[08:25] <brendand> did a pdb creep in
[08:25] <brendand> maybe
[08:25] <ogra_> hmpf
[08:25] <dednick> sil2100: hm. i had a different IP as DNS,  but that new one doesnt help matters
[08:26] <brendand> but i hope that's unlikely
[08:26] <psivaa> the tests is running "Pressing and Releasing: BackSpace" step without an end
[08:26] <brendand> psivaa, oh i see
[08:26] <brendand> psivaa, could be an ap issue
[08:27] <psivaa> brendand: hmm.. i haven't checked why this is happening today though.. i.e. any change in AP or clock app or keyboard etc
[08:27] <ogra_> keyboard changed in 85
[08:27] <ogra_> autopilot in 86
[08:28] <psivaa> and now that this clock test timed out, the dashboard should be syncing in abit
[08:29] <ogra_> thanks
[08:29] <sil2100> We had a new AP, so who knows?
[08:29] <sil2100> Is clock-app using py3 AP?
[08:30] <brendand> psivaa, the test runner should have a timeout. AP doesn't seem to though
[08:30] <Saviq> cihelp, hey, no makos in CI http://s-jenkins.ubuntu-ci:8080/job/generic-deb-autopilot-runner-mako/ ?
[08:30] <Saviq> uh oh
[08:30] <psivaa> brendand: yea
[08:31] <Saviq> all CI makos stuck in flashing ;(
[08:31] <Saviq> cihelp ↑
[08:35] <psivaa> Saviq: i'm in a meeting now, could take a look after that (30 mins) if anyone else dont pick it up
[08:36] <davmor2> Mirv: sorry I ran out of day to file the bug I'll do it after the call
[08:36] <Saviq> psivaa, k thanks
[08:56] <vila> Saviq, psivaa : looking
[08:57] <sil2100> ogra_: ah! I forgot to ask one thing
[08:57] <popey> Pro-tip. Wait till sil2100  leaves the hangout before closing the tab.
[08:57] <sil2100> popey: ;p
[08:57] <ogra_> go ahead
[08:57] <popey> Second pro-tip: CTRL+SHIFT+T un-closes a tab
[08:57] <sil2100> ogra_: do you have a public holiday tomorrow?
[08:57] <davmor2> sil2100: is turning into Columbo
[08:58] <ogra_> sil2100, not in my part of germany i think ... i actually need to check
[08:58] <popey> or steve jobs
[08:58] <ogra_> sil2100, oh ! actually i do !!! thanks for asking, i wouldnt have known
[08:58] <davmor2> Always wait for sil2100 's just one more thing before leaving a chat
[08:58] <sil2100> davmor2: ...;p
[08:59] <sil2100> ogra_: oh noes ;)
[08:59]  * sil2100 also has a holiday tomorrow
[09:00] <dednick> sil2100: hey. i need to trigger some build jobs for a few branches, but with updated build parameters (ppa added yesterday). what's the best way to do that?
[09:03] <davmor2> Mirv: https://bugs.launchpad.net/ubuntu/+source/gallery-app/+bug/1331382
[09:03] <dednick> sil2100: nevermind. got it.
[09:06] <vila> Saviq: I manually 'adb reboot' one mako, killed the jenkins job, a new one is going further: http://s-jenkins.ubuntu-ci:8080/job/touch-flash-mako-04cb53b598546534/2596/console (compare with the previous run)
[09:08] <Saviq> vila, cool, let's see
[09:18] <Mirv> t1mp: hi! could you possibly look at davmor2's Gallery header bug? https://bugs.launchpad.net/ubuntu/+source/gallery-app/+bug/1331382 - so the header is apparently there but some missing things.
[09:24] <t1mp> Mirv: yes I noticed the same bug yesterday. artmello was looking at it, I don't know how far he got
[09:25] <Mirv> t1mp: oh, thanks for pinging him. and thanks for the toolbar fix even though I haven't been able to test it myself yet (new Oxide got released, it's still compiling for maybe 1h in the Qt 5.3 PPA, so I won't upgrade before that)
[09:26] <Mirv> I put the toolbar fix also in the Qt 5.3 PPA, even though it can be removed from there if UITK staging release gets released first
[09:33] <ogra_> come on clock-app, you know you can do it ...
[09:36] <brendand> sil2100, ogra_ - nothing reproducible with clock-app
[09:36] <ogra_> well, it runs for quite some time already ... again ...
[09:37] <sil2100> :|
[09:37] <brendand> ogra_, ok. there's something missing from the equation then
[09:37] <ogra_> psivaa, ^^^ how is the clock test going ?
[09:38] <psivaa> ogra_: i did not rerun the clock test. only ran system-settings and terminal app
[09:42] <ogra_> oh
[09:43] <psivaa> now running clock app to see if that's reproducible. should have tried on its own earlier. sorry
[09:48] <t1mp> Mirv: okay
[09:52] <ogra_> psivaa, hmpf ... now it seems like all results for one device vanished
[09:52] <mhr3_> sil2100, reconf 014 pls
[09:52] <ogra_> http://ci.ubuntu.com/smokeng/utopic/touch/mako/87:20140618:20140530/8597/
[09:52]  * ogra_ wonders whats up with today ... 
[09:53] <alan_g> vila: We're seeing Mir CI build failures because downstream projects are installed in the test setup and want a Mir version that differs from what we're testing. See libunity-mir1 etc. Here: https://jenkins.qa.ubuntu.com/job/mir-mediumtests-runner-mako/1795/console - can you help?
[09:53] <sil2100> mhr3_: sure
[09:55] <vila> alan_g: I'm recovering makos, that could be a fallout, can you re-run those jobs ? It *could* be that they were run against a wrong image (the one previously installed). Could that explain the failure ?
[09:57] <alan_g> vila: I'm not sure exactly what the test setup is/should be. I'll try it...
[09:57] <psivaa> ogra_: give me some time, i should be able to bring them back or if not i'll re-run them. that was because i wanted to ignore the clock app results first
[09:58] <ogra_> ok
[10:03] <oSoMoN> sil2100, Mirv: can I have a silo for line 35?
[10:03] <sil2100> oSoMoN: let me take alook
[10:03] <sil2100> mhr3_: oh, I reconfigured the silo a few minutes ago
[10:04] <mhr3_> sil2100, cheerios
[10:06] <ogra_> clock passed :)
[10:06] <seb128> sil2100, do you hold on assigning silos because the count is low? any chasing people to get some back?
[10:06] <sil2100> ogra_: \o/ you scared me in the past
[10:06] <seb128> sil2100, you might want to free the hud sru one, it's going to move to updates tomorrow and is validated
[10:07] <sil2100> seb128: did some chasing, I already assigned one silo for you (for the one I thought is more important)
[10:08] <seb128> sil2100, feel free to clear back 012, I need mterry to fix stuff for us before that can go in, so if we are low I'm happy to give it back and have it assigned again later
[10:08] <sil2100> seb128: ok, right - thanks for the info on hud, just cleaning it
[10:08] <seb128> sil2100, if you give me one for l36 I'm going to have it back in an hour or so, it's an easy roundrip for desktop only
[10:08] <sil2100> I didn't check pending-sru page for some time
[10:09] <sil2100> seb128: I actually assigned l37 first, ok, let me give 36 as well
[10:09] <seb128> sil2100, oh ok, the google doc doesn't reflect that and the bot didn't mention it
[10:09] <seb128> oh, it just did
[10:09] <seb128> sil2100, thanks ;-)
[10:09] <sil2100> seb128: the refreshes happen only every 5 minutes, and it seems we skipped one due to google errors ;/
[10:09] <sil2100> seb128: let me assign 36 too :)
[10:09] <seb128> (l37 is also one I'm going to test and give back in an hour)
[10:10] <seb128> thanks
[10:12] <Saviq> sil2100, icanhassilo for line 5 please?
[10:13] <oSoMoN> sil2100, when are the commitlog files generated? I find it a very useful tool, but I notice that atm they only go up to #85
[10:13] <Saviq> sil2100, we hope to land it, but have a bit of trouble testing without packages...
[10:13] <sil2100> seb128: the problem with our landings is that right now I only could chase down mhr3, since other silo-landers are either not yet up or on holidays
[10:13] <Saviq> oh yay, no more silos :|
[10:13] <sil2100> Saviq: no worries! Will have one for you in a moment ;)
[10:13] <Mirv> oSoMoN: it seems you got it now?
[10:13] <sil2100> oSoMoN: o/ so...
[10:13] <oSoMoN> Mirv, yup
[10:14] <Saviq> sil2100 has some secret silos ;)
[10:14] <sil2100> oSoMoN: the commitlogs are auto-generated on our canonistack instance, but the rsync is not yet made so that it's synced up automatically
[10:14] <sil2100> oSoMoN: since it's a bit complicated
[10:14] <sil2100> Let me sync those manually
[10:14] <ogra_> well
[10:14] <oSoMoN> sil2100, ah, ok, thanks!
[10:14] <ogra_> there was a meeting yesterday where it was discussed to have system-image generate them at image build time
[10:14] <sil2100> I'll have a talk with stgraber today to maybe move the generation of those to system-image
[10:15] <sil2100> But we'll see how it goes
[10:15] <seb128> sil2100, well, there are a bunch of "test silos, feel free to flush if needed" assigned, in case you people are blocked
[10:15] <sil2100> ogra_: we'll see which happens first ;)
[10:15] <ogra_> heh
[10:16] <sil2100> oSoMoN: ok, pushed :)
[10:28] <popey> vila: can you re-trigger https://code.launchpad.net/~qqworini/ubuntu-rssreader-app/fix-bug1329648-performance-issue/+merge/223066 please?
[10:28] <sil2100> Saviq: remember that I'll be giving you an override
[10:28] <sil2100> So sync up with other unity8 landings
[10:28] <Saviq> sil2100, of course
[10:29] <sil2100> And please land something soon :P
[10:29] <sil2100> (lowish on silos)
[10:32] <vila> popey: done, I thought you got access rights to do so ?
[10:48] <popey> hm
[10:49] <popey> vila: i have no user/pass for http://91.189.93.70/
[10:51] <vila> popey: register first and I'll see if I can find the right pattern to give you access
[10:52] <vila> popey: yeah, looks like alesage, balloons, elopio and then some already have such rights, no point in frustrating you isn't it ?
[10:53] <vila> popey: ping me when you're registered
[10:54] <vila> popey: oh, and it appears that the re-run gave the same result: 2 tests fail: http://91.189.93.70:8080/job/generic-mediumtests-utopic/554/
[10:59] <popey> yeah ☹
[11:00] <popey> vila: how does one register? I seee only a login button
[11:01] <vila> popey: click it
[11:01] <popey> vila: i did, it asks for user/pass
[11:03] <vila> popey: fill in ?
[11:03] <popey> with what? I dont have an id
[11:04] <vila> popey: hmm, right, it seems we've disallowed sign up :-/ Crap
[11:05] <vila> popey: sry, first time I encounter that, let me dig
[11:07] <popey> np
[11:07] <vila> popey: see PM
[11:08] <popey> ok, logged in
[11:08] <popey> should I expect an email?
[11:09] <popey> aha, found the "configure" screen. got it
[11:09] <vila> popey: no, but I wasn't sure if the email was the right one
[11:09] <popey> Thanks vila
[11:09] <popey> I now see a rebuild button ☻
[11:09] <popey> nice one
[11:09] <popey> MUHAHAHAAH!
[11:10] <vila> popey: then try logout/login and you should see the 'Rebuild' button (left column) in ... hehe too fast ;)
[11:31] <oSoMoN> sil2100, I realized that one of the branches associated to silo 7 is not ready yet, so I removed it from the list, and triggered a rebuild, but it appears the removed branch has been included in the build anyway, how can I ensure it’s not picked up?
[11:31] <sil2100> oSoMoN: we need to reconfigure the silo now
[11:31] <sil2100> oSoMoN: let me do that
[11:32] <sil2100> seb128: btw. why is l36 set to ready: No?
[11:32] <oSoMoN> ah, right, I forgot to reconfigure…
[11:32] <sil2100> Damn, spreadsheet is having some problems it seems :|
[11:33] <seb128> sil2100, because it failed to build due to toolchain issues, so I cleaned the silo and set it back to "no" until we sort the toolchain issue
[11:34] <sil2100> seb128: ACK
[11:34] <sil2100> oSoMoN: reconfigured
[11:36] <sil2100> seb128: don't worry about 'silo 12', my mistake
[11:36] <seb128> sil2100, ok
[11:44] <psivaa> ogra_: sil2100: all the results for 87 are now in the dashboard. probably with one of the best results in recent times
[11:44] <ogra_> yeah :
[11:44] <ogra_> :D
[11:46] <brendand> sil2100, 99.8%. wow
[11:47] <brendand> sil2100, may as well call it green
[11:48] <ogra_> it isnt green before its green :P
[11:49]  * popey will print out and put it on the wall next to the other one he has where it was all green
[11:50] <popey> dated 2013/12/18
[11:50] <popey> Those were happy times...
[11:50] <sil2100> :D
[11:50] <sil2100> I will mention this on the mailing list for sure :D
[11:51] <sil2100> davmor2: if you have a moment, can you take a look at 87 promotion-wise? I would be really sad not to promote an image that's 99.8% green...
[11:51] <sil2100> Damn, 2 failures
[11:51] <sil2100> I think I'm gonna cry
[11:52] <davmor2> sil2100: 2 whole failures, Shame on you ;)
[11:52] <davmor2> sil2100: yeap sure
[11:52] <sil2100> :<
[11:52] <sil2100> ;)
[11:52] <sil2100> davmor2: thanks!
[11:53]  * popey is on vacation for the afternoon. cheerio all ☻
[11:55] <Mirv> t1mp: zsombi_ popey Saviq tsdgeos davmor2: landing-005 is ready again, please use if possible. new stuff that I've very quickly tested: 1. new Oxide, webbrowser rocks again, 2. timp's toolbar fix does fix the gallery, dropping letters and notes!, 3. SDK is ready. known remaining problems on phone: music-app (fixed .click available from popey's link), gallery-app header https://bugs.launchpad.net/ubuntu/+source/gallery-app/+bug/1331382
[11:55] <sil2100> popey: o/
[11:55] <Mirv> ok s/popey// from that then :)
[11:55] <sil2100> Mirv: all bigger blockers are fixed?
[11:55] <Mirv> sil2100: yes, sans someone else testing besides me too
[11:55] <Saviq> nice
[11:55] <sil2100> Mirv: good work!
[11:56] <Mirv> sil2100: including that I now have zero tested -gles packages after 7 hours of heavy building :) but they're there now, so it just might be emulator is also fully functional
[11:56] <t1mp> Mirv: I am just using that ppa all the time now
[11:56] <t1mp> Mirv: one more remaining problem: no 2-finger scroll in qtc, which is quite annoying
[11:57] <Mirv> t1mp: yeah that's great. it's just that it was broken earlier again when they landed Oxide to the archives, but the rebuild is ready now too so I tend to say "now would be for example a good time to dist-upgrade"
[11:57] <ogra_> heh, the mako and flo results are exactly flipped ...
[11:57] <ogra_> 4 failures vs 4 crashes
[11:57] <Mirv> t1mp: I'd currently tend towards it not being a blocker since it does not affect everyone, but yes it's surely something that needs to be fixed
[11:58] <t1mp> Mirv: ok, so I am lucky I didn't do a dist-upgrade this morning :)
[11:58] <Mirv> t1mp: yeah, you should mainly just abort if you see something being removed or so :)
[12:00] <t1mp> ok
[12:02] <Mirv> sil2100: I've went through the landing list adding notes to everywhere where consideration/care is needed because of conflicting landing with Qt. I also updated the Qt landing's instructions
[12:24] <retoaded> all: we're going to bounce ADB host ashes to bring the makos/mantas back online
[12:35] <oSoMoN> sil2100, Mirv: silo 7 ready to publish when you are :)
[12:42] <Mirv> oSoMoN: published, I'll M&C it as soon as it's possible and fire a rebuild in the Qt silo
[12:42] <oSoMoN> Mirv, excellent, thanks!
[12:43] <sil2100> o/
[12:43] <cprov> all: makos and mantas should be back online.
[12:44] <sil2100> mhr3: any luck with your silos?
[12:45] <mhr3> sil2100, not yet, alecu and dobey are starting just now
[12:49] <dobey> silo 18 built ok
[13:02] <Mirv> rsalveti: if you happen to be awake already, you could join https://plus.google.com/hangouts/_/canonical.com/qt-5-3-landing too
[13:12] <davmor2> sil2100: osk on g+ is confirmed lookeing a twitter now
[13:13] <sil2100> davmor2: you mean, working?
[13:13] <davmor2> sil2100: not working sorry
[13:13] <sil2100> Or not working?
[13:13] <sil2100> Crap
[13:14] <sil2100> davmor2: I wonder if it can be related to the oxide landing in #87
[13:14] <sil2100> davmor2: you using 87, right?
[13:14] <davmor2> sil2100: twitter is working for me here
[13:15]  * sil2100 is upgrading to #86
[13:15] <sil2100> Since 87 had the new oxide, while 86 had some modifications to webapps
[13:20] <davmor2> sil2100: so just google plus I've sent a post to facebook and twitter they both worked fine  I'll have a look at some other webapps to be sure
[13:21] <sil2100> That's strange
[13:23] <davmor2> sil2100: here maps works
[13:24] <Davmor3> sil2100: Kiwiirc works
[13:25] <brendand> sil2100, webbrowser-app has passed 4 in a row, that's encouraging
[13:25] <brendand> sil2100, this is the bug blocking the uitoolkit fix - https://bugs.launchpad.net/ubuntu-ui-toolkit/+bug/1330757
[13:26] <brendand> sil2100, it has to be fixed and then the sdk team needs to do another landing
[13:26] <davmor2> sil2100: so I wonder if it is a mislabelled text field in the google+ app.
[13:26] <t1mp> zsombi_: weren't you looking at this bug? https://bugs.launchpad.net/ubuntu-ui-toolkit/+bug/1330757
[13:27] <zsombi_> t1mp: yes, I'm trying to look at that bug, as much as my time gives...
[13:27] <sil2100> brendand: \o/
[13:27] <t1mp> zsombi_: ok, zoltan assigned it to me, I'll give it to you then
[13:27] <zsombi_> t1mp: can you make a favor still?
[13:27] <sil2100> zsombi_, t1mp: thanks guys, we would like the new UITK in
[13:28] <sil2100> Since it will make our dashboard even greener
[13:28] <t1mp> zsombi_: you have been sucked deeper into the hell of mouse events anyway, so better for you to solve it ;)
[13:28] <zsombi_> sil2100: does that bug break other apps than notes?
[13:28] <brendand> sil2100, not green yet :)
[13:28] <t1mp> zsombi_: what's the favor?
[13:28] <brendand> zsombi_, no but there is a uitk fix riding on the back of it
[13:28] <zsombi_> t1mp: could you put some logs in the Notes app where the IMA handling is done, to see whether it gets events there?
[13:29] <sil2100> davmor2: what name does the G+ application have?
[13:29] <davmor2> sil2100: Google+
[13:29] <zsombi_> brendand: meaning there is a particular UITK fix you are seeing there that caused the problem?
[13:29] <t1mp> zsombi_: yes, but you can easily run notes-app on your desktop too
[13:30] <zsombi_> t1mp: yes, I know, I started to grab all the needed things just I had been interrupted 1000 times...
[13:30] <davmor2> sil2100: just type goo into the search it should show up if not hit the down arrow to expand the number apps viewed
[13:30] <zsombi_> t1mp: but, yes, assign that bug to me...
[13:31] <sil2100> davmor2: damn, it doesn't appear here
[13:31] <sil2100> Just authenticator and maps from the store
[13:31] <davmor2> sil2100: now click on the expander
[13:31] <sil2100> Ah
[13:31] <davmor2> sil2100: then it shows more apps available
[13:31] <sil2100> Now that is confusing
[13:31] <sil2100> -_-
[13:31] <sil2100> Bullshit I say!
[13:32] <davmor2> sil2100: indeed but design wanted only 2 visible as I understand it
[13:33] <t1mp> zsombi_: that's why it is better to work in evenings. You can pretend that you are not here (so you are not interrupted), while you are secretly working.... muhahahahaha
[13:33] <t1mp> ;)
[13:33] <zsombi_> t1mp: LOL
[13:34] <brendand> zsombi_, no - meaning that there is a fix for a test failure in the ci dashboard that is in the silo that has that bug
[13:35] <brendand> zsombi_, so i guess we can't get the fix out until that issue is gone
[13:36] <t1mp> Mirv: which version of uitk does landing-005 include?
[13:36] <t1mp> Mirv: see my last comment on https://bugs.launchpad.net/ubuntu-ui-toolkit/+bug/1330757
[13:38] <t1mp> zsombi_: NoteItem.qml has an InverseMouseArea, but its onClicked is never triggered
[13:38] <t1mp> zsombi_: my guess: the listview eats it
[13:38] <brendand> elopio, did you have 005 enabled when you found that issue?
[13:38] <zsombi_> t1mp: so it's the IMA then... ok, thx, we're one step closer again...
[13:40] <t1mp> zsombi_: if I remove "topMostItem: true" from the IMA, it works as expected!
[13:40] <elopio> brendand: I miss context. What issue are you talking about?
[13:40] <t1mp> zsombi_: note that I am not using landing-006 ppa but landing-005 (qt53)
[13:40] <zsombi_> t1mp: heh?! wth???!?!?!!!
[13:41] <Mirv> t1mp: it has the archive version of UITK + https://code.launchpad.net/~zsombi/ubuntu-ui-toolkit/qt53-fixes/+merge/222475
[13:41] <Mirv> https://code.launchpad.net/~tpeeters/ubuntu-ui-toolkit/fixEmptyToolbarQt53/+merge/223412
[13:41] <Mirv> t1mp: so 20140602 + those two Qt 5.3 related branches
[13:42] <t1mp> Mirv: fixEmptyToolbarQt53 was branched from staging.. does that mean you included uitk staging in the ppa, or just the diff from my branch?
[13:42] <t1mp> zsombi_: yes, weird... I'd expect it to be the other way around :s
[13:43] <Mirv> t1mp: ah right then it's possibly staging too.. I didn't realize, since I was anyway originally expecting UITK to land first and it'd be a matter of a simple rebuild
[13:43] <Mirv> t1mp: so I used the normal MR:s in CI Train, adding those two merges
[13:44] <t1mp> Mirv: no problem, I was just wondering why I could reproduce a regression of our landing without installing the landing ppa :)
[13:44] <t1mp> Mirv: it is convenient that I don't have to add another ppa now :)
[13:47] <brendand> elopio,bug 1330757
[13:47] <brendand> elopio, did you have landing-005 enabled when you found it?
[13:47] <elopio> brendand: for that I had only silo 006.
[13:48] <Mirv> pmcgowan: remember that I'm gone after tomorrow, so if I'm wanted to do the publishing it'd probably only be with a green light e-mailed by my morning or so. or we could have another meeting tomorrow or something too. but sil2100 or rsalveti can also do the publishing and I'll e-mail them some more details too just in case (everything's also documented in the CI Train sheet and elsewhere)
[13:48] <sil2100> o/
[13:49] <ogra_> fginther, your bootloader issue could simply be caused by using an old bootloader on the phone, i told vila already otday that you should check the bootloader version if possible ... to compare to a working device
[13:49] <fginther> ogra_, oh, interesting
[13:49] <fginther> thanks
[13:49] <ogra_> (will need physical access, i think it is only shown on screen)
[13:49] <pmcgowan> Mirv, anything still blocking?
[13:50] <fginther> ogra_, do you know what the latest bootloader is (or know how to find out)?
[13:50] <ogra_> fginther, we never upgrade bootloader or radio firmware in ubuntu, so the device will be using whatever was originally flashed by android ... if thats a 4.2.2 bootloader that could possibl yexplain the issues
[13:50] <pmcgowan> Mirv, read the update, looks great
[13:51] <pmcgowan> bfiller, see the blocker issue with gallery header in Mirv's email
[13:51] <fginther> ogra_, thanks again
[13:52] <ogra_> fginther, there is "bootloader version" on screen in bootloader mode
[13:52] <pmcgowan> lool, we need your update to the framework in that silo I assume
[13:52] <ogra_> fginther, my device shows MAKOZ10o
[13:52] <lool> pmcgowan: yup, albeit I cant direct upload to it and it's not a CI-ified package
[13:52] <ogra_> but i dont often reboot into bootloader with it ... cant tell if it would show the same issues
[13:53] <pmcgowan> lool, I see, so how do we tie the landings together?
[13:53] <lool> sil2100: hey, what's the best way to add a non-CI-ed package to the silo?
[13:53] <lool> sil2100: or should we CI-ify ubuntu-touch-meta?
[13:54] <sil2100> lool: you can just use a source upload to the silo
[13:54] <mhr3> sil2100, 018 marked as rdy
[13:54] <sil2100> lool: just add ubuntu-touch-meta to the 'additional sources to land' and dput it to the PPA
[13:54] <mhr3> sil2100, will need to land one more change to click, so if you could publish quick pls
[13:54] <sil2100> (once the silo is assigned)
[13:54] <sil2100> mhr3: sure
[13:55] <bfiller> pmcgowan: ack
[13:56] <lool> sil2100: ok; the silo PPA page said I shouldn't do that, but thanks
[13:56] <sil2100> lool: I think we should change the description
[13:57] <sil2100> lool: anyway, remember to include the name of the package in the 'additional sources' field in the landing request
[13:57] <sil2100> lool: the description basically says that no direct uploads without a silo assigned should be done
[13:57] <sil2100> (I suppose)
[13:57] <ogra_> lool, seed changes are usually just uploaded, since you cant really "test" them anyway
[13:57] <ogra_> (direct upload, no silo)
[13:58] <lool> ogra_: it's not a seed change though
[13:58] <ogra_> ?
[13:58] <ogra_> how can meta not be a seed change
[13:58] <lool> ogra_: it's a .framework file addition
[13:58] <ogra_> ah
[13:58] <Saviq> fginther, one thing I forgot to talk to you about in Malta re: airline, since the plan is to build images from "silos", would it be possible to build deltas, too, to save bandwidth and install time?
[13:59] <Saviq> fginther, another interesting question would be whether it'd be possible to do roll-backs via delta, but I don't think that system-image supports this right now...
[13:59] <oSoMoN> Mirv, I’m going to submit another landing request for webbrowser-app, but it’s ok to go after the Qt 5.3 landing, I don’t need a silo right now
[14:00] <sil2100> mhr3: I'm reviewing the packaging changes right now
[14:03] <lool> sil2100: hmm where do I edit the additional sources?
[14:03] <fginther> Saviq, that would have to be put on the wishlist. Once we have a reliable method for provisioning via full images, we can investigate deltas. I can see where this could be useful from a developer perspective, but we've done no investigation into using deltas yet.
[14:03] <sil2100> lool: if you look at the main spreadsheet page there is a column 'Addidional source packages to land'
[14:03] <sil2100> lool: and you list those there :)
[14:04] <Mirv> oSoMoN: ok
[14:04] <Mirv> it's nice that the build '100' https://ci-train.ubuntu.com/job/landing-005-1-build/100/console was the first to actually "succeed" (now that finally all the packages I listed are there, including -gles ones)
[14:05] <Saviq> fginther, sure, wishlist is good enough for me ;)
[14:05] <lool> sil2100: I cant edit it though
[14:06] <sil2100> lool: oh, you don't have the permissions? Let me add you those, one moment
[14:06] <lool> thanks
[14:07] <sil2100> lool: you should have the power now - do you know if you also have silo-manipulation power?
[14:07] <sil2100> Ah, you should as a core-dev
[14:07] <lool> sil2100: added thanks
[14:08] <sil2100> mhr3: changes look good, but we'll have to ask cjwatson to remove the arm64 binary of unity-scope-click then
[14:08] <sil2100> mhr3: since indeed I don't see a arm64 of ubuntu-sdk-libs in the archive
[14:08] <lool> sil2100: hmm Signer has no upload rights to this PPA.
[14:08] <sil2100> lool: ouch... ok, so I think we'll have to ask asac to add you to the PPA team
[14:08] <sil2100> asac: ^
[14:09] <sil2100> lool: btw. which silo is that?
[14:09] <sil2100> lool: I'll have to reconfigure it now then
[14:09] <lool> sil2100: silo 5
[14:09] <lool> asac: would you add me to https://launchpad.net/~ci-train-ppa-service/+members ?
[14:09]  * sil2100 doesn't have power over that team :<
[14:13] <sil2100> Mirv: are you building something in silo 5 right now?
[14:13] <cjwatson> sil2100: This is like the third instance of that - I thought there was a fix for that in the queue due to land?
[14:13] <sil2100> Mirv: or can I reconfigure the silo?
[14:13] <Mirv> sil2100: there's a webbrowser rebuild ongoing since a new version just landed to archives, but I guess you could reconfigure it even with that? or you could abort the build job (it's already uploaded) and run watch only afterwards.
[14:14] <sil2100> cjwatson: you mean, a fix for an arm64 package of ubuntu-sdk-libs?
[14:14] <sil2100> Mirv: let me try reconfiguring even with the build ongoing
[14:14] <sil2100> One moment
[14:15] <sil2100> lool: me or Mirv can dput the package for you in the meantime
[14:15] <sil2100> But I think the whole core-devs team shuold be added to the PPA team members
[14:16] <davmor2> sil2100: okay that is weird, my battery is at 10% it showed red for a couple of seconds then went white and a 1/3 full again
[14:17] <sil2100> davmor2: ah, how reliable this is
[14:18] <lool> sil2100: http://people.canonical.com/~lool/touch-meta/
[14:20] <sil2100> lool: ok, let me do this then
[14:21] <sil2100> cjwatson: anyway, can I publish unity-scope-click then with a no-longer provided arm64 binary?
[14:24] <cjwatson> sil2100: I forget what the fix was going to be; but yes, go ahead and publish, I'll sort it out afterwards
[14:25] <sil2100> cjwatson: thank you :)
[14:25] <sil2100> lool: ok, I pushed the source package to the PPA
[14:26] <elopio> ping Ursinha: on the gatekeeper job, we have problems installing webbrowser-app-autopilot. But it installs without problems on my utopic machine with the 005 silo.
[14:26] <elopio> http://q-jenkins.ubuntu-ci:8080/job/qt-release-gatekeeper/label=daily-mako/7/console
[14:27] <davmor2> sil2100: it gets better.  I wanted to take a screenshot of it on 9% with the white 1/3 the minute I plug it in it shows as empty red with the lightning bolt in to show it's charging.  It's like the white image is over writing the red one
[14:32] <sil2100> Is the spreadsheet working for everyone else?
[14:33] <sil2100> "We're sorry, but you have sent too many requests to us recently. Please try again later." <- thanks
[14:33] <sil2100> Love google
[14:35] <sil2100> davmor2: but anyway, in overall what do you think of the state of 87?
[14:36] <lool> sil2100: uhoh
[14:36] <lool> sil2100: this is typically a per account limit
[14:36] <davmor2> sil2100: yeah I've not finished but on the whole it is look as good as the others that have been promoted
[14:36] <lool> might go away in some minutes or an hour
[14:36] <lool> but it's not good
[14:37] <elopio> ping plars: on the gatekeeper job, we have problems installing webbrowser-app-autopilot. But it installs without problems on my utopic machine with the 005 silo.
[14:37] <elopio> http://q-jenkins.ubuntu-ci:8080/job/qt-release-gatekeeper/label=daily-mako/7/console
[14:38] <plars> elopio: one moment, will take a look
[14:42] <jhodapp> sil2100: can I get a silo for line 42?
[14:42] <elopio> thanks
[14:43] <sil2100> jhodapp: let me free one silo and I'll assign one to you in some moments
[14:43] <sil2100> We're really low on those...
[14:43] <jhodapp> sil2100: thanks
[14:43] <jhodapp> sil2100: that's a good sign...lots of good stuff landing :)
[14:43] <sil2100> thostr_: I'm flushing silo 002 for you ;)
[14:43] <sil2100> jhodapp: sadly many landings are just standing around for longer without much movement ;p
[14:44] <jhodapp> bummer
[14:44] <sil2100> thostr_: please ask for an re-assignment once we have more silos free
[14:45] <sil2100> Saviq: infographics silo packages built! How's the testing going? ;)
[14:45] <Saviq> sil2100, just went through ap, but it's not gonna happen today
[14:48] <renato> fginther, ping
[14:48] <sil2100> Saviq: too bad.. oh well, do you have any other silos that can land soon? ;)
[14:48] <fginther> renato, pong
[14:48] <renato> fginther, looks like jenkins got stuck again http://s-jenkins.ubuntu-ci:8080/job/phablet-team-address-book-app-staging-ci/
[14:48] <rsalveti> Mirv: I'll take a better look at the qt 5.3 changes today, so we cna try to land it tomorrow then
[14:49] <fginther> renato, it's heavily backed up because 3 of the 4 makos are not working, it will eventuall clear up and someone has been paged to get the failed devices up again
[14:51] <plars> elopio: looks like it needs an apt-get update, but we always avoid that for smoke jobs at least because it can bring in other things we don't want
[14:51] <plars> webbrowser-app-autopilot : Depends: webbrowser-app (>= 0.23+14.10.20140617.1-0ubuntu1) but it is not going to be installed
[14:51] <plars> E: Unable to correct problems, you have held broken packages.
[14:53] <elopio> plars: I understand.
[14:53] <elopio> but then, what should we do? add the webbrowser-app we want to the ppa?
[14:53] <Saviq> sil2100, no :|
[14:53] <plars> elopio: that sounds reasonable, but you are more familiar with what you are trying to accomplish here. Would that cause issues for you?
[14:54] <elopio> plars: I am not familliar at all :) Mirv ^
[14:54] <plars> elopio: we could also have the job update if that package is in the archive already, but that seems like the wrong thing to do
[14:54] <plars> elopio: for autopilot tests though, it seems like they should always come with a corresponding version of the app
[14:55] <sil2100> jhodapp: so... I would assign a silo for you now, but it seems camera-app is already locked by Saviq's landing
[14:55] <sil2100> (which might land tomorrow)
[14:55] <elopio> plars: oh, that's the problem, right? the autopilot package is more recent than the webbrowser package.
[14:56] <plars> elopio: right
[14:56] <jhodapp> Saviq: what's going on with your landing and camera-app?
[14:57] <elopio> I'm not sure how can that happen, if both came from the webbrowser-app package that's on the PPA
[14:57] <sil2100> jhodapp: line no 5 on the spreadsheet
[14:57] <jhodapp> thanks
[14:57] <elopio> plars: I've just checked, it's already there.
[14:58] <jhodapp> sil2100: seems that needs to wait until qt 5.3...I would like to land this before we land qt 5.3
[14:59] <elopio> webbrowser-app 0.23+14.10.20140618.3-0ubuntu1 is on the ppa, and it is > 0.23+14.10.20140617.1-0ubuntu1
[14:59] <sil2100> Saviq: what do you think? ^ Can we get jhodapp's stuff landed before your silo and Qt 5.3?
[15:00] <Saviq> sil2100, I don't have any firm silo to land early
[15:00] <Saviq> sil2100, so anything that wants in before, I'm fine
[15:00] <Mirv> elopio: I still don't understand what the cause of it is, and the autopilot installed fine before and also now. but note this new version just came in, so you could maybe try again. there was another webbrowser-app landing to main archives so the silo needed a rebuild.
[15:00] <sil2100> jhodapp: ok, so I assign you a silo but please sync up with Saviq
[15:00] <sil2100> Once it lands or not
[15:01] <jhodapp> cool, thanks sil2100 and Saviq
[15:01] <elopio> Mirv: I'll kick it again.
[15:01] <Mirv> elopio: but if it's again now the same, now just with bumped version, I've no idea since I'm running the webbrowser-autopilot tests here just fine. on the other hand, we already had good results of webbrowser, so maybe it could be removed from the suite temporarily.
[15:03]  * Mirv needs to go
[15:04] <elopio> Mirv: ok, I can try that too.
[15:04] <plars> elopio: sorry, one sec... I have multiple issues I'm working at the moment
[15:06] <sil2100> jhodapp: silo 2 is for you
[15:06] <jhodapp> thanks!
[15:06] <sil2100> yw!
[15:09] <fginther> renato, all the makos are alive and operating again, the backlog of jobs should be resolved soon
[15:09] <renato> fginther, thanks
[15:13] <plars> elopio: is it possible you just need to specify webbrowser-app in the packages list?
[15:14] <plars> elopio: I'm not sure offhand what the phablet-tools are doing there, maybe they are forcing it to *just* upgrade the listed packages?
[15:15] <elopio> plars: on phablet-config I see that it does the apt-get update.
[15:15] <elopio> it should, at least.
[15:16] <plars> elopio: I guess it would have to, is it pinning everything that's not mentioned though?
[15:16] <plars> elopio: I think it might be
[15:16] <plars> elopio: maybe try adding webbrowser-app to the packages parameter in the job
[15:17] <elopio> plars: I'm trying that.
[15:17] <plars> elopio: do you kick off the job by hand, or is something automatically triggering?
[15:17] <elopio> plars: by hand.
[15:17] <plars> phablet-config is certainly pinning some things
[15:18] <elopio> yes. I don't understand the details of that though.
[15:18] <sil2100> davmor2: how's the dogfooding going so far?
[15:19] <ogra_> plars, elopio citrain-push might help (as long as the extra package you want is also in the PPA/silo)
[15:19] <davmor2> sil2100: so this looks like the other recently released images with the exception of google+
[15:19] <sil2100> davmor2: ok, you think we should block on the google+ issue?
[15:20] <sil2100> I guess we need to escalate this issue somehow, is there a bug for it already?
[15:20] <davmor2> sil2100: no it's an installed app over a default one
[15:20] <davmor2> sil2100: I'm assuming not I'm just looking to see if it is playing up elsewhere one second
[15:24] <davmor2> sil2100: open gmail app
[15:24] <davmor2> sil2100: then open g+ tab in the gmail app now text input works
[15:25] <davmor2> sil2100: so I'm wondering if the g+ app just needs a tweak
[15:26] <sil2100> hmm
[15:27] <sil2100> Ok, I guess it's fine in overall
[15:27] <sil2100> So I would say let's promote
[15:30] <davmor2> sil2100: yeah may as well
[15:30] <sil2100> ogra_: any objections regarding promotion of #87?
[15:31] <ogra_> nope, none at all
[15:31] <zsombi_> brendand: I have a fix for the bug 1330757
[15:32] <brendand> zsombi_, well that's awesome
[15:32] <zsombi_> brendand: I hope the guys can review it and merge in the landing
[15:32] <sil2100> ogra_: could you maybe promote #87 now then? I guess no need to wait for the meeting ;)
[15:32] <sil2100> Thanks!
[15:32] <brendand> zsombi_, no need to rush it, but yeah that would be good
[15:32] <ogra_> sil2100, as soon as i'm out of my current meeting
[15:33] <sil2100> ogra_: excellente
[15:33] <ogra_> :)
[15:33] <zsombi_> brendand: people are waiting for the toolkit release :) so it's pretty urgent :)
[15:34] <brendand> zsombi_, i'd like to try the fix to - to make sure it 'works for us'
[15:34] <brendand> zsombi_, silo006 right?
[15:34] <zsombi_> brendand: https://code.launchpad.net/~zsombi/ubuntu-ui-toolkit/inverseMouseArea-update/+merge/223589
[15:35] <zsombi_> brendand: yep
[15:36] <zsombi_> brendand: but the silo has one MR that has all our stuff, and this MR must land there as well
[15:36] <zsombi_> brendand: or you can actually combine them :)
[15:36]  * zsombi_ goes offline now
[15:41] <bfiller> sil2100: can I request silos for line 39 and 41 please?
[15:42] <sil2100> bfiller: o/ we only have 1 free silo sadly, let me take a look at those
[15:42] <sil2100> Yeah, so... we would really be grateful if some silos got moved forward
[15:42] <bfiller> sil2100: line 41 would be more critical and quicker to land
[15:42] <sil2100> bfiller: any progress on silo 17?
[15:43] <sil2100> bfiller: let me assign that one then, but please try to get 17 released soon as well :)
[15:43] <bfiller> sil2100: oh
[15:43] <sil2100> silo 17 of course
[15:43] <sil2100> bfiller: it's a gallery-app landing
[15:43] <bfiller> sil2100: I didn't realize I had a silo for that already
[15:43] <bfiller> sil2100: ignore line 39
[15:43] <sil2100> bfiller: yeah, it even has packages built!
[15:43] <bfiller> sil2100: yes I will test silo 17 should be releasable today
[15:43] <bfiller> need to rebuild
[15:44] <sil2100> Excellent
[15:44] <sil2100> Then assigning 41 and removing 39
[15:44] <sil2100> Ok, I see it removed
[15:45] <elopio> plars, adding the webbrowser-app to the list of packages helped, but now it's complaining about the dependencies of webbrowser-app :)
[15:45] <elopio> it's sad to have to add them all.
[15:45] <plars> elopio: heh, well yeah
[15:45] <elopio> ogra_: what's citrain-push for?
[15:46] <plars> elopio: I think that's because phablet-config is locking it down to just install/update the things you tell it to
[15:46] <ogra_> elopio, it makes sure to only install the silo packages
[15:50]  * elopio tries
[15:52] <t1mp> elopio: there is a fix for the notes-app with the UITK landing, see https://code.launchpad.net/~zsombi/ubuntu-ui-toolkit/inverseMouseArea-update/+merge/223589
[15:53] <elopio> t1mp: nice! would it be too much to ask for a regression test?
[15:53] <elopio> otherwise, we might still be suffering with notes erros on the releases.
[15:55] <ogra_> sil2100, i have some issues with promoting (system-image script tracebacks ... trying to catch stgraber for help)
[15:55] <sil2100> ogra_: ACK
[15:58] <elopio> ogra_: citrain is not installed with phablet-tools
[15:58] <ogra_> phablet-tools-citrain
[15:58] <ogra_> (is the package)
[15:59] <elopio> plars: can you add that to the jenkins runner?
[16:00] <elopio> I think I can't do it through the jenkins config.
[16:00] <robru> whoever is using citrain-push please be advised it's deprecated, use 'citrain device-install' instead
[16:00] <plars> elopio: the whole job will have to be modified to use that if we want to do it instead I think, but I'll take a look in just a bit. Do we know for certain that we won't just run into the same problem with the citrain tools?
[16:00] <t1mp> elopio: good point
[16:01] <t1mp> elopio: depends how urgent it is.. it is zsombi's fix and he just eod'd
[16:01] <t1mp> elopio: I added the comment @ MR
[16:01] <robru> elopio, plars: also it's not magic, it uses phablet-config to install the packages. if phablet-config is broken somehow, you might try 'citrain device-upgrade' instead
[16:01] <elopio> plars: I can change the job config to run citrain. I don't know if it will fix the issue, but sounds likely.
[16:01]  * t1mp afk for now
[16:02] <plars> robru: yeah, I wondered as much
[16:03] <sil2100> robru: o/ meeting?
[16:03] <t1mp> elopio: I guess we'll add the regression test tomorrow. But feel free to test the branch in the meantime :)
[16:03] <robru> plars, elopio http://bazaar.launchpad.net/+branch/phablet-tools/view/head:/citrain here is the code if you want to review what it does (it's very simple). both of the available commands for installing silos on device use phablet-config
[16:05] <elopio> t1mp: that's ok, I'll file a bug for it.
[16:05] <plars> robru: elopio: looking at that, I think it's going to do the same sorts of things, so if you want to bring in other dependencies, you're likely going to have to specify them
[16:06] <plars> robru: is this a known limitation due to the safeties in place for pinning? That if you try to use the citrain (or phablet-config) tools to install a package from a ppa, you also need to specify the dependencies?
[16:06] <robru> plars, no i've never heard of that before
[16:06] <plars> robru: I think in elopio's case, it's wanting a newer version than what was available
[16:07] <plars> robru: and phablet-config seems to be doing some pinning
[16:07] <plars> I suspect to keep us from inadvertently updating things you don't intend to
[16:08] <robru> plars, I'd ping sergiusens about that... it seems like new behavior to me, i never had trouble installing packages with it
[16:08] <robru> (although I haven't tried recently)
[16:23] <ogra_> [16:24] <tedg> sil2100, robru, seems the bot disconnected
[16:24] <sil2100> Oh
[16:25] <robru> plars, http://bazaar.launchpad.net/+branch/phablet-tools/view/head:/phablet-config#L153 here is the relevant part of phablet-config, looks like it just calls add-apt-repository, apt-get update, and apt-get install. I don't see any sort of dependency pinning going on
[16:27] <plars> robru: it looks to be doing some stuff under _handle_writable_image though
[16:29] <robru> plars, how so? the part where it's copying debs around is only if you specify --package-dir on the commandline, which citrain tool doesn't do
[16:29] <plars> robru: hmm, maybe so. Then I'm confused how elopio ended up with the error he saw earlier
[16:30] <robru> plars, i didn't see the error (didn't read much scrollback) can you paste it?
[16:30] <plars> plars> webbrowser-app-autopilot : Depends: webbrowser-app (>= 0.23+14.10.20140617.1-0ubuntu1) but it is not going to be installed
 E: Unable to correct problems, you have held broken packages.
[16:31] <plars> robru: he tried adding webbrowser-app to his packages list, but then he said it continued to complain about other dependencies of webbrowser
[16:32] <robru> plars, so webbrowser-app-autopilot is arch:all while webbrowser-app is arch:any, this was probably just a temporary hiccup where the -autopilot package had published before the -app package did
[16:32] <robru> elopio, ^
[16:34] <plars> elopio: maybe retry?
[16:34] <robru> plars, which silo?
[16:35] <elopio> plars: for now, I'm running without webbrowser because I want to see results before going away for lunch.
[16:35] <plars> robru: I think he said it was 005
[16:35] <elopio> I'll keep trying afterwards.
[16:35] <robru> ahhhhhh
[16:35] <robru> run away ;-)
[16:35] <robru> that's the qt5.3 monster silo ;-)
[16:35] <plars> :)
[16:35] <robru> plars, i'm just flashing then I'll see if I can reproduce it
[16:36] <robru> looks like webbrowser-app was uploaded recently to that silo, so it's possible if elopio was trying this a couple hours ago that I might be right (seems consistent with my theory).
[16:37] <elopio> robru, plars: I retried just before the meeting.
[16:37] <robru> hm
[16:37] <robru> elopio, so what did you do? something like 'phablet-config writable-image --ppa ...05 -p webbrowser-app-autopilot ?
[16:38] <plars> robru: phablet-config writable-image -p python3-autopilot -p autopilot-touch -p libautopilot-qt -p libautopilot-gtk -p python-gi -p ubuntu-ui-toolkit-autopilot -p friends-app-autopilot -p mediaplayer-app-autopilot -p gallery-app-autopilot -p webbrowser-app-autopilot -p camera-app-autopilot -p dialer-app-autopilot -p messaging-app-autopilot -p address-book-app-autopilot -p ubuntu-system-settings-online-accounts-autopilot --ppa ppa:ci-
[16:38] <plars> train-ppa-service/landing-005
[16:38] <plars> robru: the log is at http://q-jenkins.ubuntu-ci:8080/job/qt-release-gatekeeper/label=daily-mako/7/console
[16:39] <sil2100> elopio, brendand: btw. do we have a bug for the overall calendar-app failures we've been seeing lately?
[16:39] <sil2100> elopio, brendand: it seems every time a different test is failing though
[16:39] <brendand> sil2100, no - i just have lots of individual bugs
[16:40] <sil2100> I'll mention it without a bug for now until we get some additional info
[16:41] <robru> plars, yeah it doesn't make any sense, webbrowser-app should anyway be installed because it's seeded in the phone, and also his command is full of other things where he only specifies -autopilot and those work (pulls in all deps correctly)
[16:41] <robru> more evidence for my version-mismatch publication-timing theory
[16:43] <cjwatson> -autopilot will have been built as part of the i386 build, and there's no particular reason that should've been in sync with the armhf build, so that's certainly possible
[16:44] <robru> cjwatson, thanks ;-)
[16:44] <robru> cjwatson, elopio, plars: although I just reproduced it locally, hrm: http://paste.ubuntu.com/7664567/
[16:45] <sil2100> ogra_: is it safe to send out the e-mail?
[16:45] <ogra_> sil2100, yup
[16:45] <elopio> oh, good.
[16:45] <sil2100> ogra_: image promoted properly? ;)
[16:45] <ogra_> see above :)
[16:45] <ogra_> (yes)
[16:45] <cjwatson> robru: add webbrowser-app to that apt-get install line and see what it says
[16:46] <sil2100> cjwatson: a kind reminder regarding unity-scope-click when you have a moment (the arm64 binaries needing removal and such)
[16:46] <sil2100> ogra_: thanks!
[16:46] <elopio> it will complaint about the webbrowser-app deps.
[16:47] <robru> elopio is right, that's totally bizarre http://paste.ubuntu.com/7664576/
[16:47] <robru> cjwatson, plars ^
[16:47] <plars> yeah, that's what he mentioned seeing earlier
[16:47] <robru> well it shoots a hole in my theory that it should have resolved itself by now ;-)
[16:47] <cjwatson> sil2100: ah right, done
[16:48] <sil2100> cjwatson: thank you very muchy o/
[16:48] <cjwatson> robru: ... and keep going until you get an error that makes sense
[16:48] <robru> cjwatson, on it, thanks
[16:48] <cjwatson> apt-get is not desperately helpful for this sometimes
[16:48] <cjwatson> but if you iterate it will eventually tell you something real
[16:50] <robru> cjwatson, plars, elopio: http://paste.ubuntu.com/7664589/ ah i think i've hit something. does this mean anything to you guys
[16:50] <robru> ?
[16:51] <robru> oxide-qt - 1.0.2-0ubuntu3 is in the silo...
[16:52] <slangasek> kgunn: ok, so I see all the packages are built now on armhf in landing-016, so I assume my work here is now done :)
[16:52] <cjwatson> and Depends: liboxideqtcore0 (= 1.0.2-0ubuntu3), too
[16:52] <cjwatson> robru: what about if you add liboxideqtcore0 as well?
[16:52] <plars> dependency hell!
[16:53] <plars> something has to be stopping it from resolving these, it doesn't make sense that we should have to specify each one
[16:53] <cjwatson> plars: you don't normally, of course, but manually specifying each is the way to get useful debugging information out of apt
[16:53] <robru> I need to submit a patch to apt-get to just do this recursion for us so that the first error message is the useful one
[16:54] <mhr3> cjwatson, could you kick unity-scope-click so it gets released? seems stuck in proposed
[16:54] <robru> cjwatson, if I add liboxideqtcore0 then it just works silently
[16:55] <cjwatson> mhr3: already done
[16:55] <cjwatson> robru: blink
[16:55] <mhr3> cool ,thx
[16:55] <robru> cjwatson, yes i'm stumped
[16:55] <cjwatson> robru: hang on, let me see if I can set this up in chdist locally
[16:56] <robru> cjwatson, ok, it's silo 5
[16:58] <dobey> do i need to ping someone directly to ack the NEW for unity-scope-click in utopic-proposed?
[16:58] <robru> barry, you around for some landing stuff or on lunch still?
[16:59] <cjwatson> dobey: there's no NEW
[16:59] <dobey> cjwatson: oh. i figured it would be blocked in NEW because we added a dep on libboost-locale
[17:00] <cjwatson> new deps don't attract NEW
[17:00] <dobey> ah ok
[17:00] <cjwatson> or we'd be doing nothing else :)
[17:00] <dobey> heh
[17:00] <cjwatson> dobey: as for why it's stuck in -proposed, you're the third person to ask here in the last fifteen minutes ;-) and I've dealt with it
[17:01] <cjwatson> (by removing the stale arm64 binary)
[17:01] <dobey> cjwatson: ok. thanks. i didn't read any backlog. just came back from lunch and saw it was still there.
[17:01] <dobey> thought it was due to the dep and the ubuntu-touch seed not having it.
[17:01] <dobey> thanks :)
[17:10] <robru> cjwatson, plars, elopio: I tried it again directly on the device to see if I could get any more information, so check this nonsense out: http://paste.ubuntu.com/7664673/
[17:11] <cjwatson> robru: I'm trying to reproduce it here with a hacked chdist instance; it appears to depend on the current installed packages state, since it doesn't reproduce from a clean chdist
[17:11] <cjwatson> just waiting for indices to download
[17:12] <cjwatson> (also chdist lets me play with this stuff without having to make the image writable, so is handy)
[17:12] <robru> cjwatson, so my steps to reproduce (with a mako) are: flash image 87, add silo 5, apt-get update, followed by that paste
[17:12] <cjwatson> right, I'm on 87 so should match
[17:12] <plars> robru: well, at least it looks like elopio could work around it for now if needs be so he's not blocked
[17:13] <cjwatson> I'm running up against EOD soon though
[17:13] <robru> plars, good point, specifying all the packages is a valid workaround. bizarre though
[17:13] <plars> robru: it shouldn't be necessary though I think, so hopefully it won't be a problem in the future if we can figure out how it got into that state
[17:14] <elopio> isn't it because of the pining that phablet-config does?
[17:14] <robru> plars, yeah, I'm at the end of my knowledge/ability here, maybe cjwatson can figure it, maybe he'll EOD and get to it tomorrow
[17:15] <robru> elopio, nope, see my most recent paste, I ssh'd into device and ran apt-get locally, no phablet-config involved, no possible pinning
[17:15] <cjwatson> elopio: it doesn't do that pinning without --package-dir
[17:15] <robru> elopio, also I checked the code for phablet-config and didn't actually see any pinning going on, I don't think it does that
[17:16] <robru> rigth
[17:16] <elopio> right.
[17:17] <elopio> cjwatson: well, don't delay your EOD for me. I'm good for now listing all the deps.
[17:18] <sil2100> ogra_: https://plus.google.com/109159869108744115904/posts/XzBWXpKiD84
[17:19] <cjwatson> elopio: yeah, I just want to take a bit of time to investigate before the evidence goes away :)
[17:19] <elopio> :)
[17:23] <barry> robru: i'm here
[17:23] <robru> barry, no worries, just had to reconfig one silo
[17:23] <robru> did it already ;-)
[17:24] <robru> barry, oh, you can free 18 though
[17:24] <robru> "merge and clean" i mean
[17:24] <barry> robru: just did it :)
[17:24] <robru> sweet
[17:25] <cjwatson> http://paste.ubuntu.com/7664735/ <- debug output
[17:25] <robru> barry, so we've got 2 silos free, 1 just published (free soonish I guess), and 3 requests marked ready:yes... think we should assign something?
[17:27] <robru> cjwatson, wow I can't read that
[17:27] <mhr3> robru, reconf 014 pls?
[17:27] <robru> barry, ^
[17:28] <barry> robru, mhr3 i could give it a try ;)
[17:28] <cjwatson> ok, you know what, this is going to take non-trivial thought, Kirsten is waiting for me, and you have a workaround, so I'm going to EOD
[17:29] <robru> cjwatson, haha, thanks. goodnight!
[17:29] <cjwatson> robru: http://www.chiark.greenend.org.uk/ucgi/~cjwatson/blosxom/ubuntu/2012-01-29-apt-resolver-bugs.html may be sort of vaguely helpful for context
[17:29] <cjwatson> but fortunately it isn't often necessary to stare at this
[17:30] <cjwatson> if necessary I'll punt to mvo
[17:31] <robru> cjwatson, I wonder... the workaround is for testing purposes, what happens when we publish this and this state gets into the archive? will the image builder fall over with this dep problem?
[17:31] <barry> robru: reconfigure failed, but maybe there was something else i needed to do: https://ci-train.ubuntu.com/job/landing-014-0-reconfigure/10/console
[17:32] <robru> barry, yeah you need to use the 'assign silo' job from the spreadsheet, the reconfigure job is the one that mhr3 could have done himself (and would have failed the same way since it's deliberately limited here)
[17:33] <robru> barry, the 'assign silo' tool is the nuclear option that only we have access to, the reconfigure job you ran is the one that anybody can run when they are only changing MPs within the same projects, not adding new projects
[17:33] <cjwatson> robru: well that's one reason I'd like to investigate, though my gut feel is probably not since I can't provoke it when running from a clean dpkg database
[17:33] <barry> robru: my notes, and the faq are a bit sparse on this point :)
[17:34] <robru> barry, when people ask for a reconfigure, it means they just did the reconfigure themselves and failed because they're trying to add a new project, so we have to re-assign to override that
[17:34] <cjwatson> it *looks* like a heuristic weighting failure with the oxideqt-codecs{,-extra} business, but I need to dig into it
[17:34] <robru> cjwatson, ok well if you don't think it's harmful then I guess we'll leave it.
[17:34] <robru> cjwatson, maybe for tomorrow ;-)
[17:35] <cjwatson> yeah, I'll certainly look further now that I have all the data
[17:37] <barry> robru: so for silo 14 to reassign, i am overriding that those packages are in other silos, since they conflict with the big qt5.3 silo
[17:38] <robru> barry, yeah. what I gathered from the meeting was that we shouldn't assign new silos that conflict, but if they already have a silo that conflicts there's no real harm in reconfiguring it with ignore flag set
[17:38] <robru> barry, just let mhr3 know that probably his silo will wait for qt5.3 landing at this point ;-)
[17:38] <barry> robru: ack
[17:38] <barry> mhr3: ^^ and your silo is reconfigured
[17:39]  * barry anticipates banana
[17:40] <robru> barry, http://youtu.be/WXzoZhuvFe0
[17:41] <barry> robru: the stuff of my nightmares
[17:41] <robru> LOL
[17:41] <mhr3> oh come on, there's a better one
[17:42] <sil2100> o/
[17:42] <mhr3> https://www.youtube.com/watch?v=0S7w4EK3ZqY
[17:42] <kgunn> fginther: so maybe you or someone you designate could help...but i think our mir-devel ci jenkins may need updating ?
[17:42] <kgunn> we're seeing the old gcc issue
[17:42] <kgunn> https://jenkins.qa.ubuntu.com/job/mir-mediumtests-runner-mako/1792/console
[17:42] <kgunn> that doko fixed y'day
[17:43] <kgunn> not sure why that fix hand't hit it...thot maybe cause we're on dedicated hw ?...and chron job  hadnt run ?
[17:44] <fginther> kgunn, is this related to all these 'relocation errors' I see in that build?
[17:44] <kgunn> fginther: could be?....which build do you mean ?
[17:45] <fginther> kgunn, that link you just sent. I see lots of messages simlar to: mir_performance_tests: relocation error: /usr/lib/arm-linux-gnueabihf/libmirprotobuf.so.0: symbol _ZSt14__once_functor, version GLIBCXX_3.4.11 not defined in file libstdc++.so.6 with link time reference
[17:45] <kgunn> fginther: ah yes...sorry, i was paying more attn to the once_functor
[17:45] <kgunn> and yes
[17:45] <kgunn> that is the signature of the gcc4.9 symbol issue
[17:46] <kgunn> so i think there was another bin released into archive that made the symbol look up happy
[17:46] <robru> mhr3, what is this i dont even
[17:46] <mhr3> robru, really? you've never seen charlie the unicorn?
[17:47] <mhr3> robru, watch them all! :)
[17:47] <mhr3> robru, although it's better with.... substances :P
[17:47] <robru> mhr3, yeah... i'll pass
[17:55] <robru> barry, I guess we should assign lines 43 and 44
[17:55] <fginther> kgunn, do you happen to know anything about the change doko landed, is it an updated gcc? I want to figure out if this should be present in the build env.
[17:55] <robru> barry, (my reasoning is, line 41 indicates it's unseeded so is kind of irrelevant, line 42 is ready:no)
[17:58] <barry> robru: agreed.  i will assign silos to 43 and 44
[17:58] <robru> barry, thanks
[18:00] <boiko> robru: hey, I was checking the spreadsheet, line 16 is already merged
[18:01] <boiko> robru: I guess it stayed there because there was this problem that it would not show the state from the assigned silo
[18:01] <robru> boiko, indeed those are merged. probably got lost in the ether somewhere
[18:01] <boiko> robru: yep
[18:02] <robru> boiko, ahh the status is landed but the status cell has lots it's formula for checking that
[18:02] <robru> barry, hey if you take a look at C16 in the spreadsheet, notice it's lost it's formula (it's just blank). I don't know why that happens, but if you copy the fomula down from C15 it'll fix it
[18:04] <barry> robru: how odd.  done
[18:05] <robru> barry, thanks
[18:15] <robru> barry, clean 15 please ;-)
[18:31] <robru> barry, thanks ;-)
[18:41] <fginther> kgunn, https://jenkins.qa.ubuntu.com/job/mir-mediumtests-runner-mako/1792/console was built before the fix landed. I say just re-approve and try again.
[18:49] <tedg> barry, Can I get a silo for line 41 please?
[18:50] <ricmm> barry: can I get one for line 37?
[18:51]  * ricmm totally first in queue
[18:54] <barry> ricmm: you conflict with silo 5, but that's the big qt5.3 branch.  robru indicated that new conflicts shouldn't be overridden
[18:55] <barry> tedg: you're problem is even more interesting: https://ci-train.ubuntu.com/job/prepare-silo/737/console
[18:55] <robru> ricmm, yeah, this was discussed in the meeting this morning, qt5.3 is going ahead soonish, we don't want to assign anything conflicting right now
[18:56] <robru> tedg, ricmm : also there are literally zero silos available
[18:56] <robru> wait, one just freed...
[18:57] <robru> i guess ted can have line 41
[18:57] <robru> barry, ^
[18:57] <ricmm> uhm
[18:57] <tedg> barry, Oh, weird. It's weird that it has a bzr id with my email, but I haven't pushed to that branch as well.
[18:57] <ricmm> I freed 15, which I was holding, with qtubuntu-sensors
[18:57] <ricmm> this is a second qtubuntu-sensors landing
[18:57] <barry> robru: yes, but see my response to tedg
[18:57] <ricmm> is qt 5.3 landing today?
[18:58] <robru> ricmm, should be as soon as mirv wakes up, later today
[18:59] <robru> tedg, right, so citrain depends on the destination trunk already having packaging. to fix this you'll have to just push to trunk first, then make a new null merge that we can put in a silo for release into distro
[18:59] <robru> barry, ^
[18:59] <ogra_> ricmm, for europeans: tomorrow :)
[18:59] <ricmm> tomorrow then
[18:59] <ricmm> right
[19:00] <tedg> robru, Uhg, okay.
[19:00] <tedg> charles, ^
[19:00] <barry> robru: ack.  tedg i need to reboot, but ping me when i return and if the branch is ready, i'll assign it
[19:01] <charles> tedg, ack
[19:01] <tedg> barry, Will do.
[19:36] <robru> tedg, ok you got 15
[19:36] <tedg> robru, Thanks!
[19:37] <robru> tedg, you're welcome!
[19:37] <barry> robru: ah, that's why it told me no silo was available.  hope i didn't fsck up the row
[19:38] <robru> barry, oh, I saw your email saying you were leaving, so I figured you were already gone and assigned it myself, sorry to step on your toes there
[19:39] <barry> robru: nope, no worries.  i'm here for a little while longer.
[19:39] <barry> robru: i'll update the topic when i'm out
[19:39] <robru> barry, ok cool
[19:56] <robru> barry, mmmm, publish 7 and merge 20 please ;-)
[19:58] <barry> robru: oo oo ah ah
[20:03] <popey> if anyone fancies trying to reproduce bug 1331753 that would be nice
[20:03]  * popey tickles cyphermox ☻
[20:03] <cyphermox> oy
[20:03] <cyphermox> nah, it's up to the indicator to handle this
[20:04] <popey> ok, cool, thanks!
[20:05] <barry> robru: okay, it's all you now :)
[20:05] <cyphermox> popey: I updated the bug, I'll try to reproduce it in a minute
[20:05] <popey> thank you cyphermox
[20:05] <popey> CRDA: Error: [Errno 2] No such file or directory: 'iw'
[20:05] <popey> interesting
[20:06] <robru> barry, take care!
[20:10] <robru> cyphermox, packaging ack pretty please? https://ci-train.ubuntu.com/job/landing-007-2-publish/21/artifact/packaging_changes_pay-service_0.1+14.10.20140618-0ubuntu1.diff ;-)
[20:18] <cyphermox> sure
[20:20] <cyphermox> robru: looks fine, but I'm not familiar enough with the click hooks to tell whether it's correct that it's /bin/true for now
[20:21] <cyphermox> popey: that part in the bug you can safely disregard
[20:21] <robru> cyphermox, ah, it says temporary, seems like a temporary NOP until something else gets implemented
[20:21] <cyphermox> but thanks for reminding me, it's about time we fix this hard
[20:22] <robru> cyphermox, hey how about this one? https://ci-train.ubuntu.com/job/landing-012-2-publish/47/artifact/packaging_changes_goget-ubuntu-touch_0.3+14.10.20140618-0ubuntu1.diff new binary package
[20:23] <cyphermox> isn't ubuntu-device-do (the new binary) missing Built-Using?
[20:24] <robru> cyphermox, I dunno, that's why you're the core dev ;-)
[20:24] <robru> cyphermox, I never heard of built-using before
[20:24] <cjwatson> err what.  it's not at all clear to me that it's valid for one click hook to depend on the output of another one like that
[20:24] <cyphermox> cjwatson: still re: pay-service?
[20:24] <cjwatson> yes
[20:25] <cjwatson> err in fact that's creating $HOME/.local/share/applications/$ID.desktop as the symlink target.  Won't that out-and-out conflict with ubuntu-app-launch's hook?
[20:25] <robru> cjwatson, i don't follow, the click-hook just looks like a NOP, I don't see it "depending" on anything
[20:26] <cyphermox> robru: there is the Pattern line
[20:26] <cyphermox> even then, the NOP in packaging is a red flag that something is wrong
[20:26] <cjwatson> robru: depending was me reading it backwards, but the Pattern line causes it to create those things as symlinks to ... something
[20:26] <robru> cyphermox, cjwatson: all I have to say is, presumably this was tested and found to be working by the upstream. I don't have any experience with click hooks
[20:26] <cjwatson> nack until somebody explains to me what the heck that's for :)
[20:27] <cjwatson> robru: and I do given that I wrote the infrastructure for them!
[20:27] <robru> cjwatson, i already published it on cyphermox go ahead, so you better block it in proposed
[20:27] <cyphermox> cjwatson: I thought you'd have known :/
[20:27] <cjwatson> cyphermox: nobody asked me about this, no
[20:27] <cyphermox> robru: I didn't really say to go ahead, just that it looked fine except for that part
[20:27] <cjwatson> can somebody please file a bug on pay-service in Ubuntu, add the block-proposed tag to it, and subscribe me?
[20:27] <cjwatson> I have to run
[20:27] <cyphermox> I will
[20:27] <robru> cjwatson, ok
[20:28] <cjwatson> I can follow up in the morning
[20:28] <robru> cyphermox, oh ok, you do it
[20:28] <robru> ;-)
[20:28] <cjwatson> it's not the Exec that bothers me, it's the Pattern, FWIW
[20:28] <cyphermox> cjwatson: fair enough
[20:29] <cjwatson> "Exec: /bin/true" is just entirely pointless, it could remove that line and do less work to the same effect
[20:29] <cyphermox> robru: poke sergiusens; I think that new binary package ubuntu-device-do is missing Built-Using, it's there for the other binaries
[20:29] <cyphermox> cjwatson: yes
[20:30] <cjwatson> tedg: ^- please see above conversation - I think "Pattern: ${home}/.local/share/applications/${id}.desktop" is an invitation to strange behaviour; I'd like an explanation of what that's intended to achieve, and a discussion of how to do it better
[20:30] <robru> cyphermox, ah, it's a static linking thing, that explains why I never saw it before
[20:30] <cyphermox> robru: yes
[20:30] <cjwatson> Built-Using is a relatively new thing - our infrastructure should support it but doesn't yet
[20:30] <cjwatson> Nevertheless it's a good idea to include it so that we can catch up with it later :)
[20:31] <cyphermox> but since that's just another binary like the others in that source package, I think it should still be there
[20:31] <tedg> cjwatson, Since we can't use trusted session yet, it was so that the pay ui can still use the UAL to launch, but switch to using the click hook for definition in its manifest.
[20:31] <tedg> cjwatson, The goal would be to move the location once we have trusted sessions to start the pay ui.
[20:31] <cjwatson> tedg: but that hook is asking for the .desktop file to be created as a symlink to something in the click package attaching to that hook
[20:31] <cjwatson> tedg: that actively conflicts with UAL
[20:31] <tedg> cjwatson, Only if it has a pay-ui and a desktop section.
[20:31] <cjwatson> tedg: not the point
[20:32] <cjwatson> tedg: we shouldn't design things so that a click package can cause the system to break
[20:32] <tedg> UAL isn't the only person writing to the applications directory though.
[20:32] <tedg> I'm confused on how it'll cause the system to break.
[20:33] <cjwatson> can't pay-ui use some other location?
[20:33] <tedg> Not yet, it will for sure as soon as I can, but looking for something temporary.
[20:33] <cjwatson> because you'll have two different things writing to the same location and each expecting that they exclusively own it - it could well cause exceptions on app installation
[20:34] <tedg> We already have to deal with multiple people writing to that directory though. For instance, wine does as well.
[20:34] <cjwatson> wine doesn't write anything in the click id form
[20:34] <cjwatson> that conflict is theoretical but unlikely to actually happen
[20:35] <cjwatson> this one would be very easy to trigger just with a carefully-constructed click package
[20:35] <cyphermox> fwiw, https://bugs.launchpad.net/ubuntu/+source/pay-service/+bug/1331786
[20:35] <cjwatson> and half the point of click was not to have to worry about carefully-constructed packages
[20:35] <tedg> Sure, you'd have to construct it that way. And we're not going to let anything with pay-ui into the store without review anyway.
[20:35] <cyphermox> I put in everything I could think of that would be useful, but tbh I know nothing of click and click-hooks, I'll have to read up on it
[20:36] <cjwatson> I would be happier if you put the hook symlink targets somewhere else and had an Exec program to copy them over, so that something can arbitrate
[20:36] <cjwatson> even if that's a trivial thing right now
[20:36] <sergiusens> cyphermox: robru it's harmless; but I can add it now or later
[20:36] <tedg> Honestly, I don't mind changing it. It's really only meant to be a temporary hack to get it so that pay-ui can not use the desktop hook.
[20:36] <cjwatson> that also means the exceptions aren't going to show up in click when somebody gets this wrong
[20:36] <tedg> Heh, okay.
[20:36] <robru> sergiusens, yeah, cyphermox and cjwatson are insisting on adding it now ;-)
[20:37] <cyphermox> sergiusens: right now the binary is inconsistent with the others in the source, I'd like it to be added please
[20:37] <sergiusens> cyphermox: robru I'll add it now
[20:37] <cyphermox> thanks
[20:37] <robru> sergiusens, thanks!
[20:37] <tedg> cyphermox, cjwatson, so do you want that in this silo or another MR?
[20:37] <cjwatson> which I realise sounds like erecting a not-my-problem field but I think it would be genuinely helpful for crash reports to show up under pay-service rather than under click so that they can be dealt with more appropriately
[20:37] <sergiusens> cyphermox: yeah, it's just a hiccup... the Built-Using is being added in a different MR that doesn't have this new bin
[20:37] <cyphermox> tedg: it will need to be a new MR
[20:37] <cjwatson> I have to go read bedtime stories so I'll leave that decision to somebody else :)
[20:37] <cjwatson> sorry for the spanner in works
[20:38] <tedg> cjwatson, Have fun!
[20:38] <cyphermox> cjwatson: thanks
[20:38] <sergiusens> cjwatson: do you know if the debian infra supports Built-Using in some way?
[20:39] <cyphermox> sergiusens: it's in the policy manual at least
[20:39] <cyphermox> if it's not yet handled, it's at least allowed to be in
[20:40] <sergiusens> cyphermox: I know about Built-Using, I'm using it; but I'm not sure how it's used in any infra if at all but manually eye balling it
[20:40] <cyphermox> I don't know about infra, but you could easily enough grep through files to catch the instances of Built-Using: XYZ to account for things
[20:42] <robru> boiko, you got 20
[20:42] <boiko> robru: thanks!
[20:43] <robru> boiko, you're welcome!
[20:44] <boiko> robru: is it really 20? the landing-020 sheet doesn't seem to be working
[20:45] <robru> boiko, it's just slow to update, you can click build as soon as I say the number though and jenkins knows what to do before the spreadsheet does
[20:45] <boiko> robru: ah ok, got it :)
[20:45] <robru> boiko, http://people.canonical.com/~rbpark/citrain/ this page shows silo 20 ready to go for you
[20:46] <boiko> robru: now it is ok on the spreadsheet too
[20:46] <robru> boiko, yep, just slow ;-)
[20:46] <boiko> hehe
[20:53] <sergiusens> cyphermox: can you ack this? https://code.launchpad.net/~sergiusens/goget-ubuntu-touch/built_using_for_do/+merge/223648
[20:53] <robru> sergiusens, acked
[20:53] <sergiusens> ty
[20:54] <robru> you're welcome
[21:10] <renato> fginther, jenkins is reporting this strange error: https://jenkins.qa.ubuntu.com/job/generic-deb-autopilot-runner-mako/1396/?
[21:16] <fginther> renato, these are the system settle tests that run before and after each test suite (also does this during smoke testing).
[21:17] <renato> fginther, is that related with my project?
[21:17] <fginther> the tests expect the system to be very close to idle between tests
[21:17] <renato> or is this a generic error?
[21:17] <fginther> renato, I'll check a few other runs
[21:25] <fginther> renato, of the past 12 runs, only the two most recent ones show this problem
[21:26] <fginther> renato, this failure is usually caused by something else in the image (a runaway upstart job for example)
[21:27] <renato> fginther, do you know if all the tests run ok? or this fail came first?
[21:29] <bfiller> robru: need a silo for line 36 if any available
[21:31] <fginther> renato, this failure was after the autopilot tests ran
[21:32] <fginther> the ap tests passed
[21:32] <renato> fginther, thanks
[21:32] <renato> bfiller, ^^
[21:37] <robru> bfiller, sorry, not yet... soon though
[21:37] <bfiller> robru: I just did merge and clean on 17 so that should be free soon
[21:37] <robru> bfiller, cool
[21:38] <robru> sergiusens, published 12
[21:38] <sergiusens> robru: thanks
[21:38] <robru> sergiusens, you're welcome
[21:38] <robru> bfiller, heh, it's a race, 7 or 17, which will free first?
[21:42] <robru> ugh, spreadsheet is down
[21:43] <tedg> Bummer, just added a line.
[21:43] <robru> tedg, wow, it's back and your line is still there, that's a new one on me ;-)
[21:43] <tedg> Woot!
[21:43]  * tedg has defeated The Google!
[21:44] <robru> tedg, http://www.infectionmusic.com/tbass/blogspot/images/dilbert.gif
[21:50] <bfiller> robru: 17 freed :)
[21:51] <robru> bfiller, and you got 7 ;-)
[21:51] <bfiller> haha, nice
[21:51] <robru> tedg, you got 17
[22:03] <tedg> robru, Cool, building away!
[22:05] <cjwatson> sergiusens: I believe dak supports it, yes; the intended use was to allow it to keep sufficient sources referenced in the archive to satisfy GPL / general sanity requirements
[22:06] <cjwatson> LP should clearly do the same, just not enough engineers
[22:06] <cjwatson> Hopefully we'll get to it eventually ...
[22:42] <sergiusens> ok, so it seems from http://osdir.com/ml/debian-dak/2011-03/msg00095.html that it just makes sure that the sources can be found; which I guess then leads to rdep rebuilding when a reffed Built-Using verson changes to move the archive forward
[22:44] <robru> sergiusens, I would say, being able to programmatically determine when to rebuild statically linked rdeps is an enormous win
[22:44] <robru> otherwise you could have security vulnerabilities patched in libraries and have no idea which rdeps are still vulnerable
[22:45] <sergiusens> yeah, I think the plan is to somehow automate that and the whole controversy currently around golang in the archives from a security PoV
[22:46] <robru> sergiusens, yeah
[22:46] <robru> ok, I gotta run out, back in ~2hrs
[22:51] <cjwatson> sergiusens: rebuilding, or at least making sure that multiple sources are shipped in a suite if that's what's needed
[22:52] <cjwatson> sergiusens: but yeah, of course the ideal would be to not need to ship multiple sources
[22:52] <cjwatson> sergiusens: even without infrastructure support it's still possible to use grep-dctrl or whatever to go through Built-Using fields