[00:16] mbarnett, any word on the buildbot stuff? I'm way past EOD here, but I don't want to leave the whole system offline like this [00:18] perhaps spm has the torch now === lifeless changed the topic of #launchpad-dev to: Launchpad Development Channel | Week 1 of 10.10 | PQM is open for business | firefighting: - | https:/​/​dev.launchpad.net/​ | Get the code: https:/​/​dev.launchpad.net/​Getting [00:19] * spm hates at buildbot, reiterates plea from the heart and declares success in getting the PoS back [00:19] thanks spm [00:20] mars: np; it will need any 'was happening' builds to be stabbed tho. requerued? whatever it's called. forced? [00:21] spm, could you please restart the lucid_lp and lucid_db_lp build slaves too? I don't want to have to return to this tonight [00:21] after that I will force everything to rebuild [00:22] mars: you can do all of that yourself [00:22] the lucid slaves have to be killed as part of the recovery [00:22] oh, good [00:23] basically you *must* shutdown everything BB related. kill/stab/burn with fire. then bring up the lucid slaves; then the master. repeat on restarting the master till the *(%(%^*&%^&*$%&*$%ing thing works. [00:23] spm, so your procedures now include the steps to preven process trash from half-done builds lying around? [00:23] ok [00:23] so 'yes' [00:23] mars: that's the burn with fire part :-) [00:23] \o/ [00:23] sinzui: still around? [00:24] sinzui: how does class="listing sortable" interact with batching? [00:24] all builds forced [00:25] lifeless: poorly, because sortable just sorts the current batch [00:25] spm, lifeless, if the prod_lp slave dies again, we'll have to do a full restart and force all the builders again. It's the only way. [00:25] mwhudson: is it tolerable? (for +assignments) [00:25] mars: thanks [00:26] aw FL*(# [00:26] mars: orsum [00:26] lifeless: no idea really, it's not great [00:27] lifeless, spm, so, about that "if prod_lp" dies thing - surprise! Guess what just happened... [00:27] mars: raarh [00:27] substantiate failed! [00:27] quickly too [00:27] ugh, all the EC2 builders died [00:27] mars: I'll need a few more clues? ;-) [00:27] hammer [00:27] tongs [00:28] maybe aws is having a bad day [00:28] apply [00:28] spm https://lpbuildbot.canonical.com/waterfall [00:28] mars try a second force - I did terminate the (old) ec2 instances that were running. so the master may have belatedly got poor signals? [00:30] need to go afk, crying babes in arms, back as soon as possible [00:33] mars: sorry for dropping you there [00:33] * spm forces a build on prod_lp [00:42] After the last rollout, we have a few users who need their multiple accounts merged. [00:42] Except they now only have access to the new account -- the one they don't want to keep. [00:42] Should I ask them to file a question so an admin can merge them the right way? [00:43] jam: 'from twisted.internet import defer; defer.setDebugging(True)' [00:46] mwhudson: are there tests of specification template rendering ? [00:49] lifeless: mostly only in the page tests [00:49] akaik [00:49] mwhudson: where would they be? the .txt files i found had no browser_ stuff [00:50] mwhudson: skip that, time I learnt something new [00:50] mwhudson: whats the preferred way to render a template [00:50] I want to check that it gets batched in unittest style code. [00:50] lifeless: using testbrowser is probably easiest [00:51] self.getUserBrowser() ? [00:51] otherwise, create_initialized_view() and call .render() i think? [00:51] yeah [00:51] ah, .render is probably cleaner [00:51] less layers for what I'm interested in. [00:54] yeah, probably [00:54] ahhh stories/standalone is where stuff was. [00:54] nvm I'm deep into doing it right :) [01:35] spm: Do you have a moment to do a quick account merge? https://answers.edge.launchpad.net/launchpad/+question/125444 -- he's been unable to log in since the rollout last week., [01:35] not really, but will do. [01:35] Heh, thanks. [01:36] ahh. thanks! you've done the research. much appreciated! [01:37] is done [01:37] Yeah, that's why it was really quick. [01:37] Thanks. [01:49] abentley: Why do we not permit arbitrary code execution in the tree build step? [01:50] Some seem to think that it is because of security. [01:50] But that cannot be the case. [01:58] rockstar: hi? [02:09] wgrant: why can't it be the case? [02:10] lifeless: Because the chroot doesn't provide security. [02:10] So doing something outside the chroot can't be a security vulnerability. [02:17] Hard / Soft Page ID [02:17] 229 / 1575 ScopedCollection:CollectionResource:#message-page-resource [02:17] 91 / 255 BugTask:+index [02:17] 67 / 34 DistributionSourcePackage:+filebug [02:17] 52 / 7 Distribution:+search [02:17] 48 / 231 CodeImportSchedulerApplication:CodeImportSchedulerAPI [02:19] What is message-page-resource? [02:19] I haven't seen that before. [02:20] I'm looking ATM [02:20] https://api.launchpad.net/1.0/bugs/136469/messages [02:20] <_mup_> Bug #136469: toshiba p100 series dsdt acpi error no sound, works with acpi turned off. [02:21] ws.start=75&ws.size=75 [02:21] SQL time: 4344 ms [02:21] Non-sql time: 10882 ms [02:21] Total time: 15226 ms [02:21] Statement Count: 288 [02:21] Somehow I doubt it. [02:21] ? [02:22] poolie, hi. [02:22] That much non-SQL time for so few objects? [02:22] hi rockstar, i was just going to ask if you could pair with jam on getting his bzr-lp forking server finished [02:23] wgrant: welcome to bad-O, or thread-thrashing, or a few things [02:23] and on reviewing what he's done so far [02:23] lifeless: I meant that it was probably not bad code, but thread-thrashing, yes. [02:23] wgrant: its -so- frequent its not going to be a passive victim of worse pages [02:23] i think you may have been there for some discussion of it at the epic [02:23] poolie, I might not be the best guy to pair with him. I'm mostly a frontend guy recently. [02:23] poolie, in fact, I don't know much about the forking stuff at all. [02:23] rockstar: the big advantage is that you are in my timezone :) [02:23] poolie, but if you think I might be of help to him, I'm happy to do it. [02:23] jam, :) [02:24] jam, abentley might be better. He's paired with jml on parts of that code at least. [02:24] rockstar: I've got a lot of small questions [02:24] abentley could also be great [02:24] jam, okay. Shoot. I might be able to answer a few of them at least. [02:26] who knows about how deferred mail works (for bugs, mp's etc etc) [02:26] questions need this done to them pretty soon [02:26] but I don't want to do it arbitrarily differently. [02:27] lifeless: Haven't we established that we really don't want to follow the Bugs method? [02:27] wgrant: policy of naming, no. Method of deferring - I haven't considered. [02:27] wgrant: tell me about it. [02:27] Bugs and Code do it differently. [02:27] great. Please be informing your humble TA [02:27] * lifeless grovels and drools a little [02:28] Bugs changes create rows in BugNotification, with a BugNotificationRecipient for each (direct or indirect) subscriber. [02:28] send-bug-notifications.py then processes those every 5 minutes or so, I believe. [02:29] MPs only started deferred sending recently... and I think they use BranchMergeProposalJob for that, but I haven't looked closely yet. [02:34] rockstar: I'm mostly watching a movie with my son right now, but I'll chat with you a bit tomorrow if you're around [02:34] jam, okay. Maybe abentley and I can combine our powers. [03:08] mtaylor: oh hai [03:11] spm: I can has profile? [03:11] damn. just 5 secs too slow on heading too lunch ;-) [03:11] rotfl [03:11] har [03:12] yes? no? maybe? [03:12] oh, the yes was iomplied, just logging in [03:13] if you like, once its enabled, I'll keep poking at it while you go to lunch [03:13] sure [03:13] is restarting.... [03:13] wgrant: https://api.staging.launchpad.net/1.0/bugs/1/messages?ws.start=150&ws.size=75 - da boom - [03:14] <_mup_> Bug #1: Microsoft has a majority market share < [03:15] spm: whats staging load like ? [03:15] (can you kick it low before going) [03:16] lifeless: 4ish, kickin' [03:17] lifeless: and dropping. should be good to go [03:17] thank thee kindly [03:18] grah [03:18] no [03:18] ++profile doesn't work on the API [03:18] bug filing time [03:18] spm: turn it back off thanks, and shoo fo rlunch [03:18] spm: (when you get back is fine, no rush from my POV) [03:20] lifeless: is done [03:23] wgrant: https://bugs.edge.launchpad.net/malone/+bug/497386 for your skepticsm [03:23] <_mup_> Bug #497386: ScopedCollection:CollectionResource:#message-page-resource timeouts for bugs with many messages [03:25] lifeless: Am I missing something, or can (1) be done trivially with a DRS? [03:26] wgrant: with a rank() function probably, as long as someone unwinds the login in indexed_messages appropriately [03:26] wgrant: (thats yes) [03:27] possibly better to just store in the table though [03:34] wgrant: more data in it now [03:37] hah [03:37] indexed_messages is whats exported [03:37] I bet its calculating one of the links in it that is the *actual* bottleneck today [03:44] hmm, I wonder how to trigger jsonification of an object for a test [03:44] wgrant: have you perchance poked at that ? [03:58] lifeless: No, sorry. [04:05] lifeless: jsonified by the lazr.restful machinery? [04:05] There are methods to make webservice requests, but I've never seen a test that jsonifies something in Launchpad [04:05] looking at the lazr.restful doctests might give a hint [04:07] james_w: yeah [04:07] wondering how close to the issue I can get my test was all [04:14] lifeless: representation = simplejson.dumps(self, cls=ResourceJSONEncoder) [04:14] something like that might be close, but isn't everything the lazr.restful does [04:14] yeah [04:15] I'm just going to test the larger case - the key one - adding messages shouldn't increase queries. [04:15] once I get out of this ubuntu-bugs quagmire with our latest enthusiastic spammer [04:15] otherwise you need to get an EntryResource for the object, and call _representation on it apparently [04:16] and you need a request to do that [04:17] yeah, the simplejson.dumps should be close, but bypasses all the lazr.restful machinery, so it depends where you want to test [04:17] well, not all, but lots [04:21] need the machinery :P [04:22] lifeless: you need the cache and things, not just the serialisation? [04:24] I need to reproduce what the appserver does [04:24] otherwise the test isn't complete. [04:24] anyhow, I'm good. [04:29] well, you don't run the test via apache :-P [04:30] I've added a new model to soyuz in db-devel, and now that I'm getting around to using it, the security proxy is hiding all of it. How can I check/debug/fix that? [04:32] james_w: yes, but thats outside the scope that can trigger more db calls [04:32] StevenK: interfaces [04:32] lifeless: I added that too [04:33] and enabled it via zcml ? [04:33] lifeless: I certainly added it to the zcml, I'm not sure if it was right. [04:33] lifeless: I can dig up the MP if you want to take a squiz [04:36] StevenK: perhaps you should describe the symptoms more ;) [04:36] like 'in a test xxytyzz' [04:38] lifeless: I've added a new method to lp.registry.interfaces.IDistroSeries called deriveDistroSeries(), and in the model code it's calling job = getUtility(IInitialiseDistroSeriesJobSource).create(child), and whenever I try and access any attribute on job, I get denied. [04:39] is job the right type? [04:40] If I remove the security proxy to check, yes [04:41] check the security you've permitted for the attributes is appropriate [04:41] also getUtility(IInitialiseDistroSeriesJobSource).create(child) seems awfully ugly [04:44] lifeless: How do I check the security? My zcml-foo is fairly non-existant [05:19] oh lifeless i meant to say: what a nice tuesday mail [05:19] here, have a peanut :) [05:19] (in the sense of gallery, not monkey) [05:19] Bwaha [05:23] Is there any easy way to introspect the name of a variable? [05:27] look at it [05:27] where are you starting from? [05:27] StevenK: if you just have an object reference in python you can't directly tell what variable holds it [05:27] however, you can look at locals() and globals() and walk through the stack [05:29] poolie: thanks [05:29] poolie: I'm looping over a list of variables and croaking when they're not set, I was wondering if I could get at the variable name easily for a nice error message [05:29] pastebin the code? [05:29] StevenK: paste the code [05:29] lol [05:29] :) [05:29] pics or gtfo [05:30] poolie: was there anything particular about the tuesday may that made it nice? [05:30] i meant actually the mail about it [05:31] and only indirectly the content [05:31] but it sounds like it was fun [05:31] i liked the "today i learned about $x" [05:31] it suggests other people could possibly learn about things too :) [05:32] http://paste.ubuntu.com/493988/ [05:32] oh it's going to say "None can't be unset"? :) [05:33] so you could do 'if not locals().get(param_name)' and list the things as quoted strings [05:33] i don't know if that's exactly idiomatic [05:33] alternatively just 'assert displayname;assert summary;...' [05:33] poolie: Exactly [05:34] which will give a clear but less pretty error [05:34] (and it wouldn't be allowed in bzr code, which bans the 'assert' statement because it can be turned off) [05:34] so [05:34] I'd define a tested helper in lp.services [05:34] also i would do raise DerivationError(.... [05:34] not the old syntax [05:34] and do [05:35] something useful with it :) [05:35] the args are available on the stack too ;) [05:36] one could have a decorator [05:36] I think we may already have one [05:36] @require_nonnull_parameters(['breakfast', 'lunch']) [05:36] the apis stuff has some declaritive foo here [05:38] Yes, but the arguments are only required in one circumstance [05:41] which circumstance is that? [05:42] argvalues = inspect.getargvalues(inspect.currentframe()); for arg in argvalues.args: if argvalues.locals.get(arg) is None: raise ... # ;) [05:43] jtv: hey, so hows the template page in edge ? [05:44] lifeless: works fine [05:44] time to render? [05:44] found it surprisingly fast on staging earlier [05:44] spiv: Hold on, I'm dabbing the blood from my eyes :-) [05:45] lifeless: pretty decent; still slow but probably from a part of the process that we don't watch as closely such as transfer to the client [05:46] Haven't seen any timeouts at all on edge; I just managed to trigger one on staging though. [05:46] I'm guessing on staging it depends a lot on load. [05:47] StevenK: oh, if you want blood then I'm sure I can find uglier ways to do that... sys._getframe().f_code.co_* springs to mind. [05:47] Unfortunately chromium's "view source" breaks a lot on this page [05:47] spiv: doesn't fit as neatly into the meter as "you got it" though [05:48] spiv: Bah :-) [05:48] If You Want Blood… sys._getgrame().f_code.co_* [05:48] lifeless: just got a render time of 7 seconds. There's other things the new code will let us do if it's too much. [05:51] lifeless: in its current basic structure we could bring the critical loop body down to a single "%" operation. [05:52] jtv: jtv check the render comments to evaluate time, for now :) [05:52] once we're down to a second of render time we can worry about transfer time [05:52] jtv: oh, I see chrome fail [05:55] lifeless: just got one rendered in 2.33 seconds, so I think rendering time is close to losing its position as the dominant time sink. [05:56] Funny: looks as if firefox is actually faster than chromium for this page === almaisan-away is now known as al-maisan [06:03] jtv: thats great [06:06] A bit disappointing to see so much variability. It may be because we've become entirely bottlenecked on appserver CPU. [06:07] At least, I think we have; I'll know more when my oops shows up. [06:07] But as this becomes the norm for "performance-interesting" pages, we may have to look more critically at the GIL. [06:08] I've filed a bug and RT to experiment on this [06:09] Ah, there's my informational oops for +templates: 3885ms, of which 206ms are spent blocked. [06:09] how many rows? [06:10] Just over 2K. [06:11] All the queries are at the head and the bottom, with a big chunk of rendering time for the table in the middle. [06:12] The Big Query takes 86ms. [06:36] so 2K - probably 666ms in storm [06:36] on an idle machine. [06:36] more or less depending on row width [06:36] lifeless: O hai, did you miss my question? [06:57] question? [06:57] < StevenK> lifeless: How do I check the security? My zcml-foo is fairly non-existant [06:58] about the same as mine I suspect [06:59] lifeless: Bugger :-) [07:12] stub: how long till 8.4 ? [07:12] The packages are on sourcherry so I want to do staging today. [07:13] awesome [07:13] I want to use rank() to get message indices [07:13] should shave a tonne of time off of bug 1. [07:13] <_mup_> Bug #1: Microsoft has a majority market share < [07:13] lifeless: tsearch2 rank()? Should be in 8.3. [07:15] stub: window function rank() [07:15] rank() OVER (..) [07:15] spm: hi [07:15] yo [07:15] spm: production rollout - buildbot borkage. [07:15] https://lpbuildbot.canonical.com/builders/prod_lp/builds/98 [07:16] it grabbed rev 9762 [07:16] I see 9765 as tip of production-devel. [07:16] we want ot remove the cowboy and get stuff out there. Dunno whats going on. [07:16] However, I has to run - family time. [07:16] beyond bb being a pos as in? [07:17] yes exactly [07:17] why isn't it getting the tip of production-devel [07:17] https://lpbuildbot.canonical.com/builders/prod_lp/builds/98/steps/bzr/logs/stdio [07:17] argv: ['/usr/bin/bzr', 'checkout', '--revision', '9762', 'bzr+ssh://bazaar.launchpad.net/~launchpad-pqm/launchpad/production-devel', 'build'] [07:17] so its explicitly asking for an old rev [07:17] that... is seriously weird [07:17] which is the nuts. [07:18] spm: can you take it on, and hand it off to someone else when you EOD? [07:18] we need a build of 9765 to do all three CPs [07:18] probably not. Tom's not around. I'll do what I can, but no promises. [07:18] and remove the thing, cowboy [07:18] I'll check in in ~ 4 hours I guess. [07:18] Oh I think I may know what did that. [07:19] So does everything explode if people push --overwrite a branch that is linked to builds etc.? [07:19] I used the 'restart with last failed build' juju in an attempt to encourge the pos to work. that'd do it. [07:20] builds forced, see if that grabs the latest [07:27] bbiab [08:47] good morning [08:49] Hey up everyone. [10:34] hello all [10:35] hello [10:37] lifeless, you broke prod_lp again :( [10:38] jml: no, buildbot failed [10:38] and failed again [10:38] and failed afte that [10:38] :( [10:38] and after that [10:38] so the changes, in production-devel, are still in production-devel and not in production-stable [10:41] you'd get less buildbot failures if you had less tests [10:42] jamesh: thanks for that. [11:11] night all [11:17] lifeless: wait! [11:17] darn too late probably. jml, prod_devel is failing still [11:17] can you help please? [11:17] bigjools, I can try. On the phone. [11:18] me too :) [11:18] /usr/bin/bzr checkout --revision 9762 bzr+ssh://bazaar.launchpad.net/~launchpad-pqm/launchpad/production-de [11:18] its grabbing the wrong rev [11:18] (you're lucky, I am looking up the phone number for tomorows meeting) [11:19] the branch is fine [11:19] BB is confused [11:19] dunno why [11:19] I see rev 9765 in prod-devel [11:19] ok, water, phone, phone # all set. [11:19] _> flip side [11:23] I'v queued another build [11:51] jml: what do you mean? [11:51] bigjools, I went to "Force build" and forced a build. [11:52] building [11:52] 1 pending [11:52] jml: ok - do you know if that's any different to what happened at 07:43? [11:52] the overnight build failed too, and then someone kicked it off at that time [11:52] I don't have much hope that it'll work this time :/ [11:52] bigjools, no, I don't. but I'm going to try it in lieu of having a better idea. [11:53] ok [11:53] I've got a rather urgent CP to get out :( [12:04] bigjools, ok. I'm off the phone. You have my full attention. [12:04] jml: not much we can do until the current run finishes [12:04] we can see if the next one checks out the right revno [12:05] if not, then I'm getting on the batphone [12:05] I wonder where it gets the revno from [12:06] why does it even need to know [12:07] bigjools, I'm guessing something about race conditions. [12:07] bigjools, or perhaps some secondary approval step from the losas? [12:09] good grief. every thing is failing for different reasons. [12:09] ew, it takes 45 minutes from buildbot instantiation until it actually starts running tests [12:10] yes. [12:15] Morning, all. [12:15] hi deryck === mrevell is now known as mrevell-lunch [12:28] jml: it got the right revno this time [12:28] only 4 hours to wait now... :/ === al-maisan is now known as almaisan-away === matsubara-afk is now known as matsubara [13:20] bigjools, yeah I see it :) [13:23] Launchpad's misrepresentation of partner makes me sad :( [13:23] And makes RMS FUD harder to debate. === mrevell-lunch is now known as mrevell [13:25] wgrant, which aspect in particular [13:25] jml: It says that Skype and Flash are in Ubuntu. [13:25] Which makes it difficult to tell RMS that he's wrong when he says they are :P [13:26] oh, everything is difficult with RMS anyway... :) [13:26] It is... [13:28] wgrant, I can see why that would be frustrating. [13:29] wgrant, otoh, I'm increasingly of the opinion that we should focus our efforts toward helping the people who are using Launchpad to try to get things done. [13:29] Probably, yes. === almaisan-away is now known as al-maisan [14:25] * gmb -> breaking to escape brain-stall. [14:36] gmb, when you're back, could you look at bug 638284? [14:36] <_mup_> Bug #638284: Launchpad's Remote Tracker does not honor Debian Bug Tracker status changes [14:37] I believe this is the debbugs sync disabled due to disk space issue, but would like you to confirm. [14:57] deryck, You're right. [14:58] deryck, Perhaps we should use that bug as a way of keeping users up-to-date with the problem. Thoughts? [14:58] gmb, yes, definitely. If we don't already have a bug about it, then let's use that one. [14:58] deryck, I just looked and don't see one. I think that's mostly because we've been fielding Questions, IRC pings and emails about it but no bugs until now. [14:59] And I know that the LOSAs have an RT for the problem. [15:00] gmb, ok, cool. Do you mind updating the bug and doing this? [15:01] deryck, Done. [15:01] abentley, adeuring, bac, danilo, sinzui, deryck, EdwinGrubbs, flacoste, gary, gmb, henninge, jelmer, jtv, bigjools, leonard, mars, noodles775: reviewer meeting starting [15:01] awesome! [15:06] sinzui, where's the list of bugs remaining for the bridging-the-gap work that registry is finishing off? [15:07] https://bugs.edge.launchpad.net/launchpad-registry/+bugs?field.tag=bridging-the-gap [15:10] sinzui, cunning. thanks. [15:11] sinzui, is there a bug filed for the bad tooltip text for the branch configuration link? [15:11] yes, your incomplete one [15:12] jml, I cannot reproduce it. The description of what is in play (rendering engine + os) make it unlikely to be an issue with our code [15:12] sinzui, I don't mean the corruption thing, I mean the fact that the text says "Set branch for this series" [15:13] oh, sorry [15:13] let me look. [15:14] * jml is sorely tempted to move LEP mgmt to blueprints. [15:15] I think that's a good idea [15:16] it would give a needed thrust to improving blueprints [15:16] jml, I tried that earlier this year, there is still a lot of blueprint update by hand because the statuses are more than any project needs and notifications are broken [15:16] You cannot use feedback requests for example...you still need to send the feedback request yourself [15:17] jml, and then we should merge blueprints and bugs. ;) [15:17] deryck, *yes* [15:17] jml: I do not see a bug for the tooltip. The bug is in an Involvement Menu subclass and is trivial [15:17] deryck, and answers. [15:17] sinzui, ok. I'll file it anyway, if you don't mind. [15:18] sinzui, woah there. Not sure I'm feeling that one. ;) :) [15:18] please do, my team are asking for some easy work since the app UI is very hard [15:18] deryck, sure you do, less timeouts converting a bug to question. [15:18] heh [15:19] well that is persuasive [15:19] No more bug-question links and more portlet to show it [15:19] I just think we want to work at moving the support requests out of bugs, not making it easier to misunderstand the two. [15:20] gmb or allenap, bug 5786 is no longer relevant, correct? NEEDSINFO is not referring to upstream status, but to an old bugtask state I take it? [15:20] <_mup_> Bug #5786: NeedsInfo should be moved into a separate bug or bugtask flag [15:21] deryck, I think so, yes. In which case it was superseded by Incomplete aeons ago. [15:22] right [15:28] sinzui, we talked about https://dev.launchpad.net/Registry/RegistryKarma a while back. What did we decide? [15:28] We will do nothing but continue to hope for a replacement for karma [15:29] sinzui, excellent. I'll make a note. [15:30] * sinzui has talked to 2 users this month to explain karma is not a measure of value or work [15:32] sinzui, what about this one? https://dev.launchpad.net/Registry/EssentialSourcePackageInformation [15:33] That is done! [15:35] sinzui, ooh. I'll review then. [15:36] sinzui, the LEP says that https://edge.launchpad.net/ubuntu/+source/wsjt should have a link to copyright information. I can't see a link like that. [15:37] jml, that page should not, the series source package does...they change by series [15:38] jml: the SP descriptions will be used in the derivative distros diff page. the copyright is being used in register an upstream project [15:40] sinzui, sweet! [15:41] adeuring, hi. I'm linking your current kanban board card against bug 633698. This bug is good for this issue you're seeing? [15:41] <_mup_> Bug #633698: missing API oops reports? [15:42] * sinzui wonders if it is appropriate to quote his mistypes: "The involvement [15:42] portlet is controlled by the pillar owners and its links are enabled to [15:42] attack contributors to the applications the pillar uses." [15:42] deryck: sure [15:42] I think I meant to type attract, but maybe subconsciously i did mean attack [15:43] heh heh [15:43] A little more clearly described now: bug 633698 [15:43] <_mup_> Bug #633698: Librarian errors missing API oops reports [15:45] It seems people are either ignoring results suggested by dupe finder or it's become less useful with the recent preformance work. [15:54] bigjools, are package dependencies available over the API? [15:55] jml: do you mean as properties of source packages? [15:55] bigjools, Yes. [15:55] jml: no, we don't export those [15:55] bigjools, I mean, if they're available in another way that would be interesting too. [15:55] bigjools, any reason or just round tuits? [15:56] jml: we don't export source packages at all, just their publications. [15:56] deryck, I think it has become less useful. [15:56] deryck: I hardly ever see people paying attention to it [15:57] deryck, but a third hypothesis is more bugs filed via email. [15:57] bigjools, is there a reason for that? [15:57] jml: yes, what is a source package's URL? [15:57] bigjools, https://launchpad.net/ubuntu/+source/packagename [15:57] jml: wrong! that's a distrosourcepackage [15:58] yeah, I can tell the difference in bugs filed via email and against the project group. I'm seeing it more commonly filed straight against malone, too. [15:58] bigjools, ubuntu/lucid/+source/packagename [15:58] bigjools, jml, I want to toss a small grenade into your conversation. I do not think the DSP/SP pages and API is very good. Our pages have poor rank in Google. packages.ubuntu.com always wins. When a user is searching the Google package information, they are going to the other site, then following that link to Lp :( [15:58] sinzui, interesting. [15:58] jml: unfortunately wrong again. We need a way to put a sourcepackagerelease in its own URL. But I don't think that's useful at all though. [15:59] bear in mind that dependencies can change between versions [15:59] bigjools, something is using the word incorrectly here. [15:59] bigjools, https://edge.launchpad.net/ubuntu/maverick/+source/wsjt perhaps [15:59] this is why I added a bunch of source-related properties to publications [15:59] bigjools, since it does say "source package" [16:00] yes, but it's not a source package release [16:00] it's a source package in ubuntu maverick [16:00] oh, you didn't ask for a URL for that :) [16:00] * bigjools rolls eyes [16:00] jml: bigjoolsI do not have any immediate ideas, I think this conversation is registry related too. SPR is a specific detail that users often do not care about, they want the current info for their distros or series. I think we need to re-ask who uses this information and what pages do we provide for them [16:00] ok ok :) [16:01] bigjools, my use case here is wanting to get build dependencies so I can start working on a branch. [16:01] sinzui: I think probably both are valid, which is another reason why I prefer adding more properties to publishing records [16:01] because traversing to those from the SPR or the DSP is trivial [16:02] bigjools, so I need to be able to get from the branch's project to some kind of package record, and from there to the dependencies [16:02] bigjools, is this currently possible over the API? [16:02] jml: it's not :( [16:02] I think users arrive at an SPR too early. Searching a series takes me to the SPR. If I bookmark that page, It could be wrong in 24 hours [16:03] sinzui: we don't have a page for an SPR [16:03] bigjools, what would we need to do to make it possible? === deryck is now known as deryck[lunch] [16:03] bigjools, True [16:03] jml: are you looking for a package in a distroseries in this project? [16:03] (I don't really care about the web ui for this, fwiw, although I do acknowledge that it's interesting) [16:03] or a particular version? or something else? [16:03] bigjools, I guess I don't care & am looking for the latest in Ubuntu, since that's likeliest to be close to trunk [16:04] ok [16:04] jml: are you looking at build dependencies or installation dependencies? [16:04] bigjools, both. but for this use case, let's focus on build. [16:04] then I'd do this: [16:04] add the build deps as a method on sourcepackagepublishinghistory [16:05] then use distrosourcepackage.currentrelease or similar to get the publication [16:05] but you need to export all that on the API [16:06] bigjools, are DSP and SPPH already exported? [16:06] actually, scratch that latter, use distribution.getCurrentSourceReleases() [16:06] which takes a string package name [16:06] SPPH is exported [16:06] distro is exported [16:07] OK, so it's just a simple matter of programming then. [16:07] yep, hopefully [16:09] bigjools, thanks [16:09] jml: oh actually, feh, getCurrentSourceReleases() returns DSPs which are not exported. You should use IArchive.getPublishedSources [16:09] which returns SPPHs [16:09] bigjools, ah. fair enough. [16:10] getting the archive is trivial [16:10] distro.main_archive for example [16:10] bigjools, from time to time the thought occurs to me, perhaps soyuz's apis could be simpler. [16:10] jml: hellyes. however, we're constrained by the decision to expose the internal model [16:11] but if you have any ideas on how to make it better, I am all ears [16:11] by "api" I meant internal model, actually. [16:11] no ideas right now :) [16:11] I'll let you know if any come up :) [16:11] jml: I get frustrated with the model too. [16:11] do you remember my presentation at the original epic? [16:11] and the db diagram? [16:13] bigjools, yeah, I do. [16:14] jml: recipe builds made that twice as bad :) [16:22] danilos: ping [16:29] henninge, hi === benji is now known as benji-lunch [16:29] henninge, sorry, was otp [16:29] np [16:29] danilos: what is the meaning of the "from_upstream" attribute of a queue entry nowadays? [16:30] used to be "is_published" [16:30] henninge, ah, I think it needs to change (I know we changed it already)... it's not really from_upstream, I think it should be "from_package" [16:31] henninge, though, then again, we can keep it as from_upstream to indicate what side it's coming on [16:32] danilos: to determine if an import is from upstream, the potemplate can be queried for productseries/distroseries. [16:32] that would make from_upstream a computed attribute [16:32] henninge, except in sourcepackage uploads, which are from_upstream, basically [16:32] ??? [16:32] henninge, well, translations we import on ubuntu from source packages are upstream translations [16:33] henninge, they are just from tarballs instead of from a VCS [16:33] danilos: I am not sure I understand === benji-lunch is now known as benji [16:33] danilos: will they be imported into upstream templates or ubuntu templates? [16:34] henninge, uhm, with the new model, into both [16:34] henninge, but they will be considered is_current_upstream [16:34] danilos: ah! [16:35] danilos: so this is another parameter to the "share with other side" policy [16:35] henninge, well, kind of... the good end result will depend on that policy being right :) [16:35] danilos: "If the import is for a sourcepacakge but is marked as 'from_upstream', share it with upstream" [16:36] henninge, no, "if import is for a sourcepackage but marked as 'from_upstream', consider it an 'upstream' translation" [16:36] but that is more difficult for the importer [16:36] henninge, then, a policy of "if there's an upstream translation and it's better than ubuntu one, use that one for ubuntu as well" will give us the same result we get today [16:37] henninge, how come? it just means go through the same code path as if it's an import for a productseries [16:37] yes but it needs to determine the productseries first. [16:37] from the sourcepackage [16:37] code duplication [16:39] henninge, it should be possible to avoid it by calling setCurrentTranslation(upstream=True) directly [16:39] danilos: My take: when sharing translations with the other side it does not matter on which side the translations are imported [16:40] hm, maybe this is about template creation. [16:40] henninge, well, I think we just need to call setCurrentTranslation with appropriate parameters, we don't need to know the exact template [16:40] henninge, because we've got potmsgset already [16:41] on template import? not necessarily [16:41] henninge, I mean, we've got it on "ubuntu" side, we don't need it on the upstream side as well [16:42] henninge, by "got", I mean "just created or existing" [16:42] henninge, we should not import templates from sourcepackages as "upstream" [16:43] bigjools, the stakeholder board says "generalized build histories" is done. is that accurate? [16:43] henninge, basically, what will happen is that we'll internally have potmsgsets with upstream translations, but there may not even be any upstream templates in LP [16:43] jml: yup [16:43] yes, I am beginning to see that [16:43] bigjools, cool! I'll review the LEP for sign-off & get back to you. [16:44] jml: we're just waiting on jtv to finish off his work on actually using it, and then we can go on a made delete-fest of all the old code [16:44] s/made/mad/ [16:44] recipes already use it [16:45] bigjools, yay deleting code [16:45] it's a good feeling :) [16:47] bigjools, most of what we could do so far was in ec2 this morning ;) [16:48] \o/ [16:48] "could do"? [16:49] jml, if I understood it correctly, some bits need to be moved to using the new model fully (we were blocking that), and we didn't do any of that [16:50] danilos, ahh ok. [16:51] I have a mild mistrust of anything that claims to be generalized and is only used for one type of thing. [16:53] jml, +1. === benji is now known as benji-lunch === deryck[lunch] is now known as deryck [17:07] Does anyone know how to configure zope to treat the return value of itertools.groupby() the same way it treats generators? [17:10] abentley, I don't follow. Doesn't itertools.groupby() return an iterator? [17:11] jml, yes it does, but the security proxy doesn't treat iterators the way it treats generators. [17:11] abentley, I'm surprised, and also desire to be crystal clear on terminology. [17:12] abentley, generator here means... ? [17:12] jml, so if I return itertools.groupby(), I get a security proxy violation on __iter__. If I return (x for x in itertools.groupby), everything is good. [17:12] buggeration. [17:13] * jml checks a thing [17:13] jml, generators are iterators produced by functions with yield statements or generator expressions. [17:14] iterators is a superset including generators as well as hand-crafted iterator classes. itertools.groupby appears to return the latter. [17:14] abentley, ok. I think I see what's going on. [17:14] abentley, groupby returns an object that implements the iterator protocol === al-maisan is now known as almaisan-away [17:15] jml, correct. [17:15] abentley, I'm guessing that Zope's handling for __iter__ and what-not is done in a type-based fashion. [17:15] abentley, and that the highly specific type returned by itertools.groupby() is not included in the list of types for which zope makes this exception. [17:15] jml, me too. I suppose they may have associated interfaces with the built-in types, though. [17:16] abentley, that's my guess [17:16] except they've missed the built-in type called itertools.groupby [17:16] I guess now it's time to explore zope.security [17:17] jml, well, I was hoping someone would know off the top of their head. But I don't see gary here today. === salgado is now known as salgado-lunch [17:25] abentley, something in zope.security.checkers._defaultCheckers [17:26] working up from there [17:27] abentley, z.s.checkers.defineChecker(itertools.groupby, z.s.checkers.NamesChecker(['next', '__iter__'])) might do the trick [17:28] not sure how to do that in zcml [17:28] jml, thanks, I'll give that a shot. === Ursinha is now known as Ursinha-lunch === matsubara is now known as matsubara-lunch [17:50] abentley, I've just done a pass over the SPRB LEP and kicked it into "In progress" [17:51] jml, does that reflect drafting or implementation? [17:51] abentley, implementation [17:52] abentley, I'm happy with the LEP if you are. [17:52] I haven't looked over the UI stuff. [17:53] jml, I think it's okay. What do you mean by Allow users to use James Westby's imports to provide the debian directory *without the user leaving the web UI* [17:54] abentley, you noticed. I mean that if the way to use the lp:ubuntu/foo imports involves switching to a terminal and making a new branch or something similar, then that's not really acceptable [17:55] jml, I am surprised by the idea that using the lp:ubuntu/foo imports might involve switching to a terminal and making a new branch or something similar. [17:55] jml, Wouldn't that defeat the purpose of using recipes? [17:56] abentley, pretty much :) perhaps the qualifier is redundant. [17:56] jml, to me it suggests perhaps you want it to automatically recommend a packaging branch or something. [17:57] jml, so that the user doesn't have to leave the recipe creation page to search for the correct branch. [17:57] oh, I see. [17:57] well that would be nice but certainly not critical. [17:59] jml, what makes mark a stakeholder? [18:00] abentley, this is something he cares about a great deal. it's largely his vision. [18:01] jml, does "Promptly provide full information on failed builds to someone capable of debugging the failure" mean it must spam me? Or the packaging author? Or the build requester? === benji-lunch is now known as benji [18:02] jml, "Builds are performed in a timely manner" is something that the build farm does not guarantee for any builds. Why do we have this special burden? [18:02] abentley, re timely [18:03] abentley, it's something that is necessary for me to consider the feature complete. it doesn't mean at all that you will be obliged to do the work to make it so. [18:04] abentley, indeed, that work is already been done by team soyuz. [18:04] jml, it seems like a big scope creep to me. [18:04] abentley, not to me. [18:04] abentley, it's always been _daily_ builds [18:05] james_w, how do you usually run the bzr-builder tests? [18:05] rockstar: bzr selftest -s bp.builder [18:05] jml, It has not been done. In fact, I was supposed to work on a new build farm, and AIUI that task is now on hold. [18:05] abentley, sorry, I meant "being" [18:05] james_w, ah, didn't know about -s [18:07] jml, I'm not aware of any Soyuz plans to change the basic scheduling algorithms, but until that's done, we'll have the potential for build starvation. [18:07] it's an extremely hard problem to solve, but I've not forgotten it [18:07] abentley, so we'll have to solve it then. [18:08] * jml seizes this opportunity to order a book on queuing theory [18:08] bigjools, but until someone solves it, jml won't consider the daily builds LEP complete. [18:08] that's crazy [18:09] bigjools, what can I say, I'm loco. [18:09] recipe builds are now scored the same as PPA jobs, they won't starve [18:10] bigjools, if we lose some of our loaded builders and a bunch of higher-scored builds get created, they can. [18:10] (£80 is not the price of a book!) [18:10] s/loaded/loaned [18:11] abentley: in theory yes, but there's only one thing that generates higher-scored builds and they are not frequent, so in practice it does not happen [18:12] bigjools, aren't there a bunch of modifiers that can push up the score? Even a bunch of builds with a 2010 score can starve the daily builds. [18:13] Or was that 2510? [18:15] abentley, wrt "provide information on failed builds", out of those, I mean the build requester [18:16] abentley, errors in the system are already (I hope!) handle by OOPSes [18:16] handle*d* [18:17] abentley, or the recipe author, I guess... [18:17] jml, I believe the build requester is required to be a member of the recipe author. [18:18] abentley, that's good. even so, maybe the broader group is more appropriate. I don't know right now. [18:18] jml, we don't distinguish between errors in the build that are system errors vs user errors. [18:19] jml, rather like code imports. [18:19] abentley, by design? [18:20] jml, kinda. Our builds are just like other builds in this regard. [18:20] it seems that, for example, any exception that is raised outside of slave is guaranteed to not be a user error. [18:20] jml, sure. [18:20] * jml is having a bad day with grammar. [18:20] jml, that's why I said errors in the build. === Ursinha-lunch is now known as Ursinha [18:21] abentley, what happens with errors in the build now? [18:21] Once the build is completed and the slave is no longer responsible, errors can be handled as user errors or oopses. [18:22] jml, we send an email to the user who requested the build. [18:22] abentley, so how do we learn of failures in the system? [18:23] jml, like with code imports, we rely on users to escalate system errors as bugs. [18:23] I could have sworn we had oopses for code imports. [18:24] jml, maybe we do. === salgado-lunch is now known as salgado [18:25] abentley, ok. [18:26] abentley, in any case, I'll leave banging on about architectural transparency to lifeless. I mostly care that users who have a build that screws up find out about it and are given enough data to try to fix it. [18:26] jml, anyhow, how can we in principle know whether an error is due to user error or system error? [18:26] abentley, with the puller we have some heuristics. but that approach is probably not relevant here. [18:29] jml, can I substitute "the person who requested the build" for "someone capable of debugging the failure"? [18:31] abentley, sure. [18:34] jml, I'm also adding "Renaming branches does not break recipes" under "nice to have". [18:34] abentley, good call. [18:34] abentley, Launchpad more broadly needs to get its act together wrt renaming stuff. [18:35] jml, (we kind of assumed that was important, so branches are stored as DB ids) [18:36] jml, the relevant iterator from my zope security question is itertools._grouper, and it comes from a C module and is not exposed. [18:37] you mean type(itertools.groupby([1, 2, 3]).__iter__()) == itertools._grouper? [18:39] abentley, any more questions about the LEP? [18:39] jam, I mean type(list(itertools.groupby([1, 2, 3]).__iter__())[0][1]) == itertools._grouper [18:39] ahhh. [18:40] abentley: I think you mean jml :) [18:40] jml, should there be any requirements about bzr branch format support? [18:40] Python sucks. [18:40] jam, sorry. [18:40] np, I just showed up [18:40] abentley, I don't care about anything that's not 2a. [18:40] abentley, is that what you mean? [18:40] jml, many of our supported distros don't support 2a. [18:41] abentley, why does that matter? [18:42] abentley, because the people using those distros won't be able to push up compliant branches? or because we run the bzr-builder recipe in an image based on the distro it's targeted for? [18:42] jml, do we want to be able to build bzr recipes for old distros if said distros don't support 2a but the relevant branches are in 2a? [18:42] abentley, yes, I think so. [18:43] jml, our initial implementation did not support that, so it's easy to imagine that an implementation would not support that unless we make it a requirement. [18:44] abentley, for sure. [18:44] "branch formats usable within recipes is independent of branch formats supported by target distro" or something. [18:46] jml, didn't see you writing. I put "Allow recipes to be built from bzr 2a-format branches for any supported distorseries (whether or not the distroseries itself supports 2a). " === matsubara-lunch is now known as matsubara [18:46] fair enough [18:47] abentley, if bzr gets another format between now and the LEP being finished we can adjust accordingly :) [18:47] jml, if you keep the timeliness requirement, it probably will :-P [18:47] hah [18:49] jml, anyhow, aside from the timeliness requirement, I'm happy with the LEP as it stands. [18:50] abentley, cool. [18:51] moin [18:52] jml, do we have a graph of how long it takes SRPBs to get dispatched? I know we have one for build queue size. [18:52] ah, lifeless is around. Must be lunchtime. [18:52] abentley, I don't know. I don't think so. [18:53] jml, could you set that up, or should I ask thumperfrancis? [18:53] abentley, ask flumper. [18:53] abentley, I just recalled a use case that isn't very well documented [18:54] abentley, one big use case for recipes is having a daily build of trunk without debian/ubuntu patches. [18:54] or with as few as possible. [18:55] abentley, I'm not sure how this translates into requirements. [18:55] jml, I don't know, either, because some patches may be necessary to build at all. [18:56] One could perhaps fork the packaging branch, remove unwanted changes. [18:57] abentley, or make a completely new packaging branch [18:57] Then either use that in the recipe, or use the recipe to merge the packaging branch. [18:57] abentley, and express the ubuntu one as a recipe on top of that. [18:57] jml, you can also use nest-part to exclude changes outside the debian directory. [18:58] mars, ping [18:58] abentley, the difference between the "pure" packaging and the ubuntu packaging is primarily of interest for testing upstream code. [18:58] jml, but of course, some patches will be provided within the debian directory. [18:59] jml, it also provides a vector for upstreams who feel that ubuntu's changes are unwelcome to get a pristine version to their users. [19:00] abentley, hello. [19:00] jml, hi. [19:00] abentley, sorry, mischan [19:01] abentley, yes. that's also a good case. [19:02] abentley, perhaps this means that we should have some kind of special marking for "pure" packaging... [19:02] something to chew on. [19:02] * jml otp [19:02] If you look at bzr, the ubuntu version removes configobj from the tree and depends on its package instead. [19:03] a "pristine" bzr would have configobj in the tree, and would therefore have an unnecessary dependency. [19:03] Unless you change the bzr packaging manually. [19:09] deryck: can we have a brief call after this ? [19:10] lifeless, I have a call with thumper after this, but depending on how long it lasts, after that would be fine. [19:11] Does the LP schema allow a project to be in more than one project group... I know the UI doesn't allow it... but is it possible? [19:12] deryck: great [19:12] jkakar: iirc no there is a unique constraint [19:13] lifeless: Cool, thanks. It wonder if enough people would benefit from projects being able to be in more than one group to make it worth changing. [19:13] jkakar: I want to eliminate pgs as a special case [19:14] use multiple tagging/categorising systems [19:14] e.g. tags to to bottom up associations [19:14] lifeless: That sounds cool. [19:14] and 'defined groups' to do top down defined structures [19:14] lifeless: What I want is a way to group projects such that I can have a +activereviews page that shows me reviews for the group. [19:14] and permit both to exist [19:14] lifeless: Also, to see bugs in the group. [19:15] lifeless: Also, to create milestones for the group. [19:15] So I guess I want the group to be identical to a project, but with less arbitrary limits on how I can form them. :) [19:15] yes [19:15] I would like the same too, in the fullness of time. [19:15] lifeless: Cool! [19:42] * jml gone [19:43] sinzui, do you think a wiki page would be a better way than the ML to track Maverick upgrade issues? [19:43] sinzui: hi https://bugs.edge.launchpad.net/launchpad-registry/+bug/638924 [19:43] <_mup_> Bug #638924: Milestone:+index timeouts with many announcements [19:44] sinzui: I've just dug a bit deeper into that timeout [19:44] sinzui: I drew some different conclusions about the issue, and thought perhaps you'd like to spend a little time later discussing it [19:47] lifeless, I would like to discuss it. I have two more meetings today, but I am free this evening and tomorrow [19:47] sinzui: ping me anytime [19:47] fab [19:47] sinzui: I'd like to get some hints out there for doing the analysis stuff [19:48] Ursinha: https://devpad.canonical.com/~lpqateam/qa_reports/launchpad-stable-deployment.txt seems to have not updated ? [19:49] Ursinha: also, as that rev *is* deployed, I think you're pointing it at the wrong branch ? [19:50] lifeless, wait, I'm checking [19:50] (its meant to start at the deployed rev, not randomly far back) [19:50] it seems it was updated few minutes ago [19:50] lifeless, Ursinha, the ctime on those reports says they are only 3 minutes old [19:50] so, there is a bug then [19:50] bug 11518 [19:50] <_mup_> Bug #11518: Linux kernel-image-2.6.9-1-686 synaptic pass through problem hoary [19:50] bah [19:50] rev 11518 has bug 627741 [19:50] <_mup_> Bug #627741: oops-prune is aborting with a regex mismatch(?) [19:50] thats qa-untestable [19:51] thats one issue [19:51] the second issue is that that rev is *already deployed* [19:51] it should be starting much higher up [19:51] what branches are you giving it ? [19:57] lifeless, it seems last deployed revision on lpnet was 11515 [19:58] script starts processing at 11516 [19:58] hang on though [19:58] which is correct [19:58] 'stable' is deployed to edge [19:58] now for the other problem [19:58] db-stable is deployed to lpnet [19:58] actually thats a convenient lie but its good enough for now. [19:59] (because we need something to measure which db commits can be deployed) [19:59] Ursinha: what branches is it running with please ? [20:02] lifeless, stable and db-stable [20:02] Ursinha: it takes branch pairs IIRC [20:02] Ursinha: source and target [20:02] MergeDeployment is lpnet [20:03] devel, stable and db-devel, db-stable [20:03] lifeless, merge environment for both stable and db-stable is lpnet [20:03] so it looks lpnet for the last merged branch [20:03] ok, that will make sense once we remove edge [20:04] for now though, the devel/stable one needs to check against 'stable' [20:05] Ursinha: ah yes, I see [20:05] lifeless, let me see if I got the picture: people land code on devel/db-devel, and it goes do edge/staging, they QA it, and it supposedly should go live on lpnet [20:05] right? [20:05] and I didn't provide a knob for this. [20:05] ignore db- for this discussion [20:06] Ursinha: actually, what I'll do is ask for a CP of everything. [20:06] that will sort this out. [20:06] not sure what you mean [20:07] but it would be nice to know that everything currently in stable has been QA'd, to pick a rev to CP [20:07] Ursinha: well a CP is a merge to production-devel [20:07] lifeless, I thought this was exactly how the script is working now [20:08] ahh,, and I'll be able to do that if we figure out this other isue. [20:08] what's on stable is what should be QAed [20:08] Ursinha: ok, yes, I'm being noddy. [20:08] Ursinha: so lets talk about the other thing :) [sorry!] [20:08] hehe [20:08] I'm investigating the bug thing [20:08] ok === almaisan-away is now known as al-maisan [20:17] rockstar, I have a reply on the way to you, but I need to answer a question about the JS build system first [20:21] mars, great, thanks. [20:21] mars, I'd like to deal with this today, as it means that I have a kanban card that's just sitting. [20:21] lifeless, ok, so that was a stupid thing: qa-needstesting wasn't considered a deployable status, only qa-ok [20:21] * Ursinha goes add tests [20:22] Ursinha: qa-untestable do you mean ? [20:22] lifeless, argh, yes, sorry [20:22] qa-needstesting isn't deployable ;) [20:22] lifeless, qa-untestable [20:22] lifeless, https://devpad.canonical.com/~lpqateam/qa_reports/launchpad-stable-deployment.txt [20:22] it didn't go too far though [20:23] thats ok [20:23] we can look into that in a minute [20:31] ARGH! Stabby stabby moin! [20:47] thumper, when you're around, I'd like to chat about merge queues. === al-maisan is now known as almaisan-away [21:04] Later on, everyone.... [21:04] rockstar: we hsould just use em. [21:05] if bugs turn up, we can fix. [21:05] lifeless, :) [21:05] lifeless, there are some things about the current model that I think complicated things greatly. [21:05] rockstar, understook [21:05] understood even [21:05] rockstar: not disagreeing [21:05] rockstar: but its inventory today. [21:05] mars, wtf keyboard layout are you using that had d and k right to them? :) [21:06] lifeless, yeah, inventory that I want to throw out on the streets! :) [21:11] lifeless, you will see, though, that we have a whole lane in kanban for finishing up merge queues now. [21:13] rockstar: ping about bug #612754 [21:13] <_mup_> Bug #612754: Submit Request Failure: Signature couldn't be verified: (7, 8, u'Bad signature') - with email signed and sent from sup-mail [21:13] It is blocking me pretty much on every submission [21:13] rockstar: a lane? wouldn't it just fit under features? [21:13] rockstar: anyhow, details aside... [21:14] rockstar: I saw your update; why one queue per project? isn't one queue per series easier conceptually? [21:22] * benji goes afk for a bit. [21:29] lifeless, one queue per branch, but many branches can be in one queue. [21:29] lifeless, we can't just draw the line at series or anything. Think about all the branches currently managed by ~launchpad-pqm [21:29] jam, EVERY submission? [21:31] rockstar: any time I send a "merge: approve" [21:31] and a lot of bug reports, too, I believe [21:32] jam, yeah, it would use the same mechanism. I think might fall under "foundations" domain, but not sure. [21:32] jam, could you try with a different mail client? [21:32] I can obviously go to the website, but the email interface is broken for me [21:32] jam: which email client? [21:32] jam, mathiaz was having intermittent problems, so I was suspecting that it was a mail client issue. [21:32] rockstar: I don't have another mail client integrated with gpg. But even so, I can check the raw texts pass, and I had Vincent do the same thing for me [21:33] rockstar: I'm nomming [21:33] rockstar: and I'd like to grab abentley first [21:33] thumper: thunderbird 3 w/ enigmail [21:33] jam, is Vincent using the same client? [21:33] rockstar: vincent uses gnus, or whatever the emacs client is [21:33] thumper, we have our 1-1 today, right? [21:33] jam, *sigh* [21:33] thumper, certainly. [21:33] rockstar: I guess [21:33] rockstar: you should be able to just try "gpg --verify submit_request_failure.txt" that I attached to the email [21:34] jam, okay. [21:36] rockstar: I just sent another email (which I expect to be blocked). I suppose I can CC/BCC you one of them? [21:36] jam, absolutely. [21:37] (I just BCC'd you on an artificial one, though I think that request is actually bogus, as you can't set WIP from email) [21:37] but it should still gpg verify [21:38] jam, so I've verified that your message was good. [21:41] rockstar: sure, s/series/target branch/ [21:41] rockstar: what I mean is that we wouldn't want db-devel and devel to both use the same queue - they would starve each other [21:42] rockstar: well, at least you and I agree. Now if we can just get LP to feel the same :) [21:42] rockstar: I haven't see the messages show up on 'review' but I also haven't gotten the "Submit Request Failure" yet. [21:48] lifeless, I disagree that they'd starve eachother. We're essentially doing the same thing now with pqm. [21:49] rockstar: pqm isn't running the tests [21:49] rockstar: and pqm did starve each other [21:49] rockstar: huge issues with that [21:49] lifeless, tarmac, in this case, wouldn't run the tests either. [21:50] rockstar: we want to make the lander run the tests again [21:50] rockstar: thats gary's experiment, landing in batches of 5 [21:50] lifeless, and we can do something like that. But at that point, we'd have to separate out what branches are on what queue. [22:07] is it just me [22:07] or is [22:07] FAILURE: lp.services.job.tests.test_runner.TestJobRunner.test_oops_messages_used_when_handling (subunit.RemotedTestCase) [22:07] failing for every branch ? [22:08] on ec2 [22:10] I had an error like that as well [22:10] I figured since the error in the oops was soyuz related it was somehow my fault [22:11] lifeless: i got the same error too when trying to land a branch [22:12] ok [22:13] its probably not unrelated to my oops work [22:14] running just that test works [22:14] don't you hate it when that happens :-( [22:15] so either oops-writing is naffed [22:15] or get last oops is [22:17] mars: still here? [22:18] thumper: rockstar: abentley: skype? [22:18] wallyworld_, sure. [22:18] rockstar, wallyworld_: abentley and I are chatting [22:18] give us a few minutes to finish what we are talking about plz [22:19] thumper: np [22:19] morning [22:19] * jelmer waves [22:21] I'm looking in uniquefileallocator if folk are interested [22:22] lifeless, yep [22:22] lifeless, what's up? [22:22] mars: how clean is the oops dir in an ec2 test run [22:22] mars: see the list for the context [22:23] lifeless, no idea. someone could run with ec2 test with --postmortem and find out though. [22:28] we really should change the filenames on disk to be less magical [22:39] and for fun [22:39] running the two relevant tests together, here, works. [22:40] :!bin/test -vvt test_uploadprocessor.TestUploadProcessor.testOopsCreation -t lp.services.job.tests.test_runner.TestJobRunner.test_oops_messages_used_when_handling [22:41] mars: a premortem for ec2 would be nice [22:41] mars: e.g. set it all up, but run nothing [22:43] you can do it with "-d" and some stepping [22:43] I thought jml had implemented --dont-test or something [22:43] jelmer: any idea why https://code.edge.launchpad.net/~vcs-imports/mesa/master is failing? === matsubara is now known as matsubara-afk [22:48] hah, I just noticed my lp vm is in sydney time.. that explains some confusion I had [22:49] thumper: looking [22:49] lifeless, jml was implementing that option. Otherwise you can do it with "ec2 test -p -o '-t asdf'" [22:50] this really has me flummoxed [22:50] thumper: Looking at the history, it seems the branch was reimported from scratch recently? [22:50] jelmer: yes, yesterday [22:50] i have tried deleting some oopses [22:50] and it correctly ignores the holes and writes to the end and finds them again [22:51] thumper: So I guess this can't really be a bzr-git bug that caused incorrect repo data.. I'll try locally & file a bzr-git bug. [22:51] thumper: From just looking at the logs I don't really have an idea what could be going wrong. === Ursinha is now known as Ursinha-afk [23:17] I've put a branch up that may help [23:42] lifeless: so, about sending output from process-mail.py to a log file [23:43] theres an option to do that already apparently [23:43] --log-file or something [23:43] mm, apparently it's not used [23:43] should just need an RT (and for someone to be monitoring the log) [23:43] they just manually redirect it in the cron script [23:43] yeah [23:44] i did look at it a few weeks ago and ISTR that --log-file may be broken or something [23:44] imbw [23:44] but i think i said "how does it even work?" and spm said they don't use it :/ [23:44] its a thing that was built and not deployed [23:44] we should use it [23:45] also, as i recall, someone said "we can't just send it to a file because we need to know about errors" [23:45] maybe this was you? [23:45] we do need a story around that [23:45] but i don't see how sending it to a file is much worse [23:45] ideally --log-file would not hide ERROR severity messages [23:45] if you wanted to pull on this yak I think that would be great. [23:46] 'i am in yaks stepped in so far that should i wade no more, returning were as tedious as to go over' [23:47] so i propose [23:47] - for now, just sending an rt asking them to send it to a file [23:47] if they object, we'll deal with that, but i don't see how it should make things any worse [23:48] - filing a bug about splitting >=error to stderr and everything to a file [23:48] (which will necessitate actually using --log-file not just >&file) [23:48] seems fine to me if you add in [23:48] and i may work on that one [23:48] - email lp-dev letting folk know that errors from it may not show in the -errors-report anymore [23:48] then using the results of #1 to work out what's up with dkim [23:49] so i can say the rt has your approval? [23:49] sure; cc me? [23:51] for the sake of parallelizing, is the errors mailbox anywhere i could see it? [23:52] lp-error-reports list should have it, yes [23:53] so i'd need to join that list, disable delivery, then look in the archives? [23:53] yeah, I think so. [23:54] some devops people would say that sending mail even in the case of errors is not the best idea [23:54] if things are falling over, mailservers may be swamped or unreliabel, etc [23:55] mmm [23:55] that applies to all automation [23:55] email is one of most robust systems we have : more robust that being able to ssh into the problem box. [23:56] it's a cheap but inefficient way to broadcast things [23:57] sure [23:57] we don't have better yet. [23:57] particularly for errors. [23:59] so is it reasonable to send everything, including errors, to a file for now? [23:59] can we do voice? I'm having deja vu and perhaps more bandwidth will address your questions quicker.