StevenK | wallyworld_: O hai | 01:24 |
---|---|---|
wallyworld_ | hellooooooo | 01:24 |
StevenK | wallyworld_: I'm on mumble and ready when you are. | 01:26 |
wgrant | wut | 02:12 |
wgrant | https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-006ee065b5671473827829630f869283 | 02:12 |
wgrant | Why is something trying to serialise a bug into rabbit? | 02:12 |
StevenK | wgrant: I was about to ask you about that. | 02:13 |
wgrant | Unless we're for some reason deciding to send notifications for all objects to rabbit. | 02:14 |
StevenK | Why would we do that? It makes no sense. | 02:14 |
wgrant | So it was making the bug private. | 02:16 |
wgrant | s/private/public/ | 02:16 |
wgrant | Which somehow fires off a rabbit notification because why not. | 02:16 |
wgrant | Huh | 02:17 |
wgrant | So indeed | 02:17 |
wgrant | Anything with a base class of Storm will get rabbit notifications. | 02:17 |
wgrant | If the changed fields are JSONable, the world ends. | 02:18 |
wgrant | aren't. | 02:18 |
StevenK | Strange. | 02:19 |
=== poolie_ is now known as poolie | ||
lifeless | poolie: would you have time for a chat today? | 02:40 |
lifeless | poolie: in an hour or two from now ? | 02:40 |
poolie | lifeless, sure | 02:45 |
lifeless | poolie: how about now ? | 03:30 |
=== matsubara is now known as matsubara-afk | ||
poolie | lifeless, oops, how about now? | 04:43 |
lifeless | poolie: sure, ring me? | 04:46 |
=== almaisan-away is now known as al-maisan | ||
poolie | lifeless, engaged? | 04:52 |
=== al-maisan is now known as almaisan-away | ||
wallyworld_ | wgrant: with access policies and bugs - access policies are associated with pillars, a bug has bug tasks associated with pillars, what is a person is denied access to a pillar, it seems that they can still see the bug even if it has a bug task they cannot see | 05:44 |
StevenK | Access to a bug is defined via bugtasks | 05:44 |
wgrant | An access grant is for a bug, not a bugtask. | 05:44 |
wgrant | You can never see a partial bug. | 05:45 |
wgrant | The people who can see a private bug are anyone with a grant on the related policies or an explicit grant for the bug. | 05:45 |
wgrant | This means that revoking a policy grant may leave access to some bugs. | 05:45 |
wallyworld_ | that's the crux of my question i think | 05:46 |
wgrant | (this can't happen with a true proprietary project, because bugs can't be shared) | 05:46 |
wgrant | Also, fuck bug tasks, seriously. | 05:46 |
wallyworld_ | wgrant: the sharing details page emits bugtask urls at the moment - the page is associated with a pillar, it iterates over the bug tasks and picks the one for that pillar. i should change it to just emit the bug url i think | 05:47 |
wgrant | wallyworld_: It's not a problem either way. | 05:48 |
wgrant | You can either see all bugtasks (modulo those on deactivated projects), or you can't see any at all. | 05:48 |
wallyworld_ | it is because the exported api on sharing service breaks | 05:48 |
wallyworld_ | it has a param which is a List(Ibug) | 05:49 |
wallyworld_ | and instead it is getting IBugTask from the XHR call | 05:49 |
wgrant | Ah | 05:49 |
wgrant | Sure | 05:49 |
wallyworld_ | so i should just change the logic on the sharing page - if *any* bugtask is associated with the pillar, emit the bug url | 05:50 |
wallyworld_ | sharing details page i should say | 05:50 |
wgrant | No need to consider bugtasks at all in that case. | 05:50 |
wallyworld_ | well, the page has a context which is a pillart | 05:50 |
wgrant | If APGF references an AA that references a Bug, that Bug is relevant. | 05:51 |
wgrant | You are already context-filtered by APGF | 05:51 |
wallyworld_ | so the url is lp.net/pillar/+sharingdetails/person | 05:51 |
wgrant | Sure | 05:51 |
wallyworld_ | the details page should only show bus and branches associated with the pillar | 05:51 |
wgrant | And that will say SELECT bug from apgf join aa join bug where apgf.policy IN (SELECT id FROM accesspolicy WHERE product=pillar) | 05:52 |
wallyworld_ | so how to tell if a bug is associated with the pillar - it has a bugtask targetted at the pillar | 05:52 |
wgrant | You're already only getting bugs that are associated with the pillar. | 05:52 |
wgrant | AccessPolicyArtifact (which is flattened into APGF) already handles that. | 05:52 |
wgrant | There are triggers which mirror BugTasks' pillars into APAs. | 05:52 |
wallyworld_ | right ok. so there's some existing erroneous logic in the view code i'll just remove. cool. i like deleting code :-) | 05:53 |
wallyworld_ | i didn;t write it originally so wasn't 100% sure, just wanted to check | 05:53 |
wallyworld_ | thanks | 05:54 |
StevenK | wallyworld_: Setting the link has FF follow it explicity | 06:03 |
StevenK | wallyworld_: And moving to the JS module has broken it, so I guess I'll grab you after the call tomorrow and work through it. | 06:08 |
nigelb | bigjools: re:timezone, it was mentioned as part of a talk that I'm supposed to be listening to. | 06:17 |
bigjools | yes...? :) | 06:17 |
nigelb | bigjools: so... I have no clue what timezone :P | 06:19 |
bigjools | heh | 06:19 |
=== almaisan-away is now known as al-maisan | ||
wallyworld_ | StevenK: ok. if i get a chance before then i'll look | 06:40 |
wgrant | lifeless: Around? | 07:35 |
lifeless | kinda | 07:36 |
wgrant | lifeless: Is the pgbouncer ProgrammingError hack in Storm your doing? | 07:36 |
lifeless | no | 07:37 |
StevenK | wallyworld_: I can paste a diff if you want to look? | 07:37 |
lifeless | allenap I think | 07:37 |
wgrant | if isinstance(exc, disconnection_errors): | 07:37 |
wgrant | # When the connection is closed by a termination of pgbouncer, a | 07:37 |
wgrant | # ProgrammingError is raised. If the raw connection is closed we | 07:37 |
wgrant | # assume it's actually a disconnection. | 07:37 |
wgrant | if isinstance(exc, ProgrammingError): | 07:37 |
wgrant | if self._raw_connection.closed: | 07:37 |
wgrant | return True | 07:37 |
wgrant | Ah | 07:37 |
lifeless | possibly stub | 07:37 |
lifeless | I wrote the pgbouncer fixture | 07:38 |
lifeless | that was all | 07:38 |
wgrant | Ah, I see. | 07:38 |
wgrant | Bug #959699 | 07:40 |
_mup_ | Bug #959699: test failure: test_pgbouncer_stopped <Storm:New> < https://launchpad.net/bugs/959699 > | 07:40 |
wgrant | lifeless: Any opinions? | 07:40 |
wgrant | Upgrading psycopg2 to 2.4 seems painless except for that. | 07:41 |
lifeless | wgrant: I think upgrading is mandatory isn't it ? | 07:48 |
wgrant | lifeless: Yes. | 07:50 |
wgrant | lifeless: Well | 07:50 |
wgrant | I could backport the changes. | 07:50 |
wgrant | But that seems like just delaying the inevitable. | 07:50 |
wgrant | Extending the check to also allow DatabaseError unbreaks everything. | 07:51 |
wgrant | But seems bad. | 07:51 |
adeuring | good morning | 07:55 |
allenap | wgrant: That's mine (the pgbouncer hack). | 07:58 |
wgrant | allenap: Yeah, I see you also filed a bug upstream about this thing and disabled the relevant Storm tests. | 07:59 |
wgrant | The new exception seems legitimate. | 08:00 |
wgrant | So I think I'll fix Storm to accept it and undisable the tests. | 08:00 |
allenap | wgrant: Tip top. | 08:00 |
allenap | Thank you. | 08:00 |
mabac | StevenK, hi there! thanks for reviewing the team-engineering view. I've run format-imports on the changed files. is there anything else that needs fixing? | 08:06 |
=== al-maisan is now known as almaisan-away | ||
StevenK | mabac: I'd prefer the feature flag change name since it isn't reigstry. But mabac: I'd prefer the feature flag change name since it isn't reigstry. But mabac: I'd prefer the feature flag change name since it isn't reigstry. But that isn't a requirement. | 09:20 |
nigelb | StevenK: Is there a joke I'm missing? Or did you just type that out 3 times? | 09:21 |
StevenK | No, I just fail at keyboard. | 09:22 |
nigelb | Haha. FAIL. | 09:23 |
mabac | StevenK, ok thanks. I'll scratch my head on that one. is there any guidelines about feature flags I can have a look at? that bit is all new to me | 09:24 |
nigelb | There's a wiki.. somewhere. | 09:27 |
mabac | thanks | 09:29 |
mabac | https://dev.launchpad.net/FeatureFlags#Naming_conventions | 09:29 |
nigelb | Ohman. I fail at finding things on launchpad wiki. | 09:30 |
mabac | StevenK, so it's the "area" part that you'd prefer to change? this is a page for a team which displays blueprint work items and bugs for upcoming milestones. can the feature flag be named 'team.upcoming_work_view.enabled' ? | 09:32 |
jml | is it actually possible to do Launchpad development on precise? | 09:59 |
jml | launchpad-developer-dependencies : Depends: launchpad-messagequeue-dependencies (= 0.110~precise1) but it is not going to be installed | 09:59 |
lifeless | jml: does precise still have python2.6? | 10:04 |
lifeless | jml: my usual recommendation - lxc - will be made now. | 10:04 |
* lifeless recommends lxc | 10:04 | |
nigelb | heh | 10:04 |
jml | lifeless: it has python 2.6 | 10:09 |
cjwatson | it may have python 2.6 but it won't have many useful modules for it | 10:18 |
cjwatson | (afaik) | 10:18 |
jml | I'm following instructions on https://dev.launchpad.net/Running/LXC | 10:42 |
jml | but I don't seem to be able to log in to the lxc I've created. | 10:42 |
wgrant | jml: Your normal username and password should work | 10:43 |
wgrant | root/root used to work, but I don't think it does any more. | 10:43 |
jml | wgrant: ah right. my password too, that was the trick. | 10:43 |
matsubara | morning! | 11:26 |
rick_h | morning | 11:28 |
lifeless | nn | 11:34 |
mabac | rick_h, hi there! would you land the team-work-ui for me? we've discussed the feature flag name but will leave it as is. the formatting has been fixed. https://code.launchpad.net/~linaro-infrastructure/launchpad/team-engineering-view-ui/+merge/100707 | 11:42 |
=== jtv1 is now known as jtv | ||
rick_h | mabac: sure thing | 11:43 |
mabac | rick_h, cool, thanks! | 11:44 |
rick_h | mabac: can you set the commit message on your MP please? | 11:45 |
mabac | rick_h, oh sure | 11:45 |
mabac | rick_h, done | 11:48 |
rick_h | is there a bug to link this to? | 11:48 |
rick_h | mabac: ^^ or should I land this no-qa? | 11:51 |
jml | I'm getting a recursion error when running 'make schema': http://pastebin.ubuntu.com/914410/ | 11:51 |
mabac | rick_h, we have tested it a bit on staging but I'm not sure. | 11:52 |
mabac | salgado, do you think it can land as no-qa? | 11:52 |
salgado | rick_h, mabac, the new page is protected by a feature flag, so I think so? | 11:52 |
mabac | rick_h, that's right it's just us who are going to see it now anyway | 11:53 |
rick_h | mabac: how about just creating a quick bug to link it to noting about adding it and then we can go through the normal qa process | 11:53 |
mabac | rick_h, so yes, it's ok | 11:53 |
rick_h | not checked out the change, but just to play it safe | 11:54 |
mabac | rick_h, ok will do | 11:55 |
rick_h | thanks mabac, sorry to drag through the process more. | 11:56 |
mabac | rick_h, no problem | 11:56 |
mabac | rick_h, bug 973322 | 12:03 |
_mup_ | Bug #973322: We need a UI for the team engineering view <Auditor:New> < https://launchpad.net/bugs/973322 > | 12:03 |
jml | ah, ok | 12:03 |
jml | the version of bzr in Launchpad doesn't support colocated branches. | 12:04 |
jml | bugger. | 12:04 |
StevenK | mabac: It should not land as qa-ok | 12:04 |
jml | you guys really do like to make things hard for yourselves. | 12:04 |
StevenK | mabac: You want to link the bug to the MP, have the webops enable the feature flag and give it a bit of testing on qas, just to make sure. | 12:04 |
mabac | StevenK, ok thanks | 12:05 |
StevenK | When it hits qas, of course. :-) | 12:05 |
rick_h | StevenK: yep, that's where we're headed | 12:07 |
mabac | rick_h, StevenK salgado I've linked the bug to the branch | 12:09 |
rick_h | mabac: awesome, thanks | 12:09 |
mabac | rick_h, salgado I'll drop offline for half an hour to go home. will resurface asap and look out for trouble ;) | 12:10 |
rick_h | mabac: ok, landing has started, waiting on ec2 to kick up | 12:11 |
mabac | rick_h, great thanks! | 12:11 |
jml | wuu, running tests locally | 13:28 |
jml | uhhhhh | 13:30 |
jml | why does the Launchpad PPA have dpkg? | 13:30 |
jml | Get: 1 http://ppa.launchpad.net/launchpad/ppa/ubuntu/ lucid/main dpkg 1.15.5.6ubuntu4.5+launchpad1 [2,193kB] | 13:30 |
jelmer | jml: support for .orig.tar.xz files in source packages or something IIRC | 13:32 |
jelmer | jml: have you checked the changelog ? :) | 13:33 |
jml | jelmer: I don't really know how to do that without installing | 13:33 |
StevenK | Download the diff and zcat it | 13:34 |
jelmer | jml: you can see it on the PPA page | 13:34 |
jelmer | or, at least the last entry, which is usually the most relevant | 13:34 |
jelmer | https://launchpad.net/~launchpad/+archive/ppa/+packages | 13:34 |
jml | jelmer: thanks. | 13:36 |
cjwatson | StevenK: native packages don't have a diff | 13:43 |
cjwatson | dpkg in the LP PPA is mostly my fault. It can go away once LP upgrades to precise (at least until the next time there's a requirement for a new dpkg feature) | 13:44 |
jml | heh | 13:53 |
jml | I have an approved branch, could someone please land it? https://code.launchpad.net/~jml/launchpad/create-commercial-ppa/+merge/100635 | 13:53 |
=== almaisan-away is now known as al-maisan | ||
rick_h | jml: can you create/link the MP to a bug so it goes through normal qa please? | 14:09 |
rick_h | jml: after that I'll ec2 land it for you | 14:10 |
rick_h | jml: ty, running ec2 land now | 14:16 |
rick_h | see you tomorrow lol | 14:16 |
jml | rick_h: thank you. | 14:16 |
=== abentley changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: abentley | Firefighting: - | Critical bugtasks: 4*10^2 | ||
jcsackett | sinzui: you free for a short chat? | 14:45 |
salgado | abentley, I've got a small-ish one up for review if you've got some time: https://code.launchpad.net/~linaro-infrastructure/launchpad/upcoming-work-progress-bars/+merge/100808 | 14:55 |
abentley | salgado: sure. | 14:55 |
sinzui | jcsackett, I am, but let me kill some windows processes to be certain I have CPU and memory to chat | 14:55 |
=== al-maisan is now known as almaisan-away | ||
jcsackett | sinzui: ok. | 14:58 |
czajkowski | sinzui: is this something the new privacy stuff will address on bugs do you think? https://bugs.launchpad.net/launchpad/+bug/973228 | 15:04 |
_mup_ | Bug #973228: "Affects me too" text should acknowledge that you are affected by a duplicate <Launchpad itself:New> < https://launchpad.net/bugs/973228 > | 15:04 |
sinzui | czajkowski, no, that is a feature request | 15:04 |
sinzui | affects me too never manages duplicates. I suspect the bug is already reported | 15:05 |
sinzui | jcsackett, my experiment is making this difficult. Can we try a hangout via google messenger | 15:06 |
czajkowski | sinzui: thanks | 15:06 |
abentley | salgado: can items ever be 0? | 15:09 |
jcsackett | sinzui: we can try, sure. | 15:11 |
salgado | abentley, you mean a container having no items? that would be a bug in our code | 15:12 |
abentley | salgado: Okay. Your tests need docs, but r=me. | 15:13 |
salgado | abentley, thanks a bunch, I'll add them | 15:13 |
abentley | adeuring: Could you please review https://code.launchpad.net/~abentley/launchpad/celery-rabbit-config/+merge/100813 ? | 15:38 |
adeuring | abentley: sure | 15:38 |
adeuring | abentley: r=me | 15:43 |
abentley | adeuring: Thanks. | 15:44 |
=== matsubara is now known as matsubara-lunch | ||
=== deryck is now known as deryck[lunch] | ||
salgado | abentley, added docs and fixed one of the tests to create specs explicitly and with different priorities so that they're always in the same order | 16:20 |
salgado | abentley, the prerequisite branch is being ec2-landed now. would you mind ec2-landing this one as well? if the prerequisite one fails on ec2 this one will fail as well, but if they both pass they will land in the correct order | 16:21 |
salgado | there's a chance that the ec2 run of the first one may die or have spurious failures and the second one goes through, though | 16:22 |
=== salgado is now known as salgado-lunch | ||
=== salgado-lunch is now known as salgado | ||
salgado | abentley, actually, the prerequisite branch just landed | 16:59 |
abentley | salgado: Ah. | 16:59 |
abentley | salgado: Even if it hadn't, it doesn't matter to me whether two reviewed branches land in a single revision or separately. | 17:00 |
salgado | abentley, I was concerned it could affect the qa-tagger but I guess both bugs would still be linked to that single revision? | 17:01 |
abentley | salgado: they should. | 17:01 |
bac`` | sinzui: you should go back to bed ... until monday. | 17:27 |
=== bac`` is now known as bac | ||
=== deryck[lunch] is now known as deryck | ||
timrc | you guys gave sinzui a bed? wow, nice | 17:34 |
sinzui | timrc, my bed has a computer and tablet next to it. I just work reclined | 17:36 |
* sinzui sometimes wishes that was not true | 17:36 | |
timrc | sinzui, lol | 17:40 |
=== matsubara-lunch is now known as matsubara | ||
rick_h | deryck: working on getting python-ooptools going and when it has you create the user the passwordless bit isn't owrking right | 17:55 |
rick_h | deryck: it has a -a flag which --help doesn't show, should that be something else? | 17:55 |
rick_h | deryck: from: sudo -u postgres /usr/lib/postgresql/8.4/bin/createuser --port 5433 -a -d $USER | 17:55 |
deryck | rick_h, seems like there was a step before that. schema and migrations. | 17:56 |
rick_h | that seems to come afterwards | 17:57 |
rick_h | deryck: I'm working on getting the second cluster up and need to create the db | 17:57 |
rick_h | but need my account to have perms to do so | 17:57 |
deryck | rick_h, I think I did this straight out of the README. let me look at bash history | 17:59 |
rick_h | deryck: thanks, yea what I'm trying to follow. In the end I'm tempted to just create a user with -s -P and move on since it's a local dev env and it's how I've setup my account before on other dbs | 17:59 |
rick_h | deryck: but if I'm missing someting would like to fix the README | 18:00 |
deryck | rick_h, too long ago now for me to have bash history, but I really don't think I changed anything in the commands... | 18:01 |
deryck | rick_h, but it does seem like I reordered someone them to what logically made sense, and things "just worked." | 18:01 |
rick_h | deryck: ok | 18:02 |
=== almaisan-away is now known as al-maisan | ||
deryck | rick_h, I also used an email from lifeless to launchpad-dev as reference too. let me see if I can find that | 18:03 |
=== al-maisan is now known as almaisan-away | ||
abentley | deryck: I want to test some jobs that send emails, but we usually test email in-process. Any idea how to do this? | 18:05 |
rick_h | deryck: probably https://lists.launchpad.net/launchpad-dev/msg08183.html and the email "shortcut for getting python-oops-tools running" | 18:06 |
deryck | rick_h, yup, was just about to paste you a bit of that. | 18:06 |
deryck | abentley, thinking.... | 18:06 |
rick_h | deryck: ok, both seem to assume the current db notes are correct so I'll give it another go, maybe I've missed something. -a just doesn't show up in --help so seemed might be a typo. | 18:07 |
deryck | rick_h, same version of postgres as readme, i.e. 8.4 and not 9? | 18:08 |
rick_h | yea, the command has the full path to the 8.4/bin | 18:08 |
deryck | abentley, you want to test the mail sent by the job? i.e. inspect the mail? Or test that the job fires off mail? | 18:10 |
abentley | deryck: I am okay just testing that the job fires off mail. Unit tests handle the actual text. | 18:11 |
rick_h | deryck: doh, my fault. I didn't use the patch but manually edited pg_hba.conf and didn't do it right | 18:11 |
rick_h | deryck: thanks, sorry for the timesink | 18:11 |
deryck | rick_h, np! :) | 18:11 |
deryck | abentley, use some sort of faker mailer that stores what's sent in a variable you can inspect after the job completes? | 18:12 |
deryck | s/faker/fake/ | 18:12 |
rick_h | deryck: abentley I keep meaning to try this out sometime: http://bazaar.launchpad.net/~bloodearnest/+junk/test-email-server/view/head:/README | 18:14 |
abentley | deryck: I guess, but then the problem is convincing an arbitrary Launchpad job to use a fake mailer. | 18:14 |
rick_h | ah right, running that on qa would be a bit out of the ballpark | 18:15 |
deryck | abentley, yeah, true. | 18:16 |
deryck | abentley, do all jobs use the same mechanism to send mail? Can you monkeypatch orotherwise intercept the thing sending mail before or after and test that somehow? | 18:18 |
abentley | deryck: potentially yes, but it's a subprocess, so you have to trigger the monkeypatching somehow. | 18:19 |
deryck | abentley, ah. yuck. it is kind of messy then. | 18:20 |
=== beuno is now known as beuno-lunch | ||
deryck | abentley, sorry, I'm a bit stumped myself. | 18:20 |
abentley | deryck: Well, worst case, I guess we can do an environment variable like USE_FAKE_MAILER. | 18:21 |
deryck | abentley, ah, yeah, that would work. | 18:22 |
abentley | deryck: Oh, I've got it. I can write a celery Task that does mail_helpers.pop_notifications. | 18:23 |
deryck | abentley, nice! | 18:24 |
lifeless | moin | 18:35 |
rick_h | jml: heads up, emailed ec2 test results to you | 18:59 |
=== beuno-lunch is now known as beuno | ||
salgado | abentley, in case you still have some time today, I have another branch for review (https://code.launchpad.net/~salgado/launchpad/person-upcoming-work-view/+merge/100878). It looks big but ~95% of it is just moving code around | 20:47 |
abentley | salgado: looking | 20:48 |
abentley | salgado: 320-321 can be written containers_by_date.setdefault(milestone.dateexpected, []) | 20:54 |
salgado | abentley, I'm not a big fan of setdefault() but I can do that | 20:57 |
abentley | salgado: I'm just mentioning it. I like it. Especially since it returns the value, and you can do setdefault(x, []).append('y') | 20:58 |
abentley | salgado: It might be nice to use adaptation for GenericWorkItem. Then you could make SpecificationWorkItem implement IGenericWorkItem directly, and provide an adapter for BugTask. | 21:01 |
abentley | salgado: But since this is just shufffling pre-existing code around, r=me. | 21:03 |
salgado | abentley, thanks! (fwiw, I've considered using adapters for that, but didn't see much advantage in doing so) | 21:07 |
salgado | abentley, would you mind landing this one for me as well? | 21:10 |
abentley | salgado: Sorry, EOD. | 21:14 |
=== abentley changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: - | Firefighting: - | Critical bugtasks: 4*10^2 | ||
salgado | hmm | 21:21 |
salgado | anybody willing to ec2-land https://code.launchpad.net/~salgado/launchpad/person-upcoming-work-view/+merge/100878 for me? | 21:21 |
salgado | lifeless, maybe you as you seem to be the on call reviewer today? ;) (^) | 21:33 |
lifeless | salgado: my landing environment is a little horked just now | 21:44 |
lifeless | salgado: but I can find a victim for you | 21:45 |
salgado | lifeless, cool, that works as well :) | 21:46 |
=== matsubara is now known as matsubara-afk | ||
lifeless | gary_poster: hi; is there anything you guys need from me at the moment ? just asking as we have a long weekend coming up | 22:01 |
=== salgado is now known as salgado-afk | ||
wgrant | salgado-afk: Your branch is holy and being reverted. | 22:34 |
jelmer | wgrant: we have a problem with holy branches? | 22:34 |
jml | rick_h: thanks. | 22:56 |
jml | my recent lp branch failed a bunch of doctests because it changed login_person to return the person who is logged in | 22:56 |
jml | (meaning you can do 'with celebrity_logged_in("admin") as admin_person:' and other fun things) | 22:56 |
jml | so all of the doctests that do: | 22:57 |
jml | >>> login_person(foo) | 22:57 |
jml | >>> # something else | 22:57 |
jml | fail, because login_person isn't supposed to be returning anything, according to them | 22:57 |
jml | I think this is a stupidity of doctests | 22:57 |
StevenK | ign = login_person(foo) ? | 22:58 |
jml | just wondering if anyone has any opinions on what would be the cleanest thing to do | 22:58 |
jml | change all the call sites | 22:58 |
jml | or revert the API call, creating a private _login_person that *does* return and having the public login_person keep its None-returning behaviour. | 22:58 |
StevenK | You could do that too | 22:58 |
jml | StevenK: ign = ... would wok, but it would also flag pyflakes. | 22:59 |
StevenK | I didn't think pyflakes dealt with doctests? | 22:59 |
jml | StevenK: you can get it to if you want. | 22:59 |
jml | obviously I want to do the thing that's the least work, but I also think LP has had one too many cracks papered over. | 23:01 |
jml | I guess >>> ign = login_person(foo) is better than >>> login_person\n<Person ...> | 23:02 |
=== salgado-afk is now known as salgado | ||
salgado | wgrant, what's wrong with it? | 23:14 |
wgrant | salgado: There's an XSS in the work item title rendering. | 23:15 |
wgrant | There's a reason I questioned your foo_link stuff a couple of days back -- it inevitably leads to mistakes like this. | 23:16 |
salgado | oops, indeed | 23:17 |
salgado | had you told me the reason I could've avoided the mistake | 23:17 |
salgado | wgrant, there's another branch being ec2-landed (under abentley's account) which includes the changes you're reverting as well. not sure there's anything to be done about that before it lands as abentley is gone | 23:24 |
wgrant | salgado: It'll hopefully conflict in PQM. | 23:25 |
StevenK | Hm, qas seems faster. | 23:33 |
StevenK | Of course, as I say that, it times out 3 times in a row. | 23:33 |
rick_h | 041510 | 23:40 |
rick_h | ok, I didn't even touch the yubikey that time...it's on crack | 23:41 |
StevenK | Hm. That reminds me, when is that call ... | 23:41 |
rick_h | StevenK: so 9pm your time I think if I used the time website right | 23:41 |
rick_h | 6am my time, and should hit the other two in the morning | 23:41 |
lifeless | wgrant: sanity check me: the SCA stuff isn't hung off of Ubuntu, its a global concept in the code base today, right ? | 23:41 |
rick_h | I didn't hear back from anyone though StevenK | 23:41 |
wgrant | lifeless: Yes :( | 23:42 |
lifeless | thanks | 23:42 |
lifeless | jml: and theres the ack. | 23:42 |
wgrant | celebrities ftl | 23:42 |
StevenK | rick_h: Perhaps not enough notice | 23:42 |
rick_h | StevenK: yea, was the battle of getting the process started in time to beat convoy to produciton while giving a day or two to make sure you can show up | 23:43 |
rick_h | but two days should be good for yay/nay I'd think | 23:43 |
StevenK | You'd think | 23:43 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!