| === psynaptic is now known as psynaptic|away | ||
| poolie | hi all | 00:25 |
|---|---|---|
| mgz | hey poolie. | 00:25 |
| poolie | hi there | 00:30 |
| poolie | i'm working a bit today on a plan to bring bzr-colo into core | 00:31 |
| 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:34 |
| jelmer | mgz: I think it'd be closed as "Won't Fix" :) | 00:35 |
| poolie | hi jelmer | 00:36 |
| poolie | mgz: certain bug states? | 00:36 |
| poolie | which ones do you want to remove? | 00:36 |
| * 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:37 |
| mgz | okay, now I need sleep. | 00:43 |
| poolie | ah | 00:51 |
| poolie | in that particular case i think we'd be better off removing triaged altogether | 00:51 |
| 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" | 00:53 |
| aroman | how can bzr have a conflict with a file that doesn't exist? | 01:00 |
| mwhudson | if you delete a file, and the branch you merge from changes it, that sounds like a conflict to me | 01:04 |
| poolie | that's right | 01:06 |
| === Ursinha is now known as Ursinha-afk | ||
| 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:43 |
| spiv | The 2 local commits become a pending merge. | 04:44 |
| spiv | Which you then need to commit. | 04:44 |
| poolie | hi spiv | 04:48 |
| poolie | spiv, have you used bzr-colo yet? | 04:48 |
| leo2007 | spiv: thanks. | 04:50 |
| leo2007 | why 'bzr up' always report I am up-to-date when in fact there are 9 new commits from parent? | 04:51 |
| poolie | leo2007, if it's a separate branch you may need to pull or merge them. | 04:56 |
| spiv | poolie: no, I haven't | 04:59 |
| 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:01 |
| 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:02 |
| poolie | leo2007, what does 'bzr info' show? | 05:04 |
| 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:05 |
| 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:06 |
| leo2007 | yeah, and my branch has two commits. | 05:07 |
| leo2007 | two extra* | 05:07 |
| 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:08 |
| leo2007 | poolie: I also need to push my commits to trunk at some time later. | 05:09 |
| poolie | ok | 05:10 |
| poolie | but not right now? | 05:10 |
| leo2007 | poolie: no, not right now. | 05:24 |
| 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:25 |
| 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:26 |
| 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:27 |
| 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:28 |
| 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:30 |
| leo2007 | poolie: I have write access. | 05:31 |
| 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:34 |
| ubot5 | Launchpad bug 739144 in Launchpad itself "Code review comment via email truncated, most content lost!" [Critical,Triaged] https://launchpad.net/bugs/739144 | 05:34 |
| poolie | leo2007, perhaps the cleanest/easiest thing is to make a new branch off trunk to integrate your work | 05:36 |
| poolie | do a 'bzr merge -r whatever' from your branch into that | 05:37 |
| poolie | then push that back up | 05:37 |
| 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:38 |
| 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:39 |
| 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:40 |
| 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:45 |
| spiv | lifeless: ah, ok. Thanks for the correction. | 05:46 |
| poolie | leo2007, ok, in that case you will need to make a new checkout of trunk trunk, merge your work, then commit | 05:49 |
| lifeless | spiv: you may not have read https://dev.launchpad.net/BugTriage in a while - its been refreshed | 05:50 |
| 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:52 |
| 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:53 |
| leo2007 | poolie: I changed branch.conf and go ahead with uncommit. | 05:55 |
| poolie | just curious, what change did you make? | 05:55 |
| 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 | 05:56 |
| 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:06 |
| 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:07 |
| 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:11 |
| spiv | wgrant: whee | 06:13 |
| wgrant | spiv: So I wonder if an MTA ate it... or something. | 06:14 |
| wgrant | I guess we should check that jam's copy is intact. | 06:15 |
| 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:16 |
| 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:17 |
| poolie | ok | 06:19 |
| poolie | you might like to try this as an alternative to the latter | 06:19 |
| 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:20 |
| 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:21 |
| 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:22 |
| 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:23 |
| 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:25 |
| poolie | lifeless, it's kind of ironic that you just converted me to the convenience of not having separate laptops/desktop machines :) | 06:26 |
| lifeless | poolie: nice! | 06:27 |
| lifeless | poolie: thats in an expansion bay, or the main unit? | 06:27 |
| 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:28 |
| lifeless | ah, nice. | 06:30 |
| 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:31 |
| 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:32 |
| 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:33 |
| 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:34 |
| wgrant | In the VM :) | 06:35 |
| wgrant | How do I grab a remote branch into an existing colo workspace? | 06:35 |
| lifeless | I | 06:35 |
| lifeless | I'd expect 'make a branch, pull --overwrite' | 06:36 |
| wgrant | 'bzr branch lp:launchpad colo:devel' seems to work. | 06:36 |
| 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:37 |
| poolie | yes, i think your command is correct then | 06:38 |
| wgrant | Thanks. | 06:38 |
| wgrant | :( | 06:46 |
| 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:47 |
| spiv | wgrant: right | 06:48 |
| wgrant | :( | 06:48 |
| wgrant | Hmm. | 06:48 |
| 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:49 |
| 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:50 |
| 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:51 |
| 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 | 06:52 |
| vila | hi all ! | 07:19 |
| === r0bby is now known as robbyoconnor | ||
| poolie | hi vila | 07:34 |
| vila | poolie: hey ! | 07:36 |
| poolie | hi vila | 07:40 |
| poolie | vila, did you try bzr-colo yet? | 07:40 |
| poolie | s//at all? | 07:41 |
| vila | not at all | 07:41 |
| vila | I still favor using a different working tree for each branch and looms for more involved feature dev | 07:42 |
| vila | I also use bound branches for specific needs (so multiple working trees but on different hosts) | 07:43 |
| poolie | ok | 07:48 |
| poolie | rfc sent | 07:48 |
| 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:55 |
| 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:56 |
| 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 ;) | 07:59 |
| 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:00 |
| vila | s/proca*/punt/ | 08:01 |
| vila | urg, one more random kill of a VM as a write this :( | 08:01 |
| === hunger_ is now known as hunger | ||
| 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:02 |
| 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:03 |
| 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:04 |
| 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:05 |
| 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:07 |
| magcius | gah | 08:32 |
| magcius | This is the most annoying thing. | 08:32 |
| fullermd | vila: Really, it's your own fault for sleeping :p | 08:52 |
| vila | aaaaaaah, of course ! | 08:53 |
| poolie | hi vila, | 09:19 |
| poolie | would you like a quick chat | 09:19 |
| vila | sure | 09:21 |
| === jelmer changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: jelmer | 2.3.1 is officially out, 2.4b1 has been frozen | ||
| 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:14 |
| leo2007 | the diff, the message, etc | 10:15 |
| jelmer | leo2007: bzr log -p -rREV | 10:15 |
| leo2007 | thanks. | 10:17 |
| === psynaptic|away is now known as psynaptic | ||
| === psynaptic is now known as psynaptic|scran | ||
| === psynaptic|scran is now known as psynaptic | ||
| 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:05 |
| ubot5 | Ubuntu bug 739144 in Launchpad itself "Code review comment via email truncated, most content lost!" [Critical,Triaged] | 12:05 |
| 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:06 |
| === jam1 is now known as jam | ||
| 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:08 |
| 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:54 |
| === Ursinha-afk is now known as Ursinha | ||
| 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:56 |
| 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:57 |
| jelmer | CaMason: that seems perfectly sensible | 12:59 |
| Sp4rKy | maxb: http://paste.dunnewind.net/show/eVa29Aq8XkZ8ySIA0Xrt/ | 13:01 |
| mgz | Sp4rKy: set you LANG/LC_ALL env vars to something sensible. | 13:03 |
| mgz | *your | 13:03 |
| 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:20 |
| 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:21 |
| Sp4rKy | so nothing bzr-related I think | 13:22 |
| maxb | line 56 of your pastebin says you are not | 13:22 |
| Sp4rKy | I am :) | 13:26 |
| Sp4rKy | but puppet reset it | 13:26 |
| santagada | is there any benchmarks comparing bzr 2.1+ to mercurial and git? | 13:31 |
| santagada | I've only seem really old ones and people told me bzr improved a lot in the 2.x line | 13:32 |
| jelmer | santagada: I haven't seen any recent benchmarks | 13:36 |
| 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:51 |
| ubot5 | Error: Launchpad bug 2 not found | 13:51 |
| jelmer | jam: Sure | 13:52 |
| 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:25 |
| jam | CaMason: "bzr status -r X..Y" ? | 14:26 |
| 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:27 |
| 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:28 |
| 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:29 |
| CaMason | no sweat, that output is great, I'll get that scripted | 14:31 |
| CaMason | thanks | 14:31 |
| CaMason | bzr st --short -r last:4 | cut -c 5- | 14:33 |
| jam | CaMason: still need 'grep .php' | 14:35 |
| jam | but yeah | 14:35 |
| 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:36 |
| jam | CaMason: though you could probably just pass the list to tar so that it will include only those files in a tarball | 14:37 |
| 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:41 |
| jam | jelmer, vila: ping about https://code.launchpad.net/~jameinel/bzr/2.4-cheaper-iter-entries-by-dir/+merge/53994 | 14:47 |
| ubot5 | Error: Launchpad bug 2 not found | 14:47 |
| vila | ubot5: where do you find a bug 2 ? | 14:49 |
| * mgz eyes ubot5 suspiciously | 14:49 | |
| ubot5 | Error: Launchpad bug 2 could not be found | 14:49 |
| vila | mgz: ;) | 14:50 |
| jam | mgz: it *really* likes bug 2 | 14:50 |
| ubot5 | Error: Launchpad bug 2 could not be found | 14:50 |
| jam | mgz: currently reviewing https://code.launchpad.net/~gz/bzr/create_delta_index_api_change_633336/+merge/54130 | 14:51 |
| ubot5 | Ubuntu bug 54130 in Ubuntu "no sound of any sort 6.10 knot 1" [Undecided,Invalid] | 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:51 |
| 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:52 |
| 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:53 |
| ubot5 | Ubuntu bug 735477 in Ubuntu Distributed Development "some imports survive a kill -SIGTERM leading to massive log output and no kill" [High,In progress] | 14:53 |
| 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:54 |
| 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:55 |
| === psynaptic is now known as psynaptic|away | ||
| 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:57 |
| 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:58 |
| 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? | 14:59 |
| 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:00 |
| 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:01 |
| 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:02 |
| vila | meh, there are currently 2 NeedsFixing vote and no Approve | 15:03 |
| jam | vila: reload | 15:03 |
| jam | mgz: why is "delta_data" a "void **" rather than a "delta_index **" ? | 15:04 |
| jam | (in the pyrex header) | 15:04 |
| 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:05 |
| 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:06 |
| ubot5 | Ubuntu bug 54130 in Ubuntu "no sound of any sort 6.10 knot 1" [Undecided,Invalid] | 15:06 |
| 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:07 |
| jam | mgz: ah, just misreading it | 15:08 |
| mgz | 282 in diff-delta.c is 197 in delta.h | 15:09 |
| mgz | adding to the function descriptions in the header might help things, the similar names are confusing to start with. | 15:10 |
| 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:11 |
| mgz | I'll do that and take another pass at the comments. | 15:13 |
| mgz | which news heading should it be under? :) | 15:15 |
| jam | mgz: probably either internals or bugfixes | 15:15 |
| mgz | I'm just having a closer look at your tar export branch now, the push fixed the broken tests clearly. | 15:17 |
| === mnepton is now known as mneptok | ||
| === Ursinha is now known as Ursinha-lunch | ||
| === psynaptic|away is now known as psynaptic | ||
| === deryck is now known as deryck[lunch] | ||
| === Ursinha-lunch is now known as Ursinha | ||
| 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:15 |
| ubot5 | Launchpad bug 739481 in Bazaar "deprecate Repostory.iter_reverse_revision_history" [Low,Confirmed] https://launchpad.net/bugs/739481 | 17:15 |
| fullermd | Obviously, he means there's madness in its methods ;) | 17:16 |
| gypsymauro | hi | 17:31 |
| 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:32 |
| === deryck[lunch] is now known as deryck | ||
| 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:37 |
| 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:39 |
| === beuno is now known as beuno-lunch | ||
| sidnei | vila, is anyone running the bzr benchmarks that ian was running? | 17:55 |
| sidnei | or jam ^^ | 17:56 |
| === psynaptic is now known as psynaptic|break | ||
| jelmer | g'morning poolie | 18:34 |
| === beuno-lunch is now known as beuno | ||
| santagada | sidnei: I think you will have to run them | 18:42 |
| santagada | :D | 18:42 |
| sidnei | santagada, yeah, why not | 18:42 |
| sidnei | santagada, you could too :) | 18:43 |
| santagada | sidnei: if you can get the scripts used, I can try | 18:44 |
| sidnei | santagada, yay! | 18:44 |
| sidnei | jelmer, would you know anything about ian's benchmark scripts? | 18:51 |
| 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:55 |
| santagada | jelmer: yep it is in there but the docs http://people.canonical.com/~ianc/plugins/usertest/doc/ are 404 | 18:57 |
| jelmer | santagada: I think the docs are probably in the branch too | 18:59 |
| 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:00 |
| 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:03 |
| jelmer | cody-somerville: who did? | 19:05 |
| jelmer | cody-somerville: that all looks reasonable | 19:05 |
| cody-somerville | jelmer, Why is the group owner of somethings users and not jagosta? | 19:06 |
| cody-somerville | jelmer, LP #661678 | 19:07 |
| ubot5 | Launchpad bug 661678 in bzr (Ubuntu) "bzr whoami: unable to copy ownership from '$HOME/.bazaar' to '$HOME/.bazaar/bazaar.conf'" [Undecided,Invalid] https://launchpad.net/bugs/661678 | 19:07 |
| jelmer | cody-somerville: I don't know, but that shouldn't really be an issue | 19:08 |
| jelmer | cody-somerville: or maybe that breaks the ownership copying | 19:09 |
| jelmer | cody-somerville: what groups is he in ? is he in both jagosta and users? | 19:10 |
| === psynaptic|break is now known as psynaptic|away | ||
| cody-somerville | jelmer, weird... no. users but not jagosta | 19:12 |
| 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:14 | |
| cody-somerville | I think this might be a regression in Ubuntu. | 19:17 |
| jelmer | cody-somerville: yeah, looks like it | 19:20 |
| === Ursinha is now known as Ursinha-afk | ||
| === Ursinha-afk is now known as Ursinha | ||
| Pilky | does anyone have any experience pushing a bzr branch to a new github repository? | 20:39 |
| === psynaptic|away is now known as psynaptic | ||
| Pilky | I'm trying to do a dpush but it's giving a respository not found error | 20:41 |
| rockstar | abentley, you around? | 21:31 |
| AfC | Shame about bzr-git only using 1 CPU | 22:02 |
| * jelmer waves to AfC | 22:06 | |
| AfC | Hi jelmer | 22:06 |
| 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:07 |
| 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:08 |
| AfC | jelmer: $ bzr checkout git://anongit.freedesktop.org/git/cairo | 22:09 |
| AfC | jelmer: is the command I ran... | 22:09 |
| AfC | Perhaps one to add to the "large foreign repos we performance test" collection. | 22:10 |
| jelmer | AfC: ENOSUCHCOLLECTION ;-) | 22:10 |
| 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:11 |
| AfC | jelmer: doesn't John maintain some large family of test repos, ie Open Office? | 22:15 |
| AfC | jelmer: but anyway | 22:16 |
| AfC | jelmer: yeah, I saw you remark about that. Very cool indeed. | 22:16 |
| jelmer | AfC: Yeah, I think he has something like that, but he tests the converted trees, not the conversion itself. | 22:18 |
| === psynaptic is now known as psynaptic|break | ||
| 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:50 |
| === IceGuest_77 is now known as kingos | ||
| kingos | stats gets the revisions by doing : ancestry = a_repo.get_ancestry(revision)[1:] | 22:52 |
| 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:01 |
| 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:02 |
| spiv | ('bzr ancestry' is a simpler way to see the revisions in the ancestry of a branch) | 23:03 |
| spiv | kingos: "bzr ancestry" and "bzr log -n0 --line" give the same number of lines for me. | 23:05 |
| spiv | (on the two branches I tried, one with 34k revs the other with 688 revs) | 23:06 |
| kingos | hmmm | 23:06 |
| 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:07 |
| 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:08 |
| 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:09 |
| kingos | spiv: I meant with stats | 23:10 |
| spiv | Oh ok. | 23:10 |
| kingos | spiv: bzr stats -r2..5 fails, where as bzr stats -r5 works | 23:14 |
| jelmer | kingos: please file a bug about that | 23:19 |
| jelmer | kingos: does it simply ignore the range or does it crash? | 23:19 |
| kingos | jelmer: It fails with that progress note error | 23:22 |
| 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:23 |
| jelmer | it works happily here with both trunks afaik | 23:24 |
| spiv | jelmer: a puzzle! | 23:24 |
| jelmer | spiv: I'm only getting that error when I specify a range | 23:25 |
| spiv | jelmer: ah, hmm, pebkac in my ~/.bazaar/plugins symlinks | 23:27 |
| jelmer | kingos: can you try with trunk? | 23:27 |
| 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:28 |
| kingos | jelmer: still fails | 23:29 |
| jelmer | kingos: do you have r46? | 23:29 |
| jelmer | can you pastebin the backtrace? | 23:30 |
| kingos | jelmer: backtrace on the ticket | 23:30 |
| kingos | Bug #739823 | 23:30 |
| ubot5 | Launchpad bug 739823 in bzr-stats "bzr stats cannot handle revision ranges like -r2..5" [Undecided,New] https://launchpad.net/bugs/739823 | 23:30 |
| 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:31 |
| kingos | jelmer: no I didn't, that fixes it :( | 23:32 |
| kingos | jelmer: what should I close the bug report with? | 23:32 |
| 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:33 |
| poolie | hi spiv, jelmer, all | 23:44 |
| spiv | Hi poolie | 23:47 |
| jelmer | hi poolie | 23:48 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!