| StevenK | wgrant: Down to one failure in my no-more branch | 00:09 |
|---|---|---|
| wgrant | Excellent. | 00:11 |
| StevenK | How did this fail before? I don't get it | 00:21 |
| wgrant | Hm? | 00:25 |
| StevenK | wgrant: http://pastebin.ubuntu.com/674932/ | 00:26 |
| wgrant | StevenK: It possibly was relying on the branch not existing on disk. | 00:27 |
| wgrant | StevenK: Try checking the output on devel. | 00:27 |
| StevenK | ERROR Job execution raised an exception. | 00:30 |
| StevenK | -> http://localhost:33770/93/bLqgyciAI0wS9vOJ96yNSjGCqMV.txt (Not a branch: "lp-internal:///~person-name-870614/product-name-870620/branch-870616".) | 00:30 |
| StevenK | Whereas that doesn't happen for my change | 00:32 |
| StevenK | So I guess it wants a job for a branch that doesn't exist on disk? | 00:34 |
| wgrant | Right. Use a RevisionAddedJob or so. | 00:35 |
| wgrant | Since RevisionMailJob doesn't touch the disk any more. | 00:35 |
| StevenK | wgrant: Fixed. | 00:44 |
| wgrant | StevenK: Using RevisionAddedJob? | 00:44 |
| StevenK | wgrant: Yes | 00:44 |
| wgrant | Great. | 00:45 |
| StevenK | Now to craft evil queries | 00:45 |
| wgrant | Should be pretty trivial. | 00:52 |
| wgrant | And there's only like 11000. | 00:52 |
| wgrant | Possibly less, if some of them have preview diffs. | 00:52 |
| lifeless | wgrant: what are you doing ? | 00:53 |
| wgrant | lifeless: StevenK is abolishing review diffs. | 00:53 |
| StevenK | SELECT count(distinct(review_diff)) from branchmergeproposal where merge_diff is null; => 5213 | 00:54 |
| lifeless | did you talk to aaron about difftasticd ? | 00:55 |
| lifeless | s/d // | 00:55 |
| StevenK | Not about difftastic, that had utterly slipped my mind | 00:56 |
| lifeless | well, review diffs and difftastic are pretty linked | 00:56 |
| StevenK | They are? | 00:56 |
| lifeless | I'd hate to see that deleted rather than fixed. | 00:56 |
| lifeless | perhaps I misunderstand | 00:56 |
| StevenK | I thought difftastic was used for incremental diffs? | 00:56 |
| wgrant | lifeless: Those are incremental diffs. | 00:57 |
| lifeless | I probably do misunderstand :) | 00:57 |
| wgrant | Review diffs are what came before preview diffs. | 00:57 |
| wgrant | Back in the days of lp:mad. | 00:57 |
| StevenK | Named in DB as *static*diff | 00:57 |
| wgrant | <= 2010/01 | 00:57 |
| lifeless | ah | 00:57 |
| lifeless | cool cool thanks! | 00:57 |
| StevenK | wgrant: So, we have a query to clear review_diff where preview_diff is not null | 00:58 |
| StevenK | launchpad_dogfood=> UPDATE branchmergeproposal set review_diff = null where review_diff is not null and merge_diff is not null; | 00:59 |
| StevenK | UPDATE 6860 | 00:59 |
| wgrant | launchpad_dogfood=> SELECT merge_diff IS NOT NULL, review_diff IS NOT NULL, COUNT(*) FROM branchmergeproposal GROUP BY merge_diff IS NOT NULL, review_diff IS NOT NULL; ?column? | ?column? | count | 00:59 |
| wgrant | ----------+----------+------- f | f | 3061 f | t | 5251 t | f | 36774 t | t | 6860 | 00:59 |
| wgrant | Fail. | 00:59 |
| StevenK | Haha | 00:59 |
| wgrant | But there are 6860 with both, 5251 with just a staticdiff. | 00:59 |
| StevenK | Right, so the update for 6860 rows is fine | 01:00 |
| StevenK | Now a query to create previewdiffs | 01:02 |
| wgrant | Are preview diffs always used in preference to review diffs? | 01:02 |
| StevenK | From my reading of the code, yes | 01:02 |
| StevenK | There's only 746 MPs with a staticdiff, no previewdiffs and aren't merged | 01:06 |
| StevenK | And 4505 where date_merged is not null | 01:07 |
| wgrant | Even merged ones would be nice. | 01:07 |
| StevenK | I'm just a little lost how to loop on branchmergeproposal, creating rows in previewdiff and updating | 01:07 |
| LPCIBot | Project db-devel build #826: STILL FAILING in 5 hr 29 min: https://lpci.wedontsleep.org/job/db-devel/826/ | 01:08 |
| wallyworld_ | wgrant: StevenK: dumb question of the day - what's the difference between a review diff and a preview diff? | 01:18 |
| StevenK | wgrant: reviewdiffs are static and ancient | 01:18 |
| StevenK | RARGH | 01:18 |
| StevenK | wallyworld_: ^ | 01:18 |
| wallyworld_ | StevenK: ah, so review diffs do not get updated if someone pushes a change to the branch after it is put up for review? | 01:19 |
| StevenK | wallyworld_: They have not been generated in the database for over 18 months, it's probably not worth learning about, TBH | 01:20 |
| wallyworld_ | ok | 01:20 |
| wallyworld_ | delete away.... :-) | 01:20 |
| wgrant | Bah. | 01:22 |
| wgrant | No index on previewdiff(source_revision_id, target_revision_id) | 01:23 |
| StevenK | wgrant: Do we need one? | 01:24 |
| wgrant | StevenK: Probably. We should try on staging without it. | 01:26 |
| wgrant | But DF definitely does. | 01:26 |
| wgrant | http://paste.ubuntu.com/674955/ | 01:26 |
| wgrant | Or you end up with thousands of seq scans of the table. | 01:26 |
| StevenK | Right | 01:27 |
| StevenK | wgrant: Is that in a transaction? | 01:27 |
| wgrant | StevenK: Yes. | 01:28 |
| StevenK | Right | 01:28 |
| wgrant | Should also set review_diff = NULL, I guess. | 01:28 |
| wgrant | But it's fast enough to do all this directly. | 01:28 |
| StevenK | I have a query for that already | 01:28 |
| StevenK | If we do that at the end, we can use it to clean up for us | 01:28 |
| wgrant | We might as well do it in the one UPDATE. | 01:29 |
| StevenK | UPDATE branchmergeproposal SET merge_diff = (SELECT id FROM previewdiff WHERE from_revision_id = source_revision_id AND to_revision_id = target_revision_id) FROM staticdiff WHERE staticdiff.id = review_diff AND merge_diff IS NULL; | 01:29 |
| StevenK | UPDATE branchmergeproposal set review_diff = null where review_diff is not null and merge_diff is not null; | 01:29 |
| StevenK | Are the two of them | 01:29 |
| wgrant | I guess we need to unset all of them, whereas my UPDATE only needed to consider those without a preview_diff. | 01:30 |
| wgrant | So indeed. | 01:30 |
| james_w | OOPS-2062F5 | 01:41 |
| james_w | hmm, no bot? I'll have to do this by hand | 01:41 |
| mwhudson_ | those numbers seem small | 01:42 |
| lifeless | not really | 01:42 |
| wgrant | mwhudson_: Which? | 01:42 |
| lifeless | its 0142 | 01:42 |
| mwhudson_ | in the oops | 01:42 |
| mwhudson_ | ah right | 01:42 |
| wgrant | 2 hours in, 60 appservers. | 01:42 |
| james_w | Date: Aug. 24, 2011, 2:01 a.m. | 01:42 |
| lifeless | which makes it 0101 | 01:43 |
| lifeless | if you use a real tz :P | 01:43 |
| wgrant | :( | 01:43 |
| wgrant | Dropping a foreign key requires a lock on both tables. | 01:43 |
| lifeless | oh or its a couple days back :) | 01:43 |
| wgrant | How stupid. | 01:43 |
| lifeless | either way | 01:43 |
| james_w | yeah | 01:43 |
| lifeless | wgrant: thats because fk's are triggers. | 01:43 |
| james_w | I was just making sure the oops had synced :-) | 01:43 |
| wgrant | lifeless: Ah. | 01:43 |
| lifeless | wgrant: (apparently :P) - they get presented differently of course, but are built on that mechanism. | 01:44 |
| james_w | it | 01:44 |
| james_w | it's doing the count(*) twice? | 01:44 |
| lifeless | wallyworld_: uhm | 01:45 |
| wallyworld_ | lifeless: ? | 01:45 |
| lifeless | wallyworld_: are you *trying* to make the public -stacked-on-private branch obfuscated? | 01:45 |
| wallyworld_ | no | 01:46 |
| lifeless | why do you need a metaclass then ? | 01:46 |
| lifeless | and __setattr__ | 01:46 |
| wallyworld_ | so that code in storm queries can still go "Branch.private == xxx" | 01:47 |
| wallyworld_ | (the metaclass does this bit) | 01:47 |
| lifeless | yes, but this means that aBranch.private and Branch.private are now totally different htings. | 01:47 |
| lifeless | this is horribly confusing | 01:47 |
| wallyworld_ | and so that exisitng code which creates a branch via Branch(name=xxx, private=True) still works | 01:47 |
| wallyworld_ | (the setattr does this) | 01:47 |
| StevenK | wgrant: Ah, I forgot we need to drop the FK as well | 01:48 |
| StevenK | And then after my evil branch lands we can drop the column and table | 01:48 |
| wallyworld_ | lifeless: the other option then is to s/Branch.private/Branch.explicitly_private | 01:48 |
| lifeless | wallyworld_: please | 01:48 |
| lifeless | wallyworld_: thats what we've done in the past: KISS | 01:48 |
| wallyworld_ | ok. it wasn't confusing to me :-) | 01:48 |
| wallyworld_ | i was trying to do it behind the scenes so to speak | 01:49 |
| lifeless | wallyworld_: its not confusing to me either, cause I've seen the diff. But imagine someone looking at the rest of LP | 01:49 |
| james_w | I can't find a bug for this timeout, would someone take a look, or should I just file one? | 01:49 |
| lifeless | who comes to this code, and sees no difference visually. | 01:49 |
| lifeless | wallyworld_: unless you rename the column I suggest actually not renaming | 01:49 |
| lifeless | wallyworld_: instead add a property 'effectively_private' or something, which would honour self.private + self.stacking etc. | 01:49 |
| lifeless | wallyworld_: and reference that from security adapters, views etc. | 01:50 |
| lifeless | wallyworld_: this will keep the class .private and the schema .private in sync with each other. | 01:50 |
| wallyworld_ | lifeless: that's a big change | 01:50 |
| wallyworld_ | why not just rename the private property to explicitly private | 01:50 |
| wallyworld_ | and use dbname="private" in the property | 01:51 |
| wallyworld_ | this will have the smallest footprint in terms of change to the code | 01:51 |
| wallyworld_ | and still be quite clear i think | 01:51 |
| james_w | I think that's better, so that you don't have to remember that the obvious "private" attribute isn't likely what you usually want | 01:52 |
| lifeless | wallyworld_: I'm thinking about the mapping from object to schema | 01:52 |
| lifeless | james_w: file a bug :) | 01:52 |
| wallyworld_ | james_w: agreed. | 01:52 |
| lifeless | wallyworld_: but sure. | 01:52 |
| lifeless | wallyworld_: my main concern is that what folk think they are reading is what they are reading. | 01:52 |
| lifeless | wallyworld_: they should be able to guess at the behaviour of the code, with high accuracy rates, without having read the entire implementation. | 01:53 |
| lifeless | wallyworld_: if private is a property and *not* the db column, then 'foo.private = True' will not do what they expect. | 01:53 |
| lifeless | however, I see that that is not meant to happen here anyway | 01:54 |
| lifeless | folk are meant to call setPrivate | 01:54 |
| wallyworld_ | that bit will do what they expect. ie make the branch private. but if they say foo.private = False it may not | 01:54 |
| lifeless | so +1 | 01:54 |
| wallyworld_ | lifeless: ok. we can iterate later and change the column if needed | 01:55 |
| lifeless | wallyworld_: well, it will only do that with either a property or a setattr | 01:55 |
| james_w | https://bugs.launchpad.net/launchpad/+bug/834293 | 01:55 |
| _mup_ | Bug #834293: Product:+code-index times out <Launchpad itself:New> < https://launchpad.net/bugs/834293 > | 01:55 |
| lifeless | wallyworld_: ok; so for clarity - you're doing:13:50 < wallyworld_> why not just rename the private property to explicitly private | 01:55 |
| lifeless | 13:50 < wallyworld_> and use dbname="private" in the property | 01:55 |
| lifeless | wallyworld_: dropping the metaclass and setattr | 01:55 |
| wallyworld_ | lifeless: yes | 01:55 |
| lifeless | wallyworld_: to be clear, I don't object to metaclasses and setattr per se; just that they should really be enhancing things, not obfuscating :) | 01:56 |
| lifeless | wallyworld_: thanks! | 01:56 |
| lifeless | james_w: please don't use lp-oops urls | 01:56 |
| lifeless | james_w: just the oops id | 01:56 |
| wallyworld_ | lifeless: np, input is appreciated. i can see how it's clear to me because i'm close to it but not to others who may be looking in from the outside | 01:56 |
| wallyworld_ | lifeless: will you have time to do that loggerhead review before you go and spend your evening changing shitty nappies? | 01:57 |
| james_w | lifeless, why? | 01:57 |
| lifeless | james_w: a) we linkify anyway so theres no different in click-through, b) its easier to read and copy, c) the garbage collection code ignores url style oops references so they will get deleted. | 01:58 |
| james_w | ah, I didn't realise there was any integration | 01:59 |
| james_w | the latter seems like a bug though :-) | 01:59 |
| lifeless | james_w: it is | 02:02 |
| lifeless | james_w: but anyhow, its intended for users that have no access to the reporting UI | 02:02 |
| lifeless | your having access to it is the exception :) | 02:02 |
| james_w | yeah | 02:03 |
| lifeless | frell | 02:07 |
| lifeless | another regression | 02:07 |
| wgrant | lifeless: Where? | 02:07 |
| lifeless | bug 834266 | 02:09 |
| _mup_ | Bug #834266: "831884 is not a valid bug number or nickname" <regression> <Launchpad itself:Triaged> < https://launchpad.net/bugs/834266 > | 02:09 |
| wgrant | lifeless: I think that's the second time you've declared this bug to be a regression. | 02:10 |
| wgrant | lifeless: The case that's handled in marking a master as a dupe. | 02:10 |
| wgrant | s/in/is/ | 02:10 |
| wgrant | Trying to find the dupe.. | 02:11 |
| wgrant | There. | 02:11 |
| lifeless | wgrant: thanks :) | 02:35 |
| wgrant | grar. | 02:36 |
| wgrant | Why do people insist on implementing non-auditable copying. | 02:36 |
| wgrant | Seriously. | 02:36 |
| wgrant | Stupid. | 02:36 |
| jtv | Hey, good morning everyone! I think I'll implement some non-auditable copying today. | 02:55 |
| wgrant | jtv: No, your squad already did that last week. | 02:59 |
| wgrant | You're too late :( | 02:59 |
| jtv | Oh, but there's always more to do. | 02:59 |
| jtv | I insist on implementing non-auditable copying. | 02:59 |
| wgrant | Good, good. | 03:01 |
| wgrant | What could go wrong. | 03:01 |
| jtv | hi wallyworld___, your collection of underscores is coming along nicely I see. | 03:06 |
| jtv | Any reviews for me to approve? | 03:06 |
| LPCIBot | Project devel build #997: STILL FAILING in 6 hr 0 min: https://lpci.wedontsleep.org/job/devel/997/ | 03:13 |
| StevenK | lifeless: O hai -- wgrant and I would like to remove all references to staticdiff -- the queries take approximately 12 seconds on DF and it will be a once-off. Or are you going to make me write a garbo job? | 03:19 |
| wgrant | 12s include an index creation that can be done whenever. | 03:20 |
| wgrant | 4-5s without. | 03:20 |
| jtv | Over a hundred broken tests in buildbot. That's impressive. | 03:24 |
| wgrant | Yeah. | 03:25 |
| wgrant | A revision was landed that depended on a revision that was reverted a few hours earlier. | 03:25 |
| lifeless | the index creation is nonblocking | 03:25 |
| lifeless | if its done CONCURRENTLY | 03:25 |
| wgrant | Right. | 03:25 |
| lifeless | so, that seems fine to me. | 03:26 |
| wgrant | Hence can be done whenever, including in the patch, if required. | 03:26 |
| lifeless | 4-5s is too long to do as one transaction though if its hitting 6K rows | 03:26 |
| StevenK | We can split it up | 03:26 |
| lifeless | yup | 03:26 |
| StevenK | 2s per transaction or so | 03:26 |
| lifeless | that works for me | 03:26 |
| wgrant | lifeless: 6k merged proposals from before 2010? :) | 03:26 |
| StevenK | Only 5k | 03:27 |
| lifeless | wgrant: FK references. | 03:27 |
| lifeless | wgrant: never underestimate the MVCC lock monster | 03:27 |
| jamesh | lifeless: looks like the django ticket for passing the exception info up has progressed to "Design decision needed". Hopefully that isn't a black hole | 03:51 |
| wgrant | jamesh: It normally is with Django... | 03:52 |
| lifeless | jamesh: win. | 03:53 |
| lifeless | course, we could patch it in Ubuntu :) | 03:53 |
| jamesh | it seems one of the issues is that not all exceptions might make it to handle_uncaught_exception(), so capturing errors there might not be perfect | 03:54 |
| jamesh | I've added a comment that all the errors in my view code generally pass through that code path though | 03:55 |
| lifeless | cool | 03:55 |
| lifeless | if they swallow exceptions and don't reach that code path, that seem like a separate bug :) | 03:55 |
| lifeless | as opposed to a reason not to do this | 03:55 |
| jtv | wgrant: you asked why I didn't re-implement [BS]PPH.setDeleted in terms of PublishingSet.setMultipleDeleted. The answer is that the latter bypasses the ORM, which is more likely to be harmful in code that requests deletion of individual objects. | 04:54 |
| wgrant | jtv: True. Although it doesn't have to bypass the ORM. | 04:54 |
| wgrant | Do you know about ResultSet.set()? | 04:54 |
| wgrant | It gets far too little use. | 04:55 |
| jtv | No, I don't! I knew there was something like that for delete, but it gave us endless trouble anyway. | 04:55 |
| jtv | (There were all sorts of queries it didn't support) | 04:55 |
| wgrant | yeah, but for this sort of thing it's probably fine and a lot less ugly. | 04:55 |
| jtv | I'll file a bug to fix that. It'd save some test commits. | 04:56 |
| wgrant | Right. | 04:56 |
| wgrant | jtv: Do you like lp.soyuz.model.publishing's wonderful test coverage? | 04:59 |
| wgrant | Truly exemplary stuff. | 04:59 |
| StevenK | How sarcastic are you being? | 05:00 |
| jtv | wgrant: I'm picking up a hint of sarcasm there, but I'm told that I wouldn't understand because I'm not American. | 05:00 |
| wgrant | Just a bit. | 05:02 |
| jtv | Thanks. It helps to be clear about these things. | 05:02 |
| StevenK | wgrant: That's like calling a fish 'just a bit wet' | 05:02 |
| * wgrant deletes more of Distribution. | 05:03 | |
| jtv | A-khah. This vhat British capitalist call, understatement—da? | 05:03 |
| StevenK | wgrant: Excellent. | 05:04 |
| * StevenK fights with Jenkins | 05:06 | |
| lifeless | jtv: you managed to create two bugs | 05:12 |
| jtv | That explains why I got two confirmation boxes. | 05:12 |
| lifeless | jtv: I wonder if we have a bug in our request retry logic or something | 05:12 |
| jtv | Or a very late failure triggering a retry after db commit maybe? | 05:13 |
| jtv | I don't suppose the browser would retry the POST unless it got an unambiguous application-level failure response? | 05:14 |
| wgrant | Sure you didn't click submit twice? | 05:14 |
| jtv | Very. | 05:14 |
| wgrant | POSTs are not permitted to be retried automatically. | 05:15 |
| wgrant | At the browser-level. | 05:15 |
| jtv | This is chromium though. Full of optimizing cleverness. | 05:15 |
| wgrant | Heh | 05:15 |
| jtv | BTW I see now that I expressed myself badly: | 05:15 |
| lifeless | I know what you meant | 05:16 |
| jtv | I meant, I don't suppose the browser would retry the POST just because it did not get an unambiguous application-level failure response. | 05:16 |
| lifeless | and yes I think post-commit retry is the most plausible epxlanation | 05:16 |
| wgrant | jtv: How did you file those bugs? | 05:28 |
| jtv | wgrant: could you be more specific? | 05:29 |
| wgrant | I only see one bug filing in the appserver logs, and that was 90 minutes ago. | 05:29 |
| wgrant | Are you using edge or something? | 05:29 |
| jtv | Nope. | 05:29 |
| lifeless | wgrant: appserver bug | 05:29 |
| lifeless | wgrant: we retry requests in the appservers. | 05:29 |
| lifeless | wgrant: on POST, on conflicts. | 05:30 |
| wgrant | lifeless: The bug in question was filed only 30 minutes ago. | 05:30 |
| wgrant | I do not see even one POST for it. | 05:30 |
| lifeless | wgrant: that is how it was posted, no ? | 05:30 |
| lifeless | oh, I see 90 vs 30 | 05:30 |
| lifeless | wgrant: you've got all the appservers ? :> | 05:30 |
| lifeless | actually. EOD. EOW. SOL. | 05:31 |
| wgrant | lifeless: Good plan. See you eventually, I suppose. Good luck! | 05:31 |
| jtv | lifeless: enjoy your weekend. | 05:31 |
| wgrant | jtv: Weekend? | 05:31 |
| jtv | wgrant: yes, it's that bit where the office goes nice and quiet so you can work in peace. | 05:32 |
| === almaisan-away is now known as al-maisan | ||
| jtv | When that happens, the rest of us are having something called a week-end. | 05:32 |
| lifeless | wgrant: I think jtv is being sensible about disclosure of private data | 05:32 |
| wgrant | Bah. | 05:32 |
| lifeless | which is nice | 05:32 |
| wgrant | I wonder if puppet broke stuff. | 05:32 |
| wgrant | Not all the logs are here. | 05:32 |
| wgrant | Probably means we're missing OOPSes, too. | 05:33 |
| lifeless | that vould be a vorry | 05:33 |
| wgrant | But not surprising. | 05:33 |
| lifeless | hangon, I was going. | 05:33 |
| wgrant | See you. | 05:33 |
| lifeless | wgrant: I'm pushing up my gpfixtures WIP for LP | 05:34 |
| wgrant | lifeless: I may have a poke at it and get it finished. | 05:35 |
| lifeless | lp:~lifeless/launchpad/usegpgfixtures and of course lp:python-gpgfixtures | 05:36 |
| lifeless | it needs a ServerFixture to invoke the process etc, which would live in python-gpgfixtures for now. Its not a perfect demo of the soa test fake layout. | 05:37 |
| lifeless | perhaps it should be, but one step at a time | 05:37 |
| wgrant | Yeah. | 05:37 |
| wgrant | Anyway, shoo. | 05:37 |
| lifeless | both branches pushed. | 05:38 |
| lifeless | enjoy. | 05:38 |
| wgrant | Thanks. | 05:38 |
| lifeless | heh, the keyserver in fixtures is shorter than the one in LP; including the main() stuff and the json API. | 05:39 |
| lifeless | \o/ | 05:39 |
| wgrant | Nice. | 05:39 |
| lifeless | not a totally fair comparison, but shrug | 05:40 |
| StevenK | Right, Jenkins is in money-suck mode | 05:51 |
| danilos | jtv, hi, can you perhaps give me another short review, mostly for a branch you've already reviewed: https://code.launchpad.net/~danilo/launchpad/bug-826692-take2/+merge/72996 (it was broken for private branches, and the fix is easy, and I add a test for it) | 06:12 |
| danilos | jtv, you can perhaps just look at the incremental diff in http://paste.ubuntu.com/675046/ | 06:12 |
| jtv | danilos: okay okay, you've sold me. Don't try to buy it back. :) | 06:12 |
| danilos | heh, thanks | 06:13 |
| === al-maisan is now known as almaisan-away | ||
| wgrant | danilos: Given its history, you might want to coerce a LOSA to merge that on staging so you can try it out for real. | 06:18 |
| danilos | wgrant, sure, though when you do anticipate a problem (or when there are tests for it), it makes a big difference :) | 06:19 |
| wgrant | danilos: Bah, who needs tests. | 06:20 |
| danilos | not us the real men! our test suite are our users | 06:21 |
| danilos | wgrant, what was the commercial team name again? I need to find who can make me a few private branches on staging | 06:21 |
| jtv | danilos: “Merge proposals against private branches are visible to *the* branch owner.” | 06:22 |
| wgrant | danilos: ~commercial-admins and LOSAs. | 06:22 |
| wgrant | danilos: I have access to U1 branches, if that helps. | 06:22 |
| danilos | wgrant, are they on (qa)staging? I have access to landscape branches, but they ain't there | 06:22 |
| wgrant | danilos: The content doesn't matter, does it? | 06:23 |
| danilos | jtv, thank you :) | 06:23 |
| jtv | danilos: is this the branch that caused (some of) those 93 failures and 17 errors we had in devel earlier? | 06:23 |
| wgrant | The DB stuff is there, and that's all that matters. | 06:23 |
| danilos | wgrant, nope, I just need merge proposals against them | 06:23 |
| danilos | jtv, nope, the reversion of this branch and gary's revision using some of the stuff in this branch is what caused the failures | 06:23 |
| wgrant | danilos: gary reverted that before you emailed me, btw. | 06:24 |
| danilos | wgrant, it is? oh right, logging in might help see them | 06:24 |
| jtv | danilos: oh, I heard about those but didn't think it was the same failure. There are far too many lately. :/ | 06:24 |
| danilos | jtv, this is just a regular distributed development fallacy, I don't think there's anything we could do about it except make the test suite run shorter thus reducing the chances of something like this happening | 06:24 |
| wgrant | danilos: I agree that that's about all we can do. | 06:25 |
| danilos | wgrant, yeah, I've seen that as well, sorry if I bothered you :) | 06:25 |
| jtv | danilos: for a moment I thought you were saying I was completely wrong, but now I suspect "fallacy" isn't really the word you meant. :-) | 06:25 |
| wgrant | If we had a one hour test suite again (which is practical with parallelisation), the occurrence and impact of this sort of thing would be far, far lower. | 06:25 |
| jtv | Yes. | 06:26 |
| jtv | Although the past few days, Q/A has played a large role as well. | 06:26 |
| wgrant | jtv: That's made worse by the fact that QA can rarely happen until 10 hours after the branch is submitted. | 06:27 |
| wgrant | Which means a lot more breakage can slip into devel before it's noticed, and it's less likely to be noticed because the wrong people are doing it. | 06:27 |
| jtv | Absolutely. Getting a branch from submission to Q/A readiness is still an overnight process. | 06:28 |
| jtv | Which reminds me of another suspect in our current problems: staging updates. | 06:28 |
| wgrant | What staging updates? | 06:28 |
| wgrant | It hasn't updated in a while :) | 06:29 |
| danilos | :) | 06:29 |
| jtv | Oh well that's alright then. :) | 06:29 |
| wgrant | The ticket is only 85.. we should probably get it bumped. | 06:29 |
| jtv | danilos: I rejected the MP based on the missing "the" in the comment. Please try again Monday. | 06:31 |
| danilos | jtv, fair enough, thank you very much, I'll be back on Monday | 06:31 |
| danilos | (I'll go spend weekend fixing all the missing articles in the LP tree, however you take that ;) | 06:32 |
| jtv | np | 06:32 |
| jtv | danilos: *the* weekend. You did that on purpose, didn't you? | 06:32 |
| danilos | spend the weekend? | 06:32 |
| jtv | Yup. :) | 06:32 |
| danilos | heh, yeah, I can usually find them missing only on re-reading the sentence, and that never happens with comments for tests :P | 06:33 |
| LPCIBot | Project devel build #998: STILL FAILING in 16 min: https://lpci.wedontsleep.org/job/devel/998/ | 06:35 |
| StevenK | Uh | 06:36 |
| StevenK | bzr: ERROR: http://bazaar.launchpad.net/~launchpad-pqm/launchpad/devel/.bzr/repository/packs/9e62132dbdc7acb42f1156c7a4128cf2.pack is redirected to https://launchpad.net | 06:37 |
| StevenK | RARGH | 06:37 |
| wgrant | Yay | 06:38 |
| lifeless | wgrant: - 1. [[#william_grant|William Grant <me {_AT_} williamgrant.id.au>]] ''(133 top-level landings)'' | 06:38 |
| lifeless | + 1. [[#william_grant|William Grant <me {_AT_} williamgrant.id.au>]] ''(134 top-level landings)'' | 06:38 |
| lifeless | wgrant: lies | 06:38 |
| wgrant | lifeless: I merged a rev from a branch from December :) | 06:38 |
| StevenK | Haha | 06:38 |
| wgrant | I thought I cherrypicked it. | 06:38 |
| wgrant | But apparently not well enough. | 06:38 |
| wgrant | Ah, it was the first rev in the branch. | 06:38 |
| wgrant | lifeless: Are you here? | 06:43 |
| wgrant | lifeless: If so, a prio bump on https://rt.admin.canonical.com/Ticket/Display.html?id=47551 would be nice, since staging hasn't restored for two weeks now and we'll likely be fastdowntime-capable next week... | 06:43 |
| * 31NAAXP81 hates doc tests. too hard to debug :-( | 06:45 | |
| === 31NAAXP81 is now known as wallyworld_ | ||
| StevenK | Haha | 06:45 |
| wallyworld_ | shutup | 06:45 |
| wgrant | Underscores, random characters... what next? | 06:45 |
| StevenK | Nice nickname | 06:45 |
| wallyworld_ | i'm already way too grumpy | 06:45 |
| === StevenK is now known as W4|_|_YW0R|_D | ||
| wallyworld_ | @%^@#%^!@^ | 06:45 |
| LPCIBot | Project devel build #999: STILL FAILING in 3.5 sec: https://lpci.wedontsleep.org/job/devel/999/ | 06:45 |
| === W4|_|_YW0R|_D is now known as StevenK | ||
| wallyworld_ | smart arse | 06:46 |
| StevenK | Oh damn it! | 06:46 |
| StevenK | JENKINS! | 06:46 |
| wallyworld_ | 3.5 is pretty short | 06:46 |
| StevenK | The slave was already corrupted | 06:46 |
| henninge | wallyworld_: Hi! ;) | 06:52 |
| wallyworld_ | henninge: hi there | 06:53 |
| wallyworld_ | i assume you saw my comments :-) | 06:53 |
| henninge | wallyworld_: yes, thank you ;) | 06:54 |
| wallyworld_ | np. i hope they made sense | 06:54 |
| henninge | wallyworld_: I replied rather lengthy | 06:54 |
| henninge | very much so | 06:54 |
| wallyworld_ | ah right. i'll look at my email | 06:54 |
| wallyworld_ | henninge: right, i see the disabling of the form submit button now. and it will be re-enabled if a request build succeeds or partially succeeds? | 07:00 |
| henninge | wallyworld_: not currently, no. | 07:01 |
| wallyworld_ | i think the original request build form did this? | 07:01 |
| henninge | wallyworld_: AFAIUI the user is supposed to close the dialog and re-open. | 07:01 |
| henninge | no | 07:01 |
| henninge | it did not | 07:01 |
| henninge | or, let me check that ... ;) | 07:02 |
| wallyworld_ | ok. i thought it was either re-enabled or else the user could click an as yet unbuilt distro series and it would be enabled | 07:02 |
| wallyworld_ | without requiring the form to be closed and reopened | 07:02 |
| henninge | I just checked, the button is only enabled in the connect function. | 07:03 |
| wallyworld_ | s/connect/correct ? | 07:03 |
| henninge | wallyworld_: There are other things to fix in this dialog, and also in its code but that is outside of the scope of what I am doing here. | 07:03 |
| henninge | (which as alread widened a lot ;) | 07:04 |
| wallyworld_ | sure. i'm just a bit concerned that the button used to work a certain way but may not have kept the same behaviour] | 07:04 |
| henninge | wallyworld_: the connect_requestbuilds function that connects the link | 07:04 |
| henninge | actually, it is done in the click handler, when the dialog is opened | 07:05 |
| henninge | the enabling, I mean. | 07:05 |
| henninge | possible, but that change was before me ;-) | 07:05 |
| henninge | s/was/happened/ | 07:06 |
| wallyworld_ | perhaps | 07:06 |
| wallyworld_ | so in the case hwere the user clicks 2 out of 3 series, and the build for one of them is queued but the other has an "already building" error or something. they should then be able to click the 3rd series that was not part of the original selection and request a build | 07:07 |
| wallyworld_ | without having to close the form | 07:07 |
| henninge | wallyworld_: I agree completely! | 07:09 |
| wallyworld_ | i'm fairly sure that's how it worked before. perhaps it has changed in a branch previous to yours. if it works diffeently now, it would be cool if a bug were raised so that we didn't forget to fix it. or if the behaviour is different because of the changes in your mp, it would be cool to see it fixed in there | 07:09 |
| wallyworld_ | sorry for being a pain in the arse | 07:09 |
| henninge | wallyworld_: I just looked at the code previous to mine (bzr cat -r :submit) and the button is never re-enabled. | 07:10 |
| wallyworld_ | ah ok. seems like you are off the hook :-) | 07:10 |
| wallyworld_ | i'll update the mp with r=me and get jtv to mentor | 07:11 |
| jtv | oh, hi wallyworld_! | 07:11 |
| henninge | wallyworld_: I am about to start the fourth branch to fix this one bug about error reporting, so I will be very reluctant to add anything else to it ... ;-) | 07:11 |
| wallyworld_ | i thought that would wake yu up :-) | 07:11 |
| henninge | wallyworld_: Thank you! | 07:11 |
| wallyworld_ | henninge: sure. any fix to the submit button warrents it's own bug | 07:12 |
| henninge | yup, I'll file that | 07:12 |
| wallyworld_ | awesome. thanks. | 07:12 |
| wallyworld_ | jtv: over to you. it's beer o'clock for me but i'll pop back later to check on things https://code.launchpad.net/~henninge/launchpad/bug-824435-failure-reporting-3/+merge/72908 | 07:17 |
| jtv | wallyworld_: cheers | 07:17 |
| === wallyworld_ changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: - | Critical bugs: 237 - 0:[#######=]:256 | ||
| jtv | in more sense than one | 07:17 |
| wallyworld_ | no, thank you | 07:17 |
| wallyworld_ | :-) | 07:17 |
| * jtv gives wallyworld_ a puzzled frown | 07:18 | |
| wallyworld_ | it's been along day. i've resorted to converting a doc test to a unit test so i can debug | 07:18 |
| wallyworld_ | jtv: sorry, the subtlety of my Two Ronnies reference was obviously lost | 07:18 |
| jtv | Evidently. | 07:19 |
| * jtv needs to catch up on his Two Ronnies. | 07:19 | |
| * wallyworld_ opens a bottle and drinks :-) | 07:19 | |
| wallyworld_ | ahhhh | 07:19 |
| jtv | And "resorted to" converting a doc test to a unit test? You deserve, if not a medal, then at least a cool beer! | 07:19 |
| wallyworld_ | yep :-) | 07:19 |
| jtv | Wow, that was timely | 07:19 |
| wallyworld_ | still only 3/4 of the way through | 07:20 |
| wallyworld_ | frustrating day today | 07:20 |
| jtv | wallyworld_: this'll cheer you up… <compose>34 | 07:24 |
| henninge | jtv: ³¼? | 07:27 |
| henninge | wallyworld_: bug 834463 | 07:28 |
| _mup_ | Bug #834463: Re-enable submit button in request builds overlay. <Launchpad itself:Triaged> < https://launchpad.net/bugs/834463 > | 07:28 |
| jtv | henninge: that's cheating! You did <compose>^3<compose>14, didn't you? | 07:28 |
| henninge | jtv: well, I think "Alt Gr" is the compose key on the German keyboard and if I hold it down an press 34, I get ³¼ | 07:29 |
| * jtv fondly remembers the can't-get-used-to-metric-but-we'll-give-decimal-a-go ²²/₁₀ pricing at US petrol stations. | 07:29 | |
| wgrant | henninge: Alt Gr is not quite the same thing. | 07:29 |
| wgrant | It's just a third set of characters, AIUI. | 07:29 |
| wgrant | Compose is a little more powerful :) | 07:29 |
| jtv | But good to know there's yet another standard to confuse things. ☺ | 07:30 |
| * henninge hates to be lacking power … :( | 07:30 | |
| wgrant | henninge: I don't know of any layout that has a "Compose" key. In Ubuntu, at least on US keyboards, you have to configure it manually. I use RAlt. | 07:30 |
| henninge | ah, I see | 07:31 |
| wgrant | It is displeasing that there is not one configured by default. | 07:31 |
| henninge | RAlt *is* Alt Gr | 07:31 |
| wgrant | But perhaps there are people around who use RAlt or Menu for their traditional purposes. | 07:31 |
| soren | For many European keyboard layouts, RAlt is already special. | 07:31 |
| henninge | We need it here for {[]}€~ | 07:31 |
| soren | The menu key... Not so much. | 07:31 |
| henninge | oh, and for \ | 07:33 |
| henninge | one more reason to hate DOS paths | 07:33 |
| wgrant | At least it's not a French keyboard. | 07:33 |
| wgrant | rvba is a bad person. | 07:33 |
| wgrant | German keyboards aren't actually too bad. | 07:34 |
| wgrant | But French, aaaaaaa | 07:34 |
| rvba | wgrant: I think you did very well with a French keyboard. I shall bring you one next time we meet :) | 07:34 |
| henninge | I can live with it | 07:34 |
| henninge | :-D | 07:34 |
| jtv | What happens when you try to type qwertz on an azerty keyboard? | 07:40 |
| jtv | You probably turn Alsatian. | 07:41 |
| adeuring | good morning | 07:52 |
| jtv | hi adeuring | 08:13 |
| adeuring | hi jtv! | 08:15 |
| mrevell | Mornin' | 08:17 |
| jtv | hi mrevell | 08:18 |
| wgrant | henninge: 404 | 08:18 |
| henninge | wgrant: yes, that's the point ;) | 08:19 |
| wgrant | Ah! | 08:19 |
| === wgrant changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: - | Critical bugs: 243 - 0:[#######=]:256 | ||
| henninge | Anybody know if Matt owns a baseball bat? | 08:20 |
| mrevell | henninge, This Matt does. Is this the Matt you're looking for? | 08:23 |
| henninge | yup | 08:23 |
| henninge | mrevell: http://yuilibrary.com/something.html | 08:24 |
| mrevell | heh | 08:24 |
| bigjools | mrevell would need a cricket bat | 08:32 |
| === adeuring changed the topic of #launchpad-dev to: #launchpad-dev ist: https://dev.launchpad.net/ | On call reviewer: adeuring | Critical bugs: 237 - 0:[#######=]:256 | ||
| mrevell | The unmistakable sound of willow against bugs. | 08:33 |
| bigjools | we really need to block MPs on vcs imported branches | 08:47 |
| wgrant | Yeah. | 08:47 |
| * bigjools files a bug | 08:49 | |
| bigjools | mrevell. henninge: the lockerz.com website has a good oops page, it's a space man floating around on the page with a message "Houston, we've had a problem!" | 08:54 |
| henninge | bigjools: they seem to have different ones. Now I see a dog licking my screen .... ;-) | 08:55 |
| bigjools | lol | 08:55 |
| === almaisan-away is now known as al-maisan | ||
| stub | Given we are going to have 5 minute outages a couple of times a week, if anyone is bored... | 09:20 |
| wgrant | No reason we can't get them sub-minute :) | 09:20 |
| nigelb | wgrant: Thanks for qa-ing :D | 09:21 |
| * nigelb was asleep | 09:21 | |
| * wgrant needed to get a regression fix out. | 09:21 | |
| nigelb | stub: I now know exactly how you feel when your clock is messed up. | 09:21 |
| jtv | wgrant: please tell me you fixed that brittle bzr versioning test! | 09:21 |
| wgrant | jtv: 'fraid not. | 09:21 |
| wgrant | Feel free to do the 5-character fix, though. | 09:22 |
| nigelb | int()? | 09:22 |
| * nigelb can do it right away | 09:22 | |
| jtv | Yup | 09:22 |
| jtv | Oh thanks | 09:22 |
| jtv | I'd be happy to review it. | 09:22 |
| nigelb | have the bug number handy? | 09:22 |
| nigelb | no wait, I have it | 09:22 |
| * jtv digs | 09:22 | |
| jtv | oh | 09:22 |
| nigelb | bug 833743 | 09:22 |
| _mup_ | Bug #833743: test_versioninfo fails when system has bzr 2.4 <test-system> <Launchpad itself:Triaged> < https://launchpad.net/bugs/833743 > | 09:22 |
| bigjools | wgrant: do you know if the ec2 image got updated with the deps for the xz branch? | 09:25 |
| StevenK | Yes | 09:26 |
| StevenK | I did it | 09:26 |
| bigjools | thanks | 09:26 |
| bigjools | and thanks | 09:26 |
| nigelb | I wish the Updating diff page had ajaxy magic not forcing me to refresh every few seconds. | 09:27 |
| StevenK | nigelb: Wait | 09:28 |
| StevenK | It was demo'd at the epic | 09:28 |
| nigelb | oooooooh \o/ | 09:28 |
| nigelb | I need to keep wishing for more :P | 09:28 |
| nigelb | jtv: https://code.launchpad.net/~nigelbabu/launchpad/833743-revno-fail/+merge/73008 | 09:29 |
| jtv | nigelb: done | 09:29 |
| jtv | nigelb: need me to land it? | 09:30 |
| nigelb | Yes, please :) | 09:30 |
| jtv | Well, that should fix that devel failure. Thanks nigelb! | 09:41 |
| jtv | adeuring: could I beg you for a review? https://code.launchpad.net/~jtv/launchpad/bug-832661/+merge/73009 | 09:48 |
| adeuring | jtv: sure | 09:48 |
| jtv | thanks | 09:48 |
| wgrant | bigjools: It landed via ec2, so I hope so :) | 09:59 |
| wgrant | bigjools: Image version 519 | 09:59 |
| wgrant | German has infiltrated the channel again :( | 09:59 |
| bigjools | nigelb: my team will be finishing that work after we finish derived distros | 10:00 |
| bigjools | wgrant: good. I got fed up with ec2 randomly kicking out 2 of my branches all week so I just lp-landed them. | 10:01 |
| wgrant | bigjools: Odd, the image was fixed a day or so before it landed. | 10:01 |
| jtv | adeuring: argh! I just realized (because everyone keeps %$#@ distracting me) I forgot to set up the branch dependency. That diff should be a lot smaller. | 10:04 |
| adeuring | jtv: ah, cool :) | 10:04 |
| jtv | Branches that were unable to land because buildbot has been near-permanently broken the past few days. | 10:05 |
| jtv | adeuring: re-submitted as https://code.launchpad.net/~jtv/launchpad/bug-832661/+merge/73012 | 10:06 |
| adeuring | ack | 10:06 |
| nigelb | jtv: \o/ | 10:09 |
| nigelb | bigjools: Yay! | 10:09 |
| bigjools | nigelb: the basic code is working but we need to make it production-worthy which will be tricky as we have to set up some stat counting for Rabbit | 10:10 |
| nigelb | ooh, rabbitmq, neat | 10:10 |
| nigelb | did you guys deal with the HA rabbit thing that was on the list a while back? | 10:11 |
| bigjools | yeah, once this is done we'll be able to add more async updates to pages that wait for jobs | 10:11 |
| nigelb | something like the sync pages you guys did? | 10:11 |
| bigjools | that sort of thing | 10:11 |
| bigjools | we'll do popular pages first though :) | 10:12 |
| bigjools | can't remember where we got to with HA rabbit | 10:12 |
| wgrant | bigjools: Rabbit metrics will be pretty easy with the plugin. | 10:12 |
| wgrant | And I think it has an HA exemption. | 10:12 |
| wgrant | The hardest bit is probably getting OOPSes into txlongpoll. | 10:12 |
| bigjools | yes | 10:13 |
| wgrant | But that won't be terrifyingly difficult. | 10:14 |
| bigjools | which plugin is this? | 10:14 |
| wgrant | With lifeless' work this week. | 10:14 |
| wgrant | bigjools: rabbitmq-management | 10:14 |
| wgrant | ppa:wgrant/rabbitmq | 10:14 |
| bigjools | ah cool, didn't know about that | 10:14 |
| nigelb | Doesn't LP already install rabbitmq by default? | 10:14 |
| wgrant | Has packages. | 10:14 |
| wgrant | nigelb: Yes, but it's not actually used. | 10:14 |
| * nigelb remembers having rabbit on his ystem | 10:14 | |
| wgrant | bigjools: It provides a web UI and JSON API with counters and rates and stuff. | 10:14 |
| bigjools | nigelb: you can turn it off, the tests that need it will start it | 10:14 |
| bigjools | wgrant: oh, awesome, just what we need | 10:15 |
| wgrant | bigjools: Exactly. | 10:15 |
| bigjools | just need to work with the losas to get that nagiosed | 10:15 |
| wgrant | Works on Lucid->Natty, not sure about Oneiric. | 10:16 |
| wgrant | Oneiric has 2.5, so we should probably upgrade to that everywhere. | 10:17 |
| wgrant | Will investigate that next week. | 10:17 |
| nigelb | bigjools: nah, I use it occasionally with other stuff | 10:18 |
| nigelb | (like celery) | 10:18 |
| nigelb | Oooh. I just realized. With that 5 char fix. I now have 5th non-canonical LP contributor spot. | 10:18 |
| bigjools | LP generally need a very, very solid and easy story to communicate between components | 10:19 |
| bigjools | or SOA will be awful | 10:19 |
| nigelb | Heh, yeah. Fun. | 10:19 |
| nigelb | This means writing tests for that stuff will be further fun. | 10:20 |
| wgrant | bigjools: Well, most SOA stuff will not be through rabbitmq, but some hopefully will ebe. | 10:21 |
| bigjools | wgrant: either way, it needs to be easy to communicate :) | 10:21 |
| wgrant | bigjools: Indeed. | 10:32 |
| wgrant | bigjools: At least OOPSes for WSGi apps are just about trivial now. | 10:32 |
| wgrant | bigjools: Have you seen the zeca replacement? | 10:32 |
| === jtv is now known as jtv-afk | ||
| bigjools | wgrant: there's a zeca replacement? | 10:39 |
| adeuring | jtv-afk: r=me | 10:42 |
| wgrant | bigjools: lp:python-gpgfixtures | 10:43 |
| wgrant | bigjools: lifeless wrote it, to be less huge and not depend on Twisted. | 10:43 |
| wgrant | So lp:gpgverifyd doesn't need a Twisted dep. | 10:43 |
| bigjools | cool | 10:43 |
| jtv-afk | thanks adeuring! | 10:44 |
| wgrant | And once gpgverifyd is up, poppy's time in the tree can come to an end. | 10:48 |
| jtv-afk | That's it for me. Have a good weekend, people! | 10:49 |
| bigjools | and there was much rejoicing | 10:49 |
| bigjools | nn jtv-afk | 10:49 |
| wgrant | Night jtv-afk. | 10:49 |
| nigelb | Night jtv-afk! | 10:49 |
| jtv-afk | nn | 10:49 |
| nigelb | Waiting for MFBT :/ | 10:50 |
| wgrant | nigelb: I see you are #5 now! | 10:59 |
| nigelb | wgrant: I noticed! \o/ | 10:59 |
| nigelb | 3 more branches to #4 | 10:59 |
| nigelb | I landed 3 branches this week. If I keep this up, I just may have a chance to beat you :D | 11:00 |
| wgrant | Yup. | 11:00 |
| bigjools | activate the HIREBOT | 11:01 |
| nigelb | lol | 11:01 |
| wgrant | Heh. | 11:02 |
| nigelb | Did anyone come up with stats for the LP team yet? | 11:02 |
| nigelb | It would nice to see how outside contributors compare with the actual team :D | 11:02 |
| * bigjools wants to eradicate security.cfg | 11:04 | |
| wgrant | nigelb: I have a branch which gets it mostly working for ~launchpad too. | 11:04 |
| nigelb | oooh :D | 11:05 |
| === henninge is now known as henninge-lunch | ||
| wgrant | nigelb: But for some idea, 'bzr stats' is helpful. | 11:09 |
| nigelb | hmm | 11:10 |
| nigelb | need to try it when I get to my computer. (at work) | 11:10 |
| bigjools | wgrant: what is the number that stats is outputting? It doesn't say anywhere, not in the output nor the help. | 11:13 |
| === al-maisan is now known as almaisan-away | ||
| jelmer | bigjools: number of commits | 11:14 |
| bigjools | jelmer: including all levels I guess? | 11:15 |
| jelmer | bigjools: yep | 11:15 |
| bigjools | jelmer: ok thanks. | 11:15 |
| bigjools | so it shows who does local commits the most :) | 11:15 |
| jelmer | so it's not a terribly good metric for e.g. Launchpad, given some people do a commit for each two lines they write and others only \ | 11:15 |
| wgrant | Yup. | 11:15 |
| jelmer | a couple of times per landing | 11:15 |
| bigjools | the one exception is Celso | 11:16 |
| nigelb | Celso? | 11:16 |
| bigjools | he was basically a coding machine | 11:16 |
| nigelb | heh | 11:16 |
| nigelb | I like commiting multiple times | 11:17 |
| nigelb | (because I keep making stupid mistakes) | 11:17 |
| wgrant | Ste | 11:17 |
| wgrant | StevenK is the worst offender :P | 11:17 |
| nigelb | lol | 11:17 |
| wgrant | One 1100 line commit per branch or so. | 11:17 |
| nigelb | but he uses perl to remove code | 11:17 |
| wgrant | True. | 11:17 |
| wgrant | Makes it even worse. | 11:17 |
| nigelb | That's cheating :D | 11:17 |
| bigjools | it needs to be weighted by lines per commit | 11:20 |
| jelmer | it'd be hard to distinguish between actual lines changed and lines moved | 11:22 |
| bigjools | yeah it's not perfect but better than just commits I think | 11:22 |
| bigjools | ok I need help because security.cfg is such a monstrosity I have no idea what tables I need to add to it so my process can close a bug | 11:24 |
| bigjools | how do I ascertain what I need? | 11:25 |
| wgrant | Hahaha | 11:25 |
| bigjools | this is a leading question :) | 11:25 |
| wgrant | Look at process-accepted | 11:25 |
| bigjools | I am | 11:25 |
| bigjools | but ... | 11:25 |
| bigjools | you see where I am driving with this? | 11:26 |
| wgrant | Yes, it's hard. | 11:26 |
| wgrant | Partly because LP grew into a 700KLOC monstrosity. | 11:26 |
| bigjools | security.cfg just needs to die | 11:27 |
| wgrant | I'm not sure whether it's worth it. | 11:27 |
| wgrant | But it would be a lot easier if it wasn't all one thing. | 11:27 |
| bigjools | given that the webapp has carte blanche anyway, why are we restricting scripts? | 11:27 |
| wgrant | I can only think of a couple of bugs that have been revealed by the restrictions. | 11:28 |
| bigjools | ok how evil is it to inherit queued in sync_packages? | 11:28 |
| * jelmer remembers a few incidents with security.cfg being too strict | 11:28 | |
| bigjools | because I simply cannot be arsed to work this out | 11:28 |
| bigjools | jelmer: indeed | 11:28 |
| bigjools | it just seems to cause problems, not solve any | 11:28 |
| wgrant | Only a few? :) | 11:28 |
| bigjools | we could do something more intelligent in security.cfg and have groups that represent actions, not scripts | 11:29 |
| wgrant | I've been considering that for a while. | 11:30 |
| bigjools | there's a little of that already - well done to whoever made "translations_approval" | 11:30 |
| wgrant | I don't think there need to be too many. | 11:30 |
| wgrant | Since bug actions need like 20 tables, that probably covers a lot of the lcutter. | 11:31 |
| bigjools | well since PCJ does all of what queued does, I am going to inherit it, screw it | 11:31 |
| wgrant | Sounds like a plan. | 11:32 |
| wgrant | A not very good plan, but an effective one :) | 11:32 |
| bigjools | I'd rather it was too wide than too narrow | 11:32 |
| wgrant | Indeed. | 11:32 |
| bigjools | I'm really not sure what we are achieving with the permissions | 11:32 |
| === mrevell is now known as mrevell-lunch | ||
| LPCIBot | Project devel build #1,000: STILL FAILING in 4 hr 48 min: https://lpci.wedontsleep.org/job/devel/1000/ | 11:51 |
| === henninge-lunch is now known as henning | ||
| === henning is now known as henninge | ||
| === bac changed the topic of #launchpad-dev to: #launchpad-dev ist: https://dev.launchpad.net/ | On call reviewer: adeuring, bac | Critical bugs: 237 - 0:[#######=]:256 | ||
| bac | good morning adeuring | 12:08 |
| adeuring | good morning bac! | 12:08 |
| henninge | Anybody got an idea why the LibrarianLayer might be failing locally like this? http://paste.ubuntu.com/675201/ | 12:21 |
| bigjools | henninge: clear out /var/tmp stuff | 12:25 |
| bigjools | including pid file | 12:25 |
| henninge | bigjools: I don't see anything testrunner or launchapd specific in /var/tmp | 12:33 |
| henninge | the only pid file was development-google-webservice.pid | 12:33 |
| === mrevell-lunch is now known as mrevell | ||
| mrevell | le | 12:34 |
| mrevell | matsubara, hey mumble? | 12:34 |
| matsubara | mrevell, hey, yes! | 12:34 |
| wgrant | henninge: Chameleon does some very evil stuff; I need to talk to gary_poster about removing that or it. | 12:34 |
| wgrant | henninge: dpkg -S setuptools.egg-info | 12:34 |
| wgrant | Oh, gary_poster is here. | 12:34 |
| wgrant | gary_poster: Hi. | 12:34 |
| gary_poster | wgrant, on call will ping | 12:35 |
| wgrant | k | 12:35 |
| wgrant | henninge: Which Ubuntu release has this machine been upgraded from? | 12:36 |
| wgrant | henninge: I suspect you have a non-dpkg-managed /usr/lib/python2.6/setuptools.egg-info, as we found on loganberry and several other production machines. | 12:36 |
| henninge | wgrant: from maverick to natty | 12:37 |
| wgrant | henninge: We deleted it, and everything worked. | 12:37 |
| wgrant | henninge: Hmm. | 12:37 |
| wgrant | So, /usr/lib/python2.6/dist-packages/setuptools.egg-info is meant to be a symlink. | 12:37 |
| wgrant | I suspect it's a directory on your machine. | 12:37 |
| henninge | python-setuptools: /usr/lib/python2.6/dist-packages/setuptools.egg-info | 12:38 |
| henninge | python-setuptools: /usr/lib/python2.7/dist-packages/setuptools.egg-info | 12:38 |
| henninge | python-setuptools: /usr/share/pyshared/setuptools.egg-info | 12:38 |
| gary_poster | wgrant, I'm aware of one evilness--z3c.ptcompat is perhaps the hairiest Python I've ever seen. Perhaps. It sounds like you have another? | 12:38 |
| gary_poster | z3c.ptcompat can eventually go | 12:39 |
| gary_poster | which was why I was not overly worried about that one | 12:39 |
| wgrant | gary_poster: I invite you to read the top of chameleon/template.py | 12:39 |
| gary_poster | heh, ok, going wgrant | 12:40 |
| cjwatson | there are problems with migrating dpkg-managed filesystem entries between symlinks and directories - it has to be done by manual maintainer script code (for some excellent reasons) | 12:40 |
| wgrant | gary_poster: It hashes, in undefined order, the versions of every package it can find on the system. | 12:40 |
| cjwatson | unfortunately .egg-info entries became one or the other at the whim of complex build systems | 12:40 |
| cjwatson | (i.e. a simple rebuild could change without any obvious reason in the source package) | 12:40 |
| wgrant | cjwatson: Yay | 12:40 |
| cjwatson | it's probably simplest to rm -rf the .egg-info file in question and then reinstall the package that owns it | 12:41 |
| wgrant | cjwatson: Interestingly, on the production machines the package was no longer installed. | 12:41 |
| wgrant | I presume it was removed after the upgrade. | 12:41 |
| wgrant | But didn't remove the directory, because it was meant to be a symlink. | 12:41 |
| cjwatson | that's a bit harder to explain, but perhaps if dpkg expects it to be a directory it uses rmdir not unlink | 12:41 |
| cjwatson | rather than unlink => if EISDIR rmdir | 12:42 |
| wgrant | Yeah. | 12:42 |
| wgrant | Anyway, on production where it's been a problem we've just deleted the directory, and reinstalled the package if it was still installed. | 12:44 |
| wgrant | All seems happy. | 12:44 |
| wgrant | But that part of Chameleon really worries me. | 12:44 |
| === almaisan-away is now known as al-maisan | ||
| gary_poster | wgrant, that's nothing compared to z3c.ptcompat, IMO. :-P | 12:47 |
| gary_poster | Anyway, the undefined order is probably barely alright practically for what the purpose appears to be, which is to enforce some kind of "rebuild when things change," given that the undefined order is stable in a Python release, and a new Python release ought to trigger this kind of thing anyway. | 12:47 |
| gary_poster | But we certainly can and should convince the person to order them. Beyond that, given that Chameleon is a compile-to-Python template system, the basic idea strikes me as reasonable, within the context of the kind of task Chameleon has set itself to. | 12:47 |
| wgrant | gary_poster: It is revolting and causing cronspam and breaking the test suite. I guess we may need to clean up all production and dev machines. | 12:50 |
| gary_poster | wgrant, "revolting" is a wildly unnecessary description, IMO, not that I have anything to do with it. Just seems unproductive to talk that way. Causing cronspam I saw; it is because of broken packages in our distro's packaging system, which is a chronic and annoying problem for anyone who does work with system Pythons. I have not seen a broken test suite. | 12:52 |
| gary_poster | wgrant, practically, what machines have been taken care of? | 12:54 |
| cjwatson | somebody should file an Ubuntu bug about that python-setuptools problem if they haven't already; we should be able to take care of it in an update | 12:54 |
| cjwatson | if you can't rely on system packages, that's a pretty serious problem from our POV | 12:54 |
| gary_poster | cjwatson, when I've experience this in the past, I was unable to identify a cause. My suspicion has been distro upgrades not cleaning things up properly. | 12:56 |
| cjwatson | gary_poster: I've roughly outlined the cause above. | 12:56 |
| cjwatson | gary_poster: a bug about the fact of the problem is sufficient | 12:56 |
| gary_poster | I have no hard evidence to support this and have been unable to dupe reliably, so it's the kind of...ok OK! Great, cjwatson, I'll read the backlog and file it then. Thanks | 12:56 |
| cjwatson | (or at least, the very likely cause) | 12:57 |
| gary_poster | heh, good enough | 12:57 |
| cjwatson | we can go through the history and hunt for symlink<->directory chnges | 12:57 |
| cjwatson | *changes | 12:57 |
| cjwatson | I agree it's likely to be a pain to come up with a coherent reproducer for | 12:57 |
| cjwatson | but let's not burn too many people's time on that when we have a pretty good hypothesis | 12:57 |
| gary_poster | +1 | 12:58 |
| wgrant | cjwatson: I tried a clean hardy->lucid upgrade with python-setuptools installed, and it worked fine. | 12:58 |
| wgrant | But AFAICT on loganberry that's what broke it. | 12:58 |
| wgrant | It's possible there was some old launchpad PPA package, though... I don't have logs to find out. | 12:58 |
| * cjwatson will have a quick hunt through publishing history | 12:58 | |
| gary_poster | cjwatson, wgrant, https://bugs.launchpad.net/ubuntu/+source/python-setuptools/+bug/834698 | 13:08 |
| _mup_ | Bug #834698: setuptools.egg-info can end up as a directory when it is meant to be a symlink <python-setuptools (Ubuntu):New> < https://launchpad.net/bugs/834698 > | 13:08 |
| wgrant | It's not just setuptools. That's just the most common one. | 13:09 |
| wgrant | Ah, you say that in the bug. | 13:09 |
| gary_poster | yeah | 13:09 |
| === salgado_ is now known as salgado | ||
| wgrant | bigjools: Oh, you're using changelog_entry to create the aggregate changelog? | 13:42 |
| wgrant | bigjools: I was expecting to use the real librarian changelog, but I guess that's probably OK... | 13:42 |
| wgrant | Except not. | 13:43 |
| wgrant | It's bad. | 13:43 |
| wgrant | It searches for all SPRs in any context, doesn't it? | 13:43 |
| bigjools | yes, hmm | 13:43 |
| bigjools | I thought that was ok but maybe not | 13:43 |
| wgrant | It'll count all PPA uploads, Ubuntu uploads, Linaro uploads, etc. | 13:44 |
| bigjools | yes | 13:44 |
| wgrant | As well as the general badness and unreliability that changelog_entry entials. | 13:44 |
| wgrant | entails. | 13:44 |
| bigjools | what is wrong with changelog_entry? | 13:44 |
| wgrant | It is a guess. | 13:45 |
| wgrant | A historically error-prone guess. | 13:45 |
| bigjools | can you be a bit more explicit? | 13:45 |
| wgrant | Let me find some bugs. | 13:45 |
| wgrant | I'm looking :) | 13:45 |
| wgrant | Ah, it's change_summary that is the cause of bug #144620. But changelog_entry for the gina case is a guess, and for Ubuntu it is frequently wrong because people build packages badly. | 13:46 |
| _mup_ | Bug #144620: Some displayed sourcepackagerelease changes files don't have attribution <lp-soyuz> <Launchpad itself:Triaged> < https://launchpad.net/bugs/144620 > | 13:46 |
| wgrant | Worse still, if Linaro then copy from Ubuntu, they will miss everything. | 13:46 |
| wgrant | Because Ubuntu only has the last SPR. | 13:46 |
| bigjools | doesn't matter does it? | 13:47 |
| wgrant | Why not? | 13:47 |
| bigjools | it's only for acceptance emails | 13:47 |
| bigjools | it's right that each SPR has only its changelog | 13:47 |
| bigjools | what sync-source does is crack | 13:47 |
| wgrant | Er, no :) | 13:47 |
| bigjools | can you try to be less condescending? | 13:47 |
| wgrant | An upload's changes file is meant to contain all the intermediate changelog entries. | 13:48 |
| wgrant | Acceptance emails should too. | 13:48 |
| wgrant | So they actually list the changes. | 13:48 |
| wgrant | And not just the last change. | 13:48 |
| wgrant | And isn't this to be used for bugs too? | 13:48 |
| wgrant | If we restrict the SPR search to those published in the origin archive, Debian->Ubuntu copies will work. | 13:49 |
| wgrant | But Debian->Ubuntu->Linaro copies will magically only have the last SPR. | 13:49 |
| wgrant | So the acceptance emails will be truncated, and not enough bugs will be closed. | 13:49 |
| wgrant | This is easily solved by just using the actual changelog, I think. | 13:50 |
| bigjools | including previous version's changelogs in a particular SPR is weird | 13:50 |
| wgrant | We shouldn't include them in the SPR. | 13:50 |
| wgrant | We should consider them as part of the upload/copy. | 13:51 |
| wgrant | That's the whole point of this change, isn't it? | 13:52 |
| wgrant | To include more than just the actual SPR that is being copied. | 13:52 |
| bigjools | correct | 13:52 |
| wgrant | To do that only for the first copy seems less than ideal. | 13:52 |
| henninge | deryck, abentley: From the w3c spec: | 13:52 |
| henninge | 10.4.1 400 Bad Request | 13:52 |
| henninge | The request could not be understood by the server due to malformed syntax. The client SHOULD NOT repeat the request without modifications. | 13:52 |
| wgrant | Particularly when changelog_entry is a reasonably awful thing in the first place, and we have the changelog file a couple of milliseconds away. | 13:53 |
| henninge | But I will still use 400 if that is how we do it around here ... ;-) | 13:53 |
| bigjools | what does gina put in changelog? | 13:53 |
| abentley | henninge: right. The HTTP spec provides no way to signal that the request was unacceptable for reasons other than bad syntax. | 13:53 |
| wgrant | bigjools: I think it puts everything between the last SPR published and the current one. | 13:53 |
| StevenK | wgrant: Personally, I'd like to kill changelog_entry | 13:53 |
| deryck | henninge, I don't think it's a perfect match, but it's close enough. the spec makes me feel better about it actually. :) | 13:54 |
| wgrant | StevenK: I very much would. | 13:54 |
| henninge | abentley: because it was not unacceptable. | 13:54 |
| wgrant | StevenK: It is very wrong in the new world. | 13:54 |
| wgrant | StevenK: Because it depends on the previous publication. | 13:54 |
| abentley | henninge: it was unacceptable. The request could not be performed. | 13:54 |
| wgrant | It's really part of the upload, not the source package. | 13:54 |
| henninge | abentley: no, it was performed, at least in part | 13:54 |
| StevenK | And even so, we don't even keep the .changes file around | 13:55 |
| wgrant | StevenK: We do... | 13:55 |
| henninge | abentley: I would expect a 4xx to mean that nothing was changed on the server. | 13:55 |
| wgrant | StevenK: We strip the sig, but we keep the changes file for every well-formed upload. | 13:55 |
| abentley | henninge: perhaps we differ on what "perfomed" means. | 13:55 |
| wgrant | henninge: As would I. | 13:55 |
| henninge | but as I said, I am not going to go against our customs here ... | 13:56 |
| henninge | ... at least not in this branch. | 13:56 |
| henninge | wgrant: oh, so you are aware of our misuse of 400s? ;-) | 13:57 |
| wgrant | bigjools: I think changelog_entry is a near-adequate compromise for displaying in the web UI sometimes, but we should avoid it where possible. And it's now possible to go direct to the changelog and get a correct result, so we should do that. | 13:57 |
| wgrant | henninge: No :( | 13:57 |
| wgrant | henninge: Where? :( | 13:57 |
| henninge | everywhere, so I am told. | 13:57 |
| bigjools | wgrant: I am verifying what gina does, I don't trust it | 13:57 |
| wgrant | henninge: Most 400s should abort the transaction, so the only server changes will be sessions and OAuth nonces... | 13:58 |
| wgrant | henninge: Is that not the case? | 13:59 |
| wgrant | bigjools: It is not trustworthy. | 13:59 |
| wgrant | bigjools: But I think it looks at the last published SPR, and takes the entries since then. | 13:59 |
| bigjools | and looking at gina code makes me want to scratch my eyeballs out | 13:59 |
| wgrant | bigjools: To do anything else would make little sense. | 13:59 |
| henninge | wgrant: nope, at least not for the case I got here. | 13:59 |
| cr3 | does that apache configuration for serving static files on launchpad do anything special for etags? | 13:59 |
| wgrant | cr3: gary_poster changed all that to be much better recently, I believe. | 13:59 |
| wgrant | henninge: Which is that? | 13:59 |
| henninge | wgrant: it returns a 400 if not all builds for a recipe could be requested. | 13:59 |
| wgrant | Ahh. | 13:59 |
| cr3 | wgrant: might that be available somewhere for me to see? | 13:59 |
| wgrant | cr3: I'm hoping gary_poster will be able to tell you :) | 14:03 |
| wgrant | henninge: That sounds bad to me. | 14:03 |
| cr3 | wgrant: lets mention his nick, gary_poster, as often as possible to get his attention :) | 14:03 |
| wgrant | henninge: I would assume that a 400 meant no changes had been made. | 14:03 |
| henninge | no need to convince me ... ;-) | 14:03 |
| wgrant | I guess the really corect thing to do is use a 207... but aaaaaaaaa | 14:07 |
| bigjools | this Gina code makes me want to go back to C++ | 14:10 |
| gary_poster | wgrant, cr3, hiya :-) | 14:11 |
| wgrant | bigjools: gina does not age well. | 14:12 |
| henninge | deryck: I think abentley understood that situation. | 14:12 |
| bigjools | it's hideous | 14:12 |
| wgrant | bigjools: Although it wasn't ideal in the first place either, no. | 14:12 |
| gary_poster | cr3, yes, it does do something special for ETags | 14:12 |
| wgrant | # XXX kiko 2005-11-05: this is very funny. | 14:12 |
| gary_poster | heh | 14:12 |
| cr3 | gary_poster: awesome, could I have a looksee at the apache config? | 14:12 |
| abentley | henninge: Well, not completely, but I do feel that if it wasn't completely successful, the status code should reflect that. | 14:12 |
| bigjools | wgrant: where is it checking to see what was previously published? | 14:12 |
| abentley | henninge: ideally, we'd have a separate status for each request. | 14:12 |
| wgrant | bigjools: It's not. | 14:12 |
| wgrant | bigjools: It just takes the first entry. | 14:12 |
| bigjools | oh. yay | 14:12 |
| wgrant | bigjools: This is, as we say, "wrong". | 14:12 |
| bigjools | so my hunch was write | 14:12 |
| bigjools | ffs | 14:12 |
| bigjools | right | 14:12 |
| wgrant | bigjools: changelog_entry is not to be trusted. It doesn't really belong on SPR at all. | 14:12 |
| bigjools | ok so I will switch to changelog | 14:12 |
| wgrant | bigjools: It's mainly there to permit fast access for views, and because we didn't store changelogs in the librarian. | 14:12 |
| wgrant | We should remove it from everywhere we can. | 14:12 |
| bigjools | but I think I still need to parse backwards through what's published | 14:12 |
| wgrant | ... starting with this code that will DoS everyone if I upload 100 packages with similar versions to a PPA :) | 14:12 |
| wgrant | bigjools: See the base version calculator. | 14:12 |
| henninge | abentley: that would either mean the 207 or making seperate xhr requests for each build. | 14:12 |
| wgrant | bigjools: It walks through them until it sees the common ancestor. | 14:12 |
| bigjools | I need to go and lie down | 14:12 |
| gary_poster | cr3, that's a question for the LOSAs, I don't have it. I can tell you that we generate ETags for launchpad API docs and WADL and JSON; it is tied to file size and mtime; we synchronize mtime for these files based on the last bzr revision so that it should be stable across machines that share the same revision | 14:12 |
| wgrant | bigjools: python-debian makes it fairly trivial. | 14:12 |
| henninge | abentley: We can file a bug to fix that. ;-) | 14:12 |
| bigjools | we store last common version | 14:12 |
| abentley | henninge: yeah, 207 seems the most reasonable. I didn't know about that RFC. | 14:12 |
| wgrant | bigjools: Actually, IIRC we create a set of the common versions, and take the max. You need to do the same, but then walk back through the entry iterator until you hit that version. | 14:12 |
| gary_poster | cr3, I'm not sure if the Apache file will tell you more than that; and I'm only familiar with the api.[qastaging.|staging.|edge.]launchpad.net rules | 14:13 |
| wgrant | It'll be pretty painless once you realise how awesome python-debian is. | 14:13 |
| bigjools | what iterator? | 14:13 |
| wgrant | bigjools: the changelog entry iterator from python-debian. | 14:14 |
| wgrant | s/iterator/generator/ | 14:14 |
| cr3 | gary_poster: thanks, that's definately something I can grep in launchpad but I'll still ask for the apache config in #launchpad-ops out of curiosity. I'm sure there's a trick or two I can learn | 14:14 |
| bigjools | hang on | 14:14 |
| gary_poster | cool cr3 | 14:14 |
| wgrant | cr3: Default Apache etags are generated from inode number, mtime and size. | 14:15 |
| gary_poster | yup | 14:15 |
| wgrant | cr3: inode number obviously isn't portable between machines. | 14:15 |
| wgrant | cr3: But if you reconfigure FileETag and make sure your mtimes are the same, the etags will match across machines. | 14:15 |
| wgrant | bigjools: Check DSD._updateBaseVersion | 14:18 |
| wgrant | And the getAncestry that it calls. | 14:18 |
| bigjools | I need to step back from this | 14:18 |
| bigjools | it's not straight to me exactly what needs to happen any more | 14:18 |
| matsubara | adeuring, bac: hi there, are you available for a review? https://code.launchpad.net/~matsubara/python-oops-datedir-repo/improve-db-statement-matches/+merge/73059 | 14:19 |
| bigjools | what I need is an example case | 14:19 |
| adeuring | matsubara: sure, I'look | 14:20 |
| wgrant | bigjools: Do you know how sync-source.py does this? | 14:20 |
| matsubara | thanks adeuring | 14:20 |
| wgrant | bigjools: It does it the same was as normal uploads: it calls dpkg-genchanges with -v$LATEST_VERSION_IN_UBUNTU. | 14:20 |
| wgrant | This causes dpkg-genchanges to include in the changes file all changelog entries strictly later than $LATEST_VERSION_IN_UBUNTU. | 14:21 |
| gary_poster | cr3, now a question for you. :-) could you either make ~launchpad the admin of https://launchpad.net/launchpad-results , add ~launchpad to ~launchpad-results ? Since it is part of the Launchpad project, we are responsible for triaging bugs | 14:21 |
| wgrant | Or remove launchpad-results from launchpad-project, possibly. | 14:21 |
| gary_poster | s/ add / or add/ | 14:22 |
| gary_poster | yeah that too | 14:22 |
| cr3 | gary_poster: I think the problem with that is that I'm not a member of ~launchpad which might prevent me from working on the project, but please correct me if I might be wrong :) | 14:22 |
| wgrant | Since it's not code managed by our team, it probably shouldn't be in launchpad-project. | 14:22 |
| gary_poster | cr3, yeah that leaves you two options | 14:23 |
| cr3 | wgrant: I was following the process here though: https://dev.launchpad.net/CreatingNewProjects | 14:23 |
| bigjools | wgrant: you're not talking about my aggregate changelog stuff any more are you? you're talking about gina? | 14:24 |
| wgrant | cr3: That's for split-out parts of Launchpad. | 14:24 |
| gary_poster | cr3, I agree with wgrant that maybe it should not be in launchpad-project. Alternatively, if you add ~launchpad to ~launchpad-results, at least everyone responsible would be able to to what they need. | 14:24 |
| wgrant | bigjools: They are intertwined, but I'm not talking about gina at all now. | 14:24 |
| bigjools | why are you talking about parsing changelogs then? | 14:25 |
| wgrant | bigjools: Because traditional syncs do that. | 14:25 |
| gary_poster | cr3, but unless there's a good reason to have it be part of launchpad-project, again, I agree with wgrant | 14:25 |
| wgrant | bigjools: That's the baheviour we're trying to emulate. | 14:25 |
| cr3 | gary_poster, wgrant: I have a call scheduled with lifeless later today, I'll add that to the agenda depending on where we want to go with the project | 14:25 |
| gary_poster | cool cr3 | 14:25 |
| bigjools | wgrant: which requires fixing in gina AIUI | 14:25 |
| wgrant | bigjools: Not if we make native syncs parse the changelogs too. | 14:26 |
| cr3 | I'm easy either way, I did feel strange seeing the launchpad folks getting bug reports about the project so I feel your pain :) | 14:26 |
| bigjools | euargh | 14:26 |
| gary_poster | for now then, cr3, perhaps you could simply triage https://bugs.launchpad.net/launchpad-results/+bug/833854 ? :-) | 14:26 |
| _mup_ | Bug #833854: Unable to submit results with results2launchpad on natty <Launchpad Results:Confirmed> < https://launchpad.net/bugs/833854 > | 14:26 |
| wgrant | bigjools: Classic/legacy/traditional/ohgodgoaway syncs don't use changelog_entry. They create a normal upload, which parses the changelog to work out which entries to include in the changes file. | 14:26 |
| bigjools | wgrant: you said that gina doesn't import all of the changelog | 14:26 |
| wgrant | bigjools: Right. | 14:26 |
| bigjools | so we can't parse it | 14:26 |
| cr3 | gary_poster: fair enough, done :) | 14:26 |
| wgrant | bigjools: But that's not too relevant if we ignore gina. | 14:26 |
| gary_poster | thanks cr3 :-) | 14:27 |
| wgrant | bigjools: No, it doesn't import all of the changes into *changelog_entry*. | 14:27 |
| wgrant | bigjools: debian/changelog is imported into the librarian verbatim. | 14:27 |
| wgrant | bigjools: There is no possible error there. | 14:27 |
| bigjools | wgrant: ok *that* is what was confusing me | 14:27 |
| wgrant | bigjools: changelog_entry is generated based on a dodgy heuristic. | 14:27 |
| bigjools | let's ignore changelog_entry then | 14:27 |
| wgrant | Yes :) | 14:27 |
| bigjools | assume changelog is complete | 14:27 |
| wgrant | If it's not, then it's still not a regression from the old method. | 14:28 |
| wgrant | Because normal uploads and legacy syncs just parse the changelog. | 14:28 |
| bigjools | I'm not convinced that changelog parsing is needed | 14:29 |
| bigjools | if gina makes a composite one for a particular import then we never saw the oldver versions anyway | 14:30 |
| wgrant | bigjools: If you fix gina to make a composite one, then maybe. | 14:33 |
| wgrant | bigjools: But using the real changelog is definitely safer, and probably easier. | 14:33 |
| bigjools | wgrant: hang on | 14:33 |
| bigjools | right, I think I am finally tuned in. I need more sleep. | 14:35 |
| wgrant | Perhaps I should change the docstring of changelog_entry to "Red herring." | 14:36 |
| wgrant | bigjools: Anyway, you should probably revert that revision. | 14:37 |
| wgrant | Or things could get *very* confusing and noisy. | 14:37 |
| bigjools | hmmm | 14:37 |
| wgrant | I mean, the current implementation is clearly practically flawed. | 14:38 |
| wgrant | Because it will pick up PPA uploads etc. | 14:39 |
| bigjools | it will yes | 14:39 |
| bigjools | a bad oversight | 14:39 |
| wgrant | Hmm. I wonder what happens if I delete a package and copy it back in. I guess it includes every SPR ever seen by Launchpad. | 14:39 |
| wgrant | That could be amusing. | 14:39 |
| wgrant | With the right SPN, that is. | 14:40 |
| wgrant | I suppose I should sleep at some point. | 14:44 |
| wgrant | bigjools: You're not around Monday, I suppose? | 14:44 |
| bigjools | wgrant: I am actually | 14:44 |
| wgrant | Oh. | 14:44 |
| wgrant | I thought it was a holiday. | 14:44 |
| bigjools | it is but I swapped it | 14:45 |
| wgrant | Ahh. | 14:45 |
| adeuring | matsubara: r=me | 14:47 |
| matsubara | thanks adeuring | 14:47 |
| wgrant | Night all. | 14:47 |
| bigjools | night | 14:48 |
| matsubara | adeuring, I have another one from oops-tools which is related to that MP: https://code.launchpad.net/~matsubara/oops-tools/829460-typeerror-qsmmx/+merge/73062 could you take a look as well, please? | 14:48 |
| adeuring | matsubara: sure | 14:48 |
| cr3 | gary_poster: you mentionned generating etags for api, wadl and json. however, I'm seeing an oddly short etag for .css files, for example, and I'm not seeing anything about FileETag in the apache configuration nor anything special in the launchpad code, any ideas where I should look? | 15:15 |
| === beuno is now known as beuno-lunch | ||
| adeuring | matsubara: kiko has a good point about your mp | 15:21 |
| === al-maisan is now known as almaisan-away | ||
| matsubara | adeuring, yep, I'll reply to kiko's comment. Apart from that, are there other things to change in the mp? | 15:50 |
| adeuring | matsubara: no, otherwise, the MP looks good | 15:51 |
| matsubara | adeuring, cool. I'll grab some lunch and sort this out afterwards. thanks for the review! | 15:51 |
| === matsubara is now known as matsubara-lunch | ||
| adeuring | matsubara-lunch: enjoy lunch! | 15:51 |
| adeuring | matsubara-lunch: note that I'll have EOD in about an hour, and I'll leave home then | 15:52 |
| LPCIBot | Project devel build #1,001: STILL FAILING in 4 hr 4 min: https://lpci.wedontsleep.org/job/devel/1001/ | 15:56 |
| === beuno-lunch is now known as beuno | ||
| gary_poster | cr3, I don't know. I haven't touched ETags for CSS, at least intentionally | 16:08 |
| cr3 | gary_poster: I think I found what's going on: seems to be a server context FileETag config I'm not seeing in the launchpad virtualhost. I'm double checking with chex just to make sure | 16:10 |
| cr3 | that's all I could assume being from the outside looking in :) | 16:10 |
| gary_poster | hm, ok cool cr3 | 16:10 |
| cr3 | can someone help me rationalize what goes under lp.services? for example, I would tend to think there shouldn't be anything that depends on a database layer there, but that probably means I don't get the purpose of that namespace | 16:16 |
| === deryck is now known as deryck[lunch] | ||
| gary_poster | abentley, you looked at https://answers.launchpad.net/launchpad/+question/167859 last week. We have two almost identical SourceForge subversion branches, one of them importing and one of them not. I tried the failing one locally and it worked fine. I was thinking of asking LOSAs to clear out past attempts to see if that would help somehow. Does that sound reasonable, and/or do you have a better idea? | 16:48 |
| gary_poster | cr3, I think of it as "general-purpose sorts of things go here, like things that might go into a library, or things that are LP-specific but used as tools throught the code base." That said, I'll deny everything if you claim I told you anything about this. ;-) | 16:50 |
| gary_poster | abentley, I spoke too soon. The local checkout eventually failed after almost completing with "bzr: ERROR: A Subversion remote access command failed: REPORT of '/svnroot/ifolder/!svn/vcc/default': SSL handshake failed: Secure connection truncated (https://ifolder.svn.sourceforge.net)" | 17:13 |
| gary_poster | Perhaps I should assign this to Jelmer? | 17:13 |
| abentley | gary_poster: makes sense. | 17:13 |
| gary_poster | ok thanks | 17:13 |
| === matsubara-lunch is now known as matsubara | ||
| abentley | sinzui: I think I found a bug in addMember: http://pastebin.ubuntu.com/675383/ | 17:19 |
| sinzui | yes you have | 17:20 |
| sinzui | oh, hold on | 17:20 |
| sinzui | approved is a member, invited is not. how can that happen. I think approved would have to go to deactivated first | 17:20 |
| abentley | sinzui: or you could consider it a bug in the browser code. | 17:20 |
| sinzui | abentley, is this a case where I add a team twice? Once I invite, the other party accept and the state goes to approve, but invite the team again. This should be a no op. there is nothing to do and no status should change | 17:22 |
| abentley | sinzui: yes, this is adding a team twice. | 17:23 |
| abentley | sinzui: how much of a no-op should it be? would we still reset the expiration date, etc? | 17:32 |
| sinzui | I would not think so | 17:33 |
| sinzui | I understand your point, but I do not think that is a way team admins force renewals. Lp sends them out and the other team accepts them. If the admin wanted to extend the expiration date, he can do that from +members | 17:35 |
| abentley | sinzui: Is there a legitimate way for a team to become PROPOSED? I can do it using force_team_add. If so, should the transition from PROPOSED to INVITED legitimate? | 17:43 |
| sinzui | A team is proposed when the admin of the team is the user doing the add. | 17:44 |
| sinzui | abentley, proposed -> invited should not happen. That action is an implicit acceptance by admins of both teams of the user, so I expect the membership to be approved | 17:46 |
| abentley | sinzui: ISTM that if the admin of the target team then attempts to add the team, the status should go to APPROVED? | 17:46 |
| sinzui | we agree | 17:46 |
| gary_poster | Anyone else getting lots of errors in ec2 tests with complaints like this? | 17:51 |
| gary_poster | [<bzrlib.lockable_files._LockWarner object at 0x142dc510>] | 17:51 |
| bdmurray | what's the url that contains info regarding staging's database updates? | 18:00 |
| === deryck[lunch] is now known as deryck | ||
| gary_poster | bdmurray, getting it for you, and it hasn't bee since the 15th IIRC. | 18:05 |
| bdmurray | gary_poster: okay, I thought I'd put the url in https://help.launchpad.net/StagingServer | 18:06 |
| gary_poster | explanation, btw, from stub: "the account running the update has lost its | 18:06 |
| gary_poster | sudo access, probably puppet fallout. I've opened RT #47499" | 18:06 |
| _mup_ | Bug #47499: Sources.list are set to Australia <Ubuntu Express:New> < https://launchpad.net/bugs/47499 > | 18:06 |
| gary_poster | bdmurray, is this what you had in mind? https://staging.launchpad.net/successful-updates.txt | 18:07 |
| bdmurray | gary_poster: yes firefox wasn't helping me remember it | 18:07 |
| gary_poster | cool | 18:07 |
| abentley | sinzui: with my changes, I think I can prove that TeamMemberAddView.add_action never triggers a TeamMembershipTransitionError. Should the same be true for Person.addMember itself? | 18:10 |
| sinzui | abentley, that would be nice, but I think that is impossible given that users call that via poorly written scripts. | 18:12 |
| abentley | sinzui: ISTM that currently addMember can be used to demote someone from ADMIN to APPROVED or PROPOSED. Does that make sense? | 19:03 |
| sinzui | NO | 19:04 |
| sinzui | oh | 19:04 |
| sinzui | I think there is a related bug. maybe you found the root cause | 19:05 |
| * sinzui looks | 19:05 | |
| gary_poster | abentley, I wonder if you could help me for a moment. If you don't think you can do so easily, no problem; writing this has helped me gather good diagnostic information. I was going to put it on IRC, but it was too much, so here's what I have: http://pastebin.ubuntu.com/675475/ | 19:07 |
| gary_poster | mm, lemme try making that wrap... | 19:08 |
| gary_poster | abentley, try again: http://pastebin.ubuntu.com/675476/ | 19:08 |
| abentley | gary_poster: So when we say "garbage", we mean "stuff that the garbage collector should have collected". | 19:10 |
| abentley | gary_poster: I have poked at this before, and my impression was that the garbage collector is not perfect. | 19:11 |
| gary_poster | abentley, yes, I believe so. If I had to guess, I would say that the message I see locally is not being rendered for some reason | 19:11 |
| gary_poster | abentley, heh | 19:11 |
| sinzui | abentley, bug 480157 which clearly states what you found | 19:13 |
| gary_poster | abentley, can I somehow force the file that the message references to unlock? | 19:13 |
| _mup_ | Bug #480157: IPerson.addMember() should not demote admins <lp-registry> <teams> <Launchpad itself:Triaged> < https://launchpad.net/bugs/480157 > | 19:13 |
| abentley | gary_poster: So I can take a look at that test and see if the lock lifetimes are broken. | 19:13 |
| gary_poster | ok thanks abentley. Please let me know if I can help. Given that these are keeping my ec2 land from passing but they are occurring oin buildbot and not causing a stop-the-line, I guess I'll submit directly for now; I'll also shoot a quick note about the situation to the list. | 19:14 |
| abentley | gary_poster: the test looks correct. I think the puller really is failing to unlock the branch. | 19:17 |
| gary_poster | abentley, so it smells like a bzr error? | 19:17 |
| abentley | gary_poster: no. | 19:17 |
| gary_poster | oh? | 19:17 |
| abentley | gary_poster: it smells like a puller error. | 19:17 |
| * gary_poster thought puller was bzr, and is corrected | 19:18 | |
| abentley | gary_poster: puller uses bzrlib. | 19:19 |
| abentley | gary_poster: but it is part of codehosting. | 19:19 |
| lifeless | cr3: hi | 19:20 |
| gary_poster | ok, gotcha. abentley, do you want me to pull on that as a matter of my own edification, or should I leave you to it? | 19:20 |
| abentley | gary_poster: Have a look at it. There are supposed to be symmetrical Branch.lock(read|write)/Branch.unlock calls. It seems like they're not organized correctly. | 19:21 |
| gary_poster | cool abentley. I'll take a glance. May I treat you as a mentor for this one? | 19:22 |
| cr3 | lifeless: hola senor | 19:22 |
| abentley | gary_poster: sure. | 19:22 |
| gary_poster | cool thanks | 19:22 |
| lifeless | cr3: do you have skype ? | 19:22 |
| cr3 | lifeless: I might, let me have a looksee | 19:22 |
| lifeless | or I can do voip | 19:22 |
| abentley | gary_poster: The traditional pattern is that branch.lock_(read|write) is followed by a try/finally block that does branch.unlock. | 19:22 |
| gary_poster | makes sense | 19:23 |
| lifeless | I think we have a decorator too - a with write_locked(branch): | 19:23 |
| cr3 | lifeless: yep, marcatinterunion | 19:23 |
| lifeless | IMBW | 19:23 |
| abentley | lifeless: indeed. | 19:23 |
| abentley | gary_poster: anyhow, you should be able to tell from the URL which branch isn't being unlocked appropriately. | 19:23 |
| abentley | gary_poster: Oh, it might be relevant that locks are tracked on a per-instance basis. So another instance of "default-stack-on" is probably being opened and locked elsewhere. | 19:27 |
| abentley | gary_poster: that would be why stack_on.unlock said "LockNotHeld" | 19:28 |
| gary_poster | abentley, hm, ok. per instance of what? is the puller in another process, or at least in another bzrlib instance? | 19:29 |
| abentley | gary_poster: per instance of the branch class. | 19:30 |
| abentley | gary_poster: class instance, not bzrlib instance or process. | 19:30 |
| gary_poster | ah ok abentley. | 19:31 |
| gary_poster | abentley, they shared directory names though. That's to be exoected? | 19:31 |
| gary_poster | expected | 19:31 |
| gary_poster | That is, the lock file when it said "LockNotHeld" was the same | 19:31 |
| gary_poster | path as the lock file that gc complained about | 19:32 |
| abentley | gary_poster: that's to be expected. | 19:32 |
| gary_poster | oh ok | 19:32 |
| gary_poster | (that seems mystifying on the surface of it, but I don't think digging into it will be necessary.) | 19:33 |
| abentley | gary_poster: if you open a branch twice, you get two instances of the branch class, referring to the same files. | 19:33 |
| gary_poster | abentley, ah so the instance does not hold the lock that exists? | 19:33 |
| gary_poster | (for another instance, and the whole multiple instance thing is presumably the whole point) | 19:34 |
| abentley | gary_poster: I don't understand the question. | 19:34 |
| gary_poster | yeah I think I just realized how obvious the answer to my confusion was | 19:34 |
| gary_poster | you can have multiple class instances, each pointing to the same file. In order to manage threads and processes and so on, bzr gives locks to its files. When I tried to unlock the instance, the error message was not "there is no lock" but "the lock over there isn't mine" | 19:36 |
| gary_poster | that was the obvious bit, yeah, abentley? | 19:36 |
| abentley | gary_poster: bzrlib isn't really built with threading in mind. The read-locking enables caching. The write-locking pysically prevents other bzrlib clients from making changes. | 19:39 |
| gary_poster | abentley, ack | 19:39 |
| abentley | gary_poster: The error message was "I'm not locked", without saying anything what other objects may or may not be locked. | 19:40 |
| gary_poster | ack | 19:40 |
| gary_poster | abentley, well...let me make sure I am on the right track here. if I have branch file F, and bzrlib branch instance A of F, and bzrlib branch instance B of F, and A has a lock, if I tried to unlock B, it would say "I'm not locked." That's what you mean here, yes? | 19:42 |
| abentley | gary_poster: right. | 19:42 |
| gary_poster | cool | 19:42 |
| gary_poster | abentley, the bug is within bzrlib, or we aren't using it correctly somehow. We never get the repo pack to unlock it ourselves, and bzrlib doesn't do it because the code path apparently expects "fallback.unlock()" (whatever that is) will do it, but that is not around for us. Here are the details: http://pastebin.ubuntu.com/675505/ | 20:03 |
| gary_poster | s/repo pack/repo back/ | 20:04 |
| lifeless | cr3: bug 799271 | 20:04 |
| _mup_ | Bug #799271: cache entries get corrupted and lead to hard to diagnose failures <launchpadlib :Triaged> < https://launchpad.net/bugs/799271 > | 20:04 |
| abentley | gary_poster: Okay, it looks like a bzrlib bug. | 20:06 |
| LPCIBot | Yippie, build fixed! | 20:06 |
| LPCIBot | Project devel build #1,002: FIXED in 4 hr 10 min: https://lpci.wedontsleep.org/job/devel/1002/ | 20:06 |
| abentley | gary_poster: I think the lock_read must not happen until we are sure that we'll add it as a fallback repository. | 20:07 |
| gary_poster | abentley, ok, that makes sense. Let me see if that works... | 20:08 |
| abentley | gary_poster: or else we need to manually unlock if we we're exiting without adding it. | 20:08 |
| gary_poster | right | 20:08 |
| lifeless | cr3: https://dev.launchpad.net/ArchitectureGuide/ServicesAnalysis | 20:10 |
| gary_poster | abentley, I don't know how much of an indication of correctness this is, but ./bin/test -vvc lp.codehosting.puller.tests.test_worker passes (and without the locked file complaint) with the reordering you suggested. I'm inclined to branch bzr and make the change, but I'll probably need some serious help with a test. But you agree that I should make a bug, work up a full branch for an MP, and make an egg for LP, yes? | 20:14 |
| gary_poster | and I'll try for the test with help first :-) | 20:15 |
| gary_poster | though maybe hints on what tests to run would be good--I saw that the bzr test suite is 3.5 hours now | 20:15 |
| gary_poster | mm, I saw your faultline plugin; that might help | 20:15 |
| abentley | gary_poster: True. | 20:15 |
| abentley | gary_poster: Yes. For bzr itself, faulline adds an "--auto" flag that will automatically determine the tests to run. | 20:17 |
| abentley | gary_poster: IOW, "bzr selftest --auto" is your friend. | 20:17 |
| gary_poster | ok cool, abentley. So...in order to get faultline to trigger I just need to add a comment to where I intend to make the change? | 20:18 |
| gary_poster | then I can look at those tests, try to figure out what to write new, and go from there | 20:18 |
| abentley | gary_poster: You can do it that way, or you can just specify the file. | 20:19 |
| gary_poster | oh ok | 20:19 |
| === bac changed the topic of #launchpad-dev to: #launchpad-dev ist: https://dev.launchpad.net/ | On call reviewer: - | Critical bugs: 237 - 0:[#######=]:256 | ||
| sinzui | jcsackett, do you have a few minutes to mumble? | 20:56 |
| === matsubara is now known as matsubara-afk | ||
| gary_poster | abentley, had trouble with faultline fwiw. the --auto hack uses FaultFinder.from_tree, while the trunk has FaultFinde.from_trees. Simply fixing the name is insufficient. | 21:31 |
| gary_poster | File "/home/gary/.bazaar/plugins/faultline/faultline.py", line 250, in run | 21:31 |
| gary_poster | finder = FaultFinder.from_trees(target.basis(), target, | 21:32 |
| gary_poster | AttributeError: 'WorkingTree6' object has no attribute 'basis' | 21:32 |
| gary_poster | bzr fault-line works fine | 21:32 |
| abentley | gary_poster: sorry 'bout that. | 22:25 |
| gary_poster | abentley, no apology needed, just telling you. you want me to file a bug? | 22:27 |
| jeblair | i have an launchpad openid sso problem: | 22:38 |
| jeblair | when lp:~gandelman-a logs into my site, he shows up with the local_id https://login.launchpad.net/+id/QAxGXJy | 22:39 |
| jeblair | but his account page, https://launchpad.net/~gandelman-a | 22:39 |
| jeblair | says his local_id should be https://login.launchpad.net/+id/KeeKF87 | 22:39 |
| jeblair | and i can't work backwards from QAxGXJy to find out what account it's for. | 22:39 |
| jeblair | why would it show up as something different, and how can i verify his identity? | 22:40 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!