[00:01] <somerville32> Hey. I've made Bzr quotes! :]
[03:21] <lifeless> night all
[03:22] <Peng> Good night.
[04:25] <beuno> lifeless, you wouldn't happen to be around, would you?   I'm working with Verterok on some changes to bzrlib we would like included before 1.0, and I can't commit to the bzr's branches anymore. Is there a chance I can get activated again?
[04:39] <jelmer> beuno: which bzr branch would you like to commit to ?
[04:40] <jelmer> bzr.dev isn't accessible directly - please send merge requests to the list
[04:40] <beuno> jelmer, no, we want to uplaod a branch to the group so both of us can commit
[04:41] <beuno> and it really doesn't make sense to create a new group just for this purpose
[04:41] <beuno> so we want to upload it to the bzr group, and work on it there
[04:41] <jelmer> ah, ok
[04:42] <beuno> (seemed to me like the logical workflow)
[07:04] <Kamping_Kaiser> would i be able to install bzr on a sparc running debian Etch?
[07:07] <Peng> If Python runs on it, bzr should have no problem.
[07:08] <Kamping_Kaiser> thanks
[07:08] <Peng> Bazaar has some C components for performance, but even if they didn't compile for some reason, it doesn't need them (it'll just be slower).
[07:11] <Kamping_Kaiser> bzr intalled from backports fine. thanks.
[11:27] <Peaker> If I decide to reject/destroy a branch in a shared repo, I'll get ghost revisions left, right? Is there a way to clean up such ghosts?
[11:29] <LarstiQ> Peaker: ghost revisions are the opposite, they are referred to by a branch but don't actually exist in the repository.
[11:29] <Peaker> LarstiQ: oh, how can that happen?
[11:29] <LarstiQ> Peaker: after removing a branch you have revisions in your repo that are not referenced instead, and yes you can remove those (although 'bzr gc' still isn't written)
[11:29] <gsuveg> re
[11:30] <LarstiQ> Peaker: one very good source for that is branches converted from arch, where it was almost trivial to get to that state.
[11:30] <gsuveg> bzr-gtk is broken?
[11:30] <LarstiQ> gsuveg: nafaik
[11:30] <gsuveg> gutsy and from bzr site
[11:30] <Peaker> LarstiQ: How can I remove them?
[11:30] <LarstiQ> Peaker: the remove-revisions plugin
[11:31] <Peaker> LarstiQ: ah, thanks
[11:31] <LarstiQ> Peaker: but be careful, that can also create ghosts
[11:31] <Peaker> LarstiQ: if it can't see all the branches?
[11:31] <Peaker> LarstiQ: or, how would it cause that?
[11:31] <LarstiQ> Peaker: if you tell it to remove revisions that are still used
[11:31] <Peaker> LarstiQ: Oh, I was hoping its more like "gc" :)
[11:31] <LarstiQ> Peaker: the step of figuring out which ones to use is not automated afaik
[11:31] <gsuveg> bzr-gtk: Depends: bzr (< 0.91~) but 0.92~rc1-1bazaar1 is to be installed
[11:32] <LarstiQ> Peaker: right :)
[11:32] <gsuveg> LarstiQ, sry. me sound like its a bit broken
[11:32] <gsuveg> apt sources deb http://bazaar-vcs.org/releases/debs/gutsy ./
[11:33] <LarstiQ> gsuveg: you're talking about specific situations wrt a distribution, your original statement was way broader
[11:33] <LarstiQ> gsuveg: so that probably means newer bzr-gtk debs have to be uploaded
[11:33] <LarstiQ> but bzr-gtk itself works just fine
[11:33] <dato> gsuveg: we're waiting that bzr-gtk 0.92 gets releseased, otherwise it can't be packged :)
[11:33] <LarstiQ> jelmer: ^^
[11:33] <LarstiQ> dato: oh well, that might also block a bit ;)
[11:33] <gsuveg> dato, ah.
[11:36] <gsuveg> but .91 would work with .92 not?
[11:39] <Peaker> why is ubuntu bleeding-edge not up-to-date with newest released bzr's?
[12:02] <gsuveg> dato, and on repo bzr-gtk is only the 0.90
[12:02] <gsuveg> you can edit the dependecy not ?
[12:06] <dato> gsuveg: well, it's better not to
[12:16] <jelmer> LarstiQ, Szilveszter does the releases these days
[12:16] <gsuveg> i've back to 0.90 what in gutsy is
[12:18] <LarstiQ> jelmer: k
[13:57] <lifeless> moin
[13:58] <ryanakca> Since codebrowse appears to be down, how could I get a file from revision 4 if that file is no longer versioned? I've tried bzr revert -r4 file ... but it complains about not being versioned...
[14:00] <dato> ryanakca: try bzr cat -r 4 path/to/file >file.v4
[14:02] <ryanakca> dato: thanks :)
[14:12] <lifeless> ryanakca: bzr revert -r4 file should indeed have worked;
[15:08] <lifeless> desperately seeking reviewers
[15:27] <vila> lifeless: hi :) You have two patches pending revisions, I already expressed my concerns about transport.list_dir, I didn't dig enough reconcile nor packs so far to comment on the second (stage 1 of pack reconcile)
[15:28] <vila> AIUI you plan to rework the first to avoid list_dir, if that's the case, I'd be happy to give you a +1 if that makes it happen quicker :)
[15:29] <vila> ghaa, s/revisions/reviews/
[15:52] <lifeless> vila: well, you know I disagree  on the list_dir usage
[15:52] <lifeless> there is no technical reason I know of yet to avoid list_dir for writable transports
[15:53] <vila> lifeless: ha, thanks for the precision, I was wrong then :)
[15:54] <lifeless> I plan in a future packs format to see if we can remove list_dir
[15:54] <lifeless> but for the current format there is no alternative
[15:54] <lifeless> that isn't worse.
[15:55] <vila> hmmm, so putting the webdav plugin on the back burner still depends on that then
[15:55] <vila> I'll to monitor that point more closely
[16:44] <lifeless> still, I'm seeking a reviewer for the stage1 reconcile packs patch
[16:55] <lifeless> jelmer: ping
[17:02] <jelmer> lifeless, pong
[17:19] <lifeless> jelmer: I've looked at the setup.py patch; and it seems less clean to me than th autotools it's replacing
[17:19] <lifeless> jelmer: I wanted to chat interactivvely about this, because I may be missing something
[17:31] <jelmer> lifeless: at the moment, the python package doesn't get installed at all
[17:32] <jelmer> so you're forced to run out of the source tarball
[17:32] <lifeless> right, so I want to fix that
[17:32] <lifeless> and I ocmcmented in the bug that I had no objection per se t o moving everything to setup.py if it was a net win; but thats clearly more than just fixing the bug
[17:33] <jelmer> Also, the dependency on automake just to install a few files is a bit heavy
[17:33] <jelmer> make check doesn't work currently (for me at least)
[17:34] <lifeless> what goes wrong ?
[17:35] <jelmer> let me check
[17:40] <jelmer> lifeless: never mind, looks like config-manager got deinstalled for some reason
[17:41]  * jelmer wonders if it'd be a better idea to start from scratch
[17:42] <lifeless> jelmer: with pqm ?
[17:43] <jelmer> not with pqm specifically, but the sort of thing I'm looking for myself
[17:45] <lifeless> a little more detail might help me here :)
[17:45] <jelmer> I don't need support for baz, config-manager or creating repositories and things like the current testsuite in shell, automake make it hard to add the features I am looking for (bundle support, python gpgv, loading bzr plugins, better status page)
[17:45] <ubotu> New bug: #160012 in bzr "http urllib hides programming errors related exceptions" [Low,In progress] https://launchpad.net/bugs/160012
[17:46] <jelmer> perhaps git support
[17:46] <lifeless> jelmer: so, pqm is getting cleaned up slowly;
[17:47] <lifeless> pqm does load bzr plugins - the plan is to drop all other VCS upport; support git etc via bzrlib plugins
[17:48] <jelmer> pqm doesn't load bzr plugins at the right time yet, that's what my other patch fixed
[17:48] <lifeless> bug #? I'll commit it now
[17:52] <jelmer> I don't think there's a bug #.. was a merge request I sent to you on may 23
[17:54] <jelmer> should I resend it?
[17:54] <lifeless> I've found it I think. one sec, playing with it.
[17:56] <jelmer> lifeless: We could still ditch autoconf and automake, use a simple Makefile for building the docbook stuff and setup.py for the python-specific things?
[18:06] <lifeless> PEP8 issues but otherwise fine I think
[18:06] <lifeless> (VWS after class is needed)
[18:07] <lifeless> also ou create a heavweight checkout not a lightweight one
[18:10] <jelmer> lifeless, what about using Makefile for docbook for bug 117197 ?
[18:10] <ubotu> Launchpad bug 117197 in pqm "Doesn't install required Python package" [High,Fix committed] https://launchpad.net/bugs/117197
[18:17] <jelmer> lifeless: still alive?
[18:19] <mc_> how can i tell bzr which editor to use?
[18:20] <dato> mc_: there are several ways, all explained in the tutorial. basically some environment variables (EDITOR, BZR_EDITOR)
[18:21] <dato> mc_: and the "editor" option in ~/.bazaar/bazaar.conf
[18:23] <mc_> ty
[19:06] <schierbeck> jelmer: pingz0r!
[19:11] <jelmer> schierbeck, pong!
[19:15] <schierbeck> what do you think about using commit messages to identify revisions to the user?
[19:15] <schierbeck> when they have to choose from a revision's parent
[19:17] <lifeless> that might be nice
[19:17] <schierbeck> i've sent a branch url to the ml
[19:18] <schierbeck> have a look and tell me what you think :)
[19:18] <schierbeck> currently only the toolbar buttons use it
[19:18] <jelmer> lifeless: see my comments from about an hour ago
[19:20] <schierbeck> ?
[19:20] <schierbeck> i only just sent it in
[19:20] <schierbeck> damn you're fast!
[19:20] <dato> heh
[19:20] <jelmer> schierbeck, that was about some pqm stuff
[19:20] <schierbeck> oh
[19:20] <schierbeck> :)
[19:21] <lifeless> jelmer: Sorry, eating etc
[19:21] <lifeless> I've merged your patch, it's off to people now
[19:21] <jelmer> lifeless: any thoughts wrt using make+setup.py rather than automake?
[19:22] <jelmer> lifeless, thanks for merging it
[19:22] <lifeless> done, revno 172
[19:24] <lifeless> network here sucks worse than well most things
[19:28] <lifeless> I don't entirely get the objection to automake; automake isnot huge, it's well understood
[19:32] <jelmer> It's not really aimed at installing python packages
[19:33] <jelmer> you'd have to add some magic to find the right directory to install it in, the right python executable to use, etc
[19:36] <jelmer> also, automake sucks in general imo
[19:46] <schierbeck> jelmer: don't you think we call the navigation buttons in the viz something other than "back" and "forward"
[19:47] <schierbeck> it doesn't fit with the visual representation of the history
[19:47] <schierbeck> i'd rather have "up" and "down"
[19:47] <jelmer> yeah, up and down sounds fine to me
[19:47] <dato> but history is *time* independently of how you repreesnt it
[19:47] <jelmer> I'm not so sure about using commit message to identify revisions
[19:47] <dato> and time goes forwards and backwards, not up and down
[19:47] <dato> IMHO :)
[19:48] <jelmer> there are a lot of people that don't use clear enough commit messages
[19:50] <schierbeck> jelmer: i still think it's MUCH better than, say, revision id
[19:50] <schierbeck> and i think it's good enough for now
[19:50] <schierbeck> until we find something better
[19:51] <schierbeck> dato: but normal people don't think that way
[19:51] <schierbeck> they say "i want to go down on this list"
[19:51] <dato> well. you won't convince me but, alas, I'm not the bzr-gtk maintainer. :)
[19:51] <schierbeck> user interfaces aren't about what's right, they're about what's right for the users
[19:52] <schierbeck> :)
[19:53] <jelmer> schierbeck: I'd rather not experiment like this in the branch that's used for releases
[19:54] <phanatic> schierbeck: i'm about to release 0.92 and jelmer and i were talking about broken lines (ui option to disable it would be nice to have)
[19:55] <jelmer> schierbeck: I think revno's would be a better temporary solution
[19:57] <schierbeck> jelmer: compromise -- revno's *and* messages
[19:57] <schierbeck> phanatic: i'm working on options ui right now
[19:58] <schierbeck> jelmer: you have to agree, revids are completely useless for this purpose
[19:59] <jelmer> yeah, revids aren't useful for this sort of stuff, indeed
[19:59] <jelmer> schierbeck, I think a combination is a good compromise
[20:02] <schierbeck> okay
[20:02] <schierbeck> i'm currently looking at including the branch nick as well
[20:02] <schierbeck> it works pretty good
[20:15] <Peaker> is there a way to retroactively delete large files to save space in the repo?
[20:16] <jelmer> you can remove revisions from history using the remove-revisions plugin
[20:16] <jelmer> but it's very very slow (rewrites the whole repository)
[20:18] <Peaker> so if I remove revisions that added large files, the continuations of those will be rebuilt without those large files?
[20:18] <Peaker> or will the continuations/children just be broken?
[20:20] <jelmer> In theory, yes
[20:20] <jelmer> Haven't ever done that yet
[20:21] <Peaker> yes broken or yes deleted? :)
[20:22] <jelmer> the continuations will be ok
[20:24] <Peaker> ah cool, I hope he didnt add more stuff with the big files
[20:27] <schierbeck> phanatic and jelmer: how should i turn off brokenlines?
[20:28] <schierbeck> if you could add a gproperty to viz.treeview.TreeView it would be pretty easy
[20:29] <phanatic> schierbeck: we were pondering about a button on the toolbar which would toggle broken lines (and also remember its state)
[20:30] <schierbeck> phanatic: i'd rather have it in the menu bar
[20:30] <schierbeck> people probably won't toggle it every few minutes
[20:31] <jelmer> schierbeck: that means the menu bar would have to be merged before 0.92
[20:31] <Peaker> do you think it would be a good idea to create a plugin that removes a file retroactively by recreating the entire history in the repo excluding the addition and any changes to that file?
[20:31] <phanatic> agreed. but merging the menubar branch just before release wouldn't be a good qa prectice :)
[20:31] <phanatic> practice
[20:31] <jelmer> schierbeck: which should really be released asap before bazaar 0.92 is released
[20:32] <schierbeck> jelmer: okay, we can move it to the menubar after the release
[20:33] <schierbeck> what persistence backend should we use?
[20:33] <schierbeck> the conf files?
[20:33] <jelmer> either the conf files or gconf, not sure what would make the most sense
[20:34] <jelmer> using the conf files is consistent with bazaar, using gconf is consistent with GNOME
[20:34] <phanatic> jelmer: gconf is not available on win32
[20:34] <phanatic> afaik
[20:34] <jelmer> ok, so we would at least have to support the conf files
[20:34] <jelmer> guess we can always add gconf support later, if there's a good reason for it
[20:35] <schierbeck> do we have to reload the treeview when toggling?
[20:36] <schierbeck> or can it redraw dynamically
[20:36] <jelmer> reloading would be acceptable for now I think
[20:37] <schierbeck> okay
[20:38] <schierbeck> by the way, what do you think about the menubar approach? is it something i should pursue?
[20:39] <phanatic> schierbeck: from the olive point of view, a menubar on a child window looks quite interesting :)
[20:39] <schierbeck> phanatic: i know, but i hate olive
[20:39] <schierbeck> i never use it :)
[20:39] <phanatic> many people do, love it or hate it :P
[20:40] <schierbeck> i think it's important that we can set options directly from viz
[20:40] <schierbeck> such as show/hide columns
[20:40] <schierbeck> and a go menu really makes sense
[20:41] <schierbeck> i'm only asking because i'm making some other major improvements on that branch
[20:41] <jelmer> yeah, we have to keep olive in mind
[20:41] <phanatic> that sounds reasonable. i don't have any other complaints about the menubar on viz
[20:42] <jelmer> another option would be to add a LogWindow that is specific to olive and is somewhat simpler
[20:42] <phanatic> but maybe you could allow it to be disabled
[20:42] <jelmer> now that we have all the different components available as separate widgets, that should be quite easy
[20:44] <schierbeck> yup, that sounds good
[20:44] <schierbeck> i'll continue with my efforts then
[20:45] <schierbeck> i'd like to switch to using signals and properties only
[20:45] <schierbeck> the revision-/logview especially is bad
[20:45] <schierbeck> with a custom callback mechanism
[20:46] <schierbeck> when's the next release due?
[20:46] <jelmer> all synchronised with bazaars' releases
[20:46] <jelmer> s/bazaars'/bazaars main/
[20:47] <Peaker> it could be nice to pop up kompare as the differ in the "bzr vis" dialog
[20:48] <phanatic> we agreed to do synchronised releases till bzr 1.0
[20:49] <dato> and then?
[20:50] <phanatic> bzrlib should be api stable by then, so we can walk on our own path
[20:53] <phanatic> jelmer, schierbeck: i'll do a release tomorrow, if you don't mind...
[20:53] <schierbeck> it's fine
[20:53] <jelmer> sounds good to me, provided that the broken lines feature can be turned off somehow
[20:54] <schierbeck> is there a setting one can give to the cell renderer that disables the newish stuff?
[20:54] <schierbeck> i'm not too comfortable with the cairo stuff
[20:55] <jelmer> schierbeck: you can specify the behaviour of the broken lines code using a parameter to TreeView's constructor
[20:55] <schierbeck> okay
[20:57] <schierbeck> should it be None when turned off?
[20:57] <jelmer> yes
[20:57] <schierbeck> okay
[20:57] <schierbeck> and just hardcoded to 32 otherwise?
[20:57] <schierbeck> (short-term)
[21:06] <jelmer> I'm not sure what the best value for it would be, it would depend on the branch I think
[21:06] <jelmer> I just kept 32 as default since that's what gary used
[21:10] <schierbeck> okay
[21:10] <schierbeck> jelmer: what should the toggle button be labeled?
[21:12] <jelmer> "Compact View" or something?
[21:15] <schierbeck> okay
[21:22] <schierbeck> jelmer, phanatic: pushing to lp right now
[21:22] <schierbeck> i still need to implement persistence
[21:22] <phanatic> schierbeck: cool
[21:24] <schierbeck> phanatic: i'd like to have a meeting some time in the not-too-distant future
[21:24] <schierbeck> about coding guidelines
[21:24] <phanatic> :)
[21:24] <schierbeck> things like the naming of callbacks
[21:24] <schierbeck> there are like 3 different ways being used right now :)
[21:25] <phanatic> yeah, it would be useful
[21:25] <schierbeck> i'll send a message to the ml tomorrow
[21:25] <phanatic> right
[21:26] <schierbeck> http://bazaar.launchpad.net/~dasch/bzr-gtk/brokenlines
[21:26] <schierbeck> check it out
[21:26] <schierbeck> i'll go eat something :)
[21:55] <schierbeck> jelmer: do you know how to implement the persistence layer?
[21:55] <schierbeck> i haven't looked at the api
[21:57] <jelmer> phanatic was looking at that
[21:58] <schierbeck> okay
[21:59] <schierbeck> i'll just take a look myself, it seems that phanatic has left
[22:07] <schierbeck> well, that was pretty easy
[22:07] <jelmer> you may both be working on the same thing
[22:12] <schierbeck> well, i'm already done :)
[22:12] <schierbeck> i've pushed it to the branch
[22:12] <schierbeck> http://bazaar.launchpad.net/~dasch/bzr-gtk/brokenlines
[22:13] <lifeless> ola
[22:24] <Verterok> lifeless, hola
[22:32] <lifeless> jamesh: hi, how did pending reviews go on further changes ?
[22:35] <jamesh> not sure
[22:36] <lifeless> jelmer: we need a better name for olive
[22:36] <lifeless> jelmer: it's still showing as 'olive' rather than e.g. 'bzr GUI' or something
[22:36] <jelmer> lifeless: please discuss that with Szilveszter, I don't use/develop Olive
[22:37] <lifeless> ahha, ok
[22:37] <jelmer> personally, I would rather see the integration in nautilus improved than having a standalone app
[22:38] <jelmer> but I think Olive is nice to have too - it's certainly more mature than nautilus-bzr
[22:39] <schierbeck> jelmer: i agree completely
[22:39] <lifeless> I agree that iing the nautlius integration is important
[22:39] <lifeless> s/ii/fixi/
[22:39] <schierbeck> we need more work on nautilus-bzr
[22:39] <schierbeck> i should eventually replace olive completely, if possible
[22:39] <schierbeck> *it
[22:40] <jelmer> not sure about that - olive also works on Windows and XFCE
[22:40] <schierbeck> we need better integration with the Windows file browser, too
[22:40] <jelmer> so there is certainly a place for it, until we get thunar and windows shell integration done
[22:40] <lifeless> we have a bzr tortoise for inwdows now
[22:40] <jelmer> lifeless: tortoise isn't anywhere near olive wrt functionality though
[22:41] <lifeless> till; native UI++
[22:41] <schierbeck> +1
[22:41]  * jamesh wonders why all Windows VCS plugins are called tortoise
[22:41] <jelmer> yeah, I agree
[22:41] <schierbeck> btw, i got a tango guy working on some icons for us
[22:41] <jelmer> jamesh: they're all slow
[22:42] <lifeless> ouch
[22:42] <jelmer> schierbeck: ah, nice :-)
[22:42] <schierbeck> thought so :)
[22:42] <fullermd> I wish one of them were easier to get going, though.  Every time I look at the installation instructions, it makes ME twitch, and I'm the *nix guy.  The idea of trying to point some of the graphicist Windows people I'd want to use it at that installation isn't confidence-inspiring.
[22:42] <jelmer> we need more people developing on Windows
[22:43] <fullermd> Or less people running Windows   ;)
[22:43] <jamesh> by that I take it you mean other people?
[22:43] <schierbeck> i'm with fullermd...
[22:43] <schierbeck> hehe
[22:43] <fullermd> I mean, there can't be more than a billion or so of them, right?  All it takes is a little rounding error to turn 1 into 0...
[22:43] <schierbeck> how are we doing on OS X
[22:44] <jelmer> jamesh: Afraid so, yep
[22:45] <schierbeck> jelmer: should we review and merge the brokenlines-option branch tonight?
[22:47] <jelmer> schierbeck: as long as it happens before 0.92 :-) Not sure what Szilveszters plans wrt the relaese date are
[22:48] <schierbeck> i think he wants a release tomorrow
[22:54] <lifeless> later all, meeting time
[22:54] <schierbeck> bb
[22:55] <schierbeck> well, i'm off as well
[22:55] <schierbeck> see y'all!
[23:00] <ubotu> New bug: #159997 in bzr "`bzr push` fails with error 530 (login incorrect)" [Undecided,New] https://launchpad.net/bugs/159997
[23:00] <ubotu> New bug: #160081 in bzr "KnitCorrupt: incorrect number of lines" [Undecided,New] https://launchpad.net/bugs/160081
[23:08] <siretart> jelmer: is bzr-svn supposed to support push over svn+ssh:// urls?
[23:09] <jelmer> siretart: yes.
[23:09] <siretart> jelmer: http://paste.debian.net/41505
[23:09] <siretart> not sure what's going wrong here
[23:10] <siretart> svn ls svn+ssh://svn.debian.org/svn/pkg-wpa/wpasupplicant/trunk works at least
[23:10] <jelmer> siretart: please file a bug
[23:10] <siretart> ok. what information do you need?
[23:10] <siretart> (apart from the traceback)
[23:10] <jelmer> the backtrace should be sufficient
[23:10] <siretart> ok
[23:10] <siretart> thanks!
[23:13] <siretart> filed as bug #160085
[23:13] <ubotu> Launchpad bug 160085 in bzr-svn "push over bzr+ssh:// crashes" [Undecided,New] https://launchpad.net/bugs/160085
[23:13] <jelmer> thanks