[00:34] <poolie> hi spiv?
[00:37] <spiv> Hi poolie
[00:37] <poolie> hey
[00:37] <poolie> i was just going to check you were still ok to pilot
[00:37] <poolie> and to see if you wanted reviews or anything
[00:38] <poolie> i was going to work on launchpad flags and dkim but i could do that first if you want
[00:39] <spiv> The queue looks fairly short... although there are a couple of patches from me in it.
[00:40] <spiv> Perhaps take a look at https://code.launchpad.net/~spiv/bzr/fetch-spec-everything-not-in-other/+merge/42811 ?  It's a prereq for the other two mps from me, although it is a pretty large diff.
[00:41] <spiv> Oh, although I see jam looked at a the previous iteration of it, so perhaps I should just ask him.
[04:48] <exarkun> Are there tools for looking directly at a repository's contents?
[04:50] <exarkun> or, which python api should I be looking at? :)
[04:52] <exarkun> like say I wanted to enumerate all of the leaf revision ids in a shared repository, can I do that?
[04:53] <spiv> exarkun: just a sec
[04:54] <exarkun> (I think I deleted a branch that had some stuff in it that I want, and my assumption is that I didn't completely destroy the data since it was a branch in a shared repository...)
[04:57] <spiv> exarkun: API-wise it's something like python -c "from bzrlib.repository import Repository; repo = Repository.open('code/testtools'); repo.lock_read(); g = repo.get_graph(); print g.heads(repo.revisions.keys())"
[04:58] <spiv> exarkun: but now that I see you don't really care about the API, try "bzr heads" or "bzr heads --all", from the bzrtools plugin
[04:58] <exarkun> Oh cool.  Thankee.
[05:01] <exarkun> yay recovered
[05:32]  * spiv sighs and restarts his gnome-terminal process, which has run out of fds.  Someone really needs to add that fix to maverick-updates...
[06:01] <spiv> poolie: any thoughts on the UI change proposed in https://code.launchpad.net/~jelmer/bzr/diff-git/+merge/44185 ?  (allow "bzr diff --git" rather than requiring "bzr diff --format=git")
[07:24] <vila> hi all !
[07:29] <poolie> hi spiv
[07:33] <poolie> hi vila
[07:33] <vila> poolie: hey there !
[07:38] <poolie> spiv, i answered
[07:40] <poolie> spiv: are you still here?
[08:42] <vila> Funny trick with the new 'bzr config' command: when I do a review locally, I generally create a branch whose parent is lp:bzr
[08:42] <vila> so when people update their branch I have to type again the url to get updates
[08:42] <poolie> right
[08:42] <vila> well, I had.
[08:42] <vila> Now I do: bzr config reviewed=lp:<review_url>
[08:43] <vila> and 'bzr pull -v `bzr config reviewed`
[08:43] <vila> or 'bzr diff --old `bzr config reviewed`'
[08:43] <vila> no more need to defined specific directory aliases like submit: , parent: and all, and it's supported by all bzr commands :)
[08:47] <poolie> hm
[08:47] <poolie> only on unix though
[08:47] <poolie> that's a nice reason to have config emit only the url
[08:50] <vila> yup, I'm so totally convinced now :)
[08:56] <poolie> :)
[08:56] <poolie> on windows we could do something like bzr pull config:reviewed
[08:59] <poolie> vila, we should probably defer b5 until during/after the sprint
[08:59] <poolie> do you want to hack on it there?
[08:59] <poolie> or switch to tarmac there?
[09:00] <vila> yeah, I think that would be the best, having everyone involved and aware of all the issues and debugging all nits
[09:01] <vila> yeah, definitely for 2.3b5 *and* tarmac, I'll update the release date
[09:02] <vila> .. and discuss how we reach 2.3.0 final
[09:03] <poolie> well, we'll need to schedule it with the sysadmins too
[09:04] <vila> yeah, but we can play with it on a scratch branch and ask the sysadmins to switch with a working setup
[09:04] <vila> (unless I miss something on how tarmac is supposed to work)
[09:05] <vila> but yeah, we can tell them we *will* switch around 2012-01-13 (I've update the 2.3b5 date on lp)
[09:51] <zyga> anyone here knows how to use bazaar.conf and lp-propose-merge to get an implicit push location
[10:06] <vila> zyga: Most of the time I do: bzr push lp:~vila/bzr/`bzr nick`
[10:07] <vila> zyga: the only way to go further today is to use locations.conf but it will take precedence over anything defined in branch.conf which is certainly not what you want
[10:07] <vila> zyga: there is a work in progress to allow path-based default values to be defined in bazaar.conf though
[10:09] <zyga> vila, I want to "bzr push"
[10:09] <zyga> vila, salgado gave me bazaar.conf that doesn't work that works for him
[10:09] <zyga> http://paste.ubuntu.com/544906/
[10:09] <zyga> vila, could it be possible that salgado is riding bzr.dev wave?
[10:10] <zyga> vila, my real problem is on usability of lp-propose-merge
[10:10] <zyga> it takes bzr push + bzr lp-propose-merge while I just wanted to lp-propose-merge
[10:10] <zyga> (and push also is verbose as you explained, you need to specify the push branch which is tedious)
[10:11] <vila> zyga: sections defined in bazaar.conf are just ignored
[10:11] <zyga> hmm
[10:11] <vila> zyga: unless salgado has written a plugin... which I doubt
[10:11] <zyga> vila, that's what salgado is using, I need to check with him again
[10:11] <vila> zyga: may he uses locations.conf instea
[10:11] <zyga> hmm? should I put that in locations conf and see if it worsk?
[10:12] <zyga> I'm on 2.2.1
[10:12] <vila> zyga: but the aim of locations.conf is to *override* branch.conf (so whatever is defined in branch.conf is ignored if a matching is found in locations.conf)
[10:13] <vila> zyga: it will work even for 2.0 I think (95% sure)
[10:13] <zyga> that's okay, I just want to stop having to type everything twice all the time
[10:13] <zyga> (something is happening)
[10:13] <zyga> yayt
[10:13] <zyga> it worked
[10:13] <zyga> bzr lp-propose-merge
[10:13] <zyga> no push needed :D
[10:13] <zyga> thanks :-)
[10:13] <zyga> hmm
[10:13] <zyga> (premature happines)
[10:13] <vila> zyga: you need to type it once, once it's defined in branch.conf it will be used (--remember can change it)
[10:14] <zyga> vila, I keep making branches
[10:14] <vila> zyga: type it once unless you define a default in locations.conf I mean
[10:14] <zyga> I have ~10 branches a day
[10:14] <zyga> http://pastebin.ubuntu.com/545877/
[10:14] <zyga> what does that message mean?
[10:15] <zyga> this is my locations.conf
[10:15] <zyga> http://pastebin.ubuntu.com/545878/
[10:15] <vila> hmm, it may come either from launch-control not being a project defined on launchpad or some weirdness in the stacked-on branches defined on lp (and dev focus too)
[10:16] <zyga> hmm
[10:16] <zyga> launchpad.net/launch-control exists
[10:16] <vila> ok
[10:16] <mok0> Does anyone here have experience maintaining a gnu autotools dependent project in bzr?
[10:16] <vila> may be a missing trailing '/' ?
[10:17] <zyga> let's see
[10:17] <vila> zyga: if you use bzr trunk, 'bzr config' will display the expanded values that apply in the current dir
[10:17] <zyga> vila, I don't use trunk, sorry :/
[10:17] <vila> np np
[10:18] <zyga> vila, is there any difference between lp:~something and the bzr+ssh://longish version?
[10:18] <mok0> I'd like to know what your opinion on the autogenerated files is: do you store them in the repo?
[10:18] <zyga> can I just use the lp: shorthand?
[10:19] <vila> mok0: strictly speaking versioning generated files is... akward, but it may help when creating tarballs, but generally you don't mix the too, you version only files that a re modified by humans
[10:19] <vila> zyga: yes you can
[10:19] <zyga> I hacked the locations conf a bit and bzr info in the branch I'm working on now says: http://pastebin.ubuntu.com/545881/
[10:19] <zyga> it looks good IMHO
[10:19] <zyga> btw, what is submit branch?
[10:19] <mok0> vila: that's exactly the problem I have: "make dist" seems to work at cross purposes of bzr
[10:19] <zyga> I never figured that part out
[10:20] <vila> zyga: the difference is that the lp: shorcuts can be expanded into their http: variant under some circumstances
[10:20] <zyga> vila, yeah I know, if lp-login is not used
[10:20] <vila> zyga: submit_branch is the branch your merge from or against, a bit confusing
[10:21] <vila> mok0: only if you version generated files
[10:21] <zyga> "merge from" ?
[10:21] <zyga> vila, can you give me an example of what command uses that submit_branch?
[10:21] <vila> zyga: when you work on a feature branch and you want to update from trunk (merge new changes)
[10:21] <vila> zyga: merge
[10:21] <vila> zyga: send
[10:22] <vila> zyga: lp-propose :)
[10:22] <zyga> hmm
[10:22] <mok0> vila: well, I don't like to store configure, aclocal.m4 and friends, but that means I need to generate configure, and that fails unless you have all the dependencies installed.
[10:22] <vila> mok0: exactly
[10:22] <zyga> vila, so bzr push worked for me
[10:22] <mok0> Which is aPITA
[10:22] <vila> zyga: don't forget the :policy=append_path bit
[10:22] <zyga> vila, but lp-propose-merge again said that "bzr: ERROR: bzr+ssh://bazaar.launchpad.net/%2Bbranch/launch-control/ is not registered on Launchpad"
[10:23] <mok0> OTOH, storing configure and friends in the repo is a PITA because they keep changing and it pollutes your history
[10:23] <vila> mok0: it's more a work flow issue than a VCS issue per se, but depending on the project they often overlap
[10:23] <mok0> vila: yeah... I was just wandering if anyone had a smart solution
[10:23] <vila> mok0: the question is how you distribute your sources and how you want people to contribute to the project
[10:24] <mok0> vila: I'm not upstream, only trying to maintain a deb package
[10:24] <mok0> vila: and I _need_ to patch configure.ac
[10:24] <vila> mok0: either you version only non-generated files and requires devs to have the generating tools installed or you version the generated files but should ensure you're in sync at commit time
[10:24] <vila> oh, packaging... that's  different :)
[10:25] <vila> mok0: In this case you have the additional issue that upstream may be versioning generated files
[10:25] <mok0> vila: yes, because you do build work etc. in the directory
[10:25] <zyga> vila, okay, one step closer, I removed merge_target and submit_branch from locations.conf, now lp-propose-merge wants to have a reviewer, can I make it use the default reviewer for lp:launch-control somehow?
[10:25] <vila> zyga: search for the stacked-on branch and check that the dev focus is correct too
[10:26] <vila> zyga: isn't it the default ???
[10:26] <zyga> hmm
[10:26] <vila> zyga: -R reviewer ?
[10:26] <zyga> vila, I don't understand either part
[10:27] <vila> zyga: (from 'bzr help lp-propose' I rarely use this command myself)
[10:27] <zyga> vila, I could use that but lp already knows who is the reviewer
[10:27] <vila> zyga: EPARSE
[10:27] <zyga> so I want to avoid having to type that, It must be a configuration issue somewhere
[10:27] <zyga> note: https://code.launchpad.net/~linaro-infrastructure/launch-control/trunk this is the branch I want to submit to this is the development target
[10:27] <vila> zyga: yeah probably
[10:28] <zyga> vila, if I do lp-propose-merge lp:launch-control
[10:28] <zyga> it says: $ bzr lp-propose-merge lp:launch-control
[10:28] <zyga> bzr: ERROR: bzr+ssh://bazaar.launchpad.net/%2Bbranch/launch-control/ is not registered on Launchpad
[10:28] <zyga> did I make a typo I cannot see or is there something wrong here?
[10:29] <vila> zyga: weird, I can 'bzr info' it but not 'bzr config' it :-/
[10:29] <zyga> vila, hmm?
[10:31] <zyga> bzr bug somewhere?
[10:31] <vila> zyga: for bzr config, probably
[10:31] <zyga> vila, how about lp-propose-merge, why does it say that launch-control is not registered?
[10:32] <zyga> do I need to spell out the actual location of the branch: lp:~linaro-infrastructure/launch-control/trunk
[10:32] <vila> zyga: you could try that yes
[10:33] <zyga> that worked but said that no reviewer is specified
[10:33] <zyga> sigh
[10:33] <zyga> how did salgado make this work without passing all those arguments
[10:33] <vila> sounds like a launchpad config issue then
[10:34] <vila> zyga: check with salgado, either he has a different config or you're not part of the same teams ?
[10:34] <zyga> is the maintainer the default reviwer?
[10:34] <zyga> we are both part of the ~linaro-infrastructure team
[10:34] <vila> but who review the proposals ?
[10:34] <zyga> that team
[10:34] <vila> is it properly configured on lp ?
[10:34] <vila> 'it' being vague :)
[10:35] <zyga> vila, good question, how can I check that
[10:35] <zyga> https://launchpad.net/launch-control
[10:35] <zyga> maitainer is set
[10:35] <vila> but not driver ?
[10:35] <zyga> no, driver is not set
[10:35]  * zyga never understood what that really meant
[10:35]  * vila neither :)
[10:36] <zyga> I set the driver too
[10:36] <zyga> let's see if lp-propose-merge will work now
[10:36] <zyga> nope
[10:37] <zyga> I just want this whole review thing to get out of my way ;-)
[10:37] <vila> zyga: hmm, I think that's something that should be specified on the target branch or something
[10:37] <zyga> vila, thanks for all the help
[10:37] <zyga> target branch being?
[10:37] <zyga> trunk?
[10:37]  * vila looks at the bzr lp project
[10:38] <vila> zyga: there is a review team for lp:bzr
[10:38] <zyga> bzr info does not say
[10:38] <vila> zyga: it's a launchpad thing
[10:38] <vila> zyga: look at https://code.launchpad.net/~bzr-pqm/bzr/bzr.dev
[10:39] <vila> there is a review team there, but nothing comparable on launch-control (may be because I'm not part of the team there, can't say for sure)
[10:41] <mok0> Is there a special channel for discussing packaging in bzr?
[10:41] <mok0> Or is that here :-P
[10:41] <vila> mok0: here is fine
[10:41] <mok0> vila, thanks
[10:42] <vila> mok0: #ubuntu-devel may be better if you're targeting Ubuntu (or even debian)
[10:42] <mok0> So now I am wondering, should I just make all changes in the autobuild system that I need on my bzr branch
[10:42] <mok0> ... and somehow create my package from that
[10:42] <vila> mok0: you're *creating* a package ?
[10:42] <mok0> vila: ytes
[10:42] <mok0> yes
[10:43] <mok0> Upstream doesn't provide a recent tarball, source is distributed via svn
[10:43] <vila> mok0: hmm, I'll be on limited help then, I don't have a significant experience here
[10:43] <mok0> I have it mirrored in an LP project
[10:43] <vila> good
[10:43] <mok0> Then I have a branch off that called "ubuntu" :-)
[10:43] <vila> mok0: you're targeting Ubuntu ?
[10:43] <mok0> vila: for now, yes
[10:44] <vila> mok0: did you look at bzr-builddeb ?
[10:44] <mok0> vila: I've used it now and then, but I found it got in my way
[10:44] <vila> mok0: you should definitely ask in #ubuntu-devel and file bugs when it gets in your way !
[10:44] <mok0> I wasted hours until I discovered that it stashes away its own copy of the tarball in the buildarea
[10:45] <mok0> I couldn't understand WFT was going on
[10:45] <vila> mok0: I don't know the details but there are several possible workflows, with a bit luck you're just not using the right one
[10:45] <mok0> vila: perhaps yes
[10:46] <mok0> vila: and then there's quilt..........
[10:46] <zyga> vila, checking
[10:46] <vila> mok0: james_w wrote a very succint document about that, but I don't remember if/where it's published
[10:46] <zyga> vila, sorry, my son is ill and needed some help
[10:46] <vila> zyga: that's a *priority* interrupt
[10:46] <mok0> vila, lemme see if mr. Google will come to my help :-)
[10:48] <zyga> vila, the review team _is_ set
[10:48] <zyga> https://code.launchpad.net/~linaro-infrastructure/launch-control/trunk/+reviewer
[10:48] <zyga> I can see linaro-infrastructure as the reviewer
[10:48] <vila> zyga: no permission to look at that
[10:49] <zyga> vila, right but it's set there
[10:49] <mok0> vila, would you be referring to this? https://wiki.linaro.org/BzrIntroduction
[10:49] <zyga> I think lp might not show the reviewer if it's the same as owner
[10:49] <vila> zyga: :-/ I'm out of my league then
[10:49] <vila> mok0: no, it was one with pretty pictures :)
[10:50] <vila> mok0: but james_w is mentioned so you're on the right track ;)
[10:51] <mok0> vila, hehe. I found this now, it looks like I need to read that: http://jameswestby.net/bzr/builddeb/user_manual/
[10:52] <mok0> No pretty pictures though
[10:52] <vila> mok0: certainly a must read :)
[10:54] <vila> mok0: may be https://wiki.ubuntu.com/UbuntuDevelopment/ is a good starting point too
[10:55] <mok0> vila: Indeed... thought it mostly looks like a link-collection
[10:55] <vila> mok0: could be, but #ubuntu-devel can better answer than me for that
[10:56] <mok0> vila: you've been most helpful, thanks
[10:56] <vila> mok0: np, happy to help but I know bzr better than packaging (I'm learning though ;)
[10:57] <mok0> vila: I think  dvcs packaging is very much in its infancy
[10:57] <vila> mok0: yup, actively working on though ;)
[10:58] <mok0> vila: AFAIK you still need a tarball
[10:58] <mok0> vila: which is kinda crazy if the source can be pulled from a branch and you can construct the debian/ from the packaging branch
[10:58] <vila> mok0: that's the part I'm unsure about (since I always start with a bzr branch myself)
[10:59] <vila> mok0: that's what 'pristine tar' is about: re-create tarballs from a branch
[10:59] <mok0> vila: then that's a new definition... it used to be "the tarball you download from upstream"
[11:00] <mok0> vila: anyway, I don't see there's a need for tarballs
[11:00] <vila> mok0: but for many operations builddeb re-creates the tarball from the branch
[11:00] <mok0> vila: I know... as I wrote above, I was burned by that
[11:00] <vila> so instead of downloading it from upstream you just use the equivalent version
[11:01] <mok0> vila: because when you edit edit edit in the branch, the old tarball is still sitting there :-(
[11:01] <vila> mok0: which is why I think you may not be using builddeb as intended
[11:01] <mok0> vila: and so it seems your edits are gone
[11:01] <mok0> vila: perhaps you are right
[11:02] <vila> mok0: because you seem to be doing 'normal' things, so builddeb should know how to deal with them
[11:02] <mok0> vila: which is why I'd like to see a description of a proper workflow
[11:02] <mok0> vila: I agree
[11:02] <vila> mok0: have you read the user manual you pointed above ?
[11:03] <mok0> vila: not yet ... I'm not THAT fast :-)
[11:04] <vila> mok0: hehe, just checking, but I'm 60% sure you'll find many answers there
[11:04] <mok0> vila: I am sure I kan learn a lot
[11:04] <mok0> s/kan/can
[13:52] <johnf> I'm running bzr annotate filename and I'm getting something like "bzr: ERROR: The file id "file-20060906040903-s4f1zy3gz43haztt-3" is not present in the tree" any ideas as to what the problem could be?
[13:58] <jelmer> hi johnf
[13:58] <johnf> jelmer: howdy
[13:58] <jelmer> johnf: I thought you were based in .au ?
[13:58] <jelmer> johnf: In what context?
[13:58] <johnf> jelmer: I usually am. In Germany for the holidays
[13:59] <johnf> jelmer: Let me pastie the whole thing
[13:59] <jelmer> johnf: Ah, nice. Enjoying the snow ? :-)
[14:00] <johnf> jelmer: Yes :) I've never really experienced snow before. This is totally surreal!
[14:01] <johnf> jelmer: sent you the pastie privately since it has some email addresses etc I'd rather not make public :)
[14:01] <jelmer> johnf: np
[14:02] <jelmer> johnf: what's the status of that file in the current working tree?
[14:03] <johnf> jelmer: Hmm OK maybe I'm doing something dumb
[14:04] <johnf> I have a branch which is currently up to rev130 and I've done this "bzr up -r 20; bzr annotate file"
[14:04] <johnf> that is when I get the error
[14:04] <johnf> if instead I do "bzr branch -r 120 orig  copy; cd copy; bzr annotate file" it works fine
[14:05] <johnf> should the first approach work?
[14:05]  * jelmer wonders what "bzr up -r" does exactly
[14:07] <johnf> jelmer: yeah I think that't the problem. It makes the working tree the same as rev 20. But I think when I run say the annotate command it is still working on revision 130 where the file no longer exists
[14:22] <jelmer> johnf: does "bzr status" report a lot of changes?
[14:22] <jelmer> johnf: You might want to try "bzr annotate -r -1 <filename>" or "bzr annotate -r 120 <filename>"
[14:23] <johnf> jelmer: bzr status says "working tree is out of date, run 'bzr update'"
[14:23] <jelmer> johnf: ah, so "bzr up" only changes the working tree, not the branch
[14:24] <johnf> jelmer: yeah. Adding -r to annotate worked fine
[14:32] <ThiasG> Hello, thank you for making bazaar available. We switched recently from git to bazaar.
[14:32] <ThiasG> Now a coworker hat done a bzr rmbranch bzr+ssh://bazaar@bzr.openpetra.org:2208/openpetra/trunk
[14:32] <ThiasG> Is there an easy way to undo this change?
[14:35] <jelmer> ThiasG: hi
[14:35] <jelmer> ThiasG: You should be able to run "bzr heads --dead" to find the previous tip revision
[14:37] <jelmer> after that you should be able to create that branch again and then update it to that revision using "bzr pull -rrevid:<revid> ."
[14:38] <ThiasG> I found the revid.
[14:39] <ThiasG> The branch I just create with bzr init bzr+ssh://bazaar@bzr.openpetra.org:2208/openpetra/trunk ?
[14:41] <jelmer> ThiasG: yep
[14:41] <jelmer> ThiasG: if you don't have local access you'll need a somewhat more complicated pull command
[14:41] <jelmer> ThiasG: rather than using "." you should probably specify the same branch URL, once for the target (with -d) and once as source
[14:42] <ThiasG> I have local access to the shared repo.
[14:42] <ThiasG> In the trunk dir, I typed in bzr pull -rrevid:timotheus.pokorra@solidcharity.com-20101220135316-3qbh20dt0fkwi811
[14:43] <jelmer> ThiasG: you'll probably need the "." after that as well, unless the default pull location has that revision
[14:43] <ThiasG> But this gave me "bzr: ERROR: No pull location known or specified."
[14:43] <ThiasG> okoay
[14:43] <ThiasG> Now he is working
[14:44] <ThiasG> All changes applied successfully.
[14:44] <ThiasG> Now on revision 1035.
[14:44] <ThiasG> I'm finished?
[14:44] <jelmer> should be, yeah
[14:45] <ThiasG> Is it correct, that I could remove the content of the trunk directory except the .bzr directory? It is the shared remote repo.
[14:46] <jelmer> ThiasG: yes; "bzr rmtree" should do that for you
[14:47] <ThiasG> I dod a bzr status, which gave me 8 modified files.
[14:48] <jelmer> if there are modified files you should probably check why they are modified, just in case they're changes you'd like to keep..
[14:49] <ThiasG> Okay, thank you very much for your help.
[14:50] <ThiasG> Does someone already have a hook for restricting removing of branches? Otherwise I have to write one ;-)
[14:56] <jelmer> I don't think there is anything like that at the moment
[14:58] <ThiasG> Aber dann ist es nicht so tragisch. Ich checke sie ein, oder?
[14:58] <Tak> ja, selvfølgelig!
[14:59] <ThiasG> Sorry, wrong channel...
[15:05] <ThiasG> Just for completeness: The command for removing the working tree is "bzr remove-tree"
[15:06] <ThiasG> Thank you for your fast help :-)
[17:26] <mhall119> hi, I'm using bzrlib to do the equivilent of "bzr branch $src $dst"
[17:27] <mhall119> given a remove url for $srf
[17:27] <mhall119> and a local file path for $dst
[17:27] <mhall119> I have:
[17:27] <mhall119> src_branch.create_clone_on_transport(get_transport(destination), revision_id=rev_id)
[17:27] <mhall119> but that doesn't give me a working tree in $destination
[17:27] <mhall119> what am I doing wrong?
[17:31] <jelmer> mhall119: that's correct, branch.create_clone_on_transport() only creates a branch (and copies revisions where necessary)
[17:32] <jelmer> you can create a tree later by calling bzrdir.create_workingtree()
[17:46] <mhall119> that did the trick, thanks a bunch
[17:46] <jelmer> np
[21:15] <lifeless> mgz: hi
[21:31] <mgz> hey lifeless.
[23:31] <mkanat> spiv: Thanks for acknowledging and helping clarify that bug.
[23:43] <spiv> mkanat: you're welcome :)
[23:43] <mkanat> :-)