[00:41] <KombuchaKip> poolie: Hey poolie. Question for you and everyone.
[00:42] <poolie> hey
[00:42] <KombuchaKip> As bzr bundles go, does anyone suggest a file extension, such as .bundle? Or is .patch or .diff fine, even though they are more than vanilla unified diffs?
[00:42] <poolie> i'd say either .bundle or .diff
[00:42] <KombuchaKip> poolie: Ok.
[06:53] <vila> hi all
[06:53] <mgrandi> hi
[07:19] <vila> blast, I almost fall for the freenode/acta announcement, time for another coffee ;)
[08:11] <mgz> morning all
[08:20] <LarstiQ> hi mgz
[08:20] <mgz> hey LarstiQ
[08:49] <poolie> o/ mgz,larstiq
[08:49] <mgz> hey poolie
[09:09] <ams_cs> jelmer: ping
[09:14] <jelmer> ams_cs: pong
[09:14] <ams_cs> jelmer: did you make any progress on the lp:gcc/4.7 merge problem?
[09:15] <ams_cs> it is now getting urgent
[09:15] <LarstiQ> heya poolie :)
[09:16] <jelmer> ams_cs: no, not much unfortunately
[09:17] <jelmer> also hi LarstiQ, poolie, mgz
[09:21] <ams_cs> jelmer: hmm, if I were to take a diff from the upstream branch, and apply it to the local branch as a manual merge, would that be a problem when the problem is solved?
[09:22]  * ams_cs is looking for work-arounds
[09:25] <lifeless> ams_cs: as long as it doesn't add files, that should be fine
[09:26] <ams_cs> lifeless: hmm, it almost certainly will add files
[09:26] <lifeless> its more complex if it does, because of file ids
[09:27] <ams_cs> lifeless: if I revert the manual merge before doing the automatic merge, that would be ok as long as none of the new files had local modifications?
[09:27] <jelmer> you should be able to create consistent file ids by using 'bzr add --file-ids-from'
[09:38] <ams_cs> so, "bzr diff -r m..n lp:gcc/4.7 | patch -p1 && bzr add --file-ids-from" should DTRT?
[09:39] <mgz> you need to supply a tree to take the file ids from, but yes, probably.
[09:40] <mgz> *branch
[09:40] <mgz> ...or is it tree
[09:55] <ams_cs> mgz: if I do the wrong one (tree v. branch), will it say so, or will it just silently fail?
[09:58] <jelmer> ams_cs: it will just say "adding FILE" rather than "adding FILE w/ fileids from other tree" (or something along those lines)
[11:34] <jelmer> vila: ping?
[11:35] <vila> jelmer: pong
[11:37] <mgz> ...this query stuff is silly, most of what vila and I have been discussing this morning should just have been in a public channel
[12:12] <jml> mgz: this is what you meant by defining __unicode__ to return something consistent? http://paste.ubuntu.com/911396/
[12:12] <jml> mgz: context: https://code.launchpad.net/~frankban/testrepository/encoding-error/+merge/98207
[12:12] <mgz> ah, yes, was going to respond to that today
[12:13] <mgz> jml: exactly
[12:13] <jml> mgz: thanks.
[12:13] <jml> mgz: I really appreciate your help with this.
[12:13] <mgz> and the reasoning is that then we don't need to worry about if the formatting of the exception *already* did the replacement of bytes, thereby invalidating the test
[12:15] <mgz> the same test, with a stream that has an encoding attribute, would then match u"...MyError: \u201c"
[12:15] <mgz> .encode(stream.encoding)
[12:16] <jml> right.
[14:11] <mgz> bzr-grep is one of the plugins that needed a relative import fix, right?
[14:12] <jelmer> yes
[15:29] <mgz> is this build (test) failure on arm something spurious we have a bug for?

