| === poolie_ is now known as poolie | ||
| poolie | hi there mgz | 07:24 |
|---|---|---|
| vila | hello there ! | 07:40 |
| mgz | morning! | 07:59 |
| poolie | hi mgz, jelmer, vila | 08:03 |
| poolie | shall we talk? | 08:03 |
| * vila mumbles | 08:04 | |
| mgz | I'm on. | 08:04 |
| lifeless | jelmer: hi, around / | 08:23 |
| 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:30 |
| hrw | http://pastebin.com/1VqWu9Ag to be exact | 08:31 |
| mgz | hrw: not a very useful traceback that, sec | 08:41 |
| hrw | mgz: I know. | 08:42 |
| mgz | what's merge_changelog.py ? It's not the changelog-merge plugin. | 08:42 |
| 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:43 |
| hrw | gnome-terminal suxx when it comes to copy/paste ;( | 08:44 |
| 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:45 |
| 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:46 |
| 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:47 |
| 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:50 |
| 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:51 |
| 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:52 |
| 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:54 |
| mgz | I'll work out how to make the logging module do something sane later | 08:55 |
| lifeless | jelmer: nvm - see #subunit | 08:55 |
| mgz | hrw: so, if you want try editing merge_changelog.py with that and then remerge | 08:56 |
| 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:57 |
| 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:58 |
| 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 | 08:59 |
| 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:00 |
| jelmer | are we standing up? | 09:02 |
| mgz | I am! | 09:02 |
| hrw | ok, /me -> reporting bug | 09:03 |
| mgz | ...we did it at 8 I'm afraid jelmer | 09:03 |
| mgz | hrw: thanks, include all your bits, especially the ostrze◈enie parts | 09:04 |
| hrw | sure | 09:05 |
| 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:06 |
| mgz | we were ignoring it the last few weeks as poolie wasn't around, which was probably confusing | 09:07 |
| poolie | ah oops | 09:09 |
| poolie | i can try to be away next tuesday :) | 09:09 |
| mgz | ehehe | 09:09 |
| hrw | mgz: bug 893495 | 09:10 |
| ubot5 | 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:10 |
| 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:12 |
| hrw | mgz: I hope that I did not forgot anything | 09:13 |
| mgz | hrw: thanks, that should do (though you used LANG=C so it hides why the logging failed!) | 09:15 |
| hrw | mgz: no, message is same but now more people may understand it | 09:17 |
| 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:18 |
| hrw | mgz: ok, will add | 09:19 |
| hrw | added comment | 09:19 |
| 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:20 | |
| 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:21 |
| mgz | just attaching the raw changelog with conflict markers may be useful. | 09:22 |
| hrw | I have BASE/THIS/OTHER | 09:24 |
| hrw | attached all of them | 09:25 |
| mgz | great! | 09:25 |
| mgz | hopefully you can now manually resolve the conflict and continue working. | 09:25 |
| hrw | yep | 09:26 |
| hrw | thx for help | 09:26 |
| mgz | ...and naturally dpkg-mergechangelog works fine on those files for me, so the bug is somewhere else | 09:29 |
| hrw | mgz: I will push my branch to LP so you can try it on your system | 09:30 |
| jelmer | vila: updated | 09:30 |
| vila | hehe, you mean updat*ing* :) | 09:31 |
| hrw | mgz: pushed, remember to use r71 not head | 09:31 |
| jelmer | vila: no, really done now :) | 09:32 |
| vila | ok :) Thanks ! | 09:32 |
| mgz | I guess changelog.this is 0 bytes in /tmp it's not clear how that happened | 09:36 |
| 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:37 |
| jelmer | vila: hpss-branch-store branch submitted :) | 09:38 |
| 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:54 |
| mgz | I wanted vi back, and got information about my disk usage instead, thanks unix! | 09:55 |
| jelmer | :) | 10:04 |
| vila | jelmer: reviewed, small tweaks, but big +1 overall and many thanks | 10:40 |
| jelmer | vila: that was quick :) Thanks | 10:41 |
| vila | jelmer: hehe, the context was paged in, it helped ;) | 10:42 |
| vila | jelmer: and I trust the tests are robust enough :) | 10:43 |
| 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:45 |
| mgz | jelmer: I wouldn't blame the post-its | 10:47 |
| mgz | the number of mps you've submitted would tax any glue | 10:48 |
| mgz | the board must be about ready to collapse | 10:48 |
| jelmer | mgz: I hope not. I'm using one of the load-carrying walls here.. ;-) | 10:50 |
| jelmer | mgz: you seem to have a couple of approved branches, btw | 10:58 |
| mgz | jelmer: thinking of commit messages is hard? | 11:17 |
| mgz | I mean, sure, I'll get them landed. :) | 11:17 |
| 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:18 |
| mgz | jelmer: what's the protocol for unprivating? bug 876511 is interesting and doesn't seem to have any personal info. | 11:20 |
| ubot5 | Error: Launchpad bug 876511 could not be found | 11:20 |
| mgz | how little you know, ubot5 | 11:20 |
| jelmer | mgz: :) | 11:20 |
| 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:21 |
| mgz | some part of the testament code is getting a bytestring and thinking it's unicode | 11:22 |
| 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:23 |
| mgz | revision-ids would be possible but... seems unlikely | 11:24 |
| mgz | revprops is the other candidate | 11:24 |
| mgz | list_files uses os.listdir which is always a bad sign. | 11:26 |
| jelmer | vila: I'm not sure I understand your last comment on hpss-branch-store | 11:28 |
| vila | the one about adding comments ? | 11:28 |
| 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:29 |
| vila | the ones I pasted should be enough to raise awareness that there is something going on with these stacks | 11:30 |
| jelmer | vila: but do you want me to add comments to hpss-branch-store, or were you just providing context? | 11:31 |
| 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:32 |
| 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:33 |
| 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:34 |
| 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:35 |
| 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:36 |
| 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:37 |
| 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:38 |
| 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:39 |
| 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:40 |
| vila | argh, then your proposal is bogus and I failed to see that | 11:41 |
| 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:42 |
| 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:43 |
| jelmer | vila: used the wrong stack where? | 11:44 |
| 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:45 |
| 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:46 |
| vila | jelmer: does that make sense ? | 11:47 |
| jelmer | vila: yep | 11:48 |
| vila | jelmer: pfew, thanks :) | 11:49 |
| vila | these are existing grey areas that concern only those two options afaik | 11:49 |
| vila | which I why I defined these stacks without using them yet as a reminder that these options are... special | 11:50 |
| 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:51 |
| vila | yeah, in this other proposal I was naming them control_stack_only and remote_branch_only | 11:52 |
| 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:53 |
| 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:55 |
| vila | some options are handled with GlobalStack, some are handled with BranchStack for example | 11:56 |
| jelmer | vila: updated | 11:56 |
| 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 | 11:59 |
| vila | right, bzr config -d lp:xxx now displays bazaar.conf content, I should have thought to check that | 12:13 |
| jelmer | I thought it always did that? | 12:18 |
| jelmer | that seems right to me | 12:18 |
| vila | taking your previous example, `bzr config child_submit_to` would be broken if it was | 12:20 |
| jelmer | vila: ah, sorry. You mean it only displays bazaar.conf content | 12:21 |
| 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:22 |
| 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:23 |
| 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:24 |
| 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:29 | |
| jelmer | vila: merci et bon appetit :) | 12:58 |
| * jelmer has a somewhat limited French vocabulary | 12:58 | |
| vila | jelmer: you've already got the most important ones :) ... "Je vous aime" can help in many situations too ;-D | 13:03 |
| jelmer | hehe | 13:07 |
| 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. | 13:08 |
| 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:27 |
| jelmer | mull: thanks. I've just followed up | 14:48 |
| mull | ok. oops, I had completely forgotten that I left an "assert" in there... that's not ideal | 14:50 |
| 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 | 16:05 |
| === deryck is now known as deryck[lunch] | ||
| === beuno is now known as beuno-lunch | ||
| 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:06 |
| jelmer | GRiD: it's still in beta, and far behind git/svn imports | 17:09 |
| GRiD | jelmer, ok. well, i used the standard launchpad interface for doing the import. is it worth filing a launchpad bug? | 17:11 |
| GRiD | actually, i see there is one. bug #806904 | 17:15 |
| ubot5 | Launchpad bug 806904 in Launchpad itself "Mercurial import fails from Google code" [High,Triaged] https://launchpad.net/bugs/806904 | 17:15 |
| === beuno-lunch is now known as beuno | ||
| === deryck[lunch] is now known as deryck | ||
| 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 | 18:45 |
| === mull is now known as Guest87506 | ||
| Noldorin | hi folks | 21:15 |
| jelmer | hi Noldorin | 21:15 |
| Noldorin | hi jelmer | 21:15 |
| Noldorin | how's it going? | 21:15 |
| jelmer | Noldorin: I'm alright. how are you? | 21:53 |
| Noldorin | jelmer, pretty good. going to have a go at a small patch poolie and i were talking about | 21:55 |
| poolie | hi all | 22:19 |
| thomi|work_ | wgz: sorry for the delay: http://pastebin.com/Bi1ZseQL | 22:46 |
| 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:04 |
| wgz | thomi|work_: <http://float.endofinternet.org/temp/pageant.zip> is a non-debug pageant with the fix | 23:05 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!