[00:00] poolie: as you say in your comment, your change will make tests less random. isn't that a bad thing? don't we want tests to pass with unpredictable input? [00:02] this is a bit philosophical [00:02] iamfuzz: O hai! [00:02] StevenK, o/ [00:02] i think you should test stuff intentionally, not count on randomness [00:02] tests that happen to run before this one will get one type of input and tests that happen to run after it will get a different prng [00:02] StevenK, thanks for the help btw. Trying to get this up to evaluate as the tool for our build farm here [00:02] it's hard to see how that's helpful [00:03] StevenK, easy peasy getting it running but can't import keys. It looks like I may have screwed something up irt the bazaar rewrite rule or something perhaps [00:03] * wgrant is scared now [00:04] StevenK, when attempting to import a key, it looks like it tries to hit this URL based on the logs: https://bazaar.launchpad.dev/pks/lookup?search=0xD69FC46438D3A33619E5577D39BE3335F26A3797&op=get [00:04] which if I hit directly, gives more the "Lost something?" 404 page with broken images [00:04] iamfuzz: Hmm, it should be keyserver.launchpad.dev, not bazaar.launchpad.dev. [00:04] Have you changed the configs at all? [00:05] however, hitting bazaar.launchpad.dev directly does properly redirect to launchpad.dev [00:05] poolie: isn't the whole point of using a rng to provide different input each time? [00:06] wgrant, the apache config, yes [00:06] iamfuzz: The Apache config shouldn't matter here. [00:06] wallyworld_: Are you still reviewing poolie's branch? [00:06] iamfuzz: The test keyserver doesn't go through apache [00:06] it's keyserver.launchpad.net:11371 [00:06] s/net/dev/ [00:07] wallyworld_, so, generally, my experience is that using a rng in tests is a bad idea [00:07] if there are some random values that catch a bug, which is possible [00:07] there are two problems [00:07] one is, the particular values are likely to come up only very rarely, so the bug may be latent for a long time [00:08] secondly, it will be hard to reproduce it, so perhaps hard to understand why it's failing [00:08] oh, and also, it may fail at inconvenient times [00:08] for example on buildbot but not ec2 etc [00:08] wgrant, https://keyserver.launchpad.dev:11371/pks/lookup?search=0xD69FC46438D3A33619E5577D39BE3335F26A3797&op=get just hangs on me [00:08] yep, timed out [00:08] iamfuzz: http, not https [00:08] ah there we go [00:09] much better [00:09] Error handling request: No keys found [00:09] StevenK: yes [00:09] wallyworld_, so this particular test is testing code that itself uses the rng, so i think it has a valid reason to touch it [00:09] but it should isoltae itself [00:09] wgrant, what is it attempting to parse for its pgp key info to not be finding any keys? or is there a utilities/ script I need to run? [00:10] iamfuzz: gpg --keyserver keyserver.launchpad.dev --send-keys SOMEKEYID [00:10] poolie: that all makes sense. thanks for explaining [00:10] iamfuzz: The dev keyserver doesn't know about any keys by default. [00:11] wgrant, ah doh, sorry bout that. I had assumed it would sync with the ubuntu keyserver [00:11] iamfuzz: No, that would take a looooooooooong time :) [00:11] point taken :-) [00:12] You can point your local LP at the Ubuntu keyserver, but that gets problematic when you want signing keys for your PPAs, as it will upload them to the real keyserver where they can never be deleted. [00:12] wgrant, worked like a charm, many thanks. Now I just have to get email working on here and should be golden [00:13] iamfuzz: Email from the webapp is generally redirected to root@localhost. [00:13] even better [00:13] Or you can grab the token with "SELECT * FROM logintoken" [00:13] Then https://launchpad.dev/token/SOMETOKENVALUE [00:14] If you are lazy and don't want to decrypt the email. [00:14] wgrant, I'm not *that* lazy ;-) [00:14] you guys have made it far easier than I expected [00:14] StevenK: r=me. you've put the egg in download-cache i'm sure? :-) [00:14] * iamfuzz crosses fingers soyuz works out as well :-) [00:15] wallyworld_: I have, and there are two branches [00:15] StevenK: already reviewed the other one :-) [00:15] iamfuzz: I spent the two days after the code was released working out and documenting how to make Soyuz work. https://dev.launchpad.net/Soyuz/HowToUseSoyuzLocally should be adequate. [00:16] Although I guess you've already seen that, if you have the keyserver running. [00:16] wallyworld_, should i put that on the mp maybe [00:18] poolie: i think that would be great [00:18] poolie: also so that the original branch author etc can see why the change was made [00:20] wallyworld_, thanks for asking [00:21] poolie: np. i was being a bit cautious just to make sure i didn't approve something that would fuck things up because i didn't appreciate the reason for the change [00:24] sure [00:24] i would like to make people appreciate randomness in tests is not a feature [00:25] poolie: of course, you don't always get to choose -- i remember a test failure that turned out to be assuming the email packages way of generating message ids was collision resistant [00:25] poolie: i don't think i've ever used a rng in any tests but made the mistake here of assuming that because it was used, a requirement was to have as much randomness as possible [00:26] but sadly it just uses second level timestamp + randint(100000) [00:26] wallyworld_: You do, by side effect [00:26] i guess if are a writing a comms protocol test or something like that you need one [00:27] * StevenK sighs at our Makefile [00:27] * wallyworld_ off to get some medicine from the doctor. back soon hopefully [00:27] * StevenK fixes rm to be $(RM) [00:32] StevenK: is there a particular reason for that? [00:32] jelmer: For which, sorry? [00:32] StevenK: $(RM), it surprised me too [00:33] the last project I encountered that substituted RM did it because of broken rm implementations [00:33] jelmer: It's cross-platform, which isn't really a concern for us, but I'm a pedant like that. [00:33] ah, ok [00:33] launchpad on windows ? :-) [00:33] Bwahaha [00:33] We need POSIX [00:34] Launchpad on OS X could be possible, which is a scary prospect [00:35] i've contemplated it, but funnily enough always found better things to do [00:35] The most difficult bit would be porting python-apt, I expect [00:36] The most adventurous thing I've done is running it on kfreebsd. [00:36] python-macports [00:36] I can see it now [00:36] mwhudson: Haha [00:37] i think jamesh said he did it once in the early days, or thought about it? [00:37] anyway, talking of better things to do --> lunch [00:51] wallyworld_, https://bugs.launchpad.net/launchpad/+bug/1734 is arguably fixed by hiding bug comments [00:51] <_mup_> Bug #1734: Bug discussion is append-only and cannot be gardened

