s from "some/branch : changes" to "/some/branch : changes"? [23:03] <beuno> no, whatever goes into debug.log [23:03] <beuno> WARNING:simpleTALES.Context:Exception occurred evaluating python path, exception: name 'url' is not defined [23:04] <beuno> I have *no* idea where that came from === mw is now known as mw|brb === Mathilda is now known as uws === mw|brb is now known as mw [23:28] <beuno> Peng_, re bug #247992 [23:28] <ubottu> Launchpad bug 247992 in loggerhead "Visiting just "/download" or "/download/" redirects to a bad URL" [Undecided,New] https://launchpad.net/bugs/247992 [23:28] <beuno> how is it that you end up in /download? [23:29] <Necoro> hmm ... by the way - is there sourcecode highlighting support for loggerhead? [23:30] <Necoro> and if yes: is there a reason, it isn't turned on LP? [23:30] <beuno> Necoro, nope. But there may be if you file a bug requesting it :) [23:31] <Necoro> I'll do when I'm bored ;) ... [23:32] <beuno> good, I prefer exciting bugs [23:32] <beuno> :p [23:33] <Necoro> beuno: http://pygments.org/ =P [23:34] <beuno> Necoro, oh, did I mention we *love* patches? [23:34] <beuno> even boring ones! [23:35] <beuno> either way, we'd have to make it optional. I don't want to add another dependency for this [23:35] <Necoro> I hope, LH has some way of configuration =P [23:36] <beuno> oh, codescanner just came back from the dead [23:37] <Necoro> anyways ... time for bed ;) ... I'll see what I can do tomorrow ^^ [23:44] * beuno is off to a dinner [23:50] <lifeless> jam: if you want to talk reachability we could skype [23:53] <jam> lifeless: sure, though I don't have long before the standup, and we're going on a walk after that (I guess I could skip the standup today) [23:55] <lifeless> up to you - poolie said you were interested in what I'm thinking about is all [23:58] <igc> morning

