[00:00] <lifeless> wgrant: and bug 739051
[00:00] <_mup_> Bug #739051: Product:+index timeouts <timeout> <Launchpad itself:Triaged> < https://launchpad.net/bugs/739051 >
[00:00] <wgrant> Blah, yes, but that should die.
[00:00] <lifeless> wgrant: you asked if I was sure.
[00:01] <lifeless> wgrant: 4% or so of our timeouts-by-pageid involve this table :)
[00:07] <StevenK> wgrant: Still not clear how the new DSP should look
[00:17] <wgrant> Oh good, I don't even have to update the topic.
[00:17] <wgrant> Because 10 bugs have been filed, and 10 fixed.
[00:17] <StevenK> But deployment is still a mess? :-)
[00:17] <wgrant> Until we have no complaints for two hours, yes.
[00:18] <StevenK> I can't land branches! Does that count?
[00:18] <wgrant> :(
[00:19] <lifeless> we can freeze landings to devel if needed
[00:24] <mtaylor> lifeless: is there anything I can currently watch to see if if new packages have landed in a ppa?
[00:25] <wgrant> mtaylor: getPublishedSources and getPublishedBinaries
[00:26] <lifeless> mtaylor: e.g. see bzr-builder 's --watch option
[00:26] <lifeless> mtaylor: which may still be in a branch if james_w hasn't merged it yet.
[00:26] <mtaylor> sweet
[01:37] <lifeless> I need a buildout hand
[01:37] <lifeless> I have a project which I want to build its own interpreter for, I don't want it importable by lp.
[01:38] <lifeless> how do I tell lp's buildout to -literally- shell out and buildout that subproject rather than recursing into it and its dependencies
[01:38] <wgrant> lifeless: Probably the 'develop' option.
[01:39] <lifeless> nope
[01:39] <wgrant> Really?
[01:39] <wgrant> Huh.
[01:39] <lifeless> that symlinks the develop egg in
[01:39] <lifeless> so that you can import the thing
[01:39] <lifeless> without it having a versioned egg
[02:13] <mtaylor> lifeless: please tell me you're building a stackless interpreter because you need to
[02:14] <lifeless> mtaylor: I'm not building one; sorry.
[02:14] <mtaylor> lifeless: DAMN
[02:14] <lifeless> mtaylor: I hear that $language de jour will save the world.
[02:15] <lifeless> wgrant: look at the tip of lp:python-gpgfixtures
[02:15] <mtaylor> lifeless: yup
[02:15] <wgrant> Uhoh, plural? This can't be good.
[02:16] <wgrant> lifeless: LP needs to be able to upload too.
[02:18] <lifeless> wgrant: you might think that.
[02:18] <wgrant> We generate keys.
[02:18] <wgrant> And upload them to keyservers.
[02:18] <wgrant> That needs testing.
[02:19] <lifeless> indeed
[02:20] <lifeless> I will not reduce test coverage with what I do.
[02:22] <lifeless> wgrant: the implications of that statement may terrify you. And rightly so.
[02:22] <wgrant> I am wondering what your plan is.
[02:28] <lifeless> ah
[02:28] <lifeless> there is one use of /pks/add in the test suite
[02:28] <wgrant> Not just the test suite.
[02:28] <wgrant> Production code does it too.
[02:29] <lifeless> I know prod does it
[02:29] <lifeless> it looked untested to me
[02:29] <wgrant> Ah
[02:29] <lifeless> see the commented out calls to generateSigningKey, fo rinstance.
[02:30] <wgrant> Ahaha lovely.
[02:30] <lifeless> and the other ones that say 'no key is generated cause we reuse here...'
[02:31] <lifeless> There is one more though, which appears to genuinely exist.
[02:31] <lifeless> but we don't test the error path.
[02:31] <lifeless> so I'll need to add enough glue to pull out the key fingerprint and id and shove them in /keys.
[02:31] <lifeless> but most of our code can diaf
[02:36] <wgrant> Yep.
[02:36] <wgrant> The difficult bit is working out the fingerprint, as you say.
[02:40] <lifeless> there is a gpg parser on pypi
[02:40] <lifeless> but I'll just use a gnupghomefixture for the lifetime of the request + a mutex to avoid os.environ race conditions
[03:12] <LPCIBot> Project db-devel build #822: STILL FAILING in 1 min 53 sec: https://lpci.wedontsleep.org/job/db-devel/822/
[03:12] <mtaylor> lifeless: I haz made patch. simple one-liner with no recipe does what I want now
[03:13] <mtaylor> lifeless: thanks for pointing out the obvious :)
[03:16] <LPCIBot> Project db-devel build #823: STILL FAILING in 0.57 sec: https://lpci.wedontsleep.org/job/db-devel/823/
[03:19] <StevenK> OH! I can land stuff now?
[03:19] <wgrant> 3 hours, OOPS levels around normal, no complaints.
[03:19] <wgrant> Go wild.
[03:33]  * StevenK lands 3 branches in 80 seconds.
[03:33] <StevenK> buildbot gave up waiting after the third and started, strangely enough
[04:03] <wgrant> 35 of our 305 tables are unused or only used by a small bit of unimportant code :(
[04:14] <StevenK> Can we remove some of them?
[04:15] <wgrant> Yeah.
[04:16] <wgrant> Once we have fastdowntime I'll do it.
[04:16] <wgrant> ALthough some of them have ancient data that we should archive.
[04:16] <wgrant> Probably.
[04:27] <stub> wgrant: Which tables are you looking at?
[04:30] <wgrant> stub: http://paste.ubuntu.com/674281/
[04:30] <wgrant> stub: The top list is either entirely unused or only used by person merges.
[04:30] <wgrant> The bottom three are used by things that shouldn't exist any more.
[04:30] <wgrant> And each require deleting like 10 lines of code.
[04:30] <StevenK> Didn't we utterly remove bounties?
[04:31] <stub> The tables have never been purged
[04:32] <stub> wgrant: Nothing there requires archiving.
[04:32] <stub> (that hasn't already been archived, like shipit)
[04:32] <wgrant> k
[04:32] <wgrant> Once we have fastdowntime I will do the honours.
[04:33] <wgrant> Drop foreign keys in one downtime, then remove the merge code, then do away with the tables.
[04:33] <StevenK> wgrant: staticdiff has a *lot* of code associated with it
[04:33] <wgrant> Grar.
[04:33] <wgrant> Except we can't actually drop them with slony, can we?
[04:33] <wgrant> StevenK: It's mostly unused.
[04:33] <wgrant> StevenK: It was for review diffs, but they are dead now.
[04:33] <wgrant> StevenK: It is the hardest of the list to remove, though, right.
[04:34] <StevenK> wgrant: I was told by lifeless to not remove stuff related to that.
[04:34] <wgrant> StevenK: That was incrementaldiff.
[04:34] <StevenK> They aren't related?
[04:34] <StevenK> If they aren't, what's the difference?
[04:34] <wgrant> There are three types of MP diffs.
[04:35] <wgrant> staticdiffs (review diffs), previewdiffs (preview diffs), and incrementaldiffs (incremental diffs)
[04:35] <wgrant> incrementaldiffs are incremental.
[04:35] <wgrant> staticdiffs were from back when you had to run mad to update MP diffs. LP would generate the staticdiff, and it would never change.
[04:35] <wgrant> previewdiffs were what mad generated -- they could update.
[04:35] <StevenK> Can you expand 'mad' ?
[04:35] <wgrant> But now LP updates previewdiffs itself, and I don't believe staticdiffs are used.
[04:35] <wgrant> mad = Merge Analysis Daemon
[04:35] <StevenK> Oh
[04:36] <wgrant> lp:mad
[04:36] <StevenK> Sounds hideous
[04:36] <wgrant> Yes.
[04:36] <StevenK> Right, so I will look at ripping out the use of staticdiff
[04:36] <wgrant> No, it's not in scope :)
[04:37] <wgrant> launchpad_dogfood=# SELECT MAX(date_created) FROM branchmergeproposal WHERE review_diff IS NOT NULL;
[04:37] <wgrant>             max
[04:37] <wgrant> ----------------------------
[04:37] <wgrant>  2010-01-27 08:16:31.060926
[04:37] <StevenK> I'm either blocked on FDT for SPPH-SPN denorm, or working out how to hell to reimplement DSP?
[04:37] <wgrant> StevenK: Have you got the garbo jobs and indices sorted out?
[04:37] <StevenK> For denorm? Yes
[04:37] <wgrant> fdt is probably not going to happen this week.
[04:37] <StevenK> I can't do anything at all with them until the patch lands
[04:38] <StevenK> The branches are up, thanks to the magic of sync-pipeline
[04:38] <wgrant> StevenK: Ah, I saw they were still in Next and assumed they weren't implemented.
[04:38] <StevenK> wgrant: Yes, because I don't want to utterly take over Coding single-handedly when I'm blocked by FDT
[04:39] <StevenK> wgrant: So, I can either remove staticdiff, or we can argue about DSP.
[04:39] <StevenK> Personally, the former sounds a little more fun
[04:39] <wgrant> We need to sort out DSP in the next week or so.
[04:40] <StevenK> Except I'm on holidays next week ...
[04:40] <wgrant> Ah, forgot that bit.
[04:40] <wgrant> And so is Curtis.
[04:40] <StevenK> Yes.
[04:40] <wgrant> So I guess we won't be pushing the in-progress stuff too hard.
[04:40] <StevenK> wgrant: So, which of the two do you to tackle?
[04:41] <StevenK> wgrant: Do you want to have a friendly argument about DSP?
[04:41] <wgrant> StevenK: Do you have a list of uses of DSP and DSPID?
[04:41] <StevenK> I do
[04:42] <StevenK> The only thing that's stopped me writing stuff up is a name for the new hotness
[04:42] <wgrant> Hm, pad.ubuntu.com looks sadly UDS-specific.
[04:43] <StevenK> -> tea
[04:49] <wgrant> StevenK: http://pad.ubuntu.com/cWLmLex2tc
[04:49] <wgrant> StevenK: Where a caller is listed for something, that is all of the callers.
[04:49] <wgrant> (apart from the maintenance methods, which are moving onto the classes themselves in ec2 now)
[04:50] <nigelb> oooh, we deployed. Nice :)
[04:50] <StevenK> wgrant: I don't have a list of callers, but I suspect they are numerable
[04:50] <wgrant> nigelb: Yup. Your code works, too!
[04:51] <StevenK> wgrant: Added my notes
[04:51] <nigelb> \o/
[04:52] <wgrant> nigelb: Got any more 4 digit bug fixes?
[04:53] <nigelb> wgrant: If they're relatively easy to fix, I'm interested.
[04:54] <wgrant> That doesn't sound like an adequate sense of adventure.
[04:54] <nigelb> THat's making sure I can fix them in a lifetime.
[04:55] <nigelb> Let me see if I can get into top-5 list in this week.
[04:55] <nigelb> 5 more bugs to fix to get there.
[04:55] <wgrant> Just two more merges, IIRC.
[04:55] <wgrant> 1 more will bring you to equal 5th place.
[04:55] <nigelb> ooh. 2 more. Interesting.
[04:56] <wgrant> Sadly, 127 more are required to bring you to 1st place.
[04:56] <nigelb> Yeah.
[04:56] <nigelb> That's hard, but not undoable.
[04:56] <nigelb> A fix per week for 2+ years.
[04:59] <nigelb> hmm, what needs to be done for bug 50661
[04:59] <_mup_> Bug #50661: Magic words in comments (e.g. bug NNNN) should be documented <docs> <easy> <lp-web> <ui> <Launchpad itself:Triaged by matthew.revell> < https://launchpad.net/bugs/50661 >
[04:59] <nigelb> I could just take stuff documented in one of the doctests that I boke.
[05:00] <nigelb> *broke
[05:01] <StevenK> wgrant: Where's this list of top-5?
[05:01] <nigelb> https://dev.launchpad.net/Contributions
[05:01] <StevenK> Ah, nice
[05:05] <nigelb> woah, bug 811028 is easy? Lies!
[05:05] <_mup_> Bug #811028: Time frame 'a moment ago' incorrectly concatenated  to 'on' <easy> <ui> <Launchpad itself:Triaged> < https://launchpad.net/bugs/811028 >
[05:06] <StevenK> Bleh
[05:06] <wgrant> sinzui fixed something like that for questions in the last deployment.
[05:06] <StevenK> Yeah, looks like I missed a spot
[05:07] <StevenK> That's registration of product etc, isn't it?
[05:07] <wgrant> It says bug.
[05:07] <wgrant> But bugs are fine.
[05:07] <wgrant> I think...
[05:07] <nigelb> bah.
[05:07] <wgrant> Oh, it uses fmt:displaydate.
[05:07] <StevenK> And bugs say 'Reported by ...'
[05:08] <wgrant>     def displaydate(self):
[05:08] <wgrant>         delta = abs(self._now() - self._datetime)
[05:08] <wgrant>         if delta > timedelta(1, 0, 0):
[05:08] <wgrant>             # far in the past or future, display the date
[05:08] <wgrant>             return 'on ' + self.date()
[05:08] <wgrant>         return self.approximatedate()
[05:08] <StevenK> Right
[05:09] <lifeless> stub: are you actually here, or just caffeinating ?
[05:09] <stub> I'm here
[05:09] <StevenK> approximatedate() returns a moment ago for =< 10
[05:09] <lifeless> care to have a brief catchup now ?
[05:09] <nigelb> wgrant: that means its fixed, right?
[05:09] <stub> lifeless: sure
[05:09]  * stub fires up skype
[05:10] <wgrant> nigelb: Not necessarily.
[05:10] <wgrant> Should test...
[05:10] <nigelb> I hope qastaging doesn't timeout for me again.
[05:10] <lifeless> bwahaha
[05:10] <nigelb> well, in the first 5 tries.
[05:10] <wgrant> Reported by William Grant a moment ago
[05:10] <nigelb> hah
[05:11] <StevenK> Looks fine to me
[05:11] <wgrant> Registered a moment ago by William Grant
[05:11] <wgrant> Projects are fine too.
[05:11] <nigelb> what else? blueprints and answers?
[05:12] <StevenK> Uploads?
[05:12] <lifeless> commits ?
[05:12] <wgrant> Asked by William Grant a moment ago
[05:12] <wgrant> Questions are fine now too.
[05:12] <lifeless> wgrant: add support pushed
[05:12] <wgrant> Registered by William Grant on a moment ago
[05:12] <StevenK> lifeless: I seriously doubt commits make use of approximatedate
[05:12] <wgrant> Blueprints are bad.
[05:13] <StevenK> Text?
[05:13] <lifeless> wgrant: supports more keys which I think real keyservers do too :P
[05:13] <nigelb> ah, blueprints are broken, yes.
[05:13] <StevenK> Can haz paste?
[05:13] <lifeless> wgrant: in general, or in principle?
[05:13] <wgrant> nigelb: Want to clarify that in the bug and fix?
[05:13] <wgrant> lifeless: Heh.
[05:13] <StevenK> In this case
[05:13] <nigelb> Registered by Nigel Babu on a moment ago
[05:13] <nigelb> wgrant: yup, fixing in a bit.
[05:13] <StevenK> That might be what the reporter actually meant
[05:14] <wgrant> I presume so.
[05:14] <wgrant> It's the only object I've found that uses that dext.
[05:14] <nigelb> Possibly, blueprints is the unloved child.
[05:14] <wgrant> Projects use "Registered", but put the name at the end.
[05:14] <nigelb> I should careful that I don't end up owning it with 5 of my 6 fixes in blueprint I think.
[05:15] <StevenK> Bwahah
[05:16] <nigelb> *be careful
[05:23] <StevenK> wgrant is going to not like me.
[05:23] <StevenK> % bzr di | diffstat -s
[05:23] <StevenK>  14 files changed, 11 insertions(+), 335 deletions(-)
[05:23] <nigelb> did you remove more tests?
[05:23] <wgrant> StevenK: StaticDiff?
[05:24] <StevenK> wgrant: Yah
[05:24] <wgrant> StevenK: What did you do with the review_diff fkey on BMP? a few things still seemed to use it.
[05:24] <wgrant> I'm not sure they used it for anything.
[05:24] <wgrant> But they used it.
[05:24] <StevenK> I binned it
[05:26] <wgrant> Ah, it was just constructors.
[05:26] <wgrant> Easier than I expected.
[05:27] <StevenK> I have missed stuff, though
[05:28] <StevenK> Right
[05:28] <StevenK> Now to fish around in sampledata
[05:29] <nigelb> Hrm, need to learn to read configure.zcml better.
[05:30] <StevenK> nigelb: Don't. Your eyes will bleed.
[05:30] <StevenK> wgrant: The only I can't work out what to do with is lib/lp/codehosting/tests/test_jobs.py
[05:30] <nigelb> StevenK: I'm submitting MP's to LP, one should assume that they've already started bleeding.
[05:31] <StevenK> nigelb: But XML means the wounds can not be cauterised
[05:31] <nigelb> heh
[05:37] <nigelb> so, I see tal:content="context/bug/datecreated/fmt:displaydate"
[05:38] <nigelb> where do I look to see the code behind it?
[05:38] <wgrant> StevenK: Erm. It looks like RevisionMailJobs use StaticDiff, but apparently they don't stay around in the DB...
[05:38] <nigelb> or rather, how do I figure out where to look.
[05:38] <wgrant> In fact, they never hit the DB.
[05:38] <StevenK> wgrant: That's disappointing
[05:38] <wgrant> nigelb: lib/lp/app/browser/tales.py
[05:39] <nigelb> ooh, thanks
[05:40] <wgrant> StevenK: Nothing has been added to the table since January last year, as expected. But it looks like RevisionMailJobs should be calling StaticDiff.acquire, which instantiates and returns a StaticDiff.
[05:40] <wgrant> And StaticDiff inherits SQLBase, so that should automatically add it to the DB.
[05:41] <StevenK> Perhaps the commit gets dropped
[05:41] <wgrant> The sequence should still be incremented, though, right?
[05:41] <wgrant> Unless it gets reset on DF.
[05:44] <StevenK> wgrant: So I wonder if I we should fix RMJ to use previewdiff?
[05:45]  * nigelb is gettign "chmod: changing permissions of `/var/tmp/bazaar.launchpad.dev/rewrite.log': Operation not permitted"
[05:46] <wgrant> nigelb: Apache creates that sometimes, so it ends up owned by root or www-data.
[05:46] <wgrant> nigelb: sudo chown it.
[05:46] <nigelb> wgrant: chown to my user or apache user?
[05:47] <wgrant> nigelb: Yours.
[05:47] <nigelb> ah
[05:48] <StevenK> It even calls transaction.commit()! WTF
[05:48] <wgrant> StevenK: Yes.
[05:48] <wgrant> It makes very little sense.
[05:49] <wgrant> Instantiating a StaticDiff must not add it to the store.
[05:49] <wgrant> (the commit is necessary because the diff is stored in the librarian)
[05:49] <StevenK> Ah, I bet that is the issue
[05:49] <StevenK> It isn't added to the store
[05:50] <wgrant> SQLBase does that automatically, normally.
[05:50] <wgrant> >>> from lp.code.model.diff import StaticDiff
[05:50] <wgrant> >>> StaticDiff()
[05:50] <wgrant> <StaticDiff at 0x8382410>
[05:50] <wgrant> >>> transaction.commit()
[05:50] <wgrant> Traceback (most recent call last):
[05:50] <wgrant> IntegrityError: null value in column "from_revision_id" violates not-null constraint
[05:53] <nigelb> gah, I broke it. I can't read tal.
[05:53] <StevenK> Ah. No wonder I can't find it. My branch removes it.
[05:54] <nigelb> can someone spare a few minutes to explain how this works? I think I have no clue what I'm doing.
[05:55] <StevenK> nigelb: Pastebin your diff
[05:55] <StevenK> nigelb: bzr di | utilites/paste # if your friend
[05:55] <nigelb> StevenK: I don't have a diff
[05:55] <nigelb> because I don't know what to diff on.
[05:55] <nigelb> :(
[05:56]  * nigelb pastbin's broken diff
[05:56] <nigelb> http://pastebin.ubuntu.com/674302/
[05:57] <nigelb> I brain-deadly pasted what works for answers. Which I now realize is wrong.
[05:57] <wgrant> Erm, that was from answers?
[05:58] <nigelb> yeah
[05:58] <wgrant> +        tal:attributes="title context/bug/datecreated/fmt:datetime"
[05:58] <wgrant> bug?
[05:58] <nigelb> baaah
[05:58] <wgrant> I wonder if sinzui stole that from Bugs.
[05:58] <nigelb> no
[05:58] <nigelb> my bad
[05:58] <nigelb> messed up paste :|
[05:59] <wgrant> StevenK: Ha ha ha.
[05:59] <nigelb> oh lol
[05:59] <nigelb> Now I have on 10 minutes ago
[05:59] <StevenK> wgrant: Hm?
[06:00] <nigelb> Okay, so current diff http://pastebin.ubuntu.com/674304/
[06:01] <wgrant> StevenK: http://paste.ubuntu.com/
[06:01] <wgrant> Er.
[06:01] <wgrant> Bah, wants a name.
[06:01] <wgrant> Nasty creature.
[06:01] <wgrant> http://paste.ubuntu.com/674305/
[06:01] <wgrant> Note that it ran a REVISIONS_ADDED_MAIL job, not a REVISION_MAIL job.
[06:01] <wgrant> I wonder if REVISION_MAIL is unused.
[06:02] <wgrant> Code seems to be full of dead code.
[06:03] <wgrant> Oh dear.
[06:03] <wgrant> StevenK: lib/lp/codehosting/scanner/email.py +55
[06:04] <wgrant> StevenK: If it's not an initial scan, it uses REVISIONS_ADDED_MAIL
[06:04] <wgrant> StevenK: If it is an initial scan, it uses REVISION_MAIL, but disables diff generation.
[06:04] <StevenK> Haha
[06:04] <wgrant> So I think all that code is actually unused.
[06:04] <wgrant> But grepping harder.
[06:05] <wgrant> All the callsites I can see set perform_diff=False.
[06:05] <wgrant> And we've seen there have been none in the DB for more than 18 months.
[06:05] <wgrant> I think we can be fairly confident it's dead, but we should check with Aaron.
[06:05] <StevenK> wgrant: http://pastebin.ubuntu.com/674308/
[06:05] <wgrant> StevenK: Care to remove perform_diff from RevisionMailJob, delete that remaining test, and send it off to ec2 test?
[06:06] <wgrant> Note that we can't drop the table yet.
[06:06] <wgrant> But do revoke perms.
[06:07] <wgrant> So, test_jobs.py can be deleted.
[06:08] <StevenK>  17 files changed, 12 insertions(+), 415 deletions(-)
[06:08] <wgrant> All the revno/diff handling from RevisionMailJob can go.
[06:08] <StevenK> Even revno?
[06:08] <wgrant> The only revnos passed in are 'removed' and 'initial'. The int stuff can go.
[06:09] <wgrant> So drop the if/else in create(), drop the perform_diff argument, and delete most of getMailer.
[06:09] <StevenK> Already done
[06:09] <wgrant> Just passing None as diff_text instead.
[06:09] <StevenK> Done that too
[06:09] <wgrant> Does that leave BranchDiffJob unused/
[06:10] <nigelb> StevenK: got a chance to look at the diff?
[06:10] <wgrant> Seems to.
[06:10] <StevenK> No, it is still RMJ's parent, and it calls .getMetadata
[06:10] <wgrant> StevenK: RMJ has no cause to use it any more.
[06:11] <StevenK> Oh, the update can probably DIAF too
[06:11] <wgrant> StevenK: Since it's not generating diffs, it doesn't need the metadata.
[06:11] <wgrant> It has no revno any more, remember.
[06:11] <StevenK> """A Job that calculates the a diff related to a Branch."""
[06:11] <nigelb> ok, so what's the difference beteen tal:attributes and tal:content?
[06:11]  * StevenK smirks
[06:12] <wgrant> Heh.
[06:12] <StevenK> Not any more it don't.
[06:12] <wgrant> nigelb: tal:content sets the value inside the element. attributes sets attributes on it.
[06:12] <StevenK> wgrant: """A Job that sends a mail for an initial scan of a Branch."""
[06:12] <wgrant> StevenK: Or scans where revisions are removed.
[06:13] <nigelb> hah. Nailed it!
[06:13] <StevenK> ... for a scan of a Branch
[06:13]  * nigelb wonders how many tests he broke
[06:13] <wgrant> nigelb: <a tal:attributes="href context/owner/fmt:link" tal:content="context/owner/displayname" /> will turn into <a href="/~wgrant">William Grant</a>
[06:13] <nigelb> wgrant: AH!
[06:14] <nigelb> okay, now I understand what the code in answerws is doing
[06:14] <nigelb> Except for this bit
[06:14] <wgrant> tal:replace replaces the element entirely.
[06:14] <nigelb>         <span
[06:14] <nigelb>           tal:attributes="title context/datecreated/fmt:datetime"
[06:14] <nigelb>           tal:content="context/datecreated/fmt:displaydate">2005-10-05</span>
[06:14] <wgrant> So '<a tal:attributes="href context/owner/fmt:link" tal:replace="context/owner/displayname" />' just turns into 'William Grant'
[06:14] <nigelb> what is that 2005-10-05 doing there?
[06:14] <wgrant> nigelb: That's just a default value. If, say, someone views the template in a web browser directly.
[06:15] <wgrant> tal:content replaces any existing content.
[06:15] <nigelb> ah, that gets replaced by tal:content
[06:15] <nigelb> ok, I understand this beast better.
[06:15] <wgrant> StevenK: Up to -500 yet?
[06:16] <nigelb> Also, if I do a "bin/test lp.blueprints" does it run doctests as well?
[06:16] <StevenK> nigelb: It probably will, yes
[06:16] <wgrant> nigelb: Probably.
[06:16] <wgrant> nigelb: Some are a bit special.
[06:16] <wgrant> But I think it should get all the blueprint ones.
[06:16] <nigelb> I'll let the special ones be caught by ec2 land.
[06:17] <StevenK> wgrant: No, sadly.
[06:17] <wgrant> StevenK: Pick random lines of code to delete until you meet the quota.
[06:17] <StevenK> Bwahah
[06:17] <nigelb> heh
[06:17] <nigelb> rm -r blueprints will get you a long way and make wgrant a happy man.
[06:30] <StevenK>  19 files changed, 31 insertions(+), 483 deletions(-)
[06:30] <StevenK> But the diff is 1,000 lines
[06:30] <nigelb> find 7 more lines to delete?
[06:31] <StevenK> That's only 490! FAIL
[06:31] <nigelb> bah, 17 more!
[06:31] <StevenK> Math fail
[06:31] <nigelb> ok, not test failure in blueprints.
[06:31]  * nigelb proposes MP
[06:33] <StevenK> steven@liquified:~/launchpad/lp-branches/no-more-staticdiff% bzr log -r -1.. | tail -n 1
[06:33] <StevenK>   Consign StaticDiff and all that supported it to a watery grave.
[06:34] <wgrant> bzr log --line -r-1
[06:34] <nigelb> hm, why does make lint error out...
[06:34] <nigelb> bzr: ERROR: unknown command "pipes"
[06:34] <nigelb> am I missing a bzr plugin?
[06:34] <StevenK> You are
[06:34] <wgrant> It should work OK without it, though.
[06:34] <StevenK> wgrant: Beh
[06:35] <StevenK> wgrant: That doesn't quite work
[06:35] <StevenK> % bzr log -r-1 --line
[06:35] <StevenK> 13780: Steve Kowalik 2011-08-25 Consign StaticDiff and all that supported it...
[06:35] <wgrant> Bah.
[06:36] <StevenK> cjwatson: You should just need to merge devel into your xz branch and get it re-tossed at ec2
[06:37]  * wgrant does that locally.
[06:38] <StevenK> I hope the image works
[06:43] <nigelb> lifeless: Could you review? https://code.launchpad.net/~nigelbabu/launchpad/811028-time-frame/+merge/72831
[06:44] <nigelb> I wonder if he's OTP
[06:45] <wgrant> Or EOD.
[06:45] <wgrant> Given that he starts at 0645 on Thursdays.
[06:45] <nigelb> ooh.
[06:45] <nigelb> wgrant: Could spare a few minutes to review in that case?
[06:46] <wgrant> nigelb: Do you know what existing tests there are for this?
[06:46] <nigelb> wgrant: No, I don't
[06:46] <nigelb> I ran the tests for blueprints and none seem to have failed
[06:46] <wgrant> It would be nice to add one to check that it doesn't say "on a moment ago"
[06:47] <nigelb> hm, use factory? ;)
[06:47] <nigelb> :)
[06:47] <wgrant> Yeah. Create a blueprint using the factory, then render the view and check that text.
[06:47] <nigelb> okay
[06:47] <nigelb> I may need help for some part of it, but let me get there.
[06:48] <wgrant> Sure.
[06:48] <wgrant> It will be short, and good practice :)
[06:52] <nigelb> How do I check if a certain content exists in a view?
[06:52] <nigelb> I've done this before but I now forget.
[06:54] <wgrant> html = create_initialized_view(someobj, '+index')()
[06:54] <wgrant> self.assertIn('some string', html)
[06:54] <StevenK> And self.assertNotIn()
[06:55] <StevenK> And branch just got tossed out of ec2 in the make stage
[06:55]  * StevenK pouts
[06:55] <wgrant> What happened?
[06:56] <StevenK> Disagreement between the code and ZCML, I think
[06:56]  * StevenK will look when he gets home
[06:58] <nigelb> StevenK: are you not working from home?
[06:58] <nigelb> co-working place?
[07:03] <nigelb> wgrant: added test and pushed
[07:06] <wgrant> nigelb: That test will only fail if html is a substring of 'on a moment ago', which doesn't seem hugely likely.
[07:06] <wgrant> I'd do this:
[07:07] <nigelb> actually, GAH
[07:07] <nigelb> It will never fail.
[07:08] <wgrant> You should probably use extract_text.
[07:08] <nigelb> because I just realized the span's title attribute will be the time_stamp
[07:08] <wgrant> Otherwise you'll get the <span> and stuff, yeah.
[07:08] <wgrant> extract_text() will remove all that.
[07:08] <nigelb> ah, ok
[07:09] <wgrant> self.assertIn("a moment ago", extracted_text)
[07:09] <wgrant> self.assertNotIn("on a moment ago", extracted_text)
[07:09] <wgrant> Maybe.
[07:10] <wgrant> Possibly better to use extract_text and then assertTextMatchesExpressionIgnoreWhitespace, though.
[07:10] <wgrant> Since there are newlines in the string.
[07:10] <nigelb> okay
[07:10] <wgrant> cjwatson: Your branch seems to be in ec2 happily enough.
[07:10] <wgrant> Hopefully for the last time.
[07:11] <nigelb> whats the false test for assertTextMatchesExpressionIgnoreWhitespace?
[07:12] <wgrant> There isn't one. So I'd just test the whole "Registered by Foo Bar a moment ago" string.
[07:12] <nigelb> mm, so create a person too?
[07:13] <wgrant> self.factory.makeSpecification(registrant=self.factory.makePerson(displayname="Some Person"))
[07:13] <wgrant> Or something like that.
[07:13] <nigelb> okay
[07:50] <adeuring> good morning
[07:53] <nigelb> hm, where does extract_text live?
[07:55] <nigelb> nvm, found it
[08:08] <mrevell> Mornin'
[08:08] <wgrant> Morning mrevell, and congrats!
[08:08] <nigelb> Morning mrevell
[08:09] <mrevell> Thanks :)
[08:09] <nigelb> wgrant: the assertTextMatchesExpressionIgnoreWhitespace does not work.
[08:09] <wgrant> nigelb: :( why not?
[08:09] <wgrant> Apart from having an obscene name.
[08:09] <nigelb> Says, not found
[08:09] <wgrant> Have you printed it out to see what it really looks like?
[08:09] <nigelb> Can I manually add the /n and test with AssertIn instead?
[08:10] <nigelb> I don't know what assertTextMatchesExpressionIgnoreWhitespace looks like but I now know what the output of extracted_text looks like.
[08:12] <wgrant> lib/lp/testing/__init__.py has that method.
[08:14] <nigelb> oh.
[08:14] <nigelb> regular expression
[08:15]  * nigelb lunches
[08:21] <bigjools> morning
[08:26] <cjwatson> wgrant: I can dream.  Thanks.
[08:29] <wgrant> cjwatson: (it failed due to probable AWS breakage, but is back in again)
[08:32] <wgrant> No, AWS being flaky again. Can't connect to the second instance.
[08:32] <wgrant> Yay
[08:32] <lifeless> nigelb: partly EOD partly debugging a u1 pqm issue with spm, partly cooking dinner
[08:32] <lifeless> nigelb: you might prefer assertThat(foo, DocTestMatches(bar))
[08:33] <wgrant> Ah, forgot about that one.
[08:34] <lifeless> optionally with ,ELLIPSIS in the doctestmatches constructor
[08:35] <wgrant> I wish the API didn't encourage putting everything on the model objects.
[08:41] <jml> wgrant: +1
[08:42] <wgrant> I guess it's not really lazr.restful.
[08:42] <wgrant> We can expose *Set perfectly well.
[08:42] <wgrant> But security has to be done manually.
[08:43] <wgrant> Maybe we want a custom zope.security checker to make that sort of thing easier.
[08:43] <wgrant> Decorate methods with the context argument and permission, or something.
[08:50] <jml> wgrant: well, I also think that *Set objects are mostly a waste of time too.
[08:53] <wgrant> jml: Mostly.
[08:53] <wgrant> The security benefits are just about nil, so I tend to just try to sneak static methods through reviews nowadays..
[08:54] <wgrant> Or even functions.
[08:54] <wgrant> Zope seems to treat Python like Java :(
[08:55] <jml> functions.... wuuuu....
[08:55]  * jml likes functions
[08:55] <jml> the utility stuff might be useful for cases where you want to sub out a utility for something that has the same interface
[08:55] <wgrant> But API methods need to be on a *Set or model object, and people lean to putting stuff on model objects, which means you end up with Distribution having more than 200 lines of imports from every LP package.
[08:55] <nigelb> lifeless: ah, thanks :)
[08:56] <jml> but I don't see us doing it aynwhere
[08:56] <jml> wgrant: yeah. makes it hard to separate stuff.
[08:56] <wgrant> Rather than having, say, getPendingAcceptancePPAs on ArchiveSet, where it belongs.
[08:56] <jml> although sometimes it seems as if lifeless says that it ought to be like that
[08:57] <jml> grumbles about special type-based checking for PPAs aside
[08:57] <wgrant> Heh.
[08:58] <wgrant> I think lifeless is mainly against arbitrary divisions and siloization.
[08:58] <wgrant> This is just proper layering.
[08:58] <wgrant> And separation.
[09:09] <nigelb> wgrant: doing the DocTestMatches compares it to the HTML directly.
[09:09] <nigelb> should I be doing a extract_text before that?
[09:10] <wgrant> nigelb: Probably, yeah.
[09:10] <wgrant> Most doctests use extract_text if there are spans and stuff involved.
[09:10] <nigelb> I knew this bug fix was way too easy.
[09:10] <nigelb> Hence the tests are challenging.
[09:11] <wgrant> You learn how to do them after a while.
[09:11] <wgrant> Well, you learn where to look and how to grep for similar ones.
[09:11] <wgrant> Then you look at how they do it :)
[09:11] <wgrant> And try to work out whether they are best practice from now, or worst practice from 2005.
[09:11] <nigelb> heh
[09:12] <bigjools> SoupMatcher FTW
[09:12] <bigjools> grep for it
[09:19] <wgrant> Or I guess lazr.restful adapter support would solve lots of this as well.
[09:20] <wgrant> lifeless: Any reason gpgfixtures can't replace zeca tomorrow?
[09:23] <nigelb> bigjools: no results.
[09:23] <nigelb> I only looked in lib/lp though.
[09:23]  * bigjools finds example
[09:24] <wgrant> nigelb: soupmatchers
[09:24] <wgrant> It's a module.
[09:24] <wgrant> containing various matchers like Tag, HTMLContains
[09:24] <bigjools> nigelb: look here: lib/lp/soyuz/browser/tests/test_publishing.py
[09:24] <bigjools> grep soupmatchers
[09:24] <nigelb> hah, I grepped for SoupMatcher
[09:24] <bigjools> also look in lib/lp/registry/browser/tests/test_distroseriesdifference_views.py
[09:24] <bigjools> nigelb: sorry, my bad
[09:25] <nigelb> :)
[09:26] <nigelb> How evil is line 26 in https://code.launchpad.net/~nigelbabu/launchpad/811028-time-frame/+merge/72831
[09:28] <bigjools> fairly
[09:28] <nigelb> sigh, I gussed as much
[09:29] <nigelb> bigjools: I can't use soup matcher because I need to extract the text.
[09:29] <bigjools> you could use DocTestMatches if whitespace is not a concern
[09:29] <nigelb> whitespace isn't a concern
[09:29] <bigjools> soup matcher extracts text
[09:29] <nigelb> maybe I should look up how doctestmatches is used.
[09:29] <bigjools> you just need to grab the right tag
[09:29] <bigjools> some tests use a div with an id just for that
[09:29] <nigelb> hmm
[09:30] <wgrant> In this case you can hopefully just pick out the registering slot.
[09:30] <nigelb> but I get the fugly span bits
[09:30] <nigelb> which I don't want
[09:30] <wgrant> With soupmatcher?
[09:30] <bigjools> soupmatchers is powerful but the syntax is a bit awkward
[09:31] <nigelb> wait, soupmatches solves the fugly span problem too?
[09:31]  * nigelb tries
[09:31] <bigjools> if the text is all in that tag, yes
[09:32] <nigelb> Its sadly, not.
[09:32] <nigelb> which is why I wrote that evil code
[09:32] <bigjools> ah
[09:32] <bigjools> I'd go for DocTestMatches then
[09:33] <bigjools> http://readthedocs.org/docs/testtools/en/latest/for-test-authors.html#matchers
[09:33] <wgrant> If you use extract_text, then you shouldn't need ELLIPSIS.
[09:33] <wgrant> Just a default DocTestMatches should do.
[09:33] <bigjools> yup
[09:34] <nigelb> doctests returns everything one below the other
[09:34] <nigelb> *doctestmatches
[09:34] <nigelb> isn't that similar to simply using extract_text?
[09:34] <bigjools> use both
[09:35] <nigelb> Ah.
[09:35] <bigjools> it solves your nasty use of \n
[09:35] <nigelb> :D
[09:35] <wgrant> Because doctests are... slightly liberal with whitespace.
[09:35] <wgrant> (hi gina)
[09:35] <bigjools> grrr
[09:35] <nigelb> gina?
[09:35] <bigjools> I fixed that recently
[09:36] <bigjools> gina is the archive importer
[09:36] <nigelb> ah
[09:36] <LPCIBot> Project devel build #992: STILL FAILING in 6 hr 5 min: https://lpci.wedontsleep.org/job/devel/992/
[09:44] <nigelb> I.. I'm confused.
[09:44] <nigelb> http://paste.ubuntu.com/674407/
[09:44] <nigelb> I'm doing things wrong, but I can't figure out what's right.
[09:46] <jml> nigelb: other way around
[09:46] <jml> nigelb: assertThat(extract_html(thing), DocTestMatches("... foo ...", doctest.ELLIPSIS))
[09:46] <jml> also probably doctest.ELLIPSIS | doctest.NDIFF
[09:47] <nigelb> ah
[09:49] <jml> nigelb: as a rule, assertThat(observed, Matches(expected))
[09:49] <LPCIBot> Project db-devel build #824: STILL FAILING in 6 hr 5 min: https://lpci.wedontsleep.org/job/db-devel/824/
[09:53] <nigelb> jml: I'm still doing something wrong. The test is failing with http://paste.ubuntu.com/674413/
[09:55] <jml> nigelb: well, yeah, but now it's failing *properly*
[09:55] <nigelb> haha
[09:56] <wgrant> Unless you extract the registering slot using BeautifulSoup, you'll need to wrap your match string in ellipsis.
[09:56] <nigelb> I couldn't parse that.
[09:56] <wgrant> Append and prepend '...' to your match string.
[09:56] <nigelb> ah
[09:57] <lifeless> wgrant: jml: yes, siloisation -1, layering +1.
[09:58] <nigelb> argh!http://paste.ubuntu.com/674417/
[10:01]  * nigelb fails at seeing what's going wrong.
[10:01] <jelmer> anybody up for a review of a small refactoring?
[10:01] <wgrant> It does default to NORMALISE_WHITESPACE, doesn't it?
[10:04] <nigelb> wgrant: ok, got it. I should have just followed the instructions on the testtools manual ^-^
[10:06] <nigelb> wgrant: commited and pushed, could you review? :)
[10:07] <jml> wgrant: I don't think so, actually.
[10:08] <jml> wgrant: have been tempted to add a version that has normalize, ellipsis & report_ndiff as standard
[10:08] <nigelb> jml: It does't, I had to add that.
[10:12] <wgrant> nigelb: That test looks much better, thanks! Just two tiny things left.
[10:12] <wgrant> nigelb: Your find_tag_by_id and extract_text imports are around the wrong way; they should be sorted alphabetically.
[10:12] <wgrant> And test_time_frame is probably not a great test name.
[10:13] <wgrant> test_registration_date_displayed, possibly.
[10:13] <nigelb> okay, fixing
[10:14] <nigelb> Fixed!
[10:17] <wgrant> nigelb: Sorry, one further thing I missed: the testtools import is in the LP section, but it should be in the third-party library section (with lazr.*)
[10:17] <wgrant> Apart from that, looks ready for ec2.
[10:19] <lifeless> wgas for gpgfixtures, I have a branch using the homedir fixture, not the keyserver itself yet
[10:19] <lifeless> wgrant: ^
[10:19] <lifeless> wgrant: *as for...
[10:19] <wgrant> lifeless: Aha.
[10:19] <lifeless> wgrant: I probably won't finish the migration, but it should be a superset of the facilities we need now.
[10:19] <wgrant> I may look at that in your absence.
[10:19] <lifeless> the main thing will be finding tests that assume the server is pre-seeded with all keys and have them seed it with the keys they need
[10:20] <wgrant> Yep.
[10:20] <lifeless> using the json api
[10:20] <wgrant> A good thing to do anyway.
[10:20] <lifeless> wwhat else
[10:20] <lifeless> oh, we need a fixture to either a) bring up the server in the test process as a thread or b) bring it up as a child process and read-back the port its on; either way shove that into the live config
[10:20] <lifeless> shallow stuff
[10:21] <wgrant> I think we're going to need to rework lazr.config soon.
[10:21] <lifeless> nn
[10:21] <wgrant> Night.
[10:22] <nigelb> wgrant: done
[10:29] <wgrant> nigelb: approved. Should I send it off to ec2?
[10:29] <nigelb> wgrant: yes, please :)
[10:30] <wgrant> nigelb: Could you set a commit message on the MP?
[10:32] <nigelb> set
[10:33] <wgrant> nigelb: Instance starting.
[10:33] <nigelb> okay, I'll watch my email ~4 hours from now
[10:34] <wgrant> nigelb: AWS has been a bit flaky this evening, so it might fail, but we'll see.
[10:35] <nigelb> oh, ouch. okay.
[10:35] <wgrant> I've had two instances not start, another one not be connectable, and two die with block device errors.
[10:35] <nigelb> ah, aws b0rks?
[10:35] <wgrant> I can only assume.
[10:35] <nigelb> lol. I deal with it everyday at day job :)
[10:36] <nigelb> we had one instance disappear taking all the data with it.
[10:36] <nigelb> It was a backup instance, but got everyone jolted awake ^-^
[10:36] <wgrant> The instance has started, at least.
[10:36] <nigelb> what region?
[10:38] <wgrant> nigelb: us-east
[10:38] <nigelb> hehe, same as us :D
[10:46] <nigelb> bigjools: My dislike for bling and shiny is one of the reasons I haven't upgraded :D
[10:46] <nigelb> Xubuntu is probably where I'm headed when I upgrade
[10:46] <jelmer> wgrant: hmm, deployment hasn't happened to the code importds?
[10:47] <jelmer> It's a bit confusing that the related bugs are still marked as fixreleased
[10:48] <wgrant> jelmer: It should have.
[10:48] <wgrant> But I saw the failures, and wondered when you'd ask me :P
[10:49] <wgrant> mthaddon: Could you confirm that the importds are in nodowntime and running the latest rev?
[10:49] <wgrant> hloeung said they were, but it seems not.
[10:50] <nigelb> At UDS, I saw this guy in a Launchpad T-shirt and asked him  "Are you a Launchpad guy? Could you help us?
[10:50] <nigelb>  and proceeded to ask something about blueprints API
[10:51] <nigelb> Later, I realized that was flacoste :)
[10:51] <wgrant> Haha
[10:52] <mthaddon> wgrant: they're running 13697 and are in ndt
[10:52] <wgrant> Erm.
[10:52] <wgrant> ndt is 13779 :/
[10:52] <mthaddon> interesting...
[10:52] <wgrant> Rather!
[10:54] <mthaddon> I'll update them now, suspect this is because one of the importd servers (galapagos) is dead and hadn't been removed from the list
[10:54] <jtv> Anyone else getting a failure in test_versioninfo, caused by revno being a string instead of an int?
[10:54] <wgrant> Yeah.
[10:54] <bigjools> nigelb: luddite!
[10:54] <wgrant> I thought the deployment was a bit quick today.
[10:54] <wgrant> mthaddon: Is it easy enough to check the rest of ndt?
[10:54] <mthaddon> wgrant: yep, will do once that's finished
[10:55] <mthaddon> wgrant: also I think we should add a step at the end of NDT to confirm revnos on all the servers we've deployed to (I'll do that)
[10:55] <nigelb> bigjools: I prefer stable and working over bleeding edge
[10:57] <wgrant> mthaddon: Indeed, that would be helpful.
[10:57] <wgrant> Thanks.
[10:57] <wgrant> It would be nice if there was a list of what's running what.
[10:58] <bigjools> +1
[11:00] <mthaddon> wgrant: devpad:/srv/launchpad.net-logs/code_check
[11:01] <wgrant> Oh. That's a bit perfect.
[11:01] <wgrant> Has that always been there?
[11:01] <mthaddon> yep
[11:01] <wgrant> Yes, for 3.5 years.
[11:01] <mthaddon> one of the best kept secrets of LP
[11:01] <wgrant> Does that check all the deploymgr trees?
[11:02] <wgrant> bilimbi's on there, so it seems reasonably up to date.
[11:02] <mthaddon> yep, it does all
[11:02] <bigjools> nice!
[11:02] <wgrant> Very tempting to fix sourcedeps.cache.
[11:02] <mthaddon> https://pastebin.canonical.com/51693/
[11:03] <wgrant> This should probably be mentioned on LPS or something.
[11:03] <mthaddon> good idea - feel free to add it somewhere that seems relevant
[11:04] <wgrant> Ah, it only runs daily?
[11:04] <mthaddon> yep
[11:04] <jtv> Anyone know what the current "versioninfo" buildbot failure is about?
[11:05] <wgrant> I guess it should probably trigger after each deploy, as you said earlier, I guess.
[11:05] <wgrant> jtv: Where?
[11:06] <wgrant> jtv: The current runs look successful, AFAICT.
[11:07] <jtv> wgrant: oh, I can't load up the log but devel is failing for me.
[11:08] <jtv> (I wonder why this is: some https pages won't load at all, even when others work fine)
[11:08] <wgrant> No tracebacks in the lucid_lp log that I can see.
[11:09] <jtv> Has lp.app.tests.test_versioninfo run yet?
[11:09] <wgrant> No.
[11:09] <wgrant> Oh, you're seeing this locally?
[11:09] <jtv> Grumble.  Why do other logs load just fine for me, but this one stays stuck in both chromium and FF?
[11:09] <wgrant> You said "buildbot failure" :)
[11:09] <wgrant> buildbot leaves it open because it's not done yet.
[11:09] <wgrant> So it streams.
[11:09] <jtv> Yes, I thought I saw a buildbot failure but https not working confused my research.
[11:10] <wgrant> There was spectacular buildbot breakage a few hours ago due to a double master massacre, but looks fine now.
[11:10] <jtv> wgrant: don't know if it's the same thing but I get similar symptoms with some bugs, for instance.
[11:10] <wgrant> Been working OK for me.
[11:10]  * wgrant blames Thailand.
[11:11] <jtv> Yeah, it could be censorship.  They said something about censoring https a while back.
[11:12] <jtv> wgrant: do you get the failure locally, if you first "make clean && make"?
[11:12] <wgrant> jelmer: The importds are upgraded now.
[11:12] <wgrant> jelmer: Thanks for noticing.
[11:13] <wgrant> AssertionError: '13785' != 13785
[11:13] <wgrant> May be the bzr upgrade.
[11:13] <jtv> Yup.  I got that from EC2 too.
[11:13] <jelmer> wgrant: thank you
[11:13] <wgrant> I've had a few successful ec2 runs today.
[11:13] <jelmer> wgrant: where is that AssertionError from?
[11:13] <jtv> wgrant: for me it appeared just very recently.
[11:14] <wgrant> jelmer: lp.app.versioninfo is returning a str instead of an int.
[11:14] <jelmer> wgrant: which lp branch?
[11:14] <jelmer> (bzr in devel is still on the old bzr, only db-devel has moved to 2.4+)
[11:14] <wgrant> jelmer: devel, and that's a very good point.
[11:14] <jtv> AFAIC the test could cast both sides to int and sidestep the whole issue.  But I don't know what else that would upset.
[11:15] <wgrant> I wonder if that runs with the system bzr.
[11:15] <wgrant> But that wouldn't explain ec2.
[11:16] <wgrant> It appears to use the system bzr.
[11:17] <jelmer> wgrant: hah
[11:18] <jelmer> wgrant: then I think I know what it is. In 2.4 one of the "bzr version-info" fields was changed to a string to support dotted revnos
[11:18] <wgrant> jelmer: That would do it.
[11:18] <wgrant> I wonder if the ec2 image uses a PPA with 2.4.
[11:18] <jelmer> doesn't it use the bzr ppa?
[11:19] <wgrant> I'm checking.
[11:19] <bigjools> jtv: your branch that I'm reviewing shows deleted bzr conflict markers in the diff, which means the preq branch is conflicted I guess?
[11:19] <wgrant> lib/devscripts/ec2test/instance.py:deb http://ppa.launchpad.net/bzr/ubuntu $DISTRIB_CODENAME main
[11:19] <wgrant> lib/devscripts/ec2test/instance.py:deb http://ppa.launchpad.net/bzr-beta-ppa/ubuntu $DISTRIB_CODENAME main
[11:19] <wgrant> Yup.
[11:19] <jtv> bigjools: possibly.  I'll resolve.
[11:20] <wgrant> I wonder why this didn't affect my three successful runs with the new image.
[11:20] <StevenK> wgrant: The ec2 image would have just been updated with 2.4
[11:22] <wgrant> StevenK: Yeah, but I've used the image multiple times today.
[11:22] <wgrant> Current run has a str there... I guess we'll see if it succeeds.
[11:23] <StevenK> wgrant: So you're happy with the image itself?
[11:23] <wgrant> It seems to work.
[11:25] <StevenK> Huzzah, I have fixed make for my branch of evil
[11:25] <wgrant> What was broken?
[11:26] <wgrant> dpkg-xz-support-619152 => devel  [OK]     (up for 2:52:55.425176)
[11:26] <wgrant> We may have success.
[11:26] <StevenK> I forgot to remove a class and securedutility for BranchDiffJob
[11:26] <wgrant> StevenK: If abentley appears before you vanish, you should probably ask him about the history here.
[11:28] <StevenK> 19 files changed, 31 insertions(+), 492 deletions(-)
[11:28] <wgrant> StevenK: You've stopped deleting the table, right?
[11:29] <StevenK> Indeed
[11:29] <StevenK> As in, I haven't done so
[11:29] <StevenK> Tossing back at ec2
[11:30] <wgrant> The original diff appeared to have the table gone from sampledata.
[11:30] <StevenK> That was removing triggers
[11:34] <wgrant> Ah.
[11:44] <nigelb> What advantage does PQM have over tarmac?
[11:45] <StevenK> None.
[11:45] <nigelb> Oh.
[11:48] <jelmer> StevenK: It supportts tla, arch and baz
[11:48] <jelmer> s/arch/arx/
[11:48] <jelmer> :P
[11:48] <jelmer> s/StevenK/nigelb/
[11:48] <jelmer> sigh
[11:48] <jelmer> nigelb: It supportts tla, arx and baz
[11:49] <nigelb> what are those?
[11:49] <wgrant> They are probably or hopefully old enough that nigelb doesn't....
[11:49] <wgrant> right.
[11:49] <wgrant> baz was bzr's predecessor.
[11:50] <wgrant> tla and arch are older and even crustier.
[11:50] <jelmer> wgrant: not arch, arx
[11:50] <jelmer> (which is yet another fork of arch)
[11:51] <wgrant> Oh, I didn't know it supported that.
[11:51] <wgrant> Impressive.
[11:51] <nigelb> Ah, so just support for more VCS?
[11:51] <wgrant> nigelb: Crucially, VCSes that have been obsolete for more than 5 years.
[11:51] <nigelb> heh
[11:51] <wgrant> And nobody ever really used anyway.
[11:52] <nigelb> I dream of one day being able to say approved and launchpad doing the merges itself with pqm or tarmac in the backend.
[11:52] <wgrant> Maybe eventually. It's awkward, though, as most projects hopefully want to have a test suite.
[11:53] <nigelb> Ah.
[12:01] <nigelb> hah. http://www.reddit.com/r/programming/comments/jsudd/you_see_rasmus_lerdorf_creator_of_php_wrecking/
[12:16] <danilos> jelmer, hi, what's the status of the loggerhead trunk? can we move LP to it? what is missing? should I perhaps revert the problematic changes in loggerhead trunk, get that revision into LP, and then reland them on loggerhead trunk?
[12:17] <jelmer> danilos: I'm not sure, I haven't followed loggerhead much recently.
[12:17] <jelmer> What are the problematic changes?
[12:17] <danilos> jelmer, wasn't there a problem that you were working on?
[12:18] <jelmer> danilos: I fixed a bug that affected loggerhead, but don't recall working on loggerhead itself recently
[12:18] <jelmer> danilos: as far as I know loggerhead trunk is fine :)
[12:18] <danilos> jelmer, LP is not using the latest rev from trunk because of some regressions
[12:19] <wgrant> danilos: That was misdiagnosed.
[12:19] <wgrant> danilos: The regression was in an unrelated change of jelmer's.
[12:19] <danilos> wgrant, ah, so that's all sorted?
[12:19] <jelmer> danilos: yep, should be
[12:19] <wgrant> danilos: It still needs to be relanded.
[12:19] <danilos> jelmer, sorry to have bothered you then :)
[12:19] <danilos> wgrant, I'd be happy to do that because there's another revision I care about
[12:19] <wgrant> lifeless and I reverted it hastily upon seeing an extra 3000 loggerhead OOPSes a day, without noticing there was a non-threadsafe SafeBranchOpener in the same deployment.
[12:20] <danilos> jelmer, wgrant: thanks for your input, I'll go up our loggerhead to the latest trunk
[12:20] <wgrant> Great.
[12:43] <nigelb> wgrant: Is there an inside joke to your email? "2008/02/29 and dodgy date manipulation code for that."
[12:45] <wgrant> nigelb: I am guessing that ChanServ thinks a year is 365 days.
[12:45] <wgrant> But 2008 had 366 days.
[12:45] <nigelb> Ahhh.
[12:45] <wgrant> cjwatson: Landed. Sorry it took so long.
[12:54] <nigelb> wgrant: the fix for that bug is to just remove int(output) to be outpuut instead?
[12:54] <nigelb> really?
[12:54] <nigelb> (or change revno to be str(revno))
[12:54] <cjwatson> wgrant: hooray, thanks!  now I just have to wait for bug 809123 and I can flush my queue ...
[12:54] <_mup_> Bug #809123: we cannot deploy DB schema changes live <fastdowntime> <qa-ok> <Launchpad itself:Fix Committed by stub> < https://launchpad.net/bugs/809123 >
[12:55] <wgrant> nigelb: Maybe. We need to see what other stuff uses that value.
[12:55] <wgrant> nigelb: It's displayed in the footer of every page, for example.
[12:56] <nigelb> ah
[12:56] <wgrant> cjwatson: Getting there. I believe there's only 5 or so hosts that aren't pgbouncer-capable, which is the last major blocker to fastdowntime.
[12:56] <wgrant> Hopefully by early next week we'll be ready.
[12:56] <wgrant> And this is actually a somewhat realistic estimate, I think :)
[12:57] <StevenK> Bah, I meant this channel.
[12:58] <wgrant> Well, aren't you a failure.
[12:58] <StevenK> wgrant: Clearly.
[12:58] <StevenK> wgrant: It seems that test_branch{,job} still referenced BranchDiffJob all over the place.
[12:58] <wgrant> Ah.
[12:59] <cjwatson> wgrant: incidentally, roughly when should I expect cocoplum to be updated?  I don't know its update schedule nowadays
[12:59] <StevenK> cjwatson: cocobanana needs to be requested.
[12:59] <StevenK> cjwatson: With 24 hours notice for 5 minutes of downtime
[12:59] <wgrant> cjwatson: It's no longer scheduled.
[12:59] <wgrant> So, as StevenK says.
[13:00] <wgrant> It still requires poppy downtime, so by convenition we must give 24 hours notice.
[13:00] <wgrant> Unless Platform wants to waive that requirement, I suppose...
[13:01] <cjwatson> What is cocobanana?
[13:02] <wgrant> cocoplum
[13:02] <cjwatson> Enough hostnames in the DC are quite similar that I find deliberate misspellings rather confusing ...
[13:03] <cjwatson> cocoplum is at least not too far back; r13727
[13:04] <wgrant> Yeah, we deployed on Monday.
[13:04] <StevenK> cjwatson: Sorry, I should have said. cocobabana/cococabana is an LP in-joke
[13:04] <StevenK> cocobanana, even. Sigh.
[13:05] <wgrant> cjwatson: Actually, cocoplum isn't important here.
[13:05] <wgrant> cjwatson: Since binaries are all uploaded to cesium.
[13:05] <StevenK> And cesium is NDT
[13:06] <wgrant> Right.
[13:06] <wgrant> It'll hopefully have this tomorrow morning.
[13:06] <wgrant> In 12 hours or so.
[13:07] <StevenK> abentley: O hai
[13:08] <abentley> StevenK: Hai!
[13:08] <StevenK> abentley: wgrant and I are of the opinion that StaticDiffs are unusd as of Janurary 2010. I've put together an MP to remove them, would you be able to take a peek at it?
[13:09] <wgrant> RevisionMailJob still calls BranchDiffJob to generate but them, but RevisionAddedJob is now used for that instead.
[13:09] <StevenK> abentley: Mind you, I'm not asking for a review, more a "Yes, this looks fine to do." or "No, please watch out for X, Y and Z."
[13:09] <wgrant> RevisionMailJob is only ever called for initial and removed scans.
[13:09] <cjwatson> oh, yes, good point.  excellent.
[13:09] <wgrant> No staticdiff has been created in 18 months.
[13:09] <abentley> StevenK: they are no longer used in new reviews, but do we want to delete them from old reviews?
[13:10] <wgrant> cjwatson: I hope we've not blocked too much... Debian's only been at it a week or so, right?
[13:11] <cjwatson> about that, yes.  it was a problem for an eglibc upload the other day, but quickly worked around and I haven't heard of any other instances yet.
[13:11] <StevenK> abentley: TBH, it's 18 month old data, at least, and the code tries a PreviewDiff first if that exists, right?
[13:11] <cjwatson> I think it's worked out OK.
[13:12] <abentley> StevenK: Yes, it is old.  Trying a preview diff first shouldn't be relevant, because old reviews won't have a preview diff.
[13:12] <StevenK> Let's see ...
[13:13] <StevenK> 33k static diffs on DF. That's a little more than I was hoping.
[13:14] <dobey> abentley: morning :)
[13:14] <abentley> dobey: morning.
[13:15] <dobey> abentley: i don't think that bug is quite fixed yet :(
[13:15] <dobey> abentley: bug #833147 that is. see my last 2 comments on it
[13:15] <abentley> dobey: Is this about +activereviews?
[13:15] <_mup_> Bug #833147: landing_candidates does not show proposals for private branches <qa-ok> <regression> <Launchpad itself:Fix Released by abentley> < https://launchpad.net/bugs/833147 >
[13:15] <dobey> abentley: yeah, and the count seems wrong
[13:15] <StevenK> wgrant: What do you think?
[13:16] <abentley> dobey: according to danilos, +activereviews doesn't use landing_candidates.
[13:16] <dobey> huh
[13:17] <wgrant> StevenK: If we do want to keep them, we could turn them into fake previewdiffs or something.
[13:17] <wgrant> Keeping the legacy table around forever seems undesirable.
[13:17] <StevenK> Hmmmm
[13:17] <abentley> dobey: you may be thinking of bug #833184
[13:17] <_mup_> Bug #833184: Branch.getMergeProposals breaks with private branches. <tech-debt> <Launchpad itself:Triaged> < https://launchpad.net/bugs/833184 >
[13:17] <danilos> abentley, well, I confirmed that the query count is still not insane on the page (for the timeout I was fixing, it was about 250 today when it used to be around 1500)
[13:18] <danilos> abentley, I've basically changed +activereviews to not use landing_candidates so I could make it use getMergeProposals() with eager loading of a bunch of related data
[13:18] <abentley> danilos: was that in the same branch?
[13:19] <dobey> abentley: is that what is used by the bit in launchpad that sets a proposal/branch to 'merged' once it's been merged into its target?
[13:19] <danilos> abentley, I think so, yes
[13:19] <abentley> dobey: I don't recall which APIs are used by that.
[13:20] <dobey> abentley: ok. it's also not working now :(
[13:22] <dobey> abentley: we have a branch that landed ~13 hours ago, but i haven't got a mail from LP and it hasn't set the proposal/branch to 'merged'
[13:22] <abentley> danilos: I don't see that change in the diff.
[13:22] <StevenK> wgrant: That sounds like a good idea -- do you think that blocks the branch I've worked on.
[13:25] <abentley> danilos: found it.  Darn.
[13:28] <abentley> dobey: no, the merge detector is using landing_candidates, not getMergeProposals.
[13:28] <dobey> abentley: hrmm. i wonder why it's not working then :-/
[13:29] <abentley> dobey: What are the names of the branches involved?
[13:29] <dobey> abentley: lp:~pedronis/ubuntuone-servers-common/sqlalchemy-uris -> lp:ubuntuone-servers-common
[13:30] <wgrant> Status: Merged
[13:30] <wgrant> The MP is still Approved, but the branch merge was detected.
[13:30] <wgrant> StevenK: Your branch drops access to the staticdiffs, so yes, probably.
[13:30] <dobey> ok, so it's half-broken then :)
[13:31] <wgrant> abentley, danilos: Any reason not to roll back both the branches?
[13:31] <deryck> henninge-lunch, ping for standup
[13:31] <dobey> maybe related to the fact that the number of activereviews is wrong?
[13:32] <abentley> wgrant: I don't think so.
[13:33] <wgrant> If you land the reversion now we can probably deploy it in 10-12 hours.
[13:33] <wgrant> I'd be reluctant to roll production back 80 revs now, though.
[13:34] <abentley> wgrant: OTP
[13:35] <StevenK> wgrant: When you say make them previewdiffs, do you mean a garbo job or a query?
[13:36] <wgrant> StevenK: It's only 30000 rows. Query.
[13:36] <wgrant> StevenK: But we need to determine if that is acceptable.
[13:37] <StevenK> SELECT count(*) from branchmergeproposal where review_diff is not null; => 12111
[13:38] <StevenK> So 20,000 of those are effectively abandoned?
[13:38] <StevenK> abentley: Okay, so if wgrant and I can work out a migration plan, you're happy to see it be removed?
[13:38] <abentley> StevenK: sure.
[13:38] <StevenK> abentley: Excellent, thank you.
[13:39] <wgrant> abentley: Any problem with just turning all those ancient ones into fake preview diffs?
[13:40] <abentley> wgrant: I don't think so.
[13:41] <StevenK> So am I right that ~20,000 are dead/unlinked?
[13:41] <wgrant> StevenK: They're possibly from RevisionMailJobs, but I'd really expect more...
[13:43] <abentley> danilos: I will go ahead and (mostly) roll back our revisions.  Cool?
[13:44] <wgrant> abentley: Please roll back entirely, unless you have an extremely compelling reason not to.
[13:44] <abentley> wgrant: I will not roll back the test that I added to ensure this doesn't happen again.
[13:44] <wgrant> Makes tracking easier, and gets us back to a known-good state.
[13:44] <wgrant> Ah.
[13:44] <wgrant> That sounds like a good idea.
[13:47] <StevenK> Bah, Curtis, stop that!
[13:50] <abentley> wgrant: Is it possible that dobey's misseed merge detection happened before the deployment?
[13:51] <bigjools> StevenK: he's only after the karma :)
[13:51] <StevenK> bigjools: Are you getting the e-mails too?
[13:51] <wgrant> abentley: It probably did.
[13:51] <bigjools> yes
[13:51] <wgrant> abentley: The deployment was 14 hours ago.
[13:52] <dobey> abentley: i don't know how it could have merged before the deployment, since it landing depended on the landing_candidates fix?
[13:52] <wgrant> abentley: But Branch:+activereviews is still empty, Product:+activereviews shows 1 branch, and Branch:+index shows 2 branches.
[13:52] <wgrant> So something is still pretty screwed.
[13:53] <abentley> wgrant: I grant that activereviews is screwed, but if something's wrong with merge detection, it's a separate something, because merge detection uses landing_candidates.
[13:53] <wgrant> abentley: Ew.
[13:53] <wgrant> abentley: That's not ideal.
[13:54] <wgrant> abentley: I guess we should check scanner logs...
[13:56] <danilos> abentley, sure, I don't think I can fix it today
[13:57] <danilos> abentley, (sorry, otp)
[13:58] <jelmer> jcsackett: thanks for the reviews
[13:58] <jcsackett> jelmer: you're welcome. :-)
[13:58] <wgrant> abentley: Of course, I can see trunk, so I can just check when the merge happened.
[13:58] <wgrant> Ahem.
[13:59] <wgrant> Date: 2011-08-24 23:46:49
[13:59] <wgrant> Middle of the rollout.
[13:59] <wgrant> Ah.
[13:59] <wgrant> But appservers generally update before loganberry.
[13:59] <wgrant> s/loganberry/ackee/, now.
[13:59] <abentley> wgrant: so, race condition.
[13:59] <wgrant> So tarmac would have seen the branch before the scanner was fixed.
[14:04] <abentley> dobey: it appears the scan happened halfway through the deployment, when the scanner was broken, but the API was fixed.
[14:04] <dobey> abentley: ok, so just bad timing?
[14:04] <abentley> wgrant, danilos, deryck: landed rollback as r13787
[14:05] <wgrant> abentley: Thanks. All except that test?
[14:05] <abentley> wgrant: Yes.
[14:05] <wgrant> Great.
[14:05] <wgrant> I will see that it's rolled out ASAP in the morning.
[14:05] <deryck> abentley, indeed, thanks for doing this!
[14:05] <abentley> wgrant: Oh, darnit, I forgot to use --rollback.
[14:05] <danilos> abentley, thanks
[14:05] <danilos> abentley, it's already rolled out so not a big deal, I'd say
[14:05] <wgrant> abentley: Not too critical, since we're not rolling back prod.
[14:06] <wgrant> qa-tagger won't see the bad rev even if we mark it bad.
[14:06] <wgrant> abentley: Care to update the IncidentReport?
[14:06] <abentley> wgrant: true.
[14:06] <abentley> wgrant: sure.
[14:06] <dobey> abentley: can we make the scanner run for that branch again? or should i just set status manually? there was some reason we stopped having tarmac set the status, but i don't remember what exactly. just remember it messed with LP automagic stuff
[14:07] <abentley> dobey: just set the status manually.
[14:07] <dobey> ok
[14:09] <dobey> so just the reviews count and +activereviews issue it seems.
[14:09] <dobey> wgrant, abentley: thanks guys
[14:09] <wgrant> dobey: https://code.launchpad.net/ubuntuone-servers-common/+activereviews should still work.
[14:09] <wgrant> Just the branch-specific one is broken.
[14:10] <dobey> right, ok
[14:17] <bigjools> anyone got any strong opinions on whether constants can/should go in enums.py or do we need a constants.py?
[14:20] <bac> i'd vote for enums
[14:22] <bigjools> that's what I was leaning to as well
[14:37] <sinzui> jcsackett, do you have time to review my two branches?
[14:37] <jcsackett> sinzui: i'm actually looking at your first one now.
[14:38] <sinzui> thank you
[14:42] <nigelb> wgrant: failed with that error you emailed about.
[14:48] <wgrant> nigelb: Landed.
[14:49] <wgrant> Night all.
[14:50] <nigelb> wgrant: Thanks. Night!
[14:54] <benji> hi jelmer, my bzr branch (https://code.launchpad.net/~benji/bzr/bug-702914/+merge/72239) has landed so the last thing to do is to either apply that patch to the LP snapshot or re-snapshot the current trunk.  I'm happy to do either of those if you point me at the branches in question.
[14:54] <jelmer> hi benji
[14:55]  * jelmer looks at the bzr.dev log
[14:57] <jelmer> benji: so, either way, I'll have to update my bzr-2.4b4 branch
[14:58] <henninge> jcsackett: Hi!
[14:58] <jelmer> that's currently on db-devel at the moment, so we can do some extended QA on staging
[14:58] <jelmer> s/currently/
[14:58] <henninge> jcsackett: I have to go now but if you could have a look at my latest branch, I'd be very pleased. ;-)
[14:58] <henninge> jcsackett: https://code.launchpad.net/~henninge/launchpad/bug-824435-failure-reporting-3/+merge/72908
[14:58] <jcsackett> i'll take a look just as soon as i'm done with sinzui's, henninge. :-)
[14:58] <jelmer> benji: So I guess the question is how urgent your fix is, and whether it can wait until bzr on launchpad is updated to bzr 2.4.0
[14:58] <deryck> abentley, I'll be about 5 minutes late to our call, but meet you in mumble then, if cool with you.
[14:59] <henninge> jcsackett: there are links to diffs in the cover letter as the branch is quite big.
[14:59] <henninge> jcsackett: thanks, that's great! ;-)
[14:59] <abentley> deryck: sure thing
[14:59] <benji> jelmer: it's relatively low on the urgency scale, and also quite low on the risk scale too, so I'm cool with however you want to handle it
[15:00] <jelmer> benji: in that case, let's just take a slightly newer revision of bzr.dev when we update devel to bzr 2.4
[15:01] <jelmer> benji: that seems like both the safest thing to do, and involves the least amount of work
[15:01] <benji> jelmer: cool.  In that case I'll consider my work done.  Thanks
[15:08] <jelmer> benji: thanks for fixing that :)
[15:08] <benji> my pleasure
[15:13] <LPCIBot> Project devel build #993: STILL FAILING in 5 hr 37 min: https://lpci.wedontsleep.org/job/devel/993/
[15:14] <bac> abentley: do you have time to talk for a bit about a but i'm working?
[15:14] <abentley> bac: OTP
[15:14] <bac> abentley: ok.  perhaps in a little while
[15:27] <jcsackett> is diff generation for MPs down? i've been waiting for about 30 minutes for a diff on henninge's mp to generate ...
[15:28]  * jcsackett digs through email to see if he missed a script failure notice
[15:44] <adeuring> jcsackett: could you please review this MP: https://code.launchpad.net/~adeuring/launchpad/bug-739052-7/+merge/72917 ?
[15:45] <jcsackett> adeuring: sure.
[15:45] <adeuring> thanks!
[15:56] <jcsackett> adeuring: r=me.
[15:56] <adeuring> jcsackett: thanks!
[17:40] <LPCIBot> Project devel build #994: STILL FAILING in 2 hr 26 min: https://lpci.wedontsleep.org/job/devel/994/
[17:45] <mrevell> Night all
[17:56] <abentley> deryck: so, that bug turned out to be a surprisingly simple fix.  Who do we have who's up on Twisted?
[18:00] <deryck> abentley, hmmm, so I'd point you at allenap, bigjools, lifeless, or wgrant, I think. :)
[18:01] <abentley> deryck: Cool, thanks.  We need a table for this.
[18:10] <LPCIBot> Project devel build #995: STILL FAILING in 30 min: https://lpci.wedontsleep.org/job/devel/995/
[18:39] <abentley> deryck: pre-imp?
[18:40] <deryck> abentley, do you mind asking someone else?  Sorry to pass.  Just have couple things I need to get done before EOD.
[18:40] <deryck> abentley, but I absolutely will if no one else is available.
[18:40] <abentley> deryck: okay.
[18:42] <abentley> sinzui: pre-implementation call?
[19:00] <dobey> hrmm
[19:01] <dobey> when one marks a milestone inactive, aren't the bugs targeted to that milestone supposed to still show that milestone value in the bugs page?
[19:01] <dobey> i thought it did…
[19:09] <sinzui> abentley, okay. in a few minutes one I extract myself from a breakpoint
[19:23] <sinzui> abentley, I am on mumble?
[19:23] <abentley> sinzui: okay.
[19:24] <abentley> sinzui: bug 82077
[19:24] <_mup_> Bug #82077: [apport] gnome-volume-control crashed with SIGSEGV in g_type_class_meta_marshal()  <GNOME media utilities:Fix Released> <gnome-media (Ubuntu):Fix Released by desktop-bugs> < https://launchpad.net/bugs/82077 >
[19:24] <abentley> sinzui: bug 820077
[19:24] <_mup_> Bug #820077: TeamMembershipTransitionError: Bad state transition from DECLINED to INVITED  <oops> <Launchpad itself:In Progress by abentley> < https://launchpad.net/bugs/820077 >
[19:26] <bac> cjwatson: colin could you have a look at https://answers.launchpad.net/ubuntu/+source/ubiquity/+question/158404 when you get a chance?  the user has sent email to us asking for some resolution or a comment.
[19:32] <sinzui> abentley, https://bugs.launchpad.net/launchpad/+bug/109716
[19:32] <_mup_> Bug #109716: Cannot join open team if there's an existing membership pending approval <lp-registry> <teams> <Launchpad itself:Triaged> < https://launchpad.net/bugs/109716 >
[19:38] <LPCIBot> Project db-devel build #825: STILL FAILING in 6 hr 10 min: https://lpci.wedontsleep.org/job/db-devel/825/
[19:47] <lifeless> hi flacoste :)
[19:47] <lifeless> you have mail; we might want to touch base on the general principle today.
[19:48] <lifeless> bah, no gary. I wonder who else knows buildout really really well :)
[19:50] <james_w> lifeless, is this still the recursive issue?
[19:50] <lifeless> yeah
[19:50] <james_w> does something like http://pypi.python.org/pypi/cp.recipe.cmd/0.1b help?
[19:51] <lifeless> possibly
[19:51] <lifeless> I'd like something with a -little- more awareness of options and so on
[19:53] <flacoste> hi lifeless
[19:55] <flacoste> lifeless: i don't think we need to touch base over that, i completely agree with your last email
[19:56] <flacoste> lifeless: about buildout, i probably enough to get into trouble, i've reviewed and discussed all of gary's work on it at length with him
[19:56] <flacoste> probably _know_ enough
[19:58] <lifeless> :)
[19:58] <lifeless> flacoste: ah good, I'm glad we agree. Buildout:
[19:59] <lifeless> flacoste: I have this gpgfixtures project extracting gpg stuff; a wsgi, in-memory keyserver and so on
[19:59] <lifeless> flacoste: I'd *like* to demonstrate the microservice fake setup where LP *runs* the fake service without being able to *import it*
[19:59] <lifeless> flacoste: so it looks like a complete abstraction barrier
[20:00] <flacoste> lifeless: i think i know how to do this, voice is probably better, want to skype me?
[20:01] <flacoste> lifeless: it's seems even easy :-)
[20:01] <lifeless> sure
[20:01] <lifeless> 2 secs
[20:20] <lifeless> flacoste: lp:python-gpgfixtures
[20:21] <lifeless> flacoste: btw skaet is having trouble - https://bugs.launchpad.net/launchpad/+bug/834082
[20:21] <_mup_> Bug #834082: Regression? can not target to series or update assigned to for ubuntu bugs <Launchpad itself:New> <Ubuntu:New> < https://launchpad.net/bugs/834082 >
[20:22] <lifeless> is there someone still live in maintenance to look ?
[20:22] <flacoste> deryck: if you are around ^ ^ ^
[20:23] <deryck> I'm around.
[20:23]  * deryck looks back
[20:24] <deryck> hmmmm
[20:24] <deryck> that sounds more like the group or her group membership changed.
[20:24] <lifeless> flacoste: bin/py -m gpgfixtures.keyserver
[20:25]  * deryck looks at bzr log
[20:28] <LPCIBot> Project devel build #996: STILL FAILING in 1 hr 57 min: https://lpci.wedontsleep.org/job/devel/996/
[20:30] <lifeless> interestingly
[20:30] <lifeless> mdz took techboard out of udd today, but I don't htink that that would have been granting privilieges
[20:37] <deryck> lifeless, I can't imagine.  If it's easy enough, might be worth adding it back as a simple test to see if she can work again. :)
[20:41] <deryck> I can't really see anything that looks like it would have changed series nominations and assigning bugs.
[20:42] <deryck> sinzui, do you know of any change that might now be keeping skaet from setting bugs to series and assigning bugs to a team?
[20:52] <sinzui> deryck, no clue
[20:52] <deryck> sinzui, ok, cool.  thanks.
[20:53] <sinzui> deryck, I do not see a skaet in launchpad
[20:53] <sinzui> https://launchpad.net/people/?name=skaet&searchfor=all
[20:53] <deryck> sinzui, she filed a bug.  bug 834082
[20:53] <_mup_> Bug #834082: Regression? can not target to series or update assigned to for ubuntu bugs <regression> <Launchpad itself:Triaged> <Ubuntu:New> < https://launchpad.net/bugs/834082 >
[20:55] <sinzui> deryck, that relates more to bug nominations than bug targeting
[20:55] <deryck> sinzui, indeed.  Did I say targeting?  Sorry.
[20:55] <lifeless> well
[20:55] <lifeless> she is rm
[20:55] <lifeless> so she never nominates :)
[20:57] <deryck> semantically, that's true, but it still goes through Bug.addNomination, I believe.
[20:58] <sinzui> I see she is a direct and indirect driver for the series. I believe she should have permission.
[20:58] <deryck> yeah, i would think so, too.
[20:58] <sinzui> deryck, I think the picture already shows that the bug is nominated and accepted
[20:59] <sinzui> This might be a case where we allow users to attempt a non-change action, and then show an error
[21:01] <deryck> sinzui, oh, right.  I didn't even catch that.
[21:04] <sinzui> deryck: I think the action here is that he wants to assign teams and target milestones. which the image implies she can do, but a bug-nomination constraint is being called after the bug is already accepted? Since the behaviour/checks are different between the DSP and (series)SP contexts, I think something has changed to distroseries bugtargets
[21:05] <deryck> ah, yes.  hmmmm
[21:06] <lifeless> sinzui: she :)
[21:14] <deryck> So she's not using the drop down form under the task.  She's trying to target to maverick and assign desktop team....
[21:14] <deryck> and is using the page via the "target to series" link and the js assign someone widget....
[21:14] <deryck> so this smells like group changes, not code changes, to me.  since the two are really unrelated.
[21:15] <deryck> sinzui, lifeless ^^
[21:15] <lifeless> tada
[21:15] <deryck> hi skaet, we're talking about you ;)
[21:15] <lifeless> deryck: skaet: You've probably met :P
[21:15] <deryck> indeed
[21:15] <skaet> :)
[21:17] <deryck> skaet, this feels to me like it has to be something changed in the groups, since targeting to series and assigning someone to the bugtask are not really related.
[21:19] <skaet> deryck,  not aware of any changes to my groups recently.
[21:19] <sinzui> deryck, the drivers for maverick and oneiric are identical: ~ubuntu-drivers, ~ubuntu-release. BugNomination.canNominate() will exit early with True for a driver member. The series are only different because one is a conjoined slave
[21:21] <deryck> sinzui, so I'm doing some poking at the code myself, and see it's BugNominationView that raises the error and does its own check.
[21:22] <sinzui> Excellent the view ignores the object's own definition of who can change it
[21:22] <deryck> exactly.
[21:22] <deryck> but it is basically the same, a check against launchpad.driver.
[21:24] <deryck> this stuff hasn't been touched in awhile, if bzr blame is to be believed.
[21:25] <sinzui> deryck,  the driver check between the view and the object look identical and she is in both driver teams
[21:26] <deryck> sinzui, yeah, agreed.  I don't see how this could be failing.
[21:31] <lifeless> \o/
[21:32] <deryck> is there some insight there, lifeless?  or just general excitement? :)
[21:34] <deryck> skaet, so is this accurate -- you *can* target to series when there isn't one set, but *cannot* target to series when there is one already set?
[21:36] <skaet> deryck,  don't believe that is the case.    See the links in the bug.   series has been set in both cases (same bug).
[21:37] <deryck> skaet, but the one you did was set for one task, but not another?  and you set it to Oneiric for the other?  or no?
[21:38] <skaet> deryck,  it was set to Oneiric before I encountered it.
[21:39] <skaet> if it has /oneiric/ in the path,  I can't seem to target series.
[21:39] <deryck> oh!  I get what you're saying now.
[21:40] <skaet> :)
[21:40] <deryck> skaet, so you're clicking through from a series list of bugs and then can't target to a different series from that url?
[21:40] <lifeless> skaet: what happens if you go to the other task on the bug
[21:41] <lifeless> and then target to maverick or whatever you're trying to target to ?
[21:41] <lifeless> skaet: (or are you trying to target to oneiric ?
[21:41] <skaet> lifeless was going to target it,  so it got looked at for maverick.
[21:41] <lifeless> ok
[21:41] <deryck> skaet, but it works if you drop the "oneiric" from the url?
[21:42] <lifeless> so yeah, head to the upstream task, and try to add a task there for maverik
[21:42] <skaet> deryck,  yes,  that is what works.
[21:42] <deryck> skaet, ok, so at least we have a work around for that :)
[21:43] <deryck> not nice, but at least you can get by until we figure it out.
[21:43] <deryck> skaet, but you have nothing working for assigning to a team?  Or this also works from the non-oneiric url?
[21:45] <skaet> derych,  no pencil icon beside name on either link, but dropdown seems to work from path without /oneiric/ in it.
[21:45] <skaet> deryck, ^^
[21:45] <skaet> so work around there too.
[21:45] <deryck> skaet, ok.  so at least you can work around that, too.
[21:45] <deryck> right
[21:48] <skaet> yup,  will use these for now.   But given the beta bug set about to hit,  please, please, please get the more efficient ways working again.
[21:48] <deryck> skaet, oh, definitely.  I'll add it to my squad's board to figure out as soon as we can.
[21:49] <skaet> deryck, thanks!
[21:49] <deryck> skaet, np!
[21:54] <deryck> ok, I'm out.  Later on, everyone!  Thanks, sinzui, for the help thinking about that issue.
[22:29] <nigelb> ok, so apparently, I can't join here until identified.
[23:39] <wgrant> Ahh, quality sampledata.
[23:39] <wgrant> foobar-1.0.dsc
[23:39] <wgrant> iceweasel-1.0.dsc
[23:39] <StevenK> Haha
[23:39] <wgrant> Why do people insist on hyphens :(
[23:39] <wgrant> NOT VALID
[23:42] <james_w> I didn't think the filename was actually important?
[23:42] <StevenK> It is!
[23:43] <james_w> i.e. you could have annoy-wgrant.dsc and it would still be valid if the contents made sense
[23:43] <StevenK> The format of the filename is specified in Policy, I think
[23:44] <wgrant> james_w: It's certainly important for all the other files.
[23:44] <wgrant> james_w: Otherwise dpkg-source can't know what to do with them.
[23:44] <james_w> yeah
[23:45] <james_w> they obviously have to match the names listed in the .dsc
[23:45] <wgrant> But this stuff probably isn't specified in Policy.
[23:45] <wgrant> I'm not sure any of the source formats are.
[23:45] <james_w> I'm sure there are many things (I'm sure I've written some) that assume the filename format, but I don't see why it would be strictly required
[23:45] <wgrant> Just the source package layout itself.
[23:45] <james_w> from a schema point of view
[23:46] <james_w> http://www.debian.org/doc/debian-policy/ap-pkg-sourcepkg.html#s-pkg-sourcearchives
[23:46] <wgrant> Hah.
[23:46] <wgrant> So the dsc is indeed unspecified.
[23:46] <wgrant> Although that sectioin is a few years out of date...
[23:47] <james_w> yeah
[23:48] <james_w> so maybe those files are named like that to test that files named like that are handled, as there are some old files in Debian like that :-)
[23:48] <wgrant> We don't handle them.
[23:49] <wgrant> Except for a couple of methods.
[23:49] <wgrant> They certainly can't make it all the way through.
[23:49] <wgrant> Never could.
[23:49] <wgrant> They're only used for a few small unit tests.
[23:49] <james_w> ok
[23:50] <james_w> that concludes today's episode of pedantry, as you were
[23:50] <wgrant> I think it's generally safe to assume that terrible old stuff in LP is just terrible old stuff, and not actually real.
[23:50] <wgrant> Heh
[23:50] <lifeless> kiko will know :)
[23:50] <lifeless> for those things in particular
[23:51] <wgrant> I'm currently fixing a unit test for a method in a script that was never used, which just feeds data to archiveuploader which will reject hyphens anyway.
[23:51] <wgrant> So I'm not sure it's particularly important :)