| lifeless | wgrant: blacklist +1 | 00:00 |
|---|---|---|
| wgrant | lifeless: But that means having the list of exclusions in a separate tree. | 00:00 |
| lifeless | wgrant: we've needed one exclusion in 6 years | 00:00 |
| lifeless | wgrant: I think we can deal | 00:01 |
| wgrant | True. | 00:01 |
| wgrant | Pushing. | 00:01 |
| wgrant | Ah, allenap beat me to a bulk loading helper. | 00:03 |
| * lifeless isn't sure its the right way | 00:03 | |
| wgrant | I'm not sure it is either. | 00:04 |
| lifeless | we want, for instance, to eager load visibility rules etc | 00:04 |
| lifeless | so I think it needs per-type handling rather than a separate helper | 00:05 |
| lifeless | however, allenap has written something that will be usable for somethings | 00:05 |
| wgrant | Right, that's what I was thinking. It is a pattern that we already use in several places. | 00:05 |
| wgrant | And this helper can do nice stuff like not issuing a query if everything is already preloaded. | 00:06 |
| lifeless | it introspects the storm cache? | 00:06 |
| wgrant | Since that is going to become a common case, I think. | 00:06 |
| wgrant | *can do* | 00:06 |
| wgrant | Not does now. | 00:06 |
| lifeless | ah | 00:06 |
| lifeless | sure | 00:06 |
| thumper | arse | 00:07 |
| thumper | leonardr: I don't suppose you are still around? | 00:07 |
| thumper | leonardr: I have a lazr-restful problem | 00:07 |
| leonardr | thumper: i'm here | 00:07 |
| thumper | ah, awesome | 00:07 |
| thumper | leonardr: let me pastebin something... | 00:07 |
| wgrant | lifeless: https://code.launchpad.net/~wgrant/launchpad/exclude-lpnet-template/+merge/52497 | 00:08 |
| wgrant | Thanks. | 00:10 |
| wgrant | lifeless: You're landing lamont's thing and the staging fix? | 00:10 |
| lifeless | thats how I found this, yes. | 00:11 |
| lifeless | I'm not sure what branch the check checks out | 00:11 |
| wgrant | Checking. | 00:11 |
| thumper | leonardr: http://pastebin.ubuntu.com/577252/ | 00:11 |
| wgrant | ./launchpad bzr+ssh://bazaar.launchpad.net/~launchpad-pqm/launchpad/stable | 00:11 |
| wgrant | fuuuu | 00:11 |
| thumper | leonardr: getting TypeError: Only a read-only field can have a mutator method. | 00:11 |
| wgrant | lifeless: But you can fix that in the branch :P | 00:12 |
| lifeless | wgrant: meh, will wait for bb | 00:12 |
| thumper | leonardr: wanting the accessor and mutator only in "devel" | 00:12 |
| lifeless | stable is not unreasonable | 00:12 |
| thumper | leonardr: any ideas? | 00:13 |
| leonardr | reading | 00:16 |
| leonardr | thumper: have you tried putting @operation_for_version first? | 00:17 |
| thumper | leonardr: first as in at the top, or bottom? | 00:17 |
| leonardr | at the bottom | 00:17 |
| * thumper tries | 00:17 | |
| thumper | nope, that doesn't fix it | 00:18 |
| leonardr | right now the mutator is exported in beta nad the field is not exported at all in beta | 00:18 |
| leonardr | same error? | 00:18 |
| thumper | yep | 00:18 |
| leonardr | thumper: the field itself needs to be read-only. it can't just be exported as read-only | 00:19 |
| thumper | oh? | 00:19 |
| leonardr | see the mutator_for method in lazr.restful declarations.py | 00:19 |
| thumper | really? | 00:19 |
| leonardr | that's what it says | 00:19 |
| leonardr | if not self.field.readonly: | 00:19 |
| leonardr | raise TypeError("Only a read-only field can have a mutator " | 00:19 |
| leonardr | "method.") | 00:19 |
| thumper | hmm... | 00:19 |
| thumper | we should fix that | 00:19 |
| thumper | maybe... | 00:19 |
| wgrant | Why can't you make the field read-only? It only affects forms and the webservice. | 00:20 |
| lifeless | sinzui: are you going to land the new lazr restful egg? | 00:20 |
| thumper | wgrant: because the forms edit it | 00:20 |
| thumper | wgrant: I'd have to override the field... | 00:21 |
| wgrant | :( | 00:21 |
| thumper | wgrant: and it changes the permissions | 00:21 |
| thumper | wgrant: if the field is readonly, the permissions don't allow setting | 00:21 |
| wgrant | It doesn't affect security proxies. | 00:21 |
| leonardr | lifeless: i think it would be okay to let mutator_for succeed if the field is never *published* as read-write in any version for which it has a mutator | 00:21 |
| wgrant | Hmm, unless maybe it affects set_schema, but not much uses that. | 00:22 |
| * leonardr has to go | 00:22 | |
| thumper | wgrant: I think it does... | 00:22 |
| thumper | leonardr: ok | 00:22 |
| wgrant | thumper: Anyway, shouldn't the form be using the mutator anyway? | 00:22 |
| thumper | wgrant: it means more hoop jumping to extract the field from the data dictionary, getting the delta object first, raising the object modified event manually | 00:23 |
| thumper | man I wish our form infrastructure used the API :) | 00:23 |
| * thumper has a plan | 00:25 | |
| thumper | :( | 00:26 |
| thumper | ohh... tentative success | 00:27 |
| thumper | :( now getting You tried to modify a read-only attribute. in the 400 response | 00:35 |
| wgrant | checkwatches OOPSes and bye-bye-nullbugtask today, I think. | 00:41 |
| lifeless | wgrant: but its perf tuesday! | 00:43 |
| wgrant | lifeless: Killing NullBugTask gets rid of some timeouts! | 00:43 |
| wgrant | But OK. | 00:43 |
| wgrant | Maybe getBuildRecords. | 00:44 |
| lifeless | \o/ | 00:44 |
| wgrant | I also need to attack +copy-packages again.. the copying is now fast, but the rest of the page is not :/ | 00:44 |
| lifeless | wgrant: its a never ending story | 00:45 |
| leonardr | thumper: it sounds like the lookup of the mutator operation didn't succeed. you could try putting a breakpoint in generate_entry_adapters() (lazr.restful declarations.py) | 01:00 |
| leonardr | it should be creating a PropertyWithMutator for the field in the appropriate version | 01:00 |
| thumper | i'll try that | 01:01 |
| * thumper sighs | 01:02 | |
| thumper | every freaking entry | 01:02 |
| thumper | ok | 01:04 |
| thumper | lots of continues, and found the right interface | 01:04 |
| lifeless | huwshimi: Bug 730535 | 01:16 |
| _mup_ | Bug #730535: Enter key ignored the first time in bug tag editing field <bugtag> <javascript> <Launchpad itself:Triaged> < https://launchpad.net/bugs/730535 > | 01:17 |
| lifeless | huwshimi: is that a regression from your changes? | 01:17 |
| huwshimi | lifeless: it looks like the same issue. I believe my changes won't be rolled out until lazr-js is updated in LP. | 01:18 |
| lifeless | huwshimi: ah! then your bug should not be closed | 01:19 |
| lifeless | huwshimi: and this new bug should be a dupe. | 01:20 |
| huwshimi | lifeless: yeah | 01:20 |
| huwshimi | lifeless: I think it was marked as closed during a deployment or something | 01:20 |
| * thumper sighs | 01:22 | |
| lifeless | huwshimi: do you know how to move forward on this? | 01:22 |
| huwshimi | lifeless: Nope :) | 01:22 |
| lifeless | ok | 01:22 |
| lifeless | first things first, lets get the bugs sorted out | 01:23 |
| lifeless | find your old one | 01:23 |
| lifeless | set to in progress | 01:23 |
| lifeless | dupe the new onto the old | 01:23 |
| lifeless | the old one should have two tasks, one on lazr-js and one on launchpad,t he lazr-js one should be fix released if your change is merged into it. | 01:23 |
| lifeless | I'm moderately sure deryck finished upgrading us to the latest lazr-js recently so your fix should be easy to get to. | 01:24 |
| wgrant | Ah, sorry, that was probably my fault. I thought I set it back, though :/ | 01:25 |
| huwshimi | lifeless: The old one (bug #580404) doe not have a lazr-js task, I assume I can just add that? | 01:32 |
| _mup_ | Bug #580404: pressing enter in tags field doesn't save them <ajax> <javascript> <lp-bugs> <qa-needstesting> <Launchpad itself:In Progress by huwshimi> < https://launchpad.net/bugs/580404 > | 01:32 |
| lifeless | huwshimi: yes | 01:33 |
| lifeless | huwshimi: you made the change in lazr-js right ? | 01:33 |
| huwshimi | lifeless: ugh, sorry I'm getting random lockups with my keyboard and mouse (but I can see that the OS is still working) | 01:37 |
| huwshimi | lifeless: Yes the changes were made to lazr-js | 01:37 |
| LPCIBot | Yippie, build fixed! | 01:38 |
| LPCIBot | Project db-devel build #427: FIXED in 5 hr 14 min: https://hudson.wedontsleep.org/job/db-devel/427/ | 01:38 |
| huwshimi | lifeless: ok, I've done all that. What next? | 01:42 |
| lifeless | next, you need to figure out whats new in lazr-js leading up to the commit where your patch landed, so you can decide how much qa you want to do | 01:42 |
| lifeless | and/or whether you want to land everything or just up to your patch | 01:43 |
| lifeless | use bzr and or bazaar.launchpad.net to look at the history and decide | 01:43 |
| lifeless | pick the rev of lazr-js you want to update to | 01:43 |
| lifeless | and then we go to the actually-doing-it step | 01:43 |
| huwshimi | lifeless: ok thanks will take a look | 01:44 |
| huwshimi | lifeless: How do I know what hasn't been landed? | 01:46 |
| huwshimi | lifeless: Or rather released | 01:47 |
| lifeless | look at versions.cfg, see the version there, look at the branch for lazr-js, walk back until the release | 01:47 |
| huwshimi | lifeless: I'm not entirely sure what you mean by that, there are a lot of version numbers in that file and none seem to refer to lazr-js? I may be completely mis-understanding you | 01:51 |
| lifeless | lazr-js = 1.6DEV-r202 | 01:52 |
| wgrant | OOPS reports during release week are depressing. | 01:53 |
| lifeless | wgrant: because deploys stop ? | 01:53 |
| lifeless | https://lpstats.canonical.com/graphs/AppServerRequestLpnet | 01:53 |
| lifeless | 14:51 < huwshimi> lifeless: I'm not entirely sure what you mean by that, there are a lot of version numbers in that file and none seem to refer to lazr-js? I may be completely mis-understanding you | 01:54 |
| lifeless | 14:51 < lifeless> lazr-js = 1.6DEV-r202 | 01:54 |
| huwshimi | lifeless: Sorry crashed again | 01:54 |
| wgrant | lifeless: Yes. | 01:54 |
| huwshimi | lifeless: Ah right, you're referring to the versings.cfg in Launchpad, not the one it lazr-js :) | 01:55 |
| huwshimi | lifeless: ok, so there is one other commit since the last release | 01:56 |
| wgrant | * 1954 Exceptions | 01:57 |
| huwshimi | lifeless: The other commit does not have an attached bug, is it still possible for me to be able to qa it somehow? | 02:00 |
| lifeless | huwshimi: of course | 02:01 |
| lifeless | bugs don't permit qa, they are just about recording stuff | 02:01 |
| lifeless | huwshimi: make an assessment of the other change | 02:02 |
| huwshimi | lifeless: It's a module that's been updated (looks like a file has been replaced with a whole new version). | 02:05 |
| huwshimi | ok next time this crashes I'm giving up and going back to my old laptop | 02:17 |
| lifeless | huwshimi: what is it? | 02:17 |
| huwshimi | lifeless: the laptop? | 02:17 |
| lifeless | huwshimi: so you need to decide if its safe to include in lp as-is | 02:17 |
| lifeless | yes the laptop | 02:17 |
| huwshimi | it's a 2011 Macbook Pro. | 02:17 |
| Ursinha | lifeless, and now? | 02:18 |
| Ursinha | I forgot to change a link | 02:18 |
| Ursinha | sorry | 02:18 |
| lifeless | Ursinha: brilliant | 02:18 |
| huwshimi | ok that time it was Natty crashing. Laptop, I'm giving you one more chance | 02:20 |
| huwshimi | lifeless: from a quick grep I can't find any references to that lazr-js module. | 02:29 |
| lifeless | where ? ;) | 02:29 |
| huwshimi | lifeless: in the launchpad codebase | 02:30 |
| huwshimi | lifeless: I could be wrong though :) | 02:30 |
| lifeless | huwshimi: so if we're not using galery-form, its a no brainer | 02:32 |
| lifeless | huwshimi: I think its on the wiki somewhere, but what you need to do next is make a new sdist, put it in the lp download cache (copy it in, bzr add, bzr commit), update versions.cfg in lp and propose that as a branch to land in devel | 02:32 |
| huwshimi | lifeless: Where do we define which javascript files we include? | 02:33 |
| * thumper leaps through a few more hoops | 02:37 | |
| lifeless | huwshimi: I don't know | 02:38 |
| huwshimi | lifeless: So I'm wrong about us not including that file | 02:59 |
| lifeless | huwshimi: in which case, check that lp will still work with the new version :) | 03:02 |
| huwshimi | lifeless: And how do I do that? :) | 03:04 |
| lifeless | I'm sure you'll think of something | 03:05 |
| lifeless | e.g. how did you make sure the bug tag editing worked | 03:05 |
| huwshimi | lifeless: Well I'm trying to figure out if we actually use this module at all | 03:06 |
| lifeless | wgrant: do you remember where we set allowed attributes for built in types? | 03:17 |
| lifeless | thumper: ^ | 03:18 |
| thumper | for built in types? | 03:19 |
| thumper | like what | 03:19 |
| thumper | ? | 03:19 |
| lifeless | dict | 03:19 |
| lifeless | for instance | 03:19 |
| thumper | lifeless: hmm... | 03:19 |
| lifeless | in this case, defaultdict | 03:19 |
| thumper | no | 03:19 |
| lifeless | doesn't have __getitem__ permitted | 03:19 |
| thumper | grep is your friend :) | 03:20 |
| lifeless | and making an interface would be batshit | 03:20 |
| thumper | it'll be in a configure.zcml | 03:20 |
| huwshimi | Does anyone here know how we handle which javascript files are included in Launchpad? I've found this, but it doesn't seem to be correct: https://dev.launchpad.net/JavaScriptBuildSystem | 03:22 |
| thumper | huwshimi: what do you want to know? | 03:23 |
| thumper | I've learned some things | 03:23 |
| lifeless | lp_sitecustomize.py | 03:24 |
| huwshimi | thumper: There is a javascript file (as part of lazr-js) that is included in our launchpad.js, but I can't see where we actually include that to be built. | 03:24 |
| thumper | jsbuild is full of magic | 03:25 |
| thumper | and a PITA | 03:25 |
| thumper | make jsbuild calls out to a couple of utility scripts to determine dependancies | 03:25 |
| huwshimi | thumper: do you remember which scripts they are? | 03:27 |
| thumper | huwshimi: look in the Makefile | 03:28 |
| thumper | for the jsbuild: target | 03:28 |
| thumper | they are in backquotes | 03:28 |
| wgrant | The file list is hardcoded now, isn't it? | 03:28 |
| wgrant | In utilities/yui-deps.py | 03:30 |
| thumper | wgrant: does that include the lazr-js bits? | 03:32 |
| thumper | huwshimi: are you doing something in lazr-js? | 03:34 |
| thumper | huwshimi: I have a request | 03:34 |
| wgrant | thumper: Ah, no, just all of YUI :( | 03:35 |
| huwshimi | thumper: I'm trying to build lazr-js for Launchpad and trying to determine if we are using a module that was updated to a new version by someone else. | 03:36 |
| huwshimi | thumper: What's the request | 03:36 |
| huwshimi | ? | 03:36 |
| thumper | huwshimi: somewhere in the picker code, it is adding a   | 03:36 |
| thumper | huwshimi: it needs to die, and CSS used instead | 03:36 |
| huwshimi | thumper: I don't think I want to change anything else right now or else my brain will melt, but feel free to file a bug or something and I'll try and get to it :P | 03:39 |
| thumper | :) | 03:39 |
| thumper | ok | 03:39 |
| huwshimi | thumper: if you landed a branch quickly I could probably include this in the build. | 03:45 |
| thumper | huwshimi: ETOOMUCHTODO | 03:45 |
| huwshimi | thumper: Fair enough :) | 03:45 |
| thumper | huwshimi: I've already been on a diversion | 03:46 |
| thumper | anyone: https://code.launchpad.net/~thumper/launchpad/choice-widget/+merge/52357 | 03:49 |
| huwshimi | thumper: Those scripts don't seem to mention lazr-js stuff | 03:52 |
| huwshimi | thumper: or am I missing something? | 03:53 |
| thumper | lib/canonical/launchpad/icing/lazr/build/lazr.js | 03:54 |
| thumper | huwshimi: that is the last line of the jsbuild command in the Makefile | 03:54 |
| thumper | huwshimi: I'm guessing that you'll find that is a symlink to the location where lazr-js is built | 03:54 |
| wgrant | What's the setuptools sdist option to add a version suffix? | 03:55 |
| thumper | using the jsbuild_lazr make target | 03:55 |
| thumper | wgrant: I don't remember but I need it too | 03:55 |
| thumper | wgrant: what are you packaging? | 03:55 |
| wgrant | thumper: Updating pydkim. | 03:55 |
| * wgrant greps logs. | 03:55 | |
| thumper | not in my history sorry | 03:56 |
| wgrant | Because it's not in --help :( | 03:56 |
| wgrant | -b | 03:56 |
| huwshimi | thumper: Ah right, so we do just include the whole of lazr-js and don't control which files we include. | 03:57 |
| thumper | huwshimi: maybe... | 03:57 |
| huwshimi | thumper: Thanks for that. Now I can get on with my investigating. | 03:58 |
| wgrant | Except that the egg_info command doesn't work here :/ | 03:58 |
| wgrant | It's like setuptools isn't installed... | 04:00 |
| huwshimi | lifeless: so I think after all that we include that file but don't use it, but I can't be sure | 04:22 |
| StevenK | Does anyone want to fix the failed stable into db-devel merge? | 04:23 |
| wgrant | Not again :( | 04:23 |
| wgrant | Fixing. | 04:23 |
| StevenK | wgrant: Thanks | 04:23 |
| wgrant | This is changing one that I already resolved on Saturday :( | 04:23 |
| === MTecknology is now known as MT-TakinBreak | ||
| StevenK | wgrant: Can you have another look at https://code.launchpad.net/~stevenk/launchpad/populate-spr-changelogs/+merge/52363 ? I've addressed all of your concerns, bar IMasterStore, since everything else done by garbo uses it. | 04:36 |
| wgrant | StevenK: You renamed getCandidateSPRIDs, but it still returns SPR IDs... | 04:37 |
| wgrant | Also, why are we still restricting to Debian? | 04:38 |
| StevenK | 1. Our sampledata sucks. 2. I don't think there is any point doing it over more. | 04:39 |
| wgrant | Apart from that it looks good. | 04:39 |
| wgrant | What about all the Ubuntu publications from more than a year ago? | 04:39 |
| StevenK | wgrant: Er? It returns a ResultSet of SPRs ordered by id? | 04:39 |
| wgrant | No, it returns a ResultSet of SPR.id ordered by id. | 04:40 |
| StevenK | Bah, fixed | 04:40 |
| StevenK | wgrant: I'm happy to say upload_archiveID IN (ubuntu.main_archive.id, debian.main_archive.id) | 04:41 |
| wgrant | StevenK: Why say that at all? | 04:41 |
| StevenK | Running it over sampledata which the tests is horrid | 04:41 |
| StevenK | Er. Which the tests do | 04:41 |
| wgrant | It's easy to clean the sampledata up. | 04:42 |
| StevenK | I'd rather just delete it :-) | 04:42 |
| wgrant | Right, but deleting it in the tests is hard. | 04:42 |
| huwshimi | lifeless: What should I do with this then? I don't want to release these changes if they'll break things... | 04:42 |
| lifeless | huwshimi: will they break things? | 04:43 |
| huwshimi | lifeless: Well that's the problem, I don't know. I can't see where we're using this module, but that doesn't mean we're not using it. I could just be looking for the wrong things. | 04:44 |
| StevenK | wgrant: Personally, I'd prefer to leave it for Debian. For the derived case, we aren't going to care about the older Ubuntus | 04:45 |
| wgrant | StevenK: There is stuff in Natty that has no changelogs... | 04:45 |
| lifeless | huwshimi: check the wiki for info, failing that ask for help: mail the dev list asking for 'how to find out where a lazy-js module is used by lp' | 04:45 |
| StevenK | Really? | 04:45 |
| huwshimi | lifeless: OK thanks, will do. | 04:45 |
| wgrant | StevenK: Anything that was uploaded before we started importing changelogs not-very-long-ago. | 04:46 |
| StevenK | wgrant: The DB on DF for maverick said zero had a null changelog ... | 04:46 |
| wgrant | StevenK: With upload_distroseries=natty? Sure. | 04:47 |
| wgrant | But not much stuff in natty was uploaded to natty. | 04:47 |
| StevenK | The natty DB on DF is very little | 04:47 |
| wgrant | Even moreso there. | 04:47 |
| lifeless | StevenK: the point is the things uploaded to maverick that haven't been changed in natty | 04:47 |
| StevenK | wgrant: So, how do you propose I have the tests ignore the sampledata? | 04:48 |
| wgrant | StevenK: Expire all LFAs at the start of the test. | 04:48 |
| wgrant | The brutal approach. | 04:48 |
| StevenK | Allow me to say "Ew" | 04:48 |
| wgrant | It is better than sampledata. | 04:48 |
| * StevenK tries to work out how to do so | 04:49 | |
| wgrant | We may eventually want two template DBs, one without crap. | 04:49 |
| wgrant | Since we won't be able to drop the crapful one for a long time :( | 04:50 |
| StevenK | wgrant: I can't think of an elegant way to expire all the LFAs | 04:54 |
| wgrant | StevenK: Store.find(LibraryFileAlias).set(content=None)? | 04:55 |
| StevenK | wgrant: Having it return SPRs directly complains about the GROUP BY | 04:59 |
| wgrant | StevenK: Group by SourcePackageRelease instead. | 04:59 |
| wgrant | Hmm. | 04:59 |
| wgrant | That might be why I was grabbing IDs... grouping by all the fields may have proved slower, although that seems odd. | 05:00 |
| wgrant | Since it should be able to optimise to a pkey grouping. | 05:00 |
| lifeless | shoulda coulda woulda | 05:00 |
| lifeless | the way to do that is to use the id based query as an inner query | 05:00 |
| lifeless | like e.g. _getExternalMessages does | 05:01 |
| jtv | StevenK: can you think of any reason why gina would initialize the references in SPPHs it creates using the ids for distroseries, SPR, etc. instead of the actual model objects? | 05:17 |
| StevenK | Nope | 05:18 |
| StevenK | gina is .... special | 05:18 |
| * StevenK grumbles | 05:21 | |
| lifeless | jtv: code fragment ? | 05:21 |
| StevenK | Now it dies due to a variable used before assignment :-( | 05:21 |
| StevenK | And if I change its indent level, it loops until killed | 05:22 |
| jtv | lifeless: | 05:22 |
| jtv | entry = SourcePackagePublishingHistory( | 05:22 |
| jtv | distroseries=self.distroseries.id, | 05:22 |
| jtv | sourcepackagerelease=sourcepackagerelease.id, | 05:22 |
| jtv | status=PackagePublishingStatus.PENDING, | 05:22 |
| jtv | component=component.id, | 05:22 |
| jtv | section=section.id, | 05:22 |
| jtv | datecreated=UTC_NOW, | 05:22 |
| jtv | datepublished=UTC_NOW, | 05:22 |
| jtv | pocket=self.pocket, | 05:22 |
| jtv | archive=archive | 05:22 |
| jtv | ) | 05:22 |
| jtv | StevenK: is gina special enough to warrant that? | 05:22 |
| wgrant | I have a branch which fixes that. | 05:23 |
| lifeless | jtv: I would change it to distroseriesID=self.distroseries.id etc | 05:23 |
| StevenK | jtv: Er, things like that are the REASON why gina is special | 05:23 |
| lifeless | we shouldn't overuse Reference objects, they are fragile | 05:23 |
| jtv | Okay, but is there any justification? | 05:23 |
| wgrant | For manually instantiating it, rather than using PublishingSet.newSourcePublication? | 05:23 |
| jtv | No, for using the ids instead of the model objects. | 05:24 |
| StevenK | I suspect SPPH support was bolted on. | 05:24 |
| jtv | Because I'm trying to make it use newSourcePublication. | 05:24 |
| wgrant | https://code.launchpad.net/~wgrant/launchpad/unify-publication-creation | 05:24 |
| wgrant | One remaining issue: it doesn't set datepublished. | 05:24 |
| StevenK | Which is fine | 05:25 |
| StevenK | We don't want it to | 05:25 |
| jtv | It shouldn't even do that in the first place. | 05:25 |
| wgrant | Perhaps so, but inconsistent. | 05:25 |
| jtv | Shame that branch sat around for half a year—it's a change I need for my current work. | 05:25 |
| wgrant | jtv: I didn't want to get into the gina argument at that point. | 05:26 |
| jtv | But all in all we don't really know whether there's any particular reason to use ids there? | 05:27 |
| wgrant | There isn't one. | 05:27 |
| wgrant | If you see something odd in gina, it's because gina is crap, not because it needs to be that way. | 05:28 |
| jtv | That's nice to hear. | 05:28 |
| jtv | Brings me to the next question: newSourcePackagingPublication creates a new DSP if one does not exist—which is breaking gina tests. | 05:29 |
| wgrant | I added a permission in that branch. | 05:29 |
| wgrant | I think it's the right thing to do. | 05:30 |
| jtv | I was wondering if maybe it was just laziness of the test, and there should always be a DSP | 05:30 |
| wgrant | gina predates DSP. | 05:30 |
| wgrant | There's no problem with creating one. | 05:30 |
| StevenK | wgrant: Why didn't you want to get into a gina argument? | 05:31 |
| wgrant | StevenK: Because nobody knows whether we want to stop setting datepublished or start creating them Published or burn gina to death. | 05:31 |
| lifeless | whats gina used for? | 05:32 |
| StevenK | Julian said yesterday we want to stop setting datepublished | 05:32 |
| wgrant | OK, how does _'s string interpolation work? | 05:32 |
| StevenK | lifeless: It imports Debian | 05:32 |
| wgrant | lifeless: Importing Debianish archives into the DB and librarian. | 05:32 |
| jtv | And so the datepublished=UTC_NOW is completely bogus | 05:32 |
| wgrant | jtv: It is a lie, and not one with considerable utility. | 05:33 |
| wgrant | Kill it. | 05:33 |
| jtv | I had already done that. | 05:33 |
| StevenK | wgrant: http://pastebin.ubuntu.com/577330/ makes me sad | 05:33 |
| wgrant | StevenK: Oh? | 05:34 |
| wgrant | It makes me happy. | 05:34 |
| StevenK | http://pastebin.ubuntu.com/577331/ | 05:34 |
| wgrant | StevenK: Which line does it fail on? | 05:35 |
| StevenK | self.start_at = spr.id + 1 | 05:36 |
| wgrant | Ah, that's not a new issue. | 05:36 |
| wgrant | It'll happen whenever there are no SPRs to process. | 05:37 |
| StevenK | :-( | 05:38 |
| lifeless | 200 tasks -> 10 second renders :( | 05:50 |
| wgrant | lifeless: But it at least renders now? | 05:51 |
| lifeless | thats on my laptop | 05:51 |
| wgrant | Ah. | 05:51 |
| lifeless | which is an i7 | 05:51 |
| wgrant | Ow. | 05:51 |
| lifeless | 50ms per bugtask hmm | 05:53 |
| === almaisan-away is now known as al-maisan | ||
| wgrant | lifeless: Is wampee running with the second new set of appservers? | 05:58 |
| lifeless | wgrant: yes | 06:00 |
| wgrant | Excellent. | 06:00 |
| jtv | wgrant, want to review my branch? https://code.launchpad.net/~jtv/launchpad/bug-730460-use-spph-factory/+merge/52515 | 06:05 |
| wgrant | jtv: Gladly. | 06:05 |
| jtv | Thanks. | 06:05 |
| jtv | wgrant: I split off the factory part to free me up for the real work, so there's not much there. | 06:10 |
| wgrant | lifeless: Could you mentor that? | 06:11 |
| === al-maisan is now known as almaisan-away | ||
| jtv | I'll go grab some food. | 06:21 |
| === jtv is now known as jtv-eat | ||
| wgrant | lifeless: What would you recommend as a Python testrunner these days? I normally use nose, but you probably have better ideas. | 08:09 |
| === almaisan-away is now known as al-maisan | ||
| lifeless | wgrant: testr with subunit.run as the core | 08:18 |
| wgrant | lifeless: subunit.run doesn't do test discovery, does it? | 08:20 |
| lifeless | wgrant: it does if you have python 2.7 or the discovery module installed | 08:20 |
| wgrant | Ah, handy! | 08:21 |
| wgrant | Thanks. | 08:21 |
| adeuring | good morning | 08:35 |
| StevenK | wgrant: So, that script doesn't love me. | 08:52 |
| wgrant | StevenK: Oh? | 08:59 |
| StevenK | FeatureError: Single aggregates aren't supported after a GROUP BY clause | 08:59 |
| wgrant | bigjools: What do you think about replacing cron.daily-ppa with DiskPool improvements? | 09:00 |
| StevenK | wgrant: I think we're going to have to shift back to ids ... | 09:00 |
| lifeless | wgrant: see the oops-repository .testr.conf for inspiration | 09:00 |
| wgrant | StevenK: Yeah, probably. | 09:00 |
| lifeless | or | 09:00 |
| lifeless | wrap the result as I suggested | 09:00 |
| StevenK | wgrant: Will you rescind your issue with it if I do that? | 09:00 |
| lifeless | see _getExternalthingy in translations for an example | 09:01 |
| wgrant | StevenK: Maybe. | 09:01 |
| wgrant | lifeless: No lp:oops-repository? | 09:01 |
| lifeless | wgrant: https://code.launchpad.net/oops-repository | 09:03 |
| bigjools | wgrant: sounds reasonable as long as it doesn't slow down the publisher | 09:03 |
| lifeless | wgrant: I haven't setup a 'trunk' yet, nor all the metadata | 09:03 |
| bigjools | figure out where empty dirs are left | 09:03 |
| wgrant | bigjools: The file removal method will just check if the directory it's removing from is empty. | 09:04 |
| wgrant | So it will slow p-d-r insignificantly. | 09:05 |
| bigjools | poifekt | 09:06 |
| bigjools | lifeless/stub: can you guys look at my MP with schema changes please? | 09:20 |
| lifeless | bigjools: I'll look in the morning - brain is hurting ;) | 09:23 |
| lifeless | bigjools: I've just enough energy left to send a perf tuesday mail :) | 09:23 |
| bigjools | lifeless: it is the morning :) ok, no prob | 09:24 |
| lifeless | morning schmorning | 09:24 |
| StevenK | wgrant: :-( | 09:25 |
| jml | hmm | 09:36 |
| stub | When do we merge db-devel -> devel? I've got a futzed merge proposal up (it will land on devel, but contains stuff currently only in db-devel) | 09:47 |
| stub | bigjools: I'll look now | 09:47 |
| bigjools | c=heers | 09:48 |
| bigjools | cheers, even | 09:48 |
| stub | bigjools: you targetted to devel, not db-devel | 09:50 |
| bigjools | FFS, I didn't, but bzr send did :/ | 09:50 |
| bigjools | grar | 09:50 |
| lifeless | stub: anytime prior to the pqm freeze | 09:51 |
| lifeless | stub: so anytime in the next 4 weeks | 09:51 |
| stub | bigjools: point me to an updated mp when you have one. its r=stub, patch-2208-52-0.sql | 09:53 |
| === Ursinha is now known as Ursinha-afk | ||
| stub | I think that is anytime prior to reopening db-devel for landings, innit? | 09:54 |
| bigjools | stub: ta | 09:55 |
| lifeless | stub: db-devel is open | 09:55 |
| lifeless | stub: we had the freeze for this month already | 09:55 |
| stub | There are changes on that branch that landed before the freeze that are not in devel | 09:55 |
| lifeless | stub: we merged everything from db-stable | 09:56 |
| stub | hmm | 09:56 |
| lifeless | night y'all | 10:00 |
| bigjools | nn lifeless | 10:00 |
| stub | I can't see a db-devel or db-stable merge since feb | 10:03 |
| bigjools | stub: when it scans: https://code.launchpad.net/~julian-edwards/launchpad/publisher-config-db-schema/+merge/52530 | 10:03 |
| stub | oic it | 10:03 |
| stub | nfi how my stuff missed going across - it landed on Friday | 10:04 |
| stub | I even got poked to qa it | 10:05 |
| stub | Mine can wait, but if an earlier revision got merged we might be missing something important. | 10:06 |
| wgrant | stub: We merged the rev right before yours. | 10:08 |
| wgrant | stub: Yours was un-QA'd at the time. | 10:09 |
| stub | ok | 10:09 |
| wgrant | We were already very much out of LOSA time, so we didn't want to push it. | 10:09 |
| wgrant | We could almost sensibly merge again, though... | 10:10 |
| stub | there is no particular reason to land it this cycle. | 10:12 |
| wgrant | There is. | 10:12 |
| wgrant | The spam from the old one is irritating! | 10:13 |
| === al-maisan is now known as almaisan-away | ||
| === almaisan-away is now known as al-maisan | ||
| === vila is now known as vila-afk-lunch | ||
| === al-maisan is now known as almaisan-away | ||
| === henninge_ is now known as henninge | ||
| === henninge is now known as henninge-lunch | ||
| === almaisan-away is now known as al-maisan | ||
| === vila-afk-lunch is now known as vila | ||
| jam | can somebody land https://code.launchpad.net/~jameinel/launchpad/use_loggerhead_trunk/+merge/52062 | 12:11 |
| jam | At least, lifeless said on IRC, "Just land the branch" because loggerhead's pqm didn't actually run the test suite | 12:11 |
| jam | so we didn't bother setting it up again yet | 12:11 |
| jml | jam: sure thing. | 12:14 |
| jml | jam: will let you know when the EC2 instance has detached. | 12:14 |
| jam | jml: thanks | 12:15 |
| jml | hmm. looking at the diff, I'll skip EC2 | 12:16 |
| jml | ffs. | 12:16 |
| jml | lp-land requires a local checkout | 12:16 |
| jam | jml: it is pretty simple :) | 12:16 |
| jml | jam: it's in PQM now. | 12:18 |
| jam | jml: thanks | 12:18 |
| bigjools | this whole Storm Unicode vs RawStr thing is driving me potty | 12:37 |
| jml | what about it? | 12:39 |
| bigjools | I can't throw str at unicode and expect it to work | 12:39 |
| jml | jam: "81 queries/external actions issued in 10.73 seconds" -- I want to debug your problem instead of answering email :\ | 12:40 |
| bigjools | if I try and use RawStr and str() everywhere, somehow unicode gets in.... | 12:40 |
| jml | bigjools: the first thing you said is basically the whole point. A str doesn't have any encoding information, so it can't be used to represent human-readable text. | 12:42 |
| bigjools | but it can ... | 12:42 |
| jam | jml: this is http://pad.lv/OOPS-1893C1040 ? | 12:43 |
| jml | no, it's just bytes. a_str.decode('utf8') is something that might represent human-readable text | 12:43 |
| jml | jam: yes. | 12:44 |
| bigjools | I would not mind if this was consistent everywhere, but it's not | 12:45 |
| jml | bigjools: can you give an example of where it's not? | 12:46 |
| jml | (Python is lousy at this, but Storm is pretty good) | 12:47 |
| jml | le sigh | 12:47 |
| bigjools | jml: I defined a text column in PG, the storm model was RawStr, and I poked in some data from a form with an explicit str() case. When Storm reads it back, it blows up with a unicode error. | 12:48 |
| bigjools | I'm reverting it all back to unicode now | 12:48 |
| jam | benji: since you approved https://code.launchpad.net/~jameinel/launchpad/suppress-generator-exit-726985/+merge/52414 | 12:49 |
| jam | can you ec2land it? | 12:49 |
| jam | Or does it need a second review because you didn't mark it overall approved. | 12:49 |
| jam | jml: I'd be happy for you to fix it :0 | 12:49 |
| jam | It isn't a page I go to often | 12:50 |
| jml | jam: I'll be lucky to have caught up on my email by the end of the day. | 12:50 |
| jam | so not something that is blocking me. But a bit surprising to have it take 14s to load a code overview | 12:50 |
| benji | jam: it doesn't need more approval unless you think it does | 12:51 |
| jam | benji: fine with me. I don't think it is very controversial | 12:52 |
| jam | wgrant might want to look at it. Since he asked me to write it. but it was up there for him yesterday :) | 12:52 |
| benji | I guess can land it for you if you need. | 12:52 |
| === al-maisan is now known as almaisan-away | ||
| jam | benji: well, if you think it needs ec2land, I would appreciate it. Since I'm not an lp dev, I don't have an ec2 account, etc. | 12:54 |
| === almaisan-away is now known as al-maisan | ||
| benji | ah, gotcha; sure I'll do it for you | 12:54 |
| wgrant | jam: Looks great. | 12:55 |
| wgrant | benji: Thanks. | 12:55 |
| jam | wgrant: what time is it there? | 12:55 |
| wgrant | jam: Not quite midnight. | 12:55 |
| jam | ah, k | 12:55 |
| jam | wasn't sure if it was late enough to be considered "early" yet | 12:56 |
| wgrant | Heh, no. | 12:57 |
| === henninge-lunch is now known as henninge | ||
| gary_poster | losas, is there a way for me to check how long the current staging update has taken without bothering you? | 14:17 |
| benji | gary_poster: I think devpad.canonical.com:/srv/launchpad.net-logs/staging/sourcherry/2011-03-08-staging_restore.log holds the answer, but I'm not entirely sure how to read it | 14:20 |
| gary_poster | benji, cool, thanks, looking | 14:20 |
| jcsackett | sinzui: if a project is marked as inactive, that still doesn't free up the name for another project to use, does it? | 14:22 |
| gary_poster | benji, losas, AFAICT staging started Tue Mar 8 04:14:09 UTC 2011 and ran without errors, and yet 10 hours later we still have no staging. :-( (I synced the logs just to make sure I wasn't missing anything) | 14:32 |
| gary_poster | benji, just sharing with you in case you were curious :-) | 14:33 |
| Chex_ | gary_poster: let me take a look | 14:33 |
| gary_poster | thank you Chex_ | 14:33 |
| benji | I am. | 14:33 |
| Chex_ | gary_poster: ok, appears we had a postgres/slony failure, getting you a pastebin | 14:37 |
| gary_poster | thanks Chex_. Did I just miss it in that log benji mentioned above, or was it somewhere else? | 14:38 |
| Chex_ | gary_poster: yes, it fools me often as well, the slony error happens before the end of the process, see here for where it was in the logfile: https://pastebin.canonical.com/44394/ | 14:39 |
| * Chex_ looks at his nick, and frowns | 14:39 | |
| gary_poster | ah! ok, sorry Chex_, will be more careful next time | 14:40 |
| === Chex_ is now known as Chex | ||
| gary_poster | I guess I'll go look at the server log, because I have no idea how to remiedaiate that so far | 14:41 |
| gary_poster | jcsackett, I think you were talking to an absent sinzui before, and he is now present | 14:41 |
| * leonardr also wishes to talk to a present sinzui | 14:42 | |
| jcsackett | ah, thanks gary_poster. | 14:42 |
| gary_poster | :-) | 14:42 |
| jcsackett | sinzui: if a project is marked as inactive, that still doesn't free up the name for another project to use, does it? | 14:42 |
| sinzui | I did not know I was offline. | 14:42 |
| sinzui | Not at all | 14:42 |
| jcsackett | sinzui: clearly, neither did i. :-P | 14:42 |
| sinzui | We rename them on request, or we give the old project to the user | 14:43 |
| jcsackett | ah, okay. i am looking at https://answers.launchpad.net/launchpad/+question/148314 | 14:43 |
| jcsackett | global does look like it's not doing anything. but as project-reviewing-overlord, perhaps you would like to weigh in, sinzui? | 14:45 |
| sinzui | just rename the old project to global-old | 14:46 |
| gary_poster | stub, you around by chance? | 14:46 |
| gary_poster | I'd like to know if there's any remediation you can suggest for https://pastebin.canonical.com/44394/ which is causing staging to be down | 14:47 |
| sinzui | jcsackett: this issue relates to bug 106501 | 14:48 |
| _mup_ | Bug #106501: Automatically warn about, then delete, unused projects <chr> <lp-registry> <projects> <Launchpad itself:Triaged> < https://launchpad.net/bugs/106501 > | 14:48 |
| jcsackett | sinzui: i concur. | 14:48 |
| jcsackett | that process would be nice. | 14:49 |
| jcsackett | so, you think we can offer to make the person the head of global, sinzui? | 14:51 |
| sinzui | jcsackett: just rename the old one. | 14:52 |
| jcsackett | sinzui: cool. | 14:52 |
| sinzui | jcsackett: we really do not think about it. we just get the trash out of the way | 14:53 |
| jcsackett | sinzui: sounds good. | 14:53 |
| leonardr | sinzui, when will you have time to revisit my sampledata problem? | 14:54 |
| sinzui | leonardr: about 45 minutes? | 14:54 |
| leonardr | sinzui, cool | 14:54 |
| rvba | sinzui: Hi ... I've been tasked with bug 727632 and I wonder if you could give me hints on how you think it should look in the UI as I'm still fairly new to the UI (or the code for that matter). I just sent you an email with a few details and a mockup. | 15:15 |
| _mup_ | Bug #727632: distro and distro series pages do not specify their owner <derivation> <distributions> <series> <Launchpad itself:Triaged by rvb> < https://launchpad.net/bugs/727632 > | 15:15 |
| sinzui | Do they have an owner? | 15:16 |
| sinzui | No they do not | 15:16 |
| sinzui | distros and series have registrants. | 15:16 |
| sinzui | The owner is always the project maintainer | 15:17 |
| === Ursinha-afk is now known as Ursinha | ||
| sinzui | rvba you can cargo cult the "registering" slot from a lp/registry/templates/product-index.pt into the distro and series pages. The tales need to pull the series/owner field, but the wording will be "Registered by" | 15:19 |
| rvba | sinzui: isn't this what's currently displayed already? | 15:20 |
| sinzui | rvba: oh. I think soo | 15:20 |
| sinzui | so | 15:20 |
| sinzui | rvba, is the real issue that we do not have this data in the schema | 15:20 |
| rvba | I confess I'm not sure if the issue is only in the UI or in the data. I though it was only a UI bug. | 15:21 |
| sinzui | rvba, poolie is confused in this bug | 15:21 |
| sinzui | we do not have "owners" of these objects, They must be like projects and project series | 15:22 |
| * sinzui looks at the schema | 15:22 | |
| sinzui | rvba. These pages look like the project and series pages. They are correct! I think the issue may be that the schema does not provide the the information, so it is pulled from a surprising field. | 15:23 |
| rvba | sinzui: maybe I'll just correct the wording "Registered" instead of "registered" and ask poolie more details about this then ...? | 15:25 |
| sinzui | rvba distro is missing the registrant field! we are showing the maintainer as the registrant. This is a lie. *All* distros and distros series were registered by a losa, most by mthaddon actually | 15:26 |
| rvba | sinzui: ok I get it. So the information is wrong then. | 15:27 |
| sinzui | rvba: distro has a owner field, but it is actually the registrant. The owner is always the distro maintainer (owner). | 15:27 |
| sinzui | oops | 15:27 |
| sinzui | disrgard that | 15:28 |
| sinzui | *distroseries* has a owner field, but it is actually the registrant. The owner is always the distro maintainer (owner). | 15:28 |
| rvba | so if we want to display the owner field I just have to pull that info from the corresponding distro (for series) | 15:29 |
| sinzui | rvba: so this bug is about 1, the distro does not know who the registrant is. 2, distroseries stores the registrant in the owner field. | 15:29 |
| sinzui | rvba: Many object store the registrant in the owner field because the PrimaryContext (project or distro) always owns them | 15:30 |
| * sinzui looks for bug | 15:30 | |
| * rvba looks into the datastructure | 15:30 | |
| sinzui | excellent. I find duplicate bugs | 15:33 |
| sinzui | rvba: This issue overlaps with bug 153333, bug 188402, bug 207532 | 15:34 |
| _mup_ | Bug #153333: Clean up owner and registrant attributes <feature> <lp-registry> <registry> <tech-debt> <Launchpad itself:Triaged> < https://launchpad.net/bugs/153333 > | 15:34 |
| _mup_ | Bug #188402: Include registrant on people page <feature> <lp-blueprints> <Launchpad itself:Triaged> < https://launchpad.net/bugs/188402 > | 15:34 |
| _mup_ | Bug #207532: Product, Project and Series don't have read-only registrant <lp-registry> <tech-debt> <Launchpad itself:Triaged> < https://launchpad.net/bugs/207532 > | 15:34 |
| rvba | sinzui: this is much more involved than I anticipated :-) | 15:36 |
| sinzui | rvba: you do not need to fix everything. those bugs provide context by what we mean by registrant and owner in the schema | 15:37 |
| sinzui | rvba: I updated your bug about what is wrong with distro and distroseries | 15:37 |
| rvba | sinzui: all right, I'll focus on fixing this problem for series and distro series | 15:38 |
| rvba | but still, since registrant and owner are two different things (?) the UI will have to evolve to present the 2 informations right? | 15:38 |
| sinzui | There is one caveat. both distro and distroseries implement IHasOwner, which means they must have an owner field, but in the case of distro we mean maintain, and in the case of distroseries, we mean registrant | 15:40 |
| sinzui | We either change the interface / implementation of these objects, or we continue to ignore them. | 15:40 |
| rvba | sinzui: don't you think that changing the interface / implem should be part of the larger refactoring you were just talking about | 15:43 |
| === al-maisan is now known as almaisan-away | ||
| sinzui | rvba: we could remove the registrant field from distros so we stop lying. We could stop there. As pointed out in the other bugs. registrant should be immutable. Since distros series do not have a direct owner, it seemed okay in the past to reuse the field for registrant. but owner is intended to be mutable. It is not possible BTW to change a series owner. We removed the field from edit forms | 15:46 |
| rvba | sinzui: thanks for the clarification | 15:48 |
| rvba | sinzui: I guess I'll fix the interface for now since we (red team) are in feature mode. | 15:49 |
| sinzui | rvba: this could get tricky. set a limit of a few hours for each task and if you do not make progress on the task, shout for help. you are in 6 years of muddled code and It is easy to loose scope | 15:51 |
| rvba | if I understand correctly to fix it properly we would have to create proper interfaces like IHasRegistrant and refactor quite some code ... plus the data migration. | 15:51 |
| deryck | gmb, ping. you got a sec? | 15:52 |
| sinzui | rvba: I think that increases scope. I am sure you do not want to retrofit that into all the objects. | 15:55 |
| rvba | sinzui: you're saying I should focus on distributions and distroseries? | 15:56 |
| sinzui | rvba: maybe we want to make add registrant to distroseries and make the property always return the owner. We can export owner as registrant. | 15:56 |
| rvba | sinzui: so no data migration if I understand you suggestion | 15:57 |
| rvba | s/you/your/g | 15:57 |
| sinzui | rvba: yes the issue is about making the ui clear. You need to add a registrant field to distro. that is a schema..ui change. I do not think we can migrate the data, it is all lies. We usually state the object was registered by ~registy in this case. | 15:58 |
| sinzui | rvba: I think these are two bugs, because you need two branches to fix the different needs of each object and page | 15:59 |
| gmb | deryck: Sure. | 15:59 |
| deryck | gmb, so I retriaged bug 605923 at leonardr's request. It's the missing archived debian bug bugwatch issue again. | 16:00 |
| _mup_ | Bug #605923: bug watches for archived debian bug reports appear not to exist <bugwatch> <lp-bugs> <Launchpad itself:Triaged> < https://launchpad.net/bugs/605923 > | 16:00 |
| gmb | Ugh | 16:00 |
| deryck | gmb, I was wondering if you could take a look at the bug and just brain dump some info there, for anyone wanting to look into fixing it? | 16:00 |
| gmb | deryck: Sure. I'll take a look at it in a little bit. | 16:01 |
| deryck | gmb, many thanks! | 16:01 |
| gmb | np | 16:01 |
| rvba | sinzui: so you want to add a registrant field to the distro but still populate the owner field? | 16:01 |
| sinzui | rvba: add registrant to distro, the migration script will set the value to ~regisrty | 16:01 |
| rvba | sinzui: I'm not sure I understand the delimitation of the "2 bugs" properly | 16:02 |
| sinzui | rvba: most distros were registered by kiko, most distroseries where registered by mthaddon. both cases they were admins, they were not involved in the project and no one should contact them about them | 16:03 |
| sinzui | rvba: 1. distro need a registrant field. the page needs to use the registrant field in the registering slot. the migration script will set all existing distro registrants to ~registry | 16:04 |
| sinzui | rvba: 2. distroseries registrant field is the owner, we have choices: a) rename the field field to registrant, b) add a registrant property that always returns the owner, update the interface to export the owner as registrant. | 16:06 |
| rvba | sinzui: all right ... this seems to be good bug to deep further into the code | 16:07 |
| rvba | sinzui: unless you think you need to give me more information I think I'll dive in and come back with question when I'll be stuck | 16:08 |
| sinzui | rvba: happy hacking. | 16:08 |
| rvba | sinzui: s/question/questions/g | 16:08 |
| rvba | sinzui: thx a lot | 16:09 |
| deryck | henninge, looking at your MP.... should TranslationSharingDetailsMixin also raise NotImplementedError for is_sharing and can_edit_sharing_details? | 16:12 |
| deryck | henninge, so the API is clear? | 16:12 |
| henninge | deryck: Yes, I think that makes sense. I thought about it, too, but I don't know why I discarded the thought. | 16:13 |
| deryck | henninge, ok, cool. | 16:13 |
| deryck | henninge, ok, looks good to me otherwise. I'm not sure I see the value in both the page test and the browser unit test. they seem very similar.... | 16:33 |
| deryck | henninge, but I guess there is already too much there and it needs updating. | 16:34 |
| henninge | deryck: The browser unit test never checks the actual URL, but the page test does. | 16:34 |
| deryck | henninge, what value is there in the URL? Just that hitting the URL produces the page we expect? | 16:35 |
| henninge | The link is still dead at this point, so it's just showing that it is pointing to the right place. | 16:36 |
| deryck | henninge, sure, that's fine. Seems like a lot of page test for this. but no worries. it's your call. | 16:37 |
| sinzui | hi leonardr: I think I have my head clear and can help. I recall we were looking a test failures that I thought were really because the test was not setup right; sample data is wrong | 16:37 |
| deryck | henninge, so r=me, with the tiny change mentioned above. | 16:37 |
| leonardr | sinzui: right | 16:38 |
| henninge | deryck: thanks a lot ;-) | 16:38 |
| deryck | np | 16:38 |
| leonardr | sinzui: my code is at lp:~leonardr/launchpad/bug-106338 | 16:38 |
| leonardr | the failure is in patches-view.txt | 16:40 |
| sinzui | leonardr: I saw many tests fail last year when we added code that checked that the package was legit. I fixed them by ensuring they were published in Ubuntu: | 16:41 |
| sinzui | self.factory.makeSourcePackagePublishingHistory( | 16:41 |
| sinzui | sourcepackagename='alsa-utils', distroseries=distroseries) | 16:41 |
| leonardr | i think that could solve the 'a52dec is not in ubuntu' error | 16:42 |
| === jtv is now known as jtv-zzz | ||
| leonardr | do you think it makes sense to go through patches-view and get it to stop using sampledata? | 16:42 |
| sinzui | this test sucks | 16:43 |
| sinzui | I want to delete the test and declare victory | 16:43 |
| leonardr | the whole thing? do we have coverage elsewhere? | 16:44 |
| sinzui | I doubt there is proper test coverage | 16:44 |
| sinzui | where is the failure in this test? | 16:45 |
| * sinzui runs | 16:45 | |
| sinzui | it | 16:45 |
| leonardr | sinzui: there are some problems creating the data in the first place, and then there are problems where the new validation code i added says there are problems with which bugs are conjoined to other bugs | 16:47 |
| sinzui | this test could use the factory instead | 16:47 |
| sinzui | leonardr: is evolution and a52dec the problems? I think there are missing SPPH in hoary in sample data. We can use the factory to make them genuine ubuntu packages | 16:49 |
| leonardr | ok, i'm going to write some code that might or might not work | 16:49 |
| sinzui | leonardr: pause | 16:49 |
| leonardr | k | 16:50 |
| sinzui | I just got this built. I will play the test and try a trick with the factory and transaction.commit() to put the packages in the right state. Feel free to look at something else or get some tea | 16:50 |
| leonardr | ok, i'm working on another project as well | 16:52 |
| sinzui | excellent, someone solved this in a story before | 16:52 |
| sinzui | leonardr: sorry. I had make schema. I think I have this fixed. Looks like I fixed the same problem in a bug story last year | 17:03 |
| leonardr | that's great | 17:04 |
| m4n1sh | in https://launchpad.net/+apidoc/1.0.html#person the field hide_email_addresses | 17:05 |
| m4n1sh | "hide_email_addresses" | 17:05 |
| m4n1sh | what should it be set? | 17:05 |
| m4n1sh | true/false?\ | 17:05 |
| leonardr | m4n1sh: yes | 17:09 |
| m4n1sh | leonardr: can it be reflected in the WADL? | 17:10 |
| m4n1sh | WADL file | 17:10 |
| sinzui | unity is a memory hog | 17:11 |
| leonardr | yes, we could set type="xsd:boolean" as we have for dates | 17:11 |
| sinzui | and I think it leaks like a sieve. | 17:11 |
| m4n1sh | sinzui: it has a great ALPHA plastered all over | 17:12 |
| m4n1sh | leonardr: under which project should I file a bug for this? | 17:12 |
| m4n1sh | foundations? | 17:12 |
| leonardr | m4n1sh: put it in lazr.restful | 17:13 |
| m4n1sh | thanks | 17:13 |
| sinzui | leonardr: I need to reboot to reclaim 1.5G of memory to run the test suite: This is what I did and It think it will fix the issue: http://pastebin.ubuntu.com/577529/ | 17:14 |
| leonardr | sinzui, thanks | 17:14 |
| === deryck is now known as deryck[lunch] | ||
| leonardr | sinzui: ok, that got rid of the sampledata problem. i still have the problem that the validation is preventing bugtasks from being created | 17:27 |
| leonardr | make_bugtask(bug=bug_a, target='hoary', target_is_distroseries_name=True) | 17:28 |
| leonardr | => | 17:28 |
| leonardr | LaunchpadValidationError: This bug is already on Ubuntu. Please specify an affected package in which the bug has not yet been reported. | 17:28 |
| sinzui | leonardr: are we certain that these bugs are unique? They may not given this is a story test | 17:29 |
| leonardr | sinzui: well, the bugs are created within the test | 17:31 |
| leonardr | so any bug tasks for that bug only exist within the test | 17:31 |
| sinzui | yes, but since the test does note setup isolation from the blocks in each narrative, it is easy to step on something | 17:31 |
| leonardr | sinzui: looking at the calls to make_bugtask, for bug_a we have a task on the 'trunk product series of patchy, | 17:33 |
| leonardr | the evolution source package (of what?) | 17:33 |
| leonardr | the a52dec source package (of what?) | 17:33 |
| leonardr | and then we try to create one on hoary | 17:33 |
| leonardr | could the source-package ones be interfering with the attempt to create a generic hoary bugtask? | 17:36 |
| sinzui | leonardr: possibly. If the validator looked at distroseries before source package | 17:38 |
| sinzui | leonardr: the calls to create SPPH were in hoary. I assume that we are working hoary in the test because it is the current series in sample data | 17:40 |
| leonardr | sinzui: here's the validate code | 17:41 |
| leonardr | target = None | 17:41 |
| leonardr | if distribution is not None: | 17:41 |
| leonardr | validate_new_distrotask(bug, distribution, sourcepackagename) | 17:41 |
| leonardr | elif sourcepackagename is not None: | 17:41 |
| leonardr | target = distroseries.getSourcePackage(sourcepackagename) | 17:41 |
| leonardr | else: | 17:41 |
| leonardr | target = product or productseries | 17:41 |
| leonardr | if target is not None: | 17:41 |
| leonardr | valid_upstreamtask(bug, target) | 17:41 |
| leonardr | that was the best i could figure out when to call validate_new_distrotask/validate_distrotask/valid_upstreamtasks | 17:41 |
| leonardr | you think source package name should take precedence over distribution? | 17:41 |
| sinzui | yes I do | 17:41 |
| sinzui | I think the rules are package before series before primary context | 17:43 |
| leonardr | ok, trying that now | 17:44 |
| leonardr | sinzui: 'series before primary content' -> product or productseries should come before distribution? | 17:44 |
| sinzui | I think it is distro before project. project and distribution are primary context...that is to say they are pillars, they are the first item we traverse | 17:50 |
| leonardr | sinzui: i gotta tell you that everything you say on this topic goes off on a 45 degree angle from me understanding it | 17:53 |
| sinzui | leonardr: bugtasks and conjoined bugs, packages and publishing history are arcane stuff. If the test were good, this would not be a morass. | 17:55 |
| sinzui | leonardr: I write something that I think is the correct test, then delete everything that contradicts it. | 17:56 |
| leonardr | sinzui: but i have no idea how this works. i'm just trying to make an error give a 400 status code when it happens | 17:56 |
| leonardr | let's see what happens now... | 17:57 |
| sinzui | leonardr: :( this is why these bugs are so old. fixing it means making our applicate make sense | 17:57 |
| leonardr | sinzui: revising the check to my understanding of the precedence doesn't affect the error | 17:58 |
| leonardr | i'll paste | 17:58 |
| sinzui | hmm, well maybe we do not need the sourcepackage check. does validate_new_distrotask already do that? | 18:00 |
| leonardr | sinzui: i think it does. can we call validate_new_distrotask on a distro series or can it only be a distribution? | 18:01 |
| leonardr | i think it can only be a distribution | 18:02 |
| leonardr | so, if we're passed in a distro series, we still need the sourcepackage check | 18:02 |
| === MT-TakinBreak is now known as MTecknology | ||
| sinzui | okay | 18:03 |
| leonardr | sinzui: http://pastebin.ubuntu.com/577553/ | 18:12 |
| leonardr | i've spelled out the precedence in such explicit detail that i now understand it, and i'm still getting the error | 18:12 |
| leonardr | does that code look right? | 18:12 |
| sinzui | leonardr: It looks right, but it makes me weep. | 18:15 |
| === deryck[lunch] is now known as deryck | ||
| sinzui | validate_new_distrotask is called twice I know a distroseries is never upstream, yet we validate it with upstream. I think something stinks below your method. I would not ask you to fix it just yet given the difficulties we are having in the branch too | 18:17 |
| sinzui | ^ leonardr if your branch starts passing tests now, lets report a bug about this insanity and let it block the value your branch already provides | 18:17 |
| leonardr | sinzui: tests are still not passing | 18:18 |
| leonardr | validate_new_distrotask is raising the exception | 18:18 |
| sinzui | leonardr: doh, I do *not* want to block your branch from landing. I prefer to report a bug about the issue and say we are done | 18:18 |
| leonardr | am i calling it when i should not be? | 18:18 |
| sinzui | leonardr: maybe. | 18:19 |
| leonardr | sinzui: ok, i understand what's happening | 18:23 |
| leonardr | this code prohibits you from adding a bugtask to the 'ubuntu' distribution if there is already a bugtask in ubuntu's 'evolution' sourcepackage | 18:24 |
| leonardr | is that the correct behavior? | 18:24 |
| sinzui | I am thinking | 18:24 |
| sinzui | leonardr: I want to say no, but if I were more involved in Ubuntu, I think I would say this is sensible. A bug is Ubuntu is generic. the bug must really be in a package. We know many users cannot guess the correct package. We move the bug to the package during triage... | 18:26 |
| sinzui | but I still believe I could have a task that is definitely not in the package specified, and I do not know where it is | 18:27 |
| * sinzui plays on staging | 18:27 | |
| leonardr | sinzui: i do not want this branch to change the behavior | 18:27 |
| sinzui | staging I hate you. May a pox befall your first born | 18:27 |
| leonardr | no, the first born is production | 18:28 |
| sinzui | leonardr: the validator is correct. We do not want a generic bug when we have a bug that is specific. The test needs to be buried alive, then dug back up and shot | 18:29 |
| m4n1sh | done filing the bug https://bugs.launchpad.net/lazr.restful/+bug/731518 | 18:30 |
| _mup_ | Bug #731518: Set hide_email_addresses in person of type xsd:boolean <lazr.restful:New> < https://launchpad.net/bugs/731518 > | 18:30 |
| m4n1sh | anyone can have a look at it | 18:30 |
| * sinzui looks at what could be deleted | 18:30 | |
| sinzui | leonardr: If I find that one template/view is governing all the layout in this test, I will start chopping | 18:33 |
| leonardr | sinzui: ok, let me push my revisions | 18:33 |
| sinzui | leonardr: there is one view and one template. This test is repetitive nonsense. It works on bugtarget. We do not care about each bugtarget, neither does the user according the the bad narrative in the so-called story. We can delete from the second header to the end of the test. "Patches View by Distro" onward is redundant with product. | 18:40 |
| leonardr | m4n1sh, the quickest way to get that into lazr.restful would be if you gave me a branch. you just need to add binary support to WadlFieldAPI.type, and copy some tests from what we do to test xsd:datetime | 18:41 |
| sinzui | leonardr: the story should be about "a bug target, such as a project" | 18:41 |
| leonardr | ok... | 18:42 |
| m4n1sh | leonardr: will do in meanwhile when I get time | 18:42 |
| leonardr | sinzui: ok, do i have r=you on the changes i've already pushed + destroying the rest of that test? | 18:44 |
| * sinzui looks one more time | 18:44 | |
| * leonardr has now pushed everything | 18:45 | |
| sinzui | leonardr: r=me with the fixing of the two issue I think I see in the diff: http://pastebin.ubuntu.com/577568/ | 18:52 |
| sinzui | I seem to have traded a memory leak for a runaway proc. ubuntuone ate 66% of my battery in one hour. | 18:52 |
| * sinzui restarts to kill procs | 18:59 | |
| leonardr | ok, bombs away | 19:01 |
| jml | gary_poster, benji: help requested re https://code.launchpad.net/~jml/launchpad/what-is-in-the-web-ui/+merge/52594 (any other zope experts or interested punters welcome too) | 19:10 |
| * jml is off for the evening | 19:10 | |
| jml | g'night all. happy hacking. | 19:10 |
| bac | hi sinzui | 19:39 |
| lifeless | lets play spot the deploy: http://webnumbr.com/launchpad-critical-bugs | 19:47 |
| === ajmitch_ is now known as ajmitch | ||
| sinzui | hi bac: sorry. I was dealing with a run away proc. you have my attention now | 20:04 |
| bac | hi sinzui. np | 20:05 |
| bac | i was just going to ask you some yui test questions. | 20:05 |
| bac | i'm trying to get some debugging output. Y.log() disappears. i tried console.log() too but it doesn't output to the browser console. any tips | 20:06 |
| sinzui | um. no. are you saying the out never arrives, or that something clears it? | 20:07 |
| bac | expected to see it in the browser console but see nothing | 20:08 |
| bac | sinzui: oh, wait, i do see it in the console div, amongst the other output. i was looking in the error console | 20:09 |
| sinzui | oh, I was nervous asking if you were sure you were looking at the log | 20:10 |
| thumper | sinzui: got a minute to mumble? | 20:19 |
| bac | sinzui: deryck pointed out that commenting out the console in the test_.js dumps everything into the console and is interogatable. | 20:23 |
| sinzui | thumper: I can talk now | 20:27 |
| lifeless | sinzui: https://code.launchpad.net/~sinzui/lazr.restful/json-not-xhtml-0 looks like it isn't actually landed | 20:55 |
| sinzui | lifeless: I do not know what is up with that. I do not see it, but I think I pushed it. | 20:57 |
| * sinzui tries again | 20:57 | |
| lifeless | sinzui: I looked at https://code.launchpad.net/~lazr-developers/lazr.restful/trunk | 20:57 |
| sinzui | so did I ;( | 20:58 |
| lifeless | wgrant: remerging db-devel would be cutting it -real- fine | 21:01 |
| thumper | leonardr: mumble? | 21:02 |
| leonardr | thumper, yes | 21:02 |
| sinzui | lifeless: sorry, I think I had pushed to the wrong location :(. The fix is in rev 178, version 0.17.4 | 21:04 |
| lifeless | sinzui: thats cool; are you going to do the lazr.restful update in lp itself? | 21:06 |
| sinzui | leonardr: can you look at the revs in https://code.launchpad.net/~lazr-developers/lazr.restful/trunk ? I am having a panic attack. I think something you landed today is missing because of my rememerge | 21:06 |
| leonardr | sinzui: it's possible, i'll look | 21:06 |
| sinzui | lifeless: please wait for leonardr to be sure I did not loose something | 21:06 |
| lifeless | sinzui: of course | 21:06 |
| jcsackett | lifeless: can you take a look at the reply to the mp of mine that stub added you to? and if you have any further concerns holding it back from being landed, let me know? | 21:06 |
| lifeless | sinzui: I'm hoping we can get the oem bug through qa for the deploy on thursday | 21:06 |
| lifeless | jcsackett: if its a db patch, the requirement is stubs approval - I just audit so I'm in the loop on db schema changes | 21:07 |
| lifeless | jcsackett: per the db schema change policy | 21:07 |
| jcsackett | lifeless: dig, i just saw a pending review for you that i didn't add. :-P | 21:08 |
| lifeless | jcsackett: so, you *should* have added it :) but you don't need my vote | 21:08 |
| jcsackett | right on. :-) | 21:08 |
| jcsackett | lifeless: did i read an earlier comment correct, that we may be remerging db-devel before the rollout? | 21:09 |
| lifeless | no | 21:09 |
| jcsackett | oh good. | 21:09 |
| lifeless | wgrant was expressing enthusiasm for getting more fixes in | 21:09 |
| jcsackett | lifeless: dig. i had some concern there. | 21:10 |
| leonardr | sinzui: i think we may have lost your *own* changes | 21:12 |
| sinzui | leonardr: I really think I lost that last revision. if you have a copy of lazr-restful from you push today. I think you want to repush, maybe with overwrite. bzr cdiff -r176..-1 | less -r only shows my changes | 21:13 |
| sinzui | leonardr: but...I though I had pushed my changes yesterday, lifeless reported they were not there. So I remerged and pushed. So regardless of what happened. I want to be sure both out changes are in the branch | 21:15 |
| wallyworld | leonardr: https://code.launchpad.net/~wallyworld/launchpad/recipe-request-builds-existing/+merge/52389 | 21:19 |
| leonardr | sinzui: i'm on revision 178 and my change to _resource.py is present | 21:19 |
| sinzui | leonardr: raise e? | 21:20 |
| leonardr | yeah | 21:20 |
| leonardr | raise e within the else clause | 21:21 |
| sinzui | okay I see that, We lost your commit message though | 21:21 |
| sinzui | see the bottom of the page: https://code.launchpad.net/~lazr-developers/lazr.restful/trunk | 21:21 |
| sinzui | leonardr: I would be happy if you could push your copy to be trunk, then restart my merge so that the changelog is correct | 21:22 |
| bac | sinzui: have time to talk on mumble briefly? | 21:24 |
| leonardr | sinzui: i'm not sure how to do that. 'bzr push lp:lazr.restful' says no new revisions to push | 21:24 |
| sinzui | oh | 21:24 |
| bac | brb | 21:25 |
| sinzui | leonardr: does push --overwrite do nothing? | 21:25 |
| leonardr | let's see | 21:25 |
| sinzui | leonardr: bzr log -n 0 -r 177..178 shows my remerge swallowed out commit message. So I do not think we lost code, I just messed up the log of histrory | 21:25 |
| leonardr | i agree | 21:26 |
| leonardr | --overwrite also does nothing | 21:26 |
| sinzui | :( I suck | 21:28 |
| sinzui | leonardr: thanks for your time. I will try a reverse merge to undo this | 21:29 |
| leonardr | do you want my original commit message? | 21:29 |
| leonardr | wallyworld: are we talking about 2 extra web service calls, or 2n extra calls? | 21:34 |
| * wallyworld thinks for a second | 21:35 | |
| wallyworld | leonardr: akin to 2n - 1 per archive and 1 per distroseries | 21:36 |
| leonardr | i think the current approach is fine | 21:36 |
| lifeless | sinzui: you don't suck, the trunk isn't setup correctly | 21:36 |
| wallyworld | leonardr: cool. it just seems kludgy | 21:36 |
| bac | sinzui: when you have time i'd like to ask you about how yui unit tests find the local JS resources. | 21:36 |
| lifeless | it needs the setting in bzr for no history changes to be set | 21:36 |
| leonardr | it is, but kludgy is better than super-inefficient, and we don't have a good alternative right now | 21:36 |
| wallyworld | leonardr: it would be nice to somehow be able to specify what attributes we wanted to return for elements in a collection_link | 21:37 |
| wallyworld | when the link is fetched | 21:37 |
| leonardr | wallyworld: yeah, that's part of expand-and-filter | 21:37 |
| wallyworld | leonardr: is that something currently in progress? | 21:38 |
| leonardr | wallyworld: no, i planned to work on it but then the teams were rearranged. it needs to be scheduled as a large new feature | 21:38 |
| wallyworld | leonardr: imho it a pretty important feature as we move towards more xhr support in lp, so it would be good to see it on the radar :-) | 21:39 |
| lifeless | wallyworld: leonardr: can I but in and ask about the context ? | 21:39 |
| lifeless | s/but/butt/ | 21:40 |
| wallyworld | lifeless: i'm retrieveing a collection of build records via the ws api from javascript | 21:40 |
| wallyworld | lifeless: by getting a collection link | 21:40 |
| wallyworld | lifeless: the records contain links to other objects | 21:40 |
| wallyworld | but i need attributes on those objects and the returned collection elements just have the links | 21:41 |
| lifeless | wallyworld: planning to, or are ? | 21:41 |
| wallyworld | lifeless: i have a mp for review | 21:41 |
| lifeless | I mean, is this in trunk already ? | 21:41 |
| lifeless | wallyworld: so, this sets of red flags for me. | 21:41 |
| wallyworld | me to but there's no infrastructure to support what i need yet | 21:42 |
| lifeless | what are the alternatives ? | 21:42 |
| wallyworld | see leonardr's comment about expand and filter support | 21:42 |
| wallyworld | lifeless: i have an alternative - and am using it in the mp | 21:42 |
| lifeless | sorry, I wasn't clear | 21:42 |
| lifeless | what are the alternatives to crippling our appservers when users hit this page | 21:43 |
| * lifeless adds hyperbole to help the discussion | 21:43 | |
| wallyworld | lifeless: but we don't cripple the app servers - i'm not making N+1 calls - the mp uses another way of doing it | 21:43 |
| leonardr | lifeless: wallyworld is using url hacking to make 1 request instead of 2n | 21:43 |
| lifeless | ok, whew. | 21:43 |
| lifeless | thats brilliant | 21:43 |
| leonardr | i told him that was the right thing to do | 21:43 |
| wallyworld | lifeless: give me some credit - i'm not that stupid :-) | 21:44 |
| sinzui | leonardr: lifeless the history is back in the correct order. My remerge did not increment version.txt so my log fix really was wanted | 21:44 |
| lifeless | wallyworld: well, I read '10:41 < wallyworld> lifeless: i have a mp for review' as meaning the 2n approach | 21:44 |
| wallyworld | lifeless: i was just after a +1 from leonardron the kludgy approach used | 21:44 |
| lifeless | wallyworld: leonardr: thanks for humouring me, totally agree we should use the kludge | 21:44 |
| wallyworld | lifeless: fair enough :-) | 21:44 |
| leonardr | cool | 21:45 |
| lifeless | sinzui: great, so - are you going to do the lazr.restful upgrade for lp ? | 21:45 |
| wallyworld | lifeless: yeah, but we will run into more cases requiring it as we expand out xhr support, so I +1 on leonardr implementing expand and filter support into lazr restful :-) | 21:45 |
| wallyworld | if we ever get the time to do such things :-) | 21:46 |
| leonardr | sinzui, lifeless: i have a branch in ec2 land that will upgrade launchpad to 0.17.3, but you probably want 0.17.4 | 21:46 |
| sinzui | lifeless: I do not what what i do for that. cut a release, push it to pypi, increment egg version in buildhout? | 21:46 |
| sinzui | leonardr: which branch? I will cargo cult | 21:46 |
| leonardr | sinzui: the one you were looking at earlier | 21:47 |
| leonardr | https://code.launchpad.net/~leonardr/launchpad/bug-106338 | 21:47 |
| sinzui | ah. | 21:47 |
| leonardr | sinzui: here's my 'release script': http://pastebin.ubuntu.com/577617/ | 21:48 |
| sinzui | excellent. thank you! | 21:48 |
| lifeless | sinzui: cut a release; add to download-cache and commit, then update versions.cfg in lp and merge that to devel. | 21:50 |
| lifeless | gary_poster: hi | 21:52 |
| gary_poster | lifeless, hi | 21:52 |
| lifeless | hi | 21:53 |
| lifeless | this bug I filed | 21:53 |
| gary_poster | bug 731099? | 21:53 |
| _mup_ | Bug #731099: structural subscriptions have poor queries on bugs with many bugtasks <story-better-bug-notification> <Launchpad itself:Triaged> < https://launchpad.net/bugs/731099 > | 21:53 |
| lifeless | yeah | 21:53 |
| lifeless | at the risk of being annoying, I was wondering if you had the time to chat - just here - about it interactively | 21:54 |
| gary_poster | subscription portlet shouldn't use the same code path anymore. I haven't checked. That's a bug IMO if it does | 21:54 |
| gary_poster | sure | 21:54 |
| lifeless | so what I did locally was add 200 bugtasks to a single bug | 21:54 |
| wallyworld | leonardr: you ok to approve the mp so i can push it through ec2? thanks :-) | 21:54 |
| lifeless | the main bug html rendered without the query I saw - it was the async population of the subscribers portlet that did the big query | 21:54 |
| gary_poster | ah-ha | 21:55 |
| gary_poster | if you get me that url I'll look at it lifeless. essentially, here's where I am: | 21:55 |
| lifeless | /bugs/1/+bug-portlet-subscribers-content | 21:56 |
| _mup_ | Bug #1: Microsoft has a majority market share <iso-testing> <ubuntu> <Clubdistro:Confirmed> <Computer Science Ubuntu:Invalid by compscibuntu-bugs> <EasyPeasy Overview:Invalid by ramvi> <GNOME Screensaver:Won't Fix> <Ichthux:Invalid by raphink> <JAK LINUX:Invalid> <The Linux OS Project:In Progress> <metacity:In Progress> <OpenOffice:In Progress by lh-maviya> <Tabuntu:Invalid by tinarussell> <Tivion:Invalid by shakaran> <Tv-Player:New> <Ubuntu:I | 21:56 |
| lifeless | is what my local log shows | 21:56 |
| gary_poster | 1) the portlet should not use that "let's send things" query. There's a much simpler approach that gives a reasonable approximation. | 21:57 |
| gary_poster | Further, Jono and I have tentatively agreed that the subscribers info should probably be deleted because it is no longer accurate enough or interpretable-by-humans enough to be of value, but that's a but of a by the way. | 21:58 |
| gary_poster | 2) the best way to get rid of the doubling in query size is to add with support to Storm (which I'd love to get to, but is not currently a priority). What we can do now without losing functionality is to make an intermediate query so we don't have to duplicate things. As I said in the bug report, I'm not convinced it is the right balance of things, but it's not an inner loop, so it probably won't make that big of a | 22:00 |
| gary_poster | that was probably truncated :-/ | 22:00 |
| gary_poster | As I said in the bug report, I'm not convinced it is the right balance of things, but it's not an inner loop, so it probably won't make that big of a diff either way | 22:00 |
| lifeless | gary_poster: it looked to me eyeballing the query that the inner clauses are able to be optimised out - but that may be my eyes glazing over at hand evaluating OR vs AND precedence | 22:00 |
| gary_poster | There are two possibilities in your eyeballing | 22:01 |
| gary_poster | that I see | 22:01 |
| lifeless | gary_poster: specifically, what I saw was (project-or-product and (status-of-filter) OR (project-or-product and (status-of-filter) | 22:01 |
| gary_poster | 1) what you said | 22:02 |
| lifeless | gary_poster: and I thought it might be factorable to (status-of-filter and (project-or-product OR project-or-product OR ..) | 22:02 |
| gary_poster | 2) I missed something | 22:02 |
| gary_poster | heh, I was going to go on for a while so I went for summaries ;-) | 22:02 |
| lifeless | :) | 22:03 |
| gary_poster | lifeless, is there a pertinent bit in the stuff you filed that's an example? Let's see if I can explain it or not | 22:03 |
| lifeless | context - | 22:04 |
| lifeless | L | 22:04 |
| lifeless | EFT JOIN BugSubscriptionFilterTag ON BugSubscriptionFilterTag.filter = BugSubscriptionFilter.id WHERE StructuralSubscription.id IN (1) | 22:04 |
| lifeless | repeating bits - | 22:04 |
| lifeless | AND ((StructuralSubscription.product = 4 OR StructuralSubscription.project = 4) AND (BugSubscriptionFilt | 22:04 |
| lifeless | erImportance.importance = 20 OR BugSubscriptionFilterImportance.importance IS NULL) AND (BugSubscriptionFilterStatus.status = 10 OR BugSubscriptionFilterStatus.status IS NULL) | 22:04 |
| lifeless | OR | 22:04 |
| lifeless | (StructuralSubscription.product = 130) AND (BugSubscriptionF | 22:04 |
| lifeless | ilterImportance.importance = 5 OR BugSubscriptionFilterImportance.importance IS NULL) AND (BugSubscriptionFilterStatus.status = 10 OR BugSubscriptionFilterStatus.status IS NULL) | 22:04 |
| lifeless | (repeats with only the product clause changing in each repeeat | 22:04 |
| gary_poster | lifeless, that's because the individual bugtasks have those values, individually | 22:06 |
| lifeless | ok | 22:06 |
| lifeless | so we could group this into one complex thing per (importance,status) tuple | 22:07 |
| lifeless | which would be about 25 clauses on pathological bugs | 22:07 |
| lifeless | gary_poster: I think we should be data driven about whether this matters | 22:07 |
| lifeless | gary_poster: the /bugs/1/+bug-portlet-subscribers-content url on a machine with the filters will let us gather that data | 22:07 |
| _mup_ | Bug #1: Microsoft has a majority market share <iso-testing> <ubuntu> <Clubdistro:Confirmed> <Computer Science Ubuntu:Invalid by compscibuntu-bugs> <EasyPeasy Overview:Invalid by ramvi> <GNOME Screensaver:Won't Fix> <Ichthux:Invalid by raphink> <JAK LINUX:Invalid> <The Linux OS Project:In Progress> <metacity:In Progress> <OpenOffice:In Progress by lh-maviya> <Tabuntu:Invalid by tinarussell> <Tivion:Invalid by shakaran> <Tv-Player:New> <Ubuntu:I | 22:07 |
| gary_poster | lifeless, right; I thought about the optimization and rejected it. I didn't expect anything like 200 bugtasks. bug 1 is like that, I take it? | 22:08 |
| _mup_ | Bug #1: Microsoft has a majority market share <iso-testing> <ubuntu> <Clubdistro:Confirmed> <Computer Science Ubuntu:Invalid by compscibuntu-bugs> <EasyPeasy Overview:Invalid by ramvi> <GNOME Screensaver:Won't Fix> <Ichthux:Invalid by raphink> <JAK LINUX:Invalid> <The Linux OS Project:In Progress> <metacity:In Progress> <OpenOffice:In Progress by lh-maviya> <Tabuntu:Invalid by tinarussell> <Tivion:Invalid by shakaran> <Tv-Player:New> <Ubuntu:I | 22:08 |
| lifeless | gary_poster: 1 is small - | 22:09 |
| lifeless | 1 | 21 | 22:09 |
| lifeless | 230350 | 159 | 22:09 |
| gary_poster | my goodness | 22:09 |
| gary_poster | why, out of curiosity? | 22:09 |
| lifeless | when I get the main page for bug 230350 rendering, I can tell you | 22:10 |
| _mup_ | Bug #230350: Missing Debian Maintainer field <Ubuntu:Invalid> <afflib (Ubuntu):Fix Released by saivann> <alac-decoder (Ubuntu):Fix Released by warp10> <axiom (Ubuntu):Invalid> <beneath-a-steel-sky (Ubuntu):Fix Released> <bibletime-i18n (Ubuntu):Fix Released by txwikinger> <binkd (Ubuntu):Fix Released> <bzr-builddeb (Ubuntu):Won't Fix> <capisuite (Ubuntu):Invalid> <chinput (Ubuntu):Fix Released by warp10> <chmsee (Ubuntu):Fix Released> <ciso (U | 22:10 |
| gary_poster | :-P | 22:10 |
| lifeless | It looks like a very meta bug | 22:10 |
| lifeless | packages were missing a field, and it got batch filed on all the packages with that issue. | 22:10 |
| lifeless | we could have bugs with thousands of tasks of this nature | 22:11 |
| gary_poster | wow, blech | 22:11 |
| gary_poster | isn't that indicative of a bug in whatever is using LP? | 22:11 |
| gary_poster | in any case... | 22:11 |
| lifeless | it *is* what multiple tasks are intended for. | 22:11 |
| lifeless | its just a scale that us devs don't inuit | 22:12 |
| lifeless | *intuit* | 22:12 |
| gary_poster | IOW, it is reasonable to expect one bug to have action items in 150+ projects? | 22:12 |
| gary_poster | This is pure curiosity | 22:13 |
| gary_poster | I'm trying to assemble my action item summary in a separate "thread" | 22:13 |
| gary_poster | there are three action items I can take | 22:13 |
| lifeless | I believe 159 is our largest bug at the moment | 22:14 |
| gary_poster | Right, my question is not whether they exist, but whether they actually serve a useful purpose | 22:14 |
| wgrant | FWIW, performance was fine at the time the bug was filed. | 22:14 |
| wgrant | But subscription noise stopped us from using them. | 22:14 |
| lifeless | but this is also self limiting at the moment - the bug page scales at 50ms per task *after* 5 patches to improve it, so falls over well before larger split-outs | 22:15 |
| leonardr | wallyworld: sorry, didn't realize you wanted me to review the whole branch | 22:15 |
| gary_poster | 1) if you file a bug about /bugs/1/+bug-portlet-subscribers-content tickling this code path and assign it to me, I'll promise to see if I can address it quickly. If I can't address it quickly, I'll push it off till bug rotation. | 22:15 |
| _mup_ | Bug #1: Microsoft has a majority market share <iso-testing> <ubuntu> <Clubdistro:Confirmed> <Computer Science Ubuntu:Invalid by compscibuntu-bugs> <EasyPeasy Overview:Invalid by ramvi> <GNOME Screensaver:Won't Fix> <Ichthux:Invalid by raphink> <JAK LINUX:Invalid> <The Linux OS Project:In Progress> <metacity:In Progress> <OpenOffice:In Progress by lh-maviya> <Tabuntu:Invalid by tinarussell> <Tivion:Invalid by shakaran> <Tv-Player:New> <Ubuntu:I | 22:15 |
| lifeless | gary_poster: I'll retitle the current bug, because it should be more clear anyway | 22:16 |
| wallyworld | leonardr: sorry. you don't have to. i can get the ocr to do it no problems. | 22:16 |
| leonardr | wallyworld: that would be better, i'm eod | 22:16 |
| wallyworld | leonardr: will do. | 22:16 |
| gary_poster | 2) if there's an indication that this code path is causing timeouts, I can try to do the optimization you describe. Even though I'm fairly skeptical of its utility, I've been wrong plenty before. | 22:16 |
| lifeless | gary_poster: I don't know that there are timeouts on this yet, https://bugs.qastaging.launchpad.net/bugs/230350/+bug-portlet-subscribers-content renders ok | 22:17 |
| _mup_ | Bug #230350: Missing Debian Maintainer field <Ubuntu:Invalid> <afflib (Ubuntu):Fix Released by saivann> <alac-decoder (Ubuntu):Fix Released by warp10> <axiom (Ubuntu):Invalid> <beneath-a-steel-sky (Ubuntu):Fix Released> <bibletime-i18n (Ubuntu):Fix Released by txwikinger> <binkd (Ubuntu):Fix Released> <bzr-builddeb (Ubuntu):Won't Fix> <capisuite (Ubuntu):Invalid> <chinput (Ubuntu):Fix Released by warp10> <chmsee (Ubuntu):Fix Released> <ciso (U | 22:17 |
| lifeless | gary_poster: and staging is down as you noted | 22:17 |
| gary_poster | 3) I continue to want to reduce the duplication of the SQL size as I was describing in that bug, but I want to do that with the WITH statement. It is an easy experiment to see if an intermediate query helps in this case, though, so that's another thing we can try. | 22:19 |
| gary_poster | If you want me to prepare a branch with that change for you to test with (in the 200 bugtask page), I could do so in a min of half hour and a max hopefully of 2 hours. | 22:19 |
| gary_poster | Meanwhile, I have to run. Please ping me with any bugs you create | 22:20 |
| gary_poster | bye everyone | 22:20 |
| lifeless | gary_poster: ciao | 22:22 |
| lifeless | gary_poster: I've retitled the bug, I think high pri is appropriate and we should see how it behaves on that bug's subscriber portlet on staging when its back | 22:23 |
| lifeless | gary_poster: no point polishing something that is ok for now | 22:23 |
| sinzui | lifeless: leonardr: My bad day continues. I seem to have destroy my lp tree in an errant branching of launchapdlib | 22:30 |
| sinzui | please bear/bare/bair/bar with me as I look for where I placed my brain | 22:31 |
| lifeless | sinzui: >< | 22:32 |
| jcsackett | sinzui: i do not appear to have sound. give me a moment. | 22:33 |
| huwshimi | sinzui: I appear to be getting very intermittent sound from everyone, restarting mumble | 22:34 |
| jcsackett | yay! mumble issues for everyone. | 22:34 |
| huwshimi | sinzui: ugh this is useless | 22:35 |
| sinzui | huwshimi: I called an end to the stand up. I hope we can talk tomorrow and the monkey god of software is kind | 22:44 |
| huwshimi | sinzui: Ah ok, I'm not sure what went wrong. It might have been network issues or something | 22:45 |
| wgrant | huwshimi: jcsackett was having similar issues (although it eventually came mostly good), so I suspect it's not your fault. | 22:46 |
| jcsackett | sinzui: i found the test in question. | 22:46 |
| jcsackett | wgrant: huwshimi: i find mumble is frequently having issues. | 22:46 |
| sinzui | jcsackett: does it look sane and simple. I think I was sane that day I wrote it | 22:47 |
| jcsackett | sinzui: it looks fairly direct, yes. | 22:47 |
| sinzui | huwshimi: wgrant: yes sound is very dodgy now. At least the new sound-indicator tells me I have not in/out. | 22:48 |
| sinzui | Oh, but it does not tell me when mumble + pulse will throw a wobbly and take my CPU with it | 22:49 |
| wgrant | sinzui: The U1 crasher is fixed now, btw. | 22:49 |
| wallyworld | thumper: leonard has eod. he's fine with the approach since we don't have expand and filter implemented in ws yet. can you +1 it? https://code.launchpad.net/~wallyworld/launchpad/recipe-request-builds-existing/+merge/52389 | 22:49 |
| sinzui | fab. I was thinking of not taking updates for few days | 22:49 |
| === Ursinha is now known as Ursinha-afk | ||
| lifeless | meh, bug text wrapping breaks my brain | 23:48 |
| lifeless | wgrant: hey | 23:49 |
| lifeless | -> Index Scan using securesourcepackagepublishinghistory_sourcepackagerelease_idx on sourcepackagepublishinghistory (cost=0.00..0.50 rows=1 width=4) (actual time=0.011..0.011 rows=0 loops=1276160) | 23:49 |
| lifeless | Index Cond: (sourcepackagepublishinghistory.sourcepackagerelease = sourcepackagerelease.id) | 23:49 |
| lifeless | Filter: ((sourcepackagepublishinghistory.archive = ANY ('{1,534}'::integer[])) AND (sourcepackagepublishinghistory.distroseries = 106) AND (sourcepackagepublishinghistory.component = 3) AND (sourcepackagepublishinghistory.status = 2)) | 23:49 |
| lifeless | whats that filter checking for in english | 23:49 |
| wgrant | lifeless: Published sourcepackagereleases in universe, natty(?), primary and partner. | 23:50 |
| lifeless | hmm, I think this is the issue though | 23:50 |
| lifeless | -> Index Scan Backward using bugtask_importance_idx on bugtask (cost=0.00..116380.60 rows=110413 width=276) (actual time=9.909..2039.202 rows=3788 loops=1) | 23:50 |
| lifeless | Filter: ((distribution = 1) AND (status = 10)) | 23:50 |
| lifeless | -> Index Scan using sourcepackagerelease_sourcepackagename_idx on sourcepackagerelease (cost=0.00..4.77 rows=21 width=8) (actual time=0.508..34.643 rows=337 loops=3788) | 23:50 |
| lifeless | Index Cond: (sourcepackagerelease.sourcepackagename = bugtask.sourcepackagename) | 23:51 |
| wgrant | What's this from? | 23:52 |
| wgrant | Oh. | 23:53 |
| wgrant | Component bug searches? | 23:53 |
| lifeless | https://bugs.launchpad.net/launchpad/+bug/731679 | 23:53 |
| _mup_ | Bug #731679: distribution:+bugs timeout <timeout> <Launchpad itself:Triaged> < https://launchpad.net/bugs/731679 > | 23:53 |
| lifeless | I'm trying to figure out the intent, yes | 23:53 |
| lifeless | I think its 'new bugs only' | 23:53 |
| lifeless | but https://bugs.launchpad.net/ubuntu/+bugs?orderby=-importance&search=Search&field.status=NEW is snappy | 23:54 |
| wgrant | Which OOPS is that from? | 23:55 |
| lifeless | wgrant: the first one | 23:55 |
| wgrant | I'd say it was from DistroSeries:+bugs... | 23:55 |
| wgrant | oh, I see. | 23:57 |
| wgrant | Of course. | 23:57 |
| wgrant | A component filter should be all that is necessary. Have you tried that? | 23:58 |
| wgrant | Yeah, that works. | 23:58 |
| wgrant | Where "works" is "times out" | 23:59 |
| wgrant | https://bugs.launchpad.net/ubuntu/+bugs?field.component=3 | 23:59 |
| lifeless | https://bugs.launchpad.net/ubuntu/+bugs?field.searchtext=&orderby=-importance&search=Search&field.status:list=NEW&assignee_option=any&field.assignee=&field.bug_reporter=&field.bug_supervisor=&field.bug_commenter=&field.subscriber=&field.component=1&field.component-empty-marker=1&field.tag=&field.tags_combinator=ANY&field.status_upstream-empty-marker=1&field.has_cve.used=&field.omit_dupes.used=&field.omit_dupes=on&field.affects_m | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!