[00:03] <igc> morning all
[00:04] <mwhudson> hello igc
[00:04] <mwhudson> igc: did you see that bug i filed on bzr-historycache?
[00:05] <igc> mwhudson: not yet, just logged on
[00:05] <mwhudson> igc: ok :)
[00:05]  * mwhudson holds off on the nagging
[00:21] <spiv> igc: welcome back.
[00:22] <spiv> igc: there's mail on the list from Greg Ward about bzr-fastimport you should look at, if you haven't already.
[00:43] <igc> hi spiv
[00:44] <igc> spiv: thanks for the tip - yet to get to email today but will soon
[00:50] <mwhudson> wow, i have bzr revert exploding
[00:51] <mwhudson> http://pastebin.ubuntu.com/158897/
=== tchan1 is now known as tchan
[01:06] <mwhudson> bah
[01:06] <mwhudson> dulwich is requiring python 2.5 again :(
[01:09] <mwhudson> and tests fail
[01:51] <lifeless> spiv: If my patch from friday is unreviewed, I've nearly corrected the [small] fallout from it, would love a review.
[01:52] <lifeless> spiv: '[MERGE] Reduce round trips pushing new branches substantially' is the subject
[02:12] <spiv> lifeless: sure.  I'd love a review of the updated sink-side checking for missing parent inventories patch, btw.
[02:12] <lifeless> yup
[02:12] <lifeless> have some administrivia I've been deferring too long to finish
[02:12] <spiv> Fair enough.
[03:39] <lifeless> spiv: is bzrlib.tests.blackbox.test_push.TestPush.test_push_error_on_vfs_http failing for you ?
[04:06] <spiv> lifeless: passing for me
[04:06] <spiv> lifeless: (py2.6, jaunty)
[04:06] <lifeless> _bah_
[04:14] <lifeless> ah
[04:14] <lifeless> its my removal of 'no host'
[04:18] <lifeless> oh no its not
[04:18] <lifeless> its because its not trying mkdir :)
[04:18] <lifeless> its probing for a smart server
[04:21] <lifeless> spiv: why do we have should_probe, rather than the medium probing for us ?
[04:23] <awilkins> Is dulwich what comes after brisbane?
[04:23] <lifeless> no
[04:24] <lifeless> its a python implementation of git
[04:24] <lifeless> used for bzr-git amongst aother things
[04:24] <awilkins> Ah, yes
[04:30] <spiv> lifeless: it was added because really only the HTTP medium needs to be probed, others know immediately if the transport can support smart requests or not.
[04:31] <spiv> lifeless: that work could probably be pushed down into the medium rather than via should_probe, if that's what you're asking.
[04:32] <spiv> There's probably a bit of extra awkwardness with the "probe" doubling as a weak version probe, I don't recall off the top of my head if that matters to anything.
[04:34] <lifeless> spiv: indeed, I've added a block of code
[04:34] <lifeless> are you subscribed to commits?
[04:34] <lifeless> if so, one commit back has my 'fix tests' commit - could you review that too
[04:34] <lifeless> then it can land
[04:36] <spiv> I am, I'll take a look.
[04:42] <spiv> lifeless: sent a reply to your review reply, looking at fix tests commit now.
[04:42] <spiv> Then it's *really* lunch time :)
[04:42] <lifeless> thanks!
[04:44] <spiv> lifeless: that commit looks fine.
[04:46] <lifeless> cool; in which case I'll land [using your tweak from before :P] - I've replied to your reply fwiw
[04:53] <meoblast001> hi.. i just branched a project with bzr and i have no bazaar configuration directory
[04:55] <lifeless> meoblast001: that sounds fine
[04:55] <lifeless> meoblast001: but perhaps you mean something other than what you typed
[04:55] <meoblast001> lifeless, but i need a bazaar configuration directory
[04:55] <meoblast001> so i can set my whoami
[04:55] <lifeless> 'bzr whoami --help'
[04:56] <meoblast001> lifeless, is this the correct format Braden Walters <meoblast@aol.com>
[04:57] <Peng_> meoblast001: Yes.
[04:57] <meoblast001> ok thanks
[04:59] <mwhudson> hmm\
[04:59] <mwhudson> i just this the ssh user name thing
[05:00] <lifeless> mwhudson: EPARSE
[05:00]  * mwhudson tries again
[05:01] <mwhudson> i just hit the ssh user name thing
[05:03] <lifeless> mwhudson: please upgrade it to a bug then :)
[05:05]  * spiv wonders why he hasn't
[05:05]  * spiv has lunch
[05:06] <lifeless> mwhudson: do you have an authentication.conf file?
[05:07] <mwhudson> lifeless: yes, for launchpad stuff
[05:08] <lifeless> ok, that rules out that theory :)
[05:08]  * fullermd also has LP stuff in auth.conf.
[05:08] <lifeless> I don't have one, was wondering if that was related
[05:12] <mwhudson> https://bugs.edge.launchpad.net/bzr/+bug/367726
[05:12] <ubottu> Ubuntu bug 367726 in bzr "ssh usernames specified in .ssh/config are not honoured for bzr+ssh connections" [Undecided,New]
[05:18] <lifeless> bah, pqm failure I can't reproduce
[06:24] <lifeless> chilly day today
[06:31] <AfC> I believe "bloody freezing" would be more apt.
[06:33] <lifeless> yah
[06:37] <mwhudson> AfC: i didn't think mainland australians were allowed to use phrases like that
[06:41] <lifeless> mwhudson: canadians should know
[06:42] <mwhudson> yes
[06:56] <AfC> I am but an ex-pat, cast adrift upon a sea of strangeness and schooners.
[07:16] <vila> hi all !
[07:21] <Peng_> vila: Hello. :)
[07:58] <lifeless> spiv: and its landed
[08:00] <Peng_> Yay, "bzr pull" downloaded a reasonable amount of data instead of 5 MB.
[08:02] <mwhudson> Peng_: working on launchpad, 5 megs is fairly reasonable! :)
[08:04] <spiv> lifeless: yay
[08:05] <lifeless> spiv: found another aliasing bug though, which I just fixed in transit
[08:05] <spiv> I saw that commit; it looked reasonable.
[08:05] <lifeless> yeah, I figured it was clearly correct :)
[08:25] <AfC> Does someone have a branch of bzr-gtk handy (ie published somewhere) handy? The branch on Launchpad is stalling out.
[08:28] <spiv> AfC: weird, I just branched lp:bzr-gtk with no trouble (47s, 3.7M repo)
[08:28] <spiv> AfC: I can push it up somewhere for you but it sounds like something funny is going on...
[08:30] <AfC> spiv: fair enough. I'll try again.
[08:31]  * AfC hopes it realizes it already downloaded half of it
[08:32] <AfC> [I am hoping to elucidate why `bzr viz` is claiming that pygtk is not installed]
[08:32] <AfC> [I don't think it's bzr-gtk's fault, but a glitch in the (otherwise excellent) Python packaging on this distro. I recall a similar problem when I did Python 2.4 to 2.5]
[08:47] <mwhudson> Jc2k: did you know dulwich trunk tests fail and it depends on python2.4 again?
[08:52] <lifeless> mwhudson: do you mean 2.5?
[08:52] <mwhudson> lifeless: i do
[08:52] <mwhudson> clearly today has not been a good day for me to try to make sense
[08:53]  * lifeless finishes off txaws.ec2
[09:52] <garyvdm> Hi - I did:
[09:53] <garyvdm> bzr mv lib/diff.py lib/diffwindow.py
[09:53] <garyvdm> bzr mv lib/extdiff.py diff.py
[09:53] <garyvdm> bzr commit
[09:53] <flacoste> i get the following error when i bzr branch from lp:
[09:53] <Peng_> diff.py or lib/diff.py?
[09:54] <garyvdm> Ah
[09:54] <garyvdm> Thanks
[09:54] <garyvdm> Many eyes...
[09:54] <flacoste> [francis@Huxley launchpad]$ bzr branch lp:~danilo/launchpad/ajax-textboxbzr: ERROR: bzrlib.errors.ErrorFromSmartServer: Error received from smart server: ('error', "'AbsentContentFactory' object has no attribute 'get_bytes_as'")
[09:54]  * igc dinner
[09:56] <Peng_> flacoste: Ah, lucky you. Known bug. It's been (or being) fixed. The simplest workaround is to not use the smart server, e.g. "bzr branch nosmart+bzr+ssh://bazaar.launchpad.net/~danilo/launchpad/ajax-textboxbzr".
[09:56] <flacoste> ok, thanks!
[09:56] <Peng_> (or sftp://)
[09:57] <Peng_> flacoste: FWIW, the problem is that newer clients use new smart server methods that require more data to be on the server, and older clients didn't push that data when using stacked branches.
[09:59] <flacoste> Peng_, thanks it worked fine :-)
[09:59] <Peng_> Great. :)
=== sabdfl1 is now known as sabdfl
=== thekorn_ is now known as thekorn
[12:33] <jdobrien> I keep getting the following error:
[12:33] <jdobrien>  [unknown]
[12:33] <jdobrien>   netrc_credential_store /usr/lib/python2.6/dist-packages/bzrlib/plugins/netrc_credential_store [unknown]
[12:37] <james_w> that's an error?
[12:37] <james_w> what are you doing to get that?
[12:37] <james_w> is that just part of the output?
[12:57] <lifeless> what does bzr plugins show jdobrien
[13:00] <jdobrien> lifeless: actually I'm experiencing that bug #354036
[13:00] <ubottu> Launchpad bug 354036 in bzr/1.13 "ErrorFromSmartServer - AbsentContentFactory object has no attribute 'get_bytes_as' exception while pulling from Launchpad" [High,Confirmed] https://launchpad.net/bugs/354036
[13:01] <jdobrien> lifeless: the one our whole team is experiencing
[13:02] <lifeless> jdobrien: have you applied the fix, run the fix script?
[13:03] <lifeless> spiv has had the server fix approvd today, and I'm sure mwhudson will be keen to get it uploaded
[13:03]  * jdobrien looks for the fix script
[13:03] <jdobrien> lifeless: foo?
[13:03] <lifeless> yes
[13:03] <lifeless> and with the server side fix done we can start investigating other causes
[13:03] <lifeless> its kindof a generic error
[13:04] <jdobrien> as is the patch name :-)
[13:11] <jdobrien> lifeless: bzrlib.errors.TransportNotPossible: Transport operation not possible: readonly transport
[13:12] <lifeless> use a bzr+ssh url, not an lp url
[13:12] <jdobrien> lifeless: i did: python foo.py  bzr+ssh://bazaar.launchpad.net/~gafton/ubunet/updown-fixtests
[13:13] <jdobrien> i think many on our team just downgraded bzr...it keeps us moving but doen't help resolve the issue
[13:16] <jdobrien> lifeless: oh wait... that's not my branch
[13:16] <jdobrien> lifeless: i suspect it needs to be fixed by its owner
[13:25] <lifeless> jdobrien: thats right
[13:25] <lifeless> downgraded bzr will cause the problem for other people
[13:25] <jdobrien> yeah...like me! I can't review anyone's branch now
[13:25] <jdobrien> lifeless: hmm...that sounds like their problem ;)
[13:26] <lifeless> you can use sftp:// urls as a workaround
[13:26] <spiv> Or even prefix nosmart+ to the bzr+ssh:// URL... the bug description should have a comprehensive list of workarounds now.
[13:41] <lllama1> Hello all. Simple question (can't quite find the right google words): how can I include (and have updated) the revid in my source files?
[13:43] <rocky> has jelmer been around lately?
[13:51] <lifeless> lllama1: see bzr --help version-info, and also the new (beta quality in 1.14) tree filters
[13:51] <lllama1> lifeless: star. Many thanks.
[13:54] <rocky> is there anyway to disable a plugin that has been installed just for one bzr request?
[14:21] <knielsen> Hi, I made a tag with `bzr tag -rrevid:XXX` in a local branch. The tag works fine, but is there any way I can see it like other pending changes? It's nowhere to be seen in `bzr status`, `bzr diff`, or `bzr missing`
[14:22] <beuno> knielsen, bzr tags
[14:22] <beuno> it's not pending, because it's already applied to the branch
[14:23] <knielsen> I assume it will be transfered as part of a `bzr push`, but it would be nice to see what tags are pending before pushing? But maybe that's not possible
[14:23] <beuno> knielsen, sure, bzr tags-missing or something like that would be nice
[14:23] <beuno> file a bug  :)
[14:24] <knielsen> beuno: ok, thanks. So a tag is not part of a commit, I guess, bzr tag applies the tag immediately without waiting for a commit
[14:24] <lifeless> knielsen: a tag of an existing rev is immediate, yes.
[14:24] <knielsen> makes sense I guess, thanks for the help
=== dereine[OFF] is now known as dereine
=== ja1 is now known as jam
=== nevans1 is now known as nevans
[16:21] <vila> BasicOSX: It looks like NEWS in bzr.dev is quite wrong. At least it mentions bug #256612 being fixed in 1.14rc2 where in fact the fix exists only in bzr.dev (AFAICS)
[16:21] <ubottu> Launchpad bug 256612 in bzr "should prompt for usernames during HTTP Basic/Digest auth" [High,Fix released] https://launchpad.net/bugs/256612
=== nevans1 is now known as nevans
[18:44] <LarstiQ> gah that wiki spam is irritating
[19:05] <jam> LarstiQ: yeah, I got newz to disable their accounts
[19:06] <jam> did you also realize they are attaching files with bad html
[19:06] <jam> nasty stuff that uses javascript to rewrite the body
[19:06] <jam> and encode the actual content in decimal
[19:06] <LarstiQ> jam: haven't spotted that in the notifications
[19:06] <jam> LarstiQ: Attachments don't generate emails
[19:06] <jam> which is also a bad thing
[19:06] <LarstiQ> ick
[19:06] <jam> http://bazaar-vcs.org/Talks/NedovHobahit?action=AttachFile&do=view&target=skoal-cherry-smokeless-tobacco.txt
[19:07] <jam> I opened an rt request about having attachments generate emails
[19:07] <LarstiQ> jam: ah, I was wondering if the dribble might have been data in distributed network
[19:07] <jam> LarstiQ: and even better, if you delete the *page* it *doesn't* delete the attachments
[19:07] <LarstiQ> jam: great
[19:12] <garyvdm> Hi - I'm hacking some new code for qbzr.
[19:12] <garyvdm> I have a simple base class - and another class that inherits form that.
[19:13] <garyvdm> When I lazy_import the base class - I get this error:
[19:13] <garyvdm> bzr: ERROR: exceptions.TypeError: Error when calling the metaclass bases
[19:13] <garyvdm>     metaclass conflict: the metaclass of a derived class must be a (non-strict) subclass of the metaclasses of all its bases
[19:14] <garyvdm> When I don't lazy_import - It works fine.
[19:14] <garyvdm> How come this is?
[19:15] <LarstiQ> garyvdm: are you doing metaclass magic?
[19:15] <garyvdm> LarstiQ: No
[19:15] <garyvdm> This is the code and trace back
[19:15] <garyvdm> http://python.pastebin.com/m7962071e
[19:16] <garyvdm> The base class is in bzrlib.plugins.qbzr.lib.diff: http://python.pastebin.com/d18c07715 - line 38
[19:17] <LarstiQ> garyvdm: that looks to me like it should work, my only guess is that the base class is being lazy_import proxied and clashes somewhere
[19:17] <eggy_> It looks like the ScopeReplacer overloads __getattribute__, __call__ and __setattr__, and that doesn't work for subclassing
[19:17] <LarstiQ> garyvdm: jam is much more knowledgeable about lazy_import, maybe he knows
[19:17] <garyvdm> the inheriting class is in bzrlib.plugins.qbzr.lib.commands: http://python.pastebin.com/d597201ff - line 328
[19:17] <jam> I know nothing :)
[19:17] <eggy_> LarstiQ: I don't think you can possibly proxy out subclassing
[19:18]  * LarstiQ hands over the stage to eggy_ ;)
[19:18] <jam> garyvdm: if you are inheriting from a class lazy importing is worthless
[19:18] <jam> so don't fret too much about it
[19:18] <eggy_> You can't even proxy out use of operators like + and () with __getattribute__
[19:18] <jam> I have the feeling that metaclasses get things messy
[19:19] <garyvdm> jam: ok
[19:19] <eggy_> jam: should this get documented? Like, "don't use this for classes you're going to subclass"
[19:19] <jam> eggy_: if you want, it should be fairly obvious that using something during import that you 'lazily' imported, is just going to force the import
[19:20] <jam> garyvdm: are you importing the class itself, or the module
[19:20] <jam> in *general* i would only use lazy import to import modules
[19:20] <eggy_> jam: ah yes, I just read it now. It does recommend to only lazy import modules
[19:21] <garyvdm> jam: Just the class I think. I'm doing: from bzrlib.plugins.qbzr.lib.diff import DiffArgProvider
=== beuno_ is now known as beuno
[20:35] <rindolf> Hi all.
[20:36] <rindolf> When doing:
[20:36] <rindolf> bzr checkout 'svn://anonsvn.kde.org/home/kde/trunk/extragear/multimedia/amarok/' amarok.trunk/
[20:36] <rindolf> I'm getting:
[20:36] <rindolf> bzr: ERROR: Not a branch: "/trunk/extragear/multimedia/amarok".
[20:36] <rindolf> What can I do about it?
[20:41] <LarstiQ> rindolf: I recall something about the kde repo layout being specified in the bzr-svn code
[20:41] <LarstiQ> rindolf: which version of bzr-svn btw?
[20:42] <rindolf> LarstiQ: bzr-svn-0.5.3-1 , bzr-1.13.0, MDV Cooker
[20:42] <LarstiQ> MDV Cooker doesn't mean anything, but the others seem fine
[20:42] <rindolf> LarstiQ: Mandriva Linux Cooker
[20:43] <LarstiQ> ah
[20:43] <LarstiQ> rindolf: does `bzr branch svn://anonsvn.kde.org/home/kde/trunk/extragear/` work? Ie, two levels higher
[20:44] <rindolf> LarstiQ: let me see.
[20:44] <rindolf> fetching svn revision info 57/960031
[20:44]  * LarstiQ got that inspiration from bzr-svn layout.custom.KDELayout
[20:44] <rindolf> Seems so.
[20:45] <rindolf> Why "bzr branch" instead of "bzr checkout"?
[20:45] <LarstiQ> rindolf: might want to file a bug that the layout doesn't work as smoothly for the extragear part of the KDE repo
[20:45] <LarstiQ> rindolf: oh eh, you can use checkout if you want
[20:45]  * LarstiQ normally doesn't so did not construct what he would do with that
[20:45] <rindolf> LarstiQ: can I tweak the layout locally?
[20:46] <LarstiQ> rindolf: I think so
[20:46] <rindolf> LarstiQ: OK.
[20:46] <LarstiQ> rindolf: see `bzr help svn-layout`
[20:47] <rindolf> LarstiQ: where can I find layout.custom.KDELayout? I don't seem to have it.
[20:54] <LarstiQ> rindolf: for me, the full path to the file is /home/larstiq/.bazaar/plugins/dev/svn/layout/custom.py
[20:54] <rindolf> I see it's in /usr/lib/python2.6/site-packages/bzrlib/plugins/svn/layout/custom.py
[20:55] <LarstiQ> rindolf: yeah, that makes sense for distro installed bzr-svn
[20:55] <rindolf> LarstiQ: OK.
[20:55] <rindolf> LarstiQ: is there anyway I can use it?
[20:55] <rindolf> KDELayout, I mean.
[20:56] <LarstiQ> rindolf: well, I think it is already being used, which is why it raises the NotABranch error
[20:56] <rindolf> LarstiQ: ah.
[20:57] <LarstiQ> rindolf: you could look in ~/.bzr.log or maybe `bzr info` to see what svn branching scheme is being used
[20:57] <LarstiQ> rindolf: the thing is, it looks like the bzr-svn KDELayout is incomplete
[20:57] <rindolf> LarstiQ: I see.
[20:57] <LarstiQ> rindolf: you might be able to get what you want with the help from `bzr help svn-layout`, but additionally I think bzr-svn's KDELayout needs to be fixed.
[20:58] <rindolf> LarstiQ: OK.
[20:59] <rindolf> LarstiQ: I don't see KDELayout being used.
[21:01] <rindolf> LarstiQ: and repository UUID matches.
[21:01] <LarstiQ> rindolf: hmm.
[21:02] <LarstiQ> rindolf: then I'm slightly out of my depth.
[21:02]  * LarstiQ tries it locally
[21:03] <rindolf> LarstiQ: at least I don't see it in the logs.
[21:03] <rindolf> LarstiQ: but it may still be used
[21:03] <BasicOSX> vila:  haven't looked, but I'm hoping it's a bad merge. Probably from the spiv branch where I was warned NEWS merge might be messy
[21:04] <LarstiQ> rindolf: it's not mentioned when -Dsvn -Dtranport are supplied either
[21:04] <rindolf> LarstiQ: ah.
[21:04]  * LarstiQ ponders
[21:09] <LarstiQ> rindolf: bzr svn-layout svn://anonsvn.kde.org/home/kde/
[21:09] <LarstiQ> rindolf: gives me an inverse trunk1 layout
[21:44] <xma> hi
[21:45] <rindolf> LarstiQ: so what can I do?
[21:45] <LarstiQ> rindolf: have you tried the suggestion from `bzr help svn-layout`?
[21:48] <rindolf> LarstiQ: yes, I now added « branches = trunk/extragear/multimedia/amarok/ » and it seems to work.
[21:49] <LarstiQ> rindolf: good to hear
[21:49] <rindolf> It currently tries to fetch info on all 960059 revisions.
[21:49] <rindolf> LarstiQ: can I used the history only starting from a certain revision?
[21:50] <LarstiQ> rindolf: I don't believe so
[21:51] <LarstiQ> but I'm just a user, so I could be wrong
[21:53]  * LarstiQ goes to bed
[21:53] <LarstiQ> rindolf: jelmer doesn't seem to be online, but if you file a question/bug on launchpad.net/bzr-svn he'll get to it
[21:54] <rindolf> LarstiQ: OK.
=== beuno_ is now known as beuno
[22:32] <rocky> what version of bzr did bug #183559 get committed to (if any) ?
[22:32] <ubottu> Launchpad bug 183559 in bzr "bzr switch should have a -r option" [Undecided,Fix committed] https://launchpad.net/bugs/183559
[22:47] <kenichi> the hook that lp uses to comb "bugs" revprops... is that in the bzr source tree?
[23:08] <jam> rocky: 'fix committed' means someone implemented it, not that it has been merged
[23:09] <jam> looking at the bug, it seems Odd_Bloke did the work here: https://code.edge.launchpad.net/~daniel-thewatkins/bzr/183559-switch-r