| wgrant | StevenK: rvb has two pending items on https://devpad.canonical.com/~lpqateam/qa_reports/deployment-db-stable.html -- could you please try to QA those? | 04:00 |
|---|---|---|
| === wgrant changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: - | Critical bugs:208 - 0:[######=_]:256 | ||
| wallyworld | wgrant: the work you are doing on product picker - have you made any changes to ProductVocabulary in vocabularies.py? | 04:03 |
| LPCIBot | Project windmill-db-devel build #364: STILL FAILING in 1 hr 7 min: https://lpci.wedontsleep.org/job/windmill-db-devel/364/ | 04:03 |
| wgrant | wallyworld: Just http://paste.ubuntu.com/619573/ | 04:04 |
| wallyworld | wgrant: thanks. i'm looking at altering the json so that exact matches (or matches above a certain ranking) are returned in a separate attribute so that if there are "too many" we can stil display the exact ones | 04:06 |
| wallyworld | bug 255282 | 04:07 |
| _mup_ | Bug #255282: project name picker search / vocabulary is hard/impossible to use (too many results on exact searches) <disclosure> <lp-registry> <project-picker> <projects> <Launchpad itself:Triaged by wallyworld> < https://launchpad.net/bugs/255282 > | 04:07 |
| wgrant | wallyworld: Probably better to limit? | 04:07 |
| wgrant | wallyworld: That's what that diff does. | 04:07 |
| wgrant | wallyworld: It ranks exact matches first, then by FTI, and limits as well. | 04:07 |
| wallyworld | wgrant: ah yes, i didn't see the limit | 04:08 |
| wgrant | Limiting in the current implementation is bad, because it ranks by displayname. | 04:08 |
| wallyworld | in that case, that bug is moot | 04:08 |
| wgrant | But ordering by rank makes limiting sensible. | 04:08 |
| wallyworld | yes agreed | 04:08 |
| wallyworld | i spent some time cleaning up a fix previously landed which didn't work properly :-( | 04:09 |
| wgrant | Oh? | 04:09 |
| wallyworld | there was one recently to deal with the picker handling too many matches but it was all wrong (i didn't do the fix, just cleaned it up :-) | 04:10 |
| wgrant | Ah, right, I remember that one. | 04:10 |
| wallyworld | wgrant: so i should assign that bug to you since your change deals with the problem | 04:11 |
| wgrant | wallyworld: Probably, yeah. I think this two line change solves most of the product picker problems. | 04:11 |
| wallyworld | ok. you can link a few bugs to your branch :-) | 04:11 |
| wgrant | Yup. | 04:12 |
| wgrant | The prettification is a separate, more complicated beast. | 04:12 |
| wgrant | wallyworld: The link doesn't seem to do anything. | 04:13 |
| wgrant | The one you just landed. | 04:13 |
| wgrant | And the spacing is off. | 04:13 |
| wallyworld | works for me? | 04:13 |
| wallyworld | your sure your browser is not blocking popups? | 04:14 |
| wgrant | Which browser? | 04:14 |
| wallyworld | i use ff4 | 04:14 |
| wgrant | Ew, popups? | 04:14 |
| wallyworld | well the browser says its a popup but it's a window.open(...) call | 04:14 |
| wallyworld | and i have mine set up to open in a new tab | 04:15 |
| wgrant | Hm, then it shouldn't be green. | 04:15 |
| wgrant | Green means an inline thing. | 04:15 |
| wallyworld | well, i was told to make it green | 04:15 |
| wgrant | href is not defined | 04:15 |
| wgrant | When I try it in Firefox 4. | 04:15 |
| wallyworld | green meaning "this link doesn't kill the current page" | 04:15 |
| wallyworld | ? | 04:15 |
| wallyworld | i'll have another look, but it worked when I tested before ec2'ing | 04:16 |
| wgrant | Hmm. Where is href defined? | 04:16 |
| wgrant | I think you might have meant data.alt_title_link | 04:16 |
| wallyworld | i need a bit more context. let me open the branch | 04:16 |
| wgrant | window.open(href) is failing, since href is not defined. In the 'if (data.alt_title)' branch. | 04:17 |
| wgrant | Anyway, it's all behind flags, so it doesn't really matter much right now. | 04:18 |
| wallyworld | that sucks. yes, it is broken. not sure how i let that happen. | 04:18 |
| wallyworld | i'll fix | 04:18 |
| wgrant | Thanks. | 04:18 |
| wgrant | We should also huwshimi about the link style, I think. | 04:18 |
| wgrant | It looks a bit odd being in the parenthesised section. | 04:19 |
| wallyworld | sure. i'll do what i am told :-) i wanted to make it something different but was told the styles are fixed and not easily changed | 04:19 |
| wgrant | Well, it's easier to change now it's there. | 04:20 |
| wgrant | The hard bit is doen :) | 04:20 |
| wallyworld | yep | 04:20 |
| wgrant | wallyworld: Did you intend to reuse the commit message? | 04:31 |
| wgrant | I see you did that on lazr-js a few times too. | 04:31 |
| wgrant | It's rather confusing. | 04:31 |
| wallyworld | probably should have changed it | 04:31 |
| wallyworld | didn't think you would be looking so closely at it | 04:32 |
| wgrant | I read most diffs, so I can keep track of what's going on and hit people when they introduce security holes :) | 04:33 |
| wallyworld | fair enough :-) | 04:36 |
| LPCIBot | Project windmill-devel build #171: STILL FAILING in 1 hr 10 min: https://lpci.wedontsleep.org/job/windmill-devel/171/ | 04:36 |
| LPCIBot | Project windmill-devel build #172: STILL FAILING in 45 min: https://lpci.wedontsleep.org/job/windmill-devel/172/ | 05:22 |
| === almaisan-away is now known as al-maisan | ||
| === al-maisan is now known as almaisan-away | ||
| jtv | Who's up for a pre-imp chat? | 07:47 |
| LPCIBot | Project windmill-db-devel build #365: STILL FAILING in 1 hr 9 min: https://lpci.wedontsleep.org/job/windmill-db-devel/365/ | 07:52 |
| jtv | lifeless: got another fun problem that I'd love to discuss with you — creating multiple Jobs in one query. | 07:59 |
| wgrant | jtv: lifeless isn't here today. | 07:59 |
| jtv | Ah blast | 07:59 |
| wgrant | jtv: But that's always fun. | 07:59 |
| jtv | Yes | 07:59 |
| wgrant | I think you have to use strings. | 07:59 |
| wgrant | That's what I do, at least. | 07:59 |
| wgrant | eg. in PublishingSet.publishBinaries | 07:59 |
| jtv | You mean, SQL strings? | 08:00 |
| wgrant | Ja. | 08:00 |
| jtv | That's not really the problem I'm pondering though. | 08:00 |
| jtv | I never really assumed that Storm would support what I wanted directly. The real questions is how to make this work well API-wise. | 08:00 |
| jtv | It seems easy: extend IJobSource with a createMultiple() that returns an iterable of job ids. | 08:01 |
| jtv | Then feed those into job-type-specific equivalents of createMultiple(). | 08:01 |
| jtv | The part I dislike is how some IJobSource-derivatives operate on Job, and classes implemented purely in that table; and others like to refer to other tables that in turn refer to Job. | 08:02 |
| jtv | So IJobSource.createMultiple() would end up in job utilities that are expected to return something else than Job. | 08:03 |
| lifeless | I would like to delete 'Job' | 08:03 |
| jtv | You're not here. | 08:03 |
| jtv | Shoo. | 08:03 |
| lifeless | its a generally poor pattern for sql to do inheritance like that | 08:04 |
| lifeless | I pass through | 08:04 |
| jtv | Not using direct inheritance support in the DB does make things feel very awkward and old-fashioned, | 08:04 |
| jtv | almost like inheritance in JavaScript. | 08:05 |
| jtv | Maybe we should've just used db-native table inheritance. :) | 08:05 |
| lifeless | well | 08:06 |
| lifeless | I would have done code inheritance but not db inheritance | 08:06 |
| lifeless | for most jobs there isn't anything in common, but we've created a bottleneck as it stands | 08:07 |
| wgrant | :( | 08:13 |
| lifeless | by analogy, why don't we have a base *table* with the id column :> | 08:14 |
| wgrant | Indeed. | 08:14 |
| wgrant | Also, why does the test suite and staging update take so long :( | 08:14 |
| wgrant | And why does something conflicting with db-devel have to have just landed :( | 08:15 |
| jtv | The answer, my friend, is blowing in the wind. | 08:15 |
| jtv | lifeless: you're right though — design of our jobs is driven by commonality of contents, not commonality of purpose. | 08:16 |
| jtv | It'd be nice if we could at least have a pattern along the lines of "put everything in the json metadata, but we can also duplicate data that needs to be searchable in proper columns." | 08:17 |
| jtv | I think I need to keep multi-job creation out of IJobSource because it isn't even a utility interface; it's an interface definition pur sang. | 08:19 |
| adeuring | good morning | 08:22 |
| jtv | hi adeuring | 08:24 |
| adeuring | hi jtv! | 08:24 |
| === henninge changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: henninge | Critical bugs:208 - 0:[######=_]:256 | ||
| rvba | wgrant: Hi, I'm in the progress of QAing r10636. | 08:53 |
| wgrant | rvba: And r10641? | 08:54 |
| rvba | wgrant: yes, that too | 08:55 |
| wgrant | Thanks. | 08:55 |
| wgrant | rvba: Have you talked to Stevenk? | 08:55 |
| StevenK | At length. | 08:55 |
| rvba | wgrant: Yes I have ... | 08:55 |
| mrevell | Happy Monday | 08:56 |
| wgrant | Heh | 08:56 |
| rvba | Hello mrevell! | 08:56 |
| LPCIBot | Project windmill-devel build #173: STILL FAILING in 1 hr 10 min: https://lpci.wedontsleep.org/job/windmill-devel/173/ | 09:11 |
| === jtv1 is now known as jtv | ||
| LPCIBot | Project windmill-db-devel build #366: STILL FAILING in 1 hr 14 min: https://lpci.wedontsleep.org/job/windmill-db-devel/366/ | 09:30 |
| jelmer | wgrant: hi | 10:04 |
| wgrant | jelmer: Hello. | 10:06 |
| jelmer | wgrant: you mentioned in #bzr you were QA'ing some of the bugs in my newer-bzr branch; are you still working on that and/or is there something I can help with? | 10:08 |
| wgrant | jelmer: I tried a few things on qastaging, but I'll probably need to do importds on staging tomorrow, since qastaging doesn't have any. | 10:09 |
| wgrant | (and it's not on staging yet) | 10:09 |
| * wgrant -> food | 10:10 | |
| jelmer | ah, ok | 10:10 |
| jelmer | wgrant: if you need any help, you know where to find me :) | 10:15 |
| === almaisan-away is now known as al-maisan | ||
| wgrant | jelmer: Yup, thanks. | 10:27 |
| wgrant | rvba: How's it going? | 10:54 |
| rvba | wgrant: good so far, I've found a bug. | 10:55 |
| rvba | wgrant: is this blocking you in any way? | 10:55 |
| wgrant | rvba: This is potentially disastrous. | 10:56 |
| wgrant | rvba: We need to merge db-stable into devel today. | 10:56 |
| wgrant | What's the bug? | 10:56 |
| rvba | wgrant: a simple UI bug. | 10:56 |
| wgrant | In +initseries? | 10:56 |
| rvba | yes | 10:56 |
| wgrant | Ah, OK, fine then. | 10:56 |
| rvba | Nothing disastrous :) | 10:56 |
| wgrant | I'd like to do the merge in the next 30 minutes. | 10:57 |
| wgrant | To catch the next devel run. | 10:57 |
| wgrant | So it'd be great if you could have the QA done by then. | 10:57 |
| rvba | Since the changes in question are (like always) derivation related ... I suppose we could mark these bug QAok. | 10:58 |
| rvba | s/bug/bugs/ | 10:58 |
| wgrant | Well, they also have the potential to break Ubuntu initialisation, but yeah, that's a while off. | 10:58 |
| wgrant | So if you can't get them done soon, qa-ok it is. | 10:58 |
| rvba | wgrant: that's right, they have potential to break ubuntu init ... I think StevenK is checking these changes very seriously. | 10:59 |
| rvba | StevenK: I suppose +initseries won't be used "for real" right now, the only dangerous thing is the initialisation of ubuntu. what is the conclusion of your conversation with Julian this morning about this? Will you check the ubuntu initialisation? | 11:02 |
| rvba | wgrant: We found another bug in initialisedistroseriesjob ... if you pass packagesets=None the job will fail because of the way parameters are passed inside a metadata attribute. | 11:12 |
| rvba | It will be very easy to fix but it's a stupid bug. | 11:13 |
| rvba | https://bugs.launchpad.net/launchpad/+bug/793434 | 11:13 |
| _mup_ | Bug #793434: Passing packagesets=None triggers an error when initializing a series. <derivation> <Launchpad itself:In Progress by rvb> < https://launchpad.net/bugs/793434 > | 11:13 |
| rvba | wgrant: I suppose I should wait for you to merge db-stable into devel and then fix this in devel ...? | 11:15 |
| === al-maisan is now known as almaisan-away | ||
| wgrant | rvba: Probably, yes. We'll merge shortly, then be frozen until QA'd past the merge. | 11:18 |
| wgrant | Which will be tomorrow some time. | 11:18 |
| rvba | Ok, I'll get the fix ready then. | 11:19 |
| wgrant | Thanks. | 11:20 |
| wgrant | rvba: So, can we qa-ok them? | 11:31 |
| rvba | wgrant: I *just* did. | 11:31 |
| rvba | Right in time I suppose ;) | 11:31 |
| wgrant | Heh. | 11:31 |
| wgrant | Thanks. | 11:31 |
| === almaisan-away is now known as al-maisan | ||
| bigjools | I wish make schema would do just exactly that, not a million other things | 12:25 |
| stub | bigjools: I use 'make -C database/schema' | 12:25 |
| bigjools | stub: do you know why the top-level Makefile's schema target depends on build then? | 12:27 |
| * henninge lunches | 12:27 | |
| stub | bigjools: Don't know. Technically that is correct I guess, since we need /bin/py built and stuff, so the problem is that 'make build' is too busy | 12:28 |
| maxb | Also that 'make build && make schema' re-does bits of the build | 12:28 |
| bigjools | ah, that Makefile uses bin/py ... :/ | 12:30 |
| stub | probably something to do with wadl depending on *.py... perhaps that should only rebuild if explicitly asked or if it is non-existent | 12:30 |
| bigjools | jeebus, the test failure attachments are huge now | 12:30 |
| stub | Yer... all those librarian logs... | 12:31 |
| bigjools | and SQL now it seems | 12:31 |
| stub | that I suspect are not reset between tests... | 12:31 |
| wgrant | Hmm. | 12:32 |
| wgrant | schema doesn't need build. | 12:32 |
| wgrant | Just compile. | 12:32 |
| wgrant | Which is much smaller, and runs OK with -j3. | 12:32 |
| === wgrant changed the topic of #launchpad-dev to: devel is release-critical until r13163 deployable | https://dev.launchpad.net/ | On call reviewer: henninge | Critical bugs:208 - 0:[######=_]:256 | ||
| bigjools | that was slower than -j2 last time I checked | 12:34 |
| wgrant | ... bah. | 12:34 |
| stub | What does 'orphaned' mean on the qa'd patch deployment report | 12:35 |
| stub | ? | 12:35 |
| wgrant | stub: You used [testfix] when you shouldn't have. | 12:36 |
| wgrant | I decided it was safe to deploy, since it passed buildbot and seems harmless. | 12:36 |
| wgrant | So it is in devel now. | 12:36 |
| wgrant | staging seems happy enough, so if it's not OK please yell really really soon. | 12:39 |
| stub | That branch lifelesslanded would be qa-untestable anyway. Nothing is using the new table yet, so the fallout would be in related areas that don't cope with the triggers. | 12:44 |
| wgrant | stub: Yep. | 12:51 |
| bigjools | have we got a run_jobs.py cronned in on staging? | 12:56 |
| jtv | hi henninge! Can I trouble you for a review? https://code.launchpad.net/~jtv/launchpad/db-bug-793382/+merge/63545 | 13:05 |
| * henninge tries not to let anything trouble him ... | 13:05 | |
| jtv | Is that good or bad? :) | 13:06 |
| henninge | jtv: sure, I am happy to look at your review. ;-) | 13:06 |
| jtv | \o/ | 13:06 |
| henninge | good for me, saves me the troubling. | 13:06 |
| henninge | s/at your review/at your proposal/ | 13:07 |
| gmb | flacoste: Can I get an RC for https://code.launchpad.net/~gmb/launchpad/bug-772609-hopefully-without-breaking-anything-this-time/+merge/63432? It should have landed Friday night but bounced due to a [testfix]. | 13:10 |
| wgrant | gary_poster: Morning. | 13:16 |
| gary_poster | morning wgrant | 13:17 |
| wgrant | gary_poster: You're still planning to release the new subscriptions stuff during the downtime deploy this week? | 13:17 |
| gary_poster | or evening, sorry | 13:17 |
| wgrant | (the bugmail footer change is in devel now, so will be deployed unless it's reverted) | 13:17 |
| wgrant | (but we still have the strucsub listing regression, so I'm not sure) | 13:18 |
| gary_poster | wgrant, yes | 13:18 |
| wgrant | Great. | 13:18 |
| gary_poster | (the structsub listing thing has branches to be addressed--that also rip out the feature flags--after at least a day or two of making sure that the subscriptions stuff is ok when exposed to everyone) | 13:19 |
| wgrant | OK. We've only had a few complaints about its absence, so I guess it's not too bad. | 13:20 |
| gary_poster | cool | 13:20 |
| wgrant | Despite the mild security implications. | 13:20 |
| gary_poster | wgrant, security? Do "other subscribers" affect visibility of private bugs? | 13:21 |
| wgrant | gary_poster: No. But people inevitably mistakenly put private info in public bugs, and want to know who it was emailed out to. | 13:22 |
| wgrant | Hopefully that's less common now. | 13:22 |
| gary_poster | ah, k. | 13:22 |
| wgrant | gmb: Hmm, I'm not sure who can grant r-c these days. Since there's no RM... | 13:23 |
| gmb | Hmm. | 13:23 |
| gmb | Traditionally it was flacoste, lifeless or <RM>. So I guess we have to wait on one of the other two. Or maybe gary_poster can sign off on it. | 13:24 |
| wgrant | This seems pretty clearly necessary and really wants to land in the next 3 hours, or I will be sad tomorrow. | 13:24 |
| gmb | Yes. | 13:24 |
| * gary_poster has vague memories of team leads having privs like this? | 13:24 | |
| wgrant | It hasn't been used since the RM position was abolished, | 13:25 |
| gmb | gary_poster: Let's say that your memories are right :) | 13:25 |
| wgrant | Heh. | 13:25 |
| gary_poster | :-) | 13:25 |
| stub | Because we are minimizing the stuff that *has* to rollout during downtime deployment. Does this come with a db patch? | 13:25 |
| gary_poster | gmb, ok, I'll go fiddle with the MP then | 13:25 |
| gmb | stub: No. | 13:25 |
| * gary_poster waits... | 13:25 | |
| wgrant | stub: Yeah, this is the issue with deploying features at the same time. | 13:25 |
| wgrant | Which lifeless is vehemently against. | 13:26 |
| gmb | stub: But if stuff is rolled out without this, we will have breakages. | 13:26 |
| gmb | And that will make both wgrant and I go <sadface> | 13:26 |
| wgrant | This release prep is chaotic enough already, let's not make it worse by delaying this. | 13:27 |
| gary_poster | stub, barring your quick strong objection, I'll approve | 13:27 |
| stub | Sure. Might want to make that clear to Francis and/or robert then | 13:27 |
| stub | I don't object, not that it would matter if I did :) | 13:27 |
| gary_poster | heh, I dunno | 13:28 |
| stub | I would wonder if not landing it could be worked around by just disabling the feature using a flag, which also isn't clear from the MP | 13:28 |
| gary_poster | gmb, rc approved with all the authority of my title behind it ;-) | 13:29 |
| gmb | Cool, thanks. | 13:29 |
| stub | Its actually pretty awesome the last few releases haven't needed RC's... | 13:30 |
| stub | Used to be a truck load of 'OMG its broken' fixes picked up by last minute QA | 13:30 |
| wgrant | Well, given that we deploy stuff every couple of days, there's less space for stuff to explode. It's been working pretty well! | 13:30 |
| lifeless | stub: wgrant: gary_poster: FWIW I think 'rc-approval' is fine from squad leads | 13:40 |
| lifeless | I'm not sure we -need- an rc-approval bit other than 'this has to be landed to make the downtime safe' | 13:41 |
| gary_poster | cool, thanks lifeless | 13:41 |
| gary_poster | and agreed | 13:41 |
| gary_poster | a team review approval seems pretty good to me | 13:41 |
| lifeless | this is fixing the anonymous viewing of bug pages right ? | 13:41 |
| lifeless | gary_poster: re: releasing the new subscription stuff - thats slated for Monday right ? | 13:42 |
| wgrant | It has to be Thursday, I think :/ | 13:42 |
| wgrant | The bugmail footer change is not flagged. | 13:42 |
| lifeless | why ? | 13:42 |
| wgrant | So it will be deployed on Thursday. | 13:42 |
| wgrant | Unless that page works for everyone? | 13:42 |
| gary_poster | lifeless, correct. we had the flag discussion on the bug tracker, I think | 13:42 |
| lifeless | I think we should wait for an hour or two after the deploy before setting the flag | 13:43 |
| lifeless | or monday per gary_poster's comment just now ;) \o/ | 13:43 |
| gary_poster | no no | 13:43 |
| gary_poster | I was agreeing with wgrant | 13:43 |
| lifeless | ok | 13:43 |
| gary_poster | we can wait, but then there will be a couple of hours in which the links will point to a page without valuable info | 13:43 |
| gary_poster | page will appear | 13:44 |
| lifeless | sure | 13:44 |
| gary_poster | but no info | 13:44 |
| lifeless | lets just wait ~1 hour - enough time to see that nothing else is truely messed up | 13:44 |
| gary_poster | I'm fine with that | 13:44 |
| lifeless | if something is, we can open the flag wide and know its not the flags fault | 13:44 |
| lifeless | vice versa, if it looks good and we open the flag wide and it falls over, we know it probably is the flag. | 13:45 |
| lifeless | anyhoo... its now late, so gnight all :) | 13:45 |
| gary_poster | sounds good lifeless. 'night | 13:45 |
| === wgrant changed the topic of #launchpad-dev to: devel is release-critical until r13164 deployable | https://dev.launchpad.net/ | On call reviewer: henninge | Critical bugs:208 - 0:[######=_]:256 | ||
| wgrant | Night lifeless. | 13:47 |
| LPCIBot | Project windmill-db-devel build #367: STILL FAILING in 1 hr 7 min: https://lpci.wedontsleep.org/job/windmill-db-devel/367/ | 13:49 |
| deryck | adeuring, henninge -- ping for standup. | 14:00 |
| LPCIBot | Project windmill-devel build #174: STILL FAILING in 1 hr 7 min: https://lpci.wedontsleep.org/job/windmill-devel/174/ | 14:01 |
| henninge | deryck: yup | 14:01 |
| henninge | X crash. Unity? | 14:02 |
| deryck | reboot, brb | 14:08 |
| gary_poster | mrevell, hi. are you going to be around to give some UI opinions in the next half hour or so if I send you some screen shots? | 14:22 |
| mrevell | gary_poster, Yes, certainly. | 14:22 |
| gary_poster | mrevell, thank you | 14:22 |
| mrevell | np :) | 14:22 |
| henninge | jtv: reviewed | 14:22 |
| jtv | Thanks! | 14:22 |
| jtv | henninge: apologizing for not finding anything wrong may be going a bit far :) | 14:23 |
| henninge | .... | 14:23 |
| henninge | yeah, let me see if I can find something wrong, then | 14:24 |
| jtv | uh-oh | 14:24 |
| henninge | jtv: the indentation of the parenthesis on line 319 and 332 looks strange ... but I may be wrong. | 14:27 |
| henninge | same on line 350 | 14:27 |
| henninge | jtv: there you go! ;) | 14:27 |
| jtv | Thank you, that's better. :) | 14:27 |
| jtv | The indentation looks a bit weird there because we rarely open a parenthesis on a line of its own. | 14:28 |
| jtv | In this case though I do think it makes sense. | 14:28 |
| henninge | yeah, I guess I was wrong, then ... | 14:28 |
| henninge | well, actually I wasn't as we agree about the strangeness. | 14:29 |
| jtv | I'm not sure there's any perfect answer. | 14:29 |
| jtv | I generally like what I think is GNU style, with opening and closing braces identically indented. | 14:29 |
| === flacoste changed the topic of #launchpad-dev to: devel is release-critical until r13163 deployable | https://dev.launchpad.net/ | On call reviewer: henninge | Critical bugs:208 - 0:[######=_]:256 | ||
| flacoste | gary_poster: you probably want to land your bug 792493 branch on devel once PQM gets out of RC-mode | 14:38 |
| _mup_ | Bug #792493: Creating a structural subscription for a team with a preferredemail makes a mute link that oopses <oops> <Launchpad itself:Triaged by gary> < https://launchpad.net/bugs/792493 > | 14:38 |
| flacoste | gary_poster: also, i downgraded the revision to deploy to 13163 since that's the one that include the merge, your other RC can be deploy nodowntime afterward | 14:39 |
| flacoste | so it's not a blocker per se i think | 14:39 |
| wgrant | It is unless we want to delay the unflagging for hours and have bugmail links broken. | 14:39 |
| wgrant | We cannot turn the flag on by default without 13164. | 14:40 |
| gary_poster | flacoste, what wgrant said. My branch is not that important, but his is | 14:40 |
| === flacoste changed the topic of #launchpad-dev to: devel is release-critical until r13164 deployable | https://dev.launchpad.net/ | On call reviewer: henninge | Critical bugs:208 - 0:[######=_]:256 | ||
| flacoste | ok, makes sense | 14:41 |
| flacoste | shouldn't be a big problem | 14:41 |
| gary_poster | cool | 14:41 |
| flacoste | anybody took care of the conflicts yet? | 14:41 |
| wgrant | I can prepare a branch if you want, but it's pretty trivial. | 14:42 |
| wgrant | Since you can just take the files from devel. | 14:43 |
| flacoste | yeah, no problem | 14:43 |
| wgrant | There's only three. | 14:43 |
| wgrant | flacoste: We'll be remerging db-stable tomorrow once devel reopens anyway. | 14:44 |
| wgrant | So no need to reland it on devel. | 14:44 |
| flacoste | yep | 14:45 |
| gary_poster | mrevell, mail sent (with two screenshots inline; hope that's not too annoying) | 14:45 |
| mrevell | Thanks gary_poster, looking now. Not at all annoying :) | 14:46 |
| gary_poster | cool :-) | 14:46 |
| nigelb | Does running launchpad impair the ability for my apache to server php? | 15:00 |
| wgrant | nigelb: rocketfuel-setup installs apache2-mpm-worker, and PHP isn't threadsafe so it must be removed. But LP works fine with apache2-mpm-prefork instead of -worker, so you should be able to install libapache2-mod-php5 again. | 15:03 |
| wgrant | (it will remove -worker and install -prefork) | 15:03 |
| nigelb | wgrant: I tried that and it ended with an unsucessfull install, but its fine. I'll just use nginx :) | 15:03 |
| wgrant | nigelb: What went wrong? | 15:05 |
| wgrant | I've done it in the past. | 15:05 |
| LPCIBot | Project windmill-devel build #175: STILL FAILING in 1 hr 9 min: https://lpci.wedontsleep.org/job/windmill-devel/175/ | 15:10 |
| nigelb | wgrant: dpkg failures | 15:14 |
| wgrant | nigelb: Huh. | 15:24 |
| flacoste | jelmer: were you able to QA the bzr upgrade? | 15:41 |
| deryck | henninge, I see you saw I marked bug 410864 as related. I agree it looked like a dupe too... | 15:47 |
| _mup_ | Bug #410864: 'choose a source package' suggests undefined when search has too many results <qa-ok> <Launchpad itself:Fix Committed by henninge> < https://launchpad.net/bugs/410864 > | 15:47 |
| deryck | henninge, but I thought I'd be cautious and leave it separate since the widget was used differently. | 15:48 |
| henninge | deryck: argh! | 15:48 |
| henninge | deryck: I just read the bug properly. It is not the same bug and it is not fixed. | 15:49 |
| henninge | Actually, I had wondered about what is described there while fixing the bug. | 15:49 |
| deryck | henninge, I walked through the steps in the bug on qastaging and had a nice list of packages to choose from. over 35 steps, IIRC. | 15:50 |
| deryck | 35 steps in the results picker, I mean | 15:51 |
| * henninge has to try this now | 15:51 | |
| === salgado is now known as salgado-lunch | ||
| henninge | deryck: :( | 16:01 |
| deryck | Why the frown? | 16:01 |
| henninge | deryck: qa-bad | 16:01 |
| deryck | ah sadness indeed. How is it bad? | 16:01 |
| henninge | deryck: It broke the check for picker with search boxes. | 16:02 |
| deryck | I don't get meaning of "the check for picker with search boxes" | 16:02 |
| henninge | hm | 16:02 |
| deryck | henninge, how is it broken? Sorry to be dumb. | 16:02 |
| henninge | I just got a result box with 220 batches. | 16:03 |
| henninge | deryck: https://bugs.qastaging.launchpad.net/ubuntu/+source/linux/+bug/687392 | 16:03 |
| _mup_ | Bug #687392: Kernel panic with 2.6.32-26 security upgrade <Linux:Confirmed> <linux (Ubuntu):Incomplete> < https://launchpad.net/bugs/687392 > | 16:03 |
| deryck | heh a ha! | 16:03 |
| henninge | deryck: edit "Linux" and enter "linux" into the search box. | 16:04 |
| deryck | I see it now. | 16:04 |
| deryck | only 220 pages! :) | 16:04 |
| henninge | deryck: Unfortunately I have to leave really soon and have no time to fix or rollback. | 16:05 |
| deryck | henninge, so depending on where we are in the qa process, i.e. if qa-ok revisions ahead of you, which is likely. I'd still leave it qa ok and do a follow on fix.... | 16:05 |
| deryck | henninge, it's a corner case that this many results will turn up normally. and ugly, big corner case. but at least the inital bug is fixed and the picker is usable... | 16:06 |
| deryck | if ugly. | 16:06 |
| henninge | oookaaay | 16:06 |
| deryck | henninge, so either constrain the widget width, or limit the number of pages we show. is anything beyond 40-50 pages useful? | 16:07 |
| henninge | deryck: the limit is 20 | 16:07 |
| henninge | deryck: I removed it for Robert's special case but unfortunately it leaked into other cases it seems. | 16:07 |
| deryck | henninge, right, but you could only display 20 and not limit on 20. | 16:08 |
| henninge | deryck: I filed two other bugs for a proper fix. | 16:08 |
| henninge | I think they are linked from my mp? | 16:08 |
| henninge | deryck: I will fix this tomorrow and maybe include a fix for bug 410864. | 16:09 |
| _mup_ | Bug #410864: 'choose a source package' suggests undefined when search has too many results <Launchpad itself:In Progress by henninge> < https://launchpad.net/bugs/410864 > | 16:09 |
| deryck | henninge, great, thanks. | 16:10 |
| deryck | though I'm still not clear why 410864 isn't fix since we just looked at 220 results on that page. ;) | 16:10 |
| deryck | but we can talk about it tomorrow. | 16:10 |
| sinzui | I am 2 hours into my day. I am already burned. No doubt because I worked 3 days to see progress. | 16:15 |
| sinzui | 1. We do not need a special JS for linting/evaluating. I can make seed do it | 16:15 |
| sinzui | 2. I can run YUI tests without firefox, or any browser, I do not require a database or the web server. The test runner still needs xvfb, | 16:15 |
| sinzui | jcsackett: do you have time to talk? | 16:17 |
| jcsackett | sinzui: sure, but one moment. i need to reboot. | 16:18 |
| jelmer | flacoste: wgrant said we'd have to wait until staging gets updated as it has a importd we can use for testing | 16:20 |
| jcsackett | sinzui: back, calling you now. | 16:21 |
| flacoste | jelmer: don't we have a bazaar.qastaging ? i'm sure we can test at least basic bzr functionality there | 16:22 |
| jelmer | flacoste: the basic bzr functionality we can test there - and that works, but all the bugs associated with my branch require running of a importd with the new code | 16:23 |
| flacoste | jelmer: staging is running 10647 and you require 10649 right? | 16:24 |
| jelmer | flacoste: what branch are those revno's for? | 16:27 |
| flacoste | jelmer: db-stable, that's what staging runs, i see that your stable landing was merged on db-stable at 10649 | 16:28 |
| jelmer | (on another note, why are there 5 people with recipes that build lp:~launchpad-pqm/launchpad/stable) | 16:28 |
| jelmer | flacoste: ah, yep | 16:29 |
| flacoste | jelmer: recipe: i hav eno idea | 16:30 |
| flacoste | people trying to autobuild launchpad .deb? | 16:30 |
| maxb | Oh dear. That's an impressive lack of clue | 16:31 |
| bigjools | yet hilarious at the same time | 16:31 |
| jelmer | I guess.. none of them merge in any packaging branches though, so that's doomed to fail | 16:31 |
| maxb | It's about as ridiculous as requesting subversion code imports from bazaar.launchpad.net, which people also seem to do from time to time | 16:32 |
| jelmer | maxb: we should fix that by just letting them enter a URL and Doing The Right Thing | 16:33 |
| maxb | But, what is The Right Thing? | 16:33 |
| maxb | It's not even clear what they are hoping to achieve | 16:34 |
| jelmer | maxb: In some cases I guess a mirror (if it's a bzr branch elsewhere), if they're trying to import from bazaar.launchpad.ent we should tell them to "bzr branch && hack && bzr push" | 16:34 |
| jelmer | maxb: I think they're looking for the fork button | 16:34 |
| maxb | Could be | 16:35 |
| maxb | On a related note, we could use a "Do you really want to be doing this?" banner for people entering questions on Launchpad itself | 16:36 |
| maxb | Back on the code import issue, I think https://code.launchpad.net/+code-imports/+new is wrong to default to Subversion | 16:37 |
| maxb | It should default to nothing and force you to pick one | 16:37 |
| jelmer | maxb: we should not require you to specify the VCS at all, just let you enter a URL | 16:37 |
| maxb | Hm. I am of the opinion that there is no point writing the code to do that, because if a user can't even figure out what VCS they are importing from, they don't deserve an import :-) | 16:38 |
| flacoste | maxb: that's a little harsh :-) | 16:39 |
| flacoste | maybe they onbly care about bzr | 16:39 |
| flacoste | whatever, just give me a bzr repo | 16:39 |
| flacoste | ! | 16:39 |
| jelmer | maxb: *I* would appreciate having to click one radio button less for each import | 16:40 |
| jelmer | if we have the data we shouldn't bother to ask our users for it | 16:40 |
| === al-maisan is now known as almaisan-away | ||
| flacoste | jelmer: staging is updating now, should be available in ~90 minutes | 16:49 |
| jelmer | flacoste: great - thanks :) | 16:52 |
| rvba | bac: Hi ... I'm not sure I should have done it this way, but I created another branch ("a rebased" version of the branch you've been reviewing) so that it targets devel. | 17:02 |
| rvba | bac: sorry to bother you with that, but perhaps you could review/approve it ...? | 17:02 |
| rvba | https://code.launchpad.net/~rvb/launchpad/init-multiple-parents-bug-777120-devel/+merge/63572 | 17:02 |
| === deryck is now known as deryck[lunch] | ||
| === matsubara is now known as matsubara-lunch | ||
| === salgado-lunch is now known as salgado | ||
| === deryck[lunch] is now known as deryck | ||
| === matsubara-lunch is now known as matsubara | ||
| LPCIBot | Project windmill-devel build #176: STILL FAILING in 1 hr 17 min: https://lpci.wedontsleep.org/job/windmill-devel/176/ | 18:33 |
| === henninge changed the topic of #launchpad-dev to: devel is release-critical until r13164 deployable | https://dev.launchpad.net/ | On call reviewer: - | Critical bugs:208 - 0:[######=_]:256 | ||
| timrc | wgrant, I might be seeing a regression of https://bugs.launchpad.net/launchpad/+bug/750640 | 19:29 |
| _mup_ | Bug #750640: If the source version differs from the binary version, it is not specified in the Package index for that binary <oem-services> <qa-ok> <soyuz-publish> <Launchpad itself:Fix Released by wgrant> < https://launchpad.net/bugs/750640 > | 19:29 |
| maxb | timrc: It's 4:30am in Melbourne... | 19:30 |
| timrc | maxb, $1 USD says he has logging enabled and will see it when he wakes up | 19:31 |
| timrc | wgrant, nm, I think I misread comment #2 | 19:51 |
| lifeless | morning y'all | 20:30 |
| === bigjools-afk is now known as bigjools | ||
| lifeless | flacoste: yo | 21:12 |
| flacoste | hi lifeless | 21:13 |
| mwhudson | jelmer: does launchpad no longer depend on pysvn? | 21:16 |
| mwhudson | (i guess cscvs still does) | 21:16 |
| === lifeless changed the topic of #launchpad-dev to: Performance Tuesday! | devel is release-critical until r13164 deployable | https://dev.launchpad.net/ | On call reviewer: - | Critical bugs:208 - 0:[######=_]:256 | ||
| mwhudson | hm, it seems the update of sourcedeps.cache depends on dictionary order | 21:28 |
| abentley | mwhudson: yes, that's likely. | 21:28 |
| mwhudson | shall i file a bug? | 21:29 |
| abentley | mwhudson: But I thought it would only perform the update if the data had changed. | 21:29 |
| mwhudson | ah | 21:29 |
| abentley | mwhudson: I experienced a bug this morning where it said the cache had been updated, so I'm now no longer sure that's right. | 21:30 |
| mwhudson | i think that's what it just did to me | 21:30 |
| abentley | mwhudson: Okay, what did it do? Are the cache files the same data in different orders? | 21:31 |
| mwhudson | abentley: it looks at a quick glance as if it will update the cache if any branches were updated, not if any branch ended up with a different tip than that in the cache | 21:32 |
| mwhudson | so i think if i revert and run update-sourcecode again, it will not be changed | 21:32 |
| mwhudson | abentley: yeah | 21:32 |
| abentley | mwhudson: okay, that's useful. | 21:33 |
| jelmer | mwhudson: hi | 21:33 |
| jelmer | mwhudson: cscvs indeed still does, and there codehosting code also still uses oo_svn | 21:33 |
| mwhudson | jelmer: ah well | 21:33 |
| mwhudson | i guess hypothetically we could kill off the remaining cscvs-svn imports and then delete all the svn code from cscvs | 21:34 |
| mwhudson | but well, fails to beat the effort/reward test i guess | 21:35 |
| jelmer | mwhudson: yeah, probably | 21:35 |
| jelmer | mwhudson: I was going to ask the other day - the codeimport workers don't have direct/API access to the database, right? | 21:35 |
| mwhudson | jelmer: no | 21:36 |
| mwhudson | the machines still do, for sodding oops-prune | 21:36 |
| jelmer | mwhudson: I was looking at bug 432217, I guess that's a fair bit harder in that case | 21:37 |
| _mup_ | Bug #432217: Import branches have auto-format upgrade disabled <code-import> <lp-code> <tech-debt> <Launchpad itself:In Progress by jelmer> < https://launchpad.net/bugs/432217 > | 21:37 |
| jelmer | mwhudson: it seems though, that at least for bzr-{git,svn,hg} branches we could just nuke the branch if it's in an old format rather than bothering with upgrading? | 21:38 |
| mwhudson | jelmer: yes, for deterministic imports that's totally the way to go | 21:38 |
| mwhudson | for the others, ugh, i guess there's no good answer really | 21:38 |
| mwhudson | jelmer: we can give the machines access to the db again if we want, but i've always regarded them as a bit more likely to get compromised than the average machine | 21:39 |
| jelmer | the code has a FIXME saying a upgrade job should be created, though I wonder how that would have to happen (XML-RPC request??) | 21:39 |
| mwhudson | (i seem to be more paranoid than most people about this) | 21:39 |
| mwhudson | uhh | 21:39 |
| mwhudson | a branchupgradejob wouldn't help | 21:39 |
| mwhudson | because of the storage of the import branches on escudero | 21:39 |
| mwhudson | so if you upgraded the branch on crowberry, it would just get downgraded again the next time the import puller ran | 21:40 |
| jelmer | ah, urgh | 21:40 |
| mwhudson | (the real answer to this side of things is to have the code import worker have some kind of token-mediated access to crowberry that allows write access to exactly one branch) | 21:40 |
| mwhudson | i think on staging the code import worker can write to any branch on the codehost in effect | 21:41 |
| mwhudson | this doesn't seem like a good idea for prod :) | 21:41 |
| jelmer | :) | 21:43 |
| jelmer | I'll have a look at nuking the bzr-{hg,svn,git} branches; we can nuke and recreate cscvs-based svn import branches | 21:44 |
| jelmer | that just leaves CVS imports | 21:44 |
| jcsackett | sinzui: did you ping me earlier? | 21:45 |
| sinzui | jcsackett: no, but a kitten may have. She slept on my keyboard during lunch | 21:46 |
| jcsackett | sinzui: dig. the cats are after your computer again. | 21:46 |
| sinzui | jcsackett: I just approved your yui test branch | 21:50 |
| mwhudson | jelmer: wow the ratio of failed to running says something here: https://lpstats.canonical.com/graphs/CodeImportsCVSBreakdown/ | 21:50 |
| jcsackett | sinzui: cool, thanks. | 21:53 |
| jelmer | garr, I thought my internet connection was just bad today | 22:07 |
| jelmer | mwhudson: oh, wow (those colors are.. unusual) | 22:08 |
| mwhudson | jelmer: sysadmins are not visual designers, usually :p | 22:08 |
| jelmer | mwhudson: while you're here.. am I correct in thinking that the code import workers don't have any access to e.g. information on what the development focus for a project is? | 22:12 |
| mwhudson | jelmer: yes, that's true too | 22:12 |
| mwhudson | it's not hard to arrange to pass more information along though | 22:12 |
| mwhudson | (are you thinking about stacking?) | 22:12 |
| jelmer | mwhudson: yes, exactly | 22:12 |
| cr3 | if I add a new method to the restful api, do I need to add @operation_for_version("beta")? | 22:16 |
| * timrc would think "devel" would be a more appropriate version *duck* | 22:18 | |
| lifeless | devel | 22:19 |
| cr3 | timrc: I'm thinking "not backward compatible == beta", "backward compatible == devel" | 22:20 |
| lifeless | beta *was* a beta | 22:20 |
| lifeless | it is not now | 22:20 |
| lifeless | ignore it | 22:20 |
| lifeless | you want for devel | 22:20 |
| lifeless | mwhudson: jelmer: those machines are not getting db access. | 22:21 |
| timrc | can the suggestion that gets spit at you if you do not include @operation_for_version be changed to suggest 'devel' rather than 'beta'? I stumbled upon this recently as well and some head scratching ensued | 22:21 |
| mwhudson | ah, now we have someone who is as paranoid as me apparently | 22:21 |
| lifeless | timrc: patches gratefully... | 22:21 |
| timrc | lifeless, =) | 22:22 |
| jelmer | lifeless: fair enough | 22:22 |
| mwhudson | lifeless: has the access they have for oops-prune been removed then? | 22:23 |
| timrc | lifeless, hey while you're here... I did not really have a reviewer for https://code.launchpad.net/~timrchavez/launchpad/set_ppa_private_from_api_724740-2 -- I discussed some w/ bigjools, though... should I just add the next on call reviewer to the merge proposal ? | 22:23 |
| jelmer | can it be that launchpad is firewalled by sourceforge? | 22:24 |
| mwhudson | jelmer: in the past they've been happy with us doing what we do, but it's possible for sure | 22:25 |
| lifeless | mwhudson: I thought that went *out* to them / was a different DB | 22:26 |
| lifeless | timrc: ping them here if you can | 22:26 |
| lifeless | jelmer: mwhudson: so its not for security I don't want the importds talking to the DB | 22:27 |
| lifeless | rather its that long running processes with DB access have a history of terrible transaction handling. | 22:27 |
| lifeless | these things have no call to know about our DB schema. | 22:27 |
| lifeless | and if they did, downtime deploys would get that much harder. | 22:27 |
| flacoste | after merging devel i have an error with sprite generation: | 22:33 |
| flacoste | KeyError: u'../images/mute.png' | 22:33 |
| flacoste | any ideas? | 22:33 |
| flacoste | ok, make clean solved the issue | 22:35 |
| LPCIBot | Project windmill-db-devel build #368: STILL FAILING in 1 hr 7 min: https://lpci.wedontsleep.org/job/windmill-db-devel/368/ | 22:46 |
| === matsubara is now known as matsubara-afk | ||
| lifeless | back | 23:02 |
| thumper | what's with all the failing import emails? | 23:39 |
| thumper | there seems to be an uncharacteristically large number of them | 23:40 |
| mwhudson | thumper: maybe this is related? <jelmer> can it be that launchpad is firewalled by sourceforge? | 23:40 |
| thumper | haha | 23:40 |
| thumper | maybe | 23:40 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!