| * mwhudson lunches | 00:08 | |
| thumper | how to I get emails into the stub mailer without transaction.commit() ? | 01:27 |
|---|---|---|
| thumper | mwhudson: how do we force a remirror? | 01:37 |
| thumper | mwhudson: lp:~kees/+junk/cpu-checker is fine in the hosted area, but screwed in mirrored | 01:37 |
| mwhudson | thumper: launchpadlib? | 01:50 |
| mwhudson | or lock and unlock | 01:50 |
| mwhudson | (i have a dead simple plugin for the latter) | 01:50 |
| thumper | mwhudson: we do pull --overwrite effectively don't we | 01:50 |
| mwhudson | thumper: yep | 01:51 |
| mwhudson | and blow it away if we can't open the branch | 01:51 |
| thumper | mwhudson: the blowing it away bit seems to not work | 02:02 |
| thumper | https://code.edge.launchpad.net/~kees/+junk/cpu-checker | 02:02 |
| mwhudson | thumper: argl | 02:03 |
| mwhudson | thumper: i see; you can open the branch in the mirrored side | 02:03 |
| mwhudson | thumper: but not, say, run log on it | 02:04 |
| thumper | mwhudson: yeah | 02:04 |
| thumper | mwhudson: or get the ancestry | 02:04 |
| thumper | mwhudson: any idea how that happened? | 02:04 |
| thumper | I don't | 02:04 |
| thumper | losa: ping | 02:04 |
| mwhudson | thumper: nope | 02:05 |
| wgrant | https://code.edge.launchpad.net/~launchpad-pqm/launchpad/devel | 02:08 |
| wgrant | That says "Updating branch" | 02:08 |
| wgrant | But I know that the revision was visible on LP 7 minutes ago. | 02:08 |
| wgrant | (visible meaning "in the mirrored copy", I guess) | 02:09 |
| thumper | wgrant: yes | 02:15 |
| thumper | ... | 02:15 |
| thumper | arse | 02:15 |
| thumper | ENOLOSA | 02:15 |
| wgrant | thumper: That seems an excessive amount of time to scan one new rev. That can't be normal, surely? | 02:16 |
| thumper | wgrant: no it isn't normal | 02:16 |
| thumper | wgrant: there is something wrong | 02:16 |
| wgrant | Ah, good. | 02:16 |
| thumper | wgrant: but the system is opaque | 02:16 |
| thumper | jml: see, a job viewer would be really useful here | 02:17 |
| mwhudson | launchpad/devel is up to date now | 02:20 |
| wgrant | mwhudson: Yeah, it took a bit over 10 minutes to scan. | 02:20 |
| thumper | wgrant: scanning is still a serial process for all branches in Launchpad | 02:25 |
| wgrant | thumper: Ah, yes. Ew. | 02:25 |
| thumper | wgrant: FWIW, if the email gets sent, the scanner has finished | 02:31 |
| thumper | wgrant: it could have been replication lag you were seeing | 02:31 |
| wgrant | thumper: The email wasn't sent until at least 10 minutes after it was pulled, so it wasn't repl lag. | 02:33 |
| thumper | wgrant: well, there is a delay after the pull before the scan, and a delay after the scan to send the email | 02:36 |
| thumper | wgrant: shouldn't be 10 minutes though | 02:36 |
| === matsubara is now known as matsubara-afk | ||
| * wgrant fixes community-contributions.py to work with db-devel. | 03:10 | |
| jml | thumper, I never argued that it was inherently useless. | 03:27 |
| lifeless | jml: morning? | 03:34 |
| * mwhudson winds up a not particularly productive day | 03:54 | |
| wgrant | mwhudson: Looks like that ec2 land evaporated. | 06:17 |
| wgrant | Which is odd, since I've had 4 EC2 emails come through successfully in the past 24 hours. So maybe your mail config hates me. | 06:18 |
| wgrant | kfogel: https://dev.launchpad.net/Contributions/Draft, produced by lp:~wgrant/launchpad/community-contributions-fixes, now with db-devel support and unbroken post-r9999 sorting. | 06:31 |
| === dpm-afk is now known as dpm | ||
| adeuring | good morning | 07:59 |
| wgrant | henninge: Morning. | 08:14 |
| henninge | Hi wgrant! ;) | 08:15 |
| wgrant | henninge: So, intellectronica landed that first branch that you reviewed this morning after the testfix. Can you please try to land the second one that noodles UI-reviewed? | 08:16 |
| wgrant | https://code.edge.launchpad.net/~wgrant/launchpad/fix-build-breadcrumbs/+merge/20888, that is. | 08:16 |
| noodles775 | wgrant: oh, I saw that mwhudson had updated the commit message and assumed he was landing it? | 08:16 |
| wgrant | noodles775: He tried, but APAC eC2 hates me and just avaporates. | 08:17 |
| wgrant | European landings tend to work fine. | 08:17 |
| noodles775 | Ah. | 08:17 |
| henninge | wgrant: np, I will do it. | 08:17 |
| wgrant | But when the NZers try it, the instances almost always disappear :( | 08:17 |
| wgrant | henninge: Thanks. | 08:18 |
| mwhudson | wgrant: yep, instance gone :/ | 08:19 |
| wgrant | mwhudson: Yay. | 08:19 |
| wgrant | noodles775: Thanks. | 09:04 |
| noodles775 | wgrant: np. | 09:04 |
| mrevell | Guten morgen | 09:11 |
| noodles775 | Morgan mrevell. | 09:11 |
| mrevell | :) | 09:12 |
| === noodles785 is now known as noodles775 | ||
| deryck | Morning, all. | 11:00 |
| allenap | adeuring: I'm having a look at your IPerson/IHasBugs issue. | 11:11 |
| adeuring | allenap: thanks! | 11:11 |
| deryck | gmb, intellectronica -- heat looks like it's finally updating as it should now. | 11:22 |
| intellectronica | deryck: yes. loganberry was, as you suspected, behind. a re-roll fixed the problem. | 11:23 |
| deryck | gmb, intellectronica -- can you two create a combined file of sql to update heat and max_bug_heat and get that run, to get us updated across the board, now that the jobs system will keep it up to date. | 11:23 |
| intellectronica | i'm not sure we can do that with just sql, can we? | 11:24 |
| === daniloff is now known as danilos | ||
| gmb | intellectronica: We can update bug heat with SQL. max_bug_heat I don't know about. | 11:24 |
| intellectronica | gmb: what do you think? can we do that with sql, or maybe a script that creates heat calculation jobs? | 11:24 |
| intellectronica | gmb: we can calculate it in sql | 11:25 |
| deryck | intellectronica, I think so. that same queries in the model code for max_bug_heat can be fed into an update. | 11:25 |
| gmb | intellectronica: In that case we should be fine. I'll dig out my bug heat queries. | 11:25 |
| gmb | SQL for updating bug heat is here: http://pastebin.ubuntu.com/391693/ | 11:26 |
| intellectronica | gmb: the main problem i see with doing this with just sql is that it will result in queries that take too long to run | 11:26 |
| gmb | intellectronica: Yeah, that's a risk. | 11:26 |
| gmb | OTOH, if we create a CalculateBugHeatJob for each of 500,000+ bugs those jobs will take a long time, too. | 11:27 |
| intellectronica | gmb: i wonder, since you've started working on a script to create jobs, if it wouldn't be easier to use that | 11:27 |
| deryck | intellectronica, like gmb says jobs for every bug is too long, too. | 11:27 |
| intellectronica | deryck: right, but it doesn't happen in a single transaction | 11:28 |
| gmb | intellectronica: Well, it's not a very finessed script: http://pastebin.ubuntu.com/391695/ | 11:28 |
| deryck | intellectronica, hmmm, good point. | 11:28 |
| intellectronica | :) | 11:28 |
| intellectronica | simple i like | 11:28 |
| deryck | hmmmm, I'm not liking the mass create bug jobs idea either. | 11:30 |
| intellectronica | deryck: what are we actually trying to solve? | 11:30 |
| gmb | deryck: We could use a looptuner. But that's liable to take a day or so to complete because it's quite conservative. | 11:30 |
| intellectronica | do we want to calculate heat for all bugs, or just get max_heat calculated? | 11:30 |
| deryck | intellectronica, I want both, heat for all bugs and max_bug_heat. sort of a reset, since the update heat system hasn't been working completely until now. | 11:39 |
| intellectronica | deryck, gmb: right. i'd say creating jobs (and letting them process over the day or so it might take) is probably the best approach, since it's safe and exercises the code we've already written (rather than emulate it with unrelated sql). | 11:41 |
| gmb | intellectronica: In that case we should try the creation script on staging first to make sure that it doesn't hold the transaction open too long or anythign similarly annoying. | 11:43 |
| deryck | intellectronica, gmb -- yeah, this is my only concern is that create 500,000+ jobs in one fell swoop has issues we don't yet know about. | 11:44 |
| deryck | if we test on staging first, I'm fine to do it that way. | 11:45 |
| gmb | deryck: Actually, an issue that occurs to me is that the processing script might try to do them all at once (it's generic code, so I've never subjected it to any kind of massive load test). | 11:45 |
| intellectronica | let's try that, and if that doesn't work, batch it by target, or just in batches of bugs | 11:45 |
| gmb | Once we've created the jobs on staging we should run cronscripts/calculate-bug-heat.py and see what happens. | 11:46 |
| intellectronica | gmb: hmmm ... so maybe it's better to start with batching. create a batch of jobs, process them, repeat... | 11:46 |
| gmb | intellectronica: Possibly. I think that the script will cope with that. The proof of the pudding is in the staging, however. :) | 11:47 |
| intellectronica | heh | 11:47 |
| === matsubara-afk is now known as matsubara | ||
| allenap | adeuring: I can't figure out why it's not working, but I have a word-around: http://paste.ubuntu.com/391719/ | 12:19 |
| allenap | adeuring: I also noticed that the LaunchpadObjectFactory was doing some naughty things - unwrapping security proxies and never re-adding them - so I fixed that. You probably shouldn't apply that part of the patch; I'll file a bug about it. | 12:21 |
| adeuring | allenap: thanks! | 13:22 |
| allenap | adeuring: You're welcome :) Still a mystery though... | 13:22 |
| adeuring | yeah... | 13:23 |
| allenap | adeuring: salgado's solution is more elegant (bool). But that doesn't explain why person.all_bugtasks.limit is forbidden and product.all_bugtasks.limit isn't. | 13:26 |
| adeuring | allenap: right, that's what I was asking me too ;) | 13:27 |
| allenap | adeuring: Fwiw, I filed bug 535021 about the naked object problems in LPO. | 13:29 |
| mup | Bug #535021: Some LaunchpadObjectFactory methods remove security proxies then inadvertently return naked objects <Launchpad itself:New> <https://launchpad.net/bugs/535021> | 13:29 |
| adeuring | allenap: great, thanks | 13:30 |
| adeuring | allenap: I'm wondering if that would also explain that the tests for product.has_bugtasks did not fail | 13:30 |
| adeuring | argh... that's about _person_ objects.... | 13:31 |
| allenap | adeuring: Yeah, seems likely. | 13:31 |
| allenap | adeuring: If it is the case, could you comment on that bug to say that it has caused confusion already? | 13:32 |
| adeuring | sure | 13:32 |
| salgado | adeuring, allenap, if it works for Product it's because for that class the return value of all_bugtasks is not security proxied | 13:33 |
| adeuring | salgado: maybe ... but why? | 13:33 |
| salgado | I see that Person.searchTasks() returns getUtility(IBugTaskSet).search(search_params, *args), so it is security proxied | 13:33 |
| salgado | now looking for Product.searchTasks() | 13:33 |
| salgado | HasBugsBase returns BugTaskSet().search(search_params) | 13:34 |
| salgado | which is not security proxied | 13:34 |
| salgado | that's why | 13:34 |
| adeuring | ahhh, thanks! | 13:34 |
| allenap | salgado: Of course! Somehow I missed that Person implements its own searchTasks(). | 13:35 |
| adeuring | so that's what should be fxided | 13:35 |
| allenap | adeuring: Even so, probably still use the bool(result_set) or is_empty() fix too. It's supposedly more efficient than count(), though I don't know by how much. | 13:37 |
| adeuring | allenap: right | 13:37 |
| === barry` is now known as barry | ||
| thekorn | mrevell, allenap, hi, I started writing a blog post about my experiences as a launchpad contributor, but I'm not done with it yet, I think I need another 2 days | 14:06 |
| mrevell | thekorn, Hey, thanks for working on that. Whenever you're ready is great. | 14:06 |
| allenap | thekorn: That's brilliant :) | 14:06 |
| === beuno is now known as beuno-afk | ||
| kfogel | wgrant: OMG, that rocks. I will review today. Want to make a merge proposal? | 14:13 |
| intellectronica | jtv: i don't think this is a result of any of my branches, and i'm even tempted to just try and force a rebuild | 14:48 |
| jelmer | allenap: You just filed a bug against launchpad itself rather than a particular component, was that intentional? | 14:48 |
| intellectronica | but will look more closely | 14:48 |
| jtv | intellectronica: noodles775 seems to concur... too late at night for me to look at the details but I agree. | 14:49 |
| intellectronica | noodles775: so, force a rebuild? | 14:50 |
| noodles775 | intellectronica: yeah, I'm just running `bin/test -vvt testLibrarianWorking` at the moment on tip of devel, it's working so far without error. | 14:50 |
| noodles775 | yep, it just finished without error. So +1 for force a rebuild :) | 14:51 |
| jtv | intellectronica: you want to press the button? | 14:52 |
| intellectronica | jtv: pressed | 14:52 |
| jtv | thanks! | 14:52 |
| allenap | jelmer: Yes, kind of. A foundations responsibility perhaps, but one which anyone could fix. | 14:58 |
| jml | allenap, that is that sad tune to which the song of foundations is sung. | 14:59 |
| allenap | jml: :) Is there an easily identifiable subset of foundations bugs that could be tackled by us mortals? Would that simply be bugs tagged trivial? | 15:00 |
| jml | allenap, good question! /me punts to gary_poster | 15:01 |
| jelmer | allenap: ah, thanks | 15:02 |
| gary_poster | jml, allenap, not really. I suppose I could start doing that, though, if I knew what the distinction might be. FWIW, bugs tagged as UI that don't involve CSS bugs are good candidates, but I think you are asking for the opposite way round (how do I tag, rather than how do I find) | 15:04 |
| allenap | gary_poster: I don't really know what I'm thinking of, but it was brought about by bug 535021. It's something I'd be happy to fix, but it doesn't belong on the malone project where deryck or I might see it in the normal course of things, and schedule it. TBH, we're all busy enough that finding new sources of work is probably not going to fly far. Most of the time, work is feature driven rather than looking for bugs to fix. | 15:10 |
| mup | Bug #535021: Some LaunchpadObjectFactory methods remove security proxies then inadvertently return naked objects <Launchpad Foundations:New> <https://launchpad.net/bugs/535021> | 15:11 |
| gary_poster | allenap: yeah. Non-foundations people take "foundations" bugs all the time. Registry does this in particular. I think it is fabulous. | 15:14 |
| allenap | gary_poster: Cool. I'll try and join that merry band :) Want any malone bugs? ;) | 15:15 |
| gary_poster | allenap: heh, uh, no. :-) | 15:16 |
| mramirez | might indicate where the configuration is positioned to Logear launchpad with ldap | 15:22 |
| mramirez | might indicate where the configuration is positioned to Logear launchpad with ldap | 15:25 |
| mramirez | * [Chan | 15:25 |
| === salgado is now known as salgado-lunch | ||
| didrocks | jml: I'm not as popular than you, my branch got rejected because of no description :) | 15:46 |
| didrocks | jml: I'm adding some now | 15:47 |
| adiroiban | danilos: do you know when the +translate UI rework will be done? | 15:54 |
| danilos | adiroiban, no, though I'd like to raise priority because I consider it tech-debt and very important for anything we want to do | 15:54 |
| adiroiban | in the Romanian team, we are trying to use Launchpad for our review process | 15:55 |
| adiroiban | and bug 339507 is a real blocker | 15:56 |
| mup | Bug #339507: translation page should show old translations <ui> <Launchpad Translations:Triaged> <https://launchpad.net/bugs/339507> | 15:56 |
| danilos | adiroiban, yeah, I understand; as I said, I won't mind you fixing that bug right now in the same manner, and we'll only have to be careful not to break it when we do the pofile:+translate rework | 15:56 |
| adiroiban | well, there should be a next test for this bug and it should catch this kind of regressions | 15:57 |
| danilos | adiroiban, well, with a thing like entire page/view rewrite, you don't really get the benefit of testing (with pagetests), since we'd be using entirely different views | 15:58 |
| adiroiban | well, if there will be such a regression | 15:59 |
| adiroiban | I will notice it :_) | 15:59 |
| allenap | jelmer: I understand what you were asking now. I forgot that there were both launchpad and launchpad-foundations projects. Thank you for reassigning that bug. | 16:00 |
| danilos | adiroiban, fwiw, I am having issues with ec2 land (if you are interested why your branch hasn't landed yet) | 16:17 |
| adiroiban | danilos: ok. are they general issues, or directly caused by my branch? | 16:18 |
| henninge | danilos, adiroiban: It took me a few attempts, too. | 16:22 |
| danilos | adiroiban, general issues it seems | 16:23 |
| henninge | danilos: have you done the sudo apt-get install python-zope.inferface thing? | 16:23 |
| danilos | henninge, does it appear to you as if it doesn't go headless for me | 16:23 |
| danilos | henninge, I think I did, I successfully ran a bunch of tests and ec2 test | 16:23 |
| henninge | I had prlbmes landing branches, wgrant's lately. | 16:24 |
| danilos | henninge, fwiw, there are some lp-dev-deps updates that I haven't installed, let me try that (though, I've had problems for more than a day now) | 16:24 |
| leonardr | intellectronica, i'd like your opinion on bug 534066 | 16:28 |
| mup | Bug #534066: changing bugtask attributes via api gives "412 precondition failed" <api> <Launchpad Bugs:Triaged by james-w> <https://launchpad.net/bugs/534066> | 16:28 |
| intellectronica | leonardr: sure, looking | 16:28 |
| intellectronica | leonardr: that bug itself has a fix, and will be deployed soon, once it hits production-devel. but i agree this is a general problem we need a solution for | 16:30 |
| leonardr | intellectronica: what's the fix, and can you tell me some other places where the problem exists? | 16:30 |
| intellectronica | leonardr: so yes, task_age will be removed (it was removed already a month ago and only made a comeback because of a freak accident). but sooner or later we'll have a field which we can't remove and cause a similar problem | 16:31 |
| leonardr | are there any such fields now? if not, i'm going to focus on other sources of 412 errors | 16:31 |
| leonardr | also, my argument applies to any field that's important enough to go into the representation but not important enough to change the etag when it changes | 16:32 |
| leonardr | you'll have no way of knowing whether your value for that field is accurate | 16:32 |
| intellectronica | leonardr: none i can think of off the top of my head, but even task_age itself, while cheap to remove now, was introduced because a consumer wanted it. | 16:33 |
| intellectronica | leonardr: well, it depends whether the field is writeable. i don't see why it's such a big problem to have read-only fields that are in the representation but aren't used for etag calculation. | 16:33 |
| danilos | henninge, fwiw, updating all source deps made 'ec2 land' go headless for me | 16:34 |
| leonardr | if the values of those fields never change, it's fine | 16:34 |
| leonardr | like date_created | 16:34 |
| danilos | henninge, s/source deps/lp deps/ | 16:34 |
| leonardr | if they change and the etag doesn't change, the client never finds out that the value changed | 16:34 |
| henninge | danilos: yes, I basically had to do the same. | 16:34 |
| intellectronica | leonardr: anyway, that's just something to keep in mind. i agree with you that it's best now to figure out all the other 412 errors and worry about adding this facility later. | 16:34 |
| danilos | anyway, done for the day | 16:34 |
| === danilos is now known as daniloff | ||
| intellectronica | leonardr: right, but in the case of task_age this is something we could live with | 16:35 |
| === matsubara is now known as matsubara-lunch | ||
| intellectronica | anyway, i didn't even think this through enough to have an opinion | 16:36 |
| leonardr | intellectronica: for me "we could live with this data being arbitrarily out-of-date" -> "we don't need this data" | 16:36 |
| leonardr | i have the first glimpses of a couple solutions, i'll write them up in the bug | 16:36 |
| intellectronica | leonardr: that's not exactly true, but judging by this case that's an approximation of the truth. consumers can get this value by calculating locally. | 16:37 |
| leonardr | intellectronica: without putting you on the spot, can you give me a hypothetical counterexample? | 16:37 |
| intellectronica | leonardr: i can think of many read-only attributes where a change in their value is completely irrelevant to a patch you're submitting to the object, and where the only reason they don't usually cause a problem is that they don't tend to change as frequently as every second. consider the number of affected users for a bug, for example. | 16:41 |
| intellectronica | or bug heat | 16:41 |
| intellectronica | the likelihood of the values changing between a fetch and a patch operation is evidently not as high, but if it does, you won't be able to patch even though there's no real reason for you not to be able to, it's just a side effect of the way caching works | 16:42 |
| leonardr | intellectronica: the problem is, if we changed it so those fields didn't affect the etag, clients would never know when the bug heat or affected users changed | 16:43 |
| leonardr | or rather, they would only find out when something _else_ changed | 16:43 |
| leonardr | it would be really nice if we could publish two etags, a GET etag and a PATCH etag | 16:44 |
| intellectronica | leonardr: right, so maybe the problem isn't really how we do caching, but how we decide whether a patch is valid. we just don't have enough information because we don't know which fields changed. | 16:44 |
| intellectronica | leonardr: you mean a read-only and a read/write tag? that sounds like a pretty good solution. | 16:45 |
| intellectronica | is there a sensible way to publish this in as part of the protocol? | 16:45 |
| leonardr | i've never heard of anyone doing that, and it's not part of the http standard | 16:45 |
| intellectronica | but maybe as an extra header? | 16:47 |
| intellectronica | this must be a problem many REST implementations must have | 16:47 |
| leonardr | i may write a blog post about this and see if anyone has ideas | 16:47 |
| leonardr | intellectronica: another way to do it is to check last-modified for PATCH and etag for GET | 16:49 |
| leonardr | but we'd have to make sure that changes to those read-only fields don't affect last-modified | 16:50 |
| intellectronica | leonardr: for last-modified you need to be synchronised with the server time somehow, but i guess that's not a serious problem | 16:50 |
| leonardr | intellectronica: not really, last-modified is just a string you get from the server and send back, like etag | 16:50 |
| intellectronica | heh, yeah, makes sense | 16:50 |
| james_w | leonardr: did you see the mailing list discussion about this? | 16:51 |
| leonardr | james_w: i know there was one a while back, i haven't gotten into it yet | 16:51 |
| james_w | a while back being last week? | 16:52 |
| leonardr | yeah | 16:52 |
| james_w | right | 16:52 |
| === salgado-lunch is now known as salgado | ||
| james_w | I would suggest you start there, it has some discussion on the questions you ask in the bug | 16:54 |
| leonardr | james_w: ok, i'm going there now | 16:55 |
| === matsubara-lunch is now known as matsubara | ||
| === gary_poster is now known as gary-lunch | ||
| jml | thumper, ping | 18:54 |
| === gary-lunch is now known as gary_poster | ||
| wgrant | https://code.edge.launchpad.net/~wgrant/launchpad/fix-build-breadcrumbs/+merge/20888 and https://code.edge.launchpad.net/~wgrant/launchpad/buildstatus-to-buildmaster/+merge/20892 failed a couple of tests last night, but I've fixed them -- can somebody ec2land them, please? | 21:05 |
| === beuno-afk is now known as beuno | ||
| wgrant | kfogel: Do you want to review the c-c.py branch? | 21:32 |
| === matsubara is now known as matsubara-afk | ||
| kfogel | wgrant: yes. Can you just make it into a merge proposal and request a review from me? (I can't do it right now, but I will later.) | 21:38 |
| wgrant | kfogel: Done, thanks. You should have mail in a few seconds. | 21:38 |
| kfogel | wgrant: I hate the way launchpad doesn't update the diff immediately, sigh :-). | 21:39 |
| intellectronica | kfogel: is there a better way to not update the diff immediately? :) | 22:23 |
| mwhudson | bizarre, pidgin seems to have got all crashy suddenly? | 23:31 |
| NCommander | Is anyone actively working on implementing package sets (for archive reorg) in launchpad? | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!