[01:09] <lifeless> oh the irony - bug 784854
[01:09] <_mup_> Bug #784854: Questions in Launchpad Answers should be checked for double posting. <Launchpad itself:New> < https://launchpad.net/bugs/784854 >
[01:09] <lifeless> [yes, I know its not ironic. Pedants!]
[01:19] <mwhudson> wgrant: you remember we talked about running a script to update all lp branches to be stacked on +brand-id/$id
[01:19] <mwhudson> wgrant: did that happen?
[01:23] <wgrant> mwhudson: A couple of batches were started.
[01:24] <wgrant> spm and thumper hopefully know more.
[01:24] <wgrant> One run died due to a 502 during a nodowntime, I don't know what happened after that.
[01:24] <spm> oh bugger. I completely forgot to kick that again
[01:49] <wgrant> Hmm.
[01:49] <wgrant> I think the devel failure is spurious.
[01:49] <wgrant> Passes locally, doesn't really make sense...
[01:49] <wgrant> But I've never seen it before.
[01:49] <mwhudson> spm: so what is the status ?
[01:49] <mwhudson> spm: is there an rt i can subscribe to or something?
[01:50] <spm> you know. I don;'t think there is. I shall create one - makes itless likely to be forgotten.
[01:50] <mwhudson> woo process
[01:56] <wgrant> How does one subscribe to an RT, anyway? We don't have separate accounts, so it doesn't seem to be possible.
[01:59] <mwhudson> i think you just make a comment on it via email?
[01:59] <mwhudson> i'm not really sure though
[02:00] <mwhudson> definitely "rt user account" != "email address to send activity on a ticket to" as concepts though
[02:01] <wgrant> LP's RT does SSO now... maybe the IS one should too.
[02:12] <lifeless> lp's is the u1 one
[02:12] <lifeless> is need to upgrade
[02:12] <wgrant> Ah.
[02:12] <lifeless> aiui
[02:17] <lifeless> storeblob should move to the librarian directly I think
[02:18] <wgrant> Possibly. But that requires that the librarian know about more than just LFA/LFC.
[02:18] <lifeless> it already does
[02:18] <wgrant> And TLT.
[02:18] <lifeless> however I am thinking about what would be needed for a standalone blob store
[02:20] <lifeless> it seems to me that apport should be doing: a) upload a tonne of data to a gcable non-accessible area, b) handing off the result of that to something that claims a reference to the data from a)
[02:20] <wgrant> Right.
[02:21] <lifeless> now, we could do this today using the one temporary blob table
[02:21] <lifeless> with the insert from the librarian and then an update to set metadata from the appservers
[02:22] <lifeless> and refactor later to one thing owned by the librarian and another owned by the appservers
[02:23] <lifeless> if we change the gc implementation to be something like gcable = [blob for blob in store if none(map(methodcaller('references'), librarianclients))]
[02:23] <lifeless> for obj in gcable: if obj.age > 30 days: delete obh
[02:23] <lifeless> fin
[02:24] <lifeless> that wouldn't let us do fast in-librarian usage reports
[02:24] <wgrant> Yeah. I'm not entirely sure how the reference counting will work with an SOA, but it seems doable.
[02:24] <lifeless> but it would let us do them from within each service
[02:24] <lifeless> alternatively we have a 'service' concept in the librarian
[02:24] <lifeless> and we attach blobs to services
[02:25] <lifeless> and we can create a service for (e.g.) each distro
[02:25] <wgrant> Hmm, I guess, yes.
[02:25] <lifeless> for apport
[02:25] <lifeless> etc
[02:25] <lifeless> and ask for reports at the granularity of a service
[02:25] <lifeless> like 'how much data does this service have' -> ppa quota report
[02:25] <wgrant> We probably need arbitrary "tagging" for blobs, to get the groupings.
[02:25] <wgrant> Yeah.
[02:25] <wgrant> Like that.
[02:26] <lifeless> gcing of services becomes an issue then
[02:26] <lifeless> but it would be a much slower churn rate
[02:26] <lifeless> and other ubuntu/Canonical projects could get api access to make and consume services in the same pool
[02:27] <lifeless> interestingly if you look at s3
[02:27] <lifeless> aggregate reports are not exposed
[02:27] <lifeless> you can see what you used
[02:27] <lifeless> but not get 'whats the size of my bucket delilah'
[02:27] <lifeless> which suggests some possibilities about their internal model
[02:27] <wgrant> Hmm.
[02:27] <wgrant> I didn't realise that.
[02:27] <lifeless> well, IMBW
[02:28] <lifeless> I couldn't find anything in the api docs though
[02:31] <lifeless> http://docs.amazonwebservices.com/AmazonS3/latest/dev/index.html?BucketBilling.html
[02:32] <lifeless> Fees for object storage and network data transfer are always billed to the owner of the bucket that contains the object unless the bucket was created as a Requester Pays bucket.
[02:32] <lifeless> The reporting tools available at the Amazon Web Services developer portal organize your Amazon S3 usage reports by bucket.
[02:34] <lifeless> so while I can see us doing blob-storage + blob-accounting (including gc) layered on top
[02:34] <lifeless> I suspect amazon have blob-storage-and-accounting
[02:34] <lifeless> with possible microservices that scale each function (storage,accounting) separately, but that are allowed to know about each other
[02:34] <lifeless> e.g. callbacks on storage adding to the accounting service
[02:34] <lifeless> ditto downloads/uploads
[02:36] <lifeless> I think we should aim to be able to replace germanium with the librarian when we split it out
[02:36] <wgrant> There's a spec for that.™
[02:36] <wgrant> DisklessArchives on the old wiki.
[02:37] <wgrant> Would make everything much simpler.
[02:37] <lifeless> of course there is
[02:37] <wgrant> and smaller.
[02:37] <lifeless> well, a tradeoff - we'd make the impact of downtime even greater, so want to start adding in redundancy
[02:38] <wgrant> Right, but a split-out librarian should be fairly easily redundant.
[02:40] <lifeless> something like that :>
[02:41]  * wgrant constructs a bonfire to dispose of archiveuploader.
[02:41] <LPCIBot> Yippie, build fixed!
[02:41] <LPCIBot> Project devel build #731: FIXED in 5 hr 12 min: https://lpci.wedontsleep.org/job/devel/731/
[03:08] <lifeless> mtaylor: yo
[03:25] <LPCIBot> Project db-devel build #561: FAILURE in 5 hr 36 min: https://lpci.wedontsleep.org/job/db-devel/561/
[03:27] <lifeless> hmm
[03:27] <lifeless> it seems like they fail on design
[03:27] <lifeless> so no
[03:27] <wgrant> Oh?
[03:27]  * lifeless goes to the dark side and makes negative comments
[03:27] <lifeless> 'The rsync daemon requires no authentication, so it should be run on a local, private network'
[03:28] <wgrant> Have you seen the librarian lately?
[03:28] <lifeless> crunchy shell security is a pretty big WTF for a multi-tenant system
[03:28] <wgrant> Yeah.
[03:28] <lifeless> wgrant: so I'm assessing this based on:
[03:28] <wgrant> The db-devel failure is real; I am fixing.
[03:28] <LPCIBot> Project windmill-devel build #103: STILL FAILING in 47 min: https://lpci.wedontsleep.org/job/windmill-devel/103/
[03:28] <lifeless>  - testing story [I see no test fakes for us to use in their docs]
[03:29] <lifeless>  - sanity [e.g. wtf count]
[03:29] <lifeless>  - friction vs what we want [like diskless archives]
[03:29] <lifeless> their building on rsync is itself a wtf for me
[03:31] <wgrant> Hmmmmm
[03:31] <wgrant> This test is duplicated.
[03:31] <wgrant> Odd.
[03:31] <lifeless> double landing? db-devel then devel + merged silent-wrong?
[03:31] <wgrant> Doesn't look like it.
[03:32] <wgrant> They are adjacent, but it's possible.
[03:32] <lifeless> that matches the symptoms
[03:32] <lifeless> log will know
[03:33] <wgrant> Oh.
[03:33] <wgrant> Not duplicate.
[03:33] <wgrant> test_higher_radio_mentions_parent vs test_higher_radio_mentions_parents
[03:33] <lifeless> also 'The listings are stored as sqlite database files'
[03:34] <lifeless> doth NOT fill me with confidence
[03:34] <wgrant> ahaha
[03:34] <lifeless> I love sqlite
[03:34] <lifeless> but if you want K:V its more than you need
[03:34] <lifeless> and if you want SQL its less than you need for this size problem
[03:36] <lifeless> these are relatively small things
[03:36] <lifeless> But I'm finding it hard to love it
[03:38] <lifeless> aahhahahahhaha
[03:38] <lifeless> 'Currently it is recommended to use 3 (as this is the only value that has been tested). '
[03:42] <mwhudson> lifeless: what are you talking about?
[03:42] <lifeless> mwhudson: I'm doing some reading on alternative blob stores to the librarian
[03:42] <mwhudson> ah ok
[03:42] <lifeless> mwhudson: the librarian is starting to creak
[03:42] <mwhudson> ceph!
[03:42]  * mwhudson hides
[03:42] <lifeless> thats a fascinating option
[03:43] <lifeless> and one I think I've been talking about since ~ 2005
[03:43] <lifeless> but
[03:43] <lifeless> we need a layer on top of that
[03:43] <mwhudson> for gc and such?
[03:44] <lifeless> gc, accounting, url generation
[03:44] <lifeless> not to mention actually adding and removing data
[03:44] <mwhudson> huh, has "S3-compatible storage" now
[03:44]  * mwhudson gets back to hiding
[03:44] <lifeless> wheeee
[03:44] <lifeless> http://ceph.newdream.net/wiki/S3-compatible_Gateway
[03:45] <mwhudson> spm: did you make an rt about the branch-$id script thingy?
[03:45] <spm> mwhudson: not yet, no.
[03:46] <lifeless> http://ceph.newdream.net/wiki/RADOS_Gateway
[03:47] <lifeless> mwhudson: some options are: - ocfs2 + multiple librarian front-ends
[03:47] <lifeless>  - openstack swift
[03:48] <lifeless>    - with accounting hooks etc implemented
[03:48] <lifeless>  - ceph + a metadata service
[03:49] <lifeless>    - though http://ceph.newdream.net/wiki/RADOS_Gateway notes that rados is slow
[03:50] <james_w> what were you looking at with the rsync/sqlite/etc. stuff?
[03:50] <lifeless> swift
[03:52] <lifeless>  - we could do something like haystack
[03:52] <lifeless>    - given our files are all immutable, regular fs overhead is uninteresting
[04:08] <spm> mwhudson: actually, istr there was some problem with the run we did last week. will need to dig out details tho.
[04:09] <wgrant> spm: Didn't it just die with a 502 during a nodowntime?
[04:09] <spm> don't recall exactly. it may have been as simple as that
[04:11] <mwhudson> spm: this is why there needs to be an rt :)
[04:11] <spm> yes.
[04:12] <spm> wgrant: the cause per-se didn't matter; as it got complex from there as the scripts don't handle an outage gracefully. basically abort. which makes doing 300+k branhces a little more time consuming.
[04:12] <wgrant> Yeah :(
[04:17] <mwhudson> i guess it has to look at every branch for each run?
[04:17] <lifeless> yes
[04:45]  * mwhudson goes through old tabs
[04:45] <mwhudson> lifeless: didn't you say that you'd reword the "team participation / directory service" section of https://dev.launchpad.net/ArchitectureGuide/ServicesAnalysis a bit?
[04:45] <mwhudson> no worries if you just decided not to bother
[05:02] <wgrant> lifeless: https://code.launchpad.net/~wgrant/launchpad/bug-784948/+merge/61503
[05:03] <StevenK> wgrant: You can also dump the import of removeSecurityProxy
[05:03] <wgrant> Silence.
[05:03] <StevenK> :-(
[05:03] <StevenK> Only trying to help
[05:03] <wgrant> (but done)
[05:03] <wgrant> I had noticed that, but then archiveuploader tried to stab me :(
[05:03] <lifeless> mwhudson: in my queue
[05:04] <wgrant> Nasty archiveuploader.
[05:04] <lifeless> wgrant: why doesn't notification.send()
[05:04] <lifeless> log
[05:04] <lifeless> if logging is important ?
[05:05] <wgrant> lifeless: For one thing the logger would have to be passed down another level.
[05:05] <wgrant> I guess it might be useful to log the addresses, though.
[05:05] <lifeless> that seems pretty mechanical
[05:06] <lifeless> anyhow, I've commented along these lines and approved
[05:06] <wgrant> I was going for minimal solution that will unblock deployments and let me get back to more important things.
[05:06] <wgrant> Thanks.
[05:07] <lifeless> as a variation, log the email if its available
[05:08] <wgrant> (of course these logs go nowhere; the script is run with -q and no output redirection)
[05:08] <lifeless> bbbbwah
[05:08] <wgrant> Yes.
[05:08] <StevenK> That should also be fixed
[05:08] <wgrant> Yes.
[05:10] <StevenK> Hmm, where did this heat come form?
[05:10] <StevenK> *from
[05:10] <StevenK> It's 21 degrees!
[05:26] <lifeless>  wgrant how goes BFJ ?
[05:28] <wgrant> lifeless: It needs table flattening and triggers added at the next DB deploy, so BPB's data can be populated. That's still three weeks away.
[05:28] <wgrant> There are still ~2 methods that need fixing up.
[05:28] <wgrant> But that can only be done after the migration.
[05:28] <wgrant> Everything that can be done beforehand is done.
[05:29] <lifeless> cool
[05:29] <lifeless> and then a second db patch to tidy up?
[05:29] <wgrant> I was counting on being on maintenance for a couple of weeks longer, and the deploy deploy not being a week late.
[05:29] <wgrant> Right.
[05:29] <wgrant> 1) DB patch with triggers and garbo.
[05:30] <mwhudson> spm: did you make an rt about the branch-$id script thingy?
[05:31] <wgrant> 2) Normal branches to migrate to flattened tables, with lots of queries being mechanically changed and two being rewritten.
[05:31] <wgrant> 3) DB patch to drop old tables.
[05:31] <wgrant> 2's branches are mostly prepared, except for the two general query rewrites.
[05:31] <spm> mwhudson: I have opened a blank RT. what more do you want of me?!?!!?
[05:31] <wgrant> And lots of that has already landed.
[05:31] <mwhudson> spm: hey, if i can be cc:ed on updates to it, i'll shut up
[05:31] <spm> heh
[05:31] <spm> I want to believe
[05:32] <mwhudson> well, at least a bit
[05:33]  * StevenK gives up on OverridePolicy and merges in devel
[05:35] <wgrant> StevenK: You're encountering difficulties?
[05:35] <wgrant> lifeless: https://code.launchpad.net/~wgrant/launchpad/bug-784948/+merge/61503, now with added logging.
[05:39] <StevenK> wgrant: Yes.
[05:39] <StevenK> And I want the storm distinct-on thing
[05:39] <wgrant> Ah.
[05:41] <StevenK> I've stopped it caring about pockets, but it still can't locate this upload for the new test case
[05:42] <wgrant> :(
[05:43] <StevenK> Which means it gets stuffed into universe, since FromExisting didn't return anything for that SPN
[05:45] <StevenK> DAMN IT
[05:46] <StevenK> I don't specify distroseries
[05:47] <wgrant> Heh.
[05:48] <StevenK> wgrant: I'll keep my +1 for that branch with the logging changes
[05:48] <wgrant> StevenK: Thanks.
[05:50] <lifeless> grrrr
[05:50] <wgrant> Aha.
[05:50] <lifeless> rabbit fail
[05:50] <wgrant> archiveuploader is defeated.
[05:50] <wgrant> lifeless: Again?
[05:50] <lifeless> the layer
[05:51] <lifeless> tests failed when run in the whole test suite
[05:51] <lifeless> I suspect isolation fail
[05:51] <wgrant> :(
[05:51] <wgrant> It's still failing regularly in devel/db-devel.
[05:51] <lifeless> that sucks
[05:51] <lifeless> canonical.testing.ftests.test_layers.MemcachedTestCase.testRabbitWorking
[05:51] <lifeless>  canonical.testing.ftests.test_layers.DatabaseTestCase.testRabbitWorking
[05:51] <lifeless>  canonical.testing.ftests.test_layers.LibrarianTestCase.testRabbitWorking
[05:51] <lifeless>  canonical.testing.ftests.test_layers.ZopelessTestCase.testRabbitWorking
[05:51] <lifeless> erence: None != 'localhost:47565'
[05:52] <wgrant> Lovely.
[05:59] <lifeless> other layers use it
[05:59] <lifeless> and None is the default in the schema
[06:00] <spm> mwhudson: 45879 :-)
[06:00] <mwhudson> spm: w00t
[06:01] <lifeless> hey wow
[06:01] <lifeless> 702  OOPS-1964O247   Sprint:+temp-meeting-export
[06:01] <lifeless> our top count is under 1K now
[06:01] <lifeless> thats pretty awesome
[06:01] <mwhudson> let me guess, that will go away next week when it's not uds?
[06:01] <lifeless> I think the temp is a lie
[06:01] <lifeless> mwhudson: thats overnight
[06:01] <lifeless> mwhudson: so no, its already post uds
[06:02] <mwhudson> ah
[06:02] <lifeless> 23 /   20  Sprint:+temp-meeting-export
[06:02] <mwhudson> spm: do you have any idea how many branches have been processed?
[06:02] <wgrant> It only started just before UDS, though.
[06:02] <spm> mwhudson: we got about 23K done
[06:02] <mwhudson> spm: heh ok
[06:08] <wallyworld> lifeless: do you know the mechanism by which a particular url advertises to the browser that is can provide an rss feed and hence enable the rss button?
[06:09] <lifeless> which rss button
[06:09] <wallyworld> the one in the browser toolbar
[06:09] <lifeless> <meta link rel= ...
[06:10] <wallyworld> orange square
[06:10] <wgrant> (which is gone from all modern browsers, FWIW)
[06:10] <lifeless> though I think most browsers have stopped doing
[06:10] <wallyworld> i've got a bug that says rss feeds need to be disabled for private bugs
[06:10] <lifeless> thats not what it means :)
[06:11] <lifeless> also the bug says it blows up for private bugs which is arguably different
[06:11] <lifeless> but AIUI we haven't implemented authenticated feeds yet for some bizarre reason
[06:11] <wallyworld> yes but the suggested solution is just to disable rss feeds for private bugs
[06:11] <lifeless> so disabling it is probably the most reasonable expedient solution
[06:11] <wgrant> 2 things: 1) the <link> shouldn't be there. 2) there should be no login link on feeds.
[06:11] <mwhudson> feeds were designed to only be served out of squid
[06:11] <lifeless> mwhudson: a mistake
[06:11] <lifeless> :)
[06:11] <mwhudson> is the specific bizarre reason
[06:12] <lifeless> mwhudson: still a mistake, vary will let you handle authentication through squid just fine
[06:12] <mwhudson> yeah well, blame your boss's boss
[06:12] <mwhudson> lifeless: not defending it!
[06:12] <lifeless> mwhudson: elliot?
[06:12] <mwhudson> iirc
[06:12] <lifeless> heh
[06:12] <lifeless> anyhoo
[06:12] <lifeless> We can and will solve it
[06:12] <lifeless> I want to get reliable atom/rss available in the next 6-12 months, for all objects we index.
[06:13] <lifeless> so we can pshb it up
[06:14] <mwhudson> omg, someone used specificationfeedback on me!
[06:14] <wgrant> KILL THEM
[06:14] <mwhudson> wgrant: i will opt for education
[06:14] <wgrant> There are international laws against that sort of thing.
[06:14] <wallyworld> lifeless: so for now, if i look for a way to disable rss feeds for private bugs as per the suggestion in the bug report that will be ok?
[06:15] <wgrant> Come on, soyuz-upload.txt...
[06:15] <wgrant> Work please.
[06:16] <wgrant> And don't take 140s.
[07:37] <LPCIBot> Project windmill-db-devel build #294: STILL FAILING in 1 hr 9 min: https://lpci.wedontsleep.org/job/windmill-db-devel/294/
[07:53] <lifeless> wallyworld: thats fine, of course. But please stay connected ;P
[08:38] <adeuring> good morning
[08:47] <LPCIBot> Project windmill-devel build #104: STILL FAILING in 1 hr 9 min: https://lpci.wedontsleep.org/job/windmill-devel/104/
[08:50] <rvba> wgrant: thanks for fixing the test in test_distroseries.py earlier today.
[09:01] <jtv> Do we have a good pattern for adding annotations to objects that views feed to templates, without adding them to the objects and without making them persistent?  I can think of: pass a tuple of (annotation, object); pass a wrapper that delegates to the original object; or pass just a dict of relevant data to the view.
[09:04] <jtv> lifeless, any thoughts?
[09:13] <mrevell> Hi
[09:13] <jtv> hi
[09:15] <lifeless> jtv: I think lazr.delegates was intended for this sort of thing, but its terribly heavyweight
[09:16] <lifeless> jtv: another option you haven't enumerated is a lookup on the view - view/annotation/object (where annotation is callable)
[09:17] <lifeless> bigjools: hi
[09:18] <lifeless> bigjools: hi
[09:19] <bigjools> howdy
[09:19] <bigjools> howdy
[09:19] <lifeless> bigjools: https://code.launchpad.net/~lifeless/launchpad/rabbit/+merge/61057 seems to have found a test isolation issue of some sort [it has the test Layer for you]
[09:19] <jtv> lifeless: that's a good one, thanks...  I just managed to squeeze some work out of my lazy brain and got to "dict"
[09:20] <jtv> lifeless: and delegates is definitely too heavyweight; I really didn't want to add ZCML for this!
[09:26] <bigjools> lifeless: what's the isolation issue?
[09:27] <lifeless> bigjools: looks shallow - something seems to be zapping the config back to the schema default (of None) when the full test suite is run (vs when just the new tests are run)
[09:48] <jtv> allenap: something I expect to have to repeat rather a lot is "here's a DSD, what would be the package specification for a PlainPackageCopyJob that would resolve it?"  I'm about to write a function specify_dsd_package(dsd): return (dsd.source_package_name.name, dsd.parent_source_version) but did you perhaps have something for that already?
[09:49] <lifeless> bigjools: anyhow I mention that test failure
[09:49] <lifeless> bigjools: in the (vague) hope that allenap or yourself might want to land the branch
[09:49] <bigjools> heh
[09:49] <bigjools> you mean you want to offload it? :)
[09:50] <allenap> jtv: No, I don't have anything for that. It might be nice to incorporate that into an alternative PlainPackageCopyJob.create() classmethod.
[09:50] <lifeless> more that I don't want you guys blocked on me doing it
[09:50] <bigjools> I doubt we're that close yet
[09:50] <lifeless> I have a few balls to juggle right now, and while its important, its not top of the list
[09:50] <jtv> allenap: not worth the bother if it's a simple helper call.  BTW I also filed a bug yesterday for two flaws in getActiveJobs: it doesn't sort and it doesn't filter for job status.
[09:51] <allenap> jtv: I saw; sorry for creating the bugs in the first place :)
[09:51] <jtv> I'm sure it felt like a worthwhile effort at the time.  :)
[09:52] <jtv> I _would_ fix them en passant but am slightly too woozy right now.  Also, can't just fix it without tests.
[09:52] <jtv> (Glad I didn't tackle this earlier since I just disposed my dead-end branch)
[09:54] <jtv> WTF?  Why doesn't it show up as my last-reported bug?
[09:55] <allenap> lifeless: I'm reviewer today, so I might have a go with that layer branch.
[09:55] <lifeless> allenap: I'll forward you the ec2 output
[09:55] <allenap> Thanks.
[09:55] <LPCIBot> Project db-devel build #562: STILL FAILING in 5 hr 41 min: https://lpci.wedontsleep.org/job/db-devel/562/
[09:57] <jtv> allenap, bigjools: bug 784515
[09:57] <_mup_> Bug #784515: PlainPackageCopyJob.getActiveJobs should check job status <derivation> <Launchpad itself:Triaged> < https://launchpad.net/bugs/784515 >
[10:02] <bigjools> jtv: yeah that's not good is it :)
[10:02] <jtv> possibly not
[10:17] <StevenK> allenap: Are you up for a reviewing an oversized branch?
[10:17] <StevenK> allenap: It is effectively moving the code and massaging it to work
[10:18] <allenap> StevenK: Yeah, okay.
[10:18] <StevenK> allenap: https://code.launchpad.net/~stevenk/launchpad/announcements-copies/+merge/61516
[10:18] <StevenK> allenap: The two methods at the top of notification that aren't exported are the end-goal
[10:19] <allenap> StevenK: Okay, I assume I'll understand what that means when I read the code :)
[10:19] <StevenK> Hopefully it does
[10:23] <henninge> Does anybody see a potential hurt in piping LP.cache['context'] through obfuscate-email, like so? http://paste.ubuntu.com/609988/
[10:24] <henninge> obfuscate-email is only applied on anonymous requests
[10:24] <henninge> wgrant: ^ ?
[10:26] <wgrant> henninge: Ugh.
[10:27] <wgrant> henninge: I have no idea how to solve this.
[10:27] <henninge> wgrant: what do you mean?
[10:27] <henninge> it is solved
[10:27] <henninge> I mean, that works
[10:28] <henninge> I am just wondering if I missed any effect because this is a rather simple solution
[10:28] <wgrant> Yeah, until it leaks somewhere we don't want and all the email addresses in the DB get erased.
[10:29] <henninge> Ah
[10:30] <henninge> wgrant: you said yesterday that the cache is not really needed on anonymous pages.
[10:30] <wgrant> It seems perilous to be sending out bad data in a machine-readable format, when it looks fine in most circumstances.
[10:30] <wgrant> Then someone writes a tool that uses it.
[10:30] <wgrant> And goodbye email addresses.
[10:30] <henninge> yes, I see the danger
[10:31] <henninge> there are two general  solutions that I see
[10:31] <henninge> 1- Not send out the data
[10:31] <henninge> 2 - check all data for obfuscated email addresses
[10:32] <henninge> all *received* data that is
[10:37] <henninge> wgrant: yes, thinking about it the only general solutionwould be to reject all data on the the webservice that contains <email address hidden> because whoever is doing that is doing something wrong.
[10:39] <StevenK> allenap: Still looking through it?
[10:40] <lifeless> well
[10:40] <lifeless> <email address hidden> is an invalid email address
[10:40] <lifeless> won't pass the parsers
[10:41] <lifeless> I like not calculating and sending data we don't need to calculate and send
[10:41] <wgrant> lifeless: This is in stuff like bug descriptions.
[10:46] <lifeless> wgrant: ahhh so
[10:46] <lifeless> yes
[10:47] <lifeless> henninge: rejecting incoming corrupt data would be a poor choice because how do you file a bug about it then ?
[10:47] <wgrant> The correct term is "abandon all hope"
[10:47] <wgrant> Exactly.
[10:47] <wgrant> We can't reject it.
[11:03] <allenap> StevenK: My laptop is deciding to sporadically reboot itself. Still going...
[11:09] <wgrant> Despite the MP's apparent pointlessness, I support it as a first step :)
[11:12] <StevenK> Haha
[11:23] <allenap> StevenK: Done, at last.
[11:24] <StevenK> allenap: The two things you said to ditch are the "end goal" method
[11:25] <StevenK> allenap: As in things like the archiveuploader, the package copier will just call notification() and everything happens.
[11:25] <allenap> StevenK: Oh, okay, so they're empty shells that will be filled later. Fine.
[11:25] <StevenK> allenap: I will ignore your bug, since the next step is to refactor all this next.
[11:26] <StevenK> allenap: Thank you for the review, and sorry for the over-sizedness
[11:26] <wgrant> Ah, I see you raise the class argument that StevenK and I had earlier.
[11:26] <wgrant> Why do you feel a class would be beneficial?
[11:26] <wgrant> There is no state.
[11:27] <allenap> StevenK: No worries :)
[11:57] <bigjools> jkakar: perl? ew!
[11:58] <jkakar> bigjools: I know.  Ugh.
[11:58] <jkakar> bigjools: I'm trying to run some tests for a Fluidinfo client library... not getting anywhere... I did Perl years ago, but I've (thankfully) forgotten it all.
[11:59] <bigjools> I have studiously avoided perl
[12:03] <lifeless> wallyworld_: yes thats fine
[12:03] <wallyworld_> ok
[12:04] <StevenK> Nothing wrong with Perl.
[12:19] <lifeless> StevenK: nothing ... right with it either
[12:19] <lifeless> :)
[12:32] <bigjools> StevenK: ... that high explosive won't fix
[12:41] <wgrant> henninge: Are you guys keeping an eye on Answers? The backlog is approaching 36 hours.
[13:08] <henninge> wgrant: thanks, I will look at it
[13:15]  * henninge relocates first
[13:41] <adeuring> allenap: could you please have a look at this mp: https://code.launchpad.net/~adeuring/launchpad/bug-739065/+merge/61555 ?
[13:42] <allenap> adeuring: Sure.
[13:42] <adeuring> thanks!
[13:43] <mrevell> allenap, https://code.launchpad.net/~matthew.revell/launchpad/karma-help-bug93410 I have a particular question. Let me know when you have the branch running at lp.dev
[13:45] <wallyworld_> sinzui: question for you if you are around
[13:51] <jtv> allenap: busy review day?
[13:52] <allenap> jtv: I can fit you in :)
[13:52] <jtv> Great, thanks!
[13:53] <jtv> It's https://code.launchpad.net/~jtv/launchpad/db-bug-781514/+merge/61557
[13:53] <allenap> mrevell: Ready when you are.
[13:55] <mrevell> Hello allenap. If you log in and go to your person overview page, I've put a help link beside the karma score. This links to the help page on help.lp.net but in a pop-up window. I'm not satisfied with that, it looks a bit odd to my eyes. But there's already a help link on that page and I think it'd also look odd if they behaved differently (i.e. the question mark mouse pointer only appears if the help link has a t
[13:55] <mrevell> arget of "help"). Any thoughts?
[13:58] <allenap> mrevell: You're right, it does look odd.
[13:59] <mrevell> allenap, I could replace it with this: https://help.launchpad.net/YourAccount/Karma?action=print
[14:00] <mrevell> allenap, I'm reluctant to create a new help text file in the tree if it's just gonna duplicate the contents of a help wiki page. Probably what I'll do is write a short help wiki pop-up and link it to the fuller wiki page.
[14:01] <allenap> mrevell: I think you need to speak to a UX person really. I think they should all look the same :-/ I guess you could have a quick overview in the frame, with a link in there to the wiki with target="_top".
[14:02] <mrevell> allenap, I'll do that ... quick overview and a link that targets _top. Thanks.
[14:02] <allenap> mrevell: Tip top.
[14:08] <bac> matsubara: is the qabot not working currently?
[14:08] <sinzui> wallyworld_: I am about, but I am decaffeinated.
[14:08] <matsubara> bac, it should. what happened?
[14:09] <matsubara> unless Ursula disabled it for a rollout or something
[14:09] <bac> matsubara: bugs have been deployed but it hasn't done it's magic on them
[14:09] <bac> the deployment report looks stale too
[14:11] <wallyworld_> sinzui: the rss feed for private bugs; i've disabled it and also did the same for private branches. sadly, if you use the inline ajax editing to change the privacy status, the rss feed isn't toggled. i'm wondering if we want to land what's done and working and raise a new bug for the ajax work
[14:11] <matsubara> bac, looking into it.
[14:11] <bac> thx
[14:13]  * deryck disappears for reboot but will brb
[14:13] <sinzui> wallyworld_: I do not think that is an issue unless users actually experience the bug
[14:14] <abentley> henninge: do you want to mumble about this bug a bit more?
[14:14] <henninge> abentley: sure, but give me a few minutes. Say at :30 ?
[14:15] <abentley> henninge: sure.
[14:15] <henninge> thanks
[14:17] <wallyworld_> sinzui: they will see the issue i think if a bug was public and is changed to private. the rss feed button will still be enabled and hence the situation will be as per the bug report. but my claim is that this is a corner case that will hardly ever eventuate. a page refresh will fix it up at this point also
[14:17] <sinzui> wallyworld_: Then the bug is not fixed!
[14:18] <sinzui> wallyworld_: RSS feeds cannot contain private information, They are intended for anonymous users
[14:19] <wallyworld_> sinzui: no argument there. i was asking about landing the fix in two branches. but i'll do it in the one branch
[14:19] <sinzui> wallyworld_: It is always okay, and desirable, to land multiple branches
[14:20] <wallyworld_> sinzui: ok. will get the current branch in and do the ajax work separately. thanks.
[14:23] <jcsackett> wallyworld_: your various reviewers will never complain about smaller branches to review, either. :-p
[14:23] <wallyworld_> jcsackett: yeah. and i've had some large ones recently too
[14:23] <abentley> wallyworld_: been meaning to ask: Why did you implement performDailyBuilds as a new method, rather than extracting it from makeDailyBuilds?
[14:24] <mrevell> allenap: Where is the queue of people waiting for reviews now? it used to be in the channel topic.
[14:24] <wallyworld_> abentley: give me a second to look at the code. it's been a while :-)
[14:24] <mrevell> allenap, Or is it just the +activereviews you look at now?
[14:25] <allenap> mrevell: There is no queue. I'm doing adeuring's review at the moment, and will be following up with jtv's.
[14:25] <abentley> mrevell: We use +activereviews, but you should still request someone to look at yours.  They can claim the proposal on the web.
[14:25] <mrevell> Thanks abentley.
[14:25] <mrevell> jcsackett, allenap: Would either of you care to take a look at this? https://code.launchpad.net/~matthew.revell/launchpad/karma-help-bug93410/+merge/61566
[14:31] <jcsackett> mrevell: sure.
[14:31] <wallyworld_> abentley: makeDailyBuilds is called from the cron script and has logging and slightly different error handling to performDailyBuilds which is called from the ui via an ajax call
[14:32] <henninge> abentley: I am ready now
[14:32] <abentley> wallyworld_: I think it's a DRY violation, and it caused me to waste a bunch of time "fixing" the wrong method.
[14:32] <mrevell> thanks jcsackett
[14:32] <abentley> henninge: starting up.
[14:34] <wallyworld_> abentley: sorry. at the time i thought there was enough of a difference (maybe i still do, not sure) to justify the separate implementations. they both call requestBuild but the calling environment and especially exception handling is different
[14:35] <jcsackett> mrevell: r=me. martin has a comment on the MP that's probably worth considering, but i don't think it's a block to approval.
[14:35] <mrevell> Thanks jcsackett
[14:41] <LPCIBot> Project windmill-devel build #105: STILL FAILING in 48 min: https://lpci.wedontsleep.org/job/windmill-devel/105/
[14:43] <matsubara> bac, it's now up to date. UrsulaJ is investigating why it stopped.
[14:43] <bac> thanks matsubara
[14:49] <nigelb> ok, the bug I fixed is in qastaging.
[14:51] <nigelb> can I do the verification myself? Or someone else should be doing it?
[14:54] <wgrant> nigelb: You can do it. Check that it works and doesn't break stuff, and tag the bug qa-ok.
[14:59] <nigelb> wgrant: Awesome, thanks.
[15:01] <nigelb> haha, I caused a timeout doing something else :p
[15:02] <wgrant> :(
[15:03] <nigelb> I realized the db in that is old, so I couldn't access the project.  I just wanted to see how old and clicked the branch.  BANG. Timeout.
[15:05] <nigelb> wgrant: Okay, tested.  Worked.  Now remove qa-needstesting and make it qa-ok ?
[15:06] <wgrant> nigelb: Right.
[15:06] <nigelb> okay, done!
[15:06] <nigelb> Now sit tight and wait till the rev gets deployed to production?
[15:09] <wgrant> Probably in about 10 hours, unless stuff breaks overnight.
[15:14] <deryck> nigelb, hey, welcome as a contributor to launchpad now!
[15:14] <nigelb> deryck: \o/ :)
[15:15] <nigelb> Its addictive, I'm already looking for another bug to fix.
[15:16] <bigjools> I have loads you can do ;)
[15:16] <nigelb> bigjools: beginner friendly? ;)
[15:17] <bigjools> nigelb: you didn't specify that :)
[15:17] <nigelb> heh
[15:17] <rvba> I've got a strange error when I run "./utilities/ec2 land my-mp-url": http://paste.ubuntu.com/610096/
[15:17] <rvba> Any idea anyone?
[15:17] <nigelb> I'll admit I don't know enough zope to fix the more harder bugs.
[15:17] <bigjools> nigelb: btw I'm sorry we didn't meet at UDS, unfortunately time was too short for me
[15:17] <rvba> (The error itself is "AttributeError: 'Entry' object has no attribute 'queue_status'")
[15:18] <nigelb> bigjools: wait, you were *at* UDS?
[15:18] <bigjools> yes :)
[15:18] <bigjools> for 1.5 days
[15:18] <nigelb> Darn
[15:18] <nigelb> I'm sorry I didn't find you
[15:18] <nigelb> ahh
[15:18] <bigjools> I am the freakishly tall dude
[15:18] <bigjools> well, there's a few of us like that thinking about it
[15:19] <nigelb> At this point, noodles is the freakishly tall dude I remember.
[15:19] <nigelb> :P
[15:19] <bigjools> yes we're the same height roughly
[15:19] <nigelb> hah
[15:19] <bigjools> he used to work in my team
[15:19] <nigelb> If I do turn up at another UDS, I'll make sure I find you :)
[15:20] <nigelb> I know, I did tell him I remember him from #launchpad
[15:20] <bigjools> sure thing
[15:22] <bigjools> rvba: seems like nobody wants to answer you! perhaps take it to the list
[15:23] <rvba> bigjools: it's for landing my 2nd performance branch. I think I'll sleep on it first and focurs on getting something done on the overlay front today.
[15:24] <nigelb> bug 4595 surely can't be fixed anymore.  I don't think there are tooltips anymore that the bug doesn't exit.
[15:24] <_mup_> Bug #4595: Don't auto-linkify non-existent bug reports <easy> <lp-web> <tales> <ui> <Launchpad itself:Triaged> < https://launchpad.net/bugs/4595 >
[15:24] <bigjools> rvba: it's a problem when it triest to get at the MP over the webservice.  It looks like the code is out of step with production, but that's just weird.
[15:24] <bigjools> tries(
[15:27] <rvba> I'll see if any of the libraries used is suspiciously recent.
[15:29] <bigjools> I can't see anything obvious, I looked at the MP interface
[15:35] <deryck> henninge, how's the question answering work coming?
[15:35] <henninge> deryck: just started ;-)
[15:35] <deryck> henninge, ah, ok.  np.  Just doing my duties as well and didn't want to conflict with you.
[15:36] <henninge> deryck: yeah, better you pick something else
[15:36] <deryck> np.  I'll do project review now.  I've just been working down the list.
[15:56] <nigelb> ok, picked a new bug to fix, bug 203478
[15:56] <_mup_> Bug #203478: Meeting attendees should be sorted by display name <easy> <lp-blueprints> <sprints> <ui> <Launchpad itself:Triaged> < https://launchpad.net/bugs/203478 >
[15:56] <nigelb> hopefully, I can kick out the fix today, writing the tests though are an entirely different matter :\
[15:58] <deryck> nigelb, you could start with the test.  I can chat with you about how to write a test for this, if you'd like.
[15:58] <nigelb> deryck: Yes, I'd love that.
[15:59] <deryck> nigelb, ok, let me look at the bug to make sure I know the problem.
[16:01] <deryck> nigelb, ok, this shouldn't be bad.  I would probably add a test to lib/lp/blueprints/browser/tests/test_sprint.py
[16:01]  * deryck is looking for an example of something similar to point nigelb at
[16:02] <nigelb> makePerson and make two people
[16:02] <nigelb> and then add them to the sprint
[16:04] <nigelb> but hrm, how would I actually figure out that the name and display name are in different order
[16:06] <deryck> nigelb, broadly you would use the factory to create people with some made up names, then sort those names and then compare to the list in the page.
[16:07] <deryck> nigelb, look in lib/lp/registry/tests/test_mailinglist.py for test_getSenderAddresses_dict_keys for something similar.
[16:07] <nigelb> okay
[16:08] <deryck> nigelb, I imagine (I haven't looked) that the template has a view method that returns the list of people.  your test would assert that the expected name order matches what this method returns.
[16:08] <nigelb> I know the method that returns the list of people.
[16:08] <deryck> ok, great.
[16:09] <deryck> nigelb, and this method is on the view class, yes?
[16:09] <nigelb> no, its on the model class
[16:09] <deryck> nigelb, ok.  so I would add the test to a different file, since you're testing the model not the view
[16:09]  * deryck looks....
[16:09] <nigelb> attendances in lib/lp/blueprints/model/sprint.py
[16:11] <deryck> nigelb, ok, so I would add a new test file lib/lp/blueprints/model/tests/test_sprint.py and add a test case class with a test method that checks this.
[16:11] <deryck> nigelb, there is a sample test file in the top of the tree, IIRC
[16:11] <nigelb> yeah, I used that last time :)
[16:13] <deryck> nigelb, awesome.  let me know if you need anymore help.  I don't mind.
[16:13] <nigelb> deryck: let me see how far I can get without the temptation to headdesk.  At that point, I'll ping you :)
[16:14] <deryck> nigelb, ok, sure. :-)
[16:25] <jtv> thanks for the review, allenap!  I'll bother jcsackett for the next one.  :)
[16:25] <jtv> jcsackett: speaking of which... Good morning!  Got room for this review?  https://code.launchpad.net/~jtv/launchpad/bug-785190/+merge/61594
[16:26] <jcsackett> jtv: sure, i'll look at it in just a few.
[16:26] <jtv> Thanks
[16:35] <gmb> allenap, jcsackett: Can one of you take a look at this for me: https://code.launchpad.net/~gmb/launchpad/fix-oops-with-teams-bug-778847/+merge/61600
[16:38] <nigelb> How do I run a test written in model/tests?
[16:39] <gmb> nigelb: bin/test -ct test_filename should work.
[16:39] <gmb> The test runner magically finds the tests.
[16:39] <nigelb> magic! nice :)
[16:40] <jcsackett> gmb: looking at your MP now.
[16:40] <gmb> jcsackett: Tahnks
[16:45] <nigelb> ok, this is strange. The didn't fail.
[16:46] <nigelb> ah, it ran the test_sprint from lib/lp/blueprints/browser/tests instead of lib/lp/blueprints/model/tests
[16:47] <jcsackett> gmb: r=me, with a small comment on the MP.
[16:47] <gmb> jcsackett: Thanks.
[16:50] <nigelb> gmb: "bin/test -ct test_sprint", but its running the browser test instead of model test, is there a way to specify I want to run the model test?
[16:51] <gmb> nigelb: You could specify it as:
[16:51] <gmb> bin/test -ct python.path.to.test_file
[16:51] <gmb> (e.g.
[16:51] <gmb> bin/test -ct lp.bugs.tests.test_bug.py
[16:51] <gmb> )
[16:51] <nigelb> ah
[16:51] <gmb> s/.py//
[16:52] <LPCIBot> Project windmill-db-devel build #295: STILL FAILING in 1 hr 9 min: https://lpci.wedontsleep.org/job/windmill-db-devel/295/
[16:55] <jtv> thanks jcsackett
[16:57] <nigelb> gmb: "bin/test -ct lp.blueprints.tests.test_sprint" and "bin/test -ct lp.blueprints.model.tests.test_sprint" didn't work :(
[16:57] <gmb> Hmm.
[16:59]  * gmb tries it
[17:02] <gmb> nigelb: Is test_sprint a new file for you? I don't see it in my tree...
[17:02] <nigelb> gmb: oops I should have told you.  I just wrote it
[17:02] <gmb> nigelb: bin/test -ct blueprints.model.tests.test_specification works for me, for example.
[17:02] <gmb> ah.
[17:02] <gmb> nigelb: Can you paste the file in Etherpad for me? There might be something missing from it...
[17:03] <nigelb> gmb:  http://pad.ubuntu.com/CSDp1HJN53
[17:04] <gmb> nigelb: Ah, here might be the problem: You've got TestCaseWithFactoryImported but you subclass TestCase.
[17:05] <nigelb> ahh
[17:05] <nigelb> let me try with that fixed
[17:07] <nigelb> gmb: *facepalm*
[17:07] <gmb> Heh.
[17:07] <nigelb> gmb: That isn't what went wrong.
[17:07] <nigelb> its even more sillier than that.
[17:07] <gmb> :)
[17:08] <nigelb> gmb:  So, I was writing the test in the devel branch instead of my branch and running the test in my branch. *headdesk*
[17:08] <gmb> nigelb: Haha. I've done that before too.
[17:08] <gmb> Oh well.
[17:08] <gmb> Anyway, working now?
[17:08] <nigelb> copying over now
[17:08] <gmb> Cool.
[17:10] <nigelb> aha, now it explodes because its wrong.  Happier.
[17:10] <gmb> Cool.
[17:27] <nigelb> ok, I need help.
[17:28] <nigelb> the method I thought I should assert with doesn't return what I thought it would, causing the test to fail.
[17:30] <nigelb> and here's a paste of the failing test http://paste.ubuntu.com/610159/
[17:33] <deryck> nigelb, you want to convert the list of objects to a list of names.  something like [person.displayname for person in obj.method()]
[17:33] <nigelb> deryck: the one returned by sprint.attendances?
[17:33] <deryck> oh wait
[17:33] <deryck> nigelb, I didn't look close enough, sorry
[17:34] <nigelb> the sprint.attendances is where I'm running into trouble
[17:36] <maxb> URL forms like /+branch/projectname seem to work for bzr+ssh, web ui, loggerhead, but NOT for http branch access. Is this intentional? oversight? not-a-bug?
[17:40] <deryck> nigelb, ok, so you have a list of person objects comparing to a list of attendees.  but I believe attendee.attendee_id should match person.id
[17:40] <deryck> nigelb, so match the list of ids.
[17:41] <nigelb> deryck: so sprint.attendances.id?
[17:41] <nigelb> or sprint.attendances.attendee.attendee_id?
[17:41] <deryck> that one ^^ attendee_id
[17:42] <deryck> nigelb, and person may have this as well.  person_id or personID.  but even I get confused about which model classes use this.
[17:42] <deryck> use which form I mean.  so I was just suggesting the direct look up on person to make it easier on you.
[17:43] <deryck> nigelb, actually, never mind on that person_id thing. that's for related objects
[17:43] <nigelb> oh
[17:43]  * deryck is trying to multi-task and it shows
[17:43] <nigelb> heh
[17:43] <nigelb> so what should I be now to fix the test?
[17:45] <deryck> nigelb, my orginal suggestion is still right.  I just meant to ignore my person_id comment.  so....
[17:45] <nigelb> ah
[17:45] <deryck> SprintAttendance.attendee_id == Person.id
[17:46] <deryck> nigelb, ^^ so you need a list of attendee_id's and person ids and compare those lists.
[17:46] <jtv> jcsackett: one more for the road?  https://code.launchpad.net/~jtv/launchpad/db-bug-782096/+merge/61612
[17:46] <jcsackett> jtv: sure.
[17:47] <jtv> thanks
[17:47] <nigelb> deryck: okay, this is going to be vastly more efficient if I just show you what I have now and if you can point out what needs changing.
[17:47] <deryck> nigelb, yes, probably so.  sorry :-)
[17:47] <deryck> jcsackett, hi.  can you do a review for me?
[17:47] <nigelb> deryck: heh, its okay. http://pad.ubuntu.com/CSDp1HJN53 is what I have.
[17:48]  * deryck looks
[17:48] <jcsackett> deryck: sure.
[17:50] <deryck> nigelb, I think what I've added should work.  minor _id change, and then a little style change....
[17:50] <deryck> nigelb, we don't use one letter variables, even in list comprehessions.
[17:50] <deryck> jcsackett, thanks!  https://code.launchpad.net/~deryck/launchpad/keyserver-port-fix-785155/+merge/61609
[17:50] <nigelb> deryck: okay, ah, didn't know about the style :)
[17:50] <deryck> nigelb, no worries.  someone would have mentioned it in review, I'm sure.
[17:50] <jcsackett> jtv: i see that your branch fixes the status issue. how does it solve the ordering issue?
[17:51] <deryck> nigelb, we also indent functions calls differently.  I'll show you there, too....
[17:51] <nigelb> aha
[17:51] <jtv> jcsackett: I wrote an order_by... did that get lost somewhere?
[17:52] <jcsackett> jtv: i don't see an order_by in the diff.
[17:52] <deryck> nigelb, assuming I'm still in 79 characters, what I did should work.  make lint in the tree will tell you for sure.
[17:52] <nigelb> deryck: attendee_id didn't work, but attendee.id did!
[17:52] <nigelb> deryck: (well, it failed.  But that was the whole point ;) )
[17:53] <deryck> nigelb, show me the failure in paste please?
[17:53] <nigelb> okay
[17:53] <nigelb> deryck: I haven't modified the code yet, so the failure I get now is expected failure I think.
[17:53] <jtv> jcsackett: no idea where that went then... let me just restore it.
[17:53] <jcsackett> jtv: ok. :-)
[17:53] <nigelb> http://paste.ubuntu.com/610165/
[17:54] <jcsackett> deryck: that's a very small branch, and a very good one. r=me.
[17:57] <deryck> jcsackett, thanks.
[17:57] <deryck> nigelb, yup, that looks good.
[18:01] <LPCIBot> Project windmill-devel build #106: STILL FAILING in 1 hr 8 min: https://lpci.wedontsleep.org/job/windmill-devel/106/
[18:04] <bigjools> good night everyone
[18:05] <nigelb> night bigjools
[18:05] <jtv> jcsackett: the diff has finally updated
[18:06] <jcsackett> jtv: r=me, with the return of the order_by. :-)
[18:06] <jtv> thanks!
[18:10] <nigelb> deryck: I changed the code that I was supposed to change to get it to work, still doesn't work :(
[18:10] <deryck> nigelb, test fails in the same way?
[18:10] <nigelb> deryck: yeah
[18:11] <deryck> nigelb, can you paste a diff as it is now?
[18:12] <nigelb> deryck: bah, ignore me. same problem as earlier. :/
[18:12] <nigelb> Note to self: Never open devel branch ever.
[18:12] <deryck> nigelb, ok, np
[18:27] <nigelb> jcsackett: Hi, could you review https://code.launchpad.net/~nigelbabu/launchpad/203478-meeting-sort/+merge/61623 for me? :)
[18:30] <jcsackett> sure, looking now nigelb.
[18:30] <nigelb> Thanks :)
[18:43] <jcsackett> nigelb: r=me, though i did leave one comment on your MP.
[18:44] <nigelb> jcsackett: I'll fix that.  What does r=me mean?
[18:45] <nigelb> jcsackett: (This is my second bug fix to LP :))
[18:45] <jcsackett> nigelb, sorry, it means i approved your branch. :-)
[18:45] <nigelb> ah
[18:45] <jcsackett> when code is landed in lp, the commit is tagged with the reviewer name, (so your branch will land with r=jcsackett)
[18:45] <nigelb> ah
[18:45] <jcsackett> "r=me" has become shorthand for "i approve this."
[18:46] <nigelb> do I need to place the commit message with that tag or is that done by whoever lands it?
[18:52] <jcsackett> that's done automatically.
[18:52] <jcsackett> the tags are just added to the commit message you give it in the mp, or the person landing provides.
[18:55] <nigelb> jcsackett: aha.  anyway, I pushed with the change you mentioned in the MP.  Now I bug someone to land it? ;)
[18:56] <jcsackett> nigelb: yup, all is good. i can go ahead and send it out, if you like.
[18:56] <nigelb> jcsackett: please do :)
[19:19] <jcsackett> nigelb: it's out to the full testsuite and from there to land.
[19:19] <nigelb> jcsackett: Thanks!
[19:19] <jcsackett> if it fails the testsuite you and i will both be notified via email.
[19:19] <LPCIBot> Project windmill-devel build #107: STILL FAILING in 48 min: https://lpci.wedontsleep.org/job/windmill-devel/107/
[19:19] <jcsackett> actually, you should be notified both for failure or success, but failure is the option requiring you to do more work. :-)
[19:20] <jcsackett> nigelb, i would expect you to get the email either way in 4 to 6 hours.
[19:21] <nigelb> heh
[19:21] <nigelb> so, I shall wake up to an email :)
[19:22] <abentley> gary_poster: around?
[19:23] <gary_poster> abentley, hi, yes, but I have call in 7
[19:23] <abentley> gary_poster: do you know where we configure the python logger to generate oopses?
[19:25] <gary_poster> abentley, I'm not sure, though some python log configuration is in ./configs/development/launchpad.conf
[19:27] <abentley> gary_poster: it's wacky, because it appears to be implemented by OopsLoggingHandler, but OopsLoggingHandler isn't used AFAICT.
[19:28] <gary_poster> abentley, heh, I see what you mean
[20:05] <LPCIBot> Project windmill-devel build #108: STILL FAILING in 45 min: https://lpci.wedontsleep.org/job/windmill-devel/108/
[20:07] <bac> jcsackett: review?  https://code.launchpad.net/~bac/launchpad/bug-777789/+merge/61638
[20:08] <jcsackett> bac: sure, just a moment.
[20:08] <bac> jcsackett: thanks
[20:13] <jcsackett> bac: r=me.
[20:13] <jcsackett> today has been a number of short branches. i dig it.
[20:13] <bac> jcsackett: thanks
[20:16] <LPCIBot> Yippie, build fixed!
[20:16] <LPCIBot> Project db-devel build #563: FIXED in 5 hr 34 min: https://lpci.wedontsleep.org/job/db-devel/563/
[20:51] <LPCIBot> Project windmill-devel build #109: STILL FAILING in 46 min: https://lpci.wedontsleep.org/job/windmill-devel/109/
[20:58] <sinzui> jcsackett: do you have time to review https://code.launchpad.net/~sinzui/launchpad/suppress-url-hacker-oops/+merge/61617
[20:58] <nigelb> http://justanothertriager.wordpress.com/2011/05/20/fixing-launchpad-bugs/ :)
[21:13] <jcsackett> sinzui: looking now.
[21:18] <lifeless> statik: hi ?
[21:20] <lifeless> morning y'all
[21:24] <jcsackett> sinzui: r=me.
[21:24] <sinzui> thank you jcsackett
[21:28] <LPCIBot> Project windmill-db-devel build #296: STILL FAILING in 1 hr 12 min: https://lpci.wedontsleep.org/job/windmill-db-devel/296/
[21:30] <lifeless> sinzui: I think you are missing a test
[21:30] <lifeless> sinzui: that may show a bug
[21:31] <sinzui> oh
[21:31] <sinzui> lifeless: What needs testing?
[21:31] <lifeless> code.launchpad.dev
[21:32] <lifeless> as well as launchpad.dev
[21:32] <lifeless> we should ignore cross-vhost self links
[21:32] <lifeless> sorry
[21:32] <lifeless> we should *not* ignore cross-vhost self links
[21:34] <sinzui> lifeless: I think the check is does that. I can add a test where the referer is bazaar.launchpad.net and verify that the oops is reported
[21:34] <lifeless> please
[21:34] <lifeless> I may be wrong, but it would be lovely to be sure
[21:34] <sinzui> one moment
[21:34] <lifeless> (and safe if someone else refactors)
[21:38] <sinzui> lifeless: This test passes. Is it what you mean: http://pastebin.ubuntu.com/610261/
[21:38] <sinzui> lifeless: indeed safety  from refactors is important.
[21:39] <lifeless> ah, I see
[21:39] <lifeless> so you check that 'launchpad.net' in 'bazaar.launchpad.net'
[21:39] <lifeless> great.
[21:39] <lifeless> and yes that test is the key
[21:40] <lifeless> we could plausibly have one where the server url is code.launchpad.net and the referer 'launchpad.net'
[21:40] <lifeless> for completeness. I don't know if thats really needed or not.
[21:48] <sinzui> lifeless: okay, I will add that. Yes the check is  that the mainsite's root url is in the the referer, where I used urlparse to get the netloc of both
[21:50] <deryck> jcsackett, hi again.  Can you do another smallish review for me?
[21:51] <jcsackett> deryck: sure.
[21:51] <deryck> jcsackett, oh, never mind.  lifeless did it already.
[21:51] <jcsackett> cool. :-)
[21:52] <deryck> lifeless, would the new low bug not be covered by your related bug 781854?
[21:52] <_mup_> Bug #781854: oauth consumer banning bans tokens from all users with the same consumer label <Launchpad itself:Triaged> < https://launchpad.net/bugs/781854 >
[21:53] <lifeless> deryck: well, 781854 might be closed if my analysis is wrong, and if so wouldn't fix the thing about user agent
[21:53] <lifeless> deryck: *if* we do do 781854, then yes, it would be covered.
[21:53] <deryck> lifeless, ack.  I'll open a new bug then.
[21:53] <deryck> just to be safe.
[21:53] <lifeless> deryck: Alternatively you could change your fix to just use a consumer key like 'anonymous client'
[21:54] <lifeless> deryck: rather than the user-agent.
[21:54] <lifeless> and nuke the bit of the test claiming that its needed.
[21:54] <lifeless> deryck: but I don't want to suggest you do more work :) [OTOH it looks very easy to me]
[21:55] <deryck> lifeless, yeah, if you don't think that would have unintended consequences, I don't mind making that change.
[21:55] <deryck> it does look pretty straight forward.
[21:56] <lifeless> deryck: I can't see any consequences we couldn't change in the future :)
[21:56] <lifeless> deryck: and user-agent isn't a trustable field anyway
[21:56] <deryck> lifeless, I meant more of the deryck-will-be-chasing-20-test-failures-tomorrow kind :)
[21:57] <lifeless> deryck: ah. So we know the test suite passes today.
[21:57] <lifeless> which means that we use a user agent, or authentication, on all api-exercising tests.
[21:57] <lifeless> there may be other tests looking for the failure.
[21:57] <lifeless> But there can't (by definition) be other tests that use the api dependent on the old behaviour - only the tests for the guts of the anonymous support [which consumer is used etc]
[21:58] <lifeless> so there might be other tests of this behaviour scattered around, but I expect that all fallout would be very shallow
[21:58] <lifeless> like 'delete that test' shallow
[21:59] <deryck> lifeless, yeah, I'm okay to give this a try.  I can always revert to what you've approved if there is massive test fallout.
[21:59] <lifeless> cool!
[22:05] <james_w> http://blip.tv/ubuntu-developers/ubuntu-uds-o-budapest-friday-plenary-lightning-talks-5182944 at 18:00 is jml's lightning talk
[22:05] <lifeless> thanks
[22:05] <james_w> of particular interest to the yellow squad
[22:07] <deryck> lifeless, how about now?  https://code.launchpad.net/~deryck/launchpad/dont-oops-on-api-without-user-agent-781262/+merge/61662
[22:13] <deryck> I'm out now.  Later one everyone!
[22:19] <lifeless> james_w: starts at 17:40
[22:19] <lifeless> james_w: great applause in it though :)
[22:23] <sinzui> jcsackett: r=me with the addition of a second test for half-escaped data
[22:23] <jcsackett> sinzui: dig.
[22:23] <jcsackett> thanks.
[22:35] <lifeless> nigelb: flask looks interesting
[22:37] <LPCIBot> Project windmill-devel build #110: STILL FAILING in 1 hr 9 min: https://lpci.wedontsleep.org/job/windmill-devel/110/
[22:47] <jcsackett> lifless: you referring to the framework?
[22:47] <jcsackett> lifeless, rather. :-P ^
[22:49] <lifeless> yes
[22:50] <jcsackett> it does seem interesting. i keep wanting to clear up some time to throw something together with it.
[22:50] <jcsackett> werkzeug, the wsgi library underneath it, is very nice.
[22:51] <lifeless> a gpg signature checking & secure key creation service would be nice
[22:51] <lifeless> small isolated, no DB to worry about (but gpg stuff to glue together)
[22:53] <jcsackett> that would be pretty cool.
[23:11] <james_w> http://blog.chromium.org/2011/05/ssl-falsestart-performance-results.html
[23:13] <nigelb> lifeless: Indeed.  Its pretty simple and easy :)
[23:13] <nigelb> jcsackett: test failed :(
[23:15] <nigelb> jcsackett: I can't figure out why though :/
[23:20] <nigelb> hm, I guess he's out of the day
[23:20] <jcsackett> nigelb: sort of. it's the end of my work day, but i have a call at in 40 min so i'm sort of around. :-)
[23:21] <jcsackett> just slower to respond, as i'm cooking.
[23:21] <nigelb> jcsackett: ahh, did you see the failure email?
[23:21] <jcsackett> i see the failure--it's an easy fix. just update the sort order in the test; since you changed how sorting is happening, the change in the order is expected.
[23:21] <jcsackett> in a perverse way, this proves your code does what you want it to, nigelb. :-)
[23:22] <nigelb> ah,the doctests failed?
[23:22] <jcsackett> yup.
[23:22] <jcsackett> blueprints/stories/sprints/20-sprint-registration.txt
[23:22] <jcsackett> at line 148, it prints out the attendees.
[23:23] <nigelb> haha
[23:23] <nigelb> of all the things to happen ^-^
[23:24] <jcsackett> it's actually pretty common that changes to sorts or what text is presented causes this sort of trivial error. it can be a good idea to do a quick search through docs and stories in the module your working in to see if there's anything related that might brewak.
[23:24] <LPCIBot> Project windmill-db-devel build #297: STILL FAILING in 46 min: https://lpci.wedontsleep.org/job/windmill-db-devel/297/
[23:24] <jcsackett> s/brewak/break/
[23:24] <jcsackett> on the plus side, this is an easy fix for you; just change the ordering in the story to reflect your changes. :-)
[23:26] <nigelb> I should have run all the blueprint tests once
[23:28] <jcsackett> nigelb: that can be a good thing to do. i frequently just kick off the unittests i know about and the doc/stories modules.
[23:31] <nigelb> jcsackett: at this point though, do I need to run the tests locally again? Or can you just re-land it?
[23:32] <jcsackett> have you pushed up the change?
[23:32] <nigelb> yep
[23:33] <jcsackett> cool, i'll land it.
[23:33] <nigelb> \o/
[23:36] <jcsackett> nigelb: it'll have to wait till after i finish making dinner though. cooking + landing is a bit difficult. :-P
[23:36] <nigelb> heh
[23:36] <nigelb> Well, this time, hopefully, I'll be asleep by the time the mail comes in.
[23:36] <nigelb> 4 am is a good time to sleep :p
[23:41] <cjohnston> nigelb, wake up!
[23:41] <nigelb> cjohnston: bah, wwhy?
[23:41] <cjohnston> lol


