[00:00] <stewart> hi! is there any way to merge in a tree but take none of the changes from it?  i.e. the merge revision reverses any changes in the branch i'm merging. (i'm trying to clean up some old release trees and have tags for each release instead of different trees, and, well, things are a total mess)
[00:00] <spiv> stewart: "bzr merge FOO ; bzr revert ."
[00:01] <spiv> (Then commit, of course)
[00:01] <stewart> spiv, awesome!
[00:02] <stewart> spiv, it's obvious now that i think about it :)
[00:02] <spiv> :)
[00:07] <spm> o/ spiv
[02:07] <_habnabit> how can I unset pending merge tips?
[02:09] <_habnabit> specifically, I have a checkout from a few years ago that I'm trying to dissect and turn into smaller commits, but apparently there's pending merges and as such I can't commit only a subset of the files
[02:20] <spiv> _habnabit: bzr revert --forget-merges
[02:21] <_habnabit> that'll only forget the merges and nothing else?
[02:21] <spiv> Yes.
[02:22] <spiv> As the help says "Remove pending merge marker, without changing any files."
[02:22] <_habnabit> okay, thanks.
[02:53] <Kamping_Kaiser> http://paste.debian.net/134214/ can this issue be trivially resolved (a rich root conversion somehow?) or do i have to rebranch?
[02:58] <spiv> Kamping_Kaiser: looks like you just need to do "bzr upgrade" in your local branch (or delete your local branch and rebranch if you prefer; it can be faster sometimes)
[03:05] <Kamping_Kaiser> spiv: thanks, i'll give it a crack. the error made it seem much more complicated then that
[03:06] <Kamping_Kaiser> lightning fast conversion, thanks
[03:08] <AuroraBorealis> darn, gz isn't here >.>
[03:09] <_habnabit> bzr revert is giving me 'bzr: ERROR: The file id "plugins-20091211215309-7pl7ljzyayqv3ifa-2" is not present in the tree [...]'
[03:09] <_habnabit> (snipped the repr of the tree)
[03:10] <_habnabit> is there a fix for this?
=== mwhudson_ is now known as mwhudson
=== idnaria is now known as idnar
[06:12] <vila> hi all !
[06:12] <vila> poolie: care to unblock https://code.launchpad.net/~vila/bzr/861472-migrate-log-format/+merge/77570 ?
[06:13] <cinerama> hi vila, can i get you to do me a favour?
[06:19] <vila> cinerama: hehe, probably, but ask first :)
[06:20] <cinerama> vila: i need help testing a french tollfree number.  i can't dial it from here :)
[06:21] <vila> cinerama: yeah, that make sense (they are often restricted to local callers)
[06:21] <cinerama> vila: i'll just msg you the number if that is OK?
[06:22] <AuroraBorealis> hmm, when does mgz get on? o.o
[06:26] <vila> AuroraBorealis: give him an hour
[06:26] <AuroraBorealis> kk
[06:27] <AuroraBorealis> might be in bed then >.>
[06:31] <poolie> hi vila
[06:33] <AuroraBorealis> also: it seems that if you interrupt any fast-import
[06:33] <AuroraBorealis> and then try to resume it, you hit this bug: https://bugs.launchpad.net/bzr/+bug/541626
[06:33] <ubot5> Ubuntu bug 541626 in Bazaar "'BTreeBuilder' object has no attribute '_find_ancestors'" [High,Triaged]
[06:38] <AuroraBorealis> that would seem very annoying if you have to restart the entire import cause of a bug o.o
[06:40] <jelmer> moin
[06:41] <vila> poolie, jelmer : _o/
=== Ursinha is now known as Ursinha-afk
[07:12] <jam> morning vila, jelmer
[07:12] <jam> and poolie, if you're still around
[07:13] <poolie> hi jam, i'm still here
=== Ursinha-afk is now known as Ursinha
[08:00] <mgz> morning all
[08:00] <poolie> hi mgz
[08:00] <AuroraBorealis> hi.
[08:06] <jelmer> poolie, jam: What do you think about landing colocated branch support in an experimental format?
[08:07] <jelmer> that way we can polish the UI and actually have it tested, before we decide we're happy with the format change.
[08:07] <jam> jelmer: sounds reasonable to me. My main concern was having a semi(poorly?)-supported default format
[08:07] <jelmer> once we're happy we can backport the format change to 2a
[08:09] <jelmer> jam: cool
[08:16] <vila> jelmer: my main concern with using a dev format is that we'll get less exposure and need some migration path later, so more work for less feedback. But if that's the only way to get progress, I'll vote for progress ;)
[08:17] <jelmer> vila: migration *should* be a matter of rewriting the format file
[08:32] <poolie> jelmer i'm sorry it's stalled
[08:32] <poolie> an experimental format seems like an ok step forward
[08:37] <jelmer> cool, I'll have a look at getting it into an experimental format
[08:40] <nigelb> Hrm.
[08:40] <nigelb> Bzr is behaving weirdly
[08:40] <nigelb> I did a bzr push to an LP branch. Its taking forever.
[08:40] <jelmer> nigelb: ... bizarrely, would you say?
[08:40] <nigelb> heh
[08:41] <nigelb> oh bah. Nevermind.
[08:41]  * jelmer wonders if he can collect a prize for being the 1 millionth person to make that pun
[08:41] <jelmer> nigelb: what was it?
[08:42] <nigelb> jelmer: Normally I just create a new branch, which I think is faster because of stacking.
[08:42] <nigelb> This time I pushed a new branch to the top of an old branch
[08:42] <nigelb> And I forgot --overwrite
[08:43] <mgz> bb.test_branch.TestBranch.test_branch_broken_pack is a known random failure, right
[08:44] <poolie> ok good night all
[08:44] <jelmer> mgz: yes, though I thought it ought to be fixed now. Vincent landed something that should've fixed it recently.
[08:44] <jelmer> have a nice evening poolie
[08:44] <poolie> thanks
[08:44] <mgz> vila: you landed the fix for the random fail on dev only?
[08:45] <vila> mgz: what random fail ?
[08:45] <mgz> ^
[08:46] <vila> ECONTEXT
[08:46] <jelmer> vila: 6 lines up :)
[08:46] <vila> yeah, got that, but still doesn't ring a bell, searching the mps
[08:48] <mgz> bug 807032
[08:48] <ubot5> Launchpad bug 807032 in Bazaar "blackbox.test_branch.TestBranch.test_branch_broken_pack can (and did) fail ramdonly on pqm" [High,Fix released] https://launchpad.net/bugs/807032
[08:49] <vila> ha, that one ! Yes, apparently dev only
[08:49] <vila> mgz: do you encounter it for 2.4 ?
[08:49] <mgz> yup, just then.
[08:49] <vila> that's the nice thing with spurious failures isn't it :-}
[08:50] <vila> mgz: do you want me to make a mp targeted at 2.4 ?
[08:51]  * vila re-reads the mp... so I wasn't the only unlucky guy :-}
[08:51] <mgz> sec, just seeing when it originated
[08:52] <vila> not sure I daggy-fixed that one :-/
[08:54] <mgz> yup, 2.4 only, 's from r5954
[08:59] <mgz> okay, updated some bugs and created more work for the patch pilot :)
[09:00]  * fullermd reckons that's the #bzr national sport.
[09:01] <vila> mgz: as in I should do a mp targeted to 2.4 ?
[09:01] <vila> mgz: or just submit it directly
[09:01] <mgz> I'd do an mp, but go ahead and land it.
[09:01] <vila> k
[09:02] <mgz> jam already reviewed the change and it looks okay
[09:44] <mgz> why is blame saying "extracting 0/330/33" at me...
[09:44] <mgz> something progress bar-y has messed up again
[09:57] <jelmer> vila: resubmitted metadir-goes-colo, with the metadir support in a new format
[09:58] <vila> jelmer: just got the mail, will review a bit later (~lunch)
[10:32] <vila> jelmer: you overwrote your previous proposal with https://code.launchpad.net/~jelmer/bzr/metadir-goes-colo/+merge/78221 ?
[10:33] <vila> jelmer: I can't find the previous one anymore 8-}
[10:41] <jelmer> vila: true
[10:41] <jelmer> vila: the previous one is pretty pointless though, it adds the colocated branch support in BzrMeta1
[10:42] <vila> jelmer: sure, I just wanted to quickly re-read it
[10:42] <vila> jelmer: no big deal if you don't have one easy way to provide it
[10:42] <vila> should be in my mail somewhere
[10:45] <jelmer> vila: for the changes, up to r6091 in the same branch
[10:45] <vila> ha excellent
[10:45] <jelmer> vila: for the mp and discussion: https://code.launchpad.net/~jelmer/bzr/metadir-goes-colo/+merge/72451
[10:57] <vila> jelmer: approved (under the assumption you'll wait for 2.5dev3, is that correct ?)
[10:57] <vila> jelmer: oh, and thanks for the pointers above, I used them !
[11:00] <jelmer> vila: any particular reason you'd want me to wait for 2.5b3?
[11:00] <vila> jelmer: not really
[11:01] <vila> your "beginning of the cycle" was ambiguous and I read it as 2.5b3,
[11:01] <vila> and my RM hat had a knee-jerk reaction thinking about tomorrow's freeze,
[11:01] <jelmer> vila: oh, I didn't realize I'd left that in there. I think I meant when 2.5 opened
[11:01] <vila> but that's silly :)
[11:02] <vila> argh, crossing messages :) I meant my knee-jerk reaction was silly
[11:02] <jelmer> ah :)
[11:02] <jelmer> vila: so you're happy to have it land now?
[11:02] <vila> yup
[11:02] <jelmer> vila: great, thanks! :)
[11:03] <vila> . o O (Now, mister PP and mister RM, would you please settle on what you want ?)
[11:03] <vila> . o O (PP: land !, RM: ok, land...)
[11:03] <vila> :)
[11:03] <jelmer> :))
[11:10] <vila> really lunch time now
[12:12] <jml> I want to add boolean options to lp:udd's config
[12:15] <vila> jml: I've added them to bzr >= 2.5 :-/
[12:15] <jml> vila: ahh. I see.
[12:16] <jml> vila: I guess it would be nice to be running more recent versions of bzr on the production machine.
[12:16] <vila> jml: don' be cruel :-)
[12:16] <vila> jml: in the mean time, you should be able to get_user_option_as_boolean ?
[12:16] <jml> vila: not from iconfig
[12:17] <vila> jml: gimme a se
[12:17] <vila> c
[12:17] <jml> vila: so far, I'm just doing config.get('option') == 'true'
[12:17] <vila> good enough for you ?
[12:18] <vila> jml: who are the intended users ?
[12:20] <jml> vila: me :)
[12:20] <jml> vila: so it's ok for me
[12:20] <vila> cool :)
[12:20] <vila> sorry for the... compatibility issues :-/
[12:21] <jml> vila: no worries.
[12:22] <mgz> vila: what's you're solution for getting paths out of envvars in config?
[12:22] <vila> mgz: hehe, glad you mention it :)
[12:23] <vila> mgz: env vars in config are used to provide default values
[12:23] <vila> mgz: so the plan is to have a specific option type for paths which can define how their corresponding env vars should be decoded
[12:24] <mgz> okay. and for things like BZR_LOG that don't go through config?
[12:24] <vila> mgz: make them go through config ?
[12:24] <vila> :)
[12:24] <mgz> do we want a bottom level osutils.path_from_environment() ?
[12:25] <vila> that certainly won't hurt !
[12:26] <vila> mgz: oh, let me guess, you're looking at bialix's bug about the unicode home dir ?
[12:27] <mgz> that, and thinking about jelmer's blocked mp
[12:27] <vila> mgz: LOL
[12:27] <vila> I was about to mention that too !
[12:27] <mgz> and looking at the current bb.test_version tests, which are, to put it mildly, a mess
[12:27] <vila> but ff has quit (why ?) and I was waiting for it to refresh to paste the url :)
[12:28] <vila> mgz: +1 to clean them up, especially as a separate mp
[12:28] <mgz> okay, lunch, where I shall ponder further.
[12:29] <vila> mgz: briefly looking, they are very old and may even be redundant with other tests
[12:33] <vila> mgz: there are a couple of strongly related topics I'd like to discuss, ping me when you're ready (and not before your lunch ;)
[12:36] <vila> bad jelmer
[12:36] <vila> in https://code.launchpad.net/~jelmer/bzr/deprecate-revision-history/+merge/78242 you have a === added file 'bzrlib/tests/per_repository/test_fileid_involved.py.OTHER'
[12:37] <vila> o.O How did you manage that... I thought bzr add was complaining now when trying to add such a file...
[12:39] <jml> this code needs a little stylistic cleanup.
[12:43] <jelmer> jml: which code
[12:43] <jelmer> vila: argh, looking now
[12:43] <jelmer> jml: ?
[12:43] <vila> jelmer: BB:tweak, the conflicts don't seem serious
[12:43] <jml> jelmer: lp:udd. Nothing major, just moving stuff that's in scripts into modules, making them import safe etc.
[12:44] <jelmer> vila: the odd thing is that "bzr send -o - lp:bzr" doesn't show them
[12:44] <vila> jml: $deity bless you
[12:44] <jelmer> vila: ah, it's a conflict.. nevermind
[12:45] <jelmer> vila: dankuwelmerci!
[12:46] <vila> jelmer: of course ! *You* didn't bzr add ! lp is.... misleading
[12:48] <jam> vila: I wanted to check with you, does it look like I squashed the hanging issue? I just checked on babune, and everything seems to be pretty blue in the last 12 hours or so
[12:48] <jam> only gentoo is 2days12hrs
[12:48] <vila> jam: feel free to dig the gentoo failures
[12:49] <jam> vila: yeah, it looks like gentoo is failing because it is timing out
[12:49] <jam> but at least it isn't hangnig
[12:49] <jam> hanging
[12:49] <jam> the failing tests look like they are all taking 8-14 seconds
[12:50] <jam> vila: I'm curious on your thoughts. Should we just increase the timeout, the original goal was to ensure that tests always progress, and a 4s test case seemed really long.
[12:51] <jam> I don't know why they would be *legitamately* taking 14s
[12:51] <jam> this test, for example: http://babune.ladeuil.net:24842/view/%20High/job/selftest-gentoo/lastFailedBuild/testReport/junit/bzrlib.tests.per_branch.test_stacking/TestStacking/test_fetch_copies_from_stacked_on_and_stacked_RemoteBranchFormat_default_/
[12:51] <jam> took 14s
[12:52] <jam> running it here takes 738ms
[12:52] <jam> so about 20x slower on gentoo
[12:52] <jam> I could set the test suite timeout to 2 minutes, but I'm still curious why gentoo is taking that long
[12:53] <jam> hmm.. seems something else funny is going on as well. as the previous runs on gentoo were also under the 1s mark
[12:54] <vila> jam: I wrote long explanations about my thoughts already no ? long story short: I didn't understand how you addressed the timeout leaking into the test server, your fix was supposed to address that so we have no more hangs (turned into failures)
[12:54] <vila> *if* these failures are related, you didn't fix the race
[12:57] <MvG> vila: Yesterday I got a mail from LP about you requesting a merge, but the linked page doesn't exist:
[12:57] <MvG> https://code.launchpad.net/~gagern/bzr/bug842575-rm-resolve/+merge/78102
[12:57] <MvG> Have you somehow withdrawn the merge request or something like that, or is this a bug in LP?
[12:57] <ubot5> Ubuntu bug 78102 in libflash (Ubuntu) "[Merge Request] libflash 0.4.13-9 from debian unstable" [Wishlist,Fix released]
[12:58] <vila> MvG: sorry about that, I deleted it after looking at it
[12:58] <MvG> Who's responsible for training ubot? The above doesn't make as much sense as one might expect.
[12:59] <vila> MvG: and commented on the bug, short story: you've been bitten by 'bzr resolve --all' being... not what it seems
[12:59] <MvG> vila: OK, explains the missing page.
[12:59] <jam> MvG: yeah, ubot doesn't understand mp links
[13:00] <MvG> jam: Can it be told to understand enough to know that it doesn't understand them? I.e. ignore anything with /+merge/ in it?
[13:00] <jam> MvG: I really don't know much about it, but I agree with your point
[13:01] <MvG> vila: I must confess I didn't really see the connection to the other two relatives of bug 842575 you mentioned. Although I'll still trust you that there is one, besides them all mentioning conflkict resolution.
[13:01] <ubot5> Launchpad bug 842575 in Bazaar "Missing file reported after resolved removal conflict" [High,Confirmed] https://launchpad.net/bugs/842575
[13:01] <jam> MvG: https://wiki.ubuntu.com/IRC/Bots
[13:02] <jam> vila: I'm trying to run another gentoo test run, to see if it is static failures or transient, but it just says gentoo is offline. Does it come online manually, or only at certain times of day, or?
[13:03] <vila> MvG: yeah, the linl is 'bzr resolve --all' which, without an action specified, consider that the conflict has been resolved and delete the conflict and its helpers *even* if that's not true
[13:05] <vila> jam: the slave is started if there is a run requiring it
[13:06] <MvG> jam: Wrote a line about the bot in #ubuntu-bots-team. Let's see.
[13:09] <MvG> vila: What do you mean "even if that's not true"? In the context of that bug, with a local modification and an incoming delete, what more can one do to resolve the conflict than remove all the helper files?
[13:09] <MvG> jam, vila: you need any test run on Gentoo?
[13:09] <vila> MvG: internally the code is different
[13:10] <jam> MvG: it ran on babune, I just wasn't sure about the timing of things. You make a request, it then spins up the machine and runs it.
[13:10] <MvG> vila: You mean the code for --all vs. a specific file?
[13:10] <vila> MvG: that's why I didn't mark yours as a duplicate because even if they are related they are still different enough
[13:10] <vila> MvG: yes
[13:10] <MvG> OK, I see.
[13:19] <MvG> wrt bug 842695: vila suggested discussing that on the mailing list. But as I'm not subscribed to the bazaar list, would one of you start the discussion there and summarize any results back on the bug report? I don't fancy subscribing to a high-volume mailing list just for this discussion if there is another way.
[13:19] <ubot5> Launchpad bug 842695 in Bazaar "log --include-merges apparently prints unrelated commits" [Undecided,Confirmed] https://launchpad.net/bugs/842695
[13:19] <jam> jelmer: the latest run of babune is about 2x slower than previous runs, and seems to only include your change
[13:19] <jam> 6190 Patch Queue Manager       2011-10-04 [merge]
[13:19] <jam>      (jelmer) Add load_plugin_translations() function. (Jelmer Vernooij)
[13:19] <jam> Do you think that could affect test suite performance at all?
[13:20] <jam> It doesn't seem like it should, so I'm suspecting something 3rd party
[13:20] <jelmer> jam: I'd be very surprised if that slowed things down
[13:20] <jam> vila: I'm trying to understand the duration things, like hree: http://babune.ladeuil.net:24842/job/selftest-chroot-maverick/241/testReport/history/?
[13:20] <jam> here
[13:20] <jam> it says the test suite took 55 minutes
[13:20] <jam> however, the time listed here: http://babune.ladeuil.net:24842/
[13:21] <jam> for selftest-chroot-maverick is only 7m59s
[13:21] <jelmer> jam: it just adds another utility function that only gets called by plugins, and has one test
[13:21] <jam> is one wall-clock time and the other is test-suite time?
[13:22] <jam> I see the same discrepancy between http://babune.ladeuil.net:24842/job/selftest-chroot-oneiric/lastBuild/testReport/history/? and http://babune.ladeuil.net:24842/job/selftest-chroot-oneiric/buildTimeTrend
[13:22] <mull> hi, all.  I'm still a bit new to bzr, and wondering if there's a simple way to create a branch which is a subset of its parent (by ignoring/filtering/blacklisting files).  is this possible?
[13:23] <jam> mull: there is a little bit of 'it depends'. you can do "bzr split SUBDIR", and it will create a branch that now only includes that subdirectory.
[13:24] <jam> However, it won't rewrite the history, so the older revisions of that new branch will be for the whole tree
[13:24] <MvG> jam: the console text appears to report the shorter time. Is that output from bzr itself or from subunit2pyunit? If it is from bzr, is it wall-clock time?
[13:24] <jam> If you want to create a new history, then you want to look at the 'bzr-fastimport' plugin and stuff like bzr fastexport, bzr fastimport-filter(?) , bzr fast-import
[13:24] <vila> jam: --parallel explains the difference
[13:25] <jam> vila: right, so the buildTimeTrend is wall-clock, and the test suite trend is the sum of times spent in each test
[13:25] <mull> jam -- ahh, fastimport sounds like the right thing.  yes, ideally I'd be rewriting the history
[13:25] <mull> thanks
[13:26] <jam> vila: do you know of any particular reason why babune would be slower on the recent runs? My patch landed about 4 runs ago, so I don't think it is directly responsible.
[13:26] <jam> And pretty much all of the runners I've checked show a significant slowdown in the last 1-2 runs
[13:26] <jam> (maybe you were using babune to do other work at the same time or something.)
[13:27] <jam> like I *just* requested a full gentoo run, and it finished in wall-clock 7min57s, but the one that tried to run this morning took 24min
[13:27] <jam> http://babune.ladeuil.net:24842/view/Gentoo/job/selftest-gentoo/buildTimeTrend
[13:59] <mgz> jam: re test timing discrepency
[14:00] <mgz> one number is how long it took from the starting the test suite to the finish
[14:00] <mgz> the other is the sum of all test times
[14:01] <mgz> when forking, the first can be several times smaller
[14:01] <jam> mgz: yeah, that's been sorted out.
[14:01] <jam> i'm calling it 'wall clock' time vs test case time
[14:01] <jam> the question is why did the last test runs across maverick natty, oneiric, gentoo, freebsd all suddenly take 2-4x longer than previous
[14:01] <jam> and when requesting a run of them manually, they drop back to their original time
[14:03] <mgz> have you looked at the individual test timings?
[14:03] <mgz> are they uniformly or by and large slower?
[14:04] <mgz> or are there specific problem tests?
[14:05] <jam> mgz: fast run just requested by me:http://babune.ladeuil.net:24842/view/Gentoo/job/selftest-gentoo/530/testReport/
[14:05] <jam> mgz: slow run from a 12 hrs ago: http://babune.ladeuil.net:24842/view/Gentoo/job/selftest-gentoo/529/testReport/
[14:05] <jam> you can sort of "duration"
[14:06] <jam> the slowest subset is the same "test_commit_builder"
[14:06] <jam> but it goes from 5min to 19min
[14:06] <jam> test_repository goes from 1m17s to 6m11s
[14:06] <jam> test_controldir doesn't seem much affected
[14:07] <jam> test_stacking is 1m6s to 4m40s, etc
[14:07] <jam> digging into individual tests, you can no longer sort them by time
[14:08] <jam> however, if you open both in tabs and then switch between them, they should line up
[14:08] <jam> for example: http://babune.ladeuil.net:24842/view/Gentoo/job/selftest-gentoo/530/testReport/bzrlib.tests.per_repository.test_commit_builder/TestCommitBuilder/
[14:08] <jam> vs
[14:08] <jam> http://babune.ladeuil.net:24842/view/Gentoo/job/selftest-gentoo/529/testReport/bzrlib.tests.per_repository.test_commit_builder/TestCommitBuilder/
[14:09] <jam> some tests are roughly the same time
[14:09] <vila> jam: have you looked at the dates and times ?
[14:09] <jam> I don't know whether "3ms" vs "34ms" is significant
[14:09] <jam> vila: across the board this seems to be the runs from this morning
[14:09] <jam> ~12 hours ago
[14:09] <jam> that are slower
[14:10] <vila> if they all run at the same time then you've got your explanation no ?
[14:10] <jam> I haven't manually requested re-runs from anything but gentoo yet
[14:10] <mgz> busy disk would have an effect something like that
[14:10] <jam> vila: the history trend doesn't seem to agree, wouldn't they all be starting at the same time over history?
[14:10] <jam> mgz: on the TestCommitBuilder, this test test_commit_unchanged_root_record_entry_contents
[14:11] <jam> in its permutations is consistently 80ms vs 300ms
[14:11] <jam> note that the Remote tests seem particularly affected
[14:11] <jam> going from .22s to 2.5s
[14:12] <jam> vila: so yes, the test suites could be competing with eachother, but if that was the case, I would have expected that to be happening every day, wouldn't it?
[14:13] <vila> no idea
[14:19] <vila> jam: if the tests are not meant to cope with a server timeout, I think the server should not timeout for these tests
[14:20] <vila> but that's just one more reason to use the real server... so feel free to ignore it too
[14:20] <mgz> let's see what happens next auto build.
[15:32] <jml> https://code.launchpad.net/~jml/udd/symbol-import/+merge/77312
[16:46] <james_w> I'm guessing that what Colin reports in https://code.launchpad.net/~ubuntu-branches/ubuntu/oneiric/dbus/oneiric-201107131641/+merge/67862 isn't instructive as to the cause?
[16:47] <james_w> but I've seen that on a few UDD branches recently, so there is likely a bug somewhere
=== yofel_ is now known as yofel
=== beuno is now known as beuno-lunch
[17:13] <jam> jelmer: I just got a email bump from your mail host:
[17:13] <jam> "quota exceeded"
[17:14] <jelmer> u
[17:14] <jelmer> jam: oops, I'll delete some more mail
[17:14] <jelmer> jam: thanks for letting me know
[17:21] <jam> jelmer: I was replying to your revision_history change, which I thought I had already commented on
[17:21] <jam> did you resubmit it/
[17:21] <jam> ?
[17:24] <jam> the issue is that it is ~ just moving the O(history) code into all the calling locations, rather than having them not actually doing it
[17:24] <jam> i'm trying to think of a happy medium where we don't add new callers
[17:24] <jam> but we keep the bad code in one place, rather than putting it in lots of places in the code
[17:31] <jelmer> jam: there is only one place where we use it outside of the testsuite, and that's in revisionspec
[17:42] <jam> jelmer: what do you think about a separate function (not a Branch method) to consolidate the code, and make it easy to find?
=== beuno-lunch is now known as beuno
[18:03] <jelmer> jam: I'm not sure that's actually necessary, it's just 6 calls to iter_lefthand_ancestry in the testsuite, all with known small histories
[18:03] <jam> sure, just more not having to repeat ourselves 6 times
[18:15] <jelmer> jam: fair enough
[18:21] <Sebboh> Hi. I'm not a regular bzr user, but some source I want to check out is in a bzr repo.  I'm using the bzr that comes with cygwin. I'm on Windows 7.  I get an out of memory error when I try: "bzr branch lp:leo-editor".  Now what?
[18:33] <jam> jelmer: anyway, it isn't critical, if you feel its too much work, I mostly wanted to discuss it a bit, since it seemed odd
[19:20] <jelmer> Sebboh: hi
[19:20] <jelmer> Sebboh: I'm not sure, it seems to work fine here with reasonable resource usage
[19:20] <jelmer> Sebboh: are you actually running out of memory or does that just happen to be the error message you're getting?
[19:26] <bpierre> hit
[19:26] <bpierre> *hi
[19:59] <Sebboh> Jelmer: I'm not running out of system memory.  But bzr.exe is 32bit.  http://pastebin.com/rXTq6fcg
[20:00] <Sebboh> I switched away from the cygwin bzr, I'm using 2.5b1 (standalone installer) from http://wiki.bazaar.canonical.com/WindowsDownloads now.
[20:06] <jelmer> hi bpierre
[20:06] <jelmer> Sebboh: ah :-(
[20:07] <jelmer> jam: I've removed one of the uses of iter_lefthand_ancestry; the other 4 seem hard to factor out sensibly so I'll keep them in for now.
=== jam2 is now known as jam
[21:04] <Sebboh> jelmer, after playing around with it for a while, I was able to get the repo downloaded (probably. the last stage is still running).  I used this method: bzr branch -r 2000 lp:le-editor; cd leo-editor; bzr pull -r 3000; bzr pull  ...(There are 4500 revisions total.)
[21:05] <Sebboh> I did get an out of memory error in the middle when I tried bzr pull to get me from r2000 to r4500.. it was too much.  So hopefully my workspace isn't corrupt or anything crazy. (I presume not because the subsequent bzr pull -r 3000 worked without error.)
[22:02] <Sebboh> So I was wrong about it working.  Turns out that pulling revision 3086 runs me out of memory, every time.  I watch bzr.exe memory usage spike from 60megs to over 500megs in less than a second, then it terminates.
[22:09] <jelmer> Sebboh: that's odd, that revision isn't particularly big
[22:09] <jelmer> charis:/tmp/leo-editor% bzr log -r3086 -p | wc -l
[22:09] <jelmer> 1898
[22:10] <Sebboh> I was thinking, maybe it just happens to be the revision that pushed the repo over some threshold.
[22:11] <Sebboh> I've seen a lot of talk about using 64bit python..  That's fine, and it might work for me, but, it sure as heck doesn't address the root issue. :)  (This is a huge bug.)
[22:12] <jelmer> So bzr pull -r3085 works but -r3086 breaks?
[22:12] <Sebboh> Yes.  With my w ... Sorry, I have to go.
[22:29] <Sebboh> jelmer: http://pastebin.com/XKJ15pJR
[22:29] <Sebboh> Work has been over for half an hour; bye! :)
[22:59] <MarkAtwood> hi!  i occationally get an error that looks like this:
[22:59] <MarkAtwood> bzr: ERROR: No such file: u'/home/hudson/hudson/.bzr/repository/indices/c38c25468e66e50956fd947035bf3ec6.rix': [Errno 2] No such file or directory: u'/home/hudson/hudson/.bzr/repository/indices/c38c25468e66e50956fd947035bf3ec6.rix'
[22:59] <MarkAtwood> when this happens, i have to delete all my branches that use that shared repo, delete that shared repo .bzr tree, and then do init-repo and start over
[23:00] <MarkAtwood> this is non-optimal
[23:00] <MarkAtwood> is there a better way to check and repopulate a corrupted shared repo?
[23:04] <jelmer> MarkAtwood: please file a bug about this
[23:04] <MarkAtwood> i jsut did
[23:04] <MarkAtwood> i wish the repo wouldnt get corrupted
[23:04] <MarkAtwood> but if it does, it would be nice if there was a way to have the repo grab "missing stuff" from launchpad
[23:07] <jelmer> I think there's an open bug about having a command that can regenerate an index file
[23:08] <jelmer> but indeed, the more interesting question is why that index is missing in the first place
[23:08] <jelmer> MarkAtwood: what's the bug #?
[23:09] <MarkAtwood> heh, and i just closed that tab, too
[23:09] <MarkAtwood> https://bugs.launchpad.net/bzr/+bug/868785
[23:09] <ubot5> Ubuntu bug 868785 in Bazaar "occasional corrupted shared reposatory" [Undecided,New]
[23:10] <MarkAtwood> we run bzr under hudson, so it's constantly checking out the source of the project and rebuilding it
[23:10] <MarkAtwood> so bzr branch is running many many times a day on many machines
[23:11] <MarkAtwood> (which is why it uses a shared repo, to cut down on network traffic)
[23:11] <MarkAtwood> when this happens, that jenkins node "jams"
[23:13] <jelmer> I'm not too familiar with the repository internals but hopefully one of the other devs will have an idea tomorrow
[23:14] <MarkAtwood> thank you jelmer
[23:33] <spiv> jelmer: sounds like it may be the same issue the Twisted folks saw under buildbot
[23:34] <spiv> jelmer: that simultaneous pulls of identical updates into a shared repo can cause symptoms like that: deleting an index file that's needed, etc.
[23:35] <spiv> jelmer: it's probably possible to at least provide a repair tool to just drop the missing pack/indices from pack-names
[23:35] <spiv> jelmer: but of course it'd be good to fix the root cause.  jam has a thorough understanding of the issue I believe
[23:36] <spiv> jelmer: the workaround for affected users to avoid configuring their CI tools to have multiple workers doing the same work simultaneously in the same shared repo
[23:36] <spiv> jelmer: e.g. no share a repo between build slavese.
[23:44] <poolie> o/ spiv, jelmer, all
[23:46] <Kamping_Kaiser> o.0
[23:46] <Kamping_Kaiser> er, echan
[23:48] <jelmer> spiv: ah, thanks
[23:48] <jelmer> g'morning poolie