[00:00] lifeless: I've been working on a lazy revno mapper, which seems to work well (sometimes) [00:00] I'm considering ways to refine it [00:00] jam: is it in bzr.dev? [00:00] lifeless: the *code* is in a branch (not a plugin) [00:00] Has anybody noticed a regression in permissions in the repo? [00:00] And I'm planning on submitting it for review [00:00] jam: ok [00:00] though I might still want to tweak it a bit [00:00] I don't have power at home right now [00:01] but [00:01] jam: I have two use cases that I don't think will work well.. [00:01] tags and search [00:01] http://bzr.arbash-meinel.com/1.6-dev/lazy_revno when I do [00:01] Hm. There is. [00:01] both tend to grab data from fairly evenly distributed bits of the graph and then want a revno for it [00:01] lifeless: sure, but you can still do it with local ops [00:01] instead of traversing the whole graph [00:02] lifeless: at the moment, the time is strictly dominated by 'get_parent_map' calls o [00:02] on my pack repo [00:02] jam, spiv, igc, call in a sec [00:02] lifeless: found the commit in the kernel - and the workaround [00:02] jam: right, I agree that you can examine less than whole [00:02] so I'm trying to find ways to minimize "leaks" [00:03] * fullermd files a bug. [00:03] jam: but on a 100K tree getting to the root is still what - 20K operations vs 1 for a tag name retrieval and for a search result [00:04] lifeless: I don't need to get to root [00:04] lifeless: just to the common ancestor [00:04] sure [00:05] my point is that unlike merges or 'log' these two operations tend to throw stuff up at or near root routinely [00:06] for example, 45ms for 3512.2.4 [00:06] lifeless: i can see your point [00:06] how long for '3' ? :) [00:08] running timeit now [00:08] for extra credit, how long cold cache [00:08] 936ms on the pack repo [00:08] * fullermd arrogantly assigns it 'critical' status. [00:11] you got an alogrithm that didn't have to find root? neat. [00:11] or maybe I had that, I forget [00:12] at least yours works :-) [00:12] james_w: no, I started from scratch :) [00:12] lifeless: 617ms with a fully packed repo [00:12] jam: not the common case :) [00:12] as I mentioned, dominated by the get_parent_map time [00:12] might want to try on a btree repo [00:13] sure, something to do later [00:13] family time in the dark for now [00:13] :) [00:14] wheee [00:19] lifeless: unpacked btree repo is 787ms versus 936ms for pack-0.92 [00:20] good [00:30] jelmer: dh_python: Doing nothing since dh_pycompat exists; dh_pysupport or dh_pycentral should do the work. You can remove dh_python from your rules file. [00:31] elmo: Yeah, I noticed that as well. I need to look into avoiding that warning when using cdbs. [00:33] jelmer: both uploaded [00:33] elmo: Thanks, much appreciated! [00:39] Hmm, to follow the usual schedule, I think 1.6 final should've been released shortly after 1.6b2. [00:40] The new smart protocol would've been the most interesting new feature. [00:45] JFYI over here, we are in no rush for 1.6. [00:45] release early release often is great, but BZR has been meeting our needs since 1.0. [00:48] spiv, any chance of having the smart server support upgrade for 1.7? [00:49] evarlast: Sure, but pushing the release back constantly to support large new features isn't very good. [00:53] Peng_: and how many times has that been done in bzr? [00:55] jelmer: there's a patch on the list for that, so that probably will happen. [00:56] jelmer: I should say it will happen, I just don't want to cram yet another thing into 1.6 :) [00:57] if there are no branches or tags, only a trunk/, for an svn repo, will that fudge up the recognition of branching pattern of an svn-import ? [00:58] spiv: W00t, hadn't seen that one :-) [00:59] spiv, It would be nice to have that in 1.6 actually now that it has started whining when branches are in an old format [00:59] * meteoroid wonders if there are ebuilds for 1.6 [00:59] meteoroid, that should work fine [00:59] jelmer: phew, i get so tired of creating empty branches and tags when svn cp will (i think) create them [00:59] i read somewhere that rename doesnt work when performed in bzr and pushed to svn, is that true? anything i should be sure to do from svn instead of bzr? [01:00] dato: Hmm, 0.15 was in the RC stage for a month. [01:00] i am basically using bzr as much as i can to interface with these tortoise users ;d [01:00] jelmer: by "support" I just mean "works over vfs operations" rather than "performs the upgrade server-side". [01:01] meteoroid, no, rename works fine [01:01] awesome [01:01] meteoroid, renames done from svn aren't pulled into bzr ok [01:01] oh, really? [01:01] meteoroid, since svn doesn't support proper renames [01:01] what happens? [01:01] meteoroid, only copy + delete [01:01] really? lame. [01:01] bad svn [01:03] spiv: Ahh, ok [01:03] spiv: I was hoping for running it server-side [01:06] so, i tried to follow the tutorial for setting up rw webdav for my bzr repos, but when i start apache, i get: Unknown DAV provider: filesystem [01:06] glad to post the virtualhost in question [01:06] using ubuntu hardy - maybe i only have dav_svn, and not dav_normal ? [01:07] cant find a package indicative of such support.. [01:38] jelmer: what does the numeric 2nd argument in a SubversionException indicate? [01:38] an svn error code? [01:38] markh: Yep [01:38] * markh tries grepping... === mw is now known as mw|out [01:40] markh: What error code are you seeing? [01:40] 175002 pulling the python trunk - but only after a long time, so its possible it was transient. I'm retrying now [01:41] retrieving revision 462 or 40113 now - it will be a while if it works :) [01:41] of [01:42] jelmer: what does renaming in svn do to the bzr copy? [01:44] markh, 175002 is SVN_RA_DAV_ERROR IIRC [01:44] markh, In other words "Something went wrong talking webdav" [01:44] meteoroid: Renaming in svn basically means the file appearing to be deleted and readded under a different name in bzr [01:45] thanks - I'll see how the new attempt goes. But at around 1 revision every 2 seconds, it will be many many hours :( [01:45] you may want to obtain a local copy of the svn repo [01:46] or just pick a smaller one - it seemed a convenient one to test :) [01:50] hello [01:50] i have a big problem with bzr [01:51] pollelu@confino:~/rapache-icons$ bzr push lp:~rapache-devel/rapache/design [01:51] Agent admitted failure to sign using the key. [01:51] Permission denied (publickey). [01:51] bzr: ERROR: Connection closed: please check connectivity and permissions (and try -Dhpss if further diagnosis is required) [01:51] pollelu@confino:~/rapache-icons$ [01:51] some idea? [01:51] Agent admitted failure to sign using the key. [01:52] you are on Intrepid? [01:52] yes [01:52] that's a problem with gnome-keyring and/or seahorse [01:52] Im working in intrepid [01:52] running "ssh-add" should fix it [01:52] ok thanks [01:54] thanks Master of BZR, my problem is now solved :) [01:55] jelmer: ok not a big problem just ugly change history and loss of ancestry :/ [01:56] meteoroid, yep [01:56] meteoroid, hopefully bzr will support file copies at some point [01:57] lifeless, wecanhas pathtokens? [01:59] * meteoroid hopes with his crossed fingers [02:00] Verterok, did u end up releasing that new version? [02:01] gambler: Hi, I'm struggling with a concurrency bug... [02:02] so, not yet...but trying to get this fixed so it can be "usable" [02:03] Verterok, ok no rush, let me know when to test [02:03] gambler: sure, thanks! [02:03] :S [02:04] gambler: I'll try to (at least) seed a "unofficial" build ;) [02:04] no rush :) [02:05] jml: Thanks for the review. :D I've scanned through it and will sit down and deal with it properly tomorrow. [02:11] beautiful : http://www.etsy.com/view_listing.php?listing_id=12792904 [02:57] Sorry for the length :) I'm a little confused about merging. I've 2 branches, one a pristine copy of the upstream branch (.dev), and another .work branch, branched from the local .dev branch. The branches diverged for a while, but as the changes landed upstream, and therefore in the .dev branch, all were merged successfully and the branches now appear identical. However, every time I attempt to re-pull .work from .dev, it fails telling [02:59] markh: has your local branch been fully merged by bzr.dev? [02:59] markh: bzr missing will tell you [03:00] lifeless: ah, no - it says I have 3 extra ones. [03:01] but they are all merges :) [03:01] It says I'm missing 4, but I think they are the ones I'm yet to merge-commit from .dev. (The branches in question are actually bzr-svn ones) [03:02] so if you only have extra merges; you can pull --overwrite [03:04] ah - right - and that well "re-converge" them? [03:04] will [03:06] it will discard your extra commits [03:12] by "extra" you mean the merges I had to make? [03:20] Odd_Bloke: my pleasure. [03:24] markh: yes [03:29] I guess its conceptual - help for '--overwrite' tells me it will let me forget local changes - but from my POV I don't have any local changes - the branches seem "identical". So once branches have diverged, --overwrite is the only way to "reconverge" them? [03:36] markh: or to have your branch merged into bzr.dev [03:36] markh: an older version of your branch was merged; but you have made subsequent changes that were not merged [03:37] markh: when you do 'commit' you are recording a change [03:38] yeah, or changes that were tweaked etc before being applied [03:39] markh: "changes" is perhaps a confusing term. There can changes to content, but there can also be different revision histories without having different content. If you don't care about the history differences (and it sounds like you don't, given that they are just trivial merges), then you can use --overwrite to replace your branch with a copy of trunk. [03:39] yeah, I understand now, thanks. It seemed like I was forever doomed to merge/commit cycles on that branch which seemed insane :) [03:40] spiv: yeah, casual reading made me assume it was simply a shortcut for reverting changes before pulling [03:41] hi all [03:42] igc: hey! [03:42] igc: how's it going? [03:42] pong lifeless [03:42] lifeless: thanks for the explanation [03:42] hi spiv [03:42] igc: hi [03:42] hi markh [03:42] spiv: not so good this week [03:42] markh: generally I just wouldn't be keeping branches with no content differences in the first place, though. [03:43] markh: thus I never find myself making pointless merge commits that I want to throw away :) [03:43] spiv: well, although the branches are currently identical, there is a good chance other work will be done, so keeping that .work branch around made sense [03:43] igc: I feared as much, you haven't been around much. :( [03:43] so --overwrite says ignore differences [03:43] igc: that's no good :( You able to keep distracted? [03:43] I think it should be more precise [03:43] igc: :( [03:44] markh: well I'm sleeping almost continuously [03:46] I need to head up to the hospital for my daily visit in 15-20 minutes but I thought I'd quickly say hi and skim my 100s of emails before then [03:46] igc: we're good at producing emails :) [03:47] markh: did your changes to setup.py get merged yet? [03:47] yuck - i hope you can stay positive [03:47] markh: I volunteered to merge it after tweaks [03:48] igc: not yet, I haven't got back to reworking that patch yet. I saw that - thanks! [03:48] markh: just checking you weren't waiting on me [03:48] nope - thanks - I'll let you know when I am ;) [03:50] hey all, I've borked the logs of an LP bzr branch by making changes to a local branch, then merging from lp, then commiting the merge, and finally pushing the changes [03:50] igc: its not actually a real priority for me to be honest, especially while it appears I will be making the binaries themselves anyway. It wouldn't surprise me to find other tweaks necessary before a 1.6 final... [03:50] should I have done a pull instead of merge? [03:50] is there a way to restore the logs? [03:50] * markh lunches... [03:51] markh: np [03:51] apologies if this isn't the correct place to ask [03:52] sommer: this is the right place [03:52] sommer: which branch? in what way is it borked? [03:52] spiv: https://code.edge.launchpad.net/~ubuntu-core-doc/ubuntu-doc/ubuntu-intrepid [03:53] spiv: basically I overwrote the commit messages of another [03:53] spiv: happened in revision 62: http://bazaar.launchpad.net/~ubuntu-core-doc/ubuntu-doc/ubuntu-intrepid/revision/62 [03:54] it's happened before, but I couldn't find the steps to correct it [04:02] sommer: I'm not sure what you mean by "overwrote". Are you referring to the revisions by Matthew East visible at http://bazaar.launchpad.net/~ubuntu-core-doc/ubuntu-doc/ubuntu-intrepid/changes?start_revid=59.1.6 ? [04:03] spiv: yes, that's what I mean [04:03] spiv: I guess not really overwritten, but if the main branch had them it would be better :) [04:04] well I guess they're still there, but the revision number was at something like 67 [04:04] sommer: so, the history is correct. The problem is just that the display of revisions at bazaar.launchpad.net isn't as good as it should be. [04:05] spiv: yes, is there a way to correct that? [04:05] sommer: the revision numbers are specific to a particular branch. When you merge changes from another branch the history will change. [04:05] mwhudson: ^ ping? [04:05] mwhudson: what happened to showing the authors of merged revisions in loggerhead? [04:05] spiv: right, do other projects just use the new revision number then? or is there a preferred way to sync rev numbers? [04:06] sommer: why do you care about revision numbers? [04:06] spiv: to be honest, *I* don't, but my guess is others may [04:06] sommer: or do you just care about giving credit to the right person? [04:06] spiv: credit is good to [04:07] olckS brydcbi-o p.annf jdabi.o yd.p. [04:07] :) [04:07] * igc lunch [04:07] spiv: so nothing's really changed there [04:07] spiv: it's been talked about, is all [04:08] mwhudson: I'm sure I saw a beautiful mockup at some point :) [04:08] mwhudson: ETA for the feature? [04:08] sommer: so, to credit the right person, mainly what needs to happen is that Launchpad should be displaying better information in this situation. [04:09] sommer: i.e. it sounds like you're doing everything just fine. [04:09] spiv: cool, I guess I just wanted to make sure, thanks man [04:10] sommer: optionally though, next time you could do "bzr commit --author='A. Nother Person'" when committing a merge, I think that will cause existing Launchpad (and "bzr log", etc) to primarily show that rather than you. [04:10] spiv: depends on tuit supply [04:10] spiv: you mean this sort of thing? http://people.ubuntu.com/~mwh/hacked_up_changelog_view_3.png [04:11] sommer: (the fact that you committed the revision is still recorded, it just also adds an extra property saying that you say the author is someone else) [04:11] spiv: or the one that displays a list of committer names where only one name is displayed now? [04:11] anyway, sprinting [04:11] mwhudson: right. [04:11] mwhudson: So, +1 from me for doing that one sooner rather than later, FWIW [04:11] (which isn't very much, most likely...) [04:12] spiv: it's probably not that hard for a seasoned bzr hacker! [04:12] Heh. [04:15] we should add a ui to set append_revisions_only [04:15] or perhaps make that the default for 'bzr init' [04:15] or something [04:20] does that prevent uncommit? [04:21] option "dont_let_user_accidentally_oush_over_non_lh_parent" true [04:23] mwhudson: it does, but we could teach uncommit to ask about overriding it [04:27] is it expected that if I run bzr status from outside the branch's dir, the doesn't show the pending merges? [04:27] Verterok just bumped into that, and we think it's a bug [04:31] mwhudson, I've been eyeballing bug #240542, but I'm not sure what the idea is for start/stop-loggerhead scripts. I get the feeling you want to nuke em [04:31] Launchpad bug 240542 in loggerhead "Provide a description for nesting urls" [Undecided,Confirmed] https://launchpad.net/bugs/240542 [04:31] beuno: i think i want to ignore them for a while, then delete them [04:31] beuno: but i can probably be persuaded otherwise [04:31] beuno: you mean 'bzr st foo' where foo is a tree? [04:32] mwhudson, I've been thinking about persuading you, but I have less and less reasons to [04:32] lifeless, yeap [04:32] mwhudson, I do want some sort of global config at some point, but we may want to use serve-branches, and wherever we place it [04:33] beuno: right, yes, the no-config-at-all approach that serve-branches had clearly isn't going to work in the long term [04:34] mwhudson, ok, I'll un-target that bug, if I find out how [04:34] confirmed [04:34] its a bug [04:35] Verterok, you won a bug report [04:35] beuno: Verterok: please file a bug; high importance [04:35] lifeless: ok, thanks for confirming it [04:39] lifeless, re: bug #248018 [04:39] Launchpad bug 248018 in loggerhead/1.6 "slow search results override fast ones" [High,Confirmed] https://launchpad.net/bugs/248018 [04:40] yes! [04:40] pls fix [04:40] I'm thinking about ignoring the you if you type one letter [04:40] in addition to fixing the bug [04:40] hmm [04:40] btw [04:40] the 200ms thing confuses people [04:40] can I suggest just requesting at each keystroke [04:41] hm [04:41] as long as the best search array so far is whats shown it will be correct, and it give people a hint [04:41] I don't think the server will like getting hit so many times [04:42] if I take away the timer, then every single keystrole will get sent [04:42] I'm pretty sure that's not a good idea [04:42] ok [04:42] well let me describe what I see people do [04:42] they type in a search very quickly [04:42] and hit enter [04:43] they never even realise it can do completion because they don't pause long enough [04:43] so its not discoverable [04:43] that's not necessarily a bad thing, if they already know so exactly what they want, it makes sense for the find-as-you type to be ignored, no? [04:43] not when I'm showing people bling [04:43] I do agree it's not very discoverable [04:44] hahah [04:44] ok, we can have a special show-off edition [04:44] even more cool would be word-completing as they type [04:44] no timer, and a cube like compiz [04:44] com|mit [04:44] with the | being where the insertion cursor is, and mit being pulled from the completion results [04:45] ah, that would be cool [04:45] (this is where completion for exclusion terms is still useful btw) [04:45] Even if you don't fire off a query, showing the autocomplete box with a dim "(autocompleting...)" or something in it might be good for discoverability. [04:45] (and this is why I'm saying 200ms is _way_ too long) [04:45] as I type a term in... [04:45] so "rapid-type-then-hit-enter" still works, but at least the user gets a signal about the possibility of doing it a different way in the mean time. [04:46] all the results are contained in the first response recieved from the search engine [04:46] the more they type the smaller the response set is all [04:46] when we start doing ranking [04:46] spiv, that's already sort of the case. It says "loading" when you start typing [04:46] and doing clipping [04:46] then that may change [04:46] beuno: no it doesn't [04:47] beuno: it says it when you pause, at least for me [04:47] For bonus cool: preload the page the with the first N autocompletes for each letter of the alphabet, so you can give instant results! [04:47] beuno, lifeless: done, Bug #255204 [04:47] spiv: indeed, that needs ranking though [04:47] Launchpad bug 255204 in bzr "bzr status doesn't show pending merges when executed outside the branch dir" [Undecided,New] https://launchpad.net/bugs/255204 [04:47] lifeless, ah, you're right, it doesn't. It should. [04:47] lifeless: well, the ranking could be "the order I plucked these out of the db" ;) [04:47] beuno: anyhow, what I'd *like* is that when I start typing it does in-field completion of the first entry in the completion results [04:48] lifeless, I need to handle sessions to be able to contain and trim results before sending the response [04:48] lifeless: and the complete results could be retrieved after the 200ms timer or something, if you want that. [04:48] spiv: it is today, but thats not so useful :) [04:48] Ranking strikes me as an orthogonal issue. [04:48] beuno: I don't really care about *how* it does this, just that that is what I would like to give our users. [04:48] But an important one for making search useful, I agree :) [04:48] beuno: if that sounds nice, we can move on to talking about *how* [04:49] lifeless, in-field completion would be cool. Not sure how I would do that with javascript, but I can't think of a reason it wouldn't work [04:49] lifeless, it does [04:49] I'd really prefer doing clipping on the server side [04:49] beuno: yes, me too [04:49] rather than dropping requests on the cliente side [04:49] hm [04:49] beuno: erm, terminology :) [04:50] dropping requests is needed because of async nature of the beast [04:50] clipping is about sending less than the full set of results because, or ordering whats sent so that partially-recieved data is maximally useful [04:51] * spiv enfoodinates. [04:51] lifeless, agreed. The interaction needs a lot of work to be impressive [04:51] spiv: I think ranking is technically orthogonal but not user-experience orthogonal [04:51] beuno: as a thought experiment, whats wrong with requesting on each keystroke? [04:52] in broad terms [04:52] lifeless, the server performing one search per character [04:52] beuno: thats all ? [04:53] lifeless, yeap, it waists tons of resources [04:53] imagine that on Launchpad [04:53] beuno: it will be fine :) [04:53] beuno: so, without being silly [04:54] lets imagine you dedicate a thread to the client [04:54] they ask for ('a',) [04:54] you start a search for completions [04:54] they ask for ('ab',) [04:54] you cancel the first search and start a search for completions for ('ab',) [04:54] etc [04:55] at some point your searches complete faster than their requests come in, and they get completions happening [04:55] lifeless, that works fine. The thing is, we currently don't handle sessions in LH, so I can't really do that today [04:55] as to remember who requested what, on the server side [04:55] beuno: I'm not sure it needs sessions but I'll defer that to you [04:56] I could fake sessions, I guess... [04:56] in fact, all it really needs is a nonce per completion-interaction - the same thing sent in every completion request [04:56] and that would solve both our concerns [04:56] hrm [04:57] but thats just me being tricky and pointing out that generic sessions are >>> what this needs [04:57] that plus inline completion would be magic [04:57] plus arrow down to other completion results [04:57] plus ranking [04:58] plus number of results [04:58] plus color depending on the depth of the history [04:58] or type of result returned [04:59] well completions are interesting, because they are not looking at documents, only terms - most terms I think will show up in most document types eventually [04:59] but sure [04:59] you could be looking for a committer's name [04:59] http://gadgetopia.com/autosuggest/ [05:00] that does mouse-into-the-completion-widget [05:00] ah, you can go down with your arrow keys [05:01] thought its buggy [05:01] yours is better about handling typing and deletion etc [05:01] yeah, it's not very polished [05:01] but I thought you might like to see their code (LGPL!) for the arrow support [05:01] lifeless, I do, thanks. I can use parts of that [05:02] good thing is, as it stands now, I should be starting full time with Canonical con monday, so I'll have plenty of time to dive into this :p [05:02] congrats [05:02] thats been rather submarine news :) [05:02] hahah [05:03] yeah, it's not 100% official yet, so no blog post, yadadada, but we worked the remaining issued out today and set a startinf date [05:03] hi beuno [05:03] very very cool cool [05:03] and thanks, I'm excited [05:03] hey poolie [05:05] I wonder if flash is needed to do what we want [05:05] god no [05:05] we can do this with javascript, just need to bend the rules a little bit [05:05] please let's not go anywhere near flash :) [05:06] beuno: so what are you going to be focusing on most for canonical? [05:06] thumper, it's a bit blurry ATM, but mainly UI on most canonical projects. And, loggerhead :) [05:07] beuno: cool [05:07] beuno: loggerhead needs some memory love [05:08] thumper, yeah, I already have something in the works to work around the "too many changed files" issue [05:08] ajax to the rescue [05:08] I wasn't aware of the issue [05:08] I just know that loggerhead chews up memory [05:08] when run for a while [05:09] thumper, it times out on some requests [05:09] see bug #254892 [05:09] Launchpad bug 254892 in launchpad-bazaar "Cannot view r2704 of ~mysql/mysql-server/mysql-4.1" [Undecided,New] https://launchpad.net/bugs/254892 [05:09] of course, we have to do some profiling to find out where the memory hog is today [05:10] a *lot* has changed in the past few months [05:12] iooh right [05:12] beuno: so on the files listing [05:12] the revnos link to a 'filtered by fileid' view [05:13] beuno: this is not good for performance [05:15] mwhudson, ah, right, and doesn't really *do* anything, does it? [05:15] not really [05:15] feel like fixing it? :) [05:16] mwhudson, sure, easy fix. Just link to the revno. I can do that now [05:16] ta :) [05:21] mwhudson, committed!D [05:23] :) [05:27] does canonical employ/engage a graphic artist by any chance? [05:28] markh, talk to Joey Stanford, we do graphic work for Canonical [05:29] beuno: is that work gratis? Or do I first need to speak to someone from canonical to approve it? :) [05:30] markh: what do you need? [05:30] markh, canonical, approve [05:30] The windows icon needs lovin, and we need a tortoise ;) [05:30] a pissing chinese tortoise? [05:30]