| sinzui | huwshimi: mumble? | 00:01 |
|---|---|---|
| huwshimi | sinzui: Sure | 00:02 |
| lifeless | sinzui: added; please give another once-over. Thanks! | 00:04 |
| lifeless | hmm | 00:33 |
| lifeless | how does the lp wiki get wikinames these days? | 00:33 |
| lifeless | SSO or LP ? | 00:33 |
| * sinzui wants to know that answer | 00:33 | |
| sinzui | we can close about 8 bugs id LP is not involved | 00:33 |
| lifeless | hloeung: hi | 00:33 |
| hloeung | lifeless: Hi | 00:34 |
| lifeless | we're wondering how dev.launchpad.net gets its wikinames for users logging in via openid | 00:34 |
| lifeless | is it via the SSO service | 00:34 |
| lifeless | or via LP | 00:34 |
| wgrant | lifeless: Wikinames? Doesn't it just use usernames? | 00:34 |
| wgrant | It's not like the old days of the Ubuntu wiki. | 00:35 |
| lifeless | well, consult - https://dev.launchpad.net/UserPreferences | 00:35 |
| wgrant | Hm? | 00:35 |
| lifeless | if someone does a timestamp | 00:35 |
| lifeless | it uses their wikiname | 00:35 |
| lifeless | but there is no ui to set it | 00:36 |
| wgrant | Hmm, true. | 00:36 |
| lifeless | so presumbably its coming from openid or *something* | 00:36 |
| NCommander | wgrant: so I'm trying to poke dominator to handle my arch_any_all skew test case, and I'm really concerned about performance. To determine if a skew has happened, we need to query each SPH for a given binary package, and check to see what has published where. That's not going to be DB friendly ... | 00:36 |
| wgrant | But it gets it through SSO, which doesn't expose wikinames. | 00:36 |
| wgrant | Maybe it just uses displayname. | 00:36 |
| lifeless | we're about to delete wikinames from lp | 00:36 |
| lifeless | if that table is replicated to sso | 00:36 |
| wgrant | It's not. | 00:36 |
| lifeless | I can imagine Bad Things Happening | 00:36 |
| wgrant | \d lp_<TAB> | 00:36 |
| lifeless | NCommander: indeed. That would be fail. | 00:37 |
| NCommander | Right | 00:37 |
| wgrant | NCommander: What is the algorithm you are using? | 00:37 |
| wgrant | We do far worse queries in the dominator now. | 00:37 |
| NCommander | wgrant: I haven't written one yet | 00:37 |
| NCommander | wgrant: well, for each BPPH, I need the SPH to grab the binary packages it generates, and then checks the dependencies to see if they would still be satisifiable if a package was marked SUPERSEDED | 00:38 |
| wgrant | NCommander: I don't think you can sensibly parse dependencies. | 00:39 |
| wgrant | NCommander: that is going to be terribly slow. | 00:39 |
| lifeless | if they are modelled in the db we can do it | 00:39 |
| lifeless | recursive query | 00:39 |
| cody-somerville | wgrant, why does it have to be slow? | 00:40 |
| lifeless | cody-somerville: death by a thousand cuts | 00:40 |
| NCommander | Ideally, I want LP to make sure the archive is in an installable state | 00:40 |
| lifeless | NCommander: you might like to look at the conflictchecker schema | 00:40 |
| cody-somerville | NCommander, There are tools that exist that do just that. | 00:40 |
| NCommander | cody-somerville: your not catching the point | 00:40 |
| lifeless | NCommander: it handles in-db dependency queries to answer some very similar questions | 00:40 |
| NCommander | The archive should NEVER be uninstallable as it disrupts image building on ports architectures | 00:41 |
| lifeless | FWIW I agree | 00:41 |
| NCommander | lifeless: right, but conflictchecker isn't run once an hour like the publisher :-) | 00:41 |
| wgrant | NCommander: The publisher is run every 5 minutes. | 00:41 |
| * NCommander coughs | 00:41 | |
| lifeless | NCommander: no, but it can handle a single package change in typically 50-100ms | 00:41 |
| wgrant | The primary archive publisher is a special case. | 00:41 |
| NCommander | lifeless: the dominator does the entire archive at once. Not on a per package basis. Given we have 17-20k binary packages, that's going to add up | 00:42 |
| NCommander | fast | 00:42 |
| wgrant | NCommander: Not quite. | 00:42 |
| lifeless | NCommander: you don't need to recheck things that aren't changing. | 00:42 |
| wgrant | NCommander: I think they will still transition from Published->Superseded as normal. | 00:42 |
| lifeless | NCommander: you need to check the implication of things that *are* changing. | 00:42 |
| wgrant | NCommander: But Superseded will be included in indices, until removal is scheduled. | 00:43 |
| wgrant | NCommander: judgeSuperseded will implement this logic. | 00:43 |
| NCommander | wgrant: as it stands, shouldn't it be PUBLISHED if it should be in the index? | 00:43 |
| wgrant | NCommander: It examines Superseded but uncondemned publications. It needs to implement this extension. | 00:43 |
| wgrant | NCommander: Yes, but we are not talking about as it stands :) | 00:43 |
| NCommander | At the risk of making a lot of pain for myself, but it might be saner to have a new PUBLISHED_SUPERSEDED status | 00:45 |
| wgrant | Why? | 00:45 |
| NCommander | instead of making SUPERSEDED now be inconsistant w.r.t. to something publishing status | 00:45 |
| wgrant | All tools can now handle multiple versions in the indices. | 00:45 |
| wgrant | Since Debian does it. | 00:45 |
| NCommander | yes, but if I look at all SUPERSEDED packages, I no longer have an idea what may or may not be held in archive. | 00:45 |
| NCommander | er, in the indices | 00:46 |
| NCommander | Ideally, PUBLISHED_SUPERSEDED should also include a reason on why it hasn't left the incidies | 00:46 |
| wgrant | The idea is that everything on disk will be in the indices. | 00:46 |
| lifeless | stuff in superseded is on disk, right ? | 00:46 |
| NCommander | So then SUPERSEDED should simply always be in the indicies. | 00:47 |
| NCommander | until it reaches its execution time. | 00:47 |
| wgrant | lifeless: Partly. | 00:47 |
| wgrant | lifeless: status = SUPERSEDED AND dateremoved IS NOT NULL is on disk. | 00:47 |
| wgrant | GRAR | 00:47 |
| wgrant | s/NOT // | 00:47 |
| NCommander | wgrant: won't that become DELETED on the next publisher run? | 00:48 |
| wgrant | NCommander: No. | 00:48 |
| wgrant | Superseded/Deleted/Obsolete are all final states. | 00:48 |
| wgrant | Superseded == package was superseded | 00:48 |
| wgrant | Deleted == package was explicitly deleted | 00:48 |
| wgrant | Obsolete == series went obsolete. | 00:48 |
| NCommander | Ah | 00:49 |
| NCommander | So as I read domination, the only thing that tells LP is something is SUPERSEDED is if it pops multiple versions of a given package | 00:49 |
| NCommander | That check needs to be made smarter | 00:49 |
| lifeless | huh, no | 00:49 |
| wgrant | Why? | 00:49 |
| NCommander | bah | 00:51 |
| NCommander | sorry | 00:51 |
| NCommander | my brain seized | 00:51 |
| NCommander | so if I'm following you, the 'correct' solution is to have everything that is SUPERSEDED end up in the indicies until its execution time, and then modify deathrow to be smarter about what packages it brings death to. | 00:53 |
| NCommander | am I in the right ballpark? | 00:53 |
| * wallyworld grumpy. no coffee yet so far today. must rectify | 00:54 | |
| wgrant | NCommander: Until its *condemnation* time. | 00:54 |
| wgrant | Removing it at the time of execution would leave stuff 404ing a lot. | 00:54 |
| wgrant | We have no maintenance people around right now, do we? | 00:55 |
| wgrant | lifeless: ^^? | 00:55 |
| NCommander | Well, then the most straightforard thing to start off with is implementing that SUPERSEDED packages stay in indicies and fixing whatever breaks from that, then make deathrow smarter | 00:55 |
| lifeless | wgrant: in this tz atm ? I think not. | 00:55 |
| wgrant | lifeless: :( | 00:56 |
| lifeless | maybe brad or someone. | 00:56 |
| wgrant | lifeless: There are unlanded cowboys :( | 00:56 |
| lifeless | they can be reapplied in a pinch | 00:56 |
| lifeless | which sucks butwhatare yougoingtodo | 00:56 |
| wgrant | Or we just exclude germanium this time. | 00:56 |
| lifeless | right | 00:56 |
| * NCommander makes a new LP branch for changing how SUPERSEDED is handled | 00:58 | |
| wgrant | NCommander: We probably want to talk to Julian before you start on anything like this. | 01:00 |
| NCommander | wgrant: fair enough. What time zone is he in? | 01:00 |
| wgrant | NCommander: He's UK | 01:00 |
| wgrant | So BST. | 01:01 |
| wgrant | Yay, I can self-review without lifeless killing me now. | 01:02 |
| NCommander | right, so I will see him in ~8 hours | 01:02 |
| wgrant | NCommander: I hope not. | 01:02 |
| NCommander | wgrant: ?, that would be at the start of his day | 01:04 |
| lifeless | wgrant: I would never kill you :) | 01:05 |
| wgrant | NCommander: Yes, but the middle of your night. | 01:05 |
| wgrant | Hmm. | 01:06 |
| wgrant | Is my connection dodgy, or is LP sending empty responses? | 01:06 |
| NCommander | wgrant: well, that's hat caffiene is for, but hopefully he will be up when I get up (and that your timezone overlaps somewhere in there) | 01:07 |
| wgrant | Overlap between the three of us is just about impossible. | 01:07 |
| wgrant | Maybe late my evening. | 01:08 |
| wgrant | Hm. | 01:40 |
| wgrant | ShipIt is inactive, but the bugs are still open? | 01:41 |
| wgrant | sinzui: Can we delete mailing-list-experts? | 01:43 |
| wgrant | sinzui: It's not a celebrity any more, and its only related artifact is the deleted mailing-list-beta-testers | 01:43 |
| wallyworld | wgrant: you have some changes to lazr-js for the picker entry rendering? i need to hack in the same area - i want to extract out the picker entry rendering to a method that can be overridden. if you are done i can merge in your branch before i start hacking | 02:33 |
| wallyworld | or i can take just your lazr-js changes for the affiliation rendering work and go with that | 02:35 |
| wgrant | wallyworld: Heh, no, the lazr-js changes are terrible hacks that need to be rewritten. And they're tiny. So you do your stuff, and I'll rework on top of that when you're done. | 02:41 |
| wallyworld | ok. thanks | 02:41 |
| LPCIBot | Project windmill-devel build #159: STILL FAILING in 1 hr 6 min: https://lpci.wedontsleep.org/job/windmill-devel/159/ | 02:59 |
| timrc | StevenK, hey... where are you guys pulling python-testtools from? I'm not seeing 0.9.11-r189 on pypi (at least sudo easy_install "testtools>0.9.10" is not finding it) and I don't see it getting built in Ubuntu, either | 02:59 |
| lifeless | its not released yet I don't think | 03:00 |
| lifeless | __version__ = (0, 9, 11, 'dev', 0) | 03:01 |
| lifeless | timrc: thats a snapshot | 03:01 |
| lifeless | timrc: its in the lp download cache | 03:01 |
| timrc | lifeless, ah... rocketfuel-get is my friend | 03:18 |
| jtv | hi folks | 03:22 |
| wgrant | Morning jtv. | 03:22 |
| lifeless | u | 03:30 |
| lifeless | hi jtv | 03:30 |
| jtv | hi | 03:31 |
| jtv | what does the "u" stand for? | 03:31 |
| lifeless | jtv: bigjools suggested we have a call w.r.t. the persona discussion - I'd be delighted to do that sometime today if you want. | 03:31 |
| lifeless | jtv: 'u' - up in gmail. | 03:31 |
| jtv | ewin? | 03:31 |
| lifeless | yup | 03:31 |
| jtv | :) | 03:31 |
| jtv | Julian also suggested that we chat about another problem, but since I haven't had my coffee yet I can't even speak coherently about it | 03:32 |
| lifeless | well there is no rush | 03:32 |
| lifeless | I'm still in my workday for at least another 1.5 hours, and probably significantly more | 03:32 |
| jtv | Knowing you, you'll probably throw in another 17 of overtime. | 03:34 |
| lifeless | yeah | 03:34 |
| lifeless | I just won't feel guilty about wandering off during those hours :) | 03:34 |
| jtv | Good! | 03:34 |
| jtv | Well, I've made a note of the time and will definitely get that coffee first. | 03:35 |
| wgrant | lifeless: Good plan to try GPGHandler first. | 04:13 |
| jtv | lifeless: the coffee is kicking in. Yes, I'd be delighted to have a chat about the persona thing if you still have time! | 04:32 |
| lifeless | sure thing | 04:32 |
| jtv | lifeless: mumble? | 04:35 |
| wgrant | lifeless hates freedom. | 04:36 |
| lifeless | jtv: do you have canonical voip? | 04:36 |
| lifeless | jtv: failing that skype ? | 04:36 |
| lifeless | mumble to here is frankly terrible | 04:36 |
| jtv | I don't have the voip thing, no… let me start skype. | 04:36 |
| StevenK | wgrant: O hai. Where does one get testr? | 05:23 |
| spiv | StevenK: from lp:testrepository, or packaged in https://launchpad.net/~testing-cabal/+archive/archive | 05:25 |
| wgrant | StevenK: apt:testrepository | 05:25 |
| wgrant | Fail, gnome-terminal doesn't link that. | 05:26 |
| wgrant | apt://testrepository | 05:26 |
| wgrant | Still fail. | 05:26 |
| wgrant | Anyway, it's in the primary archive. | 05:26 |
| StevenK | spiv, wgrant: Ta | 05:35 |
| === almaisan-away is now known as al-maisan | ||
| === Ursinha is now known as Ursinha-afk | ||
| StevenK | Is anyone available to review? | 06:09 |
| wgrant | StevenK: What's up? | 06:10 |
| StevenK | wgrant: https://code.launchpad.net/~stevenk/launchpad/notify-announce-list/+merge/63067 | 06:11 |
| wgrant | You've probably had enough of my reviews lately, though. | 06:11 |
| StevenK | Haha | 06:11 |
| wgrant | Aha. | 06:11 |
| StevenK | This is a hopefully 1: short, 2: safe | 06:11 |
| wgrant | Yeah. | 06:12 |
| wgrant | It's not the branch I thought it was. | 06:12 |
| StevenK | No, Julian subverted me. | 06:12 |
| wgrant | StevenK: You've not cleaned up archiveuploader. Your point is invalid. | 06:14 |
| wgrant | You can wipe announcelist out of archiveuploader entirely, AFAICT. | 06:14 |
| StevenK | wgrant: I had not done so because I wasn't sure how much test fallout there would be. | 06:15 |
| wgrant | Test fallout is better than tech debt in the most tech debty part of the tech debt that is our codebase. | 06:15 |
| StevenK | wgrant: Let me wave the axe around more. | 06:15 |
| wgrant | Thankyou sir. | 06:15 |
| * StevenK tries to remember where else he saw it | 06:17 | |
| wgrant | lib/lp/archiveuploader/uploadpolicy.py should be all that's left. | 06:18 |
| wgrant | Except maybe tests. | 06:18 |
| wgrant | But there probably aren't tests. | 06:18 |
| wgrant | Because this is archiveuploader. | 06:18 |
| wgrant | Ah, no, uploadpolicy.txt tests it vaguely. | 06:19 |
| StevenK | I've just cleaned that up by removing the *ugly* property | 06:19 |
| wgrant | Yup. | 06:19 |
| StevenK | However, I can recall something that took announce_list as an argument | 06:19 |
| wgrant | acceptFromQueue? | 06:19 |
| wgrant | notify? | 06:19 |
| StevenK | lib/lp/soyuz/browser/queue.py perhaps | 06:19 |
| * StevenK looks | 06:19 | |
| wgrant | A whole lot of other stuff which was sick and wrong? | 06:19 |
| StevenK | Let me see if the test you mentioned is broken first | 06:20 |
| StevenK | I changed the file already, so finding it is a simple matter of grep | 06:21 |
| LPCIBot | Project windmill-devel build #160: STILL FAILING in 1 hr 9 min: https://lpci.wedontsleep.org/job/windmill-devel/160/ | 06:21 |
| StevenK | wgrant: It was soyuz/scripts/queue.py | 06:25 |
| wgrant | :( | 06:25 |
| StevenK | I've cleaned it up too | 06:25 |
| wgrant | StevenK: Done. | 06:33 |
| StevenK | wgrant: Is http://pastebin.ubuntu.com/615643/ better? | 06:38 |
| wgrant | Worse. | 06:39 |
| wgrant | That linewrap makes me sad. | 06:40 |
| wgrant | There's a reason I did it the other way :) | 06:40 |
| StevenK | Sure, but distroseries.changeslist is longer :-) | 06:40 |
| wgrant | If you must have the BACKPORTS line wrap, put it on a separate line and indent it. | 06:41 |
| wgrant | Complex conditions want to be readable :( | 06:42 |
| StevenK | wgrant: http://pastebin.ubuntu.com/615644/ | 06:42 |
| wgrant | StevenK: At that point you might as well just move the whole thing on to a new line. | 06:43 |
| wgrant | No parentheses, and it's clearer. | 06:43 |
| wgrant | But that is better :) | 06:44 |
| StevenK | wgrant: http://pastebin.ubuntu.com/615645/ | 06:44 |
| wgrant | StevenK: Looks great, thanks. | 06:44 |
| StevenK | Excellent. I've also eradicated announce list from queue.py and its tests, so I'll toss it at ec2. | 06:45 |
| wgrant | Perfect. | 06:45 |
| StevenK | wgrant: Also, not arguing about my changes? What, are you sick? :-P | 06:46 |
| wgrant | This is a largely unoffensive cleanup :) | 06:47 |
| StevenK | Tis not large enough for my liking | 06:47 |
| StevenK | wgrant: Oh, was that your first code review? | 06:47 |
| StevenK | (As opposed to code*) | 06:47 |
| wgrant | Well, apart from the one yesterday where lifeless graduated me so he didn't have to find a mentor, yes. | 06:48 |
| StevenK | Haha | 06:48 |
| * StevenK ponders a bug vs --no-qa | 06:53 | |
| wgrant | no-qa | 06:54 |
| wgrant | lifeless: I see the notification on the blog... no issues with deploying the inTeam fix? | 06:56 |
| === al-maisan is now known as almaisan-away | ||
| lifeless | wgrant: no issues | 07:29 |
| LPCIBot | Project windmill-db-devel build #354: STILL FAILING in 1 hr 5 min: https://lpci.wedontsleep.org/job/windmill-db-devel/354/ | 07:31 |
| wgrant | lifeless: Thanks. | 07:33 |
| wgrant | Yay | 07:54 |
| wgrant | I think person search works OK when karma is added. | 07:54 |
| wgrant | wallyworld: Do you have a newer query than the one you gave to lifeless yesterday> | 07:54 |
| wgrant | Hmm. | 08:27 |
| wgrant | Except team search. | 08:27 |
| wgrant | This sort of completely breaks that. | 08:27 |
| wgrant | Fail. | 08:27 |
| StevenK | wgrant: Is that wallyworld's branch, or something else? | 08:29 |
| wallyworld | wgrant: i've included one in the mp: https://code.launchpad.net/~wallyworld/launchpad/person-picker-results-order/+merge/63057 | 08:30 |
| wgrant | StevenK: I have added karma to his query. | 08:30 |
| wgrant | And it works pretty well. | 08:30 |
| wgrant | IRC nicks and email addresses are awkward, though :( | 08:30 |
| wgrant | Since all we have is non-discriminatory prefix match. | 08:31 |
| wgrant | They tend to dominate. | 08:31 |
| wgrant | Karma mostly sorts that out. | 08:31 |
| wgrant | But something longer-term would be nice. | 08:31 |
| jtv | I've had quite enough of this bouncing. Let's see if it gets better if I take wifi out of the loop. | 08:46 |
| === jtv1 is now known as jtv | ||
| jtv | stub: I'm hoping to get a db review & patch number out of you for https://code.launchpad.net/~jtv/launchpad/db-bug-790161/+merge/63002 | 08:52 |
| lifeless | wgrant: aggregate karma across the team ? | 08:53 |
| wgrant | lifeless: That would work for ranking people and teams separately. | 08:54 |
| wgrant | lifeless: But ranking them sensibly in a single listing borders on impossible. | 08:54 |
| lifeless | average the karma across the team | 08:55 |
| wgrant | That might actually work. | 08:56 |
| adeuring | good morning | 09:02 |
| mrevell | Hello | 09:06 |
| adeuring | hi mrevell | 09:07 |
| === almaisan-away is now known as al-maisan | ||
| stub | jtv: k | 09:35 |
| jtv | ขอบ | 09:35 |
| lifeless | stub: evening | 09:39 |
| stub | jtv: Why is copy_policy free form test rather than something like an enum? | 09:43 |
| stub | lifeless: yo | 09:43 |
| jtv | stub: otp | 09:44 |
| stub | (yeah you know me) | 09:44 |
| danilos | anyone knows if there's an easy way to fetch multiple persons (given by their self_links) using API without doing multiple round-trips to the server? | 09:52 |
| wgrant | You can't. | 09:53 |
| danilos | or, how would one best export a tuple over the API for use in JS (I want to get a tuple (BugSubscription, Person, Person [subscribed_by]) from an API call so I don't have to do multiple round-trips, but I'd also feel that such API wouldn't really be the best publicly facing thing one might have; or maybe it would be) | 09:53 |
| danilos | wgrant: "yay" | 09:54 |
| danilos | I am guessing I'll have to define a separate interface holding this information, because I want a collection of such tuples; or, is there a way to force "shallow" (1-level) snapshotting of particular attributes on an already exported interface? | 09:58 |
| lifeless | danilos: you're probably best off defining a custom view which can return the json youneed | 09:58 |
| lifeless | our API is hugely focused on types and URL mapping, sadly | 09:59 |
| danilos | lifeless, is that the practice we encourage? I kind of dislike that approach | 09:59 |
| lifeless | danilos: to date folk generally throw their hands up and say 'man this is too hard' | 09:59 |
| danilos | lifeless, right, it's probably the simplest thing but the bug page is doing a bunch of that stuff and I'd rather do away with it (well, I'd still be able to get rid of 3-4 portlets, and introduce 1 new view, so it'd be an improvement, but I was hoping for 0) | 10:00 |
| lifeless | danilos: I recall a page somewhere that exists just to give json to browser js scripts | 10:00 |
| danilos | lifeless, yeah, there's a few of those on the bug page, and some of them render the actual HTML that's loaded through AJAX (yuck) | 10:01 |
| lifeless | danilos: the main API can do that too | 10:01 |
| lifeless | danilos: I agree that its yuck. It makes the service proposal I have have some fugly bits | 10:01 |
| lifeless | danilos: but all that said, I think if you have something pretty use case specific, putting it in the public API would be a little ugly | 10:02 |
| danilos | lifeless, right; still, useful to know that this is the approach I should take | 10:02 |
| danilos | lifeless, agreed, but if I need this (i.e. "get all subscriptions with subscriber Person fetched at the same time"), I am pretty sure public users might need it too | 10:03 |
| danilos | lifeless, but, then again it'd be opening a whole new can of worms, and I'd rather not go there | 10:03 |
| lifeless | right | 10:04 |
| lifeless | there is a broad issue with the API and performance | 10:04 |
| danilos | yup | 10:04 |
| lifeless | launchpadlib cannot use point solutions | 10:04 |
| lifeless | it needs some (perhaps easy) infrastructure and a defined pattern for the solutions to fit into | 10:04 |
| danilos | ok, thanks; I'll go with a view-provided JSON and load that on-demand, and I'll let you worry about coming up with nice infrastructure for this :P | 10:05 |
| lifeless | There is a document about doing a V2 API by leonardr/benji/gary on the wiki | 10:05 |
| lifeless | cool | 10:05 |
| wallyworld | stub: hi. i was hoping you could give me a db patch number for the person.displayname index creation script. it's included in mp https://code.launchpad.net/~wallyworld/launchpad/person-picker-results-order/+merge/63057 | 10:28 |
| stub | wallyworld: I landed a patch to add the person.displayname index already | 10:28 |
| stub | patch-2208-60-1.sql | 10:29 |
| jtv | stub: back. And that was opp, not otp. | 10:30 |
| wallyworld | stub: ok thanks. i thought you'd create the index but i needed to do the ptach still as part of my mp. i'll remove it. | 10:30 |
| jtv | stub: the boss specified a plain text field for the policy name because it's a bit easier to follow than an enum field. | 10:31 |
| stub | wallyworld: no probs. I tend to create the patches that I apply live, since the live version is usually very similar to what needs to land and I want to minimize chances of administrative screwups | 10:31 |
| bigjools | the policies are named rather than enummed :) | 10:31 |
| stub | bigjools: enums are names stored as integers | 10:31 |
| wgrant | But the names are crap :( | 10:31 |
| bigjools | SIGH | 10:31 |
| bigjools | nice constructive criticism there wgrant | 10:32 |
| wgrant | 'insecure' doesn't make sense outside the uploader. | 10:32 |
| wgrant | That is my only objection :) | 10:32 |
| stub | bigjools: Is there a fixed set of names, or are they freeform input of some sort? | 10:32 |
| wgrant | Well, it doesn't really make sense *in* the uploader either, but that's what we have. | 10:32 |
| * bigjools lets jtv continue | 10:32 | |
| jtv | stub: fixed set, for matching policy classes. | 10:33 |
| stub | So what is the advantage of a text field over an enum for that? We know the advantages of enum over text field which is why we normally use them. | 10:35 |
| jtv | Mostly that it takes us from a mapping between policies and names to a mapping between policies, names, and numbers. | 10:36 |
| jtv | Not lethal, but inconvenient. | 10:37 |
| bigjools | I am not wedded to names, switch it if you want | 10:37 |
| stub | The enum infrastructure means it is a mapping between policies and enums, not between policies, names and numbers. | 10:37 |
| * stub would love to use pg builtin enums, but not suitable for agile development until PG 9.1 | 10:38 | |
| jtv | Well the enum provides a mapping between names and numbers; we'd add the mapping between names and policies ourselves. | 10:38 |
| stub | I don't follow. You reference enums as names, not as numbers using some external mapping repeating what the enum infrastructure gives you for free. | 10:39 |
| jtv | Apart from getting ints in the database, of course. | 10:40 |
| stub | job.copy_policy = CopyPolicy.ZAPIT | 10:40 |
| stub | Right. And you don't see then in the Python code. | 10:40 |
| jtv | Well, apart from the one place of course. | 10:41 |
| jtv | Not trying to argue, really; just describing the inconvenience. | 10:41 |
| stub | There is small inconvenience creating the enum definition, but advantages to using it (smaller tables, no toast, faster lookups, smaller indexes, typo catching, faster python code). So unless there is a good reason, we should switch that column to an integer and use the standard pattern. | 10:43 |
| jtv | Toast may be a bit of an exaggeration for this case. :) | 10:43 |
| jtv | But sure, I can switch it. | 10:44 |
| stub | I think the toast table gets created when the main table gets created | 10:44 |
| jtv | Oh well | 10:45 |
| stub | I can list more rationalizations for enums too if you like :) | 10:45 |
| jtv | No that's alright, thank you :) | 10:45 |
| === al-maisan is now known as almaisan-away | ||
| jtv | stub: updated the patch. | 10:56 |
| stub | jtv: Ta. Does allowing NULL still make sense ('not set' vs. explicit enum value)? | 11:06 |
| stub | I expect so as not all jobs will use the field (?) | 11:06 |
| jtv | stub: that may depend a bit on where the class hierarchy goes, but I guess it would make sense for now to forbid it. | 11:07 |
| stub | if it makes sense, make it not null. Or leave it as nullable if we are not sure yet. | 11:08 |
| jtv | I'll make it "not null." If we ever decide that's wrong, we can relax it. Easier than going the other way. | 11:08 |
| stub | jtv: Unless we are mid cycle :) | 11:10 |
| * stub isn't helping | 11:10 | |
| jtv | We'll just wake up an admin in the middle of the night to drop the constraint. | 11:11 |
| stub | lifeless: did you see https://code.launchpad.net/~stub/launchpad/bug-758587-tests/+merge/63012 ? | 11:18 |
| bigjools | make it default to the current "insecure" policy please jtv | 11:19 |
| stub | jtv: Did you find that cpu indicator yet? | 11:19 |
| jtv | bigjools: it seems to make more sense to do that in the code, not in the db. | 11:19 |
| bigjools | jtv: either is fine | 11:20 |
| jtv | At the DB level I think neglecting to provide a value should produce either a null or an error, even if we do require a value for PlainPackageCopyJob. | 11:20 |
| jtv | stub: no, I don't have it yet | 11:21 |
| LPCIBot | Project devel build #771: FAILURE in 4 hr 52 min: https://lpci.wedontsleep.org/job/devel/771/ | 12:04 |
| === almaisan-away is now known as al-maisan | ||
| jtv | rvba: reviewed your branch | 12:19 |
| rvba | jtv: thanks a lot! | 12:21 |
| jtv | np | 12:21 |
| rvba | I'll reply to your comments once I've finished my chicken :). | 12:22 |
| === Ursinha-afk is now known as Ursinha | ||
| bac | hello mrevell | 13:23 |
| === matsubara-afk is now known as matsubara | ||
| wgrant | Hm. | 13:42 |
| wgrant | That is a /lot/ of failurse. | 13:42 |
| jelmer | wgrant: it's so bad, it's even affecting your spelling :P | 13:49 |
| wgrant | That's more the freezingness :( | 13:50 |
| jelmer | wgrant: of your machine or of your fingers ? | 13:50 |
| jelmer | hi matsubara | 13:50 |
| wgrant | The latter. | 13:50 |
| matsubara | hi jelmer | 13:50 |
| jelmer | matsubara: I made some more progress on updating bzr - current work is at lp:~jelmer/launchpad/newer-bzr | 13:52 |
| matsubara | jelmer, cool. should I merge your branch into mine and run tests to see if the errors are fixed? | 13:53 |
| matsubara | oh, you merged my branch :-) | 13:53 |
| jelmer | matsubara: it's too early for that, I'm still chasing some errors in bzr-git | 13:54 |
| matsubara | jelmer, ok, thanks for letting me know. | 13:54 |
| mrevell | Hey bac# | 14:01 |
| deryck | Hi, adeuring, abentley, and henninge. You guys have the standup yet? | 14:13 |
| abentley | deryck: no, waiting for you. | 14:13 |
| henninge | deryck: we are chatting but waiting for youi | 14:13 |
| henninge | yui? | 14:13 |
| deryck | ok, cool. thanks. coming.... | 14:13 |
| henninge | yiu? | 14:13 |
| henninge | :-D | 14:14 |
| deryck | if mumble will ever connect | 14:14 |
| cjohnston | henninge: mornin | 14:16 |
| abentley | deryck: do you want to Skype instead? | 14:17 |
| deryck | maybe so. let me try one more restart. | 14:17 |
| henninge | cjohnston: Hi! | 14:18 |
| henninge | cjohnston: otp now | 14:18 |
| cjohnston | ok | 14:18 |
| cjohnston | mine still need to be worked on? | 14:18 |
| henninge | cjohnston: the test run failed because of other errors. I just sent a mail to launchpad-dev. | 14:18 |
| henninge | cjohnston: the branch should be fine now, I expect | 14:19 |
| henninge | but don't know for sure | 14:19 |
| gmb | Is anyone else seeing "AssertionError: Name "id-only" is not registered as a view or navigation step for "Person" on "mainsite"." OOPSes on launchpad.dev instances? It happens on pretty much every page. | 14:21 |
| cjohnston | henninge: ok.. If you get an answer, let me know please :-) | 14:21 |
| gary_poster | matsubara or Ursinha, will either of you have some time for some exporatory testing tomorrow? And then we'll actually need some more probably Thursday of next week too | 14:34 |
| matsubara | gary_poster, yep | 14:35 |
| gary_poster | *exploratory :-) | 14:35 |
| matsubara | gary_poster, can you give me more details? | 14:35 |
| gary_poster | cool, thanks matsubara, I'll send you details the start of my day tomorrow. | 14:40 |
| gary_poster | Overview: the better bug notification feature had two bugs that meant rewriting large chunks of UI. We have one in db-devel now, and one will be ready for a no-downtime deploy after next Wed.'s downtime deploy. | 14:40 |
| gary_poster | Tomorrow, we need to make sure that the intermediate changes we have are OK for a few days in production; then next Thursday we need to make sure that the final changes are OK. Since they change a lot of code, and touch on a lot of the issues that were raised in the feature review, I thought exploratory testing would be a good idea. | 14:40 |
| gary_poster | Moreover, particularly for the intermediate changes, I know that we had hoped to get the final changes in before the db-deploy, so we were not as careful as we usually are, so another pair of eyes would be appreciated. | 14:40 |
| gary_poster | (done) | 14:40 |
| matsubara | gary_poster, sure thing. I'll wait for the details tomorrow and let you know once I have done the testing | 14:41 |
| gary_poster | thanks matsubara! | 14:41 |
| benji | I don't know one way or the other. Let me take a look real quick. | 14:41 |
| gary_poster | benji, you and your channels :-P | 14:42 |
| benji | so many channels, so few windows | 14:42 |
| gary_poster | :-) | 14:42 |
| jcsackett | StevenK: you still around? | 14:51 |
| StevenK | jcsackett: Barely | 14:51 |
| jcsackett | StevenK: fair. i posted a screenshot on the MP you requested one on. but if it's too late for you to take a look at it i can throw it to someone else. | 14:52 |
| StevenK | jcsackett: Link me the MP again? | 14:52 |
| jcsackett | https://code.launchpad.net/~jcsackett/launchpad/oh-oh-pick-me-pick-me/+merge/63047 | 14:52 |
| jcsackett | screenshot is in my reply to your comment, StevenK. | 14:53 |
| StevenK | jcsackett: Okay, I shall Approve. Do you feel it needs a UI review now or when it starts being used? | 14:54 |
| jcsackett | StevenK: i intended to get UI when it gets bolted in. until then it's too much of a pain for a UI reviewer to play with. | 14:54 |
| StevenK | jcsackett: Sounds fine. r=me | 14:55 |
| jcsackett | thanks, StevenK. | 14:55 |
| deryck | henninge, shall we chat now? | 15:34 |
| henninge | ser | 15:34 |
| henninge | deryck: yes, just getting ready | 15:34 |
| deryck | mumble is acting up again | 15:36 |
| === abentley changed the topic of #launchpad-dev to: Performance Tuesday! | https://dev.launchpad.net/ | On call reviewer: abentley | Critical bugs:208 - 0:[######=_]:256 | ||
| timrc | If a ppa is made public after its been made private do discard the buildd_secret as well? | 15:49 |
| timrc | do we ^ | 15:49 |
| wgrant | timrc: You can't change the privacy of a PPA after it has been used. | 15:51 |
| wgrant | Oh, I guess you're working on the API export? | 15:52 |
| timrc | wgrant, right, but before it's been used you can... and so in that case, do we discard the buildd_secret | 15:52 |
| timrc | wgrant, right... | 15:52 |
| wgrant | timrc: Yes, you need to discard it. | 15:52 |
| timrc | wgrant, cool, thx | 15:52 |
| wgrant | The DB doesn't enforce it, but the secret would become public. | 15:53 |
| LPCIBot | Project windmill-devel build #161: STILL FAILING in 1 hr 8 min: https://lpci.wedontsleep.org/job/windmill-devel/161/ | 16:04 |
| adeuring | abentley: fancy a small review (100 lines)? https://code.launchpad.net/~adeuring/launchpad/bug-750274/+merge/63129 | 16:24 |
| abentley | adeuring: sure. | 16:24 |
| abentley | adeuring: r=me | 16:32 |
| adeuring | abentley: thanks! | 16:32 |
| === al-maisan is now known as almaisan-away | ||
| === almaisan-away is now known as al-maisan | ||
| gmb | sinzui: I'm looking at https://bugs.launchpad.net/launchpad/+bug/61531 at the moment and I could do with knowing whether it's something that the disclosure work is going to deal with. | 16:41 |
| _mup_ | Bug #61531: Forbidden error when trying to mark a bug as private <403> <lp-bugs> <oops> <privacy> <ui> <Launchpad itself:In Progress by gmb> < https://launchpad.net/bugs/61531 > | 16:41 |
| === al-maisan is now known as almaisan-away | ||
| sinzui | gmb: it is not a priority since we are focused on non-subscription mechanisms to provide access | 16:44 |
| gmb | sinzui: How far away is that work from being viable? I.e. is it worth me fixing the bug anyway just to make an OOPS go away or should I mark it low (or Invalid or whatever). | 16:45 |
| sinzui | gmb: Is this a case where ajax works and html does not? | 16:45 |
| gmb | sinzui: No, the problem is that either of them breaks. It's just that the HTML version breaks more obviously. | 16:46 |
| gmb | Because you can mark the bug private but then you can't see it. With AJAX it's not immediately apparent there's a problem until you refresh the page. | 16:46 |
| sinzui | Since the work is not scheduled, never. We will introduce pillar permissions in 2 months in conjunction with allowing owners to see who is subscribed to what... | 16:46 |
| gmb | Okay. | 16:47 |
| sinzui | but there are no requests from stakeholders to change how subscription to individual bugs and branches works. | 16:47 |
| gmb | Ah, right. | 16:47 |
| gmb | In that case, I'll go fix it. | 16:47 |
| gmb | sinzui: Thanks for clearing that up for me. | 16:47 |
| LPCIBot | Project windmill-devel build #162: STILL FAILING in 44 min: https://lpci.wedontsleep.org/job/windmill-devel/162/ | 16:48 |
| sinzui | gmb: I think this bug is really about Lp's privacy entitlement rules. We simply do not permit bugs to be private without also being security issues unless an admin has toggled the projects private bug rules. | 16:50 |
| gmb | Hmm. I'm not sure that I understand what you mean. Are you saying that we shouldn't allow private bugs unless $SOME_RULE_FLAG is set to True? | 16:51 |
| sinzui | gmb: lp bugs conflates privacy and security. They are not equal since the issues are seen by different users. At this time, I think no user can toggle a bug private unless the project is configured to have private bugs. The any user can see and change security though | 16:52 |
| cody-somerville | sinzui, I don't think thats accurate. | 16:53 |
| sinzui | It will be | 16:53 |
| gmb | sinzui: This is the work that you're going to be landing in 2 months, right? | 16:53 |
| sinzui | We are separating security from privacy. We have always known Lp did not do a proper implementation | 16:53 |
| gmb | s/landing/releasing | 16:54 |
| sinzui | gmb yes | 16:54 |
| gmb | Right. | 16:54 |
| gmb | sinzui: In that case, I'll still fix the bug since the fix is cheap and it kills an OOPS. | 16:54 |
| sinzui | gmb When I change the bug supervisor, we will not suffer the subscription insanity. Though I can assign a team I am not a member of to the security contact, thus not have access to security bugs, I can change the role, and get access back | 16:55 |
| sinzui | gmb yep | 16:55 |
| gmb | Here's to not suffering insanity. | 16:55 |
| cody-somerville | lol | 16:56 |
| cody-somerville | I read that as sufficient instead of suffering | 16:56 |
| === beuno is now known as beuno-lunch | ||
| === salgado is now known as salgado-lunch | ||
| LPCIBot | Project windmill-devel build #163: STILL FAILING in 44 min: https://lpci.wedontsleep.org/job/windmill-devel/163/ | 17:32 |
| === matsubara is now known as matsubara-lunch | ||
| === deryck is now known as deryck[lunch] | ||
| === didrocks1 is now known as didrocks | ||
| === sidnei_ is now known as sidnei | ||
| === beuno-lunch is now known as beuno | ||
| === salgado-lunch is now known as salgado | ||
| jkakar | lifeless: FYI, I remember talking to smagoun at SomeHands last year and he mentioned he'd worked on/built a big system made out of many services connected by message queues. You might want to ping him to get his input about your ideas for Launchpad. | 18:42 |
| === deryck[lunch] is now known as deryck | ||
| === matsubara-lunch is now known as matsubara | ||
| lifeless | jkakar: thanks | 18:59 |
| jkakar | np | 19:00 |
| === almaisan-away is now known as al-maisan | ||
| sinzui | lifeless: This is an example oops I have seen when we attempt to store that exceeds MAX_EMAIL_SIZE: | 19:32 |
| sinzui | InvalidEmailMessage: Msg <...> size 13947097 exceeds limit 10485760 | 19:32 |
| sinzui | see lib/services/messages/model/message.py | 19:33 |
| lifeless | yes | 19:33 |
| lifeless | thats a large incoming mail ? | 19:33 |
| lifeless | we shouldn't record that as an OOPS, its out of our control. Hmm, but the mail path should match that. | 19:34 |
| lifeless | I see your point. | 19:34 |
| lifeless | even with that set we'd still have trouble. | 19:34 |
| sinzui | In a round about way mailman > holds > lp store it for review | 19:34 |
| lifeless | sinzui: do mailman list messages go through this code path ? | 19:34 |
| lifeless | s/that set/incoming mail size limited in postfix/ | 19:35 |
| sinzui | lifeless: only the hold path. and mailman now knows not to send the entire message | 19:35 |
| sinzui | it also knows to only forward the text part as well | 19:35 |
| lifeless | ok | 19:36 |
| sinzui | So Lp does not oops no | 19:36 |
| sinzui | now | 19:36 |
| lifeless | so for lists.launchpad.net we allow bigger | 19:36 |
| sinzui | we *could* | 19:36 |
| lifeless | but the postfix setup anything for @launchpad.net should limit to 10485760 | 19:36 |
| lifeless | because our code path enforces that anyway | 19:36 |
| sinzui | I believe it is currently configured to be lower | 19:36 |
| lifeless | 50MB | 19:37 |
| lifeless | which is, I believe, somewhat larger :) | 19:37 |
| === Ursinha is now known as Ursinha-afk | ||
| lifeless | sinzui: I had a question for you | 19:48 |
| lifeless | sinzui: why do we blacklist -owner as a team/person name. | 19:48 |
| lifeless | sinzui: is it because we wouldn't be able to give the object a mailing list ? | 19:49 |
| lifeless | sinzui: and if so, I'm confused because having the owner of list foo as a list itself sounds darn cool | 19:49 |
| sinzui | lifeless: I honestly do not know. | 19:50 |
| * sinzui looks at nameblacklist | 19:50 | |
| sinzui | lifeless: mailman does routing based on naming convention. http://www.gnu.org/software/mailman/mailman-install.txt | 19:52 |
| lifeless | sinzui: yeah, I realise we'd need to smack mailman upside the head a little | 19:53 |
| sinzui | lifeless: mailman3 aka a restful lib might be easy to smack | 19:54 |
| lifeless | yeah | 19:54 |
| lifeless | so lets leave it for now, I wanted to confirm I understood it properly - thanks | 19:55 |
| LPCIBot | Project windmill-db-devel build #355: STILL FAILING in 1 hr 5 min: https://lpci.wedontsleep.org/job/windmill-db-devel/355/ | 20:02 |
| LPCIBot | Yippie, build fixed! | 20:03 |
| LPCIBot | Project devel build #772: FIXED in 4 hr 56 min: https://lpci.wedontsleep.org/job/devel/772/ | 20:03 |
| benji | abentley: do you have a minute for a simple review? https://code.launchpad.net/~benji/launchpad/bug-719637/+merge/63159 | 20:30 |
| abentley | benji: sure. | 20:30 |
| benji | cool | 20:30 |
| abentley | benji, do you know about the lp.testing.temp_dir context manager? | 20:33 |
| benji | abentley: I do now. ;) | 20:33 |
| abentley | benji: why are you deleting the directory in setUp? | 20:35 |
| benji | abentley: that was some copy-pasta; I just realized that the entire setup and teardown methods are unneeded; I've pushed a change to remove them | 20:36 |
| abentley | benji: excellent. | 20:36 |
| abentley | benji: in 9-14, are you actually considering throwing an exception or reporting an OOPS? | 20:39 |
| abentley | benji: nm, I must be seeing things. | 20:39 |
| abentley | benji: r=me. | 20:39 |
| benji | cool, thanks! | 20:40 |
| jcsackett | sinzui: i just threw up the MP for the branch that links the new YUI personpicker into the web ui. i requested you as reviewer, if you don't mind, since it needs UI as well as code. | 20:45 |
| benji | gary_poster: I used (a slightly modified version of) the lp2kanban script to update a card for me and it wanted to change the card with title "This will be closed automatically by doing this feature [I should not get bugmail when I am subscribed via an invalid bugtask]" to the real title for bug 380205... | 20:51 |
| _mup_ | Bug #380205: Invalid bugtasks should not cause emails for structural subscriptions <email> <lp-bugs> <story-better-bug-notification> <Launchpad itself:Fix Committed by yellow> < https://launchpad.net/bugs/380205 > | 20:51 |
| benji | so if you want to run the script against the board, know that that'll happen | 20:52 |
| gary_poster | benji, good to know | 20:52 |
| gary_poster | benji, I wonder if script should only be willing to change title if the current card's title is a certain string, or maybe less than N chars or something | 20:53 |
| gary_poster | (unless you explicitly request it somehow?) | 20:53 |
| gary_poster | If we tweak a title we miht have a reason for it | 20:54 |
| gary_poster | might | 20:54 |
| benji | well, if we went that route it would be better to some how mark the card as robot-managed | 20:54 |
| gary_poster | maybe title would have short prefix? | 20:55 |
| benji | for example, if I enter a card, putting in the bug ID, the script fills in the details, then I edit the bug title, I'll want the new title updated on the card | 20:55 |
| gary_poster | understood | 20:55 |
| gary_poster | or suffic | 20:55 |
| gary_poster | suffix | 20:55 |
| benji | that's possible, I have a slight preference for the rule being "if it has a bug number (external ID), then it is externally managed" | 20:56 |
| gary_poster | that's pure but not as flexible as I think I want. I s'pose we could try it out and see how much it chafes me | 20:56 |
| benji | we could then add an opt-out rule instead of an opt-in rule | 20:56 |
| benji | tag the card with "keep your grubby robot hands off me" | 20:57 |
| gary_poster | that would be fine-ish, but if instead it is an opt-in, and a card that is synced initially will get the opt-in mark by default, then we might get the best of both worlds: by default, things are synced, but it's clear what to delete if you want to stop the syncing | 20:58 |
| benji | I like that better. | 20:58 |
| benji | gary_poster: I'll add a card for that functionality. | 20:59 |
| gary_poster | cool benji | 20:59 |
| LPCIBot | Project windmill-devel build #164: STILL FAILING in 1 hr 8 min: https://lpci.wedontsleep.org/job/windmill-devel/164/ | 21:10 |
| === Ursinha-afk is now known as Ursinha | ||
| === Ursinha is now known as Ursinha-nom | ||
| jcsackett | sinzui: can we remove the card for bug 669933 given its resolution? | 21:15 |
| _mup_ | Bug #669933: person picker could accept extra criteria to find a user <disclosure> <lp-registry> <person-picker> <Launchpad itself:Won't Fix> < https://launchpad.net/bugs/669933 > | 21:15 |
| sinzui | jcsackett: yes, we can delete it | 21:16 |
| jcsackett | cool, done. | 21:16 |
| === al-maisan is now known as almaisan-away | ||
| LPCIBot | Project windmill-db-devel build #356: STILL FAILING in 41 min: https://lpci.wedontsleep.org/job/windmill-db-devel/356/ | 21:51 |
| === abentley changed the topic of #launchpad-dev to: Performance Tuesday! | https://dev.launchpad.net/ | On call reviewer: - | Critical bugs:208 - 0:[######=_]:256 | ||
| LPCIBot | Project db-devel build #605: FAILURE in 2 hr 55 min: https://lpci.wedontsleep.org/job/db-devel/605/ | 22:04 |
| === Ursinha-nom is now known as Ursinha | ||
| === salgado is now known as salgado-afk | ||
| LPCIBot | Project windmill-devel build #165: STILL FAILING in 45 min: https://lpci.wedontsleep.org/job/windmill-devel/165/ | 22:37 |
| === matsubara is now known as matsubara-afk | ||
| lifeless | poolie: when you're around, I would like to talk about bzr formats and lp | 23:04 |
| sinzui | wgrant: wallyworld: jcsackett. I will be 15 minutes late to the stand up. Sorry. | 23:49 |
| wallyworld | np | 23:50 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!