| StevenK | wgrant: http://pastebin.ubuntu.com/1199747/ | 00:01 |
|---|---|---|
| wgrant | StevenK: Have you confirmed that it now fails with the diff reverted? | 00:03 |
| StevenK | wgrant: Just did. | 00:04 |
| StevenK | IllegalTarget: Product-name-100217 doesn't allow Private bugs. | 00:05 |
| wgrant | Sounds good, then | 00:05 |
| wgrant | StevenK: Hm, why are you using multiple products? | 00:10 |
| StevenK | wgrant: Sorry, was noming. Yeah, let me remove that bit. | 00:36 |
| StevenK | wgrant: http://pastebin.ubuntu.com/1199798/ | 00:42 |
| wgrant | StevenK: You could also remove the makeCommercialSubscription bit if you use makeProduct(bug_sharing_policy=BugSharingPolicy.PUBLIC_OR_PROPRIETARY) | 00:43 |
| StevenK | Does that also allow USERDATA? | 00:43 |
| wgrant | Yes | 00:44 |
| StevenK | Which invalidates the test, does it not? | 00:44 |
| wgrant | You'd still have to transition it to BugSharingPolicy.PROPRIETARY after creating the bug | 00:44 |
| wgrant | It just saves you from having to manually create the commercialsubscription | 00:44 |
| StevenK | I think it's moot, it would be the same amount of lines | 00:45 |
| StevenK | But I can if you want | 00:45 |
| wgrant | Perhaps | 00:46 |
| wgrant | Anyway, it looks fine now | 00:46 |
| StevenK | wgrant: The diff is updated if you want to +1 | 00:50 |
| wgrant | You can actually kill of two more lines by not setting the product or bug owners, but I think you might kill me too | 00:51 |
| StevenK | wgrant: And use login_celebrity, I guess | 00:53 |
| wgrant | StevenK: person_logged_in(product.owner) | 00:54 |
| wgrant | Due to the APG it'll even have access to the bug | 00:54 |
| StevenK | wgrant: owner killed | 00:56 |
| wgrant | That sounds painful | 00:56 |
| StevenK | Haha | 00:56 |
| StevenK | wgrant: Thanks, tossing at ec2. | 00:58 |
| StevenK | Bloody hell, buildbot, finish already | 01:00 |
| StevenK | wallyworld, wgrant: Some cards can probably move out of QA-Landing | 01:04 |
| wallyworld | probably | 01:04 |
| wgrant | buildbot only finished 30 seconds ago | 01:07 |
| StevenK | wgrant: Heh, it was saying 56 minutes when I looked 10 minutes ago. | 01:08 |
| wgrant | 6 seconds after you mentioned QA-Landing, in fact... | 01:08 |
| lifeless | bigjools: 1920093641 | 01:32 |
| lifeless | bigjools: 1.9B | 01:32 |
| bigjools | lifeless: 433453453458798 | 01:32 |
| lifeless | bigjools: rows. | 01:33 |
| bigjools | sweet | 01:33 |
| lifeless | can we scale? Yes we can! | 01:33 |
| lifeless | of course, it is 68GB on disk. | 01:33 |
| wgrant | + indices | 01:34 |
| wgrant | If we're talking about branchrevision, there's like 100GB of indices | 01:34 |
| wgrant | Ah, no, only about 70GB now. We pruned a few | 01:35 |
| bigjools | lifeless: is it web scale? | 01:36 |
| lifeless | bigjools: http://www.mongodb-is-web-scale.com/ | 01:37 |
| bigjools | haha | 01:37 |
| bigjools | lifeless: "If there's a problem writing your data, you're fucked. Does that sound like a good design to you?" | 01:38 |
| lifeless | bigjools: "If that's what they need to do to get those kickass benchmarks, then it's a great design." | 01:39 |
| bigjools | lifeless: "Does /dev/null support sharding?" | 01:39 |
| bigjools | I can't continue, laughing too hard | 01:39 |
| lifeless | bigjools: you hadn't seen this ? | 01:40 |
| bigjools | I have | 01:40 |
| bigjools | but it remains hilarious | 01:40 |
| lifeless | indeed! | 01:42 |
| lifeless | bigjools: http://www.xtranormal.com/watch/11762072/native-html5 | 01:43 |
| wgrant | ORDER BY Branch.date_last_modified DESC, Branch.target_suffix ASC, Branch.lifecycle_status DESC, Branch.owner_name ASC, Branch.name ASC | 01:45 |
| wgrant | would you like some tie-breakers? | 01:45 |
| wgrant | lifeless: Have you thought about getting eg. bug search totals from bugsummary? | 01:55 |
| lifeless | I think that would rock | 01:56 |
| lifeless | only works for some cases though | 01:56 |
| lifeless | could be used to set upper bounds on bad estimates. | 01:56 |
| lifeless | (can't be used to set lower bounds with our search algebra) | 01:56 |
| wgrant | Yeah | 01:57 |
| wgrant | Most of the common searches should work | 01:57 |
| lifeless | personally I just want to nuke all the counts | 01:57 |
| wgrant | Obviously not fti | 01:57 |
| lifeless | or make them round - 10's 100's 1000's | 01:57 |
| lifeless | put that behind a FF for a bit | 01:58 |
| lifeless | see what the reaction is | 01:58 |
| lifeless | if its good, change the code base to estimate everywhere. | 01:58 |
| lifeless | bigjools: this is hilarious - http://www.xtranormal.com/watch/7023615/watch_movie | 02:00 |
| bigjools | must...resist.... | 02:00 |
| bigjools | too much to do | 02:00 |
| mwhudson | lifeless: i didn't think the native-html5 one was very funny | 02:01 |
| mwhudson | it was quite odd, though, so that's something i guess | 02:01 |
| wgrant | lifeless: Well, EXPLAIN-based estimates will often be waaaaaaay off | 02:01 |
| lifeless | mwhudson: the html5 one was not as good as I thought it would be | 02:01 |
| lifeless | mwhudson: the one I just linked is a follow on from the mongodb one | 02:02 |
| lifeless | wgrant: shrug :> | 02:02 |
| mwhudson | ahh | 02:02 |
| lifeless | wgrant: I guess we need some care | 02:02 |
| wgrant | It should be better now that we have bugtaskflat, I guess | 02:02 |
| wgrant | But before bugtaskflat it would have been hopeless | 02:02 |
| mwhudson | lifeless: ok, watch_movie is pretty good | 02:04 |
| mwhudson | 3 mins in | 02:04 |
| wgrant | OOPS report is pretty today :) | 02:06 |
| lifeless | much better | 02:06 |
| lifeless | not sure I'd call it pretty | 02:06 |
| wgrant | Well | 02:07 |
| wgrant | Prettier than it's been for a while | 02:07 |
| lifeless | yes | 02:07 |
| lifeless | massive improvement | 02:07 |
| lifeless | just there is more to do | 02:07 |
| StevenK | wgrant: https://dogfood.launchpad.net/ubuntu/+source/unity/+changelog | 03:42 |
| lifeless | grah | 03:53 |
| lifeless | Non-sql time: 5595 ms | 03:53 |
| lifeless | if you're fixing timeouts | 03:53 |
| lifeless | https://bugs.launchpad.net/~lifeless/?advanced=1 | 03:53 |
| lifeless | bug 1049452 if anyone wants to have a poke | 03:55 |
| _mup_ | Bug #1049452: Person:+bugs timeout on advanced search form <timeout> <Launchpad itself:Triaged> < https://launchpad.net/bugs/1049452 > | 03:55 |
| lifeless | wgrant: StevenK: How do we release launchpad-buildd ? | 03:56 |
| wgrant | lifeless: dch -i | 03:57 |
| wgrant | lifeless: Then wait for IS to get us builders back | 03:57 |
| lifeless | also, annoying - why is https://bugs.launchpad.net/python/+bug/96878 not FR for python, upstream has it as such. | 03:57 |
| wgrant | Then RT | 03:57 |
| _mup_ | Bug #96878: Launchpad session cookie is accessible from Javascript <bugjam2010> <infrastructure> <lp-foundations> <qa-ok> <Launchpad itself:Fix Released by wgrant> <Python:Fix Committed> < https://launchpad.net/bugs/96878 > | 03:57 |
| wgrant | lifeless: Resolution: accepted | 03:58 |
| wgrant | lifeless: tsk tsk, duping your own timeout bugs | 04:02 |
| lifeless | well, blame my short memory | 04:04 |
| wgrant | lifeless: I was hoping the timeout was on +reportedbugs.. | 04:09 |
| lifeless | wgrant: the search works fine... | 04:09 |
| lifeless | wgrant: | 04:09 |
| lifeless | 57 queries/external actions issued in 1.68 seconds | 04:09 |
| lifeless | AJAX Log ↓ | 04:09 |
| lifeless | not the fastest thing under the sun, but working >> not working. | 04:09 |
| lifeless | Can't /setup/ the query though. | 04:09 |
| lifeless | The form DIAF. | 04:09 |
| lifeless | I bet its listing milestones for every project on Launchpad, more or less. | 04:10 |
| wgrant | I made that pretty fast in most cases | 04:10 |
| wgrant | But maybe you're terrible :( | 04:10 |
| lifeless | and doing so super inefficiently. Probably a list of storm objects | 04:10 |
| lifeless | with in | 04:10 |
| lifeless | milestone in milestones: <- trigger the sqlbase __eq__ which is dog slow. | 04:11 |
| lifeless | + quadratic in a list. | 04:11 |
| wgrant | Not that slow | 04:11 |
| lifeless | -bet you- | 04:11 |
| lifeless | yes that slow | 04:11 |
| lifeless | we've had 20s timeouts from that before. | 04:11 |
| lifeless | shortly after new bug subscriptions, if you recall | 04:11 |
| wgrant | Perhaps | 04:12 |
| StevenK | wallyworld, wgrant: https://code.launchpad.net/~stevenk/launchpad/dsp-changelog-timeout/+merge/123880 | 04:34 |
| wgrant | StevenK: Have you recowboyed that to check that the query count is now sanE? | 04:35 |
| StevenK | No, let me that do | 04:37 |
| StevenK | My dyslexia seems strong today | 04:39 |
| StevenK | At least I didn't run make start stop | 04:39 |
| wgrant | Heh | 04:41 |
| wgrant | Huh | 04:41 |
| StevenK | wgrant: 198 -> 51 | 04:42 |
| wgrant | Limit (cost=10000003268.61..10000003269.44 rows=1 width=0) (actual time=122.637..122.637 rows=0 loops=1) | 04:42 |
| wgrant | The main +specworkload query apparently doesn't please postgres very much | 04:42 |
| wgrant | enable_seqscan=0 applies a 10 billion cost penalty | 04:43 |
| wgrant | But that plan still wins | 04:43 |
| StevenK | wgrant: No review? | 04:44 |
| wgrant | StevenK: That wasn't the only extract_bug_numbers callsite? | 04:45 |
| wgrant | (it was) | 04:46 |
| wgrant | Ah | 04:46 |
| wgrant | There's one in stringformatter.py itself | 04:46 |
| StevenK | It's called in stringformatter itself | 04:46 |
| StevenK | Yeah | 04:46 |
| StevenK | I can inline it and stop exporting it if you wish | 04:46 |
| wgrant | Nah | 04:46 |
| StevenK | Probably not worth it | 04:46 |
| wgrant | r=me, thanks | 04:47 |
| wgrant | We still have a few VPC queries, but that's possibly just removedby so I don't really care | 04:47 |
| StevenK | Yeah, we could make the pre-loading smarter by including some of the data from spph | 04:48 |
| wgrant | Not as big an issue as the bugs :) | 04:49 |
| StevenK | Indeed, so it's fine for now | 04:49 |
| wgrant | The page is still slow on DF, but a fair bit of it is probably template time | 04:49 |
| StevenK | And Unity has a TON of SPRs | 04:50 |
| StevenK | Tell me when you're done and I'll revert DF | 04:50 |
| wgrant | I'm done | 04:50 |
| StevenK | Tempted to close 1000257 | 04:55 |
| wgrant | bug #1000257 | 04:55 |
| _mup_ | Bug #1000257: OOPS sending email notification for bug watch <bugwatch> <oops> <Launchpad itself:Triaged> < https://launchpad.net/bugs/1000257 > | 04:55 |
| wgrant | Indeed | 04:56 |
| StevenK | I can't see how it happened, but it did | 04:56 |
| wgrant | StevenK: ndt | 04:59 |
| wgrant | Probably | 04:59 |
| StevenK | wgrant: http://pastebin.ubuntu.com/1199974/ | 05:24 |
| lifeless | StevenK: https://devpad.canonical.com/~lpqateam/ppr/lpnet/ | 05:59 |
| StevenK | wallyworld: Nice easy one for you: https://code.launchpad.net/~stevenk/launchpad/destroy-plus-daily-builds/+merge/123888 | 06:21 |
| StevenK | wallyworld seems to be missing. | 06:31 |
| stub | Been butting my head against pgbouncer. | 07:25 |
| lifeless | stub: oh? | 07:26 |
| stub | Unfortunately, root cause of my problems seems to be that KILL and RESUME just affect if opening new outgoing connections work or not. | 07:26 |
| lifeless | stub: btw your part line is ... fun | 07:26 |
| lifeless | '18:52 -!- stub [~stub@canonical/launchpad/stub] has left #launchpad-dev ["PART #launchpad :PART #postgresql :PART #slony :PART #storm :PART #zope3-dev :ISON cr3 jkakar daniels intellectronica daf czajkowski static SteveA fabbione Ng | 07:26 |
| lifeless | thumper bigjools debonzi BradB bac sinzui_is_awake jdub allenap Znarl chrism andrewv elmo lifeless `a"] | 07:26 |
| lifeless | ' | 07:26 |
| stub | So the timouts for how long until I check if a backend is up, how long I wait for a backend connection, how long a client connection keeps retrying for a backend, all kick in | 07:26 |
| stub | I have no idea what an ISON is | 07:27 |
| lifeless | me neither | 07:27 |
| stub | Anyway, unless I or someone wade into the C code, we might need two pgbouncers to do the updated fdt and actually lower downtime rather than increase it | 07:29 |
| lifeless | stub: sure; how would that work ? | 07:29 |
| stub | I can reduce the timeouts during the window, but to a minimum of 1 second. And that makes a huge difference if we are aiming at <5s | 07:30 |
| stub | lifeless: Instead of KILL and RESUME on individual databases, we have separate pgbouncer instances for master and slave connections and shut them down/start them up | 07:31 |
| stub | But it means a lot more bespoke production crap | 07:31 |
| stub | init scripts etc. | 07:31 |
| stub | And certainly not generalizable for outside of canonical. | 07:32 |
| wgrant | Oh | 07:36 |
| wgrant | I thought we had an alternative to pause that rejected new connections | 07:36 |
| wgrant | But indeed, such a thing does not exist | 07:36 |
| stub | wgrant: We have KILL and PAUSE, and we need KILL in current launchpad because we are running in session mode, not transactional mode | 07:37 |
| wgrant | Right, but we have nothing like PAUSE that doesn't hang | 07:37 |
| wgrant | WHich is what we really need | 07:37 |
| stub | If we were running in transactional mode, yeah. | 07:37 |
| wgrant | Even in session mode | 07:38 |
| stub | But for current LP, the existing connections would never die unless we signalled all the clients 'oi, go reconnect now' | 07:38 |
| wgrant | Right, but KILL serves that purpose already | 07:38 |
| wgrant | We can kill all existing connections easily | 07:38 |
| stub | Yes, so for now KILL does what we need | 07:38 |
| wgrant | We just can't reject new ones claenly | 07:38 |
| stub | KILL rejects new connections | 07:39 |
| wgrant | If we run it constantly, yes | 07:40 |
| stub | The documentation is fuzzy there | 07:40 |
| wgrant | But it's a momentary thing | 07:40 |
| wgrant | It drops all current and pending clients at the moment it's run | 07:40 |
| wgrant | If we PAUSEd and ran kill every 10ms, it would work | 07:40 |
| stub | On my system, KILL keeps it dead until RESUMEd | 07:41 |
| stub | which is why I say the docs are wrong | 07:41 |
| wgrant | I can still connect, it just hangs | 07:41 |
| wgrant | On 1.5.1 | 07:42 |
| wgrant | If I then KILL again, the hung connection drops, as expected | 07:42 |
| stub | $ psql -p 6432 launchpad_dev_master | 07:42 |
| stub | psql: ERROR: pgbouncer cannot connect to server | 07:42 |
| wgrant | That's very interesting | 07:43 |
| wgrant | Do you have a tiny bouncer->server timeout or something? | 07:43 |
| stub | 2012-09-12 14:43:01.020 5838 LOG C-0x1e0d518: launchpad_dev_master/stub@unix:6432 login failed: db=launchpad_dev_master user=stub | 07:43 |
| stub | 2012-09-12 14:43:01.020 5838 LOG S-0x1e2aec8: launchpad_dev_master/stub@unix:5432 closing because: pause mode (age=0) | 07:43 |
| stub | wgrant: oh, you are experiencing the same problem my test case picked up | 07:44 |
| stub | wgrant: After a KILL, the pools don't know that the db is down so keep trying to open connections, and failing because the db is down | 07:44 |
| stub | wgrant: So it keeps retrying for 15 seconds until the 'db is down' flag is set | 07:44 |
| stub | wgrant: And then, after a RESUME, that pool is still stuffed as it only tries to reconnect to a dead db every N seconds. | 07:45 |
| wgrant | Ah, there we go, it does eventually time out | 07:46 |
| wgrant | And now it is dead properly | 07:46 |
| wgrant | So what we really need is a way to force it to poll and time out quickly | 07:46 |
| adeuring | good morning | 08:00 |
| lifeless | transactional mode still woudn't be fast enough, would it ? | 08:01 |
| wgrant | I don't think so | 08:02 |
| wgrant | Ah | 08:11 |
| wgrant | It's pretty easy to make it to do what we want | 08:11 |
| wgrant | Like | 08:11 |
| wgrant | Really easy | 08:11 |
| lifeless | share | 08:13 |
| wgrant | Will have patch in a sec | 08:13 |
| wgrant | Particularly if I don't try to run an amd64 binary on i386 | 08:15 |
| === almaisan-away is now known as al-maisan | ||
| stub | wgrant: I can reduce the timeouts, but it still can add about 2 seconds to the time according to my test case | 08:30 |
| stub | wgrant: Patch welcome though, I hate relearning C everytime I need to do this. | 08:31 |
| wgrant | It all works, except that changing the size of the PgDatabase struct makes it segfault | 08:32 |
| wgrant | Just adding the new unused flag | 08:32 |
| wgrant | Segfault | 08:32 |
| wgrant | But if I reuse one of the existing flags it all works | 08:32 |
| wgrant | Will look further after dinner | 08:32 |
| wgrant | I can't see a hardcoded size anywhere obvious | 08:33 |
| czajkowski | jelmer: when you get a chance can you follow on the Question you were on https://answers.launchpad.net/launchpad/+question/206501 so I can see if it can be closed. | 08:34 |
| czajkowski | cheers | 08:34 |
| wgrant | (it turns out their makefile deps suck, so a make clean fixed it) | 09:02 |
| wgrant | stub: http://pastebin.ubuntu.com/1200173/ | 09:04 |
| wgrant | You currently need a DISABLE/KILL/RESUME then ENABLE sequence | 09:04 |
| wgrant | As disable doesn't actually kill, and kill implicitly pauses | 09:05 |
| lifeless | nice | 09:07 |
| stub | Cool | 09:09 |
| stub | That on github? | 09:10 |
| wgrant | I hate tracking down the official repo on GitHub | 09:10 |
| wgrant | Maybe there's a link somewhere... | 09:10 |
| * wgrant googles | 09:10 | |
| stub | I could argue that KILL should imply DISABLE | 09:11 |
| wgrant | Indeed | 09:11 |
| wgrant | Alternatively KILL could just kill | 09:11 |
| wgrant | and you're expected to PAUSE first | 09:11 |
| stub | yeah, I can take the patch to the mailing list | 09:12 |
| wgrant | https://github.com/markokr/pgbouncer-dev looks like it | 09:12 |
| stub | Unless they use git://git.postgresql.org/git/pgbouncer.git directly | 09:12 |
| wgrant | They do, but the github account is owned by the primary committer | 09:13 |
| wgrant | So it seems relevant | 09:13 |
| * wgrant has forked it | 09:13 | |
| wgrant | I always forget how obtuse git is | 09:19 |
| wgrant | stub: I've revised it a bit, so it now rejects only at client connect time and is not so terrible. https://github.com/wgrant/pgbouncer-dev/compare/disable | 10:58 |
| wgrant | I'll create a pull request if you don't object soon | 10:58 |
| stub | wgrant: Cool. I was going to build a package here to test my test case | 11:00 |
| wgrant | Great | 11:00 |
| stub | (running through the full process before I go and hack up full-update.py) | 11:00 |
| wgrant | You still need the DISABLE/KILL/RESUME, do stuff, ENABLE sequence, but I'll mention improving that on the MP | 11:00 |
| wgrant | If you leave it paused too long it'll still lose the backend connections and hang once you reenable | 11:01 |
| wgrant | But if you resume immediately after killing you can keep it disabled forever | 11:01 |
| wgrant | Also note that DISABLE only forbids new client connections. An existing client connection can still grab a server connection if it hasn't already. I could forbid in find_server as well, but I'm not sure if it's worth it | 11:03 |
| wgrant | Given you need to KILL anyway | 11:03 |
| stub | So htf do I convert https://github.com/wgrant/pgbouncer-dev/compare/disable to a diff? | 11:19 |
| wgrant | stub: You're beyond my GitHub knowledge at this point, I'm afraid | 11:21 |
| wgrant | Let me poke around | 11:21 |
| stub | I guess I'm locked in ;) | 11:22 |
| wgrant | http://pastebin.ubuntu.com/1200362/ | 11:23 |
| Laney | stick ".patch" on the end of that URL | 11:26 |
| wgrant | Ah | 11:26 |
| wgrant | I tried .diff | 11:26 |
| wgrant | But not .patch | 11:26 |
| wgrant | Hm | 11:27 |
| wgrant | .diff works now too | 11:27 |
| wgrant | I must have been on a different URL | 11:27 |
| stub | Because hacking urls is discoverable UI | 11:27 |
| tumbleweed | on commits, .diff and .patch give you different things | 11:27 |
| wgrant | Yeah, .patch gives headers and commit message and stuff | 11:27 |
| stub | Still seems noise to strip | 11:29 |
| stub | oh, guess diff ignores it | 11:29 |
| stub | no, noise to strip. | 11:30 |
| === al-maisan is now known as almaisan-away | ||
| stub | oh no, I'm on 1.5.2, patch is trunk | 11:31 |
| wgrant | There shouldn't be conflicts outside NEWS | 11:31 |
| stub | yeah | 11:32 |
| stub | I just need more coffee | 11:32 |
| stub | built the package, manual tests look good | 11:42 |
| stub | And my updated tests like it too. | 11:48 |
| stub | wgrant: Looks good. | 11:48 |
| wgrant | Great | 11:48 |
| wgrant | My only significant concern is that an evil client could connect but not cause a server connection to be established. | 11:49 |
| wgrant | Then you DISABLE, and wait for connections to disappear from the backend server | 11:49 |
| wgrant | But if you don't KILL, there could still be someone lurking in pgbouncer | 11:49 |
| wgrant | waiting to strike and ruin your day | 11:49 |
| wgrant | (to reproduce, open up a psql session but don't do anything. Call DISABLE in another session, and see that you can still talk in your original session) | 11:50 |
| === gary_poster|away is now known as gary_poster | ||
| wgrant | stub: Hopefully this will be a little less messy (and faster!) than sudoing around multiple instances | 12:07 |
| stub | Oh, much. | 12:07 |
| stub | We will need to KILL anyway after a timeout | 12:08 |
| stub | To catch evil transactions. | 12:08 |
| wgrant | Yeah | 12:08 |
| wgrant | Definitely | 12:09 |
| wgrant | But for the master we will just want to DISABLE and then KILL immediately | 12:09 |
| stub | http://paste.ubuntu.com/1200439/ is the test case for the always-slave process, and it is passing with the new pgbouncer | 12:09 |
| wgrant | Oh, an actual LP test case | 12:10 |
| wgrant | Fancy | 12:10 |
| StevenK | stub: https://code.launchpad.net/~stevenk/launchpad/buildfarmjob-index-redux/+merge/123854 would love a review | 12:13 |
| wgrant | stub: Looks good | 12:13 |
| stub | got the failwhale | 12:15 |
| stub | not even an oops | 12:15 |
| wgrant | 502? | 12:15 |
| wgrant | Huh | 12:15 |
| wgrant | Haven't seen many of those since we switched back to the rightful DB servers | 12:15 |
| stub | StevenK: Didn't we do this already? | 12:16 |
| StevenK | stub: Almost. The previous index did not have status, this one does. The two of them will work in concert for Builder:+history | 12:17 |
| stub | yer | 12:18 |
| StevenK | stub: Builder:+history with the index we added to prod makes it really fast. Builder:+history also allows filtering by status, which is slow. | 12:18 |
| wgrant | Well, slow for uncommon statuses | 12:18 |
| StevenK | Right. | 12:19 |
| StevenK | It's noticibly slower. Like 4 seconds versus 0.4 | 12:19 |
| stub | It it ready for prod or just qastaging? | 12:21 |
| stub | Oh, I'm building this pgbouncer package for precise. I can just copy it to lucid and it will be fine, right? | 12:21 |
| StevenK | I think it should be fine, but I admit to not actually testing it. | 12:22 |
| StevenK | stub: I'm happy to play around on DF tomorrow if you're more comfortable with me having tested it. | 12:22 |
| stub | Just removing it requires a FDT update. Apart from that no real worries applying it to prod. | 12:23 |
| wgrant | stub: I'm not sure if the same binary will work | 12:23 |
| wgrant | We have a ~lucid1 for 1.5.1 atm... | 12:23 |
| === almaisan-away is now known as al-maisan | ||
| stub | So reupload for lucid or make a recipe to work around the limitation | 12:24 |
| wgrant | Exactly | 12:24 |
| stub | StevenK: Its on qastaging | 12:25 |
| StevenK | Let's have a look | 12:25 |
| StevenK | 0.8 hot for main | 12:25 |
| StevenK | 1.3 for FTBFS hot | 12:26 |
| wgrant | SUPERSEDED is more interesting | 12:26 |
| StevenK | 0.9 for depwait hot | 12:26 |
| StevenK | superseded is 2.2 cold, 0.29 hot | 12:27 |
| wgrant | Excellent. | 12:27 |
| wgrant | To production we go. | 12:27 |
| StevenK | How about I land it first? | 12:28 |
| StevenK | :-) | 12:28 |
| StevenK | stub: It's landed as r15944, you can add it to prod at your leisure | 12:31 |
| === abentley changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: - | Firefighting: abentley | Critical bugs: ∞ | ||
| === abentley changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: abentley | Firefighting: - | Critical bugs: ∞ | ||
| abentley | deryck: I'm the OCR. Could you please review https://code.launchpad.net/~abentley/launchpad/spec-creation-info-type/+merge/123821 ? | 13:19 |
| deryck | abentley, sure | 13:19 |
| abentley | deryck: Thanks. | 13:19 |
| deryck | np! | 13:19 |
| === cjohnston_ is now known as cjohnston | ||
| abentley | rick_h_: btw, my enum is lp.registry.enums.PUBLIC_PROPRIETARY_INFORMATION_TYPES | 14:27 |
| rick_h_ | abentley: cool, thanks. Will look at updating that today. | 14:28 |
| sinzui | adeuring, can you comment on bug 839779 and bug 450480 about how to fix them? | 14:41 |
| _mup_ | Bug #839779: HWDB doesn't create HWDeviceClass anymore <hwdb> <regression> <Launchpad itself:Triaged> < https://launchpad.net/bugs/839779 > | 14:41 |
| _mup_ | Bug #450480: Get PCI and USB vendor/product names from the "PCI ID Repository" project and from linux-usb.org respectively <hwdb> <regression> <Launchpad itself:Triaged> < https://launchpad.net/bugs/450480 > | 14:41 |
| * adeuring is looking | 14:42 | |
| adeuring | sinzui: I am a bit lost ATM regarding | 14:50 |
| adeuring | #839779 | 14:50 |
| _mup_ | Bug #839779: HWDB doesn't create HWDeviceClass anymore <hwdb> <regression> <Launchpad itself:Triaged> < https://launchpad.net/bugs/839779 > | 14:50 |
| adeuring | I guess that newer HWDB reports do not contain any data about devices classes anymore. | 14:50 |
| adeuring | but I need to check | 14:51 |
| adeuring | sinzui: regarding bug 450480: WHat do you miss in the bug report? | 14:52 |
| _mup_ | Bug #450480: Get PCI and USB vendor/product names from the "PCI ID Repository" project and from linux-usb.org respectively <hwdb> <regression> <Launchpad itself:Triaged> < https://launchpad.net/bugs/450480 > | 14:52 |
| sinzui | adeuring, why a cronscript? Shouldn't the data be processed correctly when it is uploaded? | 14:52 |
| sinzui | or put another way? I do not understand why hal has that data, but udev does not? | 14:53 |
| adeuring | sinzui: ask the udev developers ;) The data is probably not important enough | 14:54 |
| sinzui | okay. So want a process that gathers the secondary data to provide consistent, historic reporting? | 14:55 |
| adeuring | sinzui: the script that processed the HWDB report can of course also read the two URLs directly | 14:55 |
| adeuring | and use the data. | 14:55 |
| adeuring | but we should also update existing "bad" records. | 14:55 |
| sinzui | okay. and calling out to external site is blocked for most servers | 14:56 |
| adeuring | sinzui: that's a problem indeed... But we might be able to read the data manually form time to time | 14:57 |
| sinzui | understood. The data does not change often, which is why you want to pull it daily or weekly | 14:57 |
| adeuring | sinzui: right. | 14:58 |
| sinzui | okay. I think I know enough to fix this | 14:58 |
| deryck | abentley, your code looks great. well tested and solid. r=me. | 14:58 |
| abentley | deryck: Thanks. | 14:58 |
| adeuring | sinzui: BTW, we wil always have the situation that a report contains a devcie where vendor/product names are yet knwon, even in the two databases mentioned in the bug report. | 14:58 |
| adeuring | I don't know how often these DBs are updated, but we must always expect some lag | 14:59 |
| adeuring | when for example some small vendor sells a new USB mouse | 14:59 |
| * sinzui nods | 14:59 | |
| sinzui | adeuring, what do you need to know about HWDeviceClass in staging's db? | 15:00 |
| sinzui | is there a query I can run? | 15:01 |
| adeuring | sinzui: the existing data itself is not a problem. Just need to check why no nbewer data exists | 15:01 |
| adeuring | sinzui: after looking a bit more at the output of "udevadm info --export-db" I still have no idea why HWDeviceClass is not updated. Could be a bug in the processing the reports. On the other hand, it would make sense to check if the data from recent submissions really has no links to HWDeviceClass records. After all, the set of device _classes_ is rather small compared with the number of different device models: A USB mouse is is a USB mou | 15:13 |
| adeuring | so it might even be a "non-bug" | 15:13 |
| sinzui | okay. I will look into this. | 15:14 |
| sinzui | adeuring, who uses the the hwdb now? | 15:14 |
| adeuring | sinzui: I have no idea... ask cr3 | 15:15 |
| sinzui | oh, I did | 15:15 |
| adeuring | or flacoste | 15:15 |
| sinzui | he uses the XML only | 15:15 |
| cr3 | adeuring: ogasawara still uses the hardware db | 15:15 |
| adeuring | ah, right | 15:15 |
| rick_h_ | abentley: quick ok on the change over to your enum please? https://code.launchpad.net/~rharding/launchpad/updated_product_allowed_types/+merge/123987 | 15:20 |
| abentley | rick_h_: r=me. | 15:21 |
| rick_h_ | abentley: thanks | 15:22 |
| === dpm is now known as dpm-afk | ||
| === al-maisan is now known as almaisan-away | ||
| === deryck is now known as deryck[lunch] | ||
| === dpm-afk is now known as dpm | ||
| === matsubara is now known as matsubara-lunch | ||
| sinzui | jcsackett, do you have a few moments to discuss Bug #810664 | 17:03 |
| _mup_ | Bug #810664: Specification:+index asserts - (from_node, to_node) not in self.edges <oops> <regression> <Launchpad itself:Triaged> < https://launchpad.net/bugs/810664 > | 17:03 |
| jcsackett | sinzui: sure. | 17:17 |
| === dpm is now known as dpm-afk | ||
| sinzui | jcsackett, http://pastebin.ubuntu.com/1200924/ | 17:21 |
| sinzui | jcsackett, I just got my replacement router. I am going to drop off the net for a bit | 17:37 |
| === deryck[lunch] is now known as deryck | ||
| === matsubara-lunch is now known as matsubara | ||
| === dpm-afk is now known as dpm | ||
| deryck | abentley, I have two branches related to specification_sharing_policy if you have the bandwidth to review them. | 18:54 |
| abentley | deryck: Sure. | 18:54 |
| deryck | abentley, thanks. see.... | 18:55 |
| deryck | https://code.launchpad.net/~deryck/launchpad/specification-sharing-policy-unused/+merge/124021 | 18:55 |
| deryck | and | 18:55 |
| deryck | https://code.launchpad.net/~deryck/launchpad/specification-sharing-policy-garbo/+merge/124026 | 18:55 |
| abentley | deryck: The allowed types for SpecificationSharingPolicy.PUBLIC, SpecificationSharingPolicy.PUBLIC_OR_PROPRIETARY, SpecificationSharingPolicy.PROPRIETARY_OR_PUBLIC look incorrect because they include InformationType.PRIVATESECURITY, InformationType.USERDATA, InformationType.PUBLICSECURITY | 19:02 |
| abentley | deryck: In the definition of setSpecificationSharingPolicy, can we use IProductPublic.specification_sharing_policy directly instead of copying it? | 19:05 |
| deryck | abentley, sorry was on call with flacoste | 19:17 |
| deryck | abentley, so to the first question, sorry about that. copied from branch which I thought would be the same. I'll take another pass at that. | 19:18 |
| abentley | deryck: Cool. | 19:18 |
| deryck | abentley, as for the copy, I did this exactly like bug and branch sharing policy. both of those copied. So I didn't question it. | 19:18 |
| deryck | I don't know if there's some reason it needs the copy honestly. and I was just playing it safe. | 19:19 |
| abentley | deryck: I had a grovel through copy_field recently, and it seems like its only purpose is to let you change attributes (like readonly). So give it a try without the copy and I bet it will work. | 19:20 |
| deryck | abentley, ok, will do. I can change the other places too and try them. | 19:20 |
| abentley | deryck: Should your branch also be defining default values for the policies? I don't see that. | 19:22 |
| abentley | deryck: Bugs has lp.bugs.interfaces.bugtarget.BUG_POLICY_DEFAULT_TYPES for example. | 19:23 |
| deryck | abentley, right. | 19:23 |
| deryck | abentley, so I didn't realize those were needed until the two methods coming in the final branch. | 19:23 |
| deryck | abentley, I have them in that, but can bring them up to this branch if it makes more sense. | 19:23 |
| abentley | deryck: No, that's fine as long as it's in the plan. | 19:24 |
| deryck | abentley, ok, cool. | 19:24 |
| abentley | deryck: Do you think there should be a policy that permits PUBLIC, PROPRIETARY and EMBARGOED? | 19:47 |
| deryck | abentley, on TL call, just a minute and I'll consider that. | 19:50 |
| jcsackett | quit | 19:58 |
| deryck | don't do it jcsackett! it will be better tomorrow, I'm sure. ;) :) | 20:02 |
| deryck | abentley, ok, thinking on that now.... | 20:02 |
| jcsackett | deryck: :-P | 20:02 |
| lifeless | sinzui: do you need a link to the zconfig bug ? | 20:03 |
| sinzui | I saw it yesterday in my browser | 20:04 |
| sinzui | lifeless, it affect lp and zope right, and I think fred was the reviewer? | 20:04 |
| deryck | abentley, so what use case are you thinking of? Starting public, but shifting to either of the other two later? or something else? | 20:04 |
| lifeless | sinzui: yes | 20:05 |
| lifeless | sinzui: that sounds right | 20:05 |
| sinzui | lifeless, send me the bug, as my history does not want to reveal it | 20:06 |
| abentley | deryck: No, I guess I was just thinking that we wouldn't want to prevent people using Embargoed from doing everything else that people using Proprietary can do. | 20:06 |
| lifeless | sinzui: abel took a stab at it, but sadly only ended up moving the issue around, we didn't understand quite what was going on. | 20:06 |
| lifeless | bug 481512 | 20:06 |
| _mup_ | Bug #481512: race condition when rotating logs <canonical-losa-lp> <lp-foundations> <qa-untestable> <Launchpad itself:Triaged> <ZConfig:Fix Released by fdrake> < https://launchpad.net/bugs/481512 > | 20:06 |
| abentley | deryck: I don't have a use case really, unless people other than PES use Embargoed. | 20:06 |
| sinzui | yes, I saw the branch apparently. thank you lifeless | 20:09 |
| lifeless | sinzui: de nada | 20:09 |
| lifeless | sinzui: thank *you* | 20:09 |
| abentley | deryck: We are famous now: http://feedproxy.google.com/~r/d0od/~3/3xNeugsEvpU/ubuntu-12-10-login-screen-adds-remote-desktop-access | 20:12 |
| deryck | abentley, nice! | 20:14 |
| deryck | abentley, I hope they have that server beefed up more than we did. ;) | 20:14 |
| abentley | :-) | 20:14 |
| abentley | deryck: Could you please review https://code.launchpad.net/~abentley/launchpad/fix-banner/+merge/124052 ? | 20:33 |
| deryck | abentley, absolutely. | 20:33 |
| deryck | abentley, should you be a bit more specific in the test? to make sure that the phrase is actually in the banner, and not somewhere else in browser.contents. | 20:39 |
| abentley | deryck: I can do that. | 20:39 |
| deryck | abentley, ok, cool. other that that, looks great. I like the IInformationType approach. | 20:39 |
| abentley | deryck: Great. I considered extending IPrivacy, but I saw that there are circumstances where we know whether it's private, but not what the information_type is. | 20:40 |
| deryck | abentley, right. and r=me officially now on the mp. | 20:41 |
| abentley | deryck: Thanks. | 20:41 |
| deryck | np! | 20:41 |
| abentley | deryck: r=me on the first one. | 20:59 |
| deryck | abentley, thanks! | 21:02 |
| lifeless | sinzui: can I hand that branch off entirely ? | 21:12 |
| sinzui | okay | 21:12 |
| sinzui | It is now mine | 21:12 |
| lifeless | sinzui: thanks, much appreciated. | 21:12 |
| === matsubara is now known as matsubara-afk | ||
| wgrant | StevenK: OOPS-2bf590b755c7e5cd89893f05cfb1eb91 | 23:13 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!