[00:14] <spiv> Good morning.
[01:06] <jelmer> moin spiv
[01:06] <spiv> jelmer: Morning.
[01:07] <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:15] <poolie> hi spiv, jelmer
[01:15] <poolie> biab
[01:43]  * igc out for a few hours
[02:32] <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:34] <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:35] <spiv> poolie1: care to make a decision (or flip a coin) on that?
[02:40]  * spiv goes with 'content-merge-hook'
[02:45] <spiv> Zero new bugs.  Time for coffee.
[02:48] <lifeless> spiv: I'd just take them merge, myself.
[03:08] <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:11] <lifeless> poolie: I think too many semantic tags becomes a bit counterproductive
[03:12] <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
[06:15] <lifeless> poolie: http://www.rendell.org/pebble/software/2010/02/09/1265756844985.html might be an interesting read for you
[06:31] <poolie> yes, it is
[06:39] <igc> me back
[06:44] <poolie> yay
[06:44] <poolie> igc i'll see you monday! :)
[07:12] <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:13] <lifeless> OOPS-1564CEMAIL22
[07:14] <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:15] <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:16] <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:17] <lifeless> spivs bzr pull-relock branch
[07:18] <lifeless> mwhudson: forwarded you the email
[07:19] <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:20] <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:21] <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:22] <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:23] <spiv> lifeless: yes
[07:23] <spiv> Or at least, the email from LP tells me it did ;)
[07:26] <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:27] <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:28] <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:29] <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:30] <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:31] <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:32] <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:33] <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:34] <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:35] <mwhudson> lifeless: i'm not surprised
[07:35] <mwhudson> so yeah, i'll send an email/file a bug tomorrow
[07:36] <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:37] <mwhudson> grabbing the kernel import takes ~an hour on the slave, grabbing it via copy_tree_to_transport takes 30 seconds
[07:38] <lifeless> mwhudson: why are you copying it around at all ?
[07:39] <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:40] <mwhudson> hm, might work i guess
[07:41] <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:44] <lifeless> ^^
[08:28] <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:29] <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:30] <poolie> he tends to be very detailed
[08:31] <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:32] <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:33] <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:34] <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:35] <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:36] <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:37] <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:38] <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:39]  * 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:41] <spiv> lifeless: so if we're using subunit on PQM now, should we try --parallel as well?
[08:42] <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:43] <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:44] <spm> ... or bribe me to sneak a pqm instance onto eg wildcherry.... :-P
[08:44] <lifeless> spm: what would that take?
[08:45] <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:46] <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:50] <spiv> I did?  I guess it's possible...
[08:51] <lifeless> spiv: your previous flat; a demo with the basical url dispatch and what was that orm again
[08:58] <bialix> hi all
[09:32] <spiv> lifeless: that does ring a vague bell, yeah...
[09:32] <spiv> lifeless: a long time ago :)
[09:33] <lifeless> in a flat far far away!
[09:49] <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:50] <edgimar> revno just gives me the lastest revision of the branch from what I can tell.
[09:52] <edgimar> (which isn't necessarily the revision associated with the files currently in my local directory.)
[09:53] <lifeless> bzr revision-info --tree
[09:54] <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:56] <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:57] <vila> edgimar: 'bzr revno' *is* the latest, using an option or using a different command anyway...
[09:58] <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:59] <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
[10:00] <awilkins> edgimar, bzr qlog has an indicator on the log list where the tree is at
[10:00] <vila> jelmer: ping
[10:02] <edgimar> awilkins, ok - good to know.
[10:03] <edgimar> awilkins, is qlog a standard command in bzr?
[10:07] <bialix> edgimar: no, it's from QBzr plugin
[10:10] <edgimar> one other question: how do I update to a specific revision number?  it seems that "update" won't work for this?
[10:12] <edgimar> ok found it - revert.
[10:17] <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:20] <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:21] <edgimar> So does that mean that there's no way to switch your tree to a different rev with a lightweight checkout?
[10:32] <lifeless> edgimar: I thought we fixed that bug
[10:32] <lifeless> edgimar: what bzr release are you using ?
[10:42] <edgimar> 2.0.2
[10:43] <edgimar> lifeless ^^
[10:46] <lifeless> edgimar: its merged into 2
[10:47] <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:48] <edgimar> I can't right away, but perhaps if I have some spare time later.
[10:49] <lifeless> sure
[10:49] <lifeless> uhm
[10:49] <lifeless> https://bugs.edge.launchpad.net/bzr/+bug/498409 is the bug
[10:49] <lifeless> just for your reference
[10:50] <lifeless> poolie: still around ?
[10:50] <lifeless> poolie: please pencil a quick call with me tomorrow am :P
[11:46] <awilkins> Anyone know a good comparision of bzr-svn vs git-svn ?
[11:47] <jelmer> awilkins: in what sense?
[11:54] <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:55] <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:56] <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:58] <dcoles> I think git initialises a subversion metadata directory on the client side... not sure if it pushes extra stuff to the svn repo
[12:01] <jelmer> dcoles: no, it doesn't push extra stuff to the svn repo afaik
[13:32] <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:35] <lelit> doh, bzr does magics :)
[13:35] <lelit> branch file:///local/path works as (un)expected :)
[13:42] <jelmer> lelit: hi
[13:42] <jelmer> lelit: yep :-)
[13:43] <lelit> jelmer, is there a trick to get just a subtree with that url?
[13:44] <lelit> I mean, I get an error trying "branch file:///repos-path/branches/interested-in"
[13:45] <jelmer> lelit: what error?
[13:47] <lelit> ERROR: Not a branch: "..."
[13:48] <lelit> uhm, wait
[13:50] <lelit> jelmer: ignore that, sorry
[14:13] <edgimar> lifeless:  I checked the problem I had before with bzr 2.1.1, and it still occurs (same error).
[14:34]  * awilkins is being driven mad by the obliqueness of git
[14:38] <jelmer> edgimar: I think lifeless is probably asleep (he's in .au)
[14:44] <edgimar> jelmer, ok- I guess he'll see it sometime - I'll check back later...
[15:00] <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:05] <vila> jelmer: ping
[15:06] <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:07] <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:52] <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:53] <jelmer> abadger1999: hi
[15:53] <abadger1999> jelmer: Let me know if it gives you problems when you review it.
[15:54] <jelmer> abadger1999: thanks
[15:54] <abadger1999> jelmer: Sure, not a problem.
[15:54] <jelmer> abadger1999: I see only one revision as well
[15:55] <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:56] <abadger1999> The second is present in diff.py
[15:56] <abadger1999> *second change
[15:58] <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:59] <abadger1999> Or I could create a new branch
[16:00] <jelmer> can you create a new branch perhaps?
[16:00] <jelmer> I'll promise to review it today
[16:00] <abadger1999> okay
[16:22] <abadger1999> jelmer: https://code.launchpad.net/~toshio/bzr-gtk/handle-patch-dirty/+merge/23330
[16:23]  * abadger1999 submits bzr bug for the corrupted branch
[16:23] <jelmer> abadger1999: thanks and thanks :-)
[16:24] <abadger1999> :-)
[16:28] <vila> abadger1999: you're toshio !!!! I would have never guessed :-/
[16:29] <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:40] <jelmer> abadger1999: I'll have a look in an hour or two
[16:41] <abadger1999> jelmer: Thanks.  No hurries -- I'm just processing my downstream bug queue :-)
[16:42] <jelmer> abadger1999: :-)
[16:43]  * jelmer wished launchpad supported recognizing merges based on patch contents rather than revids, that would make +activereviews really useful for this sort of thing
[17:33] <jam> vila: still around?
[17:35]  * vila cries in log code :(
[17:35] <vila> morning jam
[17:52] <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:54] <jelmer> vila: btw, thanks for that --strict fix
[17:54] <vila> jam: reading
[18:03] <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:04] <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:05] <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:06] <vila> jam: http://paste.ubuntu.com/413761/ my revno is 90
[18:07] <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] <jam> have a good evening vila
[18:08]  * fullermd waves at vila.
[18:08] <vila> jam: I'll try to answer to your mail with more details later or tomorrow
[18:10] <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:25] <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:52] <cody-somerville> I'm doing a bzr pull and its causing bzr to crash with TooManyConcurrentRequests
[18:54] <fullermd> That error is usually a knock-on from something else...
[18:59] <cody-somerville> yes indeed
[19:06] <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:07] <fullermd> I'm slightly surprised that that works, but merge --pull WILL do a pull if it can.
[19:41] <cody-somerville> aye
[19:41] <cody-somerville> just wonder whats causing just plain ol' bzr pull to crash
[19:51] <__monty__> I'm looking for some help with a bug, this one to be precise: https://bugs.launchpad.net/bzr/+bug/45599
[20:47] <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'
[21:55] <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 :)
[22:15] <lifeless> edgimar: yes, its not in 2.1.1 yet
[22:22] <lifeless> edgimar: we have multiple release branches - 2.0.x, 2.1.x, 2.2.x, for users wanting stability.
[22:23] <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:25] <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:28] <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:29] <lifeless> ok cool
[22:30] <mwhudson> i guess that'
[22:31] <mwhudson> s another reason for some kind of authenticated lp:-resolution: we can direct beta testers to bazaar.edge.launchpad.net
[22:33] <lifeless> mwhudson: or we could just assign some % to edge
[22:33] <lifeless> and monitor stats about behaviour
[22:34] <lifeless> :P
[22:35] <mwhudson> well, it's been a while since we had a really bad bug in codehosting...
[22:36] <lifeless> mwhudson: did you review by email ?
[22:36] <lifeless> or web ui ?
[22:37] <mwhudson> lifeless: web ui
[22:39] <lifeless> thanks
[22:39] <lifeless> one bug fixed, two bugs filed.
[22:39] <lifeless> its going to be one of those days ;)
[22:44] <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:45] <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:46] <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:47] <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:48] <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:49] <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:50] <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:51] <lifeless> mwhudson: there is scope to (for instance) preserve intact the packs structure and avoid all compression overhead
[22:52] <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:53] <lifeless> git does a similar amount of conceptual work
[22:53] <lifeless> so a reasonable comparison point
[22:59] <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
[23:00] <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:01] <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:02] <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:03] <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:04] <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:05] <lifeless> clear were pretty good when I was there
[23:06] <mwhudson> now telstraclear -- probably enough to put anyone who's spent time in .au off? :)
[23:07] <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:08] <lifeless> mwhudson: for backhaul they should have their own network
[23:08] <lifeless> they started with the railway country backbone
[23:12] <poolie> hi all
[23:12] <poolie> (phone)
[23:14] <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:15] <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:16] <lifeless> mwhudson: for your copy, can you guarantee noone else is writing to the source branch when you make your copy?
[23:19] <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:20] <lifeless> same ls -lR
[23:20] <lifeless> uhm
[23:21] <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:30] <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:33] <james_w> looks like it