[00:25] <poolie> hi all
[00:25] <mgz> hey poolie.
[00:30] <poolie> hi there
[00:31] <poolie> i'm working a bit today on a plan to bring bzr-colo into core
[00:34] <jelmer> 'morning spiv, poolie
[00:34] <jelmer> 'evening maxb, mgz
[00:34]  * jelmer wonders what part of the day fullermd is in
[00:34] <mgz> jelmer, have you filed a bug against launchpad yet to enable projects to remove certain states from the drop down box yet? :)
[00:35] <jelmer> mgz: I think it'd be closed as "Won't Fix" :)
[00:36] <poolie> hi jelmer
[00:36] <poolie> mgz: certain bug states?
[00:36] <poolie> which ones do you want to remove?
[00:37]  * fullermd doesn't know himself anymore   :|
[00:37] <mgz> poolie: I'm winding jelmer up a little, he's forgotten bzr doesn't use 'Triaged' a few times. :)
[00:43] <mgz> okay, now I need sleep.
[00:51] <poolie> ah
[00:51] <poolie> in that particular case i think we'd be better off removing triaged altogether
[00:53] <maxb> On the other hand, the distinction between confirmed and triaged is rather vital if a project wants to separate user confirmations and "has had developer attention"
[01:00] <aroman> how can bzr have a conflict with a file that doesn't exist?
[01:04] <mwhudson> if you delete a file, and the branch you merge from changes it, that sounds like a conflict to me
[01:06] <poolie> that's right
[04:43] <leo2007> If I have 2 commits in my local bzr branch and the parent has new commits, what happens if I do a 'bzr up'?
[04:44] <spiv> The 2 local commits become a pending merge.
[04:44] <spiv> Which you then need to commit.
[04:48] <poolie> hi spiv
[04:48] <poolie> spiv, have you used bzr-colo yet?
[04:50] <leo2007> spiv: thanks.
[04:51] <leo2007> why 'bzr up' always report I am up-to-date when in fact there are 9 new commits from parent?
[04:56] <poolie> leo2007, if it's a separate branch you may need to pull or merge them.
[04:59] <spiv> poolie: no, I haven't
[05:01] <leo2007> poolie: pull says conflicts. But merge will not place my local revs on top of the remote parents, right?
[05:01] <poolie> leo2007, are these separate branches, or is your local branch a checkout of trunk?
[05:02] <poolie> spiv, how do you manage your branches?
[05:02] <poolie> just separate trees within a shared repo?
[05:02] <leo2007> poolie: a checkout.
[05:04] <poolie> leo2007, what does 'bzr info' show?
[05:05] <leo2007> poolie: http://paste.pocoo.org/show/lGSnxK33ZSi6vAKxlWmq
[05:05] <poolie> when you say '9 new commits from parent' where do you see that? by separately running 'bzr log' on the parent?
[05:06] <leo2007> poolie: from 'bzr missing'
[05:06] <poolie> leo2007, this looks like just a regular standalone branch then
[05:06] <poolie> you're trying to bring the latest stuff from trunk into your branch, and then continue with development of your branch?
[05:07] <leo2007> yeah, and my branch has two commits.
[05:07] <leo2007> two extra*
[05:08] <poolie> ok, so you should probably just merge trunk
[05:08] <poolie> your own revisions will still be visible in history, but they won't be on top of it
[05:08] <spiv> poolie: yes, exactly that layout
[05:08] <poolie> if you want to rewrite history so it looks like they were done after what is now on trunk, use bzr-rewrite
[05:09] <leo2007> poolie: I also need to push my commits to trunk at some time later.
[05:10] <poolie> ok
[05:10] <poolie> but not right now?
[05:24] <leo2007> poolie: no, not right now.
[05:25] <leo2007> I basically want to pull from upstream compile and submit my commits.
[05:25] <leo2007> I am familiar with git but not bzr.
[05:25] <poolie> spiv, when you get a chance could you install it and have a play
[05:26] <poolie> leo2007, ok, the typical bzr thing would just be to merge from trunk, resolve any conflicts, compile and test, then send up your changes
[05:26] <leo2007> would that mean my branch having different history than upstream?
[05:27] <poolie> well, your branch is going to show you did some work, then you merged trunk and resolved conflicts
[05:27] <poolie> which is accuarte
[05:27] <poolie> when trunk merges from you, all the history will be accurate
[05:28] <leo2007> Is it possible to push an individual commit to upstream? In my case, I have two new commits locally, one is more mature and the other is waiting for confirmation before submitting.
[05:30] <poolie> when you say 'push' do you mean actual bzr push direct into trunk?
[05:30] <poolie> do you have access to write to trunk?
[05:30] <poolie> or just to submit for someone else to review?
[05:31] <leo2007> poolie: I have write access.
[05:34] <lifeless> spiv: hi, re bug 739144 - making it critical is fine; please don't set to confirmed though - if you've triaged it, set it to triaged.
[05:36] <poolie> leo2007, perhaps the cleanest/easiest thing is to make a new branch off trunk to integrate your work
[05:37] <poolie> do a 'bzr merge -r whatever' from your branch into that
[05:37] <poolie> then push that back up
[05:38] <leo2007> poolie: is it possible to export a commit to a file which I can then put back in easily? something like git format-patch and am?
[05:39] <leo2007> I am thinking since I have only two commits for now. I could save them to a file and drop them in my local branch. Sync my branch and put them back.
[05:39] <poolie> 'bzr send -o FILE'
[05:39] <leo2007> that would appear solve all my questions.
[05:40] <poolie> or perhaps 'bzr shelve' is a better idea
[05:40] <poolie> or, if you have only two, just uncommit, shelve, pull, then unshelve
[05:45] <leo2007> poolie: bzr: ERROR: Operation denied because it would change the main history, which is not permitted by the append_revisions_only setting on branch "/Users/Shared/sources/EmacsBZR/trunk/".
[05:46] <spiv> lifeless: ah, ok.  Thanks for the correction.
[05:49] <poolie> leo2007, ok, in that case you will need to make a new checkout of trunk trunk, merge your work, then commit
[05:50] <lifeless> spiv: you may not have read https://dev.launchpad.net/BugTriage in a while - its been refreshed
[05:52] <spiv> lifeless: I haven't read it in detail, no, although I did skim it to check that I wasn't being too outrageous in choosing Critical
[05:53] <spiv> lifeless: I just didn't think at all about Confirmed vs. Triaged because I'm totally out of the habit of ever considering Triaged :)
[05:53] <lifeless> :)
[05:53] <spiv> jelmer of course is having the opposite problem these days :)
[05:55] <leo2007> poolie: I changed branch.conf and go ahead with uncommit.
[05:55] <poolie> just curious, what change did you make?
[05:56] <leo2007> poolie: append_revisions_only = False
[05:56] <poolie> lifeless, how about you, did you ever use bzr-colo
[05:56] <poolie> oh, for the real emacs trunk?
[05:56] <poolie> that might make other people unhappy
[05:56] <leo2007> poolie: my branch
[06:06] <leo2007> poolie: could you recommend some good docs for using bzr?
[06:06] <poolie> well, mostly the current version under doc.bazaar.canonical.com
[06:06] <poolie> i know emacs also have some special conventions that i think are on their wiki
[06:07] <poolie> i would also really recommend using bzr-colo with bzr
[06:07] <poolie> from
[06:07] <poolie> http://doc.bazaar.canonical.com/plugins/en/colo-plugin.html
[06:11] <wgrant> spiv: :(
[06:11] <leo2007> ok, i'll take a look after reading http://doc.bazaar.canonical.com/migration/en/survival/bzr-for-git-users.html
[06:11] <leo2007> poolie: thanks for your help.
[06:11] <wgrant> spiv: Processing that same email locally works fine.;
[06:13] <spiv> wgrant: whee
[06:14] <wgrant> spiv: So I wonder if an MTA ate it... or something.
[06:15] <wgrant> I guess we should check that jam's copy is intact.
[06:16] <spiv> wgrant: yeah, that's a good idea
[06:16] <wgrant> If it's intact, we might need to go through MTA logs and find where the size drops...
[06:17] <lifeless> poolie: no, I have used looms, and pipelines, and for non-distro work I just use a lightweight checkout of branches in a shared treeless repo
[06:19] <poolie> ok
[06:19] <poolie> you might like to try this as an alternative to the latter
[06:20] <poolie> i would appreciate your feedback if you do so
[06:20] <lifeless> it will be a bit tricky right now -  my lp dev environment is down to 200MB free :( (and my host os 2GB free :( :( )
[06:20] <lifeless> I need to get a larger SSD
[06:21] <lifeless> I've been looking at getting a larger desktop box in fact - but the price for ones with 48GB of memory is ridiculous ;)
[06:21] <poolie> hm, it shouldn't use any more space than what you do now
[06:22] <wgrant> poolie: Is colo fairly usable these days?
[06:22] <poolie> it might take more than 200MB to convert into it
[06:22] <poolie> i think it's really good
[06:22] <wgrant> I haven't tried it since the week it was announced.
[06:22] <poolie> i'm just drafting a mail proposing we should bless it as the standard way to use bzr
[06:22] <poolie> and ship it by default etc
[06:22] <stylesen> poolie: ping
[06:22] <wgrant> IIRC the main problem I had with it was shelf.
[06:22] <poolie> it gives people a less manual way to set up the single-tree multiple brancehs thing
[06:22] <poolie> hi stylesen
[06:23] <stylesen> poolie: Hi poolie, would like to have a private chat with you!
[06:23] <lifeless> poolie: yeah, converting is what I was thinking might be an issue
[06:23] <poolie> sure, see pm
[06:23] <poolie> lifeless, i think the default conversion does copy all your histoyr
[06:23] <poolie> this could be optimized of course
[06:25] <poolie> for the common case of turning a repo + branches into a colo workspace, just moving the directories ought to be enough
[06:25] <poolie> lifeless, i just bought a 750GB magnetic disk to go into my laptop base
[06:25] <poolie> to store (my own) photos
[06:26] <poolie> lifeless, it's kind of ironic that you just converted me to the convenience of not having separate laptops/desktop machines :)
[06:27] <lifeless> poolie: nice!
[06:27] <lifeless> poolie: thats in an expansion bay, or the main unit?
[06:28] <poolie> in the sata bay of the ultrabase
[06:28] <poolie> the base does work pretty well for using it as a desktop replacement
[06:30] <lifeless> ah, nice.
[06:31] <lifeless> poolie: I'm finding my biggest limit is RAM
[06:31] <lifeless> the disk is a bit annoying, but I can juggle tolerably (though 128GB is quite constraining)
[06:31] <lifeless> but I can barely use all 4 cores with 8GB
[06:32] <poolie> i probably will ssh into my desktop box again if i'm doing something on lp and don't anticipate travelling soon
[06:32] <poolie> it seems like i touch dkim infrequently enough that every time i do, i spend 30 mins trying to get all the dependencies going again :/
[06:32] <lifeless> poolie: so if I do get a new desktop, I'll setup testr to run tests on the desktop from my laptop
[06:32] <wgrant> lifeless: Are new ThinkPad motherboards still limited to 8GB? :/
[06:33] <lifeless> probably set that up locally too so that I edit in a local vim session, and the lp-dev VM runs the tests
[06:33] <lifeless> wgrant: the W something or other can do (IIRC) 12
[06:33] <lifeless> wgrant: need 4GB for a lp test run end to end last time I tried to put a figure on it
[06:34] <lifeless> wgrant: (4GB in a VM)
[06:34] <lifeless> wgrant: so to parallelise robustly-before-we-fix-the-test-suite, I'm thinking we want 4GB*cores.
[06:34] <wgrant> lifeless: It's a lot less if you run i386.
[06:34] <lifeless> wgrant: but then I'd be running i386.
[06:35] <wgrant> In the VM :)
[06:35] <wgrant> How do I grab a remote branch into an existing colo workspace?
[06:35] <lifeless> I
[06:36] <lifeless> I'd expect 'make a branch, pull --overwrite'
[06:36] <wgrant> 'bzr branch lp:launchpad colo:devel' seems to work.
[06:37] <poolie> or bzr colo-fetch lp:launchpad
[06:37] <wgrant> colo-fetch says it creates a new workspace.
[06:37] <poolie> sorry, i misread
[06:38] <poolie> yes, i think your command is correct then
[06:38] <wgrant> Thanks.
[06:46] <wgrant> :(
[06:47] <wgrant> I wish bzr switch had an option to shelve changes into the branch or something.
[06:47] <poolie> wgrant, that was just requested
[06:47] <poolie> it shouldn't be too hard to add
[06:47] <wgrant> poolie: Except that shelves are in the WT, right?
[06:48] <spiv> wgrant: right
[06:48] <wgrant> :(
[06:48] <wgrant> Hmm.
[06:49] <wgrant> I guess it's useful to have them visible in all, but it would be nice if I could tell where each shelf came from.
[06:49] <wgrant> Since I use shelve a *lot*.
[06:49] <spiv> wgrant: hmm!
[06:50] <wgrant> (and I just about never give a message... perhaps I should)
[06:50] <spiv> wgrant: bzr-colo could perhaps auto-fill the --message option of 'bzr shelve' with the branch nick?
[06:50] <wgrant> Right.
[06:50] <wgrant> That would help.
[06:51] <poolie> wgrant, well, what i meant is that it seems like it would be a small code change to put them in the branch dir
[06:52] <poolie> giving better identities would be good
[06:52] <poolie> i'd like if they showed a diff stat or a snippet of the change more easily
[07:19] <vila> hi all !
[07:34] <poolie> hi vila
[07:36] <vila> poolie: hey !
[07:40] <poolie> hi vila
[07:40] <poolie> vila, did you try bzr-colo yet?
[07:41] <poolie> s//at all?
[07:41] <vila> not at all
[07:42] <vila> I still favor using a different working tree for each branch and looms for more involved feature dev
[07:43] <vila> I also use bound branches for specific needs (so multiple working trees but on different hosts)
[07:48] <poolie> ok
[07:48] <poolie> rfc sent
[07:55] <poolie> vila, like multiple machines all on the same network, bound to branches on one of them?
[07:55] <poolie> for fixing failures inside vms, or something?
[07:56] <vila> well, the branches are called my/setup and my/admin and they centralize/share all tweaks/setups I do on all my hosts
[07:56] <vila> that includes VMs
[07:59] <vila> but I still haven't a good story for fixing failures in VMs, partly because I keep encountering corruptions due to hard crashes and partly because I don't want to put valid auth tokens in VMs
[07:59] <vila> (thought I cheat a bit with the later ;)
[08:00] <vila> I work around corruptions by using mounted file systems for most of the VMs
[08:00] <vila> I'd prefer a bzr-based workflow but each time I need it, I'm already in bugfix mode and procrastinate
[08:01] <vila> s/proca*/punt/
[08:01] <vila> urg, one more random kill of a VM as a write this :(
[08:02] <vila> hmm, death may be more appropriate in fact, *2* VMs died (out of 3 running) and only the 3rd one should have shut down...
[08:03] <poolie> wow
[08:03] <poolie> died in the vm infrastructure, or in the guest os?
[08:03] <vila> the vm just vanished
[08:03] <vila> n ologs, no core, no nothing
[08:04] <poolie> this is with virtualbox?
[08:04] <vila> most annoying "babune" bug for months, no idea how to progress, last attempt was configuring core dumps but none ever appeared
[08:05] <vila> yup, and vbox is my first suspect, I keep hoping that the next version will address the issue :-/
[08:05] <poolie> maybe some of these things could run under kvm, vmware desktop, or something else?
[08:05] <vila> I chatted in #vbox several times but no one has any idea about what is going on nor how to collect useful infos to help debug it
[08:07] <vila> and since most of the time it happens during my sleep it's very hard to even caracterize it (hence my kill/death remark above)
[08:32] <magcius> gah
[08:32] <magcius> This is the most annoying thing.
[08:52] <fullermd> vila: Really, it's your own fault for sleeping   :p
[08:53] <vila> aaaaaaah, of course !
[09:19] <poolie> hi vila,
[09:19] <poolie> would you like a quick chat
[09:21] <vila> sure
[10:14] <leo2007> how to show what's in a commit?
[10:14] <jelmer> leo2007: do you mean the tree contents, the changes in that commit, the commit message / committer information?
[10:15] <leo2007> the diff, the message, etc
[10:15] <jelmer> leo2007: bzr log -p -rREV
[10:17] <leo2007> thanks.
[12:05] <spiv> jam1: LP appears to have mangled an email I sent to it: https://launchpad.net/bugs/739144.  You were CC'd, did you receive it intact?
[12:06] <spiv> jam1: probably best to reply on the bug, it's zzz time here :)
[12:06] <jam1> spiv: I got the email in-tact
[12:06] <jam1> and broken from lp
[12:08] <spiv> jam: I'm not sure if I feel relieved to hear that or not!
[12:08] <jam> spiv: sleep well. But yes, you sent the email correctly to me, LP messed something up
[12:08] <jam> or LP's mailhost did :)
[12:54] <Sp4rKy> hi
[12:54] <Sp4rKy> I get an error when trying bzr update :
[12:54] <Sp4rKy> bzr: ERROR: exceptions.UnicodeEncodeError: 'ascii' codec can't encode character u'\xe8' in position 85: ordinal not in range(128)
[12:56] <CaMason> hi guys. In our current team workflow, we occasionally have a 'merge session' where we merge in all changes prior to a release. After that, I get the team to `bzr pull` from the master branch, so we're all now working from the same code
[12:56] <CaMason> is that last bit sensible?
[12:57] <CaMason> it seems to work OK, as all team members then get everyone elses changes in their own branches
[12:57] <maxb> Sp4rKy: See if there is a traceback in ~/.bzr.log, and pastebin it
[12:59] <jelmer> CaMason: that seems perfectly sensible
[13:01] <Sp4rKy> maxb: http://paste.dunnewind.net/show/eVa29Aq8XkZ8ySIA0Xrt/
[13:03] <mgz> Sp4rKy: set you LANG/LC_ALL env vars to something sensible.
[13:03] <mgz> *your
[13:20] <maxb> Sp4rKy: to expand slightly on mgz's answer - you're trying to check out code with non-ascii file names. To do this, you need to be configured to use a locale which uses a character encoding which can represent them, so that Bazaar knows how to write the filenames to disk
[13:21] <maxb> Nowadays, everyone ought to be using a utf8 locale, really
[13:21] <Sp4rKy> maxb: in fact I am using utf-8 locale
[13:21] <Sp4rKy> but for some strange reason puppet (I manage the bzr repo with it) reset it ;)
[13:22] <Sp4rKy> so nothing bzr-related I think
[13:22] <maxb> line 56 of your pastebin says you are not
[13:26] <Sp4rKy> I am :)
[13:26] <Sp4rKy> but puppet reset it
[13:31] <santagada> is there any benchmarks comparing bzr 2.1+ to mercurial and git?
[13:32] <santagada> I've only seem really old ones and people told me bzr improved a lot in the 2.x line
[13:36] <jelmer> santagada: I haven't seen any recent benchmarks
[13:51] <jam> jelmer: care to finish your review of https://code.launchpad.net/~jameinel/bzr/2.4-cheaper-iter-entries-by-dir/+merge/53994
[13:51] <jam> ?
[13:52] <jelmer> jam: Sure
[14:25] <CaMason> what's the easiest way to output all files that have changed between revisions? Sometimes we get a customer that needs a 'patch', and we want to send only the PHP files that have changed
[14:26] <jam> CaMason: "bzr status -r X..Y" ?
[14:27] <CaMason> we might be talking a few hundred files :) Any way to `bzr cat` based on the revisions?
[14:27] <CaMason> if not, I could set up a script
[14:27] <jam> CaMason: so you want the complete contents of all files that changed recently (that end in .php)?
[14:27] <CaMason> between specified revisions, yes
[14:28] <jam> CaMason: "bzr status --short" is quite scriptable
[14:28] <jam> my 'cut' experience is limited
[14:28] <jam> but
[14:28] <CaMason> ah, hadn't seen that :D
[14:28] <jam> bzr status --short -r X..Y | grep ".*\.php"
[14:29] <jam> gets you a sart
[14:29] <jam> start
[14:29] <jam> I would use sed to get just the filenames, but that's because I don't know cut
[14:31] <CaMason> no sweat, that output is great, I'll get that scripted
[14:31] <CaMason> thanks
[14:33] <CaMason> bzr st --short -r last:4 | cut -c 5-
[14:35] <jam> CaMason: still need 'grep .php'
[14:35] <jam> but yeah
[14:36] <jam> bzr st --short -r last:4 | cut -c 5- | grep '.php' | xargs -n1 bzr cat -r -1
[14:36] <CaMason> ah that's no bother, I actually want all files. I just said 'php' so people didn't worry about a build script :P
[14:37] <jam> CaMason: though you could probably just pass the list to tar so that it will include only those files in a tarball
[14:41] <CaMason> `bzr st --short -r last:4 | cut -c 5- | xargs zip ../patch.zip` worked great
[14:41] <CaMason> its for windows clients unfortunately :)
[14:47] <jam> jelmer, vila: ping about https://code.launchpad.net/~jameinel/bzr/2.4-cheaper-iter-entries-by-dir/+merge/53994
[14:49] <vila> ubot5: where do you find a bug 2 ?
[14:49]  * mgz eyes ubot5 suspiciously
[14:50] <vila> mgz: ;)
[14:50] <jam> mgz: it *really* likes bug 2
[14:51] <jam> mgz: currently reviewing  https://code.launchpad.net/~gz/bzr/create_delta_index_api_change_633336/+merge/54130
[14:51] <jam> why do you return the Error class rather than just raising it?
[14:51] <mgz> okay, someone just borked poor ubotu5.
[14:51] <vila> gee, unplug that bot !
[14:52] <jam> mgz: at least it didn't mention "that bug" again
[14:52] <mgz> jam: I don't really like helpers appearing in the stack, and to raise I need to return object from the cdef anyway
[14:52] <jam> mgz: well,there are other ways, and you don't have to explicitly list object (it is the default if you say nothing)
[14:53] <mgz> so it's either helper than raises or returns None, or returns exception instances
[14:53] <jam> cdef foo() returns None
[14:53] <jam> same as regular python
[14:53] <vila> jam: oh, and pong https://code.launchpad.net/~vila/udd/735477-kill-harder/+merge/53837 ;)
[14:54] <mgz> I picked the way that gave me a shorter path in the common case, and one less level of stack when something goes wrong. but I'm open to all suggestions of this kind, made various stylistic judgement calls.
[14:54] <jam> vila: you didn't respond to my comment on that proposal
[14:55] <jam> I don't usually like hard-coded constants in the middle of code, can you bring it to a module/class level constant?
[14:55] <vila> jam: it wasn't related to the proposal but to another script :)
[14:55] <jam> otherwise seems good to me
[14:55] <jam> vila: though isn't that script broken by any grace period that isn't 0?
[14:55] <jam> since it only waits 1 second before starting the next process
[14:57] <vila> jam: no, as explained in the cover letter (updated before asking for re-review) during the grace period no kills are issued but the mass_import script doesn't wait either
[14:57] <jam> vila: I saw the update, but probably missed the details in the 5-pages-of-text
[14:58] <vila> the discussion then went about how long it takes for the mass_import to stop
[14:58] <jam> vila: so only ImportDriver is using the new kill_with_escalation, and mass-import is doing?
[14:59] <vila> 61 lines == 5 pages ? a page = 12 lines ?
[14:59] <jam> anyway, it isn't very clear how your first comment how it ties in with the last comment. since you seem to say it should switch, but then say it doesn't
[14:59] <vila> jam: sorry I don't understand your question
[14:59] <jam> or maybe just doesn't fast enough?
[15:00] <jam> vila: I'll try to start at the top
[15:00] <jam> "For the first case, we don't really care about what is currently
[15:00] <jam> going on since this denotes a bug"
[15:00] <jam> that sounds exactly like the case we care about
[15:00] <jam> s/the case/a case/
[15:01] <vila> except we can't any data from a process that doesn't respond to SIGTERM (as shown with nexuiz-data)
[15:01] <jam> vila: certainly
[15:01] <vila> and we *currently* generate log files 1GB/day with attempts to kill it
[15:01] <jam> I think martin and my point is that under load, 2s is actually pretty short for something to even generate a backtrace
[15:02] <jam> I'm happy to have the SIGTERM end up with SIGKILl
[15:02] <vila> well, not *currently* because it's seen as failing but still
[15:02] <jam> after a reasonable time
[15:02] <jam> 10s seems good to me
[15:02] <jam> a bit long for "die now please"
[15:02] <jam> but good for most situations
[15:02] <vila> jam: which is what the proposal implements hence asking for a re-review
[15:02] <jam> vila: which is the part I've certainly approved already
[15:03] <vila> meh, there are currently 2 NeedsFixing vote and no Approve
[15:03] <jam> vila: reload
[15:04] <jam> mgz: why is "delta_data" a "void **" rather than a "delta_index **" ?
[15:04] <jam> (in the pyrex header)
[15:05] <mgz> it was a straight change from returning void* to taking void**, but it could be unsigned char** instead given the actual value
[15:05] <jam> mgz: and in the docs, I would say "when DELTA_OK "fresh" contains a struct ..."
[15:05] <mgz> was it some cython being to clever with strings workaround thing?
[15:05] <jam> rather than "outparam" which isn't defined
[15:06] <jam> mgz: the actual value is a delta_index pointer
[15:06] <jam> at least from what I'm reading in delta.h
[15:06] <mgz> possibly the header is misleading?
[15:06] <mgz>     unsigned char *out;
[15:06] <mgz> ...
[15:06] <jam> https://code.launchpad.net/~gz/bzr/create_delta_index_api_change_633336/+merge/54130
[15:06] <mgz>     *delta_data = out;
[15:07] <jam> line 285
[15:07] <jam> you added a new parameter, it should be called "fresh" not "delta_data", or whatever you want to do with it
[15:07] <mgz> create_delta and create_delta_index have different signatures.
[15:08] <jam> mgz: ah, just misreading it
[15:09] <mgz> 282 in diff-delta.c is 197 in delta.h
[15:10] <mgz> adding to the function descriptions in the header might help things, the similar names are confusing to start with.
[15:11] <jam> mgz: overall approve, just needs a news entry
[15:11] <jam> something about getting better error messages when things fail
[15:11] <jam> is probably enough
[15:13] <mgz> I'll do that and take another pass at the comments.
[15:15] <mgz> which news heading should it be under? :)
[15:15] <jam> mgz: probably either internals or bugfixes
[15:17] <mgz> I'm just having a closer look at your tar export branch now, the push fixed the broken tests clearly.
[17:15] <vila> jelmer: what do you mean in bug #739481 ? Repository has too many methods - iter_reverse_revision_history " ... "in favor of Repository.iter_reverse_revision_history" ?
[17:16] <fullermd> Obviously, he means there's madness in its methods   ;)
[17:31] <gypsymauro> hi
[17:32] <gypsymauro> suppose my shared repository is offline, can I commits locally and then when I can reach my serve again move all changes to the shared repository?
[17:37] <maxb> gypsymauro: Yes, but a little advice on terminology - a "shared repository" in bzr terms usually refers to a location on disk created with "bzr init-repo" which exists to share one copy of history between multiple branches within it.
[17:37] <maxb> Whereas I assume you are talking about a remote server hosting branches.
[17:39] <gypsymauro> maxb: no I'm talking about a shared repository in bzr terms :)
[17:39] <maxb> How can a directory on disk be offline?
[17:55] <sidnei> vila, is anyone running the bzr benchmarks that ian was running?
[17:56] <sidnei> or jam ^^
[18:34] <jelmer> g'morning poolie
[18:42] <santagada> sidnei: I think you will have to run them
[18:42] <santagada> :D
[18:42] <sidnei> santagada, yeah, why not
[18:43] <sidnei> santagada, you could too :)
[18:44] <santagada> sidnei: if you can get the scripts used, I can try
[18:44] <sidnei> santagada, yay!
[18:51] <sidnei> jelmer, would you know anything about ian's benchmark scripts?
[18:55] <santagada> if it is a simple shell or python we could run it on my mac on windows and osx, you could do it on ubuntu
[18:55] <jelmer> sidnei: I think it's on Launchpad as lp:bzr-usertest
[18:57] <santagada> jelmer: yep it is in there but the docs http://people.canonical.com/~ianc/plugins/usertest/doc/ are 404
[18:59] <jelmer> santagada: I think the docs are probably in the branch too
[19:00] <sidnei> yeah, looks like it
[19:00] <sidnei> santagada, see http://bazaar.launchpad.net/~bzr/bzr-usertest/trunk/view/head:/scripts/script_network.py for example
[19:03] <cody-somerville> jelmer, Hey.
[19:03] <cody-somerville> jelmer, I got that information you requested: https://pastebin.canonical.com/44973/
[19:03] <cody-somerville> jelmer, It... looks like a bigger issue at hand. And the fact that someone else also reported this is rather concerning.
[19:05] <jelmer> cody-somerville: who did?
[19:05] <jelmer> cody-somerville: that all looks reasonable
[19:06] <cody-somerville> jelmer, Why is the group owner of somethings users and not jagosta?
[19:07] <cody-somerville> jelmer, LP #661678
[19:08] <jelmer> cody-somerville: I don't know, but that shouldn't really be an issue
[19:09] <jelmer> cody-somerville: or maybe that breaks the ownership copying
[19:10] <jelmer> cody-somerville: what groups is he in ? is he in both jagosta and users?
[19:12] <cody-somerville> jelmer, weird... no. users but not jagosta
[19:14] <jelmer> That would explain why bzr is errorring out - as it probably can't set the group for that file
[19:14]  * jelmer reopens the bug
[19:17] <cody-somerville> I think this might be a regression in Ubuntu.
[19:20] <jelmer> cody-somerville: yeah, looks like it
[20:39] <Pilky> does anyone have any experience pushing a bzr branch to a new github repository?
[20:41] <Pilky> I'm trying to do a dpush but it's giving a respository not found error
[21:31] <rockstar> abentley, you around?
[22:02] <AfC> Shame about bzr-git only using 1 CPU
[22:06]  * jelmer waves to AfC
[22:06] <AfC> Hi jelmer
[22:07] <jelmer> AfC: It could very well use more in theory, we just haven't put the work in yet and I imagine the GIL would be problematic in this case.
[22:08] <AfC> jelmer: I've been trying to get a checkout of Cairo. It's been 20 minutes so far. Might be a good test repository for you (especially seeing as how it's probably the third oldest Git respository out there).
[22:09] <AfC> jelmer: $ bzr checkout git://anongit.freedesktop.org/git/cairo
[22:09] <AfC> jelmer: is the command I ran...
[22:10] <AfC> Perhaps one to add to the "large foreign repos we performance test" collection.
[22:10] <jelmer> AfC: ENOSUCHCOLLECTION ;-)
[22:11] <jelmer> AfC: There probably should be one, though..
[22:11] <AfC> heh
[22:11] <jelmer> Among other things I'm currently working on getting all the Bazaar interface tests passing against the foreign formats. After that, I hope to take a look at further improvements, including performance.
[22:15] <AfC> jelmer: doesn't John maintain some large family of test repos, ie Open Office?
[22:16] <AfC> jelmer: but anyway
[22:16] <AfC> jelmer: yeah, I saw you remark about that. Very cool indeed.
[22:18] <jelmer> AfC: Yeah, I think he has something like that, but he tests the converted trees, not the conversion itself.
[22:50] <IceGuest_77> hi, quick question, hoping someone can help me. I am having a look at the stats plugin, and trying to understand how it works. Why are the numbers of revisions it reports more than from bzr log -rsomerev -n0 | grep revno | wc -l. What revisions is log not showing, and why?
[22:52] <kingos> stats gets the revisions by doing : ancestry = a_repo.get_ancestry(revision)[1:]
[23:01] <jelmer> hi kingos
[23:01] <spiv> kingos: off the top of my head I'd expect the ancestry of a revision to match the log -n0
[23:02] <jelmer> spiv beat me to it, that's what I'd say as well
[23:02] <jelmer> get_ancestry() is a bit weird as the first entry it returns is always None, hence the "[1:]" bit.
[23:03] <spiv> ('bzr ancestry' is a simpler way to see the revisions in the ancestry of a branch)
[23:05] <spiv> kingos: "bzr ancestry" and "bzr log -n0 --line" give the same number of lines for me.
[23:06] <spiv> (on the two branches I tried, one with 34k revs the other with 688 revs)
[23:06] <kingos> hmmm
[23:07] <spiv> (the stats plugin is not working for me atm)
[23:07] <jelmer> spiv: hmm?
[23:07] <spiv> jelmer: AttributeError: 'ProgressTask' object has no attribute 'note'
[23:08] <spiv> jelmer: with trunk lp:bzr and trunk lp:bzr-stats
[23:08] <kingos> spiv: yeah you can't specify an initial range I htink
[23:09] <spiv> kingos: to bzr ancestry?  No, unfortunately.  You could always do 'bzr branch --no-tree -rSOMEREV' (maybe add '--stacked' if you aren't using a shared repo) to work around that :/
[23:10] <kingos> spiv: I meant with stats
[23:10] <spiv> Oh ok.
[23:14] <kingos> spiv: bzr stats -r2..5 fails, where as bzr stats -r5 works
[23:19] <jelmer> kingos: please file a bug about that
[23:19] <jelmer> kingos: does it simply ignore the range or does it crash?
[23:22] <kingos> jelmer: It fails with that progress note error
[23:23] <kingos> jelmer: do I file it under bzr, or is there a plugin specific bug page?
[23:23] <spiv> kingos: oh, I'm not passing any args to bzr-stats at all
[23:23] <spiv> kingos: bugs.launchpad.net/bzr-stats I expect
[23:24] <jelmer> it works happily here with both trunks afaik
[23:24] <spiv> jelmer: a puzzle!
[23:25] <jelmer> spiv: I'm only getting that error when I specify a range
[23:27] <spiv> jelmer: ah, hmm, pebkac in my ~/.bazaar/plugins symlinks
[23:27] <jelmer> kingos: can you try with trunk?
[23:28] <spiv> Whee, 'ln -s ~/code/bzr-stats/trunk stats' does something confusingly different if you already have a 'stats' directory...
[23:28] <jelmer> spiv: heh
[23:29] <kingos> jelmer: still fails
[23:29] <jelmer> kingos: do you have r46?
[23:30] <jelmer> can you pastebin the backtrace?
[23:30] <kingos> jelmer: backtrace on the ticket
[23:30] <kingos> Bug #739823
[23:31] <spiv> kingos: By 'r46' he means "the revision I committed 3 minutes ago
[23:31] <kingos> of stats?
[23:31] <spiv> kingos: yes
[23:31] <spiv> jelmer: thanks, r46 fixes the -r2..5 bug for me
[23:32] <kingos> jelmer: no I didn't, that fixes it :(
[23:32] <kingos> jelmer: what should I close the bug report with?
[23:33] <kingos> jelmer: fix committed, or something else?
[23:33] <jelmer> kingos: yeah, fix committed
[23:33] <jelmer> it'll be fix released after the next bzr-stats release
[23:44] <poolie> hi spiv, jelmer, all
[23:47] <spiv> Hi poolie
[23:48] <jelmer> hi poolie