[00:09] <mwhudson> jelmer: the diff on  https://code.launchpad.net/~jelmer/launchpad/bzr-code-imports/+merge/70684 *still* seems to have extraneous changes
[00:09] <mwhudson> jelmer: which must be quite frustrating by now :)
[00:09] <mwhudson> jelmer: ah, seems you merged db-devel?
[00:17] <jelmer> mwhudson, yeah, as it has the bzr-2.4b4 branch merged, which is targetted to db-devel
[00:17] <jelmer> mwhudson, let me resubmit
[00:19] <lifeless> pop quiz
[00:19] <lifeless> who cares about informational oopses?
[00:19] <mwhudson> lifeless: people presumably care about the ones made with ++oops++
[00:20] <lifeless> mwhudson: I don't think they would suffer if that was not 'informational'
[00:20] <lifeless> jelmer: does the code change depend on schema changes that are not yet deployed ?
[00:24] <jelmer> lifeless: No, but it has merged some revisions from an older revision of db-devel which seems to confuse the MP code
[00:25] <lifeless> so we don't deploy from db-devel
[00:25] <lifeless> -ever-
[00:25] <lifeless> -at all-
[00:25] <lifeless> landing it on db-devel will just cause conflicts and pain
[00:25] <jelmer> ok
[00:25] <lifeless> (conflicts when folk changing devel conflict with your code)
[00:25] <lifeless> (pain when conflicts happen :P)
[00:26] <lifeless> is it perhaps triggering a criss-cross merge case?
[00:26] <lifeless> what happens when you merge (but don't commit) devel into it ?
[00:27] <jelmer> conflicts :P
[00:27] <lifeless> jelmer: so, I would fix that :P
[00:27] <lifeless> and propose to devel
[00:27] <lifeless> mwhudson: I'm thinking to nuke the 'informational' flag
[00:27] <lifeless> mwhudson: and just use specific exceptions like 'ProfilingOops' instead to filter them on the reporting side
[00:28] <mwhudson> lifeless: ah i see
[00:28] <lifeless> mwhudson: things like the hwdb code that logs an oops when it gets a POST missing a field
[00:28] <lifeless> suggest that the informational side has been misunderstood and misused
[00:29] <wgrant> lifeless: I think it is useful to have an OOPS-like mechanism for non-critical logging.
[00:29] <lifeless> wgrant: well, I'm going through our uses
[00:30] <lifeless> wgrant: so far I've found one case that makes sense - profiling / ++oops++ - both of which use a custom exception
[00:35] <lifeless> the disconnected handling in publisher, for instance - that deserves to be a real oops
[00:35] <lifeless> its a problem if its happening
[00:35] <lifeless> (it should never be happening)
[00:52] <lifeless> yep, all uses were either a) noddy or b) trivially classified on the exception anyway.
[00:52] <lifeless> *nuke*
[00:55] <sinzui> wallyworld_, did you need me to look at something?
[00:55] <wallyworld_> sinzui: yes, just to approve the ff request: https://wiki.canonical.com/InformationInfrastructure/OSA/LaunchpadProductionStatus#Feature_Flag_Changes
[00:55] <wallyworld_> thanks
[01:44] <LPCIBot> Project devel build #976: STILL FAILING in 6 hr 7 min: https://lpci.wedontsleep.org/job/devel/976/
[01:47] <lifeless> jelmer: lol; meep - your branch is really confused isn't it :)
[02:07] <wallyworld_> StevenK: want a trivial review? https://code.launchpad.net/~wallyworld/launchpad/remove-answer-contact-827051/+merge/71632
[02:32] <nigelb> wallyworld_: heya
[02:32] <wallyworld_> nigelb: hi, got your email, still catching up with things, sorry haven't replied yet
[02:33] <lifeless> speaking of reviews
[02:33] <lifeless> wallyworld_: still pending on loggerhead;sorry
[02:33] <lifeless> https://code.launchpad.net/~lifeless/python-oops-datedir-repo/extraction/+merge/71633 and https://code.launchpad.net/~lifeless/launchpad/useoops/+merge/71634
[02:33] <wallyworld_> lifeless: np. i was going to remind you later today :-P
[02:33] <lifeless> are the next stage of my ripping oops out of LP
[02:33] <nigelb> wallyworld_: great thanks :)
[02:34] <wallyworld_> nigelb: will look very shortly
[02:34] <nigelb> \o/
[02:34] <lifeless> I think the only thing left is an http module and either a canonical module or some sensible-defaults copied into the core oops system.
[02:52] <jtv> Any reviewers in the house?  Got a job for you!  https://code.launchpad.net/~jtv/launchpad/bug-826659/+merge/71636
[02:53] <jtv> Short diff, long cover letter because I vent some steam and formulate some rules for testing.
[02:59] <wallyworld_> jtv: i'll look if someone can mentor
[02:59] <jtv> hi wallyworld_!  Thanks.  I see a slight conflict of interest with me doing that, obviously.  :)
[03:00] <wallyworld_> jtv: yep :-) i and looking at something for nigelb just now but will do the review asap after that
[03:01] <jtv> Thanks.  Let me know if you need any mentoring for branches other than mine.  And maybe it's time to look at graduation — I have a feeling we may have lost our procedure for that.
[03:09] <wallyworld_> nigelb: your @call_with(user=REQUEST_USER) is having no effect since it's in the wrong place.
[03:10] <wallyworld_> nigelb: you need to add this to an interface method and register the interface with the web service parsing infrastructure so it gets slurped up
[03:10] <nigelb> wallyworld_: oh. *thats* why.
[03:11] <wallyworld_> nigelb: there's various webservice.py files in the code base which is where the webservice stuff looks to see what it needs to register
[03:11] <wallyworld_> with your code at the moment, user is set to None
[03:11] <nigelb> ah, that explains that.
[03:12] <wallyworld_> you could pick an example interface what is exported to the web service and model what you need to do on that
[03:13] <nigelb> so, write a wrapper over the search function using a webservice interface?
[03:13] <wallyworld_> you also should write a test for the web service side of it
[03:13] <nigelb> I should write a javascript test too. I've been lazy ;)
[03:14] <wallyworld_> nigelb: you don't need to write a wrapper - you just need to figure out how to get the current logged in user inside your check_bug_links method.
[03:15] <nigelb> ah!
[03:15] <wallyworld_> your code looks ok so long as you know the user
[03:16] <wallyworld_> we uased to use ILaunchbag to arbitarily get the user for a given interaction but that's frowned upon now
[03:16] <StevenK> That's because ILaunchBag needs to die horribly.
[03:16] <StevenK> And painfully.
[03:16] <wallyworld_> the @call_with is one way of doing it if the method is an existing web service
[03:17] <wallyworld_> there may be a better way without having to export teh method as a web service but i'm not sure off hand what that would be
[03:17] <nigelb> this has been done before? and I just need to find some example code and work my code the same way?
[03:17] <wallyworld_> StevenK: yes, agree about ILaunchbag. do you know any other way to get the logged in user other than @call_with ?
[03:18] <wallyworld_> nigelb: @call_with is used in many places
[03:18] <nigelb> wallyworld_: heh, except I didn't understand the correct way of using it :)
[03:19] <wallyworld_> if you are in a view, you can type self.user i think. but we are not in a view here
[03:19] <wallyworld_> i don't know enough about the zope machinery to understand how the user is extracted from the request
[03:21] <nigelb> the only place call_with works is in interfaces?
[03:21] <wallyworld_> nigelb: LinkChecker is initialised with the request object
[03:21] <wallyworld_> nigelb: i think you can get the user from in there
[03:21] <wallyworld_> nigelb: afaik, all web service decorators need to be added to interface methods
[03:22] <nigelb> ah, cool.
[03:23] <wallyworld_> nigelb: try user = request.principal.person
[03:23] <wallyworld_> not sure if that's kosher but it works
[03:23] <nigelb> heh, okay :)
[03:24] <wallyworld_> nigelb: for anonymous requests, i suspect principal will be None so check for that
[03:24] <nigelb> sure, will do
[03:25] <wallyworld_> so forget the web service stuff
[03:28] <mwhudson> i think IPerson(request.principal) might be more kosher
[03:29] <lifeless> wallyworld_: @call_with for web service methods/properties is best practice.
[03:29] <wallyworld_> mwhudson: ah, thanks
[03:29] <wallyworld_> lifeless: it's not exposed as a web service method atm
[03:30] <wallyworld_> otherwise @call_with would be the best solution i agree
[03:31] <wallyworld_> nigelb: see mwhudson's comment above - use IPerson(request.principal)
[03:32] <nigelb> wallyworld_: already changed code :)
[03:32] <wallyworld_> excellent
[03:32] <lifeless> wallyworld_: ah, I didn't think it could be anything -other- than a web service clal
[03:32] <lifeless> wallyworld_: :)
[03:34] <wallyworld_> lifeless: it's defined in zcml as a browser:page implementation
[03:34] <wallyworld_> and the __call__ method is implemented
[03:34] <lifeless> yeah, I can imagine
[03:36] <wallyworld_> web service is sort of overkill for what it does perhaps, it's only an "internal" api
[03:36] <lifeless> in principle the web service would take care of encoding, auth checking, marshalling etc
[03:37] <lifeless> doing it by hand is, well, by hand.
[03:37] <nigelb> err, what's the result of a searchBugIds call? I don't seem to be able to understand this.
[03:38] <nigelb> Here's the call I'm making and its associated traceback http://paste.ubuntu.com/666969/
[03:38] <lifeless> a list of ids :)
[03:39] <lifeless> nigelb: your bug_ids set is full of strings.
[03:39] <lifeless> nigelb: also, that python loop will be -very- slow
[03:40] <lifeless> nigelb: you need to map it into a set -
[03:40] <lifeless> found_ids = set(bug_ids)
[03:40] <lifeless> missing_bugs = found_ids - bugs
[03:40] <nigelb> oh.
[03:40] <nigelb> I didn't know I could do that :|
[03:41] <lifeless> nigelb: I wouldn't use an english description either, you want minimal data flowing - this is an implementation detail, not a UI
[03:41] <lifeless> so the thing you serialise out should just be the ids of the inaccessible bugs, no explanation why
[03:41] <nigelb> lifeless: the why explanation shows up as tooltips.
[03:41] <lifeless> nigelb: there is only one explanation
[03:41] <nigelb> that's how the javascript end of things seem to be configured.
[03:42] <lifeless> nigelb: sure, but you can do that on the client.
[03:42] <wallyworld_> jtv: you and your fancy latin words
[03:42] <lifeless> nigelb: disclosing whether the bug was private or just a gap in the bug sequence would leak information about the bug.
[03:42] <nigelb> heh, that means creating a new javascript function on the client ;)
[03:42] <jtv> wallyworld_: I'm sorry if I urinated you off, amice
[03:43] <lifeless> nigelb: well, up to you where you do it; just saying what I see ;)
[03:43] <wallyworld_> jtv: no, you didn't, just saying :-P
[03:43] <jtv> :)
[03:43] <nigelb> lifeless: heh, my first non-trivial branch, so I think I might aim for perfection or as much close to it as I can get.
[03:45] <lifeless> nigelb: as long as its fit for purpose
[03:45] <lifeless> nigelb: beyond that, shrug :)
[03:45] <nigelb> heh
[04:14] <nigelb> lifeless: for some reason the missing_bugs = found_ids - bugs isn't working
[04:17] <lifeless> nigelb: break in with pdb and have a look around
[04:18] <nigelb> in the middle of doing that
[04:26] <nigelb> wait, what.
[04:26] <nigelb> search returns bug ids as int.
[04:26]  * nigelb cries
[04:26] <nigelb> is there a way to convert that to string or make it return strings?
[04:27] <lifeless> nigelb: like I said, your thing was full of strings
[04:28] <lifeless> nigelb: no, you should be converting your strings to ints before you query in fact ;)
[04:28] <nigelb> lifeless: bug numbers can't exceed the length of ints, can't they?
[04:28] <lifeless> [because the data type is int]
[04:28] <lifeless> nigelb: do you mean as in MAXINT ?
[04:28] <nigelb> yeah
[04:29] <lifeless> we can upgrade the column to 64-bit before that
[04:29] <lifeless> but we'll be a few decades yet
[04:29] <nigelb> oh. ok.
[04:35] <nigelb> IT WORKS \O/
[04:36] <StevenK> lifeless: So I should write a loop to create 200,000 bugs to help it along?
[04:38] <lifeless> StevenK: ...
[04:39] <lifeless> poolie: around ?
[04:41] <StevenK> lifeless: :-P
[04:44] <poolie> hi lifeless, otp atm
[04:44] <poolie> to statik
[04:44] <lifeless> kk
[04:45] <lifeless> wgrant: you are terrible at leave.
[04:45] <wallyworld_> lifeless: like you can talk
[04:45] <StevenK> Haaha
[04:45] <StevenK> wallyworld_ is right, you so can't.
[04:45] <wallyworld_> mr pot, meet mr kettle
[04:45] <lifeless> wallyworld_: I'm talking from a position of knowledge.
[04:47] <lifeless> so I'm thinking about oopses here
[04:47] <wgrant> lifeless: And I've just fallen into the trap of correcting incorrect question answers.
[04:48] <lifeless> wgrant: i hope you take time in lieu :)
[04:48] <wgrant> Hah.
[04:48] <wgrant> It will only take a few minutes.
[04:48] <lifeless> cognitive overhead :)
[04:48] <lifeless> I *know* it takes me a fortnight +- to spin down from work, so I plan leave accordingly
[04:49] <wallyworld_> that's a loooong time
[04:49] <lifeless> wallyworld_: yes, and if you think back to last december - after about two weeks I was around much less
[04:49] <wgrant> Indeed.
[04:50] <lifeless> wallyworld_: if I take < 2 weeks leave with the intent of relaxing, its an utter fail
[04:50] <wallyworld_> lifeless: i was in NZ for most of Dec, so didn't notice :-)
[04:50] <lifeless> wallyworld_: nice, did you drive around ?
[04:50] <lifeless> wgrant: btw, talking about generic names
[04:50] <lifeless> http://pypi.python.org/pypi/Products.Collage/1.3.6
[04:51] <lifeless> wgrant: 'Products' as a top level package in python.
[04:51] <wallyworld_> yes, started in Dunedin, all through south island, then onto north island
[04:51] <wgrant> lifeless: Sounds like Zope.
[04:51] <wgrant> Is it?
[04:51] <lifeless> wgrant: plone, so more or less yes
[04:51] <wgrant> I think Zope 2 is allowed to have the global namespace.
[04:51] <wgrant> RIght.
[04:52] <wgrant> Since Zope invented just about everything, and they use sensible namespaces now :)
[04:52] <lifeless> so anyhow
[04:52] <lifeless> I'm thinking about how to pass in things like the request object, urls, exc_info
[04:53] <lifeless> the generic way to wire up for DI would be to supply a container callback
[04:53] <lifeless> but this is going to be fuugly for the simple case
[04:54] <lifeless> so I'm thinking of having a 'context' parameter to config.create()', and documenting that on_create hooks will receive this, and it can be used to psas things to the hooks, and some well known hooks will look for things there.
[04:54] <lifeless> like - attaching exception info would look for context['exc_infp']
[04:54] <poolie> lifeless: is the preforking server unblocked now? or almost?
[04:54] <lifeless> poolie: not until we have the disconnect stuff done
[04:55] <lifeless> wgrant: what do you think? The alternative seems to be tighter coupling between report population/creation and the point the report is created.
[04:55] <lifeless> StevenK: wallyworld_: ^
[04:56] <wallyworld_> lifeless: i'm not sure i have enough context - you want to do IOC with the new oops module?
[04:57] <wallyworld_> to allow the oops module to poke stuff back into the container?
[04:57] <lifeless> wallyworld_: I want it to play with IOC environments (like lp's) and with non IOC stuff (like LaunchpadScript, loggerhead, gpgverify)
[04:57] <lifeless> wallyworld_: so here is an example case
[04:58] <lifeless> in LP we use zope.exceptions.exception_formatter to format the traceback in an oops report
[04:58] <lifeless> this is pretty zope specific
[04:58] <lifeless> even though, thankfully, its a the edge of the dependency graph I think.
[04:59] <wallyworld_> yes, i can imagine it would be zope specific
[04:59] <lifeless> so oops *could* use that
[05:00] <lifeless> and have config.attachException(report, exc_info)
[05:00] <lifeless> this would drag in zope.exceptions and zope.interfaces
[05:00] <lifeless> which isn't too bad
[05:00] <wgrant> Did you know that imposing Zope dependencies aparent from zope.interface and zope.component is considered a crime against humanity?
[05:00] <wgrant> s/aparent/apart/
[05:00] <lifeless> wgrant: well this is why the thought going into this
[05:01] <lifeless> an alternative would be to say 'if you want to attach an exception, do it yourself', but thats cruel.
[05:01] <lifeless> a third way would be to have an explicit config knob 'call this function to configure the traceback formatter'
[05:01] <wallyworld_> lifeless: i'd rather pass in some sort of context with redirects to the preferred implementation as you say
[05:01] <lifeless> the way I am considering is to say 'put your exception in content['exc_info'], and your exception on-create hook will format
[05:02] <lifeless> if you want a different formatter, don't put the supplyed on-create hook in there, instead put your own one.
[05:02] <lifeless> supplied.
[05:02] <lifeless> this kindof shifts the complexity around
[05:02] <lifeless> but
[05:02] <lifeless> I think it starts to pay off when you consider handling of 'request' objects
[05:02] <lifeless> and the like.
[05:03] <lifeless> where the core really shouldn't have any concept of such a beast.
[05:03] <wallyworld_> i don't think it introduces too much extra complexity any simple case
[05:04] <lifeless> so create(content=dict(request=current_browser_request(), exc_info=sys.exc_info(), program=sys.argv[0])
[05:04] <lifeless> )
[05:04] <lifeless> and let the hooks suck out what they want
[05:05] <lifeless> I'm down to *one function* to pick apart
[05:05] <lifeless> and then launchpadloggerhead can lose a canonical import, and gpgverify can work.
[05:05] <wallyworld_> maybe a namedtuple rather than a dict?
[05:05] <lifeless> wallyworld_: blah :)
[05:06] <lifeless> wallyworld_: theres no particular reason to make it immutable
[05:06] <wallyworld_> not so much to make it immutable but for type safety and extensibility
[05:06] <wgrant> How's that more typesafe or extensible?
[05:06] <lifeless> you'll need to expand on how it gives those in a way a dict would not ?
[05:07] <wallyworld_> i guess you could subclass dict if you needed to
[05:07] <StevenK> To do what?
[05:07] <wallyworld_> add extra functionality besides name-values pairs to the context
[05:07] <lifeless> wallyworld_: uhhh, you've *totally* lost me.
[05:08] <lifeless> wallyworld_: so the point of the context is to pass data from outside 'create' to each on_create hook, without needing create-and-every-callbacj to take **kwargs
[05:08] <wallyworld_> context could be more than just a container for name-value pairs- it couild actually provide some other encapsulated functionality
[05:08] <lifeless> wallyworld_: it could; what do you have in mind ?
[05:08] <wallyworld_> just a sec, otp
[05:13] <wallyworld_> lifeless: i dont' have any specific functionality in mind for this case, but in practice such context objects can be used for more than data passing - they can provide useful behaviour such as access to container specific services
[05:13] <wallyworld_> so a dict may be too simple
[05:13] <lifeless> wallyworld_: so, I would say that if someone in a container environment needs access to the container, they do:
[05:13] <lifeless> context=dict(container=realcontainer, exc_info=sys.exc_info(), ... etc)
[05:13] <lifeless> wallyworld_: and have their custom on_create hook do content['container'].containerservicecall()
[05:14] <lifeless> wallyworld_: or even implement __getitem__ on their container and pass it in directly, if the protocols line up well enough
[05:15] <lifeless> wallyworld_: remember we're duck typed, so there is no need for it to *be* a dict, not even a subclass :)
[05:15] <wallyworld_> that would work. i guess it comes down a little to personal preference. i tend to dislike using simple data structures as integration "glue" since often i find more is needed
[05:15] <lifeless> I've come to really appreciate minimalism
[05:16] <wallyworld_> but maybe duck typing removes the need for that as you say
[05:18] <lifeless> anyhow, that can be iterated on
[05:18] <lifeless> given we have 1(1!) user so far :P
[05:18] <wallyworld_> sure, so +1 for option 3 :-)
[05:20] <wallyworld_> however it's done, we just need to be clear on the contract between the modules and ensure that is satified from both sides
[05:20] <wgrant> Now now, clear and sensible contracts are not the Launchpad way.
[05:22] <poolie> lifeless: i'm off the phone but i might have some lunch now
[05:22] <poolie> will ping you after
[05:30] <wallyworld_> lifeless: quick question - what's the storm syntax for a query term checking for "is null" that I can pass to "where=And(*terms)"? instead of [MyClass.property == 'name'] I want [MyClass.property is null] or whatever
[05:34] <lifeless> poolie: ok
[05:34] <lifeless> wallyworld_: ==None
[05:34] <StevenK> wallyworld_: == None
[05:35] <wallyworld_> lifeless: StevenK: thanks!
[05:36] <StevenK> wallyworld_: I think you've broken devel on buildbot
[05:36] <StevenK> Failure in test lp.answers.tests.test_questiontarget.QuestionTargetAnswerContactTestCase.test_canUserAlterAnswerContact_owner
[05:37] <wallyworld_> StevenK: i'll look
[05:43] <wallyworld_> StevenK: ffs. i didn't remove a test when i did the revert earlier
[05:43] <StevenK> FAIL
[05:43] <wallyworld_> yes :-(
[05:43] <StevenK> There's a JS test and a python test both failing
[05:44] <wallyworld_> i'll check the js one
[05:45] <StevenK> RARGH
[05:45] <StevenK> Stupid librarian logs attached to test failures
[05:45] <StevenK> USELESS
[05:46] <wallyworld_> StevenK: which js test? bb only shows 1 failure, the py one
[05:47] <wgrant> StevenK: You should fix the fixture to only attach the log for the current test.
[05:47] <StevenK> wgrant: I should fix the fixture to not attach the log in the first place!
[05:47] <StevenK> wallyworld_: Read the summary, there are two.
[05:48] <lifeless> StevenK: attaching the log is great
[05:49] <lifeless> StevenK: what needs to change is to only attach the *new entries* for a test.
[05:49] <StevenK> Sure, great. 3,800 lines between the test failure and the traceback
[05:56] <jtv> Any review mentors available?  https://code.launchpad.net/~jtv/launchpad/bug-826659/+merge/71636
[05:57] <StevenK> Well. Bugger.
[05:58] <StevenK> Calling the column sourcepackagename hurts when you join against SPR
[05:58] <StevenK> :-(
[06:02] <wallyworld_> StevenK: can you possibly +1 this? do I land with 'testfix' now or wait till bb barfs? https://code.launchpad.net/~wallyworld/launchpad/remove-tests-for-badrev-13696/+merge/71642
[06:02] <jtv> wgrant: are you reviewing today?
[06:02] <StevenK> jtv: wgrant is on holidays
[06:02] <jtv> Then he shouldn't be here!
[06:03] <wallyworld_> jtv:  *supposed* to be
[06:03] <jtv> Ah yes
[06:03] <StevenK> wallyworld_: r=me
[06:03] <jtv> Well, I'll just go have lunch then or something.
[06:03] <StevenK> wallyworld_: If you land it now, you may have to force buildbot when it finishes.
[06:04] <jtv> wallyworld_: I added a follow-up note on my MP, even though I'm not formally mentoring that one.  :)
[06:04] <wallyworld_> jtv: thanks, will look
[06:05] <wallyworld_> StevenK: i'll be at soccer when it barfs but will force as soon as i return, about an hour later. so i'll land now so it's all ready
[06:06] <lifeless> StevenK: since you're familiar with the code... https://code.launchpad.net/~lifeless/python-oops/extraction/+merge/71510 please?
[06:07] <StevenK> lifeless: 1169 lines!?
[06:07] <lifeless> StevenK: bah, thats the old one.
[06:07] <lifeless> one sec
[06:07] <lifeless> StevenK: https://code.launchpad.net/~lifeless/python-oops-datedir-repo/extraction/+merge/71633 is the one I meant.
[06:08] <StevenK> lifeless: So, calling the new column on SPPH sourcepackagename leads to problems
[06:08] <lifeless> StevenK: existing queries barf ?
[06:08] <StevenK> Right
[06:08] <lifeless> StevenK: lets use a different name; easier and safer than fixing all queries in advance.
[06:08] <lifeless> spn_cache or something
[06:09] <StevenK> lifeless: I've switched to 'name'
[06:09] <lifeless> StevenK: I'd prefer something other than that, because of 'name' being the url component in so many other classes.
[06:09] <lifeless> StevenK: however, up to you.
[06:09] <StevenK> lifeless: 'spn' / 'bpn' ?
[06:09] <lifeless> StevenK: sure
[06:11] <lifeless> Subject: RETURNED MAIL: DATA FORMAT ERROR
[06:11] <lifeless> heh
[06:12] <StevenK> lifeless: r=me, with a slight wrist-slap
[06:14] <lifeless> sexy times
[06:15] <lifeless> ah yes, the version number.
[06:15] <lifeless> that was oversight in the move before
[06:48] <wallyworld_> StevenK: if you are around in about 1hr30 and force a build, i'll buy you a beer :-)
[06:50] <StevenK> wallyworld_: You should have landed it with [testfix]
[06:51] <wallyworld_> StevenK: bollocks. can i change it now?
[06:52] <StevenK> No, it's landed.
[06:52] <wallyworld_> bollocks x 2
[06:53]  * wallyworld_ gotta run to soccer
[07:05] <poolie> lifeless, hello?
[07:09] <lifeless> can has reviews? tiny: https://code.launchpad.net/~lifeless/python-oops/extraction/+merge/71644 and getting big but its really simple stuff... just rearranged code: https://code.launchpad.net/~lifeless/launchpad/useoops/+merge/71634
[07:09] <lifeless> poolie: hi
[07:09] <lifeless> poolie: sure, if you want to ring the landline ?
[07:25] <lifeless> poolie: ?
[07:35] <LPCIBot> Project db-devel build #812: STILL FAILING in 5 hr 50 min: https://lpci.wedontsleep.org/job/db-devel/812/
[07:42] <poolie> oh sorry, sure
[07:48] <adeuring> good morning
[08:09] <stub> http://bazaar.launchpad.net/~launchpad-pqm/launchpad/stable/view/head:/lib/canonical/launchpad/webapp/dbpolicy.py?file_id=x_Andrew_Bennetts_%3Candrew.bennetts%40canonical.com%3E_Fri_Oct__1_11%3A57%3A48_2004_12702.0 is failing for me, but otherwise code browse was reasonably snappy
[08:10] <stub> "redirecting the request for this address in a way that will never complete"
[08:12] <lifeless> stub: bug 819444
[08:14] <StevenK> stub: O hai. I've had to rename {binary,source}packagename to {b,s}pn, but you think an index on just that column is fine to start with?
[08:15] <stub> Why the rename, apart from long names suck?
[08:15] <stub> An index on just that column is fine. If you know the queries it is needed for, we might be able to make a compound index that satisfies those queries as well as the population job.
[08:16] <StevenK> stub: Breaks existing queries that join against SPR and SPN
[08:16] <stub> I'm not sure I like that rationale. We know we need to fix code when changing the schema.
[08:17] <lifeless> stub: we can't be sure we've caught all the existing queries
[08:17] <stub> I would go for 'because the long names suck, so we should just use spn and bpn everywhere' but that doesn't solve your problem.
[08:18] <lifeless> stub: the reason for the breakage was a previously unique column name becoming non-unique + hand crafted queries not putting the table name in place
[08:18] <stub> lifeless: You could say that about every new column addition we make, and it has never been a problem in the past.
[08:18] <lifeless> stub: previously we did code + schema changes in lockstep, with several days (or more) qa on staging
[08:18] <lifeless> stub: we're explicitly not doing that now...
[08:19] <stub> Yes, and now we need to run the test suite with both /stable and /db-devel
[08:19] <stub> Or we are going to have to start naming new columns with UUIDs
[08:19] <lifeless> stub: well, its a risk assessment.
[08:20] <stub> Yes, and next time we denormalize further we are going to call the column spn2?
[08:20] <lifeless> stub: I guess I'm saying I'm fine with a name that reduces the risk; if you want a more risky but more consistent name, I can live with that
[08:20] <lifeless> stub: I'd hope that we don't use spn unqualified, having learnt that lesson
[08:21] <StevenK> stub, lifeless: So, I will kill this ec2 run, and I will investigate fixing the queries that use the full name of SPN and BPN unqualified.
[08:21] <stub> I want consistent names. If we want to switch to spn/bpn  I'd like it to be consistent. This also gets tied up with migrating to text strings over integer ids
[08:22] <lifeless> stub: such a migration might be a pessimisation for some queries (absent trigrams...)
[08:22] <stub> Yes. We don't know yet.
[08:22] <lifeless> stub: I think we need more investigation on that particular thing (though I know I was one of the proponents of it before :P )
[08:23] <stub> For now, I'd rather stick with the full names and do two ec2 test runs (-b launchpad=stable, -b launchpad=db-devel)
[08:23] <lifeless> stub: given stable is merged to db-devel all the time, just db-devel should be robust
[08:24] <StevenK> stub: I know the test failures for db-devel anyway, so I will investigate those tomorrow.
[08:24] <stub> True. So this isn't any different from before then?
[08:24] <lifeless> stub: remember that someone could land a break in devel at any time; we probably need a deploy rule 'can only deploy a schema change if the current *live* revno has been tested by buildbot on db-devel'
[08:24] <lifeless> stub: we'll figure out all the corner cases soon :P
[08:25] <lifeless> matsubara-afk: are you around ?
[08:25] <stub> Yes. We knew there would be extra landing complexity and more branches for allowing live patches. People thought the trade off was worth it.
[08:25] <matsubara> lifeless, hey, yes. I'm in the QA sprint
[08:25] <lifeless> stub: yup, and I still do :P
[08:26] <stub> Which reminds me, I have branches to land since I couldn't get my branch to push last night due to major sucky 'Net.
[08:26] <lifeless> matsubara: I want to patch oops-tools. It wants its own db cluster - is that still correct ?
[08:27] <matsubara> lifeless, what do you mean by it wants its own db cluster?
[08:27] <lifeless> matsubara: are there any docs on hacking it ? [the README.txt only talks about running locally...]
[08:28] <matsubara> lifeless, hmm README.txt is the closest I have for docs.
[08:28] <stub> StevenK: So you need to do what I was doing yesterday - separate branch from stable containing the required test fixes to land on devel, which gets merged into your db-devel so you can run the tests to ensure the required fixes really are the required fixes. And don't use devel for the source of your fixes or you risk leaking untested changes from devel -> db-devel.
[08:31] <matsubara> lifeless, are you not able to run it locally to test your changes?
[08:33] <lifeless> matsubara: I don't know how to run its test suite ;)
[08:33] <matsubara> lifeless, make check
[08:36] <lifeless> let me have another go at it :)
[08:39] <lifeless> matsubara: I want to get rid of the custom oops parser
[08:42] <matsubara> lifeless, right. basically you'll have to add your package to the download-cache, update versions.cfg and setup.py with the new package, remove the code from src/oopstools/oops/models.py and update it to use the code in the package. Do you need help with this?
[08:42] <lifeless> matsubara: hopefully not :P
[08:44] <nigelb> wallyworld_: my MP now works. I think I'll spend tonight / tomorrow morning writing tests.  Is there any more clean up that you'd suggest?
[09:13] <henninge> jml: Hi!
[09:13] <StevenK> Dear Thunderbird, why are you taking up 1.2 cores?
[09:13] <henninge> StevenK: you will have to email that question, not put it on irc ...
[09:14] <StevenK> Bwaha
[09:14] <lifeless> gmb: oh hai
[09:14] <gmb> lifeless: Wotcher
[09:14] <lifeless> can haz review?
[09:15] <lifeless> https://code.launchpad.net/~lifeless/python-oops/extraction/+merge/71644
[09:15] <lifeless> and
[09:15] <lifeless> https://code.launchpad.net/~lifeless/launchpad/useoops/+merge/71634
[09:15] <gmb> lifeless: Sure. I'll attend to those presently.
[09:15]  * gmb grabs a cup of tea before getting down to work.
[09:16] <lifeless> gmb: thanks!
[09:16] <gmb> np
[09:28] <Ursinha> hey guys :)
[09:29] <Ursinha> I have a team subscribed to several packages, is it possible to mute bugmail in only one of them?
[09:32] <Daviey> Ursinha: yes
[09:35] <Ursinha> Daviey: using the ui?
[09:36] <Daviey> Ursinha: It might be team admins only.. but for example, https://bugs.launchpad.net/ubuntu/+source/euca2ools/+subscriptions
[09:36] <Daviey> I can edit the, "Ubuntu Server Team subscription" listed there
[09:42] <Ursinha> Daviey: pedro was trying to edit the subscription of desktop-bugs of a package but there was no mute option
[09:43] <lifeless> matsubara: so updated all the bits, ran make check:
[09:43] <lifeless> bin/test
[09:43] <lifeless> Creating test database for alias 'default'...
[09:43] <lifeless> Traceback (most recent call last):
[09:43] <lifeless>   File "/home/robertc/source/launchpad/oops-tools/parts/django/django/db/backends/postgresql_psycopg2/base.py", line 140, in _cursor
[09:44] <lifeless>     self.connection = Database.connect(**conn_params)
[09:44] <lifeless> psycopg2.OperationalError: could not connect to server: No such file or directory
[09:44] <lifeless>         Is the server running locally and accepting
[09:44] <lifeless>         connections on Unix domain socket "/var/run/postgresql/.s.PGSQL.5433"?
[09:45] <matsubara> lifeless, does `psql -p 5433 lpoops` works for you? it looks like your postgres db for oops tools is not there
[09:54] <lifeless> matsubara: thats what I was asking about needing a special cluster ! :)
[09:54] <lifeless> matsubara: so the answer is 'yes, it needs a special cluster'
[09:55] <danilos> Ursinha, I believe muting is person-only, teams can't have mutes (i.e. since you can't stop bug mail without leaving the team, we introduced muting; if teams don't want bug mail for a certain package, they should unsubscribe basically)
[09:57] <Ursinha> right, doesn't apply for ubuntu use case :/
[09:58] <poolie> jelmer, re your mps for lptools
[09:58] <poolie> i think it's better to bring them in than to quibble about exactly how they're written
[09:58] <poolie> so, 3x +1
[09:59] <jelmer> poolie: gracias
[09:59] <lifeless> jelmer: btw that loggerhead open-branch thing is failing 1000x a day
[09:59] <jelmer> lifeless, I'm working on fixing it as we speak
[09:59] <lifeless> jelmer: so if you're going to do other stuff first, let me know so I can roll it back
[09:59] <lifeless> jelmer: ah cool
[10:00] <matsubara> lifeless, :-)
[10:02] <lifeless> matsubara: the README.txt tells how t make a pg 8.3 cluster
[10:02] <lifeless> matsubara: does that need to be updated ?
[10:04] <matsubara> lifeless, it should work the same for 8.4. if you can update: s/8.3/8.4/, I appreciate
[10:06] <lifeless> matsubara: that seems happier
[10:11] <allenap> jelmer: It looks like the prereq in https://code.launchpad.net/~jelmer/launchpad/bzr-code-imports/+merge/71625 might be out of date; the diff is >3000 lines suddenly.
[10:12] <jelmer> allenap: Whoops, thanks - I'll set it back to wip for the moment while I get these other things sorted.
[10:16] <gmb> jelmer: I just approved https://code.launchpad.net/~jelmer/launchpad/bzr-2.4b4/+merge/71624. Want me to run it through EC2 for you?
[10:20]  * gmb does so anyway
[10:20] <jelmer> gmb: Thanks, though my current branch will actually conflict with it (and has higher priority)
[10:20] <gmb> jelmer: Oh, okay.
[10:21] <jelmer> gmb: Thanks for the review though :)
[10:21] <gmb> np :)
[10:21] <lifeless> gmb: thanks; sorry about the size
[10:22] <gmb> lifeless: No worries. After years of reviewing Celso's branches, 1500 lines is nothing.
[10:22] <lifeless> gmb: and all fairly focused :)
[10:22] <gmb> Indeed
[10:40] <tumbleweed> query: archive.getPermissionsForPerson returns an empty list when connected anonymously. Is there any good reason for this? (I can't find a related bug)
[10:44] <lifeless> probably means yiou have no permission to read that persons details anonymously
[10:45] <tumbleweed> are such details not provided to non-ubuntu-developers?
[10:45] <tumbleweed> for per-component permissions, it's pretty obvious from team membership
[10:46] <lifeless> ubuntu has nothing to do with it
[10:46] <lifeless> if you're getting an empty list the api probably got a list with inacessible entries in it
[10:46] <lifeless> which it will filter
[10:46] <lifeless> so try logging in :)
[10:46] <tumbleweed> what I'm getting at is why does one need to be authenticated to read these
[10:48] <lifeless> thats a good question
[10:48] <lifeless> why shouldn't you be authenticated though ?
[10:48] <tumbleweed> because this is for ubuntu-sponsoring. There is no good reason to be authenticated
[10:48] <tumbleweed> (except this)
[10:50] <poolie>  what does "expired token" mean?
[10:50] <poolie> that the actual login has expired, or something else?
[10:50] <lifeless> oauth tokens can be time limited
[10:50] <lifeless> e.g. to a month o fuse
[10:50] <lifeless> you need to request a new one when that happens
[10:51] <poolie> gar
[10:52] <poolie>         # TODO: handle the case of having credentials that have expired etc
[10:52] <poolie>
[10:57] <tumbleweed> lifeless: would you like a bug report? its easily worked-around, but very non-obvious to the API client
[10:58] <adeuring> lifeless: I sent an email about a batching issue (too long for IRC) to the lp-dev mailing list. could you have a look at itß
[10:58] <adeuring> ...it?
[10:58] <lifeless> ß sure
[10:59] <lifeless> tumbleweed: up to you, but I'm not convinced its a bug
[10:59] <tumbleweed> lifeless: what is it then? It seems wrong to have to authenticate to read public information
[10:59] <tumbleweed> lifeless: and having to authenticate cronjobs is an administrative pain
[11:00] <tumbleweed> (IIRC this isn't the first time we've tried to do this, but we didn't remember the issue)
[11:00] <lifeless> tumbleweed: we have restrictions on visibility on a lot of data
[11:01] <lifeless> I'm not saying there is a good reason for this particular case
[11:01] <tumbleweed> I have notice that I can use isSourceUploadAllowed (packageset authorisation), unauthenticated. But I can't determine PPU or component-based upload rights
[11:02] <lifeless> anyhow, its much better for us if cronjobs are authenticated
[11:02] <lifeless> because when they go rogue and use a tonne of resources, its a pain to track anonymous sessions down
[11:02] <tumbleweed> fair enough
[11:03] <tumbleweed> this one is quite a beast (~10 min running time)
[11:06] <wgrant> Ursinha: Why can't the team unsubscribe?
[11:07] <poolie> oh ffs
[11:07] <poolie> any http error maps into keyerror
[11:08] <Ursinha> wgrant: because we used the list of packages a team is subscribed to to say which packages should the team care about
[11:08] <Ursinha> *we use
[11:09] <jml> henninge: hi
[11:10] <poolie> which is bug 626960
[11:10] <_mup_> Bug #626960: Collection dictionary access should not return KeyError when the server is down <lazr.restfulclient:Triaged> < https://launchpad.net/bugs/626960 >
[11:10] <henninge> jml: Hi! I resolved it already.
[11:10] <henninge> jml: testtools' setup.py does not know egg_info
[11:10] <henninge> and does not need it
[11:10] <jml> indeed it shouldn't :)
[11:11] <henninge> I am quite new to setuptools, so I am not sure why
[11:11] <henninge> but sdist produced the right package
[11:11] <poolie> o/ jml
[11:13] <jml> poolie: hi
[11:14] <wgrant> Ursinha: Ah :(
[11:15] <Ursinha> wgrant: so we're workarounding it by creating teams only to be collections of packages, let's say
[11:15] <wgrant> You could also just keep a list of names around :)
[11:15] <wgrant> But yeah, using the subscription list is handy.
[11:15] <Ursinha> wgrant: haha no way...
[11:15] <wgrant> I have a few teams that I do it for.
[11:15] <wgrant> Much easier to manage.
[11:16] <Ursinha> yet another list of things... better keep in launchpad
[11:16] <wgrant> But unfortunate for notifications, indeed.
[11:18] <poolie> hello gmb
[11:18] <poolie> could you review https://code.launchpad.net/~mbp/lazr.restfulclient/626960-keyerror/+merge/71667 please
[11:18] <poolie> and perhaps land https://code.launchpad.net/~james-w/lazr.restfulclient/reject-non-json-responses/+merge/16960
[11:35] <gmb> poolie: Sure, I'll take a  look shortly.
[11:53] <poolie> thanks matey
[11:59] <jtv> danilos: did you just make qastaging send me email?  I thought that was supposed to be captured?
[12:07] <jelmer> poolie: can you land my lptools branches or should I apply for team membership?
[12:13] <lifeless> matsubara: so, have tests running, I will fiddle with this tomorrow more
[12:13] <matsubara> lifeless, cool.
[12:20] <jelmer> is there a publically accessible list of things that are in a specific package set?
[12:20] <StevenK> jelmer: You can query that sort of thing over the API
[12:25] <jelmer> StevenK: close enough - thanks
[12:26] <danilos> jtv, hum, interesting, I did some QA this morning for subscribing large teams to PPAs, but qastaging shouldn't send any emails
[12:26] <jtv> That's what I thought.
[12:26] <jtv> And then I got that email about your privates.
[12:27] <jtv> About your empty privates, in fact.  Which, on reflection, may not have been your first choice for a message to be sent out to the world.
[12:27] <danilos> jtv, empty privates, though
[12:27] <danilos> :)
[12:27] <danilos> jtv, actually, it sucks that the emails have gone through (all of ~canonical would have gotten it)
[12:27] <jtv> We can only hope that qastaging email is at least whitelisted.
[12:27] <jtv> As they were at the time.
[12:27] <lifeless> I didn't see any such mail
[12:27] <danilos> jtv, I didn't get anything, so I hope we are all good
[12:28] <jtv> I got two.
[12:28] <jtv> But then I think I'm whitelisted for staging email.
[12:28] <danilos> jtv, right, that explains it then
[12:29] <jtv> I hope it does!
[12:31] <jtv> Wow.  Still hearing a thunderclap that started about 20 seconds ago.
[12:32] <jtv> The lightning was pretty far off (5km at least) but shockingly bright.
[12:32] <danilos> lifeless, hi, do you perhaps know what's our limit for storm caches? I am trying some load_referencing and similar magic, and it seems I am hitting the limit because depending on the order, different statements show up
[12:33] <lifeless> I don't, no. I am rather of the opinion that we need to set it as high as it can be without thrashing, because otherwise it just forces pathological behaviour - and we wipe the cache between requests anyway.
[12:33] <lifeless> danilos: there is a policy knob in the lazr config that controls it, IIRC
[12:34] <lifeless> all that said, every time I've looked at similar symptoms, we haven't had a cache limit problem, rather the cache working on the 2nd page in a test
[12:34] <lifeless> or similar
[12:35] <lifeless> (because test view instantiation doesn't reset the cache - the storm resetting only happens in thread 1+, not 0+
[12:35] <nigelb> 56
[12:35] <danilos> lifeless, right, thanks, I'll try to dive deeper (I am using ++profile++show to look at the queries being issued)
[12:36] <lifeless> danilos: qastaging, or dev?
[12:36] <danilos> lifeless, dev
[12:36] <lifeless> don't forget celebrities do get cached
[12:37] <lifeless> hmmm, way past bedtime. I have to crash()
[12:37] <lifeless> gnight all
[12:41] <danilos> night-night, lifeless
[13:07] <deryck> Morning, everyone.
[13:22] <LPCIBot> Yippie, build fixed!
[13:22] <LPCIBot> Project devel build #977: FIXED in 5 hr 46 min: https://lpci.wedontsleep.org/job/devel/977/
[13:22] <bigjools> 5 hr 46 min!
[13:39] <jtv> gmb: got reviews for you if you've got time.  You'll enjoy this one: https://code.launchpad.net/~jtv/launchpad/more-820456/+merge/71689
[13:41] <gmb> jtv: Just nomming at the moment. Queue 'em up, though and I'll come to them when I return.
[13:42] <jtv> gmb: there's one that may not jump out at you from the queue—brad started on it once but never had time to finish it.
[13:42] <jtv> So it's claimed, but actually looking for a new reviewer.
[13:42] <jtv> Bon appétit.
[13:42] <gmb> jtv: okay. Can you add me as a reviewer so I don't lose track of it?
[13:42] <jtv> Aye-aye.  Thanks.
[13:43] <gmb> Cool, and np
[13:55] <deryck> abentley, ping.  I can chat whenever you like now.
[13:55] <abentley> deryck: I'll just get coffee...
[13:55] <deryck> abentley, hmmm, me too :)
[14:08] <deryck> What's the old qa report page we used to cut-n-paste bug numbers from when asking for a nodowntime deploy?
[14:08] <deryck> matsubara, can you point me at it? ^^
[14:10] <matsubara> deryck, You mean the report that used to be on lpqateam.devpad.com? If yes, see: https://bugs.launchpad.net/lp-devops-dashboard/+bug/823886
[14:10] <_mup_> Bug #823886: New dashboard design removed available deployable revision and fixed bugs list <Launchpad DevOps Dashboard:Triaged> < https://launchpad.net/bugs/823886 >
[14:11] <deryck> matsubara, yeah, I was looking for that list.  Didn't know it didn't exist anymore.
[14:12] <matsubara> sorry about that. I'll get to it once I get back from the QA sprint. Meanwhile I guess the only way to get that info is to see the deployment report itself
[14:14] <deryck> matsubara, gotchas.  no worries, thanks!
[14:32] <abentley> deryck: actually, wallyworld has landed a rollback as 13696.
[14:32] <deryck> abentley, ah, nice!  So we should be deploy ready then, once the qa pages catch up?
[14:33] <abentley> deryck: Looks like.
[14:33] <deryck> abentley, awesome.
[14:38] <abentley> matsubara: buildbot approved revision  13697 an hour ago, but it's not included on https://devpad.canonical.com/~lpqateam/qa_reports/deployment-stable.html Do you know why?
[14:41] <matsubara> abentley, will look into it in a moment
[14:41] <abentley> matsubara: thanks.
[14:44] <jelmer> gmb: can I add another MP to your queue?
[14:51] <nigelb> bigjools: I haz success \o/
[14:51] <nigelb> Well, not entirely, but mostly :)
[14:52] <bigjools> nigelb: congrats
[14:52] <nigelb> The MP looks small now, but I need ta add tests :)
[14:56] <gmb> jelmer: Sure.
[14:56] <jelmer> gmb: Great :) The MP is https://code.launchpad.net/~jelmer/launchpad/safe-opener-threading/+merge/71670
[14:57] <gmb> k
[14:59] <stub> Who is the owner of imported bug comments?
[15:01] <gmb> stub: The Person who made the comment (we create one if they don't exist in LP)
[15:01] <stub> k. not a robot. good.
[15:10] <matsubara> abentley, r13697 is in the deployment report now
[15:10] <abentley> matsubara: thanks.
[15:11] <matsubara> np
[15:12] <abentley> deryck: The board is green for a deployment.  Can you talk me through it?
[15:13] <jtv> thanks for the review gmb
[15:13] <deryck> abentley, yay!  Indeed I can.
[15:13] <gmb> jtv: np.
[15:13] <deryck> abentley, looking for links....
[15:14] <deryck> abentley, so it's really only a matter of filling out the table under "Requested stable Deployments" on the LaunchpadProductionStatus wiki page....
[15:15] <deryck> abentley, you have to paste all the bug numbers fixed with links in that table.  but the revno is the highest revno to deploy.
[15:16] <deryck> abentley, approved by is "qa-tagger" and deploy to is "nodowntime"
[15:16] <deryck> abentley, and you can see example just above that have been deployed.  then you ping a losa once the wiki page is filled out.
[15:16] <abentley> Okay.
[15:17] <deryck> abentley, it takes around 2 hours to do the deploy and you want to be on hand for that time.
[15:17] <deryck> I think that's it.
[15:22] <jelmer> abentley: great to see that fix for bug 386596, that also helps towards build-from-branch-into-primary.
[15:22] <_mup_> Bug #386596: pushing to a packaging branch can't create a new package <codehosting-ssh> <escalated> <lp-code> <not-pie-critical> <package-branches> <principia> <qa-ok> <stakeholder> <Launchpad itself:Fix Committed by abentley> < https://launchpad.net/bugs/386596 >
[15:27] <abentley> losa: please deploy 13697.  I have updated LPS.
[15:27] <abentley> jelmer: cool.
[15:31] <allenap> gmb: Fancy a short one? https://code.launchpad.net/~allenap/launchpad/wrong-needs-linking-count-bug-795359/+merge/71715
[15:31] <gmb> allenap: I'll add it to the queue.
[15:31] <allenap> gmb: Ta :)
[15:31] <gmb> np
[15:51] <jtv> thanks again gmb!  And I just put up another one.
[15:51] <gmb> jtv: Hah. Might just be able to get that one done before my head melts.
[15:51] <gmb> :)
[15:51] <jtv> gmb: I'll stop here then.  :-)
[15:52] <gmb> Performance Tuesday | https://dev.launchpad.net/ | On call reviewer^W^W^Wjtv's review monkey: gmb | Critical bugs: 238 - 0:[#######=]:256
[15:52]  * gmb is glad he forgot to put /topic in there, actually :)
[15:56] <jtv> cjwatson: did you get my email about custom-uploads copying?  Unless you see any problems with the design, it's all set to go in at your word.
[15:58] <allenap> Thanks gmb :)
[15:58] <gmb> allenap: np :)
[16:05] <gmb> jtv: approved.
[16:05] <jtv> gmb: thanks, and feel free to take the rest of the day off.  :)
[16:05] <gmb> Ta :)
[18:25] <mtaylor> lifeless: if I'm consuming launchpad openid auth, are timeouts your end, my end, or just the way life is?
[19:10] <LPCIBot> Yippie, build fixed!
[19:10] <LPCIBot> Project db-devel build #813: FIXED in 5 hr 48 min: https://lpci.wedontsleep.org/job/db-devel/813/
[19:18] <abentley> deryck: there's no OCR, so could you please review https://code.launchpad.net/~abentley/launchpad/fix-unicode-path/+merge/71762 ?
[19:18] <deryck> abentley, yeah, definitely.
[19:19] <abentley> deryck: thanks.
[19:19] <deryck> np
[19:25] <lifeless> mtaylor: +login ?
[19:26] <mtaylor> lifeless: yeah?
[19:26] <mtaylor> lifeless: (basically, I keep having to re-auth to launchpad all the time in my jenkins, and I was wondering if that was a config thing on my end, or just the way life goes)
[19:27] <lifeless> oh, you don't mean 'the login process times out', you mean 'the tokens seem to run out of life' ?
[19:28] <abentley> lifeless: are you around when the LOSAs BOD?
[19:29] <lifeless> BOD ?
[19:29] <lifeless> oh, start.
[19:29] <lifeless> I can be.
[19:30] <abentley> lifeless: We've done a no-downtime deploy of the push-creates-source-package, but they didn't have time for the codehosting deploy.
[19:30] <abentley> lifeless: I can handle it tomorrow if it's not convenient for you.
[19:31] <lifeless> abentley: the losas want stuff RT'd while they are sprinting; can you: put it on LPS as a request, RT it (and cc: me on the mail to RT so I get copied), and if I'm around I will touch base with the first losa to show up and see about doing it
[19:32] <abentley> lifeless: Okay.
[19:32] <lifeless> thanks
[19:36] <abentley> lifeless: can I use you for "Approved by"?
[19:38] <lifeless> yes
[19:41] <deryck> abentley, r=me on the review.  Looks good.
[19:42] <abentley> deryck: thanks.
[19:42] <deryck> abentley, np!
[19:44] <sinzui> jcsackett, do you have time to mumble?
[19:45] <jcsackett> sinzui: 15 min?
[19:45] <sinzui> sure
[19:50] <sinzui> deryck, bug 173019 may not be as easy as you think and I doubt it is high given the age of the bug and the lack of duplicates
[19:50] <_mup_> Bug #173019: "Renewal period" is marked as "(Optional)" when it isn't <lp-registry> <teams> <ui> <Launchpad itself:Triaged> < https://launchpad.net/bugs/173019 >
[19:52] <deryck> sinzui, hey.  I thought I marked that low actually.
[19:53] <sinzui> :)
[19:53] <deryck> maybe my fingers didn't do what my brain did :-)
[19:53] <sinzui> deryck, Past discussion was to use a multistep form, or an overlay to only ask for information that is needed
[19:54] <deryck> sinzui, and I just thought "easy" because I assumed we could drop the "optional" label.  If that's not possible without a larger fix, forgive my lack of knowledge.
[19:55] <sinzui> deryck, understood. We do not know how to express invariants as a state between optional and required
[19:56] <deryck> sinzui, ah, gotchas.
[20:08] <jcsackett> sinzui: i'm on mumble whenever you're free.
[20:10] <lifeless> can we delete shipit.css now ?
[20:34] <bac> lifeless: could i get your thoughts on https://code.launchpad.net/~bac/launchpad/bug-813322-2/+merge/71733?  not asking for a code review, just feedback on the approach.
[20:35] <lifeless> sure
[20:35] <lifeless> looking
[20:36] <lifeless> sweet
[20:37] <lifeless> bac: looks fine; I think that we will find we need to another pass for backend efficiency (e.g. perhaps a separate xaction for each dup we move across, but thats a different ratchet - we're not at that point in our optimisation arc yet.
[20:38] <lifeless> bac: so a big +1 from me.
[20:38] <bac> lifeless: great, thanks
[20:45] <lifeless> I need brainstorming help
[20:45] <lifeless> we have page ids
[20:45] <lifeless> which are kindof a unique part-of-the-codebase-to-look-at
[20:46] <lifeless> cronscripts are also unique-parts-of-the-codebase-to-look-at
[20:46] <lifeless> but putting 'sendbranchmail' in as a pageid rubs me the wrong way.
[20:47] <lifeless> I want to find a generic term that I can use in the public contract for oopses, and migrate towards for the serialized form as well
[20:48] <benji> "task-id", "action-id", "activity-id", "functionality-something"
[20:48] <lifeless> good, good, keep em coming!
[20:48] <lifeless> another one I thought of was 'context'
[20:49] <benji> I like "facet" but we already use that term in LP
[20:50] <lifeless> thats ok
[20:50] <lifeless> this is for python-opos
[20:50] <lifeless> python-oops
[20:50] <lifeless> which LP will use
[20:50] <lifeless> but needs to be suitable for u1, landscape, possibly isd, possibly ubuntu, package-importer
[20:50] <lifeless> its kind of like user-agent
[20:51] <lifeless> 'agent' ?
[20:51] <lifeless> like, agent: zope3/Person:+index
[20:52] <benji> "concern"
[20:52] <lifeless> thats good
[20:52] <benji> "agent" is very close to "client" in my head, so that seems a little confusing
[20:52] <lifeless> I see
[20:53] <benji> I don't really like it, but "relm" comes to mind.
[20:54] <lifeless> realm ?
[20:54] <lifeless> thats another possibility
[20:54] <benji> heh, yeah I typoed the "a"
[20:55] <lifeless> if you saw : "Lucid/apport;program=evolution" , would that make sense to you ?
[20:56] <lifeless> or would : "evolution" with other fields noting it was from a lucid box be better?
[20:56] <lifeless> I'm thinking about how to write up a recommended use
[20:57] <benji> to me, "Lucid/apport;program=evolution" communicates well (I think, here's what I think it means: "this error was reported by apport on Lucid but the app generating the error was evolution")
[20:58] <lifeless> bac: yeah
[20:58] <benji> you might break those into two fields, the reporter (which might well be an "agent") and the topic being reported ("program: evolution")
[20:58] <lifeless> bah
[20:58] <lifeless> benji: yeah
[20:58] <lifeless> topic and reporter, I like.
[20:58]  * lifeless things
[20:58]  * lifeless thinks.
[20:59] <lifeless> so the difference between pageid and url
[20:59] <lifeless> is that one pageid applies to many urls.
[20:59] <lifeless> theres one other concept we might want, which is for multitenancy
[21:00] <lifeless> which I think reporter really fulfils
[21:00] <lifeless> claiming a reporter of launchpad gets you into the launchpad oops bucket that only lp devs can see
[21:00] <lifeless> folk can inject crap in there if we have an anonymous submission thing, but we can filter that out programattically.
[21:01] <benji> I wonder if some loose hierarchy would work.  Something like "ubuntu/lucid/appport" and "canonical/launchpad".
[21:02] <benji> Although, you can get in several forms of one-size-fits-all trouble with that approach.
[21:03] <lifeless> so reporter: 'Describes the program reporting the oops. For instance you might put your program name in here, or your website domain.'
[21:04] <lifeless> topic: 'The subject or context for the oops. For instance with a command line program you might put the subcommand in here, in a website you might put the template or function name (something that is common to many different urls)'
[21:05] <lifeless> apport would do 'reporter: lucid/apport' topic:'evolution'
[21:06] <lifeless> gpverify would do 'reporter: launchpad/gpgverify' or just 'reporter:gpgverify' and for topic the api being called.
[21:06] <benji> why would apport include "lucid"?  I would think that'd be included in some other field if needed (along with all kinds of other environmental info).
[21:06] <lifeless> our main appservers would do 'reporter: launchpad/main' or just 'launchpad' and for topic what we currently put in pageid
[21:07] <lifeless> benji: oh, so one of the big things ubuntu have is that cross-release crashes are generally considered irrelevant
[21:07] <lifeless> benji: that would just be an easy way to trigger partitioning of the analysis
[21:08] <benji> seems reasonable, "lucid" really is intrinsic to the identity of the reporter then
[21:09] <lifeless> I like this - thanks for the brainstorm
[21:09]  * lifeless goes to make it realityish
[21:10] <benji> yep, any time
[22:11] <mtaylor> lifeless: yes - I mean "the tokens seem to run out of life"
[22:11] <lifeless> mtaylor: I don't believe we have a mandatory expiry.
[22:11] <lifeless> mtaylor: what expiry are you choosing when you create the tokens?
[22:11] <mtaylor> lifeless: ok- so that's more likely something on my side then
[22:11] <mtaylor> lifeless: not sure - let me poke around (it's in java, so it takes a moment) :)
[22:13] <lifeless> back in a ninute
[22:35] <lifeless> back
[22:40] <lifeless> mtaylor: ^
[22:42] <lifeless> sinzui: I had a wtf moment when I saw your branch name 'private-bug-1'
[23:03] <sinzui> lifeless, I think I could make that bug private without a brach
[23:05] <lifeless> sinzui: I think yo ucould too
[23:05] <lifeless> sinzui: still, I had a moment :)
[23:06] <sinzui> We could retitle the bug to be Microsoft has a dominate share of the increasing irrelevant desktop market
[23:07] <lifeless> :)
[23:07] <lifeless> well
[23:07] <lifeless> we could try.
[23:07] <lifeless> Who knows, it might not timeout.
[23:08] <sinzui> yeah. We probable cannot close the bug without making Lp twice as fast
[23:34] <StevenK> sinzui: http://irclogs.ubuntu.com/2011/08/10/%23launchpad-dev.html


[00:37] <kgunn> robert_ancell: on the reporting stuff...here http://unity.ubuntu.com/mir/component_reports.html
[00:37] <kgunn> so lttng obviously needs lttng
[00:37] <kgunn> but for handlers "log"
[00:38] <kgunn> does that just get written out to a file ?
[00:39] <robert_ancell> kgunn, I think you need to run it with --glog for the logs to go to glog then you can set --glog-stderrthreshold to have them go to stderr or --glog-log-dir to change where the log files go
[00:39] <robert_ancell> I haven't mastered the logging commands yet though
[00:40] <kgunn> robert_ancell: yeah...it says you can define an envrion variable
[00:40] <kgunn> to turn it on...which i assume means like "export MIR_SERVER_DISPLAY_REPORT=log"
[00:41] <robert_ancell> kgunn, you can set any of the flags to mir by using MIR_SERVER_* environment variables, e.g. MIR_SERVER_GLOG_LOG_DIR=/tmp/logs
[00:41] <robert_ancell> yep, that would be the equivalent of --display-report=log
[00:41] <kgunn> robert_ancell: can that be post server launch ?...or will i need to reboot ?
[00:42] <robert_ancell> kgunn, env variables need to be defined before server launch
[00:42] <robert_ancell> kgunn, you can set them in /etc/environment if you want them universally applied
[00:42] <kgunn> like in a pref file ?
[00:42] <kgunn> oh...
[00:43] <robert_ancell> kgunn, or edit /etc/lightdm/lightdm.conf.d/10-unity-system-compositor.conf and set unity-compositor-command as you like if you're testing the whole stack
[00:56] <kgunn> robert_ancell: huh...so i tried to alter envirnonment on the nexus4...but no matter what nano just won't write out the change
[00:56] <kgunn> ever experienced anything like that on n4 ?
[00:56] <kgunn> i root shell...
[00:56] <kgunn> oops/i/i am
[00:57] <robert_ancell> write out what change?
[00:57] <robert_ancell> oh, editing the file?
[00:57] <robert_ancell> what does mount say?
[00:57] <kgunn> robert_ancell: correct...trying to add GLOG.... & MIR_....
[00:58] <kgunn> robert_ancell: mount says a bunch...so i guess it depends...
[00:58] <robert_ancell> try 'touch /etc/blah' and see if it throws an error
[00:58] <kgunn> alot of "rw"'s
[01:00] <kgunn> robert_ancell: touch worked...chmod worked....
[01:00] <robert_ancell> kgunn, nano fail?
[01:00] <robert_ancell> try cat > /etc/...
[01:00] <robert_ancell> :)
[01:02] <kgunn> weird...so "cat > /etc/environment" just sat there...
[01:02] <kgunn> no output
[01:03] <kgunn> but i definitely see the file when i open with nano
[01:03] <robert_ancell> kgunn, that overwrites the file
[01:03] <kgunn> and i can ctl-O to write out...but then, it prompts what file name to save under...and it simply won't accept "enter"
[01:03] <robert_ancell> then type the contents and press ctrl+d to end
[01:39] <RAOF> robert_ancell: Morning.
[01:39] <robert_ancell> RAOF, hey
[01:44] <RAOF> Hrm. Why doesn't that hit the assert()
[01:49] <kgunn> RAOF: hope bkfst was good (something unhealthy like eggs and bacon)
[01:49] <RAOF> It did include bacon, yes :)
[01:49] <RAOF> Pan-baked eggs with bacon and sausage and onion and such.
[01:53] <kgunn> yum
[02:10] <robert_ancell> RAOF, so what's the plan? Are there some specific bugs you are working on?
[02:11] <RAOF> So, at least one of the bugs is that we're not updating what Intel thinks the front buffer is.
[02:11] <RAOF> That's causing at least *some* of the crashes after resolution change.
[02:11] <robert_ancell> RAOF, this is in Mir?
[02:11] <RAOF> This is in XMir.
[02:12] <RAOF> My plan is to work on XMir + Intel until I can do resolution & layout changes and it doesn't crash.
[02:14] <robert_ancell> ok
[03:09] <kgunn> robert_ancell: well...i added MIR_SERVER_GLOG_LOG_DIR=/tmp/logs & MIR_SERVER_DISPLAY_REPORT=log....but nothing showing up in /tmp/ ?
[03:09] <robert_ancell> kgunn, did you do MIR_SERVER_ENABLE_GLOG=1?
[03:10] <robert_ancell> kgunn, rather MIR_SERVER_GLOG=1?
[03:10] <kgunn> doh!
[03:17] <duflu> That sounds quite overcomplicated to me
[03:17] <kgunn> hmm  still no joy
[03:18] <kgunn> robert_ancell: actually would it be MIR_SERVER_GLOG_LOG=1 ?
[03:19] <robert_ancell> kgunn, mir_demo_server --help shows it is '--glog', so it should be MIR_SERVER_GLOG
[03:19] <robert_ancell> kgunn, have you tried setting MIR_SERVER_GLOG_MINLOGLEVEL?
[03:19] <robert_ancell> I had the same frustrations using the logging myself
[03:20] <kgunn> robert_ancell: actually...that's a good idea...i should get familiar on pc first before phone
[03:20] <robert_ancell> though --help seems to imply minloglevel is set to a valid default
[03:20] <duflu> Hmm, if Mir is logged to unity-system-compositor.log already, why don't we start logging useful stuff by default?
[03:22] <duflu> ... I mean at least "Mir has started successfully and is using these monitors with resolutions... Listening on socket /tmp/mir_socket"
[03:24] <RAOF> That would be moderately useful, yes.
[03:24] <kgunn> robert_ancell: duflu RAOF ....i think i'm gonna go to bed early...and get up really early...like 4 or 5 am
[03:24] <robert_ancell> kgunn, later
[03:24] <robert_ancell> duflu, that would be super useful
[03:25] <kgunn> just not sure when everyone plans to eod...but if it all ends before i get on...can the last man standing write a handoff email....where we're at, what's worthy to test, what the balance of problems is etc.
[03:25] <duflu> kgunn: OK, later
[03:27] <robert_ancell> kgunn, sure
[03:31] <RAOF> kgunn: See you later.
[03:37] <duflu> Wow, qa-testing is better now. Just with ugly frame scheduling/damage glitches
[03:44] <duflu> I'm not even sure how it's possible to get the kind of small horizontal line artefacts I see though
[03:54] <duflu> Actually there seem to be some frame scheduling problems in qa-testing2, just much less often
[04:05] <robert_ancell> duflu, have you found anything in the bypass branch that may be causing problems?
[04:05] <duflu> robert_ancell: Nothing bypass-specific yet. All the bugs I've seen happen on qa-testing2 (just take longer)
[04:08] <duflu> robert_ancell: It's extra hard to test things when a recent MM commit broke fingerpaint :/
[04:09] <duflu> Maybe fingerpaint is to blame. Don't know
[05:10] <RAOF> Bah. The xf86 cursor code would really like HW cursor stuff.
[05:27] <duflu> Why does MM look so flawless for demo_server_client? Where are the bugs that XMir triggers?... :(
[05:27] <duflu> *demo_server_shell
[05:28] <robert_ancell> ok, I'm calling it a night - duflu, RAOF, please remember last one here to send out an email update. Thanks!
[05:35] <duflu> RAOF: When you talk about receiving buffer fd's from the server, that's in-protocol, right? Not on the side channel...
[05:45] <RAOF> duflu: Correct
[05:52] <tvoss_> duflu, ping
[05:52] <duflu> tvoss_, pong
[05:55] <duflu> RAOF: Sanity check: qa-testing{,2} are different in that "2" has no bypass, right?
[05:59] <RAOF> duflu: qa-testing might be a couple of Xserver revisions behind, too.
[06:00] <RAOF> I've only been pushing to qa-testing2
[06:01] <duflu> Except this morning, which is why I tested qa-testing
[06:01] <RAOF> Yeah, accidentally :)
[06:02] <tvoss_> RAOF, are you using swap_buffer_sync or swap_buffer nakedly?
[06:02] <RAOF> tvoss_: swap_buffer nakedly.
[06:02] <tvoss_> interesting, sam reports issues with that
[06:05] <RAOF> Oh, really? What issues?
[06:06] <duflu> RAOF: https://bugs.launchpad.net/bugs/1216337
[06:06] <RAOF> Ah, that one.
[06:07] <duflu> RAOF: Ooooh, doing native GBM you have a hardware buffer being swapped using the software swap_buffers call I guess. I wonder if we handle that correctly
[06:07] <RAOF> Oh, no. A new appearance of the same symptom.
[06:07] <RAOF> software swap_buffers call?
[06:08] <duflu> RAOF: Yes mir_surface_swap_buffers* is usually for software only surfaces
[06:08] <RAOF> It's also what EGL uses to implement eglSwapBuffers, though.
[06:08] <RAOF> It's the only way to get a frame to Mir.
[06:09] <duflu> RAOF: Yeah should be. Just theorizing
[06:56] <RAOF> Woot!
[06:56] <RAOF> We have a successful layout change with gnome-control-centre
[06:57] <duflu> RAOF: "We" ? :)
[06:58] <RAOF> I
[06:58] <RAOF> Ok, that's really weird.
[06:58] <RAOF> Mir has stuck the surface in the wrong place :)
[07:02] <RAOF> tvoss_: Huh. Looks like it was indeed just the software cursor code being hateful.
[07:10] <duflu> OK, my brain is fried and I'm also out of essentials such as... food. So I'm off to the supermarket for a while.
[07:10] <RAOF> duflu: Have fun.
[07:10] <RAOF> You might be able to test something that works when you return.
[07:10] <RAOF> At least on the XMir side.
[07:10] <RAOF> And for values of "works" equal to "doesn't crash horribly as soon as you touch the layout"
[07:13] <tvoss_> RAOF, \o/, uploaded to the ppa, yet?
[07:14] <RAOF> xserver MM11 just uploaded.
[07:14] <tvoss_> RAOF, does that require an updated intel driver?
[07:14] <RAOF> Yes, if you want it to work.
[07:15] <tvoss_> RAOF, ack, I guess mm11 needs to finish compiling first
[07:15]  * tvoss_ grabs a quick breakfast
[07:15] <RAOF> Yup.
[07:32] <tvoss_> RAOF, the xserver build for i386 hangs on xfvb
[07:32] <RAOF> Grr.
[07:32] <RAOF> Someone's going to have to work out what's happening there.
[07:34] <RAOF> tvoss_: Build retried.
[08:32] <tvoss_> RAOF, the 64bit build in the ppa hangs again
[08:36] <tvoss_> quick restart
[08:49] <tvoss_> RAOF, would it make sense to just disable the xvfb test in the ppa for now?
[08:50] <RAOF> Yeah, it probably would.
[08:50] <tvoss_> RAOF, hitting refresh to check the build is a bit tedious
[08:52] <tvoss_> RAOF, does mm12 require a new intel driver?
[08:53] <RAOF> Nope.
[08:53] <RAOF> It just fixes the crash on startup in mm11 that I introduced by testing a subtly different change locally.
[08:54]  * RAOF prepares to crash his unity-system-compositor by unplugging his HDMI output
[08:55] <RAOF> Huh. Didn't crash (yet)
[08:56] <duflu> RAOF: Yeah the Mir server seems to survive hotplugging fine. Even if you don't get to use the new monitors
[09:01] <RAOF> mlankhorst: I don't suppose you're seeing the xvfb-run test hang all the goddamned time in the xserver builds you're doing?
[09:03] <tvoss_> RAOF, just remove it from the ppa version for now
[09:04] <RAOF> Yeah, done in mm13
[09:05] <tvoss_> RAOF, ack, moving over to the new house, back in a few minutes
[09:07] <duflu> RAOF: Does XMir use buffer age?
[09:07] <RAOF> Yes
[09:08] <duflu> I wonder if we're messing that up somehow
[09:08] <duflu> ... in the server
[09:10] <mlankhorst> RAOF: only 50% of the time
[09:11] <RAOF> mlankhorst: Yeah :/
[09:21] <kgunn> hey fellas
[09:21] <mlankhorst> RAOF: might fail on virt only though
[09:21] <RAOF> kgunn: Good morning. Sleep well?
[09:22] <RAOF> mlankhorst: Yeah, maybe. I haven't been tracking that.
[09:22] <duflu> kgunn: Hi. You could sleep more :)
[09:22] <kgunn> uh-oh
[09:22] <RAOF> Well, until https://launchpad.net/~mir-team/+archive/qa-testing2/+build/4904608 finishes building.
[09:22] <kgunn> :)
[09:23] <kgunn> time enough to make a coffee
[09:24] <duflu> I have real food I can cook tonight. Wonder if I will get to...
[09:25]  * RAOF is just eating some real food.
[09:25] <duflu> Oooh, Sam reports similar lag issues and apparently also relies on buffer age
[09:38] <duflu> RAOF: If we get as far is the frame scheduling being the _only_ problem, can you try ignoring buffer age?
[09:38] <duflu> *as far as
[09:38] <RAOF> Yes
[09:38] <RAOF> (radeon and nouveau already do)
[09:38] <RAOF> Or, rather, fail to act on it.
[09:39] <duflu> ... because the only two clients which use buffer age are the only two clients reporting lag/ordering problems
[09:39] <RAOF> Heh.
[09:39] <RAOF> Huzzah!
[09:39] <duflu> Maybe
[09:40] <RAOF> qa-testing2 now has all the things!
[09:40] <duflu> Cool
[09:43] <kgunn> cool....
[09:47] <duflu> Oooh, gnome-control-centre multi-monitor joy without crashes :)
[09:48] <RAOF> Yay!
[09:48] <RAOF> I shall now do some much-delayed housework in the form of some washing up.
[09:50] <tvoss_> RAOF, duflu back
[09:51] <kgunn> hey tvoss_
[09:51] <kgunn> RAOF: sweet....i just hdmi hotplugged/connect-disconnect 8 times....survived all....just once it didn't scale right
[09:52] <kgunn> getting somewhere :)
[09:55] <tvoss_> kgunn, please try layout changes, too
[09:55] <tvoss_> via the control center
[09:56] <duflu> It seemed to work, but then bug 1216522
[09:56] <kgunn> woooo-hoooo!!! was just doing that...hdmi extended desktop working & hotplugged
[09:57] <kgunn> wooohoo....and dropping the built-in display  off works!
[09:58] <tvoss_> duflu, for https://code.launchpad.net/~vanvugt/mir/distinguish-crtc-exceptions/+merge/181947
[09:58] <tvoss_> duflu, are we sure that the type is usable as an array index? cannot tell from the mp
[09:59] <duflu> tvoss_: Yes copied from the header where they are #defined 0 .. 14
[09:59] <tvoss_> duflu, ack
[09:59] <tvoss_> duflu, which header is that?
[09:59] <tvoss_> want to note it down in my review comment
[10:00] <duflu> tvoss_: It's mentioned in the proposal diff , but /usr/include/xf86drmMode.h
[10:01] <tvoss_> duflu, top-approved
[10:04] <kgunn> tvoss_: RAOF duflu ok...this is really robust...i've not been punted t to the greeter at all....i used hdmi, then i switched to vga, hotplugging all the way, mirror/extended/dropped builtin display....all of works
[10:05] <kgunn> even moved the 2nd display virtually
[10:05] <duflu> kgunn: Yeah it's better but I hung X pretty quickly. Meanwhile USC kept running smoothly
[10:06] <kgunn> duflu: :(
[10:06] <RAOF> duflu: Stop trying to rotate :)
[10:07] <duflu> RAOF: I did no such thing
[10:08] <kgunn> RAOF: i tried to rotate actually....didn't work...but x did not crash
[10:09] <kgunn> trying reboot scenarios now
[10:09] <RAOF> Yeah, I haven't hooked up any of the shadow alloc stuff that's necessary for rotation.
[10:09] <RAOF> If I understand it correctly that *shouldn't* be hard.
[10:10] <kgunn> RAOF: we can survive CFT w/o that...i'm sure some one somewhere relies on it...but hey..this is prebeta baby
[10:10] <RAOF> …having just spent a weekend finding that the goddamned software cursor code dies if you don't dance around it perfectly.
[10:12] <kgunn> RAOF: yeah...now i see how folks like you become experts in x...lots..& lots of scar tissue
[10:12] <duflu> OK, I need to get some proper food sorted. Till tomorrow...
[10:12] <kgunn> duflu: later
[10:12] <RAOF> duflu: Eat well!
[10:12] <tvoss_> duflu, till tomorrow
[10:20] <kgunn> RAOF: tvoss_ nice work guys....this is so robust...i'm gonna upgrade on my primary machine...
[10:20] <kgunn> it has display port...so technically one more phys connector type
[10:21] <kgunn> was just telling voss....i've only managed  to crash x one time....and i'm being pretty damn mean to it
[10:22] <kgunn> probably would've crashed in standalone x
[10:24] <kgunn> robotfuel: there's no way your on...but if you're gonna do some work on sunday afternoon, qa-testing2 worthy of a run on the anointed 8 or 9
[10:26] <RAOF> As long as they're all intel - patches for nouveau & ati are pending :)
[10:26] <kgunn> RAOF: i'm all intel....all the time baby
[10:28] <kgunn> RAOF: so was duflu on nouveau (when he managed to "crash his x pretty quickly")
[10:28] <kgunn> ...having a hard time seeing crashing it quickly...
[10:29] <kgunn> ok...bbiab/rebooting to mm
[10:40] <mlankhorst> kgunn: might depend on graphcis card
[10:46] <kgunn> mlankhorst: ack that
[10:53] <kgunn> RAOF: tvoss_ ...so this is intersting....i'm on displayport/hdmi...extended desktop, i put my console in 2nd display...i run openarena...
[10:54] <RAOF> ...and?
[10:54] <kgunn> first i noticed...its totally unhinged...both high & low res going about 100fps
[10:55] <kgunn> i'm guessing its cpu or shader limited (obviously not pixels:)
[10:55] <kgunn> second thing....it takes me out of extended mode....but correctly changes the settings too....i need to test on standalone X
[10:55] <kgunn> maybe this is correct behavior
[10:56] <RAOF> Yeah, openarena is going to try and set the mode (if you're running it fullscreen)
[10:56] <RAOF> Nice that it works :)
[10:57] <kgunn> what was nice...after loading qa-testing2...i had some old display settings (extended & 2nd screen on left hand side instead of right)
[10:58] <kgunn> and it just worked!
[10:58] <kgunn> i can't wait for ancell to load this into the anointed machines in lexington
[10:59] <kgunn> RAOF: why does openarena become unhinged from vsync here ?
[11:00] <RAOF> kgunn: Because that's unimplemented; it's always been unhinged from vsync
[11:01] <kgunn> RAOF: not so my friend....when i disconnect the cable...i drop back down to ~60fps
[11:01] <kgunn> i just did it
[11:01] <RAOF> And you're running XMir?
[11:01] <kgunn> RAOF: hmmm....could it be in mirror mode...
[11:01] <RAOF> Are you sure?
[11:02] <kgunn> that the game has 2 buffers to draw into...so for ~every frame in single screen mode...he's counting 2 ?
[11:03] <kgunn> RAOF: damn it...rookie...i know for sure it was xmir on the second machine...i just took it for granted on this one...
[11:04] <kgunn> RAOF: even tho its X....that's still weird
[11:04] <kgunn> unless my theory of 2 fb being available in one frame render is why...
[11:05] <kgunn> RAOF: at least i know how X should behave :)
[11:05] <RAOF> Hm, don't know :)
[11:06] <tvoss_> kgunn, details, perhaps we can file a bug about it
[11:06] <kgunn> tvoss_: yep..something to chase up with michael
[11:06] <tvoss_> kgunn, michael?
[11:07] <kgunn> ok...rebooting to mm for reals (michael=phoronix)
[11:13] <kgunn> RAOF: tvoss_ ...any of you see the return of the lag?... or kind of, its not global... extended desktop irc in one display..terminal in the other
[11:13] <kgunn> irc has no lag...but terminal does
[11:13] <kgunn> lag=typing letter showing up
[11:13] <RAOF> kgunn: Yeah, duflu was also seeing that (as am I) - https://bugs.launchpad.net/bugs/1216337
[11:35] <tvoss_> kgunn, RAOF duflu had the idea that it might be related to buffer age
[11:39] <kgunn> ok...so for sure i'm xmir-mm...re-ran openarena....
[11:39] <kgunn> if i'm extended desktop...it treats the 2 displays like 1 surface (i see some render no one screen and some of the other)
[11:40] <kgunn> and it runs at like 25 fps
[11:40] <kgunn> if i go to mirror mode....it runs at like 125 fps
[11:41] <kgunn> and if i turn off one monitor....the benchmark tries to run, but complains about the video mode and "ends prematurely"
[12:00] <kgunn> RAOF: pastebin.canonical.com/96338/....x crash while turning off second display & going between mirror/extended
[12:00] <kgunn> EQ overflow (event queue ?)
[12:03] <kgunn> actually this is consistent...have hdmi connected, extended desktop, turn off the second display via settings...x crash
[14:29] <robotfuel> kgunn: are you around? did you want me to start a test run on qa ppa2 now?
[17:56] <xnox> I am using intel graphics, yet when switching to mir, lightdm crashes and I have to comment out "#type=unity"
[17:56] <xnox> is there any way i can fix that?
[22:56] <robert_ancell> thomi, is there a way to know who started a jenkins job?
[22:57] <thomi> robert_ancell: in the job run page, it says "started by <username>"
[22:57] <thomi> robert_ancell: in the private server anyway, I think that information is stripped on the public instance
[22:58] <robert_ancell> thomi, right, so on http://<IP_ADDRESS>:8080/view/qa-ppa2/job/qa-ppa2-openarena-ps-intel-2500-le/1/ where would I see that?
[22:58]  * thomi looks
[22:58] <robert_ancell> thomi, ah I got it
[22:58] <thomi> yeah, it was started by an upstream job
[22:58] <robert_ancell> because that job was started by the main job I needed to click that
[22:58] <robert_ancell> It was started by Chris
[22:58] <thomi> right, was started by chris
[22:59] <robert_ancell> They all failed, I'm just wondering if I should be worried by that or it was some sort of test run to check the config was working
[23:04] <RAOF> kgunn: Hm. Your “EQ overflow” crash is because Mir isn't responding to a message (again ☹)
[23:33] <RAOF> Has anyone tested qa-testing2 against nouveau or radeon? I'm just interested to know if my patches work :)
[23:35] <robert_ancell> RAOF, what's the focus next? ati/nouveu or the lag issue?
[23:37] <RAOF> Fixing the client-buffer-tracker MP, then probably lag. I don't have the hardware available to test MM on ati or nouveau.
[23:40] <kgunn> RAOF: robert_ancell can run it against the boston 8
[23:41] <robert_ancell> kgunn, it's running qa-testing2 now
[23:41] <kgunn> RAOF:also that EQ overflow only happened once that i caught
[23:41] <kgunn> every other time....the xorg log just ends....are post-config
[23:41] <kgunn> but no error complaint
[23:41] <kgunn> robert_ancell: ack
[23:41] <kgunn> fingers crossed
[23:42] <robert_ancell> thomi, it looks like a failure, but I'm not deciphering the build log - http://<IP_ADDRESS>:8080/view/qa-ppa2/job/qa-ppa2-openarena-ps-intel-2500-le/2/console
[23:42] <RAOF> In my experience the Xorg log just ending tends to be unity-system-compositor dying, and one of the mirclient threads noticing then throwing an exception.
[23:42]  * thomi looks
[23:42] <RAOF> Of course, because it's on a thread it gets logged nowhere.
[23:42] <robert_ancell> "Build step 'Execute shell' marked build as failure"
[23:43] <robert_ancell> 2013-08-25 23:18:32,372 ssh DEBUG: SSH command (/usr/share/utah/client/utah-done.py) failed with return code: 4
[23:43] <robert_ancell> this might be it
[23:43] <thomi> robert_ancell: right, it looks to me like the actual test failed
[23:43] <thomi> no
[23:44]  * thomi curses utah
[23:44] <robert_ancell> oh, is it just polling utah - nasty!
[23:45] <thomi> robert_ancell: if you look at how it's configured, it runs:
[23:45] <thomi> run_utah_tests.py -d -m physical --name "$machine" -i "$ISO" -p "$PRESEED_FILE" -l $WORKSPACE master.run || RETCODE=1
[23:45] <thomi> in the log you can see "RETCODE=1"
[23:45] <thomi> so run_utah failed
[23:46]  * thomi tries to find out why
[23:52] <thomi> robert_ancell: it's odd - it looks like the tests are running, because I can see FPS results from the openarena run, but something else is failing
[23:52] <thomi> but utah is frustratingly useless - gah
[23:59] <thomi> robert_ancell: the nearest I can make out, the final command in the test script is failing, that is:
[23:59] <thomi> xrandr | grep -i xmir
[23:59] <thomi> which I assume is there to make sure we're running xmir
[23:59] <thomi> so possibly that's the issue here


