[06:49] <vila> hi all !
[06:50] <LarstiQ> hey vila!
[06:52] <mgrandi> hi
[07:10] <poolie> o/ vila, larstiq
[07:10] <vila> poolie: hey !
[08:21] <mgz> morning
[08:24] <poolie> hi mgz
[08:24] <mgz> hey poolie
[08:28] <vila> mgz: hey !
[09:46] <mgz> canonical as a company name makes for some funny phrases
[09:46] <mgz> I like "non-canonical copyright holders" from jelmer's email
[09:57] <jelmer> mgz: :)
[09:57] <jelmer> there's a company in the CIFS/SMB world called "LikeWise"
[09:58] <mgz> ehehe, that's hillarious
[09:58] <jelmer> also the cause of very amusing conversation sometimes
[11:07] <mgz> private bug 968065 is a dupe of bug 894195 maybe?
[11:15] <jelmer> mgz: yes
[11:15] <jelmer> mgz: marked as such
[11:30] <mgz> hm, fun conflicts merging up from 2.4 to 2.5
[11:31] <jelmer> feature flags related?
[11:31] <mgz> not obviously, no
[11:32] <mgz> ...some of it is find_format, so that will be.
[11:32] <jelmer> the 2.4 changes there should be discarded
[11:32] <jelmer> let me know if there's anything I cna help with
[11:33] <mgz> so, I kill the find_format methods?
[11:35] <jelmer> let me check..
[11:36] <jelmer> mgz: the custom find_format that's being introduced in Branch, WorkingTree and Repository, yes
[11:36] <jelmer> mgz: they're inherited from BzrFormat in 2.5
[11:38] <mgz> ah, I think I understand this bzrlib.errors conflict now
[11:43] <mgz> okay, that's got it I think, just ParseFormatError added is right.
[11:43] <mgz> wait, now there are two...
[11:44] <mgz> okay, drop the one without the format param.
[11:47] <mgz> hm. both forms are used.
[11:49] <mgz> bzrdir.extract_format_string has:
[11:50] <mgz> raise errors.ParseFormatError(lineno=lineno+2, line=line, text=text)
[11:50] <jelmer> bzrdir.extract_format_string shouldn't be in 2.5
[11:50] <mgz> okay
[11:50] <jelmer> that's merely a convenience function for the way features are handled in 2.45
[11:50] <jelmer> *2.4
[11:50]  * mgz re-eyes the diff for other additions
[11:50] <mgz> okay, that's nearly sane now
[12:14] <jelmer> mgz: any news on the new windows installers?
[12:14]  * jelmer had another person hit the bzr-svn incompatibility
[12:16] <mgz> posted them (late) the other evening when I said I was building them and bugged you about plugin versions
[12:16] <mgz> translations are a little borked, but actually not quite as borked as I thought they were going to be,
[12:17] <jelmer> ah, cool
[12:17] <mgz> bzr-svn and bzr-git versions should all be happy.
[12:17] <mgz> how do you spell cyrillic...
[12:19] <mgz> I can't get close enough to make greping /etc/.../words work
[12:19] <mgz> goooogle
[12:19] <mgz> wait, that is how you spell it.
[12:20] <mgz> I was sure I'd get a "Did you mean..."
[12:20] <mgz> ...I didn't use -i
[12:20] <mgz> and it's captialized >_<
[12:21] <mgz> I'm not sure what the 'Cyrillic's' entry is about
[12:21] <jelmer> mgz: can you mention when you've uploaded new windows binaries in https://bugs.launchpad.net/bzr-windows-installers/+bug/950751?
[12:23] <didrocks> hey jelmer
[12:24] <didrocks> jelmer: I just noticed something which puzzled me using bzr buildder
[12:24] <didrocks> from this change: https://code.launchpad.net/~jelmer/bzr-builddeb/auto-apply-quilt/+merge/87555 all quilt patches are applied when bzr bd-do or bzr bd by bzr
[12:24] <didrocks> however, there is no trace in the build log about them
[12:25] <didrocks> not sure if run_quilt() is eating the output
[12:25] <didrocks> (as you quilt push -a -v)
[12:25] <didrocks> or it's because of the quiet parameter :)
[12:25] <didrocks> but I think that you can wonder if the new added patch is applied (did you bzr add? add it to debian/patches/series)
[12:25] <didrocks> (in fact, it just happened to me ;))
[12:27] <mgz> jelmer: done
[12:28] <jelmer> didrocks: you should see the output during the source package build
[12:29] <jelmer> mgz: thanks!
[12:29] <didrocks> jelmer: hum, just tried again and I don't
[12:30] <didrocks> jelmer: I'm in merge mode if that can be of importance
[12:30] <jelmer> didrocks: what's the build?
[12:31] <didrocks> jelmer: just pushed the branch: lp:~compiz/libcompizconfig-backend-gconf/ubuntu
[12:32] <jelmer> didrocks: I'm curious about the launchpad build log specifically, or was this using a local build?
[12:33] <didrocks> jelmer: just the local build, the launchpad build log is fine and dpkg-source shows that it's applying patches
[12:33] <didrocks> jelmer: just talking about bzr bd here (merge mode only related, maybe?)
[12:34] <jelmer> ahh
[12:34] <jelmer> you said bzr-buildder, which is a typo that can be read in two ways :)
[12:34] <didrocks> ah? ;)
[12:34] <didrocks> bzr builddeb? :)
[12:34] <jelmer> I thought you were talking about bzr-builder, which also does quilt applying
[12:35] <didrocks> ok, sorry for the confusion :-)
[12:36] <jelmer> as far as I know run_quilt() shouldn't be eating the output
[12:36] <jelmer> I'll try your branch
[12:37] <didrocks> thanks ;) seb128 confirmed as well
[12:37] <didrocks> (on another branch)
[12:37] <didrocks> it's not a big deal, just puzzling until you know
[12:40] <jelmer> yep, I can reproduce it too
[12:40] <jelmer> it's a bug, we're returning the output to the caller, who ignores it
[12:41] <jelmer> I'll file a bug and subscribe you
[12:41] <didrocks> jelmer: excellent, thanks :-)
[12:54] <vila> jelmer: why did you resubmit lazy-registries ? I can't reply anymore to the previous one, I don't have access to the intermediate diffs inline... it just makes my reviewer's life harder for ... what ?
[12:56] <mgz> there are plusses and minuses
[12:56] <jelmer> vila: I'd merged bzr.dev in between
[12:56] <jelmer> vila: this refreshes the diff
[12:56] <vila> ok, I think I see the minuses :) Tell me about the plusses :)
[12:56] <vila> the diff is always refreshed
[12:57] <vila> and the intermediate ones leave reviewers the choice of either checking them or re-review the whole
[12:57] <jelmer> sorry :-/
[12:57] <vila> resubmitting just make that impossible on both :-/
[12:58] <vila> it may be a bug (or two) against lp that the 'reply' buttons are not there anymore (in both proposals) and neither are the diffs but :-/
[12:58] <jelmer> vila: it's mostly a force of habit I guess, sorry
[12:59] <vila> no worries, I thought I mentioned it anyway in case you could do that less often ;)
[13:00] <vila> It's true that it's the way to go in some cases but in general I find it more disruptive and only ask for it (or do it) when the discussion is long and the proposal change enough to be worth creating a new one
[13:00] <vila> (and also when I foobar the target ;)
[13:07] <vila> jelmer: I find that merging  bzr.dev just before submitting leves the proposal cleaner. It's not always viable though.
[13:09] <vila> jelmer, mgz: Is it only me or does clicking the proposal status button always display a new page now ?
[13:10] <mgz> vila: check your js error log? you get a new page for changing the status when js is off.
[13:11] <vila> . o O (js error log ??? kids these days...)
[13:11] <vila> where the hell do I find that ?
[13:13] <vila> wow indeed bunch of warnings there (~40 or something at least)
[13:15] <vila> bah, the log in chronological order, most recent entries *last* ;_;
[13:22] <jelmer> vila: do we really need a test for lazy_register_filter_stack_map when deprecating it ? That function didn't have any tests to begin with..
[13:23] <jelmer> hmm, I guess it's not the hardest test to write, though
[13:23] <vila> right, that was a bug :) Adding a test now will less costly than wondering in 6 months when deleting the function: where is the test ? Why isn't there one ?
[13:23] <vila> exactly
[13:23] <jelmer> vila: I'm not sure I understand why the test is necessary though?
[13:24] <vila> because that's a good rule ? And easy to remember ? ;)
[13:24] <jelmer> vila: I don't think that's a good rule for deprecated code
[13:25] <fullermd> If you just outright delete it now, you avoid the issue  8-}
[13:25] <jelmer> vila: if you're worried we'll spend time looking for tests when we remove the function in 6 months, can't we just add a comment ?
[13:25] <vila> jelmer: I think the other review where I mentioned the issue was a better context but I can't remember which one it was
[13:26] <vila> jelmer: saying 'there is no test for that ?', fair enough :)
[13:26] <jelmer> vila: great :)
[14:23] <jelmer> vila: thanks for the reviews!
[14:24] <vila> hehe, I'm not done yet :)
[14:28] <jelmer> ooh, even better :)
[16:46] <mgz> vila: still online?
[16:47] <vila> mgz: not for long :-/
[16:49] <mgz> so, the future has been laid out
[16:52] <fullermd> Sweet.  Got some stock tips for me then?
[16:52] <mgz> sell.
[16:53] <fullermd> Shoot, I could tell you that without laying out any future...
[16:53] <mgz> ...being in the UK makes for depression at the moment
[16:53] <mgz> it's sunny though.
[16:53] <mgz> tortoise is happy.
[16:53] <fullermd> ITYM "on earth".
[16:54] <fullermd> It's sunny here too.  I hate it.
[16:54] <mgz> I therefore deduce that you are not a tortoise.
[16:54] <fullermd> D'oh.  You saw right through my shell game.
[16:55] <fullermd> According to the thermometer hanging outside my window, it's 102 degrees.
[16:55] <vila> no sun here
[16:55] <fullermd> Of course, it goes way high, hanging in the sun.  TWC says only 77.  Still way too zarking hot for March.
[16:55] <fullermd> Bodes ill for the summer.  I may have to hibernate for 5 months or so.
[16:56] <vila> hehe, poor tortured meters...
[16:56] <fullermd> Should get over 80 today.  And for most of the next 10 days, by the forecast...
[17:02] <fullermd> vila: Are you waiting for anything from me on that date: bug?
[17:02] <vila> remind the number ?
[17:02] <vila> I think I was waiting for some confirmation
[17:02] <fullermd> What, you want me to actually THINK now too?
[17:02] <fullermd> bug 964171
[17:03] <vila> well, you're not a troll, so hot temperatures shouldn't be a problem for your brain ;)
[17:03] <fullermd> You had one reply that seemed to ask something I couldn't quite figure, but then another that seemed like you saw it and had some idea about fixing it.
[17:24] <pmatulis> how do i revert a committed change?
[17:24] <pmatulis> i already pushed this to l/p
[17:25] <jelmer> pmatulis: "bzr merge -rNEWREV..OLDREV ." to unapply the changes between OLDREV and NEWREV
[17:25] <jelmer> then "bzr commit -m 'Explain why'"
[17:25] <pmatulis> jelmer: i'll try it, thanks
[17:25] <fullermd> Colloquially, what you do is more "reverse" it.
[17:29] <vila> fullermd: yeah, well, I was investigating and had a crash and lose track of this particular bug, thanks for the heads-up
[17:30] <fullermd> Well, stop investigating bugs while you're driving!   :p
[17:31]  * SamB wishes bzr would make some kind of effort to check locks for freshness ...
[17:31] <jelmer> SamB: on the local machine, and with current versions of bzr it will
[17:32] <fullermd> Yeah, 's nothing worse than stale lox...
[17:32] <SamB> define "current"
[17:32] <lifeless> fullermd: low
[17:34] <fullermd> No, that's cows, not salmon   :p
[17:34] <SamB> ... know a good way to tell mutt to delete all messages with bodies identical to the one I'm looking at?
[17:34] <pmatulis> jelmer: so if i have revisions 9, 10, 11, and i want to blow away 10 i would do 'bzr merge -r9..11 .' ?
[17:34] <fullermd> Don't think there is one.  If there's a sufficiently distinctive sufficiently short phrase in it, you could tag on it.
[17:35] <lifeless> pmatulis: bzr merge -r 11..10 .
[17:35] <fullermd> No, 10..9, if you want to get rid of 10.
[17:36] <lifeless> bah
[17:36] <lifeless> yes
[17:36] <fullermd> (you're undoing the 9..10 change)
[17:37] <pmatulis> fullermd: ah ok
[17:41] <SamB> hmm, it looks like to upgrade bzr to the sid version I need to uninstall bzr-hg :-(
[17:42] <mgz> SamB: current=2.5, but you can also enable it with a config option on older bzrs
[17:43] <SamB> mgz: that's funny, I *had* 2.5 ...
[17:44] <SamB> ... is there a way to disable these "Doing on-the-fly conversion" warnings ... ?
[17:44]  * mgz double checks the lockdir code
[17:48] <mgz> SamB: `bzr config --scope=bazaar locks.steal_dead=true`
[17:49] <mgz> seems it didn't get flipped for 2.5 after all.
[17:49] <SamB> thanks
[17:50] <mgz> best way to lose the conversion warnings is to upgrade both sides to 2a
[17:57] <mgrandi> hello
[17:59] <mgz> hey mgrandi
[18:00] <mgz> and how are you this evening?
[18:00] <mgrandi> well, still morning for me haha
[18:00] <mgrandi> spent all of yesterday at work trying to fix a problem where my universities wifi wasn't authenticating me >.>
[18:01] <mgz> that's always joyous
[18:02] <mgrandi> it was, even more since there is a wonderful layer of redtape and the left hand doesn't know what the right is doing, so pretty much impossible to talk to the people who can actually figure out whats going wrong
[18:03] <mgrandi> and the 'public' wifi means i can (barely) only use a web browser, and some webpages don't work on that, but its fixed nwo
[18:05] <mgrandi> HOWEVER, i was wondering, if there are any ways to test like...the integrity of a branch, unit tests or something, because i want to see if this bzr plugin for some IDE still works (it was last updated in early 2011)
[18:12] <SamB> bzr has no magical knowledge of what the code in a branch is supposed to do ...
[18:12] <mgrandi> i meant was
[18:12] <mgrandi> the actual branch
[18:12] <mgrandi> not what's inside of it
[18:12] <SamB> you just want to check that it's not corrupt?
[18:13] <mgrandi> yeah more or less. to see if the plugin works and isn't going to corrupt any repositiories i have
[18:17] <SamB> "bzr check" does some stuff ...
[18:19] <mgrandi> i knew of that, just wondering if there was anything else
[18:20] <mgz> so, if the plugin itself has tests, you can run those
[18:20] <mgrandi> it doesn't seem to have tests
[18:20] <mgz> generally with `bzr selftest -s bp.PLUGINNAME`
[18:20] <mgrandi> well its not a bzr plugin
[18:21] <mgrandi> its a plugin for a IDE that interacts with bzr, somehow (haven't looked at it indepth yet)
[18:22] <mgz> okay, not having tests is bad
[18:22] <mgz> but in general, just make sure you mirror the branch you're working on somewhere else as well?
[18:23] <mgrandi> yeah
[18:23] <mgz> the main plus of dvcs is you have backups on everyone else's machines
[18:26] <mgrandi> yeah
[18:26] <mgrandi> it 'looks' like its just calling the bzr executable
[18:26] <mgrandi> ShellCommandService.getInstance(project).execute(hgFile.getRepo(), "revert", Arrays.asList("-q", "--no-backup", hgFile.getRelativePath()));
[18:35] <mgrandi> so i'll research it more.
[22:25] <poolie> hi all
[22:26] <jelmer> g'morning poolie
[22:26] <poolie> hey there