[00:03] <spiv> SamB: well, even if the release is 2.0, I'm happy for the verb to be 1.19.
[00:04] <spiv> I don't want the name of the verb to actually mislead, though :)
[00:04] <SamB> spiv: that's what I'm saying. there's no sense in bumping it from a nonexistant release ;-)
[00:04] <SamB> indeed
[00:04] <spiv> (And I'm happy to pay the fairly minimal cost to bump it when it misses the intended release.)
[00:05] <SamB> you don't want it named for a release before/after the one it debuts in ;-)
[00:06]  * SamB finds 2a pretty slow for just about anything involving conversion at the moment, actually ...
[00:07] <SamB> ... though it's extremely pathetic for it to be using more downstream than upstream during a push, which I assume your branch eliminates
[00:07] <SamB> hard for me to test this, though :-(
[00:26] <lifeless> SamB: over the network conversions?
[00:37] <SamB> lifeless: any!
[00:37] <SamB> over network, local ...
[00:37] <SamB> if the 2a repository isn't local, that makes it worse, certainly
[00:45] <lifeless> local should be ok
[00:46] <poolie> hullo again lifeless
[00:46] <poolie> did i see you were working on bug 375013?
[00:47] <igc> morning
[00:49] <AfC> Classic. Write a long reply to a bzr mailing list thread, only to realize in the end that if I'm going to pontificate like this, I'd better do it in a blog post instead. Bother.
[00:49] <AfC> "Save Draft" think about again later
[00:53] <poolie> which thread, just for curiousity?
[00:54] <AfC> poolie: GPL licencing
[00:54] <AfC> poolie: nothing to do with bzr
[00:55] <AfC> I just liked John's "moral" comment and wanted to add something
[00:55] <AfC> [battery, back in 60]
[01:12] <poolie> jam, i think explaining the gpl is good but it's not appropriate to be so flippant in the context of a business inquiry
[01:14] <lifeless> poolie: yes
[01:14] <poolie> yes you agree?
[01:14] <lifeless> poolie: I'm thinking of just untagging it from 2.0
[01:14] <poolie> oh ok
[01:14] <lifeless> poolie: [bug 375013?]
[01:14] <poolie> right
[01:15] <lifeless> I heavyweight checkouts will work as they push via streams
[01:15] <lifeless> lightweight checkouts over the network are a bad idea anyway
[01:16] <poolie> at least as they currently exist
[01:16] <lifeless> lightweight checkouts of stacked branches would seem to be a rare case at the best of times
[01:16] <lifeless> well, indeed.
[01:16] <poolie> i think we should make them work in future
[01:16] <poolie> it's a reasonable thing to want
[01:16] <lifeless> fixing commit to use streams would make them suck less hard
[01:16] <lifeless> sure
[01:16] <poolie> it may require tweaking the definitions a bit
[01:16] <lifeless> at the moment, working content local, all history remote, performs badly
[01:17] <lifeless> so even with the bug fixed, its not a recommended way to deploy/use bzr today.
[01:17] <lifeless> which is why I'm thinking of downgrading it to high, or even leaving it critical but untargeting from 2.0.
[01:17] <lifeless> what do you think?
[01:18] <poolie> i think it might be right
[01:18] <lifeless> [and it's not 2a specific, it fails with 1.9 if you have content in the tree]
[01:25] <poolie> would it be possible to detect the problem cases and just fail cleanly?
[01:25] <poolie> eg to ban committing in lightweight checkouts of a remote repository?
[01:25] <poolie> or remote stacked repository
[01:26] <lifeless> remote isn't part of the equation
[01:26] <lifeless> we could put a check in commit.py to say if self.branch.repository._fallback_repositories: bail()
[01:27] <poolie> in general i'm more comfortable downgrading a bug if it causes a traceback rather than a problem in what's recorded
[01:27] <lifeless> yah
[01:28] <poolie> want to add that check, including a mention of the bug number near it, and then downgrade/untarget?
[01:28] <poolie> emmajane: hi, still around?
[01:28] <emmajane> ping
[01:29] <emmajane> just eating a cow. or myabe it's a steer. definitely it's beef though.
[01:31] <lifeless> poolie: yes
[01:59] <poolie> jam, are you back at all?
[02:03] <jam> poolie: I'm mostly just heading upstairs, I may be back in another hour or so
[02:03] <poolie> np
[02:03] <poolie> i was just thinking about your mail about 2.0
[02:03] <jam> poolie: about the release schedule, etc?
[02:03] <jam> I'd be happy to chat with you about that later
[02:04] <poolie> yes, and whether this should be 2.0b1
[02:04] <poolie> ok
[02:04] <poolie> just ping me
[02:04] <spiv> poolie: ping, mind if I call now?
[02:08] <poolie> sure
[02:11] <emmajane> igc, ping. I'll be up for a little bit and thought I'd check to see if you were around?
[02:17] <igc> hi emmajane
[02:17] <emmajane> hey :)
[02:19] <emmajane> Have you had a chance to play with Sphinx any more?
[02:19] <igc> emmajane: a little
[02:20]  * emmajane nods
[02:21] <igc> emmajane: you have pretty fine control over the title page for example
[02:22] <emmajane> You can apply style sheets to sphinx pages though.
[02:22] <igc> yes
[02:22] <emmajane> I can't remember if you've got the source for what you sent me as a branch?
[02:23] <emmajane> I htink I just remember seeing output?
[02:23] <igc> emmajane: if it helps, have a look at https://launchpad.net/bzr-alldocs
[02:23] <emmajane> thanks :)
[02:23] <igc> emmajane: grab the trunk and see how it hangs together
[02:24] <igc> the interesting files are en/_templates/index.html and en/_templates/layout.html
[02:24] <emmajane> excellent.
[02:24] <igc> emmajane: I'm just building the 1.18rc1 docs as we speak and tweaking that site to reference them
[02:24] <emmajane> awesome :)
[02:25] <emmajane> I love automatic builds of documentation.
[02:25] <emmajane> I recognize that I need better hobbies, but it's right up there with magic tricks and ponies for me.
[02:25] <igc> emmajane: well the alldocs stuff isn't automated *enough* yet but that can come post 2.0
[02:26]  * emmajane nods
[02:26] <igc> emmajane: e.g. still one site per langu rather than something smarter
[02:26]  * emmajane nods
[02:26] <AfC> emmajane: we do automatic (ie, live) _screenshots_ for our documentation. http://java-gnome.sourceforge.net/4.0/doc/api/org/gnome/gtk/TreeView.html :)
[02:26] <emmajane> igc, do you have people working on translations, or is it mostly beuno jsut working on one language?
[02:27] <emmajane> \o/ Sovereigns of Canada. :)
[02:27] <igc> emmajane: no, several people working on different languages
[02:27] <emmajane> igc, cool
[02:27] <igc> emmajane: the alldocs website has been translated to French, Japanese and Russian
[02:28] <emmajane> very nice!
[02:28] <igc> emmajane: and it's messy right now - if it were done via LP translations, I'm sure we'd get many more
[02:28]  * emmajane grumbles. the ubuntu package of bzr is old.
[02:29] <emmajane> igc, tough call. Docs are hard to translate. LP doesn't necessarily make it easier (we deal with this for the ubuntu docs team as well)
[02:29] <emmajane> LP is optimized for string translation.
[02:29] <emmajane> the User Guide != strings. :)
[02:29] <igc> poolie: fwiw, the NEWS in bzr.dev has 2 'In development' headings and no 1.18 heading :-(
[02:30] <AfC> lifeless: c.f. our conversation at dinner a few weeks ago, see emmajane's comment above.
[02:30] <igc> emmajane: right, but the wrapper site is really just a few strings. see http://doc.bazaar-vcs.org/en/
[02:30] <AfC> lifeless: and yes, I realize we're working on the problem.
[02:31] <emmajane> igc, you're right. that's not bad.
[02:31] <igc> emmajane: but wrapper site aside, I know at least one person is actively working on translating the bzr docs to Japanese
[02:32]  * emmajane taps her keyboard and tries to decide the most elegant way of upgrading and ignoring ubuntu.
[02:32] <AfC> that's easy. Run Gentoo.
[02:32]  * AfC ducks
[02:32] <emmajane> HAHAHAHA
[02:32] <emmajane> you're HilARIOUS. :)
[02:33] <emmajane> The gentoo cow is the best part about gentoo. :)
[02:33] <igc> emmajane: the cool thing is, I still haven't announced the alldocs project yet so having those translations being contributed already is awesome
[02:33] <emmajane> igc, that is cool!!
[02:33] <lifeless> AfC: which specific comment?
[02:33] <AfC> emmajane: [but that also explains why I still don't run Ubuntu, and is the gist of my quick aside to Robert a moment ago. As I said, the packaging issue is being addressed. I hope it works out, because then maybe I could run a Debian distro again]
[02:34] <AfC> lifeless: "grumbles. the ubuntu package of bzr is old."
[02:34] <emmajane> AfC, APT is made of win.
[02:34] <emmajane> Gentoo is made of pain.
[02:34] <AfC> emmajane: [but this is otherwise off topic for #bzr, and I'm not a distro zealot]
[02:35] <emmajane> lifeless, bzr 1.13.1 on python 2.6.2 (linux2) makes me sad.
[02:35] <lifeless> emmajane: what release?
[02:35] <emmajane> lifeless, jaunty. up to date.
[02:35] <AfC> wow
[02:35] <lifeless> sounds about right
[02:36] <lifeless> it was current when released
[02:37] <lifeless> AfC: old releases of distros stagnating isnt really being worked on; rather we're aiming to have point releases for them, for critical fixes etc
[02:37] <lifeless> so in this case, emmajane might be seeing 1.13.2 at this point.
[02:38] <lifeless> OTOH we already do point releases when we think its important enough, so I'm not all that sure that that will change at all.
[02:38] <emmajane> 2.0 will get packaged though, right?
[02:38] <lifeless> yes
[02:38] <lifeless> but getting it into jaunty is about as hard as getting 1.17 into jaunty
[02:38] <emmajane> I only care because igc's docs are in 2a for which I need 1.16+
[02:38] <lifeless> which is to say, very.
[02:39] <lifeless> emmajane: use the PPA :)
[02:39] <emmajane> lifeless, don't you know people who can do that? ;)
[02:39] <lifeless> emmajane: yes. The problem is that the delta is huge - 10's of thousands of lines, and SRU policy is to essentially audit that delta.

[02:39] <emmajane> cry
[02:39] <lifeless> backports have no such policy
[02:39] <lifeless> and neither do PPA's
[02:39]  * emmajane nods
[02:40] <lifeless> thus the answer to 'I /need/ a newer bzr' is - use the PPA.
[02:40] <lifeless> the major thing that is going to help here, isn't the new release schedule
[02:40] <AfC> lifeless: without any emotional charge whatsoever, and I do understand the engineering decisions that led the situation being the way it is (after all, inherited from Debian),
[02:40] <lifeless> its doing less formats.
[02:40] <AfC> lifeless: I really suggest there is something wrong when Canonical Ltd can't tell it's Linux distro project to backport and include another Canonical project's current version. But you and poolie have heard that enough from me, so I really need to stop bothering you about it.
[02:41] <emmajane> Yes. Because distros and packages have taught us that progress and change are both bad. :)
[02:41] <lifeless> so, poolie and I sat down with james_w one time, he was offering to walk bzr through a SRU
[02:41] <AfC> emmajane: That is also a Debian inheritance.
[02:41] <lifeless> he spoke to the RM, who vets SRU's
[02:41] <lifeless> AfC: I think emmajane was being sarcastic :)
[02:42] <emmajane> SRU is a TLA for "pain"?
[02:42] <lifeless> I have to say though that I think the SRU (stable release policy) is good, and something many customers depend on.
[02:42] <emmajane> ah, right.
[02:42] <lifeless> in our case, we *have* regressions vs 1.13.1 at the moment
[02:42] <AfC> lifeless: yeah, well, it's the reason (and pretty much the only one) we migrated away from Debian in 2002, and so I'm very alert for it changing, because I'd love to go back [or, forward, if you will, to Ubuntu]
[02:42] <igc> emmajane: once you get 1.16 or later, grab https://edge.launchpad.net/~ian-clatworthy/+junk/bzr-explorer-docs as well
[02:42] <emmajane> igc, :)
[02:43] <lifeless> there are several bugs in the bug database where users are being hurt hugely by changes we've made
[02:43] <lifeless> corner cases, to be sure
[02:43] <lifeless> but thats what the SRU aims to prevent.
[02:43] <lifeless> I think it does a decent job.
[02:43] <AfC> lifeless: frankly, "we [know we] *have* regressions vs" is actually what's important. That's very responsible, and very cool of you. Most projects aren't that mature.
[02:43] <lifeless> thanks :)
[02:44] <AfC> Hm. I need to stop writing about the weather and write about this topic instead.
[02:45] <AfC> lifeless: (the seed being this, then going to "... but the problem is what happens when customers running a stable release don't upgrade to the next stable release". But again, off topic)
[02:45] <lifeless> finish your small business accounting package. Please.
[02:45] <poolie> igc, the 1.18 branch isn't merged back to bzr.dev yet, when we do that it will fix the headings
[02:45] <AfC> lifeless: got to finish my word processor first, but I'm actually starting to get excited about working on the accounts package again. I think I've figured out a way to make progress.
[02:45] <emmajane> AfC, you're writing a word processor?!
[02:45] <lifeless> poolie: is there anything delaying that merge-back? I'm about to be blocked on  it..
[02:45] <AfC> [and yes, this should be followed by a "what the fuck are you doing writing a word processor"?]
[02:46] <emmajane> LOL
[02:46] <emmajane> clearly you were thinking about writing a book but decided that docbook and OOo sucked so much that you'd just write your own word processor first?
[02:46] <emmajane> Not that I'd know anything about that :)
[02:46] <lifeless> emmajane: yak shaving FTW!
[02:46] <AfC> emmajane: s/docbook/LaTeX/, and yes
[02:47] <emmajane> LOL
[02:47] <AfC> yummy yummy yak
[02:47] <poolie> afc, so "why can't Canonical tell X to do Y" has many interesting threads
[02:47] <emmajane> there's nothing like an author trying to avoid writing a chapter. :)
[02:47] <poolie> one being that people may object, rightly or wrongly, to canonical making Ubuntu do what Canonical wants
[02:48] <AfC> poolie: I know. I'm approaching this as a management consultant, not a techie.
[02:48] <poolie> the short answer is that i think we should meet in the middle
[02:48] <emmajane> (afc: http://www.amazon.com/Front-End-Drupal-Designing-Developers/dp/0137136692 is me)
[02:48] <AfC> poolie: (and I don't pretend to know all the factors, so this *is* interesting to me, even if we're all tired of talking about it)
[02:48] <poolie> if we make bugfix-only updates they should go through SRU without needing a big hammer
[02:49] <poolie> and if a rubber mallet is needed, canoncial will apply that with discretion
[02:49] <AfC> emmajane: very nice
[02:49] <lifeless> poolie: I suspect we'll need further process changes roughly orthogonal to the release schedule changes to help cases like emmajane's.
[02:50] <AfC> poolie: the fundamental problem is that this isn't Cisco IOS. It's open source, and for essentially every open source project with the possible exceptions of (eg) Linux 2.4 vs 2.6 and (once upon a time) Apache 1.3 vs 2.0
[02:50] <SamB> docbook is a word processor?
[02:50] <AfC> SamB: no, XML documentation fomat
[02:50] <AfC> SamB, emmajane: wait one
[02:50]  * emmajane finally gets the PPA installed.
[02:50] <SamB> AfC: you forgot!
[02:50] <SamB> it's also an SGML documentation format
[02:51] <emmajane> SamB, that's old skool.
[02:51] <AfC> poolie: ... and for open source (and commercial software too, but no one admits it), the bug fixes are in the next version, locked up in new features. There's no difference; the new features are the bug fixes; the bug fixes are new features.
[02:51] <AfC> poolie: (this is one of my keynote themes)
[02:51] <SamB> though at this point I guess you should probably use XML even if you do want to use it with DSSSL sheets
[02:51] <igc> hi SamB
[02:51] <poolie> lifeless: if you mean "but i don't want just bugfixes i want the new black" then yes, that needs - either good ppas or backports or whatever
[02:51] <emmajane> sometimes I wish error messages had LESS information.
[02:52] <poolie> afc, i think in some ways open source is just recognizing reality there
[02:52] <emmajane> Tracebacks scare me.
[02:52] <poolie> emmajane: yeah that's an interesting question too
[02:52] <emmajane> +unexpected tracebacks
[02:52] <igc> SamB: I've put some work into fast-import in recent days to make it more reliable coming up to the 2.0 release
[02:52] <poolie> possibly we should hide them unless the user actually wants to report a bug
[02:52] <poolie> afc, at the end of the road is something like tom lord's position that everyone should just maintain their own branch and cherrypick the features they want or need
[02:52] <SamB> poolie: I loves reporting bugs if I have a clue what bugs I'm reporting
[02:52] <AfC> poolie: so (and now that it's come up, this is essentially be feedback for the 6-month release thread), I am very wary of such a cycle; for all it's benefits I would suggest that the bzr hacker community will have a hard time mustering much enthusiasm to do anything on 2.stable.x instead of bzr.dev
[02:53] <poolie> you may be right
[02:53] <emmajane> From a user perspective it looked like this: bzr: ERROR: exceptions.KeyError: 'Bazaar repository format 2a (needs bzr 1.16 or later)\n' (the slash n is awesome) and the lkjadjkldjlksfadjlksdfljk;asadfjl;sadfjl;sadfljk; for a long time and the error again in English.
[02:53] <poolie> i think it's worth a try though
[02:53] <poolie> !!
[02:53] <igc> SamB: after all, 2.0 will undoubtedly mean more people trying to import into bzr
[02:53] <poolie> that's a bit poor
[02:53] <emmajane> That's what tracebacks look like to me. :)
[02:53] <SamB> igc: mmm hmm
[02:54] <lifeless> poolie: yes, thats what I mean (and my hunch is thats what most folk are asking for)
[02:54] <poolie> emmajane: if that's what i think it is should be saying 'unrecognized format' and no traceback
[02:54] <igc> SamB: so my priorities for fast-import are:
[02:54] <AfC> poolie: "recognizing reality" yes, exactly. But Debian-esque release freezing and upstream evolving reality just don't seem to jive. I think that's the fundamental problem in the open source sphere currently.
[02:54] <poolie> i agree they're gibberish
[02:54] <SamB> igc: you want me to try getting that tarball importer working?
[02:54] <igc> 1. make importing reliable and bug free
[02:54] <igc> 2. make exporting from other tools really easy
[02:54] <lifeless> SamB: are you on Mac OSX ?
[02:54] <AfC> poolie and lifeless: anyway, sorry to get into that.
[02:54] <emmajane> poolie, It's plausible that someone tried to help me at some point and turned on tracebacks by default.
[02:54] <SamB> lifeless: no
[02:54] <SamB> why?
[02:55] <AfC> poolie and lifeless: but always a pleasure to talk with (and learn from) you gents.
[02:55] <igc> 3. fast-export bugs
[02:55] <lifeless> there is a bug in the python tarball module in some versions of the python Apple ship
[02:55] <poolie> afc, i think users will never agree 100% on what's worthwhile fixes and what's unwanted churn
[02:55] <lifeless> they shipped a beta, if I remember the details correctly.
[02:55] <poolie> anyhow...
[02:55] <SamB> lifeless: hmm ... iirc, the script in question is written in perl
[02:55] <igc> SamB: any help you can offer on making import highly reliable would be great
[02:55] <AfC> poolie: there's also the "corporate sysadmin" vs "developer" vs "end user". All three have radically different needs.
[02:55] <fullermd> SamB: Pfft.  SGML roolz   :p
[02:55] <AfC> anyhow
[02:56] <igc> SamB: that 'tag from ref' bug or whatever it was sounds important if git-fast-export is now producing that more reguarly
[02:56] <SamB> fullermd: well, I don't know if they've been updating the SGML DTDs and those are kind of important if you're going to use abbreviated forms ...
[02:56] <igc> SamB: but in general, any help on bug fixing or adding tests is ultra-welcome
[02:57] <AfC> SamB, emmajane: I'm happy to talk to you about what I'm working on, I _have_ done up a very preliminary web page, but it's not at "I can download it and play with it myself stage" yet so I'm reluctant to talk it up too much.
[02:57] <fullermd> SamB: Well, I don't either; I don't use Docbook.  I was just making a general trol^Wcomment  ;p
[02:57] <SamB> igc: actually, that was generated by a slightly-altered form of the tarball import script from git's contrib tree
[02:57] <igc> SamB: I'll like to release bzr-fastimport 0.9 next Monday say ...
[02:57] <AfC> SamB, emmajane: but this isn't the place to talk about it further, so after a couple URLs if you want to chat with me about it (please do!) -> #java-gnome on irc.gimp.net
[02:57] <lifeless> SamB: you know that bzr can import from tarballs itself?
[02:57] <igc> SamB: to give some time to get it packaged into karmic, etc.
[02:57] <SamB> lifeless: it's nice to just set it loose on a bunch of 'em, though ...
[02:58] <AfC> SamB, emmajane: general motivations http://blogs.operationaldynamics.com/andrew/#one-year-and-more and what isn't linked to from there because I'm not promoting it anytime soon is http://research.operationaldynamics.com/projects/quill/
[02:59] <poolie> afc, that's nice
[03:00] <poolie> i've always thought the thing about 'a man's reach exceed his grasp' is especially relevant to software or similar creations
[03:01] <SamB> lifeless: oh, also this fast-import thing gets the datestamps right on the commits, I think ...
[03:02] <SamB> that is, it takes them from the tarballs
[03:02] <lifeless> SamB: thats a fairly esoteric definition of 'right' ;)
[03:02] <SamB> yeah ;-P
[03:03] <AfC> poolie: it's been a fascinating couple of weeks, because I met a poet who understands (well, almost) what open source is. Really great discussions.
[03:03] <SamB> igc: so ... if I were going to send you a modified version of a git contrib/ script to include, where should I put it?
[03:03] <SamB> oh, exporters
[03:03] <SamB> :-)
[03:04] <emmajane> poolie, where would the traceback stuff be turned off/on? I don't see anything in bazaar.conf
[03:04] <SamB> hmm ... is there some easy way to import a single file's history from another branch?
[03:04] <SamB> a completely unrelated branch?
[03:04] <poolie> emmajane: ah i might have been talking about what should happen rather than what does happen
[03:05] <poolie> classic major Australian isp service announcement a while ago "no email should have been lost during the upgrade"
[03:05] <poolie> yeah :)
[03:05] <emmajane> poolie, ahhhh
[03:05] <poolie> emmajane: we could change trace.py to not show them and only log them
[03:05] <emmajane> poolie, that'd be lovely.
[03:05] <poolie> there's a flag that does the opposite, -Derror, always shows them
[03:05] <poolie> want to send an rfc mail?
[03:05] <emmajane> sure.
[03:06] <SamB> poolie: it should be easy to configure it to behave like now, I think
[03:06] <SamB> I prefer not to have to dig too deep for my tracebacks
[03:06] <poolie> it'd be a small change to trace.py
[03:06] <SamB> at least, when it's a bug-type traceback
[03:06] <poolie> oh i see
[03:06] <emmajane> "the version you want is newer than the version you're using" isn't a bug IMO.
[03:06] <poolie> we could add another flag or somethnig then you could set in bazaar.conf
[03:07]  * emmajane nods. Flags work.
[03:07] <lifeless> we should make unknown formats not traceback, if they are.
[03:07] <SamB> yeah, that's not a bug per-se
[03:07] <lifeless> we can render it reasonably well
[03:07] <SamB> just an absent feature
[03:07] <emmajane> I'll paste the full message with the RFC.
[03:08] <emmajane> there are kwargs involved.
[03:09] <SamB> so ... how would I import a file *with* it's entire history from a branch ... will that thing in that mail I saw recently do it?
[03:11] <fullermd> Files don't have history; history has files.
[03:11] <SamB> fullermd: maybe that's true in the soviet union ;-P
[03:12] <fullermd> It's also true in bzr   :p
[03:12] <fullermd> And mergitatone, for that matter...
[03:20] <SamB> well, *I* was speaking english
[03:21] <SamB> nevermind that the file in question is actually under git ;-P
[03:26] <emmajane> poolie, RFC sent. I'm not sure that it quite captures things correctly, so feel free to tell me what my opinion is supposed to be if I got it wrong. :)
[03:26] <SamB> lol
[03:27]  * emmajane scrolls up and notes the references to oppressive regimes and figures it all fits quite nicely together. :)
[03:55] <lifeless> poolie: is there a list of failing testids with your plugin?
[03:55] <poolie> nup, not up to date
[03:55] <poolie> i can attach it to that bug
[03:55] <lifeless> please
[03:55] <poolie> many are now fixed so i'll re-run it
[03:55] <lifeless> even a larger list would be helpful - massively reduces the window to look at
[03:55] <poolie> i'm tempted to do subunit-sort first, it woul rock for that kind of thing
[03:55] <poolie> but i won't
[03:55] <lifeless> :)
[04:07] <poolie> merge back to trunk sent
[04:09] <igc> poolie: new docs built and uploaded - email sent to list
[04:09]  * igc lunch
[04:09] <poolie> ok
[04:09] <poolie> igc my merge will incidentally fix news
[04:17]  * emmajane shuts down for the night.
[04:23] <jam> hey poolie, still working?
[04:23] <jam> night emmajane
[04:23] <poolie> i am
[04:23] <poolie> struggling to keep awake at 1:23pm :)
[04:24] <poolie> more seriously i would like some lunch soon....
[04:24] <poolie> i was going to work this afternoon but away from email and irc
[04:25] <Adys> I thought bzr pack was supposed to compress/garbage-collect a repository? After running it on an old one, repo size jumps from 41mb to 54mb
[04:25] <lifeless> Adys: it consolidates the storage to reduce roundtrips when accessing it over the VFS
[04:25] <poolie> Adys: there are probably some pack files in obsolete_packs that are retained in case someone's still using them
[04:25] <poolie> but that will be removed soon
[04:25] <lifeless> Adys: basically you never need to run it
[04:25] <poolie> and what he said
[04:25] <poolie> jam, did you want to talk?
[04:26] <Adys> um, does that mean I should revert back to the old one or it doesnt matter?
[04:27] <poolie> it doesn't matter
[04:27] <lifeless> Adys: its not harmful
[04:27] <Adys> fair enough
[04:27] <lifeless> Adys: but its not usually helpful either - bzr will pack behind the scenes when it needs to.
[04:27] <poolie> see bug 304320 and bug 373539
[04:27] <poolie> i agree it's surprising/confusing
[04:29] <jam> poolie: I'm happy to chat a bit if you want
[04:29] <poolie> i was going to ask you about the 1.18rc1 thing
[04:29] <jam> but if you prefer to head off, that's fine
[04:29] <poolie> i replied
[04:29] <poolie> at any rate i don't plan to do anything more on it before i fly so it's not urgent
[04:30] <poolie> unless you really want to talk
[04:31] <jam> poolie: no, I just read your reply, and it fits pretty well my understanding
[04:31] <jam> as far as it goes, I don't really care if we just do a 1.18 and make the big change at 2.0
[04:31] <lifeless> I'd prefer to make the change at 2.0
[04:31] <jam> it feels a bit more straightforward, to be honest
[04:31] <poolie> ok
[04:32] <lifeless> avoids problems with debian version numbers around the version number
[04:32] <lifeless> not to mention giving packagers warning
[04:32] <poolie> therefore we'll do a 1.18 in a week, and then a 2.0beta1 following that?
[04:32] <poolie> after the default changes
[04:33] <jam> poolie: sounds ~ right, though a bit of a stepped up schedule when the next release would hit
[04:33] <jam> are you thinking to get a beta out before 2.0-final?
[04:33] <poolie> it might be good
[04:33] <poolie> i think a bit of extra exposure after we change the format could be good
[04:33] <poolie> even if we don't think every change is finished
[04:34] <jam> I'll think about it
[04:34] <jam> I was hoping to see 2.0 be the next release
[04:34] <poolie> ok
[04:34] <poolie> me too
[04:34] <poolie> i wouldn't have a one-month beta
[04:34] <jam> but we'll have to see how things are shaping up
[04:34] <poolie> maybe we can just do an rc, or a couple of rcs, and then see
[04:34] <poolie> let's see when things land
[04:34] <poolie> biab
[04:38] <SamB> poolie: 2.0 had better have spiv's branch landed, that's all I can say!
[04:39] <jam> SamB: stop working cross format, and it won't matter
[04:39] <jam> if you want 2a, use it
[04:39] <jam> :)
[04:39] <SamB> jam: so ... it doesn't use VFS calls over the hpss if you're using just 2a?
[04:40] <jam> SamB: yep
[04:40] <jam> well, no more than the current one does, which is only edge cases IIRC
[04:40] <SamB> but it seems kind of dumb to have it using 95% VFS calls over the hpss like it is ...
[04:41] <jam> SamB: so I optimize the cross-format conversion to be fast when you have 2 local branches or "bzr upgrade"
[04:41] <jam> because cross-format over long distances didn't seem that important
[04:41] <SamB> jam: that's not very fast either!
[04:41] <jam> if you want to upgrade, then you upgrade
[04:41] <jam> SamB: it could be a *lot* slower
[04:41] <SamB> jam: so?
[04:41] <jam> the primary issue is getting the data out of the old format
[04:41] <SamB> I should steal some of your RAM
[04:41] <jam> about 60+% of the time
[04:41] <SamB> jam: that's not saying much
[04:42] <SamB> for me, it's at roughly ∞ anyway ...
[04:42] <SamB> for bzr.dev-sized repos
[04:44] <SamB> jam: also, you guys haven't upgraded lp:bzr yet
[05:17] <igc> poolie: I think the bzr-windows team has got off to a good start - we have 22 members now
[05:17] <igc> poolie: I'd like to do the same for os x
[05:18] <igc> poolie: do you agree? if so, bzr-mac or bzr-os-x as the name?
[05:19] <igc> poolie: once again, topic #1 will be packaging/installers, following a similar RFI/call-for-volunteers process as the Windows team
[05:28] <bialix> igc: I don't quite understand your mail about windows installer changes
[05:28] <igc> bialix: which bit?
[05:29] <bialix> maybe I need some coffee first
[05:29] <bialix> btw, Inno can't build msi, but it definitely build one exe
[05:29] <bialix> item #2 is unclear for me, WDYM?
[05:30] <bialix> and you talk about consensus. Does there already consensus reached?
[05:30] <igc> bialix: Well, if the consensus is that msi is what we want, then we need to look at how we build that
[05:31] <igc> bialix: there was a fair amount I think, e.g. ...
[05:31] <bialix> msi is long standing wish with lowest priority as I can say
[05:32] <igc> one installer is promoted; easy-install for the simple command-line case
[05:32] <bialix> igc: btw qbzr 0.13 is out, it just lacks announce mail
[05:32] <igc> bialix: also Explorer & tbzr both in with the latter off by default
[05:32] <igc> bialix: oh, ok - I'll roll out a new explorer release tonight
[05:33] <bialix> igc: it seems sidnei want to throw away bzr.exe, but awilkins want it stay.What is consensus here?
[05:33] <igc> bialix: we keep it I think
[05:33] <bialix> igc: TBZR today is barely usable buggy alpha software
[05:34] <bialix> it's shame that nobody works on it, but Mark has put very high bar it seems
[05:34] <bialix> so I think wil be better to remove it from installer entirely for some time
[05:34] <bialix> is it too extreme?
[05:36] <igc> bialix: maybe not. post to bzr-window asking if anyone prefers it to explorer? If no-one says yes, then perhaps we could leave it out altogether
[05:36] <bialix> well Naoki seems to trying maintain it
[05:36] <lifeless> it was asked for /a lot/ when it didn't exist
[05:36] <lifeless> and folk seem to be using it
[05:36] <igc> bialix: otoh, maybe plenty of silent users are relying on it being there
[05:37] <igc> bialix: I'd be hestitant to remove it given it's part of our current default install
[05:37] <bialix> lifeless: in the past there was no alternative. today we have bzr-explorer
[05:38] <bialix> igc: perhaps I;ve lost the track of user needs, I'm happy with my custom installer, so I think from my egoistical POV
[05:39] <poolie> bialix: i think at least making it optional would be a good step
[05:39] <poolie> as i wrote on the list
[05:39] <poolie> igc, +1 to a mac os list
[05:39] <bialix> igc: if I'l have some free time at lunch time I'll try to consolidate the feedback
[05:39] <poolie> the metric i'm really watching is whether more people post
[05:39] <poolie> but we'll see
[05:40] <bialix> poolie: it's already optional
[05:40] <poolie> i think being able to build an installer using only the free compiler would be good
[05:40] <poolie> oh one more random thought here - i wonder if we can run win32 python under wine well enough to test?
[05:41] <bialix> I have no experience with COM programming, so I have no idea is mingw could compile this stuff
[05:41] <bialix> hg guys seems to run windows tests on wine with good success
[05:42] <bialix> run CLI bzr should be no problem for wine
[05:42] <bialix> but somebody should just try
[06:07] <igc> poolie: so preferred list name? bzr-mac or bzr-os-x or bzr-mac-os-x
[06:08] <poolie> the first is shorter :)
[06:08] <igc> poolie: I probably prefer it
[06:47] <lifeless> poolie: bug 375013 fix up for review.
[07:11] <vila> hi all
[07:16] <igc> hi vila
[07:42] <lifeless> vila: I wonder if I could get a review from you on my merge for bug-375013
[07:44] <vila> lifeless: hmm, given the subject, I'm afraid I can't do that dave, but I'lll have a look
[07:44] <vila> lifeless: merge request URL ?
[07:45] <lifeless> c.l.n/~lifeless/bzr/bug-375013
[07:45] <lifeless> is the branch
[07:45] <lifeless> clickyclicky from there
[07:45] <vila> got it
[07:47] <vila> lifeless: err is the 2.0.0 stuff from your or another mad case ?
[07:47] <lifeless> 2.0.0 ?
[07:47] <vila> https://code.edge.launchpad.net/~lifeless/bzr/bug-375013/+merge/9967
[07:47] <vila> bzr and bzrlib/__init__.py
[07:47] <lifeless> ignore those
[07:47] <lifeless> its trunk being old
[07:58] <vila> lifeless: so, if I read that right, this is a one-line fix (in get_commit_builder) and then fixing failing tests ?
[07:59] <lifeless> yes
[07:59] <lifeless> and a NEWS entry about it.
[07:59] <vila> lifeless: but it seems you change some tests to use a checkout instead of a branch ? (I may need to read more deeply, just a quick confirmation)
[07:59] <lifeless> I got better at the fix later on
[07:59] <vila> lifeless: right the NEWS entry is important
[08:00] <lifeless> but they are == in terms of speed so didn't bother to make them all the same
[08:02] <vila> the feeling I have is that you have hijacked some tests instead of making new ones, am I wrong ?
[08:02] <lifeless> I think you're wrong
[08:02] <lifeless> I don't think I changed the intent of any test.
[08:02] <lifeless> some tests were doing things that they didn't claim to test, so I pruned them back to what they claimed.
[08:03] <vila> ha, good, not obvious at first read, hence the question
[08:04] <lifeless> I'm off for a while. ciao.
[08:04] <vila> lifeless: meh, don't you want an approve ?
[08:43] <LarstiQ> spm: how did the pqm upgrade go?
[09:03] <bialix> igc: bzr-explorer 0.6 small issue with bzr.exe
[09:03] <igc> bialix: namely?
[09:04] <bialix> About dialog fails with import error: no module named platform
[09:05] <bialix> bzr.exe lacks std platform module
[09:05] <igc> bialix: damn I hate how bzr.exe doesn't have all the python libs :-(
[09:06] <bialix> really? hate?
[09:06] <bialix> I can package it into installer for bzr-explorer if you wish
[09:06] <igc> bialix: ok, I guess we can catch the import error in explorer and not report the python version?
[09:06] <bialix> or into qbzr installer
[09:07] <igc> into the bzr-explorer installer sounds good to me
[09:07] <bialix> why not report?
[09:07] <bialix> sys.version is not good for you?
[09:07] <igc> bialix: it will do. I was copying some code from a book sample and I just did as it did
[09:08] <bialix> I can look at the code and tweak it (not yet)
[09:08] <igc> bialix: please
[09:08] <bialix> should I push tag then or you prefer 0.6.1
[09:08] <igc> bialix: 0.6.1
[09:09] <bialix> ok, so I'll fix the issue and make new release with installer for 0.6.1 only
[09:09] <bialix> and you can announce it tomorrow
[09:09] <bialix> ok?
[09:09] <igc> bialix: yes
[09:10] <bialix> garyvdm about to announce qbzr 0.13 right now
[09:11] <bialix> igc: actually I've thought you want to report OS version, like "Windows XP SP3"
[09:11] <bialix> platform module can provide this sort of info
[09:11] <bialix> python version available via sys
[09:11] <igc> bialix: I think that would be good but not for 0.6
[09:12] <bialix> I'm just trying to understand your intent re platform module
[09:12] <bialix> I have no chance to look at code yet
[09:12]  * bialix pulls and looks
[09:14] <bialix> igc: post 0.6.x I'd like to cleanup tests
[09:14] <bialix> there is ./tests and ./lib/tests
[09:14] <bialix> we have to merge them into one
[09:15] <igc> bialix: go for it. Just ./tests is the best direction I think
[09:15] <bialix> why not ./lib/tests ?
[09:15] <bialix> what's the reason to keep in the root of the tree?
[09:16] <igc> bialix: it just feels more symmetric to me: data, doc, lib, tests, etc,
[09:16] <igc> bialix: "lib" is effectively "src"
[09:16] <bialix> ok
[09:17] <bialix> qbzr question: one man building qbzr .deb for Debian Lenny and Etch
[09:17] <bialix> where he can publish them?
[09:18] <bialix> LP PPA can be used?
[09:34]  * igc dinnner
[09:59] <bialix> igc: fix for about dialog has pushed
[11:04] <bialix> LarstiQ, jelmer: hi
[11:11] <LarstiQ> hey bialix
[11:11] <bialix> LarstiQ: are you debian dev/maintainer?
[11:27] <garyvdm> bialix: Just updated http://groups.google.com/group/qbzr/web/screenshots
[11:27] <bialix> very nice, thanks
[11:28] <bialix> AfC has mentioned they have auto screenshot updater for the docs in java-gnome. I'm not sure how it could be done, but definitely could
[11:29] <bialix> especially for new site with user docs
[11:29] <garyvdm> bialix: It was difficult to choose what to include.  I don't have any thing for qcat.
[11:29] <LarstiQ> bialix: no, I don't have upload rights.
[11:29] <LarstiQ> bialix: but I do have some involvement
[11:29] <bialix> LarstiQ: what is usual practice?
[11:30] <LarstiQ> bialix: I think I'm missing some context, what do you want to do?
[11:30] <garyvdm> bialix: is this to get qbzr into debian?
[11:31] <bialix> LarstiQ: one man from ru_bzr want to build deb package for qbzr for Debian Lenny and Etch, he asking me about advices how to publish his work
[11:31] <bialix> garyvdm: yep
[11:32] <bialix> I'll start procedure of buying domain
[11:32] <garyvdm> bialix: Well I can't see a reason that he could not publish it to the ppa.
[11:33] <bialix> lp guys said there is no PPA for Debian
[11:33] <garyvdm> oh
[11:33] <bialix> you can look at irclogs of #launchpad
[11:33] <garyvdm> bbl
[11:33] <LarstiQ> bialix: I'm willing to review the packaging work
[11:33] <bialix> [11:27]	<wgrant>	bialix: Launchpad can't currently build PPA packages for Debian. However, if qbzr is Python as I assume, Ubuntu packages should work on Debian.
[11:34] <LarstiQ> bialix: finding someone to sponsor the upload to backports shouldn't be too hard either
[11:34] <wgrant> Right, no Debian PPA support at this point.
[11:34] <bialix> LarstiQ: can I give your contact to that man?
[11:35] <LarstiQ> bialix: sure
[11:35] <LarstiQ> bialix: hmm
[11:35] <bialix> so you can provide some hints
[11:35] <LarstiQ> bialix: qbzr doesn't seem to be in Debian currently?
[11:35] <bialix> are you asking me about this?
[11:35] <bialix> I don;t know even where to look to check?
[11:35] <LarstiQ> bialix: direct him to me, we'll figure it out then :)
[11:36] <bialix> okay
[11:36]  * LarstiQ is best contactable on irc btw
[11:38]  * bialix nods
[11:38] <bialix> LarstiQ: you talk Serbian?
[11:39] <LarstiQ> bialix: no, I guess I should remove that, I added that for testing bits of Rosetta
[11:39]  * LarstiQ does so now
[11:39] <bialix> np
[11:39] <jelmer> :-)
[11:40] <jelmer> bialix: qbzr is indeed not in Debian
[11:40] <LarstiQ> bialix: I do since speak a little bit of Finnish though ;)
[11:40] <bialix> :-)
[11:41] <LarstiQ> updated
[11:48]  * jelmer speaks 4 words of russian, not sure how to write them though :-)
[11:55] <bialix> jelmer: there is usual practice on writing them using latin alphabet
[12:00]  * LarstiQ heads to lunch
[13:10] <bialix> garyvdm: so, what's our plan for today?
[13:25] <garyvdm> bialix: http://launchpad.net/qbzr/trunk/0.13.1/+download/qbzr-0.13.1.tar.gz
[13:25] <bialix> ok
[13:26] <bialix> do you have a dedicated branch for this?
[13:26] <bialix> found https://code.launchpad.net/~qbzr-dev/qbzr/0.13
[13:30] <bialix> garyvdm: does QtTest is used in qbzr now?
[13:36] <bialix> garyvdm: windows installer has been uploaded
[14:13] <garyvdm> bialix: I forgot to include in NEWS something that say we now require Qt 4.4. I'll include it in the announcement mail.
[14:37] <bialix> garyvdm: cool graph on ohloh, indeed!
[15:11] <jam> morning vila
[15:11] <jam> fjalvingh: are you around?
[15:11] <vila> morning jam
[15:16] <fjalvingh> james_w: Hello, yes; im around
[15:16] <fjalvingh> jam, I mean 8-(
[15:33] <jam> garyvdm, bialix: I just say 0.13.1 announced, is that different from the 0.13 you told me about last night?
[15:33] <bialix> нуы
[15:33] <bialix> yes
[15:34] <bialix> garyvdm has fixed regression introduced before 0.13 release
[15:34] <igc> night all
[15:35] <garyvdm> jam: tisk tisk tisk lots of code just before a release...
[15:39] <jam> :)
[15:39] <jam> night igc
[15:39] <fullermd> That's what releases are for, aren't they?  To get people to put in new code?
[15:39] <bialix> jam: it seems like your comment about new features before release... it was evil eye
[15:39] <jam> bialix: it was experience
[15:40] <cody-somerville> I'm having much difficult reverting a single revision
[15:42] <jam> cody-somerville: Assuming you mean "I'm having trouble removing the changes introduced in a single revision"
[15:42] <jam> then you probably want
[15:42] <jam> "bzr merge -r REV..REV-1"
[15:42] <cody-somerville> But I have no idea what REV-1 is for 625.1.1
[15:42] <jam> cody-somerville: before:625.1.1 works fine
[15:43] <jam> so "bzr merge -r 625.1.1..before:625.1.1"
[15:43] <cody-somerville> thanks
[15:43] <cody-somerville> that worked
[15:43] <cody-somerville> but was way too difficult
[16:23] <garyvdm> bailix: There are lots of bug that I want to change to "wish list", so that I can see the real bug at the top of the page.
[16:23] <garyvdm> e.g. bug 306688
[16:24] <garyvdm> Is that ok>
[16:39] <LarstiQ> garyvdm: are you using the same bug workflow as bzr?
[16:39] <garyvdm> LarsitQ: workflow?
[16:40] <garyvdm> LarstiQ: I was looking for what to work on next. I would like to fix bugs first, before working on new features.
[16:41] <garyvdm> It would be nice to be able to prioritize Wishlist bugs...
[16:52] <LarstiQ> garyvdm: doc/developers/bug-handling.txt
[16:54] <cr3> darn you guys! now I can't type "bar" anymore, it always comes out as "bzr"!
[16:54]  * awilkins has also noticed that bzr has become a short reflex loop
[16:54] <Tak> fzo, bzr, bzz
[16:57] <garyvdm> LarstiQ: Hmm - we are using wishlist for features, bzr doc describes them as very "wishfull thinking buddy...."
[16:58] <garyvdm> aka very low Importance.
[16:59] <LarstiQ> garyvdm: right
[17:42] <garyvdm> Hi bialix
[17:42] <bialix> evening garyvdm
[17:43]  * bialix reviewing qexport
[17:44] <bialix> today I'm thinking about automating screenshot work
[17:45] <bialix> we can use qbzr trunk to illustrate some interesting dialogs
[17:45] <bialix> and some dialogs could be created programatically
[17:46] <bialix> then only printscreen capture need to be automated
[17:46] <bialix> I hope there is some programmable tools to do this work
[17:47] <bialix> will be nice to get this functionality directly from qt though
[17:47] <garyvdm> bialix: That would be cool!
[17:47] <bialix> garyvdm: do you aware about creating screenshots of qt windows?
[17:47] <garyvdm> Sorry no
[17:47] <bialix> I think such feature exists in Tkinter, but I don't remember for sure
[17:58] <luks> there is something in QDesktopWidget
[17:58] <luks> hm, maybe not there
[17:58] <luks> but it's somewhere
[17:59] <luks> QPixmap::grabWindow
[18:00] <bialix> luks, garyvdm: http://doc.trolltech.com/4.5/desktop-screenshot.html
[18:00] <bialix> originalPixmap = QPixmap::grabWindow(QApplication::desktop()->winId());
[18:00] <bialix> luks: yeah
[18:27] <luks> TestCaseWithTransport automatically creates a standalone branch in the root of the test directory, is there a clean way to disable that?
[18:28] <luks> I need to make a failing blackbox test for code that uses WorkingTree.open_containing and with that branch there it will always find something
[18:29] <LarstiQ> does it really?
[18:29] <james_w> yeah
[18:29] <luks> yes
[18:29] <james_w> it's there for safety
[18:29] <james_w> and you would be writing a test that would fail on some systems
[18:29] <bialix> luks: unfortunately you can't
[18:29] <LarstiQ> james_w: ah, so it doesn't recurse upwards infinitely?
[18:30] <james_w> perhaps creating a type of bzrdir that says "stop looking here please" for use in tests would help
[18:30] <james_w> LarstiQ: exactly
[18:30] <luks> I'm not sure I follow
[18:30] <Tak> wait, what system allows infinite upward recursion?
[18:31] <luks> it's hard to believe that no blackbox test in bzr ever needed that
[18:31] <luks> but I really can't find anything
[18:32] <luks> I wonder what would happen if I remove the root .bzr directory
[18:32] <statik> hi bzr hackers! on one of my machines, i'm trying to use bzr and bzr-gtk, both installed from https://edge.launchpad.net/~bzr/+archive/ppa. I get this failure: Unable to load plugin 'gtk'. It requested API version (1, 13, 0) of module <module 'bzrlib' from '/usr/lib/python2.6/dist-packages/bzrlib/__init__.pyc'> but the minimum exported version is (1, 17, 0), and the maximum is (1, 17, 0)
[18:32] <luks> or perhaps just move it and then move back
[18:33] <statik> I'm trying to do this on jaunty (9.04), and having some trouble figuring out how to get a usable version of bzr-gtk
[18:34] <luks> bah, so this means I can't write the test
[18:35] <bialix> luks: I suppose it's for safety, so your test don't open the branch outside you testing sandbox
[18:35] <luks> bialix: yeah, I just realized that
[18:35] <bialix> I've stuck with the same probkem recently
[18:35] <bialix> problem
[18:35] <luks> I'll just have to ignore that case
[18:36] <jam> luks: why don't you just create another dir that is a repository
[18:36] <jam> without a working tree
[18:36] <jam> self.make_repository('.')
[18:36] <jam> that should trap WT.open_containing() so it doesn't find the one in the test root
[18:36] <luks> oh, that will work?
[18:36] <jam> luks: try it, but I'm 90% sure it will work
[18:36] <luks> cool, thanks
[18:38] <luks> works great
[18:38] <garyvdm> statik: I'll probable end up trying to convince you to try qbzr, but let me try help with bzr-gtk first. What version of bzr-gtk do you have installed? This can be seen from bzr plugins -v
[18:38] <jam> vila: are you still around? (not that you should be)
[18:39] <jam> statik: you need to get the latest bzr-gtk from its ppa, IIRC
[18:39] <jam> known issue that bzr-gtk had not actually released code for a long time
[18:39] <statik> garyvdm: thanks for the help. jam: ah, I didn't realize bzr-gtk had it's own ppa, I was confused because I saw bzr-gtk packages in the main bzr ppa
[18:39] <jam> statik: well, I'm not positive about that
[18:39] <jam> I'm looking
[18:40] <jam> it may just be that nobody packaged the latest release
[18:40] <statik> garyvdm: i had the version from the ~bzr ppa, but i think i might try switching to qbzr or bzr-gtk trunk
[18:40] <statik> garyvdm: if i'm running bzr 1.17 is it better to use qbzr from trunk or from a ppa somewhere?
[18:40] <garyvdm> jam: If so, someone should either copy the new ppa to the bzr ppa, or delete the old ones.
[18:41] <jam> garyvdm: I don't think there is a bzr-gtk ppa after all
[18:41] <jam> vila was kind enough to force an actual release of bzr-gtk code
[18:41] <jam> but I don't see any .debs around
[18:41] <garyvdm> statik: the one in the bzr ppa is 0.12, which is fine for 0.17. The latest release is 0.13.1, which is only in the qbzr ppa
[18:42] <jam> garyvdm: other than the fact that I just hit "copy" for 0.13.1 => bzr's ppa
[18:42] <statik> garyvdm: ~qbzr-dev is the qbzr ppa you are referring to?
[18:42] <jam> I guess Is hould have only copied it to the beta
[18:42] <garyvdm> jam: Oh - cool
[18:42] <jam> since 1.18rc1 isn't in the bzr ppa...
[18:42] <jam> does 0.13.1 work with 1.17?
[18:43] <jam> statik: I do see: http://bzr.debian.org/pkg-bazaar/bzr-gtk/ubuntu/
[18:43] <garyvdm> jam: 0.13.1 should be fine with 0.16, and 0.17
[18:43] <jam> I don't really know what's up with that
[18:43] <jam> garyvdm: well, hopefully 1.16 and not 0.16
[18:43] <jam> :)
[18:43] <jam> though if it still works with 0.16, great
[18:43] <garyvdm> jam: err- yes - I get so confused.
[18:43] <jam> garyvdm: yeah, the numbers are "close" but still not in sync
[18:44] <jam> uh-oh
[18:44] <jam> it looks like *I* was the last person to upload bzr-gtk
[18:44] <jam> though that was back in 2008-08-26
[18:44] <statik> haha, with qbzr 0.12-1 'bzr help qbzr' says "Not finished -- DON'T USE" in the description
[18:45] <jam> statik: interesting. certainly should be updated. It is the default package on windows for a while now, and is in rather good shape
[18:45] <garyvdm> statik: bzr qbzr is our main window, which is not finished. All the other command are very useable
[18:45] <statik> but, yay, qannotate works nicely and I can get back to spelunking through my code reviews :) thanks for the help!
[18:45] <statik> garyvdm: ah, that makes more sense
[18:45] <garyvdm> statik: e.g. qlog, qcommit, etc.
[18:46] <jam> garyvdm: you might want to reconsider the name of your main window, so that you get help on the plugin rather than the command
[18:46] <garyvdm> jam: yes, I plan to rename it to qmain.
[18:46] <ryanakca> Is there an equivalent to git add -p, that's to say, only commit parts of the changes in a file?
[18:46] <LarstiQ> statik: contrast `bzr help plugins/qbzr`
[18:47] <garyvdm> bialix: ^^^ any objection to doing that now...
[18:47] <jam> ryanakca: not directly, but you can use "bzr shelve" to back out parts of the change temporarily and then "bzr unshelve" it later
[18:47] <bialix> one sec
[18:47] <LarstiQ> ryanakca: on _add_?
[18:47] <jam> LarstiQ: 'git add' stages things to actually be committed
[18:48] <jam> (as in 'git add' stores stuff in the repository)
[18:48] <statik> LarstiQ: ah, thats what i was looking for. thanks!
[18:48] <jam> but doesn't reference it until 'git commit'
[18:48] <ryanakca> jam: but to shelve just say, lines 8-12 , but not lines 25-75 ?
[18:48] <bialix> garyvdm: objection for what?
[18:48] <jam> ryanakca: bzr shelve is interactive
[18:49] <garyvdm> bialix rename qbzr to qmain
[18:49] <ryanakca> jam: Awesome, thanks
[18:49] <jam> with the main advantage that you can then *test* what you are committing
[18:49] <bialix> garyvdm: ah, no, of course, it's hidden anyway. But please write NEWS, because some people seems to try using it
[18:49] <LarstiQ> ryanakca: although it doesn't support hunk splitting atm
[18:50] <garyvdm> bialix: lots of new users type bzr help qbzr, and get a not so nice message about  not been complete.
[18:50] <ryanakca> LarstiQ: OK
[18:50] <bialix> yes, let's do it
[18:52] <SamB> jam: it would be nice if bzr revert was interactive too ...
[18:52] <SamB> or could be
[18:55] <mzz> couldn't you shelve the changes you want to keep, revert everything else, then unshelve?
[18:55] <mzz> I think I've actually done that
[18:55]  * SamB wants "bzr vizmissing" 
[18:55] <LarstiQ> mzz: yes
[18:56] <jam> SamB: bzr qlog branch1 branch2
[18:56] <jam> a bit of extra info
[18:56] <jam> but would show you what is on one branch and not the other
[18:56] <SamB> jam: I don't think I have enough free disk space to install qbzr
[18:57] <jam> SamB:  I thought viz may have also been updated to handle multiple branches
[18:57] <SamB> oh, true
[18:57] <SamB> too bad I can't do branch1...branch2, though :-(
[18:57] <jam> SamB: bzr log -r -1:../branch1..-1../branch2 ?
[18:57] <jam> not sure how that works with viz
[18:58] <garyvdm> SamB: bzr qlog . branch2
[18:59] <SamB> "bzr viz ../trunk .&" does something ;-)
[18:59] <meoblast001> hi, i have a question
[18:59] <garyvdm> SamB; you can do that with vis if the missing revisions from branch2 are available in branch1's repo
[18:59] <meoblast001> suppose i have some binary files in my program
[18:59] <jam> meoblast001: I have a dream :)
[19:00] <meoblast001> if i modify and push those binary files regularly, does that increase the size of the branch rapidly?
[19:00] <SamB> garyvdm: they are in the same repo, actually -- are you saying that viz only looks in one repo?
[19:00] <meoblast001> and make people have to download more
[19:00] <garyvdm> SamB: I the revisions are not there, it will fail silently :-(.
[19:00] <SamB> meoblast001: it depends on how much serialization changes when you change the file
[19:00] <SamB> meoblast001: what sort of binary files?
[19:01] <meoblast001> .blend files
[19:01] <meoblast001> it's a game
[19:01] <garyvdm> SamB: yes, vis only looks at 1 repo, qlog is able to look at multiple.
[19:01] <SamB> how does .blend work?
[19:01] <mzz> meoblast001: I'd expect it to depend heavily on the file format (if the file's compressed it'll suck, for example)
[19:01] <LarstiQ> .blend is not compressed
[19:02] <LarstiQ> and it's chunk based
[19:02] <meoblast001> is that good?
[19:02] <SamB> probably!
[19:02] <LarstiQ> meoblast001: I think it should work reasonably well, but I haven't tried it in practice yet.
[19:02] <jam> meoblast001: I would say... It depends
[19:02] <jam> the latest format (--2a) should do better at producing binary deltas than previous formats which did line-deltas
[19:02] <meoblast001> is all the data for revisions held in .bzr, i could check
[19:02] <luks> hm, what do I have to do to resubmit a merge request on LP?
[19:03] <jam> luks: mark it "resubmit"
[19:03] <jam> versus Approve/etc
[19:03] <LarstiQ> meoblast001: in the .bzr of the repository yes (ie, the .bzr with .bzr/repository/)
[19:03] <meoblast001> yuck
[19:03] <meoblast001> 27 megabytes
[19:03] <SamB> meoblast001: does that include obsolete_packs ?
[19:03] <luks> jam: thanks
[19:04] <LarstiQ> meoblast001: for what treesize?
[19:04] <meoblast001> and the entire directory for my game is 28
[19:04] <meoblast001> actually, that doesn't seem right
[19:04] <LarstiQ> meoblast001: at how many revisions?
[19:04] <garyvdm> SamB: I would like to get some feedback, how come you are using bzr-gtk, as appose to qbzr?
[19:04] <meoblast001> about 50
[19:04] <LarstiQ> meoblast001: ok
[19:04] <SamB> garyvdm: qt is too big
[19:04] <meoblast001> so is that bad?
[19:04] <jam> garyvdm: hysterical raisins, I imagine
[19:04] <garyvdm> SamB: ok
[19:04] <meoblast001> it seems pretty bad
[19:04] <LarstiQ> meoblast001: a bit hard to tell yet
[19:04] <SamB> and my /usr is pretty full
[19:05] <meoblast001> at revision 1000 we'll have several gigs of stuff
[19:05] <LarstiQ> meoblast001: well, how quick has it been growing?
[19:05] <meoblast001> slowly
[19:05] <meoblast001> 50 revisions over the course of a half year
[19:05] <LarstiQ> meoblast001: no I mean, has it been 27meg from rev1 and stayed the same?
[19:05] <meoblast001> would you recommend removing all the art and putting that in a seperate location?
[19:05] <mzz> meoblast001: I don't follow. Does 28 for the "entire directory" include those 27m for .bzr?
[19:05] <meoblast001> mzz: yes
[19:05] <mzz> ok, that's odd
[19:06] <LarstiQ> meoblast001: ah, I thought without .bzr was 28
[19:06] <meoblast001> wait a second
[19:06] <meoblast001> this is weird
[19:06] <jam> meoblast001: just paste the results of "du -ksh .; du -ksh .bzr"
[19:06] <meoblast001> hm, my tree is 27 MB
[19:06] <mzz> meoblast001: are you sure the directory wasn't much larger in the past? 27m of .bzr for 50 revisions of a tree that's on average 1m seems a bit larger than usual.
[19:06] <meoblast001> so let me check .bzr
[19:06] <mzz> or that.
[19:06] <meoblast001> it is also 27
[19:07] <meoblast001> that's weird
[19:07] <mzz> yeah, that sounds more reasonable.
[19:07] <garyvdm> SamB: I have spoken to many people that have that reason. So many I often consider creating a gtk port of qbzr. (I think that would be eaiser than porting qbzr's feature to bzr-gtk.)
[19:07] <mzz> meoblast001: data inside .bzr *is* compressed, so it's possible for it to be a bit smaller than your source tree is, if you don't have many revisions and they compress well.
[19:07] <LarstiQ> garyvdm: eh, that sounds like a lot of work
[19:08] <luks> come on, QtGui+QtCore is like 10M or so
[19:08] <SamB> garyvdm: well, another approach might be to get the python qt bindings split into smaller pieces
[19:08] <meoblast001> well, 50 revisions, .bzr is about the same size as the rest of the source tree
[19:08] <luks> I doubt that's the real reason
[19:08] <meoblast001> does that sound like it's good?
[19:08] <mzz> meoblast001: that sounds about right to me, yes. But I'm no expert :)
[19:08] <LarstiQ> meoblast001: that sounds belieavable, yes
[19:08] <meoblast001> so i should continue the way i'm going?
[19:08] <SamB> luks: the python bindings are monolithic, though
[19:09] <mzz> meoblast001: I would, but ymmv
[19:09] <SamB> luks: in Debian, at least
[19:09] <meoblast001> ymmv?
[19:09] <luks> SamB: in debian, they can be built separately
[19:09] <mzz> meoblast001: your mileage may vary
[19:09] <garyvdm> luks, SamB: Yes, thats why U loged bug 381409
[19:09] <meoblast001> ok
[19:09] <garyvdm> *I
[19:09] <SamB> garyvdm: ah, thanks
[19:10] <SamB> I was just about to go see if I had gotten around to it ;-)
[19:10] <garyvdm> lol
[19:10] <LarstiQ> garyvdm: how does it pull in phonon?
[19:10] <garyvdm> LarstiQ: I describe it in the bug
[19:10] <SamB> garyvdm: hmm, is there a debbug for that too?
[19:10]  * LarstiQ has python-qt4 installed on Lenny, no phonon
[19:10] <luks> phonon is a part of Qt
[19:10] <luks> it was added in 4.5, maybe you have something older?
[19:11] <SamB> I think python-qt4 also pulls in the qitchen sink
[19:11] <mzz> probably
[19:11] <LarstiQ> luks: yup, 4.4
[19:11] <mzz> afaict it's quite possible to split PyQt4 into smaller binary package just like Qt4 itself is
[19:11] <mzz> packages, even
[19:11] <bialix> python experts help needed: is it valid to write: def func(self, workdir=None, *args): ?
[19:12] <jam> bialix: I believe it is "def func(self, *args, workdir=None)"
[19:12] <mzz> bialix: yes, but it doesn't do what you want.
[19:12] <jam> not sure, though
[19:12] <jam> ah right
[19:12] <bialix> mzz: it's already splitted in Windows package
[19:12] <mzz> bialix: what jam said is a SyntaxError. What you said works but if you call it with two arguments "workdir" eats the second one, not "args"
[19:13] <jam> mzz: right, I forgot
[19:13] <mzz> bialix: you want python 3's keyword-only arguments. Without those the best you can do is take **kwargs and parse them manually.
[19:13] <jam> which is why we went with "def func(self, *args, **kwargs)" and then inspect kwargs in some of our code
[19:13] <mzz> exactly
[19:13] <bialix> I can relax and don't set workdir as None
[19:14] <mzz> bialix: yeah, making workdir non-optional makes it work as expected too
[19:14] <bialix> ok
[19:14] <bialix> thx
[19:15] <garyvdm> LarstiQ: How knowledgeable are you with debian packaging? Could you have a go at fixing bug 381409 in Debian?
[19:15] <vxnick> is there any plugin docs other than the two pages on the bzr website? Struggling a bit to make a plugin, despite checking things like builtins.py
[19:15] <SamB> mzz: yeah, and it's presumably not that hard to split libc6-dbg just like libc6 is split ...
[19:15] <mzz> python 3 lets you write both what you said and what jam said, and they'll behave differently when they get a single positional arg, but you probably can't use that yet.
[19:15] <mzz> and I have no idea if that feature will be backported.
[19:15] <LarstiQ> garyvdm: I expect that to be fairly involved
[19:15] <SamB> mzz: I don't think it will be
[19:16] <mzz> SamB: oh, I guess it'd be backwards incompatible for things like the inspect module, bleh.
[19:16] <SamB> mzz: I was just thinking that probably that kind of CODE already means something else in Python2000
[19:16] <mzz> SamB: no, it's a SyntaxError
[19:16] <SamB> oh
[19:16] <garyvdm> LarstiQ: Do you think you could push the bug to Debian's bug db, and nag a dd to work on it for me?
[19:16] <SamB> in that case I could see it being backported
[19:16] <LarstiQ> garyvdm: sure
[19:17] <garyvdm> LarstiQ: Thanks
[19:17] <mzz> SamB: I'd have to check, but I bet it'd make it impossible for older code to introspect functions making use of the new feature.
[19:17] <SamB> mzz: it might cause difficulties, true
[19:17] <SamB> but that's not nearly as bad as breaking everything!
[19:18] <SamB> (potentially)
[19:19] <mzz> SamB: fwiw: http://paste.pocoo.org/show/133700/ (python 3.1)
[19:19] <SamB> I don't suppose anyone here would have any sway on http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=520680 ?
[19:19] <SamB> it's marked wontfix
[19:21] <LarstiQ> SamB: I'm afraid that is not likely to change
[19:21] <mzz> SamB: his arguments aren't that good imho, but I can't help you there.
[19:21] <LarstiQ> mzz: not good?
[19:21] <SamB> hmm, I guess I'll just see if I can get #gdb involved ...
[19:22] <mzz> SamB: specifically I'm pretty sure those mozilla-related -dbg packages are huge just because the debug info for those packages is, not because there's one debug package per source package
[19:22] <SamB> some of them work at redhat, which seems to have a nice solution to the "too many -dbg packages" problem ...
[19:22] <mzz> SamB: and I don't know enough about debian to understand why "increase the number of packages in the archive" is problematic
[19:22] <SamB> mzz: psh, I don't care about the mozilla ones
[19:22] <LarstiQ> mzz: the point is, _all_ -dbg packages follow one-per-source
[19:22] <mzz> SamB: yeah, but that's over half of what he listed in response to your "what other packages are you referring to"
[19:22] <SamB> I just want libc6-dbg split by architecture like the runtimes are
[19:22] <mzz> LarstiQ: yes! it should be fixed for all of them :)
[19:22] <SamB> LarstiQ: surely that can be fixed
[19:23] <LarstiQ> mzz: eh, no
[19:23] <SamB> and he never mentioned *that* as an argument, either
[19:23] <SamB> I would have recognized that as a valid, reasonable, concern!
[19:23] <LarstiQ> euh, I thought he said that
[19:23]  * LarstiQ reads again
[19:23] <SamB> not that I could see
[19:23] <mzz> "debugging packages in Debian are all using the same layout: one per
[19:23] <mzz> source package"
[19:23] <LarstiQ> SamB: he did: Yes, debugging packages in Debian are all using the same layout: one per
[19:23] <mzz> ugh, linebreak, sorry.
[19:23] <LarstiQ> source package. A lot of them are a lot bigger than libc6-dbg.
[19:24] <SamB> oh, he did ?
[19:24] <LarstiQ> mzz: number of packages in the archive is an ongoing concern.
[19:24] <mzz> and yes, many others are bigger, but the ones he listed are bigger just because they're bigger, not because they're from a source package that's split into many binary packages.
[19:24] <SamB> oh, but then he went into that fallacy "other packages are doing the same thing, so it's fine if I do!"
[19:24] <mzz> SamB: not necessarily. It's entirely possible this is policy, not just convention. I wouldn't know.
[19:25] <SamB> if he hadn't gone and pointed the finger at irrelevant packages I would have been more well-disposed towards his argument
[19:25] <bialix> garyvdm: in side-by-side qdiff color lines becomes thickier, it's intended behavior
[19:25] <bialix> garyvdm: ?
[19:25] <mzz> SamB: that doesn't matter if it is indeed policy. You'd have to get policy changed.
[19:25] <LarstiQ> SamB: I think you parsed that wrongly
[19:25] <bialix> garyvdm: I mean green and red lines
[19:25] <SamB> LarstiQ: could be!
[19:26] <SamB> but I don't care about mozilla symbols
[19:26] <SamB> the way it dies is that I kill it for it's RAM anyway
[19:27] <garyvdm> bialix: It happens on the side where there is nothing.  The change was not intended, but, I was not too worried about it.
[19:27] <garyvdm> bialix: Would be easy to fix.
[19:27] <LarstiQ> SamB: if you can get an ok from a ftpmaster up front about splitting into more packages, you could bring that to the table
[19:27] <SamB> LarstiQ: I don't see any reason for that, though
[19:27] <LarstiQ> SamB: for what?
[19:27] <SamB> why duplicate the same source tarball three times?
[19:28] <bialix> garyvdm: I don't mind it stay, bt I've noticed because it seems I've used to old behavior
[19:28] <LarstiQ> no, not source tarball
[19:28] <mzz> SamB: again, I don't know about debian, but if the concern is about disk usage, not number of packages, I'd expect this kind of split to not hurt significantly
[19:28] <bialix> garyvdm: it's not big deal
[19:28] <LarstiQ> SamB: splitting the -dbg package
[19:28] <SamB> oh, you meant .debs?
[19:28] <LarstiQ> mzz: the concern is number of packages
[19:28] <mzz> drat.
[19:28] <SamB> something about "users"
[19:28] <SamB> was mentioned
[19:29] <LarstiQ> SamB: you are argueing with the maintainer about a point that I think will be upheld even if you escalate to a wider audience
[19:30] <LarstiQ> SamB: how small is your disk anyway?
[19:30] <mzz> the size of my /usr/ isn't that much of an issue next to the size of my /home if I don't clean it up regularly
[19:31] <SamB> oh, apparantly I reported the python-qt4 thing as #535759
[19:31]  * mzz prods ubottu 
[19:31] <SamB> oh, apparantly I reported the python-qt4 thing as debbug #535759, that is
[19:31] <SamB> how does this thing work?
[19:31]  * mzz gives ubottu a friendly pat on the head
[19:32] <SamB> mzz: I have /home on a bigger disk
[19:32] <SamB> I might possibly be able to grow /home, I'm not sure
[19:32] <SamB> er.
[19:32] <SamB> grow /usr
[19:32] <mzz> yay lvm
[19:33] <SamB> for instance, if my old /home is right after it, or my ancient HURD partition ...
[19:33] <SamB> mzz: hmm, I'm not using that
[19:33] <SamB> is it easy to start?
[19:33] <LarstiQ> SamB: parted?
[19:34] <mzz> too bad! if you were you'd be able to grow your /usr partition onto the other drive.
[19:34] <fullermd> lvm?  Is that what people use who can't get ZFS?  ;p
[19:34] <mzz> converting to it is rather a hassle though.
[19:34] <SamB> mzz: I think I'd be more likely to grow /home on that one ;-)
[19:34] <garyvdm> SamB: You have to prefix with bug. Bug 535759
[19:34] <SamB> garyvdm: doesn't work for debian bugs!
[19:34] <LarstiQ> fullermd: LVM is much older
[19:34] <SamB> debian bug 535759
[19:34] <SamB> okay, that works
[19:34] <LarstiQ> fullermd: even the Linux implementation, but I was thinking HP-UX (or maybe AIX)
[19:35] <fullermd> I know.  That's no good reason not to troll a little though   :p
[19:35] <SamB> fullermd: I thought it was called "tease"
[19:35] <fullermd> SamB: You'd have to be a lot better looking before I upgraded you to 'tease'.  Sorry.
[19:36] <SamB> I'm not even the one using LVM
[19:36] <SamB> I'm still using IBM/MS partition tables
[19:37] <fullermd> That's why we're all making fun of you, see   8-}
[19:37] <SamB> yeah, as well you should
[19:37] <SamB> that primary/extended/logical thing is *so* stupid!
[19:38] <fullermd> Pshaw.  It's brilliant; you can run DOS and CP/M on the same machine!  What more do you want?
[19:38] <SamB> how can you run CP/M on it?
[19:38] <SamB> and since when does CP/M support fixed disks ?
[19:38] <fullermd> I dunno.  I can't afford enough drugs to want to try.
[19:38] <SamB> I thought CP/M was for Z80
[19:38] <fullermd> It probably wouldn't run bzr anyway...
[19:39] <SamB> yeah, getting it to work nicely on DOS would be hard enough
[19:39] <SamB> it's not even worth trying on CP/M
[19:43] <mzz> I don't think bzr would like the 8.3 filesystem much, even if you managed to find a python that runs on dos.
[19:46] <garyvdm> http://mail.python.org/pipermail/python-list/2004-December/295818.html
[19:50] <mzz> I didn't say 16 bit dos (you could run it in an extender)
[19:51] <SamB> mzz: how about DOS 7, then?
[19:51] <mzz> http://www.caddit.net/pythond/
[19:52] <luks> wow, threading?
[19:52] <LarstiQ> opengl?
[19:52]  * bialix hopes igc will be glad to see qexport landed; it turned out to be more work than I've expected
[19:54] <SamB> hmm, the Debian policy manual doesn't have anything obvious about debug packages ...
[19:56] <bialix> garyvdm: we have 26 public q-commands now, 23 of them are equivalents to bzr CLI
[19:56] <bialix> woot!
[19:56] <garyvdm> :-)
[19:57] <luks> somebody should port qbzr to git
[19:57] <bialix> gtk lags behind ;-P
[19:57] <bialix> luks: there is QGit
[19:57] <bialix> but it's only ~ qlog
[19:57] <luks> bialix: I don't care much about using Qt, but having sensible UI
[19:58] <bialix> well, ok
[19:58] <bialix> so I've misunderstood you
[19:58] <bialix> what's the sense to port bzr-specific tool then?
[19:58] <luks> well, I miss the tools I know :)
[19:59] <bialix> you don't use bzr at all?
[19:59] <luks> I do
[19:59] <luks> but I had to deal with git too recently
[20:00] <garyvdm> luks: use bzr-git
[20:00] <luks> that would be too slow :)
[20:04] <garyvdm> bialix: I think one of the things that sets qbzr apart from bzr-gtk this that the ui is very consistent, and consistent with the cli
[20:04] <bialix> garyvdm: ?
[20:05] <bialix> oh
[20:05] <bialix> I've misread
[20:05] <garyvdm> bialix: bzr-gtk's ui is very inconsistent.
[20:05] <bialix> I've read bzr-git instead of bzr-gtk
[20:05] <bialix> yeah, I've got it
[20:06] <bialix> well, bzr-gtk was collection of different tools at first
[20:06] <garyvdm> yes
[20:06] <bialix> or maybe still is
[20:06] <SamB> bialix: still seems like it
[20:06] <bialix> so we have a big bonus in our design
[20:07] <SamB> for instance, why doesn't gmissing look anything like viz?
[20:07] <bialix> garyvdm: we have several blueprints filed, as I've discovered
[20:07] <bialix> I'll attach bug reports to them, so we can track it
[20:15] <garyvdm> bialix: For tag from qlog, I recommend working from lp:~garyvdm/qbzr/logslots . It should merge into trunk soon. The code is much easier to read.
[20:16] <bialix> garyvdm: I'll wait then
[20:16] <bialix> garyvdm: I'll start working on saving more commit data, including bugs
[20:16] <garyvdm> bialix: That will be cool.
[20:17] <bialix> I've promised to Craig to implement this
[20:17] <bialix> I should do it finally
[20:18] <garyvdm> bialix: I did mention this in a mail, but I just want to bump it. It would be cool if the was a api in bzrlib for plugins to provide a default message.
[20:19] <bialix> there is some hook
[20:19] <garyvdm> bialix: bzr-builddeb provides a default message (which it pulls from the debian/changelog file.) It would be nice if qcommit could default to that.
[20:20]  * garyvdm looks at the bzr-builddeb code.
[20:20] <bialix> I remember there was hook, but documentation does not mention it
[20:20] <bialix> jelmer: ping
[20:21] <bialix> james_w, jelmer: someone of you has implemented hook for commit message
[20:21] <bialix> I don't remember details
[20:22] <garyvdm> bialix: http://bazaar.launchpad.net/~bzr-builddeb-hackers/bzr-builddeb/trunk/annotate/head%3A/__init__.py#L105
[20:23] <bialix> MessageEditorHooks, it's about providing template for edit it by user
[20:24] <bialix> yes, it's one
[20:25]  * bialix bbl
[20:52] <Noldorin> hi lifeless
[20:53] <garyvdm> Noldorin: CTCP time reply “Wed Aug 12 05:53:21 2009” from lifeless
[20:54] <Noldorin> garyvdm: heh, fair enough
[20:54] <Noldorin> forgot he's an aussie :)
[20:57] <moldy> hi
[20:57] <moldy> can i get bzr to show relative pathnames in e.g. "bzr st"?
[21:01] <mneptok> Noldorin: uh oh ...
[21:02] <mneptok> Noldorin: lifeless is a New Zealander. and quite passionate about that point.
[21:02] <mneptok> Noldorin: he's going to go all Morgoth on you now
[21:04] <Noldorin> mneptok: woops, lol
[21:04] <Noldorin> it's all the antipodes :)
[21:04] <garyvdm> moldy: I don't think so. Why do you want to do that?
[21:05] <moldy> garyvdm: because i commonly work from a directory that is not the root of my branch
[21:05] <Noldorin> mneptok: tolkien fan too, i must presume?
[21:05] <LarstiQ> moldy: not atm, but you can restrict status output to a subdir
[21:05] <moldy> garyvdm: having relative pathnames would allow copying and pasting, and possibly make shell completion better
[21:05] <moldy> my zsh installation does not do bzr completion well :(
[21:06] <moldy> LarstiQ: ok, thanks
[21:06] <LarstiQ> moldy: looking up the bug, just a sec
[21:07] <LarstiQ> moldy: bug 30159
[21:07] <garyvdm> mneptok, Noldorin: I think lifeless currently resides in Sydney
[21:07] <mzz> moldy: yeah, the zsh I have here kinda sucks at it too. I keep typing "bbzr ..." so I get regular filename completion to work around it.
[21:07] <Noldorin> mneptok: hah, so i was right! :)
[21:08] <LarstiQ> mzz: compdef -d bzr too radical?
[21:08] <moldy> mzz: hehe, ya :)
[21:08] <Noldorin> Noldorin: well, at least an aussie in residence
[21:08] <mzz> LarstiQ: if that does what it sounds like: perhaps
[21:09] <mzz> LarstiQ: some of its completions are kinda ok, although frequently slow, like completing new files for "bzr add"
[21:09] <moldy> LarstiQ: glad to hear that this is going to change eventually
[21:11] <LarstiQ> moldy: welll
[21:11] <LarstiQ> moldy: as you see it is a low priority bug
[21:11] <LarstiQ> moldy: it would be _nice_ to fix
[21:11] <LarstiQ> moldy: but it's not entirely trivial
[21:11] <fullermd> And some of us really like root-relative paths  :)
[21:12] <LarstiQ> moldy: it lacks someone to dedicate time towards it
[21:13] <moldy> LarstiQ: i understand
[21:14] <mneptok> garyvdm: he does reside there, but is a New Zealander. if you'd like to dispute his nationality with him, i'll start making your funeral arrangements. :)
[21:14] <garyvdm> lol
[21:14] <moldy> i will keep it in the back of my head, maybe i can find the time to come up with a patch
[21:15] <LarstiQ> moldy: cool. If you do, feel free to bug me
[21:15] <garyvdm> moldy: you could try the branch linked to that bug.
[21:15] <garyvdm> lp:~jdobrien/bzr/bug30159
[21:16] <moldy> i will see. right now, i have other stuff to do (the stuff i am actually using bzr for ;), but i will bookmark it and _maybe_ come back to it ;)
[21:16] <LarstiQ> garyvdm: I don't think much happened there
[21:16] <LarstiQ> some tests
[21:16] <LarstiQ> moldy: sure, cool :)
[21:17]  * LarstiQ continues preparing for HAR
[21:17] <fullermd> Well, once you have tests, it's easy.  You just bang up a little code randomizer and run it 'till the tests pass.
[21:17] <moldy> hehehe
[21:20] <lifeless> mneptok: thanks ;)
[21:31] <lifeless> Noldorin: hi
[21:31] <lifeless> Noldorin: what was the bug number for this problem?
[21:40] <garyvdm> Hi lifeless :-)
[21:41] <lifeless> hi garyvdm
[21:41] <lifeless> hows things?
[21:41] <garyvdm> Good. You
[21:41] <garyvdm> ?
[21:42] <lifeless> pretty good; the weather can't decide if its appalling or sunny though :(
[21:46] <lifeless> jml: hi; enjoying your self/
[21:46] <lifeless> ?
[22:48] <nekohayo> hey there, how is the status/health of the bzr git translation thing?
[22:55] <mneptok> lifeless: i know the difference between Hobbiton and Alice Springs ;)
[23:03] <lvh> hi
[23:14] <nekohayo> I tried to branch pitivi's git repository by installing bzr-git and doing a "bzr branch git://git.pitivi.org/git/pitivi.git pitivi-bazaar", but I just get a huge traceback, including NameError: global name 'name' is not defined
[23:23] <thumper> jelmer: ping
[23:24] <thumper> jelmer: I was going to also ask about bzr-git and git://git.pitivi.org/git/pitivi.git
[23:24] <thumper> jelmer: probably some weird edgecase
[23:50] <Noldorin> lifeless: hey, you there?
[23:51] <lifeless> yes
[23:51] <lifeless> did you see my question?