/srv/irclogs.ubuntu.com/2010/06/29/#bzr.txt

lifelesspoolie: http://www.network-theory.co.uk/cgi-bin/ghm.cgi?01:51
thumperlifeless: hey, perhaps you can help with something02:23
thumperhttp://bazaar.launchpad.net/~agilence/+junk/tonomundo/changes shows last revision is 19202:23
thumperhttp://bazaar.launchpad.net/~agilence/+junk/tonomundo/.bzr/branch/last-revision shows last revision is 1302:24
thumperany idea what causes this?02:24
pooliethat's odd02:25
thumperI've seen it happen before02:25
thumperbut I can't remember why, or what we did to fix it02:25
pooliei think we had some bugs in the past where the cached last revno could be wrong02:25
poolieit's possible that pushing using a buggy client could get it wrong02:25
poolieis there a bug for this, or is it causing a crash?02:25
thumperbug 59949202:26
ubot5Launchpad bug 599492 in Launchpad Bazaar Integration "Incorrect links to revisions (affected: 1, heat: 6)" [Undecided,New] https://launchpad.net/bugs/59949202:26
poolielifeless, does that ring any bells with you?02:26
pooliespiv^^02:28
nekohayohey there, what's up with nested trees/submodules support? I see https://blueprints.launchpad.net/bzr/+spec/nested-tree-support being dead for 4 years!02:28
poolienekohayo, hi, i would recommend you use scmproj02:29
pooliehttp://doc.bazaar.canonical.com/plugins/en/scmproj-plugin.html02:29
thumperpoolie: is that the official answer now?02:29
nekohayopoolie, actually I'm asking this because I'm dying having to use git to pull pitivi... I'd like to be able to use bzr-git02:30
thumperpoolie: what about submodule support for bzr-git?02:30
pooliethumper, that's not on our plate at the moment02:30
* thumper nods02:30
spivpoolie: no bells other than "this used to happen sometimes in the past"02:30
thumperI've asked on the bug about the client bzr version02:30
spiv'bzr reconcile' ought to fix it.02:30
nekohayois it on some not-so-far roadmap or ETA, or should I not expect this within years?02:31
lifelessthumper: hi, sorry02:31
nekohayo(I can't provide a patch, sadly)02:31
thumpernekohayo: I think decisions were made at a recent sprint to allow nested trees to work as a plugin initially02:31
lifelessyes02:32
thumpernekohayo: to clear the road for some development on it02:32
lifelessthumper: so I think that that indicates a 'wrong' last-revision file in the branch.02:32
thumpernekohayo: but I don't know if anyone is moving with it right now02:32
thumperlifeless: yes...02:32
lifelessthumper: if the user runs 'bzr reconcile' bzr will rewrite it.02:32
thumperlifeless: and push again?02:32
thumperlifeless: or we should reconcile the LP version?02:32
lifelesspush --overwrite (to force it to update)02:33
lifelessor reconcile, and the next push that actually does stuff should fix it automatically.02:33
lifelessyou could reconcile the LP version too02:33
thumpercan you reconcile a remote branch?02:33
lifelessyes but its a tad slow02:34
spivThe user will probably need to reconcile their local copy too.02:36
thumperthanks02:41
thumperbug has been updated02:41
lifelessthumper: nested trees - marius kruger is interested in running with it, but hes out of cycles02:43
pooliespiv, in the 2.2.0 milestone page, how many bugs does it say under "assigned to you"03:16
pooliethe actual field, not adding it up yourself03:16
lifelesshttps://edge.launchpad.net/bzr/+milestone/2.2.0 ? yes fail.03:16
lifelessusing caching is hard.03:17
poolieit seems like in principle you could warn about that03:17
lifelessVary03:17
lifelessIn general we want Vary on everything that is cachable.03:17
lifelessBecause there are so many...variations :P03:18
pooliemm03:19
lifelessthumper: bzrlib/tests/blackbox/test_serve.py03:29
thumperlifeless: ta03:30
lifeless12 tests03:30
lifeless336 lines; balance is ok but its a lot of complexity03:30
parthmpoolie: hi04:01
idnarargh04:13
idnarso I have a branch, which I've committed several revisions to04:13
idnarand now I realise that in one of the earlier revisions, I accidentally removed a file and readded it elsewhere, instead of using bzr mv04:14
idnaris there an easier way to fix the branch up besides creating a new branch and manually replaying the revisions on this one, one at a time?04:15
idnarhmm, I'm going to try making a copy of the branch, uncommitting past the faulty revision, fixing it up, then rebasing the complete branch on top of that one04:22
=== jfroy_ is now known as jfroy
thumperlifeless: it seems that push --overwrite didn't update the last revision: https://bugs.edge.launchpad.net/launchpad-code/+bug/599492/comments/304:28
ubot5Launchpad bug 599492 in Launchpad Bazaar Integration "Incorrect links to revisions (affected: 1, heat: 6)" [Undecided,Incomplete]04:28
idnarargh, now I have a "contents conflict"04:33
* idnar continues hurtling down the rabbit hole04:35
idnarokay, I think that worked04:38
lifelessthumper: thanks05:10
=== FryGuy_ is now known as FryGuy-
=== mlh_ is now known as mlh
lifelessvila: ping07:18
vilahi all !07:33
vilalifeless: pong07:33
pooliehi there vila07:34
vilalifeless: do GlobalConfig and LocationConfig objects sound like good candidates for bzrlib.state ?07:34
pooliehow's it going?07:34
vilapoolie: fine, I encounter funny details while working on the config file locks, like: lock info trying to access the config while locking it and lock trying to create the config dir to access a non-existent config file but I'm almost finished07:36
lifelessvila: hi, was looking for a 'ForceNeeded' error but couldn't see one07:38
lifelessvila: uhm, *if* they are currently getting globally memoised, sure.07:38
lifelessvila: but I wouldn't add anything to it that isn't already globally memoised.07:39
lifelessvila: I think we should have smaller lifetime context objects for such things.07:39
vilalifeless: the context here is that to fix the bug I need to lock write access but also read access which makes accessing the config more costly. On the other hand we actually almost always access the file for every config variable. The file is read/parsed and all (variable/value) tuples are indeed memoised... to be thrown away immediately07:41
lifelessvila: why do you need to lock read access?07:41
lifelessvila: that smells very wrong to me07:42
vilalifeless: since there is a very high suspicion (I couldn't get a corrupted conf file yet), it means two writers have been able to write to the same file at the same time. I see no reason to believe that a reader can't get a partial file while a writer is producing it07:42
lifelessvila: I think it would be a lot better to do the following:07:43
lifeless - ensure that the file is written with our atomic-write facilities07:43
vilait is07:43
lifelesse.g. transport.put_bytes()07:43
vilawell, no, it isn't07:43
lifelessin which case readers cannot get partial files07:43
lifelessand07:44
lifeless - ensure that changes to it do not do so from stale data - changes should be 'lock, read, write, unlock', never 'read, lock, write, unlock'07:44
vilathat's already done, with tests07:44
lifeless - do that by making configs gotten without locking be immutable.07:44
lifelessso that we're not dependent on tests for correctness.07:45
vilathe third point is guaranteed from the second one07:45
lifelessvila: no its not :)07:45
vilawell, at least from the config object point of view, extending this rule to callers....07:45
lifelessvila: 1 word: plugins07:45
lifelessOTOH you may have done 3 already - I haven't seen your code.07:46
lifelessanyhow, if you have those three things, why do you need to lock when reading?07:46
lifelesslocking is /very/ expensive and there is no way we should consider for more than an msec doing that on every execution of bzr07:46
vilaI don't have the first yet07:46
lifelessit would also cause all sorts of bugs on readonly filesystems.07:46
lifelessvila: well, thats easy then :)07:46
vilaconfig dir on read-only FS.... missed that one, not sure it's easy to achieve but no reason to make it harder07:47
poolieurk, yes, we should really not lock on read07:47
vilayet, even if the write is atomic, do we rely on the FS to keep providing the file content as it was when opened even if the path is no longer valid ?07:49
lifelessvila: there are a few cases. I think its ok. Its certainly no worse than today, right ?07:51
vilalifeless: no worse yes, at least we cover the concurrent writers which the bug seems to be about07:52
lifelessright.07:52
vilalifeless: regarding point 3 above (immutable), if you keep your config objects around, even if immutable, they can be come out of date, sharing them is a way to address the problem hence my question about state07:54
vilas/be come/become/07:54
lifelessvila: different problem07:54
lifelessvila: that can happen today.07:54
vilalifeless: yes07:54
lifelessvila: and I don't see any need to change any code beyond config.py for this patch; we want to fix 'concurrent writers', nothing less, nothing more.07:54
lifelessThe reason to focus on the use case here is because we are generally happy with configs I think07:55
vilalifeless: I don't intend to fix more than needed, just discussing the problem while it's fresh07:55
lifelessthere aren't other issues to tackle, unless we make them ;)07:55
vilalifeless: and also checking I understand how you intend bzrlib.state to be used ;)07:56
vilas//to use/07:56
lifelessvila: I want to delete it totally07:56
vilas!s///!!07:56
mgzUnsupported or unknown search engine!07:56
lifelessvila: but its a tool to transition existing global state from all over the library into one place.07:56
lifelessvila: which is better than the same state spread out.07:56
vilaconfig files are global state, outside of the code currently, but still a global state07:57
lifelessvila: unless they are assigned to a global variable, they aren't for the purpose of this discussion.07:57
lifelessimport universe is cheating!07:57
vilathen I'm done :)07:57
lifelesscool07:58
vilausing threads to test concurrent actors is yummy, I even just found away to avoid hangs (at least some) when the test fail...08:06
vilagee, that's typo day ! s/away/a way/08:06
vilafreudian slip for get awat may be...08:06
vilaaway of course, couldn't avoid the typo there, story of my life :)08:07
CaMasonHi guys. I have a commit that introduced some good and bad changes on a file. What would be the best way to 'unpick' this file for a new commit?11:28
jpdsCaMason: bzr shelve - is your friend.11:28
CaMasonyes, I figured that would help11:29
CaMasonso, should I get the copy of the file before the bad commit?11:31
=== nlisgo_ is now known as nlisgo
=== Chex_ is now known as Chex
rubbsCaMason: you may be able to uncommit and then shelve.16:21
rubbsbzr uncommit takes off the last commit and restores to that state IIRC16:22
tsmithbzr: ERROR: No module named _curses16:53
tsmithi'm on CentOS and CANNOT find th epython curses module16:53
jelmervila: hey16:58
jelmervila: your  lp:~vila/bzr/525571-lock-bazaar-conf-files branch has conflicts16:58
maxbtsmith: This should be provided by the Python installation itself, i.e. your Python installation is broken16:58
tsmithwell that's good to know!16:59
tsmithi couldn't find source code for pycurses anywhere16:59
vilajelmer: wow, I was about to tell you I submitted this :)17:05
jelmer:-)17:06
vilajelmer: as far as bzr-svn is concerned, it should just me a matter of requiring 2.2 and changing the base class for subversion.conf17:06
jelmerah, great17:06
jelmervila: I'll give it a try when I get a chance, thanks very much for working on this (and I'm sure you'll also make the losas very happy)17:07
vilajelmer: that's only conflicts in NEWS, ignore them, news_merge is not configured on lp :-P17:07
vilajelmer: I only quickly skimmed config.py in bzr-svn, there seem to some duplication that may need to be removed though17:07
vilas/to some/to be some/17:08
vilajelmer: Overall: my feeling is that we were *very* unlucky to encounter concurrent writers, my proposal use the transport API to make the config write atomic, so this fixes the bug,17:09
vilas/,$/./17:10
vilajam: what was your tweak for https://code.edge.launchpad.net/~vila/bzr/cleanup/+merge/28306 ? osutils lazy imports ? Or was there more ?17:12
jelmervila: there are a lot of imports running on the import slaves I guess17:12
vilajam: nevermind, I was looking at the wrong mp17:13
jamvila: I think just the osutils stuff17:13
vilajam: yes, sorry17:13
JoshBrownI've accidentally added my email to my name in all my commits, so I'm seeing something like: 'Josh Brown josh@host.com <josh@host.com>' - is there any way I can edit the logs to remove the duplicated email address?17:25
maxbI am confused. Why would I be getting a Contents conflict when I cherrypick a revision that adds a file?17:32
maxboh, because I don't understand what -r N.. does17:33
maxbEeek. This scares me.17:50
maxbI have a bzr-svn branch, and did a merge, and got bogus merge results17:51
maxbI ran the repository through fast-export|fast-import, and got saner merge results17:51
maxbbzr-svn must be doing something evil17:51
vilamaxb: next time, try 'bzr st --show-ids'17:56
maxbvila: ok, what am I looking for?17:56
vilamaxb: content conflicts are generally about conflicting *paths* with different file-ids17:57
maxbah, right, you are speaking regarding my first problem17:57
maxbThat turned out to be me misunderstanding the exclusiveness of the N in -r N..17:57
vilaha, sry for the noise then17:58
maxbnp, you are right about the issue - I was merging a modify on a file-id which didn't have its addition merged17:58
maxbthe other issue is unfortunately rather scarier17:58
jamvila:  I realize you are probably gone, but any thoughts on bug #53058418:19
ubot5Launchpad bug 530584 in Ubuntu Distributed Development "File conflict when merge back packaging branch to upstream (affected: 1, heat: 6)" [Medium,Triaged] https://launchpad.net/bugs/53058418:19
jamlike, does your resolve stuff have a 'bzr resolve --mine" for deleted files?18:19
vilajam: almost done but not quite, --mine should work for deleted files as well as long as they were deleted by the merge18:20
vilaAFAIR18:20
jamvila: the point is to leave it deleted18:20
jamsupersede changes in favor of considering the file deleted18:21
jamI don't fully understand what is flowing where yet, so i'm not 100% sure what is OTHER and what is THIS18:21
vilaha, yes, just -rereading the bug report18:21
vilathat reminds me of some thoughts I had about making some --mine/--other "sticky" but I don't have the context anymore :-/18:22
vilasomething like a merge plugin based on a list of (file-id, --mine) or something18:23
vilaor file path... anyway, some text file a user can still modify18:24
jamvila: have you upgraded your VBox yet?18:27
vilajam: no, given the changelog I see no urgency18:28
jamvila: oh, and I was timing 'ping bazaar.lp.net' and found it at 120ms from babune, is that normal?18:28
jamI thought you had 20ms ping time to lp18:29
vilajam: ha, right, I forgot to comment on that, no 20ms is indeed the "normal" lag18:29
vilaat what time did you try ?18:29
jamjust tested again and seem 120ms18:29
jamright now18:29
vilawow, indeed, never saw that !18:29
jam+20% packet loss18:30
jambut maybe because I used ^C18:30
vila6% packet loss here ^C too18:30
jamyeah, without ^C and just doing -c 10 no loss18:30
vilaafter your mail I tested again and I got 20ms as expected18:30
jamI think it is just 1/num succeeded18:30
vilaso it may depend on time of day ?18:30
jamabsolutely possible, but surprising nonetheless18:31
jamthat is a rather large swing18:31
jamand you still get *way* better downloads from http://bazaar.lp.net than I do18:31
jamat this instant, I have 110ms ping time (so lower than you)18:32
jamand it 'bounces' trying to cap 3Mbs18:32
jamalthough it does a better job than it did the other day18:32
jamand it just dropped to 200kB/s for a second or to18:33
jam218:33
vilahmm, the osutils tweak is more tricky than I thought, both 'import tempfile' and 'from tempfile import mkdtemp' are *required*18:33
vilaof course I didn't ran the tests after such a small tweak :)18:35
jamvila: that's why we have pqm. Because I've certainly done things similarly.18:40
vila:-D18:40
jamvila: for your config locking patch18:42
jamshould we be putting 'held' in the directory directly18:42
jamor should we be using a 'lock' subdir18:42
jamand what is the overhead time of locking/unlocking repeatedly? (how long are the locks maintained, etc)18:42
vilathe locks are maintained very briefly we just output the config file textual content18:43
jamvila: sure, but I just did some timing and "lock_write() && unlock()" on Windows takes 10ms18:44
vilaI think people won't mess up with a directory named 'lock', I'm less sure of that with a 'held' file and/or 'info'18:45
jamvila: also, what is the concurrency that we are trying to solve. Does it make sure to hold the lock open from the time the file is read until it is written?18:46
vilajam: No ! Only around the file being written. How could I forgot to explain that :-(18:47
vilacould I have forgotten ?18:47
jamvila: I thought the problem with svn concurrency was that the read got out of sync with the other one18:47
jamwas it actually having 2 writers on the same file?18:47
vilaAIUI yes, hmm, yeah, that was mentioned on IRC I think18:48
vilaand since the fix use an atomic write, the risk is really very low to mess up a reader18:48
vilaIt would require interrupting a read() of an opened file18:49
jamvila: if the problem is not using atomic write, then just doing that would 'fix' it, without the overhead of a lock dir18:49
jamand needing stuff like break-lock18:49
vilano18:50
vilathe sequence is: lock; read ; set new value ; write; unlock18:50
vilano lock means races all over the place18:51
jamvila: you just said "No ! Only around the file being written."18:51
vilaand even harder to diagnose bugs18:51
jamyou then said: (12:50:16 PM) vila: the sequence is: lock; read ; set new value ; write; unlock18:52
vilaeerk18:52
jamso which is it?18:52
viladang it, I changed it after discussing it with lifeless this morning18:52
vilas/read/re-read/ would be more appropriate, but I've changed the method where the @needs_write_lock is used18:53
vilajam: fixed, I have to EOD, I'll try to provide a better explanation tomorrow19:02
vilajam: just pushing for now19:02
vilajam: and to answer your question: *it* is: lock ; re-read the config file ; set the new value ; write the config file ; unlock19:04
jamvila: k19:04
jamhave a good night19:04
vilaand @needs_write_lock must be set on all methods that *calls* _write_config_file19:04
vilaand I have a bug in my test for catching this regression19:05
vilas/for catching/for not catching/, typo's day until the end... :)19:13
=== FryGuy_ is now known as FryGuy-
dipnlikhi, can I ask a bzr-svn question here?19:50
rubbsyes, I probably can't answer, but ask away, someone can help.20:14
rubbsdipnlik: ^^20:14
dipnlikoh, nevermind, now it's working again20:18
rubbsgood to hear20:18
rubbsfor future reference all things bzr can be asked here.20:18
rubbssome know more than others, but all questions get answered eventually20:18
rubbswell, maybe not all. but just about all.20:19
dipnliki had a problem with tags, i created a tag with bzr but bzr-svn didn't auto-create the equivalent svn tag20:19
rubbsah20:19
rubbsjust curious how did you get it working? manually create the svn tag?20:19
rubbsI ask because I'm eventually going to be lead person on migrating from svn to bzr20:19
dipnlikafter i created the first tag manually, the second one worked as expected20:20
dipnlik"manually" == "using svn cp"20:20
dipnlikand here we don't really intend to migrate the svn server, I just use bzr as a client because it's more user friendly and for some cheap local branches20:21
dipnliksad thing is that when I merge local branches to the trunk their log messages don't go the svn repo, so I don't use them as much as I wanted to :|20:22
rubbsright, that's why we eventually will get rid of svn completely20:24
rubbsmy plan is to get them to use bzr as a client first20:24
rubbsget used to the client, then switch out the server,20:24
dipnlikoh, nice plan20:25
dipnlikrubbs: didi you read http://www.szakmeister.net/blog/2010/may/30/bzr-svn-round-2/ (and the first one, linked on the 1st paragraph)?20:28
dipnlikI didn't read it all but it looks interesting20:29
rubbsno I haven't, but i will book mark it thanks!20:32
rubbsbookmark*20:32
exarkunIf I have a bzr repository that I want to make public, but it contains some confidential information that I want to keep private, what should I do?20:55
jamexarkun: you might want to look at 'filter-branch' from bzr-fastimport21:12
jamit should allow you to rewrite the history into something similar, but with some bits removed21:12
exarkunCool, thanks21:12
lifelessmorning21:41
jammorning lifeless21:53
lifelesshiya21:54
lifelessvila:22:11
lifeless+    __doc__ = """\22:11
lifeless+    Break a dead lock on a repository, branch, working directory or config file.22:11
lifelessI'd prefer to see that spelt as22:11
lifeless__doc__ = \22:11
lifeless"""Break...22:11
lifelessbecause having to actually think about what you were escaping hurt my brain22:12
vilalifeless: that's your brain telling you that you missed what is wrong (in both cases the newline is escaped), and what is wrong are the spaces I've added :-P22:16
* vila lower the volume and goes back to bed :)22:16
mgz...don't actually *need* to escape that docstring22:16
mgz*newline22:16
mgzit gets pulled off before anyone tries to print it22:17
lifelessvila: in one, the \ is inside the docstring content22:17
lifelessvila: so you22:17
lifeless're escaping ^M22:17
vilamgz: no, lifeless got it right, there should be no spaces before "Break"22:18
lifelessand then the formatter strips it22:18
mgzthe newline/spaces before 'Break' will always get stripped though, no?22:19
vilaand in the other I escape ^M too and the scanner strips it22:19
vilamgz: no22:19
mgzsome people do print blah.__doc__ rather than help(blah), but they're silly.22:19
* vila off22:20
mgzokay, night.22:20
=== nlisgo_ is now known as nlisgo
mgzI'm still confused as to what doesn't follow pep 257 stripping rules though.22:21
mgzthe whole point of them is so you don't need to do weird backslash or dedent things.22:22
TresEquiswhy would you ever type '__doc__ = ...' instead of inlining the triple-quoted string?  That's just noise22:29
lifelessTresEquis: -O022:30
lifelessTresEquis: there are two sorts of docstrings in bzrlib22:30
lifelessTresEquis: programmer docs and command help22:30
lifelessTresEquis: we don't want stripped binaries to lose the command help.22:30
lifelessmgz: I know, thus my asking vila to change ;)22:31
TresEquisscripts don't need stripping, anyway22:31
lifelessTresEquis: commands are not scripts22:31
TresEquisthey don't even get compiled22:31
lifelessTresEquis: you've added an untrue assumption to the discussion22:32
lifelesspydoc bzrlib.builtins22:32
lifeless'bzr' is the script22:32
lifelessand it has no functions or docstrings or anything22:32
mgzyeah, it's not like git with lots of teeny shell scripts22:32
mgz...is git even like that any more?22:32
TresEquisyou don't need to use -OO ever22:32
lifelessmgz: fsvo of22:32
lifelessTresEquis: the windows packagers folk saved a MB or something doing it22:33
lifelessTresEquis: so we happily acquiesced and helped them do it.22:33
mgzit was me.22:33
mgzeasy change, was going for a slight startup speedup22:33
TresEquisdocstrings aren't the same as comments22:33
lifelessmgz: thats right22:33
TresEquisbut whatever22:34
lifelessTresEquis: I don't know why comments come into this22:34
mgzand I think having special, user-visible docstrings marked differently in the source is a good thing22:34
TresEquissounds like you are using docstrings where you could use comments22:34
lifelessTresEquis: the compiled python files *are* smaller without docstrings for the bulk of the library.22:34
mgzeven if it's not as significant a win as it might have been22:34
lifelessTresEquis: not at all. The bzrlib API has docstrings describing how to use functions in it.22:34
TresEquisif they need to be runtime-introspectable, then they shouldn't be stripped22:35
mgzthey don't.22:35
TresEquisif they don't need to be runtime-introspecctible, then they could just be comments22:35
lifelessTresEquis: that would make pydoc useless22:35
mgzthere are two different cases here22:35
lifelessTresEquis: I really don't know what you're saying here.22:35
mgzbzrlib being good to develop on22:35
mgzand bzr being used as a tool22:36
mgzwe want decent docstrings for the first22:36
TresEquisif they need to show up in pydoc, then they need to be runtime introspectible22:36
lifelessTresEquis: not from a binary .exe22:36
mgzbut no one with a packaged bzr cares about the method descriptions22:36
lifelessTresEquis: there are two separate sets of docstrings22:36
TresEquisnolo contendere, I guess22:37
mgzthere's a thing about "never use -OO" in the python world, but this is one of the few sensible cases22:38
* exarkun disbelieves22:39
mgzwhich bit? :)22:39
exarkundocstrings are great22:40
exarkunPython should try sucking less.  There's no particularly good reason for docstrings to make things bloated or slow.22:40
mgzright, so there shouldn't be a disincentive to use them over comment when you're shipping pyo files only22:40
mgz*comments22:41
mgzit's not uncommon with py2exe I think.22:41
exarkunpy2exe is a different case, isn't it?22:42
mgzit's what bzr uses for the windows package22:42
exarkunIt gives you an opaque blob you can ask Windows to execute.  Even if there are docstrings in there, you can't really find them, right?22:42
mgzright, so, why not remove them, which is what the change is.22:43
exarkunoh, I see22:43
exarkunI missed the one comment above where someone said "windows" ;P22:43
mgzas far as I can see, not an approach that works on nix, as users and developers will be working from the same package22:44
mgzso they'll always be on pyc anyway22:45
lifelessmgz: debian/ubuntu can build pyc's too - its an /etc config option22:45
lifelessmgz: whats tricky is choosing which level of pyo to build22:45
lifelessmgz: s/pyc/pyo/22:45
mgzyeah, and that's not something barry's __pycache__ thing has done anything about I believe22:46
TresEquistrading off the cost of this discussion vs. the bandwidth for the downloads ;)22:46
lifelessTresEquis: :P22:46
mgzthe actual cost is likely to be in confused plugins devs. Need to do a post to list now there's a windows packaged 2.2b3 (there is, right?) saying what changed22:47
mgzlifeless: you didn't push a testtools fix for u""?22:49
lifelessmgz: let me check22:49
lifelesspushing now22:50
lifelesssorry22:50
mgz's okay, just needing it now.22:51
lifelessok, someone else pushed, pulling that in first22:51
mgzhm, and no, no packaged 2.2b3 for windows yet it seems, I may as well draft the message now though22:51
mgzI'm not seeing anything on launchpad testtools trunk after your rev22:52
mgzdid you uncommit locally?22:52
lifelessmgz: actually no, I did push it.22:52
lifelessmgz: I just have the edited version locally22:52
lifelessrev 7522:52
lifelessrevno: 7522:53
lifelesscommitter: Robert Collins <robertc@robertcollins.net>22:53
lifelessbranch nick: trunk22:53
lifelesstimestamp: Thu 2010-06-24 20:03:30 +100022:53
lifelessmessage:22:53
lifeless  Do not generate str objects for StringException's internally.22:53
lifelessits just not py3 happy22:53
mgzyup, I see that.22:53
mgzyou were going to add _()22:53
lifelessI did in fact22:54
lifelessbut I hadn't committed it22:54
lifelessand then forgot and ...22:54
mgzthanks!22:57
=== beuno_ is now known as beuno
pooliehello all23:17
pooliehi jam23:17
jamhi poolie23:47
jamcalling now23:47
pooliehi there jam23:47
poolieok23:48

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!