[00:58] <StevenK> lifeless: ^ Did you get distracted?
[01:00] <lifeless> yes
[01:07] <lifeless> StevenK: uhm
[01:07] <lifeless> auditorfixture appears to be auditor ?
[01:08] <StevenK> How the heck did I screw *that* up
[01:10] <lifeless> NFI
[01:10] <lifeless> but
[01:10] <lifeless> you did :)
[01:10] <StevenK> Yeah, I'm just about to push --overwrite
[01:14] <StevenK> lifeless: It should look better now?
[01:20] <lifeless> p[-;;;;;;;;;;;;;;;;;;;;;xccccccccccccccccccbvvvvvvvvvvvvvvvvvvvvv
[01:20] <lifeless> uhm, cat.
[01:20] <StevenK> Hah
[01:21] <lifeless> does runserver support dynamic port allocation ?
[01:23] <StevenK> lifeless: From what I saw, yes.
[01:23] <lifeless> StevenK: you did something similar to txlongpollfixture, I presume; that did what I did for rabbit, which doesn't support dynamic port allocation
[01:24] <lifeless> a better thing, if its doable is to just run runserver and watch what port it chooses
[01:24] <lifeless> StevenK: that said, if this works, great.
[01:24] <StevenK> Which it doesn't.
[01:25] <StevenK> But I've hit the limit of Django-ness -- I dislike the idea of forking off python to run it
[01:25] <lifeless> StevenK: my main concern looking at is is that we'll have the same bugs that rabbitfixture has had w.r.t. race conditions on startup (such as the timeout logic); we should perhaps consolidate the common code into fixtures
[01:25] <lifeless> StevenK: running django in a subprocess is entirely appropriate
[01:26] <lifeless> StevenK: we /do not want/ to try and import django into our python environment - for multiple reasons, including django having a honking great set of global variables that will collide
[01:26] <lifeless> https://docs.djangoproject.com/en/dev/ref/django-admin/#runserver-port-or-address-port suggests it does not do dynamic ports.
[01:27] <lifeless> StevenK: ok, so it doesn't work. What happens, specifically ?
[01:29]  * StevenK rips out the devnull, so he can see what is going on
[01:29] <lifeless> StevenK: oh, I see the devnull. Don't do that :)
[01:30] <StevenK> Hm, smoking gun
[01:30] <lifeless> StevenK: you can capture the stdout to e.g. the logfile
[01:30] <lifeless> StevenK: and you won't lose information that way
[01:30] <StevenK> devnull is for stdin
[01:30] <StevenK> However, for this I wanted the output to the terminal
[01:31] <StevenK> python manage.py is all well and good -- when you're in auditor's directory
[01:31] <lifeless> bleep, I misread.
[01:31] <lifeless> yes.
[01:32] <StevenK> So I wonder if auditor is hiding somewhere I can call it ...
[01:32] <lifeless> why did you want terminal? To see what was up ?
[01:32] <lifeless> The failure message should have given you the log file ocontents.
[01:32] <StevenK> lifeless: Nope, I was just getting the raise Exception("Timeout ....
[01:33] <lifeless> StevenK: so you have a fixture object
[01:33] <lifeless> that.getDetails() should give you a path in, for future reference.
[01:33] <lifeless> e.g. f.getDetails().items()[0].itertext()
[01:33] <StevenK> lifeless: In _start(), that's going to be self, isn't it?
[01:33] <lifeless> StevenK: yes, but _start doesn't need to change.
[01:34] <lifeless> StevenK: you already attach the logfile; the caller can choose to look
[01:34] <lifeless> StevenK: TestCase.useFixture attaches the details before it sets up, IIRC, so it should be doing this.
[01:34] <StevenK> lifeless: I think _start() does need to change, since the error is "python: can't open file 'manage.py': [Errno 2] No such file or directory" :-)
[01:34] <lifeless> StevenK: doesn't need to change w.r.t. reporting :P
[01:35] <lifeless> StevenK: you need to introspect to get the path to the auditor egg, txlongpoll should have example code.
[01:35] <StevenK> txlongpoll or txlongpollfixture?
[01:35] <lifeless> the latter
[02:00] <StevenK> lifeless: Right, I see how txlongpollfixture does it. But auditorfixture doesn't have parts/auditor :-(
[02:01] <StevenK> lifeless: And I have a [auditor] section in buildout.cfg
[02:08]  * wgrant cries
[02:08] <wgrant>             for team in administers_and_in:
[02:08] <wgrant>                 if (bug_supervisor is not None and
[02:08] <wgrant>                     not team.inTeam(bug_supervisor)):
[02:08] <wgrant>                     continue
[02:08] <wgrant> inTeam is not preloaded
[02:09] <lifeless> StevenK: uhm, your auditor section doesn't define an entry point
[02:09] <StevenK> lifeless: It needs to? My buildout-foo is very weak
[02:10] <lifeless> StevenK: I *think* so, it generates the right interpreter etc
[02:10] <lifeless> I just realised, running 'python manage.py' is wrong because of that, it should be a buildout created python executable
[02:11] <lifeless> which the entry points are used to do
[02:12] <StevenK> lifeless: I still need a path to manage.py, I don't think it matters which interpreter I use.
[02:12] <StevenK> txlongpollfixture somehow ends up with parts/txlongpoll
[02:14] <lifeless> uhm
[02:14] <lifeless> not sure where to pull on this one
[02:15] <lifeless> you don't run the manage.py from auditor directly
[02:15] <lifeless> python version mismatch etc stuff
[02:15] <StevenK> Not even the unpacked egg?
[02:15] <lifeless> indeed
[02:15] <lifeless> txlongpollfixture doesn't either.
[02:18] <StevenK> Ah. So what should I do?
[02:18] <lifeless> so the basic idea
[02:19] <lifeless> is you have a function which can be an entry point
[02:19] <lifeless> e.g. def foo(argv=None):
[02:19] <lifeless>     if argv is None: argv = sys.argv
[02:19] <lifeless>     ...
[02:19] <lifeless> that is probably inside manage.py already
[02:20] <lifeless> you point at the *python path* to that function, which will be inside auditd (and you'll probably know far more about django glue than you want to by the time you're done)
[02:20] <lifeless> buildout generates a local executable for you in bin/ when you set scripts=
[02:20] <lifeless> see entry-points = twistd-for-txlongpoll=twisted.scripts.twistd:run
[02:20] <lifeless> scripts = twistd-for-txlongpoll
[02:20] <lifeless> for instance, in LP's buildout.cfg
[02:20] <lifeless> so you'll have something like
[02:21] <lifeless> entry-points = auditord-manager=auditord.manager:run
[02:21] <lifeless> scripts = auditord-manager
[02:21] <lifeless> then, the fixture runs bin/auditord-manager
[02:22] <lifeless> probably adjusted to be os.path.join(os.getcwd(), 'bin/auditord-manager')
[02:22] <lifeless> because of the cwd param to Popen
[02:23] <lifeless> StevenK: does that make sense?
[02:23] <StevenK> lifeless: Barely
[02:24] <StevenK> lifeless: So I need a auditord module now?
[02:24] <lifeless> you have one
[02:24] <lifeless> the django app
[02:25] <lifeless> whats the auditord project name ?
[02:25] <StevenK> auditor
[02:28] <lifeless> auditlog is your module name
[02:29] <lifeless> you need to move / symlink or something manage.py within auditlog from the looks of things
[02:29] <lifeless> and ugh yeah the one thing I really don't like about django - settings
[02:30] <wgrant> Um
[02:30] <wgrant> That's the one thing?
[02:30] <StevenK> Haha
[02:30] <wgrant> It's one of the worst things, but lots of the rest is also hideous :)
[02:30] <StevenK> lifeless: And apparently a fixture would be *easy*
[02:30] <StevenK> ... and other lies I've been told. :-)
[02:32] <StevenK> lifeless: I'm not sure what module you want me to jump into?
[02:32] <StevenK> auditor.manage seems pointless
[02:34] <wgrant> lifeless: Shouldn't manage.py be replaced by a buildout-generated bin/manage?
[02:35] <lifeless> wgrant: yes, thats what I'm describing
[02:36] <lifeless> StevenK: you have a package 'auditlog'
[02:36] <lifeless> StevenK: We have a project 'auditord', with a public name of 'auditor' and package 'auditlog' - I think you should choose one and go with it
[02:37] <StevenK> lifeless: I can't!
[02:37] <lifeless> StevenK: why not ?
[02:37] <StevenK> You can't call the app 'auditor' if the project is.
[02:37] <lifeless> .expand()
[02:37] <wgrant> I'm pretty sure you can.
[02:38] <StevenK> lifeless: I never picked the name auditord, that was you
[02:38] <wgrant> It just gets a bit odd, due to implicit relative imports.
[02:38] <lifeless> ok, so, auditor, fine.
[02:38] <lifeless> What happens if you use the name auditor for the package ?
[02:39] <StevenK> steven@undermined:~% django-admin startproject foobar
[02:39] <StevenK> steven@undermined:~% cd foobar
[02:39] <StevenK> steven@undermined:~/foobar% python manage.py startapp foobar
[02:39] <StevenK> Error: You cannot create an app with the same name ('foobar') as your project.
[02:39] <wgrant> Try it anyway
[02:40] <wgrant> It'll probably work
[02:40] <StevenK> I just did?
[02:40] <wgrant> You tried using Django's stupid tool to do it.
[02:40] <StevenK> And?
[02:41] <StevenK> I'd been avoiding Django just fine until you two railroaded me into auditor.
[02:42] <lifeless> https://code.djangoproject.com/ticket/1908
[02:43] <wgrant> Well
[02:43] <wgrant> I never suggested Django is a good fit.
[02:43] <wgrant> It's really not.
[02:43] <lifeless> 5 months ago
[02:43] <lifeless>     Triage Stage changed from Accepted to Fixed on a branch
[02:43] <lifeless> The bug has been fixed in trunk, apps with same name as project name can be created now
[02:44] <StevenK> wgrant: I think that was lifeless
[02:44] <lifeless> StevenK: what was me ?
[02:44] <StevenK> Suggesting Django
[02:45] <lifeless> its a preferred tech
[02:45] <lifeless> I've said explicitly that I think its sufficient for the small targeted things we need
[02:45] <lifeless> that it has some very good values around lean-ness, clean& understandable code, and performance
[02:46] <wgrant> Um
[02:46] <lifeless> and that it may be too heavyweight for some things (like gpg-httpd)
[02:46] <wgrant> The problem is not that it's insufficient.
[02:46] <StevenK> And then you try and write a fixture and go insane
[02:46] <lifeless> StevenK: you're breaking new ground
[02:46] <wgrant> It's that all of the awkward stuff it provides is entirely useless for this sort of service.
[02:46] <wgrant> For auditordloger, the useful stuff it provides over raw WSGI is an ROM
[02:46] <wgrant> ORM
[02:47]  * lifeless notes that this is a distraction
[02:47] <StevenK> Clearly you want the app to be called auditor too, which means I need to look at packaging Django 1.4
[02:47] <lifeless> StevenK: auditlog is a package name, that is the package you need to make a manager.py exist in, it's probably easiest to have it be a new file with contents derived from the django made one.
[02:48] <lifeless> StevenK: I do, but even that is a distraction
[02:48] <lifeless> StevenK: and, its one that can be solved later. Because nothing in LP will know about *either* auditor or auditlog.
[02:48] <StevenK> lifeless: Why does it need to exist under auditlog?
[02:48] <lifeless> StevenK: so that buildout can import it.
[02:48] <StevenK> But buildout can import from auditor too?
[02:48] <StevenK> auditor/__init__.py exists, so it import auditor should work
[02:49] <lifeless> wait, what
[02:49] <lifeless> OHHH
[02:49] <lifeless> crazy f*d up layout.
[02:49] <lifeless> ok, so yes, auditor.manage:run
[02:49] <lifeless> and edit manage.py to have a run() method
[02:49] <lifeless> (and the usual if __name__ == '__main__': boilerplate
[02:50] <StevenK> manage.py already has __main__ boilerplate
[02:50] <lifeless> it does, it needs altering
[02:52] <lifeless> e.g. http://paste.ubuntu.com/998398/
[02:54] <lifeless> StevenK: btw, we probably want to change auditor from being a django project to being a django app (and then have a project which is for testing created on the fly, and one for prod deployment)
[02:54] <lifeless> StevenK: but again, Future Work.
[02:55] <lifeless> StevenK: I will make one note on the naming of things; the reason I propose auditord is so that auditor is available for a client library, if you were to decide you want one.
[02:55] <lifeless> StevenK: as it is, you'll have to use auditorclient or something instead.
[02:56] <StevenK> Client library? Err?
[02:56] <StevenK> It returns JSON, how can that possibly require a client library?
[02:57] <lifeless> you never know your own future :)
[02:58] <lifeless> I'm not asking you to rename it, I'm explaining why I'm sticky on the d's - its an easy default and makes it easier for me to think about names.
[02:58] <StevenK> I can see a gun and my temple in my future
[02:58] <lifeless> I don't think quake3 supports that.
[02:58] <StevenK> Who said anything about Quake 3?
[02:59] <StevenK> lifeless: bin/auditor-manage can not import auditor.manage
[03:00] <lifeless> StevenK: I did, because why not?.
[03:01] <lifeless> StevenK: so, thats python path debugging time
[03:02] <StevenK> sys.path = ['/home/steven/auditorfixture/parts/auditor', '/home/steven/auditorfixture/bin', '/usr/lib/python2.7', '/usr/lib/python2.7/plat-linux2', '/usr/lib/python2.7/lib-tk', '/usr/lib/python2.7/lib-old', '/usr/lib/python2.7/lib-dynload', '/home/steven/auditorfixture/eggs/auditor-0.0.1-py2.7.egg', '/home/steven/auditorfixture/eggs/Django-1.4-py2.7.egg']
[03:02] <lifeless> and is manage.py present within /home/steven/auditorfixture/eggs/auditor-0.0.1-py2.7.egg ?
[03:03] <StevenK> Sigh, no.
[03:04] <StevenK> I guess that's due to find_packages() in auditor's setup.py
[03:12] <lifeless> StevenK: yes, I suspect so
[03:13] <lifeless> StevenK: note that its not finding the top level __init__.py at all
[03:13] <lifeless> StevenK: so your egg only contains auditlog.
[03:13] <StevenK> Yes
[03:18] <lifeless> http://paste.ubuntu.com/998418/
[04:01] <wgrant> lifeless: Oh yeah
[04:01] <wgrant> lifeless: I discovered on Friday evening that my optimisation of bugsummary was bad.
[04:02] <wgrant> lifeless: I'd accidentally typoed so it flushed the journal into the journal, so it was writing to a temp table, not a real one.
[04:02] <wgrant> So it's only about 2.5x faster than before.
[04:03] <wgrant> s/flushed the jounral into the journal/flushed the temp journal into the temp journal/
[04:03] <wgrant> And that's with journal FKs removed.
[04:04] <lifeless> wgrant: still, 2.5x is fast enough to run two in parallel
[04:05] <wgrant> lifeless: I have a cunning plan to avoid having to do that.
[04:05] <wgrant> A couple of unresolved issues, but it should work.
[04:08] <lifeless> StevenK: that pastebin was to you, should work.
[04:10] <wgrant> StevenK, wallyworld_: https://code.launchpad.net/~wgrant/launchpad/bugsummary-v2-app-no-fixed-upstream/+merge/106557
[04:11]  * wallyworld_ looks
[04:17] <wallyworld_> wgrant: looks ok to me. lots of code deletion :-)
[04:17] <wgrant> wallyworld_: Yup. Thanks.
[04:47] <mwhudson> https://bugs.launchpad.net/lava-deployment-tool/+bug/1000819/@@+huge-vocabulary timeouts are known?
[04:47] <_mup_> Bug #1000819: uwsgi 1.0.3 no longer available <LAVA Deployment Tool:New> < https://launchpad.net/bugs/1000819 >
[04:48] <mwhudson> https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-f6d562060ee52035ead5254827fee6ab\
[04:52] <wgrant> mwhudson: Yeah, branch search is criminally bad
[04:53] <mwhudson> :(
[04:54] <mwhudson> is it just select from branch where unique_name like '%${TERM}%' or something?
[04:54] <wgrant> The query is awful awful awful
[04:54] <wgrant> But it shouldn't be as slow as it is.
[04:55]  * mwhudson looks at the code
[04:55] <wgrant> It's in the OOPS
[04:55] <wgrant> Top statement.
[04:55] <mwhudson> i think my bad version is a lot better than this
[04:55] <wgrant> Oh
[04:55] <wgrant> wut
[04:56] <wgrant> SELECT Branch.id
[04:56] <wgrant> FROM Branch,
[04:56] <wgrant>      Product
[04:56] <wgrant> WHERE Branch.product = Product.id
[04:56] <wgrant>   AND Product.name LIKE u$STRING)
[04:56] <wgrant> I'm pretty sure that comes under "who could possibly think that was useful or a good idea"
[04:56] <wgrant> I didn't realise it did that too
[04:56] <mwhudson> OR Branch.url = u$STRING) is my favourite useless bit i think
[04:56] <wgrant> Why?
[04:57] <mwhudson> branch.url is NULL for !mirror branches
[04:57] <wgrant> Oh, so it is.
[04:57] <mwhudson> and noone case about mirror branches any more
[04:57] <wgrant> Not unique_name, right
[04:57] <wgrant> Yeah
[04:57] <mwhudson> Product.name LIKE u$STRING is pretty special yes
[04:57] <wgrant> The theory behind it seems to be "find ALL the things"
[04:58] <wgrant> And then leave the user to page through the 9s batches.
[04:58] <mwhudson> itym "try to find all the things, but timeout instead'
[04:58] <StevenK> Apparently, find_packages() looks for __init__.py in directories. I think it lies. :-(
[04:58] <wgrant> It works sometimes!
[04:58] <wgrant> mwhudson: Part of the problem is bugtasks.
[04:58] <wgrant> mwhudson: Because there's no logical context to search in.
[04:58] <mwhudson> oh right
[04:58] <mwhudson> well
[04:59] <wgrant> So you have to search everywhere, probably.
[04:59] <mwhudson> you could look in the context for all the extant bugtasks i guess?
[04:59] <wgrant> Yeah
[04:59] <mwhudson> but that gets a bit complicated
[04:59] <wgrant> We introduced that concept with disclosure.
[04:59] <wgrant> It's possible.
[04:59] <mwhudson> cool
[04:59] <wgrant> Then I'd do name LIKE '%foo%' or unique_name = 'foo', I think...
[04:59] <mwhudson> seriously though unique_name like $string would be as good as this
[04:59] <wgrant> Not sure it needs much more than that.
[04:59] <lifeless> StevenK: it does, but it starts with listdir()
[04:59] <lifeless> StevenK: did you apply my patch ?
[04:59] <wgrant> unique_name LIKE '%foo%' is a bit bad, as it matches the product name.
[05:00] <wgrant> But maybe.
[05:00] <mwhudson> (of course, unique_name is only 4 years old or whatever, so much newer than this code)
[05:00] <StevenK> lifeless: I was out for lunch with a friend, so if it was a patch to setup.py, I'm sorry but I missed it
[05:00] <mwhudson> wgrant: not saying mine is good, just better than existing
[05:00] <lifeless> 15:18 < lifeless> http://paste.ubuntu.com/998418/
[05:00] <wgrant> mwhudson: With 9.1 we can even use trigram indices to make LIKE '%foo%' very fast.
[05:00] <lifeless> (its now 17:00 and EOD)
[05:00] <mwhudson> bug 372591
[05:00] <_mup_> Bug #372591: Branch vocabulary and search needs thought and cleaning up <lp-code> <tech-debt> <Launchpad itself:Triaged> < https://launchpad.net/bugs/372591 >
[05:00] <wgrant> mwhudson: That title has a few too many euphemisms.
[05:01] <mwhudson> it's a dup of https://bugs.launchpad.net/launchpad/+bug/793830 anyway
[05:01] <_mup_> Bug #793830: Branch:+register-merge time out due to substring matching many tables <critical-analysis> <timeout> <Launchpad itself:Triaged> < https://launchpad.net/bugs/793830 >
[05:01] <wgrant> Yeah
[05:01] <wgrant> That's the one that wallyworld was hitting a lot last week
[05:02] <StevenK> lifeless: Right, I did miss it -- I scanned backlog until I hit wgrant begging for a review and stopped.
[05:02] <wgrant> Oh, the prereq or target branch you specified doesn't match a unique_name exactly? Let me just do a 10s search for you.
[05:02] <mwhudson> heh
[05:02] <mwhudson> that makes the pain less avoidable i guess
[05:03] <mwhudson> (my oops was from the suggestions in the 'link a branch' overlay)
[05:09] <StevenK> lifeless: error: can't copy 'uditor.egg-info/PKG-INFO': doesn't exist or not a regular file
[05:09] <StevenK> EWTF
[05:09] <wgrant> mwhudson: I don't know about you, but my distribution of searches is roughly this: 95% of the time it's one of the last 5 branches I touched; 4% I want to search by substring of name in the current project; 1% I want to search by full unique_name (optionally including lp:)
[05:12] <mwhudson> wgrant: certainly "last branch i touched" is a good guess a lot of the time
[05:13] <mwhudson> and in this case it was a mixture of the first two points
[05:13] <wgrant> Yeah, but ranking like that is hard.
[05:13] <wgrant> So we tend to try to avoid combining them like that.
[05:14] <mwhudson> solr-as-a-service!
[05:14]  * mwhudson goes back to real work
[05:15] <StevenK> mwhudson: We know where you live!
[05:38]  * StevenK stabs PlainPackageCopyJobTests.createCopyJob() for failing
[06:08] <lifeless> mwhudson: patches solicited
[06:08] <lifeless> mwhudson: if you get tired of doing easy things
[06:19] <StevenK> wgrant: Should I need to do anything after running acceptFromQueue() on the PU and then re-running the PCJ?
[06:20] <StevenK> wgrant: Since IArchive.getPublishedSources(name=) is returning [] :-(
[06:23] <wgrant> StevenK: Sounds like the PCJ is not running.
[06:29] <StevenK> Oh, it does run, it just raises CannotCopy
[06:29] <StevenK> Which it doesn't tell me
[06:30] <StevenK> unique-from-test-packagecopyjob-py-line361-100000 1.0-1 in breezy-autotest (The signer of this package has no upload rights to this distribution's primary archive.  Did you mean to upload to a PPA?
[06:30] <StevenK> Right
[06:52] <lifeless> StevenK: how are you going ?
[07:13] <StevenK> lifeless: I gave up in disgust
[07:14] <StevenK> Trying to get my SPPH linked to PUs working with PCJs
[07:18] <bigjools> why are you doing that?
[07:19] <StevenK> bigjools: Because we'd like to know who accepted something, and that information is directly realted to the PackageUpload, and PCJs create PackageUploads if needed.
[07:20] <bigjools> sounds like a hack
[07:20] <StevenK> How?
[07:20] <bigjools> did you consider any other solutions?
[07:21] <StevenK> Like adding yet another column onto SPPH that shows who accepted it? Now that is a hack.
[07:21] <bigjools> like an audit trail table
[07:22] <StevenK> lifeless nacked it
[07:22] <StevenK> Which is what auditor is for
[07:22] <bigjools> linking to PU is horrible
[07:22] <StevenK> But the acceptance is for the *PackageUpload* there is no publication at that point
[07:22] <bigjools> not all SPPHes result from a PU
[07:22] <StevenK> Of course
[07:22] <bigjools> so, yet another nullable FK
[07:23] <StevenK> Like sponsor? :-P
[07:23] <bigjools> yes :/
[07:23] <wgrant> Nullable FKs are only a problem in theoretical relational algebra.
[07:23] <bigjools> I'm just interested in how you arrived at this solution
[07:24] <bigjools> if it's the least horrible then fair enough
[07:24] <StevenK> bigjools: It was the solution that made the most sense -- with auditor being used and keeping track of a PU as it moves through the queue, we needed a way to easily look up the PU for an SPPH
[07:25] <wgrant> I think it's least bad for now.
[07:25] <bigjools> the whole model is a mess :/
[07:25] <wgrant> Eventually we should replace PU with something that tracks each operation on the archive.
[07:25] <wgrant> Copies and uploads.
[07:25] <wgrant> And overrides.
[07:25] <wgrant> And deletions.
[07:25] <bigjools> like an audit table ...
[07:25] <wgrant> Audit tables have been vetoed.
[07:26] <wgrant> Audit services have not.
[07:26] <wgrant> So StevenK is writing an audit service.
[07:26] <bigjools> what SPPH should have been
[07:26] <wgrant> SPPH only tracks sources.
[07:26] <bigjools> not audit audit ... just a history
[07:26] <wgrant> That'll work OK if we can convince Ubuntu to turn into Gentoo.
[07:26] <wgrant> But I think cjwatson might not approve.
[07:26] <bigjools> lol
[07:27] <bigjools> the lack of any recording on who did what action was a terrible omission from the start
[07:27] <bigjools> but what is done is done
[07:28] <wgrant> As long as we learn from our mistakes.
[07:28] <wgrant> Which we haven't classically done, but we're hopefully getting better.
[07:28] <bigjools> we mostly do
[07:29] <wgrant> The audit service will hopefully mean we can do it easily.
[07:29] <wgrant> For everything.
[07:29] <wgrant> For every action.
[07:30] <bigjools> well I see auditing as two things
[07:30] <bigjools> hysterical data for later analysis
[07:31] <bigjools> and stuff that affects immediate decisions
[07:31] <bigjools> I can't see how a service helps with the latter
[07:41] <lifeless> wgrant: bigjools: is there a link from bug(task) -> packageupload for fixed bugs?
[07:41] <lifeless> bigjools: the service lets you query the actions on an object, so it should handle the latter nicely.
[07:42] <StevenK> wgrant: https://code.launchpad.net/~stevenk/launchpad/populate-spph-pu/+merge/105601 now knows about PCJs. You can review it now if you wish, or tomorrow when you're OCR. :-P
[07:42] <StevenK> lifeless: Fixing bugs does not use the PU, but the changesfile
[07:42] <wgrant> lifeless: There isn't. You'd have to look for the comments
[07:42] <lifeless> StevenK: so if ev wants to get from bug -> BPPH, he goes bug -> changesfile -> SPPH -> BPPH  or some insanity ?
[07:42] <wgrant> StevenK: I'll do it tomorrow
[07:43] <bigjools> lifeless: the upload code scans the changelog
[07:43] <lifeless> bigjools: yah, is the other way round we want
[07:43] <bigjools> I know :)  just telling you how shit it is right now
[07:43] <lifeless> bigjools: so, schema work needed? Thats ok, just want to be sure.
[07:43] <bigjools> it doesn't store the refs
[07:43] <bigjools> just pokes the bugs
[07:43] <StevenK> lifeless: Absolutely schema work needed
[07:44] <StevenK> lifeless: Anyway, you want the SPPH, not the BPPH
[07:44] <lifeless> StevenK: no, we want the BPPH
[07:44] <bigjools> lifeless: bear in mind that ultimately it'd be really nice to serviceify soyuz
[07:44] <lifeless> users don't download sources to fix bugs
[07:44] <StevenK> lifeless: The bug is closed when the *source* is uploaded, not the binaries
[07:44] <lifeless> bigjools: orly :P :P :P
[07:44] <lifeless> StevenK: I know
[07:44] <bigjools> lifeless: bugs are not filed on binaries
[07:44] <lifeless> I know that too
[07:45] <lifeless> expand your minds
[07:45] <StevenK> I've been dealing with buildout and setuptools today. Maybe my mind will uncurl from the fetal position tomorrow morning.
[07:45] <bigjools> linking at schema level adds more hurdles to serviceifying
[07:46] <lifeless> bigjools: it changes the work needed, thats true.
[07:46] <bigjools> lifeless: what is it that you're trying to achieve?
[07:47] <bigjools> coz you're breaking your own rule here :)
[07:49] <lifeless> otp right now, happy to expand later
[07:49] <lifeless> what rule am I breaking ?
[07:50] <bigjools> lifeless: report the problem not a proposed solution
[07:50] <bigjools> no prob anyway, I am about to scoot off for dinner
[07:51] <lifeless> The problem is how to map from bugs (apport ones specifically) to the binary packages that fix problems for users
[07:51] <lifeless> ev and I are discussing how to do that, and trying to identify big stroke work needed to do that
[07:53] <wgrant> Putting that in LP seems like entirely the wrong thing to do.
[07:53] <wgrant> Isn't that a daisy thing?
[07:55] <bigjools> lifeless: This info is in the bug comments
[07:55] <lifeless> yah, we established that
[07:55] <lifeless> sorry, really otp
[07:55] <bigjools> so where's the problem?
[07:56] <wgrant> Like
[07:56] <lifeless> parsing bug comments in a service
[07:56] <bigjools> ah "parsing", you didn't say that ;)
[07:56] <wgrant> Why not have an external service do the same thing.
[07:56] <lifeless> we're discussing that as an option
[07:56] <wgrant> Keep a list of (bug#, package, version)
[07:56] <adeuring> good morning
[07:56] <wgrant> Done
[07:56] <wgrant> Problem solved
[07:56] <wgrant> No LP crap :)
[07:56] <lifeless> wgrant: needs to cross reference tasks
[07:56] <lifeless> wgrant: so no, its not that simple.
[07:56] <wgrant> lifeless: package is there
[07:56] <wgrant> package + bug => task
[07:56] <wgrant> done
[07:56] <wgrant> no LP crap :)
[07:56] <lifeless> wgrant: + series.
[07:57] <wgrant> (bug#, series, package, version)
[07:57] <wgrant> => task
[07:57] <wgrant> done
[08:06] <jam> wasn't there a simple script (that isn't setuplx
[08:06] <jam> setuplxc) for setting up a dev environment? Just rocketfuel?
[08:06] <jam> For some reason I remember a different command (like lpsetup) from the mailing list
[08:10] <lifeless> ev: http://en.wikipedia.org/wiki/Tarjan%27s_strongly_connected_components_algorithm
[08:28] <lifeless> ev: you have frozen
[08:28] <lifeless> ev: http://www.apple.com/xsan/
[08:28] <lifeless> ev: or rather, my desktop has
[08:28] <ev> I'm back at "connecting..."
[08:28] <ev> heh
[08:28] <lifeless> power button pushed.
[08:28] <lifeless> doo be doo
[08:29] <wgrant> jam: lpsetup is being written.
[08:29] <ev> haha
[08:29] <wgrant> jam: But I don't think it's ready yet.
[08:29] <lifeless> frankban is working on it in slack time
[08:29] <wgrant> jam: https://dev.launchpad.net/Running/LXC is the recommended thing to do these days
[08:31] <lifeless> vonderbar, hung on BIOS on reboot
[08:31] <lifeless> OTOH it may have been probing RAM or something; silly quasi-server that it is.
[10:13] <rick_h_> morning
[10:14] <wgrant> stub: Does avahi work for you?
[10:14] <wgrant> stub: It normally fails because the initscript sets a ulimit for the user process limit
[10:14] <wgrant> stub: Which prevents more than ~1.5 avahi instances from running on a single kernel
[10:15] <wgrant> Unless you were lucky and got different UIDs over your two installations.
[12:17] <rick_h_> benji: morning, time for a quick review when you get a sec please? https://code.launchpad.net/~rharding/maza-server/sso_cleanup/+merge/106615
[12:18] <benji> rick_h_: sure, it will be a few minutes (on a call)
[12:18] <rick_h_> benji: no rush, thanks
[12:19] <mgz> so, my after-lunch question, when running launchpad and it gives a 503 on https://launchpad.dev/ where do I go to find out more?
[12:19] <mgz> nothing in logs is very helpful
[12:19] <wgrant> mgz: Sounds like it's not running.
[12:19] <wgrant> Have you started it?
[12:19] <wgrant> (make run or make start)
[12:19] <mgz> I did make run
[12:20] <mgz> and get the :( page
[12:20] <wgrant> Oh
[12:20] <wgrant> That sort of 503
[12:20] <wgrant> That means there's no DB .
[12:20] <wgrant> Possibly postgres isn't running
[12:20] <mgz> that's something neither rocketfuel nor make run do?
[12:21]  * mgz unskips the building step
[12:22] <wgrant> mgz: launchpad-database-setup
[12:22] <mgz> seems not, looks like new log to me
[12:22] <wgrant> Hm?
[12:23] <mgz> I'd wrongly assumed that would be done as part of the bootstrap
[12:23] <wgrant> It wipes out your postgres installation.
[12:23] <wgrant> So doing it implicitly would be a little impolite.
[12:24] <mgz> the output lives in the launchpad tree under database?
[12:24] <mgz> or in a system dir?
[12:25] <wgrant> It rebuilds and reconfigures and populates your default system postgres instance.
[12:25] <wgrant> Usually /var/lib/postgresql/9.1/main
[12:25] <mgz> ace, thanks, so will need this as part of my instance setup
[12:26] <wgrant> That's why it's in the instructions :)
[12:27] <mgz> I blame the red rectangle for making me want to ignore that section
[12:28] <mgz> okay, looks good, thanks wgrant
[12:28] <mgz> really lunchtime
[12:29] <wgrant> Heh
[13:55] <jam> jtv: there seems to be a problem with the clean-up-the-database script that we were running trying to get Q translations working again.
[13:56] <jam> I've heard that you're the guy who knows whats up, if you can give me a pointer, I can try to take it from there.
[14:12] <jamestunnicliffe> benji: Hi, could I get a review started? https://code.launchpad.net/~dooferlad/launchpad/upcomingwork_show_incomplete_bp
[14:12] <benji> jamestunnicliffe: you have good timing, I was just looking at it
[14:12] <jamestunnicliffe> benji :-)
[14:21] <benji> jamestunnicliffe: I approved your branch with a couple of small suggestions.
[14:22] <jamestunnicliffe> benji: Thanks. I have another branch waiting you have a moment, but I don't want to hog all your reviewing time!
[14:23] <benji> jamestunnicliffe: I just started on it too
[14:23] <jamestunnicliffe> benji: Ah, thanks for the tal:conditional tip. I could not find a code example showing that. Clearly google was broken on Friday...
[14:24] <benji> my pleasure
[14:47] <benji> jamestunnicliffe: review done; I saw that you could remove a couple of (pre-existing) calls to float that aren't needed, if you feel like it.  Other than that the branch looks good.
[14:48] <jamestunnicliffe> benji: I am up for changing to <tal:upcoming_work_class_name define="global upcoming_work_class_name string:expanded"/> but I have a question. The tal:<string> seems to be required but <string> doesn't seem to matter. Is it just convention that we match it (namespace?) with the name of the thing we are defining?
[14:49] <benji> jamestunnicliffe: right, the element name can be whatever you want, people often use "<tal:block>" for those, so that's an option too
[14:50] <jamestunnicliffe> benji: Thanks.
[14:51] <benji> np
[14:55] <jamestunnicliffe> benji: I have uploaded a new branch. I don't have merge privs though. Can you kick that into action?
[14:55] <benji> jamestunnicliffe: sure
[14:56] <jamestunnicliffe> benji: Will get rid of those float calls and ping you to merge that in a moment.
[14:56] <benji> jamestunnicliffe: cool
[15:02] <jamestunnicliffe> benji: lp:~dooferlad/launchpad/postponed-is-done is ready as well now. Thanks!
[15:02] <benji> k
[18:24] <lifeless> morning
[18:30] <jelmer> hey lifeless
[18:32] <lifeless> hey jelmer
[18:32] <lifeless> any luck on subunit ?
[19:06] <cjwatson> benji: Thanks for your review of https://code.launchpad.net/~cjwatson/launchpad/germinate-stale-files/+merge/106626; I've made adjustments.  Can you set Status to Approved if you're happy with that, and I'll land it?
[19:07] <lifeless> jelmer: ^?
[19:08] <benji> cjwatson: I've set it to approved.  You should feel free to do so too.
[19:09] <cjwatson> Thanks
[19:11] <benji> oh, and cjwatson: yes, you're weird ;)
[19:12] <cjwatson> heh
[19:13] <cjwatson> I guess I find it easier to be consistent about using context managers everywhere possible rather than having to think about (even trivial) exceptions
[19:13] <cjwatson> or something.  hard to cognitively unpack
[19:39] <cjwatson> Or possibly that it means that the safest ways to create an empty file and create a non-empty file are spelled more similarly
[22:25] <wgrant> WebOps: how many OpenIDs are on https://launchpad.net/~dachary/+reviewaccount?
[22:29] <spm> wgrant: just the 1
[22:32] <wgrant> Oh hm
[22:32] <wgrant> spm: SELECT * FROM openidrpsummary WHERE account = (SELECT id FROM account WHERE openid_identifier='dnTeEXH');
[22:32] <wgrant> On SSO
[22:32] <wgrant> Or equivalent web UI if there is one.
[22:33] <spm> itt, we learn that wgrant is single handedly responsible for wvg task queuing
[22:33] <spm> >:)
[22:33] <wgrant> No, that's users who somehow create more than one SSO account without noticing.
[22:36] <czajkowski> special
[22:37] <spm> czajkowski: yes, yes I am. thanks for noticing!
[22:38]  * czajkowski peer at spm have you been taking lessons from mr. StevenK 
[22:38]  * StevenK raises an eyebrow.
[22:38] <spm> pfft. try other way around. the grasshopper learns from the master
[23:26] <StevenK> wgrant: Is bug heat dead enough to nail bug 705713 shut?
[23:26] <_mup_> Bug #705713: Bug:EntryResource Timeout trying to set bug private - death by sql / late evalation <timeout> <Launchpad itself:Triaged> < https://launchpad.net/bugs/705713 >
[23:28] <StevenK> Oh my god, I know what I need to fix
[23:28] <wgrant> StevenK: Indeed, thanks.
[23:56] <StevenK> RARGH
[23:57] <StevenK> Any OOPS I've tried to see from following links in bug reports gives no such oops
[23:57] <StevenK> And then Firefox crashed