[00:07] <jelmer> hey poolie
[00:07] <jelmer> hi maxb
[00:07] <maxb> hello
[00:11] <poolie> hi jelmer, maxb
[00:49] <poolie> thanks for the reviews jelmer
[00:52] <lifeless> jelmer: if you're still aroud
[00:52] <lifeless> jelmer: can we talk about geoffs patch ?
[00:54] <jelmer> lifeless: sure
[00:55] <lifeless> so, he put that patch together based on a description of what I wanted in loggerhead
[00:55] <lifeless> I'm worried that its being parleyed into a bigger, different change.
[00:55] <lifeless> I don't think loggerhead should need to know about doing iter_tree_entries etc for the export.
[00:56] <jelmer> lifeless: I'd prefer to change this to be more flexible for other callers as well if we're going to change it, and both options seem to be roughly equally trivial
[00:57] <lifeless> jelmer: the implementation you suggested doesn't meet loggerheads needs
[00:57] <jelmer> lifeless: what's the context?
[00:57] <lifeless> jelmer: we need a generator
[00:58] <lifeless> to let us return control to the wsgi framework
[00:59] <jelmer> lifeless: but you're not actually going to stream the data, just send it all in a bulk at the end?
[00:59] <lifeless> we are streaming
[00:59] <jelmer> lifeless: the generator still takes a tarball argument, and adds the data there as well
[00:59] <lifeless> I would like it if geoffs patch were evaluated directly on its impact on bzrlib: is it sufficiently tested, will it decrease performance, or make things be structured badly.
[01:00] <lifeless> jelmer: that doesn't matter.
[01:00] <lifeless> jelmer: loggerheads tarball object is mapped to a file object that accumulates the bytes in a buffer; when each yield occurs the accumulated bytes are handed off to the wsgi stack
[01:05] <spiv> Good morning.
[01:07] <mgz> special mailing list post of the day: <http://lists.ironpython.com/pipermail/users-ironpython.com/2011-June/014868.html>
[01:10] <jelmer> lifeless: that seems more complicated than just iterating over the items and files and writing out item.tobuf() + file.read()
[01:10] <lifeless> jelmer: that would a) not work with zip files, b) not stream.
[01:11] <jelmer> lifeless: this function doesn't work with zip files anyway
[01:11] <lifeless> but the structure will
[01:11] <jelmer> lifeless: both ways stream per file
[01:11] <lifeless> shrug
[01:11] <lifeless> I don't really want to overdesign this
[01:11] <lifeless> I don't want geoff blocked on something that makes it harder for him or loggerhead
[01:11] <lifeless> and he is right now
[01:12] <lifeless> if the design is poor, we should ask him to fix it
[01:12] <jelmer> anyway, I haven't voted on this, and I don't feel strongly about it. I was just saying it seemed simpler to factor out the body of the loop, rather than creating a generator which makes things more complex imho
[01:12] <lifeless> but you seem to want to solve different problems
[01:12] <lifeless> jelmer: it requires a generator
[01:12] <lifeless> _requires_
[01:13] <jelmer> that generator can be in loggerhead
[01:13] <jelmer> and just be a three line loop
[01:14] <lifeless> jelmer: Well, that won't work for .zip files (which folk will want), because they don't have the same output model
[01:14] <lifeless> I don't think it makes sense to make the loggerhead code simpler for tarballs at the cost of needing two codepaths in loggerhead for zip/tarballs
[01:15] <jelmer> IIRC zipfiles in Python don't stream anyway
[01:16] <lifeless>                 zipf.writestr(zinfo, content)
[01:16] <lifeless> is the per-file stuff
[01:16] <lifeless> so, it needs a similar tweak to permit this in loggerhead for zip files
[01:16] <lifeless> I think writing to the file is simple and clear
[01:17] <lifeless> we can have the same contract for both generators, both live in bzrlib.export.*, and one driver for adapting them to wsgi streaming
[01:17] <lifeless> if we have /any/ tar specific code in loggerhead that won't work.
[01:17] <lifeless> which is what I don't like about your proposal
[01:17] <lifeless> mgz: win
[01:18] <lifeless> mgz: I presume you know about the great regex mistake ?
[01:20] <mgz> I thought you'd appreciate that lifeless :)
[01:21] <jelmer> lifeless: I don't see how that helps; ZipFile's constructor requires a filename or seekable file object
[01:22] <lifeless> jelmer: we manage to export to stdout
[01:22]  * jelmer gets some sleep
[01:22] <lifeless> jelmer: which is nonrewindable
[01:22] <jelmer> lifeless: charis:~/src/bzr/bzr.dev% bzr export --format=zip -
[01:22] <jelmer> bzr: ERROR: [Errno 29] Illegal seek
[01:23] <lifeless> ah! ok, so bugs to fix there.
[01:23] <lifeless> still, i think making the contract be tied to tar would be a mistake
[01:23] <lifeless> sleep well
[01:23] <mgz> the zipfile module is pretty useless unfortunately
[01:23] <mgz> it's been multiply threatened with a rewrite that's never arrived
[01:24] <lifeless> we have/had a fixed copy
[01:24] <lifeless> bbiab, grocery shopping needs doing
[01:25] <jelmer> I think one of the problems is that the zip file format requires the compressed/uncompressed sizes to be known up front
[01:25] <jelmer> anyway, really gone now.. :)
[01:26] <mgz> hm, really? I thought the header was minimal and everything that mattered was in the tail.
[01:27] <mgz> hence the gif/zip hacks.
[01:27] <jelmer> yeah, you're right
[01:27] <jelmer> wikipedia confused me because it still calls them headers
[01:28] <mgz> beheaded headers
[01:28] <mgz> they're severed and placed in a basket at the end
[06:32] <gour> i'm converting all my old repos to bzr and while doing it i just wanted to put one old project under bzr (no conversion from some other DVCS), but bzr failed with: http://pastebin.com/Jtt4HtAP
[06:52] <gour> i've found it as https://bugs.launchpad.net/bzr-diffstat/+bug/56680
[06:53] <gour> and it's more than 4yrs ago since it's reported...it would be cool to fix it before 2.4
[06:55] <gour> another one is https://bugs.launchpad.net/bzr-submit/+bug/67973
[07:02] <gour> the most recent activity in regard to this problem seems to be https://bugs.launchpad.net/bzr-explorer/+bug/735349
[07:32] <AuroraBorealis> does anyone know if launchpad will be getting a wiki?
[07:32] <AuroraBorealis> cause ive been contributing to a project on github and its a much nicer site :<
[07:34] <gour> AuroraBorealis: there is discussiion about it atm
[07:35] <AuroraBorealis> hmm
[07:35] <gour> AuroraBorealis: check https://bugs.launchpad.net/launchpad/+bug/240067
[07:37] <AuroraBorealis> i think its a bit more then low priority =/
[07:38] <spiv> AuroraBorealis: note that that the 'launchpad' project only really uses Critical, High, and Low.  https://dev.launchpad.net/BugTriage#Importance
[07:38] <gour> this is certainly one of the features i really miss in LP, but i prefer bzr much more than git
[07:39] <gour> ..which i simply cannot stand
[07:39] <gour> i even use bzr-git for fetching github projects
[07:39] <thumper> AuroraBorealis: low means it isn't being worked on by lp devs
[07:40] <AuroraBorealis> i see
[07:40] <thumper> AuroraBorealis: I'd like to see LP get a wiki...
[07:40] <thumper> but I keep spending time writing other stuff
[07:40] <thumper> perhaps I'll instigate my own 20% time
[07:40] <AuroraBorealis> cause my projects on launchpad just seem confusing compared to github
[07:41] <spiv> I'm not sure adding a large complex feature to Launchpad will automatically reduce that confusion :)
[07:42] <spiv> I agree a wiki for projects would be nice.
[07:43] <AuroraBorealis> i feel the entire website needs to be revamped hehe
[07:43] <AuroraBorealis> but a wiki just seems like another tab
[07:48] <AuroraBorealis> also i'm confused on the little history graph things launchpad branches have
[07:48] <AuroraBorealis> https://launchpad.net/inkscape for example, does it go up then right?
[07:50] <spiv> AuroraBorealis: does the larger view at https://launchpad.net/inkscape/+series make it clearer?
[07:51] <AuroraBorealis> so it seems like 'trunk' is the vertical line
[07:51] <AuroraBorealis> and they keep branching off
[07:51] <spiv> Or for comparison, https://launchpad.net/bzr/+series
[07:52] <AuroraBorealis> but am i right that it seems the main trunk branch is on the left?
[07:52] <spiv> The bzr example is a bit more interesting perhaps because you can see the dates of releases from different series overlapping.
[07:52] <spiv> It's not a graph of branches or revision history.
[07:53] <AuroraBorealis> so its just a graph of versions?
[07:53] <AuroraBorealis> or 'series'
[07:53] <spiv> It's a visualisation of release series and their milestones.
[07:53] <AuroraBorealis> ah. k
[07:53] <AuroraBorealis> so i take it launchpad doesn't have a graph of revisions
[07:55] <spiv> Someone really ought to integrate one into loggerhead.  You can browse the revision history by following the “Browse the code” link on e.g. https://launchpad.net/inkscape
[07:56] <spiv> It doesn't yet do the sorts of pretty graphs you get with bzr GUIs like 'bzr qlog', but I'm sure someone will do one for it eventually.
[07:56] <AuroraBorealis> which take like 5 clicks to get to
[07:56] <spiv> Which do?
[07:56] <AuroraBorealis> to get to the link to 'view all revisions' hehe
[07:56] <AuroraBorealis> and yeah i was just using github to contribute to some project and i liked their revision graph
[07:56] <spiv> I count 2 clicks.
[07:57] <spiv> From https://launchpad.net/inkscape click “Browse the code”, from there click “view branch changes”
[07:57] <AuroraBorealis> ah that. i clicked code at the top
[07:58] <spiv> Yes, it's a nice graph.  Fortunately you can get the same thing in a local GUI via 'bzr qlog' (qbzr plugin) or 'bzr viz' (bzr-gtk plugin).
[07:58] <AuroraBorealis> yeah i use bzr explorer which i think has qlog in there
[07:58] <AuroraBorealis> https://github.com/sr/git-wiki/network is sweet :>
[07:58] <spiv> Which isn't quite as convenient as having it in a web page, but it's good enough for me at least.
[08:01] <AuroraBorealis> yeah
[08:07] <AuroraBorealis> geez branching the bzr source is taking forever xD
[08:12] <spiv> Have you done "bzr lp-login"?
[08:12] <AuroraBorealis> i have not
[08:12] <AuroraBorealis> is that why its taking forever?
[08:14] <thumper> AuroraBorealis: yes
[08:14] <thumper> AuroraBorealis: it'll be going over http
[08:14] <thumper> AuroraBorealis: instead of the bzr+ssh protocol
[08:14] <AuroraBorealis> doh
[08:14] <AuroraBorealis> well i'll do that after it finishes
[08:16] <AuroraBorealis> does it not need my password?
[08:16] <thumper> AuroraBorealis: it needs an ssh key on LP
[08:16] <AuroraBorealis> yeah i have that
[08:16] <thumper> then you're good
[08:16] <AuroraBorealis> but i just typed launchpad-login <username> and it didnt output anything
[08:19] <aurora|game> it seems to be working. thanks =)
[08:22] <gour> aurora|game: have you tried github's bug tracker?
[08:22]  * gour grins :-)
[08:47] <AuroraBorealis_> sorry gour , no i have not, is it crappy?
[08:49] <gour> AuroraBorealis_: i'd say, yes
[08:49] <gour> it cannot compare with LP's features
[08:50] <AuroraBorealis_> haha
[08:50] <AuroraBorealis_> cool.
[08:51] <AuroraBorealis_> im just experimenting with a lot of stuff. I like bzr cuase i can host my private code (stuff for school) on my own server and stuff
[09:00] <gour> AuroraBorealis_: i used darcs for many years, tried hg, touched git, played with monotone and recently used fossil, but now i'm moving to bzr which is simply the most intuitive & complete dvcs ("..for human being.")
[09:04] <AuroraBorealis_> hehe
[09:04] <AuroraBorealis_> yeah, i like it
[09:05] <AuroraBorealis_> plus its python, git seems to be very linux centric.
[09:05] <gour> darcs was(is) great tool, but it does not have LP or any similar, even less featured, public hosting solution
[09:05] <AuroraBorealis_> never heard of darcs
[09:06] <gour> git looks to me as a big hack, without real design behind it...monotone is nicely designed, but it's niche
[09:06] <AuroraBorealis_> i installed git
[09:06] <AuroraBorealis_> and it installed a shitty ssh.exe to my path which screwed up bazaar
[09:06] <gour> AuroraBorealis_: http://darcs.net/ it has patch theory and it's quite different and very intuitive
[09:06] <gour> bzr is 'sweet spot'
[09:07] <AuroraBorealis_> yeah =)
[09:45] <jelmer> gour: still there?
[09:45] <jelmer> gour: those two bugs you mentioned are unrelated to the issue you're seeing
[09:46] <gour> jelmer: yeah, i'm here
[09:47] <gour> hmm
[09:47] <gour> last one is relevant?
[09:47] <jelmer> gour: they're indeed UnicodeDecodeError tracebacks too, but raised from a different location
[09:47] <jelmer> gour: the bzr-explorer one?
[09:48] <gour> yes
[09:50] <gour> so, it looks all are from different locations, but same symptoms
[09:54]  * gour was pointed at the right one - https://bugs.launchpad.net/bzr-explorer/+bug/735349
[09:55] <gour> ahh...wrong one
[09:55] <gour> this one is correct: https://bugs.launchpad.net/bzr/+bug/715547
[10:31] <spiv> maxb: around?
[10:31] <jelmer> 'morning spiv
[10:34] <spiv> Good evening jelmer :)
[10:53] <gour> seeing that SF has support for web pages and wiki, i wonder what do you think about LP vs SF for hosting projects under bzr?
[10:54] <spiv> Depends on what your project needs.  You can always use both of course!
[10:54] <spiv> I find the SF bug tracker to be much, much worse than LP's.
[10:56] <gour> problem is that LP does not have neither space for web page nor wiki
[10:56] <fullermd> Not only that, it doesn't even provide CVS.
[10:57] <spiv> Sure.
[10:58] <gour> i do not worry for lack of CVS :-)
[10:58] <spiv> It is an issue for many projects.  Some are small enough that a link in the project description to the contents of the README file in bzr is plenty, and some are large enough that they have their own website anyway.  But there's a big set of stuff in between those that want that sort of feature, and LP doesn't yet cater well to that.
[10:58] <gour> but LP is the only one from {github,bitbucket, google,sf,lp} missing wikis
[10:59] <spiv> Sure.  We know.
[11:00] <spiv> Pretty much everyone thinks LP should have them too, including the LP dev team I think :)
[11:00] <gour> and the 'bug' is quite old already
[11:01] <spiv> Right.  The paid LP devs are already pretty busy with other work: <https://dev.launchpad.net/RoadMap>
[11:01] <spiv> But if someone were to help write the necessary bits I'm sure it'd be welcomed!
[11:02] <gour> lack of wiki is turning many people to 'competition' which is sad
[11:02] <spiv> It would be nice to have, but getting free or cheap webhosting elsewhere for those bits isn't too hard, so I understand why it isn't an urgent priority for the LP team.
[11:03] <spiv> Is it?
[11:04] <gour> i believe it is...having code on one site, tracker on another, wiki on the 3rd...not pretty
[11:04] <gour> considering that other hostings have all-in-one
[11:04] <gour> {github,bitbucket, google,sf} probably support wiki with a good reason ;)
[11:08] <lifeless> wiki != webhosting fwiw
[11:08] <gour> lifeless: i'd be satisfied with just having wiki on LP
[11:09] <lifeless> well, its getting specced at the moment
[11:09] <lifeless> its still ill defined what that actually means
[11:09] <gour> even just to render sphinx-generated pages
[11:10] <gour> lifeless: why don't you inspect what's offered at {github,bitbucket, google,sf} instead of reinventing the wheel
[11:10] <lifeless> gour: uhm, we have and are?
[11:10] <spiv> gour: what makes you think that's not happening?
[11:10] <lifeless> gour: they all have quite different offerings
[11:11] <lifeless> gour: and none of those commercial, proprietary services have been kind enough to share their user and market needs analysis with us.
[11:12] <gour> the point is the many people/projects would like to have wiki, that's why {github,bitbucket, google,sf}  have it...it's only question to adjust to the LP
[11:12] <gour> here i'd say that "even blind uncle" applies
[11:12] <spiv> gour: if it's that easy, then please go ahead and do it!
[11:12] <spiv> gour: it's open source, and patches are certainly welcome.
[11:13] <gour> it's not that the rest of LP is perfect in the 1.0 release
[11:13] <gour> spiv: i do not have neither required skills nor time to work on it...wikkid is a project launched for that purpose, afaik
[11:14] <spiv> gour: Ok.  Apparently no-one else has had the skills and time yet either, though.
[11:14]  * gour is thankful to have free LP, but lack of wiki might move me to SF
[11:15] <spiv> Which, as one of those people who also lacks the time, I completely understand!
[11:15] <gour> spiv: pls. don't think i am criticizing LP...just want to improve it...because, let's face it - less LP customers also means less bzr ones
[11:15] <lifeless> gour: we want it, but we want it done well. Getting a free wiki with links to it from LP is -dead- easy - heck we even model links to the wiki in LP today.
[11:16] <fullermd> I note that when I put a project on SF, I don't think it had any wiki support.  And I think it's had 3 different wiki generations since then.
[11:16] <gour> i strongly believe github is not popular just because of git
[11:17] <spiv> gour: I agree, github does many things quite well
[11:17] <gour> fullermd: how are you satisfied with SF & bzr?
[11:17] <fullermd> Well, I've never yet used bzr on SF.  My project there is in CVS   :p
[11:18] <lifeless> we're not short on desire, we're short on elbow grease; doing a system that will run 20K wikis with no page renders over 5 seconds and 99% under 1 second, no single points of failure and embeddable in the same domain [so entirely xss free] is -nontrivial-
[11:18] <maxb> spiv: Now I am
[11:18] <fullermd> Their docs on bzr aren't seemingly maintained at all.  Last I looked, they still said they support bzr 1.10, when it was easy to tell they were running 2.1 or 2.2.
[11:18] <spiv> maxb: oh hey, I was just having a temporary thinko with the kde-l10n-* command
[11:19] <spiv> maxb: it's requeued now, although I see kde-l10n-th has developed a new and interesting failure
[11:19] <spiv> Perhaps an empty bzrdir on LP or something as a remnant of the previous failures?
[11:20]  * maxb looks at kde-l10n-th and thinks "WTF!?"
[11:21] <gour> according to wikipedia, github was launched in feb 2008, and wiki 'bug' at LP is from june same year
[11:21] <spiv> maxb: previous line in log is about opening the working tree for kde-l10n-th/karmic-backports
[11:22] <lifeless> gour: yes, the desire has been around a while
[11:22] <spiv> gour: I'm really not sure what your point is?  LP does many things github doesn't, like PPAs
[11:23] <spiv> gour: because while they may have overlapping goals, they also have differing ones too, and accordingly differing priorities.
[11:23] <gour> spiv: aren't PPAs rlevant only for Ubuntu?
[11:23] <spiv> gour: they're pretty relevant to where the LP dev spend their time as well :)
[11:23] <gour> spiv: maybe only to change priority from Low :-)
[11:24] <spiv> gour: see https://dev.launchpad.net/BugTriage#Importance
[11:25] <lifeless> gour: low is accurate: we're not going to try and make this happen using paid developers in the next 6 months. And as priorities change, we don't try and assess priorities more than 6 months out.
[11:25] <gour> spiv: Low - We mark as Low any bug that we recognise as legitimate but that we have no plans to fix.
[11:25] <spiv> gour: right — and the paid LP team doesn't plan more than 6 months in advance.
[11:26] <spiv> (Not in this sense, at least)
[11:26] <lifeless> hmm, I think thats confusing
[11:26] <lifeless> so I will edit
[11:27] <gour> and it's already 3years...the whole point, and here i can stop from my side, is that lack of wiki at LP causes harm to the LP & bzr since people/projects needing one go to {bb,github.sf, google}...
[11:28]  * gour is researching about SF now...
[11:28] <spiv> gour: sure, but so do all the other bugs and missing features of LP
[11:28] <spiv> gour: and so far it's been the opinion that those are even more important to address using the finite resources available
[11:29] <spiv> Your opinion is obviously different, but stating it here isn't going to change matters.
[11:29] <gour> one of the first hits - http://amanica.blogspot.com/2011/05/bazaar-on-sourceforgenet.html
[11:30] <gour> spiv: i'm aware of it and won't discuss it any longer
[11:30] <spiv> You could try to advocate for it on the launchpad-dev list perhaps.  If you present evidence that it really is a huge factor in driving potential users away that would be useful I think.
[11:42] <spiv> maxb: those kde-l10n-* are failing due to branches on LP that are just empty directories, not even a .bzr dir.  I guess we try deleting them from LP and requeuing.
[11:42] <EM03> why bzr over git?
[11:43] <EM03> git is faster? I mean whats a killer feature?
[11:43] <spiv> Many people find it nicer to use.
[11:43] <EM03> an example?
[11:49] <Riddell> poolie: I still can't access jubany, what's the rt URL to complain on?
[11:49] <gour> EM03: git help log vs. bzr help log ;)
[11:49] <EM03> hehehe
[11:50] <EM03> i know git very well and its quick just curious why one would choose bzr
[11:50] <gour> "it's for human being"
[11:50] <EM03> can i have an example were thats true?
[11:50] <EM03> (not saying it isn't)
[11:51] <gour> i'm spoild by darcs ui, and bzr is quite pleasant to use...with git one has to think too much about the tool
[11:51] <gour> git's ui, model...
[11:51] <gour> EM03: have you tried monotone?
[11:53] <gour> e.g. i tried to become power user of orgmode, but it required too much time...otoh, taskwarrior was so intuitive...same with git vs. bzr
[11:53] <gour> EM03: otoh, if you like git, be free to continue with it ;)
[11:53] <maxb> spiv: Right - if only all the failures were that easy :-)
[11:54] <EM03> gour: not that I'm in love with it just want to see se bzr is better :P
[11:56] <gour> EM03: just try to use it for some time and don't think that some extra ms are worth the effort to think how to avoid shooting one's own feet ;)
[11:56] <EM03> oh gour , you make it sound so easy
[11:56] <gour> EM03: on which platform you are?
[11:57] <gour> EM03: http://doc.bazaar.canonical.com/bzr.dev/en/mini-tutorial/index.html
[11:58] <gour> and http://doc.bazaar.canonical.com/bzr.dev/en/tutorials/tutorial.html
[11:58]  * gour was playing with bzr when changing the format was the rule :_)
[11:58] <spiv> maxb: still failing; but updated
[11:58] <spiv> s/but/bug/
[11:59] <maxb> "There is already a branch merge proposal registered for branch lp:~ubuntu-branches/ubuntu/hardy/kde-l10n-th/hardy-201106020937 to land on lp:ubuntu/hardy/kde-l10n-th that is still active."
[12:00] <jelmer> gour: we still seem to have that image, while in fact the last change of the default format was quite some time ago (2 years?)
[12:02] <gour> jelmer: yeah, labelling is hard..just ask lightttpd guy about memory leaks
[12:02] <gour> *guys
[12:03] <fullermd> Funnily enough, every time I use monotone, I get another round of "sorry, I can't do anything until you 'mtn db migrate' to update the database structure".
[12:03] <gour> i'm also tired about git's tspeed-talk as it's the only relevant feature of dvcs
[12:03] <maxb> tspeed-talk?
[12:03] <gour> speed-talk
[12:04] <gour> fullermd: heh, foosil borrowed some stuff from mtn
[12:04] <gour> *fossil
[12:04] <maxb> Well, in fairness to git, there are some applications where I'd rather use bzr, but am compelled to use git for the performance
[12:04]  * gour cannot type properly... :-/
[12:04] <lifeless> maxb: you know jam will fix those :)
[12:04]  * gour does not work on kernel-sized projects ==> no need for git
[12:05]  * maxb is keeping the revprops tree of a Subversion repository with >1 million revisions in Git
[12:05] <maxb> bzr doesn't really like a tree with >1 million files and 1.9GB in size
[12:06] <lifeless> maxb: hmmm, it should handle it
[12:06] <lifeless> maxb: the dirstate would be sizable
[12:06] <maxb> It probably can handle it, but not quickly enough to be palatable for a human user
[12:07] <maxb> Even git is far from instantaneous on a tree that size
[12:07] <lifeless> sure
[12:07] <lifeless> file a bug ?
[12:07] <lifeless> gnight all
[12:09] <maxb> A bug on "Performance on big trees does not compare favourably to Git" feels a bit like bug
[12:09] <maxb> A bug on "Performance on big trees does not compare favourably to Git" feels a bit like bug 1
[12:12] <maxb> jelmer: You seem to have push --overwritten me in pkg-bazaar/bzr/2.4 :-/
[12:12] <lifeless> maxb: 'bzr takes 60 seconds to st a 1M file tree with hot cache'
[12:12] <lifeless> maxb: you don't need to say git in there at all
[12:12] <maxb> fair enough
[12:19] <jelmer> maxb: Yeah, sorry about that - I'd already done the merge locally too, with some additional changes and there weren't any other changes than the merge
[12:20] <jelmer> I tried merging your branch, but I got conflicts on the generated files so I opted to --overwrite instead
[12:33] <maxb> Unfortunately those revisions are already merged into the beta-ppa branches
[12:34] <maxb> I guess I'll sort out a merge
[12:38] <jelmer> maxb: sorry, I hadn't realized it was there as well
[15:47] <deni> hi guys
[15:47] <deni> can anyone tell me how to start the freaking olive gui? i installed bzr-gtk which should be the package for olive
[15:53] <maxb> Not any more. Olive has been split from bzr-gtk and is now a wholly separate project
[15:54] <deni> maxb: can i find it debain repos?
[15:56] <maxb> I am uncertain whether it has been packaged
[15:56] <maxb> I'd search on the BTS, but bugs.debian.org seems to be down right now
[15:56] <jelmer> I'm pretty sure it's not packaged
[15:57] <maxb> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=598703
[15:57] <deni> on the main page it says i can install it via leeny-backports
[15:58] <deni> i tried to install bzr via squeeze backport and i don't think it installed any gui frontends
[15:59] <jelmer> deni: it should install a olive-gtk executable in /usr/bin
[16:00] <deni> jelmer: nope
[16:00] <deni> also it can't find it in the repos
[16:01] <jelmer> deni: it's there, see http://packages.debian.org/lenny/all/bzr-gtk/filelist
[16:02] <deni> i hva the bzr-gtk package
[16:02] <deni> ]don't know how to start that though
[16:02] <deni> autocomplete says there is no olive or bzr-gtk app
[16:03] <jelmer> deni: it's not in squeeze, you need the lenny package
[16:06] <deni> jelmer: still not luck
[16:06] <deni> meh
[16:06] <deni> will try tomorrow
[16:06] <deni> thank for your help
[16:06] <jelmer> deni: see that page, it's definitely there in the lenny package
[16:07] <deni> jelmer: ok, tnx
[16:08] <jelmer> deni: that said, I'm not sure if it will work with newer versions of bzr, for example
[16:08] <jelmer> you might have more luck just pulling down the source from lp:olive
[16:11] <Riddell> jam: able to take another (hopefully final) look at https://code.launchpad.net/~jr/bzr/598572-zlib-error/+merge/62966 and https://code.launchpad.net/~jr/bzr/707274-commit-message-hook/+merge/62334 ?
[16:34] <jelmer> hi Riddell
[16:34] <jelmer> Riddell: It's ascension day here in .nl, IIRC John is away for the next couple of days
[16:35] <Riddell> ah, religion leaving us without a patch pilot
[16:40] <ovnicraft> hello i am testing a bzr oodifff plugin i get this error: http://pastie.org/2009130
[16:40] <ovnicraft> i cant fixed so i see is based in bzr api
[16:40] <ovnicraft> any hits to fixed ?
[16:40] <ovnicraft> fix it ?
[16:43] <ovnicraft> its in your doc http://doc.bazaar.canonical.com/plugins/en/oodiff.html
[16:45] <jelmer> Riddell: reviewed the zlib error MP
[16:45] <jelmer> ovnicraft: hi
[16:45] <ovnicraft> jelmer, hi
[16:46] <ovnicraft> i see in that plugin is trying to use get_default_plugin_path()
[16:47] <ovnicraft> jelmer, can you help me  ?
[16:59] <Riddell> jelmer_: what does it mean if you approve it in your review but the status is still Needs review?
[17:06] <maxb> Usually means the reviewer forgot that LP's review model has that distinction :-)
[17:10] <jelmer_> Riddell: what Max says, it means I'm stupid :)
[17:10] <Riddell> groovy, I'll self approve
[17:16] <ovnicraft> hello i have this error with my oodiff plugin http://pastie.org/2009303
[17:17] <ovnicraft> bzr needs any explicit configuration with ASCII ?
[17:17] <jelmer> ovnicraft: that looks like a bug in the plugin
[17:17] <jelmer> ovnicraft: please file a bug against the bzr-oodiff project
[17:18] <jelmer> hmm, it doesn't appear to have been touched since 2009 :-/
[17:18] <ovnicraft> jelmer, yes
[17:18] <jelmer> Riddell: ooh, that builddeb hook is neat
[17:18] <ovnicraft> and i want to support it
[17:19] <ovnicraft> jelmer, method implemented is working now
[17:20] <ovnicraft> jelmer, you can see the method http://paste.pocoo.org/show/399537/
[17:21] <jelmer> ovnicraft: I think you need to pass in plain strings to the diff function
[17:22] <jelmer> the XML document probably contains unicode strings, which you'd have to encode (to utf-8, perhaps?)
[17:22] <ovnicraft> so i need encode to utf-8 my files ?
[17:23] <jelmer> no, in bzr-oodiff before you call text_differ(), you need to encode the strings you pass to it
[17:25] <jelmer> from_text = [l.encode("utf-8") for l in from_text]
[17:26] <ovnicraft> so with utf-8 files encoded is working ok
[17:26] <jelmer> cool :)
[17:27] <ovnicraft> now will apply your changes and see waht happen
[17:27] <ovnicraft> what*
[19:16] <dcoles> Hm. Here's a bit of a worrying one. Should bzr-svn ever eat a svn revision.
[19:16] <dcoles> As in running svn log on trunk shows the revision yet bzr log doesn't.
[19:17] <jelmer> dcoles: there's an open bug report about that - it's fixed in zbr-svn trunk
[19:18] <jelmer> at least, if I think it's the issue I think you mean
[19:18] <dcoles> Basically the svn revision appears invisible to bzr-svn (I can't -rsvn:# it)
[19:19] <dcoles> It resulted in a rather interesting "Why did you revert my change. I didn't revert anything. You never made that change" *grin*
[19:20] <dcoles> I'll try trunk.
[19:21] <jelmer> dcoles: it's a race condition
[19:21] <jelmer> dcoles: upgrading to trunk won't fix the earlier revision, but it will prevent the race in the future
[19:33] <dcoles> Was that lp:515850
[19:33] <dcoles> Bug #515850
[19:33] <jelmer> yep
[21:06] <jjohansen> I have been trying to setup a git clone of a bzr tree and have run into a problem.  Basically the tree has some tags with ~ in the name which git doesn't like
[21:07] <jjohansen> is there any way to work around this?
[23:12] <rattasak> Hi, I just started using bazaar and believe i am misunderstanding something about shared repositories.  i have a project with code files in ~/projectA.  i create a repo on a mapped network drive by using 'bzr init-repository --trees /drive/repo' and then create an branch for the project i want to track in the repo using 'bzr init /drive/repo/projectA'
[23:13] <maxb> jelmer: https://code.launchpad.net/~dulwich/dulwich/unstable mirroring has stopped due to the failure of alioth. Could you update the URL to include a /bzr/ path segment and restart it?
[23:13] <rattasak> i then do 'bzr checkout /drive/projectA projectA'
[23:13] <rattasak> add and commit the files in that working directory using bzr add and bzr commit
[23:13] <rattasak> but when i check the repo at /drive/repo, i don't see a working tree there
[23:14] <maxb> Ok, so a couple of things
[23:14] <maxb> First, why would you even want a working tree on a shared drive?
[23:14] <maxb> Second, the act of sending revisions to a remote branch does not cause its working tree to be updated.
[23:15] <rattasak> ah, reliability of the network drive is a slight issue atm so i would like to have a working copy there in case the history files get corrupted during the push (which is something i'll fix with the network drive soon and is not ideal)
[23:15] <rattasak> ah
[23:16] <rattasak> doing a commit locally on something that was checkouted does a puch to the corresponding remote branch right?
[23:16] <rattasak> push*
[23:16] <maxb> Yes
[23:16] <rattasak> i see
[23:18] <rattasak> is there a set of conditions or a command to explicitly update the remote working tree?
[23:19] <maxb> "bzr update"
[23:19] <maxb> https://launchpad.net/bzr-push-and-update may be of interest to you
[23:19] <lifeless> (run on the remote machine)
[23:20] <maxb> Although I'm not sure it will work with a checkout, from its description
[23:20] <rattasak> aaah gotcha, bzr update within the repo's working tree then (e.g. /drive/repo/projectA)?
[23:21] <maxb> Yes
[23:22] <rattasak> aah great!  just tried it out.
[23:22] <rattasak> thanks for both of your guys help
[23:22] <maxb> Although, as a backup methodology, I think you would be better off setting up an automatically updated copy of the *branch* elsewhere
[23:22] <rattasak> ah i see
[23:23] <rattasak> maybe do a sync instead of the local working directory?
[23:23] <rattasak> sync with an external program i mean
[23:23] <maxb> It is usually a lot better to use "bzr push" or "bzr pull" than an external program
[23:24] <maxb> You cannot guarantee that an external program will do the right thing if the source is being written to
[23:26] <rattasak> push to a standalone branch stored elsewhere?  (if standalone branch means something not stored within a repo...i am migrating from hg so my terminology is a little mixed up)
[23:28] <maxb> Yes (and yes, that's what a standalone branch is)
[23:29] <rattasak> ah ok.  thanks for your help clearing that up for me.
[23:31] <poolie> hi all