| spiv | Good morning. | 00:14 |
|---|---|---|
| jelmer | moin spiv | 01:06 |
| spiv | jelmer: Morning. | 01:06 |
| spiv | jelmer: Any thoughts on /foo,bar/baz? :) | 01:07 |
| jelmer | spiv: I posted a comment on that MP less than 20 seconds ago | 01:07 |
| jelmer | :-) | 01:07 |
| spiv | Ooh :) | 01:07 |
| poolie | hi spiv, jelmer | 01:15 |
| poolie | biab | 01:15 |
| * igc out for a few hours | 01:43 | |
| poolie1 | thanks for the bug triage, spiv | 02:32 |
| poolie1 | the queue was getting a bit long again | 02:32 |
| spiv | Not a problem. | 02:32 |
| spiv | Do you remember which bug tag we decided on for the content merge hook? content-merge-hook maybe? | 02:34 |
| spiv | Ah, just 'merge-hook' I think | 02:34 |
| spiv | Hmm, my IRC log is inconclusive. | 02:34 |
| spiv | poolie1: care to make a decision (or flip a coin) on that? | 02:35 |
| * spiv goes with 'content-merge-hook' | 02:40 | |
| spiv | Zero new bugs. Time for coffee. | 02:45 |
| lifeless | spiv: I'd just take them merge, myself. | 02:48 |
| poolie1 | spiv: wfm | 03:08 |
| poolie1 | lifeless: the point is to have a name for the feature | 03:08 |
| poolie1 | it's more than just merging | 03:08 |
| === poolie1 is now known as poolie | ||
| lifeless | poolie: I think too many semantic tags becomes a bit counterproductive | 03:11 |
| poolie | i don't think every bug needs to have precise coordinates in its tags | 03:12 |
| poolie | the original discussion is that we had a few user conversations of saying "you should use that thing like is used for news merges" | 03:12 |
| poolie | and it's worth having some name for that | 03:12 |
| === samurai is now known as samiam | ||
| lifeless | poolie: http://www.rendell.org/pebble/software/2010/02/09/1265756844985.html might be an interesting read for you | 06:15 |
| poolie | yes, it is | 06:31 |
| igc | me back | 06:39 |
| poolie | yay | 06:44 |
| poolie | igc i'll see you monday! :) | 06:44 |
| lifeless | spiv: your pull relock is +1 from me | 07:12 |
| lifeless | spiv: lp barfed on my control mail | 07:12 |
| spiv | whee, ok. | 07:12 |
| lifeless | OOPS-1564CEMAIL22 | 07:13 |
| ubottu | https://lp-oops.canonical.com/oops.py/?oopsid=1564CEMAIL22 | 07:13 |
| lifeless | oh wheeee | 07:14 |
| lifeless | ProgrammingError: permission denied for relation codeimport | 07:14 |
| lifeless | spm: ^ | 07:14 |
| lifeless | Methinks we has a problem. | 07:14 |
| lifeless | mwhudson: / thumper: ^ | 07:14 |
| spm | I shall arbritarially blame spiv. No reason other than it's been a while, and hence his turn. | 07:14 |
| lifeless | I'm thinking more 'uhm is all mail merge processing about to go boom' ? | 07:15 |
| spm | gawd I hope not - this has been active since the last rollout I believe.... | 07:15 |
| lifeless | have a look a the oops | 07:16 |
| lifeless | doesn't look like a temporal issue | 07:16 |
| mwhudson | lifeless: what did your merge proposal do? | 07:16 |
| lifeless | mwhudson: review: +1 merge: +1 | 07:16 |
| mwhudson | lifeless: on which branch? | 07:16 |
| mwhudson | is it proposed to merge into a code import branch? | 07:16 |
| lifeless | no | 07:16 |
| lifeless | spivs bzr pull-relock branch | 07:17 |
| lifeless | mwhudson: forwarded you the email | 07:18 |
| mwhudson | lifeless: looks like we do have a problem indeed | 07:19 |
| spm | still sounds like spiv's fault to me | 07:19 |
| lifeless | mwhudson: Yah, I try to avoid the panic button otherwise ;) | 07:19 |
| vila | hi all | 07:20 |
| spm | hey vila! | 07:20 |
| mwhudson | i guess a simple grant select on codeimport will fix it though | 07:20 |
| vila | hey spm !! | 07:20 |
| mwhudson | i'm confused as to how this is only turning up now though | 07:20 |
| spm | lifeless: can you (just being a paranoid sysadmin) easily recreate this to test it works if I run the grant? | 07:21 |
| lifeless | spm: sure | 07:21 |
| spiv | FWIW, I just voted on a bzr branch proposal a few minutes ago via email with no trouble. | 07:22 |
| lifeless | spiv: by no trouble, do you mean 'it has taken effect' | 07:22 |
| spiv | lifeless: yes | 07:23 |
| spiv | Or at least, the email from LP tells me it did ;) | 07:23 |
| mwhudson | oh, i sort of see | 07:26 |
| mwhudson | you have to be able to edit a merge proposal to approve it, obviously | 07:26 |
| mwhudson | this is the check: | 07:26 |
| mwhudson | return (user.inTeam(self.obj.registrant) or | 07:26 |
| mwhudson | user.inTeam(self.obj.source_branch.owner) or | 07:26 |
| mwhudson | check_permission('launchpad.Edit', self.obj.target_branch) or | 07:26 |
| mwhudson | user.inTeam(self.obj.target_branch.reviewer)) | 07:26 |
| mwhudson | the third line there blows up | 07:27 |
| lifeless | mwhudson: I can edit that proposal, can't I ? | 07:27 |
| mwhudson | i guess spiv (and most of us) hit the first couple of lines | 07:27 |
| mwhudson | or indeed, the earlier cases of the check in the third line | 07:27 |
| mwhudson | lifeless: file a bug? | 07:27 |
| lifeless | mwhudson: I don't understand | 07:28 |
| lifeless | mwhudson: I can approve it in the web ui | 07:28 |
| lifeless | mwhudson: why would I be lacking permission in the mail UI ? | 07:28 |
| lifeless | mwhudson: I think you should file the bug, you understand whats going on here. | 07:28 |
| mwhudson | lifeless: it's not a failure of permission, per se | 07:29 |
| mwhudson | lifeless: it's the check that you have permission hitting a db permission issue | 07:29 |
| mwhudson | i'll file the bug | 07:29 |
| mwhudson | lifeless: btw, i wrote some code you'll *really* hate today | 07:29 |
| mwhudson | lifeless: https://pastebin.canonical.com/30468/ | 07:29 |
| lifeless | as opposed to every other day ? :> | 07:30 |
| C-S | Does anybody know how to get the download links from launchpad such as launchpadlibrarian.net/xxxx | 07:30 |
| C-S | ? | 07:30 |
| C-S | I am searching for the correct link to download bzr-gtk | 07:30 |
| lifeless | C-S: hit the web page | 07:30 |
| C-S | lifeless: I know I could do that :-) but I need the link for implementation in the FreeBSD port system | 07:31 |
| lifeless | C-S: FreeBSD should learn to follow redirects :) | 07:31 |
| lifeless | C-S: I'm not being facetious or difficult - thats really the issue. | 07:32 |
| C-S | lifeless: anyhow. I am not sure if it does :-) | 07:32 |
| lifeless | Uhm, wget -S of the url you see in the web page should show you the redirect info | 07:32 |
| C-S | lifeless: cool. I should maybe try both ways. to be honest, the redirect link would work | 07:33 |
| lifeless | mwhudson: so, as I read that, 'if its an import push by copying packs' ? | 07:33 |
| mwhudson | lifeless: yeah | 07:33 |
| C-S | lifeless: but its more comfortable like this. Thanks a lot | 07:33 |
| lifeless | mwhudson: so, uhm, I think this needs some pretty significant justification. And a bug in bzr related to that code bidirectionally, *at a minimum*. | 07:33 |
| mwhudson | lifeless: and copy_tree_to_transport doesn't work when the source is an http transport | 07:33 |
| mwhudson | lifeless: well, part of the justification was dependent on whether it helped | 07:34 |
| lifeless | mwhudson: its also buggy | 07:34 |
| mwhudson | (and i now know that it does) | 07:34 |
| mwhudson | lifeless: i'm not surprised | 07:35 |
| mwhudson | so yeah, i'll send an email/file a bug tomorrow | 07:35 |
| lifeless | to make it less buggy you need to: | 07:36 |
| lifeless | - take the pack names lock | 07:36 |
| mwhudson | lifeless: the basic story is that 2a fetch is slow | 07:36 |
| lifeless | - delete obsolete pack and index files | 07:36 |
| lifeless | by less buggy I mean 'wont blow up hugely eventually' | 07:36 |
| mwhudson | grabbing the kernel import takes ~an hour on the slave, grabbing it via copy_tree_to_transport takes 30 seconds | 07:37 |
| lifeless | mwhudson: why are you copying it around at all ? | 07:38 |
| mwhudson | because that's how the import system has always worked | 07:39 |
| mwhudson | it would be nice to use stacking, but that doesn't work for other crappy reasons | 07:39 |
| mwhudson | (that i should probably dig into) | 07:39 |
| mwhudson | but! | 07:39 |
| mwhudson | tomorrow | 07:39 |
| lifeless | I was thinking lightweight checkout | 07:39 |
| lifeless | not stacking | 07:39 |
| mwhudson | hm, might work i guess | 07:40 |
| mwhudson | the puller has the same issue though | 07:41 |
| mwhudson | i guess there would be other ways around that | 07:41 |
| mwhudson | but really | 07:41 |
| mwhudson | tomorrow | 07:41 |
| lifeless | ^^ | 07:44 |
| AfC | I'm trying to follow jam's emails about history-db, and I'm a bit confused. I thought Bazaar's packs were already a database, so I'm a bit vague on how another is helping him? | 08:28 |
| AfC | [there is no criticality whatsoever associated with me knowing what he's talking about, but I enjoy following the engineering discussions here and learn from them] | 08:28 |
| spiv | Horses for courses, AIUI. | 08:28 |
| spiv | I haven't yet looked closely enough to give you a more informed analysis than that, though :) | 08:29 |
| AfC | spiv: jam's emails are kinda long | 08:29 |
| poolie | he tends to be very detailed | 08:30 |
| spiv | I figure he writes so much to let me I don't need to read it, because he's obviously checked everything already ;) | 08:31 |
| AfC | Isn't it funny that we all write too-long emails (expecting people to follow and appreciate our every last detail), but complain at everyone else having the temerity to write long messages that have detail. | 08:32 |
| lifeless | so | 08:33 |
| lifeless | bzr's repository is a database | 08:33 |
| lifeless | there is a particular query that we have to do a table scan to answer today | 08:33 |
| lifeless | jam has been working on a schema to avoid that table scan when answering that query | 08:34 |
| lifeless | and doing it as a plugin for more freedom in testing and deploying it. | 08:34 |
| lifeless | it may end up part of our core database, or a separate one (partitioning for different write patterns) eventually; | 08:34 |
| lifeless | note that its new db content, not a new db engine | 08:35 |
| AfC | lifeless: plugin, sure. Adding an sqlite dependency, that seemed a bit odd. | 08:35 |
| lifeless | oh, did he? I missed that | 08:35 |
| vila | AfC: a key point in the experiment is that it's easier *today* to do range queries | 08:35 |
| * AfC could be wrong | 08:35 | |
| lifeless | uhm, thats likely expediency | 08:35 |
| AfC | lifeless: no doubt. | 08:35 |
| lifeless | preprocessing graphs for range queries is a well studied problem in the literature | 08:35 |
| AfC | lifeless: but on the other hand, you might want to be careful lest that gets too far out into the wild | 08:35 |
| lifeless | I don't know if jam looked into that. | 08:35 |
| AfC | reputation and memes 'n all that | 08:36 |
| lifeless | AfC: I don't follow | 08:36 |
| vila | AfC: I share these concerns | 08:36 |
| vila | :) | 08:36 |
| AfC | "Bazaar is so inefficient they had to turn to sqlite to store their data. Which is yet another format change. God these guys are idiots. And another dependency to boot" | 08:37 |
| AfC | all of that is untrue, but we have had a PR problem for a long time | 08:37 |
| lifeless | oh | 08:37 |
| lifeless | *if* we need a better k-v store, I'd rather use sqlite than roll our own for the sake of it. | 08:38 |
| lifeless | and sqlite is really really good | 08:38 |
| * AfC has to get going cycling home before it gets too dark | 08:39 | |
| AfC | see ya | 08:39 |
| lifeless | ciao | 08:39 |
| AfC | [sorry to run out on an interesting topic] | 08:39 |
| spiv | lifeless: so if we're using subunit on PQM now, should we try --parallel as well? | 08:41 |
| lifeless | spiv: the machine is old | 08:42 |
| lifeless | spm: please confirm balleny's cpu core count | 08:42 |
| lifeless | spiv: (we could do --parallel without subunit btw) | 08:42 |
| spm | lifeless: 1. | 08:43 |
| lifeless | spiv: ^ | 08:43 |
| lifeless | we could use the EC2 plugin on the canonical UEC cloud | 08:43 |
| lifeless | with a little work | 08:43 |
| spm | or #cores == #cpus :-) | 08:43 |
| spm | ... or bribe me to sneak a pqm instance onto eg wildcherry.... :-P | 08:44 |
| lifeless | spm: what would that take? | 08:44 |
| lifeless | a VM on there would be fine. | 08:45 |
| spiv | Ah ok. For reason I had misremembered that our PQM had more than that. | 08:45 |
| spiv | s/For/For some/ | 08:45 |
| lifeless | spiv: I think the new LP pqm box doth have it | 08:45 |
| spm | lifeless: joke. not going to happen. LP main DB server? I think not. :-) | 08:45 |
| spiv | lifeless: and a crushingly slow test suite to match! | 08:45 |
| lifeless | spm: go back far enough .... | 08:45 |
| spm | spiv: is *that* your fault then?? (still trying to pin blame on teflon-spiv here...) | 08:46 |
| lifeless | spm: yes, I believe spiv did the first commit to launchpad, so its clearly all his fault. | 08:46 |
| spm | we have a blame | 08:46 |
| spiv | I did? I guess it's possible... | 08:50 |
| lifeless | spiv: your previous flat; a demo with the basical url dispatch and what was that orm again | 08:51 |
| bialix | hi all | 08:58 |
| spiv | lifeless: that does ring a vague bell, yeah... | 09:32 |
| spiv | lifeless: a long time ago :) | 09:32 |
| lifeless | in a flat far far away! | 09:33 |
| edgimar | If I have checked out a branch via "bzr checkout --lightweight", how do I get the revision that the directory is currently associated with? | 09:49 |
| edgimar | revno just gives me the lastest revision of the branch from what I can tell. | 09:50 |
| edgimar | (which isn't necessarily the revision associated with the files currently in my local directory.) | 09:52 |
| lifeless | bzr revision-info --tree | 09:53 |
| edgimar | lifeless, ok thanks. I wonder why it needs to be so complex -- I would intuitively like "bzr revno" to do that for me, but oh well... | 09:54 |
| lifeless | edgimar: well, one of the two has to be the default :) | 09:54 |
| edgimar | I should be able to find out the latest revision just by 'bzr log' -- or there could (should?) be a 'bzr latestrevno' command. | 09:56 |
| vila | hey bialix | 09:56 |
| vila | edgimar: 'bzr revno' *is* the latest, using an option or using a different command anyway... | 09:57 |
| bialix | heya vila! | 09:58 |
| vila | edgimar: when the tree and branch revnos disagree bzr is generally issuing a warning about using 'bzr update', did you encounter a case where it didn't ? | 09:58 |
| edgimar | vila, right - I wan't it not to be the latest, but to be "my current". | 09:58 |
| vila | edgimar: as lifeless said, one of them should be the default and I think there are more cases where you want it to be the branch one, so use --tree | 09:59 |
| awilkins | edgimar, bzr qlog has an indicator on the log list where the tree is at | 10:00 |
| vila | jelmer: ping | 10:00 |
| edgimar | awilkins, ok - good to know. | 10:02 |
| edgimar | awilkins, is qlog a standard command in bzr? | 10:03 |
| bialix | edgimar: no, it's from QBzr plugin | 10:07 |
| edgimar | one other question: how do I update to a specific revision number? it seems that "update" won't work for this? | 10:10 |
| edgimar | ok found it - revert. | 10:12 |
| edgimar | If I have a lightweight checkout, though, and I do "bzr revert <filename>", does it change the file to the *latest* revision, or just the revision which you get from 'bzr revision-info --tree'? | 10:17 |
| edgimar | Hmm, revert doesn't seem to work at all for lightweight checkouts -- I get bzr: ERROR: Cannot lock LockDir(chroot-47767537201040:///bzrroot/path/to/repo/.bzr/branch/lock): Transport operation not possible: readonly transport | 10:20 |
| edgimar | So does that mean that there's no way to switch your tree to a different rev with a lightweight checkout? | 10:21 |
| lifeless | edgimar: I thought we fixed that bug | 10:32 |
| lifeless | edgimar: what bzr release are you using ? | 10:32 |
| edgimar | 2.0.2 | 10:42 |
| edgimar | lifeless ^^ | 10:43 |
| lifeless | edgimar: its merged into 2 | 10:46 |
| lifeless | 2.0.6 shouldhave the fix | 10:47 |
| edgimar | ok. | 10:47 |
| lifeless | 2.0.5 might have it | 10:47 |
| lifeless | it was merged 9th march | 10:47 |
| lifeless | if you wanted to test and let me know that would be grand ;) | 10:47 |
| edgimar | I can't right away, but perhaps if I have some spare time later. | 10:48 |
| lifeless | sure | 10:49 |
| lifeless | uhm | 10:49 |
| lifeless | https://bugs.edge.launchpad.net/bzr/+bug/498409 is the bug | 10:49 |
| ubottu | Launchpad bug 498409 in bzr "bzr revert takes a branch lock" [Medium,Fix released] | 10:49 |
| lifeless | just for your reference | 10:49 |
| lifeless | poolie: still around ? | 10:50 |
| lifeless | poolie: please pencil a quick call with me tomorrow am :P | 10:50 |
| awilkins | Anyone know a good comparision of bzr-svn vs git-svn ? | 11:46 |
| jelmer | awilkins: in what sense? | 11:47 |
| awilkins | jelmer, In the sense - what features does each support, what are the differences | 11:54 |
| awilkins | jelmer, Not especially fussed about performance but it's nice to know | 11:54 |
| awilkins | jelmer, e.g. - I've not played with git enough, but from a cheatcard I saw today there's a special command for pushing to SVN but in bzr I know you just push (in general) - that sort of thing | 11:55 |
| awilkins | Thinking of using git for a versioned data store for a particular project and realised that I haven't used git beyond playing with it. | 11:55 |
| dcoles | Bazaar uses the svn props to you can roundtrip via a svn repository | 11:56 |
| dcoles | Which is actually quite nice | 11:56 |
| awilkins | Currently I manage my local branches of the sources via bzr-svn, but I thought I should switch to git-svn and dogfood for a bit to gain some familiarity | 11:56 |
| dcoles | (though can confuse the heck out of non-bzr people) | 11:56 |
| dcoles | I think git initialises a subversion metadata directory on the client side... not sure if it pushes extra stuff to the svn repo | 11:58 |
| jelmer | dcoles: no, it doesn't push extra stuff to the svn repo afaik | 12:01 |
| === mrevell is now known as mrevell-lunch | ||
| === mrevell-lunch is now known as mrevell | ||
| lelit | hi all! I'm back on my svn->bzr switch... I was using "bzr branch https+urllib://..." for my tests; to move faster, I got a local copy of my svn repos, so I thought there was a "bzr+svn://local/path"... Is there? | 13:32 |
| lelit | I got the thing with "svn+ssh://localhost/", but maybe I'm missing an even better way | 13:32 |
| lelit | doh, bzr does magics :) | 13:35 |
| lelit | branch file:///local/path works as (un)expected :) | 13:35 |
| jelmer | lelit: hi | 13:42 |
| jelmer | lelit: yep :-) | 13:42 |
| lelit | jelmer, is there a trick to get just a subtree with that url? | 13:43 |
| lelit | I mean, I get an error trying "branch file:///repos-path/branches/interested-in" | 13:44 |
| jelmer | lelit: what error? | 13:45 |
| lelit | ERROR: Not a branch: "..." | 13:47 |
| lelit | uhm, wait | 13:48 |
| === vds1 is now known as vds | ||
| lelit | jelmer: ignore that, sorry | 13:50 |
| edgimar | lifeless: I checked the problem I had before with bzr 2.1.1, and it still occurs (same error). | 14:13 |
| * awilkins is being driven mad by the obliqueness of git | 14:34 | |
| jelmer | edgimar: I think lifeless is probably asleep (he's in .au) | 14:38 |
| edgimar | jelmer, ok- I guess he'll see it sometime - I'll check back later... | 14:44 |
| === grahal_ is now known as grahal | ||
| AfC | awilkins: I observed in here the other day that I saw the Git book from O'Reilly ... and that it was very confusing. | 15:00 |
| vila | jelmer: ping | 15:05 |
| vila | jelmer: lowering the alert level about using name=name instead of name, it was due to an overly aggressively blind local patch to bzr-loom, | 15:06 |
| vila | jelmer: the remark still stand though, since you're adding a keyword arg than can be None, better use the name= syntax to avoid breakage | 15:07 |
| jelmer | vila: I agree it's a good idea to use name= anyway | 15:07 |
| vila | jelmer: cool :) | 15:07 |
| abadger1999 | jelmer: I've updated https://code.launchpad.net/~toshio/bzr-gtk/handle-dirty-patches/+merge/18856 | 15:52 |
| abadger1999 | jelmer: But the web ui hasn't updated yet and I'm seeing problems with the branch. (bzr log traceback) | 15:52 |
| jelmer | abadger1999: hi | 15:53 |
| abadger1999 | jelmer: Let me know if it gives you problems when you review it. | 15:53 |
| jelmer | abadger1999: thanks | 15:54 |
| abadger1999 | jelmer: Sure, not a problem. | 15:54 |
| jelmer | abadger1999: I see only one revision as well | 15:54 |
| === IslandUsurper is now known as IslandUsurperAFK | ||
| jelmer | abadger1999: I guess there should be more? | 15:55 |
| abadger1999 | jelmer: Yep. If you bzr branch lp:~toshio/bzr-gtk/handle-patch-fix | 15:55 |
| abadger1999 | The second is present in diff.py | 15:56 |
| abadger1999 | *second change | 15:56 |
| abadger1999 | But the branch is definitely not happy (bzr log => bzrlib.exceptions.SyntaxError, bzr diff -r last:1 => ReisionNotPresent) | 15:58 |
| abadger1999 | You could manually diff against lp:bzr-gtk | 15:58 |
| abadger1999 | Or I could create a new branch | 15:59 |
| jelmer | can you create a new branch perhaps? | 16:00 |
| jelmer | I'll promise to review it today | 16:00 |
| abadger1999 | okay | 16:00 |
| === deryck is now known as deryck[lunch] | ||
| abadger1999 | jelmer: https://code.launchpad.net/~toshio/bzr-gtk/handle-patch-dirty/+merge/23330 | 16:22 |
| * abadger1999 submits bzr bug for the corrupted branch | 16:23 | |
| === IslandUsurperAFK is now known as IslandUsurper | ||
| jelmer | abadger1999: thanks and thanks :-) | 16:23 |
| abadger1999 | :-) | 16:24 |
| vila | abadger1999: you're toshio !!!! I would have never guessed :-/ | 16:28 |
| abadger1999 | vila: Hehe :-) Yeah, we need and irc nick::name mapping :-) | 16:29 |
| vila | abadger1999: indeed :) It's already hard to map nick <-> face :) | 16:29 |
| jelmer | abadger1999: I'll have a look in an hour or two | 16:40 |
| abadger1999 | jelmer: Thanks. No hurries -- I'm just processing my downstream bug queue :-) | 16:41 |
| jelmer | abadger1999: :-) | 16:42 |
| * jelmer wished launchpad supported recognizing merges based on patch contents rather than revids, that would make +activereviews really useful for this sort of thing | 16:43 | |
| === deryck[lunch] is now known as deryck | ||
| === beuno is now known as beuno-lunch | ||
| jam | vila: still around? | 17:33 |
| * vila cries in log code :( | 17:35 | |
| vila | morning jam | 17:35 |
| jam | hey vila. I think I responded to your request for history-db info. I'd be happy to chat more directly about it. | 17:52 |
| jelmer | vila: btw, thanks for that --strict fix | 17:54 |
| vila | jam: reading | 17:54 |
| vila | jam: sorry EOD time has come, I promised :-/ So, roughly: my feeling is that you should either: 4) profit for lp and loggerhead OR keep hammering until you get something that can be backported | 18:03 |
| jam | so I think 'hammering until backported' should block on me finishing the rework of PackCollection | 18:04 |
| jam | and possibly the annotation cache | 18:04 |
| vila | the later means an incremental merge sort at a minimum (if I understand you correctly) based on gdfo or anything else (I don't care that much :) | 18:04 |
| vila | jam: yup | 18:04 |
| vila | jam: I think the plugin is already worth deploying for lp/lh | 18:05 |
| vila | jam: by the way, I fixed a typo: | 18:05 |
| vila | jam: http://paste.ubuntu.com/413761/ my revno is 90 | 18:06 |
| jam | I don't make typos, the world just doesn't know how to spell consistently with me :) | 18:07 |
| fullermd | Wait, vila FIX a typo? | 18:07 |
| * vila notes | 18:07 | |
| * fullermd core dumps. | 18:07 | |
| vila | LOL | 18:07 |
| vila | fullermd: thanks for making my day end in a good laugh, I needed that :) | 18:07 |
| jam | fullermd: actually, I would say vila fixes his typos all the time :) | 18:07 |
| === beuno-lunch is now known as beuno | ||
| jam | have a good evening vila | 18:07 |
| * fullermd waves at vila. | 18:08 | |
| vila | jam: I'll try to answer to your mail with more details later or tomorrow | 18:08 |
| vila | jelmer: hehe, in fact I high-jacked your bug, we discussed it far before and I thought there was a bug for it until you filed yours ;-) | 18:10 |
| durin42 | jelmer: hi | 18:25 |
| durin42 | jelmer: gotta get legal approval for contributing to another project, will take me a couple of hours depending on latency there | 18:25 |
| cody-somerville | I'm doing a bzr pull and its causing bzr to crash with TooManyConcurrentRequests | 18:52 |
| fullermd | That error is usually a knock-on from something else... | 18:54 |
| cody-somerville | yes indeed | 18:59 |
| cody-somerville | odd | 19:06 |
| cody-somerville | 'bzr --pull merge <branch>' works though | 19:06 |
| cody-somerville | (it did a pull and not a merge too) | 19:06 |
| fullermd | I'm slightly surprised that that works, but merge --pull WILL do a pull if it can. | 19:07 |
| cody-somerville | aye | 19:41 |
| cody-somerville | just wonder whats causing just plain ol' bzr pull to crash | 19:41 |
| __monty__ | I'm looking for some help with a bug, this one to be precise: https://bugs.launchpad.net/bzr/+bug/45599 | 19:51 |
| ubottu | Launchpad bug 45599 in bzr ""no repository present" error should suggest using bzr branch" [Wishlist,In progress] | 19:51 |
| jam | cody-somerville: my guess, some plugin you have (like bzr-search) which is trying to do something other than 'just pull', and isn't triggering from 'bzr merge --pull' | 20:47 |
| mwhudson | huh | 21:55 |
| mwhudson | clicking around http://bazaar.staging.launchpad.net/~mwhudson/linux/trunk/files is reasonably performant | 21:55 |
| mwhudson | a pleasant surprise :) | 21:55 |
| lifeless | edgimar: yes, its not in 2.1.1 yet | 22:15 |
| lifeless | edgimar: we have multiple release branches - 2.0.x, 2.1.x, 2.2.x, for users wanting stability. | 22:22 |
| lifeless | edgimar: the upshot of this is that a fix in 2.0.Z isn't necessarily in 2.1.B, for any B - you have to check the date of the releases. | 22:23 |
| lifeless | mwhudson: can you land that patch please, I haven't gotten across the new landing procedures yet | 22:25 |
| mwhudson | lifeless: sure | 22:25 |
| lifeless | mwhudson: also, were there docs I should have updated, that describe the limit to end users ? | 22:25 |
| lifeless | mwhudson: could the diff be related to db-devel/devel split ? though only one unmerged revision shows... | 22:28 |
| mwhudson | lifeless: i very much doubt it | 22:28 |
| mwhudson | lifeless: db-devel/devel, yes maybe | 22:28 |
| lifeless | mwhudson: and devel was the right branch to target for this change ? | 22:28 |
| mwhudson | lifeless: yes | 22:28 |
| mwhudson | lifeless: we do have edge codehosting now, so it makes sense to target devel | 22:28 |
| lifeless | ok cool | 22:29 |
| mwhudson | i guess that' | 22:30 |
| mwhudson | s another reason for some kind of authenticated lp:-resolution: we can direct beta testers to bazaar.edge.launchpad.net | 22:31 |
| lifeless | mwhudson: or we could just assign some % to edge | 22:33 |
| lifeless | and monitor stats about behaviour | 22:33 |
| lifeless | :P | 22:34 |
| mwhudson | well, it's been a while since we had a really bad bug in codehosting... | 22:35 |
| lifeless | mwhudson: did you review by email ? | 22:36 |
| lifeless | or web ui ? | 22:36 |
| mwhudson | lifeless: web ui | 22:37 |
| lifeless | thanks | 22:39 |
| lifeless | one bug fixed, two bugs filed. | 22:39 |
| lifeless | its going to be one of those days ;) | 22:39 |
| mwhudson | lifeless: so, to continue from last night, i'd like to talk about why i did that packs hackery | 22:44 |
| lifeless | ok | 22:44 |
| lifeless | did you mean voice when you say talk ? | 22:44 |
| mwhudson | no, i think irc will be fine | 22:44 |
| lifeless | kk | 22:44 |
| mwhudson | basically the problem is the amount of cpu entailed in doing a from-scratch fetch of a kernel-sized 2a branch | 22:45 |
| lifeless | right | 22:45 |
| lifeless | we validate all the data - process it not dumb copy | 22:45 |
| lifeless | we don't do any cross checks | 22:46 |
| mwhudson | right | 22:46 |
| lifeless | [not expensive ones anyway - we do check that all the texts are present etc] | 22:46 |
| lifeless | it also trims unreferenced data, which is important for privacy | 22:46 |
| lifeless | if you commit a password, uncommit it, and then push; the password revision must not propogate | 22:47 |
| mwhudson | but in my case i really don't care about this | 22:47 |
| mwhudson | i just want to move the files from there to here | 22:48 |
| mwhudson | because i control the process that produced the branch | 22:48 |
| lifeless | why don't you rsync, or copy the entire branch that way | 22:48 |
| mwhudson | because, boringly, the branch is accessed over http | 22:48 |
| lifeless | the thing that is particularly squicky is copying only some data as a dumb fs operation | 22:48 |
| mwhudson | i guess changing that is probably the right thing to do | 22:49 |
| mwhudson | then i can use copy_tree_to_transport again, and not grub around in pack internals | 22:49 |
| lifeless | I mean, if you say 'hey, I cp -a, which you guys support, and X happens', in the future, we're in a good position to analyse and fix without false starts | 22:49 |
| awilkins | I found 2a a lot more cpu-hungry than the previous formats, I really noticed it | 22:49 |
| awilkins | Especially the periodic repacks | 22:50 |
| lifeless | awilkins: thats interesting; was it also *longer*, or just more intense ? | 22:50 |
| lifeless | awilkins: and do you have the C extensions built ? | 22:50 |
| mwhudson | lifeless: is there scope to make the checks/filtering faster in the medium term? | 22:50 |
| awilkins | lifeless, definitely longer ; C extensions built. Not sure how typical the trees I have are | 22:50 |
| lifeless | mwhudson: there is scope to (for instance) preserve intact the packs structure and avoid all compression overhead | 22:51 |
| lifeless | mwhudson: however without looking at current profiling data I can't really comment on time to make improvements | 22:52 |
| lifeless | mwhudson: nor what scale they would be | 22:52 |
| mwhudson | lifeless: over the internet you don't really notice, but over the data centre network or if you use 2a branches without a shared repo, you definitely notice the cpu cost of 2a | 22:52 |
| lifeless | mwhudson: how long does git take to do a full scratch clone | 22:52 |
| lifeless | of linux, for a head-head comparison | 22:52 |
| mwhudson | lifeless: yeah, don't know | 22:52 |
| lifeless | git does a similar amount of conceptual work | 22:53 |
| lifeless | so a reasonable comparison point | 22:53 |
| mwhudson | wow, my isp must have really done something useful recently | 22:59 |
| lifeless | ? | 22:59 |
| mwhudson | getting ~1 megabyte a second download for the kernel | 22:59 |
| lifeless | who are you using ? | 23:00 |
| mwhudson | that sort of thing never used to happen | 23:00 |
| mwhudson | lifeless: vodafone | 23:00 |
| lifeless | wired ? | 23:00 |
| mwhudson | adsl | 23:00 |
| mwhudson | (2+) | 23:00 |
| lifeless | interesting | 23:00 |
| lifeless | I'll have to consider staying with them next month | 23:00 |
| mtaylor | yup | 23:00 |
| mwhudson | oh rught | 23:00 |
| lifeless | vodafone NZ seems a lot more sane | 23:00 |
| mwhudson | right | 23:00 |
| mwhudson | mmm | 23:00 |
| lifeless | than AU | 23:00 |
| mwhudson | customer support is a bit flaky | 23:01 |
| mwhudson | but i don't have experience with anyone else | 23:01 |
| lifeless | mwhudson: I was impressed by their forums... where engineers actually post! | 23:01 |
| lifeless | with helpful comments! | 23:01 |
| lifeless | this is unheard of in .au | 23:01 |
| mwhudson | i thought all techy people were on internode in .as | 23:01 |
| mwhudson | .au | 23:01 |
| lifeless | mwhudson: vodafone are only mobile here | 23:02 |
| lifeless | internode are only really wired | 23:02 |
| mwhudson | oh right | 23:02 |
| lifeless | so yes, I'm with internode :) | 23:02 |
| mwhudson | well for mobile you don't get a lot of choice here :) | 23:02 |
| lifeless | It would be fun to have international number portability | 23:03 |
| lifeless | mwhudson: 3 providers I think, for mobile? | 23:03 |
| lifeless | mwhudson: or is it 4 ? | 23:03 |
| mwhudson | vodafone (big megacorp) telecom (ex monopoly) telstra (ex .au monopoly, don't have their own network i think) 2degrees (payg only) | 23:03 |
| lifeless | hmm | 23:03 |
| lifeless | and you chose? | 23:03 |
| mwhudson | voda | 23:04 |
| mwhudson | i think they are the best choice | 23:04 |
| mwhudson | but the customer service is a bit crap | 23:04 |
| mwhudson | telecom's network has had some embarrassing outages | 23:04 |
| lifeless | clear were pretty good when I was there | 23:05 |
| mwhudson | now telstraclear -- probably enough to put anyone who's spent time in .au off? :) | 23:06 |
| lifeless | tempting to knee jerk | 23:07 |
| lifeless | however as the underdog I'd expect them to actually have to do shit in NZ | 23:07 |
| mwhudson | also they don't have their own network, i think they resell voda | 23:07 |
| lifeless | mwhudson: for mobile, heh that would be entertaining | 23:07 |
| lifeless | mwhudson: for backhaul they should have their own network | 23:08 |
| lifeless | they started with the railway country backbone | 23:08 |
| poolie | hi all | 23:12 |
| poolie | (phone) | 23:12 |
| mwhudson | lifeless: git clone git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6.31.y.git took 8m24 wall clock and 1m39 user, 25s sys | 23:14 |
| lifeless | ok, significantly faster | 23:15 |
| mwhudson | yes | 23:15 |
| lifeless | so | 23:15 |
| lifeless | its worth having a bug open I think | 23:15 |
| mwhudson | a local clone took 20s | 23:15 |
| * lifeless twitches | 23:15 | |
| lifeless | mwhudson: for your copy, can you guarantee noone else is writing to the source branch when you make your copy? | 23:16 |
| mwhudson | i guess not, strictly speaking | 23:19 |
| lifeless | so, you'll need to loop | 23:19 |
| lifeless | until your copy and the source mach | 23:19 |
| lifeless | match | 23:19 |
| lifeless | bzr does this a little more cleverly | 23:19 |
| mwhudson | how do i tell if they match? | 23:19 |
| mwhudson | sha1 the pack-names or somethign? | 23:19 |
| lifeless | same ls -lR | 23:20 |
| lifeless | uhm | 23:20 |
| lifeless | first approximation is list-and-copy everything; list again, and if its changed copy everything again | 23:21 |
| lifeless | as copying is fast we don't expect this to be a problem | 23:21 |
| lifeless | particularly as this the exceptional case, not the normal case | 23:21 |
| james_w | lifeless: seen http://chasmd.org/ ? | 23:30 |
| lifeless | james_w: yes | 23:30 |
| lifeless | in discussion with them about collaboration; I think lmirror is substantially more complete at this point | 23:30 |
| james_w | looks like it | 23:33 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!