[00:35] <AfC> Is there a way to get `bzr revert` to also revert (ie remove) "unknown" files?
[00:36] <fullermd> Pretty sure not.  That's more clean-tree's territory.
[00:39] <AfC> fullermd: ah!
[00:39] <AfC> didn't know about that one.
[00:39]  * AfC reads help
[00:45] <spiv> Good morning.
[00:49] <fullermd> I wouldn't mind mornings so much, but do they have to keep coming around every stinkin' day??
[00:52] <AfC> fullermd: that's just what we need. Thanks
[03:46] <hopeseekr> .
[03:47] <hopeseekr> Hi, is it possible to put some specialized string in a file that when its committed will turn into the revision number of that commit?
[03:51] <spiv> hopeseekr: sort of.  Take a look at the bzr-keywords plugin.
[03:51] <hopeseekr> thanks
[04:01] <johnnie_> i'm using bazaar explorer - isit the case that it always creates a trunk subfolder everytime you do an init?
[04:01] <johnnie_> I find that I navigate to where my files are, do an init and then it creates this trunk subfolder and I have to move the files down in order to add them
[04:02] <lifeless> I think so, it has a default that scales well
[04:04] <johnnie_> ok - thanks - so what i'm doing is right?
[04:04] <lifeless> yup
[04:04] <johnnie_> gpthca
[04:04] <johnnie_> gotcha
[04:05] <lifeless> you should only need to init a project once
[04:05] <lifeless> after that, branching existing branches
[04:05] <lifeless> is more appropriate
[04:05] <johnnie_> ok - think i understand
[04:07] <johnnie_> i guess it's best to do the bzr init first before creating the dev files?
[04:07] <lifeless> with explorer yup
[04:07] <johnnie_> great - tnx
[08:17] <spiv> Whee, bugs in socket.py in maverick's python2.6
[08:18] <lifeless> \o/
[08:18] <spiv> (bug 615236)
[08:18] <lifeless> what are we, barries test-case
[08:18] <spiv> Er, 615240
[08:19]  * spiv goes to pick up V
[08:19] <lifeless> bug 615240
[08:26] <poolie> hi spiv, bye spiv
[08:39] <mgz> uuuu, bad feeling about that socket bug
[08:40] <mgz> that lame "explict free" comment is from the EINTR fix for socket file objects
[08:40] <mgz> http://svn.python.org/view?view=rev&revision=74426
[08:40] <mgz> ...but it doesn't have a 'view'... wonder when that was added
[08:41] <mgz> looks like a bad merge:
[08:41] <mgz> http://svn.python.org/view?view=rev&revision=83624
[08:54] <spiv> Back again.
[08:55] <bialix> hey spiv
[08:55] <mgz> spiv, are you going to file an upstream bug, or just bug someone to put the one line change on release26-maint?
[08:57] <mgz> getting an answer from ezio.melotti on why he fiddled with that patch during merging might be useful.
[08:58] <spiv> mgz: I haven't looked upstream yet, 'ubuntu-bug' is more convenient than bugs.python.org ;)
[08:58] <mgz> well, it's only a six day old error, so you're probably the first one on it
[08:58] <spiv> mgz: I'll do so (even if I don't, I'm sure the Ubuntu packagers would forward the bug and fix upstream)
[08:58] <mgz> ...he fiddled because memoryview isn't in 2.6
[08:59] <mgz> I don't think his change is really right, even with the line he missed fixed...
[08:59] <spiv> I only just finished making a coherent bug report before I had to head out the door :)
[08:59] <mgz> ah, actually it might be, svn view on python server eats whitespace changes, I always forget that
[09:00] <spiv> mgz: hah: http://bugs.python.org/issue9543
[09:00] <mgz> wasn't suggestion you were being bad, was just going to volunteer if you were busy
[09:00] <spiv> mgz: oh, please do, it's basically EOD for me here right now :)
[09:00] <mgz> ^heh, mear hours in it.
[09:04] <mgz> okay, bugs linked, think you don't need to do any more work there.
[09:07] <Pieter> hey all. Is there a way to get bzr diff --using=... to also call the supplied difftool for added or removed files?
[09:07] <spiv> Thanks!  I went ahead and added a comment with the contents of the script for convenience.
[09:08] <spiv> Pieter: I think there might be a bug report about that (if not, there probably should be)
[10:07] <flam_> bzr add command doesn't seem to work: when i add new files with bzr add <filename> it says "adding <filename>" and when i then commit bzr says "added <filename>
[10:07] <flam_> ups
[10:08] <flam_> still, when i log into the server and check if that file has been added, it isn't there
[10:08] <flam_> wtf
[10:08] <flam_> no error messages are shown
[10:09] <fullermd> Are you expecting to see it in the working tree of a remote branch?
[10:10] <poolie> flam_: you may need to run 'bzr update' on the server
[10:15] <flam_> fullermd, both
[10:16] <flam_> poolie, i don't think i have rights to do it
[10:16] <fullermd> bzr doesn't touch working trees of branches it accesses across the network (e.g., anything you `bzr push bzr+ssh://...`), so they'll never be updated.
[12:29] <MAfifi> Is pushing code to launchpad now a little problematic?
[12:30] <MAfifi> I'm trying to push a new commit to an already existing branch on launchpad, and I keep getting that error:
[12:30] <MAfifi> ssh: connect to host bazaar.launchpad.net port 22: Connection refused bzr: ERROR: Connection closed: Unexpected end of message. Please check connectivity and permissions, and report a bug if problems persist.
[12:31] <MAfifi> I've made sure I'm logged in via bzr launchpad-login <username>.
[12:32] <lifeless> MAfifi: do you have a firewall blocking port 22 perhaps ? its working for me
[12:33] <MAfifi> No, I even can't checkout code with bzr branch.
[12:33] <lifeless> Do you have a firewall blocking port 22 ?
[12:37] <MAfifi> I consulted my system administrator and he stated that it was really blocked, sorry.
[13:42] <AfC1> Thank god for professional systems administrators, in the service of their users.
[13:44] <AfC1> Probably blocks port 80 too. Can't be too careful.
[14:23] <rubbs> actually, as a sysadmin, there is a reason to not let 22 out, not that I'd do it, because it's just too tin-foil hat, even for me.
[14:23] <rubbs> mostly due to the creation of port forwards and tunnels as a way to defeat incoming firewall rules.
[14:24] <rubbs> but if you got a guy on the inside punching holes you already have a problem, trying to block outbound ssh isn't going to help that.
[14:24] <rubbs> IMHO of course
[14:25] <ddaa> it depends on the level of competency you expect to block
[14:25] <rubbs> exactly
[14:25] <ddaa> punching holes out of a http proxy is a bit trickier, I would not know how to do it in a pinch
[14:27] <rubbs> unless you had an ssh server listening on port 80. There are a million and one tuts out there telling you how you can break through firewalls at work.
[14:27] <ddaa> I'm sure I could figure it in a couple of hours
[14:27] <ddaa> note the "in a pinch"
[14:28] <rubbs> true
[14:50] <bialix> heya GaryvdM
[14:51] <GaryvdM> Hi bialix
[14:51] <bialix> do you have 5 minutes to chat about explorer?
[14:52] <GaryvdM> sure!
[14:52] <bialix> I'm starting to think about explorer performance and what to do about it
[14:52] <bialix> 2 obvious things coming to my mind
[14:52] <GaryvdM> btw - Thanks for doing the release last week. I was to busy.
[14:53] <bialix> 1) if explorer using treewidget from qbzr, then on every refresh of the branch status explorer do 2 status operatrions: 1 for its own view, and second (indirectly) for treewidget
[14:54] <bialix> I think it's a waste
[14:54] <Noldorin> what can i use for resolving conflicts of files after a merge?
[14:54] <Noldorin> does bzr come with it's own tool i should be using?
[14:54] <bialix> GaryvdM: np, it's not hard for me to do release, but gave me a way to come back into bzr dev mindset after vacation
[14:55] <bialix> Noldorin: you can use extmerge plugin, or qconflicts command from qbzr, or just fire your favorite 2/3-way merge GUI tool
[14:55] <Noldorin> bialix, winmerge would do the job?
[14:56] <bialix> Noldorin: winmerge is ok, but you have to run it just from commandline
[14:56] <GaryvdM> bialix: Sure. I think it would be easiest for us to make the qbzr treewidget accept a delta.
[14:56] <Noldorin> bialix, why's that?
[14:56] <bialix> Noldorin: like this: winmergeu file.txt
[14:56] <Noldorin> ah yes
[14:57] <Noldorin> bialix, is there a detailed tutorial on how merging works in bzr? i could probably benefit to read up on it
[14:57] <bialix> Noldorin: because winmerge gets only 1 filename as parameter, but extmerge and qconflicts don't allow you to configure it this way. yet
[14:57] <Noldorin> right
[14:57] <bialix> Noldorin: tutorial?
[14:57] <Noldorin> bialix, or guide, rather
[14:57] <Noldorin> documentation of some sort
[14:58] <bialix> it works in the similar way as GNU diff3
[14:58] <tim> hi, is there a way to clone a repository without downloading the whole history, but just the most recent revision?
[14:58] <bialix> hmm, is not the User Guide has the section about resolving conflicts?
[14:58] <GaryvdM> tim: bzr checkout --lightweight
[14:59] <bialix> Noldorin: http://doc.bazaar.canonical.com/bzr.2.1/en/user-guide/resolving_conflicts.html
[14:59] <tim> GaryvdM, thanks!
[14:59] <bialix> Noldorin: also http://doc.bazaar.canonical.com/bzr.2.1/en/user-guide/merging_changes.html
[14:59] <GaryvdM> tim: In the feature we hope to support shallow branches/history horizon (http://wiki.bazaar.canonical.com/HistoryHorizon)
[14:59] <Noldorin> cheers
[15:00] <GaryvdM> tim: lightweight checkouts kind of suck, because the have to redownload the data if you want to do a diff/status.
[15:01] <bialix> GaryvdM: 2nd point about explorer: it's almost useless to run explorer under profiler, because it's supposed to be long running process. I'm thinking about adding profile calls for specific operations or for refreshes
[15:01] <Noldorin> bialix, it doesn't explain what the BASE/THIS/OTHER files correspond to though
[15:01] <Noldorin> i can guess...
[15:01] <bialix> Noldorin: http://doc.bazaar.canonical.com/bzr.2.1/en/user-reference/conflict-types-help.html#text-conflicts
[15:02] <Noldorin> BASE is the ancestor of the file in both branches, THIS is the version of the file in the destination branch, and OTHER the version in the source branch
[15:02] <Noldorin> ah
[15:02] <bialix> it's a kinda split over the docs
[15:02] <tim> GaryvdM, well, it is ok for me ... i was trying to branch a repository, but stopped after downloading almost 3gb
[15:02] <Noldorin> yeah, i'm noticing. cheers
[15:04] <GaryvdM> bialix: That should be easy to do. You will just have start the profiler, and stop it you self.
[15:04] <bialix> Garyvdm: 3rd point: maybe we can provide a result of q-subprocess operations (like qadd, qrevert) back to explorer via some sort of IPC (don't know yet) as list of affected files, to speed-up status update
[15:05] <bialix> GaryvdM: yep, that's my guess about profiler as well. I can store such data into user directory and then asking people for mailing these data for analysis
[15:05] <bialix> tim: what is your master branch?
[15:07] <GaryvdM> bialix: Also, with KCachegrind, you can see the callees of a method. So it's easy to see what is taking long in the refresh method.
[15:07] <bialix> GaryvdM: also, I'm thinking about using separate process a-la tortoisebzr status RPC service/daemon to collect status info in the background. I'm not sure how good it will be for Linux
[15:07] <tim> bialix, lp:ubuntu/gcc-4.5
[15:08] <bialix> tim: ah. sorry
[15:08] <bialix> GaryvdM: I don't have Ubuntu yet
[15:09] <GaryvdM> tim: I know that there were some memory issues with gcc checkouts. jam was looking at them.
[15:09] <bialix> GaryvdM: but maybe I need to get new notebook, where I can create dual-boot system
[15:09] <GaryvdM> bialix: Do you have any callgrinds I can look at?
[15:10] <Noldorin> bialix, what would you recommend for merging on windows? i'm not sure i fully like winmerge...
[15:10] <bialix> GaryvdM: no new data so far, I'm trying to figure the right way to attack this problem
[15:10] <bialix> Noldorin: I'm using either winmerge, or just text editor
[15:10] <Noldorin> right
[15:11] <bialix> Noldorin: many people like diffuse, and Araxis Merge tool (non-free)
[15:11] <Noldorin> bialix, i'm trying to figure out the correct command-line option for opening a conflict file
[15:11] <GaryvdM> Noldorin: On windows, I like Araxis Merge. It's propritory :-( and expensive :-(, but works well
[15:11] <Noldorin> right
[15:11] <Noldorin> GaryvdM, i see...
[15:11] <bialix> Noldorin: for which tool?
[15:11] <Noldorin> winmerge
[15:11] <bialix> winmergeu FILE_WITH_CONFLICTS
[15:12] <bialix> just a file name, without THIS/BASE/OTHER
[15:12] <Noldorin> doesn't work...
[15:12] <Noldorin> ok
[15:12] <Noldorin> hmm
[15:12] <bialix> Noldorin: I'd recommend to use winmerge 2.13.8 or higher
[15:12] <bialix> previous versions have some bugs in this area
[15:13] <GaryvdM> bialix: Re explorer, and qbzr dialogs, I think the easiest would be for them to be in the same subprocess...
[15:13] <Noldorin> bialix, i see. that version is beta as i understand
[15:13] <bialix> GaryvdM: yep, I think we can run qdialogs from main explorer process, anyway we then invoke qsubprocess, right?
[15:13] <bialix> Noldorin: I'm using it for very long time
[15:14] <bialix> Noldorin: no problems detected so far
[15:14] <Noldorin> ok that's good to know :)
[15:14] <GaryvdM> bialix: Yes. The issue with that is then you will have different code for qbzr and bzr-gtk dialogs.
[15:15] <bialix> GaryvdM: well, at some point I can drop bzr-gtk support, if it will be too much hassle
[15:15] <GaryvdM> I wonder if there  are any people who  launch bzr-gtk dialogs from explorer?
[15:15]  * bialix too
[15:15] <bialix> in the end there is olive-gtk, and nautilus
[15:15] <GaryvdM> bialix: Re https://code.edge.launchpad.net/~garyvdm/bzr-explorer/better_tree_filter/+merge/20519
[15:15] <ddaa> I would, bzr vis is superior to qlog in some respects
[15:16] <GaryvdM> bialix: I got stuck with requiring a version qbzr.
[15:16] <GaryvdM> ddaa: In what way?
[15:16] <bialix> GaryvdM: what's the problem?
[15:16] <GaryvdM> ddaa: And do you use bzr explorer?
[15:16] <ddaa> I find the "show me the revision where this line was introduced" behaviour of vis very nice.
[15:17] <ddaa> And qlog quite confusing in that respect.
[15:17] <ddaa> GaryvdM: I'm trying on occasion, but truthfully, I'm too used to the command line and I find a gui clumsy.
[15:17] <ddaa> So feel free to ignore me.
[15:18] <GaryvdM> ddaa: Ok
[15:18] <ddaa> mh
[15:18] <bialix> ddaa: is not this is annotate?
[15:18] <ddaa> yes it is :-)
[15:18] <ddaa> was about to correct myself
[15:18] <ddaa> duh
[15:19] <GaryvdM> ddaa: for qannotate, just click on the line of text, and the revision is selected?
[15:20] <ddaa> GaryvdM: do you really want go into debugging what exactly I found confusing?
[15:20] <GaryvdM> ddaa: Yes :-)
[15:20] <bialix> yes
[15:20] <ddaa> ok, let me fire the bugger
[15:21] <GaryvdM> ddaa: what version was this in. qannotate got some nice improvements in 0.18
[15:21] <ddaa> qbzr 0.18.4
[15:22] <GaryvdM> ddaa: i.e. Find, goto line, and when you change the annotated revision, the scroll remains consistent.
[15:22] <bialix> in 0.19?
[15:22] <GaryvdM> ddaa: sorry - in 0.19...
[15:22] <bialix> GaryvdM: I guess you mean 0.19
[15:22] <GaryvdM> Yes :-)
[15:22] <ddaa> mh... maybe my confusion came from scrolling issues indeed
[15:23] <GaryvdM> bialix: For https://code.edge.launchpad.net/~garyvdm/bzr-explorer/better_tree_filter/+merge/20519 , I have 2 code paths. one for qbzr 0.18, and one for qbzr 0.19
[15:23] <GaryvdM> bialix: basicly, the methods added in 0.19 are included in that patch as a fall back...
[15:24] <bialix> GaryvdM: ok, I understand
[15:25] <bialix> GaryvdM: I'm happy to say that explorer trunk required qbzr 0.19
[15:25] <Noldorin> bialix, thanks, seems to be working nicely now :)
[15:25] <GaryvdM> bialix: My problem was I was not able to do that.
[15:25] <GaryvdM> bialix: let me have another go...
[15:25] <bialix> GaryvdM: sorry, I can't dig into your code right now
[15:26] <bialix> GaryvdM: but I will review it ASAP
[15:26] <bialix> Noldorin: good to hear
[15:27] <GaryvdM> bialix: I would have just landed it, if it were not for the qbzr version issue.
[15:27] <GaryvdM> That for me is the issue.
[15:29] <bialix> hmm
[15:34] <GaryvdM> bialix: Were should we do the check? In the __init__.py, like we do for bzrlib check in qbzr,
[15:34] <GaryvdM> or in commands.cmd_explorer.run?
[15:34] <ddaa> GaryvdM: I'll check the newer qannotate when I get it from the system update.
[15:34] <bialix> GaryvdM: I'd prefer the latter
[15:34] <GaryvdM> ddaa: Cool.
[15:35] <GaryvdM> bialix: ok - I'll do that now.
[15:41] <Noldorin> bialix, so i've finished doing my merge/conflict resolution. is there any easy way to tell bzr to remove all the .~1~ and .moved files?
[15:41] <Noldorin> and .BASE, etc.
[15:41] <bialix> bzr resolve
[15:42] <Noldorin> thatl leaves them there
[15:42] <bialix> bzr clean-tree
[15:42] <Noldorin> ah yes
[15:42] <maxb> bzr clean-tree --detritus
[15:42] <bialix> Noldorin: you need to run `bzr resolve` and mark non-text conflicts as resolved
[15:43] <bialix> qconflicts is your friend
[15:43] <Noldorin> bialix, yes, bzr resolved tells me there are no more conflicts
[15:43] <bialix> (or qresolve, it's the same thing)
[15:43] <Noldorin> but the tree was dirty still
[15:43] <Noldorin> that did the job though - thanks again
[15:44] <bialix> now you're ready to commit your merge
[15:50] <Noldorin> :)
[15:52] <GaryvdM> Bla - my in progress maverick upgrade has broken pyqt...
[15:53] <GaryvdM> I guess you or not ment to use it while it's upgrading....
[16:11] <GaryvdM> bialix: landed.
[16:11] <bialix> GaryvdM: thanks!
[16:11]  * GaryvdM off to get food.
[16:11] <GaryvdM> bbl
[16:57] <Kaspi> hello
[16:57] <Kaspi> what's the difference between branch and repository?
[16:59] <maxb> A repository is an on-disk store of revision data
[16:59] <maxb> A branch is a store for a reference to a specific revision (and implicitly all of its ancestors), and also a mapping of tag-name -> revision-id.
[17:01] <parthm> Kaspi: 'bzr help branches' and 'bzr help repositories' have some good notes. There are some more topics under 'bzr help topics' in case you haven't seen it already.
[17:09] <thrope> does loggerhead have a download tarball link yet?
[17:10] <Kaspi> parthm: maxb: thanks
[17:11] <thrope> is there any other bazaar web client that allows downloading a tarball of the latest revision? ive been pretty happy with loggerhead but really need that functionality
[17:13] <thrope> according to this it can do it
[17:13] <thrope> https://bugs.launchpad.net/loggerhead/+bug/246764/comments/4
[17:13] <thrope> but i can't see how
[18:18] <GaryvdM> jam: Ping
[19:21] <bialix> GaryvdM: ping
[19:22] <GaryvdM> bialix: Pong
[19:22] <bialix> GaryvdM: regarding your check for qbzr version in explorer
[19:22] <bialix> I think it should report in the console AND as GUI MessageBox
[19:22] <bialix> or only as MessageBox
[19:22] <bialix> think about bzrw.exe
[19:22] <GaryvdM> Good point.
[19:23] <bialix> if there won't be a real console user will not know why explorer does not start
[19:23] <bialix> even with bzr.exe the console will flashing and closing
[19:24] <GaryvdM> bialix: If explorer had a ui-mode option, and you ran the command with it, then it would show a message box.
[19:24] <bialix> we can say that explorer is always run with --ui-mode ;-)
[19:24] <GaryvdM> bialix: but that's not what I think we should ho
[19:24] <GaryvdM> *do
[19:25] <GaryvdM> bialix: The error handler should detect bzrw.exe (using sys.frozen)
[19:25] <bialix> imho, explorer is GUI application, and I'd prefer to show error messages as GUI dialogs, when possible
[19:27] <jam> hey GaryvdM
[19:27] <GaryvdM> Hi jam.
[19:27] <GaryvdM> jam: I can't connect to the ec2 computer.
[19:27] <jam> it would be at a different address, I forgot about that
[19:27]  * bialix waves at jam
[19:27] <jam> hi bialix
[19:28] <GaryvdM> jam: That's what I figured.
[19:32] <dlee> Any way to use a normal bzr repository to manage parts of a tree also managed by svn?  IOW, I have an svn checkout but want to use bzr to manage little bits of it locally.  the .svn folders confuse bzr at sublevels though.
[19:33] <dlee> i think I'm looking for a way to get bzr 2 to ignore .svn folders, without having to rename them all momentarily.
[19:33] <GaryvdM> dlee: bzr ignore .svn
[19:35] <dlee> I doubt that helps... scenario: bzr init in folder a with subfolder b/c/d.  Then cd b/c/d, bzr add file.txt... but there are b/.svn, b/c/.svn, and b/c/d/.svn, all of which keep bzr from finding a/.bzr at all.
[19:36] <GaryvdM> bialix: I just had a look at the error handling in bzr-explorer. I would like to do some improvements there.
[19:36] <GaryvdM> bialix: But tonight, I want to get the 2.2.0 final installers done.
[19:37] <bialix> GaryvdM: ok
[19:37] <GaryvdM> bialix: How much do you know about buildout?
[19:37] <bialix> a little
[19:37] <bialix> but enough to get the bad impression
[19:38] <bialix> :-/
[19:38] <GaryvdM> bialix: Would you be able to help me get the build script to use a downloaded version of pycrypto & paramiko, rather than the ones installed on the build system?
[19:39] <bialix> get?
[19:39] <bialix> you need to download?
[19:39] <bialix> or you need to force them in py2exe>
[19:39] <bialix> or you need to force them in py2exe?
[19:39] <GaryvdM> bialix: yes, download, and change sys.path.
[19:40] <bialix> I guess PYTHONPATH should be enough for py2exe
[19:40] <bialix> lemme pull the branch first, trunk?
[19:40] <GaryvdM> bialix: yes
[19:40]  * bialix pulls
[19:40] <GaryvdM> bialix: I think buildout is ment to be able to do that for you automaticly.
[19:41] <bialix> I meant: pull the latest changes from lp:bzr-windows-installers
[19:41] <GaryvdM> Yes
[19:43] <GaryvdM> I watched a video about buildout. The guy added to install_requires in setup.py, and it automaticly got the egg, and change the sys.path so that the egg got used.
[19:43] <GaryvdM> The module was not installed on the system.
[19:45] <GaryvdM> Maybe I need to do that in the setup.py in the py2exe code.
[19:45] <bialix> file build.py, line 393, def _build_exe
[19:46] <bialix> IMO, you need to add PYTHONPATH to env dict
[19:47] <GaryvdM> Ah - ok - so I'm not going to be able to get buildout to do it for me.
[19:47] <bialix> GaryvdM: btw, in the bazaar_releases.py you have custom bzr
[19:47] <bialix>         Project('bzr', 'lp:~garyvdm/bzr/2.2b4-optimize'),
[19:47] <bialix> I think it should be updated to lp:bzr/2.2 ?
[19:48] <GaryvdM> bialix: Yes
[19:48] <bialix> and you need to merge my branch with changes to qbzr/explorer versions
[19:48] <bialix> or I should merge and push?
[19:48] <GaryvdM> bialix: Allready done :-)
[19:49] <GaryvdM> oh wait.
[19:49] <GaryvdM> I did not push
[19:49] <bialix> yep
[19:49] <GaryvdM> bialix: Sorry - I thought I had done it.
[19:50] <GaryvdM> Done now. :-)
[19:51] <bialix> GaryvdM: now only bzr 2.2 branch need to be changed
[19:51] <bialix> GaryvdM: to download pycrypto/paramiko I guess you need to add them into bazaar_releases
[19:52] <GaryvdM> bialix: Yes - and I need to go through the rest of the plugins, and check if there are any new releases.
[19:52] <bialix> I'd suggest to download them and install into temp directory, then use this directory in the PYTHONPATH
[19:52] <bialix> GaryvdM: it seems igc has removed some dependencies on buildout
[19:53] <bialix> before buildout generated bat file to execute build. now it's plain python, and this is good
[19:59] <GaryvdM> jam, bialix: This is harder than I thought. So I'm going to install the new versions on the build server.
[19:59]  * bialix nods
[20:06] <GaryvdM> jam: Sorry - forgot I don't have admin.
[20:06] <GaryvdM> please will you do it for me.
[20:06] <GaryvdM> the files are in d:
[20:09] <jam> GaryvdM: what do you need installed?
[20:09] <GaryvdM> pycrypto 2.2
[20:09] <GaryvdM> and paramiko with my patch
[20:10] <GaryvdM> I have the source for both in d:
[20:10] <jam> k, be about 5 min
[20:10] <GaryvdM> jam: Thanks
[20:21] <jam> GaryvdM: just setup.py install for paramiko?
[20:22] <GaryvdM> jam: I guess so. I'm not sure what the easest way to get easy_install to manage it.
[20:22] <GaryvdM> Maybe build an egg?
[20:24] <jam> GaryvdM: were you expecting pycrypto 2.2 to be installed?
[20:25] <GaryvdM> jam: Yes - that is the latest release
[20:25] <jam> k, I only knew about 2.1
[20:25] <GaryvdM> yes - Very new.
[20:26] <GaryvdM> I've run the paramiko test suit on it - all passes.
[20:27] <jam> so I made one small change, bumping 1.7.6 to 1.7.6.1
[20:27] <jam> so that it will update to this version
[20:27] <GaryvdM> Ok - cool.
[20:27] <jam> rather than think it is new enough
[20:27] <jam> I'm a little concerned about this:
[20:28] <jam>   warning: GMP library not found; Not building Crypto.PublicKey._fastmath.
[20:28] <jam> but I guess I'll live with it
[20:28] <jam> they don't have binaries for pycrypto because of export rules, iirc
[20:28] <jam> anyway, stuff is installed, care to test it?
[20:29] <GaryvdM> jam: Thanks - Will do in a sec.
[20:43] <GaryvdM> Still no 2.2 compatible releases of bzr-loom, and bzr-pipeline :-(
[20:47] <bialix> jam: there is binary for pycrypto available on voidspace
[21:09] <quotemstr1> What's the best way to create a private fork of a project already on bzr?
[21:09] <ddaa> bzr branch
[21:10] <quotemstr1> On Launchpad, that is.
[21:10] <quotemstr1> Without having to re-upload the *entire* project to a fresh Launchpad branch.
[21:11] <GaryvdM> jelmer: I'm getting this error building subvertpy 0.7.3.1: http://pastebin.org/462761, should I log a bug?
[21:11] <ddaa> define "private fork" in terms of launchpad
[21:11] <ddaa> when uploading a branch to an existing project, lp will use stacked repo
[21:11] <jelmer> GaryvdM, please do
[21:11] <jelmer> GaryvdM, actually, any chance you can try with lp:subvertpy as well?
[21:12] <jelmer> if it doesn't work with that, I think we should fix the issue and release a 0.7.3.2
[21:12] <GaryvdM> jelmer: ok
[21:14] <quotemstr1> ddaa: Ah.
[21:14] <quotemstr1> ddaa: Is it normal that it bugs me about a missing .bzr directory?
[21:16] <ddaa> you must be doing something wrong, we'd need the full command and output of bzr (to a pastebin) to be able to tell
[21:17] <quotemstr1> Well, I created a new branch of Emacs using the bzr web interface, and tried to push to it: http://pastebin.ca/1914036
[21:19] <ddaa> what about following the hint in the error  message?
[21:19] <quotemstr1> That'll probably upload the entire project, which is huge.
[21:19] <ddaa> what about trying?
[21:20] <quotemstr1> Hrm. It seems to have worked.
[21:20] <quotemstr1> Thanks.
[21:22] <ddaa> thanks to stacked repos
[21:23] <ddaa> canonical does not terribly fancy the idea of hosting one complete copy of the emacs repo for each branch, either
[21:23] <ddaa> not to mention the fact it would make lp unusable for people
[21:27] <GaryvdM> jelmer: Yhea - builds fine with lp:subvertpy. I'm going to log a bug, and then release with 0.7.2
[21:27] <jelmer> GaryvdM, thanks.
[21:29] <GaryvdM> Ah - allready loged: bug 612056
[21:41] <C-S> Any ideas when bzr-gtk is released? It is not usable on the 2.2 version of bzr...
[21:59] <dobey> jam: ping :)
[22:16] <dobey> hrmm
[22:16] <dobey> so i am having a bit of a weird experience similar to https://bugs.edge.launchpad.net/launchpad-code/+bug/614404 i think
[22:29] <dobey> but even with jam's patch from there, i still get the same failure, occurring elsewhere
[22:31] <dobey> http://pastebin.ubuntu.com/475639/
[22:40] <james_w> dobey: that's not really the same issue, as nothing is specifying --committer for you
[22:41] <james_w> dobey: in that case I think it's probably that tarmac isn't using bzr's test case and so doesn't get the sanitised environment that should stop this sort of thing from happening
[22:54] <GaryvdM> Bla - I'm stuck. Will continue tomorrow.
[23:14] <poolie> hi gary,
[23:14] <poolie> mkanat: hello?
[23:20] <mkanat> Hey poolie!
[23:24] <poolie> mkanat: hi there, be with you in a sec
[23:24] <mkanat> Okay.
[23:26] <poolie> back
[23:26] <poolie> i'm glad that's all settled
[23:27] <poolie> now how about some lp bugs?
[23:27] <poolie> i mean loggerhead bugs
[23:27] <mkanat> :-)
[23:27] <mkanat> Yes, sounds like a plan. :-)
[23:27] <thumper> mkanat: hi
[23:27] <poolie> i had a couple of specific suggestions
[23:27] <poolie> we're seeing crashes every few days
[23:27] <mkanat> poolie: My schedule has become slightly more occupied since I was last doing loggerhead work, but I have a whole plan for how to fit this in.
[23:28] <thumper> mkanat: I should really have a chat with you and poolie about directions I'd like to see loggerhead go in
[23:28] <poolie> the losas may be able to help you characterize it
[23:28] <poolie> i don't think there's any specific emergency at the moment, so it doesn't need to be right this week or anything
[23:28] <thumper> poolie: it isn't quite as bad as every few days
[23:28] <mkanat> poolie: I think the memory leak thing should probably be addressed pretty quickly, though.
[23:28] <thumper> although we did have a day a while back where it was four times in one day
[23:28] <poolie> anyhow the suggestions were to do fixes off a stable branch we can roll out
[23:29] <poolie> maybe a numbered release branch, and then to get lp-loggerhead to converge with that
[23:29] <poolie> and also perhaps to see about meliae integration
[23:29] <poolie> perhaps working with jam
[23:29] <mkanat> poolie: Those sound like reasonable suggestions.
[23:30] <poolie> meliae should help get better data about future stuff
[23:30] <poolie> apparently the losas are all at a sprint in utc+2 at the moment
[23:30] <poolie> thumper: do you have any favourite bug nominations?
[23:31] <thumper> nothing really beyond the crash and non-responsive fixes
[23:31] <thumper> my concerns are more with strategic loggerhead direction
[23:33] <mkanat> That makes sense.
[23:33] <mkanat> FWIW, my general suspicion on loggerhead strategic direction is that it should switch to Spawning.
[23:34] <poolie> mm
[23:34] <poolie> it makes sense to me
[23:35] <poolie> how hard would it be? perhaps reasonably easy if it's just a wsgi reconfiguration
[23:35] <poolie> (he says hopefully)
[23:35] <mkanat> Well, we have a lot of custom code around Paste.
[23:35] <mkanat> I haven't looked into Spawning too much, but I have seen that there is a Paste layer.
[23:36] <mkanat> What wouldn't be portable is the kill-hung-threads stuff. But it might also no longer be necessary.
[23:36] <mkanat> I'm hoping that to get it to the point of doing a basic experiment wouldn't be too much work, but I suspect that a full "correct" migration would be more effort.
[23:38] <poolie> ok
[23:38] <poolie> so istm, i'm not sure about tim
[23:38] <poolie> that if there are smaller point bugs they would be good to do first
[23:39] <poolie> otherwise, switching to a spawning model makes sense
[23:39] <poolie> you could send a brief rfc if there's anything more to say beyond your previous mail
[23:46] <mkanat> poolie: Okay. :-)
[23:46] <mkanat> poolie: The only tricky part with Spawning is caching, because we can't share in-memory caches. So we have to do everything on-disk.
[23:47] <poolie> you could have nonshared in memory caching
[23:47] <mkanat> Yeah, we could.
[23:47] <mkanat> But I think that would make each process enormous.
[23:48] <poolie> mm maybe
[23:48] <mkanat> poolie: Maybe I should just go through every open loggerhead bug, right now, too. There aren't that many.
[23:49] <poolie> so we could externalize it to tdb, or a bzr pack, or memcached
[23:49]  * mkanat nods.
[23:49] <poolie> perhaps the last would be nice eventually but that may require bigger changes
[23:49] <poolie> also it'll make it less self contained
[23:49] <mkanat> Yeah, and I don't think it will be necessary.
[23:49] <poolie> that could be good
[23:49] <mkanat> That is, I think memcached is in the realm of YAGNI for the moment.
[23:51] <thumper> I just tried to use "bzr send" for the first time in gnome, and after switching default email client from evo to kmail it now brings up an email, but there is no attached bundle
[23:51] <thumper> it should right?
[23:51] <poolie> it should either have a body or an attachment