[02:01] <sergiusens> robru: can you help me out with https://ci-train.ubuntu.com/job/ubuntu-landing-009-1-build/146/console ?
[02:04] <imgbot> [02:17] <rsalveti> sergiusens: https://launchpad.net/ubuntu/+source/goget-ubuntu-touch
[02:17] <rsalveti> sergiusens: dual changes are not yet in release
[02:17] <rsalveti> and the other MR is probably not yet merged
[02:18] <rsalveti> actually, no
[02:18] <rsalveti> weird, an older version is stuck in proposed
[02:18] <rsalveti> how could that happen
[02:18] <sergiusens> rsalveti: I don't know...
[02:19] <rsalveti> sergiusens: both seems to be the same upload
[02:19] <rsalveti> https://launchpadlibrarian.net/191444158/goget-ubuntu-touch_0.5-0ubuntu1_0.4%2B15.04.20141128-0ubuntu1.diff.gz
[02:19] <sergiusens> rsalveti: hmm, seems someone "published" line 43 in the sheet
[02:19] <rsalveti> sergiusens: it seems train did 2 uploads at the same time?
[02:19] <sergiusens> rsalveti: but it was never set to testing yes :(
[02:19] <rsalveti> that is an interesting behavior
[02:19] <rsalveti> infinity: around?
[02:19] <rsalveti> infinity: if so, check https://launchpad.net/ubuntu/+source/goget-ubuntu-touch
[02:20] <rsalveti> sergiusens: hm, right
[02:20] <rsalveti> sergiusens: do you remember the ppa number for that one?
[02:21] <rsalveti> lp might say that
[02:21] <rsalveti> one is from ppa 03
[02:21] <sergiusens> 03
[02:21] <robru> sergiusens: ah, you should be able to just FORCE_REBUILD that silo and it'll plow over that other wrong version
[02:21] <rsalveti> and the other seems to be a dput?
[02:21] <rsalveti> sergiusens: did you do a dput manually?
[02:21] <sergiusens> rsalveti: yes, the train was broken on Friday
[02:21] <rsalveti> oh, right, then that explains one piece
[02:22] <robru> sergiusens: sorry I gotta run, but yeah after you dput'd I fixed up your silo and then did a normal publish. your dput "won" because of the higher version. should be safe to just disregard and force the build job
[02:22] <rsalveti> one interesting thing though is that the other upload (one in proposed) should, in theory, be refused by lp
[02:22] <sergiusens> robru: my dput won because it was 2 hours before ;-)
[02:22] <rsalveti> and that's clearly not the case
[02:22] <robru> sergiusens: that too ;-)
[02:22] <sergiusens> robru: and I didn't set 'testing' to yes either ;-)
[02:22] <robru> sergiusens: if you hadn't bumped the version though my secondary publish would have overwritten yours.
[02:24] <rsalveti> guess because the upload done by the train is actually a package sync
[02:24] <rsalveti> still, maybe we just found a race, not sure
[02:24] <rsalveti> an archive admin should be able to give a proper answer
[02:25] <robru> rsalveti: shouldn't be a race, I manually triggered a publish there.
[02:25] <rsalveti> robru: right, but sergiusens did a dput before that, and with a version that's higher than the one you did
[02:25] <rsalveti> which was migrated just fine for release
[02:25] <rsalveti> but then the now older version is stuck in proposed
[02:25] <robru> rsalveti: yeah, that's why my version got stuck in proposed, because it was too low to get through to release ;-)
[02:26] <robru> rsalveti: the next silo to publish it should safely overwrite the one in proposed and then also migrate to release just fine if the new version is higher.
[02:26] <rsalveti> robru: right, but I believe the right thing here is lp refusing your upload
[02:26] <rsalveti> you can't upload something that is older
[02:26] <robru> rsalveti: but why would it refuse an upload to proposed if the package wasn't in proposed?
[02:26] <rsalveti> robru: because there was a newer one in release :-)
[02:27] <rsalveti> guess a package copy directly into -proposed made that happen
[02:27] <robru> rsalveti: but does it check that? wouldn't it just say 'oh this package doesn't exist in proposed, i'll accept it'
[02:27] <rsalveti> robru: not with dput
[02:27] <rsalveti> at least afaik
[02:27] <robru> rsalveti: the train doesn't use dput, it uses copyPackage
[02:28] <rsalveti> robru: that's what I'm saying :-)
[02:28] <rsalveti> I think dput would cover that, but as the train is doing a package copy, that check might not necessarily happen
[02:29] <robru> rsalveti: either way, proposed did it's job by holding it there! ;-)
[02:29] <robru> alright I gotta run, back in a couple hours.
[02:29] <rsalveti> right, still something to check
[02:30] <rsalveti> the main problem though is that it got published without testing as 'done'
[02:30] <rsalveti> sergiusens: so just force and let's see how it goes :-)
[02:31] <sergiusens> rsalveti: I bet the changelog would look ugly :-P
[02:31] <rsalveti> right :-)
[02:36]  * rsalveti another dist-upgrade & reboot
[03:26] <infinity> rsalveti: Well done (re: goget-u-t going back in time)
[03:27] <rsalveti> yeah, first time I saw that :-)
[09:18] <seb128> hum
[09:18] <seb128> is there something wrong with the CI setup?
[09:18] <seb128> e.g on https://jenkins.qa.ubuntu.com/job/generic-deb-autopilot-runner-vivid-mako/382/console
[09:37] <seb128> fginther, ^?
[09:53] <jibel> ogra_, is it the right version of cgmanager in silo 3?
[09:55] <ogra_> jibel, yep, i just set it to testing done
[09:55] <ogra_> ah, cool
[10:49] <tsdgeos> fginther: any idea what's wrong in https://jenkins.qa.ubuntu.com/job/generic-deb-autopilot-runner-vivid-mako/386/console ?
[10:49] <tsdgeos> cihelp ↑
[10:52] <Ursinha> tsdgeos: hmm, I'll have a look
[10:53] <vila> tsdgeos: plars / psivaa_ may know better, there are some connectivity issues being worked on AFAIK
[10:54] <psivaa_> tsdgeos: vila: Ursinha: this is an issue with the wifi network in the lab, it was *thought to be fixed yesterday but we still see the issue
[10:55] <psivaa_> i've reported it back to the IS to have a look, we probably need to wait for them to fix it
[10:55] <Ursinha> psivaa_: thanks for the information
[10:57] <vila> psivaa_: thanks, well done
[10:57] <ev> psivaa_: are you able to get into a device and confirm it cannot connect to the wifi network?
[10:58] <psivaa_> ev: yes, i was able to login and connection from the device to the wifi appears working but can not go outside.
[10:58]  * ev nods
[11:07] <ogra_> cgmanager is in ... i'm starting an image build for rtm
[11:08] <seb128> ogra_, are we resuming landings for ota? ;-)
[11:08] <ogra_> seb128, yes, after this image has built we will start landing the already signed off silos that have ota-1 bugs
[11:08] <seb128> ogra_, great ;-)
[11:08] <ogra_> (and QA is actively testing the others)
[11:09] <ogra_> i'll also resume the nightly cron jobs ...
[11:09]  * seb128 is looking forward seeing fixes landing again ;-)
[11:09] <imgbot> [11:10] <seb128> wooot
[11:13] <Mirv> an image!
[11:14] <ogra_> not yet, not yet :)
[11:32] <brendand> pstolowski, marcustomlinson - either of you there?
[11:33] <pstolowski> brendand, hey
[11:33] <brendand> pstolowski, rtm silo 006
[11:33] <brendand> pstolowski, it mentions 3 bugs in the description but only one in the changelog
[11:36] <alf__> cihelp: Hi! The last few Mir CI runs are failing, see https://jenkins.qa.ubuntu.com/job/mir-mediumtests-runner-mako/3622/console . Any ideas?
[11:36] <alf__> alan_g: ^^
[11:37] <psivaa_> alf__: i think this was due to a wifi issue in the lab
[11:37] <psivaa_> let me take a look anyway
[11:38] <psivaa_> alf__: alan_g: yea, the wifi network in the lab is broken at the, we have a ticket open with the IS for this, will follow it up with them
[11:39] <alf__> psivaa_: Thanks. Note that this is a new problem, it started this morning. The jobs were working fine yesterday (after the last lab issue was fixed).
[11:39] <pstolowski> brendand, is it ok if I just update the changelog for this rtm version 0.6.8? in vivid we already have 0.6.9
[11:40] <pstolowski> brendand, (in other words, the changlog in vivd would not list these bugs)
[11:46] <psivaa_> alf__: ok, if that's the case the issue has reappeared again.
[12:12] <oSoMoN> trainguards: can silo 6 be published, please?
[12:13] <oSoMoN> trainguards: would anyone know why webbrowser-app fails to build in RTM silo 11? It seems the source package never reaches the PPA: https://ci-train.ubuntu.com/job/ubuntu-rtm-landing-011-1-build/67/console
[12:14] <Mirv> oSoMoN: ok
[12:17] <Mirv> oSoMoN: hmm. I don't see anything wrong in the output or a reason why the PPA would reject the upload. let's point that log https://ci-train.ubuntu.com/job/ubuntu-rtm-landing-011-1-build/67/console to robru.
[12:19] <cjwatson> 2014-12-02 09:50:17 DEBUG   PPA exceeded its size limit (2071.00 of 2048.00 MiB). Ask a question in https://answers.launchpad.net/soyuz/ if you need more space.
[12:20] <cjwatson> Mirv,oSoMoN,robru: I've bumped that PPA's quota.  Please retry the job.
[12:20] <ogra_> building vivid too now ...
[12:21] <cjwatson> Though I'm a little confused as to why it shows as 2GiB used and 0 packages published.  Maybe needs GC ...
[12:22] <Mirv> cjwatson: oh, well spotted, thanks! it didn't occur to me to look at that figure given the PPA was "empty"
[12:24] <imgbot> [12:24] <imgbot> [12:25] <ogra_> damn
[12:25] <Mirv> "doesn't sound good"
[12:25] <Mirv> no package changes :(
[12:25] <ogra_> no no ... there were package channges
[12:26] <ogra_> the script got mad because cdimage flushed all old builds (and manifests) so there is nothing to compare against
[12:26] <ogra_> :(
[12:26] <ogra_> http://cdimage.ubuntu.com/ubuntu-touch/ubuntu-rtm/14.09/daily-preinstalled/
[12:26] <ogra_> cgmanager	0.32-4ubuntu2rtm1 is in the manifest
[12:28] <cjwatson> It's not meant to do that ...
[12:28] <oSoMoN> cjwatson, thanks!
[12:28] <pstolowski> Mirv, hey, can you advice what to do about what I asked brendand earlier? here is the backlog http://pastebin.ubuntu.com/9344148/
[12:29] <cjwatson> The manifest's on LP, so still technically accessible, but that's annoying
[12:29] <ogra_> cjwatson, the last build was over a week ago ...
[12:29] <ogra_> iirc we only keep 1 week currently
[12:30] <cjwatson> Ah, yeah
[12:32] <Mirv> pstolowski: so you're asking if it's ok if you edit the rtm's 0.6.8 branch's changelog by hand? I guess so, although I wonder why it already isn't what it says at https://code.launchpad.net/~unity-team/unity-scopes-api/staging-rtm/+merge/242050 since it should pick the changelog entires from that commit message.
[12:35] <pstolowski> Mirv, yes, i'm asking if I can edit by hand and if it's ok that the changlog for same version in vivid stays as is.
[12:36] <Mirv> pstolowski: right, sure they can differentiate since the rtm branch is separate anyhow and the rtm build has the ~rtm in the version number
[12:36] <cjwatson> Something is odd.  ~ci-train-ppa-service/ubuntu-rtm/landing-011 has a bunch of packages with status Deleted, a scheduled deletion date set, but dateremoved None and they're still on disk, e.g. https://api.launchpad.net/devel/~ci-train-ppa-service/+archive/ubuntu-rtm/landing-011/+sourcepub/4381101
[12:37] <cjwatson> I thought death-row ran on PPAs at some point ...
[12:37]  * cjwatson attempts to educate himself further from the code
[12:39] <cjwatson> 2014-12-02 07:59:04 INFO    Processing http://ppa.launchpad.net/ci-train-ppa-service/landing-011/ubuntu
[12:39] <cjwatson> 2014-12-02 07:59:04 INFO    Removing 0 files marked for reaping
[12:39] <cjwatson> 2014-12-02 07:59:04 INFO    Total bytes freed: 0
[12:39] <ogra_> 170 changelog fixed ...
[12:41]  * cjwatson pokes about on dogfood
[12:48] <ogra_> Mirv, ^^ if you like to ... land whats signed off by QA
[12:48] <cjwatson> Ah!  Nothing ever runs death-row on derived distributions.
[12:50] <Mirv> ogra_: \o/
[12:50]  * Mirv updates the spreadsheet too
[12:58] <cjwatson> I'm looking into the PPA quota issue, though it's no longer best handled on this channel.
[12:59] <cjwatson> oSoMoN: thanks for alerting me to what turned out to be a broader issue
[13:02] <Mirv> davmor2: is QA still happy with rtm-015? (for ota-1). just checking since it very barely missed the original topblocker deadline and has been sitting in the PPA for 3 weeks.
[13:07] <oSoMoN> cjwatson, glad that turned out to be helpful
[13:08] <davmor2> Mirv: talk to rvr and jibel, and see if it is in the list of silos to test :)
[13:08] <oSoMoN> trainguards: can I have a silo for line 55, please?
[13:09] <Mirv> davmor2: rvr: jibel: rtm-015 already QA signed off, it was just weeks ago. I guess I hesitate because the bug is not specifically retargeted to ota-1, and I'm unsure if it's automatically ok to land previous topblocker fixes now to ota-1.
[13:12] <rvr> Mirv: I don't know yet which silos are ok to land, but if it was tested weeks ago, then it's out of date. Silo needs to be retested with latest image.
[13:15] <Mirv> rvr: hmmkay. could you then maybe set up the rtm-015 for retesting if that's the way to go? not that of course much was landed during the last three weeks.
[13:49] <imgbot> [13:49] <imgbot> [13:49] <davmor2> \o/
[13:50] <popey> woah
[13:52] <pstolowski> Mirv, hey, so I've pushed updated changelog, but it refuses to rebuild it? ^
[13:52] <Mirv> pstolowski: try the force option
[13:54] <pstolowski> Mirv, that didn't help
[14:00] <Mirv> pstolowski: oh right, it's unintuitive. I kicked it too, now it seems do be continuing.
[14:00] <Mirv> pstolowski: you generally need to specify the package name in there. if the MP is updated, there is not even need for the force option.
[14:00] <rsalveti> wow, many updates
[14:00] <pstolowski> Mirv, ah, ok, thanks!
[14:01] <rsalveti> ogra_: what is the current vivid top most blocker?
[14:01] <rsalveti> sence the seeds got reverted
[14:03] <rsalveti> hm, no sound indicator with 39
[14:03] <rsalveti> let me update to 40
[14:04] <rsalveti> might be that other bug that happens after wizard
[14:08] <ogra_> rsalveti, there is no top blocker in vivid ... its vivid :P
[14:08] <ogra_> i dont think anyone even tracks "blockers" there
[14:49] <alexabreu> trainguards could you republish silo 005?
[15:05] <pstolowski> brendand, hey, silo rtm 6 has been rebuilt with updated changelog
[15:06] <brendand> pstolowski, ok
[15:09] <rsalveti> ogra_: thought sil was tracking that :-)
[15:10] <ogra_> not anymore i think ... all focus was shifted to rtm ... but i might be wrong ... ask him once he is not sick anymore :)
[15:14] <mterry> robru, hey man, if I have a silo
[15:14] <mterry> whoops
[15:15] <mterry> robru, if I have a silo and it wants an associated seed change, do we still just manually upload the seed change and hope everything lands around the same time?
[15:27] <Saviq> trainguards ↑ please
[15:29] <ogra_> mterry, yes
[15:30] <ogra_> (and no, we dont operate based on "hope" :) ... we can disable image builds til both is in the archive if needed)
[15:30] <seb128> bah
[15:30] <ogra_> woudl you prefer hope ?
[15:31] <seb128> rtm 169, my phone is ringing an alarm reminder but unity8 is not responding
[15:31] <seb128> can't stop the ringing
[15:31] <ogra_> use a hammer
[15:31] <ogra_> should not take more than five hits to quieten it ... else it's a bug
[15:31] <ogra_> :P
[15:31] <seb128> oh, ubuntu logo
[15:31] <seb128> sound stopped
[15:32] <seb128> but phone keeps vibrating
[15:32] <seb128> interesting :p
[15:32] <seb128> unity8 segfault I guess
[15:32] <ogra_> yeah
[15:32] <ogra_> you should have some nice .crash files
[15:32] <seb128> bah, back to a working phone
[15:32] <seb128> with vibrating in endless loop mode
[15:33] <ogra_> we had good bunch of scoperunner crashes recently ... that can tear down unity8 along it seems
[15:33] <ogra_> *a good bunch
[15:34]  * seb128 reboots
[15:34] <seb128> does anyone if the CI infra is known to have issues?
[15:34] <seb128> https://jenkins.qa.ubuntu.com/job/generic-deb-autopilot-runner-vivid-mako/393/console
[15:34] <seb128> seems the settings tests don't even run
[15:34] <seb128> the phablet-network setup fails
[15:34] <seb128> who should be pinged about that?
[15:37] <seb128> ogra_, Mirv, fginther, ^ somebody knows?
[15:37] <ogra_> seb128, IS
[15:37] <seb128> it's not the qa or ci teams?
[15:37] <ogra_> Ap issues ... started on the weekend
[15:37] <seb128> k, so it's not only settings?
[15:37] <ogra_> we have them in smoketesting too
[15:37] <seb128> is there a ticket/bug about it?
[15:37] <ogra_> seems to be the whole lab
[15:37] <ogra_> i think psivaa_ opened an RT
[15:38] <fginther> seb128, the problem is back again. Let me send out an email notice
[15:38] <seb128> fginther, thanks
[15:38] <seb128> is anyone working on resolving it?
[15:39] <fginther> seb128, yes, IS support has acknowledged the problem
[15:39] <psivaa_> seb128: https://rt.admin.canonical.com/Ticket/Display.html?id=77057 is the ticket,
[15:39] <seb128> psivaa_, thanks
[15:39] <psivaa_> fginther: thanks for sending out the email
[15:42] <seb128> ogra_, bah, unity8 apport file doesn't have a dump, no useful info of what happened then
[15:43] <ogra_> to bad
[15:43] <seb128> the media-hub-server crashed as well
[15:44] <ogra_> any scoperunner file ?
[15:44] <seb128> that as well
[15:44] <ogra_> yeah, i think i had the same issue here too then
[15:44] <ogra_> scoperunner, media-hub and unity8 crashing together
[15:45] <seb128> did you open a bug about it?
[15:45] <ogra_> nope, no data and i was on the road when it happened
[15:49] <oSoMoN> trainguards: can silo 6 be published, please?
[15:54] <seb128> ogra_, the media-hub-server bt seems to be code from /android/system/lib/libmedia_compat_layer.so
[15:54] <seb128> so no symbols
[15:55] <ogra_> yeah
[15:55] <ogra_> but you can at least add an oops pointer (grep it from whoopsie.log) to the bug
[15:55] <mterry> trainguards, may I please have a silo for spreadsheet line #57?
[16:01] <brendand> ogra_, i need to raise the topic of possibly being able to update apps in the store only for vivid
[16:02] <ogra_> raise it then :)
[16:02] <brendand> ogra_, consider it raised!
[16:03] <ogra_> :)
[16:03] <brendand> ogra_, so right now if i order an app to be updated to fix a test in vivid, then it will also update in RTM
[16:03] <brendand> ogra_, not such a big deal if it's test code only changed
[16:04] <brendand> ogra_, but if there are app changes since before the test code was updated, that also gets pulled in
[16:04] <brendand> ogra_, even worse if those are quite big changes
[16:05] <balloons> brendand, apart from getting support on the store side (which needs to happen), I suspect the simpliest way around this is to not pull from the store to build the image
[16:05] <brendand> balloons, yeah - that decision seems to be chewing on our posteriors at the moment
[16:06] <balloons> we have other reason we'd like to be able to push things to the store, but for now the differentiation seems to be based on the framework required
[16:06] <balloons> which may indeed make enough sense that more support on the store side for filtering uploads never materializes
[16:06] <john-mcaleely> rsalveti, do you know who's waiting for the rtm device tarball?
[16:06] <john-mcaleely> (it's ready with test results, etc)
[16:08] <rsalveti> john-mcaleely: mostly me atm :-)
[16:09] <rsalveti> john-mcaleely: still stuck in the bq's screen though
[16:09] <rsalveti> wonder wtf is happening here
[16:09] <rsalveti> oh, there you go
[16:09] <rsalveti> ubuntu logo
[16:10] <john-mcaleely> it looks good for me on #170
[16:32] <ogra_> balloons, brendand, the proper solution is to simply judge all core apps as rtm
[16:46] <brendand> ogra_, anything that stops us from freely developing apps on a *development* release is not a proper solution
[16:47] <brendand> ogra_, there's absolutely no reason to treat core apps differently from any other part of the system
[16:47] <ogra_> brendand, well, then we need a devel-store
[16:47] <ogra_> official store should be for rtm
[16:48] <ogra_> we have the ability to sideload clicks for developers ... i dont see why in-development core-apps need to go to the store
[16:48] <brendand> ogra_, well what about the image?
[16:49] <brendand> ogra_, that's really the issue
[16:49] <ogra_> (especially since they are most likely developed against a framework we do not even ship yet)
[16:49] <ogra_> brendand, rtm is the measure ...
[16:49] <ogra_> sil2100, !
[16:49] <ogra_> alive !!!
[16:50] <brendand> ogra_, let's think about the end goal here - i want to be able to update e.g. reminders or weather app in order to fix test failures in vivid, without impacting on RTM
[16:50] <ogra_> brendand, well, you cant ... the official store should be tied to the official release which is rtm
[16:51] <ogra_> if there is a way to have a devel store where the devel release can build from we should use that ...
[16:51] <brendand> ogra_, i can't isn't really good enough. there has to be a way
[16:51] <brendand> ogra_, or don't have the devel release pull from the store at all
[16:51] <ogra_> then there needs to be made a way ... there isnt one today
[16:51] <sil2100> ugh!
[16:51] <ogra_> and i dont think we can decouple the official store from rtm
[16:52] <brendand> ogra_, okay that's two different things - 'can't' and 'can't right now'
[16:53] <ogra_> well, i doubt we can do it in the vivid release timeframe
[16:53] <ogra_> (setting up a second store that is)
[16:53] <sil2100> New core app version needed for vivid?
[16:53] <brendand> ogra_, well no, but that's not the only way right?
[16:54] <ogra_> the only fasable one i see
[16:54] <ogra_> *feasable
[16:56] <brendand> ogra_, so the core-apps developers are doomed to not land anything for the next 6 months that is not eligible for RTM?
[16:57] <ogra_> brendand, well, why would they push anything to the store that you cant install (due to unsupported frameworks)
[16:57] <brendand> ogra_, i didn't suggest they should
[16:58] <ogra_> they should be able to provide clicks for testing etc ... and we should consider having a test-store but as i said, the official store needs to be tied to rtm
[16:58] <ogra_> and setting up a devel store wont be a small task i guess
[16:59] <ogra_> which is why i said above that i dont belive it is doable in vivid timeframe
[17:01] <sil2100> ogra_: if you could lead the meeting today one last time I would be grateful ;) I'll take care of the e-mail once I get all the updates I need
[17:01] <ogra_> sil2100, no prob, nothing to discuss anyway
[17:01] <ogra_> we re-started cron builds and had an image with cgmanager today ...
[17:02] <ogra_> the lab has still wifi issues so we dont get proper results yet
[17:03] <ogra_> plars, meeting ?
[17:03] <plars> ogra_: on the way
[17:15] <ahayzen> brendand, we with the music-app are bracing ourselves for this exact issue when vivid has an updated media-hub/mediascanner that we cannot then support in rtm :/
[17:16] <brendand> pete-woods, thostr_ - silo 007 is *7000* lines of diff....
[17:17] <brendand> woah
[17:17] <ogra_> tiny
[17:17] <sil2100> brendand: only 7k? Come on
[17:17] <brendand> pete-woods, thostr_ - okay 6200 actually - slight exaggeration for effect :P
[17:17] <sil2100> Isolated bugfix, land it!
[17:18] <brendand> seems to remove some tests too
[17:18] <brendand> this is using citrain-diff too so i'm sure it's not launchpad mischief
[17:19] <brendand> well i'll test it a bit anyway, but i'm somewhat uncomfortable with how big that diff is. and supposedly it's only fixing one bug
[17:19] <brendand> which by the looks of it is 'unity-scope-mediascanner needz moar codez!!!!'
[17:19] <thostr_> brendand: that's interesting
[17:20] <thostr_> brendand: as the single MPs alltogether are just 1500 loc
[17:21] <brendand> thostr_, unity-scope-mediascanner_0.2%2B15.04.20141110%7Ertm-0ubuntu1.dsc vs unity-scope-mediascanner_0.2%2B15.04.20141117.1%7Ertm-0ubuntu1.dsc
[17:23] <brendand> thostr_, doesn't show grooveshark results
[17:23] <brendand> thostr_, was that intended
[17:24] <thostr_> it should only add stuff
[17:24] <brendand> thostr_, it shows vimeo in settings but no results for it
[17:24] <brendand> thostr_, i just see youtube features
[17:25] <brendand> thostr_, think of something fast or i'll have to fail this silo :P
[17:25] <thostr_> what do you mean by vimeo in settings?
[17:26] <thostr_> do you have vimeo scope installed?
[17:27] <thostr_> brendand: but if you have grooveshark and vimeo scope installed it'll just show those
[17:29] <brendand> thostr_, no i don't have vimeo installed
[17:29] <brendand> thostr_, i do have grooveshark though
[17:29] <brendand> thostr_, and it doesn't show in Music scope anymore
[17:30] <thostr_> brendand: is it checked in the settings?
[17:30] <brendand> thostr_, i have 7digital, Songkick and Youtube
[17:30] <brendand> thostr_, yes also SoundCloud - which again isn't in the scope
[17:31] <brendand> thostr_, although like vimeo i don't have that scope
[17:31] <thostr_> brendand:  so which ones have you installed and which ones are checked in settings?
[17:31] <brendand> thostr_, everything is still checked in settings
[17:31] <brendand> thostr_, i haven't unchecked anything
[17:31] <thostr_> brendand: there is still an issue around settings showing scopes that are not installed, but htat is something we'll fix very shortly
[17:32] <thostr_> brendand: and grooveshark scope is still working on it's own?
[17:33] <brendand> thostr_, yes
[17:35] <brendand> thostr_, ftr once i install vimeo and soundcloud they are fine
[17:35] <brendand> thostr_, grooveshark still doesn't show up
[17:36] <thostr_> brendand: is grooveshark the newest version?
[17:36] <brendand> thostr_, it should be this is the latest rtm-proposed image
[17:37] <thostr_> brendand: that is strange, especially since no code around grooveshark aggregation was changed
[17:37] <thostr_> brendand: we'll investigate... can you put this on ice for time being
[17:37] <brendand> thostr_, well given the 6200 line diff maybe some code has been changed that you didn't think would be
[17:38] <thostr_> brendand: that might be... investigation is first where this big diff comes from
[17:38] <thostr_> brendand: it should really be only a fraction of this
[17:38] <brendand> thostr_, ok i need to have dinner anyway
[17:38] <brendand> thostr_, thanks
[17:38] <thostr_> brendand: how can I see the diff you're seeing?
[17:39] <brendand> thostr_, i put it here - http://people.canonical.com/~brendan-donegan/landing-007.diff
[17:39] <thostr_> brendand: thanks
[17:48] <mterry> Mirv, for spreadsheet line 57, is your comment why it hasn't gotten a silo yet?  I still wouldn't mind a silo to prep for landing in the meantime...  Unless we're short
[17:59] <robru> mterry: yeah unity8 is migrating, best to wait for that to finish before assiging a silo, otherwise you just have to rebuild right away anyway.
[18:15] <davmor2> ogra_, awe_: so image 39 mako vivid mms is working with my contract sim in both directions,  I think it might be the new udev at fault maybe?
[18:16] <davmor2> now I need food
[18:16] <ogra_> davmor2, or apparmor, did you check for denials ?
[18:20] <davmor2> ogra_: no damn it I'll have a look again tomorrow I just want to get 39 passed on 5 devices at 1 hour per device :P
[18:21] <ogra_> yeah
[18:21] <ogra_> take your time
[18:33] <robru> mterry: lol, tried to assign your silo. need the MP though, not the branch.
[18:36] <mterry> robru, kenvandine just told me that he's waiting on a ubuntu-system-settings rtm-backport branch to land, before he wants to land my silo so maybe hold off after all
[18:36] <mterry> robru, but I will fix that MP
[18:36] <robru> mterry: ok no worries
[18:37] <mterry> robru, also this silo would need an associated seed change -- do we still just make those in parallel or do we have a way of tying them together with the silo?
[18:37] <kenvandine> mterry, well i have a pile of backport branches, at least one of them touches the wizard
[18:37] <kenvandine> i'm going through the bugs now trying to prioritize them for ota-1 landing
[18:37] <robru> mterry: I'm not very familiar with seed changes, talk to ogra_ for that
[18:38] <robru> kenvandine: oh if you land anything today please let me hit publish on it, I need to test something ;-)
[18:38] <mterry> kenvandine, wait, how would that affect me landing drop-wizard in vivid?
[18:38] <kenvandine> robru, it won't be today :)
[18:39] <robru> darn! ;-)
[18:39] <kenvandine> mterry, because i want to make sure we have cherry-picked everything
[18:39] <kenvandine> just to be safe
[18:39] <kenvandine> mterry, i know something later than what i cherry-pick should be fine
[18:40] <kenvandine> mterry, well, i guess dropping the wizard will ensure we don't have any more wizard fixes :)
[18:40] <mterry> heh
[18:41] <kenvandine> and if there are issues, we can just fix them in the rtm branch
[18:42] <mterry> ogra_, do you know how we handle seed changes that are associated with a silo?  Just make them in parallel around the same time?
[18:42] <kenvandine> mterry, ok... i've convinced me... do you have a silo request already?
[18:42] <kenvandine> you could just add your uss branch to it
[18:42] <kenvandine> s/i've/you've/
[18:43] <mterry> kenvandine, yeah I have, line 57 of the spreadsheet
[18:43] <kenvandine> ok, add your uss branch there
[18:43] <kenvandine> it'll be easier to test in the silo anyway
[18:52] <mterry> robru, OK if you want to make a silo for line 57 now, I'd be obliged
[18:52] <mterry> robru, sorry for turnaround  :)
[18:53] <robru> mterry: no worries. do you think you'll publish it today?
[18:53] <robru> mterry: vivid 3
[18:53] <mterry> robru, um...  depends on if Cimi presses the approve button on my tests branch in short order.  So probably no
[18:54] <robru> mterry: darn it! I went my entire shift yesterday without a single publication. I have experimental train changes I need to make, but the last thing I want to do is land them and then go to sleep and let the europeans discover all the fun regressions. I need a real live publish I can test it on myself while I'm awake.
[18:55] <mterry> robru, :)
[18:55] <robru> mterry: I think it's a conspiracy... nobody wants to be my guinea pig ;-)
[18:55] <mterry> robru, didn't we just publish a unity8 silo?
[18:56] <robru> mterry: that was before I woke up
[19:02] <dobey> cihelp: ping. who best to set up jenkins ci job for monitoring MPs and running the tests on them, for a new branch?
[19:04] <fginther> dobey, we can do that, what's the branch?
[19:05] <dobey> fginther: lp:unity-scope-click/rtm-14.09
[19:06] <fginther> dobey, ack
[19:07] <dobey> fginther: thanks
[19:07] <kenvandine> fginther, oh... i have some rtm branches i'd like to see CI run for :)
[19:08] <kenvandine> fginther, lp:content-hub/rtm-14.09  and lp:ubuntu-system-settings/rtm-14.09
[19:08] <fginther> kenvandine, got it
[19:23] <kenvandine> fginther, thx
[19:26] <fginther> dobey, kenvandine, I just realized that this request is a lot more involved then adding a few configuration entries. I'll have to get back to you on this after investigating a little
[19:26] <kenvandine> fginther, cool, thanks
[19:27] <kenvandine> not urgent, but it would be nice to have CI run on the backport MPs for rtm
[19:33] <dobey> fginther: ok, thanks
[19:41] <kenvandine> Chipaca, you have settings in rtm 14 silo for testing, are you done with that?
[19:41] <kenvandine> Chipaca, if so, mind freeing it?
[19:52] <Chipaca> kenvandine: i can think about it :-p
[19:53] <Chipaca> kenvandine: i am done with that, in fact the tests went so well we decided to land it and have landed it. weeks ago :( sorry i forgot about the silo
[20:10] <robru> bfiller: oooooh you wanna publish that today? publish publish publish
[20:14] <davmor2> ogra_, sil2100: image 39 is as wonderful as it was yesterday, my issue now is I am out of day, so I'll finish the others tomorrow but none of the issues plaguing 40 are present in 39
[20:19] <kenvandine> Chipaca, cool, thanks
[20:20] <bfiller> robru: testing now then will publish :)
[20:20] <kenvandine> bfiller, robru really wants to push a button for you :)
[20:25] <sil2100> davmor2: thanks!
[20:25] <sil2100> davmor2: I need to fix the commitlog-generating machines to see what landings got into #40
[20:25] <sil2100> davmor2: right now the openstack machine seems to be 'out of free space', but it seems I can't free any space myself
[20:26] <sil2100> So I'll take care of it tomorrow
[20:31] <robru> hm
[20:50] <robru> *phew*
[21:04] <robru> brb, lunch. nothing is allowed to explode until I get back.
[21:13] <kenvandine> robru, i'll find something to go boom
[21:35] <robru> kenvandine: nuh uh! I only deleted problems this time, I swear!
[21:48] <kenvandine> :)
[22:06] <robru> whooooooooooo
[22:08] <robru> mterry: https://ci-train.ubuntu.com/job/ubuntu-landing-007-2-publish/lastSuccessfulBuild/artifact/packaging_changes_ubuntu-keyboard_0.99.trunk.phablet2+15.04.20141202-0ubuntu1.diff any love for a packaging ack? looks like a nice python2->3 port.
[22:08]  * mterry looks
[22:12] <mterry> robru, what's the story with python:any in build-deps?  I know it's a multiarch thing, I'm just not sure why it's used for build-deps?   In the switch to python3, the :any is dropped
[22:12] <robru> mterry: not sure. barry? ^
[22:13] <barry> robru, mterry sorry, please ping doko in #ubuntu-devel (though he's probably eod)
[22:26] <robru> mterry: hm, no doko I guess. is there no documentation for this?
[22:26] <mterry> robru, oh right I forgot
[22:26] <mterry> robru, let me look real quick -- diff looks fine, I just thought it was a weird drop
[22:26] <robru> mterry: yeah I have no idea but presumably bfiller tested it in his silo and it was working.
[22:27] <bfiller> robru: silo 7? yes it's tested
[22:28] <robru> bfiller: any thoughts on the switch from 'python:any' to 'python3' (without the :any?)
[22:28] <mterry> robru, ok, it's because python is just an interpreter, and it doesn't matter which arch version you have installed
[22:28] <mterry> robru, so I think it's to enable crossbuilding
[22:29] <bfiller> robru: not sure, Elleo made that change to support python3 autopilot tests
[22:29] <robru> mterry: should that not get kept then?
[22:29] <mterry> robru, so looks like this diff will make crossbuilding harder.  Which isn't good, but I don't *think* it's a blocker, just an annoyance
[22:29] <robru> mterry: fair. so you approve?
[22:30] <mterry> robru, sure...  but Elleo ^
[22:32] <robru> alright, moment of truth... will the package make it to proposed ;-)
[22:34] <Elleo> mterry: would it be better to set that as python3:any?
[22:34] <Elleo> debian packaging isn't my strong suit, so am more than happy to be corrected :)
[22:35] <mterry> Elleo, I think so.  I don't quite understand all the requirements of cross-building, but I believe that helps with doing that.  It was python:any before you changed it to python3, so I suspect it should be python3:any.  But no big deal
[22:35] <mterry> Elleo, i.e. not urgent.  Just next time you touch the packaging, maybe make that edit
[22:36] <Elleo> mterry: I could add it to the MR now if it's not going to cause issues with the building, landing, etc.?
[22:37] <robru> sweeeet
[22:37] <Elleo> maybe simplest to just make a new MR for that change
[22:37]  * mterry shrugs
[22:37] <robru> Elleo: oh yeah no, way too late to make that change. you'd have to rebuild and retest and it would be a waste of bfiller's whole afternoon.
[22:38] <Elleo> robru: okay
[22:38] <robru> Elleo: next time you have a branch for ubuntu-keyboard just sneak that in with it ;-)
[22:38] <Elleo> heh
[22:38] <bfiller> Elleo, robru : it's fine with me if you want to update the MR. I don't mind retesting it
[22:38] <robru> bfiller: no it's published already ;-)
[22:39] <bfiller> oh, in that case, rock on :)
[22:40] <Elleo> bfiller: I'll be making a new branch for some extra autopilot tests soon, so I'll just fix it in that one
[22:40] <bfiller> Elleo: ack
[23:01] <sergiusens> mterry: Elleo it's sort of explained here: https://wiki.debian.org/Multiarch/HOWTO
[23:03] <Elleo> sergiusens: thanks
[23:10]  * mterry never deals with crossbuilding
[23:14] <robru> mterry: yeah I prefer happybuilding.
[23:14] <mterry> :p
[23:16] <mterry> charles, testing fix now
[23:18] <charles> mterry, the brightness slider and settings menuitems seem to do the Right Thing in the greeter, which is nice
[23:19] <mterry> charles, huh, I get nothing...
[23:19] <mterry> maybe I typo'd
[23:19] <mterry> charles, I flashed latest vivid, installed my branch, then made your change
[23:19] <mterry> charles, anything else I need?
[23:19] <charles> mterry, make sure you have r274 instead of r273, I had a typo a couple of minutes ago
[23:20] <charles> I'm buildding a test deb with r274 now
[23:20] <mterry> charles, ah!
[23:20] <mterry> charles, I wondered why there would be a phone_greeter profile just sitting there unused  :)
[23:20] <charles> ya... :)
[23:21] <charles> I thought about adding one, but there's nothing in the phone menu that makes sense to remove in the greeter
[23:21] <charles> so it's perfect as-is
[23:22] <charles> (mterry, ordinarilly I would test from a builddeb before pinging, but I wanted to catch you before you EODed :)
[23:22] <mterry> charles, yeah thanks  :)
[23:23] <mterry> charles, works for me
[23:23] <charles> mterry, same here
[23:24] <mterry> charles, do we still do https://wiki.ubuntu.com/Process/Merges/Checklists/indicator-power ?
[23:24] <mterry> because I notice you haven't....  ;)
[23:25] <charles> well, let's do this properly
[23:25] <mterry> charles, I mean I don't care
[23:25] <mterry> charles, just didn't know if I should fill it out when I add my approve comment
[23:27] <charles> mterry, IMO it's not a big deal for this one
[23:27] <mterry> sure
[23:27] <mterry> charles, approved
[23:27] <charles> mterry, thanks
[23:28] <charles> mterry, do you want to handle siloing in with your unity8 greeter changes?
[23:30] <charles> mterry, since your changes are blocked on this
[23:31] <mterry> charles, don't block on me yet, I'm going to have design look at everything together and OK landing the unity8 side that enables all this
[23:31] <mterry> charles, but yeah i won't land mine without including yours, if yours doesn't land first