[01:03] <mwhudson>   Tear down canonical.testing.layers.TwistedAppServerLayer in 3 minutes 0.938 seconds.
[01:03] <mwhudson> this seems excessive :(
[01:03] <lifeless> probably swapped out
[01:04] <mwhudson> yeah
[01:32] <thumper> mwhudson: got a few minutes to talk about test strategy for a change I ahve
[01:32] <thumper> ?
[01:34] <mwhudson> thumper: sure
[03:04] <wgrant> As what DB user do the tests run by default?
[03:04] <mwhudson> wgrant: launchpad
[03:05] <wgrant> mwhudson: Ah. Thanks.
[03:05] <wgrant> Hm.
[03:53]  * thumper gains even more dislike of the librarian for tests
[03:53] <wgrant> Because it takes FOREVER to start up, or something more sinister?
[03:53] <lifeless> singleton.slow. functional-not-unit.
[03:54] <mwhudson> or maybe because you have to commit all over the place when using it?
[03:57] <thumper> failed to shutdown in this instance
[03:58] <thumper> also for those other reasons, but in this particular time, for failing to die
[04:01] <mwhudson> that's a lot of reasons for hate between us
[04:01] <wgrant> There are more.
[04:21]  * thumper EODs for dinner making
[04:36] <mwhudson> programming can be terrible some times
[04:37] <wgrant> What's going wrong?
[04:38] <mwhudson> oh just zope.interface crap
[04:38] <wgrant> Ah.
[04:50] <stub> The librarian could be mocked for many tests - the transaction rules are well documented and the interface simple. Nobody has bothered though (since it is a per test-run cost rather than a per-test cost?)
[04:52] <lifeless> stub: I think you mean stubbed (no pun intended) - Mocks are not suitable for keeping true to the transaction rules.
[04:53]  * wgrant tries to remember the URL to that stubs vs. mocks. vs. fakes thing that was around a while ago.
[04:55] <lifeless> wgrant: all are test doubles; mocks assert a sequence of calls with seeded result values
[04:55] <wgrant> Ah.
[04:55] <wgrant> I can never remember which is which.
[04:55] <lifeless> stubs are generally limited functionality doubles that do stuff
[04:55] <lifeless> and fakes do even less
[04:56] <lifeless> anyhow, the rule to remember is 'mocks do not meet contracts' - each and every test has its own mock, or they aren't actually mocks.
[04:56] <lifeless> on the upside you can create a mock by decorating a realobject and recording the input/output sequence it sees.
[04:57] <lifeless> which can be a good way to make mocks, and with a little glue, turn them on/off on a per-run basis
[04:57] <lifeless> to let one validate that the mock hasn't altered test validity asynchronously.
[05:01] <mwhudson> it's on mumak.net somewhere i currently can't find
[05:12] <mwhudson> _so many_ places reference next_mirror_time :(
[05:14] <MTecknology> stub: hi
[05:14] <MTecknology> stub: we were just talking about you earlier
[05:15] <mwhudson> and mostly for lame, or at least non-intent revealing, reasons
[05:15] <stub> Talking about me for lame and non-intent revealing reasons? O_o
[05:17] <MTecknology> I decided I can either do more crappy documentation in the 30min I'll be awake, start reading an article I need to do a presentation on, tweak my bot some, install stumbleupon and use it, or..... do nothing.... Problem is that none of them sound appealing
[05:18] <MTecknology> stub: I was asking about stu and thumper thought I was talking about you. But then we did talk about you and I realized we like the same kind of ice cream
[05:19] <stub> stu flavoured ice cream? This is getting more dubious.
[05:20] <MTecknology> lol
[05:21]  * mwhudson eods
[05:25] <wgrant> stub: Can you have a quick glance at http://pastebin.ubuntu.com/307257/ and tell me if i'm doing anything horrifyingly forbidden ? I'd really really like to get this in before 3.1.10, and need to discuss it with Soyuz people tonight. Basically, I need a way to restrict permissible source package formats by distroseries. This is it.
[05:27] <stub> wgrant: We normally use a integer/enum instead of a string where there is a fixed set of allowed options, and strings for free text. I suspect 'format' is not free text and should be an enum.
[05:29] <stub> wgrant: The table name sounds a little dubious, but that will shake out in discussions with soyuz. Is this table defining the formats that are allowed for a distroseries or the formats that have been used in a distroseries?
[05:29] <wgrant> stub: Right, I wondered about that. But to be consistent, that would mean migrating a column (sourcepackagerelease.dsc_format) from a string to an enum too.
[05:30] <wgrant> stub: It's the same scheme used for ComponentSelection and SectionSelection, but I will discuss it with Soyuz. It defines the formats allowed in a distroseries.
[05:30] <stub> We are inconsistent in many places - if you are correct, adding a comment in comments.sql is fine rather than migrating the column now. We can't be as agile with the DB schema as we are with Python.
[05:31] <stub> a string field might be fine in this case if it is 'whatever apt or tool x tells us' rather than some value Launchpad needs to actually understand.
[05:31] <wgrant> All values in that column should currently be identical, but it still sounds messy.
[05:32] <wgrant> It does have to be understood.
[05:32] <wgrant> At the moment there is only one valid value. After my branch, there will be three, defining different sets of allowed files in the sourcepackagerelease.
[05:33] <wgrant> The formats are defined by dpkg.
[05:35] <stub> So in general with the Python code we want to avoid "if format == '1.0'" and instead have "if format == PackageFormat.WHATEVER"
[05:36] <stub> If it turns out in discussion that a string is the right choice for this column, I'll want some vague justification.
[05:36] <stub> But no babies will die either way.
[05:45] <wgrant> What's the best way to do this? Define the DBEnumeratedType and then a dict mapping '1.0', '3.0 (quilt)' etc. to its items? Or does DBEnumeratedType have some builtin way to do this, like lazr.restful seems to use?
[05:49] <sridher> got an error to run > make schema
[05:50] <wgrant> sridher: Which error?
[05:52] <sridher> http://paste.ubuntu.com/307272/
[05:52] <wgrant> sridher: Python 2.6 is not supported.
[05:53] <wgrant> sridher: Only 2.4 (and nearly 2.5, but it's not merged yet) at this point.
[05:53] <sridher> ok thank you sir
[05:54] <wgrant> sridher: Did you use the rocketfuel-setup script as described on https://dev.launchpad.net/Getting?
[05:55] <sridher> yes sir
[05:56] <sridher> i got error that "developer-dependency" package not found
[05:56] <wgrant> sridher: Which version of Ubuntu are you using?
[05:57] <sridher> karmic
[05:57] <wgrant> That should just work.
[05:57] <wgrant> Try running rocketfuel-setup again.
[05:57] <sridher> ok sir
[05:58] <sridher> Package `launchpad-developer-dependencies' is not installed and no info is available.
[05:58] <wgrant> apt-get update
[05:58] <sridher> ok
[05:59] <sridher> http://paste.ubuntu.com/307275/
[06:03] <wgrant> sridher: You have the launchpad PPA enabled (probably in /etc/apt/sources.list.d/launchpad-dev.list)?
[06:04] <sridher> yes sir
[06:05] <wgrant> sridher: pastebin the output of 'apt-get update'
[06:06] <sridher> http://paste.ubuntu.com/307278/
[06:07] <wgrant> I do not know what the problem is.
[06:07] <wgrant> Unless you are using something other than i386 or amd64.
[06:07] <sridher> iam amd64
[06:08] <wgrant> What is in /etc/apt/sources.list.d/launchpad-dev.list?
[06:09] <sridher> deb http://ppa.launchpad.net/launchpad/ppa/ubuntu karmic main
[06:09] <sridher> deb http://ppa.launchpad.net/bzr/ppa/ubuntu karmic main
[06:09] <wgrant> That's fine.
[06:13] <sridher> is it work with python 2.4?
[06:14] <wgrant> sridher: Yes. I presume you modified your copy to use python2.6 manually?
[06:14] <wgrant> al-maisan: Morning.
[06:14] <al-maisan> good afternoon wgrant, how are things?
[06:16] <sridher> after getting an 2.4 error i changed /devel/Makefile version to 2.6
[06:16] <wgrant> al-maisan: Not too bad. Just finishing off my v3 source format branch. One thing I came across in the tests was that the 'absolutely-anything' upload policy doesn't accept PPA uploads -- do you know if this is deliberate? I need it to for my tests, and enabling PPA uploads in it doesn't break other tests in lp.archiveuploader.
[06:16] <wgrant> But who knows what other tests might lurk elsewhere.
[06:17] <al-maisan> wgrant: I don't know off-hand but will take a look.
[06:18] <wgrant> al-maisan: (this branch recently became very important, as Debian has started uploading 3.0 (quilt) sources)
[06:18] <al-maisan> wgrant: gotcha.
[06:19] <al-maisan> wgrant: would the importance be diminished in any way of we sunc'ed lucid from testing as opposed from unstable?
[06:20] <al-maisan> s/of/if/
[06:21] <wgrant> al-maisan: That would delay it by ten days at most, and with the current backlash it's unclear exactly what is going to happen to Lucid syncs.
[06:21] <al-maisan> wgrant: I see.
[06:29] <al-maisan> wgrant: re. the 'absolutely-anything' upload policy I find this snippet in AbstractUploadPolicy.rejectPPAUploads():
[06:29] <al-maisan>         """Reject uploads targeted to PPA.
[06:29] <al-maisan>         We will only allow it on 'insecure' and 'buildd' policy because we
[06:29] <al-maisan>         ensure the uploads are signed.
[06:29] <al-maisan>         """
[06:29] <al-maisan> wgrant: why would it be so important for PPA uploads to be signed?
[06:29] <wgrant> al-maisan: Seems like absolutely-anything (only used in tests) should be safe, however.
[06:29] <sridher> http://paste.ubuntu.com/307284/
[06:30] <wgrant> al-maisan: I don't know. It works OK once I enable it in the policy, so the code is fine with unsigned uploads.
[06:30] <wgrant> There is some special signature treatment with PPA uploads (stripping signatures from stored .changes), but that seems to handle a lack of signature fine.
[06:31] <al-maisan> wgrant: if the policy in question is only used in tests then I guess "It's better to beg forgiveness than ask permission" applies ;)
[06:32] <wgrant> al-maisan: OK. Thanks.
[06:48] <noodles775> Morning
[06:49] <wgrant> Morning noodles775.
[06:53] <noodles775> Hi wgrant :)
[06:53] <wgrant> noodles775: Almighty RM, I need your advice.
[06:54] <noodles775> thumper: your branch is rc-approved... (just in case you didn't see the email).
[06:54] <noodles775> wgrant: for the v3sources?
[06:54] <wgrant> noodles775: Right. Debian has started uploading them, so it's pretty important no.
[06:54] <wgrant> +w
[06:55] <noodles775> yep, definitely. But it's also the kind of thing that I'd like to have tested on dogfood thoroughly before r-cing, which means it might be best as a CP... but bigjools will be around later...
[06:55] <wgrant> noodles775: The branches are pretty much done (save a conversion from a string to an enum in one place, which I'm finishing off now), but they're bigish.
[06:55] <wgrant> Right.
[06:56] <wgrant> But there are DB changes (safe) that are needed.
[06:56] <noodles775> He'll be able to check your branch on df...
[06:56] <noodles775> ouch
[06:56] <noodles775> btw: Thanks so much for gettin in there and fixing those!
[06:56] <wgrant> But assuming those get into 3.1.10, there are CPs required on Soyuz machines and appservers.
[06:57] <wgrant> Plus somebody needs to get the new dpkg on the buildds and Soyuz machines... not sure who to talk to about that.
[06:57] <wgrant> But lucid won't open for a few days, and the v3 packages can be survived without for a while, so that's not quite as critical as the DB changes.
[06:58] <noodles775> right. Have you got a branch with the db changes ready for review?
[06:58] <wgrant> Not on its own yet, as I need to convert a column to an enum.
[06:59] <wgrant> There is a new table, plus some new enum values on SourcePackageFileType that will cause appservers to explode if they don't know about them.
[06:59] <wgrant> appservers and builddmaster, that is.
[07:01] <noodles775> OK. So assign the db changes to stub+jml, bigjools can take a look when he's in and plan the best course of action.
[07:02] <wgrant> Will do. Thanks.
[07:02] <noodles775> Thank you!
[07:05] <wgrant> noodles775: Any recommendations for what to rename the table listing permitted formats by distroseries? I've currently called it SourceFormatSelection (because of ComponentSelection and SectionSelection), but I'm sure that's suboptimal.
[07:07] <noodles775> wgrant: re-name?
[07:07] <wgrant> noodles775: Well, to you it's just naming it.
[07:07] <noodles775> :)
[07:10] <noodles775> wgrant: SourceFormatSelection seems fine to me - if it's suboptimal, it's because of the other columns that you've based it on. The db reviewers will be in a better position to comment.
[07:10] <wgrant> noodles775: Well, stub said to ask Soyuz...
[07:11] <noodles775> wgrant: ah ok. so, as I said, SFSelection seems fine to me. bigjools will comment later I'm sure .
[07:21] <thumper> noodles775: ta
[07:28] <wgrant> What's the Storm equivalent of an EnumCol?
[07:29] <wgrant> StormMigrationGuide has that as an unanswered question down the bottom.
[07:36] <noodles775> wgrant: I haven't used it, but http://twistedmatrix.com/users/radix/storm-api/storm.properties.Enum.html
[07:36] <noodles775> gr, no, that's not a db enum.
[07:37] <wgrant> Looks like it is.
[07:37] <wgrant> I see it used for that purpose in PackageCopyRequest, with a utility to convert the DBET.
[07:37] <noodles775> Great.
[07:37] <wgrant> Thanks.
[07:37] <noodles775> np.
[07:40] <wgrant> noodles775: Looks like canonical.database.enumcol.DBEnum is what I actually want, as it supported DBETs directly.
[07:41] <noodles775> wgrant: good to know.
[07:41] <noodles775> wgrant: can you update the migration guide (if you haven't already). Thanks!
[07:41] <wgrant> noodles775: Will do.
[08:23] <adeuring> good morning
[08:25] <wgrant> Can I look up a DBItem given a DBEnumeratedType and the item's title?
[08:26] <al-maisan> Good morning adeuring
[08:27] <adeuring> hi al-maisan!
[08:37] <noodles775> wgrant: why not use the actual enum? Like PackagePublishingStatus.PENDING? (but you can do PackagePublishingStatus.getTermByToken('Pending') too?).
[08:38] <wgrant> noodles775: I need to convert a string representation of a format from the .dsc (eg. '3.0 (quilt)').
[08:38] <wgrant> I'll try that.
[08:38] <noodles775> Great.
[08:38] <wgrant> I thought that would go the other way.
[08:48] <wgrant> Oh, woops. Was wondering why my enum was throwing strange SyntaxErrors. Then realised the names started with digits.
[08:48] <wgrant> FORMAT_1_0 rather than 1_0, perhaps?
[08:58] <bigjools> wgrant: good <insert time of day here>, I hear you're working on https://bugs.edge.launchpad.net/soyuz/+bug/293106
[08:58] <mup> Bug #293106: does not support debian v3 source formats <feature> <motu> <ppa> <soyuz-upload> <Soyuz:In Progress by wgrant> <https://launchpad.net/bugs/293106>
[08:58] <wgrant> bigjools: Good morning. I am. Shall we discuss the plan?
[08:58] <bigjools> please do
[08:59] <bigjools> is it blocking anything in the distro that you know of?
[08:59] <bigjools> I assume some v3 packages need to be synced now?
[08:59] <wgrant> Not right now, but Lucid will open in a few days, and the first v3 packages have appeared in Debian.
[08:59] <wgrant> Then it will be blocking things, although not critically to start with.
[08:59] <wgrant> Now, the code is done and works.
[08:59] <bigjools> ok can this bump to the 3.1.11 milestone?
[08:59] <wgrant> I don't think it can.
[09:00] <bigjools> massive changes 2 days before a release make me very nervous
[09:00] <wgrant> However, if we get some safe bits in now, the rest can be CPed to Soyuz machines at your leisure.
[09:00] <bigjools>  /o\
[09:00] <bigjools> I love coming back from holidays!
[09:01] <wgrant> All that needs to be applied everywhere is a new table, a few new SourcePackageFileType values, a trivial function on DistroSeries, and four lines in CopyChecker.
[09:01] <bigjools> wgrant: what have you done to fix it?
[09:01] <wgrant> The big invasive changes are only needed on cesium, germanium and cocoplum.
[09:02] <bigjools> have you got a branch I can see?
[09:02] <wgrant> https://code.edge.launchpad.net/~wgrant/launchpad/distroseries-source-format-selection has it all. I'm just finishing off a change recommended by Stuart.
[09:02] <bigjools> and why can't it wait a month, do you expect a lot of v3 packages?
[09:03] <wgrant> I don't know. But distro people were eeking about it, and Lucid will freeze very early.
[09:03] <wgrant> I don't think anyone can say how many v3 packages will appear in the next month and a bit.
[09:04] <bigjools> is there a workaround to sync them if we can't upload v3?
[09:05] <wgrant> They should be convertible to 1.0 with a little effort, I guess.
[09:08] <bigjools> wgrant: why the new table?
[09:08] <wgrant> bigjools: To restrict which series can have the new formats.
[09:08] <bigjools> why is that needed?
[09:09] <bigjools> I don't know anything about the new format BTW :/
[09:09] <wgrant> bigjools: Only >= karmic's dpkg supports the new formats.
[09:09] <bigjools> ok
[09:09] <wgrant> So the old chroots will be very unhappy (and maybe chrootwait; I'm not quite sure)
[09:12] <al-maisan> could we control the source format selection w/o a schema change, at least initially?
[09:12] <al-maisan> i.e. by a piece of python logic that ascertains "Only >= karmic's dpkg supports the new formats"
[09:13] <wgrant> You could hardcode the series name, I guess.
[09:13] <bigjools> ew
[09:13] <wgrant> Yes.
[09:13] <al-maisan> .. and clean up things in 3.1.11
[09:14] <bigjools> I'm not sure what that would buy us, it's still an invasive change
[09:15] <al-maisan> no question about that
[09:15] <al-maisan> but we'd at least avoid "last minute" db schema changes
[09:16] <wgrant> Absolutely awful timing, I know, but Debian only revealed its intentions at the end of last week :(
[09:18] <bigjools> I am still -1 on this going in unless someone from distro steps in and says it must
[09:18] <wgrant> Right.
[09:18] <wgrant> I'm talking to them now.
[09:18] <bigjools> where "someone from distro" = cjwatson :)
[09:19] <bigjools> this is a 4k diff branch - that's just insane to put in at this stage
[09:19] <bigjools> err wait
[09:19] <bigjools> diff fail
[09:19] <wgrant> Last I checked it was 1.6klines
[09:19] <al-maisan> 1581 lines of diff
[09:19] <al-maisan> still a massive change
[09:19] <wgrant> And a tiny fraction of that is needed *right now*.
[09:20] <wgrant> But yes, it is big.
[09:20] <bigjools> ok now I am diffing against db-devel :)
[09:20] <wgrant> Ahaha.
[09:20] <wgrant> That would do it.
[09:21] <bigjools> wgrant: your sample data change changes the archive table, why?
[09:21] <wgrant> bigjools: external_archive_deps change wasn't in there previously.
[09:21] <bigjools> ah you can blame me for that
[09:21] <wgrant> Yup :P
[09:22] <wgrant> SourceFormatSelection is changing to an enum at the moment.
[09:22] <bigjools> you're removing the table?
[09:22] <wgrant> No.
[09:23] <wgrant> It's just going to use an enum rather than a string for the format.
[09:24] <bigjools> wgrant: from canonical.database.enumcol import DBEnum
[09:25] <wgrant> bigjools: By that I mean I'm rerunning the tests after completing the change.
[09:28] <bigjools> wgrant: what's different with the 3.0 format then?
[09:29] <wgrant> bigjools: New types of files.
[09:29] <wgrant> And massive incompatibility.
[09:30] <wgrant> And new compression formats.
[09:30] <wgrant> (although we're following dak and not supporting lzma, only gzip and bzip2, at cjwatson's direction)
[09:31] <bigjools> lzma dropped entirely?
[09:31] <bigjools> interesting
[09:31] <wgrant> Right. Trivial regex change to bring it back if we need to.
[09:31] <wgrant> (lzma deb support remains)
[09:33] <wgrant> Oh. Curses. SourcePackageFormat already exists.
[09:34] <wgrant> Any suggestions on what to call it?
[09:35] <bigjools> SourceUploadFormat?
[09:36] <wgrant> That's even more of a lie than the old SourcePackageFormat.
[09:36] <wgrant> It's a property of the source package, and nothing really to do with the upload.
[09:37] <bigjools> yeah
[09:37]  * bigjools -> OTP
[09:38] <wgrant> OTP?
[09:39] <wgrant> This #ubuntu-devel is going to get messy!
[09:39] <wgrant> +discussion
[09:43] <wgrant> (my best idea is to rename the old SourcePackageFormat to SourcePackageType or something like that, as it is only mentioned on 7 lines, but I guess that would get me even more murdered than I will anyway)
[10:06] <bigjools> wgrant: ok back (On The Phone BTW)
[10:06] <wgrant> bigjools: Oh, right.
[10:06] <bigjools> wgrant: +1 on renaming SourcePackageFormat
[10:07] <wgrant> bigjools: Great, 'cause I've done it.
[10:07] <bigjools> heh
[10:07] <bigjools> SourcePackageType ?
[10:07] <wgrant> That's the one.
[10:07] <bigjools> perfecto
[10:07] <bigjools> one day we might even start using it for something useful and support RPM
[10:07] <wgrant> Perhaps.
[10:10] <wgrant> Hm.
[10:10] <wgrant> FS corruption.
[10:10] <wgrant> That is not good.
[10:11] <wgrant> (product.py started complaining of SyntaxErrors, when I hadn't touched it. it is now full of garbage)
[10:11] <wgrant> I wonder what else just got eaten.
[10:14] <bigjools> ext4? :)
[10:14] <wgrant> indeed.
[10:14] <wgrant> But the file size changed.
[10:15] <wgrant> So it's not the OMG KITTENS ARE DIEING BUT ONLY THREE PEOPLE HAVE REPORTED IT bug.
[10:32] <wgrant> bigjools: Can I safely raise an UploadError in one of NU's error generators if I want to reject the upload and stop right there, or do I have to move the check to another function?
[10:32] <bigjools> good question
[10:32]  * wgrant traces it all the way up.
[10:32] <bigjools> suck it and see I guess
[10:33] <wgrant> Just this last failure case to handle...
[10:33] <bigjools> wgrant: EarlyReturnUploadError
[10:34] <wgrant> bigjools: Ah, handy. Thanks.
[10:34] <wgrant> (NU is too convoluted)
[10:34] <bigjools> no kidding
[10:35] <bigjools> it was refactored big-time a couple of years ago
[10:35] <wgrant> I recall.
[10:35] <wgrant> But that didn't get finished.
[10:35] <bigjools> and it improved things a lot, if you can beloeve that
[10:35] <wgrant> I cannot.
[10:35] <bigjools> :)
[10:35] <wgrant> Maybe I will revert the tree later and realise how lucky I am.
[10:37] <jml> ahh, nascentupload
[10:37] <wgrant> jml: You were privileged to be able to experience it before leaving engineering.
[10:38] <jml> wgrant, indeed.
[10:38] <jml> wgrant, I hope I made an improvement
[10:38]  * wgrant isn't touching those bits.
[10:41] <wgrant> NU might not be so bad if it was properly tested, too.
[11:00] <deryck> Morning, all.
[11:10] <wgrant> bigjools: OK, it seems that most of the rest of my FS survived. I've just finished off that change.
[11:12] <bigjools> wgrant: most of? :)
[11:13] <wgrant> bigjools: Well, I've only found that one eaten file. All the packaged files check out fine, my branches are fine, and fsck is happy, so I presume most of it is OK.
[11:13] <wgrant> But it seems odd that there would be only file, given that I haven't written to it.
[11:14] <bigjools> yes
[11:52] <wgrant> bigjools: Broken sample data is currently being fixed :/
[11:53] <bigjools> wgrant: what's broken?
[11:54] <wgrant> bigjools: There is a firefox-0.9.2.orig.tar.gz used in tests (note the '-' in place of '_'). That previously worked, as the type check just looked for endswith('.orig.tar.gz'). But now it uses a regex which needs a '_'.
[11:55] <bigjools> wgrant: this is in the data/suite/* stuff?
[11:56] <wgrant> bigjools: No, no. archiveuploader would never accept that. This is in a doctest that grabs an existing LFA and SPR.addFile()s.
[11:56] <bigjools> ah ok
[12:17]  * wgrant directs significant volumes of hate at even more crackful sampledata.
[12:29] <leonardr> jml, you seem to know a lot about rickspencer3's whereabouts. do you know where in the world is rickspencer3 today?
[12:30] <jml> leonardr, if I had to guess, I'd say he's in the west coast of the continental united states of america.
[12:30] <leonardr> hmm
[12:30] <leonardr> i will hunt him down!
[12:45] <jml> leonardr, I only half-followed your recent conversation with al-maisan -- is exposing a dict over the API really that tricky?
[12:45]  * al-maisan cocks up one ear
[12:45] <leonardr> jml: it's never been done before. making the lazr.restful changes to expose a dict should not be *that* difficult
[12:46] <leonardr> but al-maisan wanted to expose a dict _of lists_
[12:46] <jml> leonardr, why is that important?
[12:46] <wgrant> Wasn't it a dict of Entries?
[12:47] <leonardr> al-maisan can correct be, but i believe it was a dict that mapped a person to a list of strings
[12:47] <jml> there are now two interesting branches of this conversation :)
[12:48] <jml> leonardr, isn't a dict of lists a fairly standard json construct?
[12:48] <al-maisan> leonardr: actually it was a dict {pocket : object } .. let me check again
[12:48] <jml> al-maisan, it was mapping a pocket enum to a branch object iirc.
[12:48] <al-maisan> that would be right
[12:49] <leonardr> i don't remember this. i remember people mapped to the types of reviews they'd been assigned to
[12:50] <leonardr> anyway, the problem is that the arguments to a named operation have to be described in wadl, and recursively defined data types are difficult to define in wadl
[12:50] <jml> leonardr, ahh, I see.
[12:50] <leonardr> a recursively defined data type is a sign that things are getting too complicated and you should rethink your resource design
[12:51] <jml> leonardr, I can see the point
[12:51] <wgrant> Ahhhh. Tests pass a little better when one of the data files used in a few tests *hasn't* been corrupted by a stupid filesystem.
[12:51] <jml> as much as I like "for your own good"-style design.
[12:51] <jml> *dislike*
[12:51] <jml> (one of them Freudian mothers)
[12:52] <al-maisan> leonardr, jml: this is what I was trying at that time: http://pastebin.ubuntu.com/300148/
[12:52] <leonardr> jml: what i've said is kind of seat-of-pants stuff. my knowledge of that part of lazr.restful is cached on disk.
[12:53] <jml> leonardr, heh
[12:54] <leonardr> somewhat literally, in that i would have to go into the code and re-learn it
[12:54] <al-maisan> leonardr: : so, the problematic part in this case was the return type of the collection returned.
[12:55] <al-maisan> anyway, since that did not work I resorted to: https://code.edge.launchpad.net/~al-maisan/launchpad/352094
[13:30] <jml> leonardr, I know the feeling.
[14:17] <mpt> What's a "package set"?
[14:19] <mpt> I see <https://dev.launchpad.net/Soyuz/Specs/PackagesetsAndDistroseries> and <https://dev.launchpad.net/Soyuz/Specs/PackagesetsAndDistroseries/OriginalAnalysis>, but they don't seem to mention what a package set is
[14:20] <al-maisan> mpt: https://dev.launchpad.net/VersionThreeDotO/Soyuz/StoryCards#packagesetacl
[14:20] <mpt> ahh, security
[14:20] <mpt> thanks al-maisan
[14:21] <al-maisan> you are welcome :)
[14:21] <Ursinha> hey bigjools-lunch :) can you tell me what's exactly the meaning of the pending milestone you have in soyuz? after getting back from lunch, of course :P
[14:32] <bigjools> Ursinha: one word: "Celso"
[14:32] <Ursinha> bigjools, oh crap
[14:32] <Ursinha> bigjools, but do you know his rationale behind it?
[14:32] <bigjools> Ursinha: it was a place for him to put stuff he didn't want to forget about
[14:32] <Ursinha> bigjools, I see
[14:32] <Ursinha> bigjools, you're not using it?
[14:33] <bigjools> and it turned into a general pool of bugs that we need to sort out
[14:33] <bigjools> sort of
[14:38] <Ursinha> bigjools, I see
[14:39] <Ursinha> bigjools, I asked because I have some bugs that are depending on others to be fixed, not our bugs, and as we don't have a Pending status I considered using a Pending milestone
[14:39] <bigjools> Ursinha: as you know, things have changed focus recently so it's fallen to the side a little.  But its general concept will be re-used for LP generally soon.
[14:39] <bigjools> ah
[14:40] <bigjools> go for it
[14:40] <Ursinha> cool
[14:40] <Ursinha> thanks bigjools :)
[14:40] <bigjools> any time
[14:44] <gary_poster> bigjools: hi!  I have this on my QA page from Francis.  Am I right that I can push it over to your guys' page? "r9807 [r=adeuring][ui=none][bug=458833] Protect Build attributes using launchpad.Edit. (Landed on behalf of Julian.)"
[14:45] <bigjools> gary_poster: yes please do
[14:45] <gary_poster> bigjools: cool thanks
[14:49] <bigjools> gary_poster: are you going to stick it on my QA wiki page?
[14:50] <gary_poster> bigjools: sorry yes.  Trying to reply to mthaddon on a nother channel then was going to do that.  If you want to do it before me, feel free. ;-)
[14:50] <bigjools> gary_poster: yeah I can do that, what's your test plan URL?
[14:51] <gary_poster> bigjools: thanks https://dev.launchpad.net/FoundationsTestPlan/3.1.10
[14:51] <bigjools> shoulda guessed that really :)
[14:51] <gary_poster> :-)
[14:52] <bigjools> gary_poster: umm release yer edit lock :)
[14:52] <gary_poster> bigjools: sorry done
[14:52] <bigjools> ta
[14:52] <bigjools> done
[15:13] <wgrant> bigjools: Have you a definitive answer from cjwatson?
[15:13] <bigjools> wgrant: not definitive, but there's no clear requirement that I can see for putting this in 3.1.10
[15:14] <bigjools> wgrant: if the default dpkg format changes then he points out that we're fucked
[15:15] <wgrant> bigjools: Right. And that was planned to happen.
[15:15] <wgrant> But might not be any more... hard to tell.
[15:15] <sinzui> bac: EdwinGrubbs: barry: I was able to test the product-release-finder. 1 bug is fixed, the other is not. I am going to work on the bad item
[15:16] <bigjools> wgrant: did stub review your db changes
[15:17] <wgrant> bigjools: He commented that the table name was a bit odd, but that it was a Soyuz decision, and also that it should use an enum rather than a string.
[15:17] <wgrant> The latter is done, and you seem fine with the former.
[15:18] <bigjools> wgrant: yeah it follows some convention I guess
[15:18] <bigjools> wgrant: so I am thinking that we should land the schema changes only, in case the brown smelly stuff hits the fan this month
[15:18] <wgrant> The cut down (that is, without the big archiveuploader changes) diff (excluding sample data) is ~500 lines.
[15:20] <barry> sinzui: cool
[15:20] <bigjools> wgrant: we don't even need that, we can just land the sql patch on db-devel
[15:20] <bigjools> that's the thing that would stop a CP if it came to that, so this increases our options
[15:21] <wgrant> True.
[15:22] <bigjools> so if you can make a separate branch with that, create an MP, get jml and stub to review it, I'll land it for you
[16:48] <bac> sinzui, barry: here are the portlets called on the distroseries page:  http://pastebin.ubuntu.com/307675/
[16:48] <bac> sinzui, barry: for karmic, all render but the third one:  https://edge.launchpad.net/ubuntu/karmic/@@+table-milestones
[16:49] <sinzui> bac: I bet it is the status counts for bugs and blueprints
[16:50] <sinzui> bac: barry: The counts are a loop in python, Maybe the code can be made faster, or we can change the model to provide the summary. I prefer the first option because the code is also used to count assignees
[16:51] <sinzui> ps. you rock bac
[17:25] <Ursinha> hi sinzui, about the BAD items, I see you're working on bug 415595. do you know about the others?
[17:25] <mup> Bug #415595: Product release finder should import all files <story-product-release-finder> <Launchpad Registry:In Progress by sinzui> <https://launchpad.net/bugs/415595>
[17:25] <sinzui> We are working on all bad items
[17:26]  * sinzui has a fix for Bug #415595
[17:26] <mup> Bug #415595: Product release finder should import all files <story-product-release-finder> <Launchpad Registry:In Progress by sinzui> <https://launchpad.net/bugs/415595>
[18:11] <Ursinha> sinzui, right! in your opinion, any of these are release blockers?
[18:11] <kfogel> http://paste.ubuntu.com/307767/
[18:12] <kfogel> anyone know why my rocketfuel-get is failing as per above paste?
[18:12] <barry> sinzui: i'm back now; what can i look at?
[18:12] <kfogel> "bzrlib.errors.BzrError: xmlrpc protocol error connecting to https://xmlrpc.edge.launchpad.net/bazaar/: 502 Bad Gateway" ?
[18:12] <sinzui> Ursinha: I think the timeouts on distroseries defintely are
[18:13] <sinzui> Ursinha: the release finder could slip
[18:13] <Ursinha> sinzui, right
[18:13] <sinzui> The bad CSS must be fixed or we can revert the entire branch
[18:16] <kfogel> jml: curious if you recognize the error (see my paste a few lines above)
[18:17] <jml> kfogel, it rings a bell. are you behind a proxy?
[18:17] <kfogel> jml: indeed I am.  But I could easily not be.
[18:18] <jml> kfogel, try that.
[18:28] <Ursinha> sinzui, are you working in the old bug numbers or have you opened new ones?
[18:28] <Ursinha> by you I mean registry team
[18:29] <sinzui> Ursinha: I reopened the old because because our changes do not represent a partial fix
[18:38] <bac> barry: ping
[18:39] <barry> bac: pong
[18:42] <Ursinha> sinzui, and the others?
[18:43] <sinzui> I am testing the one that I can test.
[18:43] <sinzui> Ursinha: I do not know how to test salgado's change. I am not even sure it is a regisrty issue
[18:47] <sinzui> barry: ping
[18:47] <Ursinha> sinzui, actually I'm talking about the BAD items you say registry team is working on. I see you reopened the bug of yours, want to know about the others :)
[18:48] <sinzui> They are inprogress I think
[18:48] <barry> sinzui: pong
[18:48] <sinzui> Ursinha: https://edge.launchpad.net/launchpad-registry/+milestone/3.1.10
[18:48] <sinzui> ^ sort by status
[18:48]  * Ursinha looks
[18:49] <sinzui> barry: I was going to ask for you help with new member + mailing list tests, but I get an oops with my test candidate: https://staging.launchpad.net/~haibunku
[18:49] <Ursinha> thanks sinzui
[18:51] <barry> sinzui: that oops looks related to my team privacy portlet change
[18:51] <sinzui> yes
[18:51] <barry> sinzui: like. some code didn't get updated perhaps?
[18:52] <sinzui> but I saw your style fix on edge it it worked
[18:52] <barry> sinzui: does it work in lp.dev?
[18:52] <barry> (i should try it)
[19:02] <sinzui> barry: staging is borked
[19:02] <barry> sinzui: gotcha
[19:02] <sinzui> barry: db-deel has the right template, but not the right view
[19:03] <sinzui> barry: did you land the fix in two branches?
[19:03]  * sinzui sees the visibility_portlet_class in devel but not db-devel
[19:03] <kfogel_> jml: urgk.  this one ring a bell to you? http://paste.ubuntu.com/307835/  "bzrlib.errors.BzrCheckError: Internal check failed: Cannot add revision(s) to repository: missing chk node(s) for parent_id_basename_to_file_id maps"  (I've gotten out from behind the proxy now.)
[19:03] <barry> sinzui: i don't think so.  i had two bugs each with a branch but that particular feature should have landed in one branch
[19:03] <barry> sinzui: oh, that's sick
[19:04] <jml> kfogel_, umm, no, sorry.
[19:04] <jml> kfogel_, that's #bzr territory
[19:04] <barry> sinzui: i'm grabbing db-devel now
[19:05] <sinzui> barry: ../db-devel/lib/lp/registry/browser/person.py line 3248 should be our missing method
[19:07] <barry> sinzui: how did registry/templates/team-index.py get the change but not browser/person.py?
[19:07] <barry> sinzui: oh wait
[19:08] <sinzui> barry: gremlins from the kremlin? Aliens for Mars? The Illuminati?
[19:08] <barry> sinzui: db-devel's team-index.pt did not get the change
[19:08] <sinzui> oh, I revered the issue?
[19:09] <kfogel_> jml: thought probably -- but you did so well with the last question that I wanted to ask :)-.
[19:09] <barry> sinzui: i just bzr-tool-grep'd db-devel.  there's no visibility_portlet_class in the code at all
[19:09] <barry> sinzui: so, wtf is staging running?!
[19:52] <Ursinha> hi noodles775, are you there?
[19:52] <Ursinha> hmm, no
[19:53] <Ursinha> is it just me or edge is really slow?
[19:53] <rockstar> Ursinha, I've noticed it's really slow as well.
[19:54] <Ursinha> rockstar, maybe we should poke a losa
[19:55] <rockstar> Ursinha, yeah, maybe.  Forking to do that is not something I have bandwidth for right now though.
[19:55] <Ursinha> hehe
[19:55] <Ursinha> mbarnett, hey
[19:56] <mbarnett> Ursinha: heya
[19:56] <mbarnett> Ursinha: we are in the midst of a rolling update
[19:56] <mbarnett> Ursinha: which is why edge is a bit slow
[19:56] <Ursinha> mbarnett, oic
[19:56] <Ursinha> rockstar, ^
[19:57] <Ursinha> mbarnett, for how long will it be like this?
[19:57] <mbarnett> Ursinha: i'll check on the progress
[19:57] <Ursinha> mbarnett, cool
[19:58] <beuno> barry, can you think of any reason why we wouldn't want to expose what mailing lists people are subscribed to on ther profiles?
[19:59] <Chex> Ursinha: sorry, one of the edge workers was slow to come up, should be OK now, let me know if it isn't?
[19:59] <mbarnett> what he said!
[19:59] <barry> beuno: for public lists?  i think it would be interesting to know that
[19:59] <Ursinha> sure mbarnett and Chex
[19:59] <Ursinha> thanks both
[19:59] <Ursinha> :)
[19:59] <beuno> barry, perfect answer
[19:59] <barry> beuno: facepad!
[19:59] <thumper> why has no-one booted buildbot into touch?
[20:00] <thumper> the db_devel builder is still fubared
[20:00] <thumper> and we're in testfix because of it
[20:00] <thumper> it has been over 12 hours!!!!!!
[20:00] <beuno> barry, don't reveal my secret plan!
[20:00] <barry> beuno: as long as it's not spacepad :)
[20:02] <beuno> barry, do we store ML messages on the db at all?
[20:03] <barry> beuno: in general, no.  we only store ones that are held for moderation
[20:03] <jml> thumper, hi
[20:03] <thumper> jml: hi
[20:04] <beuno> barry, how complicated would it be to store subjects and authors?
[20:04] <jml> thumper, up for a skype call?
[20:04] <thumper> jml: how long do you need?
[20:04] <thumper> jml: have normal stand up soon
[20:05] <jml> thumper, ~30 mins. When's your standup?
[20:05] <thumper> in 10 minutes
[20:05] <barry> beuno: you'd probably also want message-ids.  i think not complicated, but i don't know how expensive it would be (performance- or space- wise)
[20:05] <beuno> barry, and date  :)
[20:06] <barry> beuno: you probably just want to store successfully posted messages, so you'd need to hook into that process, but i think not hard to do
[20:06] <barry> beuno: yep
[20:06] <beuno> barry, so we could tell people what kind of traffic a ML has, and what the latest messages where
[20:07] <beuno> barry, secondly, are there any good proprietary archiving softwares?  (you've said there aren't any open ones)
[20:07] <barry> beuno: well, if you did that, you'd /have/ to give them links to those messages.  /me remembers our last conversation
[20:07] <jml> thumper, is after the standup ok?
[20:07] <thumper> jml: yeah, I think so
[20:07] <barry> beuno: i'm not familiar with any commercial archivers
[20:07] <jml> thumper, cool. can you ping me please?
[20:08] <thumper> yep
[20:08] <beuno> barry, ok, thanks
[20:10] <mwhudson> morning
[20:14] <james_w> morning mwhudson
[20:14] <james_w> mwhudson: thanks for your work on branch-distro.py
[20:14] <mwhudson> james_w: np, is everything working ok for you?
[20:15] <james_w> seems to be fine
[20:15] <mwhudson> cool!
[20:16] <thumper> rockstar: want to host?
[20:16] <rockstar> thumper, sure.
[20:17] <rockstar> mwhudson, abentley, skype?
[20:17] <mwhudson> rockstar: yep
[20:26] <Ursinha> hello gary_poster, could you triage bug 423447, please?
[20:26] <mup> Bug #423447: Trying to add an email that's already registered as a SSO account but not a person, oopses <oops> <Launchpad Foundations:New> <https://launchpad.net/bugs/423447>
[20:29] <gary_poster> Ursinha: a bit busy on buildbot right now
[20:29] <Ursinha> ok gary_poster, no problem
[20:32] <thumper> jml: ready
[20:42] <jml> thumper, oh sorry
[20:43] <gary_poster> Ursinha: triaged
[20:44] <Ursinha> gary_poster, thank you
[21:18] <maxb> gary_poster: Hi! Good news: ztk-2.5 still fine as of my weekend re-test. Bad news: There's a new test, xx-resetpassword-for-sso-account.txt, on devel that *requires* canonical-identity-provider to pass - bit of a downer for me!
[21:19] <maxb> (sorry to pick on you, but salgado isn't here, and it was [r=gary] :-) )
[21:19] <gary_poster> maxb: heh and urg
[21:20] <maxb> Let me know if you'd like it filed as a bug
[21:20] <gary_poster> maxb: I'm swamped ATM.  Make a bug for me, and I'll assign it?  Yes please
[21:27] <maxb> Filed as bug 471724
[21:27] <mup> Bug #471724: Test lib/lp/registry/tests/../stories/foaf/xx-resetpassword-of-sso-account.txt fails if canonical-identity-provider absent <Launchpad Foundations:New> <https://launchpad.net/bugs/471724>
[21:52] <wgrant> jml: Can you please review https://code.launchpad.net/~wgrant/launchpad/distroseries-source-format-selection-db/+merge/14304?
[21:58] <jml> wgrant, will do.
[21:58] <jml> wgrant, if not tonight, first thing tomorrow
[21:59] <wgrant> jml: Thanks.
[22:00] <jml> wgrant, np
[22:15] <mars> silly question: do we still use the lpwindmill.py script for windmill test authoring?
[22:15] <mars> if so, where may I find the documentation on the wiki?
[22:19] <mars> rockstar, if you are still around: have you written any windmill tests recently?
[22:45] <rockstar> mars, I've ported some, am probably going to write some before the sprint, why?
[22:45] <mars> rockstar, I've been trying to test the YUI 3 upgrade, and was going to run the windmill suite.  However, I can't run windmill, or start the test authoring tools
[22:45] <rockstar> mars, how are you doing it?
[22:46] <mars> and I can't find anything about writing windmill tests on the wiki
[22:46] <rockstar> mars, I think we need to update them.
[22:46] <mars> rockstar, $ bin/py lib/lp/scripts/utilities/lpwindmill.py firefox http://launchpad.dev:8085
[22:46] <rockstar> mars, if you'd like, I can call you and get you up to speed on the new way of running windmill.
[22:46] <rockstar> mars, yeah, it's changed recently.
[22:47] <mars> rockstar, that's ok, I don't have skype.  Windmill starts using bin/test, but I'm wondering about authoring
[22:47] <mars> ok
[22:47] <rockstar> mars, no idea how to use the authoring tools.  I've never used them.
[22:47] <mars> rockstar, how did you write windmill tests in the past?
[22:48] <rockstar> mars, vim
[22:49] <mars> rockstar, I mean, did you use the lpwindmill script to set up a test server on port 8085, then start poking at the DOM with the windmill interface?
[22:49] <rockstar> mars, no, I just had my dev server and firebug, and would write the test, run it, fix it, etc.
[22:50] <mars> ok
[22:50] <mars> rockstar, after upgraded to Karmic, I'm getting SSL errors when I try to run the windmill suite.  It looks like the bin/test suite is not using port 8085, at least, not to log into the site
[22:51] <rockstar> mars, turn off your dev server when you run the tests.
[22:51] <rockstar> Windmill and the dev server have never really played well.
[22:51] <mars> I thought we fixed that :(
[22:51] <thumper> mwhudson: what do you need to qa your last two items?
[22:51] <rockstar> mars, not that I've ever seen.
[22:51] <mars> I'll try again, doubly sure
[22:51] <mwhudson> thumper: oh i did one
[22:51] <mwhudson> thumper: and the other i need some queries running i guess
[22:52] <mars> "Error in sys.excepthook:"  oops.
[22:52] <mars> :)
[22:53] <wgrant> Can I access the API anonymously yet without patching waddlib to use the browser-accessible root?
[22:56] <mars> wgrant, you used the word "yet" - have you heard of  a plan to allow such access?
[22:56] <mars> just curious
[22:56] <mars> I've been away for a while
[22:56] <rockstar> wgrant, I'm not aware of any work done.
[22:56] <wgrant> mars: Well, I filed a bug about it. It was scheduled for 3.0 (I think). It didn't happen.
[23:02] <mwhudson> do we still have the problem where when a query times out the time for the query that tripped the limit is not added to the sql time in the oops report
[23:02] <mwhudson> ?
[23:02] <wgrant> I thought that was fixed for 3.0.
[23:02] <wgrant> But I was about to ask about that.
[23:03] <mwhudson> yeah i thought so too
[23:05] <mars> rockstar, you were right, was the dev server running as well
[23:06] <wgrant> mwhudson: What was the last query?
[23:06] <rockstar> mars, yeah, the biggest problem with Windmill is knowing all its quirks.  Once you know all the errors it shows, you know why you made it mad.
[23:06] <rockstar> mars, this is also a great example of Stockholm syndrome.
[23:06] <mwhudson> wgrant: select person.* from BugSubscription, Person WHERE Person.id = BugSubscription.person AND BugSubscription.bug = 417842 AND (1=1) ORDER BY Person.displayname
[23:07] <mwhudson> wgrant: unless there is a truly insane number of subscribers that doesn't seem like it should be that slow
[23:07] <mars> rockstar, LOL
[23:09] <wgrant> mwhudson: That shouldn't be too bad, but I have to wonder why it is executing that at all.
[23:09] <wgrant> mwhudson: Since that is loaded via AJAX in a portlet later.
[23:09] <mwhudson> wgrant: yeah
[23:10] <mars> rockstar, the funny thing is, I know *exactly* where this tool fits into the big picture now.  I can start thinking of ways to make it better
[23:10] <rockstar> mars, cool.  Let me know how I can help.
[23:19] <mwhudson> wgrant: that query is fast apparently so who knows what's going on
[23:21] <wgrant> mwhudson: Using the very handy ++oops++ locally, I can see some pretty bad looking queries (selecting all bugsubscriptions for bugs that are duplicates of the current bug, and prejoining all people referred to by those subscriptions)
[23:21] <wgrant> There is absolutely no reason to do that.
[23:22] <mwhudson> wgrant: indeed, but they're acutally pretty quick
[23:22] <wgrant> Hm. sad.
[23:22] <mwhudson> so it's bad, but not the problem
[23:23] <mwhudson> wgrant: that terribly looking prejoin query takes 77.0 ms
[23:24] <wgrant> mwhudson: Blah.
[23:24] <mwhudson> and it would be so nice if a 77ms query was unacceptable but ...
[23:25] <wgrant> While there are queries going around, how do I convince somebody to run 'SELECT DISTINCT dsc_format FROM sourcepackagerelease' on production? I'd like to see just how broken the data there is, as the early sample data is shocking.
[23:25] <mars> :D
[23:25] <mwhudson> wgrant: mbarnett is your friend i guess
[23:26] <mwhudson> wtf
[23:26] <mwhudson> factory.makeBug() in 'make harness' seems to be broken
[23:27] <wgrant> mbarnett: Hi there. Can I convince you to give me the result of 'SELECT DISTINCT dsc_format FROM sourcepackagerelease' on production?
[23:27] <mbarnett> wgrant: sure sure
[23:27] <mwhudson> IntegrityError: duplicate key value violates unique constraint "bugnotification__bug__message__unq"
[23:27] <wgrant> mwhudson: Awesome.
[23:27]  * wgrant tries.
[23:28] <wgrant> Confirmed.
[23:28] <wgrant> WTF.
[23:28] <mbarnett> wgrant: http://pastebin.ubuntu.com/308005/
[23:29] <wgrant> mbarnett: Excellent, thanks.
[23:29] <mbarnett> wgrant: welcome
[23:29] <wgrant> It's wrong, but easily fixed when we need to.
[23:29]  * mwhudson makes schema to see if that helps
[23:29] <wgrant> mwhudson: It doesn't.
[23:30] <wgrant> mwhudson: I've got a fresh one here and it's broken like that.
[23:33] <mwhudson> wgrant: wtf
[23:34] <wgrant> mwhudson: That too.
[23:34] <mwhudson> it's used in the tests a fair bit
[23:34] <mwhudson> maybe differences between test and dev databases
[23:35] <mwhudson> what the heck!
[23:36] <wgrant> I tried ftest-playground already.
[23:36] <wgrant> Same problem.
[23:36] <wgrant> That was my first guess.
[23:36] <mwhudson> bugnotification is empty before this happens
[23:36] <wgrant> A subscriber might be doubled up somewhere?
[23:38] <mwhudson> no, the index is just on message and bug
[23:39] <wgrant> subscriber meaning Z3 subscriber, not BugSubscriber.
[23:39] <mwhudson> ah
[23:39] <mwhudson> yes possibly
[23:44] <mwhudson> wgrant: yeah, seems possible
[23:45] <wgrant> I don't know too much about the subscription system, though.
[23:49] <mwhudson> wgrant: yes, seems all subscribers are added twice in make harness
[23:50] <wgrant> mwhudson: Ah, that's easy.
[23:52] <mwhudson> wgrant: easy to fix>
[23:52] <mwhudson> ?
[23:53] <wgrant> mwhudson: If you look at canonical.database.harness._get_locals, you'll see it calls execute_zcml_for_scripts, and then executes script.zcml.
[23:53] <wgrant> But execute_zcml_for_scripts appears to execute script.zcml itself.
[23:53]  * wgrant tests.
[23:54] <wgrant> But that seems far too easy.
[23:55] <mars> bad smell in the windmill python suite: the client object has to be passed around everywhere.  Need a context object or something.
[23:57] <wgrant> mwhudson: Commenting out the script.zcml invocation in canonical.database.harness._get_locals fixes it, and the appropriate bugnotification is still created.
[23:57] <wgrant> But I must be missing something.
[23:58] <mwhudson> oh i think maybe xecute_zcml_for_scripts executes more zcml than it used to
[23:58] <wgrant> Possibly.
[23:58] <wgrant> It certainly executes script.zcml itself.
[23:59]  * wgrant annotates.