[04:04] <n-iCe> hi
[08:49] <Stek_Turku> Hi all.... i have HP 250 G3 and Xubuntu 18.04 LTS... yesterday evening my WiFi had stopped to work and this morning i have turned on my pc and the WiFi adapter (hw) was disappeared from nm and also it is not present in the output cmmand ifconfig and lshw... it is a realtek rt3290
[08:50] <Stek_Turku> i remember that yesterday evening with lswh i have illegal vendor ID on my WiFi adapter
[08:50] <pmjdebruijn> Stek_Turku: are you sure you didn't accidentally pushed the WiFi killswitch?
[08:50] <pmjdebruijn> most laptops have one
[08:51] <Stek_Turku> pmjdebruijn: i press it but it never didn't work... the led is always on and now if i press it (Fn+F12) it doesn't work... it happen nothing
[08:52] <Stek_Turku> i don't think that it worked only yesterday evening
[09:19] <Stek_Turku> sorry i disconnected...
[11:42] <ilias_gr> Hi all. I just cleanly install on a notebook with an Intel(R) Celeron(R) CPU  N2840  @ 2.16GHz with 4 gb ram the new 18.04.1 distro and I realized that in idle position the system needs 570 mb ram without any application open. On the other hand on an another notebook with exactly the same hardware's configuration (an Intel(R) Celeron(R) CPU  N2840  @ 2.16GHz with 4 gb ram) with 16.04.5 on idle position needs only 270 ram approximately. I ch
[11:42] <ilias_gr> ecked 'Session and Start up' and both systems have the same autostart applications. Does new distro need more ram to run or do I have to make any other configuration to reduce the ram the new system needs ?
[11:45] <ilias_gr> Hi all. I just cleanly install on a notebook with an Intel(R) Celeron(R) CPU  N2840  @ 2.16GHz with 4 gb ram the new 18.04.1 distro and I realized that in idle position the system needs 570 mb ram without any application open. On the other hand on an another notebook with exactly the same hardware's configuration (an Intel(R) Celeron(R) CPU  N2840  @ 2.16GHz with 4 gb ram) with 16.04.5 on idle position needs only 270 ram approximately. I ch
[11:45] <ilias_gr> ecked 'Session and Start up' and both systems have the same autostart applications. Does new distro need more ram to run or do I have to make any other configuration to reduce the ram the new system needs ?
[11:53] <ilias_gr> any idea why I am having more startup memory consumed, on xfce, between bionic and xenial using exactly the same systems?