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