< https://launchpad.net/bugs/1734 > [01:18] pht [01:19] wgrant, so what's next? [01:19] i guess i will get rid of the runtime master-client dependency [01:20] poolie: RIght, just remove that one import. [01:21] poolie: Replace it with the string, like the rest of the file uses already. [01:21] Then check that the appserver runs without python-lpbuildd installed, and reland. [01:21] k on it [01:23] Thanks. [01:33] poolie: that does look like it could be regarded as a dup of 885672 but when the branch lands, it's going to be quite limited to who we expose it to (at least initially) [01:33] there are bunch of not-quite dupes [01:33] it may be worth tearing them apart [01:34] I think it's pretty different. [01:34] This isn't for gardening. [01:34] This is for spam and emergencies. [01:34] Gardening is very different. [01:35] Ah, jelmer is still awake! [01:36] wgrant: sure, but the solution is the same even though the problem descriptions are different [01:36] wallyworld_: Is it? [01:36] wgrant: or StevenK: could you +1 this. it looks ok but i'm not confident that i understand the implications enough https://code.launchpad.net/~jelmer/launchpad-buildd/dpkg-buildpackage-sa/+merge/82623 [01:36] wallyworld_: I'm doing that right now. [01:36] ok thanks [01:37] wgrant: allowing the user to hide their own comments is a form or gardening i think [01:37] Ermmmmm [01:37] poolie: Why does ~launchpad-dev own lp:launchpad-buildd. [01:37] ? [01:37] * wgrant fixes. [01:38] wgrant: wow. [01:38] I wwas about to ask that. [01:38] (because of the MP requests coming on the m/l) [01:40] wgrant, oh was that the list? [01:40] the short answer is that trusted pickers aren't used everywhere [01:40] It's the list, yes. [01:40] Which is an open team. [01:40] https://dev.launchpad.net/CreatingNewProjects [01:40] sorry [01:41] We should really abolish open teams. [01:41] emancipation is key [01:41] i do think teams need some kind of superclass split [01:42] PersonGroup, Team(PersonGroup), MailingList(PersonGroup) [01:42] something ilke that [01:42] they are too overused [01:42] mmm [01:42] maybe [01:42] and being able to use the same team for many different purposes is not necessarily beneficial [01:42] maybe not [01:43] anyhow [01:43] it's kind of stupid that it's possible to make this mistake [01:44] even if i am stupid for making it [01:44] well, the instructions could do with automation [01:44] Sadly some people do like having open branches. [01:44] there are lots of groups which could be chosen [01:44] there is only one answer per that page [01:44] But we should probably add YOU ARE PROBABLY STUPID to branches owned by open teams. [01:45] heh [01:45] wgrant: [01:46] ... [01:46] don't people have to sign a coc or something to use ppas? [01:46] seems like this should be required for auto built branches [01:46] but [01:46] I think jml removed that [01:46] poolie: I think that requirement was waived. [01:46] or planned to [01:46] yeah, that's probably better [01:46] amhnews :) [02:22] wow buildbot is in bad shape [02:26] Oh? [02:26] Hmm, even more. [02:26] Excellent. [02:26] Ah. [02:26] It was restarted but not cleaned. [02:27] LOSA ping: please clean and restart pigeonpea [02:27] 6 fails in a row [02:27] 7 when the current one falls over entirely [02:27] wgrant: ok [02:30] wgrant: done [02:31] hloeung: Thanks. [02:56] wgrant, like this: https://code.launchpad.net/~mbp/launchpad/800295-protocol/+merge/82629 [02:56] Dear buildbot, please DIALCF. No love, all of us. [02:57] Dear PQM, you're next. No love, me. [02:57] heh. [03:02] Right, I think that's all of the 127 test failures fixed. [03:02] lifeless: So, do you have eight MPs for me to review? I'm feeling dangerously productive. :-P [03:03] StevenK: TGIF [03:04] +1,000 [03:20] ugh, there appears to be quite a bit of our CSS that just isn't used anymore [03:21] * mwhudson fails to be surprised [03:21] mwhudson: Yeah, but it makes me nervous [03:22] huwshimi: you get to delete code! bonus [03:22] mwhudson: Yeah [03:22] mwhudson: But I worry that I've missed something :) [03:22] mwhudson: Even when my search of the whole codebase comes back with nothing [03:22] yeah, i guess it's hard to write automated tests for css [03:23] we certainly construct class names from enums, which doesn't help grep... [03:31] wgrant: the dogfood builds yesterday worked, but I do see some errors in the log: CannotFetchFile, seemingly with empty URL & info. Any idea what that might mean? [03:32] StevenK: (from #-ops) ah, i see https://bugs.launchpad.net/launchpad/+bug/704080 now [03:32] <_mup_> Bug #704080: If there is only one recipe, it should redirect right to the recipe

