[07:24] <poolie> hi there mgz
[07:40] <vila> hello  there !
[07:59] <mgz> morning!
[08:03] <poolie> hi mgz, jelmer, vila
[08:03] <poolie> shall we talk?
[08:04]  * vila mumbles
[08:04] <mgz> I'm on.
[08:23] <lifeless> jelmer: hi, around /
[08:30] <hrw> hi
[08:30] <hrw> UnicodeDecodeError: 'ascii' codec can't decode byte 0xc5 in position 23: ordinal not in range(128)
[08:30] <hrw> I got this during merge
[08:31] <hrw> http://pastebin.com/1VqWu9Ag to be exact
[08:41] <mgz> hrw: not a very useful traceback that, sec
[08:42] <hrw> mgz: I know.
[08:42] <mgz> what's merge_changelog.py ? It's not the changelog-merge plugin.
[08:43] <mgz> ah, in bzr-builddeb
[08:43] <hrw> moment
[08:43] <hrw> /usr/share/pyshared/bzrlib/plugins/builddeb/merge_changelog.py
[08:43] <mgz> what's your line 73 in that?
[08:43] <hrw> 2.7.9ubuntu1 version from precise
[08:44] <hrw> gnome-terminal suxx when it comes to copy/paste ;(
[08:45] <hrw>             _logger.warning('%s', stderr)
[08:45] <hrw>             # Relay the warning from dpkg-mergechangelogs to the user.  We
[08:45] <mgz> okay, I have that on the tag too.
[08:46] <hrw> I merged lp:ubuntu/gcc-4.6 into lp:~hrw/ubuntu/precise/gcc-4.6/cross-fixes
[08:46] <mgz> hrw: file a bug, looks like the log statement is just slightly borked
[08:46] <hrw> ok, thx
[08:47] <mgz> I think all you lost was the detail output from dpkg-mergechangelogs', base_filename, this_filename, other_filename], stdout=sub
[08:47] <mgz> ...bad paste
[08:47] <hrw> mgz: bzr diff after merge tells me that whole changelog was dropped
[08:50] <mgz> I want to say do `bzr remerge debian/changlog` but I'm not certain that will do the right thing with builddeb
[08:50] <hrw> may try
[08:51] <hrw> did not
[08:51] <mgz> same problem, or different one?
[08:51] <hrw> http://paste.ubuntu.com/745683/
[08:51] <mgz> ta.
[08:51] <mgz> okay, that's good.
[08:52] <hrw> so bug against bzr-builddeb?
[08:52] <mgz> yeah, but I can give you a patch to try now so you can see the output
[08:52] <hrw> ok
[08:54] <hrw> btw - how to tell bzr that I solved conflicts in files?
[08:54] <mgz> ...hm, simplest thing is problably, change the logger line to:
[08:54] <jelmer> hrw: "bzr resolved"
[08:54] <jelmer> lifeless: hi
[08:54] <hrw> jelmer: thx
[08:54] <mgz>     _logger.warning('%s', stderr.decode("utf-8","replace"))
[08:54] <mgz> just for now
[08:55] <mgz> I'll work out how to make the logging module do something sane later
[08:55] <lifeless> jelmer: nvm - see #subunit
[08:56] <mgz> hrw: so, if you want try editing merge_changelog.py with that and then remerge
[08:57] <hrw> debian/changelog is not conflicted
[08:57] <hrw> dpkg-mergechangelogs: ostrzeżenie: /tmp/tmpKJKi6cdeb_changelog_merge/changelog.this(l0): oczekiwano first heading, a znaleziono koniec pliku
[08:57] <hrw> dpkg-mergechangelogs: błąd: ss-970814-1 is not a valid version
[08:57] <hrw> All changes applied successfully.
[08:57] <hrw> shit. forgot LC_ALL=C
[08:57] <hrw> anyway still 10K -
[08:57] <mgz> it's okay, the messages are for your benefit :)
[08:58] <hrw> btw - are there plans for 'bzr diff --stat'?
[08:58] <hrw> bzr diff|diffstat is longer to write ;)
[08:58] <poolie> that would be good
[08:59] <mgz> okay, so one issue is the logging is borked, the other seems to be that a failure from dpkg isn't resulting in a conflict you could try and resolve via other means
[09:00] <mgz> jelmer may know more.
[09:00] <hrw> poolie: and may give 'bzr log --stat' which in git land is one of my favorite
[09:02] <jelmer> are we standing up?
[09:02] <mgz> I am!
[09:03] <hrw> ok, /me -> reporting bug
[09:03] <mgz> ...we did it at 8 I'm afraid jelmer
[09:04] <mgz> hrw: thanks, include all your bits, especially the ostrze◈enie parts
[09:05] <hrw> sure
[09:06] <mgz> jelmer: we need a part 2 to get your update maybe
[09:06] <jelmer> mgz: oh crap, I didn't realize we had a DST change :-(
[09:07] <mgz> we were ignoring it the last few weeks as poolie wasn't around, which was probably confusing
[09:09] <poolie> ah oops
[09:09] <poolie> i can try to be away next tuesday :)
[09:09] <mgz> ehehe
[09:10] <hrw> mgz: bug 893495
[09:12] <vila> jelmer: the pad is at http://pad.ubuntu.com/bdhvpZX7Hn if you want to update it
[09:12] <vila> jelmer: if you don't, just tell me and I'll post it to the ml
[09:13] <hrw> mgz: I hope that I did not forgot anything
[09:15] <mgz> hrw: thanks, that should do (though you used LANG=C so it hides why the logging failed!)
[09:17] <hrw> mgz: no, message is same but now more people may understand it
[09:18] <mgz> hrw: attaching the changelog.this might help understand why dpkg is failing, it gets removed but...
[09:18] <hrw> mgz: there is no 'changelog.this' or changelog.BASE etc
[09:18] <mgz> hrw: yes, that's good, but the reason logging failed was because your locale has non-ascii error messages
[09:18] <mgz> hrw: yes, because the merge wrongly reports it succeeded
[09:19] <hrw> mgz: ok, will add
[09:19] <hrw> added comment
[09:20] <mgz> if you `bzr --no-plugins remerge debian/changelog` what happens?
[09:20]  * mgz hasn't played enough with bzr-builddeb yet to know all its tricks
[09:21] <hrw> debian/changelog is not conflicted
[09:21] <hrw> Text conflict in debian/changelog
[09:21] <hrw> 1 conflicts encountered.
[09:21] <hrw> mgz: cool!
[09:21] <mgz> that's better, do you now have a .THIS?
[09:22] <mgz> just attaching the raw changelog with conflict markers may be useful.
[09:24] <hrw> I have BASE/THIS/OTHER
[09:25] <hrw> attached all of them
[09:25] <mgz> great!
[09:25] <mgz> hopefully you can now manually resolve the conflict and continue working.
[09:26] <hrw> yep
[09:26] <hrw> thx for help
[09:29] <mgz> ...and naturally dpkg-mergechangelog works fine on those files for me, so the bug is somewhere else
[09:30] <hrw> mgz: I will push my branch to LP so you can try it on your system
[09:30] <jelmer> vila: updated
[09:31] <vila> hehe, you mean updat*ing* :)
[09:31] <hrw> mgz: pushed, remember to use r71 not head
[09:32] <jelmer> vila: no, really done now :)
[09:32] <vila> ok :) Thanks !
[09:36] <mgz> I guess changelog.this is 0 bytes in /tmp it's not clear how that happened
[09:37] <mgz> also I get *some* output like that, and one of the three copies has to have content or you wouldn't get the complaint about the version number from 1997
[09:38] <jelmer> vila: hpss-branch-store branch submitted :)
[09:54] <mgz> the great thing about unix tool naming conventions is you can accidentally have your hand over the wrong place on the keyboard, and you'll still end up running something
[09:55] <mgz> I wanted vi back, and got information about my disk usage instead, thanks unix!
[10:04] <jelmer> :)
[10:40] <vila> jelmer: reviewed, small tweaks, but big +1 overall and many thanks
[10:41] <jelmer> vila: that was quick :) Thanks
[10:42] <vila> jelmer: hehe, the context was paged in, it helped ;)
[10:43] <vila> jelmer: and I trust the tests are robust enough :)
[10:45] <jelmer> :-)
[10:45] <jelmer> sigh, this is the last time I'm buying cheap post-it notes. My real-life kanban board is coming apart
[10:47] <mgz> jelmer: I wouldn't blame the post-its
[10:48] <mgz> the number of mps you've submitted would tax any glue
[10:48] <mgz> the board must be about ready to collapse
[10:50] <jelmer> mgz: I hope not. I'm using one of the load-carrying walls here.. ;-)
[10:58] <jelmer> mgz: you seem to have a couple of approved branches, btw
[11:17] <mgz> jelmer: thinking of commit messages is hard?
[11:17] <mgz> I mean, sure, I'll get them landed. :)
[11:18] <LeoNerd> I sometimes find the trick with commit messages is managing to get them brief enough
[11:18] <LeoNerd> I have a tendancy sometimes to waffle on a bit
[11:20] <mgz> jelmer: what's the protocol for unprivating? bug 876511 is interesting and doesn't seem to have any personal info.
[11:20] <mgz> how little you know, ubot5
[11:20] <jelmer> mgz: :)
[11:21] <jelmer> LeoNerd: Hah, I have the opposite
[11:21] <jelmer> LeoNerd: which is also problematic
[11:21] <jelmer> mgz: basically, if it doesn't contain any private info, feel free to unprivatize it
[11:21] <jelmer> I think apport creates private bugs by default
[11:22] <mgz> some part of the testament code is getting a bytestring and thinking it's unicode
[11:23] <jelmer> that's bad
[11:23] <mgz> I'm not sure which though :)
[11:23] <mgz> what does tree.list_files return for paths?
[11:24] <mgz> revision-ids would be possible but... seems unlikely
[11:24] <mgz> revprops is the other candidate
[11:26] <mgz> list_files uses os.listdir which is always a bad sign.
[11:28] <jelmer> vila: I'm not sure I understand your last comment on hpss-branch-store
[11:28] <vila> the one about adding comments ?
[11:29] <jelmer> vila: yeah, about RemoteBranchStack and cmdline overrides
[11:29] <vila> these stacks are... weird/obscure, the comments intend to clarify why they exist at all
[11:29] <jelmer> vila: what kind of comment would you like me to add?
[11:30] <vila> the ones I pasted should be enough to raise awareness that there is something going on with these stacks
[11:31] <jelmer> vila: but do you want me to add comments to hpss-branch-store, or were you just providing context?
[11:32] <vila> just adding comments before the classes
[11:32] <vila> so people don't think they can use them
[11:32] <vila> they are a symptom that something else need to be fixed
[11:33] <jelmer> vila: actually, I'm not sure I understand why the other stores aren't in there
[11:33] <jelmer> vila: it seems like the global and location stores would apply for remote branches too
[11:34] <vila> doing so means the local user can enforce some policies on the remote server
[11:34] <jelmer> vila: the policies aren't sent to the remote server, so nothing will be done that the user isn't already allowed to
[11:35] <jelmer> vila: i.e. I have lines like this in my locations.conf:
[11:35] <jelmer> [bzr+ssh://bazaar.launchpad.net/*]
[11:35] <jelmer> child_submit_to = merge@code.launchpad.net
[11:35] <vila> the policy depends on the config option
[11:36] <jelmer> vila: can you give an example of where it would be problematic?
[11:36] <vila> for some options it's ok to give control to the user, for some others, the actual code don't give this control
[11:36] <vila> don't turn the tables :)
[11:36] <vila> I'm merely respecting what the code does ;)
[11:37] <vila> another way to look at it is to think about the *server* locations.conf and bazaar.conf files which lp doesn't define but that other servers can
[11:38] <vila> and think about the (weird and maybe useless) case where a server can be accessed as a smart server *and* as a dumb server
[11:38] <jelmer> vila: The existing code does look at locations.conf
[11:38] <vila> for the options I mentioned in the comments ?
[11:39] <jelmer> vila: no, but for other options - like child_submit_to, or remote_ssh_path
[11:39] <vila> right, these stacks aren't used for the other options :)
[11:40] <mgz> nope, can't repo it, filenames and properties seem fine
[11:40] <jelmer> vila: I don't see how remote_branch.get_config_stack().get("child_submit_to") can look in locations.conf
[11:41] <vila> argh, then your proposal is bogus and I failed to see that
[11:42] <jelmer> vila: how do you imagine it will be able to look in locations.conf ?
[11:42] <vila> it should use a BranchStack but query the branch for the right store
[11:42] <jelmer> vila: that's what I was proposing earlier :)
[11:43] <vila> yeah and I agreed with that, I missed it when reviewing, lack of tests too
[11:43] <jelmer> vila: I still don't really see where your comments about branch_only_stacks come in
[11:43] <vila> you're right in to the trap
[11:43] <vila> you used the wrong stack
[11:43] <vila> well, somehow
[11:44] <jelmer> vila: used the wrong stack where?
[11:45] <vila> RemoteBranch.get_config_stack() should use config.BranchStack(),
[11:45] <vila> and config.BranchStack should ask the branch for the right store
[11:45] <vila> RemoteBranchStack should be used only for stacked_on_location
[11:46] <vila> and I don't know if RemoteBzrdir.get_config_stack() should be defined at all... it's likely to cause the same kind of confusion
[11:47] <vila> jelmer: does that make sense ?
[11:48] <jelmer> vila: yep
[11:49] <vila> jelmer: pfew, thanks :)
[11:49] <vila> these are existing grey areas that concern only those two options afaik
[11:50] <vila> which I why I defined these stacks without using them yet as a reminder that these options are... special
[11:51] <vila> .. in the existing code I mean
[11:51] <jelmer> vila: I think Remote{Branch,Control}Stack is a really confusing name in this case though
[11:52] <vila> yeah, in this other proposal I was naming them control_stack_only and remote_branch_only
[11:53] <vila> or rather control_only_stack and branch_only_stack, anyway, 'only' is the important part ;)
[11:53] <vila> even cmdline_overrides shouldn't apply there... I think :)
[11:55] <vila> the specific aspect that is not clear in the actual config scheme is option policy, stacks helps a bit, but really, what defines an option policy is which stack is used to handle them in the code,
[11:56] <vila> some options are handled with GlobalStack, some are handled with BranchStack for example
[11:56] <jelmer> vila: updated
[11:59] <jelmer> vila: I've now just changed BranchStore to call Branch._get_config_store(), and bzrlib.remote doesn't have anything related to stacks anymore
[11:59] <vila> reading already
[12:13] <vila> right, bzr config -d lp:xxx now displays bazaar.conf content, I should have thought to check that
[12:18] <jelmer> I thought it always did that?
[12:18] <jelmer> that seems right to me
[12:20] <vila> taking your previous example, `bzr config  child_submit_to` would be broken if it was
[12:21] <jelmer> vila: ah, sorry. You mean it only displays bazaar.conf content
[12:22] <vila> no, I mean it now displays branch.conf *and* bazaar.conf (nothing relevant in locations.conf so nothing is displayed) instead of only branch.conf
[12:22] <jelmer> vila: it never displayed just branch.conf
[12:23] <jelmer> vila: if I only have bzr_remote_path set in bazaar.conf it would previously show that too
[12:23] <vila> jelmer: it did with revno 6284 if your proposal
[12:23] <vila> s/if/in/
[12:23] <vila> when doing  ./bzr config -d lp:~jelmer/bzr/switch-colocated
[12:23] <jelmer> vila: r6284 of my proposal is wrong :)
[12:24] <vila> yes
[12:24] <vila> oh, sorry, I was so unclear
[12:24] <vila> what I meant is that I could have use that to see 6284 was wrong
[12:24] <jelmer> ah
[12:24] <vila> because it wasn't displaying bazaar.conf anymore
[12:29] <vila> jelmer: done, some last nits if you feel like taking them into account
[12:29] <vila> well, at least the news entry one :)
[12:29]  * vila lunch
[12:58] <jelmer> vila: merci et bon appetit :)
[12:58]  * jelmer has a somewhat limited French vocabulary
[13:03] <vila> jelmer: you've already got the most important ones :) ... "Je vous aime" can help in many situations too ;-D
[13:07] <jelmer> hehe
[13:08] <jelmer> French is the main language of one of the other projects I'm involved in (OpenChange), so I do read quite a bit of it.
[14:27] <mull> jelmer, hi, thanks for looking at my fastimport patch; I've just proposed a merge.  Feel free to ping me here if you have questions.
[14:48] <jelmer> mull: thanks. I've just followed up
[14:50] <mull> ok.  oops, I had completely forgotten that I left an "assert" in there... that's not ideal
[16:05] <mgz> have, that's a nice suprise,
[16:05] <mgz> 5 second runtime down to 2 second runtime
[16:05] <mgz> that will make a 0.0001% to the build process
[17:06] <GRiD> hm. in general, a bzr import from mercurial (on google code) to launchpad should work? looks like bzr 2.5.0 according to this error log.
[17:09] <jelmer> GRiD: it's still in beta, and far behind git/svn imports
[17:11] <GRiD> jelmer, ok. well, i used the standard launchpad interface for doing the import. is it worth filing a launchpad bug?
[17:15] <GRiD> actually, i see there is one. bug #806904
[18:45] <mull> jelmer, now I know why I wrote the code how I did... when you say "bzr fast-export x..y", revisions up to and including x are _already_ chopped off
[18:45] <mull> so my code was getting the parent of revision x+1
[18:45] <mull> funny that I couldn't remember that 24 hours later, and it took writing the test case to realize
[21:15] <Noldorin> hi folks
[21:15] <jelmer> hi Noldorin
[21:15] <Noldorin> hi jelmer
[21:15] <Noldorin> how's it going?
[21:53] <jelmer> Noldorin: I'm alright. how are you?
[21:55] <Noldorin> jelmer, pretty good. going to have a go at a small patch poolie and i were talking about
[22:19] <poolie> hi all
[22:46] <thomi|work_> wgz: sorry for the delay: http://pastebin.com/Bi1ZseQL
[23:04] <wgz> thomi|work_: thanks, it does look like 0.61 triggered a lot of this pain then, because the 'ours' old and new values are different there
[23:05] <wgz> thomi|work_: <http://float.endofinternet.org/temp/pageant.zip> is a non-debug pageant with the fix