| * thumper looks | 00:13 | |
| thumper | mwhudson: first try no, updating source code and download cache now | 00:16 |
|---|---|---|
| thumper | mwhudson: can you look at https://dev.launchpad.net/BuildBranchToArchive/MultipleSeriesBuilds and determine if we know enough to change the model? | 00:21 |
| mwhudson | thumper: i think we know basically enough | 00:23 |
| thumper | ok | 00:23 |
| mwhudson | thumper: i guess it reopens the question of "what namespace do recipes live in" | 00:24 |
| thumper | mwhudson: can you plan a branch count (1 or more as necessary) to change the model? | 00:24 |
| thumper | mwhudson: I think we are going to have recipes at ~user/distro/+source/packagename/+recipe/name | 00:24 |
| mwhudson | thumper: i'd have thought one would be enough | 00:24 |
| thumper | ok | 00:24 |
| mwhudson | thumper: ok that makes sense | 00:25 |
| thumper | 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 |
| thumper | mwhudson: consider ~user/project | 00:28 |
| mwhudson | thumper: 'useful objects' ? | 00:30 |
| mwhudson | i can see useful pages | 00:30 |
| thumper | mwhudson: at code.lp.net/~thumper/distribution ? | 00:30 |
| thumper | mwhudson: PersonDistro c.f. PersonProject | 00:31 |
| thumper | mwhudson: PersonDistroSeries | 00:31 |
| thumper | et al | 00:31 |
| mwhudson | right | 00:31 |
| mwhudson | maybe i'm unimaginative, but that doesn't seem very interesting | 00:31 |
| thumper | what useful pages can you see? | 00:31 |
| mwhudson | it's just work isn't it? | 00:31 |
| thumper | yes | 00:31 |
| mwhudson | thumper: i think we're saying the same thing in different ways, ignore my objection | 00:31 |
| thumper | ok | 00:32 |
| thumper | jml suggested there may be some multi-object adapter thing that we could use instead of having explicit objects | 00:32 |
| thumper | so (Person, Product) instead of PersonProduct | 00:32 |
| mwhudson | oh right | 00:32 |
| thumper | I'm not so sure there is | 00:33 |
| thumper | or even if there is that it is a better solution | 00:33 |
| thumper | simple is better than complex | 00:33 |
| mwhudson | well | 00:33 |
| mwhudson | um | 00:33 |
| thumper | although which is simple is a matter of opinion | 00:33 |
| mwhudson | i think you have to have something like PersonProduct | 00:33 |
| mwhudson | that you can hang a view off | 00:33 |
| thumper | mwhudson: btw, make worked with updated download-cache | 00:34 |
| mwhudson | it doesn't have to be anything more than just a container object though | 00:34 |
| mwhudson | thumper: :( | 00:34 |
| mwhudson | well i guess yay that launchpad isn't broken for _everyone_ | 00:34 |
| thumper | what are your symptoms? | 00:34 |
| mwhudson | mwh@grond:trunk$ make | 00:35 |
| mwhudson | utilities/shhh.py PYTHONPATH= ./bin/buildout \ | 00:35 |
| mwhudson | configuration:instance_name=development -c buildout.cfg | 00:35 |
| mwhudson | While: | 00:35 |
| mwhudson | Installing. | 00:35 |
| mwhudson | Getting section i18n. | 00:35 |
| mwhudson | Initializing section i18n. | 00:35 |
| mwhudson | Installing recipe z3c.recipe.i18n. | 00:35 |
| mwhudson | Error: There is a version conflict. | 00:35 |
| mwhudson | We already have: zope.interface 3.4.0 | 00:35 |
| thumper | hmm.. | 00:36 |
| thumper | my buildout bit isn't running | 00:36 |
| mwhudson | it seems to be finding the system zope.interface | 00:36 |
| thumper | and now I'm wondering what'll happen if I remove my eggs | 00:37 |
| mwhudson | thumper: dpkg -l python-zopeinterface | 00:37 |
| mwhudson | ? | 00:37 |
| thumper | un | 00:37 |
| mwhudson | ! | 00:37 |
| thumper | however in a python shell I can import zope.interface | 00:37 |
| mwhudson | !! | 00:38 |
| mwhudson | lots of things seem to depend on it here | 00:38 |
| thumper | ii python-zope.interface 3.5.2-1 | 00:38 |
| mwhudson | hmmm | 00:38 |
| mwhudson | HMMM | 00:39 |
| mwhudson | well | 00:39 |
| mwhudson | apt-get install python-zope.interface | 00:39 |
| mwhudson | which replaces the package | 00:39 |
| mwhudson | and now it works | 00:39 |
| mwhudson | W | 00:39 |
| mwhudson | T | 00:39 |
| mwhudson | F | 00:39 |
| mwhudson | anyway | 00:41 |
| * thumper shrugs | 00:43 | |
| thumper | weird | 00:43 |
| mwhudson | well about four hours later than it should have been, let's test that git import out... | 00:45 |
| thumper | mwhudson: :) | 00:52 |
| thumper | mwhudson: I've set my preferred email back to the @c.c one | 00:53 |
| thumper | mwhudson: we'll see if I get an email this time | 00:53 |
| thumper | mwhudson: perhaps we should add an --email-from tag too | 00:53 |
| thumper | mwhudson: that way it might work for the community people too | 00:53 |
| wgrant | thumper: It works fine if I run it myself, though. | 00:54 |
| wgrant | Probably because I have no SMTP server configured. | 00:54 |
| thumper | wgrant: could be | 00:54 |
| wgrant | And my mail server is not sufficiently SPF-policing. | 00:54 |
| thumper | wgrant: if the canonical one is set to use the canonical smtp server | 00:55 |
| thumper | wgrant: it only allows emails from a canonical.com address | 00:55 |
| thumper | wgrant: and drops others | 00:55 |
| wgrant | thumper: It doesn't even allow emails to a canonical.com address from a non-Canonical one? | 00:55 |
| thumper | wgrant: it may not be the general one... not sure | 00:56 |
| thumper | wgrant: maybe? | 00:56 |
| wgrant | Yay email. | 00:57 |
| mwhudson | ec2 test should just drop a letter in the mail | 00:59 |
| mwhudson | i'm sure there's a printer somewhere in amazon's data centre? | 00:59 |
| thumper | :) | 01:00 |
| thumper | mwhudson: an unproductive afternoon just got worse with visitors | 01:10 |
| thumper | mwhudson: I'm going to get a real coffee | 01:10 |
| mwhudson | thumper: ok | 01:10 |
| mwhudson | thumper: i'm going to be finishing a little early today, btw | 01:10 |
| thumper | mwhudson: ok | 01:11 |
| thumper | like 4? | 01:11 |
| mwhudson | thumper: about 4:30 | 01:11 |
| * thumper nods | 01:11 | |
| thumper | ok, sounds fine | 01:11 |
| mwhudson | cool | 01:12 |
| mwhudson | ec2 demo seems pretty broken by the openid changes | 01:20 |
| wgrant | mwhudson: What goes wrong? | 01:25 |
| wgrant | mwhudson: Does it hardcode hostnames like rocketfuel-setup? | 01:25 |
| mwhudson | wgrant: i got fed up and didn't really dig | 01:26 |
| mwhudson | but pages that require you to log in oops | 01:26 |
| wgrant | Yeah, it's not adding testopenid.dev to /etc/hosts. | 01:26 |
| mwhudson | oh right | 01:31 |
| mwhudson | hm it is when creating a new image | 01:31 |
| mwhudson | maybe a new one is needed | 01:32 |
| === bjf is now known as bjf-afk | ||
| wgrant | Does the image creation use rf-setup? | 01:35 |
| mwhudson | wgrant: no | 01:35 |
| mwhudson | rf-setup does rather more than is needed i think | 01:35 |
| wgrant | Ah, I didn't see the devscripts change in the diff. | 01:36 |
| wgrant | Ah, because the diff is 5000 lines. | 01:36 |
| jml | 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:15 | |
| jml | thumper, entia non sunt multiplicanda praeter necessitatem | 02:16 |
| thumper | jml: when are you back at work? | 02:16 |
| jml | thumper, I was back all today. | 02:16 |
| thumper | ah, home again? | 02:16 |
| jml | thumper, no, in Massachusetts | 02:17 |
| lifeless | jml: em or um? | 02:17 |
| jml | thumper, working w/ cody-somerville & kiko, talking about OEM requirements and things | 02:17 |
| jml | lifeless, em. | 02:17 |
| thumper | jml: ok | 02:17 |
| cody-somerville | s/OEM/NewCore (the new shiny) ;) | 02:18 |
| cody-somerville | err | 02:18 |
| lifeless | 'thingy' | 02:18 |
| thumper | hi cody-somerville | 02:18 |
| thumper | cody-somerville: still working? | 02:18 |
| thumper | getting kinda late isn't it? | 02:18 |
| cody-somerville | It is | 02:19 |
| cody-somerville | 21:19 | 02:19 |
| cody-somerville | Just got back from dinner. | 02:19 |
| thumper | and you couldn't wait to see what happened while you were out? | 02:19 |
| jml | thumper, well, I couldn't | 02:19 |
| jml | 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:20 | |
| thumper | jml: I've got my own pet project now | 02:21 |
| jml | thumper, does it involve web and dvcs? | 02:21 |
| thumper | jml: yeah | 02:23 |
| thumper | jml: looking at mako for templating | 02:23 |
| thumper | jml: looks more intuitive to me than genshi | 02:23 |
| thumper | jml: still using twisted.web | 02:23 |
| jml | thumper, what does django use normally? | 02:23 |
| thumper | kid I thought | 02:24 |
| jml | thumper, have you looked at nevow? | 02:24 |
| thumper | or maybe that was something else | 02:24 |
| thumper | jml: nope | 02:24 |
| thumper | mako is super fast | 02:24 |
| jml | thumper, I'm not suggesting that you _use_ it, mind, just that it's worth a look | 02:24 |
| thumper | and what the python website uses | 02:24 |
| thumper | jml: understood | 02:24 |
| thumper | jml: there are a gazillion different templating systems out there | 02:24 |
| thumper | I've been playing around with python 3.1 a bit too | 02:24 |
| jml | thumper, nevow is one that was built to work with twisted.web | 02:25 |
| wgrant | Django uses its own thing. | 02:25 |
| wgrant | I like genshi more than mako, I think. | 02:25 |
| wgrant | but there's not much in it. | 02:25 |
| thumper | wgrant: why? | 02:25 |
| thumper | I'm not strongly stuck on any one | 02:26 |
| wgrant | I'm not sure. | 02:26 |
| thumper | I just want something that can easily apply a common skin to pages | 02:26 |
| thumper | I'm not wanting to invest a lot of time into it | 02:26 |
| thumper | (just yet) | 02:26 |
| thumper | jml: do you know of a python library that renders moin syntax? | 02:26 |
| lifeless | thumper: like, oh, moinmoin ? | 02:27 |
| thumper | lifeless: I heard that it wasn't simple to extract the rendering code from the entire wiki project | 02:27 |
| jml | thumper, there's a name on the tip of my tongue (other than moinmoin) | 02:27 |
| thumper | lifeless: but I haven't looked | 02:27 |
| lifeless | thumper: I'd look; theres been a lot of work done on moin | 02:28 |
| jml | thumper, also, I humbly suggest that you should use mediawiki formatting | 02:28 |
| thumper | jml: I was going to have a choice | 02:28 |
| jml | thumper, good good. | 02:28 |
| thumper | jml: what is the name of the mediawiki format? | 02:28 |
| thumper | is there another name? | 02:28 |
| jml | thumper, no, I don't think so | 02:28 |
| jml | thumper, there's a wiki interchange library thing that I'm struggling to remember the name of | 02:29 |
| thumper | jml: I think I did a code import for that ... | 02:29 |
| thumper | jml: creole? | 02:31 |
| jml | thumper, yeah, that's it. | 02:31 |
| thumper | lp:creoleparser | 02:31 |
| jml | thumper, phew, I'll be able to sleep now. | 02:31 |
| mwhudson | thumper: is https://dev.launchpad.net/Code/PostThreeDotO much relevant these days? | 02:46 |
| thumper | mwhudson: I don't think so | 02:47 |
| thumper | mwhudson: we know about it all | 02:47 |
| thumper | mwhudson: and they are tracked elsewhere | 02:47 |
| mwhudson | thumper: right | 02:47 |
| thumper | mwhudson: so kill it | 02:47 |
| mwhudson | thumper: delete it? replace with a link to somewhere else? | 02:47 |
| thumper | umm... | 02:47 |
| thumper | not sure where to link it to | 02:47 |
| thumper | is there a general four dot oh page somewhere | 02:48 |
| thumper | or perhaps link to the dev wiki strategy pages? | 02:48 |
| mwhudson | https://dev.launchpad.net/VersionFourDotO/Themes ? | 02:49 |
| thumper | yeah, seems reasonable | 02:50 |
| thumper | mwhudson: I'm off to go shop for BBQ | 02:56 |
| thumper | mwhudson: see you monday | 02:56 |
| mwhudson | thumper: see you monday, have a good weekend | 02:56 |
| === mup_ is now known as mup | ||
| adeuring | good morning | 08:11 |
| === thekorn_ is now known as thekorn | ||
| jelmer | mwhudson, hi | 09:24 |
| jelmer | stub: ping | 09:27 |
| adeuring | when i run "make build", i get "Error: There is a version conflict. | 09:33 |
| adeuring | We already have: zope.interface 3.4.0". Any suggestions how to fix this? | 09:33 |
| wgrant | mwhudson had that this morning. | 09:33 |
| adeuring | wgrant: tahnks for the hint! | 09:35 |
| wgrant | adeuring: It looks like he might have fixed it by install the python-zopeinterface package. | 09:35 |
| wgrant | Er, python-zope.interface | 09:36 |
| adeuring | wgrant: thanks! that helped indeed | 09:40 |
| wgrant | Urgh. It shouldn't. | 09:41 |
| jtv | Did the +login page just stop working in devel? | 09:42 |
| wgrant | jtv: It's OOPSing? | 09:42 |
| jtv | wgrant: yup, for me it is | 09:42 |
| wgrant | jtv: Add testopenid.dev to /etc/hosts. | 09:42 |
| jtv | wgrant: thanks | 09:42 |
| wgrant | An email should really have been sent about that. | 09:42 |
| jtv | wgrant: thanks, that did the trick | 09:44 |
| wgrant | Great. | 09:44 |
| stub | jelmer: pong | 09:56 |
| jelmer | stub: Any chance you can review this patch that changes the db: https://code.edge.launchpad.net/~jelmer/launchpad/bug471148/+merge/20142 ? | 09:57 |
| allenap | Is it really week 3? I've been out of touch for a while :) | 09:57 |
| allenap | Yes, yes it is. (Looked at the milestone.) | 09:58 |
| stub | jelmer: What architectures does an archive get built for if there are no entries in ArchiveArch ? | 10:02 |
| jelmer | stub: Just the unrestricted architectures | 10:02 |
| stub | So we add this flag to avoid needing 8 entries in ArchiveArch for every archive. I see. | 10:03 |
| jelmer | stub: yep | 10:04 |
| stub | We are assuming we won't need further granularity like 'build hppa in lucid only' | 10:07 |
| stub | ? | 10:07 |
| bigjools | stub: that's already handled through distroarchseries | 10:10 |
| al-maisan | stub: this is not a requirement at present; if needed we could add a DistroSeries FK to ArchiveArch | 10:11 |
| al-maisan | to put the restricted processor family override into a distro series context | 10:12 |
| wgrant | How does this work with require_virtualized? | 10:12 |
| al-maisan | wgrant: the latter is orthogonal to this | 10:12 |
| bigjools | al-maisan: no FK needed, distroarchseries man :) | 10:14 |
| al-maisan | je | 10:14 |
| al-maisan | sorry | 10:14 |
| al-maisan | bigjools: I guess we're fine for the moment | 10:15 |
| bigjools | al-maisan: yep | 10:15 |
| wgrant | Ah, so this is for restricting the architectures of non-virtual PPAs? | 10:16 |
| jelmer | stub: thanks for the review | 10:16 |
| stub | np | 10:16 |
| al-maisan | 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 |
| bigjools | wgrant: it's for restricting for any archive | 10:16 |
| bigjools | virtuality is orthogonal | 10:17 |
| intellectronica | 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:21 |
| intellectronica | ah, nm, rocketfuel-got it | 10:24 |
| bigjools | al-maisan: that's a very valid use case actually | 10:30 |
| bigjools | for example, lpia is not in lucid | 10:30 |
| al-maisan | the lpia case is not really so pertinent since lucid has no lpia DistroArchSeries anyway | 10:31 |
| jtv | 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:32 |
| jtv | bdmurray: it needs to be marked as Q/Aed in order to be included in the release. | 10:33 |
| wgrant | Argh, all the buildds are gone again. | 10:41 |
| noodles775 | gar, the cherry-pick is still waiting to land :/ | 10:41 |
| noodles775 | wgrant: the i386 ppa builders are all full? | 10:43 |
| wgrant | And amd64 :( | 10:43 |
| noodles775 | wgrant: ah, I thought you meant that the buildd manager had died again... *phew* :) | 10:44 |
| === jtv is now known as jtv-afk | ||
| mwhudson | jelmer: incremental imports seem to fail with | 10:51 |
| mwhudson | AssertionError: Invalid sha for <Commit 8ab9c1e964cd0c36bb79f95fc229e49b7e296684>: 4638aef40ba9ebb9734caeed1f373c24015259fd | 10:51 |
| mwhudson | type errors sometimes | 10:51 |
| jelmer | mwhudson: is this just of the kernel or of other branches as well? | 10:51 |
| mwhudson | (only running locally, staging is still out of date | 10:52 |
| mwhudson | ) | 10:52 |
| mwhudson | jelmer: kernel and gedit | 10:52 |
| jelmer | mwhudson: if it is just in the kernel, it might be an unrelated bug | 10:52 |
| mwhudson | only on the import of revs 3000-4000 too, not very far in | 10:52 |
| mwhudson | hm, it's not actually during revision fetch | 10:53 |
| jelmer | mwhudson: The way I usually debug this is to compare the contents of the objects | 10:53 |
| jelmer | mwhudson: git cat-file <id> and bzr git-object <id> | 10:53 |
| mwhudson | jelmer: well at 5 to midnight on a friday i'm mostly thinking about bed... | 10:53 |
| jelmer | mwhudson: ahh, right :-) sorry, I hadn't considered the timezone | 10:53 |
| jelmer | mwhudson: is there an easy way to reproduce this outside of launchpad, using command-line bzr-git? | 10:54 |
| mwhudson | jelmer: not sure tbh | 10:54 |
| jelmer | guess we should get that limit parameter upstream to make testing easier ;-) | 10:54 |
| mwhudson | jelmer: maybe you can try gedit locally? | 10:54 |
| jelmer | yeah, sure | 10:55 |
| mwhudson | https://code.launchpad.dev/+code-imports/+new | 10:55 |
| mwhudson | then run ./cronscripts/code-import-dispatcher.py as required | 10:55 |
| mwhudson | with make run_codehosting in another window | 10:55 |
| jelmer | ah, thanks | 10:55 |
| mwhudson | if it doesn't work let's not worry too much, i can try to debug it on monday | 10:57 |
| mwhudson | 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 | 10:57 | |
| deryck | Morning, all. | 11:04 |
| gmb | Is pushing branches to launchpad being slow for anyone else? I'm getting ~1KB/s, apparently, but my connection seems otherwise quite nippy. | 11:05 |
| bigjools | morning deryck | 11:06 |
| bigjools | gmb: bit slower than normal, yeah | 11:06 |
| gmb | Hrm. | 11:07 |
| gmb | (This is where my knowledge about how codehosting works ends) | 11:07 |
| intellectronica | stub: around? got a mo to review my db patch adding a trigger to update max_bug_heat? | 11:08 |
| stub | k | 11:08 |
| intellectronica | excellent, just creating an MP | 11:08 |
| intellectronica | stub: https://code.edge.launchpad.net/~intellectronica/launchpad/update-max-heat/+merge/20204 | 11:11 |
| intellectronica | gmb: did you have any thoughts on how to implement bug #505849 ? | 11:22 |
| mup | Bug #505849: Bug heat should decay over time <story-bug-heat> <Launchpad Bugs:Triaged> <https://launchpad.net/bugs/505849> | 11:22 |
| gmb | 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 |
| stub | Hmm... we don't have max heat for a distroseries? | 11:23 |
| intellectronica | 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 |
| intellectronica | stub: no, we only use the distro's max_heat | 11:24 |
| adeuring | intellectronica: sigh... | 11:24 |
| adeuring | intellectronica: do you mean listings or the icons on a bug index page? | 11:25 |
| intellectronica | gmb: gotcha. sounds like an easy solution. | 11:25 |
| gmb | adeuring: See bug 528374 | 11:26 |
| intellectronica | adeuring: let me take a screenshot | 11:26 |
| mup | Bug #528374: Flames misplaced on bug report page <Launchpad Bugs:New> <https://launchpad.net/bugs/528374> | 11:26 |
| gmb | intellectronica: mpt already did that for you :) | 11:26 |
| intellectronica | thanks mpt | 11:26 |
| stub | 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:26 |
| intellectronica | stub: oh, good point. didn't realise that. | 11:27 |
| stub | (I'm sure there was a reason for that, but I doubt it was a good one and hopefully not mine ;) ) | 11:27 |
| stub | intellectronica: Do you want to fix or should I? | 11:28 |
| intellectronica | stub: go ahead and fix it if you can. | 11:29 |
| stub | 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:30 |
| intellectronica | :) | 11:31 |
| adeuring | intellectronica: I can't reproduce this... which browser are you using? | 11:35 |
| intellectronica | adeuring: chrome | 11:36 |
| * adeuring nedds to install chrome... | 11:36 | |
| intellectronica | 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 |
| adeuring | intellectronica: I thought that was intended ... | 11:37 |
| intellectronica | adeuring: oh, i didn't realise that. why did we change the location? | 11:37 |
| adeuring | intellectronica: i have no idea what changed or when it changed. | 11:38 |
| intellectronica | adeuring: i thought it was your branch, since it was ok until yesterday, but maybe something else | 11:39 |
| intellectronica | the light icons do look much better, though | 11:39 |
| adeuring | intellectronica: well, the icons were in firefox left of "bug #123 reported" even before my change | 11:40 |
| mup | Bug #123: There's no direct way to see the project info when translating it <Launchpad Translations:Fix Released> <https://launchpad.net/bugs/123> | 11:41 |
| intellectronica | adeuring: huh. i can't believe we missed that for so long | 11:41 |
| deryck | 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 |
| mup | Bug #141613: npviewer.bin crashed with SIGSEGV <apport-crash> <apport-failed-retrace> <iso-testing> <metabug> <npviewer> <npviewer.bin> <nspluginwrapper> <nspluginwrapper (Ubuntu):Confirmed> <nspluginwrapper (Mandriva):Fix Released> <https://launchpad.net/bugs/141613> | 11:42 |
| * adeuring is now completely confused... | 11:44 | |
| stub | 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:46 |
| stub | oh.. hang on... i'm confusing myself | 11:47 |
| deryck | heh, "7 out of 4 heat flames" oops. :-) | 11:49 |
| stub | 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 |
| stub | And technically on distroseries too incase a distroseries.distribution gets changed, but I think we can ignore that one. | 11:50 |
| intellectronica | 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:52 |
| stub | If there is enough that can be factored out, sure. | 11:55 |
| stub | I'd go for the cron job personally :) | 11:57 |
| wgrant | 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? | 11:57 |
| henninge | bigjools: Hi ;) | 12:05 |
| henninge | bigjools: can you help me with build farm jobs or is that somebody else's domain? | 12:05 |
| adeuring | intellectronica: can you take care of the flame icons buG? I OCR today and have some reviews in the quere... | 12:05 |
| intellectronica | adeuring: i think i can have a look at it after i finish refactoring my max_heat db patch | 12:06 |
| henninge | wgrant: Hi :) | 12:06 |
| adeuring | intellectronica: thanks! | 12:07 |
| intellectronica | deryck: does that sound like a reasonable plan to you? ^^^^^ | 12:07 |
| wgrant | henninge: Hi. | 12:07 |
| henninge | wgrant: are you knowlegable on build farm jobs? | 12:07 |
| wgrant | henninge: Probably. | 12:07 |
| wgrant | I know most of how it works. | 12:07 |
| intellectronica | it might mean not getting any other heat bugs done, though :/ | 12:07 |
| henninge | 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:07 |
| bigjools | wgrant: it's not applying any overrides | 12:08 |
| stub | Error: There is a version conflict. | 12:08 |
| stub | We already have: zope.interface 3.4.0 | 12:08 |
| stub | ? | 12:08 |
| bigjools | maybe it should look in the primary archive | 12:08 |
| stub | Buildout error | 12:08 |
| henninge | stub: apt-get install python-zope.interface | 12:09 |
| wgrant | bigjools: It should. | 12:09 |
| bigjools | meh | 12:09 |
| wgrant | I think. | 12:09 |
| bigjools | I did have a nagging thought about it | 12:09 |
| wgrant | henninge: Do you have a local buildd set up? | 12:09 |
| henninge | wgrant: I don't think so. What would that entail? | 12:09 |
| henninge | I have build the launchpad-buildd package, or I can at least. | 12:10 |
| wgrant | henninge: So, you'll need to install that. What sort of arguments does your generation job take? | 12:11 |
| henninge | wgrant: a branch url to fetch the package branch from. That's all. | 12:12 |
| stub | henninge: Seems to be working. ta. | 12:12 |
| deryck | intellectronica, looking back | 12:12 |
| wgrant | 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 |
| henninge | stub: oghers have gone before me ... ;-) | 12:12 |
| deryck | intellectronica, so the plan being you'll refactor the trigger branch and then fix the icons? | 12:13 |
| intellectronica | deryck: yes | 12:13 |
| stub | buildout isn't reporting an error code on failure, which screws things up in the makefile... | 12:13 |
| deryck | intellectronica, good plan. | 12:13 |
| henninge | wgrant: in real life the build slaves are ec2instances, right? | 12:14 |
| bigjools | no | 12:14 |
| henninge | oh | 12:14 |
| wgrant | henninge: No. They're mostly Xen machines in the DC. | 12:14 |
| wgrant | The rest are real machines in the DC. | 12:15 |
| henninge | ok, but they are like their own machines. | 12:15 |
| wgrant | Yes. | 12:15 |
| henninge | but you are saying I should not try and simulate that part, just run it on my machine. | 12:16 |
| wgrant | Right. | 12:16 |
| henninge | I mean, "setting up a buildd" is not setting up a xen instance or the like. | 12:16 |
| henninge | ok | 12:17 |
| wgrant | No, no. You just need to install the package. | 12:17 |
| wgrant | It'll run a daemon which makes the Soyuz tests fail, but that's about it. | 12:17 |
| henninge | good. Which is the top-level script I need to start? | 12:17 |
| wgrant | Have you installed launchpad-buildd? | 12:18 |
| wgrant | That should have started it already. | 12:18 |
| henninge | oh, I see. NOt atm, I had it installed in a pbuilder chroot. I'll try that again and look at it. | 12:18 |
| wgrant | That's fine too. | 12:19 |
| wgrant | The daemon just needs to be running somewhere. | 12:19 |
| henninge | so when it runs I can use xmlrpc to have it start my job. | 12:19 |
| henninge | ? | 12:19 |
| wgrant | Right. | 12:20 |
| henninge | wgrant: ok, thanks. Let me see how far I get with that. | 12:20 |
| wgrant | import xmlrpclib; xmlrpclib.ServerProxy('http://localhost:8221/rpc').build('1-1', 'translation-templates', 'sha1ofthechrootinyourlibrarian', {}, {'branch_url': 'http://url.to/branch'}) | 12:22 |
| henninge | wgrant: thanks, that'll help a lot ;-) | 12:30 |
| henninge | wgrant: where do I find 'sha1ofthechrootinyourlibrarian' ? | 12:30 |
| wgrant | henninge: Grab http://launchpadlibrarian.net/39617064/chroot-ubuntu-lucid-i386.tar.bz2, get it into your librarian, and use f1f10b8402ed686aaf0307676c76f07b45af2a09 as the SHA1. | 12:33 |
| ricotz | salgado, hello | 12:35 |
| salgado | hi ricotz | 12:36 |
| ricotz | salgado, is it possible for you to restart this build https://edge.launchpad.net/~ricotz/+archive/testing/+build/1532157 | 12:36 |
| ricotz | it seems to be jammed | 12:36 |
| salgado | ricotz, I don't seem to have permission to do that. should I have? | 12:37 |
| ricotz | salgado, sorry, thought you have | 12:38 |
| ricotz | can you delegate this request to someone who can | 12:38 |
| ricotz | bigjools, hello ^ | 12:39 |
| bigjools | ricotz: let me lookl | 12:40 |
| ricotz | thank you | 12:40 |
| bigjools | ricotz: why do you think it's jammed? | 12:40 |
| ricotz | cause its running for an hour and doesnt show any progress | 12:41 |
| bigjools | ok I'll investigate | 12:43 |
| ricotz | this build should take less than 10min like https://edge.launchpad.net/~ricotz/+archive/testing/+build/1532162 | 12:43 |
| bigjools | ricotz: it's reset and on a different builder now | 12:50 |
| bigjools | see how it goes | 12:50 |
| ricotz | bigjools, thank you! | 12:50 |
| === matsubara-afk is now known as matsubara | ||
| wgrant | henninge: Any luck? | 12:53 |
| techrascal | we are a bunch of undergrads and want set up a launchpad clone for projects we have in our college | 12:55 |
| techrascal | we have a server access with jailed ssh | 12:55 |
| techrascal | which doesnt give us sudo access and probably not even yum install kind of operations | 12:56 |
| techrascal | can anyone help me identify the bare minimum access we need for installing launchpad source code on a server | 12:56 |
| jml | techrascal, you'll need root, I'm afraid. | 13:41 |
| jml | techrascal, can you not just use launchpad.net? | 13:41 |
| === bigjools is now known as bigjools-lunch | ||
| === fjlacoste is now known as flacoste | ||
| === al-maisan_ is now known as al-maisan | ||
| === bigjools-lunch is now known as bigjools | ||
| deryck | BjornT, ping | 14:56 |
| jtv-afk | Why doesn't gpgme find my keys when I "make harness"? (It does when I ./bin/py) | 15:06 |
| === jtv-afk is now known as jtv | ||
| jtv | deryck: on an entirely arbitrary whim, I decide that you sound like the sort of person who would know this. | 15:09 |
| BjornT | deryck: pong | 15:09 |
| deryck | Hi BjornT. So I need to rollout a new lazr-js to update with a change Tom had. Want to make sure I remember right... | 15:10 |
| deryck | BjornT, it's just roll an sdist, ci it to download-cache, and update the versions.cfg in an lp branch. is that right? | 15:10 |
| gmb | Anyone know how to fix this http://pastebin.ubuntu.com/384423/ when I'm trying to run `make`? | 15:12 |
| gmb | rocketfuel-get and make clean haven't fixed it. | 15:12 |
| deryck | gmb, do you need to clean up download-cache by hand, i.e. remove something from it that bzr up is trying to add? | 15:15 |
| deryck | pure guess that is. | 15:15 |
| gmb | Hmm. | 15:16 |
| stub | (19:09:04) henninge: stub: apt-get install python-zope.interface | 15:17 |
| stub | gmb: ^^ I got a similar error, but zope.interface. That was the solution. | 15:18 |
| gmb | stub: I'll give that a shot, thanks. (Except with the zope package, obviously) | 15:18 |
| BjornT | deryck: yes, that's right | 15:19 |
| deryck | BjornT, thanks | 15:20 |
| === jtv is now known as jtv-afk | ||
| mars | ok, there is something fishy with the Repeat view load times of BugTasks on edge: http://www.webpagetest.org/result/100226_5F6Q/#run3 | 15:30 |
| mars | They have increased a lot since December: http://www.webpagetest.org/result/091221_3RNM/#run2 | 15:31 |
| mars | is the server under load or something? | 15:32 |
| mars | Dec time to first byte: 0.955s | 15:33 |
| mars | Feb time to first byte: 2.961s | 15:33 |
| gmb | Grrrrrrr. | 15:34 |
| mars | Must be something messed up with the cached view code on webpagetest's end. The first-view times are still sane across the board. | 15:48 |
| === bjf-afk is now known as bjf | ||
| gmb | gary_poster: I'm running into this whilst running make: http://pastebin.ubuntu.com/384423/. stub suggested apt-get installing zope.testing, but that didn't help. My download-cache is up to date; any suggestions about how I can get past this? | 15:51 |
| gary_poster | gmb: yes. As a work-around, manually edit your bin/buildout file to have a " -S" at the end of the shebang line. I have a (rather invasive, but fully reviewed) branch that I'll land at the beginning of next cycle to address. If you don't plan to land this until next cycle then you could merge that. Getting branch... | 15:53 |
| gmb | gary_poster: This needs to land today, so I'll use the workaround for now. | 15:53 |
| gary_poster | https://code.edge.launchpad.net/~gary/launchpad/bug491705 | 15:53 |
| gary_poster | gmb: ack | 15:54 |
| gmb | gary_poster: Thanks, though :) | 15:54 |
| gary_poster | np :-) | 15:54 |
| gmb | gary_poster: Er, that -S didn't seem to help any. I'll try merging your branch and see what happens. | 15:56 |
| gary_poster | gmb: mm, did you run make clean after applying the -S? If so, it would have been wiped away | 15:57 |
| gary_poster | gmb: steps would be as follows: | 15:57 |
| gary_poster | 1) run make | 15:57 |
| gary_poster | 2) curse at error | 15:57 |
| gary_poster | 3) edit bin/buildout | 15:57 |
| gary_poster | 4) run make again | 15:57 |
| gmb | gary_poster: I don't think I did; let me just try again. | 15:58 |
| gary_poster | if that doesn't help I'll be surprised and a bit concerned TBH | 15:58 |
| gmb | gary_poster: Hmm. Same problem. Let me try a clean branch of db-devel (this branch was fine before I merged db-devel to resolve some conflicts, btw) | 16:00 |
| gary_poster | gmb: argh. pastebin your edited bin/buildout for me to make sure we are talking about the same thing? | 16:00 |
| gmb | gary_poster: http://pastebin.ubuntu.com/384448/ | 16:01 |
| === matsubara is now known as matsubara-lunch | ||
| gary_poster | gmb: ok alternate approach, have you infact tried make clean && make? | 16:02 |
| gmb | gary_poster: Yes. No dice. | 16:02 |
| gmb | gary_poster: In fact it complains about bin/py not existing when I do that | 16:02 |
| gmb | Running link-external-sourcecode fixes that though. | 16:03 |
| gary_poster | gmb: that doesn't make a lot of sense in my world view, so I don't understand something that you are doing. :-/ | 16:04 |
| gary_poster | um | 16:05 |
| gmb | gary_poster: So, everything was fine until I merged db-devel. Then it broke. I updated my download-cache, ran make clean && make. | 16:05 |
| gmb | And everything else has revolved around trying to get the latter to work. | 16:05 |
| gary_poster | gmb, ok, I'll try to dupe. | 16:05 |
| gmb | gary_poster: The branch is at lp:~gmb/launchpad/processapportblobjob-api-bug-513191, ftr. | 16:06 |
| gary_poster | ack, on ity | 16:06 |
| gary_poster | or it | 16:06 |
| stub | gary_poster: I did notice that buildout must not be reporting an error code on this failure, as the shhh.py ate the output and the Makefile continued (hence the 'no bin/py' error) | 16:08 |
| gary_poster | stub, huh | 16:09 |
| gmb | gary_poster: This is also happening in a fresh branch of devel. | 16:15 |
| gmb | (the no bin/py thing, that is) | 16:15 |
| gmb | And also the zope.testing thing, too. | 16:15 |
| gary_poster | gmb, a full make WFM without having to edit bin/buildout (history, for reference: http://pastebin.ubuntu.com/384454/ ). I did not have zope.testing installed from apt, which is what your showed, so I just added it and will try | 16:16 |
| gary_poster | retry | 16:16 |
| === beuno is now known as beuno-lunch | ||
| gary_poster | gmb, sigh, still, worked for me. Can you think of anything else I should maybe do to try to supe our environments? Similarly, can you try merging in the branch I mentioned and see if it makes the problem go away for you? | 16:17 |
| gary_poster | s/supe/dupe/ | 16:18 |
| gmb | gary_poster: I'll try merging your branch; I can't think of anything else you need to do. I might end up just switching machines for the sake of getting this landed... | 16:18 |
| gary_poster | :-( | 16:18 |
| gary_poster | (If my branch doesn't help, then I'll have to try to dig into this later once the release pressure has passed) | 16:19 |
| gary_poster | (because it is supposed to make this kind of thing go away) | 16:19 |
| gary_poster | note that your download-cache will need to be up-to-date | 16:19 |
| deryck | abentley, qa-ready is very nice. many thanks! | 16:22 |
| abentley | deryck, you're welcome. | 16:23 |
| gmb | gary_poster: Same error but with extra messages after your branch is merged: http://pastebin.ubuntu.com/384458/ | 16:24 |
| gmb | gary_poster: I'll switch machines; I don't have time to debug this properly. | 16:25 |
| gmb | Thanks anyway. | 16:25 |
| gary_poster | gmb: ack, and sorry. I'll need your time next week. | 16:25 |
| gmb | gary_poster: Sure. | 16:25 |
| * gmb -> switching machines; brb | 16:25 | |
| === salgado is now known as salgado-lunch | ||
| gmb | gary_poster: Looks like it's all working fine on my laptop; no idea what's up with my desktop machine's environment. Ping me next week when you want to try and debug this. | 16:35 |
| === jtv-afk is now known as jtv | ||
| jtv | bigjools: did you dazzle the crowds? | 16:37 |
| gary_poster | gmb: glad you are unblocked at least. Another guess is http://pastebin.ubuntu.com/384463/ combined with my branch, FWIW. I don't have enough information so far to do much else than guess. I'll definitely ping you next week, thanks. | 16:38 |
| bigjools | jtv: I did - the head wants me to install Edubuntu there now | 16:40 |
| jtv | sinzui, maybe you can help me with this? I'm trying to get a GPG key out of the current system user's real GPG, and it works if I run it in a plain python, but I see no keys at all in "make harness" | 16:40 |
| jtv | bigjools: we'd hate to lose you to tech sales | 16:40 |
| bigjools | jtv: I feel I have missed my calling | 16:41 |
| bigjools | my true calling | 16:41 |
| jtv | bigjools: I get missed calls all the time... I'm also using True prepay. | 16:41 |
| sinzui | jtv: I have no experience with this... | 16:41 |
| jtv | drat | 16:42 |
| jtv | darn | 16:42 |
| jtv | smeg | 16:42 |
| bigjools | jtv: I watch True Blood | 16:42 |
| jtv | bigjools: speaking of bleeding hearts, you wouldn't know about this either would you? | 16:42 |
| henninge | bigjools: I followed wgrant's helpful hints but when I try to initiate the buld I get an error back (on xmlrpc). | 16:42 |
| jtv | the gpgme problem | 16:42 |
| sinzui | jtv: I think that tests that work with package uploading may provide a clue how to do this | 16:43 |
| jtv | sinzui: I'd prefer not to rely on zeca though | 16:43 |
| henninge | bigjools: what could be wrong here? http://paste.ubuntu.com/384472/ | 16:43 |
| * bigjools looks | 16:44 | |
| bigjools | henninge: there's a chroot checksum mismatch somehow | 16:45 |
| bigjools | so what the buildmaster told it it was didn't match what it calculated when it unpacked it | 16:45 |
| henninge | bigjools: when I Iook at the code, though, it does not seem to even try to get the file from the librarian. | 16:46 |
| bigjools | henninge: it could be cached | 16:46 |
| bigjools | and the cache doesn't match | 16:47 |
| bigjools | it's supposed to re-fetch in that case though :/ | 16:47 |
| henninge | bigjools: the cache is empty | 16:47 |
| bigjools | then I am stumped :( | 16:47 |
| henninge | bigjools: also, I am a bit confused by this: http://paste.ubuntu.com/384483/ | 16:48 |
| === beuno-lunch is now known as beuno | ||
| henninge | bigjools: trying to get the file by its sha1 value gives me an empty result. | 16:48 |
| bigjools | hmm | 16:49 |
| henninge | but accessing it by its id is possible - the sha1 is correct. | 16:49 |
| bigjools | henninge: findBySHA1("blah")[0] ... ? | 16:50 |
| henninge | oh, .... right | 16:50 |
| bigjools | it's a proxied result set | 16:50 |
| henninge | yup, that was too obvious for me to see ... | 16:51 |
| henninge | ok, so it's not an error in the librarian. | 16:51 |
| henninge | bigjools: does the librarian need to be running in any way for the slave to be able to access it? | 16:54 |
| bigjools | henninge: yeesssss :) | 16:54 |
| bigjools | unless it's some magic librarian | 16:54 |
| henninge | bigjools: I have tried with LP running in another terminal, though. | 16:54 |
| jtv | henninge: but what you need from the Librarian AFAIK is the chroot, and didn't you get stuck at that point? | 16:55 |
| henninge | bigjools: what else could keep the slave from being able to access the librarian? I am running it from a chroot. | 16:55 |
| bigjools | henninge: firewall? | 16:55 |
| henninge | ;) | 16:55 |
| bigjools | can you telnet the address/port it's trying to access? | 16:55 |
| bigjools | as your slave user | 16:56 |
| henninge | how do I know what it's trying to access | 16:56 |
| henninge | ? | 16:56 |
| bigjools | the URL is passed to it from the buildmaster | 16:56 |
| henninge | lemme try | 16:56 |
| bigjools | so it might not be passing the right URL | 16:56 |
| henninge | bigjools: do you mean the librarian url? | 17:01 |
| bigjools | henninge: the path should be ok, I suspect the domain part isn't | 17:01 |
| henninge | bigjools: ok, but I am simulating the master by an rpc call that wgrant gave me. So maybe the call is missing something. | 17:02 |
| bigjools | ah | 17:02 |
| bigjools | tell me what it was? | 17:03 |
| henninge | http://paste.ubuntu.com/384472/ | 17:03 |
| henninge | bigjools: ^ | 17:03 |
| bigjools | oh that | 17:03 |
| bigjools | hmmm | 17:04 |
| bigjools | I can't remember and honestly I think I'd rather run the b-m locally | 17:04 |
| henninge | bigjools: np, how do I do that? ;-) | 17:05 |
| bigjools | henninge: /bin/twistd --python daemons/buildd-manager.tac | 17:06 |
| bigjools | henninge: assuming you have the builder defined in LP.dev | 17:06 |
| bigjools | and that your job is ready to dispatch, etc | 17:06 |
| henninge | not sure if that is assuming too much .... | 17:06 |
| henninge | bigjools: I'll try something else first. | 17:07 |
| === matsubara-lunch is now known as matsubara | ||
| bigjools | henninge: poking xmlrpc is fine but given that only wgrant has done that then I would be scratching around the code a bit myself to remember what's going on | 17:08 |
| henninge | that's what I am doing ... ;) | 17:10 |
| henninge | bigjools: http://paste.ubuntu.com/384494/ ;-) | 17:11 |
| bigjools | henninge: \o/ | 17:12 |
| bigjools | henninge: awesome, let me know how it goes. When you get it all working locally we can try it out on dogfood. | 17:12 |
| === salgado-lunch is now known as salgado | ||
| henninge | bigjools: "can't find ntp.buildd" What should that be? | 17:16 |
| bigjools | I need more context | 17:17 |
| henninge | bigjools: sorry | 17:18 |
| henninge | bigjools: build log on the slave: http://paste.ubuntu.com/384500/ | 17:21 |
| bigjools | henninge: heh | 17:21 |
| bigjools | ok | 17:21 |
| bigjools | easy fix is to define that in /etc/hosts | 17:21 |
| bigjools | along with the other million .dev ones | 17:22 |
| bigjools | and point it at ntp.ubuntu.com | 17:22 |
| henninge | bigjools: oh, that is how the buildd's are synced ... | 17:23 |
| bigjools | yeah, the DC has that domain defined | 17:24 |
| === deryck is now known as deryck[lunch] | ||
| sinzui | I think the QA wiki script is behind. I just QAed my changes on staging, but the wiki does not know that they have landed and been deployed to staging | 17:39 |
| === danilo__ is now known as daniloff | ||
| henninge | jtv: are you sure the "doUpdate" step is required? | 17:51 |
| jtv | henninge: no. Only if something dramatically breaks intltool I expect. | 17:52 |
| henninge | jtv: it calls "update-debian-chroot" but that is not included in the chroot. | 17:53 |
| henninge | so it breaks. | 17:53 |
| henninge | jtv: also any cleanup fails because it tries to remove proc instead of unmounting it (and dev/pts and sys). | 17:53 |
| jtv | henninge: I don't think it's supposed to call that from within the chroot | 17:53 |
| jtv | but it's something I could easily have gotten wrong. | 17:54 |
| magcius | eeeek! | 18:02 |
| magcius | Why can't I visit edge.launchpad.net without this new Launchpad Login Service? | 18:02 |
| sinzui | magcius: because launchpad is going to use that for login from now on. | 18:04 |
| magcius | sinzui, but why do I need an account to view Edge? | 18:04 |
| magcius | (Is it just testing Edge?) | 18:04 |
| magcius | also, I see an +openid in the URL, but there's no place I can put in my existing OpenID | 18:04 |
| sinzui | magcius: except that the login service will really be Ubuntu. | 18:05 |
| magcius | sinzui, ? what does that mean? | 18:05 |
| magcius | (I don't use Ubuntu at all) | 18:05 |
| sinzui | magcius: I believe next week all launchpad will be using openid for login | 18:05 |
| magcius | sinzui, um, I still don't follow what you're saying | 18:06 |
| magcius | Next week when 10.2 releases I'll need to login to do anything? | 18:06 |
| === deryck[lunch] is now known as deryck | ||
| magcius | also, I don't know who to talk to about this, but your sliding door needs more length | 18:07 |
| magcius | i.e. right here: http://imgur.com/67fmj.png | 18:08 |
| sinzui | magcius: Yes. but to be clear, launchpad-login code became the launchpad SSO, but users did not to use it launchpad authentication, so we removed the feature last year. Ubuntu is the real SSO server, we have been running a copy and allowing the old login to continue for about year | 18:08 |
| deryck | intellectronica, I have some nervous energy about this branch. This updates in real time with changes, right? | 18:08 |
| intellectronica | deryck: yes | 18:09 |
| magcius | sinzui, Launchpad authentication? What was that? | 18:09 |
| intellectronica | not much different from a trigger, really | 18:09 |
| sinzui | magcius: login | 18:09 |
| magcius | sinzui, so there were two ways to log in? | 18:09 |
| magcius | sinzui, what were they? | 18:09 |
| intellectronica | deryck: are you worried about timing? | 18:10 |
| deryck | intellectronica, except this happens in a view, right? So if it takes a while to complete it timesout a view. I thought triggers were independent of the view. | 18:10 |
| deryck | yeah, timing is always my fear :-) | 18:10 |
| intellectronica | deryck: why in a view? | 18:10 |
| intellectronica | oh right, when you create a task or change the target it's in a view, you're right | 18:10 |
| sinzui | Launchpad has not manages user accounts for a year. We allowed users to continue to use the launchpad copy of SSO, but the Ubuntu version is the master. when you login to a page in launchpad, you are really logging into ubuntu's sso | 18:11 |
| deryck | intellectronica, that's what I meant. I realize it's model code, but called from a view. | 18:11 |
| deryck | intellectronica, you could create a job then, but you still need something to process it offline. | 18:11 |
| deryck | intellectronica, do you feel really confident this won't timeout? | 18:12 |
| magcius | sinzui, what is the Ubuntu SSO? | 18:12 |
| intellectronica | deryck: we can remove the code that updates when you touch a bugtask. that will have pretty much the same effect, and wait for the max_heat to get updated when the bug's heat is next updated | 18:12 |
| sinzui | magcius: https://login.ubuntu.com/ | 18:12 |
| intellectronica | deryck: it's hard for me to guesstimate whether it will timeout. i can't really know without trying this on staging | 18:13 |
| magcius | sinzui, so if I have a Launchpad account, I can log in there? | 18:13 |
| deryck | intellectronica, can we just move all of it to update when heat is recalculated? | 18:13 |
| deryck | or is that what you mean? | 18:13 |
| magcius | sinzui, what exactly does the Ubuntu SSO allow me to do? | 18:13 |
| intellectronica | deryck: it will update when heat is calculated anyway | 18:13 |
| sinzui | magcius: yes, because you really do have an ubuntu account, launchpad only keeps a profile of your hacking activity. For example, Launchpad does not really know your email address. | 18:14 |
| intellectronica | deryck: it updates all targets whenever setHeat is called on a bug | 18:14 |
| deryck | intellectronica, which happens offline, right? | 18:14 |
| intellectronica | yes | 18:14 |
| magcius | sinzui, okay, what can I use the Ubuntu SSO for? | 18:14 |
| deryck | intellectronica, so the only live update is when a task is re-targeted? | 18:15 |
| magcius | sinzui, like, I see my OpenID site in there for "Sites you last authenticated to" | 18:15 |
| intellectronica | deryck: yes, or when a new task is created | 18:15 |
| sinzui | magcius: You can use the openid url on your launchpad profile page to login into other openid enabled sites without registration | 18:15 |
| magcius | sinzui, I already have an OpenID account, I don't need another one | 18:15 |
| sinzui | magcius: you have had one from launchpad for about 2 years, it is shown on you profile page | 18:16 |
| deryck | intellectronica, yeah, so I think either remove those bits. Because those will trigger setHeat anyway, right? | 18:16 |
| magcius | sinzui, I know, I have had another one from ClaimID.com for about 3 or 4 | 18:16 |
| deryck | s/either// | 18:16 |
| intellectronica | deryck: i don't see how they will trigger setHeat | 18:17 |
| intellectronica | deryck: how about, we remove triggering this when touching bugtasks and open a bug for looking at it later? | 18:18 |
| intellectronica | deryck: my worry with all this stuff that happens offline is that we'll be accumulating inaccurate data | 18:18 |
| intellectronica | it's very hard to follow what happens when | 18:18 |
| deryck | intellectronica, yeah, that sounds good. Also, if we're not adjusting heat with bugtask changes, then maybe we shouldn't do max_bug_heat either then. | 18:19 |
| intellectronica | so without triggering the calculation directly, we'll probably have reasonable results, but i just don't want to leave it at that | 18:19 |
| intellectronica | deryck: i'm sorry, i don't really understand your last sentence | 18:19 |
| deryck | intellectronica, I'm asking why do we even need to recalculate max_bug_heat on bugtask changes? If we don't change heat on the bug on bugtask changes, then why change max_bug_heat? | 18:21 |
| intellectronica | deryck: because the bug might already have heat | 18:22 |
| deryck | intellectronica, ah, but the project of the task might not yet have a max_bug_heat? | 18:22 |
| intellectronica | deryck: exactly | 18:22 |
| deryck | hmmmmm | 18:22 |
| intellectronica | deryck: how screwed are we if this gets so staging and we find it times out? it will be really nice to know whether this is actually a problem | 18:24 |
| deryck | intellectronica, thinking about that. is the only time we would call this "live" would be on changing a bugtask? which is via AJAX? | 18:24 |
| intellectronica | deryck: also when adding a new task. both are not necessarily ajaxed (changing a target can be ajaxed but there's also a non-ajax interface) | 18:25 |
| deryck | intellectronica, right, but it's through a new page, which is not as a bad as a bug list or page. I think this probably isn't a problem in practice. | 18:26 |
| intellectronica | deryck: right, i wouldn't bet on a timeout. but as always, without testing this on ubuntu on staging it's very hard to tell | 18:27 |
| deryck | intellectronica, I'm willing to risk it. allenap has to cowboy a patch to test. perhaps we could create a combined diff and test both. | 18:28 |
| intellectronica | great! | 18:28 |
| intellectronica | worst case, we know exactly what are the bits we need to back-out, so it shouldn't be too much work to recover from it | 18:28 |
| deryck | right. but I do want to avoid having to do that. | 18:29 |
| intellectronica | but if we get to cowboy a patch then even that won't be necessary | 18:29 |
| deryck | exactly. | 18:31 |
| deryck | intellectronica, so can you and allenap coordinate about that combined diff when he's available. | 18:31 |
| intellectronica | sure thing | 18:31 |
| intellectronica | deryck: apart from that, any comments on the code? | 18:31 |
| deryck | intellectronica, looks good. Just doing a careful scan of the sql, and then I'll be ready. | 18:32 |
| intellectronica | cool | 18:32 |
| deryck | intellectronica, only comment really is that line 145 has a commented out bit of code, which I assume you don't need anymore. | 18:36 |
| intellectronica | deryck: whoops, no, of course i don't need that bit. | 18:37 |
| intellectronica | removed | 18:38 |
| deryck | intellectronica, cool. running a couple queries on staging just for paranoia. | 18:39 |
| deryck | hmmm, it's slow. | 18:41 |
| deryck | intellectronica, http://pastebin.ubuntu.com/384562/ | 18:42 |
| intellectronica | oh yes, that's too slow | 18:43 |
| intellectronica | deryck: so, remove the call when touching a bugtask for now? i do think we'll have to revisit this if we want reliable results, but it probably won't be too terrible for now | 18:45 |
| intellectronica | b.t.w i think it will also be very slow when calculating heat from a script | 18:46 |
| deryck | intellectronica, just a second more and let me play and then we can decide. not meaning to delay, I know it's late for you. | 18:47 |
| intellectronica | deryck: that's oright, i'm working on other heat bugs in the meantime. no rush | 18:47 |
| intellectronica | and thanks for running these queries. nothing beats real data | 18:48 |
| deryck | yeah, I'm glad I can do them on staging. | 18:48 |
| deryck | intellectronica, I may have something. http://pastebin.ubuntu.com/384585/ | 19:14 |
| deryck | removing the union and doing a limit. and I get the right result. it makes sense to me. | 19:14 |
| intellectronica | deryck: wow. i'm impressed. | 19:15 |
| intellectronica | not by postgres :) | 19:15 |
| deryck | my head hurts now. | 19:15 |
| intellectronica | i'm amazed the difference is so bug | 19:15 |
| intellectronica | big | 19:15 |
| deryck | yeah, it's huge. | 19:15 |
| deryck | because it doesn't have to scan with the limit and order by. | 19:16 |
| intellectronica | so this is just one of the queries in the union, but even running both and maxing the result in python would be faster than the 4s we got with the union | 19:16 |
| deryck | intellectronica, no, this can replace the union. | 19:17 |
| deryck | intellectronica, you just want the highest bug heat for any bug that has a bugtask.distribution or bugtask.distroseries, right? | 19:17 |
| intellectronica | deryck: right, i missed the OR | 19:17 |
| intellectronica | it doesn't limit by distribution. don't know if that will make much of a difference | 19:18 |
| deryck | intellectronica, right. so we can add a distribution = %s. Let me check times on that. | 19:18 |
| intellectronica | deryck: can you run the same with AND Bugtask.distribution = 1 ?@ | 19:18 |
| deryck | intellectronica, quicker even! | 19:21 |
| intellectronica | awesome | 19:21 |
| deryck | intellectronica, http://pastebin.ubuntu.com/384589/ | 19:21 |
| intellectronica | wonderful | 19:23 |
| intellectronica | and the sql is much more readable too | 19:23 |
| deryck | intellectronica, cool. So r=me with something like this to replace each UNION sql statement. If that seems acceptable to you, too. | 19:24 |
| intellectronica | i'm still surprised. my guess is that it's not the max() that was making it small, but the nested queries | 19:24 |
| intellectronica | deryck: for sure. thanks a bunch! | 19:24 |
| deryck | intellectronica, cool. np! Very sick of timeouts. One day we'll do this everywhere and bring our counts do on the OOPS report. | 19:25 |
| sinzui | beuno: adeuring: landed his fix for bug advanced search: https://bugs.edge.launchpad.net/launchpad-registry/+bugs?advanced=1 | 19:31 |
| sinzui | ^ You can now see what the default criteria is for searching, and the legends a have enough space so that you can see the parts of the form. | 19:31 |
| * sinzui thinks the checkboxes at the end are silly though | 19:32 | |
| beuno | sinzui, sure | 19:32 |
| sinzui | beuno: I wanted them to be radio-button | 19:33 |
| beuno | so | 19:35 |
| beuno | almost everything on that page needs vertical spacing | 19:35 |
| beuno | the sorting drop down is confusing when layed out that way | 19:36 |
| beuno | the input box as well | 19:36 |
| beuno | this is advanced search, so you probably want to explain that the input box is optional, and to search for text in X or Y parts of the bug | 19:36 |
| beuno | the "Doesn’t matter" option for asignee could be named better | 19:37 |
| sinzui | beuno: I agree. I think Abel has done a good job closing a number of UI issues in one branch. He may hate me for it, but I can finally read that form | 19:37 |
| beuno | sinzui, YES. It's a million times better now | 19:37 |
| beuno | the any/all radio buttons on tags should be right next to the tag field | 19:37 |
| beuno | just "Help" may also suffice there | 19:38 |
| beuno | and having: | 19:39 |
| sinzui | In their previous position, they looked like they were subordinate to the item above. The form layour you introduced 9 months places subordinates below, not to the right | 19:39 |
| beuno | Show only bugs with linked branches | 19:39 |
| beuno | Show only bugs without linked branches | 19:39 |
| beuno | both ticked by default is a bit confusing | 19:39 |
| beuno | ah | 19:39 |
| beuno | well, if it can't be easily tweaked to be to the right of the input, at least change the labels to "All tags" or "Any tags" | 19:40 |
| beuno | all labels on that page could do with .5-1em of padding-top | 19:40 |
| sinzui | beuno: yes, I was too, as was abel, We and I wanted a radio button show exclusivity or state your do not care. I had to run a search to prove I would get results with that insane condition | 19:40 |
| sinzui | beuno: yes, padding can fix the radiobutton on right issue. | 19:42 |
| jml | kfogel, ol buddy ol pal | 19:44 |
| jml | kfogel, I want an elisp function that behaves like upcase-word but switches from under_score to camelCase, and another one that goes in the other direction. | 19:45 |
| beuno | sinzui, did all that help? or where you asking something else? | 19:45 |
| === jtv is now known as jtv-eat | ||
| sinzui | beuno: yes it helped. I wanted your opinion on the improvement. | 19:46 |
| beuno | sinzui, long overdue, and very nice! | 19:47 |
| jml | kfogel, It would be great if you could write this, but I say this in a way that has absolutely nothing to do with Canonical, just that it would help my occasional free software LP development | 19:47 |
| EdwinGrubbs | bac, sinzui: what do you think about this simplified upstream connections portlet? https://chinstrap.canonical.com/~egrubbs/upstream/upstream_simplified.png | 20:00 |
| sinzui | EdwinGrubbs: I think that can get long | 20:01 |
| sinzui | EdwinGrubbs: This may be easier if you keep in mind your proposing a change to two pages, not one... | 20:02 |
| bac | EdwinGrubbs: 'mozilla', 'firefox', and 'blog series' are three different links? | 20:02 |
| sinzui | EdwinGrubbs: The difference between the packaging listing and the source package page is that the listing does not get the change operations | 20:04 |
| sinzui | https://edge.launchpad.net/ubuntu/lucid/+packaging | 20:04 |
| sinzui | https://edge.launchpad.net/ubuntu/lucid/+source/openoffice.org | 20:04 |
| sinzui | EdwinGrubbs: if we can keep the branch and translations in a separate column, and keep the 3 objects linked, the layout may work for both cases. Your https://chinstrap.canonical.com/~egrubbs/upstream/horizontal_hierarchy.png is more practical for users who want to visit the project or project group | 20:07 |
| intellectronica | what's a good way to test something time-related? | 20:08 |
| intellectronica | is there a way to temper with the current time for a test? | 20:09 |
| EdwinGrubbs | sinzui, bac: I had actually removed the project group entirely after reading Curtis' email. Then I removed the project link, since the user can always make to clicks, and it makes the display cleaner and clearer. | 20:10 |
| EdwinGrubbs | s/to clicks/two clicks/ | 20:10 |
| sinzui | EdwinGrubbs: I cannot fix the project bug tracker unless I have a link to the project. We need links to projects an series. The project group link is dubious, but needed until the bugs team sorts out their upstream contact contradiction | 20:11 |
| sinzui | bac: EdwinGrubbs: look at this: https://bugs.edge.launchpad.net/openoffice | 20:12 |
| sinzui | ^ I need to enable bug tracking to set the value, then disable it again? | 20:13 |
| EdwinGrubbs | bac, sinzui: I'll use the horizontal layout but with the Branch in a separate column then. | 20:17 |
| sinzui | EdwinGrubbs: I think that is what is there now (and translations is there too) | 20:18 |
| EdwinGrubbs | yes | 20:19 |
| === gary_poster is now known as gary-lunch | ||
| === gary-lunch is now known as gary_poster | ||
| === jtv-eat is now known as jtv | ||
| wgrant | Ooh. Somebody fixed the advanced search form. | 22:06 |
| beuno | wgrant, hug sinzui and adeuring for that | 22:07 |
| wgrant | Hey, ISD finally got their act together. | 22:09 |
| lifeless | ? | 22:09 |
| wgrant | The security fix has finally been rolled out. | 22:10 |
| === matsubara is now known as matsubara-afk | ||
| bdmurray | make build is failing for me in devel at finding a distribution for lazr-js==0.9.2DEV-r169 | 22:17 |
| wgrant | bdmurray: Run rocketfuel-get lately? | 22:18 |
| wgrant | How is login.ubuntu.com going to provide the OpenID team data that Launchpad provides? | 22:20 |
| lifeless | bdmurray: update-sourcecode probably | 22:22 |
| wgrant | This one needs an updated download-cache. | 22:23 |
| wgrant | rocketfuel-get updates both. | 22:23 |
| lifeless | ah | 22:24 |
| lifeless | wgrant: is there a UEC AMI for doing LP dev? | 22:24 |
| wgrant | lifeless: No. | 22:25 |
| bdmurray | wgrant: okay I ran rocketfuel-get and it got the new version of lazr-js but its still failing | 22:28 |
| wgrant | Hmmm. | 22:29 |
| bdmurray | oh, that's not quite right | 22:31 |
| bdmurray | I have 0.9.2DEV not -r169 | 22:31 |
| * bdmurray takes it back | 22:33 | |
| wgrant | I can see it was added to the branch 7 hours ago. | 22:33 |
| bdmurray | okay I'm all squared away now thanks | 22:35 |
| lifeless | wgrant: do you know, is the EC2 test AMI suitable for adapting to be a development AMI? | 22:42 |
| wgrant | lifeless: I considered that. Quite possibly -- it can already do 'ec2 demo'. | 22:43 |
| wgrant | (although it needs an image update for the OpenID stuff) | 22:44 |
| lifeless | do you know the size of the AMI? | 22:45 |
| wgrant | No. | 22:46 |
| === jamalta is now known as jamalta-afk | ||
| mwhudson | jelmer: any luck with incremental imports? | 23:04 |
| jelmer | mwhudson: I wrote a small plugin to add --limit to bzr pull - lp:~jelmer/+junk/bzr-pull-limit | 23:05 |
| jelmer | mwhudson, but I haven't really been able to reproduce the problem yet | 23:08 |
| wgrant | sinzui: Around? | 23:08 |
| sinzui | I am | 23:09 |
| wgrant | sinzui: I'm interested in making the mirror prober less inflexible by converting it to a job-based system. | 23:09 |
| sinzui | That will make several people happy | 23:10 |
| sinzui | wgrant: jpds may also be interested in the job system for mirrors. There is a small chance the two of you could step on each other. | 23:16 |
| jpds | sinzui: We do that all the time. ;) | 23:17 |
| wgrant | sinzui: Oh, don't worry, I'm talking to him. | 23:17 |
| mwhudson | jelmer: :/ | 23:17 |
| sinzui | fab. | 23:17 |
| mwhudson | jelmer: oh well, something for monday then | 23:17 |
| jelmer | mwhudson: If I have a spare moment on the train I might have a look during the weekend | 23:18 |
| mwhudson | ooh, staging is updated | 23:18 |
| mwhudson | let's try it there | 23:19 |
| mwhudson | jelmer: ok, don't sweat it | 23:19 |
| lifeless | mwhudson: so a full repo fetch wasn't it ? | 23:22 |
| wgrant | sinzui: It seems to me that there are two options for doing this: adding a next_probe_time to DistirbutionMirror, or adding a full-blown DistributionMirrorProbeJob. | 23:25 |
| sinzui | wgrant: In the former to do image a default time and allowing users to choose probe now so that the existing proc will pull all those that are due for a probe? | 23:27 |
| wgrant | sinzui: Something like that, yes. | 23:28 |
| wgrant | The former probably makes more sense. | 23:30 |
| sinzui | I think so to, but I am thinking of reason that might happen in the next year that make us want a job instead | 23:31 |
| wgrant | Oh? | 23:31 |
| wgrant | I couldn't think of anything compelling. | 23:31 |
| sinzui | wgrant: nor me | 23:32 |
| lifeless | ugh | 23:51 |
| lifeless | http://lanchpad.net/testresources | 23:51 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
