[00:05] mwhudson: LP's bzr-git is missing 44 revisions from trunk :( [00:05] thumper: !? [00:05] thumper: time for an upgrade i guess? [00:06] yes, I think so [00:06] mwhudson: does that sound like a build engineer task? [00:06] thumper: not especially... [00:07] otoh, i'm not actually doing much else now [00:07] :) [00:07] mwhudson: don't we just have to push it through ec2 with a different bzr-git? [00:07] mwhudson: something like that? [00:08] thumper: i guess landing the branch will still run all the tests in pqm [00:08] mwhudson: does it? [00:08] well [00:08] pqm isn't doing much else right now [00:08] this is true [00:08] although we will want to land a fix for the registry breakage [00:16] mwhudson: I'm going to fix the failing test [00:16] mwhudson: I may get you to review the expected one line fix [00:16] thumper: okidoke [00:17] * thumper makes [00:17] * thumper taps fingers while make makes [00:19] oh yay, jelmer rebased dulwich trunk again [00:19] mwhudson: didn't we register a bug against that particular problem? ;-) [00:20] yeah [00:20] (in Quotes) [00:20] "where" doesn't matter so long as "did" [00:39] mwhudson: http://pastebin.ubuntu.com/266368/ [00:39] mwhudson: it fixes the failure [00:40] thumper: +1, with a sigh on the side [00:40] thumper: please submit it as a [testfix] now [00:40] * thumper nods [00:44] mwhudson: submitted [00:44] thumper: thanks [00:50] mwhudson: hmm? [00:51] mwhudson: I haven't touched dulwich in a while [00:51] jelmer: we haven't updated the version we used in even longer it seems :) [00:52] jelmer, hello [00:52] mwhudson, spm, thumper, et al: hi [00:52] hey jml [00:52] hey jml [00:53] all of my discipline in waking up on time has vanished with my 8am daily call :) [00:58] jml: oops [00:59] jml: adapting yourself to london time, one hour a day? [01:00] mwhudson, heh [01:03] mwhudson, how's buildbot looking? [01:03] jml: reasonably terrible, no worse than usual [01:03] jml: it's building, at least [01:04] mwhudson, that's something, I guess. [01:05] we'll all be surprised if the build doesn't fail though [01:05] mwhudson, I did a test run last night on devel -- there are failing tests [01:05] mwhudson, https://bugs.edge.launchpad.net/launchpad-foundations/+bug/425113 might interest you [01:06] Bug #425113: Some tests can fail without detection [01:06] jml: which ones? [01:06] lib/lp/registry/browser/tests/productseries-views.txt [01:07] jml: oh god [01:07] (the bug) [01:07] jml: thumper fixed that one already [01:07] glad to hear it :) [01:07] mwhudson, yeah, the bug is going to require some patches to Twisted, I think. [01:08] though i don't know where his fix went [01:08] thumper: did your submission fail? [01:08] mwhudson: :( [01:08] yes [01:08] forgot the ui tag [01:08] hee [01:08] as it isn't needed in normal testfixes [01:08] but is for fake test fixes [01:11] thumper, btw, bug 425399 is yet another bug in the cluster of "tighter review integration" [01:11] Bug #425399: too many clicks to get to important review [01:12] * thumper nods [01:12] jml: I saw it [01:14] cool. [01:16] thumper, btw, something interesting came up on the weekend -- would be keen to chat about it with you [01:17] jml: ok, heating pizza now, how about in 10 minutes? [01:17] thumper, sounds good :) [01:25] jml: if you don't mind hearing me munching, we can talk now [01:25] thumper, cool [01:28] jml: looks like I lost a group member - but I think we can still do the project just fine [01:28] jml: I've been thinking about it more [01:29] MTeck, cool [01:29] MTeck, how many does that leave you with? [01:30] jml: 3 total [01:31] MTeck, ahh, that's plenty :) [01:31] jml: should be plenty for it [01:31] ya :P [01:32] MTeck, so you've been thinking about it? [01:32] I'm planning on it [02:03] jml, spiv, thumper: https://pastebin.canonical.com/21867/ (for bug 424136) [02:03] Bug #424136: Cannot upgrade stacked branches from 1.9 to 2a on Launchpad [02:04] hm, why did i use canonical pastebin? [02:04] habit i guess [02:04] http://pastebin.ubuntu.com/266396/ [02:05] mwhudson: extra carriage return between tests, but other than that r=thumper [02:06] oh yeah [02:06] guess i should fix the lint too [02:07] thumper: thanks [02:08] * mwhudson lunches === thumper is now known as thumper-afk [02:10] mwhudson: looks good at a glance [02:14] mwhudson, looks good to me. [02:19] jml: I was thinking - I could probably make my own specs easily enough - any chance you'd prefer do it? I know you mentioned something about talking to people this week. [02:20] MTeck, I'm not quite sure I follow. [02:21] MTeck, I reckon that any specs you'd do would have to be a collaborative effort between you & whoever on the team was looking after that area [02:22] jml: I just meant however you guys would expect it to work [02:22] I'm guessing a lot like SSH keys and another drop down in the bug report [02:25] MTeck, yeah, it'd probably be something like that. [02:25] jml: sorry - I just want to make sure you guys get what you want - but when I think about it more, it's pretty hard to not make it fit in sensibly [02:25] MTeck, heh [02:25] MTeck, nothing to apologize about. :) [02:28] MTeck, I guess it's probably a good idea to send through a rough spec & some notes on the project to the launchpad-dev list [02:28] MTeck, don't spend too much time on it though. [02:28] yup - I'll enjoy this project [02:28] since discussion will definitely follow :) [02:34] jml: any issues with me using the LP Wiki? [02:35] MTeck, none at all. [02:35] unless it's locked :) [02:35] ok - I'll do it all there then - then you can all take a peak [02:55] thumper-afk, lp:~cprov/launchpad/bug-424797-buildd-manager-test-failure ⇒ lp:launchpad/devel is appearing on my personal +activereviews page. [02:55] thumper-afk, under "Approved to land" [02:55] thumper-afk, I'm not sure it should [02:57] jml: so - https://dev.launchpad.net/Bugs/UpstreamForwarding sound like a good url for us to use? [03:15] MTeck, [03:15] yes. [03:18] mwhudson, when everything is settled, could you please review a branch for me? [03:19] jml: request away [03:19] https://code.edge.launchpad.net/~jml/launchpad/ec2test-karmic-bug-424197/+merge/11265 [03:19] yay ajax bugs [03:20] that was easy [03:20] mwhudson, I'm full of easy patches these days :) [03:20] I tried to do 'bzr push bzr+ssh://bazaar.launchpad.net/~mteck-devs/launchpad/UpstreamBugs/' but it didn't like me :( [03:20] mwhudson, it turns out that there's a fairly big number of useful easy things to do. [03:21] MTeck, what was the error? [03:22] mwhudson, thanks. [03:23] http://pastebin.ubuntu.com/266417/ [03:24] MTeck, upgrade your branch to 2a [03:24] MTeck, 'bzr upgrade --2a' should do it. [03:25] (bzr ought to give you a way to push without stacking if the remote host has a defaut stacking branch set, but it doesn't) [03:25] You guys just completely lost me [03:26] stacking and --2a... lost [03:26] MTeck, ahh, I see. [03:27] MTeck, they are both implementation details of bzr [03:27] MTeck, bazaar branches have formats. normally, this doesn't matter, since bzr is normally able to interoperate between different format branches. [03:27] MTeck, one such format is '2a'. It has a feature that makes it incompatible with the default format. [03:28] MTeck, this feature is called "rich root support" [03:28] MTeck, Launchpad branches are all in the 2a format, since it's going to be the new default format. [03:29] MTeck, 'stacking' is a technical term for a particular way that one branch can share data with another branch. [03:30] MTeck, Launchpad has settings that hint to Bazaar that branches pushed to a project should be stacked on the trunk branch of the project. [03:30] MTeck, We do this to save us space and you time on the network. [03:30] MTeck, Normally it's just an implementation detail that you don't need to care about. [03:31] oh [03:31] MTeck, but in this case, you are trying to stack your branch on a branch in an incompatible format. [03:31] * MTeck keeps learning more and more about bzr [03:31] How was a non-2a Launchpad branch obtained? [03:31] MTeck, so Bazaar gives you an error. [03:31] --2a made it all better :) [03:32] MTeck, Bazaar could do better at this, but no one has had the combination of motivation, time and energy. [03:32] MTeck, I told you it would :) [03:33] so, the stacked piece is the part of the project part in ~team/project/branch ? [03:33] not quite. [03:33] am I close? [03:34] if a project has a development focus set, then branches will be stacked by default on that branch. [03:34] oh - over 24hr no sleep now :P [03:34] so, in Launchpad's case, lp:launchpad [03:34] oh! [03:37] jml: thanks for teaching me more yet :) [03:38] I'm curious - how do you have so many people developing LP but keep conflicts down? [03:39] 30 devs over Python 500KLOC isn't very large. [03:39] kloc? [03:40] oh... [03:40] k loc :P [03:45] kLoC ;) [03:46] So - how should I start developing on this piece [03:47] MTeck, tbh, I would look for an easy, unrelated bug to fix and do that first. [03:47] the main weapon in the fight against conflict is short lived branches [03:48] https://bugs.edge.launchpad.net/launchpad-project/+bugs?field.searchtext=&orderby=-importance&search=Search&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&assignee_option=any&field.assignee=&field.bug_reporter=&field.bug_supervisor=&field.bug_commenter=&field.subscriber=&field.omit_dupes.used=&field.omit_dupes=on&field.has_patch.used=&field.has_cve.used=&field.tag=trivial&field.tags_combinator=ANY [03:48] that's a lot [03:48] MTeck, you don't have to do all of them :) [03:48] (although it'd be nice) [03:49] :P [03:49] I wish that would tell me what criteria it used, although it's easy enough to work out. [03:49] mwhudson, I'm not sure whether "short lived" or "single purpose" is more important. [03:50] jml: "small, in some sense" [03:50] * mwhudson displays his mathematical background [03:50] heh [03:50] wgrant, https://bugs.edge.launchpad.net/launchpad-project/+bugs?field.searchtext=&orderby=-importance&search=Search&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&assignee_option=any&field.assignee=&field.bug_reporter=&field.bug_supervisor=&field.bug_commenter=&field.subscriber=&field.omit_dupes.used=&field.omit_dupes=on&field.has_patch.used=&field.has_cve.used=&field.tag=trivial&field.tags_combinator=ANY [03:50] sorry [03:50] wgrant, https://bugs.edge.launchpad.net/malone/+bug/325982 [03:50] Watch out, LINKS INCOMING [03:50] Bug #325982: Search URL is long and hard to paste [03:51] oh the irony [03:52] jml: Yep. [03:54] It's confusing that there's not just one branch that has all the code needed to develop [03:54] It's much better than the alternative (edge not updating for half of the month) [03:56] Isn't bzr supposed to be coming up with sub-branches so you can have one big branch with minor branches below it? [03:56] Oh, you're talking about the deps? [03:57] I'm not sure - it was metcalfe that mentioned it to me [03:58] I'm going off IRC for a while to try to focus a bit better. ping me via skype or xmpp if you need my attention. [03:58] http://bazaar-vcs.org/NestedTreeSupport [03:58] jml: ^ This is what I was thinking of [03:58] and he goes away so I can't annoy him :P [03:58] * mwhudson stabs the aws console through the lungs [03:59] that brings offtopic thoughts to mind (annoying people) === thumper-afk is now known as thumper [05:15] jml: if you reviewed it, it is going to show (now) [05:15] jml: as your personal active reviews page shows the reviews you need to do [05:15] jml: and are doing [05:15] jml: would you expect to see it drop off? [05:17] jtv: do you know anything about this bug? https://bugs.edge.launchpad.net/launchpad-foundations/+bug/47511 [05:17] Bug #47511: pagetests add ghost new lines to textareas [05:17] jtv: carlos reported it, which is why i'm asking you [05:17] mwhudson: ohhh [05:18] that sounds like it's related to ye aulde problem of some browsers adding newlines at the beginning/end of what's in a textarea. [05:21] mwhudson: have you tried running the test he attached? [05:21] jtv: it looks a bit old school, i don't know if it will still run [05:21] i guess i should just tyr [05:21] You _may_ also have to disable whitespace normalization... [05:24] mwhudson: the test looks old-school, but prima facie I don't see anything that shouldn't work any more [05:38] mwhudson: on devpad: [05:38] bzr branch lp:~kfogel/+junk/lpcc trunk [05:38] Permission denied (publickey). [05:38] bzr: ERROR: Connection closed: Unexpected end of message. Please check connecti\ [05:38] vity and permissions, and report a bug if problems persist. [05:38] mwhudson: this is something I must have neglected to set up on devpad, but what? a keyfile somewhere? [05:38] kfogel: agent forwarding? [05:39] mwhudson: er, do I need that to check out a public branch? [05:39] kfogel: over ssh, yes [05:39] kfogel: and you must have run bzr launchpad-login at some stage on devpad [05:39] mwhudson: maybe. but my command is "bzr branch lp:..." [05:39] why would that do ssh, or at least, why wouldn't it fall back to http?? [05:40] How do I solve this build problem: [05:40] Getting distribution for 'zc.buildout==1.5.0dev-gary-r103553'. [05:40] sinzui: Is your download-cache up to date? [05:41] I claims to be for the last 48 hours [05:42] kfogel: it would do ssh if you've previously run bzr launchpad-login (because it then assumes that ssh will work, and ssh is almost certainly faster because of the smart server). [05:42] What's the actual error? [05:42] kfogel: bzr doesn't know that the ssh connection isn't going to work [05:42] Bootstrapping. [05:42] Getting distribution for 'zc.buildout==1.5.0dev-gary-r103553'. [05:42] Error: Couldn't find a distribution for 'zc.buildout==1.5.0dev-gary-r103553'. [05:42] Getting distribution for 'zc.buildout==1.5.0dev-gary-r103553'. [05:42] make: *** [bin/buildout] Error 1 [05:42] make: Leaving directory `/home/curtis/Work/launchpad/rocketfuel' [05:42] kfogel: it doesn't fallback because bzr doesn't really make it easy for that to work :( [05:42] kfogel: it could catch and retry i guess, but the logic is all a bit upside down for that to be easy [05:42] mwhudson: it certainly knows that it fails :-). But anyway, I'm not sure what the fix is. I just need to check out some bzr branches. [05:42] kfogel: log out, ssh -A devpad [05:42] mwhudson: yeah, catch and retry is what I was expecting I guess. [05:42] spiv: ^^ [05:42] mwhudson: thanks [05:43] spiv: too bad about the code arrangement :-( [05:43] download-cache/dist is empty again. bzr says nothing is wrong [05:43] sinzui: bzr up download-cache fixed that for me [05:43] sinzui, kfogel: what the heck are you guys doing onine [05:43] thumper, yes, I'd expect it to drop off, since I can't do anything about it, and I don't really have responsibility for it. [05:43] download-cache [05:43] Tree is up to date at revision 9354. [05:43] bzr st [05:43] sinzui: that's wrong [05:43] thumper, otoh, I guess if it were a patch from someone who can't land, then it should really appear there [05:43] mwhudson, spiv: the "ssh -A" worked, thanks. [05:43] mwhudson: I just wanted to get a cron job going before I went to bed. [05:43] thumper, which is starting to sound maybe a little too intelligent [05:44] there's no way download-cache is at rev 9354 [05:44] jml: :) [05:44] thumper, what do you think? [05:44] kfogel, hi [05:44] jml: hey! [05:44] kfogel: use an http url? [05:44] mwhudson: A very good point. [05:44] MTeck, yeah, bzr should have nested trees [05:44] mwhudson: mmm, I could have constructed that, yeah [05:44] MTeck, atm, Launchpad uses three ways to manage dependencies [05:44] mwhudson: but I wanted my strawberries and cream and "lp:" goodness [05:45] jml: https://dev.launchpad.net/Contributions [05:45] kfogel, yeah, I saw :) [05:45] jml: (as per our discussion) [05:45] jml: ah good [05:45] kfogel, oh, my privmsgs got silently lost [05:45] :( [05:45] That's a pretty depressing page. [05:45] wgrant: it is a bit lopsided :-) [05:45] kfogel, I love the new ToC [05:45] jml: yay freenode [05:45] wgrant, depressing for whom exactly? [05:46] jml: cool. we under-use the "<>" syntax in moin I think. [05:46] jml: Everyone. There are practically no contributions. [05:46] wgrant, it's way more than I was anticipating. [05:46] wgrant: a month or so after the first release of a difficult-to-build hosted service? I wish for more contributions too, but this isn't bad. [05:47] wgrant: remember maxb is in the pipeline now [05:47] kfogel: Mm, I guess. [05:47] That's true. [05:47] wgrant, but I'm very keen to see more contributors. [05:47] wgrant, got any ideas for how we could get more? [05:47] jml: Not restrict everything to Ubuntu. [05:47] Debian would be easy, but PPAs don't do Debian. [05:48] wgrant: +1 +1 +1 [05:48] I completely agree. [05:48] a bug! [05:48] Debian, and then other distros too. [05:48] wgrant: our dependency setup is our Achilles' heel. [05:49] jml: I count four types of deps. [05:49] - Debian packages [05:49] - sourcecode [05:49] - bzr checkouts [05:49] - eggs [05:49] Hm. Wait. Maybe I split something there. [05:49] They confuse me, anyway. [05:49] wgrant, 'bzr checkouts'? [05:49] wgrant, sourcecode, debs & eggs -- that's it, I think. [05:50] jml: Mm, right, the bzr checkouts are sourcecode. [05:50] wgrant, it's confusing [05:50] and I don't see us dropping to one kind any time soon [05:57] mwhudson: still working on patching up that test [05:57] Has anybody tried to run LP on Debian or other derivatives yet? [05:58] wgrant: I thought someone had... [05:58] * kfogel looks [05:58] jtv: ok, don't sweat it too much [05:58] kfogel: I know somebody was considering trying it some weeks ago. [05:59] wgrant: oh, no, no record of success yet [05:59] But I don't recall hearing any results. [05:59] mwhudson: the holdup is setupBrowser not being defined. [05:59] Ahhh, stupid. Got the trouble [06:00] fixed [06:01] wgrant: I see you've managed to get quite a few branches landed, well done [06:01] ajmitch, your turn :) [06:02] ajmitch: I've about another five sitting around, too. [06:02] jml: Once I replace my dying laptop, I'll be able to look at it again [06:03] kfogel: How do you determine the author? Looking at the MP, or the latest revision, or something even more inventive? [06:04] Ah, there is code. [06:04] * wgrant looks. [06:10] jtv: does the test pass? [06:11] mwhudson: still patching it up... having to set up layers for every run is the big bottleneck [06:12] wgrant: one thing that hurts is that I can't (yet) determine the person who made the landing request. That's due to everything looking like ~launchpad-pqm; we should find someplace for PQM to hang that information, and have the script look there. [06:12] kfogel: Right. [06:12] (and we should stop sticking metadata in revision messages!) [06:12] jml: okay, cron job on devpad updates the Contributions page every 10 min now. [06:12] kfogel, sweet. [06:13] one day, it'll be just as easy to update it in response to events [06:13] wgrant: well, yes, ideally. bzr has the right kind of properties to handle this already, I think, no? [06:13] kfogel: It does. [06:14] jml: "events" like (say) maxb updating deps, or did you mean something else? [06:14] And the emails that Launchpad sends out already show the [r=foo][ui=bar] in another way. [06:14] kfogel: you expect new contributions every 10 minutes? [06:14] wgrant: hmmm. the script could parse that too... but I kind of think it's better that it show what the msg actually looks like [06:14] kfogel, I mean, update in response to an actual commit, rather than polling [06:14] ajmitch: no, but I never know *which* 10 minutes one will come in. [06:14] jml: ah, yes, that would be ideal! [06:15] doing that now would mean listening for email, which kind of sucks. [06:15] So, why is all that metadata in the revision message? [06:15] jml: yah, I'd rather Not Go There. [06:15] wgrant, pqm checks it. [06:15] wgrant: because we're unimaginative in our use of bzr properties? [06:15] wgrant, it forces submissions to match a regex [06:15] jml: I know. [06:16] jml: i mean why is it *in the revision message*. [06:16] And not in properties. [06:16] wgrant, limitations in PQM. [06:16] * wgrant headdesks. [06:16] sounds like something just waiting to be improved [06:16] wgrant, I'm not trying to be difficult, sorry. [06:17] wgrant: nice verb, I think I'm going to have occasion to use that in the future. [06:17] jml: Oh, I know. [06:22] jml: should https://code.edge.launchpad.net/~jml/lp-dev-utils/bzr-plugin/+merge/7427 be a launchpad branch now? [06:23] mwhudson, I'm not sure what to do with that now. [06:24] mwhudson, utilities/ is a pretty crappy place to keep a bzr plugin. [06:25] jml: you could say it's a pretty crappy place to keep any software [06:25] jml: I'm not sure the fact of being a bzr plugin is any more relevant than, say, being written in sh instead of py. [06:25] mwhudson: I don't think I can patch up that test and be sure it tests what it was meant to. :( [06:26] jtv: oh well [06:26] jml: bzr is just one of many tools the script uses to do its job. I don't think that affects its appropriateness for being in the utilities/ dir. [06:26] mwhudson, kfogel: you can run a script from utilities without any installation step or env variable setting, you can't do that for a bzr plugin [06:27] jml: is that true of all the scripts in there? I'd never realized it was a qualification for being in utilities. It's about to be violated again when I move lpcc.py (the thing that updates the Contributions page) over to utilities/, since that requires editmoin.py which we currently don't ship in utilities (nor should we, probably). [06:28] kfogel, well, it's not, I guess. [06:28] kfogel, but it's a nice property, I think. [06:29] jml: "meh", I guess. If it is a req, we should document it, but I don't feel strongly it is a req. [06:29] ok. [06:29] jml: ah, maybe a more positive way to say it: [06:29] jml: "something can be in utilities if it's useful for developing or running launchpad" [06:30] er, "and has no other home" :-) [06:30] heh [06:30] well, I can try to redeem the bzr plugin branch. [06:30] but it's pretty low priority for me (it wouldn't have been six weeks ago) [06:30] bedtime here. You can run wild, I won't be around to argue. Go nuts :-). [06:31] kfogel, heh [06:32] mwhudson, https://code.edge.launchpad.net/~jml/lp-dev-utils/moved-dev-tools/+merge/11237 -- want to approve that? [06:33] jml: ok [06:34] * jml is experiencing doc writing fail [07:00] spm: what's up with the buildbot? [07:02] thumper: I just bounced it - is it ded? [07:02] belh. yes. [07:02] spm: I'm gettign 503 [07:02] spm: had it succeeded? [07:02] spm: why was it bounced? [07:02] thumper: I thought it had, but clearly not; should be good now; [07:03] mwh was doing some testing [07:03] dur. try again. mwh was doing some buildbot changes and testing thereof. [07:03] it's up now [07:03] thumper: it succeede [07:03] d [07:03] need to kick db_lp [07:03] \o/ [07:04] well, there should be a stable -> db-devel merge soon [07:04] but yes, probably need to kick db_lp anyway [07:04] * thumper forced db_lp [07:04] * thumper wanders of for dinner time activities [07:04] off [07:04] * mwhudson eods [07:04] d'uh === thumper is now known as thumper-afk [08:30] good morning [08:38] morning all [09:17] Good Monday :) [09:18] eyup mrevell === Guest54570 is now known as danilos [09:59] * wgrant grumbles a bit at the lack of Debian support in PPAs. === thumper-afk is now known as thumper [10:44] bigjools: fmt:link dunt work for a distroseries. Is there any reason I shouldn't add one? [10:44] mrevell: Morning :) [10:44] allenap: weird, it should [10:44] jtv: I guess IRC woes continue [10:45] jtv: btw, what's the status on translations-person-3.0-mechanical branch? [10:45] hey there allenap [10:45] allenap: how are you doing it? [10:45] bigjools: series/fmt:link [10:46] danilos: that one got stuck in EC2 trouble before I left, so I'll be submitting. (I reverted the changes to the main page, as you asked). [10:46] allenap: ? [10:46] danilos: I did land the 3 bugfixes from Vientiane [10:47] * jtv checks... it's a bit of a "cold boot" [10:47] jtv: Vientiane? [10:47] The capital of Laos. [10:47] bigjools: Yeah, basically that. [10:48] bigjools: I get: NotImplementedError: No link implementation for , IPathAdapter implementation for [10:51] jtv: ok, cool [10:52] bigjools: Bizarrely, fmt:url works fine. [10:52] allenap: yeah it uses canonical_url IIRC [10:52] bigjools: Ah, okay. [10:52] stick wid dat unless you want more work :) [10:53] bigjools: Okay, will do :) [10:53] although distroseries is registry now, Curtis might have something to say [10:56] bigjools: I'll send him a quick email. === henninge_ is now known as henninge [11:23] wgrant: around? [11:23] bigjools: I am. [11:23] do you know the use cases for the related-software page? [11:23] eg https://edge.launchpad.net/~wgrant/+related-software [11:24] I remember fixing bugs on it but I've never seen a canonical set of use cases [11:24] bigjools: There are no really important use-cases for that page in particular (apart from general interest), but its children are important. [11:25] okay [11:25] so in theory that page could be junked? [11:25] In theory, but it is useful. [11:25] ok :) [11:25] it's a grey area in terms of application ownership [11:26] Indeed. [11:26] Although I'd say it was Soyuz. [11:26] it's my last set of pages to convert to 3.0 [11:27] and as curtis so eloquently put it: nightmare [11:29] Why? Not just mechanical changes? [11:29] the nav menu needs to be dismantled [11:29] Oh, right. [11:29] Forgot that bit. [11:29] and it's a two-tier one [11:29] and it's a mix of registry and soyuz templates :/ [11:30] bigjools: Just link the section headings? [11:30] Or add a "View all maintained packages" link at the right like new main-content portlets have? [11:31] yeah - I could convert to an action menu [11:32] Don't those end up down the bottom, so are impossible to find? [11:32] top right [11:33] related-pages appear at the bottom [11:33] Hm. I'm not sure I've seen non-indices with action menus. [11:33] well, in fact they appear where I put them :) [11:34] hmmm yeah that would fall foul of the guidelines [11:34] I've seen related pages links under action menus though, so if there's no action menu it can appear at the top right [11:35] It seems odd to have that as the only thing on the right -- it's a bit of a waste. [11:35] indeed [11:35] can you see why it was labelled nightmare now? [11:35] Yes. [11:36] My current favourite is the convention of having "View all " links in the top right. But that might not work for a page like that where the sections are the primary content. [11:37] Top right of the relevant portlet, that is. [12:08] bigjools: Any great ideas? [12:08] wgrant: my only idea is not great, and that's to have a side bar [12:09] bigjools: :( [12:09] And both the 3.0 UI gods are absent? [12:09] yep [12:14] That seems like suboptimal timing. [12:16] only 1 day for curtis [12:16] and knowing him I bet he's around anyway :) [12:17] Ah, right. [12:49] Well, that was disappointingly uneventful (getting LP running on Lenny). === ursula_ is now known as Ursinha === mrevell is now known as mrevell-lunch === mrevell-lunch is now known as mrevell [15:58] Hello there, I added this merge proposal earlier today but no email was sent out: https://code.edge.launchpad.net/~al-maisan/ubuntu/karmic/pristine-tar/gendelta-fix/+merge/11303 [15:58] Is that normal? [16:00] abentley: Can you please take a look ^^ ? [16:01] al-maisan: I'd be happy to look tomorrow, but I'm off today. [16:01] abentley: sorry .. I did not know. [16:01] al-maisan: no problem. [17:19] sinzui: are you lurking? [17:20] I am [17:20] I knew I could count on you [17:20] sinzui: being a nice guy, I thought I'd start on the +related-software 3.0 change [17:20] this is in no way me feeling guilty for moving two of my templates into registry today [17:20] bigjools: That is very generous. [17:21] Which templates? [17:21] productseries-packaging and ... /me looks [17:22] sourcepackage-packaging [17:22] Yes, I agree they belong [17:22] * sinzui was wondering why there were so few sp templates to convert [17:22] sinzui: my question is, I thought I'd use related-pages to put the mess of menus in a sidebar portlet [17:23] I started, but the context menu is for IPerson and that's not what I want, how do I use a different one? [17:23] That wont pass beuno's inspection because the menu is not a top-level collection [17:23] bigjools: I had a similar problem... [17:23] argh [17:23] ok [17:23] * sinzui tries to remember what he did. [17:23] how about an action menu? [17:24] bigjools: I remember adding a
    of links below the narrative on a page [17:24] bigjools: It is the same way links are formatted on the product page... [17:25] and then I realised that I had reinterpreted the black bar as a white bar [17:27] that's fabulously low-tech [17:28] bigjools: I hard coded it too, no nav menu [17:28] bigjools: but you can keep the menu since I think it already has what you expect to see [17:28] * sinzui chooses the fastest way to get the page landed [17:28] indeed, I just need to repeat the links in the tal then [17:29] ok, I'll attack this tomorrow [17:29] bigjools: I will welcome the distraction from CHR [17:29] there's no description on any of those pages though [17:29] so the links will appear right at the top [17:30] can tal iterate over those menus so I don't have to hard-code the link names? [17:34] bigjools: maybe the lack if description is why I do not understand what the pages are for or who uses them. I suspect teams have different uses case than users (seeing the bug reports by persia) [17:34] yeah - one of the uses I am aware of is reviewing someone's contributions when they want to become a MOTU [18:32] night all [20:45] sinzui: still around? [20:46] yes [20:46] sinzui: check this out lp:~julian-edwards/launchpad/related-software-30 [20:46] browse to https://launchpad.dev/~mark/+related-software [20:58] bigjools: this looks good [20:59] sinzui: better than I'd thought it would [20:59] what's with the weird breadcrumbs lately? [20:59] I ponder the uses of 'See also' and 'Full listing' Maybe the page doesn't need them [21:00] yes, I saw the breadcrumbs on Friday [21:00] bigjools: happily they are not your problem [21:01] sinzui: right, the extra text was an afterthought [21:01] Full listings is helpful. [21:02] I am just surprised by the See also. I understand why you need to change the label [21:03] bigjools: I think the

    and page title should either both include 'Summary', or both not use it [21:03] yeah, we could do with barry's heading branch landing ;) [21:04] bigjools: Actually, I am surprised that the heading and title are not the same [21:04] sinzui: coz it's a hack job [21:05] bigjools: the constant "Realated project" vs. "Projects related" looks like two different people working on the page. [21:06] sinzui: yeah I didn't attempt to do much with the headings/titles, I just wanted to visualise the new layout [21:06] bigjools: I do not have any suggest about how to fix this [21:07] well won't barry's branch reverse the title anyway? [21:07] the layout is a nice improvement. The links are easy to see now. This is a nice imrovement for users [21:09] bigjools: I do not this it will do that in the first round. I am not sure how that can be done since the page title would have to be generated from the breadcrumbs. The crumbs are not good english [21:10] okay, I'll knock up a page_title to sort it out [21:12] hmm [21:13] has gary been around today? [21:34] sinzui: I made some changes, check it out [21:39] bigjools: this is very nice [21:40] sinzui: the nightmare has ended :) [21:40] bigjools: you can have my ui* r=me [21:41] sinzui: rock n roll [22:06] oh, labour day, duh [22:15] morning [22:15] mwhudson: yeah, just you and me again for our team I think [22:15] thumper: abentley should be here? [22:15] or is labour day the same day as labor day? [22:15] I think it is labour day in canada too [22:16] oh yes [22:16] it's thanksgiving that's a week apart? [22:17] thumper: skype then? [22:18] yep [22:19] hm, is this the usual confusion about who's online [23:16] * maxb wonders why the tarballs at http://people.canonical.com/~herb/ are ~230MB, when a freshly `bzr pack`-ed repository is only 140MB [23:18] maxb: we had fragmentation bugs in the 2a format, in bzr. lp was suffering those, and its likely that herb tarred up the public repo, which would be fragmented [23:31] maxb, lifeless: Those were created on release night, from a fresh checkout. [23:31] But bzr sucked at that point. [23:31] wgrant: see under fragmentation [23:31] wgrant: we also didn't recompress when receiving fragmented streams [23:32] all of which combine. These things are fixed in 2.0rc2 [23:32] lifeless: Right, but it wasn't the public copy's fragmentation. [23:32] Yep. [23:32] Nightlies work great now. [23:32] wgrant: a fresh checkout made on release night would have inherited the public copies fragmentation [23:32] wgrant: because lp was set hot, and hot things go to the public copy [23:33] lifeless: Ah, right. [23:33] wgrant: [and further to that, the master is on pqm; both lp copies are 'public' in that sense] [23:33] spm: ping [23:33] lifeless: heyo [23:34] spm: this all reminds me; care to do a bzr pack in the codehosting copies of stable, devel, etc [23:34] +inf [23:34] df -h .bzr/repository/packs before and after [23:34] But 1.17 doesn't do a very good job. [23:34] of launchpad? not without flacoste being ok with doing so [23:34] And isn't that what's on codehosting? [23:34] if its < 1MB there [23:34] 's no need [23:34] wgrant: it will pack just fune [23:34] *fine* [23:35] lifeless: It didn't get devel down below 200MB for me. [23:35] wgrant: with the C extensions? [23:35] spm: well, gather the data anyhow. [23:35] lifeless: I think so, but it was a while ago. [23:35] spm: I don't see that this is a flacoste thing; its operational mgmt for a hosted branch :) [23:36] spm: if anyone its a thumper/mwhudson thing [23:36] eh? [23:36] thumper: theres a good chance that the copies of lp on codehosting are badly fragmented [23:36] and [23:36] thumper: due to about 4 interacting bugs in bzr [23:36] They are very, very badly fragmented. [23:36] Nearly 100% larger. [23:37] it will improve fetch performance, decrease server memory use, and disk space, if they get 'bzr pack' run on them. [23:37] and network overhead on fetching too [23:37] lifeless: however bzr pack takes ages [23:37] thumper: it doesn't lock the repository [23:38] lifeless: and IIRC you told me you should never need to run bzr pack [23:38] lifeless: so, why now? [23:38] thumper: you shouldn't; OTOH I also said 'I wouldn't upgrade to 2a until its fully finished' [23:38] :) [23:38] lifeless: will the autopacks fix the issue? [23:38] thumper: in 5 years or so [23:39] auto packs only touch recent data most of the time [23:39] thumper: how many revisions does your lp repo have in it ? [bzr info -v] [23:40] 67122 [23:40] thumper: as to why now, I just got reminded of it by maxb above; we'll want to do this once, to all 2a repos on codehosting, when codehosting deploys 2.0 [23:40] ok autopack will fix this for you in another 32878 commits [23:41] lifeless: so why is it badly packed now? [23:41] because of bzr bugs in 1.16,1.17 and 1.18 with fetching of 2a [23:42] lifeless: looking at the packs there, they look as large as expected [23:42] lifeless: to me it looks like natural growth [23:42] lifeless: why do you think it is different? [23:42] lifeless: I pushed completely packed repos there the first time [23:43] looking at http://bazaar.launchpad.net/~launchpad-pqm/launchpad/devel/.bzr/repository/packs/?C=S;O=D ? [23:43] yes, I was [23:43] * lifeless tests [23:44] for comparison purposes, a freshly packed shared repo of all 4 primary branches packs down to one 109MB pack [23:44] thumper: ^ [23:45] thumper: in a fragmented repo the ratios of packs stay the same; the packs are just bigger. Its their internal structure that is odd [23:45] too many compression groups [23:45] lifeless: so internal changes to bzr in recent revisions have fixed this? [23:46] 2.0rc2 will both no longer cause fragementation when fetching, and partially compensate for existing fragmentation on the client [23:46] doing a full pack now won't stop some further fragmentation on lp until lp rolls out 2.0. *but* packed data won't get fragmented: its only *new data* that fragments. [23:47] lifeless: so no point really until we are on a later version of bzr [23:47] lifeless: because we only have 1.17 on LP now [23:47] lifeless: I'm in the progress of landing 1.18 final [23:48] lifeless: and I would add in 2.0rc2 if I could find the tar.gz on LP [23:48] but I can't [23:48] lifeless: but this won't be rolled out until 3.0 [23:48] thumper: there is very much a point now [23:49] lifeless: we don't have the fixed bzr on the machines to do the packs [23:49] thumper: 99% of the data that will be in the repository when 3.0 is rolled out is already in it now; you can shrink the repo by ~ 60% according to maxb's stats [23:49] thumper: you don't need a fixed bzr [23:49] we haven't changed pack [23:50] I wouldn't be suggesting this if I didn't think it would help you! [23:50] lifeless: why then is the repo so large when I packed it before pushing? [23:50] lifeless: I had a single pack file when we created the repo [23:50] because pushing was fragmenting! [23:50] So, basically, a repack now saves bandwidth for LP and downloaders between now and 3.0 ? [23:51] hmm.. [23:51] thumper: and you pushed to the private copy, lp then copied it again to the public one fragmenting it further [23:51] (Somewhat meta question) Why does LP keep two copies anyway? [23:52] thumper: at *every step* dictionary sort order was changing what bzr considered optimal @ merge points [23:52] maxb: histerical raisons [23:52] thumper: each time this happens a gc group splits; gc groups contain full texts, so that text doubles its storage size [23:52] ahhh.... [23:52] maxb: theory at the time was scaling and security [23:53] lifeless: so to be effective we'd have to pack both copies? [23:53] thumper: users pull from the public copy only, even on bzr+ssh [23:53] lifeless: how does pack work without locking? [23:53] so most important one is the public copy [23:53] lifeless: no they don't [23:53] lifeless: bzr+ssh pulls from the hosted copy [23:53] thumper: just a few days ago we had this confirmed [23:53] if it is a hosted branch [23:53] thumper: Only if you have write access, right? [23:54] thumper: and I'm sorry to say, you're wrong :) [23:54] wgrant: it wraps it in a readonly transport [23:54] thumper: or jml/mwhudson lied to us :) [23:54] lifeless: confirmed by whom? [23:54] * thumper looks at the code [23:55] thumper: well you and i will read from the hosted copy, cause we're bzr experts [23:55] everyone else reads from the mirrored area though [23:55] mwhudson: am I a bzr expert ? [23:55] hopefully not [23:55] mwhudson: I thought that all hosted branches were read from the hosted area [23:55] lifeless: you're an admin aren't you? [23:55] mwhudson: not anymore [23:55] * jml dislikes the group, and wishes it as small as possible [23:55] thumper: how to put this tactfully? [23:56] thumper: i think you thought wrong [23:56] :) [23:56] mwhudson: where is the code? [23:57] thumper: it seems to be a bit convoluted [23:57] >>> t = bzrlib.transport.get_transport('bzr+ssh://bazaar.launchpad.net/~launchpad-pqm/launchpad/devel/.bzr/repository/packs') [23:57] >>> t.list_dir('.') [23:58] thumper: but it's in lp.codehosting.vfs.branchfs [23:58] if writable: [23:58] dispatch = self._hosted_dispatch [23:58] else: [23:58] dispatch = self._mirrored_dispatch [23:58] TransportDispatch._makeBranchTransport [23:58] 1d0252d21c3632af79515b5e8c497c15.pack [23:58] thats the same large pack as on the public side [23:58] spot check of a few others matches [23:59] now that thats out of the way [23:59] thumper: bzr repositories have fine grained locking, they were designed to be as concurrent as possible.