[00:00] <spiv> Morning.
[00:00] <poolie> hello lifeless, spiv
[00:04] <lifeless> spiv: we really need to finish that fix off; will it benefit from pairing
[00:08] <spiv> lifeless: just paging it back in after the break...
[00:08] <poolie> spiv, lifeless, i'm planning to be pretty short with mail this morning and then do fetch progress and bugs
[00:20] <spiv> lifeless: so I'm about to send the client-side fix to the list for review; it's basically the same patch as before, but the fix is duplicated to InterDifferingSerializer too.
[00:20] <lifeless> ok
[00:20] <spiv> lifeless: (I'm not thrilled by the duplicated code in InterDifferingSerializer, but then I'm not thrilled about InterDifferingSerializer existing in the first place)
[00:21] <spiv> lifeless: and I have the server-side fix that I need to add tests for
[00:22] <jml> merging/pulling in changes that delete directories sucks.
[00:22] <spiv> lifeless: the big outstanding item is NoSuchRevision errors from the server when doing recreate_search on a vanilla SearchResult
[00:22] <lifeless> spiv: ack on both points about IDS
[00:23] <spiv> lifeless: I haven't yet dug into exactly what's going on there, maybe these patches will fix it, but I suspect they might not.
[00:23] <lifeless> spiv: indeed
[00:23] <spiv> lifeless: it appears there's a problem that the client, which sees the full graph, has a different len(included_keys) to the server
[00:23] <lifeless> spiv: that would make sense
[00:24] <spiv> if the search spans the stacking boundary.
[00:24] <lifeless> the client knows where the keys came from; it could choose to split the search differently
[00:25] <spiv> I'm not sure what we should do there; perhaps in the client, if the server is stacked and the server gives NoSuchRevision, it could switch to asking for the ancestry-of the heads and then fetch the missing bits elsewhere?
[00:25] <spiv> Or as you say ask only for the right keys in the first place.
[00:25] <beuno> spiv, hi. Do you have any news on bug 354036?
[00:26] <spiv> lifeless: so I'm not sure that pairing is necessary, but if you want to start tackling that part while I finish off the bits I've got, that would be extremely helpful.
[00:27] <spiv> lifeless: What I have should fix initial pull, but I'd expect the NoSuchRevision flavour could happen if there's already a local repo... I suppose a workaround would typically be "update your trunk branch in that repo then try pull/update of the affected branch again".
[00:28] <spiv> lifeless: Also, while it's a related bug, I'm going to give the NoSuchRevision bug its own bug report I think.
[00:28] <spiv> beuno: that's just what we are talking about right now :)
[00:28] <lifeless> beuno: its been easter
[00:31] <spiv> beuno: in short: I have a candidate fix to stop the client creating broken branches, and also another fix for the server to stop unfixed 1.13 (and 1.14rc1) smart clients from making broken branches.
[00:32] <beuno> yay
[00:32] <beuno> thanks
[00:32] <beuno> I keep having to downgrade to 1.13 to work on launchpad
[00:38] <LeoNerd> So... debian updated my bzr/bzrtools, and now I have the new shelf format.. how do I get at my old shelved data? :)
[00:42] <lifeless> LeoNerd: shelve1
[00:42] <LeoNerd> Ahhh...
[00:45] <spiv> lifeless: I've filed bug 360791
[00:45] <beuno> rockstar, if you're around. Do you know what this would be happening with bzr-autoreview?  http://paste.ubuntu.com/150478/
[00:45] <rockstar> beuno, jaunty
[00:46] <beuno> rockstar, python 2.6?
[00:46] <spiv> lifeless: Having written that bug report I'm pretty much certain its a separate bug introduced by the get_stream verb.
[00:46] <rockstar> beuno, yeah, it's python 2.6's fault.
[00:46] <beuno> rockstar, is it launchpadlib?
[00:47] <lifeless> spiv: yes, I agree
[00:48] <james_w> beuno: "apt-cache policy python-httplib2"?
[00:49] <beuno> james_w,  Installed: 0.4.0-1
[00:49] <beuno>      0.4.0-0ubuntu2 0
[00:49] <beuno>         500 http://archive.ubuntu.com jaunty/universe Packages
[00:49] <james_w> beuno: err, where does it say 0.4.0-1 comes from?
[00:50] <beuno> james_w, ah. Launchpad deps
[00:50] <beuno> PPA
[00:51] <james_w> please let whoever controls that PPA know about best versioning practices
[00:51] <beuno> james_w, ironically, it's celso  :)
[00:51] <james_w> you can "sudo apt-get install python-httplib2=0.4.0-0ubuntu2" for now
[00:51] <james_w> heh :-)
[00:53] <beuno> james_w, thanks
[00:53] <beuno> works now
[01:11] <lifeless> spiv: I think I'll do for BzrDir.get_config what I did for Branch.get_config
[01:12] <lifeless> spiv: to keep moving the ratchets
[01:31] <igc> morning all
[01:32] <beuno> hiya igc
[01:34] <igc> hi beuno
[01:35] <beuno> how's it going igc?
[01:37] <igc> beuno: pretty tired actually - slept most of the last 4-5 days
[01:38] <SamB> jelmer: why do your branches for bzr-svn have to have version numberes?
[01:38] <SamB> er. numbers.
[01:39] <beuno> igc, sorry to hear that  :/
[01:39] <beuno> will we be seeing you at all hands?
[01:39] <jelmer> moin
[01:40] <jelmer> SamB: ?
[01:40] <SamB> jelmer: apparantly I've been stuck on the 0.5 branch without realizing it!
[01:40] <jelmer> SamB: ah, you mean the release series?
[01:40] <jelmer> SamB: you can use the 'bzr.dev' branch, which symlinks to whatever release series works with bzr.dev
[01:41] <SamB> do I just use --overwrite with pull to switch?
[01:41] <SamB> considering that I have no local commits?
[01:41] <igc> beuno: no unfortunately - I'm still unable to travel for a while
[01:41] <igc> hi jelmer
[01:41] <jelmer> SamB: yeah, and --remember
[01:42] <SamB> jelmer: why not have lp:bzr-svn -> lp:~jelmer/bzr-svn/bzr.dev ?
[01:43] <SamB> besides the fact that that's a bad URL
[01:45] <SamB> jelmer: what's a URL that will always be for bzr.dev ?
[01:45] <jelmer> SamB: lp:bzr-svn already points at the 0.6 branch
[01:45] <jelmer> SamB: but bzr stores the expanded URL, not the short one
[01:45] <SamB> exactly
[01:46] <jelmer> SamB: what URL lp:bzr-svn points at depends on the active release series
[01:46] <jelmer> SamB: and there is no 'bzr.dev' release series, only 0.4, 0.5, 0.6, etc
[01:46] <jelmer> SamB: anyway, http://people.samba.org/bzr/jelmer/bzr-svn/bzr.dev should always works
[01:47] <SamB> heh
[01:47] <SamB> jelmer: so ... why *don't* you have a bzr.dev series ?
[01:48] <SamB> bzr does
[01:50] <poolie> spiv: happy birthday to mary (i think)
[01:51] <jelmer> SamB: because I don't actually have a separate 'main development' branch like bzr
[01:52] <SamB> you could just split off your numbered branches after release ;-P
[01:53] <jelmer> SamB: but I do actually keep working on these branches for a while when I do minor release
[01:53] <SamB> I noticed
[01:53] <SamB> otherwise I wouldn't have needed --overwrite ;-P
[01:55] <SamB> hmm ... I'm still getting asked for username/password :-(
[01:56] <jelmer> SamB: see the recent thread on the mailing list
[01:56] <jelmer> SamB: bzr does a POST request to the HTTP server first
[01:56] <jelmer> and the server replies with a 401 Auth required reply
[01:57] <SamB> jelmer: oh, I thought you said it should be fixed?
[01:57] <jelmer> SamB: where did I say that ? :-)
[01:58] <jelmer> SamB: you can work around the issue by removing get_smart_medium() at bzrlib/transport/http/__init__.py:142
 SamB: should be fixed now (0.6 branch)
