[00:03] <lifeless> wgrant: what do you think? closable?
[00:03] <wgrant> lifeless: Needs testing. If it's not closable, then it's a security bug.
[00:03]  * spm needs to fix his losa highlight. "closable" shoudn't be a highlighter....
[00:03] <lifeless> how about closeable?
[00:04] <wgrant> lifeless: It's possibly from back in the days when one got notified of duplicates of the master bug if one was subscribed to a duplicate.
[00:04] <lifeless> :P
[00:04] <spm> ha
[00:04] <lifeless> wgrant: yes, its old; thus my question ;)
[01:08] <lifeless> wgrant: are you on launchpad-security now?
[01:08] <lifeless> wgrant: if not that would explain your confusion when I mentioned the bug before
[01:09] <wgrant> lifeless: I have been for a while.
[01:09] <wgrant> I get launchpad security mail.
[02:18] <lifeless> sinzui: I guess you're off to family time, just saw your reply to my review; if you do want to discuss it now, I'd be delighted
[02:18] <lifeless> otherwise, if I don't hear from you I'll reply as much as I can think of via mail and look for you my morning tomorrow
[02:36] <lifeless> hmm
[02:36] <lifeless> where are my daily oops reports for prod :(
[02:47] <lifeless> no landings to devel since tuesday? wtf
[02:49] <poolie> hi lifeless
[02:49] <lifeless> hiya
[02:51] <poolie> shall we talk now? pots?
[02:51] <poolie> schooners?
[02:52] <lifeless> sure
[02:53] <lifeless> skype is easiest for me
[02:57] <poolie> lifeless, https://bugs.launchpad.net/bugs/739772
[02:57] <_mup_> Bug #739772: Question should be available via the API <Launchpad itself:In Progress by jcsackett> < https://launchpad.net/bugs/739772 >
[03:51] <lifeless> jcsackett: you're going to hate me :)
[03:52] <lifeless> jcsackett: https://bugs.launchpad.net/launchpad/+bug/741440
[03:52] <_mup_> Bug #741440: merge proposal diff only shows once per page load <regression> <Launchpad itself:Triaged> < https://launchpad.net/bugs/741440 >
[04:16] <LPCIBot> Project windmill build #96: STILL FAILING in 1 hr 7 min: https://lpci.wedontsleep.org/job/windmill/96/
[04:18] <StevenK> Windmill, you make me sad.
[04:19] <StevenK> Actually, gina's doctest makes me positively suicidal.
[04:34] <StevenK> I think I broke it, gina has been running for 11 minutes.
[04:35] <StevenK> No, it's just OOPSing constantly
[04:40] <wgrant> :( fake forms
[04:44]  * StevenK burns gina.txt, and then douses it with kerosene.
[04:46] <wgrant> Watch out for gina-multiple-arch.txt
[04:46] <wgrant> It may avenge its brother.
[04:56] <StevenK> Haha
[04:57] <StevenK>   Ran 1 tests with 1 failures and 0 errors in 18 minutes 25.669 seconds.
[04:57] <lifeless> ok, time to write more deploy scripts
[05:10] <wgrant> Hmm. Lots of theme updates.
[05:10] <wgrant> New Ubuntu panel logo, new speaker icons, messaging indicate is now blue...
[05:10] <wgrant> Wallpaper is... very slightly different.
[05:10] <wgrant> What.
[05:12] <wgrant> It is almost unnoticably different :/
[05:13] <StevenK> Then how did you notice?
[05:13] <wgrant> "almost"
[05:19] <LPCIBot> Yippie, build fixed!
[05:19] <LPCIBot> Project devel build #571: FIXED in 5 hr 22 min: https://lpci.wedontsleep.org/job/devel/571/
[05:27] <StevenK> Uhhh, why is gina's doctest testing Python math?
[05:29] <lifeless> because twisted numpy accelerator for ssh changes global fnuctions
[05:32] <StevenK> That's so not related.
[05:32] <StevenK> lifeless: Can haz review?
[05:59] <StevenK> Methinks that means 'No'
[06:25] <lifeless> StevenK: check your mail
[06:26] <StevenK> lifeless: Thanks
[06:29] <poolie> do mps no longer show the diff inline in the page and only in the popup?
[06:30] <poolie> or is this just the problem that the diff is sometimes missing?
[06:34] <wgrant> The diff should always be there.
[06:38] <lifeless> poolie: mps don't have a popup; bug pages referencing mps have a popup
[06:39] <poolie> bug search timed out again
[06:40] <poolie> ok, i think it was just https://bugs.launchpad.net/launchpad/+bug/734629 then
[06:40] <_mup_> Bug #734629: empty/useless diff shown for merged proposals <code-review> <confusing-ui> <mail> <Launchpad itself:Triaged> < https://launchpad.net/bugs/734629 >
[07:24] <huwshimi> lifeless: I have a branch that adds an ajax time log. Here's a screen cap: http://people.canonical.com/~huwshimi/ajax_time_log.ogv
[07:24] <huwshimi> lifeless: I haven't figured out a way to add a useful identifier to that log yet though
[07:25] <huwshimi> lifeless: I'd like some suggestions about what other useful info you'd like to see there
[07:34] <lifeless> huwshimi: ----awesome----
[07:34] <lifeless> huwshimi: url
[07:34] <lifeless> huwshimi: and if it oopses the oops id
[07:41] <poolie> huwshimi, wow
[07:47] <huwshimi> lifeless: Yeah the url is the one I was trying to get before and couldn't. I can get back headers and data though so I should be able to oops info etc.
[07:47] <huwshimi> lifeless: I'll have a look again at the url
[07:47] <lifeless> perhaps we could stash the url in a response header
[07:50] <huwshimi> lifeless: well I'll try without that first, but it's good to know we can do that
[07:54] <stub> BinaryPackageReleaseDownloadCount is updated just over 8 times a second.
[07:55] <lifeless> 24M rows on qastaging.
[07:55] <lifeless> wow
[07:55] <stub> That is a batch job or live?
[07:56] <lifeless> batch I believe
[07:56] <stub> yer... I was wondering if you can translate that directly to downloads, but I don't think it does
[07:57] <StevenK> That's the job that parses librarian logs, I thought
[07:59] <stub> About a million downloads counted per day
[07:59] <lifeless> stub: hows the dbr looking - have we pushed the numbers down at all recently ?
[08:00] <stub> Which I think means every line counted results in an update. That could be much more efficient if we sacrificed a little RAM.
[08:03] <wgrant> stub: We batch the updates.
[08:03] <stub> lifeless: Roughly the same. Some wins - bug notification has dropped off from chewing ~17% of a core to <1%
[08:03] <wgrant> stub: At least it's meant to.
[08:04] <wgrant> We build up a massive dict.
[08:04] <stub> wgrant: But the same row might be updated multiple times in the run?
[08:05] <stub> wgrant: Or does the dict count everything, then the updates are made at the end?
[08:05] <wgrant> stub: It's possible, if the package has been copied.
[08:07] <stub> archivepublisher has dropped off the cpu chewing list too. Was it split into components, or just made awesome?
[08:07] <wgrant> stub: Just made a bit less awful.
[08:07] <lifeless> stub: when was it doing 17%?
[08:07] <LPCIBot> Project windmill build #97: STILL FAILING in 1 hr 9 min: https://lpci.wedontsleep.org/job/windmill/97/
[08:07] <wgrant> stub: Each BPRDC should be updated at most once in each batch.
[08:07] <stub> https://devpad.canonical.com/~lpqateam/dbr/weekly/db-report-2011-03-11-2011-03-18.txt from 2 months ago is what I'm using as a baseline
[08:07] <lifeless> stub: thats probably when we had the bad filter code
[08:08] <jtv> stub: what say you I lower statistics-logging in LoopTuner to DEBUG2?
[08:08] <stub> wgrant: Ok. That makes sense. If it becomes a problem, we could count everything first then do the updates in batches after the count is in.
[08:08] <lifeless> we're going to put the filters back in on monday
[08:08] <stub> jtv: I'm not fussed. If it makes things easier to work with, go for it.
[08:08] <wgrant> stub: We count everything first, but I guess Storm updates each row separately.
[08:08] <jtv> thanks stub
[08:09] <stub> wgrant: oic. It is just there are 1000000 rows to update :)
[08:09] <wgrant> stub: Heh, not quite that many, I hope.
[08:10] <lifeless> wgrant: batch update: insert into temp table (VALUES); select into ...
[08:11] <stub> Hmm... no... only 250k. So each tuple gets updated 4 times per day. Not sure 100% if that translates to 1 insert and 3 updates.
[08:11] <stub> Anyway... not anything to worry about atm....
[08:13] <stub> So 'less aweful' translates to a drop from 70% of a CPU core 2 months ago to no longer being on the list at all.
[08:14] <wgrant> stub: Huh, nice.
[08:15] <stub> appservers have dropped by 10% too, but that might not be statistically significant.
[08:15] <wgrant> stub: ew, distributionmirror shouldn't be that high.
[08:16] <stub> wgrant: no, and I think I have open bugs from me bitching about it in the past ;)
[08:16] <wgrant> stub: Where are you seeing the archivepublisher drop?
[08:16] <wgrant> It's still on yesterday's, at 70%...
[08:16] <bigjools> morning people
[08:16] <wgrant> Morning bigjools.
[08:17] <stub> Ahh crap.... please reverse everything I just said. The tabs where reversed :)
[08:17] <stub> So I guess the old lucille == archivepublisher and no change there
[08:17] <wgrant> stub: lucille turned into archivepublisher
[08:17] <wgrant> With no significant change.
[08:17] <wgrant> Right.
[08:18] <stub> And the appservers are chewing 10% more
[08:18] <stub> And bug notifications sucks dogs balls.
[08:18] <wgrant> Indeed, bugnotification is 40x what it was.
[08:18] <wgrant> Yellow!
[08:20] <lifeless> stub: this is worth a mail to the list +gary -> they want to add the mass filters to prod again; this high utilisation is a red flag for that
[08:20] <stub> k
[08:21] <jtv> wgrant: do we still need commercial-compat.sh?
[08:21] <wgrant> jtv: Yes, until Dapper dies in three months.
[08:22] <jtv> Three months, egad
[08:22] <bigjools> run-parts ...
[08:22] <jtv> hi bigjools.  wgrant: it's run at a somewhat awkward point in cron.publish-ftpmaster, and things would become a lot simpler if I could move it up or down just a bit.
[08:23] <jtv> So I was wondering: does it have to be run after the new dist directories are moved into place?
[08:23] <jtv> Or alternatively, does it have to be run before the ls-lR.gz files are generated?
[08:24] <wgrant> It should be able to run after ls-lR, I think.
[08:24] <jtv> bigjools: seeing 4 streaks of runparts invocations at the moment, 3 of which run twice.  Looking at how that number might be reduced.
[08:24] <wgrant> Let me check.
[08:24] <wgrant> runparts?
[08:24] <bigjools> jtv: hmmm we can surely consolidate some
[08:24] <jtv> I should hope so
[08:25] <bigjools> I thought there should only be 2
[08:25] <bigjools> remember that run-parts orders stuff if you want
[08:25] <jtv> wgrant: I'm rewriting cron.publish-ftpmaster in python, and the plan is to "outsource" a lot of the work to run-parts directories.
[08:25] <wgrant> jtv: Ah.
[08:25] <jtv> bigjools: yes, but there's stuff inbetween that doesn't look like it belongs in run-parts.
[08:25] <bigjools> it's more like adding hooks for non-generic stuff to live in
[08:25] <jtv> Such as moving the dists directory into place: can we move that into run-parts?
[08:26] <bigjools> no, that's generic
[08:26] <bigjools> but we might be able to move things around
[08:26] <wgrant> jtv: So, commercial-compat has to run before ls-lR, and after dists
[08:26] <wgrant> jtv: Unless you make it work on dists.new instead.
[08:26] <jtv> :/
[08:26] <jtv> oh
[08:27] <wgrant> Or delete partner
[08:27] <bigjools> it's odd that nobody has had errors about incomplete PPA dists
[08:27] <bigjools> since we don't do them atomically
[08:27] <wgrant> bigjools: buildds do occasionally.
[08:27] <wgrant> But they update infrequently and quickly.
[08:27] <bigjools> ah interesting
[08:28] <bigjools> on another note, isn't it a royal pita to see your ec2 land succeed and then pqm is in testfix!
[08:28] <wgrant> Yes, someone left it in testfix overnight :(
[08:28] <bigjools> :/
[08:29] <wgrant> It failed like half an hour after I last checked it, and was failed when I started this morning...
[08:29] <wgrant> Which makes me rather sad.
[08:30] <bigjools> StevenK: hello
[08:30] <jtv> bigjools, wgrant: right now the basic structure looks like http://paste.ubuntu.com/584690/
[08:31] <wgrant> jtv: You will ideally be able to move signReleases into publishDistro (for PPAs it's already there)
[08:31] <jtv> 4 stretches of "runparts" code, which is a bit much.  The smallest change I see that would help with that is to move installDists() down one step.
[08:31] <wgrant> We can also hopefully get rid of copyIndices, because it's stupid.
[08:31] <wgrant> What's installDists?
[08:31] <jtv> Moving signReleases into publishDistro doesn't help.
[08:31] <bigjools> why is 4 too much?
[08:31] <jtv> wgrant: installDists moves the dists directories into place.
[08:32] <wgrant> jtv: So, installDists and removeUncompressedListings and signReleases all go into publishDistro.
[08:32] <jtv> bigjools: there's no such thing as "too" much, but maintenance is going to be easier when it's fewer.
[08:32] <bigjools> why?
[08:33] <jtv> Because it's hard to explain exactly what each of those 4 run-parts directories is going to be fore.
[08:33] <bigjools> so naming stuff is hard? :)
[08:33] <wgrant> jtv: I think there's only one run-parts.
[08:33] <jtv> wgrant: what about copyIndices?
[08:33] <wgrant> Post-publication stuff.
[08:34] <wgrant> jtv: Does that put stuff in dists?
[08:34] <jtv> Err
[08:34] <jtv> …
[08:35] <wgrant> That would be a no.
[08:35] <jtv> if [ "$LPCONFIG" = "$PRODUCTION_CONFIG" ]; then
[08:35] <jtv>     echo "$(date -R): Copying the indices into place."
[08:35] <jtv>     rm -f $INDICES/override.*
[08:35] <jtv>     cp $OVERRIDEROOT/override.* $INDICES
[08:35] <jtv> fi
[08:35] <wgrant> So it doesn't have to run before installdists.
[08:35] <jtv> is what it does.
[08:35] <wgrant> So we have this:
[08:35] <wgrant> publishDistro
[08:35] <wgrant> run-parts
[08:35] <wgrant> The end.
[08:36] <wgrant> "if not self.options.security" is implemented by the Python script calling run-parts with an env-var which tells them whether it's a security run or not.
[08:36] <jtv> Well, it's not quite that simple of course because we need to do most of this twice per script run.
[08:36] <wgrant> Long-running scripts can avoid running if the security flag is set.
[08:37] <wgrant> We could also pretend that the concept of a security run doesn't exist.
[08:37] <wgrant> jtv: Why must we do it twice?
[08:37] <jtv> To expedite security uploads.
[08:38] <wgrant> Is that actually used?
[08:38] <jtv> You're in a better position to answer that than I am.  But it's in the original script and it's in the design for its replacement.
[08:39] <jtv> So you could say it's already automatically used, but we don't know whether we rely on it in any way.
[08:39] <wgrant> Keep in mind that this script was written in 2005. Most of the assumptions it makes can probably be brought into question.
[08:39] <wgrant> eg. dsync kill it with fire.
[08:39] <jtv> That's exactly what I'm doing here: questioning the assumptions.
[08:39] <jtv> dsync goes into run-parts where it's not my problem.
[08:39] <wgrant> True.
[08:40] <jtv> Signing of releases is something I'd like to divest myself off as well though.
[08:40] <wgrant> Why?
[08:40] <wgrant> We already have the code to do that.
[08:40] <wgrant> But the primary archive doesn't use it.
[08:41] <bigjools> I don't want jtv's job complicated with that right now
[08:41] <jtv> We already have the code to divest ourselves of it?  Or we already ahve the code to sign releases?
[08:41] <wgrant> jtv: The signing code.
[08:41] <wgrant> PPAs.
[08:41] <bigjools> by all means file a bug and do it, but not in this change
[08:42] <jtv> I also imagine there's the variable of what GPG key is to be used.
[08:42] <wgrant> I think we should be fixing publish-distro before we try to make its wrapper sensible...
[08:42] <bigjools> I disagree
[08:42] <wgrant> The wrapper can be a lot more sensible if it doesn't duplicate functionality that's already in publish-distro.
[08:42] <jtv> What I'm doing is at least bringing out the structure in what the old script does, and allows us to re-think these assumptions.
[08:43] <lifeless> bigjools: btw - we got the go ahead to combine the soyuz (s)ftp services and uploader into one
[08:43] <jtv> Also, at least now we can run tests.  In temporary directories.  Without global setup and writing to /srv/launchpad.net.
[08:44] <bigjools> lifeless: I am fearful but ok
[08:44] <lifeless> bigjools: we can always split it into two again - or optimise
[08:44] <bigjools> lifeless: this will break the "you get an email in a few minutes" thing more often
[08:44] <lifeless> but it will be a simpler initial config, which is important at the moment
[08:45] <bigjools> lifeless: did you ask anyone why they were split like that in the first place?
[08:45] <lifeless> bigjools: you asked elmo, I didn't see a reply from him
[08:45] <bigjools> that's a no then? :)
[08:45] <lifeless> bigjools: if he doesn't know, I suspect noone is left that knows ;)
[08:47] <lifeless> bigjools: we can dig further - I've no objection to more info
[08:47] <bigjools> lifeless: I think it would be wise
[08:47] <lifeless> bigjools: the main point for me is that we have the stakeholder buy in to do whatever tradeoff make the most sense for now
[08:47] <bigjools> just from being burned in the past by seemingly innocuous changes like this
[08:48] <lifeless> bigjools: this one seems pretty big to me :) - if we do it it would be staged, easily reversible etc
[08:48] <bigjools> lifeless: did we get a reply from platform?
[08:48] <lifeless> bigjools: silence (neither a 'whaaa' nor anything specific)
[08:48] <bigjools> I think a direct question would be good then
[08:48] <lifeless> bigjools: marjo I think, said to me that the mail was forwarded to platform directly
[08:49] <bigjools> they may not have seen it
[08:51] <lifeless> bigjools: he cc'd me; I think they have seen it - he pulled out the TL;DR summary for us
[08:52] <bigjools> what is this tl;dr fad
[08:52] <lifeless> bigjools: I'll check with elmo and flacoste and so on when we've finished the single-threaded stack
[08:52] <lifeless> bigjools: too long didn't read?
[08:52] <bigjools> yes I know what it means :)
[08:53] <lifeless> :P
[08:53] <bigjools> lifeless: anyway, go ahead with the change, I've raised any concerns I may have
[08:53] <adeuring> good morning
[08:54] <lifeless> bigjools: I'll drag you into it when we get up to making the uploaders HA during deploys - i don't think any decision needs to be made yet.
[08:54] <lifeless> bigjools: I'm just happy we have a broad set of options
[08:54] <bigjools> lifeless: indeed!
[08:54] <jtv> wgrant: what does dsync-flist do exactly?
[08:54] <bigjools> options are good
[08:54] <bigjools> that's why I run KDE
[08:54] <wgrant> jtv: hardlinks common files.
[08:55] <wgrant> jtv: It saves roughly a megabyte, I believe.
[08:55] <bigjools> ha
[08:55] <jtv> wgrant: sorry just to be clear, that's a megabyte of L2 CPU cache right?  ;-)
[08:55] <wgrant> Heh
[08:56] <jtv> So… could I just simply kill it, drop it from the script, do away with it, no questions asked?
[08:57] <bigjools> I doubt anyone would notice it missing
[08:57] <jtv> Gone.
[08:58] <jtv> Don't security uploads need to germinate?
[08:58] <bigjools> no
[08:59] <jtv> (And by the way, triggering mirrors looks like a prime candidate for "&" in the run-parts script)
[09:00] <jtv> Germination is not generic to all distros, right?
[09:00] <wgrant> Most will probably want it. But they should run the script themselves, since it's fairly specific, and I wish it would get out of our tree.
[09:00] <bigjools> jtv: mirror trigger is very quick
[09:01] <bigjools> germination is distro-specific
[09:01] <bigjools> that script is not really owned by LP even though it's in our tree
[09:01] <jtv> Oh, ISTR back in 2006 we tried to run some of this stuff on a non-Canonical machine and it just froze up trying to connect to each mirror.
[09:01] <jtv> So I sort of remembered it as being slow.
[09:05] <jtv> bigjools: what was your verdict on signing?  run-parts or generic?
[09:06] <bigjools> jtv: run-parts for now since it's less work and won't mess up this change.
[09:06] <jtv> Well I'm not 100% sure it's less work.  I see 2 options:
[09:07] <jtv> 1. Do this in run-parts, and have another script in the same dir that finds and removes the uncompressed Sources/Packages files.
[09:08] <jtv> 2. Implement it in the script itself, and have one run-parts directory less.  (The removing of uncompressed files could also go into the script, or into the next run-parts stretch)
[09:09] <wgrant> bigjools: Oh yeah, it turns out that delayed copies are now much slower than direct copies.
[09:09] <bigjools> wgrant: !
[09:09] <bigjools> "delayed" would imply that :)
[09:09] <wgrant> Since delayed copies still scale by number of BPRs.
[09:09] <wgrant> Heh
[09:10] <bigjools> so if you can guarantee that the security team can unembargo a kernel using a direct copy, please remove delayed copies
[09:10] <bigjools> we can get rid of that re-upload crap too
[09:10] <wgrant> Can't yet. Need to move notifications and overrides into direct copies :(
[09:10] <wgrant> And that, yes.
[09:10] <bigjools> we can get rid of that anyway
[09:10] <wgrant> I'm going to see if doing constant-query overrides is easy.
[09:10] <wgrant> If so, I'll JFDI.
[09:10] <bigjools> hooah
[09:11] <mrevell> Hey
[09:13] <jtv> hey!
[09:18] <wgrant> bigjools: I guess this will also have the convenient effect of stopping copy-package from breaking the archive.
[09:18] <poolie> hi all
[09:20] <henninge> Hi adeuring!
[09:21] <henninge> adeuring: your soyuz translations upload branch landed! Good job on finding the right spot. ;-)
[09:26] <adeuring> henninge: thanks :)
[09:26] <henninge> adeuring: Unfortunately it seems to be doing a little too much ... :(
[09:26] <adeuring> henninge: really?
[09:26] <henninge> adeuring: we still need the *templates* to be uploaded
[09:26] <adeuring> henninge: ah, right
[09:27] <henninge> adeuring: so addOrUpdateEntriesFromTarball needs to filter only for pot files.
[09:27] <adeuring> henninge: right
[09:27] <henninge> actually, there is a function that checks that
[09:27] <henninge> I was just looking for that
[09:29] <henninge> adeuring: TranslationImporter.isTemplateName
[09:31] <henninge> adeuring: you should be able to add a flag 'only_templates' to addOrUpdateEntriesFromTarball and use that in _isTranslationFile.
[09:31] <adeuring> henninge: right
[09:31] <henninge> adeuring: I am sorry but this really needs to be done before this gets rolled out. Let me file a bug for it.
[09:37] <poolie> jml, hi?
[09:40] <henninge> adeuring: bug 741571
[09:40] <_mup_> Bug #741571: Translation templates should always be uploaded from soyuz builds. <regression> <upstream-translations-sharing> <Launchpad itself:Triaged> < https://launchpad.net/bugs/741571 >
[09:44] <bigjools> wgrant: sorry was otp, to which breakage are you referring, for there are many :)
[09:44] <wgrant> bigjools: The "oh, you wanted to copy a universe package from a PPA? let me just silently promote that for you" one, mainly.
[09:45] <bigjools> ah
[09:53] <henninge> adeuring: I touched that code, too, because I have removed the translationsharinginfo module. But that branch is just landing.
[09:54] <adeuring> ok
[09:54] <henninge> adeuring: are you busy now or should I fix that?
[09:54] <adeuring> henninge: let's dice ;)
[09:55] <henninge> adeuring: I roll a W20 ...
[09:55] <henninge> ...
[09:55] <henninge> 20!
[09:55] <henninge> adeuring: I win ;)
[09:55] <adeuring> henninge: 20*19*18... is a huge number
[09:55] <henninge> :(
[09:55] <henninge> oh
[09:55] <adeuring> henninge: ok, so you'll fix the bug?
[09:56] <henninge> adeuring: yeah, I just thought of some other optimization for my last branch that I could include.
[09:56] <adeuring> henninge: cool, thanks
[10:01] <dpm> hi jml, did you have the chance to have a look at signing up for a session on Launchpad for Ubuntu AppDeveloperWeek or finding someone else to run it?
[10:27] <wgrant> bigjools: Your sync button is buggy.
[10:27] <bigjools> ffs
[10:28] <wgrant> bigjools: syncSources copies the latest published source in the archive, which could be, say, a security upload.
[10:28] <wgrant> It does not discriminate by series or pocket.
[10:29] <wgrant> :D
[10:30] <bigjools> I expected I'd need to fix it later to sync the versions specified
[10:32] <jtv> Any reviewers available?  https://code.launchpad.net/~jtv/launchpad/bug-741585/+merge/54674
[10:33] <bigjools> wgrant is like the eye of Sauron
[10:33]  * jtv tries to see a way that comparison works
[10:33] <jtv> —but fails
[10:33] <wgrant> bigjools: Sadly not.
[10:34] <bigjools> I have a vision of an eye sweeping the Launchpad landscape looking for bugs
[10:35] <jtv> bigjools, you've been reading too much of that "LotR from Sauron's perspective" stuff
[10:36] <bigjools> or maybe I feel like Frodo trying to sneak bugs past the eye :)
[10:38] <wgrant> One does not simply land hacks into Mordor.
[10:39] <wgrant> StevenK: Do you have a solution to your version issue? I see two possibilities.
[10:46] <jtv> bigjools, another Q about publish-ftpmaster: we only need to call process-accepted once, despite the "run once for security, run once for everything" structure, right?
[10:47] <jtv> stub, care to review my little logging cleanup?  https://bugs.launchpad.net/launchpad/+bug/741585
[10:47] <_mup_> Bug #741585: FakeLogger doesn't quite conform to logging API <Launchpad itself:In Progress by jtv> < https://launchpad.net/bugs/741585 >
[10:48] <wgrant> :(
[11:02] <jtv1> bigjools: if we won't be needing commercial-compat.sh for much longer, maybe I should just hard-code it in and we can drop it from the script later.  It actually makes things simpler.
[11:02] <jtv1> (In the long run, that is)
[11:03] <jtv> I can just add an "if we're doing ubuntu" guard around it, and add an XXX.
[11:04] <deryck> Morning, all.
[11:04] <stub> jtv: k
[11:04] <jtv> thanks
[11:04] <jtv> hi deryck
[11:07] <stub> jtv: I thought I fixed it so our custom logger class is registered so we shouldn't see any 'standard' loggers?
[11:08] <jtv> stub: but by "our custom logger class" you don't mean the FakeLogger, do you?
[11:08] <jtv> Oh, I see what you mean
[11:08] <jtv> you mean I could just call debug2.
[11:08] <stub> That should work, yes.
[11:08] <jtv> If that's safe, then I'll do it that way.
[11:08] <wgrant> eeeeeep
[11:09] <stub> If it doesn't work, there is a bug somewhere (retrieving a logger through some weird mechanism?), but that could wait for another branch
[11:09] <jtv> stub: I take it that debug2 will call self.log(DEBUG2, *x, **y)
[11:09] <stub> Yes
[11:09] <jtv> I didn't run into a problem with that; I was just being conservative.
[11:10] <jtv> Running tests.
[11:10] <stub> Actually, according to lp/services/log/loglevels.py it is _log for reasons I don't recall but might be documented in the python reference
[11:11] <stub> Or maybe it was the sourcecode...
[11:11] <stub> Its registered with the logging module in lp_sitecustomize.py anyway
[11:12] <jtv> stub: AttributeError: RootLogger instance has no attribute 'debug2'
[11:13] <stub> With the normal logger or your FakeLogger with debug2() added?
[11:13] <jtv> Probably the normal logger.
[11:13] <jtv> I don't think my FakeLogger has debug2 though.
[11:14] <jtv> There's nothing overriding the logger in that test.
[11:14] <stub> You might need to add it, or make it inherit from LaunchpadLogger instead of the logging module class.
[11:14] <jtv> Or call log() and have it just work.  :)
[11:15] <stub> I fixed this so I didn't have to keep seeing log(DEBUGX, 'foo') everywhere ;)
[11:15] <jtv> Also, I don't _think_ the FakeLogger has a debug2 method but I'm not sure
[11:16] <stub> Yes, you will need to add debug2 to FakeLogger if it isn't there. If it isn't there, it is broken as it isn't a complete mock of the real thing.
[11:16] <jtv> I could fix this up, but that would start to look like a rabbit hole and I'd prefer to be unblocked on my main job (which is a scary soyuz script overhaul)
[11:18] <stub> You have a branch that mainly consists of making things less readable, when adding a three line method on FakeLogger would keep the readability and fix a bug.
[11:20] <stub> Well.. not mainly. You have only changed two .debug2 callsites to use the old syntax.
[11:22] <jtv> But the problem I just ran into is not the FakeLogger.  So fixing up the FakeLogger wouldn't fix that one; there is yet another bug to fix.
[11:25] <stub> ok
[11:25] <jtv> The logger I seem to be getting (and which doesn't seem to have debug2) is canonical.launchpad.scripts.log.
[11:25] <stub> jtv: In what cases do you find you have None as a level?
[11:26] <jtv> I'm not aware of any.  Not sure that deserves to be in there.
[11:26] <stub> ok. Add a comment there mentioning that, or remove it.
[11:27] <jtv> I'll remove it.  It's a bit of legacy crud from jml's merging of fake loggers.
[11:27] <jtv> At least one of the old fake loggers printed "log>" instead of a log level.
[11:29] <stub> jtv: So it looks like lp_sitecustomize.py installs the custom class, and instances are correctly returned for new loggers but the root logger isn't updated.
[11:29] <jtv> I have no idea what you just said.
[11:29] <stub> (testing with 'make harness')
[11:30] <stub> The registration of our custom logger class works for everything except the root logger, which is bogus.
[11:30] <jtv> Sounds like it… what can we do about it?
[11:30] <stub> Surprised this hasn't fallen over before.
[11:30] <stub> I'll have a quick poke to see if it is an easy fix, or open a bug which you can cite in your branch.
[11:31] <jtv> Thanks.
[11:32] <jtv> I've added the new log levels.
[11:35] <bigjools> jtv: sorry just saw your questions
[11:36] <jtv> tsk
[11:36] <bigjools> jtv: p-a only needs to run once
[11:36] <jtv> Running it from the script does introduce the PATH question again, of coursee.
[11:36] <jtv> Oh, different question :)
[11:36] <jtv> Thanks.
[11:36] <bigjools> jtv: embedding commercial compat is ok
[11:37] <bigjools> but file a bug of course :)
[11:37] <jtv> Naturally.
[11:37] <jtv> That brings us down to 2 run-parts dirs: after publish-distro and at the very end.
[11:38] <bigjools> rock on
[11:38] <jtv> For the latter, the scripts will be told in some way whether this is a security-only expedited publishing or a proper full one.
[11:38] <bigjools> so post-publication.d and pre-exit.d ?
[11:38] <jtv> I still need to check whether all of the parts break down neatly into archives.
[11:38] <jtv> Something like that, I guess.
[11:40] <jtv> bigjools: what about the renaming of dists to dists.new?  That looks like it needn't be repeated either.
[11:41] <jtv> I should say: renaming of dists to dists.new plus subsequent rsync from distsroot.
[11:41] <bigjools> mmmm
[11:41] <bigjools> not sure
[11:45] <stub> jtv: So https://pastebin.canonical.com/45170/ looks like the fix, and works with bin/harness. Want to dig the rabbit hole a little deeper and save me making a separate branch?
[11:46]  * jtv waits for that page to load…
[11:48]  * jtv waits for openid…
[11:49] <jtv> ah, there's my page!
[11:51] <jtv> stub: I realize this is piling work onto you, which pains me, but I'd really rather not risk the potential Q/A fallout while I'm doing soyuz feature work.
[11:51]  * stub opens a bug
[11:52]  * jtv gets ready to xxx the bug number
[11:54] <stub> Bug #741650
[11:54] <_mup_> Bug #741650: root logger is not a LaunchpadLogger <Launchpad itself:Triaged> < https://launchpad.net/bugs/741650 >
[11:58] <jml> jtv: thumper's merging
[11:58] <stub> jtv: Copywrite in logger.py should be 2010-2011, not 2011
[11:58] <jtv> my apologies
[11:59] <jtv> stub: fixing
[12:00] <henninge> adeuring: I am done. Want to review?
[12:00] <henninge> adeuring: https://code.launchpad.net/~henninge/launchpad/devel-741571-filter-templates-in-upload/+merge/54688
[12:00] <adeuring> henninge: sure
[12:01] <henninge> adeuring: I'll be out to lunch now, you can ask questions later.
[12:01] <adeuring> ok
[12:01] <henninge> adeuring: but I think this is a pretty clear branch, I really enjoyed coding this.
[12:01] <stub> jtv: Thats it. r=stub.
[12:01] <jtv> stub: thanks—changes pushed, on the way to EC2.
[12:02] <stub> jtv: For lint issues like the one you mentioned, I usually go with whatever makes lint shutup.
[12:03] <jtv> stub: me too, usually.  This is the one exception.  I won't add warnings like that, but I'm hesitant to clean them up.
[12:13] <stub> jtv: What test are you using for this? I want to test my branch
[12:14] <gary_poster> stub, thanks for heads up.  Remind me where the db utilization report is, please?  I'd probably like to talk to you about your concerns too, once I've gotten more familiar with the data.
[12:14] <jtv> stub: I simply replaced the log calls in looptuner.py with debug2 calls and then ran looptuner.txt.
[12:14] <stub> gary_poster: https://devpad.canonical.com/~lpqateam/dbr/
[12:14] <gary_poster> thanks
[12:14] <stub> jtv: ta
[12:16] <stub> gary_poster: Its not causing problems yet, but it certainly should be looked into since it is a big jump and affects our scalability. Robert asked me to raise it because of the work I believe you are doing.
[12:19] <gary_poster> stub, right.  We are doing more work now on the asynchronous side.  It is doing features that have been requested, of course.  Do you have any concrete suggestions on next steps?  The only thing I know of is to try to take a glance at the pertinent code and see if it can be simplified, but that seems fairly vague.
[12:21] <stub> gary_poster: If we know what extra work it has started doing in the last two months, then we can tell if the extra load is justified or not. I don't know what it is doing - I just see the percentage.
[12:23] <stub> gary_poster: I think Robert's main concern is that we are currently in a performance drive, and shouldn't be landing code that makes performance worse (which it seems we have)
[12:23] <jtv> bigjools: do we copy overrides only for the main archive?
[12:23] <gary_poster> stub, even asynchronously, for requested features?  How do we know that this is a problem?
[12:23] <bigjools> jtv: copy?
[12:23] <gary_poster> Amusingly to me, two months ago would be about the week when we started working on this, of course. :-)
[12:23] <jtv> bigjools:     cp $OVERRIDEROOT/override.* $INDICES
[12:24] <jtv> $INDICES is in the main archiveroot
[12:24] <bigjools> jtv: overrides only apply to main archives
[12:24] <jtv> Perfect.  Thanks.
[12:24] <bigjools> so far anyway :)
[12:24] <gary_poster> ah it's less than 2 mo though...
[12:24] <jtv> Well, not perfect, but then I know what to implement.  :)
[12:25] <stub> gary_poster: You would have to discuss features vs. performance drive with lifeless :-) I don't think it is affecting production performance yet, but it has lessened our scalability somewhat.
[12:25] <gary_poster> ack stub.  ok thanks.
[12:26] <stub> gary_poster: It might just be we are missing an index or similar if we can work out what has changed and what we are doing differently now. Or maybe we just have to put up with it, because the extra work is required for some reason.
[12:27] <stub> gary_poster: The two months figure I got because today I compared this weeks report with a report from two months ago. It could have spiked any time between then and now.
[12:27] <gary_poster> understood stub.  I have a suspicion I know the cause, and will investigate and report back on the list.  Thanks again for the heads up.  It started rising in early March.  https://devpad.canonical.com/~lpqateam/dbr/weekly/db-report-2011-03-04-2011-03-11.txt
[12:28] <stub> (In fact, first of all I erroneously compared them in reverse and was singing the praises of whoever stopped bugnotifications from chewing on the cpu :) )
[12:28] <gary_poster> lol
[12:43] <stub> jtv: https://code.launchpad.net/~stub/launchpad/trivial/+merge/54692 (to try landing tomorrow after your branch)
[12:43] <jtv> stub: I know, I'm already looking
[12:44] <jtv> stub: does lp_sitecustomize get run by scripts as well?
[12:44] <jtv> Not sure it matters,
[12:44] <jtv> since we seem to have some logging magic for scripts anyway that probably already sets things right there
[12:45] <stub> jtv: Its buildout magic. Everything in our tree gets it
[12:45] <stub> (unless you forget python -S or _pythonpath)
[12:46] <jtv> stub: approved
[12:47] <stub> ta. I guess I can punt it to ec2 land to see what explodes now - if your branch fails, this one will fail too since I merged yours in.
[12:48] <jtv> stub: looks like my instance never fully set up, but since my review is also approved, "ec2 land" should just land them both.
[12:48] <jtv> (Unless it doesn't want to do that across users)
[12:48] <stub> jtv: Actually, I'll wait. Better two separate landings in case mine needs to be backed out.
[12:48] <jtv> OK
[12:48] <jtv> I should get a chance to send it in tonight.
[12:51] <jml> Can I get a review of this please: https://code.launchpad.net/~jml/launchpad/test-timeout-505913/+merge/54598
[13:06] <abentley> deryck: chat?
[13:07] <deryck> abentley: sure.
[13:07] <deryck> abentley: let me head to the mumbler
[13:18] <jml> 'ec2 test' is complaining about me not having an SSH agent running. But I do.
[13:19] <jtv> bigjools: I'm about to head off.  If you look at lp:~jtv/launchpad/bug-55798 at the last dozen lines of lib/lp/soyuz/scripts/publish_ftpmaster.py you'll see the structure I have now, which is thankfully shaping up to be pretty simple.
[13:19] <jml> maybe I need to set an env var or something
[13:20] <jml> huh. my keys weren't in it. odd.
[13:20] <wgrant> jml: Natty?
[13:20] <jml> wgrant: indeedly
[13:21] <wgrant> jml: Unity been crashing?
[13:21] <jml> wgrant: Does a bear... well, you know the rest.
[13:21] <wgrant> It sometimes doesn't restore the environment properly.
[13:21] <jml> wgrant: ok.
[13:22] <jml> anyway, running ssh-add makes everything better. just going to test my branch that fixes the intermittent test_timeout failure
[13:22] <jml> maybe it'll be done by the time it gets reviewed.
[13:23] <leonardr> abentley: if you can take another look at https://code.launchpad.net/~leonardr/launchpad/explicit-versions/+merge/54558, i can get it into ec2 land
[13:28] <leonardr> wallyworld, you run tests with bin/test
[13:31] <abentley> leonardr: looking
[13:33] <abentley> leonardr: r=me
[13:55] <gmb> jcsackett: Can I get a review of https://code.launchpad.net/~gmb/launchpad/fix-fragile-link-bug-741645/+merge/54698 please? Only 20 lines.
[13:55] <jcsackett> gmb: sure thing.
[13:55] <gmb> Ta
[13:59] <jml> abentley: could you please review https://code.launchpad.net/~jml/launchpad/test-timeout-505913/+merge/54598
[13:59] <abentley> jml: sure, but I've got a standup first.
[13:59] <jcsackett> gmb: r=me.
[13:59] <gmb> Thanks jcsackett
[13:59] <jml> abentley: thanks.
[14:06] <jml> why am I allowed to change translations settings for empathy (upstream) on lpnet but not qastaging?
[14:06] <jml> (https://translations.launchpad.net/empathy vs https://translations.qastaging.launchpad.net/empathy)
[14:15] <bigjools> jml, wgrant: I have to ssh-add every session because the stupid script assumes I'm running Gnome desktop
[14:15] <jml> bigjools: "stupid script" == utilities/ec2?
[14:16] <bigjools> jml: I'm not sure which part exactly, something to do with one of the included modules I expect
[14:16] <bigjools> keyring wants to use the gnome agent as well, instead of the kwallet
[14:17] <jml> I'm guessing this isn't https://bugs.launchpad.net/launchpad/+bug/577118
[14:17] <_mup_> Bug #577118: ec2test barfs if the ssh-agent keys are stored in the wrong order <build-infrastructure> <ec2test> <lp-foundations> <Launchpad itself:Triaged> < https://launchpad.net/bugs/577118 >
[14:19] <bigjools> don't think so
[14:19] <benji> bigjools: I've added a section to https://dev.launchpad.net/LandingChanges that has instructions for telling keyring to use unencrypted flat files for credential storage so you don't have to type in passwords or fiddle with keyrings
[14:19] <bigjools> benji: yep, I saw that thanks.  I don't mind that so much as the problem with the ssh keys
[14:20] <sinzui> jcsackett: ping
[14:20] <jcsackett> sinzui: good morning.
[14:20] <sinzui> jcsackett: do you have time to talk about a branch I am starting: http://pastebin.ubuntu.com/584441/
[14:22] <jcsackett> sinzui: sure.
[14:22]  * jcsackett starts mumble
[14:29] <bigjools> deryck: so, looking at Selenium yet? :)
[14:31] <deryck> bigjools: I would be interested in Selenium, definetly. :-)
[14:31] <bigjools> :)
[14:32] <bigjools> it was in reference to your last tweet/fb
[14:32] <deryck> bigjools: other parts of Canonical are using it now.  Windmill is all but dead, except for us
[14:32] <deryck> bigjools: right :-)
[14:32] <bigjools> yeah, it's not developed any more even, I heard?
[14:32] <deryck> right, it's pretty dead, I think
[14:32] <deryck> I just don't have an easy path off of Windmill
[14:32] <bigjools> except we have a twitching limb
[14:33] <deryck> heh
[14:33] <bigjools> I'll see if my team can help with this when we get to the feature review stage
[14:33] <deryck> bigjools: oh, dude!  That would be wonderful.
[14:34] <bigjools> don't get too excited, it's a month away or so :)
[14:34] <deryck> heh, fair enough :-)
[14:34] <bigjools> when we discussed it we were all of the opinion that we should not flog the dead
[14:36] <deryck> I think the important thing is to get it added as an option for these sort of tests and then get an example test going.
[14:36] <deryck> and not make the same mistakes again :-)
[14:36] <deryck> e.g. maybe we should consider running them separtely from our normal tests, decoupled from the Zope test runner
[14:38] <deryck> they have to block in some way to be useful, but exactly what that blocking mechanism is good be looked at, too.
[14:38] <bigjools> I'd be willing to do that
[14:38] <deryck> s/good/could/ (for my last one)
[14:38] <bigjools> we need to look at how many of our landed branches would need that sort of test
[14:38] <deryck> yes
[14:38] <bigjools> worth an experiment!
[14:39] <deryck> very much so!
[14:39] <deryck> selenium would, I think, allow us to have real web page integration tests that were more stable, rather than the minimal XHR integration test I'm preaching for now
[14:39] <bigjools> unfortunately I know next to bugger all about the whole JS environment so I can't be very helpful right now.  I aim to delve into this in more detail soon though.
[14:40] <deryck> I'm just thrilled to have someone express an interest :-)
[14:40] <bigjools> ha :)
[14:43] <abentley> jml: what's _logTimeout for?
[14:45] <bigjools> james_w: it struck me that there's nothing in the derived distros LEP about considering pockets when working out package differences.  Right now it'll just grab whatever was most recently published but I'm not sure if that will always be what's required.  Any thoughts?
[14:45] <james_w> bigjools, could you expand please?
[14:46] <bigjools> james_w: ok for example say the most recent upload is to -backports.  It'll show up as a diff but won't say it's from -backports.
[14:46] <bigjools> you may not want to sync from backports :)
[14:46] <james_w> hmm, indeed
[14:47] <bigjools> so I'm trying to flesh out the use cases here so we can work out what to change to make this work better
[14:47] <james_w> my initial guess is that you would want an item for each pocket that had a new version published
[14:48] <bigjools> that's what I thought - you'd end up with multiple rows for the same package showing in the table of diffs
[14:48] <james_w> "-security has <this> and -updates has <that>" and you can choose which to sync
[14:48] <bigjools> yup
[14:48] <james_w> if you chose the later one then the other would go away
[14:49] <bigjools> interesting
[14:49] <abentley> jml: it seems test_timeout_short has a lot in common with test_timeout.  Could we extract the common code to a helper?
[14:49] <james_w> it's not quite right, but I don't see a better way
[14:52] <abentley> jml: IIRC, raising an exception meant that the oops would contain a traceback showing what code had timed out.  It seems a shame to lose that.
[14:56] <bigjools> james_w: I'll ask a few more people and get some consensus
[14:56] <james_w> ok
[14:56] <bigjools> cheers
[15:32] <bac> gary_poster, jcsackett: either of you going to trizpug tonight?
[15:33] <jcsackett> bac: i'm not sure. there's a decent chance of 'no'.
[15:33] <gary_poster> no. previous commitment, bac (to painting a mural in the baby's room)
[15:33] <bac> jcsackett: that's my inclination too
[15:34] <jcsackett> bac: in my case, i need to contact one of the other splatspace members. he's technically the point man for the meeting, but is not always on time, and someone has to be there to open doors.
[15:35] <bac> jcsackett, gary_poster: on an unrelated note, andrea from lanter is a james beard finalist.
[15:35] <bac> lantern
[15:35] <jcsackett> cool.
[15:35] <gary_poster> cool :-)
[15:48] <benji> Does allhands eat newlines in objective "Progress Notes" for anyone else.  It really hurts the readability of my text.
[16:55] <jcsackett> bac: confirmed, i won't be there tonight.
[16:59]  * jcsackett is having a braindead day.
[17:00] <adeuring1> abentley: my branch lp:~adeuring/launchpad/js-translation now also shows the corect "add packaging" icon
[17:03] <bigjools> you can't beat a good refactoring for satisfaction
[17:03] <jml> abentley: have you had a chance to look at that branch?
[17:33] <LPCIBot> Project windmill build #98: STILL FAILING in 1 hr 9 min: https://lpci.wedontsleep.org/job/windmill/98/
[17:49] <bigjools> jml: too late
[17:50] <bigjools> I already submitted a fix
[17:50] <abentley> jml: I did, and I asked you some questions about it.
[17:50] <jml> bigjools: oops. missed your mail (Gmail put it into a different thread :()
[17:51] <bigjools> jml: awesome Gmail :)
[17:51] <bigjools> jml: except PQM just blew me out, grar
[17:51] <jml> abentley: on the channel?
[17:52] <jml> ahh yes.
[17:52] <jml> abentley: logTimeout is for making sure the logged oops is a TimeoutError, not ProcessDone(42)
[17:53] <jml> abentley: the tests are fairly short. I guess I could put the logger stuff in setUp and make a custom assertion. Not sure whether that would be better.
[17:54] <jml> abentley: re <abentley> jml: IIRC, raising an exception meant that the oops would contain a traceback showing what code had timed out.  It seems a shame to lose that.
[17:55] <jml> abentley: I agree, it is a shame. I'm not sure we can do that and avoid the race.
[17:56]  * jml tries something
[17:56] <jml> (although I don't really know how to verify the traceback
[17:56] <jml> )
[17:56] <abentley> jml: would it be crazy to log the oops in a signal handler?
[17:57] <jml> abentley: I don't *think* so. The caveats about complexity that we discussed the other day would apply.
[17:58] <jml> abentley: I was thinking of try: raise TimeoutError; finally: os._exit(TIMEOUT_CODE), or something similar.
[17:58] <abentley> jml: I don't understand how that would result in a traceback in the oops.
[18:00] <bigjools> right, time to make like a shepherd.  Good night all.
[18:00] <jml> abentley: well, probably something more like finally: reactor.callLater(0, os._exit(TIMEOUT_CODE))
[18:00] <abentley> jml: Ah.
[18:00] <jml> err... reactor.callLater(0, os._exit, TIMEOUT_CODE)
[18:01] <jml> abentley: so the error handling would get a chance to run, and if it doesn't then the next thing that happens is a hard stop.
[18:01] <abentley> jml: works for me.  Works for you?
[18:01] <jml> abentley: if it works at all :)
[18:04] <jml> hmm. the test passes, but I suspect it's logging two TimeoutError oopses.
[18:04] <jml> (really hard to actually check for that)
[18:12] <jml> abentley: yeah. it logs two oopses in that case.
[18:14] <abentley> jml: I guess we want that, since the first oops isn't guaranteed to work?
[18:15] <jml> abentley: maybe. I honestly don't know. Two oopses seems less good than one. But maybe the extra information is worth it.
[18:16] <abentley> jml: You could use a different exit status if the exception handler succeeds.
[18:16] <jml> I don't know how to log oopses safely from the signal handler (both because of signal handling but also because logging an oops requires a substantial amount of infrastructure that might not be present, such as parsed config)
[18:16] <jml> abentley: hmm.
[18:17] <jml> abentley: I'll give that a try.
[18:18] <jml> abentley: this is approaching the complexity of the "set some state" solution I discussed the other day, though
[18:24] <jml> abentley: I can't make this work without making a mess.
[18:26] <abentley> jml: I think getting the traceback is pretty important, so I can accept the two-oops solution.
[18:26] <jml> abentley: OK. I'll add some comments.
[18:32] <jml> abentley: http://pastebin.ubuntu.com/584950/
[18:32] <abentley> jml: r=me.
[18:32] <jml> abentley: thanks.
[18:45] <LPCIBot> Project windmill build #99: STILL FAILING in 44 min: https://lpci.wedontsleep.org/job/windmill/99/
[19:29] <LPCIBot> Project windmill build #100: STILL FAILING in 43 min: https://lpci.wedontsleep.org/job/windmill/100/
[19:37] <leonardr> benji, i'm having a problem receiving zope events. can you help?
[19:37] <leonardr> lp:~leonardr/lazr.restful/449561
[19:37] <benji> leonardr: sure, looking now
[19:38] <leonardr> look at EventTestCase in test_webservice.py
[19:50] <benji> leonardr: ahh, the zope.component subscriber (the one that takes the super simple events from zope.event and dispatches the interface based events) isn't wired up in the test
[19:50] <benji> let me see how you do that
[19:53] <benji> well, that was at least part of the problem, but it's still not working
[20:03] <leonardr> benji: i know it's working in webservice.txt, you might look at that
[20:08] <benji> leonardr: here you go http://pastebin.ubuntu.com/585015/
[20:08] <leonardr> benji, thanks, will look in just a minute
[20:09] <benji> also, the zope.component.eventtesting.getEvents function would probably simplify your tests a bit (remove the need to register your own handler)
[20:12] <lifeless> 'sender-time Sent at 4:56 AM (UTC). Current time there: 8:10 PM'
[20:13] <deryck> later on, everyone.
[20:14] <leonardr> jcsackett: very quick: https://code.launchpad.net/~leonardr/lazr.restful/fix-test-failures/+merge/54773
[20:14] <jcsackett> leonardr: looking now.
[20:18] <jcsackett> leonardr: r=me
[20:18] <leonardr> jcsackett: i'm still getting a failure. it's that damn list of things that need to be sanity-checked
[20:18] <leonardr> it needs to be cleared out all the time, not just for those tests
[20:19] <jcsackett> leonardr: ok. feel free to ping me after uploading those changes.
[20:19] <leonardr> jcsackett: ok, i think i know how to do it
[20:41] <jcsackett> leonardr: how does one go about exporting something only into devel?
[20:41] <leonardr> jcsackett: for an entry or field, you use as_of="devel"
[20:41] <leonardr> for a named operation, you use @operation_for_version("devel")
[20:41] <leonardr> this is once my branch lands
[20:41] <leonardr> ah, it just landed, so my advice is accurate
[20:42] <jcsackett> but until your branch lands it's not doable?
[20:42] <jcsackett> ah, excellent.
[20:43] <leonardr> before my branch landed it was doable but ugly
[20:48] <lifeless> ok, logs have updated
[20:48] <lifeless> I see 2011-03-24 20:07:25 INFO    Notifying robertc@robertcollins.net about bug 741821.
[20:48] <_mup_> Bug #741821: "Mute bug mail" in new bug reports is odd <confusing-ui> <story-better-bug-notification> <Launchpad itself:Triaged> < https://launchpad.net/bugs/741821 >
[20:48] <lifeless> and the initial one was
[20:48] <lifeless> 2011-03-24 15:45:43 INFO    Notifying robertc@robertcollins.net about bug 741821.
[20:48] <_mup_> Bug #741821: "Mute bug mail" in new bug reports is odd <confusing-ui> <story-better-bug-notification> <Launchpad itself:Triaged> < https://launchpad.net/bugs/741821 >
[20:49] <lifeless> thats 4h20 minutes later
[20:49] <lifeless> the bug activity is
[20:49] <lifeless> 2011-03-24 15:32:53	Andrea Corbellini	bug			added bug
[20:49] <lifeless> 2011-03-24 15:56:44	Graham Binns	tags		confusing-ui story-better-bug-notification	
[20:49]  * jcsackett nods. that works with what we've seen.
[20:49] <lifeless> 2011-03-24 15:56:48	Graham Binns	launchpad: status	New	Triaged	
[20:49] <lifeless> 2011-03-24 15:56:52	Graham Binns	launchpad: importance	Undecided	High	
[20:49]  * gmb needs to stop "Graham" and "Binns" from highlighting
[20:50] <lifeless> so 20 minutes would have been reasonable
[20:50] <lifeless> the fact that the interval is 4h20 minutes makes me wonder
[20:50] <lifeless> is there a 4 hour grace period on actions being reverted or something ?
[20:50] <lifeless> gary_poster: ^
[20:51] <gary_poster> I was just talking in ops about all this...
[20:52] <gary_poster> lifeless, no
[20:52] <lifeless> oh
[20:52] <lifeless> CHANNEL FAIL
[20:53] <gary_poster> :-)
[20:53] <bac> hi sinzui, you have a minute to chat about menus
[20:53] <lifeless> sorry
[20:53] <gary_poster> np
[20:54] <jkakar> This is a curious position to be in: You are the owner of this team. You are not currently an active member.
[20:54] <jkakar> I guess one never gives up ownership of a team...?
[20:54] <jkakar> https://launchpad.net/~clouddeck
[20:58] <lifeless> jkakar: ownership can be handed off
[20:59] <jkakar> lifeless: Ah, okay.  That should probably happen in this case.
[20:59] <jkakar> lifeless: Aha, found it... thanks for the hint. :)
[21:01] <sinzui> bac: I will in 2 minutes
[21:04] <sinzui> bac: mumble?
[21:04] <bac> sinzui: yes please
[21:11] <lifeless> is anyone fixing the db-devel conflict ?
[21:11] <jcsackett> lifeless: is there a new one? bigjools or jml killed one awhile ago.
[21:22] <leonardr> jcsackett: ok, take another look. i made the sanity check responsible for cleaning up after itself, and i added code to the test framework to wipe any test that imported a module without running the sanity check
[21:27] <jcsackett> leonardr: while the while len > 0: pop? wouldn't just reassigning to [] be faster? the contained objects lose their reference all the same so should still be cleaned up normally...
[21:28] <leonardr> jcsackett: i would love to reassign to [], but that doesn't work
[21:28] <lifeless> jcsackett: leonardr: cleaning a list ?
[21:28] <leonardr> yeah
[21:28] <lifeless> del list[:]
[21:28] <jcsackett> leonardr: ooh, that works nicely.
[21:29] <jcsackett> lifeless, rather.
[21:29] <lifeless> also spellable as list[:] = []
[21:29] <lifeless> but I'd use del
[21:29] <leonardr> change made
[21:29] <jcsackett> leonardr: does that work in your instance?
[21:30] <leonardr> yeah
[21:30] <jcsackett> awesome.
[21:30] <jcsackett> r=me,
[21:30] <leonardr> i just can't change the reference
[21:30] <jcsackett> leonardr: ah, right.
[21:30] <jcsackett> well, with the del, all seems well by me. land it. :-)
[21:30] <leonardr> ok
[22:03] <sinzui> wgrant:  mumble?
[22:17] <wallyworld> leonardr: sorry i missed you this morning - got sucked straight into a prod incident. saw your mp comment. thanks. can you tell me how to run the tests?
[22:17] <leonardr> wallyworld: bin/test should work
[22:17] <leonardr> if you don't have bin/test you need to run 'python bootstrap.py; bin/buildout'
[22:18] <wallyworld> leonardr: i there was no bin/test. i started running buildout etc and it went to download all this zope stuff so i killed it cause i was using my 3g modem at the time
[22:19] <wallyworld> i will let it finish running the next time
[22:20] <lifeless> sinzui: you wanted to talk about the person merge branch I reviewed
[22:20] <leonardr> wallyworld: ok, do this too:
[22:20] <leonardr> create a ~/.buildout/default.cfg
[22:20] <leonardr> mine looks like this
[22:20] <leonardr> [buildout]
[22:20] <leonardr> eggs-directory=/home/leonardr/.buildout/eggs
[22:20] <leonardr> download-cache=/home/leonardr/.buildout/download-cache
[22:21] <leonardr> everything it downloads will be stored so it will only download once
[22:21] <sinzui> lifeless: Yes please
[22:21] <leonardr> not for every branch
[22:21] <lifeless> sinzui: did you want voice or irc or ... ?
[22:21] <wallyworld> leonardr: ah, that's what i need. thanks
[22:21] <sinzui> lifeless: I am staring skype
[22:22] <lifeless> kk
[22:22] <wallyworld> leonardr: i'm working on the prod incident atm but will make the changes you suggested and let you know. i should be able to make myself available for a standup tomorrow morning to hopefully finalise stuff before you go
[22:23] <leonardr> ok, great
[22:23] <leonardr> talk to you then
[22:39] <wgrant> Ooh, explicit API versioning.
[22:39] <wgrant> Excellent!
[23:14] <lifeless> sinzui: mailed.