[00:55] <igc> morning
[03:30] <mwhudson> lifeless, spiv : how close is lp:~spiv/bzr-builder/refactor to landing?
[03:32] <spiv> mwhudson: hmm
[03:32] <mwhudson> also, what does it do?
[03:35] <lifeless> mwhudson: james_w needs to get back from UDS :)
[03:36] <mwhudson> lifeless: that makes sense i guess
[03:36] <spiv> mwhudson: that branch has some simple refactoring on top of lp:~lifeless/bzr-builder/bug-469874 that is used by lp:~spiv/bzr-builder/merge-subdirs-479705
[03:37] <mwhudson> sounds like a fun stack of not-landed branches
[03:37] <spiv> mwhudson: basically a replaces a list of 2-tuples where (*, None), (None, *) and (None, None) all mean different things, and replaces them with objects
[03:38] <spiv> mwhudson: and replaces case statements about that with good ol' polymorphism
[03:38] <lifeless> mwhudson: why do you ask?
[03:38] <mwhudson> lifeless: just poking at bzr-builder
[03:39] <spiv> The names I gave to the objects and methods can be improved, but the shape is certainly much nicer (and made merge-subdirs-479705 fairly straightforward).
[03:40] <spiv> Hmm, I guess I should make some merge proposals for those, not sure why I hadn't done that yet.
[03:42] <lifeless> spiv: you get to use the new dependent branches feature ;)
[03:45] <Kamping_Kaiser> does bzr have something like gits add --interactive? (allows commiting chunks of your current diff)
[03:45] <spiv> lifeless: indeed :)
[03:46] <spiv> Merge requests filed.  That should keep james_w busy for a while :)
[03:46] <spiv> Kamping_Kaiser: "bzr shelve", you can shelve the parts you don't want to commit yet, then bzr commit, then bzr unshelve.
[03:46] <Kamping_Kaiser> spiv: thanks, I'll have a go
[03:58] <poolie> igc: still around?
[03:58] <poolie> hi spiv, mwh
[03:58] <mwhudson> poolie: hello
[03:58] <Kamping_Kaiser> spiv: that works a treat, thanks.
[04:14] <lifeless> spiv: so you proposed the branch to my branch, not to trunk?
[04:14] <lifeless> spiv: oh nevermind, LP confused me
[04:19] <poolie> !!!
[04:19] <poolie> :-)
[04:26] <lifeless> yeah, news @ 11
[04:40] <bob2> lol
[04:44]  * GaryvdM is back (gone 07:00:57)
[08:14] <RenatoSilva> is there a way to bzr diff all non .xyz files?
[08:17] <bob2> you can use filterdiff (not part of bzr)
[08:19] <RenatoSilva> ok thanks anyway
[09:30] <tumbleweed> so, I've got a bot that's polling bzr branches on lp, and I'm getting RevisionNotPresent exceptions sometimes http://paste.pocoo.org/show/nHK9f5k22Vt40innuE6i/
[09:30] <tumbleweed> code in question: http://bazaar.launchpad.net/%7Estefanor/ibid/icecast/annotate/head%3A/ibid/plugins/bzr.py
[09:31] <tumbleweed> should I just ignore the exception and try again in a bit?
[09:43] <lifeless> tumbleweed: yes, I guess.
[09:48] <MvG> Hi! Trying to push a branch to lp failed at fist try ("different serializers") but succeeded at second try: http://pastebin.com/m27e603bb
[09:48] <MvG> Is this a bzr issue or a launchpad issue?
[09:59] <Peng> That's clever! The failure on the first push leaves enough around that the second push doesn't try to auto-stack. I'll have to remember that!
[10:00] <Peng> MvG: *Probably* a bzr bug, but I'm not going to set something equivalent up off-LP to verify it.
[10:01] <Peng> Note to self: File a bug about stacking being broken on staging...
[10:02] <MvG> So basically it is known current behaviour that auto-stacking doesn't work (due to some difference in repo formats?), and the fact that it worked the second time is more like a bug? Should I file anything?
[10:02] <Peng> MvG: What format is your local branch? If it's 2a, than yes, it's known behaviour that stacking fails.
[10:03] <Peng> MvG: Err, I mean, *not* 2a.
[10:03] <MvG> Format is 2a, according to "bzr info ..", where .. is the shared repository.
[10:04] <Peng> MvG: Oh, my mistake. You're using 2a, but lp:~trac-bzr-team/trac-bzr/trunk is on an older format.
[10:04] <Peng> MvG: What happened is that the first push created some of the control directories before it realized the format difference and exited. On the second push, since they existed, it didn't try to stack, so you didn't run into the format issue.
[10:05] <MvG> I understand.
[10:05] <Peng> MvG: Umm, I think it's worth filing, although I'm not sure it's worth fixing. :P
[10:06] <MvG> OK. will do so.
[10:10] <MvG> Peng: How do you tell lp:~trac-bzr-team/trac-bzr/trunk is older format? bzr info doesn't seem to help me there.
[10:18] <Peng> MvG: The error message said it was a KnitPackRepository. 2a is CHKInventoryRepository.
[10:18] <MvG> Ah, I see.
[10:20] <Peng> MvG: FYI, in bzr.dev, "bzr info -v" gives useful format information for branches accessed over the smart server.
[10:20] <Peng> MvG: In older versions, you can prepend "nosmart+" to the URL to force VFS access, e.g.: bzr info nosmart+lp:~trac-bzr-team/trac-bzr/trunk
[10:20] <Peng> MvG: (I mean, you can do it in bzr.dev too, you just don't need to...)
[10:21] <MvG> All of these give me info about the branch, but not about the repository format...
[10:22] <Peng> MvG: It included all of it.
[10:23] <MvG> In the Format section it says "repository: bzr remote repository"
[10:23] <MvG> Ah, works now...
[10:23] <MvG> Had been using an older bzr setup here without realizing it...
[10:24] <MvG> filed https://bugs.launchpad.net/bzr/+bug/484685
[10:32] <Glenjamin> hi guys, after running the bzr check command, i'm told there are ghost revisions and inconsistent parents
[10:33] <Glenjamin> is there a way to resolve these somehow?
[10:33] <Glenjamin> did those messages get blocked by the network for not being registered?
[10:34] <bob2> no
[10:34] <Glenjamin> ah good, the freenode error message isn't all that clear :)
[10:34] <bob2> 'bzr reconcile' should fix the inconsistent parents, I think (backup your branch/repository first)
[10:36] <Glenjamin> right, is there anything i can do about ghost-revisions? (and what are they?)
[10:44] <Peng> Glenjamin: Ghosts are revisions that your repo doesn't actually have a copy of.
[10:45] <Glenjamin> i was having issues with bzr-svn in a 2a repository
[10:45] <gioele> Glenjamin: what kind of branch is that? A git or svn import?
[10:45] <Glenjamin> i started again with 1.14-rich-root and it seems fine now
[10:45] <Glenjamin> i did checkout(from svn) branch(locally) push(to svn), and it have an error about parent revisions
[10:46] <gioele> Glenjamin: is it happening every time?
[10:46] <Glenjamin> it was with the 2a format, yes
[10:56] <Glenjamin> cheers for the help guys :)
[11:13] <bialix> hi, any core devs here?
[11:15] <spiv> I half am
[11:16] <bialix> ho! spiv!
[11:16] <bialix> hello spiv
[11:16] <bialix> I have 2 problems
[11:16] <spiv> Good evening :)
[11:16] <bialix> for you evening, for me afternoon :-)
[11:17] <bialix> 1) We have a problem with reconfigure of light checkout of bzr:// branch
[11:17] <bialix> spiv: I've fwd'd mail from qbzr ML about this problem
[11:17] <bialix> spiv: if you have any ideas how to debug this problem I'll be very appresiated
[11:17] <bialix> spiv: if you have any ideas how to debug this problem I'll be very appreciated
[11:18] <bialix> 2) it seems 2a (or rich-roots) broke merge -r0..-1 when files have the same file-id
[11:19] <spiv> 1) Interesting!  That seems quite weird.
[11:21] <spiv> As for 2), I would have expected that would get conflicts with or without 2a, or does it fail worse than merely conflicting?
[11:22] <bialix> spiv: 2) doesnot happens with pack-0.92 aka poor-rootsz
[11:23]  * bialix pastebins
[11:23] <bialix> spiv: see Makefile: http://pastebin.com/m1324b1ae
[11:24] <bialix> spiv: with 2a format I've got path conflict
[11:24] <bialix> with pack-0.92 I've got good merge
[11:26] <bialix> and with rich-root-pack too
[11:26] <bialix> rich-rot-pack -> conflict
[11:28] <bialix> bug https://bugs.launchpad.net/bzr/+bug/484706
[11:29] <spiv> Yeah, I think it's a rich-root thing.  I think a conflict is reasonable in that case, I'm not sure why non-rich-root wouldn't conflict (in fact I'm tempted to think that's the bug, not the rich-root case).
[11:31] <spiv> I don't see a good reason for it to be inconsistent, so there's certainly some sort of bug there.
[11:33] <bialix> spiv: I think non-rich-root behavior is *right* actually
[11:33] <bialix> there is good reason to split big branch into 2 and then merge between them
[11:34] <bialix> spiv: if you have any ideas about 1) I'd like to get some hints
[11:34] <spiv> Well, I cna see an argument for allowing it, for the same reason we treat a merge that applies the exact same change as being clean.
[11:34] <spiv> I don't have a strong opinion either way, but my initial expectation was that it should conflict.
[11:35] <bialix> spiv: all this file-ids thingy is good only for 1 reason -- to track renames. But there is a lot of other reasons when file-ids only bad thing
[11:35] <bialix> parallel imports et al
[11:35] <spiv> And if the content isn't identical it certainly should.
[11:37] <bialix> should -> what?
[11:37] <spiv> Should conflict.
[11:37] <bialix> if content is not identical it produce text conflict (for pack-0.92 format) and this is very good
[11:38] <bialix> but path conflict is not good
[11:41] <spiv> For 1), I think I see the bug in remote.py
[11:42] <spiv> It doesn't look like RemoteRepositoryFormat.initialize copes properly with a non-RemoteBzrDir argument, even though there's some code to try handle that case.
[11:44] <spiv> It's getting late here, but I'll send an email summarising what I see.
[11:47] <bialix> ok, thanks
[11:58] <RenatoSilva> is there any work/registered idea anywhere about "semantic/smart" diffs?
[11:58] <RenatoSilva> for example, diff ignoring white spaces
[11:58] <RenatoSilva> another example, CSS diff
[11:58] <bob2> already possible
[11:58] <bob2> bzr diff --using=whatever
[11:59] <bob2> '--using=diff --diff-options=-w' will ignore whitespace
[12:00] <RenatoSilva> great :) but that's just an example
[12:01] <bob2> sure
[12:01] <bob2> if a semantic css diff program exists, bzr can use it
[12:01] <RenatoSilva> I have had trouble with comparing css, and I thought it would help me if the diff algorith was "smart"
[12:02] <RenatoSilva> bob2: ok I'm being sort of offtopic because I don't know a right channel to ask, as the subject is cross-channel
[12:02]  * RenatoSilva trying to remember a use case for a "semantic" css diff
[12:02] <RenatoSilva> * recall
[12:04] <RenatoSilva> hum, ordering, for example p {\n color: #333;\n margin: 0px; \n} should be considered the same as p {\n margin: 0;\n color: #333;\n}
[12:04] <spiv> bialix: sent
[12:06] <spiv> RenatoSilva: sure, but bob2's answer still seems applicable
[12:06] <RenatoSilva> this becomes annoying when you have a lot of stuff like this and among these lines only 1 or 2 that really matter
[12:06] <RenatoSilva> spiv: ok sorry, will stop now :)
[12:07] <spiv> RenatoSilva: that is, bzr can already cope with that, you just need to tell it to use a diff program that knows how to do the diff you want.
[12:07] <spiv> And if that diff utility doesn't exist yet that isn't exactly a bzr issue :)
[12:08] <spiv> (Although if there's some way in which bzr might help, then that would be worth discussing, but from what I see so far probably not)
[12:08] <spiv> Anyway, bedtime for me.
[12:08] <RenatoSilva> spiv: ok, actually I want those programs, which I'm afraid to exist
[12:11] <RenatoSilva> I'm afraid to not exist
[12:13] <bialix> spiv: many thanks
[14:42] <jam> morning all
[14:45] <bialix> hello jam
[15:09]  * bialix akways enjoys reading jam's articles
[15:09]  * beuno remembers jam's "this week in bazaar"
[15:10] <jam> beuno: blame statik, he left me and TWiB fell apart
[15:12]  * beuno looks at statik with disapointment
[15:14] <bialix> beuno: ya, this week journal was very cool
[15:21] <henninge> Hi! I am using bzr-pipline for the first time.
[15:22] <jam> wadesworld: ping if you get some time to help debug the sftp stuff
[15:22] <henninge> I had made some changes in the last pipe and then switched to another pipe w/o committing the changes.
[15:23] <henninge> Now show-pipeline displays the "U" next to this pipe.
[15:24] <henninge> I returned to that pipe (so show-pipeline show "*U") but I don't see the uncommitted changes, at least not with "status" or "diff". Do I need to restore them somehow?
[15:26] <gioele> henninge: try "bzr shelve --list", maybe the uncommited changes have been shelved
[15:27] <henninge> gioele: "No shelved changes"
[15:27] <henninge> gioele: rockstar also explained to me last week that pipelining is different from shelving.
[15:28] <rockstar> henninge, bzr unshelve
[15:28] <rockstar> henninge, when you change to another pipe, bzr automatically shelves the changes for you.
[15:29] <henninge> rockstar: but does not automatically unshelve when I return?
[15:29] <jam> henninge: I believe that is true
[15:29] <gioele> rockstar: but "bzr shelve --list" says that there is nothing to unshelve
[15:29]  * henninge hasn't used shelve/unshelve before either
[15:29] <jam> switch-pipe shelves but does not unshelve
[15:29] <rockstar> henninge, so shelving is part of pipelines, but last week, the discussion was about shelving doing the same as pipelines, which is untrue.
[15:29] <jam> partially because "bzr merge --uncommitted ..." is able to pull stuff out of the shelf
[15:29] <henninge> ah
[15:30] <rockstar> henninge, I use shelves when I have some changes I'd like to keep instead of revert, but I need to commit something else before I commit those changes.
[15:31] <rockstar> It's kind of like limbo for changes.  Not heaven or hell.
[15:31] <henninge> rockstar: bzr unshelve also says, there is nothing on the shelve.
[15:31] <henninge> rockstar: ;)
[15:31] <rockstar> henninge, when you do bzr pipes, what does it say?
[15:31] <rockstar> Er, bzr show-pipeline
[15:31]  * rockstar always forgets that he has aliases
[15:32] <henninge> pipes works, too ...
[15:32] <henninge> rockstar: "*U pipename"
[15:32] <rockstar> henninge, and bzr status
[15:32] <henninge> rockstar: nuttin'
[15:33] <rockstar> abentley, ^^
[15:33] <henninge> rockstar: I have to say that I added and deleted a pipe and had a conflict which I resolved
[15:33] <rockstar> henninge, that shouldn't affect your changes that should have been shelved.
[15:33] <rockstar> henninge, I must consult the pipeline gods.
[15:34] <abentley> jam: switch-pipe also unshelves.
[15:34] <henninge> I also tried "merge --uncommitted" (because I read that in the help somewhere) and it failed
[15:34] <rockstar> abentley, I thought it did.
[15:34] <jam> abentley: would make sense to be symmetric
[15:34] <jam> what if you have multiple shelved patches?
[15:34] <jam> just the last one?
[15:34] <abentley> jam: There's only one.
[15:34] <rockstar> abentley, it sounds like something's wrong with how changes got shelved.
[15:35] <jam> abentley: so 'bzr shelve' doesn't interact with the actual 'shelf' that is being used?
[15:35] <henninge> here is the failure: http://paste.ubuntu.com/321609/
[15:35] <abentley> jam: Indeed.
[15:35] <henninge> oh, that is mostly explanatory text
[15:35] <abentley> jam: The shelved changes are stored in the branch, not the working tree.
[15:36] <rockstar> Ah, that's clever.
[15:36] <rockstar> So bzr unshelve shouldn't actually unshelve the changes.
[15:36] <henninge> here is the crash file: http://paste.ubuntu.com/321612/
[15:36] <abentley> rockstar: Right, and I also try to avoid referring to it as shelving.
[15:36] <rockstar> henninge, try switching away from the pipe and switching back.
[15:37] <rockstar> abentley, yes, I can see why now.
[15:37] <abentley> henninge: doing "switch-pipe" to return to the pipe with the stored changes should restore them.
[15:38] <abentley> henninge: The crash you're getting is because you didn't specify a pipe to merge from.
[15:38] <henninge> rockstar: yup, that helped
[15:38] <rockstar> henninge, so it's working now?
[15:39] <henninge> rockstar: yes, bzr status show my changed files again
[15:39] <henninge> show
[15:39] <henninge> s
[15:39] <rockstar> henninge, great
[15:39]  * rockstar scurries off to find a quiet hacking place
[15:39] <henninge> rockstar: thanks
[15:39] <henninge> rockstar: go to your room!
[15:39] <henninge> ;-)
[15:40] <henninge> abentley: thanks, too.
[15:42] <abentley> henninge: I have filed bug #484846 about the merge issue.
[15:45] <abentley> rockstar: btw, "pipes" is an automatic alias for show-pipeline now.
[15:45] <rockstar> abentley, hooray!
[15:45] <abentley> henninge: Is it possible that when you originally returned to the pipe, you used "switch", not "switch-pipe"?
[15:46] <rockstar> abentley, actually, I found out last week that basically everyone at the lazr-js sprint using pipes were using my aliases.  I thought about submitting a patch to make those aliases official.
[15:47] <abentley> rockstar: Well, I'm not sure about all of them, but just submit your aliases and I'll look them over.
[15:47] <henninge> abentley: "history | grep switch" only return switch-pipe ...
[15:47] <henninge> rockstar: pdiff and pstatus? Very useful.
[15:48] <rockstar> abentley, cool.  Well, now that I see the aliases I use, they shouldn't all go up, but EVERYONE was using next and prev.
[15:48] <rockstar> ...as well as pipes, which is now upstream anyway.
[15:49] <henninge> rockstar: where do I find "your" aliases?
[15:49] <abentley> henninge: Okay, I'll look into why it didn't restore the changes.
[15:50] <abentley> rockstar: I don't get "next" and "prev".  I use switch-pipe :last at least as often as switch-pipe :next.  So I've aliased "switch-pipe" to "swp".
[15:50] <rockstar> henninge, http://theironlion.net/blog/2009/08/26/5-must-have-aliases-bzr-pipeline/
[15:50] <rockstar> I have a few more now, but they aren't anything special.
[15:50] <rockstar> And send-pipe is silly to have now anyway, since Launchpad ignores the bundle you send through email now.
[15:51] <rockstar> abentley, maybe there should be a bzr last then as well.
[15:51] <abentley> rockstar: Anyhow, "next" and "prev" can't be automatic aliases.  Only command name abbreviations can be automatic.  But they could go in "help pipelines".
[15:51] <rockstar> abentley, ah, yeah.  You're right.
[15:52] <rockstar> abentley, okay, so it's more a doc patch now.  I can live with that.
[15:52] <abentley> rockstar: It doesn't ignore the bundle.  It just has a tendency to fail to apply it correctly.
[15:53] <abentley> rockstar: i.e. to give an incomprehensible oops.
[15:53] <rockstar> abentley, well, as far as the UI is concerned, it ignores it, because the preview diff is what's displayed.
[15:53] <rockstar> abentley, it's a moot point with pre-req branches though.
[15:54] <abentley> rockstar: The diff was never part of the bundle, it's part of the merge directive.
[15:54]  * rockstar facepalms
[15:54] <rockstar> That's what I meant.  I blame UDS and lack of sleep.
[15:55] <abentley> rockstar: actually, I tell a lie.  In bundle format 0.9 and earlier (bzr 0.18 and earlier), the diff *was* part of the bundle.
[15:57] <abentley> rockstar: Anyhow, there's a new lp-submit in the very latest pipelines that uses the LP API to create merge proposals.
[15:57] <abentley> rockstar: You get prerequisite branches automatically.
[15:57] <rockstar> abentley, wonderful.
[15:57] <rockstar> abentley, and the diff is generated correctly?
[15:58] <abentley> rockstar: Yes.
[15:58] <rockstar> Niice!</borat>
[16:07] <Peng> Is there a 2a copy of MySQL somewhere for those too impatient to spend 2 days converting it? :D
[16:07] <henninge> abentley: I have another crash for you ... http://paste.ubuntu.com/321629/
[16:07] <Peng> (I don't really care what branch; I just want it for testing.)
[16:08] <brmassa> guys, show can i create a patch between 2 revisions?
[16:08] <Peng> brmassa: What for?
[16:08] <abentley> henninge: Your bzr C extensions are not up to date with your bzr.
[16:09] <henninge> abentley: how do you see that and how do I fix that?
[16:10] <abentley> henninge: You're running bzr from a package, right?  If so, only the packager can fix it.
[16:10] <henninge> abentley: from the nightly ppa.
[16:11] <brmassa> Peng: well... i created a branch for each x.x.x, 1.x.x and 1.1.x version of my app. now i submited some some to the minor branch (1.1.x), i want to generate a patch to apply into higher levels/versions
[16:11] <abentley> henninge: I know that it's a C extension problem only because I've experienced it myself, and since I run from source, I did "make" and it fixed it.
[16:11] <henninge> Woa! bazaar-vcs got a new look!
[16:11] <Peng> brmassa: You should have done it the other way around so you could "bzr merge".
[16:12] <Peng> brmassa: Make the change to the oldest branch, then "bzr merge" it into the newer branches.
[16:12] <abentley> jam: henninge's running from the nightly PPA, but his StaticTuple is incompatible with his bzr.  Who takes care of that packaging?
[16:13] <jam> Peng: I don't believe there is. I think they've talked about upgrading, and I believe 'drizzle' has switched to 2a, but I'm not sure if drizzle is the full mysql history, etc.
[16:13] <abentley> henninge: Perhaps you can switch to the bzr beta PPA temporarily?
[16:13] <jam> abentley: the daily just needs to be rebuilt, there was a fix for that which has been around since 2.1.0b3
[16:13] <jam> I thought james_w was doing dailies
[16:14] <jam> afaik, none of the 2.1 series was built into bzr-beta-ppa
[16:14] <jam> johnf didn't have enough tuits
[16:14] <Peng> jam: Thanks.
[16:14] <abentley> jam: I suspect james_w will be busy this week...
[16:14] <henninge> abentley: that is not 2.1 yet, I tried that first. bzr-pipeline only works with 2.1, so it told me ...
[16:14] <Peng> jam: MySQL's history is about 2000 revisions longer than Drizzle's, so I guess it doesn't. Darn.
[16:14] <henninge> abentley: I am running bzr-pipeline from source
[16:15] <brmassa> Peng: well... at one point all 3 branches were the same, but since 1.1.x is focused on bug fixing only and the other 2 includes new features, the codes might diverge...
[16:15] <henninge> maybe I should just run bzr from source, too
[16:15] <abentley> henninge: lp:bzr-pipeline/stable works just fine with 2.0
[16:15] <jam> Peng: well, you really need to compare via "bzr ancestry" and not "bzr revno"
[16:15] <jam> but yeah, they might have started with a fresh codebase
[16:15] <henninge> abentley: ah, I could change that
[16:15]  * Peng didn't know about "bzr ancestry".
[16:15] <Peng> jam: Ehh, true.
[16:16] <Peng> brmassa: OK, um, commit your changes to the bugfix branch, then "bzr merge" that branch into your newer branches.
[16:16] <jam> brmassa: you can alwyays do "bzr diff -c REVNO" or "bzr merge -c REVNO", or .. create a daggy fix as Peng mentions
[16:17] <brmassa> thanks guys... its just matter of getting used to the commands and concepts.
[16:17] <Peng> "bzr merge -c" does a cherrypick?
[16:20] <CoffeeIV> how can I tell what will change from a bzr up command before actually doing it ?  bzr up doesn't seem to take the --dry-run option
[16:22] <brmassa> Peng: its working. now, is there a way to use the same commit messages used in the original branch while commiting the merge?
[16:25] <brmassa> of course without manually writting it...
[16:28] <Peng> brmassa: You can copy and paste... :D
[16:28] <brmassa> Peng: yep. i was wondering about a parameter to to this automatically
[16:47] <skx> what do I need to install to get bazaar explorer? I'm on ubuntu
[16:48] <skx> got it
[16:48] <skx> wow, you really managed to hide that info ;)
[16:50] <LarstiQ> we did?
[19:29] <Peng> Augh! "bzr pull" on MySQL died after almost 2 hours and 200-300 MB of bandwidth, losing all of hte progress it had made! :(
[19:38] <mrooney> hey, I ran into an initially confusing situation, I just wanted to see if it was a bug or expected behavior
[19:38] <mrooney> if I have a directory under VC foo, and I do bzr mv foo bar/baz when bar doesn't exist, I get the error "bar is not versioned"
[19:39] <mrooney> so I spent a while trying to figure out what that means, because it was obvious to me it wasn't versioned since it doesn't exist
[19:39] <LarstiQ> mrooney: while correct, I agree
[19:39] <LarstiQ> "bar doesn't exist" would be more helpful
[19:40] <mrooney> yes it would have been much more helpful
[19:40] <LarstiQ> mrooney: mind filing a request for that?
[19:40] <mrooney> sure
[19:40] <LarstiQ> thanks
[19:40] <mrooney> it would be great if there was an option to create the directories if needed
[19:42] <mrooney> I keep hitting it over and over when restructing projects, "oh this file needs to be in a directory"
[19:43] <LarstiQ> what kind of restructuring is that?
[19:44] <LarstiQ> in my use I usually need a directory when I have multiple files already
[19:45] <mrooney> what is your fear of automatically creating directories? people typoing a mv when they expect the dir to exist, and silently getting a new one?
[19:45] <LarstiQ> I haven't thought it through
[19:45] <LarstiQ> but my fear is overloading mv even more than it already is
[19:45] <mrooney> any sort of cleaning up a project, where I accumulate too many files in a directory and want to mv them to new directories
[19:46] <LarstiQ> mrooney: do you move more than one file at once to a directory that doesn't exist?
[19:46] <mrooney> it isn't obviously that painful to bzr mkdir first, it is just a thing I have to keep in my head
[19:46] <LarstiQ> right
[19:46] <mrooney> no just one in these cases
[19:46] <LarstiQ> mrooney: it's an alien proces to me :)
[19:47] <LarstiQ> mrooney: how would the ui look?
[19:47] <mrooney> the ui?
[19:49] <LarstiQ> mrooney: of mv making dirs that don't exist
[19:50]  * LarstiQ checks mkdir -p behaviour
[19:50] <LarstiQ> mrooney: so one question that arises
[19:51] <LarstiQ> mrooney: `bzr mv file non/existing/path`
[19:51] <LarstiQ> mrooney: would that be non/existing/path/file or non/existing/path ?
[19:51] <LarstiQ> hi LenzGr
[19:52] <LenzGr> Hi!
[19:52] <mrooney> LarstiQ: haha yes, that is ambiguous, I assume it becomes non/existing/path unless you did bzr mvfile non/existing/path/
[19:52] <mrooney> I'd follow 'mv' there
[19:53] <mrooney> though mv doesn't have a -p option like mkdir does
[19:55] <LarstiQ> mrooney: right
[19:55] <mrooney> LarstiQ: I got bug 484985 for you :)
[19:55] <LarstiQ> mrooney: thank you :)
[19:56] <mrooney> that would definitely at least make it obvious to the user what they need to do
[21:41] <ibrandt> Greetings All.  I'm having an issue with bzr join.  I started a repo in /etc/httpd some time back.  Now I'd like to version /etc as a whole.  I ran bzr init in /etc, and added and committed everything but /etc/httpd.  Now I'm trying to join /etc/httpd by running bzr join httpd from the /etc directory.  I get "bzr: ERROR: An inconsistent delta was supplied involving u'httpd', 'tree_root-20091113022148-a0u1zuvcke3o9vtb-1' reason: Path alread
[21:41] <ibrandt> versioned".  Am I misunderstanding how join is supposed to be used?  Bzr 2.0.1 and repo formats are both 2a.
[21:42] <gioele> ibrandt: add https to .bzrignore
[21:42] <gioele> s/https/httpd
[21:46] <ibrandt> Thanks for the help.  I just ran bzr ignore and got, "Warning: the following files are version controlled and match your ignore pattern: httpd These files will continue to be version controlled unless you 'bzr remove' them.", so apparently my statement that I added everything but httpd was incorrect.
[21:47] <ibrandt> Looks like I need a "bzr forget"
[21:48] <gioele> ah, no, wait. I don't think you can't you can do what you think
[21:49] <ibrandt> Ah, "bzr remove --keep httpd"?
[21:49] <gioele> "bzr join" can only join branched created with bzr split
[21:49] <ibrandt> Oh, I see.
[21:50] <ibrandt> Any way to push the root of httpd up one dir, keeping history?
[21:50] <gioele> from the help of join «Such trees can be produced by "bzr split", but also by running "bzr branch" with the target inside a tree.»
[21:50] <gioele> ibrandt: I don't know
[21:51] <ibrandt> I saw that.  Okay, thanks, I'll keep poking at it.
[21:51] <gioele> I already asked for a new join (and a new split) that could do what you want but that proposal did not find the support of the core devs.
[21:51] <gioele> while you are at it, could you expose your case to the mailing list?
[21:52] <ibrandt> Sure, do you have a thread link or a Launchpad bug I could comment on?
[21:55] <ibrandt> I got my ignores in order, and remove --keep'd httpd, and you're right, still no luck with join.
[21:58] <gioele> ibrandt: I will try to find the link to a gmane thread later
[21:58] <ibrandt> It's strange because how is bzr branch into an unversioned subdir of a parent tree all that different from bzr init on the same?
[21:58] <gioele> now I'd like to understand why it does not work
[21:58] <gioele> ibrandt: what about /etc/httpd/.bzr*?
[21:59] <gioele> do you have just .bzr or also a .bzr.retired directory?
[21:59] <ibrandt> just /etc/httpd/.bzr
[21:59] <ibrandt> My thought was the join was all about merging the history for that into /etc/.bzr
[21:59] <gioele> ibrandt: I see the problem
[22:00] <gioele> ibrandt: join is not the culprit
[22:01] <gioele> ibrandt: when you first added the files in /etc (including /etc/httpd) some paths have been stored in /etc/.bzr. Now that you are trying to join it, bzr sees conflicts between the recorded paths and the new paths
[22:01] <ibrandt> makes sense
[22:01] <gioele> ibrandt: can you start with a brand new /etc branch?
[22:02] <ibrandt> I can, just getting started, so no history there yet.
[22:02] <gioele> ibrandt: so just remove /etc/.bzr
[22:02] <gioele> and do a bzr check in /etc/httpd, just to be sure
[22:04] <gioele> abentley: I am using git to contribute to a project. Now I really appreciate bzr-pipeline behavior of shelving local uncommited changes when switching pipe
[22:05] <abentley> gioele: Cool.  I certainly find it handy.  There might be a way to automate it in git.  Don't think they have a concept like shelving, but you could do temporary commits, I expect.
[22:07] <gioele> abentley: "pipe" switching is basic part of git. Shelving is called stashing. and it must be done manually when switching branch
[22:07] <gioele> obviously the command to switch branch is called "checkout"...
[22:10] <Peng> \o/ I have a ~375 MB "upload" file that hasn't been touched for 1.5 hours. What are the chances this pull crashes and burns?
[22:11] <abentley> gioele: Ah, I'll remember that it's called "stashing".
[22:11] <abentley> gioele: The git stuff with colocated branches is similar to the pipeline thing, but pipes are ordered, while git uses "stacked git" to do an ordered series of patches.
[22:13] <gioele> abentley: I know. Luckily in this case I am working on parallel branches, not stacked branches so I didn't try stgit (or any of its relatives).
[22:14] <mwhudson> Peng: what project is that for?
[22:16] <gioele> I wonder whether the future branch colocation feature of bzr will suffer of the same problem (no auto shelving): http://doc.bazaar-vcs.org/developers/colocated-branches.html
[22:17] <ibrandt> gioele: Huh, same problem.  bzr check in httpd reported no errors.  I rm'd /etc/.bzr and .bzrignore.  In /etc did bzr init, bzr ignore ./httpd, bzr add *, bzr commit (which I verified didn't include httpd this time).  But then bzr join gives the same error.
[22:17] <dahoste> wow -- that's how awesome #bzr is.  I came in here prepared to ask a question, and I solved it without even asking.   woot!
[22:19] <dahoste> Shine on, you crazy diamonds!
[22:19] <jelmer> :-)
[22:20] <gioele> ibrandt: did you use exactly "bzr add *"?
[22:20] <gioele> ibrandt: well, I can replicate your problem
[22:21] <ibrandt> I did, assuming httpd would be ignored
[22:21] <ibrandt> I'm trying join now prior to adding anything
[22:22] <gioele> ibrandt: the * got expanded by the shell and bzr sees that you are _explicitly_ adding an ignored file so it lets you add it :)
[22:22] <gioele> ibrandt: if you used bzr add . it would be ignored correctly
[22:22] <ibrandt> Ah, makes sense
[22:24] <Peng> mwhudson: Trying to "bzr pull" nearly all of lp:mysql.
[22:24] <mwhudson> Peng: ah
[22:24] <Peng> mwhudson: And yes, I am doing an on-the-fly conversion. :D
[22:24] <mwhudson> Peng: oh
[22:24] <mwhudson> Peng: how long has this been going for?
[22:24] <Peng> Oh, I suppose this is the incredibly-long "convert everything" step.
[22:24] <jam> Peng: I really wouldn't do it on-the-fly
[22:24] <Peng> I had assumed the downloading was stuck.
[22:25] <jam> 48hrs is a bad thing to have fail
[22:25] <Peng> jam: Luckily I don't care that much! :D
[22:25] <jam> ISTR that bzr branch foo; cd foo; bzr upgrade
[22:25] <jam> will probably be faster
[22:32] <lifeless> poolie: adsl will benefit from http://staff.psc.edu/mathis/MTU/index.html#pmtud
[22:32] <lifeless> jam: it shouldn't be any faster
[22:32] <lifeless> jam: we stream deltas over the network, with common code
[22:32] <jam> lifeless: the converter is different
[22:32] <jam> the tests I had done with spiv
[22:32] <lifeless> jam: spiv put a lot of time into unifying them
[22:33] <jam> showed that while his new streaming code was a lot faster when streaming
[22:33] <Peng> Oh aye?
[22:33] <jam> it was still much slower thna converting locally
[22:33] <lifeless> jam: even the final version?
[22:33] <jam> lifeless: ISTR there was a problem with still extracting too many full texts and comparing them over-the-wire
[22:33] <jam> yeah, I believe so
[22:33] <jam> at least for the "bzr serve ; bzr branch bzr://localhost" style of conversion
[22:34] <jam> maybe that was only for push ?
[22:34] <jam> bzr serve; bzr push bzr://localhost/2a/repo
[22:34] <lifeless> Dunno. I will note that that is still one-machine :)
[22:35] <jam> sure, but doing "bzr upgrade" locally was faster than doing it over the loopback
[22:35] <Peng> mwhudson: FYI, I just checked cache speed with LP's graph in my LH StaticTuple branch. Set is about the same speed, but I slowed get down from ~277 ms to ~1.4 secs. :(
[22:35] <jam> hence, shuold be faster than doing it over the network
[22:35] <lifeless> jam: how many cores do you have in your test machine?
[22:35] <jam> 2
[22:35] <mwhudson> Peng: boo
[22:36] <mwhudson> i have some other thoughts but they are incoherent and a bit angry :)
[22:36] <mwhudson> and there are emails to write
[22:36] <jam> mwhudson: can you check for me if 'lp:bzr-svn' is accidentally stacked on itself on the http side?
[22:37] <jam> I just got a very strange recursion failure
[22:37] <jam> lifeless: I thought we had a fix for not trying to open self if you screwed up the stacking rules
[22:37] <jam> 'bzr info lp:bzr-svn' hangs indefinitely for me
[22:37] <jam> well, probably until stack depth is exhausted
[22:38] <lifeless> jam: We fixed creation of that I believe
[22:38] <lifeless> and have a bug open for handling
[22:38] <mwhudson> jam: it's stacked on ~jelmer/bzr-svn/1.0 i think
[22:38] <mwhudson> ah
[22:38] <mwhudson> which is stacked on lp:bzr-svn
[22:38] <jam> and then 1.0 is stacked back on the other?
[22:39] <jam>  /cry
[22:39] <mwhudson> is one of them a mirrored branch, i wonder
[22:39] <mwhudson> jam: yes
[22:39] <jelmer> I just changed bzr-svn to be hosted on launchpad
[22:39] <jelmer> but pushing with --no-stacked didn't seem to have much effect
[22:39] <jam> jelmer: just to let you know, nobody can branch it now :)
[22:39] <mwhudson> jelmer: bzr reconfigure --unstacked lp:bzr-svn maybe?
[22:39] <jam> well, except for you, probably
[22:40] <mwhudson> or i can do that
[22:40] <jam> mwhudson: would that trigger an update to the mirrored side?
[22:40] <mwhudson> jam: probably
[22:40] <jam> I'm wondering if the hosted side is fine, but the mirrored side is broken
[22:40] <mwhudson> :)
[22:40] <jam> note that you can't actually "Branch.open()" the mirrored side
[22:40] <jam> because it goes into infinite recursion
[22:40] <jam> so the branch puller may be dead as well
[22:41] <jam> at least that doesn't mean I configured the EC2 machine incorrectly :)
[22:42] <jelmer> I'll change it back to the original branch for now
[22:43] <lifeless> jelmer: just run bzr reconfigure --unstacked lp:bzr-svn
[22:43] <lifeless> or sftp in and zerg the setting ;)
[22:43] <jelmer> lifeless: reconfigure doesn't work,  maximum recursion depth
[22:43] <lifeless> mwhudson: does mirroring know to propogate stacking changes?
[22:43] <jam> mwhudson: On ~bzr-svn/bzr-svn/1.0 I see: stacked_on_location = /~jelmer/bzr-svn/1.0
[22:43] <lifeless> mwhudson: bzr pull doesn't :)
[22:43] <mwhudson> lifeless: yes
[22:43] <jam> same for ~bzr-svn/bzr-svn/trunk
[22:44] <mwhudson> jam: suggests the puller isn't coping too well
[22:44] <mwhudson> lifeless: the puller does a possibly surprising amount more than just 'bzr pull'
[22:44] <jam> and then in ~jelmer I see /~bzr-svn/bzr-svn/1.0
[22:44] <jam> so it isn't trunk => 1.0 it is 1.0 => jelmer/1.0 => 1.0
[22:44] <jelmer> jam: ~jelmer/bzr-svn/1.0 is mirrored, the original is not stacked
[22:45] <jelmer> jam: but perhaps the lp mirror is
[22:45] <jam> jelmer: mirrored branch are auto-stacked IIRC
[22:45] <jam> so that theydon't have to download the whole history versus the dev focus
[22:46] <mwhudson> i think i see what happened
[22:46] <mwhudson> jelmer/1.0 was the dev focus, and mirrored
[22:47] <mwhudson> jelmer pushed bzr-svn/1.0 which was stacked on the dev focus, jelmer/1.0 at the time
[22:47] <mwhudson> then bzr-svn/1.0 was made the dev focus
[22:48] <mwhudson> the next time the puller  processed jelmer/1.0 it restacked it on bzr-svn/1.0
[22:48] <mwhudson> --> pain and suffering
[22:49] <mwhudson> jelmer: i think you can probably unset the dev focus, delete bzr-svn/1.0, push it again and reset the dev focus
[22:49] <jam> bug #485069
[22:49] <mwhudson> as to how to stop this happening again, pfffff
[22:49] <mwhudson> no real idea :(
[22:50] <lifeless> jam: I thought there was a bug already. ce la vie
[22:50] <jam> lifeless: I had only seen one about a branch stacked on itself
[22:50] <jam> this is a bit more complex
[22:50] <jam> mwhudson: fail early with an exception rather than failing late
[22:51] <mwhudson> jam: yes, but my brain is refusing to think about how to do that
[22:53] <jam> mwhudson: well it is easy to do it for "Branch.open()" as you could just pass down 'seen_branches = [url1, url2]'
[22:53] <jam> I'm not sure how to do that for "set_stacked_on_location" unless we open that location, and check its fallbacks
[22:53] <jam> or we make "set_stacked_on..." always take a real Branch to start with.
[22:54] <mwhudson> that last feels a bit sane, at least
[22:58] <ibrandt> gioele: Hit another road block.  So I started fresh in /etc with just bzr init, bzr join httpd.  No errors, so I tried to commit that before adding everything else in /etc.  I get, "Committing to: /etc/ ; renamed  => httpd ; bzr: ERROR: An inconsistent delta was supplied involving 'httpdconf', 'conf-20091113022153-bk8us11fvhuf0cre-1' ; reason: working tree does not contain new entry"
[23:00] <lifeless> jam: http://staff.psc.edu/mathis/MTU/index.html is worth a read
[23:00] <lifeless> jam: I /really/ think upping the send and receive buffer size is important
[23:00] <jam> lifeless: Some interesting "hasattr() is evil" traceback: http://paste.ubuntu.com/321940/
[23:00] <lifeless> before changing the orderinging and compression logic
[23:00] <jam> This is the error I got trying to branch bzr-svn
[23:00] <jelmer> mwhudson: lp:~jelmer/meta-lp-deps/bzr-svn-reqs adds libapr1-dev and libsvn-dev to the dependencies (required for subvertpy)
[23:01] <jam> My guess is that hasattr() is suppressing the StackOverflow exception
[23:01] <lifeless> yes
[23:01] <jam> and it ends up as an attribute error failure
[23:01] <mwhudson> jelmer: ah
[23:01] <mwhudson> jelmer: can you propose a merge?
[23:01] <jelmer> mwhudson: Sure - Should I do that already, before the bzr-svn code has landed?
[23:01] <jam> lifeless: so I feel like I might have a handle on how to possibly do it on the client side, I don't have a good feel for what to do on the server
[23:02] <mwhudson> jelmer: i don't really know how launchpad-dependencies works right now
[23:02] <mwhudson> jelmer: now is good
[23:02] <mkanat> mwhudson: Just wanted to let you know that I'm on the loggerhead stuff today.
[23:02] <mwhudson> i guess i should file an rt asking for it to be installed on the slaves...
[23:02] <lifeless> jam: well, if we start with bzr:// and test on that we can eliminate ssh interactions
[23:02] <mwhudson> mkanat: woooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo!!
[23:02] <Peng> Loggerhead stuff?
[23:02] <gioele> ibrandt: I have no clue about that :( especially so late at night ;)
[23:02] <mkanat> Peng: I was contracted to fix some loggerhead issues.
[23:03] <gioele> ibrandt: but many devs are here, fell free to bug them ;)
[23:03] <Peng> Coool.
[23:03] <mkanat> One's the memory leak issue, the other one I have to go look up to remember.
[23:03] <ibrandt> Sure thing.  Thanks for the help.  Definitely made some headway.  Either join isn't baked, or more likely I'm just not understanding how it is supposed to be used.
[23:04] <Peng> mkanat: I love you.
[23:04] <mkanat> lol
[23:05] <mkanat> Oh, right, the other one is bug 118625.
[23:05] <Peng> Ah.
[23:05] <mkanat> mwhudson: Could you assign that bug and bug 156453  to me?
[23:05] <jelmer> mwhudson, done
[23:06] <Peng> mkanat: lp:~mkanat?
[23:06] <mkanat> PengYep.
[23:06] <mkanat> *Yep
[23:06] <mwhudson> mkanat: done
[23:06] <mkanat> mwhudson: Thanks!
[23:07] <Peng> mwhudson: You're quick. :)
[23:07] <mwhudson> mkanat: you could probably join ~loggerhead-team i guess
[23:07] <lifeless> jelmer: still around?
[23:07] <mkanat> mwhudson: Yeah, possibly. Let's see how these two bugs go first, I think.
[23:08] <jelmer> lifeless, jep
[23:08]  * mkanat tends to be very conservative about being assigned privileges or responsibilities. :-)
[23:08] <lifeless> jelmer: did you see the reviews I did?
[23:08] <mwhudson> mkanat: does https://bugs.edge.launchpad.net/launchpad-code/+bug/118625/comments/12 make sense to you?
[23:08] <lifeless> jelmer: bzr-gtk doesn't have ~bzr as a member, or something - I can't actually approve or land things there.
[23:08] <mwhudson> also https://bugs.edge.launchpad.net/launchpad-code/+bug/118625/comments/13
[23:08] <jelmer> lifeless: ah, yes
[23:08] <mwhudson> mkanat: basically i think the problems revolve around the revision graph cache
[23:09] <lifeless> jelmer: so you need to land em :)
[23:09] <jelmer> lifeless: I thought we made you a member of bzr-gtk some time back ?
[23:09] <mkanat> mwhudson: Yeah, that makes sense.
[23:09] <jelmer> or was that just in bundlebuggy?
[23:09] <mwhudson> mkanat: if you can confirm that, it would be great to make building it and accessing it less all or nothing things
[23:09] <mkanat> mwhudson: I'm going to do my best to reproduce it, yeah.
[23:09] <mkanat> mwhudson: Okay.
[23:09] <lifeless> jelmer: bb I suspect
[23:09] <lifeless> jelmer: I'd add ~bzr
[23:10] <lifeless> unless you really want a partition
[23:10] <mwhudson> mkanat: cool
[23:10] <jelmer> lifless: My main reason for not doing that yet is that everybody in ~bzr-gtk can commit directly to lp:bzr-gtk
[23:10] <mkanat> I'm already pretty sure I can repro the memory leak, because it happens on my own servers.
[23:10] <mwhudson> mkanat: let me know if you want some logfiles to poke at
[23:10] <jelmer> lifeless, and I wasn't really sure what the membership policy for ~bzr was
[23:10] <mwhudson> mkanat: although local reproduction would be better of course
[23:10] <lifeless> jelmer: you could ask :)
[23:10] <mkanat> mwhudson: Yeah, I totally will. Do you have a logfile analyzer for loggerhead or anything (since they get pretty big)?
[23:10] <lifeless> jelmer: also, I hear you can uncommit things that shouldn't be landed
[23:11] <lifeless> there is also a '~bzr-core' team, I believe
[23:11] <jelmer> lifeless: Yes, but that would have taken *effort* :-)
[23:11] <lifeless> though ~bzr-core includes bzr
[23:11] <lifeless> which is odd/inverted
[23:11] <mwhudson> mkanat: i've written a bunch of crappy python scripts over the years :)
[23:11] <mwhudson> they're big but not totally crazy
[23:11]  * mkanat nods.
[23:12] <jelmer> lifeless: Wasn't either one invented because people didn't want to receive email about other projects than lp:bzr ?
[23:12] <lifeless> yes, I think that is -core
[23:12] <lifeless> its not core in the sense that other projects use -core
[23:13] <lifeless> jelmer: https://edge.launchpad.net/~bzr/+members#active looks fairly sane
[23:13] <lifeless> nevertheless, I don't really care. I've reviewed all outstanding bzr-gtk merges, you need to land em :)
[23:14] <jelmer> lifeless: I've added ~bzr to ~bzr-gtk
[23:14] <lifeless> cool
[23:24] <mwhudson> mkanat: have you seen the launchpad-loggerhead glue?
[23:25] <mkanat> mwhudson: No, I haven't.
[23:25] <mwhudson> mkanat: https://code.edge.launchpad.net/~launchpad-pqm/launchpad-loggerhead/devel
[23:25] <mkanat> mwhudson: README should mention pygments too, shouldn't it (just as a side note)?
[23:25] <mkanat> mwhudson: Thanks.
[23:25] <mwhudson> mkanat: i guess so
[23:27] <mwhudson> mkanat: do you have a launchpad dev environment?
[23:27] <mkanat> mwhudson: I don't, at the moment, no.
[23:27] <mkanat> mwhudson: I may need to set that up for the hangs one.
[23:28] <mkanat> mwhudson: The memory leak one is independent of launchpad, for sure (since I experience it), so I can test that one separately.
[23:28] <mwhudson> mkanat: i don't _expect_ either to be launchpad specific
[23:28] <mwhudson> mkanat: although we do have scary thread killing code on launchpad
[23:38] <mkanat> mwhudson: Do you know about this? AssertionError: Attempt to set headers a second time w/o an exc_info
[23:38] <mkanat> mwhudson: I get that a LOT if I htdig a local loggerhead.
[23:39] <mwhudson> you get that if rendering fails somehow
[23:39] <mwhudson> and oh man getting simpletal to tell you where something went wrong is ****ING ANNOYING
[23:39] <mkanat> lol
[23:40] <mkanat> Yeah, I'm getting various tracebacks for that assertion.
[23:40] <mkanat> I seem to be reliably making the process grow, though.
[23:40] <mwhudson> mkanat: we stream the output so the headers are set by the time rendering is happening
[23:40] <mwhudson> (and we don't want to change that)
[23:41] <mwhudson> mkanat: time to break out meliae!
[23:41] <mkanat> mwhudson: Indeed!
[23:41] <mkanat> I'm just taking a bit of time to see if I can get it as big as it was on my servers, or if it's just going to hit a ceiling and stop (which wouldn't seem like a leak to me).
[23:42] <igc> morning
[23:45] <lifeless> hi igc
[23:46] <igc> hi lifeless