[00:20] <poolie> hi all
[03:41] <poolie> cinerama, the update misbehaviour is bug 557886
[03:41] <cinerama> I see
[03:42] <cinerama> no me gusta
[03:43] <poolie> i wonder if an easy fix is possible
[06:18] <vila> hi all !
[06:28] <poolie> hi vila
[06:29] <poolie> that reminds me, dst
[06:29] <poolie> when does summer time start for you?
[06:29] <vila> err, good question :)
[06:29] <vila> end of October according to my family's time keeper ;)
[06:31] <vila> darn, I thought I could trick jenkins into revealing the aborted builds by reverting its previous version but that doesn't work, the jobs are still there on disk but not in web GUI :-/
[06:32] <vila> so, you'll have to trust me or look at holes in the numbering, I'll try older versions later
[06:32] <vila> anyway, natty has been seen hanging yesterday evening and maverick was this morning
[06:33] <poolie> has it now
[06:33] <poolie> thanks for telling me
[06:33] <vila> that's maverick in the chroot, surprisingly the one I left in the vm hasn't so far
[06:34] <vila> but well, that's the schrodinger nature of races ;)
[06:36] <poolie> so do you have a reliable view of which revisions caused this?
[06:36] <poolie> or at least a window on them?
[06:37] <vila> http://babune.ladeuil.net:24842/view/%20High/job/selftest-osx-10.6/305/ for example
[06:38] <poolie> cinerama, https://code.launchpad.net/~mbp/bzr/557886-update-file/+merge/77286
[06:38] <poolie> fixes one of them
[06:41] <vila> is it just me or is lp slower at displaying diffs ? Or is it because *we* are faster at mentioning the mps ?
[06:41] <vila> I thought the diff was available in less than 5 minutes but that's already not the case here
[06:43] <vila> ha, here we go
[06:47] <poolie> when their rabbit stuff is loaded it should pop up faster
[06:47] <poolie> well
[06:47] <poolie> you will not need to reload
[06:47] <poolie> the overall latency may be no better
[06:49] <vila> reviewed
[06:50] <vila> subjectively I prefer that my browser does the boring refresh job and just tell me when it's ready instead of forcing me to poll
[06:50] <poolie> yup
[06:50] <vila> it will feel faster because I'll spend *less* time caring about that
[06:50] <poolie> https://dev.launchpad.net/LEP/NotificationService
[06:52] <poolie> coincidentally i had that open
[06:52] <vila> hehe
[07:17] <vila> puzzling, reverting to a version from 2011-08-16 for jenkins still don't revealed the aborted jobs, stopping the experiment there
[07:26] <poolie> hm
[07:26] <poolie> vila, i'm out for a while, happy hacking
[07:27] <vila> poolie: enjoy !
[07:51] <jelmer> moin
[08:03] <mgz> morning all.
[08:07] <jelmer> hey mgz
[08:18] <vila> hey jelmer, mgz !
[08:19] <mgz> hm, we still have the 'giveback' confusion in the doc? I thought that had been changed...
[08:19]  * mgz edits
[08:21] <AuroraBorealis> is there anything that i should do to help find out whats causing this bug? https://bugs.launchpad.net/bzr/+bug/855155
[08:23] <jam> jelmer: morning. You replied to bzr-announce about the pipeline release. Do you want me to bounce the message, or let it through?
[08:24] <jelmer> jam: Whoops
[08:24] <jelmer> jam: please bounce it
[08:26] <jam> I expected as much, but I figured I'd check first
[08:27] <AuroraBorealis> its been sitting at new for a while
[08:29] <jelmer> AuroraBorealis: you'd need somebody with inventory delta experience for that
[08:29] <AuroraBorealis> hmm
[08:29] <AuroraBorealis> that i dont have
[08:30] <jelmer> me neither..
[08:31] <AuroraBorealis> k
[08:31] <AuroraBorealis> i'll keep poking around
[08:31] <AuroraBorealis> now, bed
[08:47] <mgz> wow, launchpad marks up bundles emailed to mps, I've not seen that before
[08:47] <mgz> preety.
[09:11] <jam> AuroraBorealis: well, the change seems to indicate that 252test.pl is being added but the directory prog1/testcases doesn't exist.
[09:12] <jam> You might try "bzr repair-workingtree" in case it is a local issue. Though it would be nice to save a snapshot of .bzr/checkout/dirstate
[09:12] <jam> in case we can figure out what the difference is.
[09:12] <mgz> might be good to put that in the bug jam as he's zzz
[09:15] <jam> mgz: thanks for the heads up
[09:15] <jam> done
[09:15] <jam> mgz: so how are your first couple of days going?
[09:18] <mgz> pretty well, the admin stuff hasn't killed me and I've had time to work on code :)
[09:21] <mgz> jam: I think I need to run a few pyrexy things by you, shall I just put up a mp later or do you want to be bothered seperately?
[09:21] <jam> mgz: I'm happy to give early feedback if you want it.
[09:22] <jam> I know sometimes it can be hard to get traction on something.
[09:22] <jam> We generally call it "a teddy bear" to talk to :)
[09:22] <mgz> :D
[09:25] <jam> mgz: You can just mention a branch, or you can put up an MP and comment that it may not be ready, and then poke me on IRC, or whatever works for you
[09:26] <mgz> cool, I'll write a few things down
[09:56] <jml> vila: hi
[09:56] <jml> vila: would you please merge my lp:udd branch?
[09:59] <vila> jml: sure
[09:59] <jml> vila: thanks.
[10:01] <vila> jml: sorry for the delay, I missed your reply :-/
[10:02] <jml> vila: np.
[10:03] <vila> jml: done, will be deployed later but I don't expect fallouts or will fix them
[10:03] <jml> vila: what's the deployment schedule like?
[10:03] <vila> sche.. what ? :-}
[10:07] <jelmer> heh
[10:08] <jml> vila: ah, ok.
[10:19] <vila> mgz: thanks for the review on shelve-line-based, I replied, should we talk here to speed things up ?
[10:33] <mgz> vila: perhaps, but I don't see much harm in just landing that
[10:34] <mgz> especially if we can get benoit's change landed later which is a more complete solution
[10:34] <vila> ha, important point, yeah, I could delay the tests waiting for his branch
[10:34] <vila> that still leave the config option name, any suggestion ?
[10:35] <mgz> I wouldn't worry about config.
[10:35] <vila> I can't leave INSIDE_EMACS there, it's just wrong ;)
[10:35] <mgz> just doing char-based if possible and line-based if not is enough
[10:36] <vila> nope, would break on windows
[10:36] <mgz> define a little function called _char_input or something with that logic
[10:36] <mgz> _can_do_char_input
[10:37] <mgz> then that at getch can be removed at the same time when the ui module takes over
[10:37] <vila> still needs help from outside to tie the break about isatty()
[10:37]  * mgz looks again
[10:39] <vila> getchar() should not be attempted is isatty() is false, but that doesn't tell me which char/line should be used + I want line-based to work *even* (and especially if) isatty() is false (i.e. isatty() is relevant only if we want to try char-based
[10:40] <mgz> I don't see why that can't be one logical statement
[10:40] <mgz> if isatty() is false, or if magic emacs variable is set, or we're in tests, _can_do_char_input is false
[10:41] <vila> right, so I want some env var or config option to cover both emacs and the test use cases
[10:43] <vila> the emacs magic var doesn't work as there are ways (unusual but existing) to get char-based input under emacs
[10:43] <mgz> use a config option if that's the easiest way for you, I just don't want it to be the kind of thing people need to be setting manually
[10:45] <mgz> at least till it's an option that works for all bzr input rather than just the shelf command
[10:45] <vila> err, but there is no way to switch to line based without setting it manually. That's the current bug, you can't use shelve when line-based is required and this can't be decided automatically >-/
[10:46] <mgz> I thought that's what checking your magic emacs var did?
[10:46] <vila> hmm, unless benoit's branch address that but I don't remember seeing a way to do that in his proposal
[10:47] <vila> yes, it worked my limited env where I wanted to check the line-based stuff was working but... oh, I'm trying too hard ?
[10:48] <vila> you mean *you* are ok with landing with INSIDE_EMACS ???
[10:49] <mgz> yes, on the basis that a proper fix would be moving the logic to bzrlib.ui and that can happen later.
[10:49] <spiv> vila: maybe sys.platform should be set to "emacs" :P
[10:49] <vila> spiv: :)
[10:49] <vila> mgz: ooookay ! Sorry, I'm dense, not enough sleep
[10:50] <vila> mgz: can you say so and vote in the mp ?
[10:50] <mgz> will do.
[10:50] <vila> very much appreciated
[10:51] <mgz> the isatty stuff if shelf_ui is already a hack so adding a little more isn't making life worse
[10:52]  * vila nods
[10:59] <vila> lunh time
[10:59] <vila> c
[10:59] <mgz> have a nice clunh
[12:20] <AfC> Hm. I just tried
[12:20] <AfC> $ bzr branch lp:ubuntu/maverick/linux
[12:20] <AfC> and it didn't work.
[12:20] <AfC> Am I missing something obvious?
[12:24] <AfC> I mean, it says "linux" is the source package name...
[12:28] <jelmer> AfC: odd, it says here there are no branches for the linux package
[12:28] <jelmer> https://code.launchpad.net/ubuntu/+source/linux
[12:35] <jelmer> http://package-import.ubuntu.com/status/linux.html#2011-04-22 01:24:13.263528
[12:45] <AfC> jelmer: ok, thanks. Is there anything I can do about that?
[12:47] <AfC> (right now I have `bzr branch lp:linux` running, not sure if that's what I actually want; I would have preferred a packaging branch if it existed)
[14:05] <AfC> jelmer: that branch just completed, took real 101m36.019s
[14:05] <jelmer> AfC, sorry, I think I missed that. which branch just completed?
[14:10] <AfC> jelmer: lp:linux
[14:10] <AfC> (just a data point)
[14:10] <AfC> kernel.org is still down, so I can't immediately compare it to a git clone of Linux
[14:12] <ccxCZ> it's now hosted at github
[14:39] <briandealwis> Is there a way to override a config var from the command-line?  I'd like to use 'bzr pull -v' to show the log entries since the pull point, but use the line formatter.  I can set 'log_format=line' in my bazaar.conf, but that affects everything...
[14:41] <vila> briandealwis: bug #491196 pending review, but the log_format config option is not migrated yet, on the other hand --log-format-line is recognized by pull IIRC
[14:41] <vila> grr --log-format=line
[14:41] <vila> briandealwis: you're welcome to metoo the bug though ;)
[14:41] <briandealwis> thx vila: it doesn't show in the help, so I assumed I couldn't do that
[14:43] <vila> briandealwis: that's worth another bug ?
[14:44] <briandealwis> vila: —log-format=line doesn't work (with 2.5.0b1 at least)
[14:44] <vila> wow, that's... bad, but you should be able to use '--line' even
[14:44] <briandealwis> nor does --line
[14:44] <vila> ha crap, I was looking at missing >-/
[14:45] <vila> ctrl+alt+del
[14:45] <briandealwis> I'll submit a bug
[14:45] <vila> briandealwis: see bug mentioned above, this is a first step, it will also require migrating the --log-format option to adress your need
[14:46] <vila> briandealwis: filing one with your specific use case sounds appropriate (-Olog-format=line for pull)
[14:46] <briandealwis> ok
[15:48] <mgz> can someone remind me what we do with news now if a change is landing on multiple release branches?
[16:08] <vila> if you know the target ahead of times, file news in the oldest one and that's it
[16:08] <vila> it's a bit less clear when you start landing on trunk but the goal is to avoid duplication
[16:09] <vila> mgz: is that enough or do you want more details ?
[16:10] <vila> oh, also at one point we stopped using NEWS and switch to doc/en/releases-notes/bzr-2.x.txt so one of the merge is confusing
[16:10] <vila> because you suddenly get a lot of stuff merged in the wrong place, in that case remember to move each part in the specific release notes file
[16:11] <mgz> cool, that should be okay then.
[16:11] <vila> mgz: a bit confusing the first time but rest assured that it's still confusing after 20 or so occurrences ;)
[16:56] <mgz> hm, 2.1 usec down from 2.7, not a bad side effect
[16:56] <LeoNerd> What are you measuring that's that small?
[16:59] <mgz> teeny function for encoding stat results as base64
[17:00] <mgz> won't make anything run faster, but some overflow issues needed fixing
[18:41] <mpt> Hi, on my first commit after upgrading to Ubuntu 11.10 beta I get "bzr: ERROR: Failed to GPG sign data with command "[u'gnome-gpg', '--clearsign']"" ... It looks like there's no gnome-gpg in 11.10. What should I be using instead?
[19:07] <mpt> So it looks like I need to update gpg_signing_command ... I just need to figure out where, and to what
[19:08] <mpt> ... ~/.bazaar/bazaar.conf is the answer to the first question
[19:08] <mpt> ok, deleting the line altogether defaulted it back to asking for my passphrase at the terminal
[19:09] <mpt> that's good enough for now I guess
[19:13] <mpt> btw the "Configuration Settings" link is broken in <http://doc.bazaar.canonical.com/bzr.dev/en/user-guide/configuring_bazaar.html>
[19:15] <jblue> looking for suggestions on how to manage merging in many commits.. I'd like to inspect each commit, along with their commit comments, but not sure how to do this on the command line.  'bzr status -v' shows the pending merge tips, but I'm not sure how to do a diff for each tip
[19:24] <briandealwis> jblue: see log -p
[19:27] <jblue> 'bzr help log' doesn't say much about diffing pending merges
[21:00] <bpierre> Hi
[23:51] <poolie> hi jelmer, all