| mwhudson | ugh, i'm sure apis are supposed to work in read-only mode... | 00:08 |
|---|---|---|
| wgrant | mwhudson: I'm seeing distribution['ubuntu'] failing. | 00:09 |
| wgrant | I never have before. | 00:09 |
| wgrant | Are you seeing something similar? | 00:09 |
| james_w | 503s? | 00:09 |
| wgrant | Yeah. | 00:10 |
| james_w | I've definitely seen them before | 00:10 |
| wgrant | For some things, sure. | 00:10 |
| james_w | I've not tried to correlate it to anything | 00:10 |
| wgrant | But never this. | 00:10 |
| wgrant | Ugh. | 00:13 |
| mwhudson | wee! | 00:14 |
| wgrant | c.l.d.oauth tries to use the master store. | 00:14 |
| mwhudson | i wonder what's happening | 00:14 |
| wgrant | But that hasn't changed lately. | 00:14 |
| mwhudson | the response is being generated by launchpad, it seems? | 00:15 |
| === mbarnett changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | firefighting: - | On call reviewer: abentley | https://code.launchpad.net/launchpad-project/+activereviews | ||
| mwhudson | so there should be oopses | 00:15 |
| mwhudson | maybe? | 00:15 |
| wgrant | mwhudson: Unlikely. | 00:16 |
| wgrant | That probably won't generate an OOPS. | 00:16 |
| wgrant | But I can see the issue locally. | 00:16 |
| mwhudson | ah ok | 00:16 |
| wgrant | http://paste.ubuntu.com/565226/ | 00:16 |
| wgrant | That's with login_anonymously | 00:17 |
| gary_poster | wgrant: looking | 00:34 |
| wgrant | gary_poster: Thanks. Although it's less critical now, since the rollout failed so we'll probably have to cowboy. | 00:35 |
| gary_poster | wgrant, ah :-/ | 00:35 |
| gary_poster | wgrant, qa instructions already exist for the first: last para of description of https://code.launchpad.net/~gary/launchpad/bug548/+merge/48850 | 00:37 |
| gary_poster | looking at the other one... | 00:37 |
| gary_poster | I also did the same for the other one, wgrant (https://code.launchpad.net/~gary/launchpad/bug713392/+merge/48939) | 00:38 |
| wgrant | gary_poster: Ah, sorry. Just about nobody does, so I stopped checking there a while ago. | 00:38 |
| gary_poster | wgrant, np, understood :-) . I'm not consistent either, but I try to do that | 00:39 |
| === Ursinha is now known as Ursinha-afk | ||
| thumper | so... | 01:21 |
| thumper | what's the status with writing new windmill tests? | 01:21 |
| thumper | we are supposed to? | 01:21 |
| poolie | spm, i sent bug mail to lp during the rollout and it does not yet seem to have any effect.... | 01:40 |
| poolie | nm, they have come through | 01:52 |
| * thumper nipping out to what the girls' first touch game of the season | 02:12 | |
| LPCIBot | Project devel build (429): STILL FAILING in 6 hr 6 min: https://hudson.wedontsleep.org/job/devel/429/ | 02:15 |
| LPCIBot | * Launchpad Patch Queue Manager: [r=jtv][bug=714820] Ignore malformed responses when probing remote | 02:15 |
| LPCIBot | Bugzilla instances for XML-RPC capabilities. | 02:15 |
| LPCIBot | * Launchpad Patch Queue Manager: [r=adeuring][bug=181368] Gut BinaryPackageFilePublishing view. | 02:15 |
| LPCIBot | * Launchpad Patch Queue Manager: [r=jtv][bug=715659] Use zope.exceptions to format logged exceptions | 02:15 |
| LPCIBot | so that __traceback_info__ is reported. | 02:15 |
| LPCIBot | * Launchpad Patch Queue Manager: [r=leonardr][bug=715116] Add a big informational notice on the PPA | 02:15 |
| LPCIBot | pages if publishing is disabled. | 02:15 |
| LPCIBot | * Launchpad Patch Queue Manager: [r=lifeless][bug=713234] Remove duplicated queries issued when | 02:15 |
| LPCIBot | calling ArchiveView.latest_updates | 02:15 |
| lifeless | https://code.launchpad.net/~lifeless/launchpad/bug-704446/+merge/49167 | 02:36 |
| poolie | hi lifeless | 02:51 |
| lifeless | hi poolie | 02:52 |
| poolie | do you have any idea whether https://bugs.launchpad.net/launchpad/+bug/716175 would be shallow? | 02:54 |
| _mup_ | Bug #716175: api calls fail while launchpad is readonly <Launchpad itself:Triaged> < https://launchpad.net/bugs/716175 > | 02:54 |
| lifeless | poolie: I suspect its not, but without an oops can't really confirm (could simulate locally I guess) | 03:03 |
| lifeless | poolie: but I'm not hugely interested in fixing readonly mode, I don't think its a particularly good use of engineering time | 03:04 |
| lifeless | poolie: I'm going to reply to jam about loggerhead and try and clear up the confusion | 03:05 |
| lifeless | poolie: however I have a few fires to deal with first today. | 03:05 |
| lifeless | huwshimi: ping | 03:14 |
| huwshimi | lifeless: Hey | 03:14 |
| lifeless | huwshimi: contrast this | 03:14 |
| lifeless | http://bazaar.launchpad.net/~jameinel/loggerhead/merge_pqm_updates/files | 03:14 |
| lifeless | and | 03:14 |
| lifeless | http://bazaar.launchpad.net/~jameinel/loggerhead/merge_pqm_updates/changes | 03:14 |
| lifeless | note the former has a 'help' tab | 03:14 |
| lifeless | its in the lp loggerhead branch only | 03:14 |
| lifeless | I think it was added during the drive to have 'help everywhere' in LP | 03:14 |
| lifeless | but if you click on it | 03:14 |
| lifeless | it takes you to a sad panda wiki page | 03:15 |
| lifeless | I'm seeking a second opinion on just discarding that noddy tab | 03:15 |
| wgrant | lifeless: It's easy to replicate locally. | 03:15 |
| wgrant | I pastebinned the traceback earlier. | 03:15 |
| wgrant | I don't see how it could have ever worked, but it apparently did.d | 03:15 |
| lifeless | wgrant: I was not connected to irc :) | 03:15 |
| wgrant | Right. | 03:15 |
| lifeless | wgrant: feel free to annotate the bug ;) | 03:15 |
| poolie | lifeless, yeah, much better to just never go into readonly mode | 03:18 |
| poolie | hearty +1 from me to removing the help tab | 03:18 |
| huwshimi | lifeless: Help that is not helpful is useless. It appears to me that that help is not really helpful. You could either remove the tab or provide some useful help. | 03:18 |
| poolie | those little 'help' drawers were such an awful idea | 03:19 |
| poolie | lifeless, in that case i might bump 716175 down to low | 03:19 |
| lifeless | poolie: I have done so | 03:19 |
| huwshimi | Useless help just results in what I like to call "help page rage". | 03:20 |
| huwshimi | I once worked on a massive application where all the help documentation for every form field was "This is the Foo field". The documentation guy didn't understand why this was a bad thing. | 03:23 |
| poolie | huwshimi, that's what we had | 03:24 |
| poolie | i cannot think of a better way to train people to never click on things labelled Help | 03:24 |
| huwshimi | poolie: Ouch. | 03:24 |
| poolie | if we'd kept the same mechanism but only used it when we had something important to say, it would have been half decent | 03:24 |
| poolie | but better to just put it inline if it's really important and you can't think of a way to make it obvious | 03:25 |
| huwshimi | If there is a bug that has been fixed by another bug do I change it to "Fix released"? | 03:27 |
| poolie | yes, or mark it as dupe, or as invalid | 03:28 |
| poolie | whatever you think best expresses the situation or is easiest | 03:28 |
| huwshimi | poolie: Cheers | 03:28 |
| lifeless | abentley: are you still OCR? | 03:35 |
| thumper | lifeless: somewhat late for abentley don't you think? | 03:37 |
| === thumper changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | firefighting: - | On call reviewer: - | https://code.launchpad.net/launchpad-project/+activereviews | ||
| lifeless | yes :) | 03:37 |
| * thumper still feels strangely protective | 03:38 | |
| poolie | :) | 03:39 |
| huwshimi | Does anyone know what research might be alluded to in this comment? https://bugs.launchpad.net/launchpad/+bug/490058/comments/7 | 03:42 |
| _mup_ | Bug #490058: Launchpad shouldn't present itself as a database <lp-web> <Launchpad itself:Triaged> < https://launchpad.net/bugs/490058 > | 03:42 |
| poolie | she has done some user testing sessions | 03:42 |
| poolie | mm | 03:42 |
| poolie | i don't think the title of that bug is very accurate | 03:43 |
| poolie | it should be something more like "Launchpad home page should show cool stuff that's happening" | 03:43 |
| poolie | "not presented as a database" would be more like getting away from table-type views | 03:43 |
| huwshimi | poolie: Hmm.. I should try and get her findings | 03:46 |
| poolie | she'd be a good person for you to know | 03:47 |
| wgrant | There were a couple of surveys last year too. | 03:47 |
| wgrant | I never saw anything from them; were they even distributed internally? | 03:47 |
| poolie | mrevell posted something, but not very prominently | 03:47 |
| poolie | mm | 03:47 |
| spm | fyi. am doing the stabby dance on the builtbot master to remove the living dead problem it's caused. | 03:48 |
| poolie | it's kind of connected to the timeline view concept | 03:48 |
| thumper | w00t: Committed revision 12345. | 04:00 |
| thumper | nice number | 04:00 |
| LPCIBot | Project db-devel build (354): STILL FAILING in 5 hr 20 min: https://hudson.wedontsleep.org/job/db-devel/354/ | 04:00 |
| LPCIBot | Launchpad Patch Queue Manager: [rs=buildbot-poller] automatic merge from stable. Revisions: 12348 | 04:00 |
| LPCIBot | included. | 04:00 |
| huwshimi | Ugh, what am I doing wrong. I updated download-cache and did an update of devel and merged it into my branch and now getting this error: http://paste.ubuntu.com/565245/ . I know there was an update to YUI that removed a whole bunch of files. Is it possible there's something else I need to update? | 04:54 |
| thumper | huwshimi: try a "make clean build" | 04:58 |
| huwshimi | thumper: Trying but really weird things are going on | 05:02 |
| huwshimi | thumper: That's fixed it. Thanks mate | 05:08 |
| huwshimi | wgrant: Did you end up finding any of those facet images? | 05:14 |
| wgrant | huwshimi: They should be in the history of lib/canonical/launchpad/icing. | 05:16 |
| wgrant | Removed in the last 18 months. | 05:16 |
| huwshimi | wgrant: Cheers | 05:17 |
| huwshimi | wgrant: Would you use bzr explorer or something to find these files? | 05:35 |
| wgrant | huwshimi: Try checking the directory around r10000 or so. Just create a new branch and revert to then. | 05:40 |
| huwshimi | wgrant: ah right ok | 05:40 |
| lifeless | thumper: ping | 05:44 |
| lifeless | thumper: I know its paste your EOD, but perhaps you could mentor Ian's review on https://code.launchpad.net/~lifeless/launchpad/bug-704446/+merge/49167 | 05:45 |
| wallyworld | lifeless: that sql bind params review - you approved it but you also need to claim it so it can be landed https://code.launchpad.net/~wallyworld/launchpad/profile-sql-bind-values/+merge/48872 | 05:54 |
| wallyworld | pretty please :-) | 05:54 |
| lifeless | roger | 05:56 |
| wgrant | huwshimi: Did you find the images? | 06:32 |
| huwshimi | wgrant: yeah got them. I remember then now | 06:32 |
| wgrant | Someone went through and cleaned up c/l/icing a while back. | 06:33 |
| === almaisan-away is now known as al-maisan | ||
| === al-maisan is now known as almaisan-away | ||
| === almaisan-away is now known as al-maisan | ||
| huwshimi | ok time to head off | 07:05 |
| lifeless | stub: could I have a review on https://code.launchpad.net/~lifeless/launchpad/bug-704446/+merge/49167 | 07:19 |
| stub | lifeless: What is the "+ AND BugMessage.index > 0" for? | 07:29 |
| stub | end of the diff | 07:29 |
| lifeless | tunes the query for 'commented on a bug' | 07:33 |
| stub | oic. 0 is first comment == description | 07:34 |
| lifeless | https://bugs.launchpad.net/launchpad/+bug/421901/comments/10 | 07:34 |
| _mup_ | Bug #421901: Person:+bugs timeouts <lp-bugs> <timeout> <Launchpad itself:Triaged> < https://launchpad.net/bugs/421901 > | 07:34 |
| stub | approved | 07:36 |
| lifeless | thanks | 07:37 |
| lifeless | hmm | 07:43 |
| lifeless | bringing back fti columns seems entirely pointless | 07:43 |
| lifeless | jkakar: is there some way to tell storm /not/ to load a column from the db ? | 07:43 |
| lifeless | stub: can you compare the execution time for these on prod ? http://pastebin.com/raw.php?i=Lib9DXHz | 07:45 |
| stub | lifeless: second 11 seconds, first 12.7 seconds | 07:54 |
| lifeless | grr, really? | 07:55 |
| lifeless | Time: 1355.438 ms on staging | 07:55 |
| lifeless | [qa]staging | 07:55 |
| stub | http://paste.ubuntu.com/565267/ | 07:58 |
| stub | lifeless: qastaging is patched up remember | 07:59 |
| lifeless | stub: this doesn't depend on any db patches | 07:59 |
| lifeless | oh... | 07:59 |
| lifeless | we haven't indexed BugMessage.index on qastaging yet. | 08:00 |
| lifeless | stub: can I get a plan of that second query, once hot ? | 08:00 |
| lifeless | stub: also please try http://pastebin.com/TeHbFEwD | 08:02 |
| stub | That was the second query. This is the plan of the first one: http://paste.ubuntu.com/565268/ | 08:02 |
| lifeless | seq scan on bugmessage | 08:03 |
| stub | urg... that pastebin includes linenumbers in c&p | 08:03 |
| lifeless | http://pastebin.com/raw.php?i=TeHbFEwD | 08:03 |
| lifeless | stub: click on 'raw' | 08:04 |
| stub | I suspect there are a lot of bugs with only a single comment | 08:05 |
| stub | reverse that... | 08:06 |
| lifeless | indeed | 08:06 |
| stub | We have an index on (bug,index) | 08:07 |
| stub | http://pastebin.com/HMY6QqJd btw | 08:08 |
| lifeless | well, 8 seconds is better than 12 | 08:08 |
| lifeless | I think I'll unlink the bug fro mthis branch, its going to need more work | 08:09 |
| lifeless | stub: do you think a separate index on (index,) is needed, or perhaps two indices (bug,) and (index,) and drop the composite index? | 08:13 |
| stub | I'll test a separate index in a tic. Looking at some alternative querys atm. | 08:13 |
| lifeless | the one in https://bugs.launchpad.net/launchpad/+bug/421901/comments/5 I think you tried already for me, but was the best I found when experimenting last week | 08:15 |
| _mup_ | Bug #421901: Person:+bugs timeouts <lp-bugs> <timeout> <Launchpad itself:Triaged by lifeless> < https://launchpad.net/bugs/421901 > | 08:15 |
| stub | different indexes don't seem to help on BugMessage.index (or message,index) | 08:16 |
| stub | There are 177k messages from that user... | 08:17 |
| lifeless | probably why it shows up in the timeouts | 08:18 |
| stub | but I don't see a sane way to execute the query. Traversing from bug -> Message means materializing all the bugtasks with those statuses, traversing from message -> bug means materializing all 177k messages... | 08:20 |
| lifeless | perhaps if owner was on BugMessage | 08:22 |
| stub | So for that data, I'm not sure if we can beat explain analyze | 08:22 |
| stub | SELECT DISTINCT ON (BugTask.id) BugTask.* | 08:22 |
| stub | FROM BugTask, Bug, BugMessage, Message | 08:22 |
| stub | WHERE | 08:22 |
| stub | Bug.id = BugTask.bug | 08:22 |
| stub | AND Bug.id = BugMessage.bug | 08:22 |
| stub | AND BugMessage.message = Message.id | 08:22 |
| stub | AND BugTask.status in (10, 15, 20, 21, 22, 25) | 08:22 |
| stub | AND Bug.duplicateof IS NULL | 08:22 |
| stub | AND Bug.private = FALSE | 08:22 |
| stub | AND BugMessage.index > 0 | 08:22 |
| stub | AND Message.owner = 931129 | 08:22 |
| stub | ORDER BY BugTask.id; | 08:22 |
| stub | Yer - we would have to denormalize | 08:23 |
| stub | Or we just store a table of commenters on bugs | 08:23 |
| lifeless | distinct on is just more efficient, right ? | 08:23 |
| stub | it's a little more efficient than DISTINCT BugTask.* | 08:24 |
| lifeless | yeah | 08:24 |
| stub | But probably not noticebly faster | 08:24 |
| lifeless | stub: how many seconds is that ^ | 08:25 |
| lifeless | I'm not actually sure why BugMessage is separate to Message | 08:26 |
| stub | 8.7 seconds | 08:26 |
| lifeless | hmm, I had a 6 second one | 08:26 |
| LPCIBot | Yippie, build fixed! | 08:26 |
| LPCIBot | Project devel build (430): FIXED in 6 hr 11 min: https://hudson.wedontsleep.org/job/devel/430/ | 08:26 |
| LPCIBot | * Launchpad Patch Queue Manager: [r=flacoste][bug=716109] Update Launchpad to r202 of lazr-js, | 08:26 |
| LPCIBot | which includes an update to YUI 3.3. | 08:26 |
| LPCIBot | * Launchpad Patch Queue Manager: [r=jtv] [ui=none][bug=316694][incr] Take advantage of web_link when | 08:26 |
| LPCIBot | changing the URL in the browser bar, | 08:26 |
| LPCIBot | rather than hacking self_link into web_link. | 08:26 |
| LPCIBot | * Launchpad Patch Queue Manager: [r=jtv][bug=705657] Fix mirror-prober.sh wrapper script to export the | 08:26 |
| LPCIBot | correct config. (Fix bug 705657) | 08:26 |
| LPCIBot | * Launchpad Patch Queue Manager: [r=allenap][bug=710603] The new direct subscription overlay allows | 08:26 |
| _mup_ | Bug #705657: cronscripts using production/launchpad-lazr.conf config file with REPORTIFSEEN prefix <Launchpad itself:In Progress by matsubara> < https://launchpad.net/bugs/705657 > | 08:26 |
| LPCIBot | subscribing, | 08:26 |
| LPCIBot | unsubscribing and editing subscriptions and is available to the | 08:27 |
| stub | BugMessage contains bug message specific data. Message contains data relevant to all messages (answer comments etc.) | 08:27 |
| LPCIBot | ~malone-alpha team. | 08:27 |
| stub | Spambot | 08:27 |
| lifeless | http://pastebin.com/raw.php?i=UdFwWx33 | 08:27 |
| stub | 10s now :-) But the estimated cost is lower, and I think that is what we need to go by here. | 08:28 |
| lifeless | stub: the distinct on is 10 seconds? | 08:31 |
| lifeless | stub: whats the http://pastebin.com/raw.php?i=UdFwWx33 one ? | 08:31 |
| stub | They are all around the same range in seconds. The distinct on has a cost of 391000, your variant 325000. | 08:32 |
| lifeless | ok | 08:32 |
| lifeless | so I'll code up my variant next week | 08:32 |
| lifeless | how should we go about assessing the right denormalisation (e.g. owner in bugmessage; fold bugmessage and message togeter; have a table listing commentors) | 08:32 |
| stub | That last one has pretty much the same cost | 08:33 |
| stub | Even with denormalizing, we are going to have similar issues - materializing 170k rows. Lots of messages there. | 08:34 |
| stub | Doing a count of 'messages owner by 931... and index > 0' has a cost of 280k | 08:36 |
| lifeless | stub: if we had (bugtask.id, commentator), and updated it when adding a bugtask ? | 08:36 |
| stub | Bug,commentator makes more sense | 08:36 |
| lifeless | stub: we filter on bugtask status, and we search and report rows in bugtask; thats why i thought bugtask would make more sense | 08:37 |
| lifeless | -> what do I have wrong | 08:37 |
| stub | That user has commented on 43k distinct bugs | 08:38 |
| thumper | stub: is that user lifeless? | 08:38 |
| stub | People comment on bugs, not on bugtasks. | 08:38 |
| lifeless | apport | 08:39 |
| lifeless | actually not apport | 08:39 |
| lifeless | !janitor | 08:39 |
| stub | janitor | 08:39 |
| stub | who I never wanted as an actual user. | 08:39 |
| lifeless | apport has made the most comment | 08:40 |
| lifeless | and seb128 the next least | 08:40 |
| lifeless | what is ~janitor for? | 08:40 |
| stub | I think expiry and stuff | 08:40 |
| stub | its the launchpad system robot anyway | 08:41 |
| stub | so, this query makes no sense for their outliers anyway. Are we tackling the wrong problem? | 08:41 |
| stub | c/their/these | 08:41 |
| lifeless | seb128 is an outlier :P | 08:42 |
| lifeless | [yes, he is, I'm trolling] | 08:42 |
| lifeless | so there is a bug saying that the default Person:+bugs view is useless because it includes these bugs | 08:42 |
| stub | heh... so we can't just turn this off for robots (unless we just make it official and designate seb a robot) - he has almost as many messages in the system as the janitor. | 08:43 |
| lifeless | I know :) | 08:44 |
| adeuring | good morning | 08:45 |
| mrevell | Guten morgen | 09:18 |
| === jtv-afk is now known as jtv | ||
| lifeless | jml: oh hai | 09:56 |
| jml | lifeless: hello. I got your message. | 09:57 |
| lifeless | great | 09:57 |
| lifeless | since i'm still conscious, and thinking work; do you want to chat now? | 09:57 |
| jml | lifeless: definitely would like to talk, but not now. | 09:57 |
| lifeless | ok | 09:57 |
| Ursinha | good morning | 10:07 |
| bigjools | morning Ursinha, up early again | 10:19 |
| Ursinha | bigjools, trying to make it a habit | 10:20 |
| bigjools | lifeless: totally loving the render time data at the top of the page | 10:38 |
| adeuring | henninge: fancy a small review? https://code.launchpad.net/~adeuring/launchpad/bug-702468/+merge/49205 | 10:49 |
| henninge | ma kuckn | 10:50 |
| === matsubara-afk is now known as matsubara | ||
| henninge | I am getting this error when doing "make schema" http://paste.ubuntu.com/565319/ | 11:02 |
| henninge | Anybody can tell me what is wrong? | 11:02 |
| wgrant | henninge: Upgrade lp-dev-deps. | 11:02 |
| henninge | hm | 11:02 |
| wgrant | You don't have postgresql-8.4-debversion installed. | 11:02 |
| henninge | wgrant: I see, thanks. | 11:04 |
| stub | Please send more Internets. Thailand has run out. | 11:04 |
| stub | I'm rather surprised the scripts get that far when the debversion package isn't installed. | 11:05 |
| === al-maisan is now known as almaisan-away | ||
| henninge | Why does it keep these packages back? Anything I might have done? http://paste.ubuntu.com/565321/ | 11:07 |
| * henninge realizes this is probably turning into Ubuntu support. | 11:07 | |
| wgrant | dist-upgrade instead. | 11:08 |
| wgrant | upgrade will try to avoid installing new packages. | 11:08 |
| henninge | I only get this on this machine, though. My laptop upgraded fine (using update-manager). | 11:08 |
| wgrant | Right, update-manager does more than just apt-get upgrade. | 11:08 |
| henninge | currently update-manager gives me the "Not all updates can be installed. Run a partial update to install as many updates as possible." message and offers to "Partial upgrade". Is that a dist-upgrade? | 11:10 |
| === Ursinha-afk is now known as Ursinha | ||
| wgrant | henninge: Hmm, that's not good. | 11:12 |
| wgrant | What does apt-get dist-upgrade say? It sounds like it may want to remove stuff, which would be bad. | 11:12 |
| wgrant | Or there is some version skew. | 11:13 |
| henninge | http://paste.ubuntu.com/565323/ | 11:13 |
| henninge | This looks about right, though. | 11:13 |
| wgrant | That does. | 11:13 |
| wgrant | Do it. | 11:13 |
| henninge | Doing ... | 11:13 |
| henninge | ... done. | 11:16 |
| henninge | Now it wants to reboot, of course. (kernel update) | 11:17 |
| henninge | But update-manager is quiet about partial updates. | 11:17 |
| henninge | wgrant: tanks a lot! | 11:17 |
| wgrant | Great. | 11:17 |
| wgrant | Hopefully make will be happy now. | 11:17 |
| bigjools | jtv: does these queries look like they'll do the same thing? http://pastebin.ubuntu.com/565325/ | 11:20 |
| bigjools | s/does/do/ | 11:20 |
| jtv | bigjools: looking… | 11:20 |
| jtv | bigjools: what's the %s in the COALESCE stand for? | 11:22 |
| bigjools | jtv: False | 11:22 |
| jtv | bigjools: NULL OR TRUE equals TRUE, so no need for that I think. | 11:23 |
| bigjools | jtv: see lib/lp/buildmaster/model/buildfarmjob.py -> getBuildsForBuilder() | 11:23 |
| bigjools | for the storm code that generated that | 11:24 |
| bigjools | jtv: null equals true in PG? | 11:25 |
| jtv | No! | 11:25 |
| bigjools | :) | 11:25 |
| jtv | But unusually for binary operators, OR has the property that (NULL OR TRUE) evaluates as TRUE. | 11:25 |
| bigjools | the second query is missing the coalesce | 11:26 |
| jtv | Rather than to NULL, as one might otherwise expect. | 11:26 |
| bigjools | the second is Rob's attempt to optimise the first | 11:26 |
| bigjools | I'm not convinced it's right | 11:26 |
| jtv | bigjools: I don't see the "TeamParticipation.person = 2" reflected in the new query. | 11:27 |
| jtv | Oh wait, found it | 11:27 |
| jtv | It's another % in the old query. | 11:28 |
| bigjools | yeah | 11:28 |
| jtv | bigjools: but all the nastiness, complexity-wise, is in the question of which foreign keys may be null. | 11:30 |
| bigjools | the nastiness is in the fact that not all build farm jobs will have a related package build | 11:31 |
| bigjools | ie TTBJs | 11:31 |
| jtv | I get an impression that this won't show jobs for public archives that the user is not an owner of. | 11:31 |
| jtv | No, that's not right. | 11:33 |
| jtv | But the other way around? Will this respect privacy? | 11:33 |
| jtv | Say that Archive.private = TRUE and there's no matching TeamParticipation. | 11:34 |
| bigjools | looks wrong | 11:36 |
| jtv | There'll be no matching (PackageBuild, Archive, TeamParticipation), since those are inner-joined together on the conditions for visibility to the given user. | 11:36 |
| jtv | Which _sounds_ like what we want, | 11:36 |
| jtv | except then that tuple is being outer-joined to BuildFarmJob. | 11:36 |
| bigjools | it's making my head explode | 11:36 |
| jtv | Which means that if there is no (PackageBuild, Archive, TeamParticipation) that proves visibility to the user, | 11:36 |
| jtv | the outer join will just make up a (PackageBuild, Archive, TeamParticipation) of all nulls. | 11:37 |
| jtv | And the WHERE clause doesn't check for that, so AFAICT it'll happily return a BFJ for an archive that the user isn't supposed to see. | 11:38 |
| jtv | The important thing there is that with an outer join, a join condition is crucially different from a "where" condition in that the latter filters out tuples from the entire join, whereas the former may just result in a tuple of nulls where nothing matches. | 11:40 |
| bigjools | the problem with the original query is that it's doing a seq scan on archive | 11:40 |
| jtv | Use Union. | 11:40 |
| bigjools | right | 11:40 |
| jtv | This is the wide-shallow/narrow-deep pattern that we keep seeing with privacy. | 11:41 |
| bigjools | I'll ditch the left joins | 11:41 |
| jtv | Just write out separate cases for public and private archives, then factor for identical parts that you can share. | 11:41 |
| jtv | What should happen if there's no PackageBuild? Should be shown anyway? | 11:42 |
| bigjools | yes | 11:42 |
| bigjools | there's no privacy outside of anything that has a packagebuild | 11:42 |
| jtv | So for public archives you get something like… | 11:42 |
| jtv | SELECT DISTINCT BuildFarmJob.* | 11:42 |
| jtv | LEFT JOIN PackageBuild ON PackageBuild.build_farm_job = BuildFarmJob.id | 11:43 |
| jtv | LEFT JOIN Archive ON Archive.id = PackageBuild.archive | 11:43 |
| jtv | WHERE Archive.private IS FALSE | 11:44 |
| jtv | UNION | 11:44 |
| jtv | SELECT DISTINCT BuildFarmJob.* | 11:44 |
| jtv | LEFT JOIN PackageBuild ON PackageBuild.build_farm_job = BuildFarmJob.id | 11:44 |
| jtv | LEFT JOIN Archive ON Archive.id = PackageBuild.archive | 11:45 |
| jtv | LEFT JOIN TeamParticipation ON TeamParticipation.team = Archive.owner | 11:45 |
| jtv | WHERE Archive.private IS TRUE AND TeamParticipation.person = %s; | 11:46 |
| jtv | If there are a lot of BFJs without PBs, you could go even further: | 11:46 |
| jtv | SELECT DISTINCT BuildFarmJob.* | 11:47 |
| jtv | LEFT JOIN PackageBuild ON PackageBuild.build_farm_job = BuildFarmJob.id | 11:47 |
| jtv | WHERE PackageBuild.id IS NULL | 11:47 |
| jtv | UNION | 11:47 |
| jtv | SELECT DISTINCT BuildFarmJob.* | 11:47 |
| jtv | FROM BuildFarmJob -- I've been forgetting these lines, haven't I? | 11:48 |
| jtv | JOIN PackageBuild ON PackageBuild.build_farm_job = BuildFarmJob.id | 11:48 |
| bigjools | I think you need to paste | 11:48 |
| jtv | JOIN Archive ON Archive.id = PackageBuild.archive | 11:48 |
| jtv | OK, OK, I'll paste. :) | 11:48 |
| bigjools | I can't follow this here | 11:49 |
| jtv | bigjools: https://pastebin.canonical.com/43093/ | 11:54 |
| jtv | Ahhh, there's the LIMIT/OFFSET too isn't it? | 11:55 |
| jtv | Need to work that in as well. | 11:55 |
| jtv | We can use that to solve the remaining optimization problems. Hang on. | 11:55 |
| bigjools | jtv: don't worry about that, it's the batchnav | 11:56 |
| jtv | Doesn't mean we shouldn't worry about it. It's actually most likely the single biggest factor in this problem. | 11:56 |
| bigjools | the problem is that a slow query is issued twice, once to count, the next time with the limit/offset | 11:56 |
| jtv | But part of the problem is that slicing happens all the way at the end, and the query planner currently has no way to push that down into the nodes for preliminary optimization. | 11:57 |
| jtv | Hence the seq scan on Archive. | 11:57 |
| bigjools | we need ordering as well | 11:57 |
| jtv | Yes. | 11:58 |
| bigjools | and, is the distinct honoured across unions? | 11:58 |
| bigjools | or did you guarantee they don't intersect? | 11:58 |
| jtv | Yes, I required that "Archive.private = TRUE" in the last query so that makes this a partitioning. | 11:58 |
| jtv | No overlap. | 11:58 |
| bigjools | jtv: the queries are also missing a BuildFarmJob.builder = XXX | 12:04 |
| jtv | ah | 12:04 |
| bigjools | but I shall experiment and see what else I can do! | 12:04 |
| jtv | bigjools: I'm not done either :) | 12:04 |
| deryck | Morning, folks. | 12:05 |
| jtv | hi deryck | 12:05 |
| bigjools | howdy deryck | 12:05 |
| bigjools | jtv: explain analyze on your new query shows a seq scan on archive still | 12:09 |
| jtv | bigjools: not entirely surprising. | 12:09 |
| bigjools | because there's no index on private | 12:09 |
| jtv | Well that's why I said index it. :-) | 12:10 |
| bigjools | :) | 12:10 |
| jtv | bigjools: somewhat elaborate attempt here… https://pastebin.canonical.com/43094/ | 12:13 |
| bigjools | jtv: why order each inner query and then again in the outer? | 12:14 |
| jtv | bigjools: to shortcut their execution when the limit is reached. | 12:14 |
| bigjools | order and limit in fact | 12:14 |
| bigjools | ok | 12:14 |
| bigjools | I don't know how we can control that in the batchnav | 12:14 |
| jtv | The backend may be smart enough to do that for itself, but not sure. | 12:14 |
| bigjools | one can try | 12:15 |
| jtv | I've seen 8.4 backends push the ORDER BY down into sub-plans, so maybe we can leave that out. | 12:15 |
| bigjools | well I can't do it in our current infrastructure anyway | 12:15 |
| jtv | OK, I'll drop that bit. | 12:16 |
| jtv | BTW I've been assuming that by far most archives are public… is that correct? | 12:16 |
| bigjools | yep | 12:17 |
| bigjools | 3 seq scans in that query | 12:18 |
| bigjools | buildfarmjob, which is ok | 12:18 |
| bigjools | packagebuild | 12:18 |
| jtv | 2 on Archive? | 12:18 |
| bigjools | and archive | 12:18 |
| jtv | Oh | 12:18 |
| bigjools | the good news is that it seems to return the right number of rows :) | 12:18 |
| jtv | We could try the TDD approach: write the absolute minimum that satisfies our tests... SELECT %(expected_number_of_rows)d | 12:19 |
| jtv | Is this less elaborate version any worse? https://pastebin.canonical.com/43095/ | 12:19 |
| bigjools | assuming the tests are good, yes | 12:19 |
| bigjools | jtv: same sort of performane | 12:21 |
| bigjools | performance | 12:21 |
| bigjools | same seq scans | 12:21 |
| bigjools | we definitely need an index on archive.private | 12:22 |
| bigjools | it would help elsewhere | 12:22 |
| jtv | Or in this last version of the query, one on (private, owner) | 12:23 |
| bigjools | yeah | 12:23 |
| jtv | bigjools: can you see which of the two parts the packagebuild query is coming from? | 12:25 |
| bigjools | the seq scan? | 12:25 |
| jtv | Sorry, yes. | 12:26 |
| bigjools | the second I think | 12:26 |
| bigjools | there's a hash cond for archive.id above it | 12:27 |
| jtv | Could you paste me the plan? | 12:27 |
| bigjools | so prob need an index on packagebuild.archive | 12:27 |
| bigjools | which query? :) | 12:28 |
| bigjools | they're all similar but ... | 12:28 |
| jtv | https://pastebin.canonical.com/43095/ | 12:29 |
| jtv | Quite possible that we need that index, yes, or on (archive, buildfarmjob) or vice versa. | 12:30 |
| jtv | There's a patch now for hypothetical indexes in postgres. That'd be cool to have. | 12:30 |
| bigjools | http://pastebin.ubuntu.com/565348/ | 12:30 |
| bigjools | yes, you mentioned that, it would be very useful | 12:31 |
| jtv | Doesn't create real indexes, but lets you say "EXPLAIN HYPOTHETICAL" and it'll explain your query as it would do it if the hypothetical indexes were real. | 12:31 |
| bigjools | so you do CREATE INDEX HYPOTHETICAL ... ? | 12:31 |
| bigjools | hmmm so packagebuild already has indexes on archive and BFJ | 12:32 |
| jtv | Yes, like that | 12:35 |
| jtv | A unified index may help. | 12:35 |
| jtv | So one on both columns at the same time. | 12:35 |
| bigjools | is that hypothetical index stuff packaged? | 12:35 |
| jtv | No | 12:35 |
| jtv | It's a patch. | 12:35 |
| bigjools | urgh | 12:35 |
| jtv | But there's a PostgreSQL eXtension Network coming. | 12:36 |
| bigjools | so, I am seeing the original query run quicker than your new ones right now | 12:36 |
| jtv | heh | 12:36 |
| bigjools | I suspect it's cause it only has one seq scan | 12:36 |
| jtv | The seq scan on archive doesn't look at all costly. | 12:36 |
| bigjools | rows=23596 | 12:37 |
| jtv | bigjools: oh! And have you tried indexing on the sort order? | 12:39 |
| bigjools | yeah that adds 2 seconds alone, good idea | 12:39 |
| jtv | Indexing slows it down? | 12:39 |
| bigjools | removing the ORDER BY speeds it up by 2 seconds | 12:39 |
| bigjools | I'll add the index on dogfood and see what happens | 12:40 |
| === almaisan-away is now known as al-maisan | ||
| jtv | Another big cost seems to be the PackageBuild→BFJ join. | 12:43 |
| * jtv slowly figures out that bigjools wasn't being sarcastic with the "that adds 2 seconds, good idea" :) | 12:44 | |
| bigjools | heh | 12:44 |
| bigjools | jtv: actually date_finished is already indexed | 12:47 |
| jtv | bigjools: but (date_finished, id)? | 12:47 |
| bigjools | no, but how often will date_finished need a tie breaker to ID? | 12:48 |
| jtv | If the sort order is completely covered, that may open up new plans. | 12:48 |
| bigjools | index on private makes bugger all difference | 12:48 |
| jtv | :( | 12:48 |
| jtv | Well, scanning Archive wasn't that costly. | 12:49 |
| bigjools | no, I mean there's still a seq scan | 12:49 |
| bigjools | why is it scanning :/ | 12:49 |
| jtv | A seq scan is the most efficient thing to do unless it's clear that only a surprisingly small percentage of the table will actually be needed. | 12:50 |
| jtv | Think disk seeks: you can read quite a lot of data in a seq scan in the same time that it might take to seek to the next table record that an index identifies as matching. | 12:50 |
| bigjools | indeed | 12:51 |
| jtv | (Bearing in mind that the index is in key order, not tuple storage order, so likely to be very random access patterns) | 12:51 |
| jtv | That's also why we have bitmap scans. | 12:52 |
| jtv | bigjools: hang on, I just stumbled onto a major simplification | 12:54 |
| bigjools | adding an index on (date_finished, id) makes no difference :/ | 12:54 |
| === matsubara is now known as matsubara-brb | ||
| jtv | bigjools: boo | 13:01 |
| jtv | But here's another version. I'd guess it was slower, but knowing trumps guessing: https://pastebin.canonical.com/43096/ | 13:01 |
| bigjools | so far, a lot slower .... | 13:04 |
| jtv | bigjools: that's fine; it's just a stepping stone to https://pastebin.canonical.com/43097/ | 13:08 |
| jtv | Oh, that needs a DISTINCT obviously | 13:08 |
| jtv | Like so: https://pastebin.canonical.com/43098/ | 13:09 |
| bigjools | oooooo quick | 13:09 |
| jtv | Then presumably it's incorrect in some way, but still nice to see a bit of speed. :-) | 13:09 |
| bigjools | nope, looks fine! | 13:09 |
| jtv | I suspect the UNION is a very effective optimization barrier. | 13:10 |
| bigjools | returns correct number of rows | 13:10 |
| bigjools | down to 2 seconds from 9 | 13:10 |
| jtv | This makes it possible for the backend to materialize "archives this user is an owner of," which just has to be fast because so few records will be involved. | 13:10 |
| bigjools | it's quicksorting in memory now | 13:10 |
| bigjools | was using external merge on disk last time | 13:10 |
| jtv | The joins can't have helped. | 13:11 |
| bigjools | "Disk: 142912kB" - yes :) | 13:11 |
| jtv | The key to this is that the Archive seq scan is actually relatively cheap. | 13:11 |
| bigjools | it is | 13:11 |
| bigjools | actual time=0.011..21.494 | 13:11 |
| jtv | So I'm materializing one, as the first part of the union! | 13:11 |
| jtv | That's even cheaper than previously, for some reason. | 13:12 |
| bigjools | bizarro | 13:12 |
| jtv | There was just no way to get around a seq scan on archive, unless we managed to cram enormous amounts of selectivity into the PBs first—and even then. | 13:12 |
| jtv | I suspect that selectivity just isn't there. | 13:13 |
| jtv | Which can't have helped the size of the ultimate sort buffers either, for what it's worth. | 13:13 |
| jtv | Also, the PackageBuild join was very slow, and an outer join didn't look very different from an inner one, so I hoisted it out of the subquery. | 13:14 |
| jtv | That way it gets done only once. | 13:14 |
| bigjools | thanks jtv, I'll Stormify this and run the tests against it | 13:14 |
| bigjools | now, I need food | 13:14 |
| jtv | OK, glad I could help. | 13:14 |
| bigjools | jtv: you certainly did | 13:16 |
| jtv | :) | 13:16 |
| gary_poster | bo hoo, no reviewer | 13:22 |
| gary_poster | boo, even | 13:22 |
| === matsubara-brb is now known as matsubara | ||
| === lionel__ is now known as lionel | ||
| === jcsackett changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | firefighting: - | On call reviewer: jcsackett | https://code.launchpad.net/launchpad-project/+activereviews | ||
| jcsackett | gary_poster: looking for a review for https://code.launchpad.net/~gary/launchpad/bug713382/+merge/49145 ? | 13:32 |
| gary_poster | yes, jcsackett ! :-) | 13:32 |
| * jcsackett is looking at it now. | 13:33 | |
| gary_poster | thank you | 13:35 |
| jcsackett | gary_poster: in bug.py, what's the reason for working with "temp_recipients" instead of on "recipients"? | 13:43 |
| jcsackett | nm, reread proposal. | 13:43 |
| gary_poster | :-) l | 13:43 |
| gary_poster | k | 13:43 |
| * jcsackett gets more coffee while reviewing. | 13:43 | |
| gary_poster | m | 13:43 |
| gary_poster | n | 13:43 |
| deryck | henninge, we see you connect, but never hear you | 14:00 |
| jcsackett | gary: r=me. i've requested follow up from sinzui. let me know if that becomes a blocker and i'll hunt him or someone else down. | 14:06 |
| jcsackett | gary_poster ^ | 14:06 |
| sinzui | I can review it now | 14:07 |
| jcsackett | ah, i missed that you had logged on, sinzui. :-) | 14:07 |
| gary_poster | jcsackett: many thanks. will be back in afternoon | 14:13 |
| === Ursinha is now known as Ursinha-afk | ||
| === Ursinha-afk is now known as Ursinha | ||
| abentley | jcsackett, thanks for your review. You'll see that all the items I've put up for review build toward the goal of merging translations using a job. | 14:27 |
| jcsackett | abentley: i am indeed noticing that trend. | 14:27 |
| abentley | If you have any questions, I'm happy to answer 'em here. | 14:28 |
| henninge | adeuring: Two things about your branch. | 14:34 |
| adeuring | henninge: yes? | 14:34 |
| henninge | 1. I am pretty sure this is only supposed to work one way. | 14:34 |
| henninge | i.e. first "upstream" translation overwrites "Ubuntu" translation but not the other way round. | 14:35 |
| adeuring | henninge: right, but this is guarded by share_with_other_side | 14:35 |
| adeuring | this flag is always true for product and projectgroups | 14:36 |
| adeuring | and must be expicitly enabled for SPs | 14:36 |
| adeuring | so I think we don't need extra guards | 14:36 |
| henninge | hm | 14:37 |
| henninge | Where is the flag "always true"? | 14:37 |
| henninge | In the policy? | 14:37 |
| adeuring | henninge: right | 14:38 |
| henninge | ok, I see what you mean but AFAICT this is not the what you want. | 14:44 |
| henninge | s/the// | 14:44 |
| henninge | adeuring: ^ | 14:44 |
| adeuring | henninge: well, I think we want upstream translations propagated to ubuntu, and that's done by share_with_other_side == True for upstreams | 14:45 |
| adeuring | Or am I missing something? | 14:46 |
| LPCIBot | Yippie, build fixed! | 14:48 |
| LPCIBot | Project db-devel build (355): FIXED in 6 hr 1 min: https://hudson.wedontsleep.org/job/db-devel/355/ | 14:48 |
| henninge | adeuring: no, they are only to propagate if the Ubuntu translation is either empty or identical to the upstream one. | 14:50 |
| henninge | adeuring: if they are different, they stay different. | 14:51 |
| adeuring | henninge: well, the bug says "In the old model, providing the first upstream translation would have overwritten the Ubuntu translation, too. " | 14:52 |
| henninge | adeuring: yes, that is the exception to the rule I just described and which is missing from the code. | 14:52 |
| henninge | and which you implemented correctly. | 14:52 |
| henninge | But it does not work the other way round. | 14:53 |
| henninge | The exception, I mean. | 14:53 |
| adeuring | henninge: ah, so you think thatg we should restrict this feature explicitly for the flow upstream -> ubuntu? | 14:53 |
| henninge | exactly! ;-) | 14:53 |
| adeuring | even if sharing the other way round is enabled? | 14:54 |
| henninge | yes | 14:54 |
| henninge | The reasoning for this exception goes like this: | 14:54 |
| henninge | We import templates and translations from upstream, but there are no (or little ) translations yet. | 14:55 |
| henninge | Then Ubuntu translators go to work and start translating. | 14:55 |
| henninge | The upstream translators get going, too, and after a while we get updated upstream translations. | 14:55 |
| henninge | Without this exception, these upstream translations would not show up in Ubuntu. | 14:56 |
| henninge | We have been getting bad press about how "Ubuntu ignores upstream translations2 | 14:56 |
| henninge | ". | 14:56 |
| henninge | But really, Ubuntu translations should be fed back to upstream anyway, but that is not something we can solve by code. | 14:57 |
| adeuring | right. But how likely is the situation that the other "sharing variant" does something wrong? I'd prefer to not make the code even more complex ;) | 14:57 |
| adeuring | I mean, somebody must explicitly enable this sort of "sharing flow" | 14:58 |
| henninge | adeuring: It needs to retain the old behavior, though. It's documented and the translators are used to it. | 14:58 |
| henninge | What do you mean by "enable"? | 14:59 |
| adeuring | well, ok, I'll add a sort of diode then | 14:59 |
| bigjools | jtv: so I converted your SQL into STORM syntax. I think I might be about to faint that I got it right first time and the tests all pass. | 14:59 |
| henninge | adeuring: please do. | 14:59 |
| jtv | bigjools: congratulations! | 14:59 |
| adeuring | henninge: and what is the other issue? | 14:59 |
| bigjools | jtv: http://pastebin.ubuntu.com/565404/ | 14:59 |
| henninge | adeuring: secondly, I would expect a test or two for this specific behavior. | 14:59 |
| henninge | adeuring: you adapted some tests but I guess they just failed because the incumbent message happened to be empty. | 15:00 |
| adeuring | henninge: hmmm, I think the test method names indicate that the incumbent message is supposed to be empty, right? | 15:01 |
| adeuring | but nevenr mind, i can add another test ;) | 15:01 |
| henninge | adeuring: hm, you may be right | 15:01 |
| henninge | but then perhaps a test is missing for when it is not? | 15:02 |
| adeuring | ok, i'll check it | 15:02 |
| henninge | adeuring: thanks. | 15:02 |
| henninge | adeuring: I fear you will run into some work with the test when you add the "diode" because I think it is designed highly symmetrical atm. | 15:04 |
| henninge | but it would be good to show the assymmteric behavior in the test. | 15:04 |
| benji | deryck: do you know of any docs about how to use LP.client.Launchpad() to interact with the web service from JavaScript? | 15:05 |
| deryck | benji, on call, will respond just a minute | 15:05 |
| benji | thanks | 15:05 |
| LPCIBot | Project devel build (431): FAILURE in 5 hr 33 min: https://hudson.wedontsleep.org/job/devel/431/ | 15:16 |
| jcsackett | abentley: i'm looking at your last branch now. i'm not familiar with lazr configs--the purpose of your additions is just proper error capturing when the job runs? | 15:16 |
| abentley | jcsackett, no, the configuration glues it all together. Nothing could be run without it. | 15:17 |
| abentley | jcsackett, It specifies the database user to use, the JobSource to use, the error handling, etc. | 15:17 |
| jcsackett | abentley: ah, i see. i had only looked at the first two config changes. | 15:18 |
| abentley | jcsackett, lazr-js is a layered configuration system, so those first two overlay the last one. | 15:18 |
| jcsackett | abentley: dig. thanks. | 15:18 |
| deryck | benji, hi, back now. | 15:29 |
| deryck | hmmm, so lp_client docs basically> | 15:29 |
| deryck | benji, I don't think we have any actually. I've always looked at the client code itself, or followed examples in other js code. | 15:30 |
| deryck | sorry | 15:30 |
| === matsubara is now known as matsubara-lunch | ||
| benji | deryck: that's what I suspected; I'm writing the start of some docs that will hopefully fill the hole | 15:32 |
| deryck | ah nice | 15:32 |
| jcsackett | abentley: all branches are r=me; sinzui has already followed up on several. | 15:35 |
| jcsackett | really nice work. | 15:35 |
| abentley | jcsackett, thanks. | 15:35 |
| deryck | abentley or rockstar -- has the minus icon on bug pages to unlink a branch been ajax before now? Or it always went to a confirmation page? | 15:38 |
| * deryck is QAing new lazr-js and not sure | 15:38 | |
| rockstar | deryck, on bug pages? No idea. gmb did that work. | 15:38 |
| abentley | deryck, unsure. | 15:38 |
| deryck | ah ok. gmb ^^ ? | 15:39 |
| sinzui | abentley: I think everything is cleared to land now | 15:39 |
| * gmb reads scrollback | 15:39 | |
| abentley | sinzui, great, thanks. | 15:39 |
| gmb | deryck: I *think* it's always gone to a confirmation page. | 15:39 |
| gmb | Yet another we-only-did-half-the-work-before-moving-on. | 15:40 |
| deryck | gmb, ok, cool. thanks. | 15:40 |
| jcsackett | deryck: assuming you're concerned about a branch that recently hit, i can confirm that as of last monday unlinking went to a page, not ajax. | 15:44 |
| deryck | jcsackett, indeed that is my concern. Thanks! | 15:44 |
| === al-maisan is now known as almaisan-away | ||
| deryck | heh, oops. Somewhere a link from qastaging pointed to lpnet. And now there is a dumb project on launchpad. | 15:52 |
| deryck | or a new team rather. | 15:53 |
| deryck | heh, or a project that thinks it's a team. gah! | 15:53 |
| deryck | sinzui, can I or you delete https://launchpad.net/deryck-test-qa-team/, or do we need an admin for that? | 15:54 |
| sinzui | deryck: you cannot see the delete link? | 15:54 |
| sinzui | deryck: oh sorry, that is a project. the cannot be deleted. you can rename it and deactivate it | 15:55 |
| deryck | sinzui, ok, thanks. I'll just deactivate it. Sorry about that. | 15:56 |
| deryck | maybe I hand entered a URL and didn't realize I forgot the qastaging bit. | 15:59 |
| abentley | sinzui, I want to create a Job every time a Packaging is created, to merge the translations between the sourcepackage and the productseries. | 16:01 |
| === allenap changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | firefighting: - | On call reviewer: jcsackett, allenap | https://code.launchpad.net/launchpad-project/+activereviews | ||
| abentley | sinzui, Packaging doesn't have a constructor, but I'm thinking of adding one, and having it call notify. Make sense? | 16:02 |
| sinzui | yes it does | 16:02 |
| abentley | sinzui, cool, thanks. | 16:02 |
| === salgado is now known as salgado-lunch | ||
| abentley | sinzui, are Packagings ever modified, or just created and deleted? | 16:04 |
| sinzui | abentley never modified | 16:05 |
| abentley | sinzui, great. | 16:06 |
| * sinzui wonders though if changing a ds packaging workflow calls delete? | 16:06 | |
| * sinzui lookse | 16:06 | |
| sinzui | abentley: definitely not modified. We create, and occasionally delete. Packaging acts as a historical record | 16:10 |
| abentley | Good to know. | 16:10 |
| jtv | jcsackett: got an MP for you! Are you free? https://code.launchpad.net/~jtv/launchpad/bug-711077/+merge/49242 | 16:14 |
| jcsackett | jtv: in the middle of investigating a test failure. can look in half an hour? | 16:14 |
| jtv | jcsackett: if you like, though I could ask allenap first | 16:14 |
| jcsackett | jtv: if he's free now, sure. if not, i'll be happy to take a look at it soon. :-) | 16:15 |
| allenap | jtv: I'm up for a review. | 16:15 |
| jtv | great! | 16:15 |
| jtv | see mp ^^^^ | 16:15 |
| === deryck is now known as deryck[lunch] | ||
| === beuno is now known as beuno-lunch | ||
| jtv | bigjools: it seems the parallel a-f is on qastaging… want to walk me through the Q/A process? | 16:30 |
| bigjools | jtv: I'm in the middle of something, happy to do so later | 16:30 |
| jtv | OK | 16:30 |
| bigjools | jtv: passing tests were some sort of weird miracle earlier, they don't actually pass and my storm expression won't compile | 16:31 |
| bigjools | I am starting to really detest storm syntax | 16:31 |
| jtv | bigjools: it can be annoying, yes. Anything there I can help with? | 16:32 |
| bigjools | jtv: maybe, one sec | 16:32 |
| jtv | Debugging the things isn't fun either. | 16:32 |
| bigjools | tell me about it | 16:32 |
| bigjools | jtv: http://pastebin.ubuntu.com/565450/ | 16:36 |
| bigjools | won't compile, it doesn't like the PackageBuild.archiveID or PackageBuild.archive | 16:36 |
| jtv | bigjools: have you tried PackageBuild.id.is_in(Select(…))? | 16:36 |
| bigjools | jeez | 16:36 |
| bigjools | ok | 16:36 |
| bigjools | it would be PackageBuild.archive.is_in of course | 16:37 |
| bigjools | AttributeError: 'Reference' object has no attribute 'is_in' | 16:38 |
| jtv | Grrrr | 16:38 |
| jtv | Try PackageBuild.archive_id.is_in or PackageBuild.archiveID.is_in | 16:38 |
| bigjools | this ID vs reference stuff is seriously irritating | 16:38 |
| jtv | This stuff is way too hard. | 16:39 |
| jtv | Yes | 16:39 |
| bigjools | that too | 16:39 |
| bigjools | I suspect the _id will do it, I was using ID before | 16:39 |
| jtv | grrrr | 16:39 |
| bigjools | yay it worked | 16:39 |
| jtv | \o/ | 16:39 |
| bigjools | thanks jtv | 16:40 |
| jtv | np | 16:40 |
| jtv | you were blocking my lane, had to help :) | 16:40 |
| bigjools | I think I knew about this, it's clearly been a while since I wrote storm | 16:40 |
| jtv | But you keep hoping someone will fix this stuff while you're away, don't you? | 16:40 |
| bigjools | now that part is fixed, I get the problem somewhere else | 16:43 |
| === salgado-lunch is now known as salgado | ||
| jtv | That's progress. | 16:43 |
| jtv | What is it now? | 16:43 |
| bigjools | same compile error about a Reference - but no indication of which one | 16:43 |
| jtv | Ah yes that one | 16:43 |
| jtv | it's always fun. | 16:43 |
| bigjools | FSVO | 16:44 |
| jtv | I do TLAs, not ETLAs | 16:44 |
| bigjools | ha | 16:44 |
| bigjools | OMG NFW BMX | 16:44 |
| jtv | BMX? WTF!? | 16:44 |
| jtv | Anyway, with the Reference one at least you know you're missing a _id or ID suffix on a reference attribute. It's not that you might have mis-spelled one. | 16:45 |
| jtv | (That comes later.) | 16:45 |
| bigjools | yes | 16:46 |
| bigjools | shockingly, my first guess found it | 16:49 |
| jtv | the gods are toying with you | 16:49 |
| bigjools | so is dogfood | 16:55 |
| jtv | "…they play with us for their sport" | 16:56 |
| bigjools | dogfood is doofgod backwards. | 16:58 |
| bigjools | mawson should be aergia it's so bloody slow | 16:59 |
| jtv | aegria? | 17:01 |
| bigjools | aergia | 17:02 |
| jtv | Ah, not familiar with her | 17:02 |
| bigjools | darn, this query is bust | 17:02 |
| jtv | What now? | 17:02 |
| bigjools | it's returning the wrong stuff - yet the tests pass | 17:03 |
| LPCIBot | Project devel build (432): STILL FAILING in 1 hr 53 min: https://hudson.wedontsleep.org/job/devel/432/ | 17:09 |
| LPCIBot | * Launchpad Patch Queue Manager: [r=thumper][no-qa] Mechanical move of | 17:09 |
| LPCIBot | canonical.launchpad.windmill.testing to lp.testing.windmill. | 17:09 |
| LPCIBot | * Launchpad Patch Queue Manager: [r=allenap][bug=528367] Added alt tag to remove icons. | 17:09 |
| === beuno-lunch is now known as beuno | ||
| LPCIBot | Project db-devel build (356): FAILURE in 2 hr 27 min: https://hudson.wedontsleep.org/job/db-devel/356/ | 17:15 |
| LPCIBot | Launchpad Patch Queue Manager: [rs=buildbot-poller] automatic merge from stable. Revisions: 12357 | 17:15 |
| LPCIBot | included. | 17:15 |
| bigjools | jtv: hurray at last. | 17:16 |
| jtv | What was the problem? | 17:17 |
| bigjools | the history page on dogfood finally loads for adare | 17:17 |
| bigjools | jtv: pebkac | 17:17 |
| bigjools | jtv: where's your branch that you need testing? | 17:29 |
| jtv | bigjools: lp:~jtv/launchpad/bug-181368-view | 17:31 |
| jtv | That's against devel though. | 17:31 |
| bigjools | 'sok | 17:31 |
| jtv | (In fact it's already _in_ devel) | 17:31 |
| bigjools | I'm going to pocket copy a package to create publications in lots of places (it has 6 arch binaries) | 17:32 |
| lifeless | moin | 17:34 |
| lifeless | bigjools: glad you like it | 17:35 |
| bigjools | lifeless: saves a bit of ctrl-u/page-down | 17:35 |
| lifeless | I described it to elliot as 'tastefully IN YOUR FACE' | 17:35 |
| bigjools | jtv: ok, I've copied acl in maverick to maverick-proposed, with binaries. See https://dogfood.launchpad.net/ubuntu/+source/acl/+publishinghistory | 17:36 |
| * bigjools runs df publisher | 17:36 | |
| jtv | bigjools: I'm not sure what to look out for though | 17:36 |
| bigjools | jtv: I'll send you a log file when it's done. You'll see that source go from pending to published | 17:36 |
| allenap | jtv: I'm not going to finish your review today. Do you mind if I complete it in the morning? | 17:38 |
| jtv | allenap: then maybe I should ask jcsackett to give it a go after all. | 17:38 |
| jtv | allenap: or were you already partway through it? | 17:38 |
| bigjools | jtv: also this publisher may not finish within the 20 minutes I have left today | 17:38 |
| jtv | bigjools: ah… and this is df innit? | 17:39 |
| bigjools | jtv: yeah I limited it to just the suite we want, but it will still take some time | 17:39 |
| bigjools | a full run takes *hours* :/ | 17:39 |
| allenap | jcsackett: I am partway through it, but not that far, so I'm happy for him to take it if he is too. I have been pulled away by non-work things. | 17:39 |
| jtv | Oh well, have to check up tomorrow then. | 17:39 |
| bigjools | jtv: ah it finished | 17:40 |
| jtv | bigjools: so it seems to have | 17:40 |
| jtv | So how do we know it did something sensible? | 17:40 |
| jml | lifeless: good morning. | 17:40 |
| lifeless | jml: hi hi | 17:41 |
| jcsackett | jtv: you want to wait on allenap, or shall i take a look at it now? | 17:41 |
| jml | lifeless: now or in the next hour would be a good time for a call. | 17:41 |
| bigjools | jtv: I am checking the Packages files | 17:41 |
| lifeless | ok, I'll ping you in a few minutes | 17:41 |
| bigjools | jtv: how many does it kick off in parallel BTW? | 17:41 |
| jtv | jcsackett: I'd appreciate a look—I'm pretty much EOD, but I'm slightly ahead of allenap timezone-wise. | 17:41 |
| jtv | bigjools: one for each architecture (including "source") | 17:42 |
| jcsackett | jtv: okay, i'll take a look and ask any questions in the comments. | 17:42 |
| bigjools | jtv: so 6 | 17:42 |
| jtv | bigjools: but that's the parallel run. This branch is a different change. | 17:42 |
| jml | lifeless: ok. | 17:42 |
| bigjools | it is? | 17:42 |
| jtv | bigjools: yes, circumventing an awkward view. | 17:42 |
| === deryck[lunch] is now known as deryck | ||
| bigjools | seemed quicker :) | 17:42 |
| jtv | Good! | 17:43 |
| jtv | bigjools: the parallel run is still waiting for the RT | 17:43 |
| bigjools | jtv: only 4 of the binaries got published, I don't know if that's right or not | 17:44 |
| bigjools | but the ones that did look ok | 17:44 |
| jtv | bigjools: hmmm for proper Q/A we'd have to know whether that was right. | 17:44 |
| bigjools | yes | 17:44 |
| bigjools | could be PaS | 17:45 |
| jtv | PhotoAcoustic Spectroscopy? | 17:45 |
| bigjools | ah I should try an arch indep, that'll not matter | 17:45 |
| bigjools | Package Arch Specific | 17:46 |
| bigjools | it's a last-ditch override file that the publisher uses | 17:46 |
| jcsackett | jtv: while you're still here, i note in the diff you're adding some columns, but this isn't targeted to db-devel; i assume it's not introducting change to the db, but don't really understand why not. | 17:47 |
| jtv | jcsackett: adding columns!? | 17:47 |
| jtv | jcsackett: sounds as if something went wrong with the MP… just a mo' | 17:48 |
| jcsackett | jtv: several adds of IntCol (branch_id), but not replacing similar statements. i may be misinterpreting. | 17:48 |
| jtv | jcsackett: oh, those aren't columns—they're attributes that allow me to read the FK attributes directly | 17:49 |
| jtv | Pretty standard stuff. | 17:49 |
| jcsackett | jtv: ah. i figured it was something like that, but wasn't sure. and the use of "Col" in the declaration raised alarms. :-) | 17:49 |
| jtv | Seems I have to go help with a little accident here. | 17:50 |
| bigjools | jtv: so a tentative ok, but please ask wgrant to double check since this really needs more eyes to verify it before we unleash on the distro | 17:50 |
| jtv | bigjools: ack | 17:51 |
| === matsubara-lunch is now known as matsubara | ||
| === jtv is now known as jtv-afk | ||
| bigjools | jtv-afk: so meh, I forgot to notice that copy-package only copied some of the binaries, so it seems perfectly ok. | 17:54 |
| lifeless | jml: ping | 18:00 |
| lifeless | jml: skype me | 18:02 |
| lifeless | deryck: question for you, why are BugMessage and Message separate tables? | 18:03 |
| deryck | lifeless, I literally have no idea. :-) I asked once before and didn't understand the response. I think.... | 18:04 |
| deryck | lifeless, it was written in a time when we imagined different kinds of messages, of which bug message was one type. | 18:04 |
| lifeless | there are 640 shared messages | 18:04 |
| jml | lifeless: k | 18:04 |
| lifeless | that is, one message on several bugs. | 18:04 |
| deryck | hmmm, I don't know why that would be. | 18:05 |
| lifeless | deryck: I think we could make a bunch of queries faster if we deep sixed the sharing and just copied the message when that happens | 18:05 |
| lifeless | deryck: email control interface controlling many bugs? | 18:05 |
| lifeless | deryck: in case its not obvious I mean a db migration too :) | 18:05 |
| deryck | lifeless, perhaps. but I thought you could only affect multiple bugtasks, not bugs, from email | 18:05 |
| deryck | lifeless, yes, I think moving all that across to copies, not shared messages, is best | 18:06 |
| jcsackett | what's the difference between using IStore and Store.of? they seem to result in the same thing, but i'm not certain. | 18:12 |
| deryck | jcsackett, so IStore is what we provide to help manage connecting to the db, instead of just straight import Store from Storm. | 18:19 |
| deryck | jcsackett, see lib/canonical/launchpad/doc/storm.txt | 18:20 |
| jcsackett | deryck: thanks. | 18:20 |
| deryck | jcsackett, actually, I meant to point you at: lib/canonical/launchpad/doc/db-policy.txt | 18:20 |
| deryck | well, either is probably ok ;) | 18:20 |
| * jcsackett changes which file he is opening... | 18:20 | |
| lifeless | jml: http://gems.github.com/list.html | 18:22 |
| jcsackett | today has been a very busy review day... | 18:26 |
| === jcsackett_ is now known as jcsackett | ||
| jcsackett | sinzui: can i get you to look at something? | 19:09 |
| sinzui | yes | 19:09 |
| jcsackett | i'm having trouble understanding the "why" of a bit of publisher code: https://pastebin.canonical.com/43132/ | 19:09 |
| jcsackett | it looks like it's trying to rebuild web service based requests, but i don't understand why--commenting out that code doesn't seem to hurt webservice functions. | 19:10 |
| jcsackett | (this is the actual culprit for the api.launchpad.net pillar aliases redirecting outside of the api) | 19:10 |
| sinzui | jcsackett: I confess I do not understand it | 19:12 |
| lifeless | jcsackett: btw | 19:12 |
| lifeless | jcsackett: see my last comment on https://code.launchpad.net/~jtv/launchpad/bug-711077/+merge/49242 - thats something to bear in mind | 19:12 |
| sinzui | my head may be filled with straw today. I can struggling to refactor what I think is a simple test | 19:12 |
| jcsackett | lifeless: good thought. | 19:13 |
| jcsackett | sinzui: yeah, after a morning filled with the largest review queue i've seen, i'm feeling pretty muddled. | 19:13 |
| jcsackett | (and since you follow up on them all, i'm not surprised you feel the same). | 19:13 |
| jcsackett | lifeless, any chance you know what's up in this bit? https://pastebin.canonical.com/43132/ | 19:14 |
| lifeless | other than the gratuitious pass? | 19:14 |
| jcsackett | hm, you can ignore that--left over from when i commented out a bunch of code to see what changed. | 19:15 |
| * jcsackett edits paste. | 19:15 | |
| lifeless | what file is that in ? | 19:15 |
| lifeless | jcsackett: have you been introduced to bzr's annotate functionality ? | 19:15 |
| jcsackett | lifeless: i've seen annotate used once, and heard much of it. i do not, as yet, know how to do anything useful with it. :-P | 19:16 |
| jcsackett | file is canonical.launchpad.webapp.publisher | 19:16 |
| jcsackett | it seems to rebuilding webservice requests (and in the process losing the api layer) | 19:16 |
| lifeless | so the comment says: | 19:17 |
| lifeless | - no rootsite | 19:17 |
| lifeless | - handling shipit | 19:17 |
| lifeless | blame says the outer if was done in rev 3564.1.43 | 19:18 |
| lifeless | and the inner one in 7675.289.2 / 3 / 4 | 19:18 |
| lifeless | bzr log -r 7675.289.2..7675.289.4 tells me that bug-376990 was at issue | 19:19 |
| lifeless | 'canonical_url() needs to return browser URLs when generating XHTML representations' | 19:19 |
| jcsackett | yeah. | 19:19 |
| jcsackett | that seems to be the inverse of the problem leonardr pointed out to me. | 19:20 |
| lifeless | so, it wants to get canonical urls for browser links some of the time | 19:20 |
| jcsackett | so, this only happens when canonical_url is called for pillars that we've gotten by alias in the webservice. i think i can just change a call up the pipe to pass the request along. | 19:20 |
| lifeless | this also tells us how to test it | 19:20 |
| lifeless | inline bug commenting | 19:20 |
| lifeless | but we have a stale comment or something, because the block *above* the comment was changed by tim in rev 3758.1.1 | 19:22 |
| bac | hi sinzui | 19:22 |
| lifeless | jcsackett: so, what are the symptoms? | 19:22 |
| sinzui | hi bac | 19:23 |
| jcsackett | lifeless: bug 715992 | 19:23 |
| _mup_ | Bug #715992: Pillar aliases redirect outside of webservice on webservice calls <Launchpad itself:In Progress by jcsackett> < https://launchpad.net/bugs/715992 > | 19:23 |
| lifeless | wow, we are digging up some chestnuts | 19:24 |
| lifeless | this should be critical otherwise its a priority inversion | 19:24 |
| jcsackett | this came up because it needs to be whacked to deal with bug 623099 | 19:25 |
| _mup_ | Bug #623099: AttributeError filing a bug using the API <lp-foundations> <oops> <Launchpad itself:In Progress by jcsackett> < https://launchpad.net/bugs/623099 > | 19:25 |
| lifeless | yes | 19:25 |
| lifeless | agreed; I'm just saying bump it to critical | 19:25 |
| jcsackett | ah, dig. | 19:25 |
| jcsackett | done. | 19:25 |
| lifeless | because its otherwise holding a critical hostage, which wouldn't make sense | 19:25 |
| lifeless | so | 19:26 |
| lifeless | looks to me like you need to pass a request in | 19:26 |
| lifeless | ' If there is no request available, the protocol, host and port are taken | 19:26 |
| lifeless | from the root_url given in launchpad.conf. | 19:26 |
| lifeless | ' | 19:26 |
| lifeless | as leonardr says | 19:27 |
| lifeless | 'Possibly there's a method that needs to have the current request passed into it.' | 19:27 |
| lifeless | jcsackett: whats the backtrace leading into this call of canonical_url ? | 19:27 |
| jcsackett | yeah, i think i've found it; i just hit this block of code and was wondering what on earth it was doing. | 19:28 |
| jcsackett | bit of a rabbit hole, really. | 19:28 |
| lifeless | its guessing at the url the client used | 19:28 |
| lifeless | and the default is to guess 'web browser request on main site' | 19:28 |
| lifeless | worth enhancing the comment | 19:28 |
| lifeless | and adding a :param request: up in the docstring (subsuming the 'if there is no request available' prose.) | 19:29 |
| lifeless | ? | 19:29 |
| jcsackett | lifeless: yeah, i'm cleaning up the comments. | 19:31 |
| jcsackett | lifeless: thanks. | 19:34 |
| benji | deryck: I'd love any feedback or additions you might have to my first draft of "how to access webservice APIs via JavaScript": https://dev.launchpad.net/yellow/JavaScriptAPIAccessDraft | 19:53 |
| deryck | benji, ok, taking a look now | 19:54 |
| jcsackett | any chance i can get a review on https://code.launchpad.net/~jcsackett/launchpad/api-pillar-redirects-715992/+merge/49279? | 19:57 |
| deryck | benji, yeah, it's good. Do you have plans to fill in more about PATCHPlugin? | 19:58 |
| benji | deryck: I hope to. I have to figure out how to use it first. :) | 19:58 |
| deryck | benji, you can look at how the inline editor widgets and commenting use it. | 19:59 |
| benji | My plan is to put in everything I know so people can get a better start. I spent way too much time figuring out what little I know thus far. | 19:59 |
| benji | cool, thanks for the pointer | 19:59 |
| deryck | benji, I can add to this too. But I'll need pings to remind me about it. | 19:59 |
| benji | you can count on me | 20:00 |
| deryck | benji, our use of the js client as evolved over time, and we're probably named_post and named_get heavy, when we should favor patch with patch_field set true. | 20:00 |
| benji | interesting | 20:01 |
| deryck | and then setting accept to xhtml, we get back the html for the part we patched. instead of the full resource. | 20:01 |
| deryck | well, unless we need the entire thing. it depends on use, I guess. but it seems more common to do attribute patching. | 20:02 |
| benji | can the client understand xhtml? why does the server not return partial JSON? | 20:02 |
| deryck | benji, well xhtml can be created into a node easily in YUI. it's just a string, I think, not try xhtml. | 20:03 |
| deryck | s/try/true/ | 20:03 |
| deryck | so... var stuff = result_of_my_patch(); var my_html = Y.Node.create(stuff); | 20:03 |
| benji | hmm, I don't understand. Is that for when we only patch one attribute at a time? | 20:04 |
| deryck | benji, yes. which is actually common. And the attribute will be a FK to some other object on the backend. | 20:05 |
| benji | ah, ok that makes sense | 20:05 |
| deryck | that pseudo code might not be exactly how we do it either. Just going off sketch from memory. | 20:05 |
| sinzui | benji: js replies on the the DOM's engine to construct elements You can create xhtml or html using DOM nodes, but what is rendered could be the other :( I have also see cases where the code tries to place a list in a paragraph, but what is rendered is a paragraph, a list, and another paragraph | 20:07 |
| sinzui | s/replies/relies/ | 20:07 |
| benji | interesting | 20:08 |
| thumper | morning | 20:13 |
| abentley | jcsackett, I have a sequel for you: https://code.launchpad.net/~abentley/launchpad/job-on-new-packaging/+merge/49285 | 20:18 |
| * jcsackett looks | 20:27 | |
| thumper | deryck: ping | 20:42 |
| thumper | deryck: do you know most about windmill tests? | 20:42 |
| deryck | thumper, I guess I'm your only help where windmill is concerned ;) | 20:42 |
| thumper | I have a question about lines like: start_url = (windmill.settings['TEST_URL'] + 'bugs/%d' % bug.id) | 20:42 |
| thumper | windmill.settings['TEST_URL'] is what? | 20:43 |
| thumper | and why? | 20:43 |
| thumper | and why does only the code windmill tests use it? | 20:43 |
| thumper | and lib/lp/testing/windmill/lpuser.py:35 | 20:43 |
| === almaisan-away is now known as al-maisan | ||
| deryck | thumper, I actually don't know what that is. | 20:44 |
| thumper | deryck: I think it may have to do with that wallyworld did, to do with parallelizing the test suite | 20:44 |
| deryck | thumper, only code tests made use of it, and I'm not sure why. | 20:44 |
| thumper | and not using hard coded ports | 20:44 |
| deryck | yeah, that would be my guess. but that's not the way he originally mentioned about not hard coding ports. | 20:45 |
| thumper | deryck: I have a day of doing windmill today with three branches needing some form of windmill testing | 20:45 |
| thumper | deryck: I was thinking of a base class helper method | 20:45 |
| thumper | deryck: that uses canonical_url(obj, force_local=True) | 20:45 |
| thumper | deryck: and appending that to the base test url | 20:45 |
| thumper | deryck: there are too many uses of this already | 20:46 |
| deryck | thumper, why do you need windmill tests? What are you wanting to test? | 20:46 |
| thumper | deryck: mumble? | 20:46 |
| deryck | sure | 20:46 |
| Ronnie | is there a python-launchpadlib that can run without compability problems on 8.04? | 20:46 |
| Ronnie | SWAT ^ | 20:46 |
| jcsackett | abentley: r=me. | 20:50 |
| abentley | jcsackett, thanks. | 20:50 |
| === al-maisan is now known as almaisan-away | ||
| === matsubara is now known as matsubara-afk | ||
| deryck | wallyworld, windmill.settings['TEST_URL'] | 21:03 |
| deryck | wallyworld, thumper -- client.open(url='%s/bugs/1' % BugsWindmillLayer.base_url) | 21:05 |
| _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:05 |
| deryck | later on, everyone | 21:12 |
| wallyworld | thumper: http://people.canonical.com/~ianb/request-build-error.png | 21:25 |
| Ronnie | lifeless: wgrant ^^ | 21:26 |
| lifeless | Ronnie: how far up are you wanting me to look ? | 21:26 |
| Ronnie | a few lines: (21:46:52) Ronnie: is there a python-launchpadlib that can run without compability problems on 8.04? | 21:27 |
| lifeless | the one we ship in 8.0.4 ? | 21:27 |
| lifeless | blah, 8.04 | 21:27 |
| lifeless | checking rmadison | 21:27 |
| lifeless | no, nothing before karmic | 21:28 |
| lifeless | dapper is EOL in a few months | 21:28 |
| lifeless | so no plans to chane this | 21:28 |
| lifeless | Ronnie: why? | 21:28 |
| Ronnie | the ubuntu-nl server still runs on 8.04. we want in one case to communicate with launchpad (creating bug reports) | 21:29 |
| lifeless | if thats in the canonical datacentre, they are migrating them all to lucid | 21:29 |
| lifeless | just tee that up, it should be queued already | 21:29 |
| Ronnie | lifeless: its an own managed server | 21:30 |
| lifeless | ah | 21:30 |
| Ronnie | hoe flexible are loco's if we use canonical data centre> | 21:31 |
| Ronnie | can we deploy our apps ourself, are there limitations, whats the connection speed in europe etc | 21:31 |
| lifeless | theres a range of configs, really up to IS what and where | 21:32 |
| lifeless | in terms of capabilities and performance, pretty darn good; the dc is in London | 21:32 |
| lifeless | that said | 21:32 |
| lifeless | uhm, you should be able to get launchpadlib on 8.04, it will just require some work | 21:32 |
| Ronnie | lifeless: currently were thinking about staticcaly linking | 21:34 |
| lifeless | Ronnie: well, its pytho n:) | 21:35 |
| lifeless | you can probably backport the karmic set of packages fairly easily | 21:36 |
| beuno | so, is it known that the page to reqeust a merge proposal is slightly broken? | 21:36 |
| beuno | the "Other" option shows up as: "Other:'>" | 21:37 |
| beuno | which I assume is a broken template | 21:37 |
| thumper | beuno: yeah, I saw that today too... file a bug? | 21:37 |
| lifeless | there is a bug open | 21:37 |
| lifeless | its critical | 21:37 |
| Ronnie | lifeless: again about the hosting on canonical servers. how would such thing look like. if we have problems can we fix it ourself or do we have to ask canonical-isd, and what are there response times? | 21:37 |
| lifeless | sinzui is looking at it | 21:37 |
| beuno | cool | 21:38 |
| lifeless | Ronnie: I'm a poor source of info for this; #canonical-sysadmins is I think the channel for contact | 21:38 |
| === salgado is now known as salgado-afk | ||
| Ronnie | lifeless: spel error on channel? | 21:39 |
| wgrant | #canonical-sysadmin | 21:39 |
| wgrant | No s. | 21:39 |
| Ronnie | thx wgrant | 21:40 |
| sinzui | beuno: the fix is waiting for the rollout | 21:43 |
| sinzui | abentley: I had a few remarks about your last branch. Maybe you have good reason to not do as I expected | 21:47 |
| abentley | sinzui, no, mostly copying bad ideas from existing code. | 21:47 |
| jam | i'm seeing an odd typo on the merge proposal page. https://bugs.launchpad.net/launchpad/+bug/716713 | 21:52 |
| _mup_ | Bug #716713: typo in propose page <Launchpad itself:New> < https://launchpad.net/bugs/716713 > | 21:52 |
| jam | Specifically, the "Other: "line is rendered as "Other: '>" | 21:52 |
| jam | Looking at the HTML it looks like invalid html | 21:52 |
| lifeless | sinzui: whats the bug number, so we can dup jams bug :) | 21:52 |
| jam | ah, beuno, you beat me to it | 21:52 |
| sinzui | lifeless: beuno jam: bug 714527 address the issue on the recipe and Mp pages | 21:54 |
| _mup_ | Bug #714527: owned widget structured strings render as bits of quoted html <qa-ok> <regression> <Launchpad itself:Fix Committed by sinzui> < https://launchpad.net/bugs/714527 > | 21:54 |
| abentley | sinzui, thanks for your review. I've pushed changes. Diff still updating, though. | 22:01 |
| sinzui | abentley: I approved it. | 22:02 |
| abentley | sinzui, I saw, I just wanted to close the loop. | 22:03 |
| === jcsackett changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | firefighting: - | On call reviewer: - | https://code.launchpad.net/launchpad-project/+activereviews | ||
| sinzui | wgrant: mumble? | 22:33 |
| huwshimi | sinzui: Can I get you to review the colour unification stuff I've done? Not now as it sounds like you've had a long day, but when you have a chance? | 22:52 |
| sinzui | huwshimi: I sure can | 22:52 |
| huwshimi | sinzui: Thanks heaps. | 22:52 |
| sinzui | I think I have done part of it already since I looked at it the other day | 22:52 |
| huwshimi | sinzui: OK great. Would be good if you could have a quick look at the css if you haven't already. | 22:54 |
| huwshimi | just putting together the mp | 22:54 |
| huwshimi | sinzui: For whenever you can get to it: https://code.launchpad.net/~huwshimi/launchpad/unified-colours-710446/+merge/49316 | 22:59 |
| sinzui | thanks. I will wait for the diff to generate | 22:59 |
| * thumper is hacking the windmill base test case class | 23:00 | |
| thumper | interesting.... windmill hanging on start at http://code.launchpad.dev:8085/windmill-serv/start.html | 23:02 |
| thumper | sometimes only... | 23:03 |
| * thumper wanders into the kitchen in search of food | 23:06 | |
| huwshimi | sinzui: There's 60 or 70 lines removed from style.css which is nice | 23:06 |
| LPCIBot | Yippie, build fixed! | 23:09 |
| LPCIBot | Project db-devel build (357): FIXED in 5 hr 43 min: https://hudson.wedontsleep.org/job/db-devel/357/ | 23:09 |
| lifeless | wgrant: the linkification of post-filing messages is nice | 23:11 |
| lifeless | wgrant: I'm really glad you jumped on that | 23:11 |
| huwshimi | sinzui: I removed that line. All ok? | 23:37 |
| sinzui | yes | 23:37 |
| huwshimi | sinzui: Thanks :) | 23:38 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
