[05:37] <mmcc> back 30 min ago or so, trying to iron out bugs in my setup-mac.py
[08:30] <JamesTait> Good morning all! :)
[11:07] <mandel> gatox, hola!
[11:07] <gatox> mandel, buenas
[11:07] <mandel> gatox, how did the interview go?
[11:17] <gatox> mandel, jejeej well, it was fun
[11:17] <gatox> mandel, i read inn twitter that you are going to try to execute u1
[11:18] <mandel> gatox, yes, after lunch I should be ready to jump with excitement or cry like a baby :P
[11:19] <mandel> gatox, there are a number of changes I have to make in sd because some of the actions in the daemon implementation are async when they are not in all the other ones
[11:19] <mandel> and merging or work is going to be a nightmare, but I'm sure we can deal with it :)
[11:22] <gatox> mandel, so it seems that we are goinng to have this working together...... I HOPE (if everything goes ok), to have this working today too..... i only need to fix 2 tests, and i'll be ready to propose the branch
[11:24] <mandel> gatox, oh, but I'm not proposing yet, I want to see it working then fix things is the daemon, land everything there see your code and merge mine with yours
[11:25] <mandel> gatox, proposing both at the same time is a very bad idea and I know you are closer to get it accepted than me
[11:25] <gatox> mandel, ........ i hope........ jejeje
[12:03] <alecu> Hola everyone!
[12:03] <gatox> alecu, hi
[12:13] <rye> erm... we stil have bug #978903 ?
[12:13] <ubot5`> Launchpad bug 978903 in ubuntuone-client (Ubuntu Precise) "[precise] Client is stuck due to Upload executing before MakeFile" [High,Fix committed] https://launchpad.net/bugs/978903
[12:21] <alecu> rye: it seems we still have it in precise
[12:24] <rye> alecu: am I able to assist in pushing the fix? I guess we need to re-build the proposed package based on the current one. It's 1 symbol change in the patch
[12:26] <alecu> rye: we were finishing another needed fix and we'll be releasing today
[12:26] <rye> alecu: for precise, right?
[12:27] <alecu> rye: right
[12:27] <rye> alecu: what's the bug number?
[12:28] <alecu> rye: bug #882062
[12:28] <ubot5`> Launchpad bug 882062 in ubuntuone-client (Ubuntu Quantal) "ubuntuone-client doesn't validate ssl certificates" [Medium,Confirmed] https://launchpad.net/bugs/882062
[12:28] <rye> alecu: hm, I thought that was already published
[12:28] <alecu> rye: it was, but there was a little bit missing
[12:29] <rye> understood
[12:32] <ralsina> good morning
[12:33] <gatox> ralsina, hi!
[12:35] <mandel> alecu, ralsina hello o/
[12:36] <mandel> well, short hello 'cause is lunch time already..
[12:36] <urbanape> mmcc: anything you want to hear from Labs folks?
[12:37] <mandel> urbanape, he's usually here a little later.. /me hates time zones..
[12:37] <urbanape> yeah, tell me about it.
[12:37] <urbanape> I've been waking up at 6:30 EAST COAST TIME
[12:38] <mandel> urbanape, ouch! but at least you guys are all in the same continent, I'm the only eur in desktop+ .. I've started talking with my ring..
[12:39] <urbanape> easy, Gollum.
[12:39] <mandels_ring> Hello mandel!
[12:39] <mandel> lol
[12:39] <mandel> mandels_ring, I'm not calling you my precious, sorry ralsina ;)
[12:39] <mandels_ring> ring ring! Ring who?
[12:40] <mandel> ok, I'm really out to have lunch :)
[12:40]  * mandel lunch
[13:22] <joshuahoover> ralsina: looks like we need to have someone look at and fix bug #711413 as it's climbing the https://errors.ubuntu.com/ charts
[13:22] <ubot5`> Launchpad bug 711413 in ubuntu-sso-client (Ubuntu Quantal) "ubuntu-sso-login crashed with DBusException in __new__(): org.freedesktop.DBus.Error.NoServer: Failed to connect to socket /tmp/dbus-zPW5jjeWfI: Connection refused" [High,Triaged] https://launchpad.net/bugs/711413
[13:23] <dobey> eh?
[13:25] <dobey> joshuahoover: how is it climbing the charts? it's dropped down to number 17
[13:27] <dobey> joshuahoover: also, i've fixed it, i think. but nobody has been able to tell me if the fix actually fixes it or not :(
[13:29] <joshuahoover> dobey: heh, right...we do have some others that are higher
[13:29] <joshuahoover> dobey: we can't be beat!
[13:33] <dobey> now i wonder where my new workstation case is. aside from apparently at some facility in illinois
[13:34] <ralsina> joshuahoover: yep
[13:34] <ralsina> joshuahoover: mvo was looking at it last I heard
[13:34] <dobey> no
[13:34] <ralsina> no?
[13:34] <dobey> mvo was looking at a different one
[13:35] <ralsina> oops then
[13:35] <dobey> oh, no, nevermind
[13:35] <dobey> yes that is the one he was looking at
[13:35] <dobey> and i haven't fixed it
[13:35] <ralsina> However, it's a completely harmless bug
[13:35] <dobey> for some reason i was thinking of the ValueError: empty dict bug
[13:35]  * ralsina does the I was right dance
[13:36] <ralsina> it involves finger-pointing
[13:36] <dobey> it's too early for me
[13:36] <joshuahoover> and here i thought i'd witness a fight
[13:36] <joshuahoover> disappointing
[13:38] <dobey> and that exact same problem happens for many different apps
[13:38] <dobey> not just sso
[13:40] <dobey> like, the video lens and remote scope
[13:41] <dobey> anyway
[13:41] <davidcalle> dobey, fixes are coming with a SRU next week.
[13:41] <dobey> davidcalle: how did you fix it?
[13:44] <ralsina> By not crashing if the dbus connection fails?
[13:44] <ralsina> I know, wildly optimistic of me
[13:48] <davidcalle> dobey, I didn't fix it, yet. But it's mostly catching errors that are not catched, right? Lens daemons are automatically restarted when they crash or are exited.
[13:49]  * mandel back
[13:50] <dobey> how do you test that catching an error is the right fix?
[13:50] <dobey> "hope the crash count goes down" isn't sufficient
[13:52] <davidcalle> dobey, Zeitgeist had the same issue. Catching it -apparently- solved it. But I'm not aware of a good test plan for this.
[13:53] <ralsina> dobey: we have a trace for it, we know exactly where to catch that specific exception. OTOH, I am not 100% sure that's more than hiding the symptoms.
[13:54] <ralsina> Or rather, I *know* it's just hiding the symptom.
[13:54] <dobey> right
[14:05] <joshuahoover> Chipaca: any ideas on this video lens bug #950862 ?
[14:05] <ubot5`> Launchpad bug 950862 in unity-scope-video-remote (Ubuntu) "unity-scope-video-remote crashed with GError in function(): Could not connect: Connection refused" [Low,Confirmed] https://launchpad.net/bugs/950862
[14:06] <ralsina> joshuahoover: I think that's what davidcalle was just talking about :-)
[14:07] <joshuahoover> ralsina: ah...can you tell i pay no attention to your conversations here? ;)
[14:08] <ralsina> joshuahoover: it was a conversation you started, too :-)
[14:08] <joshuahoover> ralsina: i'm good like that
[14:09] <ralsina> dobey: OTOH, it's a symptom of session management being wacky, not of something wrong with sso :-/
[14:14] <dobey> man sso tests can be slow
[14:34] <joshuahoover> ralsina: ever seen this error in windows syncdaemon logs? AttributeError: Values instance has no attribute 'debug_manhole' ...a first for me
[14:34] <ralsina> joshuahoover: seen it
[14:34] <ralsina> joshuahoover: means "you are starting syncdaemon without its configuration file"
[14:35] <joshuahoover> ralsina: weird...hmmm...user has reinstalled u1 and still gets the error...any ideas?
[14:35] <ralsina> joshuahoover: not really, only seen it in development
[14:35] <ralsina> joshuahoover: permission problems and/or broken debug.conf is what I would guess
[14:36] <joshuahoover> ralsina: k, thanks
[14:44] <dobey> joshuahoover, ralsina: i think i have a brnach for the dbus thing.
[14:45] <joshuahoover> cool
[14:46] <ralsina> dobey: nice
[14:46] <dobey> ralsina: i even wrote a test!
[14:46] <ralsina> dobey: whoa
[14:46] <ralsina> dobey: did it hurt?
[14:47] <dobey> yes
[14:48] <dobey> hrmm. lp is being slow though
[14:48] <Chipaca> davidcalle: you say "lens demons are automatically restarted", but that is false, empirically
[14:50] <gatox> mandel, ping
[14:50] <davidcalle> Chipaca, I'm sure they are. Scopes are restarted instantly and Lenses are restarted when the Dash is opened/closed or the lens searched. When they have a dbus .service file.
[14:51] <mandel> I've officially changed so many calls in sd that I'm scraed it works..
[14:51] <mandel> gatox, pong!
[14:51] <gatox> mandel, which was the tag we were using for mac? darwin-u1 or u1-darwin?
[14:51] <mandel> u1-darwin
[14:51] <gatox> mandel, thx
[14:51] <mandel> gatox, and is read the following way: 'uh! one darwin!'
[14:52] <alecu> meanwhile, charles darwin twists in his grave
[14:52] <mandel> gatox, and then  point at a darwin :)
[14:52] <gatox> mandel, jajajaja
[14:55] <gatox> mandel, i'm going to propose my filesystem_notifications branch, i created 2 bugs for the missing things that i have on this.... so i can start having a couple of review from you and alecu ..... who works with the other implementations, and i can start fixing things while i work in the missing features
[14:55] <gatox> mandel, the tests are all green for what i have now
[14:56] <gatox> file_moved_from_partial and add_watches_to_udf_ancestors are missing..... and of course... any improvee and bug fix that came up from the reviews
[14:56] <mmcc> howdy
[14:56] <mandel> gatox, ok, I'm making a HUGE change in sd because rm_watch must return a deferred which then makes blah return a deferred and then blahblha that calls blah return a deferred and so on..
[14:56] <gatox> mandel, ahhhhh right
[14:57] <mmcc> ralsina, dobey I just fwded you the response from the ocmock guy
[14:57] <ralsina> mmcc ack
[14:57] <dobey> col
[14:58] <alecu> mandel: uh, that sounds like a loooot of work :P
[14:59] <mandel> alecu, yes, and I'm scared I forget something so I'm going really slow with it
[14:59] <mandel> alecu, which is also interesting because rm_watch on windows returns a deferred so I'm surprise we have seen no issues about that
[15:00] <gatox> me!
[15:00] <briancurtin> me
[15:00] <thisfred> me
[15:00] <dobey> you're all early
[15:00] <mmcc> me
[15:00] <ralsina> me (no notes)
[15:00] <dobey> meh
[15:00] <alecu> me
[15:00] <gatox> mandel, ^
[15:01] <mandel> me
[15:01] <gatox> DONE:
[15:01] <gatox> Propose the u1-client filesystem_notifications branch, start working on the missing features for this branch.
[15:01] <gatox> TODO:
[15:01] <gatox> Finish with this feature, fix everything that came up from the reviews.
[15:01] <gatox> BLOCKED:
[15:01] <gatox> No
[15:01] <gatox> briancurtin, go
[15:01] <briancurtin> DONE: trying to get dev-tools more easily integrated into buildout from lp (no more out-of-date eggs), proposed two small branches for versioning installers on jenkins
[15:01] <briancurtin> TODO: hopefully it's time to do 3.0.2 windows installers
[15:01] <briancurtin> NOTE: doctor's appointment in the early afternoon
[15:01] <briancurtin> BLOCKED: none
[15:01] <briancurtin> NEXT: thisfred
[15:01] <alecu> mandel: probably because "removing" a watch is not as time sensitive as adding one.
[15:01] <thisfred> DONE: Bug #1006879 Bug #1009505 TODO: Bug #1006876 BLOCKED: no NEXT:  mmcc
[15:01] <ubot5`> Launchpad bug 1006879 in U1DB "api for validating transaction_id of source_replica" [High,In progress] https://launchpad.net/bugs/1006879
[15:01] <ubot5`> Launchpad bug 1009505 in U1DB "get_keys_from_index is useless for multicolumn indexes" [High,Fix released] https://launchpad.net/bugs/1009505
[15:01] <ubot5`> Launchpad bug 1006876 in U1DB "put_doc_if_newer should check replica_trans_id" [High,Confirmed] https://launchpad.net/bugs/1006876
[15:01] <mmcc>  DONE: reviewed objc for mandel, setup-mac building from lp trunk
[15:01] <mmcc>  TODO: fix bug in setup-mac, work on controlpanel fails,
[15:01] <mmcc> BLOCK: could use extra eyes on setup-mac bug
[15:01] <mmcc>  NEXT: dobey
[15:01] <dobey> λ DONE: branch landing and backporting craziness, protocol 3.0.2 release
[15:01] <dobey> λ TODO: finish stable release, finish releases/uploads, tarmac tweakery
[15:01] <dobey> λ BLCK: None.
[15:01] <dobey> ralsina:
[15:01] <ralsina> DONE: mgmt call, started on bug triaging TODO: fix bug #1012620, bug triaging, 1-1s BLOCKED: no, NEXT alecu
[15:01] <mandel> alecu, yes, that might have saved our ass
[15:01] <ubot5`> Launchpad bug 1012620 in ubuntuone-client (Ubuntu) "Should ignore .goutputstream-XXXXXX files" [Medium,In progress] https://launchpad.net/bugs/1012620
[15:02] <alecu> DONE: various branches for txweb ssl issues
[15:02] <alecu> TODO: review day, work on windows build
[15:02] <alecu> BLOCKED: no
[15:02] <alecu> NEXT: mandel
[15:02] <mandel> DONE: Started integrating fsevents-daemon conde in u1-client. Made rm_watch return a deferred and followed the chained calls to make sure things work
[15:02] <mandel> TODO: Look at things that might have broken due to that change. Fix fsevents-daemon branches per review.
[15:02] <mandel> BLOCKED: no
[15:03] <alecu> mandel: also, on windows we really only "remove" watches on the top-level folders
[15:03] <alecu> mandel: so that may have helped too.
[15:03] <dobey> alecu, ralsina: can one of you review/test https://code.launchpad.net/~dobey/ubuntu-sso-client/fix-no-dbus/+merge/110083 on windows?
[15:03] <dobey> and osx if either of you can
[15:04] <dobey> or if mmcc, gatox, or mandel can test it on osx, that would be great
[15:04] <ralsina> dobey: no can do on windows, my VM exploded (again)
[15:04] <ralsina> dobey: and I am not rebooting
[15:04] <gatox> dobey, i can do it
[15:04] <alecu> dobey: I can run tests for it on windows
[15:04] <dobey> thanks
[15:04] <dobey> just want to make sure my test skipping worked and i didn't break them :)
[15:04] <mandel> I was going to say i can, but I'm late so
[15:04] <ralsina> So I do linux
[15:11] <dobey> although
[15:11] <dobey> hmm
[15:14] <gatox> ok..... i'll leave the tests for u1-client running and i'm going to have lunch
[15:15] <mmcc> so, I'm having one of those bugs where I'm certain I'm being dumb somewhere but I can't see where - anyone want to take a look?
[15:15] <dobey> that won't work
[15:17] <mandel> mmcc, sure, shoot
[15:17] <mmcc> The problem is that the dependency search code in py2app only finds the ubuntu_sso the *second* time I run setup-mac.py. For background, here's a paste of some debugging after the first run, where it can't import ubuntu_sso even though it's right there in the path;http://paste.ubuntu.com/1039199/
[15:18]  * mandel looks
[15:18] <mmcc> thanks mandel. I'm thinking it'll be something simple and I've just been staring at the same code too long
[15:21] <dobey> alecu, gatox_lunch: just pushed a ocuple fixes to that branch, that i just caught myself. :)
[15:21] <alecu> dobey: pep8 fixes?
[15:22] <mmcc> I'm also pushing the branch with setup-mac to lp:~mikemc/ubuntuone-windows-installer/setup-mac
[15:22] <dobey> alecu: yes, and calling the better shutdown_func() instead of self.shutdown() (which would have caused AttributErrors instead)
[15:22] <alecu> dobey: I just got this:
[15:22] <alecu> (crap, I can't paste in quassel from virtualbox)
[15:23] <dobey> alecu: trailing whitespace and expected 1 blank line?
[15:23] <alecu> dobey: right
[15:23] <dobey> yep, fixed those
[15:23] <alecu> dobey: great. I'll pull and re-run the tests on windows.
[15:24] <dobey> hrmm. why are the qt tests in sso so slow :(
[15:24] <ralsina> dobey: +1 for latest revno
[15:24] <mmcc> mandel, does what I'm doing in that paste make sense?
[15:25] <mandel> mmcc, can you print the path from build_app.py just for curiosity
[15:25] <briancurtin> elopio: here's an updated version of the installer name i can produce on jenkins - ubuntuone-4.1-windows-installer-20120612-214300.exe - does this work for you?
[15:25] <mandel> mmcc, and yes it does, I had to deal with something like that with windows
[15:26] <mmcc> mandel, I'm not sure exactly what you want me to print...
[15:26] <mandel> mmcc, the sys.path before you get the import error
[15:27] <mandel> mmcc, you can always extend the module finder and do whatever you want with it, the setup.py from windows does something like that to find certain deps that gave errors
[15:28] <dobey> sigh
[15:28] <mmcc> mandel, yeah, the options in the windows setup have  'ubuntu_sso' and 'ubuntu_sso.qt' in the 'includes' section -- and I guess that's why... I'm doing that here, too, that's how I get the importerror during setup instead of at runtime...
[15:29] <mmcc> mandel: if I don't add them manually the setup runs without complaint but doesn't package ubuntu_sso... :\
[15:30] <dobey> i apparently hit some button by accident in evolution, so it's only showing unread messages in my canonical folder now.
[15:30] <dobey> anyway, i'm going to get some lunch. bbiab
[15:30] <mandel> mmcc, is probable that the module finder gets confused by the imports and does not see them as dependencies..  lets try something super dirty, import the modules in the setup.py and check if it works
[15:30] <mandel> mmcc, just for testing, is not a real solution :)
[15:31] <mmcc> mandel: I'll print the sys.path from before the py2app step - note that I've used the same trick from the windows setup.py at line 373: http://bazaar.launchpad.net/~mikemc/ubuntuone-windows-installer/setup-mac/view/head:/scripts/setup-mac.py#L373
[15:31] <mmcc> mandel, right - I think I've done that already, but I'll go double check what happens
[15:32] <alecu> dobey: +1. I'm leaving the proposal open in case you want to wait for the darwin review
[15:32] <mmcc> mandel: note that I'm calling setup() multiple times -- I've never seen that done but it seems to work. let me know if that's a red flag
[15:33] <mmcc> mandel, importing ubuntu_sso from setup.py , right after adding the path to sys.path on line 373 works as you'd expect
[15:34]  * briancurtin brb
[15:34] <mandel> mmcc, as in, it is imported and you still get the error?
[15:34] <ralsina> WTF launchpad bzr: ERROR: Cannot lock LockDir(chroot-74104272:///%2Bbranch/ubuntuone-client/.bzr/branch/lock): Transport operation not possible: readonly transport
[15:35] <ralsina> oh right
[15:35]  * ralsina just forgot some bits
[15:35] <ralsina> so, wtf, self?
[15:35] <mmcc> mandel: er, I had it do a sys.exit() because i'm impatient with all the output... trying again
[15:38] <mandel> hehe
[15:38] <mmcc> mandel: ah wait, my bad, it doesn't import in the setup. this is the annoying thing about this bug, I have to remember to delete all the generated & staged stuff every time because it works the second time around
[15:39] <mmcc> I feel like I'm misunderstanding something about setup()
[15:40] <mmcc> It's structured the same way as the windows script - a "Prepare" Command subclass to run the subprojects' setup.py's, then copy things around before running the py2app Command subclass that does all the deps and packaging stuff
[15:42] <mmcc> so trying to import ubuntu_sso before doing the setup shouldn't work, because the prepare step hasn't run yet, so the path we just inserted on line 373 doesn't exist until later
[15:43] <mmcc> of course it works if you're running a second time because it's there from the first run. the thing is that it *is* also there when the py2app step tries to find it, as you see in the paste
[15:43] <mmcc> so under what circumstances could a module be verifiably present at a path in sys.path, but you still can't import it?
[15:44]  * mmcc done spamming, sorry
[15:44] <mandel> mmcc, no worries, let me read a little
[15:44] <ralsina> mmcc: if you have a folder with the same name and no __init__.py (just one way that can happen)
[15:44] <ralsina> mmcc: in any place in your sys.path
[15:45] <mmcc> ralsina: in any place? because the right one is at sys.path[0]...
[15:45] <mandel> ralsina, nice idea!
[15:45] <mmcc> ralsina: ok I'll see if that's going on
[15:45] <ralsina> mmcc: good question. I don't know.
[15:46] <mmcc> ralsina: yeah, I'd assume searching starts at [0], but at least this is something to check...
[15:46] <ralsina> mmcc: actually no, it starts at site.py IIRC but yes, usually [0] is early enough :-)
[15:47] <ralsina> mmcc: you can use python -v to see how it imports
[15:47] <mmcc> ralsina: our buildout python doesn't like -v :) there's an env var, though right?
[15:48] <ralsina> mmcc: dunno
[15:48] <mmcc> PYTHONVERBOSE=1
[15:48] <mmcc> naturally, Terminal.app hangs now
[15:50] <ralsina> mmcc: may be too much verbosity for it
[15:50] <ralsina> daaaaaaaamn running u1-client tests takes a while!
[15:51] <mmcc> ralsina: heh, no it actually handles HUGE tracebacks pretty well, but just hung while I tried to switch tabs, frantically mashing all the different keycombos I know of that switch between things. The third and fifth tries worked
[15:51] <mandel> ralsina, yes! an on windows even more and I'm making them slower (not  on purpose)
[15:52] <ralsina> mandel: fun!
[15:52]  * ralsina needs to expense a i7 then
[15:52] <mandel> ralsina, is more the fs than the cpu
[15:52] <ralsina> this HD is pretty pathetic
[15:52] <ralsina> so maybe a SSD is a good idea
[15:54] <mandel> ralsina, problem is, we hit it a lot, so it will last you less that it will last someone else..
[15:56] <mmcc> ralsina: if you're expensing hardware, we should really have a retina-display macbook so we can test our graphics at 2x resolution :)
[15:56] <gatox> mandel, alecu when you have a (big) moment, please review this: https://code.launchpad.net/~diegosarmentero/ubuntuone-client/darwin-fsevents/+merge/110098 (i think that it would be a couple of things to fix/improve)
[15:56] <gatox> ok...... u1-client fsevents proposed..... now..... to fix what it come from the reviews and implements the missing features
[15:57] <mmcc> PYTHONVERBOSE fails to enlighten, but maybe py2app's --debug-modulegraph will help
[15:58] <ralsina> mmcc: I like how you think.
[15:58] <gatox> mmm this branch is kind of..... big....... sorry
[15:58]  * ralsina realizes the only hardware he has ever expensed is a mac mini and weeps for spending money on evil things.
[15:59] <ralsina> gatox: whoaaaaaa
[15:59] <gatox> i'm fixing a couple of things i miss..... pushing some changes in a few mins
[16:00] <gatox> ralsina, are you going to buy a new machine?? i really recommend the asus zen..... but tests the keyboard first..... it requires a mind ajustment :P
[16:00] <ralsina> gatox: nah, I am still happy with the toshiba
[16:00] <ralsina> gatox: I may buy the SSD though
[16:01] <gatox> ralsina, yes.... with a ssd you really notice the difference
[16:14] <alecu> gatox: I'm doing one review of that branch, but after lunch
[16:16] <gatox> alecu, noo problem
[16:20] <alecu> ralsina, briancurtin: from which stable are we doing the windows releases? stable-3-0?
[16:22] <ralsina> alecu: yes
[16:22] <mandel> gatox, I'll do tom, is late here and would not be a good review..
[16:25] <gatox> mandel, of course
[16:25] <mandel> alecu, dobey, ralsina, how do you feel about an extra check in our tests that ensures that if a test has a yield it does use the defer.inlineCallbacks decorator?
[16:28] <dobey> mandel: we have something like that already; though it might only do it for setUp/tearDown at the moment
[16:28] <alecu> mandel: it sounds like a good idea, but I'd like us to give it a bit more thought first.
[16:28] <alecu> anyway, I'm off to lunch.
[16:28] <alecu> bbiaw!
[16:28] <gatox> dobey, +1 on your branch for the tests on mac
[16:29] <gatox> dobey, wow.... you have 3 approves
[16:29] <mandel> dobey, yes, it just do setUp and tearDown, that is why I mentioned it
[16:29] <gatox> dobey, should i change it to globally approve or do you want to wait for anything else?
[16:30] <dobey> gatox: sounds good then :)
[16:30] <gatox> ack
[16:30] <dobey> thanks
[16:39] <dobey> bugger. the riser card i got doesn't fit in any pcie slots on my board :(
[16:40] <dobey> doh pylint
[16:42]  * dobey fixes
[16:47] <elopio> briancurtin: it will work perfectly. Thanks a lot.
[16:49] <mandel> ok, EOD my head is about to implode, see you all tom!
[16:52] <ralsina> bye mandel!
[16:54] <dobey> later mandel
[16:56] <gatox> mandel, bye
[16:59] <ralsina> dobey, alecu: trivial branch https://code.launchpad.net/~ralsina/ubuntuone-client/ignore-goutput/+merge/110095
[17:07] <dobey> ralsina: any reason to not just do .* instead of .{6}? hardcoding a number there doesn't seem great to me
[17:07] <ralsina> dobey, mmcc: the license changes look good enough for me. It's never going to be a problem.
[17:07] <dobey> ralsina: right, i just sent a reply mail :)
[17:07] <ralsina> dobey: was the suggested change, I don't care one way or the other
[17:07] <dobey> to you/mmcc that is
[17:07] <ralsina> dobey: yes, saw it
[17:08] <dobey> rye: ^^ any reason to use {6} instead of * there?
[17:08] <ralsina> dobey: AFAICS, it always uses 6 chars there, but that may change in the future, so I'll change it
[17:09] <dobey> right :)
[17:09] <rye> dobey: more specific for the sake of being more specific, but you are right
[17:09] <ralsina> dobey: pushed. Any chance on getting this in 3.0.2? It prevents data loss
[17:09] <mmcc> dobey, just saw your mail re OCMock, and I agree. So I'll reply and say that'd work for us, and ask him to please proceed, sound good?
[17:10] <mmcc> cc ralsina ^^
[17:10] <ralsina> mmcc: +1 on that
[17:10] <dobey> ralsina: sure
[17:10] <dobey> mmcc: sure
[17:10] <rye> glocalfileoutputstream.c:      tmp_filename = g_build_filename (dirname, ".goutputstream-XXXXXX", NULL);
[17:11] <dobey> rye: yeah, but may change in the future
[17:11] <rye> dobey: yep, no objection to use .*
[17:13] <ralsina> jenkins on windows down!
[17:14] <briancurtin> looking
[17:15] <ralsina> it's a completely wtf failure, too!
[17:15] <ralsina> a fsm test failure in a build triggered by a SSO commit. sigh.
[17:16] <briancurtin> ooh i thought you meant the jenkins machine went down
[17:16] <briancurtin> weird
[17:16] <dobey> and it's an off-by-one error
[17:16] <ralsina> dobey: yes, that's the bonus
[17:17] <dobey> well, maybe next pass it'll succeed :)
[17:21] <ralsina> dobey: ha!
[17:22] <ralsina> let's see if it's true :-)
[17:28] <mmcc> sent ocmock email, now lunch
[17:28] <ralsina> there, fixed the build by magic
[17:28] <ralsina> full of confidence I am now
[17:58] <dobey> damned complex out-of-tree parallel updates
[18:08]  * briancurtin doctor's appointment
[18:15] <dobey> alecu, ralsina: https://code.launchpad.net/~dobey/ubuntu-sso-client/ssl-strict/+merge/110128 please?
[18:16] <ralsina> dobey: on it!
[18:20] <ralsina> dobey: +1
[18:21] <dobey> meh
[18:21] <dobey> it's causing a segfault
[18:21] <dobey> at least, it is for me
[18:24] <dobey> well, at the end of the tests
[18:24] <dobey> of the gtk tests
[18:30] <ralsina> really?
[18:30] <ralsina> weird
[18:32] <dobey> yeah, and the backtrace isn't enlightening
[18:32] <dobey> hopefully will be more so with some more debug symbols
[18:42] <dobey> grr
[18:43] <dobey> ralsina: does it not do so for you?
[18:43] <ralsina> dobey: didn't
[18:43] <ralsina> dobey: let me retry just in case
[18:45] <dobey> http://pastebin.ubuntu.com/1039507/ is the bt i'm seeing :(
[18:46] <ralsina> dobey: no segfault, no failure, no nothing
[18:46] <dobey> huh
[18:46] <dobey> ralsina: are you on amd64?
[18:47] <ralsina> dobey: intel i5
[18:47] <dobey> ralsina: i mean, are you using 64-bit ubuntu, or i386?
[18:47] <ralsina> dobey: 64 bit AFAIK
[18:47] <ralsina> dobey: how do I check?
[18:48]  * ralsina feels stupid
[18:48] <dobey> uname -m
[18:48] <ralsina> i686
[18:48] <ralsina> so may be 64-bit-specific
[18:48] <dobey> no, that's 32-bit
[18:48] <dobey> 64-bit would be x86_64
[18:48] <dobey> you're using the i686 kernel
[18:49] <dobey> ok, wtf is it crashing for me, but not for you, then
[18:49] <ralsina> yes, and it doesn't fail here, so it may be 64-bit specific. Unless you are also on 32 bits :-)
[18:49] <dobey> i am
[18:49] <ralsina> dobey: I did dist-upgrade 1 hour ago
[18:49]  * dobey checks the apts then
[18:50] <dobey> ralsina: and rebooted since as well?
[18:51] <ralsina> dobey: no, but it's not asking me to
[18:52]  * mmcc source leads me to PEP 302 Importers
[18:52] <dobey> well i see there is a kernel update, which is why i ask
[18:52]  * mmcc meant to verb that
[18:53] <ralsina> dobey: am on 3.2.0.24 which seems to be the latest
[18:53] <ralsina> although I did an upgrade, not a dist-upgrade
[18:53] <dobey> right, there's a new build of it
[18:53] <ralsina> ok, updating and rebooting, to see if I can make it fail
[18:53] <ralsina> should take 10' or so
[18:53] <dobey> oh no, there's a 25 now
[18:54] <dobey> no, i was just wondering if maybe i was seeing a kernel bug you weren't, because of the update
[18:54] <dobey> but i'm on 24 still too
[18:54] <dobey> and damn all these old kernels need to get removed automatically already
[18:55] <ralsina> 24.39?
[18:55] <ralsina> yeah, I have like 20 kernels. Sheesh.
[18:55] <dobey> yeah, 24.39 is what is being replaced
[18:55] <dobey> uname isn't more specific than the -24
[18:56] <ralsina> dobey: so, we are on exactly the same kernel and that's not it
[18:56] <ralsina> let's both upgrade & reboot, I guess
[18:57] <dobey> maybe i have bad ram
[18:58] <ralsina> dobey: we need a 3rd opinion. Tarmac's? ;-)
[18:59] <dobey> maybe
[18:59] <dobey> someone else want to review it?
[19:04] <mmcc> I can help, if testing in a VM is useful
[19:05] <dobey> https://code.launchpad.net/~dobey/ubuntu-sso-client/ssl-strict/+merge/110128
[19:07] <mmcc> k, thanks
[19:12] <dobey> hmm
[19:13] <dobey> ralsina: nope, it's dumping core on the tarmac instance as well
[19:13] <ralsina> dobey: only remotely bad thing I get is this Gtk-CRITICAL **: gtk_scrolled_window_add: assertion `child_widget == NULL' failed
[19:13] <dobey> yeah, that was happening before
[19:13] <mmcc> ralsina: I get that too, but the test still passes.
[19:13] <ralsina> but tests finish
[19:14] <ralsina> dobey: full log (stdout & stderr) https://pastebin.canonical.com/68043/
[19:14] <dobey> and tarmac is x86_64, so it's not a bit issue
[19:15] <mmcc> core dump in my vm after gtk tests...
[19:15] <dobey> ralsina: ah, so it does fail for you; you're just not getting a segfault for some reason
[19:17] <mmcc> is any of the error-reporter info useful? where does the 'send an error report' go to?
[19:18] <ralsina> dobey: nothing says failure. Maybe it's being subtle.
[19:18] <dobey> mmcc: not useful in this case. but it generally reports a bug on launchpad, i think
[19:18] <dobey> ralsina: do you not notice that the qt tests weren't run there?
[19:19] <dobey> g_dbus_connection_real_closed: Remote peer vanished with error: Underlying GIOStream returned 0 bytes on an async read (g-io-error-quark, 0). Exiting.
[19:19] <dobey> Terminated
[19:19]  * mmcc considers set -e harmful
[19:20] <dobey> mmcc: well, we either use set -e, or reimplement set -e in a bunch of bash code. i'd prefer to just do set -e
[19:20] <dobey> for run-tests, set -e makes sense
[19:20] <mmcc> dobey: fair enough, but it'd be nice if we could always print a summary "1/2 test suites pass" or something
[19:21] <ralsina> dobey: but it fails *after* the tests are finished
[19:21] <mmcc> (and set -e precludes that). it's come up a couple of times
[19:21] <dobey> ralsina: yes, same here, except it's a segfault
[19:21] <ralsina> dobey: oh, ok
[19:21] <dobey> and i don't get a g_dbus message
[19:21] <ralsina> the g_dbus one has happened intermittently t tarmac for a long time
[19:22] <dobey> mmcc: well, we really shouldn't have multiple test suites per project.
[19:22] <mmcc> dobey, oh sure, bring up the "right way"
[19:23] <mmcc> anyway, I'll stop distracting. ping me if I can help test ?
[19:23] <alecu> dobey: I'm on 64 bits, and I'm getting that error too.
[19:30] <dobey> weird
[19:42] <dobey> why can't code just work already
[19:47] <mmcc> ok I solved my little problem - I needed to clear sys.path_importer_cache before searching for modules so the runtime would actually look at the filesystem and notice that the 'prepare' step created a directory that was added to sys.path at the beginning of the script
[19:48] <ralsina> mmcc: I have never heard of such a thing
[19:49] <ralsina> but hey, if it works, it works
[19:49] <mmcc> ralsina: yep me neither! pep 302 ...
[19:50] <ralsina> reading it
[19:50] <ralsina> interesting, but things should never break that low in the totem pole
[19:51] <ralsina> I mean, needing to clean that means you have a stale finder, which is the thing that finds the files from which the modules are loaded
[19:51] <ralsina> any finder that doesn't find the module you just created would seem broken to me
[19:52] <mmcc> the problem is we put /path/to/module on sys.path before it exists
[19:52] <ralsina> mmcc: oh, ok it makes sense then
[19:52] <mmcc> so the importing mechanism gives that path a nullimporter in the cache before we populate it
[19:52] <ralsina> mmcc: to a point
[19:53] <mmcc> and the module finder can't do any better than using the pep302 importing mechanism -- except maybe it should clear the importer_cache before starting, just to be really sure
[19:54] <mmcc> I might make that suggestion, but I'm not sure how much of a general problem we've got here
[19:54] <mmcc> this also only shows up when you do "setup-mac.py prepare py2app" -- if you did prepare and py2app separately it'd work
[19:55] <mmcc> I think maybe I spent too long on this? I thought the one-liner of 'prepare py2app' that more or less matches the windows invocation would make adding it to automated builds simpler
[19:55] <mmcc> anyway, on to *real bugs*
[19:56] <ralsina> mmcc: yes, totally not worth it
[19:56] <ralsina> mmcc: OTOH, we both learned something new :)
[19:57] <mmcc> yeah, :(
[19:57] <mmcc> true, now I won't expect importing to 'just work' even if I have the path right, ever again
[19:58] <dobey> hey look! hoops! time to jump through them!
[20:04] <gatox> people...... EOD here.....see you tomorrow!
[20:05] <mmcc> bye gatox
[20:05] <gatox> mmcc, bye
[20:05] <mmcc> ok, anyone with a mac handy, if you'd like to test out setup-mac.py and tell me how it breaks: https://code.launchpad.net/~mikemc/ubuntuone-windows-installer/setup-mac/+merge/110155
[20:06] <mmcc> there's a README-mac to explain things, since nothing is double-clickable just yet
[20:07] <ralsina> mmcc: wooooohooo
[20:07] <ralsina> not that mine is handy
[20:08] <ralsina> mmcc: I can take a look late tonight maybr
[20:08] <alecu> mmcc: I'll take a look soon, too
[20:08] <mmcc> ok, thanks
[20:16] <dobey> ralsina, alecu: i figured out a way to fix the segfault issue in https://code.launchpad.net/~dobey/ubuntu-sso-client/ssl-strict/+merge/110128 :)
[20:17] <ralsina> dobey: looking
[20:17] <alecu> dobey: what was it?
[20:18] <dobey> alecu: i don't know exactly, but moved it to a separate function, patched it in the tests, and added a test to ensure the function is getting called
[20:20] <alecu> dobey: so the solution is to not run that bit of code in the tests.
[20:21] <dobey> yeah
[20:21] <ralsina> that sounds like a "solution".
[20:21] <dobey> indeed
[20:21] <dobey> it is the same thing the tests are doing in the security update patches though; albeit likely for a different reason
[20:22] <dobey> and it didn't segfault in real code
[20:22] <ralsina> dobey: I get the same g_dbus_connection_real_closed in revno 970
[20:23] <dobey> ralsina: and it gets terminated, or it keeps going?
[20:23] <ralsina> dobey: terminated
[20:23] <ralsina> dobey: and only runs the gtk suite
[20:23] <dobey> ralsina: do you get it with trunk sso tests?
[20:23] <ralsina> dobey: I can check
[20:25] <ralsina> dobey: aha! It fails in trunk
[20:26] <dobey> ok :)
[20:26] <dobey> but not here, or in tarmac, it seems
[20:27] <alecu> dobey: why do we use "ssl-ca-file"? libsoup docs says it's deprecated:
[20:27] <alecu> dobey: http://developer.gnome.org/libsoup/stable/SoupSession.html#SoupSession--ssl-ca-file
[20:28] <ralsina> dobey: so, my reviews in sso are sorta useless at this point in time
[20:28] <dobey> alecu: it's what the code in the security update is using. and it would be nice to know *when* it was deprecated\
[20:28]  * briancurtin back, thanks to the doctor for finally showing up
[20:28] <alecu> right
[20:29] <dobey> alecu: and i can't seem to find anywhere what the "ssl-use-system-ca-file" actually uses for the ca file
[20:29] <dobey> plus it's true by default, and we also need to support the older versions of libsoup in natty/oneiric
[20:29] <dobey> so i presume we need to set it anyway for now, even if it is deprecated
[20:30] <dobey> oh, i guess use-system-ca-file is false by default :(
[20:30] <alecu> dobey: yes, it makes more sense to use the older setting so it works on N-O
[20:31] <dobey> i wish i knew what it actually uses in that case
[20:31] <alecu> dobey: it is false by default, yes.
[20:32] <alecu> dobey: "ssl-strict" says "If the session has no CA file or TLS database, then all certificates are always accepted"
[20:32] <dobey> right, which is annoying
[20:33] <dobey> so i guess i need to make it set the new property as well
[20:33] <dobey> sigh
[20:34] <dobey> at least it's only the terms and conditions URL
[20:41] <ralsina> how can that possibly be defined as strict?
[20:41] <dobey> it's a very loose definition of strict
[20:42] <dobey> and we should probably release an update to ubuntu, to make it actually be strict
[20:43] <alecu> can I get some reviews on this? https://code.launchpad.net/~alecu/ubuntuone-client/txweb-ssl-3-0/+merge/110165
[21:10] <ralsina> alecu: sure
[21:10]  * ralsina is having one of those days where everything he tries causes something else to explode
[21:12] <mmcc> ralsina: I know those days! so maybe a refreshing trivial review would be nice? https://code.launchpad.net/~mikemc/ubuntu-sso-client/fix-1012837-raise-and-shine/+merge/110167
[21:12] <dobey> ralsina: welcome to the grand world of engineering
[21:12] <ralsina> mmcc: queuing
[21:13] <ralsina> dobey: it's like science, but louder, I know
[21:13] <dobey> doesn't pylint and/or pep8 complain about multiple statements on the same line like that?
[21:13] <ralsina> it took me 45 minutes and a needsfixing to merge a branch with no code in it. Not my best showing.
[21:13] <ralsina> dobey, mmcc: yes they do
[21:14]  * mmcc feels shame
[21:14] <ralsina> mmcc: I know, pylint doesn't run well on mac :-)
[21:14] <mmcc> no, I rushed that through. tested the UI but didn't run the tests
[21:16] <mmcc> yeah, of course it screws up a bunch of tests, let alone the fact that pep8 isn't even on my amc
[21:16] <mmcc> s/amc/mac. -- back to the drawing board
[21:17] <mmcc> in other news, here is the image that was burned into my head as an "engineering" major -- from a course covering precision and error: http://upload.wikimedia.org/wikipedia/commons/1/19/Train_wreck_at_Montparnasse_1895.jpg (it was either in the slides or the cover of an estimation textbook)
[21:17] <ralsina> looks salvageable
[21:18] <dobey> hrmm. 1750x2100. not great for a large print
[21:19] <ralsina> argh, how the heck does one close the questions feature in launchpad
[21:19] <ralsina> before someone hurts himself: https://answers.launchpad.net/ubuntu/+source/ubuntuone-client/+question/200360
[21:19] <dobey> you can't
[21:19] <ralsina> not to mention that the questions feature is in a host called answers
[21:20] <ralsina> I will start posting on launchpad's launchpad answers things like "yes" "no" and "because it was not formulated in the form of a question"
[21:20] <dobey> also i moved it off ubuntuone-client (Ubuntu) to just Ubuntu
[21:20] <dobey> but eh
[21:21] <dobey> questions really does need to be extinguished
[21:21] <ralsina> it's even worse than askubuntu
[21:21] <dobey> or exanguinated
[21:28] <ralsina> alecu: +1 on code review, running the tests would take it beyond my EOD
[21:28] <ralsina> alecu: so I trust that you ran them
[21:29] <alecu> ralsina: thanks!
[21:30] <ralsina> and EOD
[21:37] <dobey> https://code.launchpad.net/~dobey/ubuntu-sso-client/update-3-0/+merge/110177 for sanity check anyone?
[21:45] <dobey> ok, i'm off as well. have a good eve all.
[21:59] <mmcc> ok, FWIW my branch https://code.launchpad.net/~mikemc/ubuntu-sso-client/fix-1012837-raise-and-shine/+merge/110167 is now style-compliant and the tests pass.
[22:24] <mmcc> hi urbanape, how is WWDC going for you? exhausted yet?
[22:25] <urbanape> little bit.
[22:26] <urbanape> it's going really well. I'm loving some of the stuff coming for iOS 6 and Mountain Lion
[22:26] <mmcc> cool. I need to catch up... busy week here, haven't had a chance to read up.
[22:26] <urbanape> how's the mac port going? Saw some tweets from mandel that looked promising (or at least tempting)
[22:27] <urbanape> teasing, rather
[22:27] <mmcc> not bad. packaging was being a real pain for me, but I think I've gotten py2app doing what I need
[22:28] <mmcc> and mandel and gatox are closing in on filesystem watching from different directions, both pretty close
[22:28] <mmcc> just now I got all the tests in controlpanel passing
[22:29] <mmcc> what's the main highlight for you for the OS upgrades?
[22:29] <mmcc> my family is going to really love ios6's shared photo streams, for sure
[22:36] <urbanape> will move it internally.
[23:02] <mmcc> hrm, looks like sso's xdg tests aren't run on darwin because there's no test_darwin in there. but we don't have any way of catching that unless there are bugs in the code - since we're ignoring all test_linux and test_windows files...
[23:06] <mmcc> no, that's wrong. there's a test_common that covers it, and I was just running control-panel with the wrong PYTHONPATH, as usual
[23:06]  * mmcc is tired
[23:14] <mmcc> ok, calling it a EOD
[23:15] <thumper> can someone help me work out why filesync is disabled on my server?
[23:19] <mmcc> hi thumper, it's after hours for most of the people in this channel. You will have better luck tomorrow during London / US business hours.
[23:20]  * thumper sighs
[23:20] <thumper> beuno: I blame you
[23:20] <thumper> beuno: plz get someone in nz/au
[23:20] <thumper> thanks mmcc
[23:21] <mmcc> thumper, sure. sorry I'm not more helpful.