[17:52] <bkerensa> godbyk: we are getting close to doc freeze... Are things going good? Is there anything that needs attention?


[16:43] <ashams> seif, pinnnnnnnng
[16:43] <ashams> seif, we didn't discuss alot yesterday
[16:44] <ashams> just introducing the council idea to everybody
[16:44] <ashams> discussion and everything else will happen on the ml
[16:44] <ashams> so u didn't miss a lot
[17:12] <seif> ashams, ok cool thanks for the update
[17:12] <ashams> np
[17:15] <seif> ashams, come to #zeitgeist and contact m4n1sh
[17:15] <seif> he can mentor you
[17:15] <seif> :)
[17:16] <ashams> seif, ok buddy


[00:02] <RAOF> robert_ancell: Not really opposed, but I think it should be low priority (and so not shown by default on install). If someone adds the PPA, they probably want the system compository.
[00:13] <thomi> hmm, so in the last three days something changed in mir, and now I once again get file handle leaks, which prevent the mir-stress tests from running.
[01:57] <thomi> robert_ancell: got a second?
[01:58] <robert_ancell> thomi, sure
[01:58] <thomi> robert_ancell: I think that, even in it's uncompleted state, mir-stress is useful enough to be run on merge proposals. To achieve this, I need to get it merged into trunk. Do you see any issues with me merging it into lp:mir and continuing to work on it from there? (i.e.- after it's run on all MPs?)
[01:59] <robert_ancell> thomi, as long as it works fine it should be good to start merging
[01:59] <thomi> well, As of today, it would fail MPs, but that's because mir leaks FDs again
[01:59] <thomi> which seems to be a recurring problem
[02:00] <thomi> so it might cause you some grief, but in a good way :)
[02:01] <thomi> robert_ancell: the other thing is that from next Monday (the 10th), I'm on holiday for 2 weeks, so perhps it's better to wait until I get back.. or maybe we pick a strategy so even if it causes problems it won't be too disruptive
[02:01]  * thomi shrugs
[02:01] <robert_ancell> thomi, worth proposing now, so it can get reviewed early
[02:01] <thomi> ok
[03:53] <robert_ancell> thomi, is lp:lightdm-trunk-packaging supposed to contain all the lightdm project files? I need to add a new build-dep, not sure what the correct way to update this branch is
[03:53] <robert_ancell> I mean lp:~lightdm-team/lightdm/trunk-packaging
[03:54] <thomi> that sounds like the "old" way distro used to do packaging.
[03:54] <thomi> I'll investigate, one sec
[03:55] <thomi> robert_ancell: yeah, in time we should probably regenerate that, but I believe you should be abel to update the build-dep in that branch fine
[03:56] <thomi> just ignore all the other files :)
[03:56] <robert_ancell> thomi, ok, cheers
[03:56] <robert_ancell> I just push directly right? i.e. no MP
[03:56] <thomi> robert_ancell: yep
[03:57] <robert_ancell> thomi, and I don't need to update debian/changelog?
[03:57] <thomi> robert_ancell: ideally we'd have inline packaging, but I understand why that's not an option here
[03:57] <thomi> robert_ancell: nope, shouldn't need to
[03:57] <robert_ancell> yeah, I've been trying to think of a better method, but ultimately there will be some Ubuntu specific things that would have to diverge
[03:57] <thomi> yeah
[03:58] <thomi> you could perhaps still make upstream release tarballs without the debian/ directory?
[03:58] <robert_ancell> I could (and would)
[04:53] <robert_ancell> RAOF, do you know of any other method to communicate the Mir socket to clients other than via a MIR_SOCKET env variable?
[04:54] <robert_ancell> I guess in theory we could give the socket the shell and it could pass it on via some clever method but it seems it would make things overly difficult
[04:55] <RAOF> I'm still partial to “the shell opens a mir connection before spawning the client, and when it is spawned fd 3 is ready to connect to Mir”
[04:56] <RAOF> Failing that, it's an environment variable, or possibly just $RUN/user/mir/socket
[04:58] <robert_ancell> RAOF, is there a potential case of having more than one Mir server to connect to?
[04:59] <RAOF> I can't think of any reason why a user would want more than one Mir session active at one time.
[04:59] <robert_ancell> RAOF, the problem with option 1, is you can't run an app from a terminal ever (unless we make some clever opt-in API to the shell)
[04:59] <robert_ancell> I'm working on LightDM support for Mir sessions, but given they only exist in theory it's kind of hard to write test cases for :)
[05:00] <RAOF> Eh, we write “mir-run” which is a trivial wrapper around a shell DBus API to get an app spawned.
[05:00] <robert_ancell> Also, I guess even in case 1 you would have to pass an env variable to the app to give it the fd number
[05:01] <RAOF> No?
[05:01] <robert_ancell> I'm assuming at the moment that whatever the solution there will be an env variable set - and I can base tests off that variable (and make the daemon set it)
[05:01] <robert_ancell> hard code 3=mir socket?
[05:01] <robert_ancell> you can't introspect fds in any way can you?
[05:01] <RAOF> fd 3 would always be the mir socket, in the same way that fd 0-2 are always stdout, sterr, stdin.
[05:02] <robert_ancell> unless we screw something up and another fd gets inserver
[05:02] <robert_ancell> inserted
[05:02] <RAOF> Correct.
[05:02] <RAOF> But then that'd be a problem with sending the fd number as an environment variable anyway.
[05:03] <robert_ancell> I couldn't think of a problem..
[05:04] <RAOF> Well, it's the same sort of problem as “what if we leave another fd open as fd 3”, right?
[05:05] <RAOF> “What happens if we screw up and the fd number we set in the environment doesn't match the actual fd?”
[05:06] <RAOF> You know, we could also get this over dbus.
[05:08] <RAOF> But that's probably overthinking it.
[05:09] <robert_ancell> RAOF, ok, a specific case would be if an app was launching another app and had to pass on the fd - the next fd available might not be 3
[05:10] <RAOF> robert_ancell: It could fork(), close(3), then open the mir connection, which should then be fd 3?
[05:10] <robert_ancell> RAOF, 3 might be something else that it does need to pass on, e.g. some pipe for something
[05:11] <robert_ancell> I guess you could dup and close, but it seems nicer to just be explicit
[05:11] <RAOF> Yeah, I guess.
[05:12] <RAOF> I suspect that we'll probably end up with $XDG_RUNTIME_DIR/mir/socket, or whatever $MIR_SOCKET points to if that's set.
[05:12] <robert_ancell> yeah, that
[05:12] <robert_ancell> 's what I'm hoping
[05:13] <robert_ancell> RAOF, is that still what Wayland is doing afayk?
[05:13] <RAOF> I think so, yes.
[05:14] <RAOF> The well-known-fd option is cool, but probably overkill ;)
[05:17] <robert_ancell> RAOF, pff, I don't even trust stderr to be 2, I use STDERR_FILENO
[10:22] <alan_g> alf_: looking at client-rpc-report-lttng - and wondering (without thinking too deeply) that it would be nice to avoid having different client & server shared libs for lttng support. Would that require reworking the TRACEPOINT_* magic?
[10:23] <alf_> alan_g: thinking...
[10:37] <alf_> alan_g: I think this is doable. We would need to create a single SO containing the tracepoint provider sources (*_tp.*) from both client and server. This means that server produces mirserverlttng.a, the client produces mirclientlttng.a, and at some point (in shared?) we create a libmirlttng.so from these two.
[10:38] <alf_> alan_g: However, it does create some complications in terms of packaging, and also it couples the client and the server object-file-wise.
[10:38] <alan_g> alf_: thanks for thinking it through - I don't think that would be worth doing.
[10:39] <alan_g> I was more thinking of removing the direct dependencies on lttng - not the program specific stuff generated
[10:42]  * alan_g will be offline for a few minutes while he moves to the garden "office"
[15:12] <racarr> Morning
[15:15] <alan_g> Afternoon
[15:23] <kgunn> alf_: ping
[15:23] <alf_> kgunn: pong
[16:52] <racarr> "Finished" new platform API mirserver. Coffee break!
[17:18] <racarr> lol...
[17:18] <racarr> tried not drinking caffeine for a while this morning to see what would happen
[17:18] <racarr> now halfway through coffee...*twitch*
[17:23] <racarr> I think
[17:24] <racarr> I don't know when exactly.
[17:24] <racarr> But we should adopt
[17:24] <racarr> ubuntu::Event as MirEvent
[17:25] <racarr> The current codepath on the client is kind of embarasing:
[17:26] <racarr> read droidinput::InputMessage off the wire. Copy to droidinput::InputEvent, copy to MirEvent, send to platorm API, copy to Ubuntu event (99% identical with mir event...but not memcpy identical XD), send to toolkit, copy to QEvent
[17:26] <racarr> Elegance: ^
[17:28] <racarr> kdub_: An interesting point about the C->C++ layer in the client library and the lack of testing
[17:28] <racarr> the same problems
[17:29] <racarr> prevent platorm-api-mirclient from having good unit tests
[17:29] <racarr> because you can't meaningfully mock the machinery of the client library, so you would have to mock the whole server, or just run a server or whatever.
[17:29] <kdub_> right, its like oblique testing
[17:29] <kdub_> and there are some oblique data paths that have popped up
[17:30] <racarr> Ignoring for  second the idea of getting rid of mirclient
[17:30] <racarr> it could be made more testable.
[17:30] <racarr> i.e.
[17:30] <racarr> we introduce a "ClientConfiguration" which lets you mock the machinery (i.e. MirConnection) etc.
[17:30] <racarr> and there is private API like
[17:30] <racarr> mir_connect_with_configuration
[17:31] <racarr> (mir_connect calls this with default_configuration)
[17:32] <racarr> though I don't even know what I want to test here and if that helps me ;)
[17:34] <kdub_> i thought we had one of those
[17:35] <kdub_> src/client/default_connection_configuration.cpp
[17:39] <racarr> kdub_: I don't have that file ;)
[17:40] <racarr> are you sure you didn't write it today
[17:48] <racarr> uint32_t ua_ui_display_query_horizontal_res
[17:49] <racarr> I wonder if someone will hate us for that in a decade
[17:49] <racarr> "Unity crashes when I enable by second<PHONE_NUMBER>
[17:49] <racarr> pixel monitor"
[17:50] <racarr> ...feels pretty unlikely
[17:51] <kdub_> racarr, its a newer file... http://bazaar.launchpad.net/~mir-team/mir/trunk/view/head:/src/client/default_connection_configuration.h
[17:51] <kdub_> maybe a merge will bring it in
[17:51] <racarr> lol, it requires over 256 exabytes per second of bandwidth to drive a monitor that overflows 32 bit resolution
[17:51] <racarr> with 32 bit color depth
[17:51] <racarr> that
[17:52] <racarr> cant be true
[17:52] <racarr> anyway enough of that
[17:52] <racarr> kdub_: Ohhh
[17:52] <racarr> beautiul
[17:52] <racarr> it came in alfs stuff
[17:52] <racarr> I guess
[20:17] <kgunn> racarr: kdub_ does the android input stack support pretty much any evdev device ?
[20:17] <kdub_> my understanding is yes, but i'll for racarr to confirm
[20:41] <kgunn> kdub_: mind joining #ubuntu-unity
[20:42] <kdub_> oh sure.. .should add that one to my autojoin channels too!
[21:43] <racarr> kgunn: Merr. Sorry. Comcast strikes again.
[21:43] <racarr> Yes pretty much any evdev device seems to be the case
[21:44] <racarr> there are all sorts of weird defines for like ...the right pedal axis, or the left rudder lol.
[23:28] <racarr> *stretches* platform API server/client 2.0 are "finished" save for a sensors enabled hybris build, that's just one last bit of wiring for tomorrow though
[23:29] <racarr> I think I just wrote roughly 100 3-4 line functions *cringe*