TuxIceSo operating directly allows you to use bzr:// instead of bzr+ssh:// ?00:00
thumperTuxIce: yes, but the process runs as a specified user on the server00:01
TuxIceI see.00:01
thumperTuxIce: whereas with ssh it can run as the requester00:01
TuxIceNow, launchpad users obviously don't all have they're own physical account on the server, and by physical account I mean an /etc/passwd entry; How do you get around that?00:02
TuxIceOperating your ftp daemon to pull from a database?00:02
dashTuxIce: sftp server written in python. :)00:02
TuxIceI see.00:03
TresEquisSSH keys are stored in a single account, w/ info about the "apparent" account passed to the bzr command00:03
TuxIceOh man, so confusing.00:03
TuxIceI see.00:03
TresEquisor at least that is how I would set it up, having done that for CVS and SVN00:03
NET||abuseawww heck,, what'd i do wrong here?   This transport does not update the working tree of: bzr+ssh://me@hostname/path/to/push/repo00:03
thumperTresEquis: ssh keys stored in the database connected to the users00:04
thumperNET||abuse: push doesn't update the remote working tree00:04
thumperNET||abuse: there is a plugin to do that somewhere00:04
TuxIceSo really, every time you add a key in launchpad, its being added to one account on the lp server. When you branch/push, your essentially "proxying" (for lack of a better term, through this one account?00:04
NET||abusethumper, oh, ok, maybe i'm using the wrong repo type ont eh remote side then00:04
TuxIceAnd this one account allows sftp access, but not physical /bin/bash ssh access, correct?00:05
thumperTuxIce: yes00:05
TresEquisTuxIce: that's probably a reasonable metaphor00:05
NET||abusethumper, i was on remote, i did mkdir bzrrepo; cd bzrrepo; bzr init;      then on my local i just pushed to that location.. it uploaded the first time.. will it not upload anymore?00:05
TuxIceI see00:05
TresEquisTuxIce: sort of like this: http://www.snailbook.com/faq/restricted-scp.auto.html00:06
NET||abuseor do i have to create a different type of repo on the remote server? and pull from that server?00:06
thumperNET||abuse: I'm surprised that it did it the first time00:06
NET||abusethumper, well it did ;P00:06
thumperNET||abuse: you can either pull from the server00:06
AdamDV-iPodI see00:06
thumperNET||abuse: or add a plugin on the server00:06
NET||abusepull from server? but i want to push up to the server.00:06
* thumper tries to remember the name00:07
AdamDV-iPodAnd then, when you connect to the lp servers using sftp, your ssh server essentially "rewrites" the URL00:08
thumperNET||abuse: http://doc.bazaar.canonical.com/plugins/en/push-and-update-plugin.html00:08
NET||abusei'd be happy to recreate a new repo, push the current server branch to there, then continue updateing from m ylocal copy to the new server repo, then wipe out the current server repo and branch at the same location as the just deleted old repo from the new server repo00:08
thumperAdamDV-iPod: yes00:08
AdamDV-iPodMakes sense now. So, would it be possible to get the code that does all this?00:09
NET||abusethumper, i did this before twice, and i didn't require any plugin, where i had a location i pushed to, that location was also active as a working tree, i would pull updates from the bzr pushes to that working tree on the server and those would be the live site files for my websites.00:09
thumperNET||abuse: pull updates the working tree, push doesn't00:09
AdamDV-iPodI'm assuming the user ssh key proxying is one piece of code, the rewriing and ssh server another?00:11
NET||abusethumper, yeh i know, but the same location on the server, seemed to be both  .. em .. would you call it a stub repository ? and the working tree, i would push from my laptop to the stub, in the same directory as the stub(.bzr directory) i would also update, this would populate the /path/to/dir/ with any pushed updates00:11
AdamDV-iPodI see. And this code is unattainable because non of the lp debs have seperated it into it's own project?00:12
AdamDV-iPodErr, debs00:12
thumperAdamDV-iPod: no, all this code is in the launchpad tree00:12
AdamDV-iPodIt is?00:12
NET||abuseso on the server i had   /path/to/repo/.bzr    from the laptop, i would push to me@host/path/to/repo/      then on the server, i would cd /path/to/repo/   bzr branch;   bzr update; bzr update;00:12
AdamDV-iPodIncluding the ssh server?00:12
thumperAdamDV-iPod: yep, all there00:13
AdamDV-iPodHmmm, thAt's good then00:13
NET||abusethumper, that said, i dont' care if i have to create a  new bzr repo taht is only for use as a repository, and not as a workign tree, and i bind the working tree that's now on the server to that location on the same host, and push to that location from my local laptop too.00:13
AdamDV-iPodNow, time to try and see if I can get a working copy of launchpad setup.00:13
NET||abusethumper, how do i set that up/00:14
AdamDV-iPodThank you very much thumper :)00:14
thumperAdamDV-iPod: lib/lp/codehosting00:15
AdamDV-iPodThat's the directory in the src where the code I'm referencing is? Or ..?00:16
thumperAdamDV-iPod: yep00:17
AdamDV-iPodand that's in the launchpad source that was open sourced a few years ago?00:17
thumperuh ha00:17
AdamDV-iPodThanks :D00:17
AdamDV-iPodthumper: Launchpad builds on lucid, right?00:29
thumperAdamDV-iPod: it does, and we talk in #launchpad-dev00:30
=== wgrant_ is now known as wgrant
=== AdamDV is now known as Guest44380
=== Guest44380 is now known as AdamDV2
lifelessjames_w: still around? you register your commands in builddeb a bit strangely - bzr can't tell they are in a plugin as a result.01:51
lifelessjames_w: scratch that, grep broke me01:51
lifelesshi davidstrauss01:53
davidstrausslifeless: hi01:53
davidstrausslifeless: what's up?01:55
lifelessnothing particularly ;) just saying hai01:56
lifelesssorry about the lag a couple of days back too01:56
davidstrausslifeless: it seems to be fixed now01:56
lifelessshould be01:57
davidstrausslifeless: you guys should look into the UEC for processing those heavy loads ;-)01:57
lifelessAIUI its database contention concerns that have us serialise everything01:57
davidstrausslifeless: I'd love to help you scale there.01:57
davidstrausslifeless: I do tons of work in the NoSQL space01:57
lifelessdavidstrauss: cool01:58
lifelessdavidstrauss: thumper: ^ is the team lead for launchpad-code. We've been having some conversations around e.g. cassandra internally01:58
davidstrausslifeless: launchpad should be easy to for things like branches01:59
lifelessRight now we're not very good at doing controlled experiments though, so there is significant mgmt and technical concern that when we start doing nosql we choose The Right Tool01:59
davidstrausseasy to shard, i meant01:59
lifelessfairly, I'd say02:02
AdamDV2So, to setup a bzr branch for checking out by fellow developers on my server, I would navigate to a directory do bzr init, add * and then commit, correct?02:29
lifelessAdamDV2: just 'bzr init; bzr add; bzr commit -m "import"'02:29
lifelessAdamDV2: you don't need to give paths to most bzr commands02:29
AdamDV2I see, thanks02:30
lifelesslike 'ls', bzr knows that 'cwd is what you want'02:30
AdamDV2Can bzr handle ftp:// ?02:44
lifelessif you have a better protocol you should use it02:44
AdamDV2I know, such as sftp or bzr or bzr+ssh02:45
lifelessftp servers are very limited and thus slow for hosting bzr branches on02:45
AdamDV2How does the bzr:// protocol work?02:45
AdamDV2Does it just work out of the box?02:45
lifelessif you want to upload a website which you manage in bzr, ftp is fine - but use 'bzr upload' in the bzr-upload plugin instead.02:45
AdamDV2I'm only using ftp to test.02:45
AdamDV2I'm planning on using bzr://02:45
lifelessAdamDV2: bzr+ssh just works out of the box - install bzr on your server and you're good to go if you can ssh in.02:46
AdamDV2HOw about just bzr:// ?02:46
lifelessbzr:// is only really suitable for read-only access02:46
AdamDV2I see.02:46
lifelessit has no authentication or acl support02:46
lifelessbzr+ssh or bzr+http can do authentication02:46
AdamDV2Is there a plugin which handles bzr+mysql?02:46
lifelessI'm not sure what that would do; I'm not aware of anything glueing the two together. mtaylor: may know.02:47
AdamDV2Use mysql for user authentication?02:47
AdamDV2mtaylor: Awake?02:47
lifelesslibpam-mysql might do what you want02:48
AdamDV2I'll have to fiddle with that02:48
lifelessor any of the apache auth stuff for mysql02:49
* AdamDV2 will look into02:51
AdamDV2I created a branch server side.03:00
AdamDV2On my client I checked it out over sftp, changed it a bit, ran add, diff, then commit.03:00
AdamDV2Then ran ls on the server, no difference. Whats wrong?03:00
dashAdamDV2: does 'bzr log -l1' show your new revision?03:03
AdamDV2On the server?03:04
AdamDV2Yes, it does03:04
AdamDV2dash: Any idea why the files aren't showing up?03:05
AdamDV2Oh man, bzr is awesome04:37
parthmlifeless: good point on https://code.launchpad.net/~parthm/bzr/538868-message-for-heavy-checkout/+merge/24483 thanks for the review05:01
parthmlifeless: i am planning to fix the repo checkout message. will file a bug for the heuristics and branch part.05:02
lifelessparthm: cool05:02
parthmlifeless: whats a good way to check if we are in a repository?05:03
lifelessparthm: the underlying code does it05:03
lifelessparthm: checking at the outer layer would be a mistake05:04
parthmlifeless: i am looking at bzrlib.branch.create_checkout and wondering where to put the test. 'if lightweight' is already present there.05:05
parthmis there something like is_repository or something?05:05
lifelessparthm: deeper still05:06
parthmlifeless: ok. thanks .. will look.05:06
lifelessparthm: create_branch_convenience will know; but pull is the one doing the fetching05:06
lifelessparthm: [and this is perhaps why doing it as a heuristic in fetch is actually fundamentally easier]05:07
* parthm is reading create_branch_convenience05:08
lifelessAdamDV2: glad you're liking it05:10
parthmlifeless: this is what i have in mind http://pastebin.com/MB6F5UU0 . The change in inside bzrdir.determine_repository_policy. basic testing with branch and checkout (inside/outside repo) shows it works.05:29
parthmlifeless: does that look like a good approach.05:29
=== AdamDV2 is now known as AdamDV|ZzZz
parthmlifeless: nevermind. this shows the message for init also. need to look into it some more. thanks for the pointers.05:39
lifelessno probs05:41
lifeless-> city, finishing day on the train ;)05:54
bialixanybody knows how to merge patches to lp:bzr/2.1?05:59
bialixGaryvdM was unable to merge there05:59
bialixvila: ?06:00
twbPeculiar thing when going through polipo: Got a 200 response when asking for multiple ranges, does your server at support range requests?06:30
vilatwb: A range request should return only part of a file, if your server doesn't support it, performance will suffer,06:46
vilatwb: if bzr needs, say a few kbytes in a multi MB file, your server is returning the whole file anyway06:46
twbWell, it's a proxy, and it definitely supports range requests06:46
twbThe server on the far side of the proxy is lp:dosage06:46
vilatwb: try using -Dhttp and look at .bzr.log you'll see what bzr is aksing and *receiving*06:47
twbOf course, it would help if the problem was reliably reproducible :-/06:48
twbI can't reproduce it a second time, so I'll wander off until I can06:50
twbUpdate: I couldn't reproduce the problem again with bzr, but a simple curl -r0-0,-1 shows that polipo doesn't handle *multiple* range requests.06:57
twb(i.e. it groks Range: 0-0, but not Range: 0-0,-1.)06:57
vilatwb: bzr does a lot of multiple requests but... you can't read that unless you stay connected a bit longer...07:14
spmvila: :-)07:24
vilaspm: yeah :) But a bit frustrating nevertheless :)07:28
spmoh yes07:28
vilamy my my, babune is telling me a strange story, a doctest is failing in branchbuilder for hardy/jaunty/karmic but not for freebsd/gentoo,07:34
viladigging a bit it seems it's not run on gentoo/freebsd and not on pqm either which is more of a concern07:35
vilahmm, lifeless is gone ?07:35
parthmvila: hi08:21
vilaparthm: hey !08:22
parthmvila: i was just going through the report. the changeset is https://code.launchpad.net/~parthm/bzr/549310-mandatory-whoami/+merge/2424408:22
vilayeah, so I guess the test pass if some env var is set, but which one ?08:23
parthmvila: i think the change that might have caused this is that setting whoami is now mandatory. but tests don't do this. so tests use 'EMAIL': 'jrandom@example.com' in tests.__init__.py08:23
vilaparthm: shouldn't we use EMAIL if it's set ?08:24
parthmvila: is possible to reproduce this on lucid?08:24
parthmvila: yes. EMAIL is being used. and hence the tests are passing. i am surprised that something failed. let me try this tests specifically.08:25
vilaparthm: the test pass on the lucid slave, weird, it's supposed to use the same setup as hardy/jaunty/karmic at least as far as env vars are concerned...08:25
parthmvila: is this doctests something outside of selftest?08:25
vilaparthm: no, you can run it with 'bzr selftest -s bzrlib.branchbuilder'08:26
ubottuFor posting multi-line texts into the channel, please use http://paste.ubuntu.com | To post !screenshots use http://tinyurl.com/imagebin | !pastebinit to paste directly from command line | Make sure you give us the URL for your paste - see also the channel topic.08:26
vilaparthm: failure on hardy: http://paste.ubuntu.com/428801/08:27
parthmvila: interestingly the test is passing on my system.08:27
vilaparthm: I'm sure it is :)08:27
vilaparthm: that's why I mentioned a possible test isolation problem, if the env is correct (outside of bzr control) the test pass, if it's not, it fails08:28
* parthm launches synaptic looking for python 2.508:28
parthmupgraded to lucid recently. "Package python2.5 has no available version, but exists in the database." :(08:29
parthmvila: could it be the python version? but it passed on pqm so i suppose 2.4 and 2.6 are ok.08:30
vilaparthm: gentto uses 2.6, I don't think python version is relevant here08:30
vilawell, my gentto slave use 2.6 (dunno what is available nor used generally on gentoo)08:30
vilaha, looks like I have yet another source of typos there, hey, fingers, it's gentoo k?08:31
vilaparthm: what env vars are not used anymore with your patch ?08:32
vilaparthm: looks like config.username() docstring is not accurate anymore, it says: "If none is found, a reasonable default is (hopefully)  created." but it seems it now raises NoWhoami instead08:34
parthmvila: the only change is setting EMAIL in tests/__init__.py .. _auto_user_id() is gone and replaced by errors.NoWhoami08:34
vilaparthm: oh, and I suspect the doctests ignores the EMAIL set by bzrlib.tests.__init__.py08:34
GaryvdM Hi vila.08:35
vilaparthm: haaaa, setting EMAIL bingo :)08:35
vilaGaryvdM: Hi !08:35
vilaGaryvdM, parthm: thanks so much for your work yesterday, the review queue looks so much cleaner !08:35
GaryvdMvila: re: https://code.edge.launchpad.net/~bialix/bzr/2.1-clean-tree-bzrdir/+merge/2466908:35
* parthm fixes config.username() docstring08:36
vilaGaryvdM: yes, bialix ping me earlier but quicly went after that, probably some auth setting missing on pqm, I'll submit that08:36
GaryvdMvila: I don't have permision to push to bzr/2.1. Please could you submit08:36
GaryvdMThanks vila.08:36
parthmvila: for a moment there i though i had EMAIL set in my shell. but even without it the tests pass. hmm.08:39
parthmvila: any idea why the error is not reproducible?08:39
vilaGaryvdM: submitted08:40
vilaparthm: not yet, that's why I wanted to talk with you :D08:40
vilaparthm: so, on my karmic slave: ./bzr selftest -s bzrlib.branchbuilder.BranchBuilder fails,08:41
vilabut EMAIL=joe@example.com ./bzr selftest -s bzrlib.branchbuilder.BranchBuilder succeeds08:41
parthmvila: weird :)08:43
parthmvila: a simple fix could be just setting the EMAIL in the doctest but that still doesn't explain why its not reproducible08:44
vilaparthm: yup08:44
vilaparthm: a workaround one would be to set EMAIL in my slaves08:44
vilaparthm: but I don't see *where* EMAIL is taken into account08:45
vilablah, stoopid under your nose: config.username()08:46
parthmvila: yes08:46
parthmshould http://dpaste.com/191445/ be saying "running 0 tests..." at the top?08:47
vilaensure_username docstring is wrong too (even if NoWhoami inherits from BzrCommandError, it's worth being more precise)08:47
vilaparthm: hehe, no patches welcome :)08:47
vilaparthm: kidding, don't spend too much time no this one08:47
parthmvila: not a problem. but this is very weird.08:48
vilaparthm: or file a bug with a 'papercut' tag08:48
parthmvila: i will attach the tag to the bug you filed along with the error log you put up. i will push the updated docstrings anyway. better to keep docs precise if possible08:49
vilaparthm: in retrospect, setting EMAIL *by default* is a bit weird08:49
vilaparthm: no, I meant the '0 tests' one08:49
parthmvila: ah :)08:49
vilathe doctest one is a real problem08:50
vilaha, not real, both are reals, I meant more serious08:50
vilawe don't want reports that the test suite is now failing all over random places for no good reasons08:50
parthmvila: "setting EMAIL by default"?08:51
parthmvila: agreed.08:51
vilaparthm: in TestCase._cleanEnvironment()08:51
vilaexcept for doctests I'm pretty sure all our tests relies on this08:51
parthmvila: yes. i couldn't think of a better way. apart from each test doing a whoami or using a config file. any ideas?08:52
vilaparthm: that's why most of the vars are set to None08:52
parthmvila: i was reluctant to do that but wasn't sure there were other options.08:52
vilaparthm: let's try to barcktrack a bit, the goal here is to avoid people committing without a wrong whoami so they don't come back asking to fix old commits,08:53
vilaso your fix is fine08:53
vilaand since you added tests to check the behavior when the variable is explicitly unset, I think the tests are fine too08:54
vilaparthm: do you have EMAIL set ?08:55
parthmvila: i did have EMAIL in my zshrc but even after unsetting it tests pass.08:56
vilaparthm: meh08:57
parthmvila: does the test work for you locally?08:58
vilaparthm: hehe, what do you call 'locally' ? I have ~10 different configs to tests under :-)08:58
vila(more problably 15, but I don't want to brag :)08:58
parthmvila: :D ... i just mean whatever system you are using currently.08:59
* vila trying on karmic08:59
=== AdamDV is now known as Guest31208
parthmvila: https://bugs.launchpad.net/bzr/+bug/576269 ... file it as tech-debt as there was no papercut tag.09:00
ubottuLaunchpad bug 576269 in bzr "verbose mode in selftest show "running 0 tests"" [Undecided,New]09:00
parthmvila: i am on lucid09:00
a212901390231901vila, your windows bot seems to have been getting stuck before even getting as far as the first test of late09:00
vilaa212901390231901: shudder, yes, some weird setup bug, some network share not showing up when it should :-/09:01
vilaa212901390231901: thanks for noticing !09:02
vilaparthm: passing locally....09:02
* parthm wonders how to reproduce the error09:03
parthmvila: whats different about the env where the test is failing?09:03
vilaparthm: searching09:04
a212901390231901heh, well done for filing that bug parth, I've been ignoring it for ages09:04
parthma212901390231901: :)09:05
a212901390231901what's the fallout from the nodefault whoami? I meant to review the change but didn't find the time.09:06
* parthm starts reading bug #32132009:06
ubottuLaunchpad bug 321320 in bzr "bzr's doctests are not isolated (branchbuilder doctests check global gpg configuration)" [High,Confirmed] https://launchpad.net/bugs/32132009:06
a212901390231901ah, got the the pastebin link in the log09:07
a212901390231901I'll see if I get it here09:07
vilaparthm: found it, I'm sure you will appreciate the irony there: comment out your 'email' entry in .bazaar.conf09:08
parthmvila: hmm. weird http://dpaste.com/191454/09:09
* parthm checks if he has some other email set.09:10
parthmvila: yup.09:10
a212901390231901passes here too.09:10
a212901390231901pretty sure I don't have any email or config stuff in the test account09:10
parthmvila: reproduced it with EMAIL=<blank> and commented out email in bazaar.conf. phew! :)09:10
vilaa212901390231901: what does 'bzr whoami' says ?09:11
vilasay even09:11
parthmvila: thanks for finding this.09:11
vilaparthm: so, summary: people without whoami set will see a failure09:11
vilaI think it's a good thing in fact :)09:11
parthmvila: yes. :)09:12
vilaafter all, your fix is about helping people falling into this trap, so...09:12
parthmvila: heh :)09:12
vilaparthm: thank you for helping me finding out a hole in my slave setups :-D09:12
a212901390231901okay, nope, does fail indeed09:12
parthmvila: ooh :) ... yes. thats what this shows :)09:13
parthmvila: so the interesting question is what do we do about this. we could setup EMAIL for the doctest. or we could let this be as a failsafe.09:14
parthmvila: ideally doctests should use the same env as other tests as mentioned in bug #321320 that you linked to this report.09:14
ubottuLaunchpad bug 321320 in bzr "bzr's doctests are not isolated (branchbuilder doctests check global gpg configuration)" [High,Confirmed] https://launchpad.net/bugs/32132009:14
vilafailsafe sounds ok, I still have to understand while the tests *succeeded* in some slaves09:14
vilaparthm: that sounds right (even if it will *remove* the failsafe here)09:15
parthmvila: if we keep these two setups separate eventually something else will be different and tests will behave weird.09:15
parthmvila: we can keep this as a tech-debt ticket. would you like to put a comment in or should i?09:16
vilaparthm: go ahead09:16
vilaparthm: you can also look at creating the papercut tag, I'm surprised you can't use it09:17
parthmvila: put papercut tag on the "running 0" bug09:23
vilaparthm: thanks09:23
parthmvila: thanks for your help with understanding the doctest issue. i have updated the bug with a comment.09:24
parthmvila: how much time should to take for a patch to pass tests on queue to status on lp changing to merged?10:34
parthmvila: https://code.launchpad.net/~parthm/bzr/181124-ls-short-opts/+merge/24414 passed tests quite some time back but hasn't shown up on trunk.10:35
vilaparthm: haha, a well known French humorist would tell you: precisely ? A certain amount of time10:35
parthmvila: :) ... would 'bzr pull' be more or less immediate?10:36
parthmimmediate as in a few mintutes10:36
vilaoh,wait a minute, pqm sent a 'sucess' mail ?10:36
parthmvila: no mail yet. just that the tests passed quite some time back on pqm. the queue is empty now.10:37
vilaparthm: hmm10:37
vilaparthm: sounds like a failure somewhere to me10:38
parthmvila: yup. the success mails came out faster yesterday. maybe we are making pqm work too hard :)10:39
parthmvila: last commit on trunk is 14 hrs ago.10:39
vilaparthm: re-submit or run 'make check' locally (that's what pqm does IIRC)10:39
parthmvila: what does 'make check' do?10:40
vilaparthm: use the source Luke ! :-) It generate docs and run the full test suite with: $(PYTHON) -Werror -O ./bzr selftest --subunit $(tests) | tee selftest.log10:41
parthmvila: ah. i though it was something non-standard pertaining to pqm :)10:42
parthmvila: i will try to resubmit.10:42
parthmvila: i did a resubmit. http://pqm.bazaar-vcs.org/ ... lets see how that goes. thanks.10:44
vilaparthm: try to put (parthm) at the front for the next submissions, may people rely on that when scanning the commit messages :)10:45
a212901390231901I want to file a bug about bzrlib.lsprof being weird code, but I might save it till next week when I can ask why it's like that.10:45
parthmvila: will do. i was wondering what the recommended practice was :)10:45
vilaparthm: putting (something) in front :) lifeless does it automatically in his hydrazine branch, but that's on hold currently10:46
vilaa212901390231901: jam is likely the best to answer that10:47
vilaa212901390231901: there are historical reasons which may need to be revisited10:47
vilaparthm: oooh, he's gone :-/10:59
a212901390231901hey Alexander.11:00
bialixhey mister-with-very-long-nick!11:00
a212901390231901you don't have time today to do a test build the windows installer for me, do you?11:00
bialixa212901390231901: sorry,11:01
bialixhave to finish urgent job and pack my bag11:01
a212901390231901s'cool, can wait for next week.11:02
bialixbut I will be ready to commit this next week11:02
parthmis there something happening on pqm ... i got a weird set of errors for https://code.launchpad.net/~parthm/bzr/181124-ls-short-opts/+merge/2441412:09
parthmhttp://dpaste.com/191515/ the tests pass locally12:09
a212901390231901meh, testtools tracebacks are so useless12:11
a212901390231901I'll pull and try it here12:11
a212901390231901hm, known failures under windows as they're old tests with bad locking12:15
a212901390231901same basic result.12:15
parthma212901390231901: thanks. i am running my tests again. this mp was submitted earlier this morning but pqm was silent. this was the second submit.12:17
a212901390231901is -Werror catching you out?12:17
a212901390231901not sure if any of the locking stuff will start pushing warnings, hard to see how the branch in question has made any change to that though12:17
vilaparthm: makes no sense to me either12:18
parthma212901390231901: will try. i typically run only blackbox locally with selected tests from bt to avoid "new thread" errors.12:18
* parthm needs more ram than 1GB12:19
a212901390231901or -s bb.test_info -s bb.test_revert12:19
parthma212901390231901, vila: no errors with -Werror for bb.test_[info|revert]12:21
parthmthe patch is actually trivial ... short options. it should really be causing problems.12:22
a212901390231901yeah, seems more likely to be something external12:22
parthmi will do a resubmit ... the 3rd :P12:23
parthma212901390231901, vila: its in queue now. thanks for trying out the test guys.12:26
a212901390231901heh, roundup is funny, "A problem was encountered processing your request. The tracker maintainers have been notified of the problem." = success, comment posted12:28
a212901390231901hm, I think I'll give up on thinking of a smarter way to do this and just post the branch for review12:32
=== mrevell is now known as mrevell-lunch
=== salgado-afk is now known as salgado
sangiwhile trying to install loggerhead ./serve-branches is throwing an error like this: import bzrlib.foreign ImportError: No module named foreign12:52
jelmersangi: the version of bzr you're using is too old12:53
maxbIs there actually any point whatsoever to doing incremental packs *during* a 'bzr upgrade' ?13:06
sangiinstalling loggerhead throws an error like this : http://pastebin.com/ZDQp2Kea13:15
sangibzr version is 2.0.313:15
lifelesslooks ok13:17
=== jelmer is now known as Guest34328
Peng_sangi: That's fine.13:18
Peng_The bzr logging bit is a bug, but it's not a big deal...13:18
=== Guest34328 is now known as ctrl
=== ctrl is now known as jelmer____
=== mrevell-lunch is now known as mrevell
=== IslandUsurperAFK is now known as IslandUsurper
* luks hopes he won't get into trouble because of pushing to qbzr trunk after a long time of inactivity :)13:40
lukshm, and loggerhead doesn't handle long lines in commit messages well13:41
GaryvdMHi luks13:45
GaryvdMLuks: Np pushing to trunk..13:45
GaryvdMluks: Are you still coming to UDS?13:53
luksGaryvdM: no, I had to cancel :(13:54
GaryvdMluks: :-( - I was looking foward to meeting you13:54
luksme too...13:56
luksI really wanted to go, but couldn't find anybody to take care of some things instead of me during that time13:56
GaryvdMI see13:57
=== radoe_ is now known as radoe
cbzWhy does tortoise-bzr keep throwing lock errors (seemingly for no reason) on using the pull command?14:47
cbzThe identical command used at the cli then works14:47
a212901390231901bad interaction with another shell extension14:48
GaryvdMcbz: what happens if you run bzr qpull?14:52
cbzThat is what is having problems effectively.14:53
cbzTortoise-bzr runs bzr qpull14:53
cbzWhich occasionally complains about being unable to lock a file inside the .bzr directory14:53
hazmatany reason why bzr-svn has to refetch all revprops on update... using bzr-svn against apache repo (shared project), means every update has to check/fetch against 1m total repo revs14:57
hazmati would have thought it could just iterate from where it last left off14:58
hazmatits got a 3g cache file as well, so even after it fetches remote revsprops on every remote op (update, missing, merge) it still has to churn through its cache file for a few minutes15:04
jelmer____hazmat, it doesn't refetch all revprops as far as I know15:08
jelmer____hazmat, what version are you using?15:08
hazmatjelmer_, bzr-svn 1.0  revno 3275 with bzr 2.0.215:08
hazmatjelmer_, is it possible its just processing all the ones in cache, when it says its pull phase:discovering revprop revisions x/y ?15:10
jelmer____hazmat, What version of svn ?15:10
hazmatjelmer_, i'm trying to use it against an apache repo http://svn.apache.org/repos/asf/hadoop/zookeeper/trunk    the project only has 630 revs, but the repo has about 1m revs.15:12
jelmer____hazmat, it should only do that once and then just cache the results15:13
hazmatjelmer_, does it display the discovering revpop revisions when it processing from cache?15:15
* hazmat tries updating against bzr-svn 1.0 branch15:15
jelmer____hazmat: only for new revisions in the repo15:17
hazmathmm.. well its definitely processing from scratch on every remote cmd.. i'm gonna try updating to bzr-svn 1.0 latest on branch, and bzr 2.1, and see if it continues.15:18
hazmator at least processing every rev somehow.. its got a 2.7gb repo cache in ~/.bazaar/svn-cache15:18
jelmer____hazmat, I can't reproduce that with a current version of bzr-svn15:18
jelmer____hazmat, and launchpad doesn't appear to suffer from it either15:19
awilkinshazmat, I think I have a copy of that repo also15:29
hazmatawilkins, if you do an bzr pull on it, does process every repo rev?15:29
awilkinsAck, I don't have the revision info cache on this machine15:33
awilkinsI do recall it doing quite a lot of looking through revision properties for certain operations but I've not really made any detailed study of it15:34
awilkinsIt does have 941,754 revisions which is quite something15:35
awilkinsAnd I pulled my copy of it some time ago15:36
hazmatso i made a new pristine bzr branch against the repo (existing rev cache), and updated and it works fine with (bzr 2.1, bzr-svn 1.0 (latest))  BUT only as long as the local branch doesn't have any commits, if it does then it tries to process every rev15:36
hazmatjelmer_, ^15:36
funkyweaselGood afternoon chaps.15:37
funkyweaselI'm back with bzr performance issues agin.15:37
funkyweaselEver since I upgraded from ubuntu hardy/bzr 1.3.1 to ubuntu karmic and bzr 2.0.4 I've found bzr to be *really* slow when performing certain operations - status, diff, commiting.  Branching and upgrading take an unthinkable amount of time (several hours, upgrades hang).15:40
awilkinsfunkyweasel, across 1.3 and 2.0.4 Bazaar has moved to a new repository and branch  format ; it sounds like your issues are mostly due to runtime on-the-fly conversions of the data. Not so sure about the upgrades (which should fix the problem).15:42
funkyweaselThe repo server is still on bzr 1.3.1, so I've tried upgrading local branches to pack-0.92.  This gave a brief speed up back to old levels of performance, but has dropped back to dog-awful performance since.15:42
funkyweaselawilkins: No conversion should be happening if I am using branches generated by 1.3.1 in 2.0.4 unless the newer version is sub-optimal for use with the older repo/branch format.15:44
awilkinsfunkyweasel, True15:44
awilkinsfunkyweasel, I don't see why  2.0.4 would be slower for the old formats because it's still the same code AFAIk15:45
funkyweaselawilkins: Me neither.  but it's the only explanation I can think of.15:45
funkyweaselawilkins: It seems like 2.0.4 is *much* less efficient.15:46
awilkins2.x with native formats is pretty fast - the only thing I have to complain about is the packing speed of format 2a15:46
funkyweaselCould it be that 2.0.4 is converting old repo/branch format into the newer format internally, performing diff calculations, then converting back to old output for format?15:47
awilkinsIt takes a lot longer to do a pack on 2a than it does on lower formats, and I'm only losing about 10% repo space on the trees where the time is long enough to be annoying15:47
jelmer____hazmat, that's while pushing right?15:47
funkyweaselI'm certain that 2.x is the nuts with 2.x repos.  But that's not always handy if you have limited or no access to the repo server on an older version.15:48
awilkinsfunkyweasel, TBH, I use 2.x with 1.14-rich-root branches all the time but don't notice this ; maybe it's something to do with the even-older formats you're using15:49
funkyweaselIs it hugely unusual to have a point version difference between local/client and repo server?15:49
funkyweaselawilkins: Yep - I am pre-Rich-roots. :/15:49
awilkinsfunkyweasel, I always had to cope with Subversion so I just used rich-root branches by reflex whenever possible15:49
awilkinsfunkyweasel, I have noticed that non-rich-root to rich-root incurs the biggest conversion overhead15:50
funkyweaselawilkins: Right, yes.  But I can't do that on the repo server due to the old version of bzr, as I understand it.15:50
funkyweaselI am *not* using rich roots as far I am aware.15:50
awilkinsfunkyweasel, Also true .....15:50
funkyweaselI just don't understand how *without upgrading branches* the newer version is much slower.  That just doesn't make sense.15:51
funkyweaselI've got bzr status taking minutes as opposed to seconds.15:51
awilkinsfunkyweasel, Are you using lightweight checkouts or heavyweight checkouts from the sevrer or are they just branches?15:53
funkyweaselCheckouts from repo server.  I tried experimenting with branching from a local checkout of thetrunk, upgrading this new local branch to pack0.92, pushing to repo server and binding to repo server.  But it's still the same shocking performance drop compared to
awilkinsfunkyweasel, Just a thought, have you tried operations on branches that are not bound to the server?15:55
funkyweaselawilkins: Yup.  Same issue.15:58
hazmatjelmer_, that's while pulling15:58
hazmatjelmer_, i branch, do a local commit, and try pulling, and it has to reprocess every rev, if i don't do the local commit, and just pull, it seems to be fast, although i'm curious if thats also the case when there's new remote revs.16:00
funkyweaselI mean, if it's just a case of 2.0.2 being poor at old repo/branch versions then fair enough.  It's annoying but I just don't have time to switch to another solution.  Hopefully the repo server will get upgraded at some point, and for now I can bite down on operations taking long and leave it be.16:04
=== salgado is now known as salgado-lunch
=== beuno is now known as beuno-lunch
=== IslandUsurper is now known as IslandUsurperAFK
jmlTuxIce, thumper: the best place to look for my ssh server work is lp.services.sshserver17:18
cobalt_mikebzrlib question: should I expect any problems if I provide my own custom / subclasses _ChangeReporter for e.g. delta.report_changes?17:27
=== salgado-lunch is now known as salgado
=== beuno-lunch is now known as beuno
=== JFo is now known as JFo-afk
=== IslandUsurperAFK is now known as IslandUsurper
Pilkyis there a way with mv --auto to tell it not to mark certain files as moved, or to undo that for certain files after the fact?18:53
PilkyI've got about 10 moved files and 8 are correct but it is picking up 2 deleted files and matching them to 2 new files18:54
strkI'm using an unbound branch and now dunno if it diverged or not19:13
dashstrk: 'bzr missing' can tell you19:13
strkwhen I push, bzr complains 'ERROR: Operation denied because it would change the main history.'19:13
strkah, nice19:14
strkok, 'missing' says there are 3 extra revisions19:14
strkonly one is really mine, the other 2 are merges from trunk19:14
strknow, how do I push mine and leave the merges alone?19:15
maxbAre the merges before or after yours?19:40
maxbIn fact, maybe just pastebin the output of bzr missing19:41
=== JFo-afk is now known as JFo
strkhttp://codepad.org/ole3ycZ7 <--- 'missing' output20:02
maxbstrk: And do you now want to push "Handle the case of failed glue initialization" back to trunk?20:22
maxbIn which case, you'll need to merge, since the branches have obviously diverged20:22
maxbGiven that there was something to merge20:22
maxbThe 'ERROR: Operation denied because it would change the main history.' is indicating that you are disallowed from pushing a merge of *trunk into your branch* (because this would change the assignment of revnos to revisions already in trunk)20:23
maxbInstead you must merge *your branch into trunk*20:23
a212901390231901ha, wonder if bug 576533 will break the IRC bot20:35
ubottuLaunchpad bug 576533 in bzr "ProblemType: Crash BzrDebugFlags: set() BzrPlugins: bzrtools /usr/lib/python2.6/dist-packages/bzrlib/plugins/bzrtools [2.1.0] launchpad /usr/lib/python2.6/dist-packages..." [Undecided,New] https://launchpad.net/bugs/57653320:35
strkmaxb: so, how do I merge my branch into trunk ?20:36
maxbhave a branch/checkout of trunk; bzr merge ../mybranch20:37

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