stewarthi! 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
spivstewart: "bzr merge FOO ; bzr revert ."00:00
spiv(Then commit, of course)00:01
stewartspiv, awesome!00:01
stewartspiv, it's obvious now that i think about it :)00:02
spmo/ spiv00:07
_habnabithow can I unset pending merge tips?02:07
_habnabitspecifically, 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 files02:09
spiv_habnabit: bzr revert --forget-merges02:20
_habnabitthat'll only forget the merges and nothing else?02:21
spivAs the help says "Remove pending merge marker, without changing any files."02:22
_habnabitokay, thanks.02:22
Kamping_Kaiserhttp://paste.debian.net/134214/ can this issue be trivially resolved (a rich root conversion somehow?) or do i have to rebranch?02:53
spivKamping_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)02:58
Kamping_Kaiserspiv: thanks, i'll give it a crack. the error made it seem much more complicated then that03:05
Kamping_Kaiserlightning fast conversion, thanks03:06
AuroraBorealisdarn, gz isn't here >.>03:08
_habnabitbzr 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:09
_habnabitis there a fix for this?03:10
=== mwhudson_ is now known as mwhudson
=== idnaria is now known as idnar
vilahi all !06:12
vilapoolie: care to unblock https://code.launchpad.net/~vila/bzr/861472-migrate-log-format/+merge/77570 ?06:12
cineramahi vila, can i get you to do me a favour?06:13
vilacinerama: hehe, probably, but ask first :)06:19
cineramavila: i need help testing a french tollfree number.  i can't dial it from here :)06:20
vilacinerama: yeah, that make sense (they are often restricted to local callers)06:21
cineramavila: i'll just msg you the number if that is OK?06:21
AuroraBorealishmm, when does mgz get on? o.o06:22
vilaAuroraBorealis: give him an hour06:26
AuroraBorealismight be in bed then >.>06:27
pooliehi vila06:31
AuroraBorealisalso: it seems that if you interrupt any fast-import06:33
AuroraBorealisand then try to resume it, you hit this bug: https://bugs.launchpad.net/bzr/+bug/54162606:33
ubot5Ubuntu bug 541626 in Bazaar "'BTreeBuilder' object has no attribute '_find_ancestors'" [High,Triaged]06:33
AuroraBorealisthat would seem very annoying if you have to restart the entire import cause of a bug o.o06:38
vilapoolie, jelmer : _o/06:41
=== Ursinha is now known as Ursinha-afk
jammorning vila, jelmer07:12
jamand poolie, if you're still around07:12
pooliehi jam, i'm still here07:13
=== Ursinha-afk is now known as Ursinha
mgzmorning all08:00
pooliehi mgz08:00
jelmerpoolie, jam: What do you think about landing colocated branch support in an experimental format?08:06
jelmerthat way we can polish the UI and actually have it tested, before we decide we're happy with the format change.08:07
jamjelmer: sounds reasonable to me. My main concern was having a semi(poorly?)-supported default format08:07
jelmeronce we're happy we can backport the format change to 2a08:07
jelmerjam: cool08:09
vilajelmer: 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:16
jelmervila: migration *should* be a matter of rewriting the format file08:17
pooliejelmer i'm sorry it's stalled08:32
pooliean experimental format seems like an ok step forward08:32
jelmercool, I'll have a look at getting it into an experimental format08:37
nigelbBzr is behaving weirdly08:40
nigelbI did a bzr push to an LP branch. Its taking forever.08:40
jelmernigelb: ... bizarrely, would you say?08:40
nigelboh bah. Nevermind.08:41
* jelmer wonders if he can collect a prize for being the 1 millionth person to make that pun08:41
jelmernigelb: what was it?08:41
nigelbjelmer: Normally I just create a new branch, which I think is faster because of stacking.08:42
nigelbThis time I pushed a new branch to the top of an old branch08:42
nigelbAnd I forgot --overwrite08:42
mgzbb.test_branch.TestBranch.test_branch_broken_pack is a known random failure, right08:43
poolieok good night all08:44
jelmermgz: yes, though I thought it ought to be fixed now. Vincent landed something that should've fixed it recently.08:44
jelmerhave a nice evening poolie08:44
mgzvila: you landed the fix for the random fail on dev only?08:44
vilamgz: what random fail ?08:45
jelmervila: 6 lines up :)08:46
vilayeah, got that, but still doesn't ring a bell, searching the mps08:46
mgzbug 80703208:48
ubot5Launchpad 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/80703208:48
vilaha, that one ! Yes, apparently dev only08:49
vilamgz: do you encounter it for 2.4 ?08:49
mgzyup, just then.08:49
vilathat's the nice thing with spurious failures isn't it :-}08:49
vilamgz: do you want me to make a mp targeted at 2.4 ?08:50
* vila re-reads the mp... so I wasn't the only unlucky guy :-}08:51
mgzsec, just seeing when it originated08:51
vilanot sure I daggy-fixed that one :-/08:52
mgzyup, 2.4 only, 's from r595408:54
mgzokay, updated some bugs and created more work for the patch pilot :)08:59
* fullermd reckons that's the #bzr national sport.09:00
vilamgz: as in I should do a mp targeted to 2.4 ?09:01
vilamgz: or just submit it directly09:01
mgzI'd do an mp, but go ahead and land it.09:01
mgzjam already reviewed the change and it looks okay09:02
mgzwhy is blame saying "extracting 0/330/33" at me...09:44
mgzsomething progress bar-y has messed up again09:44
jelmervila: resubmitted metadir-goes-colo, with the metadir support in a new format09:57
vilajelmer: just got the mail, will review a bit later (~lunch)09:58
vilajelmer: you overwrote your previous proposal with https://code.launchpad.net/~jelmer/bzr/metadir-goes-colo/+merge/78221 ?10:32
vilajelmer: I can't find the previous one anymore 8-}10:33
jelmervila: true10:41
jelmervila: the previous one is pretty pointless though, it adds the colocated branch support in BzrMeta110:41
vilajelmer: sure, I just wanted to quickly re-read it10:42
vilajelmer: no big deal if you don't have one easy way to provide it10:42
vilashould be in my mail somewhere10:42
jelmervila: for the changes, up to r6091 in the same branch10:45
vilaha excellent10:45
jelmervila: for the mp and discussion: https://code.launchpad.net/~jelmer/bzr/metadir-goes-colo/+merge/7245110:45
vilajelmer: approved (under the assumption you'll wait for 2.5dev3, is that correct ?)10:57
vilajelmer: oh, and thanks for the pointers above, I used them !10:57
jelmervila: any particular reason you'd want me to wait for 2.5b3?11:00
vilajelmer: not really11:00
vilayour "beginning of the cycle" was ambiguous and I read it as 2.5b3,11:01
vilaand my RM hat had a knee-jerk reaction thinking about tomorrow's freeze,11:01
jelmervila: oh, I didn't realize I'd left that in there. I think I meant when 2.5 opened11:01
vilabut that's silly :)11:01
vilaargh, crossing messages :) I meant my knee-jerk reaction was silly11:02
jelmerah :)11:02
jelmervila: so you're happy to have it land now?11:02
jelmervila: great, thanks! :)11:02
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
vilareally lunch time now11:10
jmlI want to add boolean options to lp:udd's config12:12
vilajml: I've added them to bzr >= 2.5 :-/12:15
jmlvila: ahh. I see.12:15
jmlvila: I guess it would be nice to be running more recent versions of bzr on the production machine.12:16
vilajml: don' be cruel :-)12:16
vilajml: in the mean time, you should be able to get_user_option_as_boolean ?12:16
jmlvila: not from iconfig12:16
vilajml: gimme a se12:17
jmlvila: so far, I'm just doing config.get('option') == 'true'12:17
vilagood enough for you ?12:17
vilajml: who are the intended users ?12:18
jmlvila: me :)12:20
jmlvila: so it's ok for me12:20
vilacool :)12:20
vilasorry for the... compatibility issues :-/12:20
jmlvila: no worries.12:21
mgzvila: what's you're solution for getting paths out of envvars in config?12:22
vilamgz: hehe, glad you mention it :)12:22
vilamgz: env vars in config are used to provide default values12:23
vilamgz: so the plan is to have a specific option type for paths which can define how their corresponding env vars should be decoded12:23
mgzokay. and for things like BZR_LOG that don't go through config?12:24
vilamgz: make them go through config ?12:24
mgzdo we want a bottom level osutils.path_from_environment() ?12:24
vilathat certainly won't hurt !12:25
vilamgz: oh, let me guess, you're looking at bialix's bug about the unicode home dir ?12:26
mgzthat, and thinking about jelmer's blocked mp12:27
vilamgz: LOL12:27
vilaI was about to mention that too !12:27
mgzand looking at the current bb.test_version tests, which are, to put it mildly, a mess12:27
vilabut ff has quit (why ?) and I was waiting for it to refresh to paste the url :)12:27
vilamgz: +1 to clean them up, especially as a separate mp12:28
mgzokay, lunch, where I shall ponder further.12:28
vilamgz: briefly looking, they are very old and may even be redundant with other tests12:29
vilamgz: 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:33
vilabad jelmer12:36
vilain 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:36
vilao.O How did you manage that... I thought bzr add was complaining now when trying to add such a file...12:37
jmlthis code needs a little stylistic cleanup.12:39
jelmerjml: which code12:43
jelmervila: argh, looking now12:43
jelmerjml: ?12:43
vilajelmer: BB:tweak, the conflicts don't seem serious12:43
jmljelmer: lp:udd. Nothing major, just moving stuff that's in scripts into modules, making them import safe etc.12:43
jelmervila: the odd thing is that "bzr send -o - lp:bzr" doesn't show them12:44
vilajml: $deity bless you12:44
jelmervila: ah, it's a conflict.. nevermind12:44
jelmervila: dankuwelmerci!12:45
vilajelmer: of course ! *You* didn't bzr add ! lp is.... misleading12:46
jamvila: 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 so12:48
jamonly gentoo is 2days12hrs12:48
vilajam: feel free to dig the gentoo failures12:48
jamvila: yeah, it looks like gentoo is failing because it is timing out12:49
jambut at least it isn't hangnig12:49
jamthe failing tests look like they are all taking 8-14 seconds12:49
jamvila: 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:50
jamI don't know why they would be *legitamately* taking 14s12:51
jamthis 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
jamtook 14s12:51
jamrunning it here takes 738ms12:52
jamso about 20x slower on gentoo12:52
jamI could set the test suite timeout to 2 minutes, but I'm still curious why gentoo is taking that long12:52
jamhmm.. seems something else funny is going on as well. as the previous runs on gentoo were also under the 1s mark12:53
vilajam: 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 race12:54
MvGvila: Yesterday I got a mail from LP about you requesting a merge, but the linked page doesn't exist:12:57
MvGHave you somehow withdrawn the merge request or something like that, or is this a bug in LP?12:57
ubot5Ubuntu bug 78102 in libflash (Ubuntu) "[Merge Request] libflash 0.4.13-9 from debian unstable" [Wishlist,Fix released]12:57
vilaMvG: sorry about that, I deleted it after looking at it12:58
MvGWho's responsible for training ubot? The above doesn't make as much sense as one might expect.12:58
vilaMvG: and commented on the bug, short story: you've been bitten by 'bzr resolve --all' being... not what it seems12:59
MvGvila: OK, explains the missing page.12:59
jamMvG: yeah, ubot doesn't understand mp links12:59
MvGjam: 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
jamMvG: I really don't know much about it, but I agree with your point13:00
MvGvila: 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
ubot5Launchpad bug 842575 in Bazaar "Missing file reported after resolved removal conflict" [High,Confirmed] https://launchpad.net/bugs/84257513:01
jamMvG: https://wiki.ubuntu.com/IRC/Bots13:01
jamvila: 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:02
vilaMvG: 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 true13:03
vilajam: the slave is started if there is a run requiring it13:05
MvGjam: Wrote a line about the bot in #ubuntu-bots-team. Let's see.13:06
MvGvila: 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
MvGjam, vila: you need any test run on Gentoo?13:09
vilaMvG: internally the code is different13:09
jamMvG: 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
MvGvila: You mean the code for --all vs. a specific file?13:10
vilaMvG: that's why I didn't mark yours as a duplicate because even if they are related they are still different enough13:10
vilaMvG: yes13:10
MvGOK, I see.13:10
MvGwrt 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
ubot5Launchpad bug 842695 in Bazaar "log --include-merges apparently prints unrelated commits" [Undecided,Confirmed] https://launchpad.net/bugs/84269513:19
jamjelmer: the latest run of babune is about 2x slower than previous runs, and seems to only include your change13:19
jam6190 Patch Queue Manager       2011-10-04 [merge]13:19
jam     (jelmer) Add load_plugin_translations() function. (Jelmer Vernooij)13:19
jamDo you think that could affect test suite performance at all?13:19
jamIt doesn't seem like it should, so I'm suspecting something 3rd party13:20
jelmerjam: I'd be very surprised if that slowed things down13:20
jamvila: I'm trying to understand the duration things, like hree: http://babune.ladeuil.net:24842/job/selftest-chroot-maverick/241/testReport/history/?13:20
jamit says the test suite took 55 minutes13:20
jamhowever, the time listed here: http://babune.ladeuil.net:24842/13:20
jamfor selftest-chroot-maverick is only 7m59s13:21
jelmerjam: it just adds another utility function that only gets called by plugins, and has one test13:21
jamis one wall-clock time and the other is test-suite time?13:21
jamI 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/buildTimeTrend13:22
mullhi, 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:22
jammull: 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:23
jamHowever, it won't rewrite the history, so the older revisions of that new branch will be for the whole tree13:24
MvGjam: 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
jamIf 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-import13:24
vilajam: --parallel explains the difference13:24
jamvila: right, so the buildTimeTrend is wall-clock, and the test suite trend is the sum of times spent in each test13:25
mulljam -- ahh, fastimport sounds like the right thing.  yes, ideally I'd be rewriting the history13:25
jamvila: 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
jamAnd pretty much all of the runners I've checked show a significant slowdown in the last 1-2 runs13:26
jam(maybe you were using babune to do other work at the same time or something.)13:26
jamlike I *just* requested a full gentoo run, and it finished in wall-clock 7min57s, but the one that tried to run this morning took 24min13:27
mgzjam: re test timing discrepency13:59
mgzone number is how long it took from the starting the test suite to the finish14:00
mgzthe other is the sum of all test times14:00
mgzwhen forking, the first can be several times smaller14:01
jammgz: yeah, that's been sorted out.14:01
jami'm calling it 'wall clock' time vs test case time14:01
jamthe question is why did the last test runs across maverick natty, oneiric, gentoo, freebsd all suddenly take 2-4x longer than previous14:01
jamand when requesting a run of them manually, they drop back to their original time14:01
mgzhave you looked at the individual test timings?14:03
mgzare they uniformly or by and large slower?14:03
mgzor are there specific problem tests?14:04
jammgz: fast run just requested by me:http://babune.ladeuil.net:24842/view/Gentoo/job/selftest-gentoo/530/testReport/14:05
jammgz: slow run from a 12 hrs ago: http://babune.ladeuil.net:24842/view/Gentoo/job/selftest-gentoo/529/testReport/14:05
jamyou can sort of "duration"14:05
jamthe slowest subset is the same "test_commit_builder"14:06
jambut it goes from 5min to 19min14:06
jamtest_repository goes from 1m17s to 6m11s14:06
jamtest_controldir doesn't seem much affected14:06
jamtest_stacking is 1m6s to 4m40s, etc14:07
jamdigging into individual tests, you can no longer sort them by time14:07
jamhowever, if you open both in tabs and then switch between them, they should line up14:08
jamfor example: http://babune.ladeuil.net:24842/view/Gentoo/job/selftest-gentoo/530/testReport/bzrlib.tests.per_repository.test_commit_builder/TestCommitBuilder/14:08
jamsome tests are roughly the same time14:09
vilajam: have you looked at the dates and times ?14:09
jamI don't know whether "3ms" vs "34ms" is significant14:09
jamvila: across the board this seems to be the runs from this morning14:09
jam~12 hours ago14:09
jamthat are slower14:09
vilaif they all run at the same time then you've got your explanation no ?14:10
jamI haven't manually requested re-runs from anything but gentoo yet14:10
mgzbusy disk would have an effect something like that14:10
jamvila: the history trend doesn't seem to agree, wouldn't they all be starting at the same time over history?14:10
jammgz: on the TestCommitBuilder, this test test_commit_unchanged_root_record_entry_contents14:10
jamin its permutations is consistently 80ms vs 300ms14:11
jamnote that the Remote tests seem particularly affected14:11
jamgoing from .22s to 2.5s14:11
jamvila: 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:12
vilano idea14:13
vilajam: if the tests are not meant to cope with a server timeout, I think the server should not timeout for these tests14:19
vilabut that's just one more reason to use the real server... so feel free to ignore it too14:20
mgzlet's see what happens next auto build.14:20
james_wI'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:46
james_wbut I've seen that on a few UDD branches recently, so there is likely a bug somewhere16:47
=== yofel_ is now known as yofel
=== beuno is now known as beuno-lunch
jamjelmer: I just got a email bump from your mail host:17:13
jam"quota exceeded"17:13
jelmerjam: oops, I'll delete some more mail17:14
jelmerjam: thanks for letting me know17:14
jamjelmer: I was replying to your revision_history change, which I thought I had already commented on17:21
jamdid you resubmit it/17:21
jamthe issue is that it is ~ just moving the O(history) code into all the calling locations, rather than having them not actually doing it17:24
jami'm trying to think of a happy medium where we don't add new callers17:24
jambut we keep the bad code in one place, rather than putting it in lots of places in the code17:24
jelmerjam: there is only one place where we use it outside of the testsuite, and that's in revisionspec17:31
jamjelmer: what do you think about a separate function (not a Branch method) to consolidate the code, and make it easy to find?17:42
=== beuno-lunch is now known as beuno
jelmerjam: I'm not sure that's actually necessary, it's just 6 calls to iter_lefthand_ancestry in the testsuite, all with known small histories18:03
jamsure, just more not having to repeat ourselves 6 times18:03
jelmerjam: fair enough18:15
SebbohHi. 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:21
jamjelmer: anyway, it isn't critical, if you feel its too much work, I mostly wanted to discuss it a bit, since it seemed odd18:33
jelmerSebboh: hi19:20
jelmerSebboh: I'm not sure, it seems to work fine here with reasonable resource usage19:20
jelmerSebboh: are you actually running out of memory or does that just happen to be the error message you're getting?19:20
SebbohJelmer: I'm not running out of system memory.  But bzr.exe is 32bit.  http://pastebin.com/rXTq6fcg19:59
SebbohI switched away from the cygwin bzr, I'm using 2.5b1 (standalone installer) from http://wiki.bazaar.canonical.com/WindowsDownloads now.20:00
jelmerhi bpierre20:06
jelmerSebboh: ah :-(20:06
jelmerjam: 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.20:07
=== jam2 is now known as jam
Sebbohjelmer, 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:04
SebbohI 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.)21:05
SebbohSo 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:02
jelmerSebboh: that's odd, that revision isn't particularly big22:09
jelmercharis:/tmp/leo-editor% bzr log -r3086 -p | wc -l22:09
SebbohI was thinking, maybe it just happens to be the revision that pushed the repo over some threshold.22:10
SebbohI'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:11
jelmerSo bzr pull -r3085 works but -r3086 breaks?22:12
SebbohYes.  With my w ... Sorry, I have to go.22:12
Sebbohjelmer: http://pastebin.com/XKJ15pJR22:29
SebbohWork has been over for half an hour; bye! :)22:29
MarkAtwoodhi!  i occationally get an error that looks like this:22:59
MarkAtwoodbzr: 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
MarkAtwoodwhen 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 over22:59
MarkAtwoodthis is non-optimal23:00
MarkAtwoodis there a better way to check and repopulate a corrupted shared repo?23:00
jelmerMarkAtwood: please file a bug about this23:04
MarkAtwoodi jsut did23:04
MarkAtwoodi wish the repo wouldnt get corrupted23:04
MarkAtwoodbut if it does, it would be nice if there was a way to have the repo grab "missing stuff" from launchpad23:04
jelmerI think there's an open bug about having a command that can regenerate an index file23:07
jelmerbut indeed, the more interesting question is why that index is missing in the first place23:08
jelmerMarkAtwood: what's the bug #?23:08
MarkAtwoodheh, and i just closed that tab, too23:09
ubot5Ubuntu bug 868785 in Bazaar "occasional corrupted shared reposatory" [Undecided,New]23:09
MarkAtwoodwe run bzr under hudson, so it's constantly checking out the source of the project and rebuilding it23:10
MarkAtwoodso bzr branch is running many many times a day on many machines23:10
MarkAtwood(which is why it uses a shared repo, to cut down on network traffic)23:11
MarkAtwoodwhen this happens, that jenkins node "jams"23:11
jelmerI'm not too familiar with the repository internals but hopefully one of the other devs will have an idea tomorrow23:13
MarkAtwoodthank you jelmer23:14
spivjelmer: sounds like it may be the same issue the Twisted folks saw under buildbot23:33
spivjelmer: that simultaneous pulls of identical updates into a shared repo can cause symptoms like that: deleting an index file that's needed, etc.23:34
spivjelmer: it's probably possible to at least provide a repair tool to just drop the missing pack/indices from pack-names23:35
spivjelmer: but of course it'd be good to fix the root cause.  jam has a thorough understanding of the issue I believe23:35
spivjelmer: the workaround for affected users to avoid configuring their CI tools to have multiple workers doing the same work simultaneously in the same shared repo23:36
spivjelmer: e.g. no share a repo between build slavese.23:36
poolieo/ spiv, jelmer, all23:44
Kamping_Kaiserer, echan23:46
jelmerspiv: ah, thanks23:48
jelmerg'morning poolie23:48

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