[05:29] <bzoltan1> hello zsombi
[05:29] <zsombi> bzoltan: hai
[05:30] <bzoltan> zsombi:  have you heard anything from elopio or kalikiana about the AP failures I linked yesterday?
[05:30] <zsombi> bzoltan: nopez
[05:31] <bzoltan> zsombi:  it would be cool to get back the 1-2 days release cycle ... but it seems to be impossible
[05:34] <zsombi> bzoltan: well... and this time I haven't seen any UITK related failures... but aing tot anything confirmed...
[05:39] <elopio> bzoltan: I'm sorry, today I was stuck with apps
[05:39] <elopio> and tomorrow I'll be on holidays.
[05:39] <elopio> I can help on wednesday.
[05:49] <bzoltan> elopio:  for me that silo16 with this failures http://pastebin.ubuntu.com/7690500/ seem to be tottaly safe
[07:19] <kalikiana> bzoltan: I struggled to repro as my phone discharges faster than it can charge
[07:19] <kalikiana> as soon as I do so much as enable wireless :-(
[07:59] <sil2100> bregma: hi! Once you're around: I have some minor nitpicks about the packaging changes of libgrip in your silo
[08:03] <sil2100> ogra_: hey! I would need a core-dev packaging ACK for some of the main package in the blank powerd policy changes silo
[08:04] <ogra_> sil2100, why, isnt that landing from rsalveti ?
[08:04] <sil2100> ogra_: yeah, but he's not the author of the commits - you think he reviewed all the branches?
[08:05] <sil2100> He's just one of the landers
[08:05] <ogra_> if he took care of the silo i would expect so ... but let me take a look
[08:05] <sil2100> So I don't have certainty that he was the one reviewing
[08:05] <sil2100> ogra_: anyway, diffs: https://ci-train.ubuntu.com/job/landing-020-2-publish/lastSuccessfulBuild/artifact/packaging_changes_powerd_0.16+14.10.20140620-0ubuntu1.diff , https://ci-train.ubuntu.com/job/landing-020-2-publish/lastSuccessfulBuild/artifact/packaging_changes_indicator-power_12.10.6+14.10.20140620.1-0ubuntu1.diff
[08:06] <sil2100> The universe components had small changes, recommends additions and etc. which I +1'ed
[08:06] <sil2100> These look safish as well I guess
[08:08] <ogra_> sil2100, looks fine to me, ACK
[08:08] <sil2100> \o/
[08:08] <sil2100> ogra_: thanks
[08:09] <ogra_> sil2100, hmm, btw ... powerd = universe
[08:09] <sil2100> Oh, powerd as well?
[08:09] <ogra_> you could have acked yourself ;)
[08:09] <sil2100> I actually only checked indicator-power and assumed powerd is the same ;)
[08:09] <sil2100> Packages with power should be in main, as main has power
[08:10] <ogra_> haha
[08:12] <seb128> sil2100, ogra_: -1 for indicator-power
[08:13] <ogra_> seb128, is it in desktop ?
[08:13] <seb128> unity-system-compositor and powerd are in universe and not on all architectures
[08:13] <seb128> indicator-power is used on desktop and in main
[08:13] <ogra_> dang, we need to get rid of that desktop stuff :P
[08:14] <ogra_> sil2100, right, cant do that
[08:15] <sil2100> :|
[08:15] <sil2100> No worries
[08:15] <sil2100> seb128: thanks!
[08:16] <ogra_> yeah, i would have forgotten about that
[08:16] <ogra_> i guess it wants to become a suggests ... on the phone both packages are seeded anyway
[08:16] <seb128> ogra_, sil2100: how can you ack stuff like that? you for sure should know for sure that main can't build-depends on universe
[08:17] <ogra_> seb128, its not a build dep
[08:17] <seb128> depends sorry
[08:17] <seb128> binaries in main can't depends on binaries in universe
[08:17] <seb128> but for sure you know that?
[08:17] <ogra_> yes
[08:18] <sil2100> Yeah... sorry for that, I only took a look at the two other components that were universe-related
[08:18] <sil2100> i.e. unity-system-compositor and media-hub changes
[08:34] <Laney> sil2100: We've just been talking about this, I'll do one to move those to suggests
[08:34] <Laney> i-power handles the case when they're not present
[08:37] <seb128> it's also slightly disturbing that this mp is being landed while not approved yet
[08:38] <seb128> rsalveti, kgunn ^ shouldn't the mp be top approved before being put up for landing?
[08:43] <Laney> okay I proposed https://code.launchpad.net/~laney/indicator-power/depends-to-suggests/+merge/224246, please add that if approved
[08:43] <thostr_> could anybody configure silo 7 (I cannot as we added a new component)
[08:48] <jibel> on http://ci.ubuntu.com/smokeng/utopic/touch/mako/94:20140623:20140530/8685/gallery_app/ why are some tests listed several times? For example test_camera_button_visible appears 3 times
[08:50] <jibel> ah, nm, it's because the dashboard only shows the name of the test, not the full name with the testsuite
[08:52] <sil2100> thostr_: sure
[08:54] <Laney> (I added it myself)
[08:55] <jibel> brendand, could you look why TestPhotosView.test_camera_button_visible passed while it's impossible to reveal the toolbar?
[08:56] <jibel> brendand, I think the test should wait until the toolbar autohides, then reveal it and continue.
[08:56] <brendand> jibel, probably, yes
[08:57] <brendand> sil2100, my morning is packed, so i'll have answers on those failures sometime around lunch
[08:58] <jibel> brendand, gallery app tests should be almost completely red.
[08:59] <brendand> jibel, well if that was the test method then yes they would be i guess
[09:00] <brendand> jibel, it's only because the test sometimes catches it when it's auto-revealed that any pass
[09:03] <sil2100> brendand: sure :)
[09:05] <sil2100> thostr_: reconfigured - when you have some CI train business it's best to say 'trainguards', as all CI Train people will get a ping then ;)
[09:06] <thostr_> sil2100: thanks and good to know
[09:06] <sil2100> bzoltan: hey! Any possibility we'll have the new UITK sometime soon? The silo is already waiting for a really long time ;)
[09:07] <bzoltan> sil2100:  the silo16 should be about a day old.
[09:07] <bzoltan> sil2100:  the previous one landed as far as I know.
[09:08] <sil2100> bzoltan: uh, I don't think it landed, we still get the UITK failure as before which was supposed to be fixed with the UITK landing
[09:08] <sil2100> Let me check the commit logs
[09:09] <sil2100> bzoltan: hm, you might be right, I guess it got landed during my holidays
[09:09] <sil2100> Strange that we still get that failure then
[09:09] <sil2100> Maybe it's a different one then
[09:11] <sil2100> bzoltan: ok, ignore my doubts, it seems it's a new failure... we'll fill in a bug an poke you later ;)
[09:11] <sil2100> Sorry for the confusion
[09:11] <sil2100> brendand, ogra_: so, it seems we have a new UITK failure
[09:11] <ogra_> huh ?
[09:12] <ogra_> oh, true !
[09:13] <ogra_> woah
[09:13] <ogra_> OSError: [Errno 8] Exec format error
[09:13] <ogra_> that looks like it tries to exec x86 binaries or some such
[09:21] <t1mp> sil2100: this one? https://bugs.launchpad.net/ubuntu-ui-toolkit/+bug/1332162
[09:23] <ogra_> yeah, looks like it
[09:33] <sil2100> Yeah
[09:37] <Laney> feel free to reconfigure/rebuild silo 20 now, indicator-power's fix got approved
[09:37] <Laney> and the original mp too
[09:41] <alan_g> vila: can you help? "cp: error writing 'debian/mir-test-tools//usr/bin/mir_unit_tests': No space left on device" - https://jenkins.qa.ubuntu.com/job/generic-mediumtests-builder-utopic-armhf/1964/console
[09:41] <sil2100> Laney: thanks!
[09:42] <Laney> np
[09:44] <vila> alan_g: urgh
[09:44] <vila> alan_g: let me look
[09:58] <vila> alan_g: 400MB only for /tmp that's probably where things break, I'll need retoaded to remaster all cyclops nodes, can you reproduce locally to estimate how much you need ?
[09:59] <alan_g> vila: mo...
[10:01] <alan_g> vila: it's probably an overestimate (as not all are shipped), but the executables and libraries in my local build add up to 450Mb
[10:05] <vila> alan_g: ack, I'll need to check with fginther and retoaded if bumping the tmpfs to 512MB is reasonable. I'm worried though, those nodes are configured to run up to 2 jobs at the same time so this may not be enough anyway. You may want to investigate if/when you started consuming that much space ?
[10:07] <tvoss> sil2100, ping
[10:07] <alan_g> vila: better estimate (still an upper bound): 327M
[10:08] <vila> alan_g: hold on, I read the wrong line it seems, it's not 400MB, it's 2GB already
[10:09]  * alan_g denies using all that
[10:11] <vila> alan_g: right, it may be more involved than it looks, those 2GB may be shared across several uses
[10:11] <vila> alan_g: rebuild triggered at http://s-jenkins.ubuntu-ci:8080/job/generic-mediumtests-builder-utopic-armhf/1970/console
[10:12] <vila> alan_g: it went on a different node, let see if we can reproduce there
[10:12] <alan_g> vila: ack
[10:13] <vila> alan_g: pfew, previous run took ~2h ? Does that match your expectations ?
[10:14] <alan_g> vila: sadly, yes
[10:17] <alan_g> If folks must insist on building on feeble kit they could at least use cccache
[10:21] <cjwatson> Our primary builders tend not to benefit much from ccache because they build far too many different things on too many different nodes; I suspect similar is true for Jenkins-based builds
[10:22] <cjwatson> Maybe not to quite the same extent
[10:27] <alan_g> cjwatson: I know there are scaling issues (although there are probably solutions). But it can be frustrating waiting five hours to autoland something that just built in CI.
[10:47] <sil2100> mandel: hi! Looking at your u-d-m landing now - did you make sure no one uses the common.h include?
[11:11] <mandel> sil2100, yes, no one does
[11:11] <mandel> sil2100, 100% sure since it is a not exposed header
[11:11] <mandel> sil2100, nad I recompiled a couple of project to make sure
[11:14] <sil2100> mandel: ok, thanks :)
[11:22]  * sil2100 tries to get his system back to an usable state
[12:04] <sil2100> ogra_: as most Tuesdays I might not make it for todays evening meeting due to practice
[12:04] <sil2100> So could you lead it if I wouldn't be around?
[12:11] <ogra_> sil2100, sure
[12:11] <sergiusens> fginther: sil2100 hey guys, gatox is building the first pure click package we ever saw;
[12:12] <sergiusens> ci is completely busted with this scenario
[12:12] <sergiusens> fginther: can you make https://code.launchpad.net/~diegosarmentero/pay-ui/pay-backend/+merge/223642 just build clicks and not debs?
[12:14] <sil2100> ;)
[12:15] <sil2100> sergiusens: ok, that's good to know...
[12:15] <gatox> this one is the latest: https://code.launchpad.net/~diegosarmentero/pay-ui/pay-backend/+merge/224196
[12:17] <bregma> sil2100, I'm back on the internets again, what was your concern with my libgrip packaging?
[12:24] <sil2100> bregma: hi! So, first of all most of the concerns are really minor packaging things but would like to get those fixed before publishing: first of all, you removed some comments and trailing commas
[12:25] <sil2100> bregma: the other thing is also that there were build dependencies changed but not mentioned in the changelog
[12:26] <sil2100> bregma: same for the removal of python-grip binary package - this should be mentioned in the changelog (i.e. in the respective commit message) as otherwise we will not know easily when it has disappeared
[12:29] <bregma> sil2100, I'm not aware of any build dependency changes, I simply did a wrap-and-sort so I could more easily diff against the Debian packaging (ci-train is boken when it comes to working as a downstream)
[12:29] <bregma> but I can update the changelog to me more clear about deprecating the python- package
[12:30] <ricmm> sil2100: hey, could I get a silo for line 27 ?
[12:35] <sil2100> ricmm: sure, am having lunch right now
[12:36] <ricmm> alright
[12:37] <seb128> ricmm, hey!
[12:38] <seb128> ricmm, we need you, see -touch, the qtubuntu-sensors made unity8 desktop unhappy
[12:40] <Chipaca> gah. where's the new ci-train spreadsheet? I've only got links to the old one
[12:46] <cjwatson> https://wiki.ubuntu.com/citrain
[12:47] <Chipaca> cjwatson: meta-thanks
[12:48] <fginther> sergiusens, I have work for that in progress.
[12:49] <sergiusens> fginther: I setup something to sync on a hangout for later today
[12:49] <fginther> sergiusens, thanks
[12:51] <sergiusens> fginther: of interest would be to be able to build fats
[12:51] <sergiusens> :-)
[12:51] <sergiusens> it's winter here, so fat is good :-P
[12:52] <fginther> sergiusens, :-)
[13:06] <tvoss> sil2100, around?
[13:06] <sil2100> tvoss: sure
[13:07] <bregma> sil2100, just letting you know I've updated my libgrip d/changelog, I'm going to rebuild silo 006 to pick it up
[13:08] <Chipaca> hiya peeps. Could I have a silo for row 28 please?
[13:09] <ogra_> davmor2, wow ... i know what you meant yesterday with the google logo ... the first boot on 95 takes several centuries ...
[13:09] <ogra_> i wonder why
[13:09] <davmor2> ogra_: :)
[13:09] <davmor2> ogra_: the bit after the google logo took about the same amount of time
[13:10] <davmor2> ogra_: It was just the waiting for the google logo to go that took forever
[13:11] <ogra_> davmor2, the second boot is fine ... i assume the apparmor profile generation on first boot got slower
[13:12] <ogra_> stopwatching the second boot i get 10-12sec with the google logo and 11-13 for the boot animation ... latest after 25 sec i have the UI on screen
[13:12] <ogra_> so i guess we can blame apparmor here
[13:14] <davmor2> ogra_: :)
[13:15] <ogra_> mterry, nice first boot wizard !
[13:15] <mterry> ogra_, yay!
[13:15] <davmor2> mterry: not so nice if you have a different back drop though
[13:16] <mterry> davmor2, backdrop?  You mean if you've changed the greeter wallpaper?
[13:17] <davmor2> mterry: Yes if you upgraded to the image and had change the greeter to one that is mostly black and white the text is really hard to see
[13:17] <davmor2> change to greeter wallpaper even
[13:17] <mterry> davmor2, ah fair.  That's a temporary issue during upgrades though.  Most users will only see this the first time they boot
[13:18] <ricmm> sil2100: hey, any chance to get the silo for27 ?
[13:18] <davmor2> mterry: but your assumming that oem's won't change the backdrop though ;)
[13:18] <mterry> davmor2, no, but if they do, they'll see the effect on the wizard
[13:18] <davmor2> true
[13:18]  * jdstrand notes that server side generation of profiles on the default image should be landing this week
[13:19] <jdstrand> (as I'm told)
[13:19] <sil2100> ricmm: let me take a look, one moment
[13:19] <ricmm> thank you
[13:19] <ogra_> jdstrand, oh, cool !!
[13:20] <kgunn> sil2100: hey there, so we tested silo 20 & marked it "Yes" for tested so it would be released...i just checked this morning
[13:20] <sil2100> ricmm, tvoss: ok, so both of you have platform-api and qtubuntu-sensors
[13:20] <kgunn> and looks like someone marked it "no"
[13:21] <kgunn> any ideas?
[13:21] <sil2100> kgunn: yeah, so...
[13:21] <sil2100> kgunn: I wanted to publish that but then it was -1'ed for release
[13:21] <ricmm> sil2100: which line is tvoss'
[13:21] <ricmm> ?
[13:21] <tvoss> ricmm, 11
[13:21] <sil2100> ricmm: silo 11, line 22 - it's a 'test silo', but tvoss mentioned it lanind this week
[13:21] <Chipaca> robru: does you being sheriff mean requests for silos go to you?
[13:21] <sil2100> kgunn: ok, let me continue my explaination
[13:22]  * kgunn was being patient :)
[13:22] <ricmm> tvoss: do you mind letting me through? need to fix a crasher for unity8 on desktop
[13:22] <tvoss> ricmm, fine with me
[13:22] <ogra_> Chipaca, it means you can shoot him and make a song about it
[13:22] <ogra_> ;)
[13:22] <ricmm> tvoss: my silo is ready to land as soon as someone helps me test
[13:22] <ricmm> tvoss: thanks
[13:22] <ricmm> sil2100: ^
[13:22] <sil2100> kgunn: so, during packaging ACKing we noticed that some main packages suddenly depended on universe packages
[13:22] <sil2100> kgunn: which is trouble
[13:23] <sil2100> kgunn: so Laney devised a fix, we reconfigured and rebuilt ;p
[13:23] <sil2100> ricmm: ACK
[13:23] <ogra_> kgunn, worse was that the MP wasnt top approved yet though ...
[13:23] <ogra_> (indicator-power)
[13:23] <ogra_> it is all sorted now ... but i guess you want to re-test
[13:24] <sil2100> ricmm: assigned!
[13:24] <ogra_> sil2100, CI should really refuse to land stuff if there is no top approval
[13:24] <Chipaca> ogra_: https://www.youtube.com/watch?v=GCY_GKX09AE
[13:24] <kgunn> sil2100: ogra_ ok, will retest....and i'll follow up on the mp approval
[13:24] <sil2100> ogra_: hmmm... good idea!
[13:25] <ogra_> Chipaca, hah
[13:26] <ricmm> sil2100: thanks!
[13:26] <sil2100> ogra_: will work on that today I guess :)
[13:26] <ricmm> sil2100: back to good old silo 5 :)
[13:26] <ogra_> sil2100, ++
[13:31] <Chipaca> sil2100: robru: I'm unsure who i'm supposed to ping to ask for a silo, but i'd like one for row 28, pretty please
[13:31] <sil2100> Chipaca: hi! Let me take a look
[13:31] <Chipaca> sil2100: hi :)
[13:31] <sil2100> Chipaca: ah! Ok, so, if you want a silo you need to switch the 'Ready' field to Done
[13:31] <sil2100> Otherwise we don't consider a landing ;)
[13:31] <sil2100> So it could just sit there forever ;p
[13:34] <Chipaca> sil2100: done!
[13:34] <Chipaca> sil2100: I have to ask for it anyway, once it's ready? or does setting it to ready get me a silo automagically?
[13:35] <sil2100> Chipaca: we have to give a silo ourselves, but once it's set to ready we either see it ourselves when scouting the spreadsheet or just get pinged by the bot that someone added a ready landing
[13:35] <sil2100> So no need to poke, unless there's something important to mention ;)
[13:39] <Chipaca> I'll get the hang of it someday
[13:40] <sil2100> No worries!
[13:51] <brendand> sil2100, i can't reproduce either the weather or filemanager issue
[13:51] <brendand> sil2100, i'll file bugs for both of them to keep track
[13:53] <rsalveti> kgunn: ogra_: I can help landing 20 as well, not sure if everything got properly reviewed and top approved
[13:53] <rsalveti> but good that it was tested by qa already
[13:53] <ogra_> rsalveti, its all fine now
[13:53] <rsalveti> well, we still need to land it :-)
[13:54] <ogra_> yep ... but the other issues are fixed
[13:57] <rsalveti> seb128: it's fine to start a silo with mrs that are not yet top approved
[13:57] <rsalveti> seb128: the only problem is landing such silo in that state
[13:57] <seb128> rsalveti, right
[13:58] <seb128> rsalveti, well, somebody asked for packaging review on that one, so I assume it was about to land
[13:58] <seb128> rsalveti, not to mention that it was adding universe depends to a package in main, and things we don't want on the desktop (like powerd and the system compositor)
[13:59] <seb128> rsalveti, anyway, was an easy one, the code handle those not being there, Laney demoted them to suggest, so should be all good ;-)
[13:59] <sil2100> brendand: ok, thanks!
[13:59] <rsalveti> seb128: right, but it wasn't ready for landing yet
[14:00] <rsalveti> seb128: the testing flag was set to yes
[14:00] <rsalveti> and that's why I believe sil2100 tried to land it
[14:00] <rsalveti> but not every mr was reviewed/approved yet
[14:00] <seb128> k
[14:00] <rsalveti> maybe the issue was that the testing was set to done when the work wasn't really done
[14:00] <seb128> yeah
[14:00] <seb128> lander assume they can land stuff that are "tested: yes"
[14:00] <seb128> they take it as "ready to land"
[14:00] <rsalveti> right
[14:00] <sil2100> Right, it was set to tested -> done, as kgunn said he tested it and switched that to yes
[14:01] <rsalveti> right, that was the issue then
[14:01] <sil2100> I'm changing CI train to not allow (without an override) to build unapproved branches
[14:02] <rsalveti> right
[14:06] <sil2100> bregma: oh my, the changelog looks soo sassy!
[14:17] <Chipaca> sil2100: sassy changelog? do share!
[14:19]  * kgunn wonders if changelogs can be sassy/
[14:20] <kgunn> sil2100: can i get a silo for line 29 ? ....all the mp's are approved ;P
[14:21] <sil2100> kgunn: hehe ;) Sure, sorry, was inside some packaging work
[14:22] <kgunn> i'm sorry about that mp slipping thru...
[14:22] <kgunn> i think it might have been a late add....that was a rather dynamic list of mp's
[14:22] <sil2100> kgunn: remember that you have another unity-mir silo assigned for testing of the trusted sessions
[14:24] <kgunn> sil2100: yeah, that trusted sessions is only for testing right now...so
[14:24] <tvoss> sil2100, can I get a silo for line 30?
[14:24] <kgunn> they one i'm asking for is for landing
[14:25] <sil2100> tvoss: set it to Ready yes! :) And assigning
[15:00] <davmor2> sil2100: I think there is an issue with the osk and scopes on the latest flo I'm going to reboot and see what happens then
[15:11] <sil2100> davmor2: what seems to be the problem?
[15:12] <davmor2> sil2100: mterry: I think after a boot with the welcome screen the osk is screwed up a bit.  It doesn't appear properly till you reboot the device then it works fine.  I'll do a fresh install to confirm and grab some logs
[15:14] <mterry> davmor2, hrm
[15:14] <Saviq> sil2100, hey, could we get a silo for line 4? I promise, we'll land it this time!
[15:14] <mterry> davmor2, thought I tested that -- we should be killing maliit-server when done with wizard
[15:15] <sil2100> Saviq: !
[15:15] <davmor2> mterry: yeah that might be the issue it isn't coming back up :)
[15:15] <sil2100> Saviq: ok, but I already see some of the projects there are locked currently
[15:16] <Saviq> sil2100, I'll deal with that as needed
[15:16] <sil2100> mterry: shame on youuu! Killing things is a dirty workaround ;)
[15:17] <mterry> sil2100, maliit-server is tied to the current MIR_SOCKET server, and we'd be swapping it out on them
[15:17] <sil2100> Excuses!
[15:18] <sil2100> Saviq: ok, just make sure to coordinate
[15:18] <Saviq> sil2100, will do
[15:19] <popey> sil2100: dunno if you know this, but on #95 music app is missing and i can't bring up osk in the  app lens
[15:20] <popey> i see davmor2 has confirmed this
[15:20] <ogra_> popey, ugh
[15:20] <ogra_> popey, we dropped mediascanner 1 last night
[15:20] <popey> right, but music-app is a click
[15:21] <ogra_> music-app shouldnt use it anymore though
[15:21] <popey> it doesnt
[15:21] <ogra_> phew
[15:21] <davmor2> ogra_: popey I see the music app
[15:21]  * ogra_ isnt near his flo atm ... cant check
[15:22] <popey> hm, i see it on my flo
[15:23]  * popey reboots both makos
[15:23] <davmor2> popey: I see it on my mako
[15:23] <ogra_> we got a new apparmor ... probably it missed to re-create the profile ?
[15:23] <popey> hmmm its on my other mako
[15:23] <popey> maybe yes
[15:23]  * popey reboots
[15:23] <popey> nope not showing
[15:23]  * popey gets a cable
[15:24] <sil2100> Saviq: uh oh
[15:25] <sil2100> Saviq: ok, it took longer since there was an invalid MR in the MR list, fixed that and reassigned
[15:29] <popey> phablet@ubuntu-phablet:~$ click list | grep music
[15:29] <popey> com.ubuntu.music	1.3.496
[15:29] <popey> hmm
[15:30] <popey> phablet@black-phablet:~$ click list | grep music
[15:30] <popey> phablet@black-phablet:~$
[15:31] <popey> yeah, it doesn't show up on my other device
[15:31] <ogra_> weird
[15:31] <popey> it is in /opt/click.ubuntu.com/com.ubuntu.music tho
[15:31] <popey> I'll uninstall it and see if i can install from store
[15:31] <popey> oh, i cant can I ☻
[15:32] <ogra_> you should be able to uninstall from cmdline
[15:32] <popey> how? click doesn't think i have it
[15:32] <ogra_> oh, hmm
[15:32] <ogra_> did you search for it ?
[15:32] <popey> yes
[15:32] <ogra_> it should offer it in the store if it really thinks that
[15:34] <davmor2> mterry: also phone settings on a tablet doesn't sound right for the disabling of error reporting :)
[15:35]  * sil2100 prepares to drive to practice
[15:35] <sil2100> o/
[15:35] <mterry> davmor2, that screen/text is going to be changed
[15:36] <davmor2> mterry: good to know :)
[15:41] <davmor2> mterry: okay I have a keyboard but it took nearly a minute to appear
[15:41] <davmor2> mterry: screen had dimmed so is that 45seconds
[15:44] <mterry> davmor2, Bug marked Invalid, user is too impatient  ;)  -- I've marked a note down for that
[15:56] <fginther> sergiusens, this is the error I'm currently getting: http://paste.ubuntu.com/7695713/
[15:56] <fginther> sergiusens, missing package :-(
[15:56] <sergiusens> fginther: I think that's for xnox :-)
[15:57] <xnox> hey.
[15:58] <xnox> fginther: click from utopic is needed. utopic's version is compatible to install on previous releases (e.g. trusty)
[15:58] <fginther> ahh
[15:58] <fginther> xnox, thanks
[15:58] <xnox> fginther: and it has been copied from utopic into sdk ppa or some such.
[15:58] <xnox> bzoltan: ^ where did you publish fixed click?
[15:58] <brendand> ogra_, is there a reason we don't have two builds per day?
[16:02] <sergiusens> fginther: oh, click is update in the sdk ppa
[16:02] <sergiusens> xnox: should be the sdk ppa
[16:02] <fginther> sergiusens, ack
[16:03] <sergiusens> fginther: how are you calling click? I want to copy paste :-)
[16:05] <fginther> sergiusens, "sudo click chroot -aarmhf -fubuntu-sdk-14.10 create"
[16:12] <Saviq> sil2100, ugh, sorry :|
[16:16] <robru> Chipaca, oops, sorry. I forgot to take myself off the Sheriff topic when I EOD'd last night
[16:16] <robru> stgraber, you around? it's your day to be sheriff
[16:17] <stgraber> robru: I'm around, not in the call though due to the TB meeting and my lunch break both happening at the same time :)
[16:18] <robru> stgraber, ok, no worries
[16:19] <ogra_> we didnt have much to discuss in the call anyway ... you didnt miss anything
[16:25] <robru> stgraber, can you check the packaging in silo 6? big diff there https://ci-train.ubuntu.com/job/landing-006-2-publish/28/artifact/packaging_changes_libgrip_0.3.8+14.10.20140624-0ubuntu1.diff
[16:27] <stgraber> robru: I should be able to look at this in about an hour
[16:28] <robru> stgraber, alright, thanks
[16:39] <bzoltan> xnox: in the SDK PPA
[16:43] <tvoss> sil2100, silo13 is good to go
[16:45] <robru> stgraber, ^
[16:46] <stgraber> robru: sure, will look once I'm back from meetings and lunch.
[16:47] <robru> stgraber, thanks
[16:58] <ricmm> seb128: hey did you test the silo?
[17:02] <ricmm> seb128: because I dont see it crashing, but its aborting somewhere in Mir for me
[17:24] <ricmm> seb128: I no longer see it crashing but its failing to connect to the mir server instance... not sure what could be a cause for that
[17:28] <Saviq> robru, while you're around, seen bug #1333184 ?
[17:38] <robru> Saviq, yeah, I put that in on purpose originally, didn't realize it broke ppa-purge. not sure, ppa-purge is weird, sometimes it can remove the ppa and sometimes it can't. haven't figured it out yet
[17:38] <robru> Saviq, although I guess it's just one line to drop from citrain tool to stop deleting the ppas after installation
[17:50] <stgraber> seb128: I'll assign you a silo for that indicator-network landing, however note that in the future you can also just get one yourselves (as coredevs have the needed Jenkins ACL now)
[17:50] <stgraber> *yourself
[17:59] <Saviq> robru, it will never be able to remove a ppa that it has no deb line for
[17:59] <Saviq> robru, because it needs to find out which packages are there to be able to know to backport them
[17:59] <robru> Saviq, maybe I'm confused but that code was working for me at the time that I wrote it ;-)
[18:00] <Saviq> robru, it could probably read that from dpkg db or something, but obviously it doesn't :)
[18:00] <robru> Saviq, yeah, but you tell it what ppa you want to remove, i thought it could query that ppa even if it wasn't currently enabled
[18:00] <Saviq> robru, right, well, it doesn't :)
[18:13] <robru> Saviq, https://code.launchpad.net/~robru/phablet-tools/dont-delete-silos/+merge/224340 if you want to review
[18:13] <robru> sergiusens also if you're around ^
[18:14] <sergiusens> robru: I'm around
[18:38]  * sil2100 goes to prepare the e-mail
[18:58] <sil2100> ogra_: anyway, I think we can get back to our previous approach of building 2 images a day
[18:58] <ogra_> sil2100, yeah
[18:59] <ogra_> no issue with that
[19:02] <sil2100> ogra_: so, I have a family house-work emergency tomorrow, so I have to drive to my parents place and help out finishing some wall-painting, so sadly I'll be most of the time in and out ;/
[19:02] <sil2100> ogra_: could I ask you one last time to help out and take the lead of the meetings for me?
[19:02] <sil2100> I promise it'll be the last day like this ;)
[19:03] <sil2100> I'll be around on IRC when resting inbetween house-work
[19:05] <Saviq> robru, can you please recon silo 4? I added dialer-app (yes, we know there's a bunch of conflicts, I'll coordinate)
[19:06] <robru> Saviq, ok
[19:09] <Saviq> robru, thanks
[19:38] <robru> Saviq, you're welcome!
[19:59] <seb128> ricmm, sorry, it was not built and then I was away for a while, trying in a bit
[20:00] <seb128> stgraber, hey, thanks, I know I can technically assign silos, I just though the CI team was still supposed to do it because they have a better view of the current image status and know if things should flow in or be on hold for a bit
[20:06] <stgraber> seb128: nah, so long as we're in regular landings mode, there's no problem with coredevs just doing everything themselves
[20:12] <seb128> stgraber, where did you get that? I saw no communication on that
[20:13] <seb128> stgraber, even the fact that coredev can assign silo was not communicated, Laney and I learnt it earlier this week by lurking on this channel where you or somebody mentioned it
[20:14] <stgraber> seb128: it was one thing we discussed with slangasek and robru when barry and I went through the landing team training
[20:14] <stgraber> seb128: basically the landing team is now under foundation and so we're changing a couple of small bits to the process here and there to get things go a bit smoother
[20:14] <slangasek> well
[20:15] <seb128> if that's true, could that be communicated out of the foundation team?
[20:15] <slangasek> I think it becomes a problem if all coredevs start claiming silos without coordination
[20:15] <seb128> right
[20:15] <slangasek> I don't think it was ever said that coredevs should just claim their own silos
[20:15] <stgraber> true, but you need to be more than coredev to have the necessary rights
[20:15] <seb128> which is why I was assuming the default was to let the CI lander do the "orchestration"
[20:15] <stgraber> you need coredev+spreadsheet edit rights
[20:15] <seb128> well, quite a bunch of us have that
[20:15] <seb128> which leads to the same issue
[20:16] <stgraber> slangasek: robru did say during that call that he didn't see any problem with coredevs just assigning their own silos
[20:16] <seb128> until we run out of available silo
[20:16] <barry> right.  if there are not enough silos, then you just have to wait
[20:16] <slangasek> stgraber: right, and it's fine that he thinks that, but it's not something I had any intention of socializing more broadly because silos are a limited resource :)
[20:16] <seb128> if we do that we should have a proper and documented workflow
[20:17] <stgraber> slangasek: sure, which is why I haven't sent an e-mail about it and instead just told people who'd benefit most from it and are known to be reasonable :)
[20:17] <barry> seb128: the best we have right now is the FAQ: https://wiki.ubuntu.com/citrain/FAQ
[20:17] <barry> which of course doesn't cover this particular issue :/
[20:18] <seb128> stgraber, well, that was discussed a few times on public channel, it's becoming public knowledge, being announced or not
[20:18] <seb128> but since it's not officially documented and has not been announced, it means everyone is just doing guess work
[20:18] <barry> there are a few things that only uber-devs can do (overriding some silo constraints, iirc).  not exactly sure which team controls that though
[20:18] <stgraber> barry: coredev
[20:19] <stgraber> barry: you and I aren't in any special team and we have all the rights we need for landing, so all the Jenkins jobs are now accessible by ubuntu-core-dev
[20:19] <barry> stgraber: i thought there were still a few things that core devs couldn't self-service
[20:19] <stgraber> barry: no, there are a couple things landers can't self-service
[20:19] <stgraber> barry: but landers who are also core-dev can self-service everthing
[20:20] <barry> alrighty then ;)
[20:20] <stgraber> barry: a lander can edit the spreadsheet, can trigger a build and can do a limited reconfigure (doesn't add packages). Coredev gets you assignment, full reconfigure and publishing on top of that
[20:21] <ricmm> seb128: nvm, I found another issue, dealijg with it
[20:21] <seb128> ricmm, k
[20:22] <seb128> ricmm, I was just installing it ;-)
[20:22] <ricmm> :)
[20:26] <robru> stgraber, barry, slangasek, seb128: sorry guys I was in a meeting. yes of course if all core devs are constantly assigning silos, that's chaos, and there are a very small number of silos. but on the other hand, since core devs already have the ability to upload direct to ubuntu, it doesn't make much sense to me for them to have to ask for permission to get a silo, that's just slow and inefficient. so I would generally ask core devs
[20:26] <robru> to just be reasonable about assigning silos to themselves, don't be greedy if you already have a couple, please don't do SRUs with citrain because those take forever, etc. if you think you just have a small landing that you're going to build & test in a couple hours, go ahead, i don't mind
[20:30] <seb128> k
[20:44] <ogra_> sil2100, sure, no worries
[22:25] <Chipaca> robru: i still don't know what a sheriff is in this context :)
[22:34] <robru> Chipaca, sheriff is the guy you call for help when your train is being hijacked ;-)
[22:35] <robru> or something like that. the Sheriff is the guy assigned to help people use the CI Train effectively
[22:35] <Chipaca> robru: for ordinary stuff, or for extraordinary stuff?
[22:36] <robru> Chipaca, both. like if you need a silo assigned, or you're not sure why your build failed, or whatever. if ci train is broke, call the sheriff
[22:36] <Chipaca> robru: ah, ok
[22:36] <Chipaca> robru: thanks :)
[22:36] <robru> Chipaca, you're welcome!
[23:14] <ricmm> robru: hey, I made a mistake
[23:14] <robru> ricmm, what's up?
[23:14] <ricmm> accidentaly tried to build something in silo 3 instead of 5, silo 3 was already checking for propagation
[23:15] <ricmm> now its in an error state
[23:15] <ricmm> horrible misclick, sorry
[23:15] <robru> ricmm, so silo 3 was already published?
[23:15] <ricmm> looked like it
[23:15] <ricmm> now the msg is an error because it tried to build a pkg not in the silo list
[23:16] <robru> ricmm, hmmm, doesn't seem so? the publish job on silo 3 hasn't been ran since jun 12th...
[23:16] <robru> ricmm, oh I see, but the build job before yours was also jun 12th, that's an SRU thats just been sitting for a while
[23:17] <ricmm> so my silo is 005, I accidentaly tried to build my pkg in 003 through the jenkins interface
[23:17] <ricmm> so what do we do?
[23:17] <ricmm> can it still run merge and clean once the SRU hits release?
[23:17] <ricmm> or is it borked
[23:17] <robru> ricmm, well just do your build in silo 5 as normal
[23:18] <robru> ricmm, ehhh, I just hit publish in silo 3, lets see what happens... worst case it creates a new sync request for the same package.
[23:18] <ricmm> yup, my silo is fine, was just worried that I had damaged silo 3
[23:18] <ricmm> alright, sorry about that anyways
[23:18] <robru> ricmm, no worries, thanks for letting me know. should be good now
[23:19] <ricmm> kk awesome