=== tchan1 is now known as tchan
[06:52] <poolie> ok back to memory usage
[06:52] <poolie> so much state to pick up
[07:21] <vila> hi all, hey poolie
[07:22] <poolie> hi there vila
[07:24] <poolie> hi jam :)
[08:01]  * jelmer waves
[08:03] <mgz> morning all
[08:04] <jelmer> hey mgz
[08:10] <mgz> poolie, vila: standup?
[08:11] <poolie> oh hi
[08:11] <poolie> was having so much fun
[08:11] <poolie> good idea
[08:58] <vila> mgz, jelmer, poolie: I found the pad for last week standup, will post it (thought I did...) as well as the one for this week
[08:58] <poolie> ok thanks
[08:59] <mgz> so... I guess for the installer work I need access to the ec2 instance and urk, probably something other than just ssh
[08:59] <poolie>  probably you do
[09:00] <poolie> do you have an AWS account?
[09:00] <mgz> nope.
[09:00] <mgz> standard signup okay?
[09:07] <jelmer> vila: I've got a pending MP for bzr-upload from October, I was wondering if you'd seen it: https://code.launchpad.net/~jelmer/bzr-upload/only-strip-slash/+merge/80111
[09:08] <vila> err, yeah I saw it, I thought I merged it 8-/ Let me check
[09:12] <vila> hmm, obviously I didn't...
[09:12] <poolie> mgz, hm, i might need to send you credentials
[09:12] <poolie> i don't think you actually have to sign up
[09:12] <poolie> jam1, hi?
[09:13] <mgz> poolie: that might be better, otherwise they want card etc from me
[09:15] <mgz> I may have trouble till PSU gets delivered, as I lack windowsy things currently
=== jam1 is now known as jam
[09:17] <jam> poolie: hi
[09:19] <poolie> jam, could you help mgz get the windows ami going so he can build an installer etc?
[09:24] <jam> poolie: sure, mgz, you around?
[09:25] <poolie> urk
[09:25] <poolie> that's enough
[09:25] <poolie> jam if you want you could read https://code.launchpad.net/~mbp/bzr/890085-add-bytes/+merge/83735
[09:25] <poolie> it doesn't directly improve anything though
[09:26] <poolie> was kinda hoping it would
[09:26] <poolie> perhaps will leave it on the shelf until it's more clearly useful
[09:27] <mgz> jam: I'm around but what will I need this end? A spider did for my windows machine.
[09:28] <poolie> rdesktop will do
[09:28] <jam> mgz: yeah, its on an ec2 instance
[09:31] <jam> poolie: did you want to make add-bytes have a prereq of BigString so that the review is simpler?
[09:31] <jam> or you want them together
[09:32] <poolie> it's actually independent
[09:32] <poolie> i rebased it out
[09:32] <poolie> ..
[09:32] <poolie> perhaps lp needs to be told
[09:34] <poolie> jam, should be better now
[09:34] <jam> the web page looks good
[09:34] <jam> the email didn't
[09:35] <poolie> i think it doesn't always email updates
[09:35] <poolie> not sure of the logic
[09:35] <jam> poolie: so we actually need to change the Pack code to take a [chunks] parameter instead of a 'bytes' one.
[09:35] <poolie> i know
[09:35] <poolie> i'd really better go
[09:35] <poolie> i know this isn't sufficient by itself
[09:36] <poolie> i hoped it would show an incremental improvement but apparently not
[09:36] <jam> I'll comment on why it isn't sufficient, have a good night.
[09:36] <poolie> i'm a bit surprised there is nothing though
[09:36] <poolie> i do understand other stuff is joining up the strings
[09:37] <jam> poolie: well, we have to ''.join() the zlib chunks to pass it to the pack parameter
[09:37] <jam> and then we delete the chunks
[09:37] <jam> so there is one peak
[09:37] <jam> then the pack code does it *again*
[09:37] <jam> and we have the second peak
[09:37] <jam> we have to get rid of both
[09:37] <poolie> yep
[09:37] <poolie> got that
[09:38] <poolie> so mostly for this review i'm hoping for "not wrong" and "in the right direction"
[09:41] <vila> jelmer: sorry, in parallel with your review, I realized I missed the points you re-raised, was about to say so in the proposal ;)
[09:41] <pitti> hello
[09:42] <pitti> who is responsible for http://bazaar.launchpad.net?
[09:42] <pitti> today's Xubuntu CDs failed to build because http://bazaar.launchpad.net/~xubuntu-dev/ubuntu-seeds/platform.precise/ ceased to exist
[09:42] <pitti> but https://code.launchpad.net/~xubuntu-dev/ubuntu-seeds/xubuntu.precise exists, and bzr pull works fine, etc.
[09:43] <Peng> pitti: #launchpad in general
[09:43] <pitti> Peng: ok, will try there, thanks
[09:44] <jam> pitti: I have a feeling a $platform forgot to be expanded.
[09:44] <jam> $platform vs platform, etc.
[09:44] <Peng> Ooh, good catch
[09:44] <Peng> http://bazaar.launchpad.net/~xubuntu-dev/ubuntu-seeds/xubuntu.precise/ works
[09:45] <Peng> And https://code.launchpad.net/~xubuntu-dev/ubuntu-seeds/platform.precise does not exist.
[09:45] <jam> yeah, you can go to: https://code.launchpad.net/~xubuntu-dev/ubuntu-seeds to see what branches exist underneath it.
[09:45] <pitti> oh, I see
[09:45] <Peng> pitti: Sorry for the hopping back and forth.
[09:45] <pitti> sorry, missed that
[09:46] <pitti> I'll go back to poking the cdimage folks then :)
[09:48] <pitti> actually, it seems it's meant to be like that, it just had trouble reading http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/platform.precise
[09:49] <pitti> but that works, so maybe it was just a glitch; I'll retry the build
[09:49] <jam> pitti: ~ubuntu-core-dev/.../platform.precise is not the same as ~xubuntu-dev/.../platform.precise
[09:50] <jam> "(10:42:12 AM) pitti: today's Xubuntu CDs failed to build because http://bazaar.launchpad.net/~xubuntu-dev/ubuntu-seeds/platform.precise/ ceased to exist"
[09:50] <pitti> jam: right, as I said I just misunderstood the logs
[09:50] <jam> ah, ok
[09:50] <jam> the names are pretty similar
[09:50] <pitti> it apparently tries to pull the "platform" seed for both the derivative and ubuntu
[09:50] <jelmer> vila: np, I figured you just missed it
[09:50] <pitti> and both failed, I just looked at the wrong one
[10:17] <vila> jelmer: ping, po_merge options registrations,
[10:18] <vila> good catch (my god, what was I thinking !), but lazy won't gain us anything here
[10:18] <vila> it's useful only it it helps *not* loading additional stuff from the plugin but nothing is required here
[10:19] <vila> importing config is required but it is also required to register the options anyway
[10:23] <jelmer> vila: it prevents running the constructor of the option objects, not sure how heavy that is
[10:24] <jelmer> and potentially having to import whatever method is used for from_unicode
[10:26] <vila> Option() constructor should be << import config time, if a specific from_unicode method is needed, yes, lazy should be used to get access to it
[10:26] <vila> overall, I should use lazy to set a good example :) Will fix
[11:16] <mgz> ahh, a windows machine, it's been so long...
[11:16] <mgz> (well... since thursday)
[11:18] <mgz> ...a java update is available, okay, novelty has worn off
[11:28] <vila> mgz: probably a TZ update :-}
[11:42] <vila> jelmer: are bug #894461, bug #368717 and bug #608640 fix released or not ? tool/check-newsbug.py is confused :)
[11:42] <ubot5> Launchpad bug 894461 in Bazaar "HPSS call for Repository.pack" [Medium,In progress] https://launchpad.net/bugs/894461
[11:42] <ubot5> Launchpad bug 762330 in Bazaar "duplicate for #368717 lightweight checkout over hpss is slow, many roundtrips" [Medium,Fix released] https://launchpad.net/bugs/762330
[11:42] <ubot5> Launchpad bug 608640 in Bazaar "bzr export from remote branches downloads way more data than it should" [Medium,In progress] https://launchpad.net/bugs/608640
[11:43] <vila> the duplicate is weird in itself but what about the others ?
[11:43] <jelmer> vila: I've marked #894461 fixreleased
[11:43] <jelmer> vila: it's debatable whether the other two are fixreleased yet
[11:44] <jelmer> the HPSS branch for Repositor.iter_files_bytes is the first part of it, I consider the HPSS call for Repository.iter_inventories also necessary for it
[11:44]  * vila nods
[11:50] <zyga> hi
[11:50] <jelmer> hi zyga
[11:50] <zyga> is there any way to speed up accessing bzrlib.branch.Branch().nick on a checkout?
[11:50] <zyga> it takes veery long, much longer than revno() which is the other thing I'm intereted in
[11:50] <jelmer> zyga: there has been some talk on making branch.Brnach().nick only access the local branch, and synchronising it on "bzr up"
[11:50] <jelmer> zyga: in the mean time, you can use:
[11:51] <jelmer> bzrlib.branch.Branch._get_nick(local=True)
[11:51] <zyga> oh!
[11:51] <zyga> excellent
[11:51] <zyga> how will that differ from the other method?
[11:51] <zyga> will it raise exceptions or return out-of-date data?
[11:51] <jelmer> it only accesses the local branch nick, not the remote one
[11:52] <jelmer> so you'll also have to explicitly set the local branch nick
[11:53]  * zyga checks what it does on his branches
[12:08] <hrw> hi
=== mrevell_ is now known as mrevell
[12:19] <jelmer> hi hrw
[12:22] <hrw> I have question (again). probably one of stupid ones. I have lp:~hrw/ubuntu/precise/gcc-4.6/cross-fixes branch and want to generate diff against lp:ubuntu/precise/gcc-4.6 branch. is there other way then fetch both and then diff directories?
[12:23] <jelmer> hrw: in theory you could do the diff without downloading the branches. with the current smart server deployed on Launchpad, that will probably be about as slow as actually pulling down the branches.
[12:24] <hrw> jelmer: first branch I already have on disk
[12:24] <hrw> s/have/had
[12:24] <hrw> I fetched second one and diffed dirs
[12:25] <hrw> have to experiment with bzr-colo later
[12:25] <hrw> as with git I would have both in one .git
[12:25] <hrw> bb in ~20 minutes
[12:25] <zyga> hrw: yes
[12:26] <zyga> hrw: bzr diff --old one-branch --new other-branch
[12:26] <zyga> hrw: you can skip either argument if you are in a branch already
[12:26] <jelmer> hrw: you can fetch into a shared repository without trees, that should have the same behaviour as bzr-colo or a single .git directory
[12:27] <jelmer> bzr init-repo --no-trees gcc; bzr branch lp:~hrw/ubuntu/precise/gcc-4.6/cross-fixes gcc/cross-fixes; bzr branch lp:ubuntu/precise/gcc-4.6 gcc/4.6
[12:27] <zyga> jelmer: I think hrw already has a shared repo for gcc
[12:27] <zyga> so he has 99% of the data locally already
[12:28] <zyga> also, with 'bzr diff' you don't need trees
[12:29] <jelmer> zyga: in that case, I don't understand why bzr-colo / .git would are better
[12:29] <zyga>  jelmer they are not
[12:29] <zyga> they are identical
[12:57] <hrw> jelmer: I have a feeling that when I ask about bzr and branches I will always see 'bzr init-repo --no-trees' ;)
[12:57] <hrw> zyga: lp:linaro-gcc != lp:ubuntu/gcc-4.6
[12:58] <zyga> hrw: sure but they may share ancestry
[12:59] <hrw> zyga: they have one thing in common: 3 letters in branch name ;D
[12:59] <hrw> jelmer: will try your stuff
[13:02] <vila> hrw: '3 letters in branch name' seriously ? Not a single revision is shared ? parallel imports ?
[13:04] <hrw> vila: lp:linaro-gcc is copy of gcc source code. lp:ubuntu/gcc-4.6 is debian/ubuntu packaging for gcc-4.6
[13:04] <hrw> like you would compare linux kernel and qt5 repos
[13:05] <mgz> jelmer: is there actually a dulwich 0.8.1 release? I didn't see a tag for it.
[13:05] <vila> oh, upstream and packaging-only branches ? sry, missed that detail
[13:07] <mgz> ..there is... I just don't have the tag
[13:42] <jelmer> mgz: ah, you're trying to build the windows installers?
[13:44] <mgz> yes and it's all your fault >_<
[13:44] <mgz> ...I have one that now works with `bzr info git://...`
[13:58] <jelmer> mgz: what about "bzr clone git://
[13:58] <jelmer>  ?
[13:58] <jelmer> I'm not sure much network activity bzr info generates
[14:02] <vila> jelmer: bug #897690 filed for ObjectNotLocked on jubany
[14:02] <ubot5> Launchpad bug 897690 in bzr-builddeb "bzrlib.errors.ObjectNotLocked raised when calling _mark_native_config" [High,Confirmed] https://launchpad.net/bugs/897690
[14:02] <vila> jelmer: I think I have a fix (testing)
[14:02] <vila> yup, seems to work, proposing
[14:05] <mgz> also works, but tells me 'clone' is deprecated :)
[14:18] <jelmer> vila: ah
[14:19] <vila> jelmer: https://code.launchpad.net/~vila/bzr-builddeb/897690-object-not-locked/+merge/83790
[14:19] <vila> with hopefully enough explanations
[14:29] <jelmer> vila: looking
[14:32] <jelmer> vila: I think you're missing one of the return paths in _default_config_for_tree
[14:33] <jelmer> vila: (still returns 2 elements in the tuple rather than 3)
[14:33] <vila> crap, you're right
[14:34] <jelmer> vila: other than that, it looks good to me
[14:34] <vila> jelmer: including the debian/changelog ? Not sure if I got this right
[14:35] <vila> missed return path fixed
[14:35] <jelmer> though it is slightly odd that path2id doesn't require a read lock..
[14:35] <vila> it does
[14:36] <vila> it has a @needs_read_lock decoratr
[14:36] <vila> tor
[14:36] <jelmer> vila: right, but's slightly surprising imo
[14:36] <vila> yeah, was about to guess a rationale but ended up with a poor one :)
[14:37] <jelmer> vila: not sure if this needs mention in the changelog btw, the regression isn't in any releases
[14:37] <vila> but anyway, digging this route won't address the current issue so I punted
[14:37] <vila> ha, so I just remove that and merge to lp:bzr-builddeb ?
[14:37] <jelmer> vila: right - +1ed
[14:38] <vila> ECANTPARSE :)
[14:38] <jelmer> vila: yep
[14:38] <vila> ha
[14:38] <jelmer> vila: approved :)
[14:44] <vila> done, deploying on jubany (including a newer bzr.dev as you've fixed set_root_id(not None) which needs to be deployed too)
[14:44] <vila> bah, of course, chromium-browser is running... shudder
[14:44] <vila> s/running/imported/
[14:49] <vila> hmm, tiplog fall in the infamous 'access self.branch.control_transport on a smart branch' trap :-/
[14:50] <jelmer> vila: it seems tiplog has no choice but to fallback to VFS anyway though
[14:50] <jelmer> when it's pushing stuff, etc
[14:51] <vila> yeah, was thinking along the same lines, I never realized it was pushing a file to lp though which is... surprising,
[14:52] <vila> I thought lp was strict about which files were allowed...is *anything* allowed below .bzr ?
[14:52] <vila> scary
[14:52] <jelmer> vila: yes
[14:53] <jelmer> vila: but don't dare creating a file outside of .bzr
[14:53] <vila> I haven't looked closely, but the trap is really that even if it doesn't *need* the control_transport later, ensure_real has fired anyway
[14:53] <jelmer> vila: the scanner will without warning delete your branch
[14:53] <vila> ha good
=== vednis is now known as mar
=== mar is now known as mars
[15:02] <mgz> uploading windows installers now.
[15:06] <jelmer> vila: did you run the testsuite before landing?
[15:06] <jelmer> vila: https://launchpadlibrarian.net/86194438/buildlog_ubuntu-oneiric-i386.bzr-builddeb_2.7.9%2Bbzr649~oneiric1_FAILEDTOBUILD.txt.gz
[15:07] <vila> nope, I only tested on my case :-/
[15:08] <vila> fixing
[15:11] <vila> fixed
[15:12] <vila> jelmer: pushed, really sorry about that :-/
[15:15] <jelmer> vila: no worries, thanks for fixing the other bug
[15:15] <jelmer> which was a regression in *my* code :)
[15:17] <vila> what I don't quite get is why it didn't trigger earlier but I suppose there are more code paths
[15:17] <vila> than the one used on the importer
[15:18] <mgz> I say that, was wondering why it prompted for password, and after uploading everything now it says there was an auth problem
[15:20] <vila> mgz: enable js ;-p
[15:20] <vila> (just kidding)
[15:22] <mgz> I don't really see how curl is meant to be doing auth here, presumably via the single sign on somehow?
[15:22] <vila> curl ? Is that the recommended way ? Isn't there a script that will use lp API ?
[15:23] <mgz> the script uses curl, I'm guessing there's no lp api for uploading files
[15:23] <vila> note that I don't know what I'm talking about here...
[15:24] <mgz> lp:bzr-windows-installers ./upload_to_launchpad.py
[15:25] <vila> ok, I reverse my advice: Are you sure this script is used ? :0p
[15:25] <mgz> jam manages it!
[15:25] <mgz> so it must work somehow.
[15:26] <jam> mgz: --user USERNAME:password
[15:27] <mgz> okay, that worked, need to manually enter lp email address and pa... each time
[15:27] <jam> but yes, Launchpad lets you post your entire document before it tells you your password is wrong
[15:27] <mgz> or not, like that
[15:27] <jam> it is because uploading the file is a POST
[15:27] <jam> which doesn't validate the info until the post has finished streaming the body.
[15:27] <mgz> or three whole documents, in the last case, because the curl output wasn't flushed :)
[15:42] <mgz> hm, I didn't add '-1' in the filenames
[15:43] <mgz> do I really want 20 minutes more upload time to fix that...
[15:44] <jelmer> is it really that much?
[15:44] <vila> nope, you have an allowance of 3 bad uploads across 2 releases as the new maintainer :)
[15:56] <vila> ghaaaa Alarm clock
[15:56] <mgz> time to wake up vila!
[15:56] <vila> hehe, I wasn't sleeping, I was thinking !
[15:57] <vila> while debugging a test and the new test timeout triggered losing my context ;)
[15:57] <vila> I'm probably not the last to fall into this trap ;)
[16:01] <mgz> ehehe
[16:01] <mgz> yeah, need to cancel out on pdb break in I guess
=== zyga is now known as zyga-ill
[16:12] <vila> mgz: yup, my thought exactly (but invading pdb.break is hard, TestCase.debug on the other hand...)
=== shadeslayer_ is now known as shadeslayer
=== quicksil1er is now known as quicksilver
=== beuno is now known as beuno-lunch
[16:33] <mgz> not sure what to do about my last git related issue from earlier
[16:34] <mgz> I guess I could put up the patch I used ripping setuptools out of dulwich, on moral grounds
[16:35] <mgz> but looks like losing the `./setup.py test` thing might upset some people
[16:36] <mgz> and I didn't record the exact failure but just hacked around it as it was clearly setuptools sucking as usual
[16:37] <mgz> jelmer: if you have any thoughts^
[16:38] <mgz> basically dulwich didn't work with buildout till I made it believe setuptools didn't exist as it was installing to a path it objected to for whatever reason
[16:38] <mgz> there's probably a buildout level fix but I didn't try and find it.
[16:53] <vila> bingo, 13 failures less on jubany (if only new ones could stop appearing ... ;)
[16:55] <jelmer> mgz: hmm
[16:56] <jelmer> mgz: dulwich' setup should work without setuptools, can't you remove it on your local system?
[17:01] <mgz> the build bot needs it for other things, I can possibly kill it at the correct level next time
[17:10] <jelmer> \o/ 'bzr checkout' and 'bzr checkout --lightweight' are now VFS-free
=== beuno-lunch is now known as beuno
[17:39] <supton> what's the best practice for merging a feature branch to a mainline while preserving history of each changeset in the feature branch, without rebasing?  I rebased a mainline on a project last night, and now I feel a bit icky.
[17:40] <mgz> ...just merge it?
[17:42] <supton> mgz: right, tried merging, resolving conflicts, then committing, but I want to preserve the diffs per-changeset on the feature branch on my mainline.  If I push my merge to launchpad, and I view history, IIRC, I don't see this.
[17:42] <jelmer> supton: that history is still there, you can view it with e.g. "bzr qlog" or "bzr log -n0"
[17:42] <supton> so I uncommitted a merge and had the mixed luck of thinking, I'm the only one using the mainline, why not just rebase it from my dev/feature branch.
[17:43] <supton> jelmer: cool.
[17:43]  * supton needs to figure out what plugin qlog is in
[17:43] <mgz> it's part of qbzr.
[17:43] <supton> now, I need to figure out how to undo my rebased branch pushed to lp, so I can do this right
[17:43] <supton> mgz: thanks
[17:45] <mgz> but just for the history of the last merged change, try `bzr log -c-1 -n0 BRANCH`
[17:45] <supton> I wonder if I can rebase back to a common revision, then merge properly?
[17:45] <supton> I shouldn't have pushed this, but for lack of sleep, I did
[17:46] <mgz> `bzr uncommit lp:PROJECT` works, you just want to be quick enough that no one pulled yet :D
[17:46] <mgz> (otherwise, it's not the end of the world, and you can just leave the merge proper in next time)
[17:49] <mgz> sometimes with very messy branches you're better off flattening them, like `bzr merge ../FEATURE && bzr revert --forget-merges && bzr commit --author contrib@example.com -m"...description of change..."`
[17:50] <vila> mgz: sounds like a plugin...
[18:00] <supton> mgz: good idea, thanks.
[18:05] <mgz> I despair of ever getting this guy to set up a http smart server correctly.
[18:12] <tkamppeter> hi
[18:12] <jelmer> hi tkamppeter
[18:13] <tkamppeter> I have cleaned a file from UTF-8 characters to make it pure ASCII and then committed it to bzr+ssh://till-guest@bzr.debian.org/bzr/pkg-cups/cups/debian-trunk.
[18:13] <tkamppeter> Then the bzr client crashes with a traceback:
[18:14] <tkamppeter> bzr: ERROR: exceptions.UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 349: ordinal not in range(128)
[18:14] <tkamppeter> Traceback (most recent call last):
[18:14] <tkamppeter>   File "/usr/lib/python2.7/dist-packages/bzrlib/commands.py", line 946, in exception_to_return_code
[18:14] <tkamppeter>     return the_callable(*args, **kwargs)
[18:14] <tkamppeter>   File "/usr/lib/python2.7/dist-packages/bzrlib/commands.py", line 1150, in run_bzr
[18:14] <tkamppeter>     ret = run(*run_argv)
[18:14] <tkamppeter>   File "/usr/lib/python2.7/dist-packages/bzrlib/commands.py", line 699, in run_argv_aliases
[18:14] <tkamppeter>     return self.run(**all_cmd_args)
[18:14] <tkamppeter>   File "/usr/lib/python2.7/dist-packages/bzrlib/commands.py", line 721, in run
[18:14] <tkamppeter>     return self._operation.run_simple(*args, **kwargs)
[18:14] <tkamppeter>   File "/usr/lib/python2.7/dist-packages/bzrlib/cleanup.py", line 135, in run_simple
[18:14] <tkamppeter>     self.cleanups, self.func, *args, **kwargs)
[18:14] <tkamppeter>   File "/usr/lib/python2.7/dist-packages/bzrlib/cleanup.py", line 165, in _do_with_cleanups
[18:14] <tkamppeter>     result = func(*args, **kwargs)
[18:14] <tkamppeter>   File "/usr/lib/python2.7/dist-packages/bzrlib/builtins.py", line 3316, in run
[18:14] <tkamppeter>     lossy=lossy)
[18:14] <tkamppeter>   File "/usr/lib/python2.7/dist-packages/bzrlib/decorators.py", line 217, in write_locked
[18:14] <tkamppeter>     result = unbound(self, *args, **kwargs)
[18:14] <tkamppeter>   File "/usr/lib/python2.7/dist-packages/bzrlib/workingtree_4.py", line 209, in commit
[18:14] <tkamppeter>     result = WorkingTree.commit(self, message, revprops, *args, **kwargs)
[18:14] <tkamppeter>   File "/usr/lib/python2.7/dist-packages/bzrlib/decorators.py", line 217, in write_locked
[18:14] <tkamppeter>     result = unbound(self, *args, **kwargs)
[18:14] <tkamppeter>   File "/usr/lib/python2.7/dist-packages/bzrlib/mutabletree.py", line 210, in commit
[18:14] <tkamppeter>     *args, **kwargs)
[18:14] <tkamppeter>   File "/usr/lib/python2.7/dist-packages/bzrlib/commit.py", line 289, in commit
[18:14] <tkamppeter>     lossy=lossy)
[18:15] <tkamppeter>   File "/usr/lib/python2.7/dist-packages/bzrlib/cleanup.py", line 131, in run
[18:15] <tkamppeter>     self.cleanups, self.func, self, *args, **kwargs)
[18:15] <tkamppeter>   File "/usr/lib/python2.7/dist-packages/bzrlib/cleanup.py", line 165, in _do_with_cleanups
[18:15] <tkamppeter>     result = func(*args, **kwargs)
[18:15] <tkamppeter>   File "/usr/lib/python2.7/dist-packages/bzrlib/commit.py", line 440, in _commit
[18:15] <tkamppeter>     self.rev_id = self.builder.commit(self.message
[18:15] <tkamppeter> How can I commit this file? Problem is probably that the diff between the old file and the new file contains non-ASCII characters.
[18:16] <mgz> amusingly despite all that, I don't see the bit of the traceback I need
[18:16] <mgz> !pastebin
[18:16] <ubot5> For posting multi-line texts into the channel, please use http://paste.ubuntu.com | To post !screenshots use http://imagebin.org/?page=add | !pastebinit to paste directly from command line | Make sure you give us the URL for your paste - see also the channel topic.
[18:16] <mgz> for future reference tkamppeter
[18:18] <tkamppeter> mgz, http://paste.ubuntu.com/753917/, with calling command.
[18:19] <tkamppeter> Bazaar (bzr) 2.4.2 on Oneiric with Python 2.7.2.
[18:21] <mgz> how did you supply the commit message? are you using bzr-builddeb or did you manually enter it with an editor?
[18:22] <mgz> retrying with `bzr commit -m "A message that's really just ascii"` will probably work,
[18:22] <tkamppeter> mgz, seems that bzr-builddeb is in use and already pre-configured, as "bzr commit" does not open an editor if I commit in that repository.
[18:23] <mgz> okay, what bzr-builddeb version?
[18:23] <tkamppeter> "bzr diff" output is on http://paste.ubuntu.com/753921/.
[18:23] <tkamppeter> I will try the -m metyhod now ...
[18:23] <mgz> nope, don't.
[18:23] <mgz> you probably just need to update bzr-builddeb
[18:24] <mgz> the file is a red herring, it's 'Martin-Éric' causing the problem (which is fixed in the latest bzr-builddeb version)
[18:26] <mgz> bug 853664
[18:26] <ubot5> Launchpad bug 853664 in bzr-builddeb "tries to decode debian/changelog as ascii, and fails when it's not" [Medium,Fix released] https://launchpad.net/bugs/853664
[18:26] <tkamppeter> mgz, thank you. Used the "-m" to not need to wait for the update.
[18:28] <jelmer> hmm, I don't think that's actually released yet
[18:29] <mgz> ...you marked it as such though!
[18:31] <jelmer> ah, it's in 2.7.9
[18:36] <mgz> jelmer: that's where the version markers in launchpad are useful :)
[18:37] <jelmer> mgz: unfortunately it's not possible to assign a closed milestone to a bug
[18:37] <jelmer> mgz: which is often useful after the release has happened
[18:46] <mgz> there's a (slow, manual) trick to that
[18:46] <mgz> re-activate the milestone, set the bug to it, re-de-activate the milestone
[19:08] <poolie> hi all
[19:22] <mgz> hey poolie
[19:23] <poolie> hi there
[19:28] <GRiD> hey guys.
[19:30] <poolie> hi grid
[19:31] <GRiD> jelmer, bug 806904 says you committed a fix. is this likely be working on launchpad soon then? if there's something left you do and you can point me in the right direction, i can take a look.
[19:31] <ubot5> Launchpad bug 806904 in Launchpad itself "Mercurial import fails from Google code" [High,Triaged] https://launchpad.net/bugs/806904
[19:32] <GRiD> i realize now that i'm getting a different error than the one in this bug. but it is a failing google code import.
[19:33] <GRiD> http://launchpadlibrarian.net/85941722/weyrick-crack-lang-trunk.log
[19:39] <GRiD> "something left to do", rather. i'm not sure how much of this is bzr vs. launchpad code. i suppose a first step is trying a local import with the latest bzr-hg.
[19:40] <poolie> that's generally useful
[19:41] <poolie> actually that would be highly useful to see if you can reproduce it locally
[19:41] <poolie> then we can update it in lp
[19:41] <GRiD> yep ok i'll give it a shot in bit here.
[19:57] <jelmer> GRiD: the hg import is still very much beta at this point, so I wouldn't be surprised if there are multiple issues affecting one import
[19:58] <AuroraBorealis> question: on mac...does bzr know about resource forks?
[19:59] <GRiD> jelmer, ok. well i'll see what happens when i try locally. does it work well enough to rightly be offered as on option on launchpad at this point, then?
[19:59] <poolie> nup
[20:00] <jelmer> GRiD: bug #889530
[20:00] <ubot5> Launchpad bug 889530 in Launchpad itself "mercurial imports should be marked 'beta'" [High,In progress] https://launchpad.net/bugs/889530
[20:00] <mgz> AuroraBorealis: no
[20:00] <GRiD> jelmer, ah ok :)
=== zyga-ill is now known as zyga
=== zyga-ill is now known as zyga