[00:09] * rockstar goes to search for dinner [00:12] The project owner has an implicit subscription to all of the project's bugs unless there is a bug supervisor set. The bug supervisor can unsubscribe from its subscription, but the owner cannot. Is this intentional? [00:12] So, basically, you must have a bug supervisor set or the owning team gets spammed. [00:13] I wonder if it's a holdover from when bug supervisors couldn't unsubscribe either. [00:28] Total: 23204 tests, 8 failures, 7 errors in 236 minutes 9.812 seconds. [00:28] karmic, python2.4 [00:28] devel r9098 [00:28] maxb: pastebin beckons. [00:28] * kfogel is away: Smithwicks w/ Omar [00:28] I must set LP up in a karmic chroot... [00:43] * thumper wanders up the road for a coffee [00:46] Hmm, so several appear to be because I was holding out making sqlite available to python 2.4 until I verified what wanted it [00:48] canonical/lazr/doc/timeout.txt failure... http://paste.ubuntu.com/252217/ - mean anything to anyone? [00:49] test_realiseUpload_for_delayed_copies - http://paste.ubuntu.com/252218/ - DONE != ACCEPTED assertion failure [00:50] maxb: There were no errors before that last one? [00:50] no [00:51] and then lastly soyuz/doc/gina.txt and soyuz/doc/package-diff.txt are very unhappy [00:51] gina.txt gets unhappy sometimes. [00:52] ubuntu-meta sometimes fails to unpack on Karmic. [00:52] Even though it always works when I do it manually. [00:52] I might look further into that today, if it's that close to working on 2.4 Karmic. [01:03] yup, confirmed, with the appropriate additional sqlite packages, down to just the 4 mentioned failures [01:27] documented on LaunchpadOnKarmic [02:36] maxb: I can only reproduce the package-diff.txt and gina.txt failures. [02:37] The package-diff.txt one was an easy fix (debdiff in < Karmic is buggy, and doesn't obey the manpage wrt. exit codes; Karmic's does) [02:37] gina.txt I'm looking at now... [02:37] But it's non-deterministic :( [02:53] * wgrant kicks gina a few times for being non-Zopey, non-Stormy, and non-deterministic. [03:12] wgrant: on the bright side it is still importing debian 2x day with no complaints, has its merits. [03:13] * cprov has to setup an karmic chroot, it's about time. [03:14] cprov: Indeed. It works mostly. [03:14] But has strange strange strange issues in karmic. [03:15] maxb: on the test_realiseUpload_for_delayed_copies failure, print the 'logger.buffer' it might contain a hint about what's going worng. [03:16] wgrant: paste me the complete failure if you can. [03:16] cprov: It's an error 29 (ESPIPE!?) running dpkg-source on a variable number of packages. [03:17] wgrant: did anything sensible changed in karmic dpkg ? [03:17] cprov: I'm trying to work out exactly what it does so I can try to reproduce. [03:17] Since the command it says errored works fine. [03:17] So it might be something in Python. [03:21] wgrant: `dpkg -sn` ?? there is no -n switch [03:22] cprov: Maybe not, but it works. [03:22] Just sometimes not when gina does it. [03:23] The number of failures differs each time. [03:23] Sometimes it succeeds. [03:23] cprov: Ah, -sn is one option. Of course. [03:24] * wgrant waits for slow slow uni proxies. [03:25] wgrant: yes, -sn exists, my bad [03:27] * cprov goes to bed. [03:28] Night cprov. [03:33] barry: are you actually on right now? [03:37] (I noticed that it actually means the exit code was 29, not that an error with errno 29 occurred) [03:38] thumper: thanks for the review. I'm getting 'bzr: ERROR: unknown command "pqm-submit" '... isn't pqm-submit part of the launchpad plugin? [03:50] kfogel: no, it is bzr-pqm [03:50] thumper: ah [03:51] thumper: so I'm confused because it's *always* Just Worked from this box, and now suddenly it doesn't. AFAIK I didn't do anything to change things... well, whatever. I'll go look for the plugin. [03:52] kfogel: which bzr? [03:52] thumper: trunk, recent [03:52] /usr/local/bin/bzr [03:52] symlink to my src [03:53] thumper: submitted [04:04] spm: ping [04:05] thumper: heyo [04:06] spm: can I get logs for the scripts bmp creation jobs [04:06] spm: (both of them) [04:06] spm: logs synced that is [04:06] spm: I should see why I didn't get an email from karl [04:07] kk [04:09] thumper: bzrsyncd is done; doing codehost atm (can't recall offhand which one that stuff runs on) [04:10] spm: me neither [04:10] I'd love to rename the jobs so I can get it right [04:10] ignorance shared is.... hmmm. ignorance squared? [04:12] thumper: mpcreationjobs is bzrsyncd, fwiw [04:15] cprov, maxb: The gina.txt failure is a Karmic dpkg bug, which is probably maybe sort of tracked in bug #399938. [04:15] Bug #399938: unpacking the upstream tarball not working

[04:25] Hrm, the explanation in the bug was not clear. [04:25] It looks like it might actually be that the fixed dpkg bug has the same symptoms that are caused by Python ignoring SIGPIPE. [04:25] * wgrant pokes harder. [04:32] There we go. [04:32] Fixed. [05:09] spm: still cherrypicking? [05:14] thumper: ha. 4 hour test run? yes. :-) [05:14] :( [05:14] spm: plz get faster 'puter [05:14] thumper: pls write faster tests [05:15] last word. I win. :-P [05:15] I can haz ec2test and review? [05:15] lp:~wgrant/launchpad/karmic-2.4-fixes [05:15] I've only tested on karmic and jaunty, not hardy. [05:22] spm: arg [05:27] thumper: hopefully should be finishing sometime in the next hour, hour & ½. [05:27] ok [05:57] thumper: while you wait, can you help me figure out a problem I'm looking at? [05:58] jtv: me waiting? hah, but sure - hit me [05:58] that thumper... last time he was in a slapping mood, now he's in a be-slapped mood [05:58] * jtv hits thumper [05:58] *any-way*... [05:59] My script commits translations snapshots to a bzr branch. Works fine generally. [05:59] I feel a but coming along [05:59] But there's a project that exports its translations back to the same branch it also imports translations from. [06:00] That _should_ work. The imports are based on branch jobs when the branch changes, the exports are done from a cron job. [06:00] If the exporter sees that there's an unfinished translations import job on the branch, it backs off from committing to it. [06:01] But I notice that for several days in a row now, every daily run sees this situation and backs off. [06:01] ok... [06:02] On staging there are such jobs, except they're all completed. [06:02] how do you determine an unfinished translation import job [06:02] Exactly. [06:02] ah [06:02] don't we have a start time? [06:02] Well I look at type and status. [06:02] OK, the way I see it you need two things: [06:02] firstly [06:03] thing [06:03] ... [06:03] profit! [06:03] lifeless: thanks, that's very helpful [06:03] can we skip straight to the profit? [06:03] unfinished should mean pending, that has started but not yet finished :) [06:03] jtv: I aim to please. [06:03] rather than just pending in the future some time [06:03] better than aiming at peas. [06:03] cringe [06:03] and the import job would need to know not to run while an export is running on the same branch [06:04] lifeless: better than aiming your pee [06:04] no, actually aiming your pee is quite useful. [06:04] thumper: if you don't aim you will dis please [06:04] jtv: as long as it isn't at you or me [06:04] thumper: actually it's the other way around—I want the import job to complete peacefully and the export job to back off. [06:04] it all depends on the target [06:05] I'm just trying to figure out why the exporter hits that situation quite so often. [06:05] jtv: yes, but if there is an export job running, you don't want the import job to start right? [06:05] jtv: my guess is that when an import job has finished, it creates another at some future time [06:05] thumper: the exporter has the branch locked anyway. [06:06] I don't suppose the stuff I'm doing with the branch causes RosettaUploadJobs to be created even before I commit? [06:07] AFAICT the import job does not create a new instance of itself: it's created by the branch scanner when a change is detected. Besides, on staging I only see completed ones. [06:07] hmm.. [06:08] I'd say get a losa to run queries for you [06:08] it _might_ be an unlucky interference between cron jobs I guess [06:08] to see if production is like you think it should be [06:08] jtv: possibly [06:08] but I don't think so [06:08] owww, do I _have_ to talk to spm again? :-) [06:08] it seems wrong [06:08] jtv: no, you could wait for herb :) [06:09] spm it is then :) [06:10] For the "I'm unwittingly creating the job myself" hypothesis I could ask a losa to give the export job an extra run... [06:13] thumper: ahhhhh I think I may have it [06:13] Job.id == BranchJob.id [06:13] Bad join condition. [06:14] haha [06:14] yes [06:14] Should be Job.id == BranchJob.job [06:14] right [06:19] jtv: I CC'ed you on my email about query performance [06:19] jtv: I thought you might have some ideas [06:19] jtv: it went to the launchpad-dev list anyway [06:19] thumper: I see it [06:20] and I owe you a look. :) [06:20] jtv: I _think_ we may be able to speed up the queries with an index [06:20] jtv: I'm hoping [06:20] or we may need some other magic [06:21] thumper: I'll have a look. Most well-documented "query performance post" I've seen so far. [06:22] jtv: thanks [06:22] thumper: this is a common pattern... IIRC BjornT had a similar optimization problem dealing with "either non-private or visible to this user." [06:22] Maybe we should just have a team for Everyone. :) [06:23] thumper: you're always checking for ownership, even though you've got a done deal in the common case where the branch is public. [06:24] thumper: (assuming the "private = %s" means "private is false") [06:24] jtv: it is [06:24] in the subscription one we only look for private [06:24] you'll want to limit the ownership check to private branches [06:25] do you think that it makes that much of a difference? [06:25] perhaps it does [06:26] thumper: it's hard to say; it's right at the other end of the join so maybe not. But even then we'd hate ourselves for not checking. [06:26] jtv: it could be huge [06:26] jtv: given that we have 150k branchesnow [06:26] child's play [06:26] it is a one line fix [06:26] wanna play with the TranslationMessage table? [06:26] that should break no tests [06:27] jtv: looked at the branch revision table? [06:27] I think we win [06:27] ah now, branch _revision_ table is big I know [06:27] how big is it? [06:27] biggish [06:27] how biggish? [06:27] jtv: heyo [06:28] spm: want to compare some timings for me? [06:28] hi spm! nm, thumper sat by the couch as I wrestled through my emotional problems and resolved the issue [06:28] jtv: errr. oki. I'll try not to feel left out, unwanted etc [06:29] (It was something to do with my mother not loving me, or a bad join condition) [06:29] thumper: is that a trick question? [06:29] spm: what is my person id? [06:29] spm: I'm assembling the query now [06:30] thumper: you can also move the selection of all public branches out of the union: "Branch.private = FALSE OR Branch.id IN (... UNION ...)" [06:30] thumper: 433852 [06:34] spm: http://pastebin.ubuntu.com/252311/ [06:34] spm: there are three queries there [06:35] thumper: oki [06:35] spm: much appreciated [06:36] thumper: in return. does this look spurious or serious to you? https://pastebin.canonical.com/21094/ [06:36] spm, thumper: also, try this with a partial index on private branches only. Indexing just the "private" attribute may not be quite as effective. [06:37] can't find any mention of that failed test beyond that. [06:37] spm: spurious I think [06:37] jtv, spm: the partial index thing is probably best done on staging :) [06:37] jtv: can you give spm an example of what you mean? [06:37] I wasn't planning on doing it on prod! :-) [06:37] spm: I wouldn't think you would [06:38] spm: are you running my three on staging? [06:38] spm: staging is fine I think [06:38] thumper: prod, but can shift? [06:38] spm: I just need comparitive results [06:38] spm: prod is fine too [06:38] I think the first one takes around 1200ms [06:38] thumper: coolio. do you need the output or, sure you've got it right? [06:38] I don't need the output, just the times [06:39] * spm ndos [06:39] the output should be the same for all three [06:39] if it isn't [06:39] something is wrong [06:39] spm: it is just a count of active reviews I'm doing [06:39] spm: it won't be very big [06:40] I'd try "CREATE UNIQUE INDEX foo ON Branch(id) WHERE private IS TRUE" and "CREATE INDEX bar ON Branch(owner) WHERE private IS TRUE" and then run the query with the "private IS TRUE" condition on the ownership check. [06:40] One or the other might catch something. [06:40] * thumper waits [06:40] thumper: 1st was 2.2secs, then 1.7 to 1.9secs on later runs. result is count = 1. [06:40] I'm EODing after this [06:41] spm: ok [06:41] spm: that matches what I'm seeing in the oopses [06:42] thumper: 2nd was 2.9 for first; then consistant 1.8's; again count == 1 [06:42] ok, not much in that one then [06:42] * thumper taps his foot [06:43] thumper: wow. I think you want to use #3. 0.127secs from the get go [06:43] w00t [06:43] jtv: you tha man [06:43] 10x improvement is impressive [06:43] I think I can submit that fix easily [06:43] +1 from me for it at any rate :-) [06:43] I haven't exactly followed the channel... what was it that did it? [06:44] * thumper branches now [06:44] jtv: the third query in the pastebin [06:44] jtv: moving Branch.private = False out of the union [06:45] thumper: cool, I think I've repaid you for the day then. :) [06:45] jtv: that you have, thanks [06:45] my pleasure, sir [06:46] ok... [06:47] not as trivial as I hoped [06:47] uh-oh [06:47] but I think I can get it done tomorrow [06:47] it is more how we handle visibility checks in the branch collection code [06:47] I was hoping for a two line fix [06:47] and it will be longer [06:47] but still relatively simple I think [06:47] but not for today [06:47] I'll look at it tomorrow [06:48] * thumper acts like a tree [06:48] Oh, I think I've looked at that code once and the function calls to build up the query go pretty deep. [06:48] What do trees do? Grow? Metabolize carbon dioxide? Get hugged by hippies? [06:49] trees? cut down and turned into beautiful furniture? a la my lovely jarrah desk I built that I'm sitting at atm [06:50] spm: we don't want thumper to be get cut down and turned into furniture, now do we? [06:51] (*Beautiful* furniture could be hard, but let's generalize the principle) [06:51] ah. that'll teach me for reading approximately ONE line of scrollback and responding. Doh. [06:51] No worries. All makes for good entertainment. [06:52] LOSA Duties: operational sysadmin; general entertainer; etc [06:54] spm: dance for us! [06:54] (At this point I bet ara is wondering...) [06:55] jtv: I dance... on the inside [06:56] ooh, nice comeback [06:56] so nice in fact that I'll refrain from making jokes like "inside of what?" [06:57] heh [07:27] + * lib/lp/soyuz/tests/../doc/gina.txt - tar broke dpkg. dpkg was fixed. python breaks the fix. wgrant has a fix. [07:27] whoa, sounds hellish :-) [07:28] maxb: Nasty signal stuff. [07:28] But see lp:~wgrant/launchpad/karmic-2.4-fixes [07:28] All fixed. [07:28] Soyuz tests pass now. [07:29] That one took a little while to track down. [07:40] * maxb wonders how on earth we get valid archives wherein tar doesn't consume all the compressed data [07:40] Who knows. [07:41] But it happens... [07:41] Often. [08:03] maxb: What arch did you run the tests on? [08:04] Because I have no idea where those other failures came from... [08:07] amd64 [08:08] Seems unlikely, but that's one difference. [08:11] I'd try again, but I'm in the middle of a py2.5 testrun [08:11] I need to make myself a separate lp-sourcedeps for 2.4 vs 2.5 [08:11] I need a separate sourcedeps for amd64 vs. i386 :( [08:12] That's why all my instances are i386; my first one was. [08:12] I'm thinking symlink download-cache, bzr checkout --lightweight sourcecode/* [08:13] Possibly. [08:15] * wgrant heads home. [08:28] good morning [09:18] Morning [10:21] Now that Bugs people are around: [10:22] The project owner has an implicit subscription to all of the project's bugs unless there is a bug supervisor set. The bug supervisor can unsubscribe from its subscription, but the owner cannot. Is this intentional? I wonder if it's a holdover from when bug supervisors couldn't unsubscribe either. [10:22] This confused when I moved a project to Launchpad last week, and couldn't unsubscribe the team. [10:33] wgrant: i'm not sure i understand. what were you expecting to be able to do? [10:35] intellectronica: The project owner always has an implicit subscription to a project's bugs if the project has no bug supervisor. [10:35] intellectronica: This subscription is impossible to remove. [10:36] It is the only one which is irremovable. [10:36] This seems strange. [10:37] wgrant: well, it's not really a subscription. it's an "also notified" [10:37] the point is that _someone_ needs to be notified, and project owner or bug supervisor make sense [10:37] intellectronica: It's a forced structural subscription. [10:37] intellectronica: The bug supervisor can easily unsubscribe. [10:37] As the bug supervisor is no longer implicitly notified; it just normally has a structural subscription. [10:38] The project owner *is* implicitly notified, without a subscription. [10:38] This is entirely unobvious. [10:38] 'Subscribe to bugmail' is the obvious place to look, but doesn't help. [10:38] So I checked the code, and indeed it is hardcoded. [10:38] (lp.bugs.model.bug:620) [10:44] intellectronica: So, it is quite easy to get into a condition where nobody gets email, but also quite hard for users to work out how to stop email. [10:44] And other bugtrackers don't by default email anybody about all new bugs. [10:44] So it wouldn't be entirely unthinkable to not have the owner notified by default. [10:46] don't know, maybe you're right and we don't have to have any subscribers by default. haven't though about this enough. i still think that it would be bad if a project had noone notified [10:49] intellectronica: It sounds like a question that should be asked during the guided project creation. [10:50] That can then create a structural subscription if the creator desires. [10:51] wgrant: i'm not sure it's worth asking, but it might make sense to simply create a structural subscription (which can then be removed) [10:51] there's one serious implication of having no subscriptions, though, and that's private bugs [10:51] intellectronica: That does get slightly confusing when the ownership changes. [10:51] intellectronica: Private bugs do not care about indirect subscriptions, do they? [10:51] Don't they just subscribe either the security contact or the bug supervisor? [10:51] Or owner if either doesn't exist? [10:52] they do, in the sense that indirect subscriptions are converted to direct ones when a bug becomes private [10:52] Right. [10:52] But I'm not sure why that's of concern. [10:52] Or do you mean that you'd expect the project team to be able to see them always? [10:53] I think bug privacy implications need to be much more obvious, which would alleviate this. [10:53] because you can end up with orphan bugs. bugs which nobody will be able to see. this is risky in particular with security-related bugs [10:53] i agree [10:53] Bugs that are filed as security bugs will always have somebody subscribed, though. [10:54] And maybe marking a bug as private should warn if only you'll be able to see it. [10:54] But if a structural subscription is created initially, the projects with nobody subscribed should be minimal. In my case the interested developers subscribed separately. [10:54] But there are managerish people in the team, and they probably didn't want notifications. [13:25] jtv: What do you reckon we should call these "policies"? Review policies? [13:26] mrevell: access or permissions policies [13:26] jtv: Okay, let's stick with permissions policies as that's what we've had pretty much all along. [13:27] mrevell: cool [13:27] g'mornin [13:28] beuno: buenos [13:30] jtv, que tal? [13:30] beuno: bien, bien... ¿tu? [13:31] oh, I can do better: tú === mrevell is now known as mrevell-lunch [13:32] danilos: cp requests are both there now... what else have I forgotten? :) [13:32] jtv, "vos" [13:32] beuno: ahhh, you funny folks :) [13:32] :) [13:33] The two countries whose Spanish is _really_ weird and different: Argentina and Spain [13:34] we like being unique === bigjools is now known as bigjools-lunch [13:36] hey beuno! any news about those breadcrumbs? I'd like to see some more examples to make sure the new infrastructure can cope with them [13:37] salgado, I will write them *now* [13:40] beuno, great, thanks! === bigjools-lunch is now known as bigjools [14:08] salgado, Im putting examples for: a bug, a branch, a merge proposal, a package, a bug in a package and a blueprint. Need anymore? === dpm_ is now known as dpm [14:12] beuno, how about https://translations.edge.launchpad.net/ubuntu/jaunty/+source/gfxboot-theme-ubuntu/+pots/bootloader/af/+translate ? [14:13] salgado, will add that as well [14:13] working on the wiki page [14:13] gimmi a few more minutes [14:13] sure thing! === mrevell-lunch is now known as mrevell [14:19] sinzui: ping? [14:19] Hi BjornT [14:19] * gmb => caffeine. BBIAB. [14:19] sinzui: hi. i'm looking at c.l.javascript/registry/milestoneoverlay.js [14:19] * sinzui saw the bug [14:20] sinzui: when you show an error message in the overlay, why don't you use overlay.showError()? [14:20] BjornT: It did not exist when the widget was created [14:21] sinzui: ok. so it's ok if i change it to use showError()? [14:21] BjornT: I think rockstar added the feature after looking at competing implementations. I talked to him about it [14:21] BjornT: +1 to fix the widget. If you do not have time, I think we will get to it before 3.0 [14:22] sinzui: cool. i'll do it, since i want to update it to use a new method i wrote, and the custom error handling got in the way. [14:31] salgado, that was a tricky one [14:31] salgado, danilos, https://wiki.canonical.com/Launchpad/UI/Navigation [14:32] I did something weird there [14:32] Ubuntu > Jaunty 9.04 > Afrikaans translations > gfxboot-theme-ubuntu > Translating bootloader [14:32] instead of: [14:32] Ubuntu > Jaunty 9.04 > gfxboot-theme-ubuntu > Afrikaans translations > Translating bootloader [14:33] it was an arbitrary decision, to fix a long-standing bug for translators who can't get back to their language to translate more templates [14:34] I will continue adding the remaning examples, but let me know what you think [14:34] beuno: right, it's something we discussed before, and what we want to fix anyway [14:35] beuno: we need that on product translations as well [14:35] danilos, yeah, and the links don't make sense in the second option, even though the hierarchy may [14:35] I'm not 100% sure this isn't too crazy, but I'm 65% sure [14:35] beuno: yeah, we can easily move the links around as well [14:36] danilos, will do one for product translations. Do you have a link handy? [14:36] beuno: https://translations.launchpad.dev/evolution/trunk/+pots/evolution-2.2/es/+translate (I think, I made half of it up :)) [14:36] beuno: or, if you want something on edge... [14:37] danilos, yes :) [14:37] beuno: https://translations.edge.launchpad.net/tangocms/trunk/+lang/es and any link from there [14:38] danilos, thanks [15:10] kfogel: flacoste is in a crapper :) [15:13] stub, herb, flacoste, rockstar, bigjools, henninge, sinzui, intellectronica: LP production meeting in 47 min in #launchpad-meeting [15:13] thanks for the reminder, matsubara [15:13] matsubara: thanks [15:19] sinzui, one of the tests failed because I forgot to re-add the link to '+branding' that was removed from the actions menu. should I leave it in the nav menu for now? [15:21] salgado: Can you add the link to details page. [15:22] salgado: change details page. [15:22] salgado: EdwinGrubbs: Beuno provided a good plan to allow us to move branding links into the page, so we only need to provide the link from the change details page for now. [15:23] sinzui, at the bottom of the +edit page, using the related pages thing? or something else? [15:25] salgado: That is the immediate kind of fix (and we can hack the h2 and ul into template, no menu) , the other route is add a sentence that includes the link in extra-form slot [15:28] sinzui, +edit has been converted to 3.0 in this branch of mine, and it already has a [15:28] so, if there isn't anything preventing me from defining a menu to be used there, I think I'll just do it [15:29] +1 [15:49] kfogel, http://googletesting.blogspot.com/2009/07/call-for-attendance-google-test.html [15:54] sinzui, https://pastebin.canonical.com/21116/ fixes most of the tests that failed. only 2 more to go [15:56] salgado: +1 [15:57] salgado: if the product-menu test failed, make sure you have the latest version...the lastest version is not bittle [15:57] sinzui, I've removed portlet-milestones from project-index.pt, so now there's a test failing because there's no 'See all milestones' link in that page [15:58] We should add the link I think. I do not think there is any other way to get to that page. [15:59] sinzui, any suggestions for where to put the link? I don't see any obvious place for it in the current layout [16:01] At the bottom of projects portlet, where we list milestones [16:02] sinzui, could you comment on bug 412971? [16:02] Bug #412971: Convert bug-edit.pt to 3.0 template [16:03] beuno, sinzui -- I'm adding notes/questions/etc. to that bug right now with questions I have so far. [16:04]