[00:00] well yeah you're right, actually it'd be pretty simple to just alias a command to do that after the update [00:01] good morning [00:02] still..beats versioning mysql db [00:03] should the sqlite db even be in bzr? [00:04] well it doesn't need to be, but then you'd have to move it around separately with each update [00:04] bob2: no particular reason not do [00:04] bob2: and if it is tied to source code, good reasons to do so [00:06] I could also just move the fixtures, but that creates some more tedium then for each rev [00:06] and tedium is ..tedious;) [00:08] poolie: ping [00:08] hello [00:08] perfect timing, hi jml [00:08] and james_w and ilfeless [00:09] poolie: hi :) [00:12] hi poolie jmll AfC etc ;) [00:14] lifeless: hi :) [00:15] so, jml, do you want to talk about my breakfast? (brocolini and eggs) or something else? [00:16] poolie: your format naming patch didn't land. [00:16] we're looking for an adjective that says 'do not use unless you have read the docs' [00:17] for the 2.0 format command line option name [00:17] [this is not why it failed to land] [00:18] :) [00:19] I offer "runcible". [00:19] I think 2a won't provoke this because users are not /used/ to dealing with distributed databases [00:19] [and those users that are are probably in the 'clueful' set already] [00:19] alternatively, "alpha". [00:19] rubicund [00:21] moin *.{au,nz} [00:22] "A runcible spoon is a utensil suitable for runciation. This of course is in contrast to an irruncible spoon, which one runciates at one's peril" [00:22] Hm, 'zat mean I'm on {au,nz} time today? [00:22] jelmer: hello. [00:22] fullermd: no idea :) [00:23] * fullermd feels so cosmopolitan. [00:23] lifeless: Good morning Robert [00:25] jml, lifeless, so let's think about this in updating a document about how formats work [00:25] Obviously, the correct answer is "Schrodinger's 2" :p [00:25] for now, i'll resubmit that branch [00:25] poolie: with the syntax error fixed, yes? [00:26] :) [00:35] james_w: have you seen this before: [00:35] tar: ./usr/bin/smbtorture: file changed as we read it [00:36] ouch [00:36] no [00:36] what operation was that? [00:36] I keep getting that from bzr builddeb now all of a sudden [00:36] could you pastebin the output please? [00:37] http://pastebin.ubuntu.com/193851/ [00:37] that's the tail of the output [00:37] it seems to work sometimes, in particular if I haven't run bzr builddeb in a while [00:37] ouch [00:38] but if I run it, fix something and then run it again it seems to always feel this way [00:38] I wonder if something isn't getting killed or similar [00:38] s/feel/fail/ :-) [00:38] heh [00:38] you ^C it? [00:39] no [00:40] I'll try outside of bzr-builddeb, perhaps it's unrelated [00:40] lifeless: yesterday you said you were surprised that the fix I did needed a client-side change. [00:40] jml: I am [00:40] lifeless: would you be able to look at the patch and tell me if you spot a way to avoid it? [00:40] jml: is your branch up to date, I'm pulling [00:40] Hopefully a quick question: Is it possible to do a branch or checkout in to the current directory ? Providing '.' as the target to branch resulted in an error that the directory already existed (bzr: ERROR: Target directory "." already exists. |) [00:41] rchady: you can 'bzr checkout .' to create a tree where a branch already is [00:41] rchady: but you can't make a branch where one already is [00:41] lifeless: it is. r4433 in trunk. [00:42] but why does it complain about "." rather than ".bzr/branch" [00:42] ? [00:42] I'm not super familiar with bzr so please bear with me -- I have a remote repo I want to check out to my current directory. [00:42] SamB: because .bzr/branch is internals and not useful [00:42] I was trying: bzr branch . [00:42] rchady: is the current directly already bzr controlled? [00:42] well, in that case, it could complain "you already have a branch here" [00:42] no [00:42] not complain about "." [00:43] SamB: you could file a bug or a patch perhaps [00:43] it specifically complains about the directory "." already existing, see? [00:43] rchady: so bzr branch does a mkdir of the output directory [00:43] personally, I suspect the error message corresponds with why it's failing [00:44] rchady: is there any reason you can't just remove the directory you're in and do bzr branch ? [00:44] it is my home directory... so yeah [00:44] rchady: ok. In that case you're probably best off doing 'bzr init' then 'bzr pull' [00:45] Ok [00:47] I'm hoping to be able to manage my home dir with bzr.. we'll see, heh. [00:47] I have way too many logins on way too many disjoint, remote systems.. hoping to be able to make that a bit easier. [00:48] I had made a rpm for my home directory, but that is rather rigid for making changes on the fly [00:48] yo jelmer, can i bother you with a weird bzr-svn merging problem? === Kissaki is now known as Kissaki^0ff [00:49] jdub: hey [00:49] sure [00:50] jelmer: merging two branches of the same svn tree results in conflicts on some files [00:50] i can either describe how to do it [00:50] or upload an example somewhere ;) [00:51] (i have a number of branches of wordpress svn in a bzr repo, trying to merge 2.8 into 2.7...) [00:51] jdub: Are those branches public? [00:52] I think they're public if he was gonna describe how to do it? [00:52] i haven't put htem anywhere useful yet, but i can make a tarball of my freshly-reproduced repo for download [00:53] 38M bz2 [00:53] jdub: That'd probably be the easiest way for me to reproduce it. [00:53] msged you a download location [00:54] in that repo there's branches fro "trunk", svn branches "2.7" and "2.8", and the attemped "merge" of 2.8 into 2.7 [00:55] (with resultant conflicts) [00:55] i thought this could have been messy long-lived branches, but i reproduced it immediately with fresh repo+branches [00:56] jdub: the merge was created simply by "bzr branch 2.7 merge; cd merge; bzr merge ../2.8" ? [00:56] yeah [00:56] oh, and those were done with bzr stable ppa packages on hardon [00:56] but i got the same result with bzr beta ppa packages on jaunty [00:58] it looks like there are a lot of cherry picks between those two branches [00:59] yeah, that seems to be the main source of the conflicts [01:01] bzr doesn't recognize that some of the commits in the two branches actually contain the same changes, and if there were other independent changes to that area of code as well that causes conflicts [01:01] Are there any merge tools for Bazaar? [01:01] jdub: We can't do much about this unfortunately until Bazaar starts supporting cherrypick tracking. [01:04] jelmer: boh! [01:04] jdub: are you getting huge conflicts? [01:04] jdub: try --reprocess [01:04] lifeless: not huge ones, just lots [01:04] hello jdub [01:04] yeah, tried --reprocess and some of the other merge strategies [01:04] jdub: are they jen-u-wine? [01:04] jml, what happened with bug 284038? [01:04] Launchpad bug 284038 in bzr "push should warn about uncommitted changes" [Medium,Fix committed] https://launchpad.net/bugs/284038 [01:05] difference of between 50 and 44ish conflicts [01:05] yo poolie [01:05] poolie: there's an outstanding review [01:05] regand regarding bug 385453, i think it's ok to slip it, but we should be extra careful that the files are included in the tarball and deb [01:05] Launchpad bug 385453 in bzr "make dist should fail if C files don't exist or can't be built" [Medium,Triaged] https://launchpad.net/bugs/385453 [01:05] vila didn't do it overnight? [01:05] ok [01:06] poolie: yeah. extra care will be taken. [01:07] lifeless: they do look like the kinds of things that would be cherry-picked [01:07] jdub: and they are different on both sides? [01:10] poolie: btw, I'll get the release going as soon as your format patch lands, or as soon as you tell me you're not going to land it. [01:11] i'm distracted by other bugs [01:11] which are less important [01:11] * poolie gets undistracted [01:14] it's in pqm now [01:14] jelmer: thanks, i feel comfier knowing i'm not an idiot, and that this is not an unknown condition (the bug, not my idiocy, which is legend) [01:14] poolie: thanks. [01:15] jdub: crikey mate! [01:16] jdub: fwiw if these are cherrypicks, merging more often may reduce their impact. [01:16] jdub: also, you could try merge --weave [01:16] lifeless: tried weave and lca [01:16] yeah, trouble is that this is wp 2.7.1 -> 2.8 [01:17] even merging trunk had the same issue [01:17] would rebase trickery help at all? [01:18] jml, i submitted it to trunk, i can send it to 1.16 too [01:18] jdub: I don't think so. [01:18] (btw, this is all theoretical now, as i worked around it -> my changes were usefully separate from the core code) [01:18] jdub: in theory this is whats happened [01:18] also, jam suggested just dropping development7 now [01:18] poolie: I reckon I'll just merge trunk into 1.16 once that lands. [01:18] left side: ... patch A [01:18] right side: ... patch A(cherrypicky) .... change to B [01:18] per file merge bases might help [01:19] but we don't track per file cherrypicks either yet even when the file ends up fully merged [01:19] poolie: r4435 and r4436 are simple and valuable. [01:19] clearly the wordpress dudes need to be encouraged to shift away from svn ;-) [01:21] anyhow, lca etc don't see the patchA's as the same, so the change from A-cherrypicked to B doesn't supercede the other side ending up on A [01:22] jdub: using a loom could help though by keeping your changes logically distinct [01:22] jdub: and if you where using a solely rebase workflow where your patches 'float' on top of trunk then that too would permit bzr to not conflict [01:26] spiv, hi, good morning [01:27] poolie: good morning [01:35] jml, ok, just merging trunk makes sense [01:35] cool. [01:36] hm what do i do now then? read vila's patch probably? [01:36] spiv, what are you up to today? [01:39] poolie: I'm looking at ways to work around the "Launchpad won't work with Bazaar 1.15" issue. [01:39] poolie: Well, I'd appreciate eyes over that revno/rev-id stuff :) [01:41] lifeless: have you had a chance to look at it yet? http://paste.ubuntu.com/193874/ has the relevant diff. [01:42] jml: I was updating local copies and context switched [01:42] lifeless: understood :) [01:43] what is that pastebin for? [01:43] it's the patch that I landed w/ both client- & server-side changes. [01:44] http://paste.ubuntu.com/193874/ ? is not. [01:44] lifeless: oh, my bad. [01:44] You may have wanted it to be. [01:44] poolie: finishing my patch for VFS-free "bzr pull -r123 $stacked_smart_url" [01:44] poolie: after that... not sure, probably reviewing. [01:45] lifeless: I meant '-c' not '-r' [01:45] (if there's approval-in-concept of both patches, I may have time this weekend to try resolving jam's changes to both and make one combined patch) [01:46] poolie: also, filing a bug against LP code reviews :) [01:54] spiv, you have heaps of approved patches [01:54] small heaps at least :) [01:55] jml, it passed all tests in non-ascii mode [01:55] so it should be ok now [01:55] \o/ [01:56] spiv, what do you think about just landing the patch you originally put up for bug 109143 [01:56] Launchpad bug 109143 in bzr "hpss does not support ~ (tilde) for home dir access on bzr:// or bzr+ssh://" [High,In progress] https://launchpad.net/bugs/109143 [01:58] poolie: I don't think it'll be very hard to do it better (i.e. your way), just a matter of finding a half-day or so... perhaps I should JFDI today or Monday? [02:01] probably [02:01] i really think we should finish up outstanding stuff [02:01] one way or the other [02:02] so ... anyone have any idea why bzr-bisect doesn't have a "skip" subcommand? [02:04] spiv: if I wanted to disable the InitializeEx verb for 1.15 clients, could I somehow register a new request handler in its place that checks the 'Software version' header and then either forwards to the real or raises some sort of exception? [02:04] spiv: by which I mean, what's the best approach for disabling the InitializeEx verb for 1.15 clients? :) [02:04] Why does bzr ask me to merge when I do 'bzr up'? [02:05] GungaJin: you have locall commits [02:05] I just want to move to a different revision. [02:05] you didn't get them merged upstream [02:05] jml: I'm not sure if the header is being passed along to the request-handler [02:05] hmmm... not that I'm aware of. [02:05] How do I check where they are? [02:05] bzr missing [02:05] spiv: ahh, suck. [02:06] bzr status? [02:06] jml: probably not hard to fix, but [02:06] should show you commits on both sides [02:06] spiv: where would I have to hook in then? [02:06] jml: maybe we ought to remove the verb entirely and replace it with a new one with a slightly different name? [02:06] spiv: you mean in 1.16? [02:07] e.g. BzrDirFormat.initialize_ex_1.16 or something. [02:07] Right. [02:07] rather than an LP compatibility kludge [02:07] GungaJin: there's also a slight possibility that upstream rebased, though they really shouldn't ... [02:08] bzr missing didn't work. [02:08] I can see that working. [02:08] It seems a shame to penalise clients when there's no stacking involved, but on the other hand the offending verb has only been in one release. [02:08] GungaJin: what'd it say? [02:09] "bzr: ERROR: No peer location known or specified." [02:09] spiv: could you please do that for me? I'd wager you'll be able to do the right thing much faster than I. [02:10] jml: which one? I don't have a strong feeling on which solution to take... [02:11] spiv: out of the concrete solutions I've heard so far, I think renaming the verb sounds the least bad. [02:12] ok, so i think i'll take over bug 284038 and try to finish vila's changes [02:12] spiv: do you agree? [02:12] Launchpad bug 284038 in bzr "push should warn about uncommitted changes" [Medium,Fix committed] https://launchpad.net/bugs/284038 [02:12] jml: so were you going to paste the actual diff? [02:12] it would be nice to do for this release but imo it should not stall the release [02:12] renaming the verb sounds fairly clea [02:12] n [02:12] lifeless: I pastebinned it, but forgot the url -- sorry. http://paste.ubuntu.com/193877/ [02:13] jml: I guess I do lean that way. I wonder if lifeless will have any insights now that he's got your diff... [02:14] jml: what happens if you don't change bzrlib/bzrdir.py [02:14] jml: it looks to me like that was a first approximation fix and likely unneeded [02:14] lifeless: it tries to evaluate the stack_on as local path [02:15] jml: what are the tests to run [02:15] lifeless: yeah, i should start using looms [02:16] ./bzr -Dhpss --no-plugins selftest -Eallow_debug -s bb.test_push push_smart_with_default_stacking [02:17] $ ./bzr -Dhpss --no-plugins selftest -Eallow_debug format_initialize_on_transport_ex [02:20] ok [02:20] stack_on_pwd in UseExistingRepository is essentially required to be an abspath [02:21] if its a relpath its considered relative to . [02:21] I don't see any way around it [02:21] I'm inclined to issue a 1.15.2 [02:21] what did intrepid ship? [02:22] * 1.6.1-1: amd64 i386 [02:22] lifeless: jaunty has 1.13.1 [02:22] (https://launchpad.net/ubuntu/+source/bzr) [02:22] oh right, i, J, k [02:23] yeah. I'd ship a 1.15.2 with this patch cherrypicked [02:23] rather than renaming the verb? [02:23] or version the verb [02:23] jml: one or other; whoever is doing the work can choose IMO [02:24] cool. [02:24] It's a great opportunity to s/_ex/1.16/ , which must be a good thing ;) [02:24] spiv: Don't drop the _ex please [02:24] spiv: because the method is _ex [02:24] lifeless: yeah, I know, just trolling. [02:25] lifeless: see above where I suggested "BzrDirFormat.initialize_ex_1.16" [02:25] spiv: would you mind doing the version bump then? [02:25] jml: sure, I'll put that together for you now. I should do it on the 1.16 branch I suppose... [02:25] spiv: actually against trunk is still fine [02:26] jml: oh, they are the same? [02:26] Convenient. [02:26] spiv: trunk has a revision or two that I'm going to pull in :) [02:26] (Also, lp:bzr/1.16 doesn't work yet) [02:26] ta [02:26] I knew I forgot something last night. [02:27] oh, isn't 1.16 hosted on lp? [02:27] that was a goal for it [02:27] spm: ping [02:27] lifeless: pong [02:27] lifeless: we arranged the PQM set up in the dead of night. [02:28] jml: oh [02:28] jml: I thought the branch was made a while back... shrug [02:28] spm: I _really_ want to get pqm and lp talking [02:28] lifeless: they are, aren't they? [02:28] spm: its very important. RT was filed. I know you are poking at it from time to time, but how can we get it into 'poke until it works' mode? [02:29] 18:09 < spiv> spm: yep, lp: URL in merge request still vanishing without a trace. I'm going to workaround it with http:// again. [02:29] jml, on consideration i don't see bug 284038 as sufficiently urgent for me to steal it from vila [02:29] Launchpad bug 284038 in bzr "push should warn about uncommitted changes" [Medium,Fix committed] https://launchpad.net/bugs/284038 [02:29] so i suggest we just slip it [02:29] and let him finish it tomorrow or watever [02:29] poolie: cool. :) [02:29] whatever* [02:30] spiv: I'm not sure that lp: urls will be opened through the right codepath to do resolution; bzr+ssh please [02:30] lifeless: ARRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGHHHHHHHHHHHHHHHHHHHHHHHH! /me expresses mild frustration [02:30] spiv: or did you mean bzr+ssh failed? [02:30] spiv: and if it fails please don't change to http, lets debug and fix. small red button time. [02:31] lifeless: last time we fixed, was due to the authentication.conf getting a busticated version. *somehow* - unknown as yet, that old and busted was put back. I'd since added a ro file to stop the behaviour from repeating. [02:32] spm: *interesting* [02:32] spm: did you document it last time, to avoid other sysadmins running lp-login? [02:32] lifeless: I meant what I said; I tried an lp: URL, I wasn't aware I should avoid them. [02:32] spiv: I'm not sure that you should. [02:32] lifeless: emailed them of the issue/solution, but not the lp-login - is that what creates that file? cause that's a Big Clue to me. [02:32] spiv: but lets start with bzr+ssh [02:33] spm: lp-login creates it. (I did in fact detail this for you at the time). [02:33] 'k [02:34] given the values that go in there, that helps me narrow it down to possibilities. something in that other (unused) build/setup going awry. [02:34] lifeless: I'm typically in favour of stop-and-fix, but delaying the release for my patch seemed like a worse option... [02:35] I hear its traumatic when one starts [02:41] jml: bug 76616 did you look into the claim of a bad merge? [02:41] Launchpad bug 76616 in bzr "confusing message about ignored files on add" [Low,Fix released] https://launchpad.net/bugs/76616 [02:42] no, I didn't. [02:42] jml: I think you should, or change the status down to fix committed [02:51] jml: rename patch submitted [02:52] jml: (for review) [02:52] spiv: thanks. [02:53] jml: I haven't run the full test suite, but relevant subsets seem happy, and the grep output looks sane. [02:55] poolie: http://www.overcomingbias.com/2009/06/why-yes-men.html [02:57] I'm going into deep hack mode on check [02:57] two days of bugs and writing have driven me battty [02:57] SMS or ring to get my attention [02:59] poolie: can you please review https://code.edge.launchpad.net/~spiv/bzr/rename-init_ex-verb/+merge/7366 [02:59] poolie: I've had a look & I think it's good, but would appreciate the double check. [03:12] wilco [03:16] done [03:16] poolie: thanks [03:18] poolie: yeah, it seems to work fine against an older server (lp, which is in fact 1.14 I think?) [03:18] yep. [03:19] the other check is 1.15 client vs dev server [03:20] jml: that'll fallback in precisely the same way that 1.15 does against 1.14 (i.e. LP) now [03:20] oh of course :) [03:20] spm: so, should I try lp: or bzr+ssh: URLs on PQM again? [03:21] spiv: I would yes. the fix from last time is still in place so *hopefully* it'll all work... [03:21] spm: ok, will let you know shortly :) [03:22] heh [03:22] spm: ok, it's on PQM now... let's see what happens. [03:22] * jml afk for a bit. [03:23] spm: and at 02:23:04 it disappeared. [03:23] * spm swears, sighs, and starts looking [03:24] spm: that was with a lp: URL. [03:24] I think I'm gunna cry. [03:24] [Errno 13] Permission denied: '/home/pqm/.bazaar/authentication.conf' [03:24] \o/ [03:24] [machine crashed] spiv please try bzr+ssh [03:24] spiv: and don't try lp: until bzr+ssh are working [03:24] lifeless: given the above error, I don't think bzr+ssh would help :) [03:25] spiv: if lp: is trying to write to it, bzr+ssh probably won't [03:25] I'd agree. I need to find out what's doing the lp-login and terminate with prejudice. [03:26] spiv: specifically I *do* think it will help. [03:28] lifeless: well, spm is the one driving the debugging, so I'll happily do what he asks. [03:30] spiv: ha! if lifeless reckons it'll work, I'm happy to let you try? :-) [03:30] here are my thoughts [03:31] lp: is special. pqm might not use the right apis. it might need firewall ports opened. [03:31] bzr+ssh will let us be sure that the ssh aspect is working [03:31] we should get bzr+ssh working for source branches before trying lp at all. [03:32] Submitting bzr+ssh merge request. [03:32] that way, if lp: requires more stuff, or indeed is even breaking things, we'll be able to diagnose that directly. [03:33] spiv: that looks to be working! [03:34] Yeah. [03:35] another data point [03:35] so what is it about the LS pqm stuffo that causes the auth stuff to foobar bzr pqm. /rhetorical [03:35] as we won't be doing lp-login with the current plan, and http:// doesn't have a smart server, using lp; urls will be slower. [03:35] so even if lp urls work, we shouldn't use them. [03:37] well it's warmed up to a balmy 2degC here, so time to get outside and have some lunch in the sunshine! bbs. [03:39] lifeless: that's a shame, because I'd prefer to have lp URLs as my public_location in locations.conf. [03:41] spiv: I agree, and I think we should work up to that [03:41] Also, I don't care much about the speed of HTTP within the data centre. [03:42] :P [03:45] Especially compared to the speed of running the test suite twice ;) [03:45] well [03:45] parallel++ [03:46] Yeah, using more cores if they're there is certainly a good idea. [03:46] the C check has saved my bacon way too often [03:46] ok lappie seems stable again. -> deep hacking. [03:47] It would be interesting to have stats on the tests that PQM most commonly trips on. [03:47] oh, one lsat thing [03:48] igc: I think my command hooks patch is blocked on your replying to my reply to your review. [04:06] lifeless: Hey, is there a way to regenerate the indices? [04:06] I'm getting an odd error: bzr: ERROR: Error in data for index GraphIndex('file:///home/ted/Development/inkscape.newbzr/.bzr/repository/indices/1d2b8fb37e32a1e94a733fbc3d195756.tix'). [04:12] tedg: I haven't seen that error before... [04:12] * tedg seems to have special skills in breaking bazaar :( [04:22] tedg: off the top of my head I don't think it's possible to regenerate a .tix. I certainly don't know of any convenient tools to do it. [04:22] tedg: which repo format? pack-0.92? [04:23] spiv: What ever is default in the nightlies plus rich-root-pack. [04:23] * spiv nods [04:23] tedg: file a bug; we'll need to write a repair tool to regen the index for you. [04:24] tedg: the index is zlib'd data [04:24] lifeless: What should be in the bug, just that single tix file or the whole repo? [04:24] tedg: its mostly (but not entirely) derivable from what you have on disk [04:25] tedg: the one tix which may let us repair it depending on the damage. [04:25] tedg: and this conversation probably [04:25] I mean, I'm just trying to get a checkout from SF SVN -- but that takes days and this happened in the middle. [04:25] I can start the process over, I don't need that tix specifically. [04:25] I'm just trying to avoid starting over. [04:25] the way we could repair is to read the leaf pages only to get back the kys and values and then reoutput it. [04:26] tedg: if this occured during a fresh branch from svn, well check your hardware - you may have a disk or memory problem [04:26] lifeless: a little bit odd to get BadIndexError rather than a zlib error if it's bad hardware, though. [04:27] spiv: depends on the try's. [04:27] also we can look at the index once the bug is filed. [04:28] So, I guess I'm not 100% clear what I should attach to the bug. [04:28] 13:19 < lifeless> tedg: the one tix which may let us repair it depending on the damage. [04:28] 13:19 < lifeless> tedg: and this conversation probably [04:28] lifeless: Okay. [04:31] Why in God's name does Launchpad not understand a bzr:// URL?!? [04:34] Info attached to bug 386203 [04:34] Launchpad bug 386203 in bzr "bzr: ERROR: Error in data for index GraphIndex" [Undecided,New] https://launchpad.net/bugs/386203 [04:35] hi all [04:35] lifeless: it probably is blocked on that sorry [04:35] back [04:35] hi igc [04:36] AfC: God doesn't pay us. [04:36] lifeless: I've just woken up and feel like absolute crap so ... [04:36] I'll take a look Monday [04:36] jml: anything you need from me wrt the release? [04:36] igc: nope, you're all good. [04:36]