=== jordan_ is now known as jordan
[00:54] <JPeterson> the tortoisebzr diff window is really something else
[00:55] <JPeterson> how do i revert rows in it? lol
[00:57] <JPeterson> I've never seen anything so stupid. how do i revert parts of a file?
[00:58] <AuroraBorealis> reverse rows?
[01:02] <JPeterson> i can't do any edits in the diff window ROFL
[01:02] <JPeterson> holy mother of god
[01:05] <AuroraBorealis> i dont use tortoisebzr i just use qbzr
[01:30] <spiv> JPeterson: if you want to revert parts of a file, you might find 'bzr shelve FILE' to be more helpful.  (Not sure if there's a GUI for that?)
[01:32] <JPeterson> spiv: ok. thx.
[05:33] <Wellark> hi! I'm having problem with pipeline plugin. I'm using the latest revision from bzr-pipeline trunk, but now I started to get these messages: "bzr 2.6.0dev1 is too new for pipeline 1.1.0"
[05:36] <fullermd> Probably hasn't been updated for the new version of bzr.dev.
[05:37] <Wellark> has there been any discussion on fixing it?
[05:38] <fullermd> There's probably nothing broken, strictly speaking.  It just doesn't know that it can work with 2.6.
[05:38] <fullermd> You could just find the version check and bypass it, and see if anything breaks.
[05:38] <Wellark> :)
[05:39] <Wellark> the __init__.py does the check and it defines maximum_bzrlib_version = (2, 4)
[05:39] <Wellark> any API breakage between 2.4 and 2.6?
[05:39] <fullermd> Probably.  An API that pipeline uses?  I have no idea.
[05:40] <Wellark> I mean in bzrlib
[05:40] <fullermd> But if it worked with bzr.dev when it was called 2.5 a couple weeks ago, it probably still works with it calling itself 2.6 now.
[05:40] <Wellark> I'm not familiar with bzrlib API policies
[05:41] <fullermd> Well, I'm not really familiar with the API's, and even less with pipeline.
[05:42] <fullermd> If you smoosh the two of us together in a steam press, we could own this joint   ;)
[05:43] <fullermd> Things are likely to get broken across major releases.  But whether that has any impact on a particular plugin is a wide open question.
[05:44] <fullermd> If pipeline actually works with 2.5 (or bzr.dev just before 2.5 branched), it probably works equally well with bzr.dev-called-2.6 now.  I'd _guess_ the major premise is supportable, but I don't know.
[05:44] <spiv> Wellark: many plugins are very conservative about API versions.  They prefer to break up front if they haven't been tested against that version rather than risk some strange breakage while being used.
[05:45] <spiv> Wellark: even though most of the time no change to the plugin is needed (other than relaxing the version check)
[05:45] <Wellark> fullermd, spiv: OK, thanks. I'll upgrade the test and see what happens.
[05:46] <Wellark> and also file a bug against bzr-pipeline as it seems nobody has done so
[06:00] <stewart> have lightweight checkouts improved over $years ago? i.e. do they actually suck down less data and are faster than pulling full (big) repo?
[06:04] <spiv> I think perhaps jelmer and jam have done a bit of work on that lately.
[06:04] <spiv> I have a partially completed branch (that jelmer is continuing) to make "bzr branch --stacked" a good answer for that case, though.
[06:05] <spiv> (i.e. to make it reasonably efficient w.r.t. how much data it sucks down, at least when using a smart server.)
[06:06] <spiv> (it's about the same amount of data as a lightweight checkout -- all the full texts of the current revision's tree, but actually kept in a local stacked repo so you can still have speedy local diff etc. without necessarily hitting the network for almost every subsequent operation)
[07:45] <poolie> hi vila, and good night
[07:45] <vila> hey poolie et al.,
[07:46] <vila> poolie: g;night
[08:27] <Merwin> hi
[08:27] <vila> Merwin: hi
[08:28] <Merwin> Hey vila :-)
[08:28] <Merwin> What web interface would you recommend for end-users not very familiar with bazaar ? I'm looking for something simple which will help them understand
[08:30] <vila> hmm, loggerhead is the most advanced one I know of, but qlog used locally is IMHO the best way to understand branch history or even branches histories (you can use 'bzr qlog trunk feature1 feature2' to visualize how branches are related)
[09:26] <mgz> morning
[09:27] <vila> morning mgz
[09:28] <mgz> ha, bug 924727
[09:28] <ubot5`> Launchpad bug 924727 in Bazaar "bzr pull does not remember urllib links" [Undecided,New] https://launchpad.net/bugs/924727
[09:28] <mgz> that workaround for self signed cert won't be good much longer
[09:34] <vila> mgz: one word: rabbit hole
[09:35] <vila> mgz: are you already replying or should I ?
[09:35] <mgz> you go ahead
[09:36] <mgz> the good part is that they'll just be able set a conf value with 2.5
[09:39] <vila> ok
[09:43] <vila> yeah, unless he still want his certificates to be verified in which case things will be a bit harder to use until we fix bug #923220
[09:43] <ubot5`> Launchpad bug 923220 in update-manager (Ubuntu Precise) "update from oneiric to precise blocked on skype:i386 says updater" [High,Triaged] https://launchpad.net/bugs/923220
[09:43] <vila> grrr
[09:43] <vila> bug #924220
[09:43] <ubot5`> Launchpad bug 924220 in Bazaar "ssl.ca_certs should be supported in authentication.conf" [Medium,Confirmed] https://launchpad.net/bugs/924220
=== yofel_ is now known as yofel
[13:36] <Merwin__> bug #1
[13:36] <ubot5`> Launchpad bug 1 in Ubuntu "Microsoft has a majority market share" [Critical,In progress] https://launchpad.net/bugs/1
[15:23] <mgz> what the b- config? <http://pastebin.ubuntu.com/825188/>
[15:23] <mgz> ^any ideas vila?
[15:24]  * mgz downgrades from 2.5b5 to something b4 for now
[15:25] <vila> O_o I used feed-pqm no later than... this morning ?
[15:25] <vila> and my copy is in sync with lp:hydrazine
[15:28] <vila> mgz: try *upgrading* hydrazine ?
[15:29] <vila> mgz: there is a bzrlib_version < (2, 5) to select the right config (and you run 2.5b5 not trunk ?)
[15:31] <mgz> ah yes, missing r102 from hydrazine
[15:52] <abadger1999> I know we've had discussions about supported timeframes for various things like python-2.4 in the past so I'm going to post this for people to know that things have changed for one of the distros I package for.
[15:52] <abadger1999> Just an FYI, for future discussions
[15:52] <abadger1999> http://www.redhat.com/about/news/press-archive/2012/1/red-hat-enterprise-linux-stability-drives-demand-for-more-flexibility-in-long-term-operating-system-deployments
[15:52] <abadger1999> The RHEL5+ lifecycle has been expanded to 10 years.
[15:53] <mgz> yup, that's been pretty widely linky-ed.
[15:53] <abadger1999> k
[15:54]  * abadger1999 now looking at supporting stuff on python-2.4 until March 31, 2017
[15:56] <mgz> that doesn't feel to bad, unless you're also being bugged to move things to Python 3 at the same time.
[15:57] <mgz> we've yet to make any significant use of post-2.4 features
[15:57] <mgz> various sugar like with and str.format are getting scatterred around but it's not code that couldn't be written the old way
[15:59] <abadger1999> <nod>
[16:01] <abadger1999> I'm liking the idea of plugins for old versions if new repository formats are made too.... less work for me to package a plugin than to backport fixes/patch out post-py2.4 code in order to get a new format.
[16:20]  * SamB wonders what Ubuntu is going to do when they pass z
[16:22] <mgedmin> wrap around to a, probably
[16:22] <mgedmin> maybe a double a
[16:22] <mgedmin> aawful aardvark?
[16:22] <mgedmin> that's what speadsheets use after z, after all
[16:30] <mgz> only gets you one more animal.
[16:30] <mgz> debian has a more pressing naming problem.
[16:32] <mgz> they've already run through all the toy story characters anyone knows about.
[16:54] <mneptok> dude, Barbie.
[16:55] <mneptok> i *started* using Debian only in hopes that one day i could say, "I'm a Barbie user," without having to buy those horrid dolls.
[16:57] <SamB> mgedmin: yes, but ~aawfull doesn't compare after ~zany
[16:58] <mgedmin> hmm
[16:58] <SamB> as for Debian, they will presumably have to switch naming schemes at some point, yes, but at least this won't be a *technical* problem
[16:59] <SamB> (assuming they leave sid as-is)
[16:59] <mneptok> hmmm ... Mattel should make a "Debian Barbie"
[16:59] <SamB> they should include a USB stick with a net installer
[17:00] <SamB> (A copy of Debian testing?)
[17:50] <vila> abadger1999: have you considered having python-2.7 available in addition to 2.4 ?
[17:50] <vila> abadger1999: well, 'you' in the collective sense I mean
[17:53] <abadger1999> vila: In the epel5 world, we do have a python26 package (no python27 atm).
[17:54] <abadger1999> vila: but -- if we moved bzr to that, we'd need to create a parallel stack of all the python26 modules that bzr requires.
[17:54] <vila> abadger1999: epel5 ?
[17:54] <abadger1999> vila: addon packages for RHEL5 and rhel5 clones.
[17:54] <vila> thanks
[17:55] <vila> yeah, you need to find the right balance
[17:56] <abadger1999> <nod> definitely.
[17:58] <vila> I think the most important ones are cython|pyrex, python-paramiko and python-configobj, akk the others are for testing
[17:58] <vila> well python-pycurl is still needed probably but not for too long hopefully
[18:00] <mgz> right, break for an hour, just need to remember to come back and listen in on Barry's chat
[18:01] <abadger1999> yeah... I'm very hesitant to just build bzr without invoking the test suite, though ;-)
[18:07]  * SamB thinks it would be a lot better if bzr would branch 0 or 1 revision initially, and actually make a branch, before pulling anything else into the repository
[18:08] <SamB> (In terms of what happens when a "bzr branch" command gets interrupted.)
[18:48]  * SamB wonders how stupid it would be to replace bzr's native repository format with a variant of git's
[18:48] <LeoNerd> IIRC, formats are largely invisible to the user.
[18:49] <LeoNerd> That's one main philosophy difference between bzr and git.
[18:49] <SamB> I'm just wondering if it would be good for efficiency
[18:49] <LeoNerd> bzr holds the tool UI canonical, and re-invents the data format underneath it to better help the user
[18:49] <LeoNerd> git holds the data format canonical, and re-invents the tool UI to better help the user
[18:50] <jelmer> SamB: are you still hitting performance issues with 2.5 ?
[18:51] <jelmer> (FWIW, bzr supports git's repository format through bzr-git but because the latter uses dulwich it's significantly slower than native git)
[18:52] <LeoNerd> I've never been able to make bzr-git work without running out of "disk" space in /tmp
[18:52] <LeoNerd> ((I use tmpfs))
[18:53] <SamB> jelmer: I'm not sure if it's as bad as it was, but it's taking forever to pull lp:launchpad ...
[18:55] <jelmer> LeoNerd: that's odd, since it shouldn't really be storing anything in /tmp other than the pack file it receives from the remote git server
[18:55] <jelmer> SamB: Launchpad is large :)
[18:55] <SamB> jelmer: and I was thinking something along the lines of: use git's 'object store' format(s), and probably the existing 'blob' format
[18:56] <SamB> but make up new object types to represent the other bzr concepts
[18:56] <SamB> (how many other concepts are there?)
[18:56] <SamB> (in a repository, I mean)
[18:56] <jelmer> SamB: bzr and git pack files aren't too different, I don't think remaining performance issues are related to the formats
[18:56] <SamB> hmm
[18:57] <jelmer> it would be interesting to further optimise pack fetching over HPSS, but I doubt that that requires format changes
=== SamB_ is now known as SamB
[19:00] <SamB> did you say anything between "bzr and git pack files aren't too different" and when I got back on?
[19:01] <jelmer> SamDB: it would be interesting to further optimise pack fetching over HPSS, but I don't that that requires changes as introdusive as format changes.
[19:01] <SamB> yeah, I cought that after I returned
[19:20]  * SamB wonders if putting transient stuff on disk instead of keeping it in memory wouldn't help
[19:21] <SamB> (Well, sometimes, anyway.)
[19:30] <abentley> vila: AFACT "diff --summarize" is not a real thing, and was not real at the time this was submitted:  https://code.launchpad.net/~jbowtie/bzr/doc-bzr-st-historical-532600/+merge/35950
[19:46] <SamB> abentley: maybe "--stat"?
[19:47] <abentley> SamB: bzr: ERROR: no such option: --stat
[19:47] <SamB> oh
[19:47]  * SamB misread a "git" into there somehow
[21:06] <milki> eh, its a jelmer
[21:07] <jelmer> hey milki
[21:07] <milki> you arent in #dulwich o.O
[21:07] <jelmer> whoops
[21:14] <michaelh1> I'm using bzrlib on a long-running task.  How can I turn on some type of debug/progress to show that it's ticking along?
[21:14] <michaelh1> (this is a throw-away script.  My Google-foo fails me)
[21:15] <jelmer> hi michaelh1
[21:16] <michaelh1> Hey
[21:16] <jelmer> michaelh1: the simplest thing to do would be to create a progress bar
[21:16] <jelmer> michaelh1: are you calling bzrlib.initialize() ?
[21:17] <michaelh1> jelmer: no
[21:17] <jelmer> michaelh1: if you do so, it should install the standard termninal UI for you I think
[21:18] <michaelh1> OK.  Added, it's still silent, how can I turn on the progress bar?
[21:23] <fullermd> Kl
[21:23]  * fullermd mutters.
[21:24] <jelmer> michaelh1: that should do it, when there's stuff to display
[21:25] <jelmer> michaelh1: if you're using the Launchpad API as well, that doesn't use bzrlib
[21:25] <jelmer> oops, nevermind
[21:25]  * SamB wonders what in the world all these huge "Repository.get_parent_map" HPSS calls are for
[21:25]  * jelmer is confused by talking with Michael Hope and Michael Hall at the same time
[21:26] <jelmer> SamB: browsing the revision graph
[21:26] <SamB> jelmer: why does *my* bzr need to browse the *remote* graph?
[21:26] <jelmer> SamB: it depends on what you're doing
[21:26] <SamB> shouldn't it leave that to the remote?
[21:27] <jelmer> SamB: if you're running "bzr log lp:bzr" then it would look at the remote revision graph to find out what to display
[21:27] <michaelh1> jelmer: hmm.  the backtrace shows that it's in search_missing_revision_ids.  This is GCC so that may take some time and there might be no progress.
[21:27] <SamB> hmm
[21:27] <SamB> well, I wasn't
[21:27] <SamB> I'm just pulling
[21:27] <michaelh1> CPU usage is zero so it might be round tripping.  I'll update bzr from 2.3.4 and try again.
[21:29] <jelmer> SamB: in that case it's finding out which revisions it needs to fetch
[21:29] <SamB> there's got to be a better way to do that
[21:29] <jelmer> SamB: Git does the same thing (the "want " / "have " bits)
[21:29] <jelmer> SamB: for some cases, yes, definitely
[21:29] <michaelh1> Is there a PPA with 2.5b5 in it?
[21:30] <jelmer> SamB: if you're a couple of revisions behind on what you're pulling from, or creating an initial clone then it's fine
[21:30] <michaelh1> Ah, found it
[21:30] <SamB> jelmer: assuming you don't run out of RAM and have to interrupt bzr mid-way
[21:31] <jelmer> SamB: in that case you wouldn't end up with any data anyway I think
[21:31] <SamB> why would you think that ?
[21:31] <michaelh1> Ah, much better with 2.5b5
[21:34] <jelmer> SamB: it streams to a temporary pack file, which I think gets removed if you abort it.
[22:38]  * SamB thinks the smart protocol would be easier to understand if it weren't based on RPC ...
[22:40] <jelmer> SamB: hmm?
[22:40] <SamB> maybe not
[22:40] <jelmer> SamB: RPC is a fairly generic term, not a protocol
[22:41] <SamB> I guess what would really help was if there was some kind of ... spec
[22:42] <jelmer> SamB: see doc/developers/network-protocol.txt IIRC
[22:43] <jelmer> not great, but more than nothing :)
[22:43] <SamB> yes, it is more than nothing
[22:49] <jelmer> SamB: good places to start in the code are bzrlib/remote.py (all client-side callers are here) and bzrlib/smart/, in particular bzrlib/smart/request.py
[22:50] <SamB> yeah, I was already looking at bzrlib/remote
[22:50] <SamB> it's aptly named
[22:50] <jelmer> :)
[22:51] <SamB> this thing that you did not actually call a spec does also at least refer to relevant modules
[22:54] <fullermd> It's a speck of a spec   8-}
[22:54] <SamB> I guess you'd call it a "stub"
[22:55] <SamB> well, if you were a wikipedian, anyway
[22:56] <SamB>   Code not geared to do pipelined requests, and this might require doing
[22:56] <SamB>   asynchrony within bzrlib.  We might want to either go fully pipelined
[22:56] <SamB>   and asynchronous, but there might be a profitable middle ground.
[22:56] <SamB> there seem to be some words missing here ...
[22:56] <fullermd> It was written during the Great Verb Drought of 2009.  They were strictly rationed, and as a free software project, we can't afford to splurge on non-essentials.
[22:57] <SamB> ... right ...
[22:57] <jelmer> SamB: s/Code/The code is /
[22:57] <SamB> what about the whole idea that's missing in the second sentance?
[22:58] <SamB> or is that just an "and" that should be "or"?
[22:58] <fullermd> It's probably more like an extra word than a missing one.
[22:58] <fullermd> I think it calls for an either-ectomy.
[22:58] <SamB> ah
[23:00] <SamB> what does "tw=74" mean, exactly?
[23:00] <fullermd> vim modeline
[23:02] <SamB> is that the same as `fill-column' in emacs, do you think?
[23:02] <jelmer> yep, "textwidth" - it indicates the number of colums in a text document
[23:05] <SamB> good, good
[23:06]  * SamB has started editing and wanted to make sure to follow the local conventions
[23:12] <SamB> git does something fairly simple here: the client sends "have" messages in batches of 32, but sends an "extra" block to start with so there's always one in flight...
[23:14] <jelmer> SamB: git has a completely different approach here - it only supports receiving a pack and sending a pack
[23:14] <SamB> well why not?
[23:14] <jelmer> bzr supports all operations remotely; the initial calls that were added were for low-level operations, and over time more high-level operations have been added (for performance reasons)
[23:14] <SamB> it's not that hard to make a pack
[23:15] <jelmer> SamB: git doesn't allow you to inspect a remote repository in any way; "git log git://foo.com/bar" doesn't work
[23:15] <SamB> well, true
[23:15] <jelmer> SamB: the streams sent by bzr over HPSS are packs
[23:15] <SamB> though nowadays the protocol doesn't actually prevent that
[23:17] <SamB> (I mean, with the "shallow" stuff, it wouldn't really be all that tricky to do git logging remotely.)
[23:19] <jelmer> SamB: does that allow you to retrieve just commit objects? I thought you would get the commit contents with it as well?
[23:19] <jelmer> SamB: and it requires you to create a new connection for each request that you do
[23:19] <SamB> jelmer: oh, maybe
[23:20]  * jelmer actually has more experience with the Git protocol than with the bzr protocol
[23:20] <SamB> but that seems unlikely to make things much worse
[23:20] <SamB> you'd just have to throw them away, right?
[23:21] <SamB> ... unless there might be deltified commits based on blobs or trees?
[23:22] <jelmer> SamB: yes, but you'd have to do the negotiation each time you connect, and there could be a lot of data you throw out.
[23:22] <jelmer> SamB: bzr does that bit really quickly these days (not against launchpad, but against a modern bzr server)
[23:22] <SamB> oh, right, launchpad is probably running something old, true
[23:23] <jelmer> but I think we're getting distracted from the discussion about optimizing fetch :)
[23:23] <SamB> yeah, a bit
[23:23] <jelmer> SamB: so basically there is a generic call for retrieving objects in the HPSS
[23:24] <jelmer> SamB: Repository.insert_stream and Repository.get_stream allow you to send and receive streamed packs of objects like texts, chkbytes (inventories), revisions and signatures
[23:24] <jelmer> SamB: Repository.get_stream receives some sort of search result which indicates the kind of objects that the client wants to receive
[23:25] <jelmer> s/result//
[23:25] <jelmer> SamB: (bzrlib/vf_search.py for some of the search types)
[23:29] <jelmer> the searches do support things like "give me the data for revision X1..Xn but exclude everything that is an ancestor of Y1..Yn"
[23:29] <SamB> ... it would also be nice if it didn't use so much memory during the streaming phase, hmm ...
[23:30] <jelmer> SamB: I'm not sure why it would be using so much memory, my guess is that it could just stream directly to the pack file, but I'm not sure what's happening in practice. Perhaps a bug ?
[23:31] <SamB> bug, missing feature, who knows?
[23:34] <lifeless> jelmer: SamB: we're running 2.5b3
[23:34] <lifeless> this isn't really 'old'
[23:34] <SamB> okay
[23:34] <lifeless> maybe not 'newest', but not like we're running 1.8 or something :->
[23:35] <SamB> I was thinking more 2.3 or 2.4
[23:35] <SamB> well, after jelmer gave me the idea that it might not be the latest
[23:35] <jelmer> lifeless: it predates the collection of HPSS improvements we landed in 2.5
[23:36] <jelmer> lifeless: it's not really old, but landing 2.5b5 will have a significant impact for some operations
[23:36] <lifeless> cool
[23:37] <SamB> does it somehow return better answers for Repository.get_parent_map ?
[23:37] <jelmer> SamB: nope, it's doesn't help in that regard
[23:38] <jelmer> SamB: If I understand things correctly, "bzr pull" shouldn't be calling Repository.get_parent_map too often in your case anyway
[23:38] <jelmer> SamB: if it's trying to figure out the revno of a revision by browsing branch history then those improvements will help
[23:38] <SamB> well, it seems to do a lot of those at the beginning of the pull
[23:39] <jelmer> SamB: can you see why?
[23:39] <SamB> well, lets see ...
[23:39] <jelmer> SamB: Ctrl+\ should land you in a python debugger
[23:40] <SamB> 8.069  hpss call:   'Branch.last_revision_info', '+branch/launchpad/'
[23:40] <SamB> 8.069               (to bzr+ssh://bazaar.launchpad.net/+branch/launchpad/)
[23:40] <SamB> 8.169     result:   ('ok', '14742', 'launchpad@pqm.canonical.com-20120201203052-676sbmji00bd2h57')
[23:40] <SamB> then a bit later
[23:40] <SamB> 8.300  hpss call w/body: 'Repository.get_parent_map', '+branch/launchpad/', 'include-missing:', 'launchpad@pqm.canonical.com-20120201203052-676sbmji00bd2h57' ('\n\n0'...)
[23:40] <SamB> 8.300                3 bytes
[23:40] <SamB> 8.921     result:   ('ok',)
[23:40] <SamB> 9.162                64719 body bytes read
[23:41] <jelmer> SamB: it's more interesting to see what high-level request triggers the HPSS call
[23:41] <jelmer> (and perhaps shouldn't)
[23:41] <spiv> jelmer: hmm.
[23:41] <spiv> jelmer: you know…
[23:42] <spiv> jelmer: It'd be possible to write a -Dhpsswhy flag I reckon
[23:42] <SamB> yes, of course it would
[23:42] <spiv> jelmer: that adds to -Dhpss which method of Branch/Repository/BzrDir triggered it
[23:43] <spiv> jelmer: by horrible stack introspection :)
[23:43] <SamB> (but what if there were more than one involved?)
[23:43] <spiv> List them all.  Shouldn't be more than three most of the time I'd reckon
[23:44] <spiv> It would be a good middle-ground between context-less -Dhpss now and having to manually get full tracebacks with Ctrl-\
[23:45] <spiv> E.g. adding "via: BzrDir.sprout, Branch.sprout, Repository.get_parent_map" or whatever
[23:46] <jelmer> spiv: hmm, that'd indeed be nice :)
[23:48] <SamB> is there some way to get more ordinarily-formatted traceback in pdb?
[23:50] <spiv> SamB: I guess you can just use "import traceback; traceback.print_stack()"
[23:51] <SamB> hehe
[23:51] <SamB> that shows me a lot of pbd's own stack frames
[23:55] <spiv> I guess it would :)
[23:59] <SamB> http://paste.debian.net/154425/