[00:29] <poolie> hi maxb
[00:32] <maxb> hello
[00:46] <KombuchaKip> I just ran bzr sign-my-commits in my local working copy. I was prompted to sign previous unsigned revisions and did so. Now when I run bzr status, I don't see anything changed or new to commit to the repository. How do I commit the signed aspect of the revisions?
[00:48] <fullermd> You don't.  Signatures aren't committed things.
[00:48] <KombuchaKip> fullermd: Then how can others verify that someone else's commit is genuine?
[00:50] <fullermd> EBADCOMMUNICATION.  By making a signature, it's in the repo.  Signatures aren't something you commit, they're their own thing that making puts in the VCS storage, like tags.
[00:51] <KombuchaKip> fullermd: So if you don't commit them, how are they sent to the repository so others can verify the revision's authenticity?
[00:52] <fullermd> Same way the commits are; they get pushed/pulled around.
[00:53] <KombuchaKip> fullermd: I am using centralized model. How do I send my signature?
[00:54] <fullermd> Dunno.  In a Proper World(tm), making the signature automatically would propagate it upstream when you're using a checkout.
[00:54]  * KombuchaKip is very confused
[00:54] <fullermd> In the current mishmash, I'm not sure.  Maybe it goes as a side effect next time you commit something.
[00:55] <KombuchaKip> fullermd: It should really show something in status, at least a separate category for tags / metadata that changed.
[00:55] <fullermd> That's not what status does though.  Status talks about changes between revisions.
[00:56] <fullermd> Signatures (and tags, for that matter) aren't part of revisions.  They're a separate dimension.
[00:56] <KombuchaKip> fullermd: So then there should be a status for repository, in addition to one for revisions.
[00:57] <fullermd> Well, the bugs that cause it to be needed in this case should be fixed   :)
[00:57] <KombuchaKip> fullermd: When I click on the "signature" button in the nautilus bzr GUI, it just locks up every time.
[00:58] <fullermd> I'd guess that's something to do with it trying to read a passphrase from the terminal.
[00:58] <KombuchaKip> fullermd: Dunno. Not a very good design. seahorse-daemon just sits there spinning the clock.
[00:59] <fullermd> Hey, don't look at me.  I've never even seen the nautilus bzr GUI.  Or nautilus, for that matter   :)
[01:00]  * KombuchaKip visualized fullermd with a Lemote, virtual console, and X uninstalled.
[01:01] <fullermd> Ehhwut?  Sorry, I couldn't hear you over the clattering of my teletype.
[01:01] <KombuchaKip> fullermd: lol
[01:54] <poolie> thanks for all the patches, gary
[02:54] <mwhudson> what's the incantation to force bzrlib to use openssh as its ssh transport?
[02:55] <mwhudson> i thought it was BZR_SSH=openssh
[02:55] <fullermd> Accords with the docs...
[03:15] <mwhudson> i guess https://bugs.launchpad.net/bzr/+bug/677305 isn't going to make spiv feel any better when he gets back to work
[03:24] <maxb> ooh
[03:24] <maxb> I think I may have fixed that bug
[03:26] <lifeless> maxb: its what killed the importds :)
[03:28] <maxb> I'm kinda surprised no-one noticed - I guess no one actually uses sftp:// much
[03:28] <maxb> I only noticed because dput uses bzrlib for sftp
[03:29] <mwhudson> maxb: it seems that you can bzr branch sftp:// fine, i guess the __del__ method doesn't get called somehow then
[03:30] <lifeless> we nuke the interpreter, don't we?
[03:31] <mwhudson> oh right yes
[03:31] <mwhudson> so very unlikely that __del__ runs then :_)
[05:28] <_habnabit> Does anyone know offhand if a merge with conflicts will return a >0 status code?
[05:37] <poolie> _habnabit: yes, it should
[05:37] <_habnabit> Okay.
[07:06] <vila> hi all !
[07:13] <poolie> hi vila
[07:13] <poolie> i have to confess i am an awful patch pilot :/
[07:14] <vila> poolie: for your sin you will do it again next week :-D
[07:14] <vila> kidding
[07:14] <poolie> hm actually maybe i should
[07:14] <poolie> but, my turn will come around again soon
[07:14] <vila> Instead, you should feel very gulty so you'll be better next time
[07:14] <vila> still kidding
[07:14] <poolie> i'll try to do some next week without wearing the hat
[07:15] <poolie> i see john did some recently
[07:15] <vila> yeah, nice ones, good to see them again :D
[07:15] <vila> regarding pqm, it works again
[07:16] <vila> I haven't summarized the root causes yet, but briefly, we need to define the dependencies in a package that losas can use as a spec
[07:16] <vila> I'll try to work on this today
[07:17] <vila> This doesn't mean we don't need a backup plan, but this should severely reduce the occurrences of what we went through lately
[07:17] <poolie> i think there's a bug asking for that?
[07:18] <poolie> essentially a binary package that defines the dependencies even before such a bzr package exists?
[07:19] <vila> ECANTPARSE 'even before such a bzr' :-/
[07:20] <vila> a package with a Depends clause in the debian/control listing subunut, python-testtools and such (python-docutils ?)
[07:20] <vila> named bzr-check-dependencies or something
[07:21] <poolie> that's what i mean
[07:22] <vila> or bzr-pqm-dependencies (I'm still not sure if we will have variations on this theme like bzr-dev-dependencies or bzr-doc-dependencies for docutils/sphinx switch)
[07:22] <vila> ok
[07:22] <poolie> normally these would be stated as the build dependencies of bzr 2.3.something
[07:22] <poolie> however, there is no package of that name yet, because we can't commit the changes to upstream until we have installed the necessary dependencies into the chroot
[07:22] <vila> ha build, hmm
[07:23] <vila> meh, you lost me here :(
[07:23] <vila> lack of chroot practice probably
[07:32] <poolie> what packages will be depended-upon by tomorrow's bzr?
[07:32] <poolie> you can't look at the metadata of tomorrow's deb package of bzr to find out, because it doesn't exist yet
[07:33] <poolie> one solution to this bootstrapping problem is to have a second deb that just says what depedencies we want to have in the chroot
[07:33] <poolie> is that clearer?
[07:33] <vila> yup
[07:34] <vila> Once it exists, this package will be in the BuildDepends for bzr itself, is that it ?
[07:35] <vila> (since there is no TestDepends but we want to run tests during build this workaround this lack :)
[07:47] <vila> back to bug #676608 and 17 may not enough at http://sourcefrog.net/weblog/software/aesthetics/interface-levels.html
[07:48] <vila> s/and 17/and why 17/ for the ob tyop on my jokes
[07:48] <vila> meh, thanks too much ubot
[07:49] <poolie> almost: it won't be in the builddepends because we only need this is the special case of pqm
[07:49] <poolie> regular debian or ubuntu builds can just declare their build depedencies in the usual way
[07:49] <poolie> heh :)
[07:50] <vila> but they will define the same dependencies no ? May be I should not care about that for now though...
[07:51] <vila> poolie: those are just details, I got your points
[07:56] <vila> 18. Even when you get it right, you're wrong
[07:57] <poolie> :)
[07:59] <vila> The sad thing is that I just tweak my fix because even if all the tests (including the one failing without the fix) were passing *even* if my fix was wrong (and I'm fed up enough to not try to write a test to prove this because.... I'm not even sure I can :-/)
[07:59] <vila> So subtly wrong it looked right, but still :(
[08:00] <GaryvdM> Good morning all.
[08:01] <vila> Good Morning GaryvdM !
[08:01] <vila> err, I meant Goooood Morning GaryvdM
[08:02] <GaryvdM> Ha ha
[08:13] <poolie> good night, vila, gary
[08:13] <GaryvdM> Good night
[08:13] <vila> poolie: enjoy your week-end
[08:14] <poolie> GaryvdM: are you ok on those bugs? maybe vila can help if you need a buddy
[08:15] <GaryvdM> I'm ok - I started looking at doing a incremental annotate last night
[08:15] <GaryvdM> poolie: I spoke to jam about it
[08:16] <poolie> that would be great
[08:16] <vila> GaryvdM: feel free to ping
[08:16] <GaryvdM> poolie: for bug 153787
[08:17] <GaryvdM> poolie: I know that it won't help for command line annotate - So I hope that will be ok for them.
[08:18] <GaryvdM> But doing a incremental annotate in a gui is more suited to my skills than implementing a cache.
[08:18] <GaryvdM> vila: Thanks
[08:19] <poolie> doing an incremental annotate in a gui would be superb
[08:19] <poolie> iwbn if it could also feed out incremental data to emacs or loggerhead (over ajax)
[08:20] <GaryvdM> vila: how would it be possible to do that with emacs?
[08:20] <vila> yup. exactly what poolie said, try to keep it in mind even if you start with a qbzr version (but I'm sure you thought about it)
[08:21] <vila> GaryvdM: emacs can communicate with an asynchronous  subprocess
[08:21] <vila> GaryvdM: so in theory it can update the display when the subprocess returns more precise annotations
[08:22] <vila> GaryvdM: but as jam told you, you need first to revert the whole way the annotations are processed today starting with 'I have no idea where its coming from' to 'this line comes from this revision' via 'this line comes from a revision older than this one'
[08:23] <GaryvdM> vila: re emacs: using something like curses?
[08:23] <vila> GaryvdM: additional bonus if you managed to somehow restrict that to a window of lines currently displayed
[08:24] <GaryvdM> vila: I can't see that that would make it faster.
[08:24] <vila> well, emacs works from a tty to X11 displays and OSX graphic lib and Windows graphic lib, you shouldn't care about what it uses, just give him (line number, revision)
[08:25] <vila> or (line start, line end, revision) tuples
[08:26] <GaryvdM> vila: Is there a defined protocol for this?
[08:26] <vila> GaryvdM: none that I know of
[08:27] <vila> another additional bonus would be an option to limit the age of annotations as in: "Don't tell me about revisions older than 6 months"
[08:28] <GaryvdM> vila: so we would need to write something that runs in emacs that parses this data, and displays it?
[08:28] <GaryvdM> vila: re date limit: that would be easy. :-)
[08:29] <vila> GaryvdM: yes, some emacs code should be written
[08:29] <GaryvdM> ok
[08:29] <vila> GaryvdM: this may even be a f.. good idea to be your buddy on the emacs side...
[08:30] <vila> nothing beats parallel clients to debug a common implementation...
[08:30] <GaryvdM> A curses version would also be nice. I also have been dreaming of a curses version of qlog :-)
[08:30] <vila> clog then :)
[08:39] <vila> ... of course I didn't realized that clog is a valid English word...
[08:42] <guilhembi> GaryvdM: hello! Thanks for your reply on
[08:42] <guilhembi> https://bugs.launchpad.net/bugs/588698
[08:43] <GaryvdM> Hi guilhembi!
[08:43] <guilhembi> GaryvdM: do I interpret correctly that you mean "all is normal"?
[08:45] <GaryvdM> guilhembi: It's unfortunate that that merge conflicts. I did user tests for other examples of that situation, and the conflicts when using --weave were minimal.
[08:47] <guilhembi> GaryvdM: to be sure: you mean the high number of conflicts is normal? You can say "yes" (I will then study this more in depth).
[08:48] <GaryvdM> guilhembi: The conflicts happen because storage/innobase was added by 2 different people, not because of the shape of the rev graph.
[08:49] <guilhembi> GaryvdM: so they are normal?
[08:49] <guilhembi> i.e. expected, not a bug?
[08:49] <GaryvdM> Yes
[08:49] <guilhembi> GaryvdM: thanks. I'll look into the history to see how this mess happened.
[09:13] <GaryvdM> guilhembi: I did a bzr log storage/innobase for both the jp and mm branches
[09:13] <GaryvdM> jp: http://paste.ubuntu.com/534208/
[09:13] <GaryvdM> mm http://paste.ubuntu.com/534209/
[09:16] <GaryvdM> If you take a look - you will see that they have different histories.
[09:27] <hrw> hi
[09:28] <jelmer> hey hrw
[09:28] <hrw> I have a problem. as "git bzr push" does not want to work and I have no time to dig in code to find out why I need to import ~10 patches into bzr (exported by "git format-patch"). how to make it without having to go by "patch <0001;bzr add -r .;bzr commit"?
[09:29] <jelmer> hrw: do you know what about "git bzr push" doesn't work, it isn't an easy patch?
[09:29] <jelmer> hrw: Alternatively you could try bzr-git's pull
[09:31] <hrw> jelmer: http://pastebin.com/YVmSr4Cu
[09:31] <hrw> bzr-git sounds worth to check
[09:33] <Tak> whoa, there's a git bzr now?
[09:34] <hrw> Tak: few plugins exists - none of them works perfectly
[09:34] <hrw> Tak: I use git-bzr-ng one and it is fine for "git bzr clone" but "git bzr push" fails.
[09:34] <hrw> Tak: ah.. and in natty even clone does not work but thats a matter of waiting for new bzr-fastimport package release (r282/284 fixed two bugs)
[09:36] <hrw> jelmer: thx for bzr-git hint
[09:36] <Tak> does bzr-git support push/dpush now?
[09:37] <hrw> now only need to wait till LP will scan new branch and can request review
[09:37]  * Ng cries at another -ng project ;)
[09:37] <hrw> Tak: I only needed import
[09:37] <Tak> no, that was a question for my own curiosity :-)
[09:37] <Ng> however, I was just thinking about popping over to #bzr with a suggestion, so the highlight is a welcome reminder :)
[09:37] <hrw> Tak: I use git for managing trees and bzr only to push to lp
[09:38] <hrw> Ng: ;D
[09:38]  * Ng wondered if it's possible to (globally) uniquely identify the ultimate root parent of any branch
[09:39] <Ng> I sometimes go to pull from launchpad and find that the branch has disappeared because someone renamed a team or something - would be cute if LP could respond with "404, but here's a list of branches you could switch to or merge from"
[09:39] <jelmer> Tak: it supports dpush, not yet dpush.
[09:39]  * Tak segfault
[09:40] <jelmer> Ng: Yeah, I agree that would be useful. Just a simple test search would help a lot I think. Keeping the history of names around explicitly would probably be harder.
[09:40] <jelmer> Tak: argh, you caught me pre-coffee
[09:40] <jelmer> Tak: it supports dpush, not yet push
[09:41] <Ng> jelmer: is it worth me filing a wishlist bug?
[09:41] <jelmer> Ng: please do
[09:41] <Tak> ok - I would mainly want dpush anyway ;-)
[09:42] <Tak> I'd offer you a coffee, but our machine is broken (again)
[09:42] <Ng> jelmer: k, thanks :)
[09:46] <jelmer> Tak: :-) Thanks anyway
[09:47] <Tak> we do, however, have a wide selection of teas
[10:14] <ssandberg> hi #bzr! is there a way to set per-file commit messages on the command line? perhaps there is a plugin?
[10:15] <jelmer> hi ssandberg
[10:16] <jelmer> ssandberg: There isn't one at the moment as far as I know.
[10:21] <ssandberg> jelmer, ok. any idea how easy/hard it would be to write one? i suppose it would need one new command, and also it would need to modify the commit command so that it uses the global and per-file messages
[10:23] <jelmer> ssandberg: do you want to do this the proper way or just a quick hack?
[10:24] <jelmer> ssandberg: doing it properly would mean moving the current per-file commit backend code from bzr-gtk into bzrlib.
[10:24] <jelmer> ssandberg: and then adding a UI for it (either in a plugin or in bzr core)
[10:24] <ssandberg> jelmer, right. i see there is a https://bugs.launchpad.net/bzr/+bug/185224 for this
[10:27] <jelmer> it'd be very useful to have that in core (also so e.g. qbzr can easily use it)
[10:30] <ssandberg> jelmer, i agree, would be great to have this bug fixed
[10:30] <ssandberg> jelmer, i can't spend too much time on this myself though... i have a perl script that copies per-file comments from one place to another, which is sufficient for what i need except i have to go through the gui when i commit
[10:31] <ssandberg> jelmer, so if it's not too much work i could create a hack that modifies the commit command to take the per-file messages into account. sorry i can't help more...
[10:31] <jelmer> ssandberg: you could probably do a quick hack based on the existing code in bzr-gtk
[10:33] <ssandberg> jelmer, ok. i'll look at that
[10:33] <ssandberg> jelmer, thank you!
[12:07] <speakman> hi folks
[12:08] <speakman> can I check out just the source files from a bzr repo, without the .bzr dir?
[12:08] <speakman> I just want a "snapshot" of the source tree for e.g. specified date
[12:09] <jpds> speakman: bzr checkout --lightweight ... ?
[12:11] <speakman> Will it ignore commit history and such?
[12:12] <jelmer> speakman: bzr export
[12:13] <speakman> jelmer: thanks!
[14:55] <lvh> Hi!
[14:55] <lvh> Is this the right place to ask about bzr-hg?
[14:56] <lvh> I accidentally made the mistake of assuming hg's svn interop was good. I now have a directory Twisted-hgsvninteropdisaster.
[14:56] <lvh> The last three revisions are changes I'd like to get out. How do I do that?
[14:56] <lvh> (I could just use hg and get a diff of the last three and then apply that, of course.)
[15:00] <james_w> lvh, if you have bzr-hg installed you may be able to "bzr diff" in there
[15:00] <james_w> I'm not sure quite what you want to achieve though
[15:02] <lvh> james_w: Okay, so the fourth last revision applied a patch (in hg): I also have a bzr repo at that point.
[15:02] <lvh> james_w: Then I committed some changesets in hg.
[15:02] <lvh> I'd like to take those changesets and apply them to the bzr branch instead.
[15:02] <james_w> ah, I assumed you were targeting svn
[15:03] <james_w> "bzr pull" might work for you
[15:03] <james_w> "bzr pull ../Twisted-hgsvninteropdisaster" in your bzr bracnh
[15:07] <lvh> Nah, they're different: the bzr branch has the original development, in the hg branch I just applied a patch
[15:08] <lvh> I'll go with bzr diff
[16:23] <vila> jam: about readability, note that the comment was saying: """Return true if any of the trans_ids, will have contents.""" which is highly ambiguous when all we want to know is: do we need to refuse to unversion/delete this directory
[16:24] <jam> vila: I didn't think it was ambiguous at all. If any have contents, then it returns true
[16:24] <jam> the comma shouldn't be there
[16:25] <vila> jam: *I* find it ambiguous: which content ? Versioned ? Not versioned ?
[16:26] <vila> jam: what's the difference between _removed_contents and _removed_ids ? Can a key be present in the latter but not in the former ?
[16:26] <jam> I won't say the internals of TT aren't confusing at times. But the function _any_contents does what it says
[16:27] <vila> hehe, but that doesn't answer my question when I was reading it: what's content ?
[16:28] <vila> s/doesn't/didn't/
[16:29] <vila> Oh, and the special casing was for final_kind() (Added a comment to the review)
[16:32] <vila> jam: weird, you voted 'needs information' then 'approve' and your reviewer status on the mp page is still needs information...
[16:33] <jam> vila: email landed into launchpad after I went to the webpage to see if I had an out-of-date diff
[16:33] <jam> so probably the "first" vote was handled second and took priority
[16:34] <vila> but is still displayed first... weird, n obig deal anyway, just mentioning
[16:34] <vila> jam: thanks for the review !
[16:54] <glyph> so we're talkin' about bzr bugs in #twisted again
[16:54] <glyph> last time I came in here I had a problem with an svn branch whose history started before the first revision of trunk which included bzr-svn metadata
[16:54] <glyph> that looked like it came from an alternate history
[16:55] <glyph> (because the bzr-svn metadata in question was v3, and I was using a version of bzr-svn that used v4, so trunk and the branch disagreed as to how revisions were identified)
[16:55] <glyph> I am pretty sure this is a known / existing bug, but I can't find it
[16:55] <glyph> can someone toss me a link?
[16:58] <jelmer> glyph: bug 332116?
[21:43] <glyph> hey, do you guys still support hardy?  because if so, https://bugs.launchpad.net/bzr/+bug/677655
[21:50] <spiv> glyph: we do
[21:54] <jam> hey spiv, feeling better?
[22:08] <glyph> spiv: all my hardy machines with bzr-svn installed are now unusable for all bzr operations, so that one would be a good one to fix :)
[22:08] <glyph> I guess it must have snuck in in the last update?
[22:09] <spiv> jam: almost!
[22:09] <jam> glyph: sounds like you got an updated bzr-svn but not an updated subvertpy
[22:10] <glyph> jam: all I did was 'apt-get upgrade'
[22:10] <glyph> jam: you can see my policy settings on the bug, I'll adjust them if something's wrong
[22:16] <jelmer> glyph, jam: That looks like a broken subvertpy package.
[22:17] <jelmer> newer bzr-svn versions should generally work with older versions of subvertpy