[08:03] <didrocks> hey sil2100, how are you?
[08:08] <sil2100> didrocks: morning! Rather fine, and you? ;)
[08:09] <didrocks> sil2100: I'm ok, thanks!
[08:09] <didrocks> sil2100: I have two questions for you :)
[08:10] <didrocks> 1. do you mind having a look at the indicators tests? one of the tests search is failing on the 3 configs
[08:10] <didrocks> (we also have 2 additional failed tests on intel, would be great to have a grasp)
[08:10] <didrocks> 2. did you make any progress on the appmenu-qt/Qt5 side?
[08:11] <sil2100> didrocks: 1. I'll take a look at it
[08:11] <sil2100> didrocks: 2. there is some progress - I ported appmenu-qt to Qt5 but am still working on the appmenu plugin-framework side of Qt5, but I'm going in the right direction I think
[08:12] <didrocks> sil2100: 1. & 2. -> thanks :)
[08:13] <didrocks> sil2100: did you get support from agateau?
[08:13] <didrocks> sil2100: we'll need a FFe I guess for the appmenu part
[08:27] <sil2100> didrocks: I wrote him an e-mail, but he didn't reply yet - but renato gave me some pointers, as well as agateau's blog posts about the inclusion of appmenu in Qt4 helped out
[08:29] <didrocks> sil2100: great ;) I'm not sure if it's the holidays for him, let me try to grab him
[08:29] <didrocks> yeah, he seems away
[08:29] <didrocks> anyway, thanks sil2100! keep me posted for the indicator tests. If it's a false positive, we can force a daily already
[08:48] <sil2100> didrocks: I've been looking at the failures, and the search tests seem to be a false positive - a really strange one, since it fails the same way on all machines
[08:49] <sil2100> It fails to show the application lens on the first super+a
[08:49] <sil2100> Not sure why!
[08:49] <sil2100> Cannot reproduce it here, hm
[08:49] <didrocks> sil2100: interesting… would be good to workaround/fix it as it will block all releases in the next days
[08:49] <sil2100> Also, no previously executed tests seem to have done anything to break this
[08:49] <sil2100> didrocks: could you re-start the indicator build test maybe?
[08:49] <didrocks> sil2100: it's the one that we added yesterday
[08:50] <didrocks> sil2100: well, it failed on all 3 configs, I doubt restarting will change anything, isn't it?
[08:50] <sil2100> No, it's not the one added - it's one of the existing ones
[08:50] <didrocks> sil2100: test_search was not executed before for indicators
[08:50] <sil2100> Ah
[08:50] <sil2100> Ok, hm
[08:51] <didrocks> sil2100: look at the unity ones
[08:51] <didrocks> failing the same
[08:51] <sil2100> I just looked and indeed saw the same thing
[08:51] <sil2100> Ok, then this requires more investigation then
[08:51] <sil2100> !
[08:52] <didrocks> yep :)
[09:20] <sil2100> didrocks: ok, it seems to be a real regression - the first Super+a press does not work
[09:21] <didrocks> sil2100: oh, it rings a bell to me
[09:21] <didrocks> sil2100: maybe we need a separate test for that?
[09:21] <sil2100> didrocks: it would be hard to do, since with autopilot we're never sure what test will be executed first ;)
[09:22] <sil2100> I can try looking into unity to check what could be the source for this regression
[09:22] <didrocks> sil2100: oh, I just mean a separate test
[09:22] <didrocks> sil2100: so that we'll see this one failing as well
[09:22] <didrocks> sil2100: on the source check -> yes please ;)
[12:08] <didrocks> sil2100: hey, did you get any luck?
[12:41] <sil2100> didrocks: building now something testable
[12:41] <didrocks> sweet!
[13:02] <om26er> btw dash search was faster in 12.10 than it is in raring
[13:03] <didrocks> om26er: something to tell to Satoris I guess
[13:03] <didrocks> the rest didn't change
[13:04] <om26er> didrocks, well the dash itself is feeling faster on 12.10 to me, dunno why
[13:05] <didrocks> om26er: the blur algorithm change?
[13:06] <om26er> didrocks, that maybe related but wasn't that supposed to fasten the dash ;)
[13:06] <didrocks> it was, but you never know :)
[13:43] <kenvandine> didrocks, can you look at https://code.launchpad.net/~ken-vandine/dee-qt/prepare_for_raring/+merge/151617
[13:44] <kenvandine> i really want to get that landed in raring, the folks working on the core apps will need it
[13:56] <bregma> didrocks, I would like to bump Unity to version 7 (but leave the API version at 6) so we can do a sensible upstream release before FF today -- what are your thoughts?
[14:52] <didrocks> bregma: hey!
[14:52] <didrocks> bregma: I'm really wondering about the benefit/cost
[14:52] <bregma> didrocks, ho!
[14:52] <didrocks> bregma: changing the version to 7 without changing the API version should work
[14:52] <didrocks> meaning the path isn't changed for the assets
[14:52] <didrocks> but it needs checking
[14:53] <didrocks> bregma: do you think the risk/cost benefit worthes it?
[14:53] <didrocks> kenvandine: hey! the changes looks ok. I'm wondering though if we do have common files with dee-qt in precise for the precise -> next LTS upgrade?
[14:53] <didrocks> kenvandine: also, while we are at it, what do you think spending some time building the daily release and doing all that in one shot?
[14:53] <kenvandine> i wouldn't think so
[14:54] <didrocks> kenvandine: do you mind checking at packages.ubuntu.com?
[14:54] <bregma> I think the benefit of being able to distinguish between the release in 12.10 and the release in raring/going forward is worth it from a support point of view
[14:54] <didrocks> kenvandine: just one binary package, should be quick :)
[14:54] <kenvandine> sure
[14:54] <bregma> and an upstream release is good for downstreams
[14:54] <bregma> and we can close milestoned bugs
[14:54] <didrocks> (which downstreams? ;))
[14:54] <didrocks> bregma: do you mind trying bumping debian/changelog and the upstream version
[14:54] <bregma> the imaginary ones I would like to see sprout like mushrooms after a rain
[14:54] <didrocks> building the package
[14:54] <didrocks> and installing it
[14:54] <didrocks> bregma: heh
[14:55] <didrocks> bregma: just to check that lenses still starts and so on?
[14:55] <bregma> I've been working on that, queued up after another test I'm running
[14:56] <didrocks> bregma: if it works on a fresh session, please go ahead :)
[14:56] <bregma> unfortunately I'll have to upgrade my build machine to raring to do it proper , which means I may miss FF
[14:56] <didrocks> bregma: well, bumping the version for bumping the version is not a "feature"
[14:56] <bregma> OK
[14:56] <didrocks> bregma: so as long we don't require rebuilding the world, I'm ok with it :)
[14:56] <didrocks> just put it in a sensible way in debian/changelog
[14:56] <bregma> all I want is a new package version, no other changes, so if it Just Works I will propose it
[14:57] <didrocks> bregma: excellent!
[14:57] <didrocks> bregma: I really hope that we'll get a clearer view soon
[14:57] <didrocks> on if/not we release raring
[14:57] <bregma> yes, indeed
[14:57] <bregma> if we release raring, we'll want to branch, too, before release goes out
[14:58] <bregma> another reason to bump the package version
[14:58] <didrocks> bregma: yeah, let's see how it goes
[14:58] <sil2100> didrocks: would you mind if I did a test-build in ps-indicators-autopilot-release-testing with a custom list of tests to perform?
[14:58] <sil2100> didrocks: or is there another job for that purpose?
[14:59] <didrocks> bregma: I was expecting to go on "daily release to a ppa" when we will close to next LTS ;)
[14:59] <didrocks> bregma: not that soon!
[14:59] <didrocks> sil2100: oh no worry, please be my guest :)
[14:59] <sil2100> didrocks: since I tried using autopilot-run-custom-branch, but it doesn't work somehow, probably veebers has some WIP regarding that
[14:59] <sil2100> didrocks: thanks!
[14:59] <didrocks> sil2100: but we do have everything built on the unity stack
[14:59] <didrocks> sil2100: if you want to check the global result
[15:00] <sil2100> I know, I just want to start one suite
[15:00] <didrocks> ok
[15:00] <kenvandine> didrocks, no file conflicts
[15:00] <kenvandine> combination of soname change and multiarch makes it nice and clean :)
[15:00] <didrocks> kenvandine: ahah, I would have bet so! great ;)
[15:01] <didrocks> kenvandine: daily release? I think it's maybe time for folks/friends? ;)
[15:01] <kenvandine> folks?
[15:01] <didrocks> kenvandine: or you do want to do the first shot today
[15:01] <didrocks> I meant friends :)
[15:01] <kenvandine> i'll propose a branch enabling friends today
[15:02] <didrocks> kenvandine: and we work on that together tomorrow?
[15:02] <didrocks> kenvandine: so that we define stacks
[15:02] <kenvandine> seb128, don't forget my NEW review :)
[15:02] <seb128> kenvandine, oh, yeah
[15:02] <kenvandine> didrocks, i won't be in tomorrow :)
[15:02] <kenvandine> it's 2 packages for now
[15:02] <kenvandine> libfriends and friends
[15:02] <kenvandine> small stack :)
[15:03] <kenvandine> i just added an example to qml-friends that i'll use as the basis for an autopilot test
[15:03] <seb128> kenvandine, no COPYING/license in the tarball?
[15:04] <didrocks> kenvandine: but we need dee in daily release, isn't it?
[15:04] <didrocks> dee-qt*
[15:04] <didrocks> kenvandine: ok, let's wait a little bit for friends that you do your autopilot test
[15:06] <seb128> kenvandine, accepted, please added a COPYING though
[15:06] <kenvandine> seb128, will do...
[15:06] <seb128> kenvandine, thanks ;-)
[15:07] <kenvandine> didrocks, i feel good about libfriends and friends even without qml-friends autopilot tests
[15:08] <kenvandine> libfriends test suite actually runs friends in test mode
[15:08] <kenvandine> it is a good integration test
[15:08] <kenvandine> qml-friends needs tests before i want to add that to the dailies
[15:08] <kenvandine> seb128, added :)
[15:08] <seb128> good
[15:09] <didrocks> kenvandine: but, those 2 needs to be installed somewhere to work together, isn't it?
[15:10] <kenvandine> yes
[15:10] <kenvandine> humm
[15:11] <didrocks> kenvandine: ok, so we need a jenkins job taking latest daily, and doing that, isn't it?
[15:11] <didrocks> installing both
[15:11] <kenvandine> libfriends pulls in friends as a build dep to test
[15:11] <kenvandine> yeah
[15:11] <didrocks> ah
[15:11] <kenvandine> so that might be good enough
[15:11] <didrocks> si, it can be ran while libfriends is building?
[15:11] <kenvandine> yeah
[15:11] <kenvandine> friends doesn't depend on libfriends
[15:11] <didrocks> so you already do run integration tests during build? :)
[15:12] <kenvandine> yes
[15:12] <kenvandine> the unit tests in libfriends... i think those are good integration tests for friends
[15:12] <didrocks> \o/
[15:12] <kenvandine> since it actually runs friends and really calls it's functions
[15:12] <didrocks> excellent
[15:12] <didrocks> yeah, so they are not unit tests :)
[15:12] <kenvandine> we were very thorough with friends :)
[15:12] <didrocks> but I only care about integration tests TBH
[15:12] <didrocks> kenvandine: do you have upstream merger?
[15:13] <kenvandine> well, the are unit tests for libfriends... a side effect is integration testing of friends
[15:13] <kenvandine> no
[15:13] <didrocks> ok, let's get that fixed!
[15:13] <kenvandine> what do i need to do to add that to the merger
[15:13] <didrocks> kenvandine: pinging mmrazik|afk ;)
[15:13] <didrocks> kenvandine: do you want to add the stack definition?
[15:13] <kenvandine> yeah
[15:13] <didrocks> creating the friends stack, I think you deserve it :)
[15:14] <didrocks> kenvandine: https://launchpad.net/cupstream2distro-config/trunk
[15:14] <didrocks> you do have the stacks/head/ dir
[15:14] <didrocks> create a friends.cfg
[15:14] <didrocks> similar to the unity one for instance
[15:25] <kenvandine> didrocks, can i model it after the webapp one?
[15:25] <didrocks> kenvandine: yes, an easier one maybe :)
[15:26] <kenvandine> right :)
[15:26] <didrocks> kenvandine: the additional info will be added by mmrazik|afk for upstream merging (we are transitionning to having one single file for all those infos)
[15:26] <didrocks> kenvandine: please call the file "friends", not "friens-head"
[15:26] <kenvandine> ok
[15:26] <didrocks> kenvandine: as I added the head/ directory
[15:28] <kenvandine> https://code.launchpad.net/~ken-vandine/cupstream2distro-config/friends-stack/+merge/152199
[15:28] <kenvandine> didrocks, ^^
[15:29] <kenvandine> mmrazik|afk, when you're around, can you help me get friends added to the merger?
[15:29] <didrocks> kenvandine: approving
[15:29] <didrocks> kenvandine: you can push to trunk
[15:29] <didrocks> kenvandine: so that we win some time :)
[15:29] <kenvandine> great
[15:29] <didrocks> kenvandine: then, we need to create from your template the jenkins jobs
[15:30] <didrocks> in the same project
[15:30] <didrocks> daily-release directory
[15:30] <didrocks> you have the cu2d-update-stack command
[15:30] <didrocks> it should be used like this:
[15:30] <didrocks> ./cu2d-update-stack -U <../path/to/stack/file>
[15:31] <didrocks> kenvandine: as mmrazik|afk and fginther did some change to the tool, you can have bad surprises, tell me if it exit with non 0 :)
[15:31] <kenvandine> that will create the jenkins job?
[15:31] <didrocks> kenvandine: you need to be connected to the vpn and having your credential setup
[15:31] <didrocks> yep :)
[15:31] <didrocks> kenvandine: in the future, if you change something in the template, like add/remove a project, it will update it with the same command
[15:33] <didrocks> (it's also setting up bzr to bind to our needs)
[15:33] <kenvandine> should it be the .1 or .6 IP in my cred file?
[15:34] <didrocks> .1
[15:34] <kenvandine> nevermind
[15:34] <kenvandine> i looked at the wrong browser tab :)
[15:34]  * didrocks sees someone who never configured his cred file :p
[15:34] <didrocks> kenvandine: the file should be ~/.cu2d.cred
[15:38] <kenvandine> humm... said it couldn't find my credentials
[15:39] <didrocks> ~/.cu2d.cred ?
[15:39] <didrocks> kenvandine: ^
[15:39] <kenvandine> yeah
[15:40] <kenvandine> oh... i don't remember where i got the token in there... but it is the same as the one in the email sent to all of us
[15:40] <kenvandine> so i guess that isn't mine :)
[15:40] <fginther> kenvandine, token is from your jenkins user page
[15:41] <didrocks> kenvandine: no, its the same
[15:41] <didrocks> kenvandine: you do have an account on jenkins, right?
[15:41] <kenvandine> yes
[15:41] <kenvandine> i am logged in
[15:41] <didrocks> kenvandine: can you try -C <cred_file_path>?
[15:41] <kenvandine> 2013-03-07 10:36:40,690 ERROR Credentials not found. Aborting!
[15:41] <kenvandine> so it didn't find it... but it's right
[15:41] <kenvandine> ok
[15:42] <kenvandine> still says not found
[15:43] <didrocks> kenvandine: do you mind pasting me the cred file content you have?
[15:43] <kenvandine> ok
[15:43] <didrocks> let me try also
[15:43] <didrocks> reconfigured webapp, working here
[15:43] <didrocks> so it's not fginther breaking everything :p
[15:44] <fginther> whew!
[15:45] <didrocks> mterry: hey hey hey!
[15:46] <didrocks> mterry: now that cyphermox published the indicators, I think you can publish unity :)
[15:46] <didrocks> we are at 199 daily landing right *now*
[15:46] <didrocks> you can have the 200th upload!
[15:47] <mterry> cyphermox, ah.  the test failures were no big deal?
[15:47] <mterry> didrocks, wake me when it's 1000th
[15:47] <didrocks> :)
[15:47] <cyphermox> mterry: nah
[15:47] <cyphermox> :)
[15:50] <mterry> cyphermox, didrocks : done.  Today is FF, right?  I'm still unclear if we are doing 13.04 or not, but if we are, we should communicate that to the unity team
[15:50] <cyphermox> indeed
[15:51] <mterry> didrocks, also...  I think as an archive admin, you can demote ubuntuone-couch if you like.  I was just reminded of that fact in #ubuntuone
[15:51] <didrocks> mterry: yeah, sent an email this morning to the team leads
[15:51] <cyphermox> so far it is unclear whether we will release 13.04 formally so carrying on with FF as usual
[15:51] <didrocks> mterry: sorry, I should have CC you guys
[15:51] <didrocks> cyphermox: kenvandine robru ^
[15:51] <mterry> didrocks, frankly, it can probably be dropped from the archive...
[15:51] <didrocks> mterry: oh yeah, demoting the couch!
[15:51] <didrocks> let's demote for now :)
[15:51]  * cyphermox is going to head to uni shortly (over lunch) to do one last NM test before uploadin
[15:52] <mterry> :)  No rush on archive, as long as it's out of main
[15:52] <didrocks> mterry: flushed from main, in universe now :)
[15:52] <mterry> didrocks, sweet
[15:55] <cyphermox> mterry: there is one branch that I expect larsu will want to have land today; needing a FFE and all
[15:55] <cyphermox> but it's also needing two MIRs, would you be available later to review them?
[15:55] <cyphermox> I'm going to check if they have been filed already, otherwise I'll take care of it
[15:56] <mterry> cyphermox, sure
[15:56] <mterry> cyphermox, shouldn't need an FFe if everything happens before some hour today...  don't remember when
[15:56] <cyphermox> well yeah
[15:57] <cyphermox> but it's indicators, and I would really prefer if it went through the grinder
[15:57] <cyphermox> rather than uploading manually...
[15:57] <didrocks> yeah, manual upload is so old…
[15:57] <cyphermox> hehe
[15:57] <cyphermox> old school...
[15:58] <didrocks> and let's welcome the friends stack to daily landing!
[15:58] <cyphermox> I mean, whoever even still speaks of debdiffs anymore? ;)
[15:58] <cyphermox> yay
[15:58] <didrocks> cyphermox: exactly!
[15:59] <mterry> cyphermox, well, you could start a build and all  :)
[15:59] <cyphermox> yeah
[15:59] <cyphermox> just it would be tight
[16:00] <cyphermox> and the MIRs need to be done too :)
[16:00]  * mterry whips out his rubber stamp
[16:01] <mterry> j/k! j/k
[16:03] <kenvandine> didrocks,  is dee-qt setup to automerge?
[16:04] <didrocks> seb128: larsu: would have been cool to have a bug attached to your change to not end up with an empty changelog :p
[16:04] <didrocks> kenvandine: no, nor daily landing
[16:04] <didrocks> kenvandine: do you think we should attach that to an existing stack?
[16:04] <kenvandine> not sure where it fits
[16:04] <didrocks> yeah, I'm wondering…
[16:04] <didrocks> dee-qt deps on dee?
[16:04] <kenvandine> i'll need it when i add gwibber in
[16:05] <kenvandine> yes
[16:05] <kenvandine> the core apps will need it too
[16:05] <didrocks> kenvandine: yeah, I think we'll have an infrastructure stack
[16:05] <kenvandine> i'm sure we'll have a stack for those
[16:05] <didrocks> dee will move to it
[16:05] <didrocks> as libunity
[16:05] <didrocks> I guess
[16:05] <kenvandine> ok, lets just get this merged and uploaded to raring
[16:05] <didrocks> kenvandine: let's flesh out the stack story as discussed in the session by next week
[16:06] <kenvandine> didrocks, can you approve the MP and i'll push to trunk?
[16:06] <kenvandine> and upload
[16:06] <didrocks> kenvandine: sure, one sec
[16:07] <didrocks> kenvandine: done :)
[16:09] <kenvandine> grrr
[16:09] <kenvandine> Unable to obtain lock  held by didrocks@bazaar.launchpad.net on taotie (process #14998), acquired 342 hours, 18 minutes ago.
[16:09] <kenvandine> didrocks, can you break your lock?
[16:09] <didrocks> kenvandine: on dee-qt?
[16:09] <kenvandine> yeah
[16:09] <didrocks> lp:dee-qt?
[16:09] <didrocks> waow
[16:09] <didrocks> I did push that at some point?
[16:09] <didrocks> crazy… ;)
[16:09] <didrocks> kenvandine: done
[16:10] <kenvandine> ok, pushed and uploaded
[16:10] <kenvandine> i guess that'll go to sourceNEW
[16:10] <kenvandine> for the rename
[16:11] <didrocks> hum, not sure
[16:11] <didrocks> binNEW for sure
[16:11] <didrocks> source new, it was in precise…
[16:12] <mterry> cyphermox, what's with the misc stack?
[16:17] <cyphermox> mterry: there was a merge that wouldn't complete
[16:17] <cyphermox> for various reasons ;)
[16:17] <mmrazik> kenvandine: I'll put the autolanding bits and pieces later today...
[16:18] <kenvandine> great
[16:18] <didrocks> fginther: mmrazik: objection if I rename all <foo>-head file to <foo>?
[16:18] <fginther> didrocks, not from me
[16:18] <mmrazik> didrocks: fine with me
[16:18] <didrocks> let's go then :)
[16:19] <kenvandine> mmrazik, for friends, libfriends, qml-friends and dee-qt please
[16:19] <mmrazik> kenvandine: its just one cfg file, right?
[16:19] <didrocks> mmrazik: you have the "friends cfg file"
[16:19] <mmrazik> alesage: FYI ^^^ I think we already have autolanding etc for some of those. I'll delete them
[16:19] <kenvandine> we aren't doing daily releases for qml-friends and dee-qt yet
[16:19] <didrocks> mmrazik: but we only daily release libfriends and friends
[16:19] <kenvandine> but  we want to get the merger merging them
[16:20] <mmrazik> kenvandine: ack
[16:20] <didrocks> so I guess I need to add an option for that :)
[16:20] <mmrazik> kenvandine: there is an option for that
[16:20] <mmrazik> (i.e. option that will make the daily release machinery to ignore a particular project but still have autolanding etc)
[16:20] <alesage> mmrazik, ok
[16:22] <didrocks> oh right daily_release_default
[16:22] <didrocks> and then daily_release
[16:23] <didrocks> mmrazik: do you mind adding false for them to the two other components than libfriends/friends only?
[16:23] <didrocks> s/only//
[16:23] <mmrazik> didrocks: ack
[16:23] <didrocks> thanks a lot
[16:47] <sil2100> grrr, hw issues for jenkins test builders
[17:10] <mmrazik> kenvandine: dee-qt should be part of the friends stack?
[17:24] <robru> good morning didrocks ! ;-)
[17:24] <didrocks> hey robru! How are you?
[17:24] <robru> sleepy ;-)
[17:24] <robru> and you?
[17:24] <didrocks> robru: tired :-)
[17:25] <didrocks> robru: I'll have the list of WI setup for tomorrow I guess, I had other things with feature freeze to deal with
[17:25] <robru> didrocks, we have so much in common ;-)
[17:25] <didrocks> robru: heh, isn't it? ;)
[17:25] <robru> didrocks, ok, looking forward to seeing the workitems.
[17:26] <didrocks> :-)
[17:27] <kenvandine> mmrazik, no, not sure where it belongs right now
[17:27] <mmrazik> kenvandine, didrocks: do you mind if I put it into friends.cfg?
[17:27] <kenvandine> i don't mind
[17:27] <didrocks> mmrazik: for now no, but I'm sure it will move next week
[17:27] <kenvandine> ultimately it needs to be in like some infrastructure stack
[17:27] <mmrazik> I don't want to move the unity stack to cupstream2distro-config based config
[17:27] <didrocks> mmrazik: is it a problem for you?
[17:28] <mmrazik> didrocks: well... we still find bugs and issues in the ci/autolanding templates etc
[17:28] <didrocks> mmrazik: I mean, moving it from one stack file to another one
[17:28] <mmrazik> didrocks: but I'm using it for mir so it seems to stabilize :)
[17:28] <mmrazik> didrocks: I'm generating the ci/autolanding jobs per stack
[17:29] <mmrazik> didrocks: if I move dee-qt to unity stack and want autolanding I will need to regenerate autolanding jobs for the full stack
[17:29] <mmrazik> more or less
[17:29] <didrocks> mmrazik: oh sure, TBH I think it will be in a new stack on its own
[17:29] <mmrazik> didrocks: in that case its cool
[17:29] <didrocks> great :)
[17:31] <jjed> Hey, does anyone know what PPAs are currently required to build unity/phablet on raring? (the build script seems outdated)
[17:54] <sil2100> grrrr
[17:56]  * sil2100 for now is out of ideas
[17:57] <sil2100> didrocks: one possibility for the failure is that somehow, magically, the lenses_ list in Unity gets emptied and simply the first Super+a does not return the lens, but triggers re-scanning of the lenses directory
[17:57] <sil2100> ...or something
[17:58] <sil2100> I am unable to reproduce it in the way it happens in the test :<
[17:58] <mmrazik> didrocks, kenvandine: so besides the fact ps-jenkins can't review nor merge (no membership in super-friends) the autolanding setup is ready
[17:58] <didrocks> sil2100: maybe you can get some help from bregma's team?
[17:58] <didrocks> mmrazik: thanks!
[18:10] <mmrazik> robru, kenvandine: this looks like a missing build-deb to me:
[18:10] <mmrazik> https://jenkins.qa.ubuntu.com/job/friends-raring-amd64-ci/1//console
[18:11] <robru> mmrazik, yes, it does look that way
[18:11] <mmrazik> mhm... but python3-setuptools is in there
[18:11] <kenvandine> it can't be... it builds in raring
[18:12] <kenvandine> could that be missing from the jenkins environment where it does ci?
[18:12] <mmrazik> kenvandine: right... this is outside the chroot. we need to install python3-setuptools on the builders
[18:12] <robru> mmrazik, http://bazaar.launchpad.net/~super-friends/friends/trunk/view/head:/debian/control yeah, all that stuff it's complaining about missing is listed as a build dep, so I dunno what's gone wrong
[18:12] <mmrazik> kenvandine, robru: sorry for the buzz
[18:12] <robru> mmrazik, no worries
[18:18] <mmrazik> robru: the build now passes. Jenkins votes needs fixing because of the commit message. The commit message is used for the automatic merge commit during autolanding.
[18:19] <mmrazik> fixing the commit message is all you need to do. Once the branch is approved jenkins will pick it up again
[18:19] <robru> mmrazik, ok, which branch?
[18:19] <mmrazik> err.sorry
[18:19] <mmrazik> robru: you will get an e-mail from launchpad :)
[18:19] <mmrazik> https://code.launchpad.net/~robru/friends/purge-accounts/+merge/151657
[18:19] <robru> oh god, that branch isn't ready to land yet!
[18:20] <robru> ;-)
[18:20] <robru> there are some important changes there, but it doesn't yet solve the problem that it set out to solve.
[18:20] <mmrazik> robru: if you push a new revision jenkins will notice and will run the tests again
[18:20] <robru> I only mp'd it as an easy way for ken to review it.
[18:20] <mmrazik> robru: it will only merge it once the global state of the MP is Approved
[18:22] <robru> mmrazik, ok, I'll be working on that one today. please don't allow any other mps to be merged just yet either, I'm a little bit notorious for mp'ing things prematurely just to get other people's input on the work.
[18:22] <mmrazik> robru: don't be stressed about the jenkins messages. As long as the global state is not approved they will only comment to provide early feedback
[18:22] <robru> ok
[18:22] <robru> mmrazik, thanks
[18:40] <kenvandine> robru, i won't approve that :)
[18:45] <robru> kenvandine, I think we need some kind of "staging" trunk where I can push things, and then have the launchpad recipe build test packages into a PPA, before pushing things to trunk and to raring
[18:45] <kenvandine> why?
[18:46] <kenvandine> that kind of defeats the purpose :)
[18:46] <kenvandine> we don't need the daily ppa anymore
[18:46] <robru> kenvandine, just to make it easier to test things before pushing broken crap onto all raring users ;-)
[18:46] <kenvandine> well, not for friends and libfriends
[18:46] <kenvandine> we test before we merge ;)
[18:46] <kenvandine> don't need  a ppa for that
[18:47] <robru> kenvandine, exactly, I want a PPA where I can have packages built from unmerged test branches ;-)
[18:47] <kenvandine> robru, you sound stressed about this
[18:47]  * kenvandine uses pbuilder for that
[18:47] <kenvandine> robru, friends trunk has been rock  solid for ages... :)
[18:48] <kenvandine> don't worry so much
[18:48] <kenvandine> :-p
[18:53] <robru> kenvandine, ok, but I am knee-deep in the bugs right now... so I'm concerned about the issues we are currently facing ;-)
[18:54] <kenvandine> nothing earth shattering though
[18:54] <kenvandine> raring isn't an LTS :)
[18:56] <robru> kenvandine, I guess I'm just a little bit panicked because I thought we had an unlimited amount of time (with raring being declared "rolling"), but quite *suddenly* I discover that today is feature freeze and there are bugs that I really do *not* want to ship right now.
[19:44] <andyrock> fginther, ping
[19:44] <fginther> andyrock, pong
[19:44] <andyrock> fginther, do you know if there is a way to know what test has been exectued before a failing one?
[19:44] <andyrock> AP tests on jenkins of course
[19:46] <fginther> andyrock, yes, there should be a ap_test_debug_log.txt file in the build artifacts which collects the test output as they run
[19:46] <fginther> andyrock, let me know if you need help finding it
[19:48] <andyrock> fginther, found thanks :)
[23:23] <bschaefer> mterry, hey
[23:24] <mterry> bschaefer, hi
[23:24] <bschaefer> mterry, the reason I approved of the branch is I already tested everything out (before the FF) but he wanted to get 45 tests in before merging it...
[23:25] <mterry> bschaefer, FF only cares when it hits the archive (this would be tomorrow)
[23:26] <bschaefer> mterry, hmm alright, so we will need a FFe for this?
[23:26] <mterry> bschaefer, do we care if it hits raring vs +1?
[23:27] <mterry> bschaefer, if so, we need an FFe (probably easy to get, but technically that's hte rule)
[23:27] <bschaefer> mterry, well it would be nice in raring, and is +1 referring to what 13.10 would be?
[23:27] <mterry> bschaefer, maybe we need to fork unity for raring and keep working on +1 in trunk
[23:27] <mterry> bschaefer, yeah
[23:27] <bschaefer> mterry, it would be best to stick to rules. This was close I couldn't imagine it not getting into 13.04
[23:27] <bschaefer> mterry, we could wait a bit before forking as now we will be doing bug fixes
[23:28] <bschaefer> (which when forked we have to make 2 branches per fix)
[23:28] <mterry> bschaefer, fair.  We need to figure out which features we have waiting to land and which we want to get in 13.04
[23:28] <mterry> Make some FFes
[23:28] <bschaefer> mterry, was about to start doing that
[23:28] <Trevinho> mterry: yes, we want for 13.04... for sure..
[23:28] <bschaefer> mterry, and as far as I know this is the only one
[23:29] <bschaefer> (unless i missed another?)
[23:29] <bschaefer> mterry, for unity at lease
[23:30] <Trevinho> mterry: well... I know the rules, but this is not really breaking the FF, it was approved before...
[23:31] <mterry> Trevinho, FF is about what hits the archive, not upstream patch approval
[23:31] <Trevinho> mterry: ah
[23:32]  * bschaefer had that mixed up
[23:32] <Trevinho> mterry: well, at this point I think we can still merge to trunk, then we have to do another branch for raring reverting some code anyway
[23:33] <mterry> Trevinho, well, I'm leery of landing in trunk, since we have auto-uploading to raring
[23:33] <Trevinho> mterry: ah, I see
[23:33] <mterry> We either need to turn off auto-uploading or fork trunk or something.
[23:33] <mterry> Or just be careful about what hits trunk