< https://launchpad.net/bugs/704080 > [03:32] Indeed [03:32] that bug was about the list on a branch page, which says _1 recipe uses this branch_ [03:32] jtv: Well, possibly that it couldn't fetch the file. I've not seen them before, AFAICR. [03:33] when the link says "View source package recipes" it's more confusing [03:33] wgrant: but then there ought to be a URL in the exception message, no? [03:33] It looks as if it's getting no URL at all, and hence the error. [03:33] jtv: No idea. [03:33] Hmm [03:33] That's not helpful. [03:35] * mwhudson files https://bugs.launchpad.net/launchpad/+bug/891918 [03:35] <_mup_> Bug #891918: redirect from /~/+recipes to recipe when only one recipe can be confusing < https://launchpad.net/bugs/891918 > [03:38] mwhudson: So perhaps we should just hijack that link on Person:+index when they only have 1 recipe. [03:38] StevenK: that would certainly work [03:39] it's not a very important bug i guess [03:39] * StevenK glares at mwhudson for not triaging :-P [03:40] ah yeah [03:40] mwhudson: I'ved fixed it anyway [03:40] ta [04:11] If I want to make modifications the CSS files that are loaded I assume I modify "buildout-templates/bin/combine-css.in" [04:12] And then how to I get that rebuilt into /bin so that it gets run with "make css_combine"? [04:12] huwshimi: Change the template and then 'make clean && make' [04:13] StevenK: ah ha [04:13] You can possibly also just bin/buildout [04:13] Personally, I like to make sure, but that requires sitting through buildmailman [04:14] awesome, bin/buildout worked [04:14] RARGH, conflicts. [04:14] * StevenK smash. [04:14] StevenK: question [04:14] StevenK: did you consider just telling owners etc to be members of the bugsupervisor team ? [04:15] Why should they? They *own* the pillar. [04:15] delegation [04:16] Sure, but they should also have the permission. [04:16] why? [04:16] Can I say a cop out and reply 'Because Curtis says so' ? [04:16] if you must [04:17] the UI and help will need changing too [04:17] admins can do everything. owners delegate planning and bug responsibilities to drivers and bug supervisors. Drivers work with release planing, which encompasses bugs and specs, Bug supervisors can work bugs. [04:17] given there are now 4 teams that can grant the permissions [04:17] StevenK: yes, sure, so owners, drivers can be members of bug supervisors, and get those bits directly. [04:18] StevenK: which will drop to 25% the number of teams that need examining by the DB when querying [04:18] since supervisor no long implies notification, there shouldn't be an issue with mail receipt etc [04:18] lifeless: So, it's a Friday afternoon. I wanted to get this reviewed and landed before EOW. Not argue about it. :-( [04:19] It does imply it. [04:19] Unless you really know what you're doing. [04:19] what you're doing is inconsistent with the observer design, which will be an absolute list [04:19] its more than a little surprising [04:19] StevenK: I don't want to argue about it either. [04:23] StevenK: I've mailed the bug. [04:23] http://pastebin.ubuntu.com/741893/ Uhhhhh? [04:23] StevenK: I think the change to check permissions rather than checking teams is good and important; I thin the changes to the security model are questionable. [04:23] make [04:23] Ah [04:24] strictly bin/buildout [04:24] need newer timeline [04:24] Uhoh [04:24] Something is wrong [04:24] buildbot hasn't failed again yet... [04:24] ? [04:24] heh [04:24] Hah [04:24] One of the last eight builds has passed... [04:28] spwaking of ROW [04:28] bah [04:28] EOW [04:28] night all [04:29] lifeless: good night. but i bet you come back on later :-) [04:29] StevenK: my first look at the diff - i think you can replace self.context.userHasPrivileges with self.userHasPrivileges in the view code [04:30] wallyworld_: I hadn't pinged you yet because I was fixing the conflict. [04:30] wallyworld_: Which line of the diff? [04:30] StevenK: there's a few eg 85/86 [04:31] there's a mixin but the method it provides isn't used it appears [04:31] Ah, right [04:32] since you are fixing something else anyway..... :-) [04:34] wallyworld_: I was pushing the conflict change as I replied. Use of the property in the view fixed. [04:34] thanks [04:36] wallyworld_: Anything else, or you're still reading? [04:37] StevenK: still reading. just groking the various permission consolidations [04:38] StevenK: just saw that you could use roles.isBugSupervisor(self.pillar) instead of doing it yourself [04:39] wallyworld_: Oh, has that landed on devel? [04:39] I wasn't sure, so I left it. [04:39] ah, stupid me, no sorry, not landed yet. but close i think. let me check [04:40] StevenK: my ec2 run failed with 7 TestPoppy errors [04:40] othereise it would have landed [04:40] i think these are spurious? [04:40] lp-land it, and I'll re-merge [04:40] thanks, doing it now [04:44] StevenK: in now [04:46] wallyworld_: Thanks, merging. [04:47] StevenK: also, i think you need a few unit tests to explicitly check that a person of each role type has privileges [04:47] lifeless: Oh, and you know most of the code paths I'm changing were doing these checks anyway? I've just pulled them all together into one method. [04:47] wallyworld_: I think the bug code is well enough tested, TBH. [04:48] wallyworld_: But I can if you insist. [04:48] StevenK: just carry on, I'll discuss with sinzui [04:48] lifeless: So land it? [04:48] it is well tested but this branch introduces behaviour which allows additional users/roles to do things and we are not explicitly testing for that [04:49] the existing tests are great for regression testing but we need new tests for progression tests [04:49] StevenK: Up to you - I'm not blocking it [04:49] wallyworld_: I think the only change is admins, TBH. [04:49] and people in project roles, no? [04:50] wallyworld_: Most of that code was already there. [04:51] I trusted the existing test suite while developing this. [04:51] if it were me, i'd do a test case called TestUserHasPriviliges [04:51] to explicitly test the new method in isolation [04:52] wallyworld_: Like I say, happy to do so, if you insist. [04:52] I'm happy with this branch since it removes more code than it adds. [04:52] StevenK: that would be great if you could. it's a compromise because i'm not asking for additional tests on the view methods :-) [04:53] and it won't take long just for one new test case :-) [04:53] wallyworld_: One? [04:53] one test case but several tests [04:53] There are 4 celebrities to test and 6 pillar tests [04:54] yes, but these will be 10 tests foe the one test case [04:58] StevenK: off to get kid from school. will check your mp again when i get back [05:00] huwshimi, hi? [05:00] poolie: Hi [05:00] it's after lunch and not yet eod :) [05:01] poolie: Ah right, sorry about that. I'm just trying to finish quite a large refactor [05:01] np i sympathize [05:01] perhaps i will start drafting something and then we can talk [05:02] poolie: yeah that sounds great [05:02] poolie: Feel free to shoot questions at me [05:04] wgrant, do you have time to mumble? [05:05] sinzui: Sure [05:05] sinzui: lifeless has concerns with my bug. But he's cooking. [05:05] Although I make it 5 past midnight, so am tempted to object so you go to sleep. [05:05] But let me find my headset. [05:06] I replied. We want fix the root problem with launchpad, not make project contributors more angry with convoluted nested teams that require them to get spam [05:06] sinzui: Thank you. [05:20] Refactoring anything (in this case CSS) is nerve-wracking without tests of any kind. [05:23] wallyworld_: Are you back? [05:44] A review for someone if they're kind enough: https://code.launchpad.net/~huwshimi/launchpad/css-file-split-891896/+merge/82636 [05:45] StevenK: back now. bloody traffic really bad today :-( [05:46] huwshimi: looking in a sec [05:46] wallyworld_: I've pushed the test [05:46] wallyworld_: Cheers :) [05:46] wallyworld_: Just to warn you: "4855 lines (+2306/-2391) 20 files modified" [05:46] Crumbs [05:47] StevenK: Yeah, I was deleting Soyuz [05:47] huwshimi: Good job! [05:47] Not large enough. [05:47] StevenK: I wasn't fond of the name, so thought, "Why not!" [05:47] You have too many pluses for deletion. [05:47] nigelb: Shhh :P [05:48] heh. [05:48] Soyuz is sweat and blood, not code. [05:48] wallyworld_ is a bad person. My branch removed more than it added, and then he wanted tests. [05:48] Oh and probably curses. [05:48] nigelb: Bailing wire and gaffa tape, too [05:48] Probably some pitch too [05:48] To hold it all together? Nice idea. [05:52] i am not bad, i'm just drawn that way (says me channel Roger Rabbit) [05:52] channeling [05:58] huwshimi: so the files which include import.css won't pick up the stuff in components but the two cases of that it doesn't seem to matter [05:58] wallyworld_: Yeah, that was my intention. That should just import the base layer of our styles [05:59] wallyworld_: Sorry I should have explained on the MP [05:59] np. and you don't see a case where somthing will need to import the base layer and additional compoent styles? [06:00] wallyworld_: There may be, but I suspect for testing you'd want to include them specifically. In the future we may want to provide a case for that, but for this initial commit I let it be [06:00] sure, just checking :-) [06:00] wallyworld_: There may be a base set of components that are generic enough for that case [06:01] wallyworld_: np [06:01] huwshimi: and apart from that, all the red/green is just cut'n'paste essentially? [06:02] you've also run combine-css manually and checked the output? [06:02] wallyworld_: Yes, just splitting it between the files. I deleted 3 styles I think when I couldn't find any instances of them in the entire codebase (references to old yui 2 styles) [06:03] wallyworld_: Yeah the combine works and everything renders fine on the pages I checked [06:03] and you checked pages that use something from components? [06:04] wallyworld_: Yes, for example there are components on the sidebar, and tables and stuff which all render fine [06:05] cool. sounds good, thanks [06:06] wallyworld_: NO, thank you [06:06] erm that no was a little forceful :) [06:07] huwshimi: np. r=me [06:07] wallyworld_: Thankyou! [06:08] wallyworld_: unfortunately for you it's all smoke and mirrors :P [06:08] huwshimi: ? [06:09] wallyworld_: I was trying to making a joke about smoke testing. I'll be about my business. [06:09] huwshimi: it's been a long week, too long for bad puns :-) [06:10] wallyworld_: haha, I know you feel. Too long to be attempting puns too it appears === wallyworld_ changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: - | Critical bugtasks: 287 [06:41] * wallyworld_ off to have dinner with bigjools :-) [06:49] Dammit, it's been hotter down here today [06:49] Than it was in Brisbane. [06:49] 33 vs 26 [06:50] You're not doing a very good job of discouraging bigjools, .au :( [06:55] I thought it was supposed to be summer over there. [06:55] Why is it colder than over here? === wgrant changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: - | Critical bugtasks: 289 [06:56] wgrant: the errors in the buildmaster are all on rhenium — seemingly lost connections. [06:56] jtv: rhenium is not infamous. But if it's only that one, perhaps it is special. [06:58] What really pains me at the moment is that the biggest remaining worry is code paths that violate read-only database policy (and thus need explicit exemptions). Which means we ought to try each kind of upload. [06:58] The most likely failure resulting from my branch is “read-only transaction” errors. [07:00] What kinds of build-farm jobs do we have? I tried package builds, and I can try TTBJs, but everything else is a mystery to me. [07:00] Recipe builds. [07:00] Which are easily QA'd on staging [07:00] You may wish to cowboy it there. [07:01] How is staging's buildfarm set up? [07:01] What do you mean? [07:02] wallyworld_: Aw [07:03] wallyworld_: I just noticed that the whole squad except for you is arriving in Budapest on the same flight. [07:03] wgrant: where does staging get its builders? [07:04] jtv: clementine/concordia belong to it [07:04] So it's got its own? [07:04] But it may also have access to the donated production builders [07:04] Right. [07:04] Like dogfood's ferraz/rubidium [07:04] They both have access to all four. [07:04] good morning [07:04] morning adeuring! [07:04] Morning adeuring. [07:04] hi jtv! [07:05] hi wgrant! [07:05] wgrant: if my feeling about the most likely failures is correct, we don't really need 4 builders any more. One or two should be enough to trigger the errors I'm looking for, and half a dozen probably isn't enough to trigger the ones we're ultimately after. [07:06] jtv: I except so [07:06] *expect? [07:06] That's the one. [07:06] restecp [07:07] And staging has its own codehosting too, right? [07:07] Right. [07:07]