[15:30] <jelmer> mgz: isn't that just the normal spurious failure?
[15:31] <mgz> it's not the one I normally see, but it may well be the normal one for the bots
[15:32] <jelmer> I've seen this one regularly
[15:32] <mgz> does seem to be bug 874153 indeed
[19:43] <pikkachu> hi, is it possible to deactivate bazaar log or change its path?
[19:44] <jelmer> pikkachu: you can set the BZR_LOG environment variable
[19:55] <pikkachu> jelmer: that's the only option? ok
[19:55] <pikkachu> I'd like to ideally disable it...
[20:11] <pikkachu> I should set it to 'NUL' http://doc.bazaar.canonical.com/development/en/release-notes/bzr-1.3rc1.html
[20:11] <pikkachu> thanks!
[21:43] <mgrandi> does anyone know where the code in bzr-fastimport where the stuff for 'fast-export-from-X' is? i cant seem to find it
[21:52] <jelmer> mgrandi: it's been removed
[21:52] <mgrandi> really?
[21:53] <mgrandi> so then why do i still have access to those commands
[21:53] <mgrandi> o.o
[21:53] <jelmer> you have an old version of bzr-fastimport installed I think
[21:53] <jelmer> we removed it because it didn't really seem useful to ship outdated (and thus buggy) exporters for other version control systems
[21:54] <jelmer> while there are better ways to get the current exporters
[21:54] <mgrandi> well they wern't really buggy since they used other sources, but yeah the command line args
[21:54] <mgrandi> were wrong =P
[21:54] <jelmer> mgrandi: they used exporters shipped with bzr-fastimport itself (except for git-fastexport)
[21:54] <mgrandi> well fast-export-from-cvs required cvs2svn/bzr
[21:54] <mgrandi> and seemed to just call that
[21:55] <jelmer> the other thing is that the 'bzr fast-export-from-X' code was a really trivial wrapper around the actual fastexport tool, but didn't provide all functionality
[21:56] <mgrandi> ah ok.
[22:04] <wgz> what time should I wake up tomorrow morning?
[22:07] <lifeless> wgz: wat time do you want to wake up tomorrow?
[22:07] <mgrandi> 8am?
[22:09] <fullermd> Before noon?!  What kind of sadist are you?
[22:10] <mgrandi> haha
[22:10] <mgrandi> one with school at 9 am :>
[22:10] <jelmer> wgz: how long do you usually eat breakfast ? :)
[22:12] <jelmer> though I am kind of curious about timezones and stuff too
[22:13] <wgz> hugs all round :)
[22:19] <wgz> okay, I'll go for starting at 08:00+01 and eat breakfast very slowly if no one else is around yet
[22:20] <jelmer> wgz: so that's the same time you guys met up as last week?
[22:20] <jelmer> but one hour before our scheduled call?
[22:23] <poolie> hi all
[22:23] <poolie> i currently have it for, um
[22:23] <poolie> 7pm
[22:23] <poolie> oh, i have a conflict
[22:24] <poolie> 11h from now
[22:24] <poolie> but i might push it back a bit
[22:25] <poolie> wgz, 11:30 uk, 12:30 cet
[22:26] <jelmer> hi poolie
[22:26] <jelmer> thanks for confirming
[22:26] <poolie> no what
[22:27] <poolie> :/
[22:27] <poolie> this app is confused
[22:27] <poolie> but those times are correct
[22:27] <poolie> late enough you oughta be awake anyhow
[22:28] <wgz> okay, I'll set a less punishing alarm
[22:28] <poolie> wgz, i think i'm now +9h from you
[22:28] <jelmer> poolie: yeah, that's 3.5 hours later than two weeks ago I think :)
[23:18] <KombuchaKip> Is there any way to have bzr ensure that a file has an executable bit set?
[23:19] <poolie> KombuchaKip, even if someone else tries to turn it off?
[23:19] <poolie> not built in
[23:19] <poolie> iguess you could write a hook that forces it
[23:19] <poolie> i would probably do it from the eg makefile
[23:19] <KombuchaKip> poolie: The reason I'm asking is there is a script my makefile calls, both under bzr, and the script needs to have its executable bit set.
[23:20] <poolie> couldn't the makefile chmod it?
[23:20] <poolie> or, run it directly through '$(SH) script'
[23:22] <mgrandi> doesn't bzr make sure that the executable bit is set? (as in that it versions that attribute)
[23:22] <poolie> it does
[23:22] <poolie> i assumed he was talking about cases where someone intentionally or accidentally unset it
[23:23] <KombuchaKip> poolie: No, I just mean as in ensuring that when they checkout their working copy, the files are executable that had the attribute set when they were first commit.
[23:30] <KombuchaKip> poolie: Do you happen to know off hand how users check to see what bzr knows of a file's attributes in a branch?
[23:30] <poolie> i think bzr ls will show you
[23:31] <poolie> "when they checkout their working copy, the files are executable that had the attribute set when they were first commit."
[23:31] <poolie> this should happen automatically
[23:34] <KombuchaKip> poolie: So changing a file's attributes, via whatever the platform's interface may be, without changing the file's contents, should flag the file as modified?
[23:34] <poolie> yes
[23:34]  * KombuchaKip experiments
[23:35]  * KombuchaKip confirms poolie's claim. Files are listed under modified with an asterisk after their name in bzr status.
[23:35] <poolie> nice when that happens
[23:35] <KombuchaKip> poolie: ;)
[23:47] <dakira> hi.. maybe someone can help me working with launchpad. I just checked out lp:compiz and used add-patch to add a patch. I pushed it to a branch in my userspace: https://code.launchpad.net/~mniess/ubuntu/precise/compiz/fix-screenshot
[23:47] <dakira> Now when I propose this for merging a lot more than my simple patch is chown in the diff. Why is that? Where did I go wrong?
[23:48] <mgrandi> a link to the patch you applied and the merge proposal (where it shows the diff) would be good
[23:49] <dakira> mgrandi: I deleted the merge-proposal as I didn't want anyone bothering with such a huge diff. the patch is here: http://pastebin.com/bNtzZKky
[23:50] <mgrandi> do you have the diff that it was creating?
[23:50] <dakira> http://bazaar.launchpad.net/~mniess/ubuntu/precise/compiz/fix-screenshot/revision/766#debian/patches/fix-screenshots.patch
[23:51] <dakira> mgrandi: no, sorry.. should I propose it for merging again?
[23:51] <mgrandi> you can probably generate it without doing that
[23:51] <mgrandi> by trying to merge your branch into lp:compiz
[23:52] <mgrandi> i think you do this by cding to your branch of lp:compiz and then doing bzr merge <path to your branch>
[23:53] <dakira> mgrandi: I'm on it
[23:54] <mgrandi> it might be that addpatch is doing something weird
[23:54] <dakira> mgrandi: looks just as expected: http://pastebin.com/2N2UxHsG
[23:55] <mgrandi> so that diff you just pasted is what you expect, but not what launchpad gave you?
[23:56] <dakira> mgrandi: yep. but fortunately launchpad just send me a mail with the review-diff which I'll upload in a second ;)
[23:57] <dakira> http://dl.dropbox.com/u/79339/review-diff.txt
[23:59] <mgrandi> .bzr-builddeb/default.conf
[23:59] <mgrandi> some things you accidentally added
[23:59] <mgrandi> i think