[01:59] <SamB> about 12 hours ago, I think?
[01:59] <jelmer> SamB: ah, that was the prefix issue for svn-import
[02:00] <SamB> oh!
[02:00] <SamB> heh
[02:01] <SamB> did you know that jelmer sometimes says ambiguous things? you should fix that ;-P
[02:06] <spiv> poolie: yes :)
[02:08] <jelmer> SamB: :-P
[02:29]  * SamB wishes firegpg wouldn't invoke gpg --import synchronously ...
[02:30] <SamB> or whatever that option actually is
[02:40] <jelmer> lifeless: so, now that it's tuesday..
[02:41] <jelmer> lifeless: Any chance you can have a look at my InterBranch.pull() patch ? :-)
[02:54] <SamB> jelmer: what do you mean? it won't be tuesday for about two hours and 6 minutes yet!
[02:55] <lifeless> jelmer: yes, I will try to
[03:02] <poolie> spiv, do you want me to review your bug 354036 patch? or is lifeless going to?
[03:03] <spiv> poolie: I hope lifeless will, but another pair of eyeballs is certainly welcome!
[03:05] <lifeless> spiv: done
[03:12] <spiv> lifeless: thanks
[03:14] <spiv> lifeless: it's not immediately obvious to me how to make a good helper function, because the I find the parents in the two different code paths is pretty different.
[03:15] <lifeless> the variable names, or the data?
[03:15] <spiv> lifeless: in RepoFetcher we just ask the target after we've inserted the stream, but in InterDifferingSerializer it's a bit messier... perhaps it doesn't need to be.
[03:16] <spiv> In InterDifferingSerializer I reuse the Revision objects that we already have (in pending_revisions), for instance.
[03:16] <lifeless> parent data should be either cheap, or cached
[03:16] <lifeless> I'd use the same code
[03:17] <spiv> And also I'm doing this before the revision objects are inserted.
[03:17] <lifeless> uhm
[03:17] <spiv> Which has the nice property of making sure all the inventories are there before the revisions that depend on them.
[03:18] <spiv> But perhaps that's not so important?
[03:18] <lifeless> interdiffering topological anway
[03:18] <lifeless> bah, insert missing words
[03:18] <spiv> And letters ;)
[03:20] <spiv> But even working topologically, if we do "insert inventories; insert revisions; insert the other inventories needed by those revisions", then there's a window when we have nearly-but-not-quite complete data there.
[03:20] <lifeless> indeed, and agreed
[03:20] <spiv> Which maybe doesn't matter, because probably if anything goes wrong it'll abort the write group, etc.
[03:20] <lifeless> can't depend on write groups in this code
[03:20] <lifeless> uhm
[03:20] <lifeless> ok, go without a helper
[03:21] <lifeless> but we want to get to pre-checking it everywhere, or something like that
[03:21] <spiv> Yeah.
[03:22] <lifeless> any idea about
[03:22] <lifeless> SmartMessageHandlerError: The message handler raised an exception:
[03:22] <lifeless> Traceback (most recent call last):
[03:22] <lifeless>   File "/home/robertc/source/baz/pending/push.roundtrips/bzrlib/smart/protocol.py", line 1034, in done
[03:22] <lifeless>     self.message_handler.end_received()
[03:22] <lifeless>   File "/home/robertc/source/baz/pending/push.roundtrips/bzrlib/smart/message.py", line 161, in end_received
[03:22] <lifeless>     self.request_handler.end_received()
[03:22] <lifeless>   File "/home/robertc/source/baz/pending/push.roundtrips/bzrlib/smart/request.py", line 345, in end_received
[03:22] <lifeless>     self._run_handler_code(self._command.do_end, (), {})
[03:22] <lifeless> AttributeError: 'NoneType' object has no attribute 'do_end'
[03:22] <spiv> Huh, no.
[03:23] <spiv> Something is resetting _command prematurely?
[03:24] <lifeless> dunno yet
[03:26] <lifeless>   File "/home/robertc/source/baz/pending/push.roundtrips/bzrlib/smart/protocol.py", line 893, in accept_bytes
[03:26] <lifeless>     _StatefulDecoder.accept_bytes(self, bytes)
[03:26] <lifeless>   File "/home/robertc/source/baz/pending/push.roundtrips/bzrlib/smart/protocol.py", line 388, in accept_bytes
[03:26] <lifeless>     self.state_accept()
[03:26] <lifeless>   File "/home/robertc/source/baz/pending/push.roundtrips/bzrlib/smart/protocol.py", line 998, in _state_accept_expecting_message_part
[03:26] <lifeless>     self.done()
[03:26] <lifeless> I think its the unknown verb handling on the server
[03:26] <spiv> Hmm, it could be, yeah.
[03:26] <spiv> I thought that was tested, but perhaps there's a gap.
[03:28]  * SamB ponders the various difficulties sure to be involved in any attempt to use bzr-svn in DOS ;->
[03:49] <thumper> igc: Composite tree review pring
[03:49] <thumper> s/pring/ping/
[04:02] <igc> hi thumper
[04:02] <igc> thumper: I'm half way through - hope to finish today
[04:02] <thumper> igc: that's great, thanks
[04:03] <lifeless> I'm still really unsure that a different tree class is the right approach
[04:03] <lifeless> it just seems to move the complexity around
[04:03] <lifeless> and adds to it
[04:06] <thumper> lifeless: in which case you really need to talk with abentley and others about this
[04:06] <thumper> I don't know enough to give intelligent answers
[04:07] <thumper> but I want to make sure we have a good story here
[04:10] <lifeless> thumper: I have talked to aaron about it; we disagree
[04:10] <lifeless> doing it with an external object means we have to have a index for subtrees, and that adds complexity.
[04:10] <lifeless> iMNSHO
[04:11] <lifeless> OTOH aaron has working code and thats important
[04:11] <lifeless> the big thing is to make sure that  there are no performance regressions as the changes land in trunk
[04:11] <thumper> I think that we are in agreement on that last point
[04:50]  * igc lunch
[05:40] <lifeless> spiv: branch done
[05:40] <lifeless> spiv: onto the next one after a short break
[06:44] <lifeless> spiv: man, I found another cheap win
[06:51] <spiv> lifeless: hooray
[06:52] <lifeless> on the order of 12 round trips
[06:52] <lifeless> !
[06:52] <lifeless> running the full test suite now to find issues
[07:04] <lifeless> well, some stuff breaks
[07:08] <thumper> lifeless: what are you working on that you found 12 round trips?
[07:09] <vila> hi all
[07:11] <lifeless> performance
[07:17] <lifeless> thumper: I don't have enough info to answer what I think you are asking
[07:18] <thumper> lifeless: <lifeless> on the order of 12 round trips
[07:18] <thumper> lifeless: HPSS something or other>
[07:18] <thumper> ?
[07:19] <lifeless> well yes, everything is hpss
[07:19] <thumper> lifeless: I'm just curious
[07:19] <thumper> lifeless: just wondering if push/pull is going to get faster
[07:19] <lifeless> thumper: thats the idea :)
[07:19]  * thumper pokes lifeless in the eye for being obtuse
[07:20] <thumper> lifeless: it seems you are trying to read too much into my curiousity
[07:20] <lifeless> thumper: it will get faster as we fix more things; I'm investigating a possible improvement at the moment; it doesn't work so its not an improvement
[07:20] <lifeless> and I *don't know* what it changes
[07:20] <thumper> that seems kinda weird
[07:20] <lifeless> that I don't know?
[07:21] <fullermd> Pshaw.  This is software; since when is 'working' a necessary ingredient?
[07:21] <lifeless> fullermd: when you have users
[07:22] <lifeless> thumper: I don't know because we still have over 50 different method calls on common use cases
[07:22] <lifeless> thumper: and its hard to tell what actually changes when you tweak something and 10 or so dissapear
[07:22] <lifeless> I specifically moved around the set_parent method on Branch, thats all
[07:23] <lifeless> until I diff the network traffic, complete the test run, and so on - its all speculation; and I try to avoid speculating
[07:24] <lifeless> thumper: also please, enough with the eyepoking, its unpleasant imagery
[08:09] <lifeless> thumper: so I can answer now, while I still don't know why, getting rid of the set_parent method on RemoteBranch gets rid of 6 hpss calls in our same server use case
[08:09] <lifeless> and in our push --stacked use case
[08:26] <speakman> lifeless: Regarding https://blueprints.launchpad.net/bzr/+spec/merge-commit-reuses-log are you willing to guide me where to start, and hopefully I could contribute with code some day?
[09:17]  * igc dinner
[10:48] <lifeless> hmm, I'm going to write some code
[10:49] <lifeless> speakman: well, I'd start with a plugin myself, because I could create a new command, tweak it until it does what I want and get some people to try it out
[10:49] <lifeless> if its liked, the logic can be yanked out as a patch for bzr  itself
[10:52] <speakman> plugin sounds like a good idea. But I've never written anything for bzr(lib), so is there any existing plugin you'd recommend tweaking instead of start a new from scratch?
[10:54] <lifeless> uhm
[10:54] <lifeless> my plugin-info plugin is nice and small
[10:54] <lifeless> you could use that as a template for a plugin
[10:55] <lifeless> and grab the code from bzrlib.builtins.cmd_commit as a starting point for your own command
[10:56] <lifeless> https://edge.launchpad.net/bzr-plugin-info is the plugin I'm referring to
[10:58] <lifeless> spiv_: didn't you do a coverage option for selftest?
[11:34] <james_w> speakman: there's actually a hook to seed the commit message offered to you in the editor
[11:34] <james_w> so you could create a plugin to provide that hook, and then plain "bzr commit" would offer you an editor with that message that you could edit to your liking
[11:34] <james_w> would that suit you?
[12:01] <speakman> I'm sorry for beeing a bit off, but I'm currently at work
[12:02] <speakman> lifeless: I'll definitly check that plugin out! Thanks alot!
[12:02] <speakman> james_w: Sorry for not understanding, but what is "seed the commit message" really?
[12:02] <speakman> and "the editor"?
[12:03] <speakman> oh, the diff and stuff of course.
[12:03] <james_w> when you run "bzr commit" with no "-m" argument you are given an editor window to provide the commit message
[12:03] <james_w> that editor can be "seeded" with a message, but normally isn't
[12:03] <speakman> --with-diff does seed it?
[12:03] <james_w> nope
[12:04] <james_w> that makes changes below the "Everything below this line will be ignored line"
[12:04] <speakman> (i'm not really sure what "seed" really means. I'm no english expert :) )
[12:04] <lifeless> speakman: 'prepare'
[12:04] <james_w> you can also make changes above it
[12:04] <speakman> lifeless: okay! thanks!
[12:04] <james_w> so that if you do nothing and save and quit the message that was "seeded" will be used
[12:05] <speakman> james_w: wow! is there anything that utilize this already?
[12:05] <james_w> bzr-builddeb is the only thing that I know about
[12:06] <speakman> But then again; I have no clue how hooks works in bzrlib, and I'm pretty short of sparetime for a while :(
[12:06] <james_w> http://bazaar.launchpad.net/~bzr-builddeb-hackers/bzr-builddeb/trunk/annotate/head%3A/__init__.py
[12:06] <james_w> the "debian_changelog_commit_message" function
[12:09] <speakman> Great thanks! I really hope to contribute more self-going in the feature. People are talking about bzrlib as an example how beatiful Python code could be. I probably have alot of thing to learn when getting me into the bzrlib code.
[12:10] <jelmer> moin
[12:10] <james_w> speakman: something like http://paste.ubuntu.com/150747/
[12:10] <james_w> morning jelmer
[12:11] <james_w> speakman: save that code as ~/.bazaar/plugins/merge_commit.py and give it a test
[12:11] <james_w> speakman: oh, it needs "from bzrlib import msgeditor" at the top
[12:12] <vila> lifeless: the coverage option is global, not specific to selftest
[12:13] <speakman> james_w: great thanks! I'll try it as soon as my job ends for the day.
[12:13] <lifeless> vila: yes I've found it. Its now what I want
[12:14] <lifeless> *not*
[12:14] <vila> ok
[12:18]  * vila goes back to tweaking pronto.tell_me_what_tests_run_me()
[13:44] <spiv_> lifeless: no, I did a global --coverage option
[13:45] <spiv> (it was originally just for selftest, but it was simpler to as a global, and potentionally useful too)
[13:58] <lifeless> spiv: do you happen to know of code to go from line number in a py file to method ?
[14:05] <lifeless> night all, I'll finish this tomorrow I think
[14:07] <spiv> lifeless: possibly the inspect module has something, otherwise I don't know of any off-hand.
[14:09] <lifeless> spiv: not needed
[14:09] <lifeless> trace has what I wanted, just different params
[14:09] <spiv> lifeless: cool
[14:09] <lifeless> at least for this part of my plugin
[14:09] <lifeless> I'm generating an index of function -> test
[14:10] <lifeless> its a little long to do lineno->test
[14:11] <lifeless> anyhoo, will finish tomorrow
[14:17] <vila> lifeless: you do that for all functions or just on demand
[14:21] <lifeless> vila: selftest --index
[14:21] <lifeless> vila: then selftest --changes uses the index
[14:22] <vila> changes since the last --index ?
[14:24] <lifeless> since the last commit
[14:24] <lifeless> must go, very tired
[14:46] <rahul>  Wanna get your pic on magazine cover??? http://techbuddha.blog.co.in/2009/04/14/wanna-get-your-pic-on-magazine-cover/          --            http://techmaharshi.blogspot.com/
[14:59] <awilkins> "K-lined" : not seen that in a while
Ha-ha</nelson
[15:02] <jelmer> beuno: is there any loggerhead release in the pipeline?
[15:02] <beuno> jelmer, oh, I really do want to make a release
[15:02] <jelmer> beuno: including the start-loggerhead -> serve-branches transition?
[15:03] <beuno> jelmer, that's the blocker. No config yet
[15:03] <jelmer> beuno: ahh
[15:03] <rockstar> beuno, I have a secret plan to re-write large parts of loggerhead.
[15:03] <jelmer> beuno: any rough idea on when that would be possible?
[15:03] <jelmer> beuno: (one of the alioth maintainers is asking me for a backport)
[15:03] <beuno> jelmer, I could make a release anyway
[15:04] <jelmer> beuno: well, I'm mainly interested in doing the backport *after* the changes
[15:04] <beuno> rockstar, I hear that, really looking forward to it
[15:04] <jelmer> as they will affect users
[15:04] <beuno> jelmer, after the start -> serve migration?
[15:04] <jelmer> beuno: yeah
[15:04] <beuno> jelmer, ok. I have had zero time to work on that  :(
[15:04] <rockstar> beuno, you heard already?  I guess it's not a secret plan then.
[15:05] <beuno> rockstar, well, unless it's something different than the wholehistory and revnocache bits
[15:05] <jelmer> beuno: no worries, I was just wondering what the status was on that
[15:05] <beuno> it can be *our* secret
[15:05] <beuno> jelmer, "stalled", but mwhudson and rockstar are working on all kinds of places
[15:05] <rockstar> beuno, drastically different.  wholehistory is not going to be trivial to remove without ripping out all sorts of things.
[15:06] <beuno> rockstar, oh!  interesting
[15:07] <jelmer> beuno: ah, thanks
[15:08] <jelmer> rockstar: wholehistory?
[15:09] <rockstar> jelmer, wholehistory cache is the bane of loggerhead's existence.
[15:11] <jelmer> ah, teh cache
[15:14] <rockstar> jelmer, I'm almost positive that it's the reason loggerhead leaks memory.
[17:26] <jam> rockstar: well, IIRC when talking with mwh at pycon, we found the problem wasn't strictly the whole-history cache, as much as the 3-4 copies of it
[17:27] <jam> which is some of the stuff we uncovered with the memory_dump stuff
[18:03] <jelmer> whoa
[18:04] <jelmer> merge pulls the revisions for the other tree into the this repo
[18:07] <luke-jr> jelmer: uh?
[18:08] <jelmer> if you run "bzr merge" in a subversion working copy (with .svn directories)
[18:08] <jelmer> it will push the pending merges into the repository, but that happens to be a remote svn repository
[18:09] <jelmer> and revisions are always visible in svn
[19:44] <cody-somerville> doh
[19:45] <cody-somerville> I imported a git branch to bzr
[19:45] <cody-somerville> and its clearly missing files and whole directories :/
[19:46] <jelmer> cody-somerville: how did you import it?
[19:46] <cody-somerville> jelmer, git fast-export --all | (cd ../.bzr-repo; bzr fast-import - &> /dev/null)
[19:47] <jelmer> ok, no clue then
[19:48] <cody-somerville> Is there another way to do it?
[19:48] <jelmer> cody-somerville: bzr-git
[19:50] <cody-somerville> Is there a package in Ubuntu with that?
[19:52] <jelmer> not yet
[19:54] <pygi> there is an archlinux package however :p
[19:54] <ronny> that doesnt fix all the other reasons for not using archlinux
[19:55] <cody-somerville> lol
[19:55] <pygi> ronny, :P
[19:55] <pygi> ronny, like what? :D
[19:55] <ronny> well, they ship a broken gvim since years
[19:56] <pygi> it'd take you 5 secs to fix it... whats the problem exactly?
[19:56] <ronny> and there have been other incompetence issues - like the package manager doing silent corruption
[19:56] <ronny> pygi: the vim people told them many times, they dont fix
[19:56] <pygi> ronny, o.O
[19:57] <pygi> ronny, could you pm me, so I can do it?
[19:57] <ronny> the main issue is that their custom gvimrc breaks all colorshemes
[19:57] <pygi> (not in official repos tho)
[19:58] <ronny> every few weeks we get a unhappy pida user cause of this, and god knows how many dont even ask
[19:59] <pygi> ronny, I am just looking at the package...
[19:59] <pygi> ronny, it ships with gvimrc_example.vim from vim tarball as gvimrc?
[20:01] <ronny> pygi: last time i brothered /etc/gvimrc or /etc/vim/gvimrc was a custom mess of color hacks in archlinux
[20:01] <ronny> the fix was to just delete it
[20:01] <pygi> rockstar, ok, at least now it doesn't seem to be
[20:02] <rockstar> pygi, please watch your tab completion.
[20:02] <pygi> rockstar, ups, I did that yesterday too, no? :D
[20:02] <pygi> ronny*
[20:02] <ronny> well, shortly after that the archlinux package-manager silently corrupted my install and the package db due to absolute ignorance of a filled harddisk
[20:03] <pygi> ronny, right :)
[20:04] <ronny> well, end of the story is - i discourage everyone from using arch
[20:04] <pygi> hehe nice :)
[20:05] <pygi> do I have your forgiveness for using it then? :P
[20:05] <ronny> i just discourage fro using it
[20:05] <ronny> but i might commit hate-crimes against rpm based things
[21:48] <jelmer> vila: hi
[22:01] <pygi> jelmer, new bzr git requires 1.15?
[22:02] <pygi> w00t? :D
[22:03] <jelmer> pygi: yeah, bzr.dev
[22:03] <pygi> meh, so I have to install that too
[22:03] <pygi> so un-cool xD
[23:26] <jelmer> lifeless: ping
[23:55] <lifeless> jelmer: pong
[23:57] <poolie> lifeless, jelmer, hi