[02:43] <maxb> erm... help?  'ssh foo@bar' works. 'bzr branch bzr+ssh://foo@bar/baz' says 'Permission denied (publickey).'  !?!?!?
[02:48] <AfC> maxb: 'baz' is an absolute path, right?
[02:48] <AfC> [I don't think that's your problem, but]
[02:49] <maxb> actually it's nonexistent. there are no bzr branches on that server at present. just trying to get connectivity working
[02:50] <AfC> well, er
[02:50] <AfC> put a branch there, try again
[02:50] <AfC> (even just bzr init, eh?)
[02:50] <maxb> indeed
[02:50] <maxb> same error though
[02:50] <AfC> good luck
[02:50] <AfC> brb
[03:00] <maxb> ahh
[03:01] <maxb> it works a lot better if you don't have script that wraps ssh that breaks on the way bzr invokes ssh but not on the way you invoke ssh yourself
[08:21] <Hancock> So I just did a plain bzr revert
[08:21] <Hancock> on accident
[08:21] <Hancock> can I undo that revert
[08:21] <Hancock> somehow?
[08:21] <fullermd> Not automatically, but it leaves backups of any files you changed.
[08:22] <Hancock> so how I could I get access to that
[08:22] <Hancock> so I can un revert 1 files.
[08:23] <fullermd> They're right alongside the files, with names like file.~1~
[08:25] <Hancock> oh,  that is what those mean.....
[08:28] <Hancock> thanks, found it :)
[08:29] <vila> Hancock: that's mentioned in 'bzr help revert', is there something that can make it clearer for you ?
[08:29] <fullermd> Just be careful.  Sooner or later you'll get cocky, and be all, "I know what I'm doing", and start doing revert --no-backup.
[08:29] <fullermd> The third time you do so (I've carefully modelled the universe to determine that number), you'll suddenly need the changes you just blew away.
[08:32] <vila> at that point you start using "bzr shelve --all -m'y precious'"
[08:33] <fullermd> vila: G'morning, BTW.
[08:33] <vila> oh, hi fullermd ! Hi all !
[08:34] <fullermd> vila: Incidentally, re: bug 693533
[08:34] <vila> yeah, I read this in the log
[08:34] <fullermd> I'm of half a mind that should be Critical'd.
[08:35] <fullermd> Counterargument: it's not a regression...
[08:35] <vila> I think it's not that it drops them but respectfully ignore them :)
[08:35] <fullermd> ...  so, it takes them out for dinner and a movie, but never calls again?   :p
[08:35] <vila> kind of :)
[08:38] <vila> critical may be too much indeed, very annoying though, on the other hand nobody ever reported it...
[08:38] <fullermd> Anyway, I half feel like it's the sort of thing serious enough we should block the release on it.  OTOH, it's been there for the last couple major releases and nobody noticed, and we're sorta winding toward the end of the release cycle.
[08:38] <vila> crossing on the wire ;)
[08:39] <fullermd> Great minds think alike  :)
[08:39] <fullermd> Also, the two of us sometimes do too.
[08:39] <vila> lol
[08:39] <fullermd> [Meta-]data loss bugs make me antsy.
[08:41] <vila> that's the point I'd say, tags are... only tied to revisions in a specific way, they can be missed easily (as revealed here)
[08:41] <Peng> Is 'join' being promoted nowadays? Last I was here, nobody really used it.
[08:41] <Peng> If nobody still uses it, IMO High and non-blocking is good.
[08:41] <vila> no, it just happens than some people started using it recently
[08:41] <fullermd> I've used it occasionally.
[08:42] <Peng> Maybe block the next release, but if you want to push the current one out the door soon...
[08:42] <fullermd> join for by-_reference_ trees is all murky and works-just-enough-to-screw-you-up.
[08:42] <fullermd> join as merge-into-subdir works great.  I mean, except for losing your tags anyway.
[08:42] <vila> I'd like spiv opinion first, it may  be pretty shallow now that he fixed a deeper related issue
[08:43] <fullermd> Yeah.  He seemed so optimistic about that branch fixing it.  I almost felt guilty when it didn't.
[08:43] <vila> but the root cause may be that we don't know how to properly merge tags
[08:44] <vila> I think he fixed the 'tagged revisions do not propagate cleanly' and this bug is 'join should also copy the tags'
[08:48] <fullermd> Well, merge does well enough without being able to 'properly' merge tags.
[08:49] <fullermd> And join is roughly just the same as 'merge -r0..-1 ; mv root'
[08:55] <vila> could be, I'm not really familiar with the tag related code
[08:55] <vila> ..and looking at join code, I wonder if you're allowed to join an uncommitted tree... which would be... weird
[11:09] <lifeless> vila: hi
[11:09] <vila> lifeless: hey !
[11:09] <lifeless> have you tried testr --parallel yet?
[11:10] <lifeless> I'd be interested in how it compares to bzr's parallel - it uses test timings to inform the partitioner
[11:10] <lifeless> mgz: so you're updating that branch right?
[11:10] <lifeless> mgz: or you have done, and I should merge?
[11:10] <vila> no, wanted to but had to revert to testtools 0.9.7, I may misremember but I thought it was related
[11:12] <vila> lifeless: you mean timings from previous run ?
[11:13] <lifeless> yes
[11:13] <lifeless> it builds a little db of testid : duration
[11:13] <vila> neat :)
[11:13] <lifeless> and when it partitions the tests it makes the partitions have ~ the same total duration
[11:14] <lifeless> I'd love to know how it works for you
[11:14] <vila> I'll put that in my TODO and let you know once I upgrade testtools
[11:14] <lifeless> jml: re https://code.launchpad.net/~jml/pyflakes/duplicate-class-defs/+merge/44601
[11:14] <jml> lifeless: yes?
[11:14] <lifeless> jml: I'm curious how my example differs from what your branch catches
[11:15] <lifeless> the description seemed an exact match, to me.
[11:15] <jml> lifeless: have you looked at the tests in the branch?
[11:15] <lifeless> no
[11:15] <vila> WAG it catches parameters overriden without being used
[11:15] <jml> oh. hah. I made a typo.
[11:15] <jml> thinko.
[11:19] <jml> lifeless: there you go.
[11:19] <lifeless> hah!
[11:20] <lifeless> I haven't done testtools 0.9.9
[11:20] <lifeless> I might do it as a xmas present to the world
[11:27] <vila> jelmer_: ping, regarding bug #693880, do you have know which test is failing without your patch ? Or is there no such test ? :-/
[11:27] <jelmer_> vila: a bunch of http related ones
[11:28] <jelmer_> vila: I can provide you with a test log
[11:28] <vila> ha, good, but... why aren't they failing during the daily builds then ?
[11:29] <jelmer_> that's a good question..
[11:30] <lifeless> python 2.7?
[11:30] <jelmer_> lifeless: yeah
[11:30] <lifeless> that will be why
[11:31] <jelmer_> http://samba.org/~jelmer/natty-http.subunit
[11:31] <jelmer_> lifeless: the natty chroots already have 2.7 as far as I can tell
[11:31] <lifeless> jelmer_: dunno then
[11:32] <jelmer_> it's a slightly different version though - I have 2.7.1-2 and the chroot has 2.7.1-1ubuntu4
[11:33] <vila> jelmer_: I don't have yet a natty vm (nor any natty available in fact) but I can help you test against python2.[456] if that helps
[11:33] <lifeless> night all
[11:33] <jelmer_> g'night lifeless
[11:33] <vila> jelmer_: all I need is a test subset to run on babune
[11:33] <jelmer_> vila: That'd be great, I don't have any machines with python2.4 or 2.5 anymore
[11:35] <vila> jelmer_: -s test_http ? Or are these ones passing ?
[11:37] <vila> grr, I'll have to check manually for 2.4, but 2.5 would be ok (don't ask)
[11:38] <jelmer_> vila: it looks like it's the last upload of python that breaks it
[11:38] <vila> ha, good, at least we know
[11:38] <vila> talk about 2.7 being very conservative...
[11:39] <jelmer_> well, technically we weren't conforming to the API anyway..
[11:39] <vila> :)
[11:40] <vila> let's address the issue first, we'll in a better position to throw stones and dodge the stones they'll throw at us :D
[11:41] <vila> or switch to entirely different activities not involving stones at all, snowballs come to mind
[11:41] <jelmer_> heh
[11:43]  * vila back to setting up the natty slave finally
[11:52] <vila> shudder... I love when upgrading a vm blow up the *host* X server...
[11:52] <vila> blows even
[11:53] <jelmer_> what sort of vms are you using?
[11:53] <vila> vbox
[11:54] <vila> first time I see this though, first I lost the window decorations, now it's repainting the screen verrrry slowly, scary
[11:55] <vila> reboot coming
[11:57] <vila> first shutdown all apps, very funny now that the virtual *desktops* have been *partially* merged...
[12:18] <jelmer_> vila: there's some more test failures on natty, if you're going to look at natty anyway... *hint hint* ;-)
[12:53] <vila> jelmer: yeah (was lunch here), I know, but I've been waiting for natty (*Classic* desktop) to stabilize enough
[12:55] <vila> ..and no more virtual desktops :-( What the hell did break ?
[12:57] <vila> wow, spurious shutdown !
[12:58] <vila> err no, just the fans going silent, pfew, but with the screen going dark...
[12:59] <maxb> I'm running natty (Classic Desktop) on my netbook. I dare not try it on my main machine yet :-)
[13:00] <vila> maxb: same here, that's why it was (and still is) so annoying to have the *host* contaminated
 have you tried testr --parallel yet?
 I'd be interested in how it compares to bzr's parallel - it uses test timings to inform the partitioner
[13:43] <mgz> you'll want some non-linux2 cpu counting logic before comparing too much with bzr
 mgz: so you're updating that branch right?
[13:44] <mgz> should be all updated, yell if you need me to do anything else.
[13:58] <vila> what's the canonical command/gui used on Ubuntu to change a hostname ?
[13:59] <vila> I've edited /etc/hostname but this looks incomplete
[13:59] <vila> hence probably bogus
[14:07] <maxb> vila: I believe that's all you need to do have it set correctly at next boot
[14:07] <maxb> man 1 hostname to change the setting in the running kernel
[14:08] <vila> maxb: almost, etc/hosts needs to be updated too, and apparently there is no gui for that anymore (I used to tweak it via the network manager prefs)
[14:09] <vila> the trick is that I generally set the right host name during install and never have to modify it ... until today :)
[14:09] <vila> don't know why, but changing etc/hosts makes sudo happier...
[14:24] <maxb> Yeah, /etc/hosts can upset all kinds of thing s you wouldn't think of
[14:26] <vila> maxb: sounds good now, thanks for confirming :)
[14:33] <mgz> okay, off to get cold outside.
[14:41] <vila> jelmer: I think you will appreciate the irony: http://babune.ladeuil.net:24842/view/selftest-all-platforms/job/seltest-natty/1/console
[14:43] <jelmer> vila: hehe
[14:44] <vila> this is less fun than it appears though, as it seems any natty user is now in trouble...
[14:47] <vila> jelmer: is that correct or am I pessimistic here ?
[14:48] <vila> jelmer: if not, this is really worrying, how can we detect such python changes earlier ? Should the daily build use -proposed ?
[14:53] <jelmer> vila: yes, that's correct - with the python2.7 in natty from yesterday
[14:53] <vila> argh
[14:53] <jelmer> vila: natty is not out yet, so this is as early as we can detect it
[14:54] <jelmer> vila: I think we should just fix it, release the next beta and make sure it gets into sid & natty
[14:55] <vila> jelmer: yup, so maybe I should not postpone 2.3b5 finally :-/
[14:56] <jelmer> vila: fwiw the change in upstream python was the fix for python bug 6791
[14:57] <jelmer> it was only committed to python upstream SVN 5 days ago
[14:58] <vila> rhaaa, *python* bug ! Thanks for putting me on the wrong track ubot5 !
[15:00]  * vila reading
[15:00] <vila> . o O (Malicious server crashing clients... SO WHAT !)
[15:01] <jml> bzr's log file stuff in TestCase should be in a fixture
[15:04] <vila> jml: or deleted :)
[15:15] <vila> jelmer: gentoo will be contaminated too :-(
[15:15] <jelmer> are they running python out of the release branch?
[15:15] <jelmer> the problematic bit is a svn snapshot from 18 december. It's not in any release yet.
[15:16] <vila> I don't remember the details but they some people use 2.7 too
[15:19] <jelmer> versions prior to that svn snapshot are not affected, so only people running directly out of svn will be affected
[15:25] <vila> jelmer: right, I get that, but for how long ?
[15:26] <vila> jelmer: I don't think it's worth nagging python devs for reverting this right ?
[15:28]  * vila feels dirty: installing a symlink in /usr/bin, haven't been forced to do that in .... decades ! At least...
[15:28]  * vila resumes testing the natty slave
[15:30] <jelmer> same here; I gave up on my bzr.dev alias a while ago
[15:31] <jml> gah
[15:31] <jelmer> now running system bzr and packaged plugins, empty ~/.bazaar/plugins
[15:31] <jml> I'm getting 'No handlers could be found for logger "bzr"' when running a test in Launchpad that does bzr stuff
[15:31] <jml> but afaict, getLogger('bzr').handlers has stuff in it.
[15:32] <jelmer> jml: that sounds familiar, I've seen similar things using bzrlib in other apps
[15:32] <jelmer> AFAIK adding handlers fixed that though
[15:33] <jml> I wish Python logging wasn't a global registry with hierarchy.
[15:34] <vila> jelmer: http://babune.ladeuil.net:24842/job/seltest-natty/lastFailedBuild/ 372 failures to start with 8-(
[15:34] <jelmer> vila: that's mostly the same bug though
[15:34] <vila> yup, reading now
[15:35] <vila> jelmer: so starting with -s bt.test_http should be good enough to test against various python, working on that now
[15:35] <vila> jelmer: should I adopt the bug now ?
[15:36] <jml> jelmer: oh, nice
[15:36] <jml> jelmer: Launchpad's logging magic messes things up.
[15:36] <jml> logging.getLogger('bzr') != bzrlib.trace._bzr_logger
[15:36] <jelmer> vila: feel free to, I won't be able to look at it before EOD
[15:37] <vila> jelmer: ok, I'll take it then (being pretty sure I'll got a reviewer, mwhahaha :)
[15:38] <jelmer> jml: Argh
[15:42] <Stavros> hello
[15:43] <Stavros> i have a repo with my code and everything, will it be okay if i hardlink everything to another directory to create a branch?
[15:43] <Stavros> actually hmm, no
[15:45] <vila> Stavros: Happy to help !
[15:45] <vila> Stavros: not worth mentioning --hardlink in 'bzr help branch' isn't it ?
[15:46] <vila> right, I thought so
[15:53] <vila> pfff, bzr-2.2 not compatible with testtools/subunit/whatever...
[15:54] <vila> or is whatever py27 instead ? http://babune.ladeuil.net:24842/job/seltest-natty/5/console
[15:55] <jelmer> hmm, haven't seen that one before
[15:56] <vila> jelmer: probably because mgz fixed a lot of issues in bzr-2.3
[15:58] <babu__> hi to all...i want to develop applications....how and where do i start
[16:03] <vila> babu__: to put your code under bzr: 'bzr init .' , 'bzr add'
[16:04] <vila> babu__: "bzr commit -m 'comment explaining what was changed since last commit'" when you're happy with a change
[16:04] <vila> babu__: including adding the files to start your branch
[16:07] <vila> I feel troll'ed...
[16:11] <vila> jelmer: it's related to --parallel=fork, so I'll just avoid it here
[16:12] <jelmer> ah
[16:12] <vila> argh, wrong slave :(
[16:13] <vila> nope, not --parallel related
[16:13] <babu__> wat is bazaar
[16:13] <vila> but indeed in an area fixed by mgz
[16:13] <jelmer> babu__: Hi
[16:14] <jelmer> babu__: It's a version control system - see http://bazaar.canonical.com/
[17:10] <lifeless> vila: whats not --parallel related?
[17:10] <vila> lifeless:  http://babune.ladeuil.net:24842/job/seltest-natty/5/console
[17:11] <lifeless> ah
[17:12] <lifeless> yay rearranged modules
[17:22] <vila> jelmer: https://code.launchpad.net/~vila/bzr/2.2-693880-ssl-readline/+merge/44671
[17:24] <jelmer> vila: looking..
[17:26] <vila> jelmer: I should have kept the beginning of the comment...
[17:27] <vila> ... on the other hand, this comment didn't stop you either ;D
[17:45] <jelmer> vila: I've +1'ed your patch, thanks for fixing that.
[17:46] <vila> jelmer: you're welcome, comment already added if you refresh the page :)
[17:51] <vila> ok, pqm'ed
[17:52] <vila> I'm off, family is waiting (especially my daughters ;), happy Christmas all !