[00:00] <Gnx-> well yeah you're right, actually it'd be pretty simple to just alias a command to do that after the update
[00:01] <jml> good morning
[00:02] <Gnx-> still..beats versioning mysql db
[00:03] <bob2> should the sqlite db even be in bzr?
[00:04] <Gnx-> well it doesn't need to be, but then you'd have to move it around separately with each update
[00:04] <lifeless> bob2: no particular reason not do
[00:04] <lifeless> bob2: and if it is tied to source code, good reasons to do so
[00:06] <Gnx-> I could also just move the fixtures, but that creates some more tedium then for each rev
[00:06] <Gnx-> and tedium is ..tedious;)
[00:08] <jml> poolie: ping
[00:08] <poolie> hello
[00:08] <poolie> perfect timing, hi jml
[00:08] <poolie> and james_w and ilfeless
[00:09] <jml> poolie: hi :)
[00:12] <lifeless> hi poolie jmll AfC  etc ;)
[00:14] <jml> lifeless: hi :)
[00:15] <poolie> so, jml, do you want to talk about my breakfast? (brocolini and eggs) or something else?
[00:16] <jml> poolie: your format naming patch didn't land.
[00:16] <lifeless> we're looking for an adjective that says 'do not use unless you have read the docs'
[00:17] <lifeless> for the 2.0 format command line option name
[00:17] <lifeless> [this is not why it failed to land]
[00:18] <jml> :)
[00:19] <jml> I offer "runcible".
[00:19] <lifeless> I think 2a won't provoke this because users are not /used/ to dealing with distributed databases
[00:19] <lifeless> [and those users that are are probably in the 'clueful' set already]
[00:19] <jml> alternatively, "alpha".
[00:19] <poolie> rubicund
[00:21] <jelmer> moin *.{au,nz}
[00:22] <jml> "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] <fullermd> Hm, 'zat mean I'm on {au,nz} time today?
[00:22] <jml> jelmer: hello.
[00:22] <jml> fullermd: no idea :)
[00:23]  * fullermd feels so cosmopolitan.
[00:23] <AfC> lifeless: Good morning Robert
[00:25] <poolie> jml, lifeless, so let's think about this in updating a document about how formats work
[00:25] <fullermd> Obviously, the correct answer is "Schrodinger's 2"  :p
[00:25] <poolie> for now, i'll resubmit that branch
[00:25] <jml> poolie: with the syntax error fixed, yes?
[00:26] <poolie> :)
[00:35] <jelmer> james_w: have you seen this before:
[00:35] <jelmer> tar: ./usr/bin/smbtorture: file changed as we read it
[00:36] <james_w> ouch
[00:36] <james_w> no
[00:36] <james_w> what operation was that?
[00:36] <jelmer> I keep getting that from bzr builddeb now all of a sudden
[00:36] <james_w> could you pastebin the output please?
[00:37] <jelmer> http://pastebin.ubuntu.com/193851/
[00:37] <jelmer> that's the tail of the output
[00:37] <jelmer> it seems to work sometimes, in particular if I haven't run bzr builddeb in a while
[00:37] <james_w> ouch
[00:38] <jelmer> but if I run it, fix something and then run it again it seems to always feel this way
[00:38] <james_w> I wonder if something isn't getting killed or similar
[00:38] <jelmer> s/feel/fail/ :-)
[00:38] <james_w> heh
[00:38] <james_w> you ^C it?
[00:39] <jelmer> no
[00:40] <jelmer> I'll try outside of bzr-builddeb, perhaps it's unrelated
[00:40] <jml> lifeless: yesterday you said you were surprised that the fix I did needed a client-side change.
[00:40] <lifeless> jml: I am
[00:40] <jml> lifeless: would you be able to look at the patch and tell me if you spot a way to avoid it?
[00:40] <lifeless> jml: is your branch up to date, I'm pulling
[00:40] <rchady> 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] <lifeless> rchady: you can 'bzr checkout .' to create a tree where a branch already is
[00:41] <lifeless> rchady: but you can't make a branch where one already is
[00:41] <jml> lifeless: it is. r4433 in trunk.
[00:42] <SamB> but why does it complain about "." rather than ".bzr/branch"
[00:42] <SamB> ?
[00:42] <rchady> 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] <lifeless> SamB: because .bzr/branch is internals and not useful
[00:42] <rchady> I was trying: bzr branch <remote repo> .
[00:42] <lifeless> rchady: is the current directly already bzr controlled?
[00:42] <SamB> well, in that case, it could complain "you already have a branch here"
[00:42] <rchady> no
[00:42] <SamB> not complain about "."
[00:43] <lifeless> SamB: you could file a bug or a patch perhaps
[00:43] <SamB> it specifically complains about the directory "." already existing, see?
[00:43] <lifeless> rchady: so bzr branch does a mkdir of the output directory
[00:43] <SamB> personally, I suspect the error message corresponds with why it's failing
[00:44] <lifeless> rchady: is there any reason you can't just remove the directory you're in and do bzr branch <dirname> ?
[00:44] <rchady> it is my home directory... so yeah
[00:44] <lifeless> rchady: ok. In that case you're probably best off doing 'bzr init' then 'bzr pull'
[00:45] <rchady> Ok
[00:47] <rchady> I'm hoping to be able to manage my home dir with bzr.. we'll see, heh.
[00:47] <rchady> 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] <rchady> I had made a rpm for my home directory, but that is rather rigid for making changes on the fly
[00:48] <jdub> yo jelmer, can i bother you with a weird bzr-svn merging problem?
[00:49] <jelmer> jdub: hey
[00:49] <jelmer> sure
[00:50] <jdub> jelmer: merging two branches of the same svn tree results in conflicts on some files
[00:50] <jdub> i can either describe how to do it
[00:50] <jdub> or upload an example somewhere ;)
[00:51] <jdub> (i have a number of branches of wordpress svn in a bzr repo, trying to merge 2.8 into 2.7...)
[00:51] <jelmer> jdub: Are those branches public?
[00:52] <SamB> I think they're public if he was gonna describe how to do it?
[00:52] <jdub> i haven't put htem anywhere useful yet, but i can make a tarball of my freshly-reproduced repo for download
[00:53] <jdub> 38M bz2
[00:53] <jelmer> jdub: That'd probably be the easiest way for me to reproduce it.
[00:53] <jdub> msged you a download location
[00:54] <jdub> 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] <jdub> (with resultant conflicts)
[00:55] <jdub> i thought this could have been messy long-lived branches, but i reproduced it immediately with fresh repo+branches
[00:56] <jelmer> jdub: the merge was created simply by "bzr branch 2.7 merge; cd merge; bzr merge ../2.8" ?
[00:56] <jdub> yeah
[00:56] <jdub> oh, and those were done with bzr stable ppa packages on hardon
[00:56] <jdub> but i got the same result with bzr beta ppa packages on jaunty
[00:58] <jelmer> it looks like there are a lot of cherry picks between those two branches
[00:59] <jelmer> yeah, that seems to be the main source of the conflicts
[01:01] <jelmer> 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] <GungaJin> Are there any merge tools for Bazaar?
[01:01] <jelmer> jdub: We can't do much about this unfortunately until Bazaar starts supporting cherrypick tracking.
[01:04] <jdub> jelmer: boh!
[01:04] <lifeless> jdub: are you getting huge conflicts?
[01:04] <lifeless> jdub: try --reprocess
[01:04] <jdub> lifeless: not huge ones, just lots
[01:04] <poolie> hello jdub
[01:04] <jdub> yeah, tried --reprocess and some of the other merge strategies
[01:04] <lifeless> jdub: are they jen-u-wine?
[01:04] <poolie> jml, what happened with bug 284038?
[01:05] <jdub> difference of between 50 and 44ish conflicts
[01:05] <jdub> yo poolie
[01:05] <jml> poolie: there's an outstanding review
[01:05] <poolie> 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] <poolie> vila didn't do it overnight?
[01:05] <poolie> ok
[01:06] <jml> poolie: yeah. extra care will be taken.
[01:07] <jdub> lifeless: they do look like the kinds of things that would be cherry-picked
[01:07] <lifeless> jdub: and they are different on both sides?
[01:10] <jml> 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] <poolie> i'm distracted by other bugs
[01:11] <poolie> which are less important
[01:11]  * poolie gets undistracted
[01:14] <poolie> it's in pqm now
[01:14] <jdub> 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] <jml> poolie: thanks.
[01:15] <lifeless> jdub: crikey mate!
[01:16] <lifeless> jdub: fwiw if these are cherrypicks, merging more often may reduce their impact.
[01:16] <lifeless> jdub: also, you could try merge --weave
[01:16] <jdub> lifeless: tried weave and lca
[01:16] <jdub> yeah, trouble is that this is wp 2.7.1 -> 2.8
[01:17] <jdub> even merging trunk had the same issue
[01:17] <jdub> would rebase trickery help at all?
[01:18] <poolie> jml, i submitted it to trunk, i can send it to 1.16 too
[01:18] <lifeless> jdub: I don't think so.
[01:18] <jdub> (btw, this is all theoretical now, as i worked around it -> my changes were usefully separate from the core code)
[01:18] <lifeless> jdub: in theory this is whats happened
[01:18] <poolie> also, jam suggested just dropping development7 now
[01:18] <jml> poolie: I reckon I'll just merge trunk into 1.16 once that lands.
[01:18] <lifeless> left side: ... patch A
[01:18] <lifeless> right side: ... patch A(cherrypicky) .... change to B
[01:18] <lifeless> per file merge bases might help
[01:19] <lifeless> but we don't track per file cherrypicks either yet even when the file ends up fully merged
[01:19] <jml> poolie: r4435 and r4436 are simple and valuable.
[01:19] <jdub> clearly the wordpress dudes need to be encouraged to shift away from svn ;-)
[01:21] <lifeless> 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] <lifeless> jdub: using a loom could help though by keeping your changes logically distinct
[01:22] <lifeless> 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] <poolie> spiv, hi, good morning
[01:27] <spiv> poolie: good morning
[01:35] <poolie> jml, ok, just merging trunk makes sense
[01:35] <jml> cool.
[01:36] <poolie> hm what do i do now then? read vila's patch probably?
[01:36] <poolie> spiv, what are you up to today?
[01:39] <jml> poolie: I'm looking at ways to work around the "Launchpad won't work with Bazaar 1.15" issue.
[01:39] <fullermd> poolie: Well, I'd appreciate eyes over that revno/rev-id stuff    :)
[01:41] <jml> lifeless: have you had a chance to look at it yet? http://paste.ubuntu.com/193874/ has the relevant diff.
[01:42] <lifeless> jml: I was updating local copies and context switched
[01:42] <jml> lifeless: understood :)
[01:43] <lifeless> what is that pastebin for?
[01:43] <jml> it's the patch that I landed w/ both client- & server-side changes.
[01:44] <lifeless> http://paste.ubuntu.com/193874/ ? is not.
[01:44] <jml> lifeless: oh, my bad.
[01:44] <lifeless> You may have wanted it to be.
[01:44] <spiv> poolie: finishing my patch for VFS-free "bzr pull -r123 $stacked_smart_url"
[01:44] <spiv> poolie: after that... not sure, probably reviewing.
[01:45] <jml> lifeless: I meant '-c' not '-r'
[01:45] <fullermd> (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] <spiv> poolie: also, filing a bug against LP code reviews :)
[01:54] <poolie> spiv, you have heaps of approved patches
[01:54] <poolie> small heaps at least :)
[01:55] <poolie> jml, it passed all tests in non-ascii mode
[01:55] <poolie> so it should be ok now
[01:55] <jml> \o/
[01:56] <poolie> spiv, what do you think about just landing the patch you originally put up for bug 109143
[01:58] <spiv> 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] <poolie> probably
[02:01] <poolie> i really think we should finish up outstanding stuff
[02:01] <poolie> one way or the other
[02:02] <SamB> so ... anyone have any idea why bzr-bisect doesn't have a "skip" subcommand?
[02:04] <jml> 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] <jml> spiv: by which I mean, what's the best approach for disabling the InitializeEx verb for 1.15 clients? :)
[02:04] <GungaJin> Why does bzr ask me to merge when I do 'bzr up'?
[02:05] <SamB> GungaJin: you have locall commits
[02:05] <GungaJin> I just want to move to a different revision.
[02:05] <SamB> you didn't get them merged upstream
[02:05] <spiv> jml: I'm not sure if the header is being passed along to the request-handler
[02:05] <GungaJin> hmmm... not that I'm aware of.
[02:05] <GungaJin> How do I check where they are?
[02:05] <SamB> bzr missing
[02:05] <jml> spiv: ahh, suck.
[02:06] <GungaJin> bzr status?
[02:06] <spiv> jml: probably not hard to fix, but
[02:06] <SamB> should show you commits on both sides
[02:06] <jml> spiv: where would I have to hook in then?
[02:06] <spiv> jml: maybe we ought to remove the verb entirely and replace it with a new one with a slightly different name?
[02:06] <jml> spiv: you mean in 1.16?
[02:07] <spiv> e.g. BzrDirFormat.initialize_ex_1.16 or something.
[02:07] <spiv> Right.
[02:07] <jml> rather than an LP compatibility kludge
[02:07] <SamB> GungaJin: there's also a slight possibility that upstream rebased, though they really shouldn't ...
[02:08] <GungaJin> bzr missing didn't work.
[02:08] <jml> I can see that working.
[02:08] <spiv> 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] <SamB> GungaJin: what'd it say?
[02:09] <GungaJin> "bzr: ERROR: No peer location known or specified."
[02:09] <jml> 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] <spiv> jml: which one?  I don't have a strong feeling on which solution to take...
[02:11] <jml> spiv: out of the concrete solutions I've heard so far, I think renaming the verb sounds the least bad.
[02:12] <poolie> ok, so i think i'll take over bug 284038 and try to finish vila's changes
[02:12] <jml> spiv: do you agree?
[02:12] <lifeless> jml: so were you going to paste the actual diff?
[02:12] <poolie> it would be nice to do for this release but imo it should not stall the release
[02:12] <mwhudson> renaming the verb sounds fairly clea
[02:12] <mwhudson> n
[02:12] <jml> lifeless: I pastebinned it, but forgot the url -- sorry. http://paste.ubuntu.com/193877/
[02:13] <spiv> 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] <lifeless> jml: what happens if you don't change bzrlib/bzrdir.py
[02:14] <lifeless> jml: it looks to me like that was a first approximation fix and likely unneeded
[02:14] <jml> lifeless: it tries to evaluate the stack_on as local path
[02:15] <lifeless> jml: what are the tests to run
[02:15] <jdub> lifeless: yeah, i should start using looms
[02:16] <jml> ./bzr -Dhpss --no-plugins selftest -Eallow_debug -s bb.test_push push_smart_with_default_stacking
[02:17] <jml> $ ./bzr -Dhpss --no-plugins selftest -Eallow_debug format_initialize_on_transport_ex
[02:20] <lifeless> ok
[02:20] <lifeless> stack_on_pwd in UseExistingRepository is essentially required to be an abspath
[02:21] <lifeless> if its a relpath its considered relative to .
[02:21] <lifeless> I don't see any way around it
[02:21] <lifeless> I'm inclined to issue a 1.15.2
[02:21] <lifeless> what did intrepid ship?
[02:22] <jml>     * 1.6.1-1: amd64 i386
[02:22] <spiv> lifeless: jaunty has 1.13.1
[02:22] <spiv> (https://launchpad.net/ubuntu/+source/bzr)
[02:22] <lifeless> oh right, i, J, k
[02:23] <lifeless> yeah. I'd ship a 1.15.2 with this patch cherrypicked
[02:23] <jml> rather than renaming the verb?
[02:23] <lifeless> or version the verb
[02:23] <lifeless> jml: one or other; whoever is doing the work can choose IMO
[02:24] <jml> cool.
[02:24] <spiv> It's a great opportunity to s/_ex/1.16/ , which must be a good thing ;)
[02:24] <lifeless> spiv: Don't drop the _ex please
[02:24] <lifeless> spiv: because the method is _ex
[02:24] <spiv> lifeless: yeah, I know, just trolling.
[02:25] <spiv> lifeless: see above where I suggested "BzrDirFormat.initialize_ex_1.16"
[02:25] <jml> spiv: would you mind doing the version bump then?
[02:25] <spiv> jml: sure, I'll put that together for you now.  I should do it on the 1.16 branch I suppose...
[02:25] <jml> spiv: actually against trunk is still fine
[02:26] <spiv> jml: oh, they are the same?
[02:26] <spiv> Convenient.
[02:26] <jml> spiv: trunk has a revision or two that I'm going to pull in :)
[02:26] <spiv> (Also, lp:bzr/1.16 doesn't work yet)
[02:26] <jml> ta
[02:26] <jml> I knew I forgot something last night.
[02:27] <lifeless> oh, isn't 1.16 hosted on lp?
[02:27] <lifeless> that was a goal for it
[02:27] <lifeless> spm: ping
[02:27] <spm> lifeless: pong
[02:27] <jml> lifeless: we arranged the PQM set up in the dead of night.
[02:28] <lifeless> jml: oh
[02:28] <lifeless> jml: I thought the branch was made a while back... shrug
[02:28] <lifeless> spm: I _really_ want to get pqm and lp talking
[02:28] <spm> lifeless: they are, aren't they?
[02:28] <lifeless> 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] <lifeless> 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] <poolie> jml, on consideration i don't see bug 284038 as sufficiently urgent for me to steal it from vila
[02:29] <poolie> so i suggest we just slip it
[02:29] <poolie> and let him finish it tomorrow or watever
[02:29] <jml> poolie: cool. :)
[02:29] <poolie> whatever*
[02:30] <lifeless> spiv: I'm not sure that lp: urls will be opened through the right codepath to do resolution; bzr+ssh please
[02:30] <spm> lifeless: ARRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGHHHHHHHHHHHHHHHHHHHHHHHH! /me expresses mild frustration
[02:30] <lifeless> spiv: or did you mean bzr+ssh failed?
[02:30] <lifeless> spiv: and if it fails please don't change to http, lets debug and fix. small red button time.
[02:31] <spm> 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] <lifeless> spm: *interesting*
[02:32] <lifeless> spm: did you document it last time, to avoid other sysadmins running lp-login?
[02:32] <spiv> lifeless: I meant what I said; I tried an lp: URL, I wasn't aware I should avoid them.
[02:32] <lifeless> spiv: I'm not sure that you should.
[02:32] <spm> 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] <lifeless> spiv: but lets start with bzr+ssh
[02:33] <lifeless> spm: lp-login creates it. (I did in fact detail this for you at the time).
[02:33] <spm> 'k
[02:34] <spm> 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] <spiv> lifeless: I'm typically in favour of stop-and-fix, but delaying the release for my patch seemed like a worse option...
[02:35] <lifeless> I hear its traumatic when one starts
[02:41] <lifeless> jml: bug 76616 did you look into the claim of a bad merge?
[02:42] <jml> no, I didn't.
[02:42] <lifeless> jml: I think you should, or change the status down to fix committed
[02:51] <spiv> jml: rename patch submitted
[02:52] <spiv> jml: (for review)
[02:52] <jml> spiv: thanks.
[02:53] <spiv> jml: I haven't run the full test suite, but relevant subsets seem happy, and the grep output looks sane.
[02:55] <lifeless> poolie: http://www.overcomingbias.com/2009/06/why-yes-men.html
[02:57] <lifeless> I'm going into deep hack mode on check
[02:57] <lifeless> two days of bugs and writing have driven me battty
[02:57] <lifeless> SMS or ring to get my attention
[02:59] <jml> poolie: can you please review https://code.edge.launchpad.net/~spiv/bzr/rename-init_ex-verb/+merge/7366
[02:59] <jml> poolie: I've had a look & I think it's good, but would appreciate the double check.
[03:12] <poolie> wilco
[03:16] <poolie> done
[03:16] <jml> poolie: thanks
[03:18] <spiv> poolie: yeah, it seems to work fine against an older server (lp, which is in fact 1.14 I think?)
[03:18] <jml> yep.
[03:19] <jml> the other check is 1.15 client vs dev server
[03:20] <spiv> jml: that'll fallback in precisely the same way that 1.15 does against 1.14 (i.e. LP) now
[03:20] <jml> oh of course :)
[03:20] <spiv> spm: so, should I try lp: or bzr+ssh: URLs on PQM again?
[03:21] <spm> spiv: I would yes. the fix from last time is still in place so *hopefully* it'll all work...
[03:21] <spiv> spm: ok, will let you know shortly :)
[03:22] <spm> heh
[03:22] <spiv> spm: ok, it's on PQM now... let's see what happens.
[03:22]  * jml afk for a bit.
[03:23] <spiv> spm: and at 02:23:04 it disappeared.
[03:23]  * spm swears, sighs, and starts looking
[03:24] <spiv> spm: that was with a lp: URL.
[03:24] <spm> I think I'm gunna cry.
[03:24] <spm> [Errno 13] Permission denied: '/home/pqm/.bazaar/authentication.conf'
[03:24] <spiv> \o/
[03:24] <lifeless> [machine crashed] spiv please try bzr+ssh
[03:24] <lifeless> spiv: and don't try lp: until bzr+ssh are working
[03:24] <spiv> lifeless: given the above error, I don't think bzr+ssh would help :)
[03:25] <lifeless> spiv: if lp: is trying to write to it, bzr+ssh probably won't
[03:25] <spm> I'd agree. I need to find out what's doing the lp-login and terminate with prejudice.
[03:26] <lifeless> spiv: specifically I *do* think it will help.
[03:28] <spiv> lifeless: well, spm is the one driving the debugging, so I'll happily do what he asks.
[03:30] <spm> spiv: ha! if lifeless reckons it'll work, I'm happy to let you try? :-)
[03:30] <lifeless> here are my thoughts
[03:31] <lifeless> lp: is special. pqm might not use the right apis. it might need firewall ports opened.
[03:31] <lifeless> bzr+ssh will let us be sure that the ssh aspect is working
[03:31] <lifeless> we should get bzr+ssh working for source branches before trying lp at all.
[03:32] <spiv> Submitting bzr+ssh merge request.
[03:32] <lifeless> that way, if lp: requires more stuff, or indeed is even breaking things, we'll be able to diagnose that directly.
[03:33] <spm> spiv: that looks to be working!
[03:34] <spiv> Yeah.
[03:35] <lifeless> another data point
[03:35] <spm> so what is it about the LS pqm stuffo that causes the auth stuff to foobar bzr pqm. /rhetorical
[03:35] <lifeless> 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] <lifeless> so even if lp urls work, we shouldn't use them.
[03:37] <spm> 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] <spiv> lifeless: that's a shame, because I'd prefer to have lp URLs as my public_location in locations.conf.
[03:41] <lifeless> spiv: I agree, and I think we should work up to that
[03:41] <spiv> Also, I don't care much about the speed of HTTP within the data centre.
[03:42] <lifeless> :P
[03:45] <spiv> Especially compared to the speed of running the test suite twice ;)
[03:45] <lifeless> well
[03:45] <lifeless> parallel++
[03:46] <spiv> Yeah, using more cores if they're there is certainly a good idea.
[03:46] <lifeless> the C check has saved my bacon way too often
[03:46] <lifeless> ok lappie seems stable again. -> deep hacking.
[03:47] <spiv> It would be interesting to have stats on the tests that PQM most commonly trips on.
[03:47] <lifeless> oh, one lsat thing
[03:48] <lifeless> igc: I think my command hooks patch is blocked on your replying to my reply to your review.
[04:06] <tedg> lifeless: Hey, is there a way to regenerate the indices?
[04:06] <tedg> 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] <spiv> tedg: I haven't seen that error before...
[04:12]  * tedg seems to have special skills in breaking bazaar :(
[04:22] <spiv> 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] <spiv> tedg: which repo format?  pack-0.92?
[04:23] <tedg> spiv: What ever is default in the nightlies plus rich-root-pack.
[04:23]  * spiv nods
[04:23] <lifeless> tedg: file a bug; we'll need to write a repair tool to regen the index for you.
[04:24] <lifeless> tedg: the index is zlib'd data
[04:24] <tedg> lifeless: What should be in the bug, just that single tix file or the whole repo?
[04:24] <lifeless> tedg: its mostly (but not entirely) derivable from what you have on disk
[04:25] <lifeless> tedg: the one tix which may let us repair it depending on the damage.
[04:25] <lifeless> tedg: and this conversation probably
[04:25] <tedg> 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] <tedg> I can start the process over, I don't need that tix specifically.
[04:25] <tedg> I'm just trying to avoid starting over.
[04:25] <lifeless> 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] <lifeless> tedg: if this occured during a fresh branch from svn, well check your hardware - you may have a disk or memory problem
[04:26] <spiv> lifeless: a little bit odd to get BadIndexError rather than a zlib error if it's bad hardware, though.
[04:27] <lifeless> spiv: depends on the try's.
[04:27] <lifeless> also we can look at the index once the bug is filed.
[04:28] <tedg> So, I guess I'm not 100% clear what I should attach to the bug.
[04:28] <lifeless> 13:19 < lifeless> tedg: the one tix which may let us repair it depending on the damage.
[04:28] <lifeless> 13:19 < lifeless> tedg: and this conversation probably
[04:28] <tedg> lifeless: Okay.
[04:31] <AfC> Why in God's name does Launchpad not understand a bzr:// URL?!?
[04:34] <tedg> Info attached to bug 386203
[04:35] <igc> hi all
[04:35] <igc> lifeless: it probably is blocked on that sorry
[04:35] <jml> back
[04:35] <jml> hi igc
[04:36] <jml> AfC: God doesn't pay us.
[04:36] <igc> lifeless: I've just woken up and feel like absolute crap so ...
[04:36] <igc> I'll take a look Monday
[04:36] <igc> jml: anything you need from me wrt the release?
[04:36] <jml> igc: nope, you're all good.
[04:36] <jml> igc: thanks.
[04:36] <lifeless> igc: go rest
[04:36] <lifeless> igc: health++
[04:37] <igc> jml, lifeless: shall do.
[04:37] <AfC> jml: ok, I'll try again
[04:37] <AfC> Why in bog's name does Launchpad not understand a bzr:// URL?!?
[04:37] <AfC> :)
[04:37] <AfC> [bonus points if you get the Heinlein reference]
[04:37] <jml> I counter with "tanstaafl"
[04:37] <igc> poolie: I'm taking today off. Call me if there's anything urgent please
[04:38] <jml> AfC: because we think it's less important than the next twenty things we want to do.
[04:39] <jml> spiv: is your PQM job still running, or is that a resubmit?
[04:40] <spiv> jml: still running.
[04:40] <jml> AfC: I know that's an unsatisfying answer, but I'm afraid I don't have any others.
[04:40] <spiv> jml: you can tell it's on the latter half of the run by the [ascii] prefix on the output...
[04:40] <jml> spiv: ahh ok.
[04:40] <jml> how long does it take to land a branch these days?
[04:41] <spiv> jml: (you can see from the scrollback that the submission was delayed a little by PQM + lp: URL debuggery)
[04:42] <lifeless> back to hacking
[04:44] <spiv> jml: over an hour :(
[04:45] <mwhudson> wow
[04:45] <mwhudson> the launchpad pqm was that fast at one point :)
[04:45] <spiv> jml: judging from the times on PQM (including that my job's time seems to be 1 hour in the future vs. the clock), at least.
[04:45] <spiv> mwhudson: to be fair, we run our test suite twice :P
[04:45] <mwhudson> who cares about fair!
[04:46] <spiv> jml: ah, I think it just finished.
[04:46]  * mwhudson is waiting for make schema, grumpily
[05:05] <jml> poolie: thoughts? http://paste.ubuntu.com/193945/
[05:06] <poolie> jml: i think it's the easiest pastebin question someone's asked me for a while :)
[05:06] <poolie> there is a typo 'on run on huge'
[05:06] <jml> poolie: dropped 'on run'
[05:07] <spiv> jml: perhaps add "to it" on the last sentence of the first para, to try disambiguate that users should be cautious about upgrading formats, not about upgrading to 1.16?
[05:07] <poolie> i think it's great
[05:07] <jml> spiv: good call.
[05:07] <poolie> it's good to have some fresh blood writing it too
[05:07] <poolie> also you can pick a code name if you want!
[05:07] <jml> "to the new format"
[05:08] <spiv> jml: yeah, good call.  "it" should be banned ;)
[05:08] <jml> poolie: where would I put that?
[05:08] <poolie> i think it now goes in the rest keyvalue thing with the dates
[05:08] <poolie> there is another example
[05:08] <poolie> that syntax is a little ugly
[05:09] <poolie> oh maybe also run make html-docs and check the syntax of news is all ok
[05:09] <jml> good idea
[05:10] <jml> also, say I misguidedly tagged an earlier revision as 1.16rc1...
[05:10] <poolie> tag --force i think
[05:10] <jml> ta
[05:40] <jml> am waiting for a couple of PQM landings before actually rolling out the release.
[06:39] <lifeless> ~
[07:02] <lifeless> less useful exceptions #45
[07:02] <lifeless> ValueError: Mismatched revision id and expected: 'robertc@lifeless-64-20090612055804-efc1rzfonn6ue0fq', 'robertc@lifeless-64-20090612055804-efc1rzfonn6ue0fq'
[07:03]  * lifeless goes back to it
[07:03] <bialix> nice
[07:04] <AfC> Those Zero Width Non Breaking spaces (U+FEFF) will get you every time :)
[07:19] <jml> wuuu
[07:23] <bialix> jml?
[07:23] <bialix> it means you had good sleep?
[07:23] <jml> no, sadly.
[07:24] <bialix> and ready to fire 1.16?
[07:24] <jml> it means it's release time :)
[07:24] <bialix> let's rock!
[07:27] <jml> running make check_dist_tarball
[07:30] <jml> I'm getting failures running blackbox.test_merge
[07:33] <spiv> jml: anything I can help with?
[07:33] <jml> spiv: looks like it might be a plugin...
[07:33] <jml> spiv: http://paste.ubuntu.com/194053/
[07:33] <jml> that's the failure.
[07:35] <spiv> jml: unexpected success, almost!
[07:36] <spiv> jml: weird
[07:36] <spiv> jml: I can't reproduce locally, unsurprisingly
[07:37] <jml> it's one of my installed plugins -- renaming .bazaar/plugins to .bazaar/vogons leaves me with the errors.
[07:38] <spiv> jml: which plugins do you have?
[07:39] <jml> bzrtools, launchpad 1.16dev, netrc_credential_store 1.16dev, pqm 1.3, qbzr 0.9.2, search 1.7dev
[07:39] <spiv> jml: (I take it that that test passes for you with --no-plugins)
[07:39] <jml> yes.
[07:39] <spiv> None of those jump out at me as a likely culprit.
[07:39] <jml> me neither
[07:39] <jml> removing search, then qbzr.
[07:40] <spiv> Interestingly, the merge is still producing conflicts, as it should, so it's just the retcode that's wrong.
[07:40] <jml> looks to be qbzr
[07:40] <spiv> I will speculate -- I was about to say that :)
[07:40] <jml> hmm. bialix & gary are both gone.
[07:41] <spiv> jml: qbzr trunk seems to work for me...
[07:43] <jml> it's probably my ubuntu package then.
[07:45] <lifeless> I'm about to call it a day
[07:45] <lifeless> poolie: You may hate me for this, but I just found a design problem in bbc that makes check significantly more complex and that we can fix with a small amount of work... but its a format bump.
[07:46] <spiv> jml: that qbzr version is almost certainly broken w.r.t. to 1.15 too.
[07:46] <lifeless> bug 386227
[07:47] <lifeless> poolie: I'd like you to look at it and think about it and let me know if you think its worth doing; fornow I'm going to use a[n unreliable] heuristic in check to let me finish the check work.
[07:47] <jml> pulling in latest subunit.
[07:49] <spiv> jml: (wow, qbzr 0.9.2 is pretty ancient)
[07:49] <lifeless> jml: apt-get install should be all you need
[07:50] <jml> lifeless: http://paste.ubuntu.com/194067/
[07:50] <jml> and I have no subunit or python-subunit package installable.
[07:50] <lifeless> https://edge.launchpad.net/~subunit/+archive/ppa
[07:50] <lifeless> or run karmic
[07:52] <jml> ffs.
[07:52] <lifeless> jml: or remove subunit
[07:52] <lifeless> jml: as the test skips if subunit isn't present
[07:53] <lifeless> jml: of course, it should work with subunit too, done() was landed in subunit
[07:55] <jml> I'll remove subunit & see what happens.
[08:05] <lifeless> ok, EODing. jml - ring ifyou're stuck on the release
[08:05] <jml> lifeless: will do, thanks.
[08:05] <jml> lifeless: have a good weekend.
[08:07] <vila> hi all, have a nice week-end lifeless
[08:08] <jml> vila: hello
[08:09] <lifeless> vila: oh vila cool. poolie said to remind you of 2.0 targeted, and generally critical bugs as a priority to ocus ons
[08:10] <vila> lifeless: ok
[08:13] <vila> lifeless: any specific ones ?
[08:13] <lifeless> https://edge.launchpad.net/bzr/+milestone/2.0
[08:13] <lifeless> just the general thing of keeping our eye on the prize
[08:13] <lifeless> it doesn't have to be all consuming
[08:13] <lifeless> but we shouldn't get too distracted with other things
[08:14] <lifeless> anyhow, family time now
[08:18] <jml> woot, new failure.
[08:18] <jml> http://paste.ubuntu.com/194100/
[08:19] <jml> is that Python 2.6?
[08:20] <jml> looks like
[08:20] <vila> jml: it's a warning from 2.6 yes
[08:21] <jml> vila: ok, so how do I proceed? -- I'm doing a make check-dist-tarball
[08:22]  * jml hacks the makefile to use python2.5 and proceeds from there.
[08:22] <vila> hmm, that needs to be addressed :-/
[08:22] <vila> jml: that should work :-)
[08:22] <vila> jml: can you keep notes or file a bug so that it's not forgotten ?
[08:22] <jml> the deprecated usage is in the stdlib itself.
[08:23] <jml> vila: sure thing
[08:23] <jml> (I should have been doing that from the start.)
[08:27] <fullermd> vila: BTW, I did try a selftest run on that new system.  Unfortunately, I couldn't --parallel.  So it still took like 20+ minutes   :(
[08:27] <fullermd> (and ended up with a big ole pile of failures of various sorts too  :()
[08:28] <fullermd> I've got python 2.6 on that box too...   the bleating about SHA/MD5 at the beginning of selftest from 2.6 is kinda grumy-making...
[08:30] <vila> fullermd: 1) Why couldn't you use --parallel, 2) File a bug with all failures (when time permits, I'll add bsd to my test farm and from there...)
[08:31] <vila> fullermd: related to 2, it's generally to much pain do diagnose test failures without being able to reproduce it on a real (or virtual) system
[08:31] <fullermd> A lot of them were of the form "xyz has no revision [some id that looks like it was just created]".  Not sure what's up with that.  But a few spottests showed it on my current py2.5 system too.  Weird.
[08:32] <fullermd> Couldn't --parallel because it wanted testtools, which I don't seem to have an OS package for (and I work hard to not step outside those bounds when avoidable)
[08:33] <jml> we should fix that.
[08:33] <fullermd> I was planning to throw together a mail with the test failures sometime when I had a chance to run it, log it, and dig through the annoyingly verbose output of selftest...
[08:35] <fullermd> BTW, it's kinda annoying how there's no documentation about what the options for --parallel are...
[08:37] <vila> fullermd: about '--parallel', your right, patch welcome ? :-/ Basically you need testtools and subunit, I understand you desire to stay inside well maintained bounds.
[08:38] <vila> fullermd: about test failures: a bug with the full log is perfectly appropriate, don't bother analysing, collecting the data is the most important thing
[08:38] <fullermd> FAILED (failures=12, errors=84, known_failure_count=12)
[08:38] <fullermd> That would be a big log   :p
[08:39] <vila> fullermd: I've seen worse :)
[08:40] <fullermd> I would guess that all the "has no revision XYZ"'s have the same root cause, so it'd worth collating those out at least.  That's the big bulk of the 'errors' ones.
[08:40] <fullermd> At least 3 of the failures are the fails I've previously noted on whatever it was...
[08:40] <fullermd> 2009-06-09:01:27 <fullermd> test_two_files_different_versions_no_inconsistencies_bug_165071 fails for me on RepositoryFormat's 5, 6, and 7.
[08:41] <fullermd> (NFC what possible impact the OS could make on that one...)
[08:41] <poolie> hi, i'm back
[08:42] <vila> fullermd: NFC as in utf-8 encoding ?
[08:42] <fullermd> vila: no, as in No <profane> Clue.
[08:42] <poolie> hello vila
[08:43] <vila> poolie: hi :)
[08:43] <poolie> jml, are you still here? how did you go?
[08:44] <jml> poolie: some problems with make check_dist_tarball & python 2.6
[08:44] <jml> uploading the files to Launchpad now though
[08:47] <fullermd> (they all fail upset about getting '2 unreferenced text versions' instead of 0.  What the heck does the OS have to do with that?)
[08:48] <vila> fullermd: haaa. that's the funniest part in diagnosing the bug ! I don't to spoil it by telling you now :)
[08:49]  * vila thinks: nice one, should reuse it some day...
[08:49] <poolie> jml, make check is dodgy wrt plugins
[08:50] <poolie> i think it should run with --no-plugins probably
[08:50] <jml> poolie: I was thinking about that.
[08:50] <jml> and I wrote some of my thoughts down for later elucidation :)
[08:51] <poolie> oh jolly good
[08:51] <vila> jml. poolie: --on-plugins is a too big hammer, it excludes our own internal plugins
[08:52] <vila> hehe nice typo :-) I meant --no-plugins of course
[08:52] <vila> jelmer: pinh
[08:52] <vila> jelmer: ping
[08:52]  * vila remove his boxing gloves
[08:54] <poolie> vila, so i'm not sure we should have shipped plugins
[08:54] <poolie> occam's razor
[08:54] <poolie> it's kind of a freak
[08:55] <poolie> maybe we should look at what problems if any there would be with just merging that code
[08:55] <poolie> i'm not assuming there would be none
[08:56] <vila> poolie: I'm talking about the launchpad plugin and friends here, the ones inside bzrlib/plugins, you want to get rid of them or include more there ?
[08:57] <vila> I thaught we didn't want to merge the lp plugin for licensing reasons (will soon be moot though)
[08:58] <vila> On the other hand, the plugins are a good starting point for other plugins and as such, there is value keeping them plugins if only to ensure the mechanisms they use are well tested
[08:59] <vila> I'm thinking about the gnu plugin or the python plugins which have been discussed here and there (providing the same server specific URL handling)
[08:59] <poolie> vila, yes i was talking about the lp plugin too
[08:59] <poolie> i'm not aware of any live licencing reason to keep it separate
[08:59] <poolie> it just makes web requests to a public service, no problems there
[09:00] <jml> poolie: can you please update freshmeat for me: http://freshmeat.net/projects/bzr/
[09:01] <poolie> and i think in reality, there is no testing benefit
[09:01] <jml> also, if you could approve my post to bzr-announce, that'd be ace.
[09:01] <poolie> it just adds another case
[09:01] <poolie> jml: just post and i'll approve it
[09:01] <poolie> do you have a fm account?
[09:01] <vila> poolie: by "licensing" I meant discussions around bzr "pushing" lp which isn't open sourced. Keeping it as a plugin allows *not* distributing the plugin to whoever feels the need.
[09:02] <jml> poolie: no, I don't.
[09:02] <poolie> ok
[09:02] <poolie> i'll do that then
[09:02] <poolie> i would have made you a coadmin if you did
[09:02] <jml> poolie: I have posted to bzr-announce already -- waiting for approval :)
[09:02] <poolie> jml, actually to save time next time, please just create one
[09:02] <poolie> won't take long
[09:02] <jml> poolie: will do.
[09:03] <vila> poolie: I think the underlying problem is a lack of a better mechanism to select/activate/desactivate plugins
[09:03] <vila> I'd prefer having more plugins than less :-)
[09:06] <jml> poolie: can you please give me whatever permissions I need to register on PyPI? my username is jml
[09:06] <poolie> list post approved-
[09:07] <jml> danke
[09:07] <poolie> pypi done
[09:08] <jml> I assume I don't merge released code back into trunk until the final release, right?
[09:09] <poolie> if there are new fixes there you can do it now
[09:09] <jml> there aren't, I don't think. just the news file changes.
[09:12] <jml> hmm. I think I have a very, very old freshmeat account linked to a defunct email address.
[09:18] <poolie> so, um
[09:18] <poolie> are you looking for that?
[09:19] <poolie> or maybe i should just do this one
[09:20] <wgrant> jml: Did you mean to create the 1.16 release on LP, rather than 1.16rc1?
[09:20] <jml> wgrant: I think I meant to create 1.16rc1.
[09:20] <jml> poolie: I do have a 'jmlTas' account.
[09:21] <jml> wgrant: the instructions on the wiki page & the instructions on Launchpad itself combined for a lack of clarity
[09:21] <jml> wgrant: can I do anything about it now?
[09:21] <lifeless> jml:  you should merge back now as part of fixing up NEWS
[09:21] <wgrant> jml: You could unrelease it, but that might not be possible now you've added files.
[09:21] <lifeless> jml: the docs should be clear about this
[09:22] <wgrant> (there's normally a (-) icon next to the release date, IIRC)
[09:23] <jml> lifeless: well, they aren't to me.
[09:23]  * jml makes a note
[09:23] <poolie> jml ok you should have access on freshmeat now
[09:23] <poolie> thanks for doing all this
[09:23] <jml> poolie: np
[09:23] <poolie> it's both a lot of work, and also more work than it should be
[09:24] <jml> I guess I need to change the version numbers again when merging back :\
[09:24] <poolie> lifeless: i saw your bug about check and chk keys
[09:24] <poolie> maybe we should talk on the list
[09:24] <lifeless> poolie: sure. essentially I'm closing in on having check overhauled.
[09:25] <lifeless> some moderately tricksy stuff remaining but all monday should see it done
[09:25] <wgrant> jml: Ah - since you can delete project release files on Launchpad, you can in fact fix it all up.
[09:25] <poolie> you can also ask a duck to rename it
[09:25] <poolie> but that may take a while
[09:25] <fullermd> Why a duck?
[09:26] <jml> wgrant: cool. I'll sort that out.
[09:26] <jml> hmm.... before I register on freshmeat, it seems.
[09:26] <wgrant> poolie: You don't even need a duck.
[09:26] <wgrant> poolie: But that won't work really well, because stuff is milestoned to 1.16, and it would become milestoned to 1.16rc1.
[09:27] <poolie> oh i see, yeah
[09:27] <wgrant> but just unreleasing it, creating a new 1.16rc1 milestone, and then releasing that should work. And this UI was just redone to make it simpler...
[09:27] <poolie> jml: i gave jmlTas access
[09:27] <poolie> ok so now i really need to go
[09:27] <poolie> bye
[09:27] <jml> poolie: thanks.
[09:37] <jml> what do I advance the version numbers too?
[09:37]  * jml looks in __init__.py history
[09:38] <lifeless> jml: 1 17 0 dev IIRC
[09:38] <lifeless> and in NEWS it stays IN DEVELOPMENT but the released sections get the header they were released under
[09:38] <lifeless> *really going*
[09:39] <jml> :)
[09:42] <strk> how do I get a checkout into a specific revision ?
[09:42] <strk> 'update' has no --revision switch
[09:43] <jml> g'night all.
[09:43] <strk> and checkout complains about already existing something (.bzr)
[09:43] <jml> thanks so much everybody for making 1.16rc1!
[09:43] <lifeless> strk: what do you need a specific revision for? is it for testing, or committing on?
[09:44] <strk> testing (looking for the commit which introduced a regression)
[09:44] <lifeless> bzr revert -r revision
[09:44] <lifeless> also consider using bzr bisect
[09:44] <strk> how to get out of that afterwards ?
[09:44] <lifeless> though it can be a bit confusion
[09:44] <lifeless> bzr revert
[09:44] <strk> k, thanks (I'll leave bisect out for now, I tried it once but I'm not ready for it yet - I bisect "manually")
[09:45] <strk> oh, but 'revno' keeps telling me the new revno, not the one I reverted to
[09:45] <lifeless> yes
[09:46] <strk> how do I know the revision I reverted-to ?
[09:46] <lifeless> well this is why bisect is better ;). but for now, your bash history ?
[09:46] <fullermd> You don't, nothing is stored about that.
[09:46] <lifeless> sorry I'm being brief, really gotta run
[09:46] <fullermd> Well, it's why update -r is better, really.  But that's bug 45719 still.
[09:46]  * lifeless closes irc ssh session
[09:47] <fullermd> Past its third birthday now, too.  We forgot to throw it a party...
[09:47] <strk> indeed I tried update -r
[09:47] <strk> +1 for that bug !
[10:01] <Spabby> good morning my version control loving friends
[10:13] <Spabby> awilkins are you around please?
[10:13] <awilkins> Yes
[10:13] <Spabby> have you got 2 minutes?
[10:13] <awilkins> Don't ask to ask, just ask
[10:13] <Spabby> I just need a little help re: linux permissions if you are ok
[10:13] <awilkins> :-)
[10:13] <awilkins> Hah, I'm no expert on that but I can comment
[10:14] <Spabby> i've created a new user for myself to use to checkout over ssh, as using root is bad puppy
[10:14] <Spabby> but when I try to bzr update on the server while logged in as the new user I get permission error
[10:15] <awilkins> You did the initial checkout as root?
[10:16] <bialix> vila: hi
[10:16] <Spabby> ah
[10:16] <Spabby> i did the inital checkin as root
[10:16] <Spabby> the files where already on the server
[10:17] <awilkins> Something is probably owned by root that you haven't got rights for as your new user
[10:17] <Spabby> I htink I need to make a new group
[10:17] <awilkins> Either change the ownership to the new user, or create a group for commit rights and change the group ownership to that
[10:17] <Spabby> add the users to that group and give ownership to that group
[10:17] <Spabby> lol
[10:17] <Spabby> thanks
[10:17] <vila> bialix: hi !
[10:18] <bialix> I'm glad you're back
[10:18] <awilkins> I still haven't figured out the setuid bit
[10:18] <bialix> or at least you're here
[10:18] <awilkins> But that's probably not relevant
[10:18] <bialix> vila: lifeless asked about filing the bug re broken read-only access
[10:18] <bialix> to lp
[10:19] <bialix> I dunno maybe you already filed it
[10:20] <vila> bialix: nope, I was off-line yesterday (well more like 36hours), lots of backlog
[10:20] <vila> I thought jml said he will talk to spiv about it
[10:20] <vila> if not, I'll file the bug, but the description may be a bit vague
[10:21] <vila> or we may just copy the irc discussion about it
[10:30] <bialix> if the doc-ru branch is still has this bug you can use it as example
[10:31] <vila> It's unclear to me if it's a bzr bug or really a launchpad-code bug though as a bzr client has no way to know whether it is talking to the writable version or the read-only version, and for the fixer script in bug #354036 just *can't* update the read-only branch
[10:46] <vila> jelmer: ping
[11:30] <spiv> jml: (wow, qbzr 0.9.2 is pretty ancient)
[11:31] <spiv> jml: (d'oh, thanks for combination of suspend+resume and TCP for making me bang random keys into IRC...)
[11:34] <LarstiQ> james_w: ho hum. bzr deb:package doesn't work. I add a 'sources.Lookup(name)' in front of the while, and it does
[11:35] <james_w> LarstiQ: oops
[11:35] <LarstiQ> james_w: so for some reason apt_pkg returns different values for sources.Lookup(name) on the two runs
[11:35] <LarstiQ> james_w: (it does work in one go on packages in the main archive, but this one is in /etc/apt/sources.list.d/company.list)
[11:36] <james_w> weird
[11:36] <LarstiQ> quite
[11:36] <james_w> it seems like adding an extra call would make the first case fail?
[11:36]  * LarstiQ thinks the apt_pkg interface is weird anyway
[11:36] <LarstiQ> james_w: correct
[11:37] <james_w> definitely weird
[11:38] <bialix> vila: am I understand correctly you're author of netrc std plugin?
[11:38] <LarstiQ> bialix: he is
[11:38] <bialix> does this plugin really needed on Windows?
[11:39] <LarstiQ> james_w: ah, I see.
[11:39] <james_w> bialix: I doubt it is
[11:39] <LarstiQ> james_w: it can return None on any call, so the while loop won't work
[11:39] <LarstiQ> bialix: needed? No. does `python -c 'import netrc'` work?
[11:40] <bialix> import itself works
[11:40] <bialix> does netrc itself works -- I dunno
[11:42] <bialix> I don't think netrc is somehow related to vanilla Windows
[11:42] <LarstiQ> bialix: right. I don't know if people use it on windows, if it can work, that would be ok.
[11:42] <LarstiQ> but if it doesn't work, ditch it
[11:43] <bialix> I know I'm not using netrc, so I'm just deleting this plugin every time
[11:43] <bialix> why this support lives in a plugin?
[11:45] <LarstiQ> bialix: afaik the main goal is to provide a reference implementation of a credential provider
[11:46] <bialix> ok
[11:46] <bialix> but it could be great example even if it will be in the core
[11:47] <bialix> loading more plugins -> more delay at startup
[11:47] <bialix> @win32
[11:47] <LarstiQ> bialix: more of a delay then when netrc would be in core?
[11:48] <bialix> well, I know the difference is negligible small
[11:48] <bialix> but it is
[11:48] <LarstiQ> bialix: interesting. I'm not opposed to moving it to core, if you'd like to suggest that.
[11:49]  * bialix just ramblings
[11:49] <bialix> I've tested converison of qbzr trunk to bbc
[11:50] <bialix> everything seems ok
[11:50] <LarstiQ> james_w: no claims that I understand apt_pkg, but: cache = apt_pkg.GetCache(); package = cache[name]; package.VersionList
[11:51] <vila> bialix: I doubt netrc is of any use on windows
[11:51] <LarstiQ> james_w: scratch that, doesn't seem to relate directly to the sources.Lookup either, meh
[11:51]  * bialix does not like unused things
[11:51] <bialix> as jam reported he found any file operations on win32 is much slower than on linux
[11:52]  * vila thinks bialix should suffer like hell when looking the dlls on windows :)
[11:52] <bialix> so any unused plugin leads to slow down at start
[11:52] <vila> bialix: hmm, I see
[11:52] <vila> But I don't see an obvious way to avoid that either :-/
[11:53] <bialix> why it should be a plugin and not in the core?
[11:53] <vila> Funny you ask, poolie raise a similar issue this morning. Larstiq is right though, I intended it to be an *example* plugin people could copy/paste
[11:54] <bialix> wow! qbzr repo shrinks after upgrade 4M -> 1M
[11:55] <bialix> vila: if this is a pure example, can it be placed in the folder "examples" ;-)
[11:55]  * LarstiQ does actually use the netrc plugin
[11:55] <vila> bialix: it;s not pure, it is meant to be useful too :-)
[11:55] <bialix> but not for windows user?
[11:57] <vila> bialix: not for the average windows user. I'm sure some of them have managed to use some exotic ftp client that use the '.netrc' file :-D
[11:57] <bialix> yep
[11:58] <vila> ',netrc' is one of those "standard" files from the 70's
[11:58] <bialix> is this known effect for bbc: it works much faster when there is only one pack in the repo?
[11:59] <spiv> bialix: it is known that it helps a lot to pack after upgrade to bbc.
[11:59]  * bialix will keep building custom bzr.exe without this plugin
[11:59] <bialix> spiv: it was already packed
[11:59] <bialix> I'm testing format 2a in temp dir
[11:59] <sodoku> hey, we are doing c prrogramming homework every week at university. Some parts should evolve durings the homeworks. Any suggestions how to manage this with bzr?
[12:00] <bialix> spiv: but after upgrade repo has 4 or 5 packs
[12:00] <spiv> sodoku: possibly a branch per assignment
[12:00] <vila> spiv: are you aware of the strange bug related to #354036: when the fixer script updates the lp branch, its read-only mirror is not updated ?
[12:01] <spiv> vila: that's a LP issue rather than a core bzr issue, essentially.
[12:01] <james_w> LarstiQ: it could just be a bug in apt_pkg of course
[12:01] <vila> spiv: I agree, but that wasn't the question :-) Though I understand the answer to it is yes, right ?
[12:02] <spiv> I am aware as of today or maybe yesterday, yeah.
[12:02] <bialix> that bug is also about lp
[12:08] <sodoku1> spiv: can i remove or add files to branches? as some files don't need to be kept for all assignments
[12:11] <vila> jelmer: ping :-)
[12:11] <spiv> sodoku1: you can always add or remove files from a branch.  I'm guessing you won't be merging much between assignments so you probably don't need to worry about a merge from a later assignment deleting files in an earlier one, for instance.
[12:12] <vila> ha, no, I meant jelmer: Ping
[12:12] <spiv> sodoku1: the other obvious option is just one branch, maybe just tag each assignment when you submit it if you want to refer back to the old assignments easily.
[12:12] <sodoku1> spiv: ok, thanks
[12:12] <bialix> guys, 2a format is slower for branching standalone branchers
[12:12] <bialix> do you aware of this?
[12:13] <sodoku1> spiv: ok, thanks
[12:13] <sodoku1> yeah, thats what i thought og
[12:14] <spiv> bialix: I think so, igc has been doing a fair bit of benchmarking with the "usertest" tool with large branches.
[12:14] <spiv> bialix: ISTR that being one of the known weaknesses still to be fixed.
[12:15] <bialix> ISTR?
[12:15] <spiv> I Seem To Recall
[12:15] <spiv> It might be interesting to know the numbers on Windows though, I don't think there's been much benchmarking done there with the new format yet.
[12:15] <sodoku1> spiv: which option would you prefer?
[12:16] <spiv> Probably the results are proportionately the same as other platforms, but it's always worth checking...
[12:16] <bialix> on kerguelen maybe?
[12:16] <spiv> bialix: yeah, that's probably a good option
[12:16] <spiv> sodoku1: I dunno, it'd depend on what how it turned out :)
[12:17] <bialix> I don't have enough channel to download really BIG repo to test
[12:17] <sodoku1> spiv: branches would keep different folders for every branch? that would be better, as my dumb teacher doesn't understand bzr ;)
[12:17] <spiv> sodoku1: I'd start with a branch for the first assignment, then when the next assignment starts decide then if it makes sense as a continuation of that branch, or a branch of that original assignment, or an entirely new branch.
[12:18] <spiv> Right, there would be a folder for each branch.
[12:18] <spiv> (But you could still use a shared repository, see the init-repo command, to save disk-space)
[12:18] <sodoku1> spiv: ok, i will do it that way. Big thanks
[12:19] <spiv> bialix: yeah.  Maybe mail igc with your observations, and ask if he wants to try testing on kerguelen?
[12:19] <spiv> bialix: or volunteer yourself if you aren't busy enough ;)
[12:20] <bialix> no, thanks
[12:20] <spiv> Certainly it might be good for igc to post an update with his latest numbers so we known where the known issues are.
[12:20] <spiv> bialix: :)
[12:21] <bialix> I've sent some numbers to bz ML
[12:21] <bialix> spiv: I'm no more bzr dev
[12:21] <spiv> bialix: cool, thanks
[12:21] <spiv> bialix: I appreciate your input and efforts regardless of team membership :)
[12:22] <spiv> bialix: btw, qbzr is pretty neat!
[12:22] <bialix> thx
[12:22] <spiv> It and kcachegrind are why I have qt installed on my system :)
[12:22] <bialix> unfortunately me and Gary have too little time to make it really cool
[12:28] <bialix> spiv: I can't push 2a branch to LP yet?
[12:29] <bialix> so
[12:29] <spiv> bialix: Hmm, I don't think so, but I think they are planning on upgrading their bzr to 1.16 basically at the same time as it releases.
[12:29] <bialix> ok, I've tried to test time of push
[12:29] <bialix> will wait then
[12:57] <fullermd> What the frell?
[12:57] <fullermd> I can't upgrade from dev6 to 2a because "Does not support nested trees"??
[13:00] <jelmer> fullermd: patch pending
[13:00] <fullermd> Or dev7...   I thought 2a _was_ dev7, just with a different string...
[13:02] <LarstiQ> james_w: http://apt.alioth.debian.org/python-apt-doc/apt_pkg/cache.html#pkgsrcrecords Lookup docs seems to imply you need to call it once per version.
[13:03] <james_w> that's what the while loop does isn't it?
[13:03] <LarstiQ> james_w: except the first version can return None, and the second will return 1
[13:04] <LarstiQ> james_w: in which case, the while loop will not call Lookup for the second version
[13:04] <LarstiQ> james_w: also,  Lookup seems to cycle between versions, so you can't count on StopIteration or the like..
[13:05] <james_w> weird
[13:05] <LarstiQ> yeah
[13:05]  * LarstiQ will go bother mvo with it
[13:20] <sven_> hi! is it normal that bzr gives conflicts after uncommit + revert on a fresh branch?
[13:20] <sven_> specifically, i did: bzr branch lp:mysql-server ; cd mysql-server ; bzr uncommit -r date:2008-12-01 ; bzr revert
[13:20] <sven_> that gave conflicts like "Conflict: can't delete mysql-test/collections because it is not empty.  Not deleting."
[13:21] <sven_> and also one conflict like "Conflict adding file mysql-test/include/diff_tables.inc.  Moved existing file to mysql-test/include/diff_tables.inc.moved."
[13:21] <sven_> is this a bug?
[13:22] <fullermd> I can certainly imagine cases where conflicts would be caused.  I'm not sure whether they apply here though.
[13:23] <sven_> fullermd, shouldn't branch+uncommit -r date:2008-12-01+revert be the same as branch -r date:2008-12-01?
[13:26] <fullermd> No, not really.
[13:27] <fullermd> `branch + pull --overwrite -rdate:2008-12-01 .` would be more equivalent.
[13:27] <fullermd> Prior to the revert you have a pile of uncommitted changes sitting around, which may conflict with going to the base state.
[13:31] <sven_> fullermd, ok, thanks for explaining! i'll try pull --overwrite instead.
[13:31] <fullermd> Well, really using branch -r would be the best choice if that's what you want to end up with   :p
[13:31] <fullermd> Saves a lot of steps (and copying a fair hunk of data, if you're crossing repos)
[13:32] <sven_> fullermd, right, of course :-) i just wanted to know why branch+uncommit+revert didn't work the way i expected
[13:50] <sven_> when i run bzr gci, i get this stack trace: http://pastebin.com/m40b8163a . i'm using the latest bzr from http://bazaar-vcs.org/bzr/bzr.dev/ and the latest gtk plugins from http://bazaar.launchpad.net/%7Ebzr-gtk/bzr-gtk/trunk/
[13:51] <spiv> sven_: I think bzr-gtk is a little behind recent changes in bzrlib's API.
[13:51] <pygi> it is, yes spiv
[13:51] <vila> sven_: a patch is under review
[13:52] <sven_> spiv, vila, ok, thanks. any idea which revision of bzr i can revert to?
[13:53] <vila> sven_: not from the top of my head, search for a progress bar related commit by martin pool
[13:53] <spiv> sven_: tag:bzr-1.15.1 is probably simplest.
[13:53] <sven_> vila, spiv, thank you!
[13:56] <pygi> hi vila btw
[13:57] <vila> pygi: hi :)
[14:06] <rchady> Is it possible to change the name of the repo?  i.e. configure bzr to use .mybzr or similar?
[14:07] <fullermd> Not without hacking bzr.
[14:13] <gioele> hello
[14:14] <rchady> bummer ok
[14:14] <rchady> hoped there was a config option
[14:18] <gioele> playing with bzr fast-import I messed up a branch. Give that I cannot remove the working tree because it contains some valuable but ignored files,
[14:18] <gioele> I was thinking about copying the .bzr directory from the push location over the mangled .bzr directory in the branch. Are the two bzr directories compatible or are they different?
[14:22] <fullermd> Fortunately, the answer to that is simplicity itself.
[14:22] <fullermd> "It depends"   :)
[14:23] <gioele> fullermd: on what?
[14:23] <fullermd> Well, pretty much on details of what each location is/has/etc.
[14:23] <vila> gioele: why don't you try the opposite instead ?
[14:23] <fullermd> Either or both have internal repos?  Branch heads at the same revision?  WT state the same?  etc.
[14:24] <vila> copy the working tree over a freshly pulled branch
[14:24] <gioele> fullermd: each one is a standalone branch (well, one was before having its .bzr corrupted)
[14:25] <gioele> is it possible to branch into/over a directory that is not empty?
[14:26] <gioele> I can then remove the corrupted .bzr and "bzr branch $pushed_branch $old_wt"
[14:27] <vila> gioele: bzr branch --no-tree
[14:27] <vila> gioele: and then copy your WT (except .bzr) over there
[14:27] <guilhembi> vila: hello! more and more colleagues are hitting https://bugs.launchpad.net/bzr/+bug/385191 just by upgrading to the latest bzr.dev; could this be prioritized, please?
[14:27] <guilhembi> vila: they can't commit anymore :(
[14:27] <gioele> vila: that could be a good solution
[14:28] <vila> gioele: doing it that way will provide you with a sandbox where you can experiment over and over again
[14:28] <guilhembi> vila: is there a quick fix that could be pushed ?
[14:29] <vila> guilhembi: the fix *is* available at lp:~vila/bzr-gtk/385191-new-pb
[14:29] <vila> guilhembi: it is under review for inclusion in bzr-gtk trunk
[14:29] <guilhembi> vila: thanks! The faster it goes in the trunk, the least colleagues hit it and have to temporarily downgrade.
[14:29] <vila> guilhembi: hopefully bzr-gtk-0.96 will be released soon after
[14:29] <vila> guilhembi: your preaching the choir !!!
[14:30] <vila> guilhembi: why do you think I marked it critical ? :-D
[14:30] <guilhembi> vila: the problem is that colleagues are upgrading now, as they have learnt that gcommit saves commit messages when cancelled, in the latest bzr-gtk.
[14:30] <vila> guilhembi: I know, I'm sorry about that :(
[14:30] <vila> jelmer: PING
[14:30] <vila> jelmer: :-)
[14:31] <guilhembi> vila: Looking to the future: given that bzr-gtk is so critical, would it be possible that, before there is a push in bzr.dev, this somehow automatically runs bzr-gtk tests to verify that the push it not breaking it (even though the fault is more on bzr-gtk here)?
[14:31] <guilhembi> (fault by not changing code though class was deprecated)
[14:32] <vila> guilhembi: 1) Not enough tests in bzr-gtk so far, 2) the class has been deprecated since 1.12
[14:41] <Spabby> awilkins how do I checkout a branch from a central server onto my linux box, it has bzr + olive branch installed
[14:43] <Spabby> hmm
[14:43] <Spabby> do I need to create a local branch first before updating it from the central server?
[14:45] <Spabby> also is the bzr website down for everyone or just me ;)
[14:45] <spiv> Hmm, it's down for me too.
[14:45] <Spabby> bah!
[14:45] <vila> sven_: let's try to go forward instead of backward, how about trying bzr.dev and lp:~vila/bzr-gtk/385191-new-pb ?
[14:48] <spiv> Spabby: it's back
[14:48] <Spabby> yep thanks
[14:48] <Spabby> :)
[14:49] <sven_> vila, i still get the same crash :-(
[14:53] <vila> sven_: this one http://pastebin.com/m40b8163a ?
[14:53] <vila> sven_: then you didn't update bzr-gtk, double-check
[14:57] <sven_> vila, yes, the same one. i just tried again with the same result: 'cd ~/.bazaar/plugins ; rm -rf gtk ; bzr branch lp:~vila/bzr-gtk/385191-new-pb gtk'
[14:58] <sven_> vila, bzr version and bzr plugins say this: http://pastebin.com/m2a9b7b11
[14:59] <vila> sven_: bzr plugins -v
[15:01] <sven_> vila, http://pastebin.com/m4a4ee23b
[15:01] <vila> sven_: also, lp:~vila/bzr-gtk/385191-new-pb was missing a minor cosmetic change, try updating your branch and do 'bzr revno' there it should say 648
[15:02] <vila> sven_: hey, that's a different traceback !
[15:02] <sven_> vila, ok, i got revno 648, but it still crashes...
[15:02] <sven_> oh, is it?
[15:02] <vila> #
[15:02] <vila> AttributeError: 'gtksourceview2.LanguageManager' object has no attribute 'guess_language'
[15:02] <vila> #
[15:02] <vila>  
[15:03] <vila> no idea about that one though :-(
[15:04] <vila> sven_: but it doesn't happen here
[15:06] <sven_> vila, very strange
[15:06] <sven_> vila, i can repeat it every time. it doesn't matter which repo i'm in when i issue bzr gci
[15:07] <sven_> vila, shall i report a bug or is this an unsupported branch of bzr-gtk?
[15:08] <vila> sven_: I'm pretty sure it hasn't been introduced by that branch but by a previous modification in bzr-gtk, additionnally it may be specific to your config, what OS/version are you using ?
[15:09] <sven_> vila, Linux riska 2.6.24-24-generic #1 SMP Wed Apr 15 15:54:25 UTC 2009 i686 GNU/Linux
[15:09] <vila> sven_: what distro ?
[15:09] <sven_> vila, ubuntu
[15:09] <vila> hardy, intrepid, jaunty ?
[15:10] <sven_> vila, hmm, how do i tell?
[15:10] <vila> sven_: Man ! You just *know* it :-D
[15:10] <sven_> vila, :-)
[15:11]  * vila shouting: Damn, how do you know which ubuntu version you're using ?
[15:12] <sven_> vila, ok, cat /etc/lsb-release says it's hardy
[15:13] <vila> sven_: easy then upgrade !
[15:13] <vila> oooops
[15:13] <vila> ok, so bzr-gtk@639 says: Merge GtkSourceView2 migration patch.
[15:18] <sven_> vila, ok, i guess it was time to upgrade anyways...
[15:18] <vila> sven_: ha, the README says: In order to see syntax highlighted diffs:
[15:18] <vila>   * GtkSourceView2 Python bindings (on Debian and Ubuntu systems, these
[15:18] <vila>     are in the python-gtksourceview2 package)
[15:18] <sven_> vila, so you mean it's not supposed to work on hardy?
[15:18] <vila> sven_: wait, I was joking, try the above first !
[15:19] <vila> a crash is a bug if hardy is not supported traceback is not a good way to tell you
[15:19] <sven_> vila, ok :-)
[15:20] <sven_> vila, i have python-gtksourceview2 installed already
[15:20] <vila> sven_: and it's still crashing ?
[15:20] <bengee> hi, not sure if this is an faq: I have a project with a couple of modules (in sub-directories) and I'd like to allow checkouts of individuals modules, is that possible or do I need a separate branch for each module?
[15:20] <sven_> vila, yes
[15:21] <vila> sven_: argh, so either I install a VM with hardy or you upgrade to jaunty :-/
[15:21] <vila> in any case, please file a bug while you can reproduce it
[15:35] <sven_> vila, ok, i filed https://bugs.launchpad.net/bzr/+bug/386359
[15:35] <vila> thanks
[15:42] <vila> sven_: Can you try http://paste.ubuntu.com/194407/
[15:43] <bialix> vila: can we talk a bit about SavedCommitMessageManager from bzr-gtk?
[15:43] <vila> bialix: EOVERFLOW :-/
[15:43] <sven_> vila, yes, that works!
[15:43] <vila> bialix: ha, wait :D
[15:44] <vila> sven_: great ! At least you're unblocked !
[15:44]  * bialix explodes
[15:44] <bialix> and wait
[15:44] <sven_> vila, yes, thanks!
[15:46] <vila> bialix: I still have a huge mail backlog so if thins have been discussed further on the qbzr ML I may not be up to date
[15:47] <bialix> no, it was not discussed yet
[15:47] <bialix> but if you're busy with your mails, maybe I need to wait couple of days
[15:48] <bialix> I just have couple of questions about design of that class
[15:49] <bialix> it seems you've touched it
[15:49] <bialix> but may be not you wrote it
[17:04] <vila> guilhembi: ping
[18:36] <davidstrauss> How does bzr detect whether something is a line-mergable text file?
[18:36] <davidstrauss> bzr gave me a "contents" conflict on a .test file that's actually just php
[18:38] <Peng_> davidstrauss: It just checks for the presence of NUL bytes.
[18:38] <davidstrauss> hmm
[18:40] <LarstiQ> davidstrauss: was there a file-kind change involved?
[18:40] <davidstrauss> no
[18:40] <davidstrauss> But there are people editing on Windows and other funky platforms
[18:40] <davidstrauss> thought line endings are consistent
[19:00] <ronny> sup
[19:01] <ronny> LarstiQ: aware of anyone here toyed with the idea of tracking changes instead of snapshoots
[19:01] <LarstiQ> ronny: darcs
[19:01] <LarstiQ> ronny: in essence it is a dual problem
[19:02] <ronny> LarstiQ: that one is not exactly usable out of its user-oriented cli
[19:02] <LarstiQ> ronny: right. Coudld you elaborate on what you're looking for?
[19:03] <ronny> LarstiQ: well, im looking for more things that allow version controll in terms of related changes instead of snapshoots
[19:03] <ronny> kills the need for rebase and the most kinds of merges
[19:03] <LarstiQ> ronny: quilt, mq, looms, that sort of thing?
[19:04] <ronny> LarstiQ: those are at best workarounds, changes are not first class members of the history there
[19:04] <ronny> LarstiQ: bascially darcs and camp are the only ones that do at least the basic structure reasonable
[19:05] <fullermd> There are just as many problems that come from states being derived as there are from changes being derived.  They're just different problem.
[19:06] <ronny> fullermd: i want something that can deal with heavy cherrypicking propperly
[19:07] <jelmer> ronny: subversion >= 1.5 does that to some extent
[19:07] <jelmer> ronny: better than bzr/hg/git afaik
[19:09] <ronny> jelmer: svn is not distributed, and i doubt they have a sane ui
[19:10] <LarstiQ> ronny: svk? ;)
[19:13] <ronny> LarstiQ: whenever i tried that one it was epic fail
[19:14]  * LarstiQ nods
[21:29] <fjlacoste> my gpg env seems screwed
[21:29] <fjlacoste> gpg: problem with the agent - disabling agent use
[21:29] <fjlacoste> aborting commit write group: SigningFailed(Failed to gpg sign data with command "[u'/usr/bin/gpg', '--clearsign']")
[21:29] <fjlacoste> bzr: ERROR: Failed to gpg sign data with command "[u'/usr/bin/gpg', '--clearsign']"
[21:29] <flacoste> anybody way i could get more info out of this failure
[21:30] <LarstiQ> flacoste: is gpg agent usable outside bzr?
[21:30] <LarstiQ> flacoste: wild guess, GPG_TTY?
[21:30] <flacoste> LarstiQ: it is running, but kmail doesn't seem to be able to use it either, so i guess not
[21:30] <flacoste> but BZR does prompt me for my passphrase
[21:31] <flacoste> hmm, $GPG_TTY is not set
[21:31] <flacoste> but GPG_AGENT_INFO is
[21:31] <LarstiQ> flacoste: in my case, when that happens, I take out the openpgp card from the reader and reinsert it
[21:31] <flacoste> and running gpg from a terminal works (but the agent doesn't there either)
[21:31] <flacoste> lol
[21:31] <flacoste> i don't have a card
[21:32] <LarstiQ> flacoste: GPG_TTY need not be, but in some cases the agent can't find the tty to acquire the passphrase from. Doesn't seem to be this case.
[21:32] <LarstiQ> flacoste: right :)
[21:32] <flacoste> i've reinstalled on another computer
[21:32] <flacoste> in my other working setup, pinentry-qt4 is used
[21:32]  * LarstiQ uses pinentry-curses
[21:32] <flacoste> if i run gpg-agent by itself in the terminal
[21:32] <flacoste> i get
[21:33] <flacoste> gpg-agent: gpg-agent running and available
[21:33] <LarstiQ> flacoste: right
[21:33] <LarstiQ> flacoste: try gpg -d some-encrypted-file
[21:33] <LarstiQ> flacoste: or ssh-add -L if you've started gpg-agent with --enable-ssh-support
[21:33] <flacoste> nope, the default ubuntu setup is used
[21:34] <flacoste> and gpg-agent is run inside ssh-agent
[21:34] <LarstiQ> ok
[21:34] <flacoste> [francis@Casteneda testfix]$ gpg -d zdaemon.conf.asc
[21:34] <flacoste> You need a passphrase to unlock the secret key for
[21:34] <flacoste> user: "Francis J. Lacoste <francis.lacoste@Contre.COM>"
[21:34] <flacoste> 1024-bit ELG-E key, ID 96196F76, created 2001-01-18 (main key ID 2CB3F937)
[21:34] <flacoste> gpg: problem with the agent - disabling agent use
[21:34] <flacoste> gpg: encrypted with 1024-bit ELG-E key, ID 96196F76, created 2001-01-18
[21:34] <flacoste>       "Francis J. Lacoste <francis.lacoste@Contre.COM>"
[21:34] <LarstiQ> right
[21:34] <flacoste> entering the passphrase on the terminal decrypts the file
[21:35] <LarstiQ> flacoste: this may be a case of bzr paying attention to the gpg exit code, even though signing succeeded
[21:35] <flacoste> ah right
[21:35] <flacoste> [francis@Casteneda testfix]$ echo $?
[21:35] <flacoste> 2
[21:35] <flacoste> that's after a succesful clearsign
[21:36] <flacoste> but with agent problem
[21:36]  * LarstiQ nods
[21:36] <flacoste> should I file a bug about that?
[21:36] <flacoste> i guess so...
[21:36]  * LarstiQ is checking if there is one
[21:38] <LarstiQ> why is my battery empty _yet again_‽ :(
[21:38] <flacoste> #44755 bzr commit fails when GPG agent is unavailable
[21:39] <flacoste> fix released
[21:39] <flacoste> i guess not
[21:39] <flacoste> (low)   	
[21:39] <flacoste> #54468 sign-my-commits fails when gpg-agent and pinentry-curses are being used
[21:41] <LarstiQ> flacoste: from the comments I don't see why #44755 would be fixed
[21:41] <flacoste> i'm reoping with a suggestion to use Won't Fix :-)
[21:43] <flacoste> any idea of where i should go to get help with my gpg-agent problem?
[21:44] <LarstiQ> flacoste: did you try the GPG_TTY suggestion?
[21:44] <LarstiQ> flacoste: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=322932
[21:45] <flacoste> well, i suspect a deeper issue, since ideally, i'd like also to get it working with kmail
[21:45] <flacoste> i mean, it's not even working for the gpg command line itself
[21:46] <flacoste> ah:
[21:46] <flacoste> ah:
[21:46] <flacoste> write(8, "GET_PASSPHRASE A2B3F83DE11E0C7247"..., 223) = 223
[21:46] <flacoste> write(8, "\n"..., 1)                    = 1
[21:46] <flacoste> read(8, "ERR 67108949 No pinentry <GPG Age"..., 1002) = 37
[21:46] <flacoste> write(2, "gpg: "..., 5gpg: )                 = 5
[21:46] <flacoste> seems that gpg-agent thinks there is no pinentry configured
[21:46] <flacoste> do you happen to know how this is usually configured?
[21:48] <flacoste> ah!
[21:48] <LarstiQ> flacoste: my ~/.gnugp/gpg-agent.conf has: pinentry-program /usr/bin/pinentry-curses
[21:48] <flacoste> yep, just found that
[21:48] <flacoste> it seems it points to a now non-existent program
[21:48] <flacoste> that's what happens when you copy config files voer
[21:48] <LarstiQ> doh :)
[21:52] <flacoste> LarstiQ: all sorted out now, thanks for the support!
[21:53] <LarstiQ> flacoste: gladly :)