[00:00] <peitschie> hi poolie btw :).  It's been a while!
[00:00] <fullermd> Jeez.  I didn't even notice that.
[00:00] <poolie> hi guys
[00:00] <fullermd> That explains why bzr keeps redistributing my files according to need...
[00:00] <peitschie> roflmao
[00:01] <spiv> fullermd: funny thing for a decentralised system to do ;)
[00:06] <spm> Q: have branch A (master) and my edits to that in branch B. want to verify the diff between A and B. I typically do this as cd A ; bzr merge --preview ../B/ Is there a 'better' way of achieving this?
[00:08] <spiv> spm: perhaps “bzr merge -d ../A --preview .”
[00:09] <spiv> Depending on how you define “better” ;)
[00:09] <jelmer> "cd B && bzr diff -rancestor:../A" ?
[00:09] <jelmer> (if you want to see the differences new in B rather than the result of the merged tree)
[00:10] <spm> spiv: not having to have my cwd in A would be ideal. I have powers in there and avoiding even accidental pulls/merges etc is the goal. So yeah, that solutions works nicely!
[00:11] <spm> jelmer: ooo. that works nicely too. I think I prefer that. clearly a 'diff' action, vs a merge trial. ta muchly!
[00:14] <spm> and yes, want to verify that my changes are what I expected (lots of people are all working to the master, so is constantly updated). A final sanity check before I put the MP up. more or less.
=== Ursinha is now known as Ursinha-afk
[02:13] <peitschie> is there anyone here that could assist with bazaar explorer hats?
[02:14] <peitschie> i'm trying to create some custom toolbar entries (as opposed to "tools" entries), and just can't seem to get it to show up :(
[02:14] <poolie> hi spiv
[02:15] <poolie> peitschie: i can try to help but i don't have any suggestions just off that
[02:15] <poolie> probably i'd just try to see what's different between your configuration and what it ships with
[02:16] <poolie> or put in some trace messages to work out why they're not active
[02:16] <peitschie> poolie: i can get the toolbar to show up if its in the user-coded file, and the button highlights when the hat is actually selected in the explorer hats window... but there doesn't seem to be any examples of people doing it in the wild that I can tell
[02:18] <poolie> so what exactly is going wrong?
[02:19] <peitschie> poolie: thats the question :).  I'm getting a local branch of the current head now and will start with the print statements.  Basically, when the user browses to the repository screen, I want to add a new button up near the existing 3 in the toolbar that says "Create new feature"
[02:19] <peitschie> poolie: the toolbar element appears to work when I put it in the user file directly (the one stored in their main bzr configuration)
[02:20] <peitschie> poolie: just doesn't do anything when I put it in the hat's own toolbars.xml file
[02:30] <poolie> ok
[02:30] <poolie> i don't know off hand, it may just be a bug, i'll try to help you fix it
[02:31] <peitschie> poolie:... ahh... that'd do it.  I don't think the file is even being requested :/.  Will investigate further :)
[03:23] <peitschie> poolie: found the problem.  Filed a bug https://bugs.launchpad.net/bzr-explorer/+bug/881783 :)
[03:23] <ubot5> Ubuntu bug 881783 in Bazaar Explorer "Hat toolbars are not displayed (though user ones are)" [Undecided,New]
[03:24] <poolie> oops
[03:25] <peitschie> poolie: the problem is to do with the toolbar builder not refreshing after the hat is loaded... I don't have enough system knowledge to know the proper way to fix it though :(
=== GRiD_ is now known as GRiD
[04:25] <poolie> peitschie: still here? do you want me to look into it?
[04:27] <peitschie> poolie: i am still around :).  As I stated in the bug, I know the system cause (lazy loaded hats), but don't have a fix.  If you've got time for a fix, I'd never turn it down... I was potentially going to glance at it this weekend though outside work to see how difficult it is to rejig
[04:27] <poolie> i'll leave it with you then because i have some things in my queue already, but please do ask if you get started on it
[04:30] <peitschie> poolie: alrighty :)... thanks for the assistance!
[06:03] <poolie> hi jam, you're up late, or early :)
[07:07] <mgz> morning all
[07:11] <vila> hi mgz, poolie
[07:11] <vila> hi all other :)
[07:14]  * fullermd flails around in a vaguely wave-like fashion.
[07:25] <Merwin> hi vila :)
[07:32] <vila> Merwin: I've made progress on your bug, resolve is not the root cause, merge is
[07:32] <Merwin> Pfiou, seems to be a big and complicated bug
[08:28] <poolie> hi vila, mgz
[08:57] <mgz> okay, sent a note to the udd list about yesterday's fun with the package importer
[09:01] <ccxCZ> jelmer: current bzr-git claims to require dulwich 0.8.1, but I don't see that released anywhere, does that mean dev version then?
[09:02] <ccxCZ> and if so should I branch you @ samba.org or at launchpad?
[09:03] <mgz> ccxCZ: I hope he's asleep, but to answer your questions, yes, and either, launchpad worked fine for me
[09:04] <poolie> ok, signing off now
[09:04] <poolie> mgz, good for you
[09:04] <mgz> have a nice evening poolie
[09:04] <ccxCZ> ah forgot this is slow channels :] he spoke few lines back and I forgot to check the timestamp
[09:05] <vila> g'nignt poolie
[09:06] <mgz> I can help out if you get stuck, but all you should need (provided you have the right -dev packages) is the normal setup.py run for dulwich then bzr-git after removing your current versions
[09:06] <poolie> this was fun, and should be useful
[09:06] <ccxCZ> how the hell this happened http://paste.pocoo.org/show/498354/
[09:07] <mgz> I picked something other than the stats module for a reason when I studied maths...
[09:08] <ccxCZ> seems to work with --no-plugins, hope newer dulwich will fix this
[09:08] <mgz> ccxCZ: ah. that looks like the latest bzr-git not liking bzr 2.4, checking
[09:13] <ccxCZ> humm, didn't help one bit http://paste.pocoo.org/show/498360/
[09:15] <mgz> sec, I'll try and repo here with your versions. you're on the very latest bzr-git and dulwich now, and bzr 2.4.1 right?
[09:15] <vila> mgz: so, it eems I was wrong about categorise-failures adding spurious jobs. What I think is happening is that add-import-jobs is the culprit. It queues imports that *may* be needed by looking at the last know publication and subtracting 10 minutes for safety. So what we probably observe are imports that already succeeded but are still retried for safety, pfew.
[09:17] <mgz> vila: that sounds hopeful
[09:18] <vila> mgz: the 10 minutes interval may be wrong (probably more like at least one hour based on my observations), but overall this scenario makes sense: the usual suspects vary in time and new ones keep appearing
[09:18] <vila> like the one surprising us yesterday paraview or something ?
[09:19] <Pegasus_RPG> Hello. How can I effect a 'bzr launchpad-logout' command and bind the branch back to the anonymous http variant?
[09:20] <ccxCZ> mgz: yup, I got the bzr-git off launchpad and dulwich off jelmer's samba.org repo
[09:23] <Pegasus_RPG> nvm, I found %appdata%\Bazaar and deleted authentication.conf and bazaar.conf. That seems to have done the trick since I can now bzr bind http://blah.
[09:23] <mgz> right, all you need to delete is the launchpad_username in bazaar.conf
[09:24] <mgz> rather than the whole thing (for future reference)
[09:24] <vila> or comment it out
[09:25] <vila> mgz: so, for the record,  right now, voms and asmix are recurring
[09:25] <vila> there may be others but let's lazily monitor these ones ;)
[09:26] <ccxCZ> vila: btw where was your gentoo cheatsheet? I had few comments on it
[09:27] <mgz> wooo
[09:27] <mgz> bzr: ERROR: Connection error: while sending GET /bzr/jelmer/dulwich/.bzr/repository/packs/b67bf1ab2764bc006a2178d144dbd819.pack: [Errno 8] _ssl.c:499: EOF occurred in violation of protocol
[09:27] <mgz> never seen that before
[09:27] <vila> mgz: reproducible ?
[09:27] <mgz> doesn't look like I get ccxCZ's bug though
[09:27] <mgz> vila: trying again
[09:28] <vila> ccxCZ: http://paste.ubuntu.com/719529/ ?
[09:28] <mgz> vila: nope, worked second time
[09:28] <vila> mgz: which server ?
[09:29] <mgz> samba.org
[09:30] <vila> no idea then
[09:30] <vila> net glitch ?
[09:31] <mgz> possible, I might file just so it's recorded
[09:31] <mgz> ccxCZ: so, python2.7, bzr 2.4.1, dulwich trunk, bzr-git trunk works for me
[09:32] <ccxCZ> mgz: doing the eadd on git repo?
[09:33] <mgz> no, but doing a branch over git, which is your first traceback
[09:34] <mgz> and comes from the same line in bzr-git for you.
[09:42] <ccxCZ> if by first traceback you mean this: http://paste.pocoo.org/show/498354/ then that's doing bzr branch it mistakes for git.
[09:43] <ccxCZ> maybe I should disable irrelevant plugins to test it
[09:44] <ccxCZ> is there way to blacklist/whitelist plugins without uninstalling them?
[09:45] <mgz> `bzr help env-variables|grep PLUGINS`
[09:45] <vila> `bzr help env-variables|grep PLUGIN` unfortunately one of them has no S
[09:46] <mgz> ^that exact command works for me though, using bzr-git to branch the repo
[09:47] <mgz> looking at the code, I'm a little mystified as to how this inheritance is working, it *looks* wrong for GitRepository to pass None to super()__init__
[09:47] <ccxCZ> whitespace delimited?
[09:48] <mgz> but apparently doesn't break things for me
[09:49] <mgz> ccxCZ: colon
[09:51] <ccxCZ> hmm, it still lists them in the backtrace
[09:53] <ccxCZ> okay, I typoed, seems to branch now, so it's not bzr-git's fault
[09:55] <mgz> can you binary it down to one plugin at fault?
[09:55] <mgz> the builtin ones should all be okay as they didn't mess things up for me
[09:58] <ccxCZ> probably some ages old forgotten plugin in my homedir
[10:07] <ccxCZ> seems the bzr-svn is doing it (and that should be fairly recent version afaik)
[10:11] <mgz> ccxCZ: yeah, you've got the latest version apart from the release from last night
[10:12] <mgz> ccxCZ: I'd suggest filing a bug against bzr-git, with your traceback, and highlight the versions of which plugins are needed to trigger it
[10:12] <mgz> ccxCZ: I'm guessing just `bzr info` in a git branch is enough to trigger it?
[10:13] <mgz> if so, post that traceback
[10:15] <ccxCZ> this happens with the latest bzr-svn http://paste.pocoo.org/show/498377/
[10:15] <ccxCZ> there was no git branch involved, it was remote bzr branch (https) somehow mistaken for git branch
[10:16] <ccxCZ> jelmer's public bzr branch of dulwich to be precise
[10:16] <mgz> fileabug.
[10:16] <ccxCZ> kay
[10:19] <ccxCZ> this is bzr-svn bug definitely though
[10:21] <mgz> it seems like it, and maybe a fixed one
[10:21] <mgz> but I don't see any likely looking existing bugs
[10:22] <mgz> and given the info we've got already, pasting it all in and getting duped against something is probably still a good thing
[10:23] <ccxCZ> yup, I'll paste behaviour of all combinations
[10:24] <ccxCZ> let me try on different server with and without https first
[10:30] <ccxCZ> okay it's definitely https that triggers this, writing a bug
[10:38] <ccxCZ> seems it's already reported: https://bugs.launchpad.net/bzr-svn/+bug/774571
[10:38] <ubot5> Ubuntu bug 774571 in bzr-svn (Ubuntu) "bzr-svn: svn plugin seems to mess with read-only basic https connection" [Medium,Triaged]
[11:51] <mgz> hm, what's the best way of merging in an older branch that doesn't really apply any more?
[11:51] <mgz> I could cherrypick individual changes, or merge the whole thing and resolve out/revert parts
[11:51] <mgz> or some other cunning scheme?
[11:58] <fullermd> What does "doesn't really apply any more" mean?  As in "things have diverged enough that merge is a mess", or as in "some of these changes are OBE and should be dropped"?
[11:59] <mgz> the latter really.
[12:00] <fullermd> Ah.  I don't have any excessively brilliant suggestions there.
[12:00] <mgz> but it's different enough that merging then reverting individual bits doesn't makea great deal of sense probbly
[12:00] <fullermd> You have the obvious additive and subtractive options.
[12:01] <fullermd> Either making a new branch and cherrypicking over the pieces to keep, or adding on to the end of the existing branch reverting the bits you want to dump, and then merging in whichever end result.
[12:01] <mgz> so, I can resolve the initial conflicts in ways that don't actually make sense without also backing out non-conflicting parts
[12:01] <fullermd> (depending on the relative scales of keep-vs-lose, and whether you care about having/not the to-lose bits hiding in the history, etc)
[12:01] <mgz> I guess there's no actual requirement that each revision makes sense with mainline-y operation
[12:03] <mgz> hm. actually thanks fullermd, the second one there is sanest and I hadn't thought of
[12:03] <fullermd> Insofar as the former (massively-divered) applies, I've found the best way of dealing with that is just incremental pullins of trunk.
[12:03] <mgz> reverting in the branch then merging makes way more sense than merging then reverting, which is what I was thinking of
[12:05] <fullermd> Yeah, I always like doing as much prep as possible off to the side before worrying about doing the merge.
[12:53] <ccxCZ> vila: http://codepad.org/nUKU3Qcx my comments start with #
[12:59] <vila> ccxCZ: thanks !
=== zyga is now known as zyga-afk
=== Ursinha-afk is now known as Ursinha
[13:51] <mgz> gra, paramiko upstream being dead is a problem
[13:52] <mgz> and can't work around this one by patching in ubunut as it's win64 issue
[13:53] <mgz> ...I need to stop typing ubuntu like banana, the t always ends up at the end
[14:31] <vila> mgz: bananut ? :-D
[14:36] <mneptok> mgz: try typng "l-i-n-u-x" ;)
=== yofel_ is now known as yofel
[14:37] <vila> mneptok: G-N-U-/-L-i-n-u-x :-D
[14:37] <mgz> linus doesn't distribute a copy of paramiko, I feel.
[14:37] <mgz> nor gnu, for that matter.
[14:38] <mgz> ubunut is quite a good name for a fan club though.
[14:40] <mneptok> or the name for a male endocrinology clinic for characters in early 20th century theatre-of-the-absurd plays.
=== zyga-afk is now known as zyga
[15:14] <vila> bug #880701 half-fixed, yes it makes sense :)
[15:14] <ubot5> Launchpad bug 880701 in Bazaar "ERROR: Tree transform is malformed [('versioning no contents', 'new-3')]" [High,In progress] https://launchpad.net/bugs/880701
[15:15] <mgz> vila: did you do the easy half or the difficult half? :)
[15:15] <vila> dunno yet, but the first half was a royal pain...
[15:19] <vila> ghaaaaaa mgz pleeeeease make 2.4 pass the whole test suite ;_;
[15:20] <vila> testools 0.9.12 compat or something
[15:21] <mgz> okay, I'm looking at that area anywa
[15:21] <mgz> y
[15:22] <mgz> it's just jelmer's hack-around got one little bit wrong
[15:22]  * vila kneels down
[15:22] <mgz> in case I need it later: 5967.1.81..-1
[15:22]  * mgz switches
[15:23] <mgz> okay, recent testtools is the one that passes, going back to...
[15:24] <vila> huh ?
[15:24] <mgz> 0.9.5
[15:24] <vila> I'm at revno 224
[15:27] <mgz> okay, current passes, 0.9.6 passes, r224 fails.
[15:27] <mgz> fixing
[15:28] <vila> by current you mean 230 ?
[15:28] <mgz> I guess I mean whatever I had installed, which I assumed was recent but may have been older
[15:37] <mgz> oh, I see, it's simpler than that, Jelmer's change never landed on 2.4
[15:45]  * vila bangs head
[15:46]  * fullermd cranks up some Slayer.
=== beuno is now known as beuno-lunch
[16:00] <vila> dang, the other half is *not* symmetric :-(
[16:01] <vila> and to make matter worse, it seems to require 2 conflicts, not a single one, which in itself means more pain down the road
[16:23] <mgz> vila: fixed on 2.4, and merged up to dev, will propose both branches
[16:24] <vila> great !
[16:24] <mgz> took a bit of a diversion as this code should be deleted on bzr.dev shortly, but makes sense to merge fix from 2.4 for now
[16:25]  * vila nods
[16:40] <vila> hmpf
[16:40] <vila> when you've tried all reasonable approaches, start looking at the stupid ones
[16:41] <vila> so, I've got the second half fixed but it's so obscure I don't dare proposing it :-/
[16:42] <fullermd> Just make a giant pile of whitespace cleanups, and sneak it in with them.
[16:45] <vila> hehe
[16:47] <vila> the funny thing is that the fix is roughly: don't generate a conflict because the magic will create the right one later
[16:57] <mgz> gra, too easy to mistarget branches in launchpad, especially when juggling several
[16:59] <odin_> is the version (of a package in launchpad) only set in the comment line at the start if the recipe ?  no other way to derive it (say from the git last commit date) ?
[17:01] <odin_> this shell command gives of roughtly the right version number I want to be used: date -u -d $(git log -n1 --pretty="@%ct") "+%Y%m%d%H%M%S"   # "20110930161611"
=== beuno-lunch is now known as beuno
[17:15] <lamont> speaking of recipe builds... I need someone clueful to help me test the new bzr-builder...  any takers in jelmer's absence?
[17:29] <wgz> you're the wrong end of the day for me I'm afraid lamont
[17:30] <wgz> and I've hit a different random failure on pqm...
[17:39] <vila> wgz: which one ?
[17:39] <vila> wgz: and on which branch ?
[17:41] <wgz> bug 882168 which was from <https://code.launchpad.net/~gz/bzr/dev_2.4_integration/+merge/80484>
[17:41] <ubot5> Launchpad bug 882168 in Bazaar "Connection refused on TestTCPServerInAThread test" [Undecided,New] https://launchpad.net/bugs/882168
[17:42] <wgz> doc only change in dev.
[17:43] <vila> wgz: yup, known one, seen occasionally on babune
[17:44] <vila> wgz: not having different tests *exactly* for this one makes it hard to know the root cause
[17:44] <wgz> have we got a bug already? a quick search didn't turn one up.
[17:44] <vila> no
[17:44] <wgz> k.
[17:45] <wgz> vila: oo, you have the merge fix up, looks fun
[17:46] <vila> yeah, read the log scrollback, the second half is... making the test pass ? May be the right way... a bit scary still
[17:46] <vila> but, well, that may just be the tree transform way...
[17:48] <wgz> vila: can you eyeball the merge of my test_selftest change to bzr.dev?
[17:48] <wgz> then I'll send the 2.4 version and that to pqm
[17:48] <vila> I think my hesitations are captured by: I'm happy to not have to review it :)
[17:49] <wgz> ehehe
[17:53] <vila> done, EODing, have fun !
[17:56] <wgz> thanks!
=== zyga is now known as zyga-afk
[20:05] <jimis> hello all, is it possible to annotate from one revision until today?
[20:05] <jimis> I've tried --revision=REVNO but I think it annotates up to that revision, any ideas?
[20:06] <fullermd> You mean to just attribute any earlier lines to $REV1?
[20:06] <fullermd> I don't think so...
[20:06] <fullermd> Not via the UI at least.
[20:08] <wgz> it's probably worth a bug report jimis, against bzr and qbzr
[20:12] <jimis> fullermd: I mean annotate all more recent lines than REVNO
[20:13] <wgz> he got that. the question is what to do with lines that predate REVNO
[20:13] <fullermd> What would you do with lines that predated it?  Omitting them would be kinda a-POLA...
[20:13]  * wgz wins
[20:13] <jimis> :-)
[20:13] <jimis> POLA?
[20:14]  * fullermd breaks a couple of wgz's fingers to ensure his future victories.
[20:14] <fullermd> Principle Of Least Astonishment.
[20:14] <jimis> :-)
[20:14] <jimis> probably just not annotate at all earlier lines
[20:15] <fullermd> You Expect(tm) annotate to show the whole file.  Or at least a contiguous bit of it.
[20:15] <jimis> yes show it all, but leave blank the sidebar on earlier lines
[20:15] <fullermd> Blank on the sidebar already means "same as previous".
[20:15] <jimis> so you can concentrate on the lines that interest you :-)
[20:15] <jimis> ah ok
[20:16] <wgz> it might be quite easy in qbzr
[20:16] <fullermd> Anyway.  I'm not arguing against it in principle.  A proper-ish UI could be found.
[20:16] <wgz> as that already loads the file content then fills in the revision info and colours
[20:16] <fullermd> Would just take someone doing it.
[20:16] <jimis> I always use cmdline ui
[20:16] <fullermd> The Obvious(tm) invocation would be "bzr annotate -rX..Y $FILE"
[20:17] <jimis> right :-)
[20:18] <jimis> hmmm I think I found a relevant bug #700878
[20:18] <ubot5> Launchpad bug 700878 in Bazaar "bzr blame: annotate --revision takes exactly one revision identifier; ideally any arbitary range should work" [Wishlist,Confirmed] https://launchpad.net/bugs/700878
[20:20] <wgz> that looks likely, +affectsmetoo it
=== zyga-afk is now known as zyga
[21:37] <jimis> anyway thanks guys, hopefully someone will look into it :-)
[22:18] <poolie> hi all
[22:22] <Noldorin_> hi poolie
[22:22] <poolie> hey there
[22:22] <Noldorin_> :-)
[22:22] <Noldorin_> hmm, funny timing.
[22:23] <Noldorin_> seems i'm having trouble with pulling from LP with 2.5b2:
[22:23] <Noldorin_> bzr: ERROR: Unable to connect to target of bound branch BzrBranch7(file:///C:/Users/Alex/Documents/V
[22:23] <Noldorin_> isual%20Studio%202010/Projects/IrcDotNet/0.4/) => bzr+ssh://bazaar.launchpad.net/~noldorin/ircdotnet
[22:24]  * poolie tries
[22:24] <Noldorin_> just a standard bzr pull lp:ircdotnet/0.4
[22:27] <poolie> seems to work for me
[22:28] <poolie> do you get a traceback in ~/.bzr.log
[22:42] <poolie> Bazaar version control <http://bazaar.canonical.com> | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: mgz
[22:42] <Noldorin_> poolie, http://pastebin.com/qtgm59ny
[22:43] <poolie> does 'bzr info bzr+ssh://bazaar.launchpad.net/~noldorin/ircdotnet/0.4/' work?
[22:44] <spiv> Noldorin_: lp:ircdotnet/0.4 is ~ircdotnet-dev/ircdotnet/0.4, not ~noldorin/...
[22:45] <spiv> Noldorin_: so I'd guess the problem is the remote branch has moved rather than your bzr version.
[22:45] <Noldorin_> spiv, poolie ah darn. i changed the branch owner after binding it locally... my bad, sorry!
[22:45] <Noldorin_> spiv, thanks for that
[22:45] <spiv> Noldorin_: you're welcome!
[22:57] <poolie> hi spiv
[22:59] <poolie> biab