[00:13] * thumper looks [00:16] mwhudson: first try no, updating source code and download cache now [00:21] mwhudson: can you look at https://dev.launchpad.net/BuildBranchToArchive/MultipleSeriesBuilds and determine if we know enough to change the model? [00:23] thumper: i think we know basically enough [00:23] ok [00:24] thumper: i guess it reopens the question of "what namespace do recipes live in" [00:24] mwhudson: can you plan a branch count (1 or more as necessary) to change the model? [00:24] mwhudson: I think we are going to have recipes at ~user/distro/+source/packagename/+recipe/name [00:24] thumper: i'd have thought one would be enough [00:24] ok [00:25] thumper: ok that makes sense [00:28] mwhudson: the interesting bit is how to make ~user/distro and ~user/distro/+source/packagename (and possibly ~user/distro/distroseries and ~user/distro/distroseries/packagename) useful objects [00:28] mwhudson: consider ~user/project [00:30] thumper: 'useful objects' ? [00:30] i can see useful pages [00:30] mwhudson: at code.lp.net/~thumper/distribution ? [00:31] mwhudson: PersonDistro c.f. PersonProject [00:31] mwhudson: PersonDistroSeries [00:31] et al [00:31] right [00:31] maybe i'm unimaginative, but that doesn't seem very interesting [00:31] what useful pages can you see? [00:31] it's just work isn't it? [00:31] yes [00:31] thumper: i think we're saying the same thing in different ways, ignore my objection [00:32] ok [00:32] jml suggested there may be some multi-object adapter thing that we could use instead of having explicit objects [00:32] so (Person, Product) instead of PersonProduct [00:32] oh right [00:33] I'm not so sure there is [00:33] or even if there is that it is a better solution [00:33] simple is better than complex [00:33] well [00:33] um [00:33] although which is simple is a matter of opinion [00:33] i think you have to have something like PersonProduct [00:33] that you can hang a view off [00:34] mwhudson: btw, make worked with updated download-cache [00:34] it doesn't have to be anything more than just a container object though [00:34] thumper: :( [00:34] well i guess yay that launchpad isn't broken for _everyone_ [00:34] what are your symptoms? [00:35] mwh@grond:trunk$ make [00:35] utilities/shhh.py PYTHONPATH= ./bin/buildout \ [00:35] configuration:instance_name=development -c buildout.cfg [00:35] While: [00:35] Installing. [00:35] Getting section i18n. [00:35] Initializing section i18n. [00:35] Installing recipe z3c.recipe.i18n. [00:35] Error: There is a version conflict. [00:35] We already have: zope.interface 3.4.0 [00:36] hmm.. [00:36] my buildout bit isn't running [00:36] it seems to be finding the system zope.interface [00:37] and now I'm wondering what'll happen if I remove my eggs [00:37] thumper: dpkg -l python-zopeinterface [00:37] ? [00:37] un [00:37] ! [00:37] however in a python shell I can import zope.interface [00:38] !! [00:38] lots of things seem to depend on it here [00:38] ii python-zope.interface 3.5.2-1 [00:38] hmmm [00:39] HMMM [00:39] well [00:39] apt-get install python-zope.interface [00:39] which replaces the package [00:39] and now it works [00:39] W [00:39] T [00:39] F [00:41] anyway [00:43] * thumper shrugs [00:43] weird [00:45] well about four hours later than it should have been, let's test that git import out... [00:52] mwhudson: :) [00:53] mwhudson: I've set my preferred email back to the @c.c one [00:53] mwhudson: we'll see if I get an email this time [00:53] mwhudson: perhaps we should add an --email-from tag too [00:53] mwhudson: that way it might work for the community people too [00:54] thumper: It works fine if I run it myself, though. [00:54] Probably because I have no SMTP server configured. [00:54] wgrant: could be [00:54] And my mail server is not sufficiently SPF-policing. [00:55] wgrant: if the canonical one is set to use the canonical smtp server [00:55] wgrant: it only allows emails from a canonical.com address [00:55] wgrant: and drops others [00:55] thumper: It doesn't even allow emails to a canonical.com address from a non-Canonical one? [00:56] wgrant: it may not be the general one... not sure [00:56] wgrant: maybe? [00:57] Yay email. [00:59] ec2 test should just drop a letter in the mail [00:59] i'm sure there's a printer somewhere in amazon's data centre? [01:00] :) [01:10] mwhudson: an unproductive afternoon just got worse with visitors [01:10] mwhudson: I'm going to get a real coffee [01:10] thumper: ok [01:10] thumper: i'm going to be finishing a little early today, btw [01:11] mwhudson: ok [01:11] like 4? [01:11] thumper: about 4:30 [01:11] * thumper nods [01:11] ok, sounds fine [01:12] cool [01:20] ec2 demo seems pretty broken by the openid changes [01:25] mwhudson: What goes wrong? [01:25] mwhudson: Does it hardcode hostnames like rocketfuel-setup? [01:26] wgrant: i got fed up and didn't really dig [01:26] but pages that require you to log in oops [01:26] Yeah, it's not adding testopenid.dev to /etc/hosts. [01:31] oh right [01:31] hm it is when creating a new image [01:32] maybe a new one is needed === bjf is now known as bjf-afk [01:35] Does the image creation use rf-setup? [01:35] wgrant: no [01:35] rf-setup does rather more than is needed i think [01:36] Ah, I didn't see the devscripts change in the diff. [01:36] Ah, because the diff is 5000 lines. [02:15] thumper, wrt "simple is better than complex", "simple" is often defined as "fewer interacting entities", in which case a multi-adapter would be simpler [02:15] * thumper pokes jml in the eye [02:15] * thumper looks around to see who saw that [02:16] thumper, entia non sunt multiplicanda praeter necessitatem [02:16] jml: when are you back at work? [02:16] thumper, I was back all today. [02:16] ah, home again? [02:17] thumper, no, in Massachusetts [02:17] jml: em or um? [02:17] thumper, working w/ cody-somerville & kiko, talking about OEM requirements and things [02:17] lifeless, em. [02:17] jml: ok [02:18] s/OEM/NewCore (the new shiny) ;) [02:18] err [02:18] 'thingy' [02:18] hi cody-somerville [02:18] cody-somerville: still working? [02:18] getting kinda late isn't it? [02:19] It is [02:19] 21:19 [02:19] Just got back from dinner. [02:19] and you couldn't wait to see what happened while you were out? [02:19] thumper, well, I couldn't [02:20] thumper, and also there's nothing like taking a break from my job and doing a spot of document writing and process improvement for an open source project :P [02:20] * cody-somerville is an addict to work. :( [02:21] jml: I've got my own pet project now [02:21] thumper, does it involve web and dvcs? [02:23] jml: yeah [02:23] jml: looking at mako for templating [02:23] jml: looks more intuitive to me than genshi [02:23] jml: still using twisted.web [02:23] thumper, what does django use normally? [02:24] kid I thought [02:24] thumper, have you looked at nevow? [02:24] or maybe that was something else [02:24] jml: nope [02:24] mako is super fast [02:24] thumper, I'm not suggesting that you _use_ it, mind, just that it's worth a look [02:24] and what the python website uses [02:24] jml: understood [02:24] jml: there are a gazillion different templating systems out there [02:24] I've been playing around with python 3.1 a bit too [02:25] thumper, nevow is one that was built to work with twisted.web [02:25] Django uses its own thing. [02:25] I like genshi more than mako, I think. [02:25] but there's not much in it. [02:25] wgrant: why? [02:26] I'm not strongly stuck on any one [02:26] I'm not sure. [02:26] I just want something that can easily apply a common skin to pages [02:26] I'm not wanting to invest a lot of time into it [02:26] (just yet) [02:26] jml: do you know of a python library that renders moin syntax? [02:27] thumper: like, oh, moinmoin ? [02:27] lifeless: I heard that it wasn't simple to extract the rendering code from the entire wiki project [02:27] thumper, there's a name on the tip of my tongue (other than moinmoin) [02:27] lifeless: but I haven't looked [02:28] thumper: I'd look; theres been a lot of work done on moin [02:28] thumper, also, I humbly suggest that you should use mediawiki formatting [02:28] jml: I was going to have a choice [02:28] thumper, good good. [02:28] jml: what is the name of the mediawiki format? [02:28] is there another name? [02:28] thumper, no, I don't think so [02:29] thumper, there's a wiki interchange library thing that I'm struggling to remember the name of [02:29] jml: I think I did a code import for that ... [02:31] jml: creole? [02:31] thumper, yeah, that's it. [02:31] lp:creoleparser [02:31] thumper, phew, I'll be able to sleep now. [02:46] thumper: is https://dev.launchpad.net/Code/PostThreeDotO much relevant these days? [02:47] mwhudson: I don't think so [02:47] mwhudson: we know about it all [02:47] mwhudson: and they are tracked elsewhere [02:47] thumper: right [02:47] mwhudson: so kill it [02:47] thumper: delete it? replace with a link to somewhere else? [02:47] umm... [02:47] not sure where to link it to [02:48] is there a general four dot oh page somewhere [02:48] or perhaps link to the dev wiki strategy pages? [02:49] https://dev.launchpad.net/VersionFourDotO/Themes ? [02:50] yeah, seems reasonable [02:56] mwhudson: I'm off to go shop for BBQ [02:56] mwhudson: see you monday [02:56] thumper: see you monday, have a good weekend === mup_ is now known as mup [08:11] good morning === thekorn_ is now known as thekorn [09:24] mwhudson, hi [09:27] stub: ping [09:33] when i run "make build", i get "Error: There is a version conflict. [09:33] We already have: zope.interface 3.4.0". Any suggestions how to fix this? [09:33] mwhudson had that this morning. [09:35] wgrant: tahnks for the hint! [09:35] adeuring: It looks like he might have fixed it by install the python-zopeinterface package. [09:36] Er, python-zope.interface [09:40] wgrant: thanks! that helped indeed [09:41] Urgh. It shouldn't. [09:42] Did the +login page just stop working in devel? [09:42] jtv: It's OOPSing? [09:42] wgrant: yup, for me it is [09:42] jtv: Add testopenid.dev to /etc/hosts. [09:42] wgrant: thanks [09:42] An email should really have been sent about that. [09:44] wgrant: thanks, that did the trick [09:44] Great. [09:56] jelmer: pong [09:57] stub: Any chance you can review this patch that changes the db: https://code.edge.launchpad.net/~jelmer/launchpad/bug471148/+merge/20142 ? [09:57] Is it really week 3? I've been out of touch for a while :) [09:58] Yes, yes it is. (Looked at the milestone.) [10:02] jelmer: What architectures does an archive get built for if there are no entries in ArchiveArch ? [10:02] stub: Just the unrestricted architectures [10:03] So we add this flag to avoid needing 8 entries in ArchiveArch for every archive. I see. [10:04] stub: yep [10:07] We are assuming we won't need further granularity like 'build hppa in lucid only' [10:07] ? [10:10] stub: that's already handled through distroarchseries [10:11] stub: this is not a requirement at present; if needed we could add a DistroSeries FK to ArchiveArch [10:12] to put the restricted processor family override into a distro series context [10:12] How does this work with require_virtualized? [10:12] wgrant: the latter is orthogonal to this [10:14] al-maisan: no FK needed, distroarchseries man :) [10:14] je [10:14] sorry [10:15] bigjools: I guess we're fine for the moment [10:15] al-maisan: yep [10:16] Ah, so this is for restricting the architectures of non-virtual PPAs? [10:16] stub: thanks for the review [10:16] np [10:16] I don't quite see a use case where we'd want to have a PPA with builds for armel in say karmic but not in lucid [10:16] wgrant: it's for restricting for any archive [10:17] virtuality is orthogonal [10:21] i can't build after branching from db-devel because of "Couldn't find a distribution for 'lazr.restful==0.9.21'". anyone knows what's going on? [10:24] ah, nm, rocketfuel-got it [10:30] al-maisan: that's a very valid use case actually [10:30] for example, lpia is not in lucid [10:31] the lpia case is not really so pertinent since lucid has no lpia DistroArchSeries anyway [10:32] bdmurray: your branch has landed. Now you need to Q/A it. I'm not sure what the process for keeping track of that is in this case; in Translations we've been using an experimental process. [10:33] bdmurray: it needs to be marked as Q/Aed in order to be included in the release. [10:41] Argh, all the buildds are gone again. [10:41] gar, the cherry-pick is still waiting to land :/ [10:43] wgrant: the i386 ppa builders are all full? [10:43] And amd64 :( [10:44] wgrant: ah, I thought you meant that the buildd manager had died again... *phew* :) === jtv is now known as jtv-afk [10:51] jelmer: incremental imports seem to fail with [10:51] AssertionError: Invalid sha for : 4638aef40ba9ebb9734caeed1f373c24015259fd [10:51] type errors sometimes [10:51] mwhudson: is this just of the kernel or of other branches as well? [10:52] (only running locally, staging is still out of date [10:52] ) [10:52] jelmer: kernel and gedit [10:52] mwhudson: if it is just in the kernel, it might be an unrelated bug [10:52] only on the import of revs 3000-4000 too, not very far in [10:53] hm, it's not actually during revision fetch [10:53] mwhudson: The way I usually debug this is to compare the contents of the objects [10:53] mwhudson: git cat-file and bzr git-object [10:53] jelmer: well at 5 to midnight on a friday i'm mostly thinking about bed... [10:53] mwhudson: ahh, right :-) sorry, I hadn't considered the timezone [10:54] mwhudson: is there an easy way to reproduce this outside of launchpad, using command-line bzr-git? [10:54] jelmer: not sure tbh [10:54] guess we should get that limit parameter upstream to make testing easier ;-) [10:54] jelmer: maybe you can try gedit locally? [10:55] yeah, sure [10:55] https://code.launchpad.dev/+code-imports/+new [10:55] then run ./cronscripts/code-import-dispatcher.py as required [10:55] with make run_codehosting in another window [10:55] ah, thanks [10:57] if it doesn't work let's not worry too much, i can try to debug it on monday [10:57] and if we can't fix it we can always neuter the feature by setting the revision limit really really high [10:57] * mwhudson zzzs [11:04] Morning, all. [11:05] Is pushing branches to launchpad being slow for anyone else? I'm getting ~1KB/s, apparently, but my connection seems otherwise quite nippy. [11:06] morning deryck [11:06] gmb: bit slower than normal, yeah [11:07] Hrm. [11:07] (This is where my knowledge about how codehosting works ends) [11:08] stub: around? got a mo to review my db patch adding a trigger to update max_bug_heat? [11:08] k [11:08] excellent, just creating an MP [11:11] stub: https://code.edge.launchpad.net/~intellectronica/launchpad/update-max-heat/+merge/20204 [11:22] gmb: did you have any thoughts on how to implement bug #505849 ? [11:22] Bug #505849: Bug heat should decay over time [11:23] intellectronica: Some. deryck and I chatted about this and our general idea was that heat should decay by 10 points for each week since a bug's last been touched. [11:23] Hmm... we don't have max heat for a distroseries? [11:24] adeuring: looks like the new flame icons implementation is a bit broken. on a 1024 wide screen they new break and appear on a new line [11:24] stub: no, we only use the distro's max_heat [11:24] intellectronica: sigh... [11:25] intellectronica: do you mean listings or the icons on a bug index page? [11:25] gmb: gotcha. sounds like an easy solution. [11:26] adeuring: See bug 528374 [11:26] adeuring: let me take a screenshot [11:26] Bug #528374: Flames misplaced on bug report page [11:26] intellectronica: mpt already did that for you :) [11:26] thanks mpt [11:26] intellectronica: I think the distribution max_heat is incorrect, as BugTask's linked to a distroseries are not directly linked to a distribution (Only one of BugTask.distroseries and BugTask.distribution can be set) [11:27] stub: oh, good point. didn't realise that. [11:27] (I'm sure there was a reason for that, but I doubt it was a good one and hopefully not mine ;) ) [11:28] intellectronica: Do you want to fix or should I? [11:29] stub: go ahead and fix it if you can. [11:30] DistributionSourcePackage.max_bug_heat calculation doesn't support multiple distributions yet either, but I guess we don't have to worry about that now :) [11:31] :) [11:35] intellectronica: I can't reproduce this... which browser are you using? [11:36] adeuring: chrome [11:36] * adeuring nedds to install chrome... [11:37] adeuring: oh, and in FF it's even worse. the flames appear to the left of the bug info line instead of to the right [11:37] intellectronica: I thought that was intended ... [11:37] adeuring: oh, i didn't realise that. why did we change the location? [11:38] intellectronica: i have no idea what changed or when it changed. [11:39] adeuring: i thought it was your branch, since it was ok until yesterday, but maybe something else [11:39] the light icons do look much better, though [11:40] intellectronica: well, the icons were in firefox left of "bug #123 reported" even before my change [11:41] Bug #123: There's no direct way to see the project info when translating it [11:41] adeuring: huh. i can't believe we missed that for so long [11:42] adeuring, intellectronica -- the flames aren't orginally left of the reporter info. See: https://bugs.staging.launchpad.net/ubuntu/+source/nspluginwrapper/+bug/141613 [11:42] Bug #141613: npviewer.bin crashed with SIGSEGV

