[09:14] morning! === timmy is now known as Guest2045 [10:56] hello [11:18] good morning! [11:31] gatox, morning! [11:31] mandel, hi [11:54] * mandel lunch [12:03] hello! [12:06] alecu, hi [12:22] alecu, i talked with mandel, and i confirm one of the problems (it wasn't implemented for windows)..... and the other one maybe i can ask you later or something [12:25] gatox: I think I'm lacking a bit of context.... is this regarding the bug you mentioned yesterday? [12:25] alecu, yes [12:27] gatox: so, it's still failing with the progress reporting thru IPC from SD? are those the non-implemented bits? [12:27] alecu, tracking the progress of the file being uploaded is not implemented on windows [12:28] gatox: weird! why not? [12:28] gatox: there should be no platform differences in that! [12:28] alecu, i don't know..... and not 100% sure.... but that was the conclusion...... it works for linux, on windows it never returns the byes written [12:29] gatox: is that accessing SD thru ipc or accessing it directly? [12:30] alecu, the aggregator is accesint it directly [12:30] gatox: can you point me at the relevant bits of code? [12:31] alecu, mmm.... i don't know where to point you exactly.... i have the StatusAggregator and StatusFrontend collecting the commands Upload.... and returning the progress with that (tested with d-feet).... but debugging some code that uses that on windows..... the n_bytes_wrriten variable is always 0 [12:33] good morning! [12:33] ralsina, hi [12:33] morning chief! [12:35] gatox: oh, and thru d-feet you are accessing your dict, right? [12:36] alecu, yes.... from windows i get the same dict..... but with the progress always 0 [12:37] gatox: does every other field in that dict contain the right value? [12:37] yes [12:38] gatox: can you try logging the value in SD *before* it gets passed to the ipc layer? [12:38] gatox: I mean, at the lower layer possible [12:40] alecu, yes, i debbuged all the levels... all the values are right, but n_bytes_written in Upload command is never being updated on windows... at least as i see it [12:40] gatox: also: did you have any problem with the n_bytes_read? [12:41] alecu, i don't know...... i'm not using that, i'm using: path, size, n_bytes_written [12:41] gatox: I mean n_bytes_read when doing downloads [12:41] gatox: or are you only showing uploads? [12:43] gatox: btw: I can't understand how would n_bytes_written be different on windows. Here's the lowerest layer, where it's updated: [12:43] gatox: it's on action_queue.py, and it says: [12:43] data = self.fd.read(size) [12:43] self.command.n_bytes_written += len(data) [12:43] gatox: so, the n_bytes_written is updated with the size of the bytes read from the file being uploaded [12:44] gatox: it makes no sense that it could go wrong there. [12:44] alecu, only uploads [12:44] gatox: so, my guess is that this is happening in a higher layer [12:44] gatox: for instance, in the ipc layer. [12:45] alecu, but i was debugging logging the values of that in StatusFrontend..... that is before of going into ipc..... [12:45] gatox: 2 things: how big are the files you are uploading? [12:46] gatox: have you uploaded those files before????????????? [12:46] 20mb...... and 270mb...... and the files get upload to the web [12:46] while i'm testing [12:46] gatox: magic uploads [12:46] gatox: SD makes a checksum of the files, and if it ever was uploaded to u1, it "magically" uploads it. [12:47] gatox: so, if the file was already uploaded, it would show no progress. [12:47] alecu, ................... [12:47] alecu, the checksum doesn't consider if i change the name of the file i understand [12:47] gatox: of course not. [12:48] gatox: it's a checksum of the file contents. [12:48] alecu, ok............ so now i need to go and punish myself [12:48] gatox: here, you can have my hammer. [12:49] alecu, ok..... can i ask you about the other problem that i'm having?? :( [12:49] gatox: sure [12:49] alecu, let me get a traceback.... [12:50] alecu, ON WINDOWS.... when the file finish to be uploaded, i get this: http://paste.ubuntu.com/1148714/ [12:51] i modified handle_AQ_UPLOAD_FINISHED on interaction_interfaces just to test.... replacing: self._path_from_ids(share_id, node_id, 'UploadFinished', info={})....... with. info=None [12:52] and i didn't get that problem anymore...... but it was just a test...... i didn't check what will that mean [12:52] i did that..... to force _path_from_ids to use this part of the code: signal(path) [12:56] anyone know what all the test failures in https://launchpadlibrarian.net/112737146/buildlog_ubuntu-precise-i386.ubuntuone-client_4.1%2Br1290-64~precise1_FAILEDTOBUILD.txt.gz are about? [12:58] dobey: looking... [12:58] there are a LOT of them :( [12:59] and for some reason, this appears to have only happened on the precise i386 build; the amd64 build succeeded; as did quantal/oneiric [12:59] dobey: the dirty reactors could be caused by timing [12:59] dobey: if the build machine was very very slow, for instance [13:00] right [13:00] dobey: the assert isinstance(result, str) OTOH is a real error [13:00] but there are a LOT of AssertionError in expand_user [13:00] right [13:00] dobey: right [13:00] could be a locale issue [13:00] and probably causing the dirty reactors [13:00] cmbined with a broken corner case in our code [13:03] LANG=en_US.UTF-8 LANGUAGE=en_US.UTF-8 LC_ALL=en_US.UTF-8 GCONF_DISABLE_MAKEFILE_SCHEMA_INSTALL=1 /usr/bin/make -C . check [13:03] apparently that is how it's running make check [13:08] dobey: I am running it now on precise and it seems to work ok [13:08] dobey: although it will not end for a while [13:09] right [13:09] is very odd [13:23] brb! [13:31] dobey: officially stumped by that build failure [13:31] :-/ [13:31] dobey: I'm dist-upgrading now to see if that breaks something [13:34] back [13:43] ralsina, dobey: the problem is here: result = path.replace('~', user_home, 1) [13:43] dobey: user_home must be a unicode now [13:43] dobey: and it used to be bytes [13:43] alecu: yes, but why, and why only in that box? [13:44] alecu: that doesn't explain why it's only i386 precise though [13:44] ralsina: perhaps that's the only place where dirspec was updated? [13:45] user_home comes from dirspec.utils [13:45] alecu: hmmm could be order of build I guess [13:45] this is in nightlies [13:45] * alecu keeps typing "dirspect" [13:45] I'm finally back, sorry it took me so long [13:46] also, user_home is still bytes [13:46] user_home = os.path.expanduser(b'~') === m_conley_away is now known as m_conley [13:48] so surely that's not the issue [13:52] dobey: right [13:52] dobey: self.patch(platform, "user_home", self.home_dir) [13:53] in u1-client/contrib/testing/testcase.py [13:53] so, it's not using the user_home from dirspec [13:54] hmmm === slank` is now known as slank === slank is now known as Guest68178 [13:57] also that, yeah [13:58] because test cases have different home dir to avoid breaking user stuff [13:59] yes. anyway, mktemp ensures that it's returning bytes for the tempdir [14:01] so, I'm back to the beggining. No idea :-( [14:01] alecu: unicode_literals in the place where it's being patched? [14:02] doubtful [14:02] ralsina: no, there are no unicode_literals in SD. (only once, but they are not reachable from here) [14:03] oh.. I did not have tip of trunk. [14:05] gatox: did you find the issue with the on_upload_finished ? [14:06] alecu, not yet..... right now i'm finishing with the progress for linux/windows (with the different implementations).... and then i'm going to take care of that [14:13] gatox: it looks like this line is wrong: [14:13] def on_upload_finished(self, upload, **info): [14:13] since it's being called with two positional arguments, it fails [14:14] alecu, right..... but..... shouldn't that be failing for a long time? [14:14] gatox: and perhaps, it did, but we never noticed those logs. [14:14] gatox: since it's not being used to do anything, yet. [14:14] alecu, maybe..... ok, i'll propose a branch for that too (testing it before) [14:15] gatox: in fact, I believe all lines that have "**info" in ipc_client.py are wrong. [14:15] alecu, thx for your help! :D [14:15] alecu, ok... i'll check all of them [14:16] yw [14:16] alecu, in other good news.... the sync menu is working like a charm on ubuntu :D [14:16] gatox: awesome! [14:18] gatox: coooooool [14:18] alecu: no news about the "real" sync menu? [14:19] ralsina hurt gatox feelings..... [14:19] jejeje [14:19] gatox: hahaha [14:20] ralsina: this one is the real, the other is still vapor. [14:20] ralsina: no news yet, I'll ping again. [14:20] gatox: :-) [14:20] alecu, :D [14:23] ralsina, alecu one thing about the sync menu..... as you know is not the proper qt object that we have in the system tray.... so, for linux, i can not detect the show event, etc..... so, the only way to refresh the menu is to have a timer running all the time (only for ubuntu, now windows/darwin) [14:25] s/now/not [14:25] gatox: yes, is suboptimal [14:25] gatox: we can still show the icon as in windows but requires unity config tweaking [14:26] if someone knows any way i can listen to those events, please let me know, i've try a couple of things, but not luck [14:26] gatox: or implement an indicator instead of sni-qt [14:27] ralsina, yes, that's true too..... [14:28] anyway.... now is working and being refreshed every 1sec...... and the data requested is small.... so..... [14:30] brb; have to run an errand. should be back in time for standup [14:33] * mandel just lost his will to life due to xcode 4.4 and unit testing in objective-c [14:37] gatox: yes, that should not be horrible since syncdaemon already does something every second or so [14:37] gatox: or rather .1 seconds [14:48] ralsina: I don't like the idea of polling syncdaemon once a second... [14:48] alecu: it's really suboptimal [14:48] ralsina: I know verterok did some work to get rid of that .1 second polling in the dbus reactor.... [14:48] alecu: hmm.... we could poll much slower [14:48] let's ask him if we did got that merged. [14:49] gatox: we will have to know i we are using sni-qt ornot, because we don't want to poll if we aren't [14:49] alecu: polling who, what, where? :) [14:50] alecu, gatox: when there's the sync menu connected to us via dbusmenu, then polling will not be necessary [14:50] because we will get requests about the data from that other process [14:51] verterok: I remember you telling me about some changes you were devising to get rid of the polling that the dbus-twisted integration did. [14:51] verterok: I don't recall if it was finally landed or if it needed more work. [14:51] alecu: you mean the wakeups/sec? [14:51] verterok: exactly [14:52] alecu: I tried to work on top of a custom glib2reactor Chipaca did, but wasn't able to make it work properly...and finally got left behind [14:52] gatox: did you see this? http://bazaar.launchpad.net/~agateau/sni-qt/trunk/view/head:/README#L32 [14:53] alecu: the problem is in the glib integration...we need pydbus!! ;) [14:53] gatox: it looks like there should be an activated signal when the menu opens [14:53] * gatox reading... [14:53] gatox: also, it handles the "activate" action itself (but we probably don't want it to do it) [14:55] ralsina, mmmmm yes, that might work.... now i need to figure it out when the system tray menu gets hidden, so i can stop the timer [14:55] ralsina, thx [14:55] briancurtin: how's 3.0.2b going? [14:55] gatox: that's trickier :-/ [14:55] ralsina, yap [14:55] gatox: we'd have to look at the sni-qt code I guess [14:56] ralsina, ok.... i'll finish with the tests on windows (where there are some issues yet), and then try to optimize this for linux [14:57] gatox: ok [14:57] gatox: I am reading sni-qt to see if there's something useful [14:57] joshuahoover: binaries submitted on the same RT we were using, haven't gotten them back yet. whenever i get them back i can turn around and build an installer and submit that for signing in 5 minutes [14:57] briancurtin: cool, thanks! [14:57] ralsina, let me know if you find something [14:57] briancurtin: check that the RT has someone assigned [14:57] briancurtin: otherwise it can fall through the cracks [14:59] oh there we go, the binaries are already signed [14:59] i'll submit the installer after standup [14:59] gatox: looks like it doesn't send any signals on closing, but it also looks easy to add [15:00] ralsina, cool..... i'll check that..... [15:00] me [15:00] me [15:01] me [15:01] me [15:02] me [15:03] alecu, thisfred: standup? [15:03] me [15:03] dobey? [15:03] me [15:03] ok, dobey is last, briancurtin go! [15:03] DONE: Q VM setup, get 3.x branches in order, submit binaries [15:03] TODO: submit installer for signing, get 3.x running [15:03] NEXT: ralsina [15:03] DONE: mgmt call, other calls, helped around, reviews, misc TODO: bug triaging, pick a bug, reviews, help BLOCKED: no NEXT gatox [15:03] alecu, thisfred: standup? [15:03] mandel, go [15:03] oh no [15:04] gatox, ein? that was just thing? [15:04] wait.... my keyboard is crazy [15:04] DONE: [15:04] Sync menu upload progress items working on windows and linux, fixing some issues on windows. [15:04] TODO: [15:04] Finish with this branch and propose. Check sni-qt to see if we can add some optimizations for linux. [15:04] BLOCKED: [15:04] No [15:04] mandel, go [15:04] DONE: Worked on unittests for the daemon (test daemon and real one). Turns out that debugging does not longer work on xcode with sentests.. /me hates [15:04] TODO: Finish tests. Move to get this running in the u1-client tests. [15:04] BLOCKED: no [15:04] COMMENTS: I need to leave early. Some smart ass changed the lock of the office and I need to make a copy of the new key before stores close (today they do earlier because is a nat holiday). [15:04] mmcc, please! [15:04] DONE: reviews, talked to lisette about icons & retina, fought buildout [15:04] patches and pyflakes/lint [15:04] TODO: poke people for reviews, start making test builds, more debug fsevents [15:04] BLCK: no [15:04] NEXT: this fred [15:04] er thisfred [15:04] DONE: various small bugfixes TODO: documentation outline with aquarius | write documentation BLOCKED: no NEXT: alecu [15:05] DONE: debugging on #1036270, misc reviews [15:05] TODO: branch for that bug, help with py3k [15:05] BLOCKED: nope [15:05] NEXT: dobey [15:06] ok, dobey is not around yet it seems [15:06] so EOM [15:07] ralsina, alecu, as I said, I need to go early today.. I need to get those keys done or I wont be able to get in the office tom :( [15:07] mandel: it's k [15:07] mandel: good luck [15:08] ralsina, he, I better be able to get them 'por el bien del portero' :P [15:08] I have already expressed my discomfort with changing the locks and not saying it [15:11] mandel have you gone yet? can you quickly let me know how to run those tests in the commsocketserver branch? [15:11] I was just running the 'test' target in xcode [15:11] mmcc, where you doing it via consoloe or via command + u ? [15:12] mandel: cmd-u, essentially. i clicked on the wrench button :) [15:12] mmcc, and which version of xcode.. it can be that the horrible trick of spinning the main loop is not working :( [15:12] mmcc, I'll see if I can reproduce the problem [15:12] * gatox lunch === gatox is now known as gatox_lunch [15:13] mmcc, oh, have you used the lion vm, can you send me an email with the settings to connect to it, I think I touch something and I not longer can [15:13] mandel: do you have the link to the RT? all the info is in there [15:13] I'll email it to you too [15:13] mmcc, please, I did everything but I get a host not found for monorail.buildd [15:14] aha, ok - you need to edit your .ssh/config [15:17] sorry [15:18] DONE: u1db package pokery, discuss icon reorg and redesign, fixes for u1db packaging, got dbgsyms enabled for u1 PPAs, poke about 12.04.1 SRUs [15:18] TODO: rush to get everything done for feature freeze, reorg to drop ubuntuone-installer, SRUs for lucid/natty/oneiric [15:18] BLCK: None. [15:18] dobey: so you could fix the -dbg package problem? [15:19] ralsina: yes, fixed it by not doing -dbg package, and relying on automagic -dbgsym packaging in the archive [15:19] dobey: ok [15:20] ok, I need to go or I'll have problem tom, see you all! [15:21] and it seems to have worked in the PPA [15:21] so all good [15:23] awesome [15:27] gatox, alecu, looking at the chat log, it seems like you guys were hitting a problem with the upload_finished signal when using PB IPC - is that the same problem I saw on darwin, with tracebacks complaining about the number of arguments to the handler? [15:31] mmcc: yes [15:32] alecu: great, well let me know if I can help out with that. I know it wasn't the cause of my other bug, but I'm still interested [15:33] mmcc: afaict the args in the receiving function are wrong. And it was never fixed since it was never truly used. [15:34] alecu: where is the receiving function? I was never sure I had actually traced it correctly through… [15:35] ralsina: installer rebuilt and sent for signing [15:35] briancurtin: awesome [15:36] mmcc: the receiving function is "on_upload_file_progress" in ipc_client.py [15:36] mmcc: and the code is trying to do something like this: http://pastebin.ubuntu.com/1149009/ [15:37] mmcc: the calling code is inside the signal decorator: [15:37] return callback(*args, **kwargs) [15:39] so, in this case args has two items, and kwargs is empty. And there's no implicit naming of that second item into the kwargs. [15:40] I see. I don't think the traceback I was getting was from on_upload_file_progress though [15:40] mmcc: sorry, the line is: [15:40] function(self, *args, **kwargs) [15:41] mmcc: I think that's because this issue may affect any function in ipc_client that expects "**info" as arguments. [15:42] aha, ok [15:42] ok, bank and lunchtime for me === alecu is now known as alecu_lunch [15:43] buen provecho [15:48] yeah, need to eat here too [15:48] bbiab === gatox_lunch is now known as gatox [16:01] alecu_lunch: is https://bitbucket.org/pitrou/t3k/overview what we should be using? looking to get trial going on 3 [16:02] briancurtin: yay [16:04] briancurtin: try running the twisted tests with the included trial, to make sure it's working ok. [16:10] I have to go get lunch. It's an anniversary so it may take a bit long, will stay late [16:19] mmcc, were you having some problems that the upload_finished signal was never emitted on u1-client and for that reason the file never ended to be uploaded to the server?? or i get confuse with something else? [16:19] gatox, I was seeing that signal failing, but it ended up not causing the upload failure, they're unrelated issues [16:20] mmcc, mmmm ok..... so i need to debug what is happening on windows..... [16:21] gatox yeah, I bet when you fix it on windows it'll fix it on darwin too [16:23] mmcc, it seems that the file is being uploaded..... but when is almost complete..... stop processing it..... so the process never ends [16:24] gatox: yes, that's definitely a different issue than what I was seeing. On darwin with python-macfsevents, it sends a create event but never a close event, so no upload ever even starts [16:24] mmcc, yes, this seems to be related to something else..... not fsevents [16:30] hmm [16:55] dobey, when you get a chance can you revisit your needs-info on https://code.launchpad.net/~mikemc/ubuntuone-storage-protocol/fix-1025950-cert-locs/+merge/118603 ? [17:00] mmcc: +1 now from me. it might be good to somehow fix dirspec to look in the .app Resources by default for some things too; but we can poke at that later [17:00] dobey: thanks! [17:16] dobey: tarmac's going to complain about pep8 errors on storage-protocol, isn't it? I'm seeing a couple of pages of them… [17:20] not sure [17:21] it appears likely, yes [17:21] well, it will complain about the ones the version of pep8 in ubuntu quantal complains about [17:22] right [17:24] dobey: what pep8 version is that? on my precise vm I have 0.6.1, and it's really quiet compared to the version 1.3.3 (!) on darwin [17:25] survey (https://launchpad.net/ubuntu/+source/pep8) says… 1.2 [17:33] ralsina, 1-1 whenever you want [17:56] * briancurtin taking a late lunch break, back in a bit === alecu_lunch is now known as alecu [18:13] oh hey great, of course I have two different versions of pep8 on my mac [18:13] nice [18:23] Anyone needs any reviews? [18:28] ralsina: looks like you've already reviewed my pending branches. unless you want to grab this one from alecu: https://code.launchpad.net/~mikemc/ubuntuone-storage-protocol/fix-1025950-cert-locs/+merge/118603 [18:29] so newer pep8 complains a lot about indentation of continuation lines, at least in storage protocol. should I fix a ton of these or set those to ignore? [18:29] you can't ignore errors from p3p8 [18:29] err pep8 [18:30] you can either fix them, or ensure you're using pep8 1.2, rather than 1.3.3 [18:31] pep8 has an --ignore option at least in 1.3 [18:31] ah but it doesn't have comment ignores in files [18:31] also there are a couple other errors I can't figure out how to fix. "indentation not a multiple of four" (it is) [18:31] dobey: right [18:31] and i don't think we want to use --ignore with pep8 [18:32] hmm [18:33] ok I avoided that one by using dict() instead of a dict literal [18:34] but I'm stumped on this one: ubuntuone/storageprotocol/client.py:886:13: E125 continuation line does not distinguish itself from next logical line [18:34] mmcc: I recall reviewing that branch, yes. I'll finish with that. [18:35] alecu, great. if you can also look at https://code.launchpad.net/~mikemc/ubuntuone-windows-installer/improve-buildout/+merge/119195 that'd be great. [18:36] there's a storage-protocol branch hanging out there too, but don't look at it until I get the pep8 errors fixed [18:36] mmcc: regarding the E125, it seems like the second line of the if is indented just like the block below it [18:37] alecu: yes, I understand the message, and I agree it'd be nice to fix but I wasn't sure how to fix it. adding whitespace helps visually but doesn't shut up pep8 [18:37] mmcc: so try adding two or four spaces to that second line of the if [18:39] adding two spaces makes pep8 complain about over-indenting, but four works. thanks alecu! [18:40] mmcc: not that does sounds much logical... but it worked :P [18:40] * alecu is starting to miss "pylint disable=..." already. [18:41] that was pylint's best feature! [18:41] no wait, my fault, four spaces doesn't work either. I'm running pep8 in the console and have been spoiled by flymake so forgot to save changes [18:41] crap. [18:42] mmcc: try creating two boolean local variables [18:42] further, emacs' python mode claims that the indentation that causes the problem is the 'sole indentation' [18:43] mmcc: is_volume_created = message.type == protocol_pb2.Message.VOLUME_CREATED [18:43] right === Chipaca` is now known as Chipaca [18:51] alecu, mmcc, gatox, briancurtin, dobey: I have a horrible headache, I will take the afternoon off and work at night [18:51] ralsina: rest well [18:52] if something urgent comes up, alecu or gatox can sms me [18:52] ralsina, see you... get better [18:52] alecu: we could use flake8 instead, which has a "ignore this" option if pyflakes makes us twist our code too much [18:53] pyflakes shouldn't cause us any problems [18:55] mmcc: why are you even seeing these errors? are they all with 1.3 instead of 1.2? [18:56] dobey: these are with 1.3. [18:56] I don't know what would be different between 1.2 and 1.3. I have 1.1 and 1.3 on my mac and 0.6 on my precise vm [18:57] I should probably get a q vm so I can test with what tarmac will see, or just fix pep8 in the buildout to a particular version we all decide on (1.2?) [18:57] with 1.1, as long as I exclude protobuf generated python files, storage-protocol is clean [18:58] somewhere between 1.1 and 1.2, pep8 got pickier about indentation [18:58] er, 1.1 and 1.3 [18:58] it got pickier in 1.2 and then more so in 1.3 i guess [19:02] goddamn buildout [19:04] ok, so should we stabilize on 1.2 since that's what's in Q? [19:04] the buildout installs 1.1, I'm only fighting 1.3 here because I installed it myself back when buildout wasn't installing it correctly [19:06] mmcc: testing with a Q vm makes a lot of sense, to me. [19:07] alecu: right, but when we run tests on the other platforms, let's use the same version of pep8 and pyflakes as on Q, sound good? [19:07] (which means wait a sec before you approve that improve-buildout branch :) [19:08] mmcc: sounds good. If we make the buildout download and use that same version, even better. [19:09] alecu, I'm on it. [19:20] ok alecu, https://code.launchpad.net/~mikemc/ubuntuone-windows-installer/improve-buildout/+merge/119195 is updated to grab pep8 1.2 [19:20] if you already have a buildout from that trunk, running 'bin/buildout install development' will just update pep8 [19:21] ack [19:24] i wonder if there's a way to automate that more [19:37] alecu, ok..... the menu seems to be working and i think i found where the problem in syncdaemon was (in perspective_broker, in the signals being emitted there) [19:37] i apply a small patch and now it works correctly [19:38] s/apply/applied [19:38] alecu, ralsina: are we going with Python 3.3 for sure or should i be running with the python3 on Q (3.2.3) [19:38] briancurtin: I don't recall 3.3 being an option... [19:38] briancurtin: afaik we should aim for the version in Q [19:39] alecu: i remember it coming up and it stuck in my head because we're only just released 3.3.0b2 as of monday [19:39] dobey, just saw your message about automating - automating what? [19:39] also dobey, now that I've sorted pep8, https://code.launchpad.net/~mikemc/ubuntuone-storage-protocol/fix-run-tests/+merge/118488 is ready for your re-review [19:39] and just the other day someone in here was talking about the various combinations of what will be /usr/bin/python3 or something [19:40] gatox: yes, I suspected that much. IPC on windows was the most likely thing to be broken since no code is using those methods/signals. [19:40] mmcc: the version picking of buildout to match what's in a specific ubuntu release [19:40] alecu, and also where you said..... i need to make changes in both places [19:41] dobey: there's always a way :) [19:41] briancurtin: ideally, python3.1 would work as well, but hopefully 3.2 is enough; is there something in 3.3 we actually need? [19:41] you can have buildout configs read in other config files, some of which could contain auto-generated version specs [19:41] briancurtin: right. And since Q is going thru the freezes, it uses the stable version of python 3. [19:41] but my yak shears are getting dull… [19:42] alecu, i'll be working tomorrow from 6 to 15.... because i need to leave earlier tomorrow.... [19:42] gatox: I hope you don't want me waking up so early! [19:42] dobey: not that i know of, the 3.2.3 that's in Q seems fine to me [19:43] alecu, jejeje nono, just letting you know [19:43] gatox: great then :-) [19:43] alecu, i hope that i'll be able to finish with u1-client changes by tomorrow morning so i can propose a fully working menu [19:43] alecu, but right now is working on linux and windows.... i need to clean up a little bit the code [19:44] mmcc: +1 [19:44] dobey: thanks! [19:44] briancurtin: great; i wonder if it works on the 3.1 that's in lucid too [19:45] briancurtin: let's worry making it work on the python 3 that's in Q, and after freeze we can worry about what's needed to make it work on previous 3's [19:45] sounds good [19:46] right [19:46] although, we'll have a few issues with lucid anyway [19:46] precise also has 3.2.3 [19:48] and oneiric has 3.2.2 [19:48] so we should be fine there [19:54] alecu: do you have that t3k branch installed on your box? i'm having trouble even building it [20:01] briancurtin: I've not installed it, just ran the tests on it from the sources. [20:01] i figured it out, didn't have python3-dev installed [20:01] wasnt finding Python.h [20:02] briancurtin: I ran it with "python3 bin/trial twisted" [20:06] alecu: there are a bunch of failures, but it's operational (still running) [20:06] for some definition of operational [20:06]