[02:05] <lifeless> yay @ 3KB/s from LP
[02:05] <lifeless> (not LP's fault - the weather is messing up my internets)
[02:08] <wgrant> The cold should be improving conductivity!
[02:36] <nigelb> lifeless: Morning
[02:36] <nigelb> lifeless: It was just one page
[02:36] <nigelb> wgrant: Everyone must be home and using the internet in the cold ;)
[02:38] <lifeless> http://www.stuff.co.nz/national/5434460/NZ-set-for-perfect-snowstorm
[02:39] <nigelb> Also, it was a db heavy page, so now I think it was probably okay.
[02:39] <StevenK> Sounds right. You should listen to lifeless talk about his Internets at 5pm
[02:39] <lifeless> *hates*
[02:40] <nigelb> haha
[02:40] <nigelb> oh. Today's a Monday and its a holiday! <3
[02:43] <lifeless> grah
[02:43] <lifeless> so.umask
[02:43] <lifeless> ...
[02:43] <lifeless> and then restores it
[02:43] <lifeless> no finally.
[02:43] <lifeless> no cleanup.
[02:43] <lifeless> -> how to mess up an entire test run if one test fails.
[03:13] <lifeless> poolie: could you spare a few minutes to teddy bear a design with me ?
[03:31] <lifeless> nigelb: better pics - http://www.stuff.co.nz/national/5443420/Major-weather-disruption-around-NZ
[03:32] <nigelb> lifeless: it looks beautiful
[03:33] <nigelb> of course, I'm saying this while bathed in sunlight ;)
[03:38] <lifeless> nigelb: better pics - http://www.stuff.co.nz/national/5443420/Major-weather-disruption-around-NZ
[04:38] <poolie> nice
[04:45] <lifeless> time to move the python-oops code to python-oops_datedir_repo
[04:49] <lifeless> StevenK: any chance I can get a couple of reviews from you?
[04:49] <lifeless> https://code.launchpad.net/~lifeless/python-oops/extraction/+merge/71507 and https://code.launchpad.net/~lifeless/launchpad/useoops/+merge/71506
[04:49] <lifeless> StevenK: mainly deletes again
[04:53] <StevenK> lifeless: Having desktop issues
[04:54] <StevenK> steven@liquified:~% ps axw | grep -c "<defunct>"
[04:54] <StevenK> 153
[04:54] <lifeless> StevenK: ugh
[04:54] <lifeless> StevenK: \o/
[04:54] <StevenK> ^ That isn't helping
[04:54] <lifeless> StevenK: sure its not a lp test run parent ?
[04:54] <StevenK> No, they're all gnome stuff
[04:56] <lifeless> heh
[04:56] <lifeless> https://launchpad.net/python-launchpad-filesystem
[05:08] <StevenK> # XXX AaronBentley 2009-11-26 bug=488950: There should be separate storage for oops messages.
[05:08] <StevenK> lifeless: Haven't you dealt with that?
[05:10] <lifeless> StevenK: no
[05:10] <lifeless> StevenK: by the end of the arc I will have
[05:10] <lifeless> but changing that means fixing the oops-tools bug about actually using the common extracted code.
[05:16] <StevenK> lifeless: Both approved
[05:16] <lifeless> thank you!
[05:17]  * StevenK tries to swap back the state he had before the reviews, fails
[05:17] <lifeless> :(
[05:17] <lifeless> sorry!
[05:21] <StevenK>   File "/home/steven/launchpad/lp-branches/link-branch-to-private-bug/lib/lp/code/model/branch.py", line 181, in setPrivate
[05:21] <StevenK>     raise BranchCannotBePrivate()
[05:21] <StevenK> :-(
[05:21] <lifeless> probably nee da privacy policy
[05:21] <lifeless> or non-junk or non-distro branch
[05:21] <StevenK> I've been trying to work that out
[05:22] <StevenK> The code isn't being very helpful
[05:26] <StevenK> lifeless: So I have a product branch, and it still raises the exception. But I don't want the branch to be private by default -- I'm trying to go for what we do with LP itself.
[05:32] <lifeless> are you making it private as an admin ?
[05:32] <StevenK> No, I'm not.
[05:32] <StevenK> I'm wondering if I should
[05:32] <lifeless> I suspect you need to.,
[05:32] <lifeless> AFAIK we have no 'user can opt in' story that is polished :)
[05:33] <StevenK> This is in model code, so I probably need to removeSecurityProxy()
[05:33] <StevenK> Which makes me sad.
[05:49]  * StevenK grumbles
[05:50] <StevenK> IBugBranchSet.getBranchesWithVisibleBugs iterates over a collection of branches it is passed, and doesn't deal with unauthorized errors
[06:14] <StevenK> lifeless: Can haz review?
[06:22] <lifeless> if you give me a url
[06:23] <lifeless> StevenK: I see it
[06:23] <lifeless> uhm
[06:23] <StevenK> lifeless: Um?
[06:25] <lifeless> uhm
[06:26] <lifeless> reviewed; twice :)
[06:26] <lifeless> I have to go cook v. soon but I can discuss later, or tomorrow
[06:27] <StevenK> lifeless: Public branches can become private -- we use this in LP occasionally
[06:27] <lifeless> admin only functionality
[06:27] <StevenK> Right
[06:28] <lifeless> with this change as it stands, I can make anyone's branch private
[06:28] <StevenK> I will discuss it with Curtis tomorrow
[06:28] <lifeless> and without a privacy policy, they can't even undo that IIRC
[06:31] <lifeless> I've commented in the bug
[06:43] <lifeless> you're going to love the next review :P
[06:44] <StevenK> Find someone else? Like Henning? :-)
[06:44] <lifeless> sure :)
[06:44] <lifeless> I've deleted the guts of python-oops, moved it to python-oops-datedir-repo, and added a new new core :)
[06:45] <StevenK> datedir-repo?
[06:45] <StevenK> Why?
[06:45] <lifeless> because thats what the code really is all about
[06:45] <lifeless> the structure we need is getting clearer the more I pull things apart
[06:46] <lifeless> the lp oops system currently uses an oops repository based around directory named by the date
[06:49] <lifeless> anyhow - for whomever feels like it - https://code.launchpad.net/~lifeless/python-oops/extraction/+merge/71510 +248 - 847
[06:51] <stub> lifeless: not sure if it isn't core. Can you imagine an installation that doesn't use the directory storage? I thought it would be required as a backup for when more advanced data stores fail.
[06:53] <stub> lifeless: I'm confused in the first lines of the readme - factory = Config(). Is it a misnamed method or a misnamed variable?
[06:55] <stub> I'm used to factories having __call__ methods rather than create, but I suspect that is just personal style. I guess create is clearer as the factory needs to be configured before use.
[06:57] <stub> Not really a factory is it with .publish - more an oops_handler
[06:58] <stub> lifeless: The report is created by the oops_handler. Any reason to prefer oops_handler.publish(report) over report.publish() ?
[07:03] <lifeless> stub: reports are just dicts
[07:03] <lifeless> stub: see the README in the lp:python-oops
[07:03] <lifeless> stub: thats deliberate for interop
[07:03] <lifeless> stub: yes, I can imagine an install that doesn't use the directory storage
[07:04] <lifeless> stub: e.g. local mq on the box, let that take care of downtime handling
[07:04] <lifeless> stub: or even queue in process: by the time you can restart the process, you've gotten network back :)
[07:05] <stub> I was wondering if the core library would use it as a fallback for exceptions happening in the pluggable storage.
[07:05] <lifeless> stub: I think its best not to, so that the core really is lean - e.g. for inclusion on the Ubuntu CD
[07:06] <lifeless> stub: where they'd want to use the apport *style* of disk store (one crash per program per user stored at max)
[07:06] <stub> So exception handler would be logging.log.exception('Unable to store OOPS')
[07:07] <lifeless> stub: perhaps; I think there is room for discussion around that. I can well imagine getting bug reports either way.
[07:07] <lifeless> stub: for now, my focus is on a reasonable structure for the project(s), and acheiving enough extraction that gpgverify can import and use the library to do oops reporting
[07:07] <lifeless> unblocking the SOA project
[07:08] <lifeless> stub: if that makes sense
[07:09] <lifeless> stub: another way to do fallbacks would be a publisher clients can use that: looks for an id, if not present then log via logging.error that something is wrong
[07:09] <danilos> lifeless, hi, what's the status of our collided changes (re 728220): I could confirm OOPSes produced tonight have the data properly sanitized, so I just marked the bug qa-ok
[07:09] <lifeless> stub: I don't think there is a single right policy for all users
[07:09] <stub> Sure. I do think the OOPS system should never hard fail, so will need some sort of global exception handler and ability to emit meeps when your publication messes up or your dict isn't serializable.
[07:09] <lifeless> danilos: I resolved it all
[07:10] <danilos> lifeless, excellent, thanks
[07:10] <lifeless> stub: agree on never hard failing; want to think more about what/how to do for that - at the moment we do hard fail if things blow up, so its not a regression in any sense
[07:10] <lifeless> danilos: I moved it into the *make* rather than the *write*
[07:11] <stub> lifeless: We currently put that burden on the call sites in Launchpad.
[07:11] <lifeless> stub: overnight scan-branches blew up, its oops writer failed (directory permissions), so it propogated an exception to the root :)
[07:11] <danilos> lifeless, I assume make happens before the write, which is even better
[07:11] <stub> (appservers get it for free with publication, and scripts don't bother and would just explode on disk full)
[07:11] <lifeless> stub: yeah
[07:12] <lifeless> stub: so there is room for us to think about an interface which will let scripts to better and not burden appservers.
[07:12] <lifeless> danilos: yes, exactly.
[07:13] <lifeless> danilos: you can poke at my merge - rev 13684 - if you're interested.
[07:14] <stub> Yup. try: [code calling non-core] except Exception: log.exception('OOPception') would be fine, assuming all the logging system callbacks are also bulletproof :)
[07:17] <danilos> lifeless, thanks
[07:24] <lifeless> stub: perhaps, though for an appserver that would double-log
[07:25] <lifeless> stub: so I think this needs a bit more consideraiton
[07:30] <stub> When did we start naming_modules_with_underscore?
[07:34] <lifeless> stub: well, its not lp core, so its more pep8 than anything else
[07:34] <lifeless> which says 'when it aids clarity'
[07:35] <adeuring> good morning
[07:56] <lifeless> stub: so was that by way of review or just discussion ?
[08:10] <stub> lifeless: r=stub with comments
[08:11] <lifeless> stub: thanks!
[08:25] <StevenK> lifeless: O hai -- you remember the denorm branch you looked at on Friday? That should be fine to just lp-land, right?
[08:29] <lifeless> StevenK: hahahahahahahahahaahahah
[08:36] <StevenK> stub: O hai. So you think we should add indexes for BPPH.BPN and SPPH.SPN before we do the population?
[08:39] <nigelb> lifeless: that was brilliant reply.
[08:39] <nigelb> Need to have a quotes db.
[08:39] <nigelb> one of these days I'll host it myself.
[08:39] <StevenK> nigelb: SILENCE
[08:54] <danilos> henninge, hi, will you be reviewing today? if so, I've got a branch up at https://code.launchpad.net/~danilo/launchpad/bug-690568/+merge/71394 ;)
[08:55] <henninge> danilos: I will. ;-)
[08:55] <henninge> danilos: can you fix the lint, please?
[08:56] <danilos> henninge, sure, I didn't want it to pollute the diff
[08:56] <henninge> danilos: that's something we'll have to live with if we ever want to get any transitions done.
[08:56] <danilos> henninge, I usually do it post-review though
[08:57] <henninge> oh, that is a good idea, too.
[08:57] <henninge> danilos: cool
[09:03] <StevenK> henninge: O hai, are you free?
[09:04] <henninge> StevenK: not right now but feel free to queue ;-)
[09:04] <StevenK> henninge: https://code.launchpad.net/~stevenk/launchpad/use-shutdown-ec2/+merge/71522 when you have a tick. Nice small one.
[09:07] <stub> StevenK: If you don't have an index in place, the population will go really slow (it will take ages to calculate WHERE spn IS NULL)
[09:08] <StevenK> stub: Right. I'm doing development of this in a pipe, I will shift a pipe into the middle for indinces
[09:12] <henninge> danilos: r=me
[09:12] <henninge> StevenK: Looking now
[09:12] <danilos> henninge, thanks
[09:12] <StevenK> henninge: Thanks!
[09:15] <henninge> StevenK: did you change from shutdown -h to shutdown -P on purpose?
[09:15] <henninge> sounds better to me , just wondering if there may have been a reason not to use -P before.
[09:15] <StevenK> henninge: Since the other shutdown call used -P
[09:16] <henninge> StevenK: Ah! (that's not in the diff obviously)
[09:17] <henninge> StevenK: you mention a bug report but there is no bug linked
[09:18] <StevenK> henninge: No, but the bug is mentioned in the code I removed
[09:18] <henninge> duh
[09:22] <henninge> StevenK: I assume you have already tried this out?
[09:22] <StevenK> I have not
[09:23] <StevenK> henninge: It was going to be tested with the landing
[09:23] <henninge> ah, of course ;-)
[09:23] <henninge> StevenK: r=me
[09:23] <StevenK> henninge: Thanks!
[09:48] <wgrant> gmb: aaaaa
[09:48] <wgrant> gmb: Not sure that's a good one to pick.
[09:49] <gmb> wgrant: Any reason other than "That bug will eat your face and you will die?"
[09:49] <wgrant> given it's a) difficult, b) DB changes, c) we
[09:49] <wgrant> .. might delete nominations later this year
[09:49] <wgrant> d) difficult
[09:49] <wgrant> e) face eating
[09:49] <nigelb> f) kitten will die?
[09:50] <stub> nom nom nom
[09:50] <wgrant> There are pretty unfortunate complexities around SourcePackage tasks that this would eliminate.
[09:50] <wgrant> But...
[09:50] <wgrant> Ubuntu and lifeless want a rework of how series tasks work.
[09:50] <gmb> Ah. Hmm.
[09:51] <wgrant> So I'm not sure it's worth putting a huge amount of time into fixing my second oldest Launchpad bug.
[09:51] <nigelb> wgrant: I have up trying to read Zope 3. Much eeasier to read LP code sadly.
[09:51] <gmb> wgrant: Is there any kind of concrete schedule for said reworking? I'm more than happy to punt this if so, but I want it off the Critical list because I keep seeing it and fooling myself into thinking I can fix it.
[09:51] <wgrant> At least not until we know what's happening.
[09:51] <nigelb> *gave
[09:51] <wgrant> gmb: You could just fix the OOPS.
[09:52] <gmb> wgrant: Ah, good idea.
[09:52] <wgrant> It only affects a few bugs from before 2007.
[09:56] <henninge> Do changes to security.cfg need to be submitted to db-devel?
[09:58] <lifeless> henninge: no
[09:58] <henninge> lifeless: thanks
[09:58] <lifeless> dev.launchpad.net/PolicyAndProcess/DatabaseSchemaChangeProcess 9r something like that
[09:59] <wgrant> henninge: New permissions are applied before every nodowntime rollout, but revocations are only performed during downtime.
[09:59] <wgrant> Regardless, should be landed on devel.
[09:59] <henninge> ok
[10:00] <lifeless> gmb: which bug?
[10:04] <gmb> lifeless: https://bugs.launchpad.net/launchpad/+bug/110195
[10:04] <_mup_> Bug #110195: Nominating a bug for a distro release affects all package tasks for that distro <lp-bugs> <motu> <oops> <Launchpad itself:In Progress by gmb> < https://launchpad.net/bugs/110195 >
[10:07] <lifeless> gmb: I would fix it by making the thing that fails fail cleanly, vs oopsing
[10:07] <lifeless> gmb: that will cover the oops bit, because its not something we need to investigate each time it happens
[10:08] <nigelb> grr. posting to +check-links with extra information creates 500 error :|
[10:10] <lifeless> gmb: you could fix it fully if you want, but as wgrant says, we probably stand to gain a lot by massively simplifying things - no non-series tasks, and nomination a task status
[10:13] <gmb> lifeless: Yes, I agree; I'll make the OOPS not an OOPS and leave it at that for now.
[10:16] <nigelb> guys, if I have a bug number, how do I lookup the validity of the bug?
[10:16] <nigelb> err, inside LP that is.
[10:18] <nigelb> Is there something similar to lp.code.interfaces.branchlookup.IBranchLookup?
[10:18] <nigelb> I wonder if I bit more than I can chew.
[10:19] <bigjools> IBugSet.getByNumbers()
[10:19] <bigjools> or just .get()
[10:20] <nigelb> bigjools: where does it live?
[10:20] <jtv> henninge: time to review?  https://code.launchpad.net/~jtv/launchpad/pre-824499/+merge/71536
[10:20] <bigjools> lp/bugs/ ? :)
[10:20] <bigjools> you need to install bzr grep
[10:20]  * nigelb installs
[10:21] <nigelb> hm, don't see anything like that.
[10:21] <bigjools> bzr-grep I think is the package
[10:22] <nigelb> ah, maverick+
[10:22] <nigelb> I'm on lucid.
[10:22] <bigjools> tsk :)
[10:22] <nigelb> lp's deployed on lucid! So its a technically valid excuse :P
[10:23] <bigjools> look in lib/lp/bugs/interfaces/bug.py
[10:23] <bigjools> there is a pattern to our files y'know :)
[10:23] <nigelb> heh, yeah. I should have guessed :)
[10:23] <bigjools> there's a PPA with bzr-grep in it somewhere
[10:24] <bigjools> it's a cracking plugin
[10:24] <wgrant> bzr branch lp:bzr-grep ~/.bazaar/plugins/grep
[10:25] <bigjools> I wonder if we can give nigelb the PyCharm licence key
[10:25] <bigjools> maybe not, he doesn't have commit access
[10:25] <nigelb> To LP?
[10:25] <bigjools> yeah
[10:25] <nigelb> I thought that's only for Canonical employees?
[10:25] <bigjools> if you commit to other OSS projects you could get your own licence
[10:26] <bigjools> indeed
[10:26] <wgrant> I've given up on PyCharm for now.
[10:26] <bigjools> why?
[10:26] <StevenK> wgrant: Oh?
[10:26] <nigelb> I like vim tbh.
[10:26] <bigjools> I have the vim plugin for PyCharm
[10:27] <bigjools> it's almost like using vim except you get something from the 21st century
[10:27] <nigelb> heh
[10:27] <bigjools> but seriously, it's kinda nice having a decent IDE
[10:29] <nigelb> how does the Interface thing work?
[10:29] <nigelb> standard OOP?
[10:30] <bigjools> e_context
[10:30] <nigelb> Like, where do I see the function defitions for fuctions in Ibug
[10:31] <lifeless> s/interfaces/model/
[10:31] <nigelb> Oh.
[10:31] <bigjools> well he can't call stuff that's not in the interface
[10:31] <bigjools> the interface is the best place to look
[10:31] <bigjools> it also has docstrings
[10:32] <bigjools> nigelb: look in the file I pasted earlier and search down for IBugSet
[10:32] <bigjools> class IBugSet
[10:32] <nigelb> Yeah, I was looking at that.
[10:33] <henninge> jtv: looking
[10:34] <henninge> jtv: why does "rsyncBackupDists" need a distribution parameter? I see no change in the method body.
[10:34] <jtv> henninge: it becomes necessary for accessing configs later, in the follow-up branch.
[10:34] <henninge> ok
[10:35] <jtv> (self.configs becomes indexed by distro)
[10:36] <henninge> jtv: ah yes, I see there are more lilke that!
[10:36] <nigelb> bigjools: (maybe a stupid question), does IbugSet.get() correctly take care of hiding private bugs from the person requesting?
[10:37] <nigelb> (the docstrings only tell baout bug not found. Not about bug found, but you can't see it situation)
[10:37] <bigjools> nigelb: no idea, I've never done any bugs work
[10:37]  * bigjools would hope that the security adapter does that
[10:37] <nigelb> *whee* grep time :)
[10:37] <bigjools> check in the security.py
[10:38] <nigelb> Nothing about IBugSet in there
[10:39] <stub> So we don't want to land code changes on db-devel, yet there are some db changes that require code updates. So the best way of handling this is wranging two branches? One launchpad/stable branch with the code changes, and merge this to a launchpad/db-devel branch with the schema change, and run tests for both branches and land separately?
[10:39] <stub> (yes, pipes should make this workable)
[10:39] <wgrant> stub: DB changes aren't allowed to require code updates.
[10:39] <jtv> stub: I think we _have_ to make the code and db changes work independently.
[10:39] <wgrant> stub: Or if they do, it must already be landed on devel and deployed.
[10:39] <stub> I'm adding a NOT NULL constraint. That requires code to make sure it is never NULL.
[10:39] <jtv> Not sure how renaming columns works.
[10:40] <wgrant> It doesn't.
[10:40] <stub> wgrant: Yes. I'm thinking about how to best wrangle this.
[10:40] <wgrant> Well, you could do it with triggers.
[10:40] <wgrant> Same as renaming tables.
[10:40] <wgrant> stub: What needs wranglement?
[10:40] <stub> I need to land code changes so I can land db changes and keep the test suite passing.
[10:41] <stub> I'm adding a NOT NULL constraint. Some tests fail. I need to fix these tests on launchpad/devel.
[10:41] <wgrant> The code needs to cope with both old and new schemas.
[10:41] <wgrant> The code lands on devel. Once it's merged to db-devel, you can land the schema change.
[10:41] <stub> Yes.
[10:41] <wgrant> The code change is then deployed.
[10:41] <wgrant> fastdowntime happens later.
[10:41] <wgrant> Then it's all done.
[10:41] <stub> I'm just wondering if the method of wrangling the branches is most efficient.
[10:42] <stub> I need to do coordinated landing of changes to launchpad/devel and launchpad/db-devel.
[10:42] <henninge> jtv: that's an almost mechanical change ... ;-) r=me
[10:42] <wgrant> stub: Why can't you make the devel changes first?
[10:42] <stub> I am!
[10:42] <wgrant> I mean, at an arbitrary earlier point.
[10:42] <stub> Yes, I sketched out a method of coordinating this.
[10:43] <jtv> henninge: yes, I wanted to keep that separate from the less-mechanical changes.  Thanks!
[10:43] <stub> My code changes are defined as 'what code changes are needed to allow this database patch to land'
[10:44] <lifeless> stub: so you need to sequence it
[10:44] <lifeless> stub: a) land code that makes sure its never NULL
[10:44] <lifeless> let that get deployed.
[10:44] <lifeless> then land the schema constraint
[10:44] <stub> Yes. As I said before, I'm wondering on the best way of wrangling the branches.
[10:44] <lifeless> then deploy that, and merge the db side of it to devel after the deploy
[10:45] <stub> I'm thinking a pipe branch, first pipe from launchpad/stable containing code changes.
[10:45] <stub> Second pipe from launchpad/db-devel containing the db-changes
[10:45] <lifeless> yes, that should work fine
[10:45] <stub> Run tests for both
[10:45] <lifeless> I'd probably just do separate branhces
[10:45] <lifeless> but thats me :P
[10:46] <wgrant> lifeless: Speaking of you, when are we likely to lose you?
[10:46] <wgrant> Due to the impending lifeless-ng.
[10:46] <lifeless> wgrant: 38w1d
[10:47] <wgrant> Eep.
[10:47] <stub> The important things seem to be code branch from stable (as this will be merged into the db changes branch, so we don't want devel leaking in there), and to run the tests for code changes (don't break trunk) and code changes + db patch (the changes actually let me land the patch)
[10:47] <lifeless> wgrant: normal births occur from 37w0d to 42w0d
[10:47] <wgrant> I know that much :)
[10:47] <lifeless> stub: landing separately will naturally run the changes separately :)
[10:47] <stub> yes
[10:48] <lifeless> wgrant: I don't know what they teach at aussie schools ;P
[10:48] <wgrant> Hah.
[10:48] <nigelb> lifeless-ng?
[10:48] <stub> in this case, knowing what code changes are necessary requires running the test suite with the dbpatch
[10:48] <nigelb> bugid is er what type of variable?
[10:49] <lifeless> stub: I would be lazy; make the db branch, submit to ec2, if it lands \o/ if it doesn't, the error list will tell you what you need to change :)
[10:50] <stub> lifeless: So skew in LaunchpadDatabaseRevision might actually be a good thing, as it gives us a little transition state during the period when patches are deployed on some databases and not others. Or it might just be a footgun.
[10:51] <lifeless> stub: depends on what you mean by skew
[10:51] <lifeless> stub: with transactions we have skew between slaves
[10:51] <lifeless> stub: but never between the version on a slave, and the schema on the slave.
[10:52] <lifeless> stub: what I meant by skew was a schema that doesn't match LDR [and not just an index existing]
[10:53] <lifeless> ! http://mp3fs.sourceforge.net/
[10:53] <stub> Need to think about it anyway.
[10:54] <nigelb> I have an oops from my local instance, how I see the full OOPS?
[10:54] <nigelb> (its an XHR call, so I can't actually see the page)
[10:54] <stub> That FUSE idea is an interesting solution.
[10:56] <lifeless> nigelb: /var/tmp/lperr/*/*
[10:56] <nigelb> lifeless: thanks!
[10:57] <nigelb> I may have run into a security problem. Gotta try and confirm.
[10:57] <lifeless> nigelb: what are you hacking up ?
[10:58] <nigelb> lifeless: making the linkage of bugs similar to branches, greyed out if the bug doesn't exist
[10:59] <lifeless> nigelb: uhm
[10:59] <lifeless> nigelb: do you mean linkification ?
[10:59] <nigelb> yeah
[10:59] <nigelb> bug 4595 actually I think
[10:59] <lifeless> so, a few tips
[10:59] <_mup_> Bug #4595: Don't auto-linkify non-existent bug reports <easy> <lp-web> <tales> <ui> <Launchpad itself:Triaged> < https://launchpad.net/bugs/4595 >
[10:59] <lifeless> hah, whoever claimed easy is probably lying
[11:00] <nigelb> I agree
[11:00] <nigelb> I touched javascript and some python, not easy, but fun :)
[11:00] <nigelb> I've got it down to harvesting, posting the bug numbers via xhr call, returning invalid bug numbers.
[11:01] <lifeless> are you  doing it via a webservice call post lost ?
[11:01] <nigelb> I'm doing it via an xhr call to +check-links
[11:03] <nigelb> I almost got it  I think :)
[11:03] <nigelb> (except for a possible security concern)
[11:04] <nigelb> \o/ It works
[11:06] <stub> Bah. Need separate branches or db-devel ends up in the code changes. Duh.
[11:08] <nigelb> lifeless: It works \o/ Sadly, the I run into the security issue I feared.
[11:08] <jtv> henninge: here's the follow-up to my earlier branch, if you still have time: https://code.launchpad.net/~jtv/launchpad/bug-824499/+merge/71544
[11:18] <henninge> jtv: time? who owns time?
[11:19] <jtv> henninge: Not saying you have to own it.  You might be holding someone else's, for instance.
[11:34] <henninge> jtv: I won't be able to start for another hour or so, I am sorry.
[11:34]  * henninge is off to lunch
[11:38] <jtv> henninge-lunch: OK — I may be gone when you get back.
[11:46] <nigelb> who has worked on bugs that I can take help of?
[11:53] <lifeless> nigelb: most folk
[11:55] <nigelb> lifeless: oh.
[11:55] <nigelb> I just need some help trying to make sure I show only bugs that are visible to the current user, not just valid.
[11:56] <nigelb> IBugSet.get() only checks if I have e permission.
[11:56] <lifeless> so, I would use search
[11:56] <lifeless> not BugSet.get
[11:57] <lifeless> because you don't want to check every bug one sql line at a time
[11:57] <lifeless> thats pretty much a guaranteed timeout right there
[11:57] <lifeless> you can see how to do a narrow search by id if you poke around the bugbranch link code
[11:57] <jelmer> wow, that +localpackagediff page is awesome
[11:58] <bigjools> BugSet.getByNumbers() is what I recommended earlier
[11:58] <bigjools> jelmer: :D
[11:58] <nigelb> lifeless: ouch, branches is done that way.
[11:58] <nigelb> or so I think.
[11:59] <nigelb> Also, bug branch link code?
[12:00] <nigelb> I don't know what that is to look for it
[12:00] <lifeless> bigjools: that will perform horribly
[12:01] <lifeless> nigelb: lib/lp/code/model/branchcollection.py line 408 has some related code
[12:01] <lifeless> that might be enough to get you rolling
[12:02] <nigelb> *looks*
[12:05] <lifeless> bigjools: (the lookup would be fast, but every private bug would trigger separate just-in-time subscription lookups)
[12:05] <bigjools> I was only asked about lookup
[12:05] <lifeless> bigjools: I know
[12:05]  * bigjools heads to lunch for real
[12:07] <lifeless> adeuring: grahhh regex?!
[12:07] <lifeless> adeuring: just use iso8601
[12:07] <adeuring> lifeless: can you explain a bit?
[12:08] <lifeless> bin/py -m pydoc 'iso8601.parse_date'
[12:08] <lifeless> adeuring: rather than using a regex, use pre-existing code.
[12:08] <lifeless> adeuring: if someone messes with a memo, they can get a UDF and we don't have to care
[12:09] <adeuring> lifeless: a, thanks. I did not know about this module
[12:09] <lifeless> its verra handy :)
[12:09] <adeuring> yeah
[12:10] <lifeless> I recently added it to our deps, as part of the oops extraction I deleted a very similar regex.
[12:12] <jtv> I thought I could run the Initialize DistroSeries jobs with "./cronscripts/process-job-source.py -vv initializedistroseries" but that fails with "No section key named module."  Was a change in process-job-source configuration not applied to this config, or am I running the wrong thing?
[12:13] <nigelb> lifeless: I'm confused. I don't understand how this works.
[12:15] <lifeless> you crate a bugtasksearch params for the user, no status mask, and rather thank saying linked_branches=... you say bug=any(*ids)
[12:15] <lifeless> then searchIds which will give you the actual visible ids
[12:15] <lifeless> and you're done
[12:16] <nigelb> where *ids is my list of ids?
[12:16] <lifeless> yes
[12:16] <nigelb> ok, more clear.
[12:16] <nigelb> One more question :)
[12:16] <nigelb> How do I get current user?
[12:17] <lifeless> depends
[12:17] <lifeless> :P
[12:18] <nigelb> oh oh
[12:18] <lifeless> if this is a web api, through partial function application
[12:18] <lifeless> have a look at the interfaces/* files and look for user parameters with binding decorators
[12:19] <nigelb> lazr.restful.declarations.REQUEST_USER?
[12:20] <lifeless> something like
[12:20] <lifeless> its 0020
[12:20] <lifeless> so I am going to halt()
[12:20] <nigelb> wait, what?
[12:21] <nigelb> I didn't understand that :(
[12:27] <benji> nigelb: here's an example: lib/lp/registry/interfaces/person.py, line 1724
[12:27] <nigelb> benji: Ah. I kept seeing that in my grep, didn't realize that's exactly what I wwas looking for.
[12:27] <nigelb> Thanks!
[12:28] <benji> no problem
[12:34] <adeuring> lifeless: fancy a review of a new version of my MP?
[12:54] <adeuring> henninge: could you have a look at this mp: https://code.launchpad.net/~adeuring/launchpad/bug-739052-5/+merge/71548 ?
[12:55] <henninge> adeuring: wow, that's long
[12:55] <henninge> adeuring: and it has text conflicts
[12:55] <adeuring> ouch.. should be 300 or 400 lines. let me check...
[12:55] <henninge> adeuring: 1047
[12:56] <henninge> benji: Hi! Are you working on a review from the queue?
[12:56] <benji> henninge: not at the moment, I haven't quite spun up my reviews yet
[12:57] <henninge> benji: ok, cool
[13:03] <deryck> Morning, all.
[13:11] <adeuring> morning deryck
[13:16] <adeuring> henninge: could have a look again: https://code.launchpad.net/~adeuring/launchpad/bug-739052-5/+merge/71548 (201 lines)
[13:31] <deryck> abentley, can you hear us?
[13:31] <abentley> deryck: no
[13:31] <deryck> abentley, ok, we don't hear you either.
[13:32] <deryck> abentley, we could do skype if skype works for you.
[13:32] <abentley> deryck: let's try that.
[13:32] <deryck> abentley, ok, adeuring is switching machines and I'll call everyone.
[13:34] <abentley> deryck: restarting.
[13:34] <abentley> deryck: actually, I'll use skype on my phone...
[13:34] <deryck> abentley, ok, that works.
[13:34] <deryck> abentley, I have your number in my contacts it seems.
[13:36] <deryck> adeuring, you ready now?
[13:36] <adeuring> deryck: skype is starting...
[13:36] <abentley> deryck: I have skype on my phone.
[13:36] <adeuring> deryck: I am online on  kype
[13:36] <deryck> abentley, ah, ok.  gotchas.
[13:38] <abentley> deryck: try again please.
[13:38] <deryck> abentley, ringing....
[13:39] <abentley> deryck: I keep hitting the answer button, but it doesn't answer even though it shows it knows I've hit the button.
[13:39] <deryck> hmmm
[13:39] <deryck> and now we lost adeuring.
[13:39] <adeuring> yeah... connection dropped... no idea why
[13:39] <deryck> abentley, shall I call your land line?
[13:40] <deryck> abentley, or whatever number I have listed as "real phone" :)
[13:40] <abentley> deryck: no, phone is haywire.
[13:40] <deryck> abentley, ah, ok.
[13:40] <abentley> after exiting Skype, it's still ringing.
[13:41] <abentley> deryck: rebooting.
[13:43] <abentley> deryck: back
[13:43] <deryck> abentley, ok, dialing you in....
[13:46] <nigelb> Hi, could someone help with BugTaskSearchParams?
[13:46] <nigelb> Can I give it a list of bugs?
[13:46] <nigelb> Or rather, how do I give it a list of bugs.
[13:57] <benji> nigelb: I've never used BugTaskSearchParams, but lib/lp/bugs/browser/bug.py, line 558 looks exemplary
[13:59] <nigelb> benji: Interesting. That's what I first tried and ran into trouble.
[13:59] <nigelb> Let me try it again so that I can capture the error message
[14:09] <nigelb> benji: yup, getting hit with "TypeError: any() takes exactly one argument (2 given)"
[14:10] <benji> nigelb: it sounds like you're using the builtin "any", not the one imported from canonical.launchpad.searchbuilder
[14:10] <nigelb> benji: Ahhh. Yes. Thanks :)
[14:11] <nigelb> (I didn't know there was one to import :p)
[14:11] <henninge> adeuring: r=me
[14:11] <adeuring> henninge: thanks!
[14:28] <nigelb> Is there a way I can use pdb for debugging launchpad stuff?
[14:31] <benji> nigelb: re. pdb: yes; the easiest thing is to put "import pdb;pdb.set_trace() what is the context?
[14:31] <benji> oops
[14:31] <benji> nigelb: re. pdb: yes; the easiest thing is to put "import pdb;pdb.set_trace()" in your code.  What is the context?
[14:32] <nigelb> benji: I tried that. Didn't work.  its a webservice call.
[14:32] <benji> nigelb: define "Didn't work."
[14:32] <nigelb> well, I didn't get dropped to a ppb shell
[14:32] <nigelb> *pdb
[14:32] <nigelb> and the xhr request was stuck waiting for a response
[14:34] <benji> nigelb: did the server process have its stdio connected to a terminal?
[14:35] <nigelb> benji: I just use make run
[14:35] <nigelb> which I'm not sure leaves stdio
[14:35] <benji> nigelb: I'm not certain it matters, but try bin/run instead
[14:37] <nigelb> benji: No, not in a pdb shell this time either.
[14:37] <nigelb> Is there a better way to debug stuff that call XHR?
[14:38] <benji> that's odd; I don't think I've ever seen that symptom
[14:38] <benji> re. better way: generally having a test that excersizes the misbehaving code would be easier (both for pdb-based debugging and otherwise)
[14:39] <nigelb> hmm, yes. that should definitely leave me in a shell, yes!
[14:55] <statik> nigelb, fwiw I usually use winpdb when debugging any python web services so I don't have to worry about having the server connected to a terminal
[14:56] <nigelb> statik: oh? let me read up on that
[14:58] <statik> nigelb, the first code snippet on this page http://winpdb.org/docs/embedded-debugging/ is what you would need.
[14:58] <nigelb> statik: thank you! I've been at this almost all-day :)
[14:58] <statik> then you connect from the gui debugger
[14:59] <statik> np, hope it helps.
[14:59] <abentley> deryck: pre-imp call?
[15:00] <deryck> abentley, sure.  Just got off a call.  Can I have 10 minutes to get coffee, rest my voice? :)
[15:00] <abentley> deryck: sure.
[15:00] <deryck> abentley, I'll ping shortly.
[15:19] <deryck> abentley, I'm ready now.  mumble or skype?
[15:20] <abentley> mumble
[15:21] <LPCIBot> Project devel build #975: FAILURE in 27 min: https://lpci.wedontsleep.org/job/devel/975/
[15:22] <abentley> deryck: https://bugs.launchpad.net/launchpad/+bug/820039
[15:22] <_mup_> Bug #820039: process-mail.py fails with a LookupError: unknown encoding: macintosh error <mail> <oops> <Launchpad itself:Triaged> < https://launchpad.net/bugs/820039 >
[15:29] <nigelb> statik: winpdb is simply awesome :)
[15:34] <bigjools> nigelb: or pycharm "just works" for all this debugging :)
[15:35] <nigelb> bigjools: hah, stop tempting me ;)
[15:36] <bigjools> nigelb: it has a free 1 month trial
[15:36] <bigjools> oh sorry that's not stopping tempting you
[15:36] <nigelb> hehe
[15:36] <bigjools> nigelb: my productivity went up tenfold when I started using pycharm
[15:36] <bigjools> oh sorry that's not stopping tempting you
[15:37] <nigelb> Is there a possibility that I can get commit access to LP without being employed by Canonical?
[15:37] <bigjools> nigelb: none at all, sorry
[15:37] <bigjools> for various $LEGAL_REASONS
[15:37] <nigelb> Darn. I guess I should just wait to see if you guys will hire me :)
[15:37] <bigjools> heh
[15:38] <bigjools> we hired the last prolific contributor
[15:38] <jtv> henninge: before I head out… any questions about the review?
[15:38] <nigelb> yeah, but beating *that* contributor is probably going to take about 10 years
[15:39] <henninge> jtv: oh, I assumed you had already gone.
[15:39] <jtv> Tsk.  :)
[15:39] <henninge> jtv: I am writing the review right now. All fine.
[15:39] <jtv> Great, thanks
[15:39] <henninge> just a few suggestions
[15:39] <jtv> Even better.
[15:47] <henninge> jtv: sent
[15:47] <jtv> thanks!
[15:47] <henninge> jtv: do you know how MatchesStructure works?
[15:47] <jtv> Yes, but attempts to find it back failed for some reason.
[15:47] <henninge> "find it back" ?
[15:48] <henninge> oh
[15:48] <henninge> jtv: it's in testtools.matchers
[15:48] <jtv> I thought I'd looked there.
[15:49] <henninge> jtv: it is missing from __all__ ...
[15:49] <jtv> That'd do it.
[15:49] <jtv> I don't see it in help(testtools.matchers).
[15:50] <jtv> Meanwhile, the MP hasn't updated yet.  Strange.
[15:50] <jml> jtv, henninge: fixed in forthcoming release
[15:50] <jtv> Great, thanks.
[15:50] <henninge> jml: yes, just checked that ;-)
[15:50] <jml> Also, http://testtools.readthedocs.org/en/latest/for-test-authors.html is quite complete
[15:51] <henninge> jml: I am eager for that release, MatchesStructure.byEquality is really missing ... ;)
[15:51] <jml> henninge: nothing to stop LP from using a snapshot of trunk
[15:51] <henninge>  I guess ...
[15:51]  * henninge takes a note to look into that tomorrow
[15:52] <jml> basically, as soon as https://bugs.launchpad.net/testtools/+bug/804127 is fixed and the other critical bug fix lands, I'm going to do a release
[15:52] <_mup_> Bug #804127: assertThat(..., verbose=True) sometimes generates unprintable AssertionErrors <unicode> <testtools:In Progress by jml> < https://launchpad.net/bugs/804127 >
[15:52] <jtv> bac: if you're still up for it, I resubmitted my MP at https://code.launchpad.net/~jtv/launchpad/bug-659769/+merge/71505
[15:53] <bac> jtv: i didn't get that far into it.  might be best to ask the ocr
[15:53] <jtv> OK
[15:53] <bac> jtv: did you figure out how it got messed up?
[15:53] <nigelb> oh dear. I'm through through a whole bunch of Storm.
[15:53] <jtv> There was a rollback in devel somewhere inbetween.
[15:53] <bac> jtv: ah
[15:54] <jtv> henninge: not a trace of your review, in email or MP.  Are you sure it went in?
[15:55] <henninge> hm
[15:55] <henninge> argh
[15:55] <henninge> "bad signature"
[15:55] <henninge> I'll paste
[15:55] <jtv> Grr
[15:56] <henninge> jtv: pasted
[15:56] <jtv> loading…
[15:57] <jtv> Got it!
[15:57] <jtv> Thanks.
[15:59] <henninge> jtv: good night!
[15:59] <jtv> nn
[16:07] <nigelb> bigjools: heh, I respectfully surrender before Launchpad. I think after 9 hours I'm going crazy debugging ;)
[16:10] <jtv> MatchesStructure.byEquality, MatchesStructure.from_example.  The great thing about conventions is that there are so many to choose from!
[16:13] <jml> jtv: please file a bug. we're pretty darn responsive
[16:13] <jtv> Looks like it's already been fixed.
[16:14] <jtv> Ironically, it was the documentation that led me down the wrong path there.
[16:14] <bigjools> nigelb: heh, good luck tomorrow
[16:14] <nigelb> bigjools: I just realized wallyworld_ offered to mentor me for this. I can now bug him :P
[16:14] <jtv> jml: MatchesStructure.fromExample does work.
[16:15] <jml> Fixed.
[16:15] <jtv> Cool.
[16:15] <bigjools> nigelb: do it
[16:16] <nigelb> bigjools: I'm writing out an email ;)
[16:18] <nigelb> loggerhead having slight issues? Throwing up errors once or twice
[18:13] <sinzui> jcsackett, do you have time to mumble? I need help http://pastebin.ubuntu.com/666686/
[18:39] <jcsackett> sinzui: i can mumble now.
[19:25] <abentley> benji: could you please review https://code.launchpad.net/~abentley/launchpad/macintosh-encoding/+merge/71599 ?
[19:26] <benji> abentley: sure, I can right now
[19:29] <benji> abentley: looks good, I thought of one teeny thing you might want to do in addition
[19:29] <abentley> benji: sure.
[19:36] <LPCIBot> Project db-devel build #811: FAILURE in 6 hr 9 min: https://lpci.wedontsleep.org/job/db-devel/811/
[20:15] <lifeless> morning
[20:16] <nigelb> lifeless! Morning!
[20:28] <sinzui> lifeless, do you have time what happens when a bug is made private http://pastebin.ubuntu.com/666686/
[20:30] <lifeless> time <missing verb> what. .. ?
[20:31] <elmo> lifeless: s/do/if/ s/time/time:/
[20:31] <sinzui> lifeless, do you have time to discuss what happens when a bug is made private http://pastebin.ubuntu.com/666686/
[20:31] <lifeless> sinzui: certainly! voice or irc ?
[20:31]  * elmo guess wrong ;)
[20:31] <sinzui> skype?
[20:32] <sinzui> oh, wrong bug in paste too http://pastebin.ubuntu.com/666767/
[20:32] <lifeless> signing in now
[20:32] <lifeless> elmo: nice try though :)
[21:18] <lifeless> sinzui: bug 405277
[21:18] <_mup_> Bug #405277: Private teams are not able to join other teams (public or private) <disclosure> <lp-registry> <Launchpad itself:Triaged> < https://launchpad.net/bugs/405277 >
[21:38] <mtaylor> httplib2.SSLHandshakeError: [Errno 1] _ssl.c:499: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
[21:38] <mtaylor> EEK?
[21:39] <mtaylor> http://paste.openstack.org/show/2175/ <--- this works on my laptop - but not on another server
[21:41] <mtaylor> lifeless: ^^ ?
[21:41] <mtaylor> lifeless: (also, good morning!)
[22:01] <lifeless> mtaylor: hi
[22:02] <lifeless> mtaylor: oneiric ?
[22:04] <mtaylor> lifeless: natty on the server (where it doesn't work) maverick on my laptop
[22:05] <lifeless> got ca certs installed ?
[22:05] <mtaylor> uhm.
[22:06] <mtaylor> lifeless: shouldn't that just be something that's there?
[22:06] <lifeless> mtaylor: p'rhaps
[22:06] <jeblair> ii  ca-certificates                      20090814+nmu2                            Common CA certificates
[22:08] <mtaylor> lifeless: what jeblair said
[22:09] <lifeless> ok, thats current in natty
[22:09] <lifeless> do you have the curl ssl update ?
[22:10] <lifeless> (libcurl3, python-pycurl)
[22:10] <lifeless> and are you behind a ssl mitming firewall ?
[22:10] <mtaylor> lifeless: it shouldn't be
[22:10] <mtaylor> python-pycurl needs installed
[22:10] <lifeless> (don't)
[22:11] <lifeless> that excludes another bug
[22:11] <lifeless> uhm
[22:11] <lifeless> 'its not LP' :P
[22:11] <mtaylor> oh. crud. should uninstall?
[22:11] <mtaylor> :)
[22:11] <lifeless> maverick -> natty was a bump launchpadlib API change
[22:11] <lifeless> its possible thats the cause
[22:11] <lifeless> bumpy
[22:12] <mtaylor> lifeless: well, I mean - I've used launchpadlib on this box before
[22:19] <lifeless> mtaylor: sure
[22:20] <lifeless> mtaylor: I've no particular insight; there are only two servers you can be talking to (the dual apache SSL unwrappers)
[22:20] <lifeless> mtaylor: if either of those was causing browsers to fail validation we'd be innundated
[22:20] <lifeless> mtaylor: so I strongly suspect something local to that box/network.
[22:33] <mtaylor> lifeless: ok
[23:14] <lifeless> jelmer: bug 826082 - do you want to roll your function combination back, or fix it up ?
[23:14] <_mup_> Bug #826082: BadUrl from safe_open opening a branch <oops> <regression> <Launchpad itself:Triaged> < https://launchpad.net/bugs/826082 >
[23:32] <StevenK> lifeless: O hai. Can I get your opinion on https://code.launchpad.net/~stevenk/launchpad/testfix-ftpmaster/+merge/71619 ? I'm not really across testtools matching things.
[23:33] <lifeless> what about it ?
[23:33] <lifeless> the testtools spelling changed between initial landing and release
[23:34] <StevenK> Ah, right
[23:35] <jelmer> lifeless: Thanks for the analysis. I'll fix it up.
[23:40] <lifeless> jelmer: cool, thanks.
[23:40] <lifeless> jelmer: and it was all jam :)