[00:00] <wallyworld_> 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] <poolie> this is a bit philosophical
[00:02] <StevenK> iamfuzz: O hai!
[00:02] <iamfuzz> StevenK, o/
[00:02] <poolie> i think you should test stuff intentionally, not count on randomness
[00:02] <poolie> 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] <iamfuzz> StevenK, thanks for the help btw.  Trying to get this up to evaluate as the tool for our build farm here
[00:02] <poolie> it's hard to see how that's helpful
[00:03] <iamfuzz> 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] <iamfuzz> 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] <iamfuzz> which if I hit directly, gives more the "Lost something?" 404 page with broken images
[00:04] <wgrant> iamfuzz: Hmm, it should be keyserver.launchpad.dev, not bazaar.launchpad.dev.
[00:04] <wgrant> Have you changed the configs at all?
[00:05] <iamfuzz> however, hitting bazaar.launchpad.dev directly does properly redirect to launchpad.dev
[00:05] <wallyworld_> poolie: isn't the whole point of using a rng to provide different input each time?
[00:06] <iamfuzz> wgrant, the apache config, yes
[00:06] <wgrant> iamfuzz: The Apache config shouldn't matter here.
[00:06] <StevenK> wallyworld_: Are you still reviewing poolie's branch?
[00:06] <wgrant> iamfuzz: The test keyserver doesn't go through apache
[00:06] <wgrant> it's keyserver.launchpad.net:11371
[00:06] <wgrant> s/net/dev/
[00:07] <poolie> wallyworld_, so, generally, my experience is that using a rng in tests is a bad idea
[00:07] <poolie> if there are some random values that catch a bug, which is possible
[00:07] <poolie> there are two problems
[00:07] <poolie> 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] <poolie> secondly, it will be hard to reproduce it, so perhaps hard to understand why it's failing
[00:08] <poolie> oh, and also, it may fail at inconvenient times
[00:08] <poolie> for example on buildbot but not ec2 etc
[00:08] <iamfuzz> wgrant, https://keyserver.launchpad.dev:11371/pks/lookup?search=0xD69FC46438D3A33619E5577D39BE3335F26A3797&op=get  just hangs on me
[00:08] <iamfuzz> yep, timed out
[00:08] <wgrant> iamfuzz: http, not https
[00:08] <iamfuzz> ah there we go
[00:09] <iamfuzz> much better
[00:09] <iamfuzz> Error handling request: No keys found
[00:09] <wallyworld_> StevenK: yes
[00:09] <poolie> 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] <poolie> but it should isoltae itself
[00:09] <iamfuzz> 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] <wgrant> iamfuzz: gpg --keyserver keyserver.launchpad.dev --send-keys SOMEKEYID
[00:10] <wallyworld_> poolie: that all makes sense. thanks for explaining
[00:10] <wgrant> iamfuzz: The dev keyserver doesn't know about any keys by default.
[00:11] <iamfuzz> wgrant, ah doh, sorry bout that.  I had assumed it would sync with the ubuntu keyserver
[00:11] <wgrant> iamfuzz: No, that would take a looooooooooong time :)
[00:11] <iamfuzz> point taken :-)
[00:12] <wgrant> 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] <iamfuzz> wgrant, worked like a charm, many thanks.  Now I just have to get email working on here and should be golden
[00:13] <wgrant> iamfuzz: Email from the webapp is generally redirected to root@localhost.
[00:13] <iamfuzz> even better
[00:13] <wgrant> Or you can grab the token with "SELECT * FROM logintoken"
[00:13] <wgrant> Then https://launchpad.dev/token/SOMETOKENVALUE
[00:14] <wgrant> If you are lazy and don't want to decrypt the email.
[00:14] <iamfuzz> wgrant, I'm not *that* lazy ;-)
[00:14] <iamfuzz> you guys have made it far easier than I expected
[00:14] <wallyworld_> 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] <StevenK> wallyworld_: I have, and there are two branches
[00:15] <wallyworld_> StevenK: already reviewed the other one :-)
[00:15] <wgrant> 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] <wgrant> Although I guess you've already seen that, if you have the keyserver running.
[00:16] <poolie> wallyworld_,  should i put that on the mp maybe
[00:18] <wallyworld_> poolie: i think that would be great
[00:18] <wallyworld_> poolie: also so that the original branch author etc can see why the change was made
[00:20] <poolie> wallyworld_,  thanks for asking
[00:21] <wallyworld_> 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] <poolie> sure
[00:24] <poolie> i would like to make people appreciate randomness in tests is not a feature
[00:25] <mwhudson> 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] <wallyworld_> 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] <mwhudson> but sadly it just uses second level timestamp + randint(100000)
[00:26] <StevenK> wallyworld_: You do, by side effect
[00:26] <wallyworld_> 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] <jelmer> StevenK: is there a particular reason for that?
[00:32] <StevenK> jelmer: For which, sorry?
[00:32] <jelmer> StevenK: $(RM), it surprised me too
[00:33] <jelmer> the last project I encountered that substituted RM did it because of broken rm implementations
[00:33] <StevenK> jelmer: It's cross-platform, which isn't really a concern for us, but I'm a pedant like that.
[00:33] <jelmer> ah, ok
[00:33] <jelmer> launchpad on windows ? :-)
[00:33] <StevenK> Bwahaha
[00:33] <StevenK> We need POSIX
[00:34] <StevenK> Launchpad on OS X could be possible, which is a scary prospect
[00:35] <mwhudson> i've contemplated it, but funnily enough always found better things to do
[00:35] <wgrant> The most difficult bit would be porting python-apt, I expect
[00:36] <wgrant> The most adventurous thing I've done is running it on kfreebsd.
[00:36] <rick_h_> python-macports
[00:36] <rick_h_> I can see it now
[00:36] <StevenK> mwhudson: Haha
[00:37] <mwhudson> i think jamesh said he did it once in the early days, or thought about it?
[00:37] <mwhudson> anyway, talking of better things to do --> lunch
[00:51] <poolie> 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 <feature> <lp-bugs> <Launchpad itself:Triaged> < https://launchpad.net/bugs/1734 >
[01:18] <poolie> pht
[01:19] <poolie> wgrant, so what's next?
[01:19] <poolie> i guess i will get rid of the runtime master-client dependency
[01:20] <wgrant> poolie: RIght, just remove that one import.
[01:21] <wgrant> poolie: Replace it with the string, like the rest of the file uses already.
[01:21] <wgrant> Then check that the appserver runs without python-lpbuildd installed, and reland.
[01:21] <poolie> k on it
[01:23] <wgrant> Thanks.
[01:33] <wallyworld_> 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] <poolie> there are bunch of not-quite dupes
[01:33] <poolie> it may be worth tearing them apart
[01:34] <wgrant> I think it's pretty different.
[01:34] <wgrant> This isn't for gardening.
[01:34] <wgrant> This is for spam and emergencies.
[01:34] <wgrant> Gardening is very different.
[01:35] <wgrant> Ah, jelmer is still awake!
[01:36] <wallyworld_> wgrant: sure, but the solution is the same even though the problem descriptions are different
[01:36] <wgrant> wallyworld_: Is it?
[01:36] <wallyworld_> 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] <wgrant> wallyworld_: I'm doing that right now.
[01:36] <wallyworld_> ok thanks
[01:37] <wallyworld_> wgrant: allowing the user to hide their own comments is a form or gardening i think
[01:37] <wgrant> Ermmmmm
[01:37] <wgrant> poolie: Why does ~launchpad-dev own lp:launchpad-buildd.
[01:37] <wgrant> ?
[01:37]  * wgrant fixes.
[01:38] <nigelb> wgrant: wow.
[01:38] <nigelb> I wwas about to ask that.
[01:38] <nigelb> (because of the MP requests coming on the m/l)
[01:40] <poolie> wgrant, oh was that the list?
[01:40] <poolie> the short answer is that trusted pickers aren't used everywhere
[01:40] <wgrant> It's the list, yes.
[01:40] <wgrant> Which is an open team.
[01:40] <wgrant> https://dev.launchpad.net/CreatingNewProjects
[01:40] <poolie> sorry
[01:41] <wgrant> We should really abolish open teams.
[01:41] <dobey> emancipation is key
[01:41] <poolie> i do think teams need some kind of superclass split
[01:42] <poolie> PersonGroup, Team(PersonGroup), MailingList(PersonGroup)
[01:42] <poolie> something ilke that
[01:42] <poolie> they are too overused
[01:42] <lifeless> mmm
[01:42] <lifeless> maybe
[01:42] <poolie> and being able to use the same team for many different purposes is not necessarily beneficial
[01:42] <poolie> maybe not
[01:43] <poolie> anyhow
[01:43] <poolie> it's kind of stupid that it's possible to make this mistake
[01:44] <poolie> even if i am stupid for making it
[01:44] <lifeless> well, the instructions could do with automation
[01:44] <wgrant> Sadly some people do like having open branches.
[01:44] <lifeless> there are lots of groups which could be chosen
[01:44] <lifeless> there is only one answer per that page
[01:44] <wgrant> But we should probably add <blink>YOU ARE PROBABLY STUPID</blink> to branches owned by open teams.
[01:45] <nigelb> heh
[01:45] <nigelb> wgrant: <marquee>
[01:46] <poolie> ...
[01:46] <poolie> don't people have to sign a coc or something to use ppas?
[01:46] <poolie> seems like this should be required for auto built branches
[01:46] <poolie> but
[01:46] <lifeless> I think jml removed that
[01:46] <wgrant> poolie: I think that requirement was waived.
[01:46] <lifeless> or planned to
[01:46] <poolie> yeah, that's probably better
[01:46] <poolie> amhnews :)
[02:22] <lifeless> wow buildbot is in bad shape
[02:26] <wgrant> Oh?
[02:26] <wgrant> Hmm, even more.
[02:26] <wgrant> Excellent.
[02:26] <wgrant> Ah.
[02:26] <wgrant> It was restarted but not cleaned.
[02:27] <wgrant> LOSA ping: please clean and restart pigeonpea
[02:27] <lifeless> 6 fails in a row
[02:27] <lifeless> 7 when the current one falls over entirely
[02:27] <hloeung> wgrant: ok
[02:30] <hloeung> wgrant: done
[02:31] <wgrant> hloeung: Thanks.
[02:56] <poolie> wgrant, like this: https://code.launchpad.net/~mbp/launchpad/800295-protocol/+merge/82629
[02:56] <StevenK> Dear buildbot, please DIALCF. No love, all of us.
[02:57] <StevenK> Dear PQM, you're next. No love, me.
[02:57] <nigelb> heh.
[03:02] <StevenK> Right, I think that's all of the 127 test failures fixed.
[03:02] <StevenK> lifeless: So, do you have eight MPs for me to review? I'm feeling dangerously productive. :-P
[03:03] <lifeless> StevenK: TGIF
[03:04] <StevenK> +1,000
[03:20] <huwshimi> 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] <huwshimi> mwhudson: Yeah, but it makes me nervous
[03:22] <mwhudson> huwshimi: you get to delete code! bonus
[03:22] <huwshimi> mwhudson: Yeah
[03:22] <huwshimi> mwhudson: But I worry that I've missed something :)
[03:22] <huwshimi> mwhudson: Even when my search of the whole codebase comes back with nothing
[03:22] <mwhudson> yeah, i guess it's hard to write automated tests for css
[03:23] <mwhudson> we certainly construct class names from enums, which doesn't help grep...
[03:31] <jtv> 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] <mwhudson> 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 <confusing-ui> <qa-ok> <recipe> <Launchpad itself:Fix Released by stevenk> < https://launchpad.net/bugs/704080 >
[03:32] <StevenK> Indeed
[03:32] <mwhudson> that bug was about the list on a branch page, which says _1 recipe uses this branch_
[03:32] <wgrant> jtv: Well, possibly that it couldn't fetch the file. I've not seen them before, AFAICR.
[03:33] <mwhudson> when the link says "View source package recipes" it's more confusing
[03:33] <jtv> wgrant: but then there ought to be a URL in the exception message, no?
[03:33] <jtv> It looks as if it's getting no URL at all, and hence the error.
[03:33] <wgrant> jtv: No idea.
[03:33] <wgrant> Hmm
[03:33] <wgrant> 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 <confusing-ui> <Launchpad itself:New> < https://launchpad.net/bugs/891918 >
[03:38] <StevenK> mwhudson: So perhaps we should just hijack that link on Person:+index when they only have 1 recipe.
[03:38] <mwhudson> StevenK: that would certainly work
[03:39] <mwhudson> it's not a very important bug i guess
[03:39]  * StevenK glares at mwhudson for not triaging :-P
[03:40] <mwhudson> ah yeah
[03:40] <StevenK> mwhudson: I'ved fixed it anyway
[03:40] <mwhudson> ta
[04:11] <huwshimi> If I want to make modifications the CSS files that are loaded I assume I modify "buildout-templates/bin/combine-css.in"
[04:12] <huwshimi> And then how to I get that rebuilt into /bin so that it gets run with "make css_combine"?
[04:12] <StevenK> huwshimi: Change the template and then 'make clean && make'
[04:13] <huwshimi> StevenK: ah ha
[04:13] <wgrant> You can possibly also just bin/buildout
[04:13] <StevenK> Personally, I like to make sure, but that requires sitting through buildmailman
[04:14] <huwshimi> awesome, bin/buildout worked
[04:14] <StevenK> RARGH, conflicts.
[04:14]  * StevenK smash.
[04:14] <lifeless> StevenK: question
[04:14] <lifeless> StevenK: did you consider just telling owners etc to be members of the bugsupervisor team ?
[04:15] <StevenK> Why should they? They *own* the pillar.
[04:15] <lifeless> delegation
[04:16] <StevenK> Sure, but they should also have the permission.
[04:16] <lifeless> why?
[04:16] <StevenK> Can I say a cop out and reply 'Because Curtis says so' ?
[04:16] <lifeless> if you must
[04:17] <lifeless> the UI and help will need changing too
[04:17] <StevenK> 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] <lifeless> given there are now 4 teams that can grant the permissions
[04:17] <lifeless> StevenK: yes, sure, so owners, drivers can be members of bug supervisors, and get those bits directly.
[04:18] <lifeless> StevenK: which will drop to 25% the number of teams that need examining by the DB when querying
[04:18] <lifeless> since supervisor no long implies notification, there shouldn't be an issue with mail receipt etc
[04:18] <StevenK> lifeless: So, it's a Friday afternoon. I wanted to get this reviewed and landed before EOW. Not argue about it. :-(
[04:19] <wgrant> It does imply it.
[04:19] <wgrant> Unless you really know what you're doing.
[04:19] <lifeless> what you're doing is inconsistent with the observer design, which will be an absolute list
[04:19] <lifeless> its more than a little surprising
[04:19] <lifeless> StevenK: I don't want to argue about it either.
[04:23] <lifeless> StevenK: I've mailed the bug.
[04:23] <StevenK> http://pastebin.ubuntu.com/741893/ Uhhhhh?
[04:23] <lifeless> 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] <wgrant> make
[04:23] <StevenK> Ah
[04:24] <lifeless> strictly bin/buildout
[04:24] <lifeless> need newer timeline
[04:24] <wgrant> Uhoh
[04:24] <wgrant> Something is wrong
[04:24] <wgrant> buildbot hasn't failed again yet...
[04:24] <lifeless> ?
[04:24] <lifeless> heh
[04:24] <StevenK> Hah
[04:24] <wgrant> One of the last eight builds has passed...
[04:28] <lifeless> spwaking of ROW
[04:28] <lifeless> bah
[04:28] <lifeless> EOW
[04:28] <lifeless> night all
[04:29] <wallyworld_> lifeless: good night. but i bet you come back on later :-)
[04:29] <wallyworld_> StevenK: my first look at the diff - i think you can replace self.context.userHasPrivileges with self.userHasPrivileges in the view code
[04:30] <StevenK> wallyworld_: I hadn't pinged you yet because I was fixing the conflict.
[04:30] <StevenK> wallyworld_: Which line of the diff?
[04:30] <wallyworld_> StevenK: there's a few eg 85/86
[04:31] <wallyworld_> there's a mixin but the method it provides isn't used it appears
[04:31] <StevenK> Ah, right
[04:32] <wallyworld_> since you are fixing something else anyway..... :-)
[04:34] <StevenK> wallyworld_: I was pushing the conflict change as I replied. Use of the property in the view fixed.
[04:34] <wallyworld_> thanks
[04:36] <StevenK> wallyworld_: Anything else, or you're still reading?
[04:37] <wallyworld_> StevenK: still reading. just groking the various permission consolidations
[04:38] <wallyworld_> StevenK: just saw that you could use roles.isBugSupervisor(self.pillar) instead of doing it yourself
[04:39] <StevenK> wallyworld_: Oh, has that landed on devel?
[04:39] <StevenK> I wasn't sure, so I left it.
[04:39] <wallyworld_> ah, stupid me, no sorry, not landed yet. but close i think. let me check
[04:40] <wallyworld_> StevenK: my ec2 run failed with 7 TestPoppy errors
[04:40] <wallyworld_> othereise it would have landed
[04:40] <wallyworld_> i think these are spurious?
[04:40] <StevenK> lp-land it, and I'll re-merge
[04:40] <wallyworld_> thanks, doing it now
[04:44] <wallyworld_> StevenK: in now
[04:46] <StevenK> wallyworld_: Thanks, merging.
[04:47] <wallyworld_> StevenK: also, i think you need a few unit tests to explicitly check that a person of each role type has privileges
[04:47] <StevenK> 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] <StevenK> wallyworld_: I think the bug code is well enough tested, TBH.
[04:48] <StevenK> wallyworld_: But I can if you insist.
[04:48] <lifeless> StevenK: just carry on, I'll discuss with sinzui
[04:48] <StevenK> lifeless: So land it?
[04:48] <wallyworld_> 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] <wallyworld_> the existing tests are great for regression testing but we need new tests for progression tests
[04:49] <lifeless> StevenK: Up to you - I'm not blocking it
[04:49] <StevenK> wallyworld_: I think the only change is admins, TBH.
[04:49] <wallyworld_> and people in project roles, no?
[04:50] <StevenK> wallyworld_: Most of that code was already there.
[04:51] <StevenK> I trusted the existing test suite while developing this.
[04:51] <wallyworld_> if it were me, i'd do a test case called TestUserHasPriviliges
[04:51] <wallyworld_> to explicitly test the new method in isolation
[04:52] <StevenK> wallyworld_: Like I say, happy to do so, if you insist.
[04:52] <StevenK> I'm happy with this branch since it removes more code than it adds.
[04:52] <wallyworld_> 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] <wallyworld_> and it won't take long just for one new test case :-)
[04:53] <StevenK> wallyworld_: One?
[04:53] <wallyworld_> one test case but several tests
[04:53] <StevenK> There are 4 celebrities to test and 6 pillar tests
[04:54] <wallyworld_> yes, but these will be 10 tests foe the one test case
[04:58] <wallyworld_> StevenK: off to get kid from school. will check your mp again when  i get back
[05:00] <poolie> huwshimi, hi?
[05:00] <huwshimi> poolie: Hi
[05:00] <poolie> it's after lunch and not yet eod :)
[05:01] <huwshimi> poolie: Ah right, sorry about that. I'm just trying to finish quite a large refactor
[05:01] <poolie> np i sympathize
[05:01] <poolie> perhaps i will start drafting something and then we can talk
[05:02] <huwshimi> poolie: yeah that sounds great
[05:02] <huwshimi> poolie: Feel free to shoot questions at me
[05:04] <sinzui> wgrant, do you have time to mumble?
[05:05] <wgrant> sinzui: Sure
[05:05] <StevenK> sinzui: lifeless has concerns with my bug. But he's cooking.
[05:05] <wgrant> Although I make it 5 past midnight, so am tempted to object so you go to sleep.
[05:05] <wgrant> But let me find my headset.
[05:06] <sinzui> 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] <StevenK> sinzui: Thank you.
[05:20] <huwshimi> Refactoring anything (in this case CSS) is nerve-wracking without tests of any kind.
[05:23] <StevenK> wallyworld_: Are you back?
[05:44] <huwshimi> A review for someone if they're kind enough: https://code.launchpad.net/~huwshimi/launchpad/css-file-split-891896/+merge/82636
[05:45] <wallyworld_> StevenK: back now. bloody traffic really bad today :-(
[05:46] <wallyworld_> huwshimi: looking in a sec
[05:46] <StevenK> wallyworld_: I've pushed the test
[05:46] <huwshimi> wallyworld_: Cheers :)
[05:46] <huwshimi> wallyworld_: Just to warn you: "4855 lines (+2306/-2391) 20 files modified"
[05:46] <StevenK> Crumbs
[05:47] <huwshimi> StevenK: Yeah, I was deleting Soyuz
[05:47] <nigelb> huwshimi: Good job!
[05:47] <StevenK> Not large enough.
[05:47] <huwshimi> StevenK: I wasn't fond of the name, so thought, "Why not!"
[05:47] <nigelb> You have too many pluses for deletion.
[05:47] <huwshimi> nigelb: Shhh :P
[05:48] <nigelb> heh.
[05:48] <nigelb> Soyuz is sweat and blood, not code.
[05:48] <StevenK> wallyworld_ is a bad person. My branch removed more than it added, and then he wanted tests.
[05:48] <nigelb> Oh and probably curses.
[05:48] <StevenK> nigelb: Bailing wire and gaffa tape, too
[05:48] <StevenK> Probably some pitch too
[05:48] <nigelb> To hold it all together? Nice idea.
[05:52] <wallyworld_> i am not bad, i'm just drawn that way (says me channel Roger Rabbit)
[05:52] <wallyworld_> channeling
[05:58] <wallyworld_> 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] <huwshimi> wallyworld_: Yeah, that was my intention. That should just import the base layer of our styles
[05:59] <huwshimi> wallyworld_: Sorry I should have explained on the MP
[05:59] <wallyworld_> np. and you don't see a case where somthing will need to import the base layer and additional compoent styles?
[06:00] <huwshimi> 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] <wallyworld_> sure, just checking :-)
[06:00] <huwshimi> wallyworld_: There may be a base set of components that are generic enough for that case
[06:01] <huwshimi> wallyworld_: np
[06:01] <wallyworld_> huwshimi: and apart from that, all the red/green is just cut'n'paste essentially?
[06:02] <wallyworld_> you've also run combine-css manually and checked the output?
[06:02] <huwshimi> 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] <huwshimi> wallyworld_: Yeah the combine works and everything renders fine on the pages I checked
[06:03] <wallyworld_> and you checked pages that use something from components?
[06:04] <huwshimi> wallyworld_: Yes, for example there are components on the sidebar, and tables and stuff which all render fine
[06:05] <wallyworld_> cool. sounds good, thanks
[06:06] <huwshimi> wallyworld_: NO, thank you
[06:06] <huwshimi> erm that no was a little forceful :)
[06:07] <wallyworld_> huwshimi: np. r=me
[06:07] <huwshimi> wallyworld_: Thankyou!
[06:08] <huwshimi> wallyworld_: unfortunately for you it's all smoke and mirrors :P
[06:08] <wallyworld_> huwshimi: ?
[06:09] <huwshimi> wallyworld_: I was trying to making a joke about smoke testing. I'll be about my business.
[06:09] <wallyworld_> huwshimi: it's been a long week, too long for bad puns :-)
[06:10] <huwshimi> wallyworld_: haha, I know you feel. Too long to be attempting puns too it appears
[06:41]  * wallyworld_ off to have dinner with bigjools :-)
[06:49] <wgrant> Dammit, it's been hotter down here today
[06:49] <wgrant> Than it was in Brisbane.
[06:49] <wgrant> 33 vs 26
[06:50] <wgrant> You're not doing a very good job of discouraging bigjools, .au :(
[06:55] <jtv> I thought it was supposed to be summer over there.
[06:55] <jtv> Why is it colder than over here?
[06:56] <jtv> wgrant: the errors in the buildmaster are all on rhenium — seemingly lost connections.
[06:56] <wgrant> jtv: rhenium is not infamous. But if it's only that one, perhaps it is special.
[06:58] <jtv> 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] <jtv> The most likely failure resulting from my branch is “read-only transaction” errors.
[07:00] <jtv> 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] <wgrant> Recipe builds.
[07:00] <wgrant> Which are easily QA'd on staging
[07:00] <wgrant> You may wish to cowboy it there.
[07:01] <jtv> How is staging's buildfarm set up?
[07:01] <wgrant> What do you mean?
[07:02] <wgrant> wallyworld_: Aw
[07:03] <wgrant> wallyworld_: I just noticed that the whole squad except for you is arriving in Budapest on the same flight.
[07:03] <jtv> wgrant: where does staging get its builders?
[07:04] <wgrant> jtv: clementine/concordia belong to it
[07:04] <jtv> So it's got its own?
[07:04] <wgrant> But it may also have access to the donated production builders
[07:04] <wgrant> Right.
[07:04] <wgrant> Like dogfood's ferraz/rubidium
[07:04] <wgrant> They both have access to all four.
[07:04] <adeuring> good morning
[07:04] <jtv> morning adeuring!
[07:04] <wgrant> Morning adeuring.
[07:04] <adeuring> hi jtv!
[07:05] <adeuring> hi wgrant!
[07:05] <jtv> 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] <wgrant> jtv: I except so
[07:06] <jtv> *expect?
[07:06] <wgrant> That's the one.
[07:06] <jtv> restecp
[07:07] <jtv> And staging has its own codehosting too, right?
[07:07] <wgrant> Right.
[07:07] <wgrant> Which dogfood lacks.
[07:07] <wgrant> You *can* test recipes on dogfood.
[07:07] <wgrant> Or at least could a year ago
[07:07] <wgrant> Because it sort of uses production's codehosting.
[07:09] <jtv> I think it's time to hand back those builders I borrowed, and continue with staging.
[07:09] <wgrant> Agreed.
[07:09] <wgrant> They'll need to be upgraded before they're sent back.
[07:09] <jtv> Would've been good to stress-test against hordes of builders, but that doesn't seem to be in the cards.  And at least we'll have eliminated a good portion of these bugs.
[07:14] <jtv> wgrant: what kind of upgrading do we need to do?
[07:15] <wgrant> jtv: The production builders have all been upgraded a few times since yours were donated.
[07:15] <wgrant> If we just send them back to production, they'll be running different code to the rest.
[07:15] <wgrant> Which would be bad.
[07:16] <jtv> How do we go about upgrading them?
[07:16] <wgrant> Poke a LOSA or lamont.
[07:16] <wgrant> We'll probably do a new upgrade on Monday.
[07:16] <wgrant> Or maybe tonight.
[07:16] <wgrant> Because we like to live dangerously.
[07:16] <jtv> Friday night?
[07:17] <wgrant> Right, dangerously.
[07:17] <hloeung> jtv: I could upgrade the builders so that they're running the same as the others if you like
[07:17] <wgrant> (and the changes are tiny and limited to a regression fix and a tiny bit of extra debug info)
[07:17] <jtv> hloeung: that'd be great—and then I'd like to get them back into the production buildfarm as soon as possible.
[07:18] <hloeung> jtv: which ones are we talking about btw?
[07:18] <jtv> (Make sure they don't fall behind again etc.)
[07:18]  * jtv digs up the RT
[07:18] <jtv> See RT 48981
[07:19] <jtv> wgrant: looks like your aalib build broke rhenium.
[07:19] <wgrant> Oh?
[07:20] <jtv> That one's so old, I wouldn't be surprised if some essential file had flushed out of the librarian or something.
[07:20] <hloeung> jtv: thanks
[07:20] <wgrant> That's possible.
[07:20] <jtv> Although apparently the build did suceed.
[07:20] <jtv> https://librarian.dogfood.launchpad.net/80686189/buildlog_ubuntu-oneiric-amd64.aalib_1.4p5-38build1_BUILDING.txt.gz
[07:35] <adeuring> lifeless: could you have a look this MP: https://code.launchpad.net/~adeuring/launchpad/bug-sorting-by-attachment-age/+merge/82315 ?
[08:37] <poolie> vila, what do you mean "there's no feedback" about rejected mail
[08:37] <poolie> if lp doesn't like it, it will say so
[08:37] <vila> poolie: not in my case, never
[08:37] <poolie> you may be acclimatised to ignore it
[08:38] <vila> IIRC it happens when I reply to merge proposals and forget to sign
[08:39] <poolie> it does send mail
[08:39] <poolie> it is either a bug or perhaps it's getting lost somewhere
[08:40] <vila> ha, lost somewhere rings a bell :-} My ISP have been dropping pqm failure emails until recently
[08:41] <vila> spammers defeating the store-and-forward robustness of mail transport is the main reason I hate them :-/
[08:44] <burgerga> Hello, I have a small question: on the page of launchpad itself on launchpad it says that feature requests are handled in the wiki, however in the wiki I cannot immediately see where I should do this, can anyone point me in the right direction
[08:44] <poolie> what's the request?
[08:45] <poolie> i suspect actually contrary to that text we really want people floating requests by irc, mail or bugs-
[08:45] <burgerga> ah oke
[08:45] <burgerga> I would like to save a bug report as draft
[08:46] <burgerga> since often I have to start all over when I'm writing a lenghty one and have to go ;)
[08:46] <poolie> i suspect there is a bug for it
[08:46] <poolie> i will look
[08:48] <burgerga> think i found it
[08:48] <burgerga> https://bugs.launchpad.net/launchpad/+bug/327728
[08:48] <_mup_> Bug #327728: Create tasks <feature> <lp-registry> <Launchpad itself:Triaged> < https://launchpad.net/bugs/327728 >
[08:49] <burgerga> thanks
[08:49] <burgerga> :)
[08:49] <poolie> hm
[08:49] <poolie> i think that's a bit different
[08:50] <burgerga> yes it covers more
[08:50] <poolie> smaller bugs are more likely to be fixed :)
[08:50] <poolie> as long as they're not too small
[08:51] <burgerga> yes, I think they changed the bug report to "create tasks" and then marked it as duplicate of another bug
[08:52] <burgerga> so I think I should change it back to "save drafts"
[08:55] <poolie> and undupe it
[08:55] <burgerga> ok will do, thanks for the help
[08:55] <poolie> i just got a failure in  lp.translations.tests.test_rosetta_branches_script.TestRosettaBranchesScript.test_rosetta_branches_script_oops for the second time running
[08:55] <poolie> jtv, halp?
[08:56] <jtv> Hi poolie
[08:56] <poolie> actually the smart thing here is for me to just leave these alone and someone else will solve it over the weekend
[08:56] <poolie> so i will do that
[08:57] <jtv> poolie: did you check out the imports thing?
[08:59] <jtv> poolie: I emailed about it the other day… “import lp.codehosting” has side effects.  Removing it (because it looks redundant) or putting it in its regular alphabetical place may break things.
[08:59] <jtv> And we have a maintenance script that may do either.
[08:59] <poolie> :/
[09:00] <poolie> this is bug 890816
[09:00] <poolie> ?
[09:00] <_mup_> Bug #890816: Intermittent test failures: TestPullerMasterIntegration.test_mirror <Launchpad itself:Triaged> < https://launchpad.net/bugs/890816 >
[09:01] <poolie> jtv i have only one revision and it doesn't mention that
[09:01] <poolie> doesn't mention lp.codehosting
[09:01] <poolie> could it really be related?
[09:02] <jtv> Let me just try again to load up that bug page
[09:03] <jtv> poolie: ah no…  this is twisted trouble.  :(
[09:04] <poolie> my branch is https://code.launchpad.net/~mbp/launchpad/800295-protocol/+merge/82629
[09:06] <poolie> o/ mrevell
[09:06] <mrevell> Hello
[09:11] <danhg> Morning all
[09:12] <mrevell> hey danhg
[09:13] <poolie> mrevell, i sent a mail about markdown
[09:14] <mrevell> poolie, Oh cool /me looks
[09:15] <poolie> we could talk if you want
[09:16] <mrevell> poolie, Sure. Skype took a dislike to my mic yesterday, let me see if that's still a problem.
[09:18] <poolie> maybe just here
[09:18] <poolie> am still fighting the buildd gorilla
[09:18] <mrevell> poolie, Oh yeah. This came up in the stakeholder meeting yesterday
[09:18] <poolie> buildds, or markup?
[09:19] <mrevell> poolie, Bryce put forward a request for some form of mark-up in descriptions etc
[09:19] <poolie> yeah i saw, so i thought i would finally write it down
[09:19] <poolie> kind of sketchy but its a start
[09:30] <mrevell> poolie, Do you have any idea how long it'd take to get to your proposed first step? (markdown for project descriptions, behind a ff)
[09:32] <poolie> in the best case a day?
[09:32] <poolie> in the worst case, forever
[09:33] <poolie> i think hooking it up will be cheap but deploying stuff is a pain in the butt
[09:33] <poolie> but after the last couple of weeks my butt is a bit tougher
[09:33] <poolie> other people could probably estimate it better
[09:33] <poolie> if i took those steps would it be accepted?
[09:37] <mrevell> poolie, From a product PoV, absolutely.
[09:37] <poolie> nice
[09:38] <poolie> obviously robert and the more experienced developers can have their say too
[09:38] <nigelb> omg unicorns and ponnies if you can pull it off though :)
[09:38] <mrevell> heh
[09:39] <nigelb> This inline commenting blog post worries me. We should have it in LP :|
[09:39] <poolie> we should
[09:39] <poolie> that needs someone with more ajax than me
[09:41] <poolie> nigelb, i suspect that too, like this, may not be infeasible if we just decide to do it
[09:41] <mrevell> nigelb, poolie: It's something that's been on my roadmap from day one and we discussed it in the stakeholder meeting yesterday. Basically, I want it in Launchpad; lots of people want it in Launchpad. Today, I get to take all the requests from the stakeholder meeting, combine them with our own desires for LP and then see what we can fit into roughly 18 months.
[09:41] <poolie> mrevell, i guess the reason i ask "will it be accepted"
[09:41] <nigelb> We can also bend those "things that can fit in 18 months" with outside help :)
[09:41] <poolie> is because it's been blocked by a kind of perfectionism a bit before
[09:42] <poolie> so i'm proposing a pretty grungy stepwise approach
[09:42] <poolie> but i think we have mostly put that perfectionism behind us
[09:43] <mrevell> poolie, Yeah, perfectionism has left us with a remarkably imperfect product.
[09:43] <nigelb> heh
[09:44] <mrevell> poolie, fwiw, what you propose to do looks like just the sort of small, realistic, incremental change that I want us to do more of in LP.
[09:44] <poolie> \heart
[09:44] <nigelb> :)
[09:44] <poolie> let's see
[09:45] <wgrant> This seems like a pretty unobjectionable incremental change.
[09:45] <nigelb> Which one? Markdown or inline commenting?
[09:45] <wgrant> Markdown.
[09:45] <wgrant> Inline commenting is not small.
[09:45] <wgrant> At all.
[09:45] <nigelb> Yeah.
[09:45] <wgrant> Because we have dynamic diffs.
[09:45] <nigelb> Ah. Right.
[09:46] <nigelb> #win.
[09:46] <nigelb> We should be able to do some sort of metadata on that diff somewhere, shouldn't we?
[09:46] <mrevell> Yeah, in-line commenting has a budget of 8 weeks in my proposed roadmap (the revised version coming soon to a -dev list near you) and I'm probably being optimistic.
[09:47] <wgrant> Ooh, we have a roadmap?
[09:48] <wgrant> It's really hard to get any kind of estimate.
[09:48] <wgrant> It would probably require a major rework of the MP system.
[09:48] <wgrant> It's not at all clear how it would work.
[09:48] <poolie> so
[09:48] <poolie> if i was going to look for a small thing
[09:48] <poolie> i would do some kind of js that just quotes lines from the diff in to the edit window
[09:49] <poolie> maybe with text next to them
[09:49] <poolie> something like that
[09:49] <poolie> it may be a bit of a detour but it is not scary in size
[09:49] <poolie> it would improve it
[09:49] <poolie> but all the comments are still just text blocks; you don't need a comment of attachments that float around as the diff changes
[09:49] <poolie> maybe that's too small of a win though
[09:52] <lifeless> StevenK: would this -  https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-4a5b9cd9bd803fdc1960fbd685d6871d#statementlog have been easier to work on , for that bug nomination thing you needed backtraces of ?
[09:52] <lifeless> StevenK: its pretty crudely rendered ATM; I think making the sql format not do those crazy long lines would be another good incremental improvement
[10:42] <rvba> adeuring: Hi, could you please have a look at https://code.launchpad.net/~rvb/launchpad/activereviews-bug-867941-hugequery/+merge/82650 ?
[10:42] <adeuring> rvba: sure
[10:42] <rvba> Thank you.
[11:08] <jtv> cjwatson: do you ever have the problem that approving uploads on DistroSeries:+queue pages is too slow?
[11:09] <adeuring> rvba: vrey nice work, r=me
[11:10] <rvba> adeuring: thanks for the review!  We will see how this improves the performance of the page in question.
[11:11] <adeuring> rvba: right, it's hard to predict. Might be worth to try the query on staging
[11:12] <rvba> adeuring: I've had the query run on production a few times and it improved things quite a lot.
[11:12] <adeuring> rvba: even better
[11:12] <rvba> 4.5s → 2s
[11:12] <rvba> This is still not ideal but that's a start.
[11:13] <adeuring> rvba: right, but 2 seconds is uite good for such a complex query. There might be other parts of the code that could be improved
[11:13] <jtv> It's quite a lot, from the sound of it.
[11:14] <rvba> adeuring: one the runs: https://pastebin.canonical.com/55946/
[11:16] <cjwatson> jtv: frankly, most of the time I don't use +queue because every time I do it times out so much that I regret it.  (Even though I know I should use +queue in preference to privileged shell commands if possible.)
[11:17] <cjwatson> The last time I tried to use +queue it timed out even displaying the queue.
[11:17] <cjwatson> It's working at the moment - for now
[11:18] <jtv> cjwatson: I found a 0.8s query in there that was repeated several times, that I got down to 0.2—0.3ms.  I just Q/A'ed it, so it should be on production soon.  I'd like to ask you to try it again, and please please keep a very critical eye on it both in terms of performance and correctness.
[11:18] <jtv> That's when submitting the form; I don't think it'll help page display.
[11:18] <jtv> I do know that query is used in a few other places though, so hopefully you'll feel improvements in several places.
[11:19] <cjwatson> jtv: OK, that's good, I'll go back to trying to use it from time to time
[11:19] <cjwatson> (+queue still has several other awkwardnesses that block me from using it for everything, though.)
[11:19] <jtv> cjwatson: thanks.  Given how important and complex the code is, the sooner you can give it the third degree the better!
[11:20] <cjwatson> Notably https://bugs.launchpad.net/launchpad/+bug/828649.
[11:20] <_mup_> Bug #828649: queue UI: apparently no way to override individual binaries <derivation> <queue-page> <Launchpad itself:Triaged> < https://launchpad.net/bugs/828649 >
[11:21] <jtv> Well, one step at a time!  I'm particularly concerned that this should be correct, and it seems the same query pops up in other places as well.
[11:21] <cjwatson> I've also passed your request on to others; for example I think pitti uses +queue more than I do, for stable release managemnt
[11:21] <cjwatson> +e
[11:22] <jtv> Thanks!
[12:12] <rick_h_> morning
[12:18] <rvba> morning rick_h_
[12:33] <deryck> Morning, folks.
[12:34] <rick_h_> morning
[12:34] <rick_h_> http://blog.labix.org/2011/11/17/launchpad-rietveld-happycodereviews is crazy. I was complaining to jcastro that lp needed to integrate reviewboard for years and then there's this hah
[14:32] <mrevell> rick_h_, dev.launchpad.net/Projects/CustomBugListings
[15:02] <gary_poster> adeuring or bac, when/if you get a chance could you please review https://code.launchpad.net/~gary/launchpad/bug724609/+merge/82689?
[15:02] <bac> gary_poster: i will
[15:02] <gary_poster> thanks bac
[15:05] <gary_poster> thanks for tackling buildbot allenap. I was just about to start, and am still willing to, but if you are happy with fixing it, that's great by me
[15:05] <gary_poster> I'll go do some more CHR :-P
[15:09] <allenap> gary_poster: I'm happy to do it.
[15:09] <gary_poster> cool thanks again allenap
[15:11] <allenap> No worries :)
[16:22] <jcsackett> adeuring or bac: can i add https://code.launchpad.net/~jcsackett/launchpad/private-bugs-open-teams-and-delegate-teams-oh-my/+merge/82703 to your review work today?
[16:22] <bac> jcsackett: i will take it now
[16:22] <jcsackett> thanks, bac.
[16:22] <sinzui> jcsackett,  I want to run this in production to clean up the data to match the rules in production: http://pastebin.ubuntu.com/742379/
[16:23] <jcsackett> sinzui: taking a look now.
[16:29] <jcsackett> sinzui: this looks fine to me.
[16:30] <jcsackett> do our new rules require maintainer roles to be exclusive? that must have drifted pass me in the email masses.
[16:31] <sinzui> jcsackett, yes. they do. The maintainer automatically get access to all private and security issues in a project.
[16:31] <jcsackett> sinzui: oh right. that makes sense.
[16:31]  * jcsackett is not completely with it yet, today.
[16:35] <timrc> is there anyway updates to staging can be done in the background and then brought to the foreground as soon as they are done to cause minimal disruption of service? or was I completely crazy to use staging for testing purposes?
[16:36] <jcsackett> bac: thanks for the review.
[16:36] <allenap> bac: Up for a short review? https://code.launchpad.net/~allenap/launchpad/a-moment-ago-1/+merge/82706
[16:41] <timrc> and why are we doing updates on a Friday? that seems dubious at best
[16:41] <sinzui> timrc, staging's DB has not been updated on 7 weeks
[16:42] <timrc> so maybe it's just my luck :)?
[16:42] <sinzui> It is so stale that its data does not match the rules in production code
[16:42] <timrc> it seems that whenever I need to run these unit tests (which work against staging), there's a disruption of service
[16:42] <sinzui> timrc, staging should update on our saturdays. It has a long history of irregularity. I think it updated only 26 times last year
[16:44] <sinzui> timrc It does get code updates several times a day. It has been unavailable more than usual because of the failed DB restores I think
[16:44] <timrc> sinzui, is there any reason why we can't have two copies of staging? while one is getting updated, the other is serving requests?
[16:44] <sinzui> timrc, we do. qastaging
[16:44] <timrc> ah okay, so I should write my tests to try one and then default to the other?
[16:45] <sinzui> its data is really ancient
[16:45] <timrc> sinzui, the data matters not to me, as long as the api is consistent
[16:46] <sinzui> timrc, it is. I often switch by scripts between staging and qastaging based on availability.
[16:46] <timrc> sinzui, awesome
[16:46] <timrc> I had it in my head that qastaging was something that was for internal use by the LP team
[16:47] <jcsackett> timrc: we will do horrible things to qastaging's data in the pursuit of qa. if you don't care about that, meh, no worries. :-)
[16:47] <jcsackett> sinzui: you want/have time to mumble?
[16:48] <timrc> jcsackett, nah, I just need to be able to file bugs against a certain project and then verify things are set correctly...
[16:48] <jcsackett> sounds like an excellent use of qastaging, then. :-)
[16:49] <timrc> jcsackett, sinzui: thanks for your assistance / guidance
[16:51] <bac> allenap: sure
[16:52] <allenap> Thanks.
[16:57] <allenap> Thanks Brad.
[17:30] <sinzui> jcsackett, yes
[17:33] <jml> I find myself missing buildout.
[17:33] <jml> What's wrong with me?
[17:59]  * deryck must have been too loud in the coffee shop call with rick_h_ 
[17:59] <deryck> people are staring at me oddly
[18:03] <deryck> jml, I like buildout.
[18:04] <deryck> maybe something's wrong with me though ;)
[18:04] <jml> deryck: I find it compares favourably to pip+virtualenv
[18:04]  * jml has to go
[18:04] <jml> crap. am late
[18:04] <deryck> later!
[18:12] <rick_h_> deryck: so the two bugs that have pqm success messages I can move the cards to "deployment ready"?
[18:13] <deryck> rick_h_, ah, no, not yet... :)
[18:13] <rick_h_> ok cool
[18:13] <deryck> rick_h_, they need to play in buildnot for anywhere from 4-72 hours depending on how much buildnot hates you....
[18:13] <rick_h_> ok, makes sense. wasn't sure what level was "ready" and "done"
[18:14] <deryck> rick_h_, whenever it does merge to "stable" from "devel" which happens after the rarely succesful buildnot run....
[18:14] <deryck> rick_h_, you'll get an email that the bug was updated with "qa-needstesting" tag...
[18:14] <deryck> rick_h_, and then you'll need to manually qa your change on our qastaging server.
[18:14]  * deryck looks for a wiki page
[18:15] <deryck> rick_h_, https://dev.launchpad.net/QA/QAForContinuousRollouts
[18:15] <rick_h_> ty
[18:15] <deryck> rick_h_, that should explain how to qa and how to tag the bugs.
[18:16] <deryck> rick_h_, if you have questions when you get to it, just grab one of us on irc.
[18:16] <rick_h_> will do
[18:16] <deryck> rick_h_, and of course the "rarely successful build" stuff was me joking.  ... mostly. ;)
[18:28] <timrc> sinzui, does LP reap bugs marked as 'invalid' on staging and qastaging or do they persist?
[18:44] <abentley> timrc: I'd be surprised if they have special handling.  Everything gets wiped when we do a full restore.
[18:46] <abentley> bac: could you please review https://code.launchpad.net/~abentley/launchpad/pre-cache-batches/+merge/82716 ?
[19:02] <deryck> ok, I'm out.  Later on, everyone!
[19:48] <bac> abentley: at line 214 of your MP are the args in the right order?
[19:49] <abentley> bac: looks right to me.
[19:50] <abentley> Y.bind takes function, this, and then optional function parameters.
[19:51] <abentley> bac: So the output of load_model will be the third parameter to update_from_new_model
[19:52] <sinzui> timrc, abentley is correct. We lets the odd data accumulate because we expect a db restore to happen on Saturdays. And I do expect one tomorrow since the slony update was successful in production
[19:54] <bac> abentley: the signature is:  update_from_new_model: function(query, fetch_only, model){
[19:54] <bac> abentley: and the bind is:
[19:54] <bac> +                success: Y.bind(
[19:54] <bac> 214	+                    this.update_from_new_model, this, query, fetch_only),
[19:54] <bac> abentley: ok, nm, i see where i was misreading it
[19:55] <abentley> bac: I hate non-bound instance methods with a fiery passion, if that makes you feel any better.
[19:56] <bac> abentley: it is confusing.  but in my head i saw query and fetch_only reversed
[19:58] <abentley> bac: ah.
[20:08] <abentley> bac: thanks for the reivew.
[20:08] <rick_h_> http://www.youtube.com/watch?v=wCexiX_eUJA&feature=youtu.be&hd=1 YUI MVC yay
[20:26] <sinzui> jcsackett, Can you look at the revised SQL to update production? https://pastebin.canonical.com/56052/ We are certain that the script does not need to check for open teams in open teams.
[20:33] <sinzui> ^ bac can you look at the SQL I want to run in production?
[20:34]  * bac looks
[20:34] <benji> the Fedora Board is asking us what should be done with https://launchpad.net/fedora (at https://launchpad.net/fedora).  If anyone has things I should tell them (or would like to say yourself), let me know.
[20:36] <sinzui> benji, We cannot delete it or deactivate it without a code change. The data is not valuable. I have long wanted to be able to delete or deactivate distros that mis inform users that they can contribute to fedora using Lp
[20:37] <jcsackett> sinzui: looks fine to me, given your assurances.
[20:37] <bac> sinzui: the SQL looks good to me.
[20:38] <sinzui> jcsackett, thedac confirms the expensive part of my failed query never return exceptions to avoid
[20:38] <jcsackett> sinzui: that's very good to know.
[20:40] <benji> sinzui: in that case I'll tell them the first bit ("We cannot delete it or deactivate it without a code change.") and leave it at that.  They'll probably loose interest after that.
[20:40] <sinzui> benji, I image two strategies if this becomes important:
[20:41] <sinzui> pistol: Update db to obfuscate "fedora"
[20:42] <sinzui> whip: add active column to schema, update sets/searches to only list active distros; send a 404 when users visit deactivated distros
[20:44] <benji> sounds reasonable, thanks sinzui
[21:03] <benji> bac: heh; I'm glad my CHR is over for today.
[21:04] <rick_h_> CHR?
[21:12] <benji> rick_h_: two things 1) I am aflicted with cross-channel-itis; which means that I sometimes reply to someone in a different channel than the one in which they were speaking to me, and 2) the maint. teams do things like triage bugs and answer user questions and it's called CHR
[21:12] <rick_h_> ok, I see a lot of nicknames/codes flying and try to make sense of them. Couldn't figure out what CHR would stand for
[21:13] <bac> rick_h_: Community Help Rotataion -- come on, man, that should be obvious
[21:45] <flacoste> gary_poster: do you remember the distribute mess?
[21:45] <flacoste> specifically, i'm trying to run lazr.restful tests
[21:45] <flacoste> but running bootstrap.py it's trying to grab distribute
[21:45] <flacoste> and then all hell breaks loose
[21:46] <flacoste> because distribute is worst than freebase
[21:49] <gary_poster> flacoste, heh
[21:49] <gary_poster> I vaguely remember this.
[21:50] <gary_poster> flacoste, I think if you use a clean python, it all works
[21:50] <flacoste> that's not the answer i'm looking for :-)
[21:50] <flacoste> it's bootstrap.py seems antique compared to lazr.restfulclient
[21:50] <flacoste> which worked fine
[21:50] <flacoste> so i'll try to update this first
[21:50] <gary_poster> flacoste, I think I tried this and it did not work
[22:01] <flacoste> gary_poster: seems to have done the trick
[22:01] <flacoste> oh, and i added include-site-packages = false in buildout.cfg
[22:01] <flacoste> as that's what we want for lazr components
[22:01] <flacoste> usually
[22:01] <flacoste> closer to what virtualenv gives you
[22:01] <flacoste> that's a geat change you made there
[22:01] <flacoste> sucky that upstream isn't keeping this
[22:03] <gary_poster> flacoste, I'm glad it worked for you.  I do think I found a problem with the new stuff when I tried it for lazr.restful.  Maybe it had to do with a dependency?  I'd be happy to review it/try to break it on Monday if you wanted.  If it works, that would be great
[22:04] <flacoste> hmm, it's now building lxml2...
[22:04] <flacoste> do we really need that dependencies
[22:04] <flacoste> sigh
[22:04] <gary_poster> :-)
[22:04] <gary_poster> I have to run go pick up kids
[22:04] <gary_poster> bye, have a great weekend
[22:23] <rick_h_> bac: doh!
[22:25] <sinzui> I am seeing about 10,000 private branches that the project owners cannot access.
[22:26] <sinzui> I think I need to discount merged branches...but I believe that team/person merges, and team/project restructuring easily looses branches
[22:54] <timrc> 289 critical bugtasks... what's the prize for reaching 300?
[23:02] <sinzui> seppuku
[23:04] <sinzui> I was tempted last night to delete everything in my local lp branch and propose it for merging with devel because it would 80% of all Lp bugs
[23:08] <wgrant> sinzui: +1
[23:24] <iamfuzz> wgrant, so glad to see you :-)
[23:28] <wgrant> Uhoh!
[23:29] <wgrant> iamfuzz: What broke?
[23:29] <iamfuzz> wgrant, Actually went smoother than expected, but I can't get the buildd to kickoff a build
[23:29] <iamfuzz> wgrant, I uploaded two packages, and they're both still just sitting there waiting
[23:29] <iamfuzz> wgrant, I enabled bob the builder (nice touch)
[23:30] <iamfuzz> wgrant, but he seems lazy today
[23:30] <iamfuzz> wgrant, and the queue shows nothing
[23:30] <iamfuzz> wgrant, I go to my ppa, and there they sit waiting to build
[23:31] <wgrant> iamfuzz: bob is a non-virtual builder, PPAs default to virtual.
[23:31] <iamfuzz> wgrant, can i lie and just check that box?
[23:31] <wgrant> Head over to https://launchpad.dev/builders/bob/+edit, check "Virtual", enter anything at all into the VM host box, and see if that solves it.
[23:32] <wgrant> Yeah, the command the dev config uses to reset the VM is "echo $vmhost"
[23:32] <wgrant> So it will always succeed.
[23:34] <iamfuzz> wgrant, looks like that did the trick!
[23:34] <iamfuzz> wgrant, so is it really as simple as installing launchpad-buildd on another box, then entering its details into LP and voila, another builder?
[23:34] <iamfuzz> wgrant, I assume remote builders will upload files back to the soyuz host properly?
[23:36] <wgrant> iamfuzz: You'll probably need to play around with /etc/hosts and/or DNS to get it to resolve ppa.launchpad.dev/archive.launchpad.dev/launchpad.dev, but yeah, pretty much.
[23:57]  * nigelb waves from a closer timezone!
[23:58] <iamfuzz> wgrant, how does one create apt sources for the buildds to pull from?
[23:58] <iamfuzz> wgrant, I ran this guy: scripts/ftpmaster-tools/manage-chroot.py -s lucid -a i386 add -f chroot-ubuntu-lucid-i386.tar.bz2
[23:58] <iamfuzz> wgrant, but get a dependency wait on everything still