=== Madkiss_ is now known as Madkiss
=== teknico_ is now known as teknico
[12:08] <ralsina> good morning!
[12:12] <mandel> ralsina, morning!
[12:13] <ralsina> hi mandel
[12:13] <mandel> ralsina, I'm setting the jenkins machine.. I hope that running the tests is faster than having brew compile qt
[12:14] <mandel> ralsina, it has been compiling for several hours, is like going back in time
[12:14] <ralsina> well, unless you run into the same issues mmcc was having with qt versions...
[12:15] <ralsina> OTOH, it may well be too slow to test all commits
[12:15] <mandel> ralsina, question, I'm updating the installation process (the google doc has missing parts), should I update that doc and post it in the RT?
[12:16] <mandel> ralsina, AFAIK we have to let is know how to do it and expect them to do it next time, right?
[12:16] <ralsina> mandel: not totally sure about that
[12:16] <ralsina> mandel: ask pfibiger
[12:17] <pfibiger> ralsina, mandel: anyplace you want to document is fine. wiki, google doc, etc.
[12:17] <pfibiger> and yeah, it'll get handed off to webops and they'll totally rebuild the vms themselves, using your instructions
[12:17] <pfibiger> and maintain them going forward.
[12:18] <mandel> pfibiger, ralsina, canonical or ubuntu wiki seems more reasonable right? specially because the set up is also useful for new developers
[12:18] <ralsina> mandel: ubuntu wiki should be ok
[12:18] <ralsina> mandel: like the windows one
[12:18] <mandel> ralsina, ok, is the windows one up to date, buildout etc..?
[12:19] <ralsina> mandel: AFAIK yes, have not tried it lately. All changes have been inside the buildout
[12:19] <ralsina> mandel: we should have brian do a review of that one in a couple of weeks
[12:20] <mandel> ralsina, yes, that would be great, is not that we are going to have lots of developers wanting to contribute for the mac and windows versions (I'm not longer going to call them ports ;) ) but is good for the house keeping
[12:24] <mandel> ralsina, I'm off to have lunch bbl
[12:24] <ralsina> bye mandel!
[14:02]  * mandel_ back
[14:05] <alecu_> hello, all!
[14:06] <mandel_> alecu_, buenas
[14:07]  * mandel_ is over 3g  :-(
[14:07] <ralsina> hola alecu!
[14:07] <ralsina> mandel_: why? Your other you seems to be alive and well :-)
[14:08] <mandel_> He is not longer, the other is a bip server
=== mandel_ is now known as mandelQwerty99
=== mandelQwerty99 is now known as mandel
[14:10] <mandel> Much better  :-)
[14:10] <mandel> Also, I hate how bad is setting 3g on the Mac..
[14:14] <mandel> mmcc, when you are back, while the hack works we need to consider a better approach, its not a good idea to do that for windows too
[14:52] <dobey> https://launchpad.net/ubuntu/+source/u1db
[14:55] <mmcc> hi everyone
[14:55] <mmcc> mandel: agreed.
[14:56] <mandel> mmcc, maybe in filenotifier is a better option
[15:00] <mandel> me
[15:00] <briancurtin> me
[15:00] <mmcc> me
[15:01] <ralsina> me
[15:01] <dobey> meh
[15:02] <ralsina> gatox is not around today
[15:02] <ralsina> alecu_: standup?
[15:03] <ralsina> thisfred: standup?
[15:04] <ralsina> mandel: go, alecu and thisfred will come around eventually
[15:04] <mandel> DONE: started Jenkins setup for Mac vm (compiling the deps takes a ridiculous time). Done with the integration of ddcli DVD the daemon, code tests are much better now.
[15:05] <thisfred> me
[15:05] <mandel> Did you get it?
[15:05] <thisfred> DONE: documentation TODO: documentation BLOCKED: no
[15:05] <thisfred> next alecu_
[15:05] <ralsina> thisfred: eh?
[15:05] <ralsina> mandel: you didn't do a NEXT
[15:05] <briancurtin> DONE: port setup.py to python3, building out environment with all deps
[15:05] <briancurtin> TODO: skip uses of mocker, see what else needs to happen as things build out
[15:05] <briancurtin> NEXT: mmcc
[15:05] <mmcc> DONE: fought pyqt, qt, u1cp test weirdness. proposed last buildout test fix
[15:05] <mmcc> TODO: start on integration code for fsevents daemon, think about performance tests
[15:05] <mmcc> BLCK: want to talk about u1c test weirdness
[15:05] <mmcc> NEXT: ralsina
[15:05] <mandel> I did
[15:05] <ralsina> DONE: team call, 1-1s, canonicaladmin, reviews, helped around, planning & scheming TODO: fix stuff, help around, reviews BLOCKED: no, NEXT dobey
[15:05] <dobey> DONE: team meeting, 12.04.1 SRU poking
[15:05] <dobey> TODO: reviews, discuss icons, FF rush
[15:05] <dobey> BLCK: None.
[15:06] <dobey> thisfred: go
[15:06] <ralsina> dobey: did you get the icons share from lisette?
[15:06] <thisfred> ralsina, oops sorry, figured we were all done...
[15:06] <ralsina> thisfred: np
[15:06] <dobey> ralsina: yes
[15:06] <mandel> ralsina, it was at the end, just after the block
[15:07] <ralsina> dobey: we can probably generate everything from any of the SVGs, or we can use the separate ones in case she does res-specific tweaks later
[15:07] <mandel> But I indeed did not say next..
[15:07] <ralsina> mandel: I only got a DONE from you
[15:08] <alecu_> oh, standup
[15:08]  * alecu_ writes
[15:08] <mandel> ralsina, let me paste the rest
[15:08] <dobey> ralsina: it's certainly possible to generate everything from SVGs
[15:08] <ralsina> sloppiest standup *ever*
[15:08] <mandel> TODO: propose MPs. Add projects to Jenkins.
[15:08] <mandel> Blocked, no
[15:09] <ralsina> dobey: yes, I am not sure if we should generate from the big svg or from each svg generate one size only
[15:09]  * mandel hates 3g
[15:09] <lisettte> ralsina, dobey: can we chat about this?
[15:09] <dobey> ralsina: no we have to have different icons for some different sizes (some are ok to scale)
[15:09] <ralsina> dobey: yes, I know that. I must be very unclear today :-)
[15:10] <ralsina> dobey: nevermind :)
[15:10] <ralsina> lisettte: dobey, mumble?
[15:10] <lisettte> ralsina: yep
[15:10] <alecu_> DONE: some reviews, calls, researched piston-mini-client, and this small branch needing reviews: https://code.launchpad.net/~alecu/ubuntu-sso-client/fix-ssl-unicode/+merge/120013
[15:10] <alecu_> TODO: learn a bit more about ubuntupay
[15:10] <alecu_> BLOCKED: no
[15:11] <dobey> ok
[15:13] <alecu_> NOTE: I'm working from across the pond today, so I'm having limited conectivity
=== alecu_ is now known as alecu
[15:24] <dobey> ok, lunch time; bbiab
[15:26] <mmcc> mandel, have you done any work on making your daemon 32-bit compatible? You can probably avoid it. It looks like uname -p on darwin doesn't mean what I think it should mean.
[15:27] <mandel> mmcc, no I have not done that yet, what have you found out?
[15:28] <mmcc> the man page says "-p    print the machine processor architecture name" - so you'd think that if it prints i386, then you don't have an x86_64 processor, right? well, that sounds weird so I should've double checked. it prints i386 on my new macbook, too
[15:28] <mmcc> and I should've remembered that the core 2 duo in my mac mini is x86_64. it's not *that* old
[15:29] <mmcc> anyway, let's compile your daemon for 64 bit only so we can avoid changing the instance variable definitions.
[15:29] <mmcc> this doesn't affect ARC though
[15:29] <mmcc> still no arc on 10.6 so that wasn't wasted effort :)
[15:30] <mandel> mmcc, ok, I'll play a little with the compiler flags to see whathappens
[15:30] <mandel> I can always try to make it run on rosseta  ;-)
[15:31] <mmcc> mandel: I don't think you need to play - the flags as you've got them in the projects I've seen are 64-bit-only
[15:31] <mmcc> mandel: talk about wasted effort! :)
[15:31] <mmcc> so uh, did any of you mac-having guys get my email last night about the control-panel test issues?
[15:32] <mandel> Lol
[15:32] <mandel> mmcc, got it, but I have not tried it yet
[15:34] <mmcc> mandel: ok. you have run control-panel tests on your mac at some point right? so I'm guessing you don't see the slowdown issue
[15:35] <mandel> mmcc, not much as far as I cab remember, I'll try in the lion vm
[15:35] <mandel> can
[15:35] <mmcc> mandel: ok, cool. thanks
[15:36] <mandel> stupid fingers..
[15:36] <mandel> mmcc, no problem
=== salgado is now known as salgado-lunch
[16:13] <mandel> EOD, I'm off to the swimming pool
[16:20] <mmcc> well, anyone else have a sec to try running u1cp tests on a mac? ralsina, alecu ?
[16:21] <ralsina> mmcc: leaving for a doctor appointment / lunch
[16:22] <mmcc> ralsina: ok, no prob. I hope those are separate things
[16:22] <ralsina> I may have lunch with a doctor!
[16:22] <ralsina> but yes, separate things
[16:24] <alecu> mmcc: I can give that a try
[16:25] <briancurtin> i too am heading to lunch/doctor, also separate things
[16:25]  * briancurtin out
=== salgado-lunch is now known as salgado
[16:28] <mmcc> thanks alecu.
[16:28] <mmcc> I might need to see a lunch doctor
[16:28] <dobey> mmcc: put the lime in the coconut, and mix it all up
[16:28] <mmcc> dobey :)
[16:29] <mmcc> dobey, should I switch control-panel run-tests to USE_PYFLAKES now? I'm changing it to remove the env vars for the new buildout…
[16:29] <dobey> mmcc: i guess not unless you want to fix all the lint warnings it will create upon doing so
[16:32] <alecu> mmcc: I've checked out https://code.launchpad.net/~mikemc/ubuntuone-windows-installer/improve-buildout/+merge/119195
[16:32] <alecu> mmcc: to start with a clean env
[16:33] <alecu> mmcc: so, how should I run it?
[16:33] <mmcc> dobey: hmm, so, maybe just use pyflakes on darwin now? since the need to fix the warnings is due to tarmac, right?
[16:33] <alecu> python setup-mac.py prepare --from-trunk py2app ???
[16:33] <mmcc> alecu, follow the 'dev-setup' google doc instructions first
[16:33] <dobey> mmcc: the need to fix the warnings is that we haven't been using pyflakes so it probably has warnings that we haven't paid any attention to
[16:33] <dobey> mmcc: you should see them on darwin too if you use pyflakes there
[16:34] <alecu> mmcc: I've already have the brew packages installed in this machine
[16:34] <mmcc> dobey: right, and I do, but I also see tons of pylint warnings because it's broken for me on darwin
[16:34] <mmcc> alecu, right - skip to the buildout section - cd scripts/devsetup
[16:34] <alecu> mmcc: qt 4.8.2 and pyqt 4.9.4
[16:35] <mmcc> alecu, ok. interesting…
[16:35] <mmcc> alecu, then python bootstrap.py --distribute, and bin/buildout install
[16:35] <dobey> mmcc: well if you want to switch to get rid of the warnings, and fix the new ones in pyflakes, then i think it's ok to switch it everywhere. whatever we do, it should be the same on all platforms
[16:35] <mmcc> (don't do "bin/buildout install development" anymore, i'll update the doc once this branch lands)
[16:36] <mmcc> dobey ok I'll hold off for now because I don't know how to fix the warnings about gettext
[16:37] <dobey> ah yes, i need to poke at that
[16:44] <dobey> i hope i don't have to do any reviews today
[16:44] <dobey> although, getting this reorg stuff done/packaged/MIRed before FF is not very likely at this point :-/
[16:46]  * mmcc was just about to ask dobey for a quick review of run-tests changes…
[16:46] <mmcc> there are actually three pending run-tests fixes but two are mac only
[16:46] <dobey> heh
[16:49] <mmcc> dobey, maybe just a visual review of https://code.launchpad.net/~mikemc/ubuntuone-control-panel/fix-1037904-run-tests/+merge/120057
[16:49] <dobey> and the current launchpad builders situation isn't helping me any :)
[16:49] <mmcc> and I won't bug you with the others :)
[16:50] <dobey> and code hosting going offline in ~5 hours surely won't add to that fun
[16:51] <dobey> mmcc: so i've noticed this; why all the getting rid of the special variables for u1lint/u1trial? you fixed the buildout i guess, to not require that nonsense?
[16:52] <mmcc> dobey: yes. the fixed buildout actually installs executable scripts named u1lint and u1trial in its bin/ directory
[16:52] <dobey> awesome
[16:52] <mmcc> that's over here: https://code.launchpad.net/~mikemc/ubuntuone-windows-installer/improve-buildout/+merge/119195 if you're curious and you like pain
[16:52] <dobey> are they the ones from the source pull, or from the egg downlaod, or we don't do the egg download any more?
[16:52] <mmcc> they are the ones from the source pull and we don't do the egg download anymore
[16:53] <dobey> awesome
[16:53] <dobey> APPROVE
[16:54] <mmcc> or to be more specific, it installs wrappers that manually set sys.path to include the source dirs, and then the wrapper does the same thing as u1trial and u1lint -- it doesn't actually call the executables in bin/ because buildout is difficult
[16:55] <mmcc> let me know if you want details - the scripts will work as long as you don't add new code to the bin/u1trial script outside of main()
[16:56] <mmcc> there was so much code in bin/u1lint outside main that the wrapper script has to do imp.load_source('bin/u1lint') - but that means that changes will get picked up just fine
[16:56] <mmcc> anyway
[16:58] <mmcc> oh I see that wasn't the rhetorical APPROVE :) thanks
[17:03] <dobey> heh
[17:04] <dobey> well u1trial is all modularized now
[17:05] <mmcc> yeah, there's just the one line where it inserts '.' on sys.path. I just copied that over to the wrapper script
[17:06] <mmcc> buildout lets you add code to the wrapper script, but then it strips that code of all indentation.
[17:06] <mmcc> just had to share that bit, that was fun
[17:11] <alecu> mmcc: after some back and forth, I managed to start the u1cp tests in your review branch
[17:11] <alecu> mmcc: now osx is asking me if I want to install X11
[17:11] <alecu> mmcc: are we using it at all?
[17:11] <mmcc> alecu: well, *that* is unexpected
[17:11] <alecu> mmcc: (this is 10.8)
[17:11] <mmcc> no, we shouldn't be
[17:11] <alecu> mmcc: the dialog says "X11 is no longer included with os x.... blah blah"
[17:11] <mmcc> but I haven't tried anything on 10.8
[17:12] <mmcc> yeah… I wonder if qt was built with x11 support or something
[17:12] <dobey> probably
[17:12] <alecu> mmcc: it sent me here: http://support.apple.com/kb/HT5293
[17:13] <mmcc> alecu: yeah, xquartz is great but don't get it unless you really need x11. we should not require it
[17:13] <mmcc> I'm looking at the brew recipe for qt now
[17:14] <alecu> mmcc: anyway, I need to run to the bank now, and then catch a ferry
[17:14] <mmcc> alecu: ok, i'll let you know what I figure out
[17:14] <alecu> mmcc: I'll probably be looking at this when I get back home.
[17:14] <alecu> mmcc: btw: the buildout process is a lot more streamlined now, good job!
[17:15] <mmcc> alecu: thanks. it's nice to have it fixed
[17:25] <mmcc> OK, apparently the homebrew recipe for Qt built in a dependency on X11 to get libpng. AFAICT that's the only dependency
[17:26] <alecu> mmcc: good news: after installing xquartz, all tests have passed on u1cp
[17:26] <mmcc> someone on github has already posted a modified version the recipe that just does a direct dep on that, so I'll see how easy it is to switch over.
[17:27] <mmcc> or if we don't need to, and the answer is just install xquartz on the dev machines
[17:27] <alecu> this is using both branches mentioned in your email.
[17:27] <mmcc> alecu, I'm not sure that is good news… so you saw no error dialogs?
[17:27] <mmcc> and no 'counter' exceptions?
[17:28] <alecu> mmcc: I saw *a lot* of dialogs being opened by the tests
[17:28] <alecu> mmcc: but no test failed
[17:28] <mmcc> alecu: that's expected, and no tests should fail in either case.
[17:28] <alecu> mmcc: and I think I didn't see any weird dialog but ours.
[17:28] <mmcc> but the issue I saw on 10.7 was a lot^2 of error dialogs with an exception about underlying object being deleted
[17:29] <alecu> mmcc: I'll give it another go when I get back
[17:29] <alecu> now, I really really really need to be going!
[17:29] <mmcc> alecu: ok, ttyl
[17:29] <mmcc> thanks
[17:29] <alecu> bye!
[17:46] <mmcc> alecu - when you get back, try 'brew uninstall qt' , 'brew update' and 'brew install qt' again... I think that ought to get the new version (21 days old) of the qt recipe that removes the X11 dependency
[17:48] <ralsina> hello again
[17:49] <mmcc> we *do* need to update to that version to build the app, because as of now the packaged app has a dependency on libpng from x11, and so won't run on 10.8
[17:53] <mmcc> giiiiiit
[17:54]  * dobey imagines Capt. Kirk screaming that
[17:55] <dobey> mmcc: does https://code.launchpad.net/~mikemc/ubuntuone-windows-installer/fix-1037313-add-revnos/+merge/119799 include changes from that other buildout branch that just landed?
[17:56] <ralsina> mmcc: I sense frustration. Want to vent?
[17:56] <mmcc> dobey: apparently so, I should've set a prereq. can I do that after the fact?
[17:57] <mmcc> ralsina: oh, eh. homebrew uses git, and I need to update its copy of the qt recipe. but git checkout <hash> filename is complaining now when it didn't yesterday
[17:58] <mmcc> I can just tell brew to install from a URL though so that'll do for now
[17:58] <ralsina> mmcc: cool
[17:58] <ralsina> mmcc: perhaps some tea and a 5 minute break, too :-)
[17:58] <ralsina> mmcc: it would have helped kirk!
[17:59] <mmcc> ralsina: :) good idea. I have cookies. cooooookies > giiiiiit
[17:59] <ralsina> see?
[18:00] <dobey> mmcc: i don't think you can; maybe in the resubmit ui it's possible, not sure
[18:00] <dobey> mmcc: or you could just merge trunk in and push back up
[18:01] <dobey> also
[18:01] <dobey> now i want cooooooookies
[18:02] <ralsina> mmcc: I suggest remerging trunk if the other branch already merged
[18:02] <ralsina> damn, I want cookies too
[18:02] <ralsina> <kirk>raaaaaaaaaaaain</kirk>
[18:13] <mmcc> back with cookies. will remerge trunk, good idea
[18:14] <dobey> cool, thanks
[18:14] <dobey> will make it easier to read the diff :)
[18:20] <mmcc> pushed
[18:39] <dobey> brb
[18:40] <mmcc> homebrew calls "installing from a pre-built tarball" "pouring a bottle". It prints "=> Pouring..." to the screen. Why does that bother me so much?
[18:40]  * mmcc is getting old or something
[18:41] <mmcc> or maybe it's just that anything a package manager printed while I was waiting for a Qt install for the fourth time in two days would make me mad
[18:41] <ralsina> mmcc: at least it doesn't try to a ascii-art bottle pouring
[18:42] <ralsina> mmcc: I know of a program whose build message logs draw a color mandelbrot set on screen
[18:43] <mmcc> ralsina: hah.
[18:45] <mmcc> actually i'd watch the ascii art. it'd be a nice progress bar
[18:46] <ralsina> mmcc: not telling you to do it! But check out http://pypi.python.org/pypi/progressbar/2.3-dev
[18:46] <ralsina> mmcc: turning that into a beer-pouring bottle is a nice experiment
[18:47] <mmcc> ralsina: heh, nice. I'll add it to the list of projects I'd like to do and never will :|
[18:47] <ralsina> mmcc: hey, I have a list just like that!
[18:47] <mmcc> I keep that list in my guitar case
[18:47] <ralsina> mmcc: the one you will learn to play someday? ;-)
[18:48] <mmcc> ralsina: that's the one!
[18:48]  * ralsina adds "buy a guitar" to his list
[18:49] <ralsina> there, tight below "start a list (crossed out)"
[18:49] <ralsina> right*
[18:49] <mmcc> heh. progress!
[18:52] <mmcc> alecu - when you get back, here's what will actually work (ignore what I said earlier): 'brew uninstall qt &&  brew install https://raw.github.com/mxcl/homebrew/master/Library/Formula/qt.rb'
[18:53] <mmcc> that works to remove the dependency on X11, which will leak from dev machines into the packaged app and make the app break on default 10.8 systems
[18:53] <mmcc> now to test to make sure it still does the captcha correctly despite no longer linking to libpng
[18:54] <mmcc> the homebrew committer claims that the fix is to just not link to libpng and qt will use 'internal' png mumble mumble.
[18:54] <ralsina> mmcc: qt has a switch to choose internal or external libqt in its configure
[18:54] <ralsina> mmcc: the recipe must set that somewhere
[18:56] <mmcc> ralsina: it doesn't mention it now, maybe internal is default
[18:57] <mmcc> aha, yeah -- previously it specified -system-libpng for configure
[18:57] <mmcc> now it doesn't
[18:58] <mmcc> hooray
[18:58] <mmcc> btw ralsina do you have a sec to brainstorm on that control-panel test issue? my hack lets me run the tests just fine, but I'm not sufficiently familiar with qt & pyqt to know if it's actually solving the problem
[18:59] <ralsina> mmcc: in 5' sire
[18:59] <ralsina> sure
[18:59] <mmcc> cool
[18:59] <ralsina> mmcc: your hack makes all the test dependent on the previous ones
[18:59] <ralsina> or leak memory
[19:00] <ralsina> depending on what happens at initialization
[19:00] <mmcc> hrm. I thought it'd just leak memory - I'm pretty sure it instantiates new UI classes in setUp.
[19:03] <mmcc> memory usage got to 600MB by the end of the tests with the hack, without it , it stays at ~140, but each test case takes ~6 seconds to run and shows many "sorry an error occurred" dialogs
[19:05] <mmcc> hm, no, memory growing in the non-hack case now too
[19:07] <ralsina> mmcc: in that case, then it doesn't matter
[19:07] <ralsina> mmcc: it does seem to be reinitializing
[19:07] <mmcc> well, actually it went back down. it's tidy
[19:08] <mmcc> er, the non-hack case is definitely using less memory, I mean
[19:08] <ralsina> mmcc: so, if the problem is a "C++ object was deleted" in the deleteLater call, then commenting it should be ok
[19:09] <mmcc> well I don't know where the error is coming from - no backtrace… maybe I can try to get logs…
[19:11] <mmcc> AHA - debug logs print out the backtrace, wish I'd thought of this sooner: http://paste.ubuntu.com/1153201/
[19:13] <mmcc> it's calling update_sizes from a timer:         self.timer.timeout.connect(self.update_sizes)
[19:13] <mmcc> is that happening after the test let the object get collected?
[19:15] <ralsina> yes
[19:15] <ralsina> apparently
[19:15] <ralsina> but why only on mac?
[19:15] <mmcc> and only on 10.7
[19:15] <ralsina> could you add a self.timer.timeout.disconnect() before the deleteLater?
[19:17] <mmcc> probably. there's a lot of inheritance going on in these tests…
[19:17] <mmcc> looking for the right place to add it…
[19:20] <dobey> well
[19:20] <dobey> so much for reviews i guess
[19:21] <dobey> Oops! is all i get
[19:22] <ralsina> dobey: launchpad was down today too?
[19:22] <ralsina> dobey: for maintenance?
[19:23] <dobey> ralsina: for varying definitions of 'down'
[19:23] <dobey> ppa builders have been down-ish since sometime yesterday
[19:23] <ralsina> dobey: yeah
[19:23] <ralsina> awesome timing
[19:24] <dobey> ralsina: yeah. the 12.04.1 team is *loving* it ;)
[19:24] <ralsina> I can imagine
[19:25] <ralsina> hopefully everything will be up by monday, but having trunk nightlies to try the weekend before release is something I ... enjoy?
[19:25] <dobey> yeah, i'm a bit upset about not having nightlies
[20:15] <mmcc> lunch…
[20:43] <briancurtin> i dont think i can keep using Q if it's going to waste my time constantly
[20:43] <briancurtin> now the login screen thinks my monitor is like 10 feet wide and there's nowhere to type my password (also doesn't display my name either, just the box for it)
[20:48] <dobey> fun
[20:50] <ralsina> briancurtin: is that a Q daily?
[20:51] <ralsina> briancurtin: they merged a whole pile of things yesterday (whole x11 stack update)
[20:51] <ralsina> briancurtin: happens every cycle just before FF :-(
[20:51] <dobey> and some unity changes
[20:51] <dobey> like, no more unity2d
[20:59] <ralsina> and a new llvm-whatever soft-rendering for unity-3d
[20:59] <ralsina> EOW for me, except for a quick check tonight
[21:03] <briancurtin> ralsina: yeah it's daily. it screwed up yesterday but i sort of got it working by switching to XFCE, sort of, but now nothing works. i'll just work on stuff from windows for now and keep trying back i guess
[21:07] <ralsina> briancurtin: you could try removing lightdm and setting up some other-dm
[21:08] <briancurtin> i'll see what the options are
[21:10] <dobey> sudo apt-get install gdm will give you the option to do that in the postinst
[21:10] <dobey> gdm is the upstream gnome dm
[21:11] <briancurtin> thankfully i remembered ctrl-alt-F1. havent had to do that in a long time
[21:17] <briancurtin> eh, that does get me in but everything flashes like crazy. i guess that makes sense based on what seems to have been updated
[21:22] <briancurtin> XFCE seems to work, so i think i'm back in business
[21:23] <ralsina> briancurtin: godspeed :-)
[21:48] <dobey> have a good weekend everyone
[21:49] <briancurtin> bye dobey
[22:20]  * alecu peeks around.
[22:20] <alecu> hello!
[22:20] <briancurtin> just about to head out of here, but hola alecu
[22:21] <alecu> bye briancurtin, have a great weekend!
[22:21] <briancurtin> you too
[22:29] <mmcc> oh hi alecu. bye briancurtin
[22:29] <mmcc> alecu, looks like there's a way to avoid that X11 dep, but for now you don't need to worry about it. Glad you caught it now, though :)
[23:05] <alecu> Warning: Your Xcode (4.4) is outdated
[23:05] <alecu> Please install Xcode 4.4.1.
[23:05] <alecu> thanks brew!
[23:23] <alecu> wow, pouring a bottle was much faster than brewing my own qt. It makes sense :P
[23:27] <alecu> mmcc: in case you are still around:
[23:27] <alecu> Ran 1143 tests in 39.321s
[23:27] <alecu> (control panel, qt tests)
[23:28] <mmcc> ok… so no speed issues. and it's on 10.8. maybe my issue is just 10.7?
[23:28] <alecu> mmcc: I had installed the custom qt brew formula, and uninstalled x11
[23:28] <mmcc> does it print any exceptions as it runs?
[23:28] <mmcc> good, glad that works for someone else :)
[23:29] <alecu> mmcc: no exceptions at all, and no dialog boxes (other than the dialogs we are testing)
[23:29] <mmcc> argh
[23:30] <alecu> argh indeed
[23:30] <alecu> mmcc: we should ask ralsina to run these tests on monday on his macmini, since it should still be on 10.7
[23:30] <mmcc> ah, yeah. that'd be interesting
[23:31] <alecu> mmcc: also, we can posibly ask him to share it with vnc or the like so you can fidget with it.
[23:31] <alecu> (fidget? is that the real word I wanted to use?)
[23:31] <mmcc> maybe fiddle
[23:32] <alecu> mmcc: yeah, fiddle. thanks!
[23:32] <alecu> unless you get really nervous while fighting qt, and in that case it would be fidget all right :-)
[23:32] <mmcc> I'm wondering if I've wasted enough time on this. I have a hacky workaround for my system. I guess it's worth seeing if ralsina has the issue too, but if he doesn't I'm ready to just give up - since it is only a problem with cleaning up tests…
[23:33] <mmcc> and only on one platform
[23:34] <alecu> mmcc: I thought it was making the tests real slow for you, too.
[23:34] <mmcc> I think flail, flounder and flog are all appropriate here.
[23:34] <alecu> mmcc: if they run in a reasonable amount of time on your machine and on our 10.7 jenkins, then yes, let's not worry.
[23:34]  * alecu runs for the dictionary
[23:34] <mmcc> it was - but if I comment out the deletelater as I mentioned in the email last night, everything runs fine. It just uses about 2-3x more memory :)
[23:36] <alecu> mmcc: then, as long as we don't break the jenkins vm, or your dev machine...
[23:36] <alecu> :-)
[23:36] <mmcc> so, hacky - not what I'd want to commit, but trying to find a more correct fix has cost me hours today with nothing so far. The problem is that the local_folders page is instantiated every time you start a wizard, so all the tests create one, and some of them call load() which starts the timer, and others don't, and it's just a mess trying to figure out what test case superclass to poke at
[23:39]  * alecu hates the hackiness that comes from mixing unit and integration tests :/
[23:40] <alecu> mmcc: what about mocking the timer all of the time?
[23:40] <alecu> (all of the time... see what I did there?)
[23:40] <mmcc> heh
[23:40] <alecu> mmcc: or at least, not mocking it when testing the timer itself.
[23:40] <mmcc> oh don't worry, the timer isn't tested
[23:41] <alecu> mmcc: though I don't recall if those bits of PyQt are mockeable.
[23:41] <mmcc> I did try mocking the timer, but I had trouble figuring out which test case class to patch - it seemed like I would always end up trying to patch something that didn't have a timer
[23:41] <alecu> mmcc: I mean, patcheable.
[23:42] <mmcc> along with something that did
[23:42] <mmcc> yeah, I ran into that too :)
[23:43] <mmcc> so i was just going to call timer.timeout.disconnect() in setup, but again, a twisty maze of test case class hierarchies
[23:43] <alecu> yup... I know about that :P
[23:43] <mmcc> I'm sure it's possible to get right, I was just wondering if it's really worth the effort to get right
[23:43] <alecu> mmcc: probably not
[23:44] <alecu> mmcc: as long as it runs decently enough for you and for our 10.7 vms, let's move forward.
[23:45] <alecu> mmcc: if it gets very slow or eats a lot of ram, let's fix it then.
[23:45] <alecu> mmcc: obviously, my opinion would be other if the problem was with production code, not with the tests...
[23:45] <mmcc> definitely
[23:46] <alecu> ok, this looks like EOW for me!
[23:47] <alecu> bye all!
[23:47] <mmcc> alright, thanks for sticking around - have a great weekend alecu
[23:47] <alecu> you too, sir!
[23:57] <mmcc> ok, time for me to go