[00:00] jelmer: how much of a good idea is upgraded dulwich? [00:01] igc: thanks [00:01] wow, vila went crazy on the bugs [00:01] hello igc [00:01] want to catch up some time? [00:02] spm: ping [00:02] spm: balleny's pqm is dying [00:03] Permission denied (publickey). [00:03] igc: think you could look at https://code.edge.launchpad.net/~jameinel/qbzr/bug_430232_early_qapp/+merge/11831 ? [00:03] I think the backtrace is a furfy [00:03] I'd like to get it into a bzr installer tonight if at all possible [00:03] jam: shall do [00:03] mmmmmm furfy [00:04] poolie: let me look into these bugs for jam. Call around lunch time ok? [00:04] fine with me [00:05] jelmer: why is the trunk dulwich branch on LP registered as remote? [00:08] thumper: most of jelmer's branches are ;-) [00:09] he likes to keep them on samba.org for some reason [00:09] who does the os x installers now? guillermo? [00:12] SamB, thumper: I'm pretty sure jelmer wants people to get "the absolute latest" when they do "bzr branch lp:dulwich" and not a potentially 5-hours out-of-date mirror [00:12] That was the argument he gave earlier for bzr-svn, IIRC [00:12] since he doesn't want to directly host them on lp [00:14] why ever not? :) [00:14] we're open now :) [00:16] most of *my* mirrored branches are supposed to update hourly [00:16] thumper: probably he likes having direct access to the part of the filesystem on which he keeps them ? [00:17] well, more direct, I mean [00:17] jml: Around? [00:17] emmajane: btw if you're around i have checked the moderation queues and there's nothing interesting held there [00:17] of course, 2/3 of my mirrored branches are mirrors of SVN branches [00:18] and the other one of a branch that launchpad never manages to pull [00:19] well, that's calculated by project and not by branch, actually [00:20] lifeless, yes [00:20] ... though *one* of those SVN mirrors is not strictly read-only [00:20] ... if anyone has any dosemu branches they'd like merged, don't hesitate to submit a merge request ;-) [00:26] jam: that patch looks good to me [00:26] igc: so do you know what the 0.14 branch is for? [00:26] Is qbzr going to be doing a stable branch as well? [00:27] jam: 0.14 is the branch for karmic [00:27] jam: and the Windows 2.0.0 release as well [00:27] igc: sure, I was just wondering if the plan was for 0.14.x to be part of the 2.0.1+ releases as well [00:28] jam: I suspect 2.0.1 with go out with qbzr 0.15 but that's up to bialix and garyvdm to make that call [00:28] jml: http://rbtcollins.wordpress.com/2009/09/16/back-from-hiatus/ [00:29] igc: well technically it is probably up to me, since I'll likely be doing the packaging :) [00:29] jam: I'm certainly planning for explorer 0.9, not 0.8.x, to go out with 2.0.1 [00:29] jam: :-) :-) [00:29] jml: I thought you might either a) know of something, or b) have thoughts on the proposition [00:29] but usually I just follow the recommendations [00:29] rebooting for karmic [00:30] jam: do you want me to merge that change to 014? Or is your connectivity good enough? [00:30] igc: I'm landing it now [00:30] I'm not sure what it will take to do a 0.14.2, though [00:30] so I may just take it and do 0.14.1-win32-1 [00:31] igc: is dancingmonkeys continually updated? [00:32] jam: what do you mean by that? [00:32] it's just a branch I push after making edits [00:32] igc: how often does http://people.canonical.com/~ianc/dancingmonkeys/ update [00:32] whenever I manually update it [00:33] emmajane has the master branch - my stuff is just suggestions/experiments [00:34] lifeless, looking... [00:44] jml: thanks [00:44] lifeless: should be happening again [00:50] spm: what is needed for subunit in the chroot ? [00:51] lifeless: aiui, a package built; but I'm not across all the details; so that's a pretty handwavy response. [00:51] spm: all we need is python-subunit [00:51] you have packages of that :) [00:51] not for dapper, aiui [00:52] shouldn't matter [00:54] spm: you should be able to just dpkg -i the python-subunit package [00:58] spm: can you do a manual push from balleny +trunk ? [00:59] lifeless: I believe it also had a requirement on python-central which also wasn't in dapper. tbh, these may be trivial workarounds. I know that lamont and tom have been working on this stuff, so I'm kinda coming in with a fraction of the picture here. [00:59] bzr trunk? sure. one sec. [01:00] spm: did it have any revisions to push ? [01:00] lifeless: Pushed up to revision 4690. [01:00] 5 commits old >< [01:00] it had had a push branch location of you@escudero if that helps? [01:00] no [01:01] thats the old location [01:01] k [01:01] you should save the new ones [01:01] did on this case; it seemed the right thing to do :-) [01:01] pqm uses the configured value in the pqm.conf though, so that shouldn't have mattered [01:02] hang a sec.... $ bzr push --remember bzr+ssh://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev ;; yet still shows: push branch: sftp://robertc@escudero/srv/www.bazaar-ng.org/rsync/bzr/bzr.dev [01:02] is that an issue? or did I syntax it? [01:02] check ~/.bazaar/locations.conf [01:03] ahhh. right. I see - I guess THAT should also be updated. [01:03] or removed [01:03] [the stanza not the file] [01:03] :-) [01:04] statik: http://elliotmurphy.com/ is down? [01:05] lifeless: that stanza has post_commit_to bits; I assume that no longer matters now via LP [01:05] correct [01:05] uhm [01:05] actually [01:05] lp's pqm uses lp notifications [01:05] I think we still get the ones to bazaar-commits. [01:05] whats the stanza? [paste it somewhere] [01:06] [/home/pqm/archives/thelove/bzr/+trunk] [01:06] post_commit = bzrlib.plugins.email.post_commit [01:06] post_commit_to = bazaar-commits@lists.canonical.com [01:06] push_location = sftp://robertc@escudero/srv/www.bazaar-ng.org/rsync/bzr/bzr.dev [01:06] small enough to go here [01:06] delete the post_commit and push_location lines [01:06] kk [01:06] the former is deprecated the latter wrong :P [01:06] heh [01:07] info -v looks much happier. ta [01:14] bzr.dev/bzrlib/osutils.py:928: UserWarning: bzr: warning: Failed to load compiled extensions: how do I compile these extensions? [01:16] BasicOSX: 'make' [01:17] pages and pages of errors under os x :-( [01:17] hmm [01:17] there is an installer for os x [01:17] you might want to look at the docs on how that is built, and follow that process [01:17] defeats the purpose for running bzr.dev by using installer :-) [01:18] nono [01:18] I'm not saying use the installer [01:18] I'm saying follow the docs on how to build it [01:18] to get a built bzr [01:20] That doesn't seem very pythonic ... whole reason I picked bzr was simple install and go. If I wanted to compile stuff I would have picked git :-( I hope there was magnitude performance increases by going with .pyx [01:20] poolie: hi [01:20] BasicOSX: so, I think you can squelch that warning [01:21] I think poolie: ^ might know [01:21] BasicOSX: and yes, _huge_ performance differences [01:21] BasicOSX: we do run fine without the extensions. [01:21] yes, done already, just venting on simple (slow) vs complicated and fast [01:21] hi verterok [01:22] BasicOSX: my personal vent is on python being slow :) [01:22] poolie: re: os x installers, what's up? :) [01:22] BasicOSX: 'echo ignore_missing_extensions=True >> ~/.bazaar/bazaar.conf' should do it [01:22] hi verterok [01:23] BasicOSX: it is much faster so the point is to just make sure people are making an informed choice to do without them [01:23] poolie, igc: btw, I'm trying to build a Bazaar.app bundle (without much success :() [01:23] igc: hi [01:23] if you can think of a better way to handle it i'm all ears [01:23] verterok: it sounds like a great idea, i wish you luck! [01:23] poolie: igc idea [01:24] raw point right now, getting a hard time from the git people on the GPGMail project about bzr is a moving target and "broken" many times [01:24] I'm having some issues to make py2app include all the packages/modules [01:24] s/to make/making/ [01:25] verterok: the *really* big issue from my perspective on OS X is getting PyQt bundled in our installer [01:25] BasicOSX: i'm hoping that will be much more stable with bugfixes only into 2.0 [01:26] I'm sending you feedback :-) [01:27] igc: would be really cool to include it (bzr-explorer, etc), but with the current installer it's a bit difficult, a.k.a: I don't know if it's going to work at all. The bundle approach is a lot more promising [01:29] igc: the main issue is that we must include Qt too, and it's going to be a *really* big dmg [01:29] igc: if you are around I'd like to chat about something [01:29] jam: yep [01:29] igc: so I just sent an email updating bug #430311 [01:29] Launchpad bug 430311 in bzr-explorer "We should look into keeping connections open while a branch is "open" in Explorer" [Undecided,New] https://launchpad.net/bugs/430311 [01:29] igc: but basically, I think lightweight checkouts + bzr-explorer + qbzr are a pretty bad idea [01:30] bzr-explorer always spawns a subprocess to do anything [01:30] and *so does qbzr* [01:30] verterok: I wasn't suggesting it would be easy, but I feel [01:30] which means that to go from viewing your tree [01:30] spiv, hi? [01:30] igc: :) [01:30] through commit and back [01:30] connects 4+ times [01:30] verterok: that 90% of mac users will end up using the GUI before long [01:31] jam: :-( [01:31] and in my testing here with an Ubuntu server [01:31] the ssh handshake is *super* slow [01:31] like >1s on the local network [01:31] I assume this is something about security issues [01:32] (I've also noticed it when using openssh to connect from an Ubuntu desktop...) [01:32] poolie: oh, hi! [01:32] hey spvi [01:32] spiv: [01:32] igc: fully agreed [01:32] igc: so... I have to wonder if we want to make "Checkout" heavy by default in bzr-explorer [01:33] BasicOSX: broken in any particular way? [01:33] I know we have the whole discussion about what things should be [01:33] BasicOSX: or just that the OSX installers weren't always polished? [01:33] but the alternative is trying to find a way to share connections between subprocess [01:33] Maybe poolie can forward your my email :-) [01:33] or teaching bzr-explorer + qbzr to be done using threads ?? [01:33] i don't have any mail from you (yet) [01:35] Sent to sourcefrog email, just resent to canonical [01:35] jelmer, hi? [01:35] it may just be delayed somewhere [01:35] jam: I personally think 'checkouts' are only sensible when pointed to a local branch, preferably disk path accessible [01:36] poolie: I'm finishing that userdir patch atm. [01:36] jam: so a bound branch is the answer IMO [01:36] yay [01:36] jam: I'm looking to change the branch dialog so ... [01:36] (1) it has a 'bind this branch to parent' checkbox [01:36] igc: so... in a corporate setting, we'd like to say that all commits are auto-mirrored to the central location where everything is backed up [01:37] having a lightweight checkout pointing at a local bound branch is.... [01:37] (2) warns you if the destination isn't in a shared repo [01:37] (3) opens the created location implicitly on completion [01:37] jam: but it was too risky to do before 0.8 [01:37] well, will run with ignore_missing_extensions=True since depends for getting things compiled for os x are long and many :-( [01:39] jam:is ... ? [01:39] igc: a bit odd at best [01:40] jam: why do you think it's odd? [01:40] I realize it probably works, but a checkout of a bound branch is hard to give as a recommendation [01:40] jam: hmm [01:41] jam: I think checkouts are the current answer to 'shared tree' ala git [01:41] jam: bound branches are quite independent IMO [01:41] jam: and mixing the two is fine as far as I'm concerned [01:42] jam: at least conceptually - I don't know how reliable it is [01:42] igc: so internally I'm pretty sure it all works [01:43] probably conceptually the largest problem is that both are currently called "checkouts" [01:43] jam: not in epxlorer :-) [01:43] igc: well, since it doesn't have "Bound branches" [01:43] nor heavyweight checkouts [01:43] (I think) [01:43] jam: it has bound branches [01:44] jam: it's just 2 steps to set up currently: branch then bind [01:44] jam: hence my wish for a checkbox in the branch dialog [01:45] igc: so I assume you are already aware of the "Branch" should automatically open the target bug [01:45] jam: yes, I wanted to fix it for 0.8 but ran out of time [01:45] also... what about "create a working tree" [01:45] at the moment the way to create a tree in a treeless branch is to run the checkout dialog [01:45] with a target of '.' [01:45] jam: 0.8.1 already refreshes the repo view btw [01:46] which oddly, then opens the checkout in a new tab... :) [01:47] jam: we'll need to trap the '.' case [01:47] jam: 0.8 got auto-opening working for Init and Checkout but not Branch [01:47] sure, but it seems like "Work" could have a "create a working tree here" case... [01:47] at least, maybe [01:47] igc: so if you want to have a "and bind to parent" [01:48] then I have a workflow suggestion for you [01:48] fire away [01:48] which is "create a remote branch on the server, create a local branch of that, bind it, and switch my lightweight checkout to point at the local branch" [01:48] Which should really be 1 action [01:49] jam: sounds good [01:49] I also find that I really wish something like "qlog" was as directly visible as the working tree... [01:49] Possibly with just a summary of the last few revs, etc. [01:49] jam: the repo view does exactly that [01:50] I personally find the Collaborate / Explore / Work distinction difficult to track [01:50] jam: but you don't have repos there [01:50] jam: the 'virtual repo' (r workspace or whatever we call it) will too [01:50] igc: well, if we're going to switch to repos + bound branch + checkouts then maybe we will [01:51] though I just got a traceback trying to open a repository [01:51] jam: btw, try the 'extended' toolbar - it has log directly on the toolbar [01:51] jam: I use it 90% of the time [01:52] jam: I'll explain Collaborate, etc. in the User Guide when I get to it [01:53] jam: basically, one is for working with others, one is for looking at information and one is for 'local' actions that do something [01:53] igc: I like the expanded form... though I wonder why you don't think it should be the default [01:53] jam: it was orginally [01:54] igc: I guess my point for '"qlog" was as directly visible ' is that when I open up a branch [01:54] well a working tree [01:54] I have ... 90% whitespace on my screen [01:54] and digging down to find 'log' is uncomfortable [01:54] jam: I found it too busy when explaining explorer to solo developers that don't use the collaborate actions [01:56] jam: so the UI challenge w.r.t. stuff like qlog embedded is performance [01:56] jam: it's easy enough to launch and then hit refresh [01:57] (within the qlog window) [01:57] igc: ... sort of [01:57] it isn't how I would use it as a user [01:57] jam: but opening qlog every time someone opens a branch scares me [01:58] igc: faster than an ssh handshake for me... :) [01:58] 5s for bzr.dev [01:58] jam: :-) [01:58] but my specific point is that you could do the trivial view first, with only the last 10 mainline commits, with swivels that didn't do anything yte [01:58] yet [01:58] since you very quickly know the last few revs and their revnos, and whether they are merges [01:59] jam: right [01:59] igc: if I decided to spend some time on it... where would you put it to make visual sense? [01:59] jam: hmm [01:59] (i also still find that I'd prefer the working tree view to show colored status rather than having that as textual info in the left pane...) [02:00] jam: explorer has an extension mechanism right now where plugins can register 'panels' to display for various types [02:00] jam: you could do a qlog panel [02:01] that displayed for things with a working tree [02:01] or any type for that matter [02:01] jam: working tree love is coming [02:02] jam: keep in mind that explorer *code development* has mainly been an out of hours project! [02:02] well, my stomach is telling me that I better go hit the dining room or I'll be starving in another hour when they close... :( [02:02] jam: I reply to bugs on work time of course [02:02] igc: yeah... the main issue I see is that if we are going to have a gui under support [02:02] we better be able to expense some developer time to work on it [02:02] jam: and we can post 2.0 [02:02] I believe [02:03] I know the whole "not a gui dev shop" thing... [02:03] jam: pre 2.0, the team focus was different as you know [02:04] jam: but I really felt passionate about having a nice GUI as well - hence my many late night these last few months [02:05] jam: grab some food - we can chat more later [02:05] well, I know wavesat is a bit concerned about using the gui... [02:05] they seem to be willing to switch to recommending the command line [02:05] I think the segfault was the big scare [02:05] jam: it would have been [02:06] well, mostly I'm saying they were thinking that switching to the command line would be a reasonable trade, rather than thinking to abandon bzr [02:06] which I was happy about [02:07] jam: I'd see how tomorrow goes with your fix landed [02:08] jam: thanks for all the feedback btw [02:09] be back later [02:30] jam: is using a smart server without ssh an option? [02:52] oh, what was that loom alternative ? [02:53] jelmer: ping? It looks very much to me like the --protocol option to bzr serve has never worked? [02:53] jelmer: which seems improbable, given that bzr-svn has code to use it, but the code in trunk is clearly broken... [02:56] jelmer: (specifically, if --protocol is given on the command line, the code tries to use that value directly without looking it up in the registry) [02:58] jelmer: Oh, nevermind, I think I see. [03:04] SamB: pipes [03:04] lifeless: isn't it called pipeline ? [03:04] I must have been blind when was looking at the plugins page to try to spot the name earlier ... [03:15] lifeless: now where's a good tutorial ? [03:17] igc: maybe, but I think they want some level of access control, like having only 1 gatekeeper able to commit to the 'trunk' branch [03:18] jam: that access control is independent of ssh vs bzr isn't it? [03:18] igc: it is filesystem based, but if you are using 'bzr serve' then it runs as the server user [03:18] SamB: no idea sorry ;P [03:18] versus bzr+ssh running as the ssh users [03:18] jam: ah - didn't know that [03:18] igc: since bzr:// doesn't do auth itself [03:19] hmm, how to set the submit branch ? [03:24] igc: what do you think about having "cmd_explorer" subclass "QBzrCommand" ? [03:24] jam: I'm ok with that [03:24] I think at one point you wanted to be toolkit agnostic [03:24] but you seem pretty tied to qt now [03:25] jam: I think it caused some exception in my early Qt hacking days so I went another path at the time [03:25] jam: it's toolkit agnostic w.r.t. launching dialogs [03:26] jam: the core code needs to be in some toolkit and Qt seemed a good choice [03:26] igc: yeah, but if you are already depending on qt... it seems a bit silly to the depend on gtk at the next level [03:26] that, and you don't actually support bzr-gtk in the drop down list anymore .. :) [03:26] jam: right, so bzr-gtk is optional; qbzr is required [03:26] jam: if bzt-gtk is installed, it will appear in the list [03:27] ah, k [03:27] I guess i mostly played with the installer [03:27] jam: some users prefer the bzr-gtk dialogs and that's fine by me === abentley1 is now known as abentley [03:41] Notably anyone running a GNOME Desktop [03:41] and who doesn't have any Qt or KDE libraries on their system [03:46] AfC: that's going to work real well with bzr explorer! [04:01] jam: rev 275 of explorer has a few of your bugs fixed [04:02] jam: I'll release a 0.8.1 later today if they are useful enough to include in your new installer [04:03] igc: checking [04:06] igc: I think the "create if missing" fix is worthy [04:06] since it will make a difference for a lot of use cases [04:07] igc: any chance you could do 0.8.1 now so I can build -2 before I sleep? [04:08] igc: also http://paste.ubuntu.com/271819/ [04:08] fixes some of the "prompted for password on console rather than via dialog" that I've run into [04:08] I haven't 100% validated it yet, which is why it isn't a submitted patch [04:11] igc: well, actually I did just test it, and everything seems to work, so I'll push it up as a branch for you to merge [04:12] is bzr-explorer in 2a or 1.9 format? [04:14] jam: 1.9 [04:17] SamB: bzr-explorer ... that's for Microsoft Windows, right? [04:17] (ie's a Windows Explorer plugin like Tortise, isn't it?) [04:17] AfC: anything with Qt, AIUI [04:17] AfC: nope; its a gui for doing bzr stuff, AIUI [04:17] uh [04:17] AfC: explorer runs on Windows, GNOME, KDE and OS X [04:18] igc: it has a GTK back end? [04:18] AfC: hahahaha [04:18] AfC: it can call out to either QBzr or bzr-gtk [04:18] * AfC is confused [04:18] you think you can't run a Qt app in GNOME ? [04:18] AfC: the app itself is Qt [04:18] SamB_XP: you can't run KDE apps on a box that doesn't have Qt installed, no [04:19] it's not a "KDE App" [04:19] though sadly qt4 is rather huge :-( [04:19] igc: then it would be inaccurate to say it's a GNOME app [yes, you said something a bit different, but the point remains] [04:19] igc: lp:///~jameinel/bzr-explorer/dialog_for_password [04:19] * SamB_XP finds himself looking for the archive button on a google code issue [04:21] igc: if you like that, then I'd like to build a 2.0.0-rc2 with your fixes and mine tonight [04:21] I could possibly do it early tomorrow am if that works better for you [04:22] jam: my today is better - I'm on leave tomorrow :-) [04:23] jam: rev 276 has your fix [04:23] I'll package 0.8.1 in the next 30 minutes [04:23] jam: how late is it there for you? [04:23] igc: 11:30pm [04:25] jam: ok, I'll package now. Won't take long [04:28] igc: well, all *I* need is a tag on your trunk :) [04:33] jam: done. The tag is release-0.8.1. The rev is 277. [04:35] jam: just double-check buildout pulls down the latest stuff - that's been playing up for me on Windows at least [04:35] sure [04:36] jam, igc: i believe you just need to pass '-n' to the buildout invocation [04:37] in case it's defaulting to 'newest=false' [04:41] thanks sidnei [04:42] igc: of course setting 'newest=true' in buildout.cfg might be even better [04:42] jam: if the installer needs that, can you push the fix? [04:42] igc: I can't commit on Kerguelen... [04:42] well, I could but I can't push [04:42] anyway, for now I can manually update subdirs [04:42] but I'll poke at it over the next whil [04:43] jam: thanks. I can push the fix if I know it works [04:46] poolie: I think you may be going off on a tangent, or thinking I am proposing something ugly, or something. [04:47] poolie: if my reply doesn't sit right, lets talk. [04:53] * igc lunch [04:57] lifeless: do you mean about the test base classes? [04:57] yes [04:58] it may be a tangent if you're not proposing to use this any more than is there at present [04:58] I'm just proposing to clean up a little of what we have [04:58] ok [04:58] we have 4 official base classes [04:58] incremental cleanups++ [04:58] I'd like to split things out some more, to 5, or may be 6 [04:58] so they are smaller and more managable [04:59] ok [04:59] its *easier* to migrate a collection of tests by changing their base class than by other means. [05:00] do you have an example of a particular set of tests where you'd like to make this change? [05:00] biab [05:01] poolie: no, this comes from looking at the various test support code === poolie1 is now known as poolie [05:06] lifeless: back now [05:08] poolie: I do want to transition to a testresources style thing. If I can convince you to allow the extra dependency, some nice things can be done :) [05:09] brb [05:09] heh [05:10] what is this, tag-team IRC ? [05:20] lifeless: can you point me to a conflict checker i could run against our ppa? [05:20] and/or run it yourself [05:38] poolie: https://edge.launchpad.net/conflictchecker [05:39] poolie: it is probably not what you are looking for though [05:39] poolie: what sort of issues do you want detected? [05:39] i want to say "could i simultaneously install everything from this ppa?" [05:39] things like bzrtools have a deb-level conflict with bzr [05:39]