[00:00] <poolie> mkanat: i messaged you
=== LeLutin_ is now known as LeLutin
[00:41] <_habnabit> dash, okay, so I'm trying to figure out how to tell bzr about the svn merges that were done in the past. Do you know what svn prop it's supposed to be looking at?
[00:41] <dash> _habnabit: svn:mergeinfo i think.
[00:42] <_habnabit> I have `svn:mergeinfo` set, and it contains accurate infofmation.
[00:42] <_habnabit> Well.
[00:42] <_habnabit> Let me double-check the latter bit.
[00:43] <_habnabit> Does svn:mergeinfo describe merges *into* the branch it's set on?
[00:43] <dash> I forget.
[00:43] <dash> I haven't done merges without bzr-svn
[00:43] <_habnabit> Lucky. :(
[00:43] <_habnabit> I should've done that from the beginning.
[00:43] <_habnabit> This is a mess.
[00:54] <maxb> _habnabit: Your problem is a tricky one. bzr-svn does not directly support it
[00:55] <_habnabit> Ah, balls.
[00:55] <_habnabit> What is bzr-svn looking for?
[00:55] <maxb> Whilst bzr-svn will write svn:mergeinfo for svn to consume, it won't read it
[00:55] <maxb> bzr-svn looks for its own properties, or (I think) svk's style of merge metadata
[00:56] <dash> oh snap, svk.
[00:56]  * _habnabit grumbles.
[00:56] <_habnabit> I'm sure someone's done this before.
[00:56] <maxb> I believe the reason for doing so is that it was deemed overly complex to extract which elements of svn:mergeinfo relate to whole-tree merges, vs individual file ones.
[00:56] <maxb> I'm not sure I agree with that
[00:56] <_habnabit> Ah.
[00:57] <maxb> Especially since having started to work with svn:mergeinfo at my work, we've settled on avoiding subtree mergeinfo whereever possible
[00:58] <maxb> I have explored how to deceive bzr-svn into reading merges a little, but I never really got the procedure working for real
[00:59] <_habnabit> Lordy this is just a horrible mess. If I'd been using bzr-svn from the beginning, or we were using svn 1.5, this would be so much easier.
[00:59] <maxb> I think I'd probably attempt to investigate what form svk merge properties take
[00:59] <maxb> I don't think 1.5 would help
[00:59] <_habnabit> 1.5 has merge tracking.
[00:59] <_habnabit> I just need some way of doing merges that isn't svnmerge.
[00:59] <_habnabit> bzr-svn worked well in the past.
[01:00] <_habnabit> (For other projects.)
[01:00] <maxb> 1.5 has merge tracking, but not in a way which integrates with bzr-svn
[01:00] <_habnabit> Right.
[01:01] <_habnabit> I'm just using bzr as an svn client right now.
[01:01] <mkanat> mwhudson or thumper: Is there anything special I should know about doing a new stable release of loggerhead?
[01:01] <maxb> Ah. I have never tried that. I usually branch from svn into a native bzr branch and work there
[01:01] <_habnabit> Yeah, unfortunately that's not possible.
[01:02] <mwhudson> mkanat: not that i know of
[01:02] <mkanat> mwhudson: Okay, cool.
[01:02] <_habnabit> Basically my work is horrible, horrible, horrible, and I'm cleaning up my predecessors' messes.
[01:02] <_habnabit> Somehow, someone broke svnmerge.
[01:04] <_habnabit> I'm looking at using svk now.
[01:05] <maxb> I strongly advise against using svk
[01:05] <maxb> But svk's metadata might be a way to dupe bzr-svn into seeing merges
[01:05] <mkanat> I think svk is a dead project, from what I've heard.
[01:05] <maxb> Very dead
[01:06] <_habnabit> Right, that's what I'm hoping.
[01:06] <maxb> https://launchpad.net/~bzr-beta-ppa/+archive/ppa/+packages?field.name_filter=bzr-pqm&field.status_filter=published&field.series_filter= I wonder if anyone has any thoughts on these weird bzr-pqm build failures?
=== Ursinha is now known as Ursinha-afk
[01:11] <maxb> oh, it's not that deep, it's just launchpadlib versions
[01:22] <lifeless> maxb: did you see my reply?
[01:23] <maxb> About testtools? Yes. So I guess I should update my MP for 0.9.7, unless 0.9.8 is going to happen ASAP
[01:25] <lifeless> your mp ?
[01:25] <lifeless> maxb: if its a packaging one, I would say don't bother
[01:25] <maxb> ok
[01:25] <lifeless> I generally do the merge-upstream dance as part of cutting upstream releases.
[01:43] <mkanat> Hey, I think I need to be given permissions to commit to the loggerhead-team repositories.
[01:43] <mkanat> [mkanat@es-compy 1.18]$ bzr push lp:loggerhead/1.18 --use-existing-dir
[01:43] <mkanat> bzr: ERROR: Permission denied: "+branch/loggerhead/1.18/"
[01:43] <mkanat> poolie, or thumper?
[01:43] <mkanat> Or perhaps jam.
[01:44] <poolie> hi mkanat
[01:44] <poolie> maybe you're not in the right team?
[01:45] <mkanat> poolie: I'm in loggerhead-team. Maybe I need to be in another team?
[01:45] <poolie> hm, i'm not sure
[01:45] <spiv> That branch appears to be owned by loggerhead-team.
[01:46] <spiv> And created by mkanat!
[01:46] <mkanat> Indeed.
[01:46]  * thumper looks
[01:46] <spiv> So I think this is one for thumper...
[01:46] <mkanat> Maybe I have to push to the full URL?
[01:46] <mkanat> Or at least, the ~loggerhead-team URL.
[01:47] <thumper> mkanat: you "shouldn't" have to
[01:47] <mkanat> Now it's just hanging, so I'm guessing it might be working.
[01:49] <poolie> hm :)
[01:49] <poolie> and now?
[01:50] <mkanat> Yeah, just hanging.
[01:51] <mkanat> No matter which URL I use.
[01:51] <poolie> try running with -Dhpss and look in the log
[01:53] <mkanat> Okay.
[01:54] <spiv> mkanat: hmm...
[01:55] <spiv> mkanat: If it's hanging, then I think it's a known bug, I'll dig up the number
[01:55] <mkanat> Stops at:
[01:55] <mkanat> 7.541  hpss call:   'BzrDir.open_branchV3', '+branch/loggerhead/1.18/'
[01:55] <mkanat> 7.541               (to bzr+ssh://bazaar.launchpad.net/%2Bbranch/loggerhead/1.18
[01:55] <mkanat> And then starts doing:
[01:55] <mkanat> Exception RuntimeError: 'maximum recursion depth exceeded in __subclasscheck__' in <type 'exceptions.RuntimeError'> ignored
[01:55] <spiv> mkanat: https://bugs.launchpad.net/launchpad-code/+bug/668176
[01:55] <ubot5> Launchpad bug 668176 in Launchpad Bazaar Integration "lp-serve infinite loop on bzr branch/push development focus is empty bzrdir with "maximum recursion depth exceeded in __subclasscheck__" (affected: 3, heat: 14)" [Undecided,Confirmed]
[01:55] <mkanat> spiv: Yep, sounds like my issue.
[01:57] <mkanat> spiv: So I'm taking it that that fix hasn't been rolled out yet?
[01:57] <spiv> So far I think the launchpad-code team are planning to wait for bzr 2.2.2 to be released before deploying the fix.
[01:57] <mkanat> spiv: Okay...so nobody can push new branches until that happens?
[01:57] <spiv> No, it only affects some slightly odd situations.
[01:58] <spiv> Like ones where you need to use --use-existing-dir, I think?
[01:58] <mkanat> Okay. So I'll delete the branch and try again.
[01:59] <spiv> Perhaps a side-effect of your earlier permission denied problem is creating that sort of situation?
[01:59] <mkanat> spiv: Yeah, that sounds very possible.
[01:59] <mkanat> Okay, that worked. :-)
[01:59] <mkanat> Thanks spiv. :-)
[01:59] <mkanat> I still got the __subclasscheck__ warning, but it pushed.
[01:59] <spiv> What caused that permission denied anyway?
[02:00] <mkanat> spiv: I don't know--poolie, did you change something?
[02:00] <spiv> mkanat: huh, interesting.
[02:00] <mkanat> spiv: Oh, wait, maybe it wasn't related to that push, because I'm still getting the messages from somewhere in my console.
[02:00] <spiv> mkanat: oh, the old ssh connection may still be alive.  You may as well kill it.
[02:00] <mkanat> Yeah, I just did that.
[02:00] <mkanat> I'm surprised it didn't get some signal when bzr died.
[02:01] <spiv> There's a reason why it doesn't, but I forget what it is.
[02:02] <mkanat> Okay.
[02:02] <mkanat> Maybe because it's part of a critical section or something?
[02:03] <spiv> No, I think it's just some vexing aspect of how child processes and python interact, or something like that.
[02:03] <mkanat> Ah, I recall something about that, yeah.
[02:04] <poolie> mkanat: i sent a amil with the list of items from our conversation; you can reply if you want to add more
[02:04] <mkanat> poolie: Okay, cool.
[02:25] <poolie> mkanat: hi, thanks
[02:27] <poolie> for the reply
[02:27] <mkanat> poolie: Yeah, no problem. :-)
[02:27] <mkanat> Okay, this may sound silly, but I've never had to do this...is there a way to cherrypick a single revision from a branch and merge it?
[02:28] <poolie> not in a single command
[02:28] <poolie> though it would be good to add that
[02:28] <poolie> but basically just 'bzr merge -c REV_SPEC BRANCH && bzr commit'
[02:28] <mkanat> Yeah, basically, jelmer added an info.py file to trunk on loggerhead, and we should add that to the branch, too.
[02:28] <mkanat> poolie: But that doesn't keep the revision metadata.
[02:29] <mkanat> poolie: So it looks like they're separate revisions when you go to merge again, later.
[02:33] <mkanat> poolie: But that's the only way?
[02:33] <poolie> i'm afraid so; tracking them is not implemented yet
[02:33] <mkanat> poolie: Okay. :-(
[02:33] <mkanat> (We have this problem in a big way in the Bugzilla Project, too.)
[02:50] <_habnabit> Is there a way to automatically resolve conflicts? I was trying to use resolve --action=take-other, but it doesn't seem to do anything.
[02:50] <_habnabit> This is with bzr 2.3b4.
[02:51] <_habnabit> It doesn't remove the conflicted status, and it doesn't change the contents of the file.
[02:51] <poolie> _habnabit: hm, that seems like a bug then
[02:51] <poolie> that is what it's supposed to do
[02:51] <poolie> you may need to give the file name?
[02:51] <_habnabit> I did.
[02:52] <_habnabit> 0 exit code, no output at all even with -v.
[02:53] <poolie> please file a bug tagged 'conflicts'?
[02:54] <_habnabit> Oh, another thing that seems odd.
[02:54] <_habnabit> bzrlib is complaining that its version is wrong, when both bzr and bzrlib are 2.3dev4.
[02:54] <_habnabit> It says '... is version (2, 3, 0, 'dev', 4)'
[02:55] <_habnabit> Aaaand 'bzr version' says 'Bazaar (bzr) 2.3.0dev4'
[02:55] <spiv> _habnabit: I wonder if https://code.edge.launchpad.net/~vila/bzr/638451-malformed/+merge/40567 addresses your conflict problem?
[02:55] <_habnabit> Oh, never mind, that latter issue is me running the wrong bzr binary.
[02:56] <_habnabit> Looking at that ticket, though.
[03:00] <_habnabit> spiv, no, but it does something completely different!
[03:00] <_habnabit> Now I get an InvalidEntryName exception.
[03:03] <spiv> _habnabit: huh.  Sounds like useful feedback to add to that merge proposal, at least :)
[03:04] <_habnabit> I just think it's odd that it's taken this long to add!
[03:04] <spiv> take-other etc are fairly new.
[03:04] <_habnabit> Yes that's what I think is odd.
[03:05] <spiv> Well, it just automates something you can do manually.  It mainly cuts out some tedium.
[03:14] <poolie> hi spiv
[03:43] <_habnabit> Is there a way to see which revisions would be merged by bzr merge, without doing the merge?
[03:44] <fullermd> 'missing' will tell you which revs each side has that the other doesn't, so you can tell from that.
[03:44] <_habnabit> Oh, great.
[03:44] <_habnabit> This reminds me of another thing. Is there a way to mark revisions as 'plz to not merge ever'
[03:51] <mkanat> poolie: Okay, release pretty much done. Is there anywhere else I should announce it besides the bazaar list and on Launchpad itself?
[03:52] <mkanat> s/itself//
[03:52] <dash> _habnabit: Sort of
[03:52] <jam> _habnabit: bzr merge; bzr revert .; bzr commit -m "merging without adding the changes"
[03:52] <dash> yeah that.
[03:52] <_habnabit> Aha okay.
[03:52] <jam> the '.' in revert is significant
[03:52] <jam> it says revert the content, but leave the merge as pending
[03:52] <fullermd> That still _merges_ it, so it's in the history.  But the changes it made aren't in the current (and presumably future) revs.
[03:53] <_habnabit> Great, that should do exactly what I want.
[03:53] <fullermd> So if you don't want to merge it because it contains code you just don't want to use, that's OK.
[03:53] <fullermd> But if you don't want to merge because it has stuff you don't want to be available (IP reasons, giant files, etc), it doesn't work so well.
[03:53] <fullermd> It also means that if you ever merge that branch back into the branch those changes were on, they'll disappear there too.  So if you ping-pong between the branches much, it gets ugly.
[03:54] <_habnabit> I'm using bzr-svn, and it doesn't recognize any merges as having happened.
[03:54] <_habnabit> So this *should* make it think that the merges happened, I think.
[04:02] <poolie> mkanat: you could tweet about it?
[04:02] <mkanat> poolie: Sure, will do now.
[04:02] <poolie> cool
[04:02] <poolie> i'm really  glad we got this rolling again :)
[04:03] <mkanat> poolie: Yeah, me too!
[04:03] <mkanat> poolie: Okay, tweeted.
[04:09] <poolie> abentley: congrats!
[04:09] <abentley> poolie: :-)
[04:10] <abentley> poolie: are you aware of any tools that automate releasing bzr plugins via Launchpad?
[04:12] <poolie> i'm not
[04:13] <abentley> poolie: It seems like we should have written something like that by now.  What do you think of "The Kraken" as a name?
[04:14] <poolie> sure
[04:14] <poolie> there are some scripts in bzr/tools
[04:15] <poolie> and i think something slightly related in hydrazine, to do uploads
[04:16] <abentley> You mean hydrazine uploading the tarballs?
[04:24] <mkanat> abentley: How does pipeline relate to loom?
[04:25] <abentley> mkanat: pipeline is what I wrote when I found looms frustrating to use.
[04:25] <mkanat> abentley: Cool. I've found them frustrating as well, sometimes.
[04:27] <abentley> mkanat: They don't introduce any new concepts like threads.  A pipeline is just an ordered list of branches.
[04:28] <mkanat> abentley: Okay. Are they colocated?
[04:28] <abentley> mkanat: They don't overload the meaning of push, either.  Instead there's a new sync-pipeline command.
[04:28] <abentley> mkanat: No, they're just sibling branches by default.
[04:29] <mkanat> abentley: Okay. I suppose I could just try it out instead of asking you. :-)
[04:30] <abentley>  mkanat: They could be combined with colocated stuff, but I haven't done that yet.
[04:30] <mkanat> abentley: Okay.
[04:31] <mkanat> I found a few things particularly confusing or difficult about looms. Like trying to remember which directory I had which loom set in, for one.
[04:31] <mkanat> And then that they would permanently loomify your branch.
[04:31] <mkanat> And then certain weird and unexpected things about moving up or down threads.
[04:32] <abentley> mkanat: Right.  With pipelines, the format is always a standard Bazaar format.
[04:32] <mkanat> Coo..
[04:32] <mkanat> *Cool.
[04:33] <abentley> mkanat: You can switch between pipes with the normal bzr switch command, or with "switch-pipe" which will auto-shelve your uncommitted changes.
[04:33] <mkanat> Sweet.
[04:34] <abentley> mkanat: The weird up-thread behaviour is a separate "pump" command in bzr-pipeline.
[05:49] <jtv> I guess my repo is broken; see bug 673439.  Could anyone help me get back on my feet again?
[05:49] <ubot5> Bug 673439 on http://launchpad.net/bugs/673439 is private
[05:49] <jtv> Thank you ubot
[05:49] <lifeless> abentley: switch in looms doesn't do up-thread either, fwiw
[05:52] <jtv> spiv: last time you fixed me up IIRC… would you mind doing it again?  :)  Can I just remove the broken file?
[05:53] <jtv> Got matching cix, iix, rix, six, and tix files all empty.
[05:59] <jtv> lifeless: I hear you're pretty good with bzr… if I have a tuple of empty cix, iix, rix, six, and tix files in my repo, can I just delete them or something along those lines?
[05:59] <jtv> (imagine a smiley after that first sentence)
[06:13] <lifeless> uhm
[06:13] <lifeless> so that means you had a system crash without the content getting flushed
[06:13] <lifeless> the canonical answer is restore from backup
[06:14] <spiv> jtv: hi
[06:14] <lifeless> you may be able to rollback a single transaction if there is a .old pack-names file
[06:14] <jtv> hi spiv
[06:14] <lifeless> jtv: however I'm being called to the kitchen... and I'm not working today so I have no excuse :)
[06:14] <glyph> https://bugs.launchpad.net/bzr/+bug/673884
[06:14] <ubot5> Launchpad bug 673884 in Bazaar "dpush ends up in a broken state if it encounters a network problem (affected: 1, heat: 6)" [Undecided,New]
[06:15] <spiv> lifeless's advice is (of course) good.  If there isn't an old pack-names file you may be able to recover by cutting the broken pack out of pack-names.
[06:15] <jtv> lifeless: backup, you say?  Physically out of reach for the foreseeable future.  :-(
[06:15] <spiv> glyph: https://code.edge.launchpad.net/~maxb/bzr/2.2-close-ssh-subprocess-socket/+merge/40493
[06:16] <abentley> lifeless: true, but AIUI mkanat finds up-thread vs down-thread confusing, and pipelines doesn't have that kind of quasi-similar command.
[06:16] <glyph> spiv: is that a fix for it?
[06:16] <spiv> glyph: oh, dpush, not dput :)
[06:16] <glyph> gah what's dput
[06:16] <mkanat> abentley: I don't know if I find that confusing, actually.
[06:16] <spiv> glyph: a debian package archive thing, forget I mentioned it!
[06:16] <dash> not a bzr command. :)
[06:16] <mkanat> abentley: up-thread and down-thread as concepts are fine, it's that sometimes I want to switch between looms without all the merge craziness.
[06:16]  * spiv looks more closely
[06:17] <glyph> spiv: It's a pretty obvious bug, sorry for the somewhat obtuse description.
[06:17] <mkanat> abentley: Or I want to switch all the way down in one command.
[06:17] <abentley>  mkanat: so, you can always do both those things.
[06:17] <spiv> glyph: yeah, that looks like a reasonable bug to me.
[06:17] <mkanat> abentley: Also, when I push some of the lower threads into the repository but not the upper ones, the combine-thread functionality is annoying, often.
[06:17] <glyph> spiv: As bzr bugs are wont to do, it showed up immediately in the middle of trying to demonstrate to a co-worker why bzr is great :(
[06:17] <abentley> mkanat: you do down-thread [THREAD]
[06:18] <abentley> mkanat: even if the thread you want to switch to is higher.
[06:18] <spiv> glyph: and probably fairly easy to make better in many cases (and maybe even not too hard to make good in tricky cases, like e.g. local system crash/power drop during dpush).
[06:18] <spiv> glyph: s/bzr/all software/ ;)
[06:19] <glyph> spiv: yeah.  thanks :)
[06:19] <glyph> spiv: I am planning to use dpush increasingly heavily, so it'd be great if it worked right :)
[06:19] <glyph> In the meanwhile, is there any sensible way to do a cherry-pick which preserves log messages?
[06:23] <spiv> glyph: use rebase to do the cherrypick, maybe?  :/
[06:23]  * spiv hmms
[06:23] <glyph> spiv: is that a thing you can do?
[06:23] <glyph> spiv: That was actually my first thought.
[06:25] <spiv> glyph: another option would be to write a plugin to add a log format that output the commit message (and only the commit message), and then you could do "bzr merge -c NNN && bzr log --format=msg-only > commit.msg && bzr ci -F commit.msg"
[06:25] <lifeless> mkanat: in a loom you can use 'switch'
[06:25] <spiv> glyph: (or abuse the existing xmloutput plugin or something like that for the same purpose)
[06:25] <lifeless> mkanat: to avoid all that
[06:25] <mkanat> lifeless: Ah, okay.
[06:26] <lifeless> switch thread-name
[06:26] <lifeless> mkanat: could you file bugs though where things are unclear
[06:27] <lifeless> mkanat: including what it is about combine-thread thats annoying
[06:27] <mkanat> lifeless: Yeah, if I can quite figure out what I don't like, I will.
[06:27] <glyph> spiv: while that would be useful, I was hoping not to write that shell for-loop for every revision :)
[06:27] <lifeless> mkanat: even if you don't have that figured out
[06:27] <lifeless> mkanat: bug reports are about symptoms, not answers.
[06:27] <spiv> glyph: *nod*
[06:29] <spiv> glyph: rebase may be the right tool here, but it's just not something I've used much at all so I don't know the limitations and nitty gritty details of using it for stuff like this.
[06:29] <spiv> lifeless: I know you aren't here
[06:30] <spiv> lifeless: but you may be interested to know that doing working on making branch etc fetch all the tags as well as the tip is pushing me towards other improvements that have the side-effect of chipping off a few hpss round trips.
[06:34] <glyph> spiv: thanks for the classification
[06:48] <A117> bazaar explorer failed to run on XP
[06:49] <A117> any help plz?
[06:50] <spiv> A117: please file a bug at <https://bugs.launchpad.net/bzr>.  Hopefully someone that knows more than me about bzr-explorer and/or XP will be able to help you here too.
[06:51] <spiv> A117: also, give a bit more detail about your problem... in what way did it fail?  What were you trying to do when it failed?  What installer did you use?
[06:59] <A117> instaler for windows. error message is bzr
[06:59] <A117> CreateProcess failed; code 2
[06:59] <lifeless> spiv: thats great
[07:00] <lifeless> spiv: there's stuff in loom that badly needs your love in the same way
[07:00] <lifeless> spiv: using the same multi head improvements
[07:01] <lifeless> spiv: I had the idea of having a get_refs() call to find out what heads to fetch
[07:02] <spiv> lifeless: yeah, it'd be nice to give loom some love... I should make some time.
[07:02] <lifeless> spiv: I hear udd would cover it
[07:02] <lifeless> :)
[07:02] <spiv> :)
[07:18] <GaryvdM> Morning all.
[07:18] <GaryvdM> Bla- Just missed A117
[07:37] <peitschie> (a very late hiya GaryvdM :)  )
[08:13] <stefanlsd> hihi
[08:14] <GaryvdM> Hi stefanlsd
[08:16] <stefanlsd> Anyone familiar with bzr merge-package and what happens with the debian/changelog. seems like its ignored?
[08:21] <maxb> stefanlsd: Ignored? No, but it is processed with a custom merge tool that understands the format of debian/changelog entries and sometimes does things rather differently to what you might expect if you were expecting a textual merge
[08:23] <stefanlsd> maxb: aah ok. yeah, i actually see it was more intellegent than i expected. thanks
=== beaumonta is now known as abeaumont_
=== Ursinha-afk is now known as Ursinha
[13:57] <figure002> hello! I'd like to use parts of the text in http://doc.bazaar.canonical.com/bzr.2.1/developers/HACKING.html for my own Sphinx documentation, is this allowed?
[13:59] <james_w> figure002, it should be, but I can't remember what license it is under
[14:00] <figure002> ok, and if it is allowed, can someone tell me how to give the credit?
=== Ursinha is now known as Ursinha-afk
[15:13] <vila> figure002: in what context do you want to re-use it ? (Keeping in mind that GPL is more about distribution than use)
[15:23] <figure002> vila: i'm developing a python app for analyzing biological data for a small biological company. i'd like to use parts of that documentation for the Developer Guide of my application.
[15:24] <vila> figure002: so you intend to distribute the result ? Undr which license ?
[15:25] <vila> figure002: We're talking about distributing your developer guide here
[15:25] <figure002> vila: the app is GPL3, so i would use the same licence for its documentation
[15:26] <vila> ha, if it's GPL I see no objections on principle, now the differences between v2 and v3 are... way beyond my legal knowledge :)
[15:26] <vila> you could try to get in touch with poolie (see https://launchpad.net/~mbp), but I think it's ok
[15:26] <figure002> vila: haha, also, i mailed Canonical a few minutes ago about this
[15:27] <vila> figure002: even better
[15:27] <vila> figure002: nice of you to do that anyway :)
[15:27] <figure002> vila: so according to you, that documentation is licensed under GPL also?
[15:27] <figure002> vila: :)
[15:29] <vila> figure002: honestly, I don't remember. There have been discussions about which license should be used but I don't remember the specifics, I'm 75% sure it is GPLv2 though
[15:29] <figure002> vila: ok
=== Ursinha-afk is now known as Ursinha
[17:00] <vila> figure002: see bug #433734
[17:00] <ubot5> Launchpad bug 433734 in Bazaar "documentation doesn't make its licence terms clear (affected: 2, heat: 0)" [High,Confirmed] https://launchpad.net/bugs/433734
[17:01] <vila> argh urgh too late he left :(
[17:10] <vila> mgz: ping, I'm finally reviewing lp:~gz/bzr/cleanup_testcases_by_collection_613247 again
[17:10] <vila> mgz: far cleaner than I remember overall !
[17:11] <vila> mgz: running it locally with --parallel=fork I have a *huge* number of uncollected test cases (still running)
[17:12] <vila> mgz: it's also running on babune as http://babune.ladeuil.net:24842/view/debug/job/selftest-subset-all/98/aggregatedTestReport/ so you'll get a bunch to eat ;)
[17:12] <vila> mgz: more than 11000 uncollected, surely this is a shallow thing, any subset I could try to focus ?
[17:13] <vila> mgz: right, it looks like *all* tests are uncollected
[17:14] <vila> bah, and the babune run seems to be exhibiting yet another subunit stream leak :(
[17:15] <vila> mgz: I'll abort the babune runs, forget about them
[17:16] <vila> mgz: ha right, the local run finished, 7 failures, all in bzrlib.tests.test_selftest.TestUncollectedWarnings
=== deryck is now known as deryck[lunch]
[17:17] <vila> mgz: re-running without --parallel seems to exhibit the same behaviour :-/
[17:18] <vila> only slower :)
[17:18] <vila> mgz: ./bzr selftest -s  bzrlib.tests.test_selftest.TestUncollectedWarnings => 7 failures
[17:19] <vila> ok, so I'm definitely speaking alone tonight, I'm going to copy that to the mp instead :)
[17:28] <GaryvdM> vila: some of us are listening :-) Unfortunately I can't add much to the discussion.
[17:32]  * fullermd isn't listening, if that helps   :)
[17:35] <vila> :-D
=== deryck[lunch] is now known as deryck
[19:19] <lifeless> mgz: shiny new in testtools ;)
[19:51] <vila> lifeless: s/propogate/propagate/ no ? (at least 4 occurrences), raises_value_error is cute, make_error is brilliant and deserves a comment, hehe game of the day: make test_KeyboardInterrupt_matched fail :D
[19:52] <lifeless> vila: interesting... python 2.4 I bet ?
[19:52] <vila> lifeless: no no it succeeds, no problem but *how* can you make it fail ?
[19:54] <lifeless> if you revert a few commits, and put the test back in, it will fail
[19:54] <vila> if you type ctrl-C at the right time too ;)
[19:54] <lifeless> no
[19:54] <lifeless> there are two cases
[19:55] <lifeless> either you trigger k-i within the block its expected
[19:55] <lifeless> in which case (sadly) it will be ignored
[19:55] <lifeless> or you trigger it outside it, in which case it will propagate :)
[19:55] <lifeless> and the test run will abort
[19:56] <vila> ah right, silly me, if you catch *my* k-i you will won't trigger yours, but one is still happening, rats, too bad ;)
[19:56] <vila> s/will//
[19:59] <vila> lifeless: I wish our stable ppa was used in the pqm chroot so we can rely on updating pqm when updating our stable ppa (which should be fine since it's our best validated bzr version after all), that would ensures a broad and correct deployment of testtools...
[20:00] <lifeless> why don't you do that then ?
[20:00] <lifeless> or something analogous
[20:00] <vila> what more can I do than adding my last comment on rt 41340 ?
[20:01] <vila> lifeless: you mean by using a private testtools updated by the makefile ?
[20:01] <lifeless> no
[20:01] <vila> then what ?
[20:02] <lifeless> have a ppa with the stuff in it that gets used.
[20:02] <lifeless> e.g. the CAT ppa, perhaps.
[20:02] <vila> CAT ? url ?
[20:03] <lifeless> I don't have it offhand
[20:03] <lifeless> is the sysadmins ppa
[20:04] <vila> meh, why would I have more control an this than on pqm which currently is == 0 ?
[20:04] <vila> s/an/on/
[20:05] <lifeless> You could have its contents auto deployed to pqm
[20:05] <lifeless> or a dedicated ppa
[20:05] <lifeless> I dunno, I'm offering suggestions.
[20:05] <lifeless> I think you'll find they deploy testtools from the CAT ppa anyhow
[20:05] <vila> but why isn't our stable ppa valid for that ?
[20:05] <vila> ha, that's interesting then
[20:06] <lifeless> vila: I don't know - have you discussed this with tom ?
[20:06] <vila> hmm, at least using our private one could serve as a temporary workaround
[20:07] <vila> lifeless: no, I'm asking for feedback but Chex told me the losas are in a degraded mode these days
[20:07] <lifeless> this week for sure
[20:07] <lifeless> hol-i-days
[20:08] <vila> geez, yeah, Valentine told me today was one here... and that was why she was a t home (ooooooops :)
=== zyga is now known as zyga-afk
[23:44] <poolie> hi jam, spiv
[23:46] <spiv> Hi poolie
[23:50] <poolie> i'm going out to give blood in a bit, will be back later
[23:51] <poolie> then i'm going to see about finishing my outstanding branches and graphing packages built from branches
=== maxb_ is now known as maxb
[23:56] <spiv> I'm going to keep working on fetching all tags as well as tip when doing e.g. 'bzr branch'.  There's an incremental step towards that, fixing sprout to open & lock branches/repos once, that I have passing tests but want to polish.
[23:56] <poolie> k
[23:56] <poolie> i liked seeing the hpss ratchet go down
[23:56] <poolie> and locking just once would be very nice
[23:56] <poolie> ok, biab
[23:56] <spiv> I also need to figure out what to do with <https://code.launchpad.net/~spiv/bzr/checkout-tags-propagation-603395-2.2/+merge/40406>, perhaps just landing on trunk and not 2.2 is the way forward for that.
[23:57] <spiv> Yeah, the fix to sprout knocks one of the hpss ratchets down by another two calls :)