[00:14] Good morning. [01:06] moin spiv [01:06] jelmer: Morning. [01:07] jelmer: Any thoughts on /foo,bar/baz? :) [01:07] spiv: I posted a comment on that MP less than 20 seconds ago [01:07] :-) [01:07] Ooh :) [01:15] hi spiv, jelmer [01:15] biab [01:43] * igc out for a few hours [02:32] thanks for the bug triage, spiv [02:32] the queue was getting a bit long again [02:32] Not a problem. [02:34] Do you remember which bug tag we decided on for the content merge hook? content-merge-hook maybe? [02:34] Ah, just 'merge-hook' I think [02:34] Hmm, my IRC log is inconclusive. [02:35] poolie1: care to make a decision (or flip a coin) on that? [02:40] * spiv goes with 'content-merge-hook' [02:45] Zero new bugs. Time for coffee. [02:48] spiv: I'd just take them merge, myself. [03:08] spiv: wfm [03:08] lifeless: the point is to have a name for the feature [03:08] it's more than just merging === poolie1 is now known as poolie [03:11] poolie: I think too many semantic tags becomes a bit counterproductive [03:12] i don't think every bug needs to have precise coordinates in its tags [03:12] 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] and it's worth having some name for that === samurai is now known as samiam [06:15] poolie: http://www.rendell.org/pebble/software/2010/02/09/1265756844985.html might be an interesting read for you [06:31] yes, it is [06:39] me back [06:44] yay [06:44] igc i'll see you monday! :) [07:12] spiv: your pull relock is +1 from me [07:12] spiv: lp barfed on my control mail [07:12] whee, ok. [07:13] OOPS-1564CEMAIL22 [07:13] https://lp-oops.canonical.com/oops.py/?oopsid=1564CEMAIL22 [07:14] oh wheeee [07:14] ProgrammingError: permission denied for relation codeimport [07:14] spm: ^ [07:14] Methinks we has a problem. [07:14] mwhudson: / thumper: ^ [07:14] I shall arbritarially blame spiv. No reason other than it's been a while, and hence his turn. [07:15] I'm thinking more 'uhm is all mail merge processing about to go boom' ? [07:15] gawd I hope not - this has been active since the last rollout I believe.... [07:16] have a look a the oops [07:16] doesn't look like a temporal issue [07:16] lifeless: what did your merge proposal do? [07:16] mwhudson: review: +1 merge: +1 [07:16] lifeless: on which branch? [07:16] is it proposed to merge into a code import branch? [07:16] no [07:17] spivs bzr pull-relock branch [07:18] mwhudson: forwarded you the email [07:19] lifeless: looks like we do have a problem indeed [07:19] still sounds like spiv's fault to me [07:19] mwhudson: Yah, I try to avoid the panic button otherwise ;) [07:20] hi all [07:20] hey vila! [07:20] i guess a simple grant select on codeimport will fix it though [07:20] hey spm !! [07:20] i'm confused as to how this is only turning up now though [07:21] lifeless: can you (just being a paranoid sysadmin) easily recreate this to test it works if I run the grant? [07:21] spm: sure [07:22] FWIW, I just voted on a bzr branch proposal a few minutes ago via email with no trouble. [07:22] spiv: by no trouble, do you mean 'it has taken effect' [07:23] lifeless: yes [07:23] Or at least, the email from LP tells me it did ;) [07:26] oh, i sort of see [07:26] you have to be able to edit a merge proposal to approve it, obviously [07:26] this is the check: [07:26] return (user.inTeam(self.obj.registrant) or [07:26] user.inTeam(self.obj.source_branch.owner) or [07:26] check_permission('launchpad.Edit', self.obj.target_branch) or [07:26] user.inTeam(self.obj.target_branch.reviewer)) [07:27] the third line there blows up [07:27] mwhudson: I can edit that proposal, can't I ? [07:27] i guess spiv (and most of us) hit the first couple of lines [07:27] or indeed, the earlier cases of the check in the third line [07:27] lifeless: file a bug? [07:28] mwhudson: I don't understand [07:28] mwhudson: I can approve it in the web ui [07:28] mwhudson: why would I be lacking permission in the mail UI ? [07:28] mwhudson: I think you should file the bug, you understand whats going on here. [07:29] lifeless: it's not a failure of permission, per se [07:29] lifeless: it's the check that you have permission hitting a db permission issue [07:29] i'll file the bug [07:29] lifeless: btw, i wrote some code you'll *really* hate today [07:29] lifeless: https://pastebin.canonical.com/30468/ [07:30] as opposed to every other day ? :> [07:30] Does anybody know how to get the download links from launchpad such as launchpadlibrarian.net/xxxx [07:30] ? [07:30] I am searching for the correct link to download bzr-gtk [07:30] C-S: hit the web page [07:31] lifeless: I know I could do that :-) but I need the link for implementation in the FreeBSD port system [07:31] C-S: FreeBSD should learn to follow redirects :) [07:32] C-S: I'm not being facetious or difficult - thats really the issue. [07:32] lifeless: anyhow. I am not sure if it does :-) [07:32] Uhm, wget -S of the url you see in the web page should show you the redirect info [07:33] lifeless: cool. I should maybe try both ways. to be honest, the redirect link would work [07:33] mwhudson: so, as I read that, 'if its an import push by copying packs' ? [07:33] lifeless: yeah [07:33] lifeless: but its more comfortable like this. Thanks a lot [07:33] 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] lifeless: and copy_tree_to_transport doesn't work when the source is an http transport [07:34] lifeless: well, part of the justification was dependent on whether it helped [07:34] mwhudson: its also buggy [07:34] (and i now know that it does) [07:35] lifeless: i'm not surprised [07:35] so yeah, i'll send an email/file a bug tomorrow [07:36] to make it less buggy you need to: [07:36] - take the pack names lock [07:36] lifeless: the basic story is that 2a fetch is slow [07:36] - delete obsolete pack and index files [07:36] by less buggy I mean 'wont blow up hugely eventually' [07:37] grabbing the kernel import takes ~an hour on the slave, grabbing it via copy_tree_to_transport takes 30 seconds [07:38] mwhudson: why are you copying it around at all ? [07:39] because that's how the import system has always worked [07:39] it would be nice to use stacking, but that doesn't work for other crappy reasons [07:39] (that i should probably dig into) [07:39] but! [07:39] tomorrow [07:39] I was thinking lightweight checkout [07:39] not stacking [07:40] hm, might work i guess [07:41] the puller has the same issue though [07:41] i guess there would be other ways around that [07:41] but really [07:41] tomorrow [07:44] ^^ [08:28] 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] [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] Horses for courses, AIUI. [08:29] I haven't yet looked closely enough to give you a more informed analysis than that, though :) [08:29] spiv: jam's emails are kinda long [08:30] he tends to be very detailed [08:31] 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] 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] so [08:33] bzr's repository is a database [08:33] there is a particular query that we have to do a table scan to answer today [08:34] jam has been working on a schema to avoid that table scan when answering that query [08:34] and doing it as a plugin for more freedom in testing and deploying it. [08:34] it may end up part of our core database, or a separate one (partitioning for different write patterns) eventually; [08:35] note that its new db content, not a new db engine [08:35] lifeless: plugin, sure. Adding an sqlite dependency, that seemed a bit odd. [08:35] oh, did he? I missed that [08:35] 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] uhm, thats likely expediency [08:35] lifeless: no doubt. [08:35] preprocessing graphs for range queries is a well studied problem in the literature [08:35] lifeless: but on the other hand, you might want to be careful lest that gets too far out into the wild [08:35] I don't know if jam looked into that. [08:36] reputation and memes 'n all that [08:36] AfC: I don't follow [08:36] AfC: I share these concerns [08:36] :) [08:37] "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] all of that is untrue, but we have had a PR problem for a long time [08:37] oh [08:38] *if* we need a better k-v store, I'd rather use sqlite than roll our own for the sake of it. [08:38] and sqlite is really really good [08:39] * AfC has to get going cycling home before it gets too dark [08:39] see ya [08:39] ciao [08:39] [sorry to run out on an interesting topic] [08:41] lifeless: so if we're using subunit on PQM now, should we try --parallel as well? [08:42] spiv: the machine is old [08:42] spm: please confirm balleny's cpu core count [08:42] spiv: (we could do --parallel without subunit btw) [08:43] lifeless: 1. [08:43] spiv: ^ [08:43] we could use the EC2 plugin on the canonical UEC cloud [08:43] with a little work [08:43] or #cores == #cpus :-) [08:44] ... or bribe me to sneak a pqm instance onto eg wildcherry.... :-P [08:44] spm: what would that take? [08:45] a VM on there would be fine. [08:45] Ah ok. For reason I had misremembered that our PQM had more than that. [08:45] s/For/For some/ [08:45] spiv: I think the new LP pqm box doth have it [08:45] lifeless: joke. not going to happen. LP main DB server? I think not. :-) [08:45] lifeless: and a crushingly slow test suite to match! [08:45] spm: go back far enough .... [08:46] spiv: is *that* your fault then?? (still trying to pin blame on teflon-spiv here...) [08:46] spm: yes, I believe spiv did the first commit to launchpad, so its clearly all his fault. [08:46] we have a blame [08:50] I did? I guess it's possible... [08:51] spiv: your previous flat; a demo with the basical url dispatch and what was that orm again [08:58] hi all [09:32] lifeless: that does ring a vague bell, yeah... [09:32] lifeless: a long time ago :) [09:33] in a flat far far away! [09:49] 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] revno just gives me the lastest revision of the branch from what I can tell. [09:52] (which isn't necessarily the revision associated with the files currently in my local directory.) [09:53] bzr revision-info --tree [09:54] 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] edgimar: well, one of the two has to be the default :) [09:56] 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] hey bialix [09:57] edgimar: 'bzr revno' *is* the latest, using an option or using a different command anyway... [09:58] heya vila! [09:58] 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] vila, right - I wan't it not to be the latest, but to be "my current". [09:59] 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] edgimar, bzr qlog has an indicator on the log list where the tree is at [10:00] jelmer: ping [10:02] awilkins, ok - good to know. [10:03] awilkins, is qlog a standard command in bzr? [10:07] edgimar: no, it's from QBzr plugin [10:10] one other question: how do I update to a specific revision number? it seems that "update" won't work for this? [10:12] ok found it - revert. [10:17] If I have a lightweight checkout, though, and I do "bzr revert ", does it change the file to the *latest* revision, or just the revision which you get from 'bzr revision-info --tree'? [10:20] 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] So does that mean that there's no way to switch your tree to a different rev with a lightweight checkout? [10:32] edgimar: I thought we fixed that bug [10:32] edgimar: what bzr release are you using ? [10:42] 2.0.2 [10:43] lifeless ^^ [10:46] edgimar: its merged into 2 [10:47] 2.0.6 shouldhave the fix [10:47] ok. [10:47] 2.0.5 might have it [10:47] it was merged 9th march [10:47] if you wanted to test and let me know that would be grand ;) [10:48] I can't right away, but perhaps if I have some spare time later. [10:49] sure [10:49] uhm [10:49] https://bugs.edge.launchpad.net/bzr/+bug/498409 is the bug [10:49] Launchpad bug 498409 in bzr "bzr revert takes a branch lock" [Medium,Fix released] [10:49] just for your reference [10:50] poolie: still around ? [10:50] poolie: please pencil a quick call with me tomorrow am :P [11:46] Anyone know a good comparision of bzr-svn vs git-svn ? [11:47] awilkins: in what sense? [11:54] jelmer, In the sense - what features does each support, what are the differences [11:54] jelmer, Not especially fussed about performance but it's nice to know [11:55] 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] 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] Bazaar uses the svn props to you can roundtrip via a svn repository [11:56] Which is actually quite nice [11:56] 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] (though can confuse the heck out of non-bzr people) [11:58] 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] dcoles: no, it doesn't push extra stuff to the svn repo afaik === mrevell is now known as mrevell-lunch === mrevell-lunch is now known as mrevell [13:32] 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] I got the thing with "svn+ssh://localhost/", but maybe I'm missing an even better way [13:35] doh, bzr does magics :) [13:35] branch file:///local/path works as (un)expected :) [13:42] lelit: hi [13:42] lelit: yep :-) [13:43] jelmer, is there a trick to get just a subtree with that url? [13:44] I mean, I get an error trying "branch file:///repos-path/branches/interested-in" [13:45] lelit: what error? [13:47] ERROR: Not a branch: "..." [13:48] uhm, wait === vds1 is now known as vds [13:50] jelmer: ignore that, sorry [14:13] 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] edgimar: I think lifeless is probably asleep (he's in .au) [14:44] jelmer, ok- I guess he'll see it sometime - I'll check back later... === grahal_ is now known as grahal [15:00] 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] jelmer: ping [15:06] 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] 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] vila: I agree it's a good idea to use name= anyway [15:07] jelmer: cool :) [15:52] jelmer: I've updated https://code.launchpad.net/~toshio/bzr-gtk/handle-dirty-patches/+merge/18856 [15:52] jelmer: But the web ui hasn't updated yet and I'm seeing problems with the branch. (bzr log traceback) [15:53] abadger1999: hi [15:53] jelmer: Let me know if it gives you problems when you review it. [15:54] abadger1999: thanks [15:54] jelmer: Sure, not a problem. [15:54] abadger1999: I see only one revision as well === IslandUsurper is now known as IslandUsurperAFK [15:55] abadger1999: I guess there should be more? [15:55] jelmer: Yep. If you bzr branch lp:~toshio/bzr-gtk/handle-patch-fix [15:56] The second is present in diff.py [15:56] *second change [15:58] But the branch is definitely not happy (bzr log => bzrlib.exceptions.SyntaxError, bzr diff -r last:1 => ReisionNotPresent) [15:58] You could manually diff against lp:bzr-gtk [15:59] Or I could create a new branch [16:00] can you create a new branch perhaps? [16:00] I'll promise to review it today [16:00] okay === deryck is now known as deryck[lunch] [16:22] jelmer: https://code.launchpad.net/~toshio/bzr-gtk/handle-patch-dirty/+merge/23330 [16:23] * abadger1999 submits bzr bug for the corrupted branch === IslandUsurperAFK is now known as IslandUsurper [16:23] abadger1999: thanks and thanks :-) [16:24] :-) [16:28] abadger1999: you're toshio !!!! I would have never guessed :-/ [16:29] vila: Hehe :-) Yeah, we need and irc nick::name mapping :-) [16:29] abadger1999: indeed :) It's already hard to map nick <-> face :) [16:40] abadger1999: I'll have a look in an hour or two [16:41] jelmer: Thanks. No hurries -- I'm just processing my downstream bug queue :-) [16:42] 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 === deryck[lunch] is now known as deryck === beuno is now known as beuno-lunch [17:33] vila: still around? [17:35] * vila cries in log code :( [17:35] morning jam [17:52] 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] vila: btw, thanks for that --strict fix [17:54] jam: reading [18:03] 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] so I think 'hammering until backported' should block on me finishing the rework of PackCollection [18:04] and possibly the annotation cache [18:04] 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] jam: yup [18:05] jam: I think the plugin is already worth deploying for lp/lh [18:05] jam: by the way, I fixed a typo: [18:06] jam: http://paste.ubuntu.com/413761/ my revno is 90 [18:07] I don't make typos, the world just doesn't know how to spell consistently with me :) [18:07] Wait, vila FIX a typo? [18:07] * vila notes [18:07] * fullermd core dumps. [18:07] LOL [18:07] fullermd: thanks for making my day end in a good laugh, I needed that :) [18:07] fullermd: actually, I would say vila fixes his typos all the time :) === beuno-lunch is now known as beuno [18:07] have a good evening vila [18:08] * fullermd waves at vila. [18:08] jam: I'll try to answer to your mail with more details later or tomorrow [18:10] 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] jelmer: hi [18:25] jelmer: gotta get legal approval for contributing to another project, will take me a couple of hours depending on latency there [18:52] I'm doing a bzr pull and its causing bzr to crash with TooManyConcurrentRequests [18:54] That error is usually a knock-on from something else... [18:59] yes indeed [19:06] odd [19:06] 'bzr --pull merge ' works though [19:06] (it did a pull and not a merge too) [19:07] I'm slightly surprised that that works, but merge --pull WILL do a pull if it can. [19:41] aye [19:41] 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 [19:51] Launchpad bug 45599 in bzr ""no repository present" error should suggest using bzr branch" [Wishlist,In progress] [20:47] 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] huh [21:55] clicking around http://bazaar.staging.launchpad.net/~mwhudson/linux/trunk/files is reasonably performant [21:55] a pleasant surprise :) [22:15] edgimar: yes, its not in 2.1.1 yet [22:22] edgimar: we have multiple release branches - 2.0.x, 2.1.x, 2.2.x, for users wanting stability. [22:23] 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] mwhudson: can you land that patch please, I haven't gotten across the new landing procedures yet [22:25] lifeless: sure [22:25] mwhudson: also, were there docs I should have updated, that describe the limit to end users ? [22:28] mwhudson: could the diff be related to db-devel/devel split ? though only one unmerged revision shows... [22:28] lifeless: i very much doubt it [22:28] lifeless: db-devel/devel, yes maybe [22:28] mwhudson: and devel was the right branch to target for this change ? [22:28] lifeless: yes [22:28] lifeless: we do have edge codehosting now, so it makes sense to target devel [22:29] ok cool [22:30] i guess that' [22:31] s another reason for some kind of authenticated lp:-resolution: we can direct beta testers to bazaar.edge.launchpad.net [22:33] mwhudson: or we could just assign some % to edge [22:33] and monitor stats about behaviour [22:34] :P [22:35] well, it's been a while since we had a really bad bug in codehosting... [22:36] mwhudson: did you review by email ? [22:36] or web ui ? [22:37] lifeless: web ui [22:39] thanks [22:39] one bug fixed, two bugs filed. [22:39] its going to be one of those days ;) [22:44] lifeless: so, to continue from last night, i'd like to talk about why i did that packs hackery [22:44] ok [22:44] did you mean voice when you say talk ? [22:44] no, i think irc will be fine [22:44] kk [22:45] basically the problem is the amount of cpu entailed in doing a from-scratch fetch of a kernel-sized 2a branch [22:45] right [22:45] we validate all the data - process it not dumb copy [22:46] we don't do any cross checks [22:46] right [22:46] [not expensive ones anyway - we do check that all the texts are present etc] [22:46] it also trims unreferenced data, which is important for privacy [22:47] if you commit a password, uncommit it, and then push; the password revision must not propogate [22:47] but in my case i really don't care about this [22:48] i just want to move the files from there to here [22:48] because i control the process that produced the branch [22:48] why don't you rsync, or copy the entire branch that way [22:48] because, boringly, the branch is accessed over http [22:48] the thing that is particularly squicky is copying only some data as a dumb fs operation [22:49] i guess changing that is probably the right thing to do [22:49] then i can use copy_tree_to_transport again, and not grub around in pack internals [22:49] 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] I found 2a a lot more cpu-hungry than the previous formats, I really noticed it [22:50] Especially the periodic repacks [22:50] awilkins: thats interesting; was it also *longer*, or just more intense ? [22:50] awilkins: and do you have the C extensions built ? [22:50] lifeless: is there scope to make the checks/filtering faster in the medium term? [22:50] lifeless, definitely longer ; C extensions built. Not sure how typical the trees I have are [22:51] mwhudson: there is scope to (for instance) preserve intact the packs structure and avoid all compression overhead [22:52] mwhudson: however without looking at current profiling data I can't really comment on time to make improvements [22:52] mwhudson: nor what scale they would be [22:52] 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] mwhudson: how long does git take to do a full scratch clone [22:52] of linux, for a head-head comparison [22:52] lifeless: yeah, don't know [22:53] git does a similar amount of conceptual work [22:53] so a reasonable comparison point [22:59] wow, my isp must have really done something useful recently [22:59] ? [22:59] getting ~1 megabyte a second download for the kernel [23:00] who are you using ? [23:00] that sort of thing never used to happen [23:00] lifeless: vodafone [23:00] wired ? [23:00] adsl [23:00] (2+) [23:00]