[08:01] <mmrazik> didrocks: in case you have some time: https://code.launchpad.net/~private-ps-quality-team/cupstream2distro-config/add-debian-packaging/+merge/152835
[08:01] <mmrazik> my autolanding watchdog branch is blocked by this (and thanks to that I missed that friends/libfriends were not landing due to a bug in the deployment tools)
[08:02] <didrocks> mmrazik: yeah, I saw both, having a quick look :)
[08:03] <mmrazik> didrocks: great. not very urgent,though
[08:03] <mmrazik> just wasn't sure if you are watching the queue
[08:03] <didrocks> mmrazik: I'm, I need to create a dedicated folder as it ends up in the "untriaged" directory which I really skim over :)
[08:07] <didrocks> mmrazik: commented
[08:30] <didrocks> hey sil2100! how was your day off?
[08:49] <sil2100> didrocks: hello! Really nice, thanks, too bad I had to anyway run around and do some tax-related things in the morning anyway
[08:50] <didrocks> argh…
[08:50] <didrocks> sil2100: once you get some time, it seems that the issue with indicator tests failing are still there
[08:52] <sil2100> Even with the workaround?
[08:52] <sil2100> Grrrr
[08:52] <sil2100> Ok, so, I have another way, more nasty, to take care of this one - I'll look at it in a moment
[09:07] <sil2100> didrocks: ok, I see that at least the search test-workaround works and it doesn't fail, but tthose sudden 7 additional failures on indicators worries me - I'll upgrade my system and check what's up ;/
[09:08] <didrocks> sil2100: thanks dude!
[11:10] <sil2100> didrocks: strange thing with those failures, I see some old ones re-appearing, and also there was an unity crash on two machines
[11:12] <didrocks> sil2100: you don't reproduce them locally?
[12:22] <sil2100> didrocks: no, but I'm trying to make one of the failing tests better again, so it doesn't fail so randomly
[13:22] <didrocks> hey andyrock!
[13:22] <didrocks> andyrock: I saw sam continued to work on bug #1140505
[13:23] <didrocks> ajmitch: do you know if it's ready?
[13:23] <andyrock> mmm it should be ready for compiz/raring
[13:23] <andyrock> need to test it btw
[13:23] <andyrock> didrocks, ^^^
[13:24] <didrocks> andyrock: do you mind having a look in the next 2 days?
[13:24] <didrocks> starting to get popular :)
[13:25] <andyrock> didrocks, sure... next 2 hours should be ok too :)
[13:25] <didrocks> \o/
[13:25] <didrocks> thanks andyrock
[13:27] <xnox> I use lvm snapshots a lot, (each sbuild creates a new one) so my launcher at the moment has 9 "disk" icons for each of the lvm snapshot/chroot.
[13:27] <xnox> the available "unlock" / "blacklist" is ok, but it works on UUIDs thus it's hard to prevent it from constantly adding all the new lvm snapshots.
[13:28] <xnox> can I somehow do patter matching and blacklist /dev/mapper/*chroot* pattern for example?
[13:28] <xnox> s/patter/pattern/
[13:37] <andyrock> np
[13:51] <mterry> fginther, the latest nvidia unity jenkins run performed 15 fewer tests than it did yesterday.  I can't find obvious faults in the console log after it starts actually running tests (though there are some odd exceptions while its setting everything up, but those are there yesterday too).  http://10.97.0.1:8080/job/ps-unity-autopilot-release-testing/label=autopilot-nvidia/112/
[13:52] <fginther> mterry, I'll take a look
[13:55] <mterry> thanks!
[14:31] <seb128> mterry, hey
[14:31] <seb128> mterry, can you get https://code.launchpad.net/~seb128/unity/nautilus-default-launcher-icon/+merge/152382 approved?
[14:32] <mterry> seb128, looking
[14:34] <mterry> seb128, design approved the change I assume?
[14:34] <seb128> mterry, design are the one who requested the change :p
[14:34] <mterry> K
[14:35] <seb128> mterry, I double checked with JohnLea friday
[14:35] <mterry> seb128, do you care about migrating older users?
[14:35] <seb128> mterry, like https://launchpad.net/ubuntu/+source/nautilus/1:3.6.3-0ubuntu8 ?
[14:35] <seb128> ;-)
[14:36] <mterry> seb128, fine then.  :)
[14:36] <seb128> mterry, thanks ;-)
[14:36] <mterry> seb128, hey also..  speaking of NoDisplay, why do I have two software centers now in the dash?  One is unbranded-software-center.desktop and one is ubuntu-
[14:36] <mterry> Are there missing OnlyShowIn lines or something?
[14:37] <mterry> Maybe that's not a question for you
[14:37] <seb128> seems like a question for dobey
[14:52] <cyphermox_> mterry: ping
[14:52] <cyphermox_> mterry: available to review two MIRs? bug 1154130 and bug 1154126
[14:52] <mterry> cyphermox_, OK
[14:53] <cyphermox_> they should both link to the bug fixed by a branch we'd like to land
[14:53] <cyphermox_> maybe if you want to give me a second opinion on https://bugs.launchpad.net/indicator-messages/+bug/1154099 ; but it looks to me like bugfix more than feature
[15:02] <fginther> mterry, I found that unity died during or before unity.tests.test_dash.DashClipboardTests.test_ctrl_a
[15:05] <fginther> mterry, "09:58:23.226 ERROR __init__:55 - Unity doesn't appear to be running, exiting."
[15:06] <mterry> fginther, ah, good find.  Seems bad  :-/
[15:07] <mterry> fginther, no core files were found though
[15:07] <fginther> mterry, I don't see any crash files either, some activity is syslog is all
[15:09] <sil2100> During the indicator tests unity died as well
[15:09] <sil2100> In build 165 on unity.tests.test_hud.HudBehaviorTests.test_hud_closes_click_outside_geo, because of unknown reasons
[18:07] <mhall119> davidcalle: hangout?
[18:11] <davidcalle> mhall119, too early for me (we haven't changed time yet here :) )
[18:11] <mhall119> man, I thought google calendar handled that kind of thing for us
[18:11] <mhall119> in 45 minutes then?
[18:12] <davidcalle> mhall119, ok
[18:12] <mhall119> cool, thanks
[18:12] <davidcalle> mhall119, ty
[18:36] <seb128> sil2100, hey, can you look at https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/1141079 ?
[18:45] <seb128> mterry, ^
[18:47] <mterry> hmm
[18:57] <sil2100> seb128: looking
[18:58] <sil2100> mterry: ok, will be dealing with this ;)
[18:59] <mterry> sil2100, thanks!
[19:02] <mhall119> davidcalle: ready?
[19:03] <davidcalle> mhall119, yep
[19:03] <mhall119> davidcalle: https://plus.google.com/hangouts/_/9f2f614038358849e6634c7cdcb68a1a87d5f0dd
[19:28] <mmrazik> didrocks: still around?
[19:28] <didrocks> mmrazik: just back, what's up?
[19:28] <mmrazik> didrocks: noticed your experimental stack
[19:28] <didrocks> yep
[19:28] <mmrazik> didrocks: just a note -- if you try to create the ci/autolanding jobs it will have unexpected results
[19:28] <mmrazik> didrocks: right now the job names are constructed from the project name
[19:28] <mmrazik> didrocks: so libunity would clash e.g.
[19:29] <didrocks> mmrazik: I'm just creating the daily release
[19:29] <mmrazik> didrocks: ok. just in case :)
[19:29] <didrocks> mmrazik: I think you will get the request to have upstream merging though
[19:29] <mmrazik> didrocks: we have been discussing this with fginther todya
[19:29] <didrocks> mmrazik: I need the same name though as it's one logical unit
[19:30] <mmrazik> didrocks: so renaming it to libunity-7.0 is not an option?
[19:30] <didrocks> mmrazik: possible, but I would prefer we keep the same name. I designed the dep system on it
[19:31] <mmrazik> didrocks: mhm... not sure I understand. Wouldn't libunity-7.0 have different deps than lp:libunity?
[19:32] <didrocks> mmrazik: I mean that projects have relationship
[19:32] <didrocks> mmrazik: like, if libunity is built on the raring (distro)
[19:32] <didrocks> mmrazik: this will enabling libunity in the experimental stack
[19:34] <fginther> didrocks, will stack names always be unique?
[19:34] <didrocks> fginther: yeah, but some components can move from one stack to another
[19:34] <didrocks> like we had from misc -> qa
[19:34] <didrocks> ah
[19:35] <didrocks> you mean unique between release?
[19:35] <didrocks> fginther: I think you will have libunity for raring and one for s, isn't it?
[19:35] <didrocks> they will both have the same project name
[19:35] <mmrazik> btw. I don't get it but I'm drinking beer already. Will try to figure it out tomorrow
[19:35] <didrocks> different branches though
[19:35]  * fginther  head explodes
[19:36] <fginther> didrocks, so you could have a qa stack for raring and s, but they will be unique within the release
[19:36]  * kalenjohnson get's the mop
[19:37] <didrocks> fginther: depends in what you call release :p
[19:37] <didrocks> raring and s are series
[19:37] <didrocks> release is "head", "experimental"
[19:37] <fginther> didrocks, ahhh, so they are
[19:37] <didrocks> those names
[19:38] <didrocks> so, for instance
[19:38] <didrocks> we have libunity in head
[19:38] <fginther> didrocks, I think I understand. Just need to absorb the implications
[19:38]  * mmrazik is googling what release is
[19:38] <didrocks> and experimental
[19:38] <mmrazik> I thought head=trunk
[19:38] <didrocks> they all target the series "raring"
[19:38] <didrocks> mmrazik: exactly
[19:38] <didrocks> that's the release name
[19:39] <mmrazik> didrocks: in that case what is experimental? feature branches?
[19:39] <didrocks> mmrazik: it's the name for the release
[19:39] <didrocks> look at stacks/
[19:39] <didrocks> you have two dir
[19:39] <didrocks> each dir is a release
[19:39] <didrocks> head/ experimental/
[19:40] <didrocks> they both target the raring series
[19:40] <didrocks> (we can change the release terminology, it's not clear IMHO and I didn't choose it)
[19:41] <mmrazik> I still don't understand what experimental means then... so we will be releasing that stuff into raring?
[19:41] <didrocks> not raring
[19:41] <didrocks> in a ppa
[19:41] <didrocks> it's a collection of feature branches
[19:41] <didrocks> for the 100 scopes projects
[19:42] <mmrazik> okay... so experimental = feature branches
[19:42] <didrocks> mmrazik: right
[19:42] <didrocks> the triplet (stackname, project, release) is unique
[19:42] <didrocks> that's why I create for instance:
[19:42] <didrocks> cu2d-100scopes-experimental-1.1prepare-unity
[19:42] <didrocks> (1.1prepare is the job name)
[19:43] <mmrazik> didrocks: but eventually we will have a directory called raring? When all the trunks will be branched for new development and there will be raring branches for maintenance?
[19:43] <mmrazik> or rather s/rarinring/whatever LTS release/
[19:43] <didrocks> mmrazik: right, that's why it was called "release" before I guess :)
[19:43] <didrocks> and head will move to s
[19:43] <mmrazik> didrocks: ok. understood.
[19:44] <mmrazik> didrocks: can we make (project, release) unique?
[19:44] <mmrazik> i.e. project will be unique within stackname
[19:44] <mmrazik> fginther: ^
[19:44] <didrocks> mmrazik: well, I can imagine the day we have 2 features involving unity
[19:44] <didrocks> so experimental/100scopes.cfg
[19:44] <didrocks> and experimental/foofeature.cfg
[19:44] <mmrazik> didrocks: I would prefer different project names there TBH
[19:44] <didrocks> both containing the "unity"
[19:45] <mmrazik> unity-100scopes
[19:45] <mmrazik> unity-foo
[19:45] <didrocks> mmrazik: it's still targetting unity
[19:45] <didrocks> mmrazik: and we need to know the relations between projects
[19:45] <didrocks> so that if a new upload happen, in the "unity" project in raring
[19:45] <boldfilter> Can I move the launcher to the left side?
[19:45] <didrocks> (in head/ for instance)
[19:45] <mmrazik> didrocks: I think I'll need to absorb this :)
[19:45] <didrocks> I need to relaunch the "unity" projects in experimentals
[19:46] <mmrazik> didrocks: I think I start to understand, though
[19:46] <didrocks> mmrazik: yeah, sorry, this came after a lot of thoughts ;)
[19:46] <didrocks> mmrazik: some beers/night will help I guess :)
[19:46]  * didrocks is out of beer
[19:46] <mmrazik> didrocks: thats fine. The only issue is that my thoughts have been a bit different so far (and I just started to add some phablet stuff)
[19:47] <mmrazik> so I need to think about it and make my thoughts fit with yours :)
[19:47] <didrocks> mmrazik: yeah, phablet should have its own "release"
[19:47] <didrocks> I guess
[19:47] <didrocks> so head/ experimental/ phablet/
[19:47] <didrocks> mmrazik: making sense? ^
[19:48] <mmrazik> didrocks: yeah... I guess so