/srv/irclogs.ubuntu.com/2009/03/21/#bzr.txt

johnfjelmer: you about?00:01
jelmerjohnf: hi00:09
johnfjelmer: don't worry I was wondering why the packaging process was so different for bzr-svn than for bzr and bzrtools and then realised your managing it yourself upstream00:10
jelmerjohnf: it's different choices wrt how the packaging is done00:11
jelmerjohnf: Debian/Ubuntu use the same style for bzr and bzrtools as bzr-svn00:11
jelmerjohnf: LarstIQ was looking at providing updated packages for bzr-svn in the PPA00:12
johnfjelmer: yes he it for hardy. I'm about to do it for everything else. I meant to do it a few days ago when I did bzr and bzr-svn but ran short on time in setting up my end for the different process00:12
jelmerjohnf: I think he wouldn't mind if you uploaded for bzr-svn as well00:13
johnfjelmer: is there a reason for lp:~bzr/bzr-svn/beta-ppa-hardy vs lp:~bzr/bzr-svn/hardy-ppa ?00:15
jelmerjohnf: not really00:16
jelmerwell, one is probably more up to date than the other :-)00:16
johnfok I'll remove one of them00:16
johnfhmm I can't check them out. Something weird with the stacking00:19
jelmerjohnf: what's the error?00:20
johnfwhen checking out  lp:~bzr/bzr-svn/beta-ppa-gutsy00:20
johnfbzr: ERROR: Not a branch: "bzr+ssh://bazaar.launchpad.net/~jelmer/bzr-svn/0.5/"00:20
johnflaunchpad says it's stacked on lp:~jelmer/bzr-svn/0.5-mirrored00:21
jelmerhmm, that's because lp:~jelmer/bzr-svn/0.5/ is now a "remote branch"00:22
jelmerit used to be a "mirror branch", mirrorring the URL that's now mirrorred by  lp:~jelmer/bzr-svn/0.5-mirrored00:22
jelmernot sure if there's much that can be done about that00:22
jelmerabentley: are you still there?00:22
yeonhoohello00:24
johnfheh trying to look at the revisions gices Internal Server error00:25
jelmerjohnf: looks like a launchpad bug then :-)00:26
jelmerjohnf: you might be able to fetch it over http00:26
johnfhmm don't think so. I think it is very unhappy because the parent has disappeared00:28
lifelessjohnf: hi00:28
lifelessjohnf: do the following00:28
lifelessbzr branch --stacked lp:~jelmer/bzr-svn/0.5/ local00:29
lifelesspython00:29
lifelessimport bzrlib.repository00:29
lifelessl = bzrlib.repository.Repository.open('local')00:29
yeonhoohi..! i forgot my ssh password. is possible to register another ssh public key in launchpad?00:29
lifelessr = bzrlib.repository.Repository.open('sftp://bazaar.launchpad.net/~bzr/bzr-svn/beta-ppa-gutsy00:29
yeonhooi don't understand well about it00:29
lifelessl.fetch(r)00:30
lifelessthen run bzr heads and do a pull . -r revid:real-head00:30
lifelessyeonhoo: yes, in the web ui you can do that00:30
yeonhoo3 weeks ago i learn about bzr to upload and fetch... but now im totally new...00:30
yeonhoothe things in my head gone !!00:30
lifelessyeonhoo: https://help.launchpad.net/YourAccount/CreatingAnSSHKeyPair00:32
yeonhoolifeless: thank you very much...! i was looking for this page...00:32
yeonhooi have to up my search skill....00:33
johnflifeless: http://pastie.org/42253600:33
johnfI'm very tempted at this stage to just create branches with debian directories similar to bzr and bzrtools. That way the scripts can just build all of them automatically00:34
jelmerjohnf: if you do that, please also update the instructions in bzr.dev for building bzr-svn for the PPA00:34
lifelessjohnf: oh, my bad00:34
lifelessjohnf: o = Repository.open('lp:~jelmer/bzr-svn/0.5/')00:35
lifelessjohnf: l.add_fallback_repository(o)00:35
lifelessjohnf: then do the fetch again00:35
johnfjelmer: yep already have a patch with other changes so I can do that00:35
jelmerjohnf: and please realise that that means it will no longer be possible to import changes from the Debian/Ubuntu package00:36
jelmer(as they won't have any shared history)00:36
johnfjelmer: yeah I would need to do that manually00:36
lifelessjelmer: if you could make that branch be mirrored again, at least until 1.14 hits lp, that would fix this00:37
jelmerlifeless: hmmok00:40
lifelessjelmer: its the gaol patch spiv put up that will fix this00:40
jelmerok, should be fixed now00:43
jelmerjohnf: please try again00:43
jelmerlifeless: ah00:43
lifelesswhich hasn't landed - but you can see that its a third-party site issue00:45
johnfjelmer: looks good, thanks00:51
yeonhoohummmm01:30
yeonhooi have want to commit whole directory but it's uploading not sub directories01:30
yeonhoois there some flag to include subdirectories?01:31
johnfjelmer: I think I will change the way bzr-svn packages are built. The problem in doing it this way is there will be conflicts in changelog every single time.01:39
johnfAt the moment with bzr and bzrtools I can run 5 scripts and I'm done. Would be easier if bzr-svn worked the same way with just a quick check if any changes were made to debian dir since last time01:39
johnfalternatively I'm happy to leave it to you or someon else to update bzr-svn in the PPA01:40
yeonhoohumm01:48
yeonhoobzr add <--- it's not adding subdirectories01:48
yeonhoohow to include subdirectories?01:49
yeonhoobzr add . has same effect...01:50
yeonhoohm01:53
yeonhooah....01:58
yeonhoohelp01:58
johnfyeonhoo: what's the problem?01:59
yeonhooit is not adding subdirectories automatically01:59
yeonhoobzr add .01:59
johnfhmm it normally does01:59
yeonhooor bzr add01:59
johnfdoes "bzr ignored" indicate that it is ignoring them?01:59
lifelessare they ignored?01:59
yeonhooand i tried on --no-recurse01:59
lifelessor are they subtrees?02:00
yeonhoono..02:00
yeonhoosubtrees?02:00
lifelessor do you have analias that makes add do no-recurse ?02:00
yeonhooit prints nothing with bzr ignored02:00
yeonhoonop..02:00
yeonhooits doing recursively (as normal)02:00
yeonhoobut if it is subtrees i dont know02:01
yeonhoohow can i verify this?02:01
yeonhooi have a directory ..with many subdirectories...02:01
yeonhoois there simple command that does this?02:01
yeonhoowhen "bzr status"02:02
yeonhooit lists a lot of file not-versioned02:02
yeonhooit lists as unknown02:02
NaClTh/part02:02
lifelessif bzr status lists the files as unknown02:02
lifeless'bzr add' should add them02:02
yeonhooi already try this02:03
lifelesscan you capture the output of 'bzr status' and then 'bzr add' and pastebin it for us ?02:03
yeonhoook..02:03
yeonhoowait!02:03
yeonhoohttp://pastebin.com/d29ec14ee02:06
yeonhoohere..02:06
johnfyeonhoo: what happens if you bar add rdfapi-php?02:08
yeonhoosorry i didn't got what you said02:09
yeonhooif i bar?02:09
yeonhooah02:09
yeonhoo?02:09
johnfsorry bzr add rdfapi-php02:09
yeonhoonothing happens02:10
yeonhoojust one more blank line02:10
lifelessok02:10
yeonhoois it bzr internal problem?02:10
lifelessplease run 'bzr --version'02:10
yeonhooi should reinstall ?02:10
lifelesslook for the line that says 'Bazaar log file:'02:10
lifelessrename that file on your disk02:11
yeonhoook02:11
lifelessthen run 'bzr info -v', 'bzr st', 'bzr add'02:11
lifelessthese will put data into th elog02:11
lifelessupload the log somewhere02:11
lifelessand also, what version of bzr do you have02:11
yeonhoook02:13
yeonhoo1.11 version..02:14
=== ampelbein is now known as Ampelbein
yeonhoolifeless : unknown is persisting ..02:18
yeonhoobug!?02:18
yeonhooaccording to info -v : i have 100 unknown files..02:19
yeonhoowell im going to switch to 1.302:20
johnfyeonhoo: did you upload the log file some where we can look at it?02:21
=== d6g is now known as d6g|away
yeonhoohum02:30
yeonhooswitched to 1.3 but not solved problem02:30
yeonhoowhat i think is the project has in each directory .svn folder02:30
yeonhooi think it is affecting the add command.. or not -_-...02:31
lifelessyeonhoo: have you uploaded the log for us yet?02:33
lifelessalso 1.3 is much older than 1.1102:33
yeonhooah sorry i didn't02:34
yeonhooi saw now02:34
yeonhoowell the last log you mean?02:35
yeonhoohttp://pastebin.com/m4638006e02:37
yeonhoowell its the last log file after changing log file's name02:37
lifelessyeonhoo: ok, you are using bzr on a svn project, which is fine02:38
lifelessyeonhoo: but I guess you don't have commit access to the svn repository>02:38
lifeless?02:38
lifelessactually.. .02:38
lifelessUnable to open <bzrlib.transport.local.LocalTransport url=file:///C:/Users/yeonhoo/yeonhoo-serv/rdfapi-php/rap-pubby/templ/> with Subversion: Unable to open an ra_local session to URL02:38
lifelessjelmer: ^ why isn't this showing an error for yeonhoo02:38
lifelessyeonhoo: so whats happening is that:02:39
lifelessC:/Users/yeonhoo/yeonhoo-serv is a bzr project02:39
yeonhoohum..02:39
lifelessyeonhoo: and all the folders under it are in svn02:39
yeonhooyes02:39
lifelessyeonhoo: bzr looks at them, can see they are in svn, and ignores them because they count as nested trees02:40
lifelessyou can either work with them directly, or branch from svn to get your own bzr branch of the svn project, or remove the .svn directories, if you want to just copy the stuff on your disk into bzr02:40
johnflifeless: does bzr have a concept similar to svn-externals?02:41
lifelessjohnf: nested trees02:41
yeonhooyes... then i stated to delete .svn folder in each directory manually02:41
lifelessjohnf: incomplete, being worked on02:41
johnfcool02:41
yeonhoobut there are much..then i gave up02:41
lifelessyeonhoo: as I don't know your overall goal, I can't recommend which course of action is best for you02:42
yeonhoook..!02:42
Peng_Did something change in bzr.dev or http://bazaar-vcs.org/bzr/bzr.dev/ this week? I swear pulling it is slower and uses more bandwidth.02:42
yeonhoothank you very much!!02:42
* Peng_ should be unlazy and do a test.02:42
yeonhooi really apreciate your attention and help!! thank you guys!02:43
lifelessPeng_: nothing that should affect that, no02:43
yeonhoowell now im going to sleep then...bye!02:43
Peng_It took 35-45 seconds to pull bzr.dev on the 16th and 17th, and 75 seconds yesterday and today.02:46
Peng_http://bazaar-vcs.org/bzr/.bzr/repository/ got autopacked on the 20th, but that probably happens a lot.02:47
lifelessPeng_: interesting; if you roll back your bzr.dev?02:57
Peng_Hold on.02:57
Peng_Plus I have bzr-search and the revgraph cache slowing things down a bit.02:58
lifeless:P02:58
lifelessit could be just more commits02:58
Peng_I can't say about the commits, but on the 16th and 17th, pulling changed a lot more files than yesterday and today.02:59
Peng_Yesterday and today, I think there were only 2-3 mainline revisions and maybe 6 merged revisions.02:59
lifelessand you pull with bzr.dev itself yes?03:01
Peng_Yes.03:02
jelmerlifeless: sorry, just got back03:02
Peng_Just took 41 seconds doing it with current bzr.dev in a new repo. Eh.03:02
Peng_(No bzr-search indexes.)03:03
jelmerlifeless: Did yeonhoo's problem get solved? If not, can you summarize it?03:03
Peng_Maybe the layout of my repo is just hitting some bad case.03:03
lifelessjelmer: have a look at the last pastebin03:03
lifelessPeng_: perhaps your local repo autopacked03:04
lifelessPeng_: some large power of 203:04
lifelessjelmer: http://pastebin.com/m4638006e03:04
lifelessjelmer: partly confusion, but he had a bzr tree with svn dirs in subdirectories03:04
jelmerlifeless: what exactly didn't work?03:05
jelmer(looking at the pastebin now)03:05
lifelessjelmer: well, all the subdirs were detecte as nested trees03:05
lifelessand thus ignored by bzr add03:05
Peng_lifeless: Shouldn't autopacking make it faster?03:05
lifelessthats the confusion bit03:05
lifelessbut the lack of errors is what I was noting, his RA connections were all failing, but nothing was said03:06
lifelessPeng_: oh is it still slow?03:06
jelmerlifeless: it's correct the RA connections are failing, since these were working trees not repositories03:06
lifelessjelmer: ah03:06
lifelessjelmer: do we need to log it in that case?03:07
Peng_lifeless: This was on a fresh, fully packed repo.03:07
lifeless[it confused me]03:07
Peng_It took 43 seconds with bzr.dev -r date:2009-03-15. Maybe I'm just crazy.03:07
lifelessPeng_: I'm confused by this :P03:08
jelmerlifeless: Yeah, we probably shouldn't03:08
lifelessjelmer: knowing its a svn tree is useful, seeing what looks like an error but is expected isn't :)03:09
Peng_lifeless: Using the latest bzr.dev of the time, on the 16th and 17th, it took 35-45 seconds to pull the latest revisions of bzr.dev. Yesterday and today, it's taken 75. On a test repo missing the latest 2-3 revisions, it takes 40-45 seconds with both the latest bzr.dev and a week-old version, but that's without bzr-search indexes or a working tree, which could potentially take close to 30 seconds.03:12
Peng_Oh, plus that it's better-packed.03:12
lifelessPeng_: what happens if you use the bzr of the 15th to pull those 2-3 revs03:20
Peng_lifeless: Err, you're right. This is confusing. I did do that: it was about the same pulling in the test repo.03:21
Peng_I can't exactly test in my main repo since it already has the latest bzr.dev.03:22
lifelessso, if bzr.dev and older-.dev are the same in the new repo03:23
lifelessit suggests either the network changed, server changed, or your older repo changed03:23
lifelesshow many packs does your main repo have03:23
lifelessthere was that new theme put up03:24
lifelesskfogel: ping03:24
Peng_lifeless: 14 at the moment.03:24
lifelessI suppose its possible some rewrite rule got botchified03:24
kfogeloh03:24
kfogellifeless: hey, just responding to your mail03:24
kfogelI wrote "takes" when I should have written "already has" in the opening of my mail, which probably led you to think that I had much less understanding of the bzr commit process than I do :-).03:24
lifelesskfogel: cool03:24
lifelesskfogel: :)03:25
Peng_Hmm, I pull brisbane-core in the same repo, and it hasn't gotten slow.03:25
lifelessPeng_: bbc is on lp03:25
lifelessso03:25
Peng_lifeless: Yeah, I know. But if something was wrong on my end, it should be affected (effected?).03:25
lifelessindeed03:25
kfogellifeless: I'm not sold on my proposal -- fixing the root cause would be much better.  But the bug's been open for two years with this user-visible manifestation :-).  Nothing in the commit process conflicts with grabbing a commit message earlier and calculating a checksum -- they can be done before the commit is even *started* if we want.03:26
=== Ampelbein is now known as ampelbein
lifelesskfogel: checksum of what03:26
kfogellifeless: the overall change.  a change fingerprint.03:26
lifelesskfogel: (and yes, it does - we show the diff in the commit message for people)03:26
lifelesskfogel: how would we get the overall change without calculating the result?03:27
Peng_Is it possible to check which revisions are in a specific .pack? "dump-btree" on the index?03:27
lifelessPeng_: yes exactly, the .rix03:27
kfogellifeless: ?  not sure I understand that question.  We can calculate anything we want; it's a read operation... ?03:27
kfogellifeless: the current arrangement and sequence of code is not written in stone, I guess is what I mean.  There definitely _is_ a performance implication here, of doing work twice, I see that.03:28
lifelesskfogel: we're going to have to be much more specific, assume _no_ common ground or something03:28
kfogelhmmmm03:28
kfogellifeless: so, as part of the commit process, bzr currently calculates an overall change fingerprint, right?03:29
Peng_lifeless: I swear something odd is happening in my repo. Should a 15-line diff lead to a 2.5 MB .pack?03:30
lifelesskfogel: no03:30
lifelessit doesn't03:30
lifelessPeng_: fulltexts can do that03:30
kfogellifeless: but ... here is the level of detail I'm not sure you want to go into.  There is such a thing as "calculating a fingerprint for a VC change": there are known algorithms, they always produce the same fingerprint for the "same" change, etc.  right?03:31
lifelesskfogel: no, we don't do that03:31
lifelesswe fingerprint whole trees, not deltas, today.03:32
kfogellifeless: yes, I get that :-).  I'm just asking a general algorithmic question.  HOWEVER, I think it is really academic03:32
kfogelthe perf implications of my proposal are frightening even to me, I agree it's a no go on those grounds alone.03:32
lifelesssure, one could define an algorithm to fingerprint a delta03:32
kfogellifeless: that's all I was ever talking about in my proposal.03:32
kfogelI think I probably wrote it up in too few words, causing needless head-scratching.  Oh well.03:33
lifelessor perhaps too many :P03:33
kfogelWell, only in the sense that the proposal itself might be too many :-).03:33
lifelessI would have said something like ... 'can we just temporarily release the OS-lock on dirstate while we wait for the commit message'03:33
kfogelBut ... so what do we do?  blocking read operations is a serious lose.03:33
kfogellifeless: but then the change could change under you03:34
kfogellifeless: then there *is* a race condition03:34
Peng_lifeless: Oh, good point. It was probably a fulltext. Or 10?03:34
kfogelbecause you couldn't necessarily detect it, right?03:34
lifelesskfogel: uhm, you have skupe?03:34
lifelessI want more bandwidth, to get you across these internals03:34
kfogellifeless: heh.  I have two boxen; one at an office, where I *just* got skype working today, and one at home, where I haven't yet debugged my microphone sound problems.03:35
kfogelI'm at home right now.03:35
lifelessI did sketch it in my mail, but it seems lacking03:35
lifelessok03:35
kfogellifeless: where are you?03:35
lifelessso..03:35
lifeless.au03:35
kfogelhmmmm03:35
kfogelwhat phone #?03:35
kfogel(priv msg is fine)03:35
=== abentley1 is now known as abentley
Peng_Moving a working tree to another partition will change all the inodes and make "bzr st" need to rescan everything, right?05:00
lifelessyes05:08
Peng_\o/05:08
lifelessthats pretty fast though05:15
lifelessits just read the file once05:15
lifelessif you have just copied it, its in cache etc05:16
Peng_Yeah, I know.05:18
Peng_lifeless: FWIW, I just pulled the latest 2 revisions of bzr.dev (with bzr.dev) in 32 seconds, on my original repo and branch. This was after moving it from a small, nearly-full ext3 partition to a much larger ReiserFS partition, though. :\07:24
lifelessPeng_: do you think that has anything to do with it?07:25
Peng_lifeless: Probably. At the very least, it was rather unscientific of me to do.07:25
lifeless:P07:25
Peng_s/Probably/I don't know/07:25
Peng_That ext3 fs is probably fragmented badly.07:26
lifelessfsck can tell you07:26
Peng_Sorry, moving all of that data was terrifying enough. I'm afraid of doing something wrong with fsck and destroying my fs. :P07:27
lifelessoh, you don't need to umount it07:27
lifelessfsck -n07:27
Peng_But accidentally fscking a mounted fs could ruin it.07:27
lifelessnot with -n07:27
Peng_What if I forget -n?07:28
lifelessPeng_: don't forget07:28
Peng_Err, what the hell? bzr.dev's push location changed.07:28
Peng_Oh, I bet I need to update locations.conf.07:28
* Peng_ stops panicking.07:29
lifelessvila: ping07:52
lifelessjml: yo07:58
vilalifeless: pong09:06
lifelessvila: do you have a copy of tests.parallel with both our stuff in it?09:07
vilalifeless: no, I have a loom with a lifeless thread where I import your modifications09:08
vilaIt's at lp:~vila/bzr/parallel-selftest but it doesn't contain your latest ec2 changes09:08
lifelessk09:08
lifelessI would like the patches you promised me :P09:09
vilaand at that location it should be a simple branch09:09
lifelessI'm shuffling stuff around lots still :)09:09
vilaoops, I didn't push09:09
viladone09:09
vilarevno 4175 should contain the stuff I use here09:10
lifelessvila: could you arrange for some patches?09:10
lifelessvila: there are three projects involvled..09:10
vilaAFAICT I have changes against bzr.dev only so far, let me see09:12
lifelessvila: I know you do, I'm noting that this is what we need to split out09:12
lifelesswhich is why I want to deal in patches rather than in branches09:13
vilaAgree, I'd want to be able to use it on any bzr branch09:13
vilabut using branches instead of patches is easier for me when applying :)09:13
vilalifeless: bundle sent, check your mail09:14
vilait contains some trivial fixes for bzr.dev irrelevant here so just ignore the noise :)09:15
* vila goes back to its late breakfast 09:16
lifeless:P09:20
=== abentley1 is now known as abentley
=== abentley1 is now known as abentley
=== d6g|away is now known as d6g
lifelessok, ec2 polished a tad more..., 3m36 to do a test run12:37
=== abentley1 is now known as abentley
=== abentley1 is now known as abentley
LarstiQmoin15:15
LarstiQjohnf: I suppose at this time you are not awake?15:16
LarstiQjohnf: anyway, I had troubles pushing the hard-ppa bzr-svn branch up to launchpad, intrepid-ppa is already pushed, packages for intrepid and hardy are in bzr-ppa and bzr-beta-ppa15:31
LarstiQjohnf: I'll get to the rest today15:31
LarstiQjohnf: as to the future, I'm open for suggestions.15:31
CMooneyHi16:27
=== d6g is now known as d6g|away
CMooneyCan bzr work with avahi?16:32
jelmerCMooney: yes, there is a plugin16:33
CMooneybrilliant!16:33
CMooneyjelmer, How reliable is it?16:36
CMooneyAlso if I am using bzr on one computer on my network, how to do pull across a current version to another machine on that network (hence me asking about avahi)? Seems the guide assumes you connect to a server via http16:37
jelmerCMooney: which guide?16:38
CMooneyAh right, just read the official guide rather than the "Bzr in five minutes" and I think it has the information I need16:39
CMooneygot it. I can use stfp because I have ssh installed16:41
jelmerthe avahi plugin mainly allows you to announce and browse branches on the local network16:45
=== abentley1 is now known as abentley
CMooneyI am having a bit of trouble again.16:52
CMooneyI am able to checkout a version from one machine. I edit it on my laptop, commit the change, then try and merge. The merge doesnt work and I get "Nothing to do." from bzr16:52
LarstiQCMooney: merge what into what? Bzr thinks all the revisions of the <merge-from> branch are already in the <merge-into> branch.16:53
CMooneyLarstiQ, I thought you had to merge your changes into the main repo. eg merge the changes from my laptop to my main machine.16:54
CMooneyDo I need something else?16:54
LarstiQCMooney: if you have a checkout, and not a standalone branch, then when you commit in the checkout both locations will have the same set of revisions.16:55
LarstiQCMooney: if you don't have a checkout, and your branches haven't diverged (true so far), push/pull make more sense than merge.16:56
CMooneySo I have an edited (updated) document on my laptop, that I now want to send to my desktop. How would I do that?16:57
CMooneyLarstiQ, Ooops. Reading the documentation, I realise the word "Checkout" had a specific meaning, which I did not intend to use. I meant to say I have a branch on my laptop. (I think that's the correct terminology)16:58
LarstiQCMooney: how did you get the branch on your laptop?16:59
CMooneybzr branch sftp://.../Writeup/16:59
LarstiQCMooney: cool17:00
LarstiQCMooney: so, after you committed, do `bzr push :parent`17:00
LarstiQCMooney: after that first push, bzr will remember your push location. Also see `bzr info`17:01
CMooneySo if I open that file on the main computer (parent) now, it should be the version that I made on the laptop?17:01
CMooneyLarstiQ, So if I open that file on the main computer (parent) now, it should be the version that I made on the laptop?17:05
LarstiQCMooney: push doens't update the working tree, so you'd need to `bzr up` on the main computer17:09
LarstiQCMooney: but all the data in .bzr/ is as it should be.17:09
CMooneyso push put the updated file into .bzr and then "bzr up" accept the changes.17:10
NfNitLooppush will update the working tree for a filesystem-local push, though, right?17:11
NfNitLoopcmoomey: yep17:11
CMooneyThanks for your help, LarstiQ17:16
LarstiQNfNitLoop: true17:19
meoblast001hi18:32
meoblast001i upgraded to jaunty and now my passphrase won't work18:33
meoblast001wait18:34
meoblast001nvm i think i know the problem18:34
=== asabil_ is now known as asabil
=== abentley1 is now known as abentley
ronnylifeless: what are the plans for porting bzr to python3?19:51
jelmermoin ronny19:51
SamBronny: why would there be plans like that?19:52
ronnytrying to get a psf umbrella for a gsoc project, they have push python3 politics19:53
SamBsilly peoples19:53
LarstiQSamB: for the unicode/bytestring seperation19:54
LarstiQevening ronny19:54
ronnyyo LarstiQ19:54
LarstiQronny: I'm not aware of any plans, dependencies like pycrypto and paramiko need to be tackled too19:56
ronnyisnt paramiko from bzr people, too?19:57
LarstiQronny: no, the paramiko author has contributed to bzr a bit, and vice versa, but it's a seperate project20:02
ronnyah, i see20:04
SamBwouldn't you also need to get plugin writers to switch at the same time?20:04
LarstiQSamB: we're not going to leave 2.x for a long while20:05
jelmerSamB: I think (hope) the idea would be to support both Python2 and Python3 for a while20:05
LarstiQSamB: you're right you'd want plugins to work with 3, but luckily it doesn't have to happen all at once20:06
SamBwhat? both 2 and 3?20:06
SamBhow?20:06
Peng_Bazaar is terribly complicated. Concurrent 2 and 3 support would be difficult.20:06
jelmerPeng_: Separate code bases perhaps20:06
SamBjelmer: very funny!20:06
jelmerSamB: ?20:07
jelmerI don't think that's *that* unreasonable20:07
LarstiQSamB: the recommended py3k support route is having it be generated from the 2.x codebase, no hand editing20:07
SamBoh20:07
LarstiQSamB: up to the point you drop 2.x support20:07
LarstiQPeng_: that could be true20:08
Peng_LarstiQ: Yeah, but 2to3 isn't perfect. And you have to ditch 2.5 and 2.6 support.20:08
Peng_Don't you?20:08
LarstiQPeng_: let's try it! :)20:08
LarstiQPeng_: no20:08
jelmerPeng_: s/2.5 and 2.6/2.4 and 2.5/ ?20:08
LarstiQPeng_: 2.5 possibly20:08
LarstiQPeng_: depending on how you write it20:09
Peng_jelmer: Err, yes.20:09
LarstiQPeng_: 2.6 is explicitly supported20:09
* Peng_ has been up a while now20:09
Peng_Yeah, typo. I meant 2.4 and 2.5.20:09
* SamB doesn't *have* anything newer than 2.520:09
davidstraussabentley: ping20:10
LarstiQSamB: nor do I on Lenny20:11
SamBdoes bzr have excellent unit tests with close to full coverage?20:13
SamBdoesn't the approach outlined in PEP 3000 wreak havoc on the file history in version control?20:15
LarstiQSamB: I don't know where coverage is at now, `bzr selftest` runs the suite.20:19
LarstiQSamB: which parts wreaks havoc?20:20
LarstiQSamB: if possible, the v3 code would be generated in the build step prior to rolling a tarball.20:21
LarstiQSamB: if you replace your current code with it, then it will screw with your annotations in the same sense as any other large mechanical change.20:22
LarstiQSamB: is that what you meant?20:22
SamBwell, yeah, I guess20:23
Peng_Making it ready for 2to3 would probably mess up annotate enough.20:26
LarstiQPeng_: we'll have to try and see20:27
=== d6g|away is now known as d6g
=== d6g is now known as d6g|away
lifelessronny: our main criteria is keeping python2.4 working, at this point21:38
lifelessvila: btw21:40
lifelessvila: using runner.stream was deliberate :P21:40
ronnylifeless: ah, i see21:42
lifelessronny: if we can get a python3 version of bzr, with all our external dependencies (medusa, paramiko, subvertpy etc etc etc etc), thats cool, but it doesn't help people who want to install bzr on current released distro's21:45
lifelessWe're *starting* to talk about moving the minimum version up to 2.5.21:45
mathrickhiya21:51
mathrickthe PPA package for 1.13 seems to be broken21:51
mathrickit installs bzrlib versioned for 1.1121:51
mathrickwhich occasionally (but strangely, not always) explodes in my face21:51
mathrickmathrick@hatsumi:~/Dev/Lisp/kabinett$ bzr add bugs.org21:52
mathrickbzr: ERROR: The API for "<module 'bzrlib' from '/usr/lib/python2.5/site-packages/bzrlib/__init__.pyc'>" is not compatible with "(1, 11, 0)". It supports versions "(1, 13, 0)" to "(1, 13, 0)".21:52
mathrickI made sure to purge and re-install the package, and the error persists21:52
jelmermathrick: looks like you have a plugin installed that is outdated21:52
mathrickoh, hmm21:52
jelmermathrick: perhaps in ~/.bazaar/plugins?21:52
mathrickpossible21:52
LarstiQmathrick: which distro ppa is this btw?21:53
mathrickbut the error isn't particularly lucid if that's the case21:53
mathrickLarstiQ: ubuntu intrepid21:53
jelmermathrick: yeah, the error isn't very clear21:53
LarstiQmathrick: `bzr plugins` output?21:54
mathrickhttp://pastebin.com/m49cb740121:55
* mathrick starts with bzr-svn 0.421:55
mathrickyup21:56
LarstiQmathrick: right, the ppa should provide you with bzr-svn 0.5.321:56
mathrickyeah, I have it21:56
mathrickI just didn't disable the locally installed 0.421:56
LarstiQright21:56
mathrickit works now21:56
mathrickthanks21:56
LarstiQmathrick: np21:57
cody-somervilleBjornT, jml: The particular file is The particular file is .bzr/branch-format21:59
jmlcody-somerville: Branch.open requires read permissions to, roughly speaking, everything inside .bzr.22:10
cody-somervillejml, weird. I did bzr -R +r .bzr22:12
cody-somervilledisclaimer: trying to do it from within a django app22:12
jmlcody-somerville: opening a bzrdir from a django app?22:13
lifelesshi jml22:13
cody-somervilleYea22:13
jmloh right.22:13
jmllifeless: hi22:13
cody-somervilleI'm trying to get it to print the revno of the branch the codebase runs out of22:13
lifelessjml: 3m36 on ec2 with a hot intance22:14
jmllifeless: nice.22:15
lifelesswell, 2 hot instances but yeah22:15
fullermdFor what?22:15
lifelessBZR_PARALLEL=ec2=2 ./bzr selftest --no-plugins22:15
fullermdDear $DEITY.22:15
lifelessfullermd: runs on ec2 reports on my laptop22:16
lifelessbrought to you by the letters subunit, testtools and bzr22:16
fullermdMan, if it took that long, I might run it once in a while...22:17
lifelessfullermd: indeed :P22:17
LarstiQsooo, faster pqm?22:18
lifelessLarstiQ: once its all landed, I'll start asking about budget to do that22:18
lifelesspqm will probably want to keep some warmed up instances, or use the ec2-alike facility internally22:18
lifelessa cheap approach though would be to get a second core for pqm22:19
* fullermd guesses he needs to upgrade hardware...22:20
LarstiQlifeless: how much does the ec2 run cost then?22:20
lifelessI've accrued 23USD developing this22:21
lifeless$0.80 per High-CPU Extra Large Instance (c1.xlarge) instance-hour (or partial hour)   27 Hrs22:21
LarstiQok22:22
lifelessthats a 8-way machine22:22
lifelessthe charge is not cpu time, its commissioned-time22:23
lifelessso if we brought up 5 of those, its 2 dollars an hour22:23
lifelessthere are lots of hours in a month ;P22:23
lifelesshttp://aws.amazon.com/ec2/instance-types/22:24
lifelesswe get <roughly> linear per core22:24
lifelesssome tests are more expensive, and this isn't trying to make all the cores stop simultaneously22:24
lifelessso in the highcpu flavours, its 10c/hour/cpu22:25
lifelessand in standard ones its 10 or 20c/hour/cpu which is why I went highcpu22:26
LarstiQight22:27
lifelessanyhoo, back in a bit22:27
=== thunderstruck is now known as gnomefreak

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