[13:43] <Noldorin> hi again jelmer_
[15:26] <jelmer_> hi Noldorin
[16:56] <Noldorin> jelmer, i was thinking, since this bug fix might not happen for years, mind doing a quick write-up of what needs to be done? ;-)
[16:58] <jelmer> Noldorin: IIRC I already did that on the bug report?
[16:58] <Noldorin> jelmer, it was very brief, and quite unclear to me :-(
[16:58] <Noldorin> perhaps if you explain a bit more, i can rephrase
[16:58] <Noldorin> i know it's not always easy when it's not one's native language
[17:01] <jelmer> Noldorin: Sorry, I don't think I can add much more detail than that without actually spending an hour or two on it myself
[17:01] <Noldorin> hmm ok
[17:01] <Noldorin> :-(
[17:01] <Noldorin> the problem is
[17:02] <Noldorin> it's not enough for someone to solve it themself
[17:02] <Noldorin> unless they know bzr really well
[17:02] <jelmer> Noldorin: I don't think it's really "if they know bzr really well"; they do however have to be aware of the internal models of both bzr and git
[17:02] <Noldorin> that's what i mean :-P
[17:02] <jelmer> Noldorin: I don't see how you could fix this bug without being aware of that though
[17:03] <Noldorin> you're just getting into semantics now
[17:03] <Noldorin> no indeed
[17:03] <jelmer> the alternative is for me to spend a day or so and describe in very fine detail what needs to be done
[17:03] <jelmer> but at that point I might as well do the fix myself
[17:03] <jelmer> I don't think it's fair to say that it will take many more years for this bug to be fixed
[17:04] <Noldorin> haha
[17:04] <Noldorin> "many more"
[17:04] <Noldorin> just 1 eh? ;-)
[17:08] <jelmer> Noldorin: no idea, sorry
[17:08] <jelmer> Noldorin: this is a corner case bug in an experimental feature of something I work on in my spare time
[17:08] <Noldorin> *wanders off to Hg*
[17:08] <jelmer> I appreciate that you are hitting this, but I have only 24 hours in my day
[17:08] <Noldorin> they seem to be more active :-)
[17:09] <Noldorin> pfft
[17:09] <jelmer> Noldorin: fair enough
[17:09] <Noldorin> this take 2 hours to fix
[17:09] <Noldorin> been going on 6+ months now :-P
[17:09] <Noldorin> i've had enoug hi think
[19:24] <mathrick__> hmm, bzr+ssh:// results in smart protocol being used, but with appropriate credentials, right?
[19:24] <mathrick__> and it requires a compatible bzr version to be installed on the remote side
[19:26] <lifeless> yes, though bzr is wide compatible with itself
[19:27] <mathrick__> lifeless: not when I use the development format on the branch, though. Or is it?
[19:27] <lifeless> if that dev format is supported by the bzr at the other end it should be
[19:27] <lifeless> it will narrow the options though
[19:27] <mathrick__> well yeah, but it's the current format, which means 2.5b
[19:28] <mathrick__> hmm, what's the bzr send syntax for "send a packaged patch of the current branch for revisions 19 and later"?
[19:43] <mathrick__> lifeless: any hint on the above?
[19:44] <lifeless> bzr send -r 19.. ?
[19:46] <mathrick__> lifeless: oh right, I mean "without consulting the submit branch, just locally"
[19:47] <lifeless> mathrick__: I don't know, sorry.
[19:47] <mathrick__> ok
[19:47] <lifeless> possibly -r 19..-1 . or something
[19:47] <lifeless> mathrick__: you could have a copy of the submit branch locally
[19:48] <mathrick__> well yeah, but at this point I think it's faster to wait for the terribly slow submit branch than to copy
[19:48] <lifeless> mathrick__: well I mean you can carry it round with you routinely
[19:48] <lifeless> mathrick__: doesn't matter if its a bit stale when you submit that way
[19:49] <lifeless> there are folk that have run totally disconnected from each other, both with a copy of the others branch, kept up to date with send
[19:51] <mathrick__> lifeless: I know, it was a stop-gap measure though intended to save time (very slow push branch and it just decided to repack the whole 80MB of history), rather than systematic solution
[19:51] <mathrick__> I just hoped file:.,revno=19 would help, but apparently it doesn't
[20:14] <thumper> bzr error in recipe build: https://launchpadlibrarian.net/92511530/buildlog.txt.gz - anyone got an idea what it means?
[20:19] <jelmer> thumper: you have whitespace at the beginning of the control file
[20:19] <jelmer> thumper: this causes older versions of python-debian to blow up
[20:19] <thumper> um...
[20:19] <jelmer> thumper: actually, whitespace or comments
[20:19] <thumper> since it uses nest part, I'll ahve to look
[20:20] <jelmer> thumper: there is an RT open about upgrading python-debian, FWIW. there are a lot of desktop team packages that are affected by this bug
[20:20] <thumper> jelmer: http://bazaar.launchpad.net/+branch/compiz/view/head:/debian/control
[20:22] <jelmer> thumper: according to the log file, you're using a different control file
[20:22] <jelmer> thumper: http://bazaar.launchpad.net/+branch/~smspillaz/metacity/metacity.lim/view/head:/debian/control
[20:22] <thumper> hmm...
[20:22] <thumper> perhaps I was looking at the wrong build...
[20:22] <jelmer> (which does have comments at the top of the control file)
[20:23]  * thumper fines another
[20:25] <thumper> https://launchpadlibrarian.net/92617403/buildlog.txt.gz
[20:25] <thumper> this one had failed to upload
[20:25] <jelmer> thumper: do you have the upload log?
[20:26] <thumper> yes, just found it
[20:26]  * thumper sighs
[20:26] <thumper> INFO 	compiz_0.9.7.0~bzr2995-r3009really2995-p713~precise1.dsc: Version older than that in the archive. 1:0.9.7.0~bzr2995-r3009really2995-p713~precise1 <= 1:0.9.7.1-r3009really2995-p710~precise1
[20:28] <thumper> jelmer: so... the first one
[20:28] <thumper> jelmer: is there any workaround?
[20:28] <jelmer> thumper: remove the comments from the beginning of the control file
[20:29] <poolie> hi all
[20:29] <jelmer> thumper: for the second, make sure that your recipe generates newer version strings for newer versions of the package
[20:29] <jelmer> thumper: admittedly, launchpad's UI sucks in this regard at the moment
[20:30] <thumper> jelmer: yeah... I'm using others branches
[20:30] <thumper> jelmer: so I'm constantly surprised at what they have the values set to :(
[20:31] <jelmer> 'morning poolie !
[20:33] <jelmer> thumper: launchpad should be able to see that a build it's going to fire off will have a version string that's older than that of the last build; it shouldn't even start the build and print a clear error rather than failing confusingly during the upload
[20:33] <thumper> jelmer: care to file a bug for that :)
[20:33] <thumper> I'll "me too" it
[20:35] <jelmer> I suspect I have filed on in the past
[20:35]  * jelmer searches
[20:35] <jelmer> I have done this thing previously where I reported the same bug 3 times over the course of 6 months...
[20:39] <poolie> jelmer, bugs.launchpad.net/~/+affectingbugs :)
[20:40] <jelmer> poolie: 1 → 75 of 639 results :)
[20:40] <poolie> yeah there is that
[20:46] <jelmer> thumper: bug 670474 is part of it
[20:49] <jelmer> thumper: filed bug 931131
[20:49] <thumper> ta
[20:53] <lifeless> jelmer: small request, if you would
[20:53] <lifeless> jelmer: don't use imperatives in bug descriptions or summaries
[20:55] <lifeless> jelmer: (for LP anyhow; I don't care what you do elsewhere :P)
[20:56] <jelmer> lifeless: sure
[20:56] <jelmer> updated bug 931131
[20:56] <jelmer> lifeless: is that better?
[20:57] <lifeless> yes, much
[20:57] <lifeless> https://plus.google.com/105660309458564946897/posts/BLhnbgoouXV <- my previous mention of this ;)
[20:58] <lifeless> jelmer: I've tweaked it to say recipes too, but yeah, thanks.
[21:01] <lifeless> jelmer: also, it looks like a duplicate to me :)
[21:01] <poolie> snort
[21:01] <jelmer> lifeless: I thought so too, but I couldn't find a bug it would be a dupe of
[21:02] <lifeless> jelmer: bug 620248 ?
[21:02] <poolie> sorry
[21:02] <lifeless> poolie: for being amused ?
[21:02] <jelmer> lifeless: the have the same cause but are different bugs
[21:03] <poolie> yeah it was a bit snarky, sorry
[21:03] <poolie> but i was amused by repeatedly rephrasing it then duping it
[21:03] <poolie> i do agree with the general thing of the g+ post
[21:03] <lifeless> jelmer: I'm torn in such cases; probably mutually referenced each other in the summary is a good starting point
[21:04] <lifeless> jelmer: when its the same root cause I usually do dup them, but list /all/ the symptoms
[21:04] <jelmer> lifeless: I would argue that they should be two different bug reports precisely because of your G+ post
[21:04] <poolie> but i think sometimes there is a semantic difference and sometimes it is just a different phrasing
[21:04] <jelmer> it would be possible to fix one and not the other
[21:04] <lifeless> jelmer: I would love it if we had [symptom ...] -> [cause] -> [fix ...] in our model
[21:05] <lifeless> jelmer: I don't mind either way :) - just sharing how I try and balance these tensions
[21:05] <poolie> a graph of nodes like that would be nice
[21:05] <lifeless> poolie: I find it -much- easier, years later, to deal with reports that describe symptoms rather than solutions
[21:06] <lifeless> poolie: having spent a few weeks earlier this year doing precisely that (dealing with years old reports), I'm more convinced than ever that it helps
[21:06] <poolie> that is the general thing that i agree with
[21:06] <jelmer> lifeless: sure :)
[21:06] <lifeless> poolie: \o/
[21:06] <poolie> istr asking you to do this in bzr too :)
[21:07] <poolie> i'm just saying, if it's a transform from "shouldn't screw up X" to "screws up X"
[21:07] <poolie> it's fairly mechanical, and not that hard to do it years later
[21:07] <poolie> perhaps it's worth changing for the sake of setting a good example
[21:08] <lifeless> sure, ack on that
[21:09] <poolie> i wish people wouldn't file bugs like "bzr crashes while trying to push"
[21:09] <poolie> :/
[21:09] <poolie> ffs
[21:10] <jelmer> poolie: that's still better than "bzr crash"
[21:10] <jelmer> :P
[21:10] <poolie> barely
[21:10] <lifeless> I think its a combination of having good examples, good search juice, and making it easy for devs that decide to go spelunking in the bug db
[21:11] <jelmer> lifeless: launchpad's search is a lot better than it used to be but still kindof sucks
[21:11] <jelmer> browsing is a lot better than in e.g. bugzilla though
[21:12] <poolie> btw did you see http://castrojo.tumblr.com/post/11360873455/lets-make-it-personal
[21:13] <lifeless> poolie: I hadn't but I agree.
[21:14] <lifeless> I wish folk would /do/ rather than /suggest/
[21:15] <poolie> +1
[21:15] <AuroraBorealis> well changing the layout of the profile dosn't seem like a trivial task, and a lot of people are better at ideas rather then coding :>
[21:15] <poolie> though this is a rare case where it at least has inspiring mockups
[21:16] <lifeless> AuroraBorealis: its a task which requires little guts-of-lp-knowledge
[21:17] <lifeless> AuroraBorealis: so is amenable to folk that just want to get stuck in and help, and know e.g. html + css + (some) js
[21:17] <poolie> there's a couple of things
[21:17] <lifeless> AuroraBorealis: we mentor folk happily
[21:17] <poolie> one is that peopel ought to customize it a lot
[21:17] <poolie> the other is just removing a lot of the details of that page....
[21:17] <lifeless> hide / delete  / shove to a dedicated directory service / ...
[21:18] <poolie> a good mockup of the lp page that either preserves or specifically removes all the information that's currently on it would be more than half the way towards improving it
[21:18] <AuroraBorealis> true.
[21:18] <AuroraBorealis> i do agree that the main profile pages, and the main pages of projects are pretty ugly.
[21:18] <AuroraBorealis> like github, you go to a project page and you see code / the information about the code
[21:18] <lifeless> the problem is that we have so many /functional/ problems
[21:18] <AuroraBorealis> takes a few clicks to actually see code, and even then its weird
[21:19] <lifeless> that things like this are many many months or years away from getting traction
[21:19] <lifeless> so unless (a) priorities change or (b) we get radically more efficient at development [trying to] or (c) someone steps up and does it, it won't happen
[21:20] <AuroraBorealis> hmm.
[21:20] <poolie> i reckon if someone had a compelling mockup that improved it they might get some volunteer development help
[21:24] <abentley> jelmer: around?
[21:25] <poolie> ok, rebooting precisely
[21:25] <AuroraBorealis> i've been trying to get myself working on bzr code, but its hard to follow admittedly =P
[21:25] <poolie> just ask here
[21:25] <jelmer> abentley: hi
[21:26] <abentley> jelmer: I'm trying to add native colocation support to bzr-pipeline.  I fail at creating a native colocated branch in a test case.  Can you help me get started?
[21:27] <jelmer> abentley: ah, cool
[21:27] <jelmer> abentley: what would you like to create exactly?
[21:27] <jelmer> abentley: a colocated branch in a control directory that already holds an active branch and a working tree?
[21:28] <abentley> I want to create a working tree with a single colocated branch.
[21:28] <lifeless> AuroraBorealis: the lp code is rather different; some folk may find one easier than the other
[21:29] <AuroraBorealis> well i'm interested in both =P
[21:29] <AuroraBorealis> so in due time.
[21:29] <poolie> o/ abentley
[21:29] <abentley> poolie: o/
[21:30] <poolie> you could say that lp is kind of a harder environment but easier code
[21:30] <AuroraBorealis> my main problem with..python code i guess is i use a text editor, but then i cant like ctrl+click and go to a class/function definition
[21:30] <AuroraBorealis> like i can with java/IDE =P
[21:30] <poolie> you can use eclipse and pydev
[21:31] <AuroraBorealis> yeah. i have been using that
[21:31] <AuroraBorealis> since with unkown code its the only way i can even get anywhere
[21:31] <lifeless> AuroraBorealis: wallyworld highly recommends some IDE whose name I forget
[21:31] <poolie> jcharm?
[21:31] <abentley> lifeless: You beat me to it.
[21:31] <poolie> or, Wing IDE is pretty good
[21:31] <lifeless> abentley: :)
[21:31] <AuroraBorealis> jcharm is the ide?
[21:31] <poolie> but, there is generally speaking, a problem that when python code says "o.foo_method()"
[21:31] <lifeless> AuroraBorealis: wallyworld hangs out in #launchpad-dev, from ~ 1 hour from now, if you want to ask him
[21:32] <poolie> it is anyone's guess what code that's actually going to call ;)
[21:32] <abentley> jelmer:  I want to create a working tree with a single colocated branch.
[21:32] <jelmer> abentley: I guess we could use a utility function for creating something like that in bzr core
[21:32] <poolie> anyhow really rebooting
[21:32] <AuroraBorealis> ok.
[21:32] <jelmer> abentley: that could basically do:
[21:32] <jelmer> abentley: x = self.make_bzrdir('.')
[21:32] <jelmer> abentley: x.create_branch(name='colocated-thing')
[21:33] <jelmer> abentley: x.set_branch_reference(_)
[21:33] <jelmer> abentley: x.create_workingtree()
[21:34] <abentley> jelmer: I have http://pastebin.ubuntu.com/839691/ from attempting to copy switch -b behaviour, but it doesn't work.
[21:35] <mlh> AuroraBorealis: people I know love pycharm and sublimetext
[21:35] <mlh> sublime is not free though
[21:35] <mlh> oh, pycharm isn't either :-)  .  Both have free trial periods
[21:36] <mlh> and windows /mac only
[21:36] <jelmer> abentley: I don't think make_branch() will handle URLs with colocated branch names in them very well at the moment.
[21:37] <abentley> jelmer: oh, I should have deleted that line, eh?
[21:38] <jelmer> abentley: Yeah, I don't think that's necessary - sprout should already create the branch
[21:39] <abentley> jelmer: Okay, that works.  Cool.  I'll still try it the way you showed, as that looks cleaner.
[21:41] <AuroraBorealis> mlh, sublimetext works on linux too. I use them already =)
[21:44] <mlh> AuroraBorealis: ah, that's new to me.  Not that I pay much attention.
[22:19] <LarstiQ> AuroraBorealis: so is there anything you'd like to do with bzr code?
[22:19] <AuroraBorealis> i have...like 2 bugs that i think are assigned to me at the moment
[22:19] <AuroraBorealis> or i said i'd try and work on
[22:20] <AuroraBorealis> https://bugs.launchpad.net/bzr/+bug/81689 and https://bugs.launchpad.net/bzr/+bug/847388
[22:20] <poolie> ooh they would be great to fix
[22:20] <abentley> jelmer: given two branches, how would you detect whether they were colocated with one another?  I'd expect bzrdir.root_transport to the same, but it's not.
[22:21] <poolie> i would be happy to talk about them with you
[22:22] <AuroraBorealis> poolie, the second one i believe i have fixed, since all it involves is just adding '--no-tty' to the command line for gpg, i just need to test it on windows"
[22:22] <jelmer> abentley: Branch.control_url
[22:23] <AuroraBorealis> and the first one ive emailed someone about, and he said it would be fine if files that are symlinks are just checked out as text files with the 'location' inside the text file
[22:23] <AuroraBorealis> since in the bug report, normal users don't necessarily have permission to do NTFS junctions
[22:25] <abentley> jelmer: I get values like "file:///tmp/testbzr-Ca9fWS.tmp/bzrlib.plugins.pipeline.tests.test_pipeline.TestPipeStorage.test_insert_pipe_uses_native_colo/work/first/.bzr/branches/second/" for control_url, so the urls are going to be different even for colocated branches.
[22:28] <poolie> perhaps there should be a method to check if they're the same, rather than defining that callers should check the urls
[22:30] <jelmer> abentley: that's a bzr-colo branch
[22:31] <jelmer> abentley: not a bzr 2.5 colocated branch
[22:31] <jelmer> though I like poolie's suggestion of just adding a method for this
[22:33] <abentley> jelmer: I'm calling bzrdir.sprout('file:///tmp/testbzr-Pm8VYT.tmp/bzrlib.plugins.pipeline.tests.test_pipeline.TestPipeStorage.test_insert_pipe_uses_native_colo/work/first/,branch=second') and getting a bzr-colo branch?
[22:38] <jelmer> abentley: checkling..
[22:40] <abentley> jelmer: I'm stepping through it with pdb, and "bzr branches" thinks it's colocated.
[22:41] <jelmer> abentley: What does Branch.open(x).control_url say?
[22:42] <jelmer> I wonder if there's an inconsistency here between Branch.open and BzrDir.sprout()
[22:45] <abentley> jelmer: I've renamed 'first' to 'colo', and Branch.open(ctrl.root_transport.base).control_url => 'file:///tmp/testbzr-U_SFec.tmp/bzrlib.plugins.pipeline.tests.test_pipeline.TestPipeStorage.test_insert_pipe_uses_native_colo/work/colo/.bzr/branches/second/'