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