[11:44] * adeuring is now completely confused... [11:46] intellectronica: looks like it all needs refactoring. If a BugTask.product changes for instance, both the old product and the new product need their maximums updated. [11:47] oh.. hang on... i'm confusing myself [11:49] heh, "7 out of 4 heat flames" oops. :-) [11:50] Yer - if we do this with triggers, we need triggers on both bug and bugtask, because changes to bugtask link and unlink bugs from stuff and that stuff needs their maximums updated. [11:50] And technically on distroseries too incase a distroseries.distribution gets changed, but I think we can ignore that one. [11:52] stub: oright. i'll add triggers for the change of target. i guess in that case it would make sense to move most of the code out to a procedure and use the triggers to call that? [11:55] If there is enough that can be factored out, sure. [11:57] I'd go for the cron job personally :) [11:57] bigjools: Isn't that branch going to cause all the copy archive binaries to land in universe, so the second run won't actually use them? [12:05] bigjools: Hi ;) [12:05] bigjools: can you help me with build farm jobs or is that somebody else's domain? [12:05] intellectronica: can you take care of the flame icons buG? I OCR today and have some reviews in the quere... [12:06] adeuring: i think i can have a look at it after i finish refactoring my max_heat db patch [12:06] wgrant: Hi :) [12:07] intellectronica: thanks! [12:07] deryck: does that sound like a reasonable plan to you? ^^^^^ [12:07] henninge: Hi. [12:07] wgrant: are you knowlegable on build farm jobs? [12:07] henninge: Probably. [12:07] I know most of how it works. [12:07] it might mean not getting any other heat bugs done, though :/ [12:07] wgrant: I'd like to try out our template generate job in as much the same way as it will be run in real life. [12:08] wgrant: it's not applying any overrides [12:08] Error: There is a version conflict. [12:08] We already have: zope.interface 3.4.0 [12:08] ? [12:08] maybe it should look in the primary archive [12:08] Buildout error [12:09] stub: apt-get install python-zope.interface [12:09] bigjools: It should. [12:09] meh [12:09] I think. [12:09] I did have a nagging thought about it [12:09] henninge: Do you have a local buildd set up? [12:09] wgrant: I don't think so. What would that entail? [12:10] I have build the launchpad-buildd package, or I can at least. [12:11] henninge: So, you'll need to install that. What sort of arguments does your generation job take? [12:12] wgrant: a branch url to fetch the package branch from. That's all. [12:12] henninge: Seems to be working. ta. [12:12] intellectronica, looking back [12:12] henninge: OK, so, you can probably use Python's xmlrpclib to start the job without involving the horrible buildd-manager and Launchpad at all. [12:12] stub: oghers have gone before me ... ;-) [12:13] intellectronica, so the plan being you'll refactor the trigger branch and then fix the icons? [12:13] deryck: yes [12:13] buildout isn't reporting an error code on failure, which screws things up in the makefile... [12:13] intellectronica, good plan. [12:14] wgrant: in real life the build slaves are ec2instances, right? [12:14] no [12:14] oh [12:14] henninge: No. They're mostly Xen machines in the DC. [12:15] The rest are real machines in the DC. [12:15] ok, but they are like their own machines. [12:15] Yes. [12:16] but you are saying I should not try and simulate that part, just run it on my machine. [12:16]