[00:02] <wgrant> lifeless: One could say the same for any other sourcecode change.
[00:02] <wgrant> We could probably have make check that.
[00:02] <wgrant> Do a no-op update-sourcecode run
[00:04] <wallyworld> lifeless: how do you get the query count to show in the top right corner of the page?
[00:05] <wgrant> 'visible_render_time default 0 on'
[00:05] <wallyworld> wgrant: thanks
[00:05] <wgrant> StevenK: Is this for the base version thing?
[00:05] <lifeless> wgrant: that might be nice
[00:06] <lifeless> wgrant: shipit is particularly weird though because it breaks on zcml, not on $specific tests.
[00:06] <wgrant> lifeless: bzr-builder is also very good at breaking model imports.
[00:06] <lifeless> ah
[00:07] <lifeless> wgrant: anyhow, yes, these things all need communication :)
[00:07] <lifeless> or we could stop using source code
[00:07] <wgrant> Heh, good luck with that.
[00:08] <wallyworld> why do we use source code and not eggs for that stuff?
[00:09] <StevenK> wgrant: Yes
[00:09] <wgrant> wallyworld: eggs came along much later.
[00:09] <wallyworld> and we don't want to go in and eggify the source code stuff...?
[00:10] <wgrant> Well, I don't really like eggs.
[00:10] <StevenK> And everytime shipit is moved into an egg, it breaks and leaves this rotten smell ...
[00:10] <wallyworld> wgrant: what is your preference to eggs?
[00:11] <lifeless> grah
[00:11] <wgrant> wallyworld: Real packages are nice, because they aren't programming languages feeling that they need to reinvent the package manager :)
[00:11] <StevenK> We have 3 ways to inject dependencies into our tree: eggs, sourcecode and binary packages from the PPA.
[00:11] <lifeless> sample branches are not scanned
[00:11] <lifeless> no wonder its approximately useless.
[00:11] <wgrant> Also, real packages don't involve downloading unsigned code over HTTP.
[00:12] <StevenK> wgrant: You mean that doesn't give you a warm fuzzy feeling? :-P
[00:13] <wallyworld> wgrant: yes, but python has eggs, java has jars etc - it a common paradigm. i can see the point of keeping such things separate from the overhead of a full blown package that is not universal across os's rpm vs apt etc
[00:13] <wgrant> It is a common paradigm, but it also fucking stupid.
[00:13] <wgrant> :(
[00:13] <wallyworld> wgrant: you forgot IMHO :-)
[00:13] <StevenK> It isn't just his opinion.
[00:14] <StevenK> *Anyone* who has done a bunch of distribution work shares it.
[00:14] <StevenK> Except lifeless, because he's special.
[00:14] <thumper> :-( :-( make: *** [check] Error 1
[00:15] <thumper> I tried running ec2 test --attached
[00:15] <thumper> everything seems to pass
[00:15] <thumper> then I get this ^^^
[00:15] <thumper> I had several detached ec2 test runs,
[00:15] <wallyworld> i haven't done any distribution work so i don't yet appreciate the drawbacks of eggs etc. all i see are packaging overheads and competing implementations
[00:15] <wgrant> thumper: Full output pls.
[00:15] <thumper> and they all fail
[00:15] <StevenK> wallyworld: So, we have a wheel. It's round, it mostly turns without issues, but it has been reinvented by PyPI, CPAN, Gems, ...
[00:16] <spiv> wallyworld: you can't win, really
[00:16] <wgrant> And then the reinventors of the wheels decide that they don't want anything to do with distributions.
[00:16] <wgrant> eg. Ruby
[00:16] <thumper> wgrant: I've emailed it to you
[00:16] <wgrant> "lol, why would people want distribution packages? end users should use gems"
[00:16] <StevenK> It seems to be a bunch of NIH to me
[00:16] <spiv> wallyworld: random python upstreams of course would rather not learn new packaging tools and conventions for Debian, OS X, Windows, etc...
[00:16] <wallyworld> i'm hit, bleeding badly, can't hang on much longer, copping it from all directions.....
[00:17] <StevenK> wallyworld: Well, you did just jump up and wave your shirt in the air and yelled "I'm over here, come get some!"
[00:17] <spiv> wallyworld: but at the same time Debian, Fedora, OS X, etc don't want dozens of non-cooperating packaging systems where one would do
[00:17] <wgrant> thumper: That is a little bit special.
[00:17] <wallyworld> spiv: i guess that's one of my points - each os has it's own packaging mechanism, vs eggs for python which is universal
[00:17] <wgrant> wallyworld: Universal... for Python.
[00:18] <spiv> wallyworld: it's the "for Python" bit that's the killer
[00:18] <lifeless> StevenK: uhm, don't malign me please.
[00:18] <spiv> wallyworld: what happens when a Python package depends on a C library
[00:18] <StevenK> And then never mind rpm vs apt vs emerge ...
[00:18] <spiv> wallyworld: etc :)
[00:18] <lifeless> StevenK: I *loath* gems jars eggs etc
[00:18] <StevenK> lifeless: I was poking fun, not trying to do so
[00:18] <lifeless> StevenK: and I've been pretty vocal about that
[00:18] <lifeless> I would love to just use debs for lp dependencies.
[00:19] <wgrant> thumper: Ah, there it is.
[00:19] <StevenK> lifeless: Hm. I had you in my mind as the other way -- so noted, sorry
[00:19] <wallyworld> spiv: fair point. if only each os would stop adopting it's own packaging implementation
[00:19] <wgrant> thumper: There are failures in the stream.
[00:19] <lifeless> but the deb python maintainers want *upstream* to decide on how to handle conflicting APIs for multiple versions of the same package on disk
[00:19] <lifeless> StevenK: which is never ever ever ever ever going to happen
[00:19] <wgrant> thumper: But the summary doesn't show them because of a bug I'm currently writing a test for.
[00:19] <spiv> wallyworld: if only each os was a derivative of Ubuntu :)
[00:19] <thumper> wgrant: why aren't they in the email?
[00:19] <lifeless> because python folk wave the virtualenv magic flag
[00:20] <lifeless> the result is that every python transition is lockstep
[00:20] <wgrant> thumper: jml broke it when he added ec2 list.
[00:20] <lifeless> (and I don't mean python VM, I mean individual packages
[00:20] <wgrant> The fix is easy, but a test is slightly harder.
[00:20] <StevenK> Package management is hard
[00:20] <lifeless> and that results in us not being able to shift dependencies at all, which is why we're not using debs.
[00:20] <lifeless> see for instance my threads on debian-python (both direct and through folk I've been poking about this)
[00:21] <lifeless> StevenK: its easy if we accept that upstream have different drivers than us
[00:21] <StevenK> Well, we're using a mix of debs, eggs and source trees
[00:21] <wgrant> And random things that people thought it was a good idea to import into the tree.
[00:21] <StevenK> wallyworld: Do you see why we don't discuss this often?
[00:21] <wgrant> Heh.
[00:22] <StevenK> wgrant: :-(
[00:22] <wallyworld> StevenK: yeah, i had no idea what a feeding frenzy it would create. wow :-)
[00:22] <lifeless> StevenK: and the debs give us routine production fail, the source treess toolchain isn't being fully used and the eggs we have to cripple the toolchain because we like verified code
[00:22] <StevenK> Baptism of Fire, part #58585
[00:22] <_mup_> Bug #58585: Installer is crashing (all disk activity stops) at scanning mirror message <ubiquity (Ubuntu):Invalid> < https://launchpad.net/bugs/58585 >
[00:22] <lifeless> StevenK: but you forgot, we *also* use:
[00:22] <lifeless>  - bundled code in hidden bits of the tree
[00:23]  * thumper sighs
[00:23] <wgrant>  - more bundled code in other better hidden bits of the tree.
[00:23] <StevenK> lifeless: The debs only fail because there seems to be this magical step where packages jump from the PPA into CAT ....
[00:24] <wgrant> StevenK: The main problem is the multiple versions issue.
[00:24] <lifeless> StevenK: thats not the fail
[00:24] <lifeless> StevenK: the fail is when version A and version B are incompatible with each other as far as LP is concerned.
[00:24] <lifeless> StevenK: we then have to simultaneously upgrade the LP tree at the same time, or we have a fail
[00:25] <StevenK> :-/
[00:25] <lifeless> which means a more complex rollout - take the entire appserver machine offline, (== 20% drop in capacity - when we are already overloaded), upgrade debs, deploy new LP, bring the servers back online
[00:26] <lifeless> StevenK: what we need is what C/mono etc libraries have - sonames.
[00:26] <lifeless> then we can install the new debs, lp ignores them, and then we upgrade lp to one that uses the new debs, bingo it works.
[00:26] <lifeless> StevenK: in a java world things like e.g. osgi go a long way toward this
[00:26] <StevenK> ... or write code that can work with both version of the code. But I understand that isn't always possible.
[00:27] <lifeless> but in python 'import' is global, there is no built in concept of 'library version' - you cant say 'import bzrlib 2.2 as bzrlib'
[00:27] <lifeless> and the plumbing for this goes deep
[00:27] <lifeless> StevenK: its both not always possible and its /harder/
[00:28] <wallyworld> osgi rules!
[00:28] <lifeless> given the choice of two ways to achieve something, only particularly opinionated or previously burnt folk will choose the harder way.
[00:28] <lifeless> wallyworld: for all its mind bending stuff, yes, yes it does.
[00:29] <lifeless> so its a long term goal for me to beat enough sense into python to permit this
[00:29] <lifeless> or JFDI a workaround in the distro using pkg_resources.require()
[00:29] <wgrant> That could work.
[00:29] <lifeless> but I suspect we'd end up auto rebuilding the entire python stack
[00:29] <wgrant> What is Fedora doing about this sort of thing?
[00:30] <lifeless> because the debian python group /don't get it/
[00:30] <lifeless> because they are thinking desktops and 'upgrade every 5 years' style server environments.
[00:31] <lifeless> wgrant: I've not seen anything - reality is most folk deploy python stacks using eggs / the django thingy / virtualenv etc - for the previously discussed reasons.
[00:31] <lifeless> *and* most really agile things I've seen are php or java, not python, so there isn't that much web world pressure on distros to fix this
[00:31] <lifeless> (because python is 10 times slower than either php or java)
[00:32] <StevenK> To write, run, deploy, or all three?
[00:32] <lifeless> all three
[00:32] <lifeless> deploy is about equal actually
[00:33] <lifeless> php apps tend to be very lean
[00:33] <lifeless> java apps aren't, but they have -wonderful- tooling around development
[00:33] <lifeless> and for execution time, php and java eat python for breakfast and lunch
[00:34] <lifeless> the only /serious/ python thing at *scale* I know of is youtube : and they don't run CPython, rather they run bleeding edge experimental binaries
[00:34] <StevenK> We aren't serious?
[00:34] <lifeless> StevenK: we're tiny
[00:34] <lifeless> StevenK: all our problems are self inflicted
[00:35] <lifeless> we've < 1/2T of data
[00:35] <james_w> wgrant, I think Fedora still haven't got so supporting multiple versions of the python runtime, so I don't think they've tackled this
[00:35] <wallyworld> lifeless: python has good development tooling too. you don't *have* to use emacs :-P
[00:35] <wgrant> james_w: Hah.
[00:35] <lifeless> a single (very high end) commodity PC server can run our entire backend load
[00:35] <wgrant> And I'm not going to ask about other distros like Arch... given that they've switch /usr/bin/python to 3.x.
[00:36] <lifeless> StevenK: we have the potential to be serious if we get our shit sorted and /fast/
[00:36] <lifeless> I will be delighted when we start getting user adoption scale problems
[00:36] <wgrant> A year ago I would have said we were doomed to be slow forever.
[00:36] <lifeless> rather than 'oh and we don't delete obsolete data' scaling issues.
[00:36] <wgrant> But I think that may not be the case.
[00:36] <lifeless> wgrant: I wouldn't have taken the job if I thought it was insoluable
[00:36] <lifeless> bah
[00:36] <lifeless> unsolvable
[00:37] <wgrant> lifeless: Yes, but you are crazy :P
[00:37] <StevenK> It doesn't dissolve in water either
[00:37] <wgrant> Yet very effective.
[00:37]  * StevenK peers at subunit
[00:39] <StevenK> subunit-filter's default operation is to strip sucessful tests. Except one turns up ...
[00:42] <StevenK> I just love how the Australian Tax Office can give a recorded message saying that they are too busy to take the call ... for 3 weeks solid
[00:44] <lifeless> StevenK: if the stream gets corrupted by things printing to stdout
[00:44] <StevenK> lifeless: Such as test failures?
[00:44] <lifeless> StevenK: you can see what looks like something being not-filtered, whenthe parser actually thinks 'this is junk'
[00:44] <lifeless> StevenK: test failures shouldn't print to stdout, the raise exceptions internally
[00:45] <lifeless> StevenK: you can see if this is the case with --no-passthrough
[00:45] <lifeless> that will squelch what subunit thinks is chatter on stdout
[00:45] <StevenK> I'm already using --no-passthrough
[00:45] <lifeless> mm
[00:45] <lifeless> then if you're seeing a success,
[00:45] <lifeless> ah perhaps a skip ?
[00:45] <lifeless> some things fold skip to success
[00:45] <lifeless> and older subunit had a bug in that area
[00:45] <lifeless> try --no-skpi
[00:46] <StevenK> Ahh, no, it's these tests
[00:46] <StevenK> There are two are cunningly named
[00:46] <lifeless> woo, another stab at timeouts complete
[00:46] <lifeless> lp:~lifeless/launchpad/bug-722956
[00:50] <lifeless> I need a review https://code.launchpad.net/~lifeless/launchpad/bug-722956/+merge/51481
[00:50] <lifeless> diff is generating still
[00:52] <SpamapS> lifeless: so.. curious.. how hard is it to setup a project as a distro w/ source packages and such?
[00:53] <wgrant> lol
[00:53] <lifeless> SpamapS: impossible
[00:53] <lifeless> SpamapS: starting this week julians team is working on making it possible
[00:53] <lifeless> SpamapS: a lot of ground work is in place
[00:54] <lifeless> they were interrupted by the reorg
[00:54] <lifeless> StevenK can tell you how much work remains
[00:54] <StevenK> Lots
[00:54] <wgrant> Tonnes.
[00:54] <lifeless> o/~ I need a review o/~ to the sound of 'I need a hero'
[00:54] <wgrant> Getting it working isn't that hard. Getting it effectively usable is another thing.
[00:54] <StevenK> I'm working on low-level plumbing
[00:54] <SpamapS> lifeless: ahh.. thats good.. I think the principia ensemble project I started is going to need package tracking.
[00:55] <lifeless> are they actually packages ?
[00:55] <lifeless> or just vaguely similar
[00:55] <SpamapS> they're called formulas..
[00:55] <lifeless> should be called instruments
[00:55] <lifeless> or scores
[00:55] <lifeless> anyhow ;)
[00:55] <wgrant> Heh
[00:56] <SpamapS> lifeless: agreed.. would have been much cooler. :)
[00:56] <SpamapS> though if it hadn't been formula.. I wouldn't have been able to come up with the name Principia Ensemble
[00:56] <lifeless> SpamapS: if they are similar but not the same, then I wouldn't shove them in as packages - packages are tied up in the whole package building machinery
[00:56] <SpamapS> lifeless: yeah I don't need that.. I just need sub trackers
[00:56] <wgrant> Or do you just want the bugtracking aspects of source packages?
[00:56] <lifeless> SpamapS: think crisp and clean; we can bring up a dedicated interface pretty directly.
[00:56] <wgrant> Right.
[00:57] <lifeless> SpamapS: project groups do that, but the components are 'project' which is pretty big.
[00:57] <lifeless> if we were to refine 'bug.target' we could do subtrackers on projects quite easily.
[00:57] <SpamapS> Yeah I'd expect there to be 300 - 500  formulas
[00:57] <lifeless> thats the sound of 20 engineers screaming at me
[00:58] <StevenK> Only 20?
[00:58] <lifeless> StevenK: 5*5 in theory but we're short atm
[00:58] <lifeless> plus I know at least 2 that agree
[00:59] <wgrant> lifeless: We're not short any more :(
[00:59] <lifeless> wgrant: we are, its just going to stay like that for a while
[01:01] <lifeless> wgrant: are you actually working on https://bugs.launchpad.net/launchpad/+bug/575450
[01:02] <_mup_> Bug #575450: Archive:+copy-packages nearly unusable due to timeouts <lp-soyuz> <ppa> <timeout> <Launchpad itself:In Progress by wgrant> < https://launchpad.net/bugs/575450 >
[01:04] <wgrant> lifeless: I haven't touched it for a couple of weeks, and don't have branches with any significant improvements. You may steal it if you wish.
[01:04] <wgrant> It's not really difficult.
[01:04] <wgrant> I was just trying to make some infrastructure improvements to make testing easier.
[01:04]  * lifeless gifts wgrant with a laserlike obsession with production performance
[01:04] <wgrant> eg. ++oops++ doesn't work on form submissions or the webservice (as yet unsolved), query counts are difficult and non-deterministic (both solved)
[01:05] <lifeless> wgrant: those are great things to do
[01:05] <lifeless> wgrant: which query counts ?
[01:05] <lifeless> wgrant: oh, you mean the session thing?
[01:05] <wgrant> That, and your new matcher.
[01:06] <wgrant> Although there is still that Storm thing where it will do a SELECT 1 to check if an object exists the second time. But I wonder if store.reset() will fix that.
[01:07] <wgrant> lifeless: The most difficult bit of those timeouts it the DAS queries.
[01:07] <thumper> wallyworld, StevenK: mumble?
[01:07] <wallyworld> thumper: ok
[01:07] <wgrant> lifeless: They're produced by createMissingBuilds' calls to getBuildByArch... and that is all a really big mess.
[01:07] <lifeless> zomg
[01:08] <lifeless> DistributionSourcePackage - 778 repeated lookups
[01:08] <wgrant> Where? BugTask:+index?
[01:08] <lifeless> bug 705713
[01:08] <_mup_> Bug #705713: Bug:EntryResource Timeout trying to set bug private - death by sql / late evalation <timeout> <Launchpad itself:Triaged> < https://launchpad.net/bugs/705713 >
[01:08] <wgrant> Heat?
[01:09] <lifeless> not obviously
[01:09] <lifeless> just 1.4K sql queries
[01:10] <wgrant> It was a good thing, though.
[01:10] <lifeless> bbiab, doctor visit.
[01:10] <thumper> wallyworld: https://dev.launchpad.net/PolicyAndProcess/MaintenanceRotation
[01:12] <SpamapS> ok so the consensus right now is that sub-trackers will just have to be implemented using tags at the moment.
[01:12] <SpamapS> ?
[01:12] <wgrant> SpamapS: Unless you want to use a project group, which you probably don't.
[01:13] <SpamapS> wgrant: right I don't want to register 600 projects.. some of which will  have 8 - 20 lines of code.
[01:48] <lifeless> I think tags should work well
[01:48] <lifeless> we probably have a few small bugs to sort out in making them scale and be usable enough
[01:49] <lifeless> but that woul dbe significantly less than actual sub trackers.
[01:49] <lifeless> less work I mean
[01:53] <lifeless> wgrant: so what are you stabbing today?
[01:53] <wgrant> lifeless: The last of checkwatches.
[01:54] <lifeless> wgrant: would you like to get the loggerhead thing too?
[01:54] <wgrant> lifeless: You mean jam's branch that I reviewed last week?
[01:54] <lifeless> I think it just needs a merge to trunk + a merge to the lp deploy branch + a sourcecode rev
[01:54] <lifeless> + a bug filed for capturing timeouts
[01:54] <lifeless> yeah
[01:55] <wgrant> launchpad_loggerhead is in the tree now.
[01:55] <lifeless> 15K in one hit. It would be a record of some sort
[01:55] <wgrant> It just needs to land.
[01:55] <lifeless> oh true
[01:55] <wgrant> Which relies on us being out of testfix.
[01:55] <StevenK> Which relies on a LOSA
[01:55] <wgrant> Right.
[01:56]  * StevenK writes a test, getting UploadFailed, and sighs at this layer crap
[01:56] <wgrant> Is it unacceptable to cheat by forcing the build then landing stuff?
[01:56] <StevenK> Haha
[01:56] <StevenK> It will fail in the same way and never make it to stable
[01:56] <lifeless> if your thing passed ec2 its fine
[01:57] <wgrant> Right, it will just fail again, but at least stuff will get landed.
[01:57]  * wgrant does it.
[01:57] <lifeless> wait
[01:57] <lifeless> you could rollback the apt thing
[01:57] <wgrant> Could.
[01:58] <lifeless> file a bug with the checklist of missed systems
[01:58] <wgrant> Ah, it's building again anyway.
[01:58] <StevenK> Who landed that, anyway?
[01:58] <lifeless> link it to a branch to reinstate it
[01:58] <lifeless> jtv I think
[01:58] <wgrant> StevenK: jtv. The RT says it's rolled out everywhere.
[01:58] <wgrant> But apparently not buildbot.
[01:58] <wgrant> (it did ask for it to be rolled out to buildbot)
[02:08] <lifeless> lp.soyuz.scripts.tests.test_publishdistro.TestPublishDistro.testPublishDistroRun
[02:08] <lifeless>  soyuz-set-of-uploads_txt
[02:08] <lifeless> ^ is that the apt thing ?
[02:08] <lifeless>  soyuz-upload_txt
[02:08] <wgrant> Yes.
[02:08] <lifeless> from ec2. sigh, I need a new ami don't I
[02:09] <wgrant> Erm. AMI 508 should be enough.
[02:09] <wgrant> Was this a really old branch?
[02:09] <lifeless> wgrant: I have a different tree for submitting from
[02:09] <lifeless> so ec2 vaguaries don't bit me - but when the upgrade is mandatory, it bites
[02:12] <lifeless> thumper: wallyworld: now you're on maintenance - 5th top timeout : 26 /   18  RootObject:+daily-builds :)
[02:12] <wallyworld> lifeless: i'm working on that one right now
[02:13] <wallyworld> actually, just context switched to land some branches from alst week
[02:14] <lifeless> we can't land anthing today
[02:14] <wallyworld> lifeless: i probably missed the discussion as to what's wrong with landing stuff?
[02:18] <lifeless> buildbot's vm was not updated with the new apt, so when jtv landded the code to depend on it we went into testfix and cannot get out without a losa
[02:18] <lifeless> or reverting his branch
[02:18] <wgrant> And reverting his branch when the fix is so easy and it's not going to cause a QA chain of pain seems bad.
[02:20] <wallyworld> ok. thanks
[02:27] <SpamapS> lifeless: is it possible the compaction error is happening because of the low fd limit?
[02:42] <lifeless> SpamapS: no
[02:43] <lifeless> SpamapS: its a classdefnotfound error
[02:43] <lifeless> SpamapS: got a lucid vm ?
[02:45] <lifeless> SpamapS: I've pushed my test code to lp:~lifeless/oops-repository/trunk
[02:46] <lifeless> SpamapS: just needs the cassandra ppa, the lp ppa
[02:55] <wgrant> Hmm.
[02:55] <wgrant> Codebrowse is down?
[02:55] <SpamapS> lifeless: ah ok.. right
[02:56] <lifeless> SpamapS: I think its a missing jar that isn't wrapped into the war for whatever reason
[02:56] <lifeless> SpamapS: but, branch my code, run make check.
[02:56] <lifeless> (oh, read README and install deps)
[02:56] <SpamapS> 3 hours later.. ;)
[02:57] <lifeless> wgrant: faaaark looks like it
[02:57] <lifeless> and yet, noone has complained
[02:57] <lifeless> spm: are you lurking? cause if you are, and aren't on leave, I'd rather bug you than wake elmo.
[02:58] <StevenK> 3am London time :-(
[02:58] <wgrant> pjdc: ?
[03:01] <wgrant> lifeless: Is codebrowse downness critical now? I thought it had some ridiculously high threshold before it could be treated as such.
[03:03] <wgrant> Hm.
[03:03] <wgrant> There is no guava.
[03:03] <wgrant> Everything else is pingable, so I presume the
[03:03] <wgrant> machine itself is down.
[03:04] <StevenK> guava replies to pings here?
[03:04] <wgrant> In..deed.
[03:04] <wgrant> But not from the DC.
[03:06] <wgrant> Looks like it is up, and carob can rsync from it, but not ping it.
[03:06] <wgrant> All the other prod machines are pingable :/
[03:06] <mwhudson> wgrant: guava is in the dmz
[03:07] <mwhudson> for stupid reasons
[03:07] <wgrant> Hmm.
[03:07] <wgrant> guava CPU graphs are a bit sad.
[03:07] <wgrant> https://lpstats.canonical.com/graphs/GuavaCPU/
[03:08] <wgrant> mwhudson: I suppose this isn't documented anywhere that non-IS can see?
[03:09] <mwhudson> wgrant: not that i know of
[03:09] <wgrant> Heh.
[03:09] <mwhudson> i guess you can probably see the rt i filed for "please move guava out of the dmz" about two years ago
[03:09] <wgrant> Anyway, looks like both codebrowses wandered off to chew on a CPU each at 01:20
[03:13] <wgrant> Ah, Francis rejected it.
[03:13] <wgrant> Sad.
[03:14] <wgrant> StevenK: OOPS-1884A1684
[03:16] <lifeless> wgrant: its gritical
[03:16] <lifeless> wgrant: we have two redundant codehosting instances
[03:17] <lifeless> why was the move rejected ?
[03:17] <lifeless> wgrant: so yes, if its down, it needs to be fixed. This is bread and butter facilities for our users.
[03:17] <wgrant> lifeless: See the bottom of https://rt.admin.canonical.com/Ticket/Display.html?id=33173
[03:18] <wgrant> lifeless: I recall that previously it has been said that it was not as critical as everything. I disagree, but that is how it was.
[03:18] <lifeless> if we've killed the arch mirror
[03:19] <lifeless> we can move within the main network
[03:19] <lifeless> wgrant: the old definition of critical is what you're thinking of, I think
[03:19] <lifeless> wgrant: that got overhauled late last year
[03:20] <wgrant> I recall it also had the Soyuz threshold at 24 hours, or something stupid like that.
[03:20] <lifeless> any launchpad service or feature becoming unusable
[03:20] <lifeless> immediately
[03:20] <lifeless> ...
[03:20] <lifeless> We aim to have none of these, ever.
[03:20] <lifeless> ...This includes beta features
[03:34] <StevenK> wgrant: :-(
[03:34] <wgrant> StevenK: ?
[03:34] <StevenK> wgrant: The OOPS you linked me
[03:34] <wgrant> Ah, yes.
[03:35] <StevenK> I bet I just generated another oops
[03:37] <StevenK> Hm. Only the no signer packages do that.
[03:38] <StevenK> Why do I have this bad feeling there's a deleted recipe involved.
[03:39] <wgrant> There is.
[03:39] <StevenK> :-(
[03:40]  * StevenK tries to swap in the branch details.
[03:43] <StevenK> wgrant: So a test for this would be create a recipe, link it to an SPR, call recipe.destroySelf() and then look at the view?
[03:43] <wgrant> StevenK: I think so.
[03:43] <wgrant> You may need to make sure that the SPRelease has no signer.
[03:44] <StevenK> That's going to be fun to do in TAL.
[03:44] <wgrant> Why?
[03:44] <wgrant> (I suspect it's more your new thing than the signer, but best to be thorough)
[03:46] <StevenK> I certainly am blaming my addition
[03:51] <StevenK> wgrant: I have a test written, let's see ...
[03:54] <StevenK> wgrant: Confirmed, the test fails in the same way as the OOPS.
[03:56]  * thumper is attacking a sub-100k bug number
[03:57] <thumper> made more fun by the blueprint and email aspect :)
[03:57] <StevenK> Whee, 350 lines of traceback
[04:04] <StevenK> wgrant: So, I can ignore printing the built by if the recipe is deleted, or I can say 'deleted recipe' -- what are your thoughts?
[04:05] <wgrant> I'd say "deleted recipe"
[04:05] <StevenK> ... or can I? How do you do if else in TAL?
[04:06] <StevenK> Or can haz a link to TAL documentation that doesn't make my eyes bleed?
[04:07] <wgrant> You'll have to use a tal:condition.
[04:10] <wgrant> There's nothing like genshi's py:when.
[04:10] <lifeless> tal:iban
[04:10] <StevenK> lifeless: Two drums and a cymbal fall off a cliff.
[04:10] <lifeless> boom boom tish ?
[04:13] <StevenK> PTRuntimeError: ['Compilation failed', 'HTMLParser.HTMLParseError: EOF in middle of construct, at line 34, column 9']
[04:13] <StevenK> :-(
[04:13] <thumper> pretty simple review: https://code.launchpad.net/~thumper/launchpad/blueprint-email-handler-bug-83414/+merge/51488
[04:14] <thumper> and un-contentious
[04:15] <wgrant> Isn't it illegal to have a Blueprint branch which adds more lines than it deletes?
[04:16] <lifeless> no
[04:16] <thumper> lifeless: thanks
[04:16] <lifeless> do the simplest thing possible
[04:16] <lifeless> velocity with solid code
[04:19] <thumper> wgrant: not when the addition is tests
[04:19] <lifeless> doesn't matter what it is
[04:19] <lifeless> its part of the same code base
[04:19] <lifeless> same rules as for anywhere else apply
[04:19] <lifeless> *if* IssueTracker goes ahead, it will get folded in
[04:20] <lifeless> if it doesn't, we need it maintained, and that means having a level playing field for patches to it.
[04:20] <lifeless> we *must not* make any part of the code less pleasant to work on than another, culturally, technically or otherwise.
[04:22] <StevenK> :-([A[APTRuntimeError: ['Compilation failed', 'zope.tal.taldefs.TALError: Invalid variable name "recipe" in expression u\'not sprb/recipe\', at line 37, column 9']
[04:22] <StevenK> Can I not do that in TAL?
[04:22] <lifeless> StevenK: what are you trying to do
[04:22] <wgrant> StevenK: Not like that.
[04:22] <lifeless> its also a bad idea even if you could
[04:22] <lifeless> you need to use the ID if you don't want to trigger lazy loading
[04:23] <wgrant> 'not: sprb/recipe'
[04:23] <LPCIBot> Project devel build #482: STILL FAILING in 5 hr 29 min: https://hudson.wedontsleep.org/job/devel/482/
[04:24] <StevenK> Hm. I think that's with the new apt
[04:24] <lifeless> wgrant: probably a bad idea unless the rest of the page is guaranteed to show the recipe
[04:25] <lifeless> wgrant: not: sprb/recipeID
[04:25] <wgrant> lifeless: The rest of the page is guaranteed to show the recipe.
[04:25] <lifeless> wgrant: kk. I will keep pushing this meme :)
[04:26] <wgrant> Does anybody have a Lucid LP machine?
[04:26] <wgrant> I guess I'll fire up an ec2 instance.
[04:26] <lifeless> I develop in a lucid vm
[04:26] <lifeless> whats up
[04:26] <wgrant> Ah.
[04:26] <wgrant> Can you run test_generateConfig?
[04:26] <wgrant> In devel, with the new apt.
[04:27] <wgrant> That is apt *ubuntu9.3+ppa1, or *ubuntu9.4
[04:28] <lifeless> 0.7.25.3ubuntu9.3+ppa1
[04:29] <wgrant> Does test_generateConfig pass?
[04:29] <lifeless>  lp.archivepublisher.tests.test_ftparchive.TestFTPArchive.test_generateConfig
[04:29] <lifeless>  lp.archivepublisher.tests.test_ftparchive.TestFTPArchive.test_generateConfig_empty_and_careful
[04:29] <lifeless>   Ran 2 tests with 0 failures and 0 errors in 7.168 seconds.
[04:30] <wgrant> TestFtparchiveIndices
[04:30] <wgrant> StevenK: Is it easy enough to fire up something identical to the Hudson slave and run a test on it?
[04:31] <wgrant> s/Hudson/Jenkins/
[04:31] <lifeless>   Running:
[04:31] <lifeless>  lp.archivepublisher.tests.test_publisher.TestFtparchiveIndices.testAllIndicesArePublished
[04:31] <lifeless>  lp.archivepublisher.tests.test_publisher.TestFtparchiveIndices.testNoIndicesForDisabledArchitectures
[04:31] <lifeless>  lp.archivepublisher.tests.test_publisher.TestFtparchiveIndices.testWorldAndGroupReadablePackagesAndSources
[04:31] <lifeless>   Ran 3 tests with 0 failures and 0 errors in 19.608 seconds.
[04:32] <wgrant> :(
[04:32] <wgrant> Thanks.
[04:32] <StevenK> wgrant: Yes
[04:34] <wgrant> StevenK: Could you fire one up, check the apt version, try test_generateConfig and TestFtparchiveIndices, and then stab a-f in the face?
[04:34] <wgrant> Ah, it's actually apt-utils that matters, but they are presumably the same.
[04:35] <wgrant> Although I wonder...
[04:36] <StevenK> Let's find out
[04:36] <wallyworld> lifeless: are you able to run a query against qastaging or prod and gather stats? or do i need a dba?
[04:38] <StevenK> wallyworld: All squad leads can run ro queries against {qa,}staging
[04:39] <StevenK> wgrant: Waiting for the builder to install
[04:39] <wallyworld> StevenK: cool thanks. i'll ask thumper :-) i also need an explain done
[04:39] <wgrant> StevenK: Thanks.
[04:39] <StevenK> wgrant: I'm doing it by hand, btw
[04:39] <wgrant> :(
[04:40] <lifeless> wallyworld: I can and thumper can
[04:40] <lifeless> wallyworld: pastebin away
[04:41] <StevenK> The following polling activities are currently in progress: db-devel 7 hours 24 minutes
[04:41] <StevenK> Eeeeep
[04:41] <StevenK> lifeless: How can I clean that up?
[04:41] <wallyworld> lifeless: it's a first cut at improving the dialy builds query. still has the group by but cuts out 3 tables from the join and appears perhaps significantly faster
[04:41] <lifeless> StevenK: the poll ?
[04:41] <wallyworld> lifeless: https://pastebin.canonical.com/44001/
[04:41] <StevenK> lifeless: Right
[04:42] <lifeless> StevenK: have a look - see if there is a wedged bzr process (and if so file a bug :))
[04:42] <wallyworld> lifeless: i just am interested in a comparison with what it does currently to see how much improvement there is
[04:43] <StevenK> There is. What can I do to it to get some debugging?
[04:43] <wallyworld> just tried to navigate to +daily-builds on qastaging and that timed out so qastaging's db should be sufficient to test against
[04:43] <lifeless> wallyworld: Time: 11231.630 ms
[04:43] <wallyworld> lifeless: :-( that's no good. i was expecting much better
[04:43] <lifeless> https://pastebin.canonical.com/44002/
[04:44] <lifeless> wallyworld: If I were working on this, I'd be executing on that thread we had about how the current page can be redesigned.
[04:44] <lifeless> wallyworld: I don't see any way of making it fast by sql tricks under the current schema
[04:44] <lifeless> your query is Time: 616.543 ms hot
[04:44] <lifeless> but IIRC the existing query is about that hot too
[04:44] <wallyworld> lifeless: yeah, but i just wanted to experiment a bit to see how much removing 3 tables from the big fat join would affect the results
[04:45] <lifeless> the 11 seconds is cold
[04:45] <lifeless> what tables did you drop, and what is the new definition of the results
[04:46] <StevenK> lifeless: So this bzr has an open socket, and is blocked in recv() -- doesn't seem like much of a bug to me
[04:46] <wallyworld> lifeless: i dropped the joins to person, sourcepackagename, archive tables and got that data using a single query for each using the pre_iter hook
[04:47] <lifeless> StevenK: hmm, network should have killed it by now though
[04:47] <lifeless> StevenK: 7 hours ...
[04:47] <StevenK> You'd think
[04:47] <wallyworld> lifeless: so the results are the same but without the ordering on archive , spname
[04:47] <StevenK> lifeless: I'm happy enough to wield kill and move on
[04:47] <lifeless> StevenK: yeah
[04:48] <lifeless> wallyworld: ah, you'd post process to do the archive ordering ?
[04:48] <wallyworld> lifeless: well, considering it if the query results were any good but alas. i really thought cutting out 3 tables would help
[04:48] <lifeless> wallyworld: it may well have
[04:49] <lifeless> wallyworld: staging cold is pretty cold
[04:49] <lifeless> the query plan cost of 5320.82 is pretty reasonable
[04:49] <wallyworld> lifeless: i did it to just to see the numbers plus to teach myself how to use the pre_iter hook and do eager loading and insert SQL() expressions etc into storm queries
[04:49] <StevenK> https://code.launchpad.net/~stevenk/launchpad/link-deleted-recipe-ppa-page/+merge/51490
[04:49] <lifeless> wallyworld: its almost certainly an improvement:)
[04:50] <lifeless> wallyworld: I encourage you to get it reviewed and land it, even if you do more subsequent work on the page.
[04:50] <wgrant> wallyworld: Did you use SQL() just because you could, or is Storm missing something?
[04:51] <wallyworld> lifeless: no, i had to use the SQL since i wasn;t selecting a whole table (class) anymore and storm complained if i used that expression in the group by or select clauses
[04:51] <wgrant> Hmm....
[04:52] <wgrant> You should be able to do that in Storm.
[04:52] <wallyworld> lifeless: my thoughts with this were i would try it as a quick win and if it helped, deploy it and iterate again to doa better solution, so you're thinking matches mine
[04:53] <lifeless> wallyworld: whats the class you were not selecting anymore ?
[04:53] <lifeless> (not selecting the whole table, I mean)
[04:53] <StevenK> wgrant: Can haz review? ^
[04:53] <wallyworld> lifeless: SourcePackageRelease - the only thing i need from that table is the sourcepackagename column to that i can load the sourcepackagename objects
[04:54] <wgrant> StevenK: Sure.
[04:54] <wallyworld> lifeless: anything in the select() has to go in the group by so i wanted to remove as much as possible
[04:54] <lifeless> wallyworld: SourcePackageRelease.sourcepackagenameID is what you should use
[04:54] <lifeless> wallyworld: see my mail about fooID vs foo - last tuesdays performance tuesday mail
[04:55] <StevenK> wgrant: Ignore the comment for test, changing pushing now
[04:55] <lifeless> wallyworld: SourcePackageRelease.sourcepackagename is a Reference and storm utterly fails to compile those as you might want it to
[04:55] <wallyworld> lifeless: let me try that.  i thought that sourcepackagename was the id column in this case but i'm wrong. on a related note, i got a bit confused between xxx_id and xxxID
[04:56] <lifeless> wallyworld: so xxx_id is how folk writing native storm often spell xxxID.
[04:56] <lifeless> wallyworld: xxxID is magically created by the sqlobject metaclass
[04:56] <lifeless> woo - another perf fix - lp:~lifeless/launchpad/bug-711064
[04:57] <wallyworld> lifeless: ah ok. i'm not fluent in storm yet. *much* better at Hibernate :-)
[04:57] <wallyworld> lifeless: off to pick up the kid from school. will clean it up when i get back and put up a merge proposal as a first step
[04:57] <lifeless> coolio
[04:57] <StevenK> If Hibernate is what you do at night, I'm pretty good at that too
[04:58] <wallyworld> StevenK: it's what i did before i joined Canonical :-)
[04:59] <wgrant> StevenK: Any progress on Jenkins?
[04:59] <StevenK> wgrant: "update-sourcecode"
[04:59] <wgrant> Yay..
[05:00] <StevenK> However, the node is about 2 hops from crowberry, so bzr is nice and fast
[05:00] <wgrant> Launchpad looks so nice in the Ubuntu font's Light variant...
[05:01] <wgrant> Gnargh.
[05:01] <StevenK> wgrant: "make schema"
[05:02] <lifeless> https://code.launchpad.net/~lifeless/launchpad/bug-711064/+merge/51491
[05:03] <lifeless> another I can has review plox
[05:04] <lifeless> hmm
[05:04] <lifeless> linking to a bug report has broken
[05:04] <lifeless> if you put an invalid thing in, it just goes to lala land
[05:05] <wgrant> lifeless: https://code.launchpad.net/~stevenk/launchpad/link-deleted-recipe-ppa-page/+merge/51490
[05:07] <lifeless> bah
[05:07] <lifeless> back to bugtask:+index or distribution:+bugs
[05:07] <StevenK> Dear buildout, MOVE IT
[05:07] <lifeless> wgrant: StevenK: btw, thats awfully close to 'too much code in the template'
[05:07] <wgrant> lifeless: BugTask:+index
[05:07] <wgrant> lifeless: It is.
[05:07] <StevenK> lifeless: Absolutely
[05:07] <lifeless> I'd consider a view property to give you want you want instead
[05:07] <StevenK> So I'm happy to refactor slightly
[05:07] <lifeless> I value the fix more than the pretty
[05:08] <lifeless> Its just a thought for future work.
[05:08] <lifeless> no point reworking what you have
[05:08] <lifeless> dinner
[05:08] <StevenK> lifeless: Well, I already thought it was ugly when I submitted it ...
[05:09] <StevenK> I'm unsure if I can just add a property onto SourcePackageRecipeBuild and have it return a linkifed string
[05:09] <wgrant> StevenK: You'd do it on the view.
[05:16] <StevenK> wgrant: make schema done. Remind me the tests to run, sorry?
[05:18] <wgrant> StevenK: test_generateConfig should do.
[05:18] <wgrant> StevenK: But apt and apt-utils versions first pls
[05:19] <StevenK> ii  apt                             0.7.25.3ubuntu9.3+ppa1          Advanced front-end for dpkg
[05:19] <StevenK> ii  apt-utils                       0.7.25.3ubuntu9.3               APT utility programs
[05:19] <wgrant> Ahaaaa
[05:19] <wgrant> There is our problem.
[05:19] <wgrant> does apt-get upgrade want to fix it?
[05:20] <StevenK> Yes
[05:20] <StevenK> I don't run apt-get upgrade on bring-up
[05:20] <wgrant> You explicitly upgraded apt? Or does it just install launchpad-dependencies each time?
[05:20] <StevenK> It explicity installs launchpad-developer-dependencies
[05:20] <wgrant> OK, I'll fix that.
[05:21] <wgrant> And update the RT.
[05:21] <wgrant> Thanks.
[05:21] <StevenK> wgrant: You think the buildbot slaves have the same issue?
[05:21] <wgrant> StevenK: It would not surprise me.
[05:21] <StevenK> Neither
[05:22] <LPCIBot> Project devel build #483: ABORTED in 58 min: https://hudson.wedontsleep.org/job/devel/483/
[05:23]  * StevenK tries to figure out how to get a URL in a view
[05:23] <wgrant> canonical_url
[05:27] <StevenK> wgrant: http://pastebin.ubuntu.com/573322/
[05:27] <wgrant> StevenK: Use a structuredstring or I will
[05:27] <wgrant> stab you with an XSS.
[05:28]  * StevenK smirks
[05:29] <StevenK> wgrant: Let me know when you've fixed launchpad-dependencies and friends and I'll tell Jenkins it can build.
[05:31] <wgrant> StevenK: Uploaded.
[05:32] <wgrant> We should really run process-upload more frequently.
[05:32] <StevenK> We should wait for the publisher anyay
[05:33] <StevenK> *anyway
[05:33] <wgrant> I will coerce bigjools into bumping it to */1 tonight.
[05:34] <StevenK> Really?
[05:35] <wgrant> Well, I will at least try.
[05:35] <StevenK> Personally, I liked his idea that process-upload is always running
[05:35] <wgrant> We already run it that often on cesium.
[05:35] <wgrant> Sure.
[05:35] <wgrant> That would be nice.
[05:36] <wgrant> But it's much harder than changing one bit in a crontab.
[05:36] <StevenK> wgrant: So, you mean "from canonical.launchpad.webapp.menu import structured" or do I misunderstand?
[05:36] <wgrant> StevenK: That seems to be where it lives :(
[05:38] <wgrant> Karma, I hate you.
[05:38] <StevenK> wgrant: Happy with the method name?
[05:39] <wgrant> StevenK: You could possibly drop source_package_, but apart from that it's good.
[05:39] <wgrant> And return None instead of "", I think.
[05:39] <wgrant> jtv: Hi.
[05:39] <StevenK> Yeah, already fixed that
[05:39] <jtv> hi wgrant
[05:40] <jtv> hi StevenK—I'm afraid I only gained a few hours on my previous timezone!
[05:40] <wgrant> jtv: Did you talk to IS about the apt upgrades?
[05:40] <wgrant> It seems like buildbot only has apt upgraded, not apt-utils.
[05:40] <wgrant> (a-f lives in the latter, so buildbot is now broken)
[05:40] <jtv> Damn.
[05:41] <wgrant> I'm wondering if you have any details beyond what's in the ticket.
[05:41] <wgrant> Since we are ISless.
[05:41] <jtv> Are we!?
[05:41] <wgrant> Until London wakes up, yes.
[05:41] <jtv> Where's the ticket?
[05:41] <StevenK> jtv: spm would have only arrived home a few hours ago
[05:41] <wgrant> https://rt.admin.canonical.com/Ticket/Display.html?id=43891
[05:41] <jtv> oh, poor man—where were they sprinting?
[05:41] <wgrant> London.
[05:42] <StevenK> LHR-SYD-CBR is like 34-38 hours
[05:42] <wgrant> Not quite *that* bad.
[05:43] <StevenK> Door-to-door, it can be
[05:43] <wgrant> True.
[05:46] <StevenK> Right, I think that's enough time -- re-enabling Jenkins
[05:46] <wgrant> StevenK: Not published in Lucid yet.
[05:46] <wgrant> Will be in 4 minutes, hopefully.
[05:46] <jtv> I wonder whether it's worth rolling back the change.  Probably not.
[05:47] <wgrant> Not at this stage.
[05:47] <StevenK> That's okay, I think I broke Jenkins view of the build anyway
[05:47] <LPCIBot> Project devel build #484: STILL FAILING in 58 sec: https://hudson.wedontsleep.org/job/devel/484/
[05:48] <jtv> It's probably not worth rolling back the change, but it's damned annoying.
[05:48] <StevenK> LPCIBot: Shhh
[05:49] <wgrant> Hudson should be fixed in a few minutes, and buildbot once we have an mthaddon.
[05:49] <wgrant> And that should be in just a few hours.
[05:49] <wgrant> So we'll live :)
[05:50] <jtv> Still, buildnot build 666 couldn't very well have gone without problems, could it?  Just not appropriate.
[05:50] <wgrant> Heh
[05:50] <StevenK> wgrant: tal doesn't like structured()
[05:50] <wgrant> StevenK: What are you doing?
[05:51] <StevenK>     <li tal:content="view/recipe_build_details" tal:condition="context/sourcepackagerelease/source_package_recipe_build" />
[05:51] <wgrant> StevenK: s/context/structure context/
[05:51] <wgrant> Er.
[05:51] <wgrant> Except on the other one.
[05:51] <jtv> er :)
[05:51] <wgrant> s/view/structure view/
[05:53] <StevenK> wgrant: http://pastebin.ubuntu.com/573328/
[05:54] <wgrant> StevenK: The tal:condition is redundant now.
[05:54] <StevenK> wgrant: Really?
[05:54] <wgrant> StevenK: recipe_build_details has an 'if sprb is not None'
[05:55] <StevenK> wgrant: Oh, that diff is against the approved MP rather than submit:, but I guess you figured that out
[05:57] <wgrant> StevenK: ppa:launchpad is now all published.
[05:57]  * StevenK fiddles with Jenkins
[05:58] <wgrant> Jedson may be happy now.
[05:58] <StevenK> Jedson. *facepalm*
[05:59] <StevenK> wgrant: So you're happy with my refactor and I should commit and push?
[05:59] <wgrant> This whole one-RT-account-to-rule-them-all thing is pretty confusing.
[06:00] <wgrant> StevenK: No, because you're bypassing the entire popint of structured()'
[06:00] <wgrant> Spot the XSS.
[06:01] <wgrant> Also:
[06:01] <wgrant> Single quotes around XML attribute values: Australia says no.
[06:02] <StevenK> Double quotes? :-)
[06:04] <StevenK> Orsum. structured has no help
[06:04] <wgrant> Do you know what it does?
[06:05] <StevenK> Spits out an instance of IStructuredString
[06:05] <wgrant> Well, yes...
[06:05] <StevenK> And if I'm reading this doctest right, it escapes its second argument
[06:06] <wgrant> Right. It takes a format string as its first argument, and interpolates it after escaping the following arguments
[06:06] <StevenK> Ah ha. Fixed by dropping % (
[06:07] <wgrant> Right.
[06:07] <StevenK> wgrant: Also dropped the structured() from 'deleted recipe' -- what's the point? :-)
[06:07] <wgrant> Indeed.
[06:07] <StevenK> wgrant: Would you like a new diff, or a commit and push?
[06:08] <wgrant> StevenK: A new diff would be nice.
[06:08] <StevenK> wgrant: Oh, from the new builder bring-up:
[06:08] <StevenK> Get:1 http://ppa.launchpad.net/launchpad/ppa/ubuntu/ lucid/main apt-utils 0.7.25.3ubuntu9.3+ppa1 [240kB]
[06:08] <wgrant> Excellent news.
[06:09] <StevenK> wgrant: http://pastebin.ubuntu.com/573331/
[06:09] <StevenK> Now to create an EBS volume with devel and db-devel checked out
[06:10] <wgrant> StevenK: Not sourcecode too?
[06:10] <StevenK> wgrant: Well, yes
[06:10] <wgrant> shipit has the LP history, so it takes ages.
[06:10] <StevenK> Jenkins can't check out shipit
[06:10] <wgrant> StevenK:
[06:11] <wgrant> You are missing quotes now...
[06:11] <StevenK> "recipe <a href=\"%s\">%s</a>",
[06:11] <StevenK> Rargh!
[06:11] <wgrant> Use single quotes on the string.
[06:11] <wgrant> So you can use unescaped double quotes inside it.
[06:12] <StevenK> Now you're just being difficult. Fixed.
[06:15] <StevenK>     <li><structured-string '<a href="%s">Built</a> by %s for <a href="%s">%s</a>'></li>
[06:15] <StevenK> :-(
[06:17] <wgrant> StevenK: Ah, add /escapedtext to the TALES
[06:18] <StevenK>     <li tal:content="structure view/recipe_build_details/escapedtext" />
[06:18] <StevenK> wgrant: ^
[06:18] <wgrant> Yeah.
[06:19] <wgrant> Our templates should really do this automatically.
[06:19] <wgrant> A couple of people have made that same mistake recently.
[06:20] <StevenK> Oh, damn it
[06:20] <StevenK> Now it escapes the recipe link
[06:20] <wgrant> Hah, I wondered if it might do that.
[06:21] <wgrant> I presumed it would be smart enough to find notice that it too was a structuredstring...
[06:21] <StevenK> *And* confuses TALES enough to get: LocationError: (None, 'escapedtext')
[06:21] <StevenK> OH
[06:21] <StevenK> Damn it
[06:22] <StevenK> That's TALES complaining when recipe_build_details() returns None
[06:22] <wgrant> Hah.
[06:22] <StevenK> F. A. I. L.
[06:22] <wgrant> You could make recipe_build_details return the .escapedtext
[06:23] <StevenK> It's a property or a method?
[06:23] <wgrant> Property.
[06:24] <StevenK> Now to figure out how to stop it escaping the recipe link
[06:26] <lifeless> noddy queries R us: WHERE Person.id = $INT LIMIT $INT:
[06:27] <StevenK> Hah
[06:27] <wgrant> That sounds like a .find(Person, id=1).any()
[06:27] <wgrant> I don't think Storm is stupid enough to do that itself.
[06:29] <StevenK> wgrant: And no, structured() just does it, there's no special casing for an instance of IStructuredString
[06:32] <wgrant> I may have to declare war on our shitty string handling infrastructure at some point.
[06:33] <StevenK> wgrant: Before or after your current war of "Death to lib/canonical" ?
[06:33] <wgrant> StevenK: I only deleted lib/canonical/widgets last week :(
[06:33] <wgrant> The active subwar is "death to Zopeless", which is going OK.
[06:34]  * lifeless whispers death to timeouts
[06:34] <wgrant> More like death to checkwatches.
[06:34] <lifeless> tim is looking at checkwatches mantis handling
[06:34] <lifeless> I'm awed
[06:34] <wgrant> Also, tomorrow it is death to long PQM and cronspam.
[06:34] <StevenK> Heh
[06:35] <lifeless> wtf
[06:35] <lifeless> SQL time: 2724 ms
[06:35] <lifeless> Non-sql time: 11740 ms
[06:35] <wgrant> Which view?
[06:35] <lifeless> https://lp-oops.canonical.com/oops.py/?oopsid=1884H2231
[06:36] <wgrant> Huh...
[06:36] <wgrant> Ah, anonymous.
[06:36] <lifeless> I wonder how many of these timeouts are due to e.g. storm overreleasing the gil (when its about to grab it again 2us later) and getting terrible scheduler performance as a result
[06:37] <lifeless> also memcache really isn't pulling its weight
[06:37] <lifeless> 232.1366124msmemcache
[06:37] <lifeless> bah
[06:37] <lifeless> 24ms anyhow
[06:37] <lifeless> on a get
[06:38] <lifeless> time to turn it off
[06:38] <StevenK> And remove it?
[06:38] <lifeless> no
[06:38] <lifeless> its useful for the front page
[06:39] <lifeless> we should eager load the blog posts thoughj
[06:39] <lifeless> and depend on them being in memcache
[06:39] <StevenK> Would s/\(its\) \(useful\)/\1 only \2/ be more accurate?
[06:40] <lifeless> not entirely
[06:40] <lifeless> need to analyse case by case
[06:42] <lifeless> stub: hi
[06:43] <lifeless> stub: we didn't get the staging restore script quite right, I've filed a bug and assigned to you; it didn't set the value for the flag correctly (should be 'on' not NULL).
[06:45] <jtv> StevenK: I'm puzzled by something in the derived-distro work.  Hoping you can help.
[06:46] <StevenK> jtv: Hm?
[06:46] <jtv> Well, AIUI there was supposed to be a static maximum of 1 layer of derivation.
[06:47] <jtv> I got the impression that this was a completely separate relationship from those within a distro.
[06:47] <wgrant> I hope not.
[06:47] <jtv> Ah
[06:48] <wgrant> We can have Debian Sid -> Ubuntu 10.04 -> Linaro 10.05
[06:48] <jtv> I'm asking because DistroSeriesDifference.new rather suggests that this is all based on parent_series.
[06:48] <wgrant> But the relationship is separate from the distro.
[06:48] <StevenK> Direct parent, we don't really want diffs from anything else
[06:48] <wgrant> Right. At the moment the derivation relationship is not modelled.
[06:48] <wgrant> So everything uses parent_series.
[06:49] <jtv> So as things stand, we can't have Debian Sid → Ubuntu 10.04 → Linaro 10.05.
[06:49] <wgrant> At the moment we can have no derivation at all.
[06:51] <jtv> So how does parent_series figure in all this?
[06:52] <StevenK> It was the best place to put it, but it's the wrong place.
[06:52] <wgrant> It does not affect derivation. Derivation needs a new attribute.
[06:52] <jtv> Okay, so that check for "this is a derived distroseries" will use the new attribute?
[06:53] <StevenK> Right
[06:54] <jtv> Thanks.
[06:55] <lifeless> uhm
[06:55] <lifeless> why a new attribute?
[06:55] <jtv> ?
[06:55] <jtv> Because it's not the same thing as the "parenthood" relationship we have between ubuntu releases.
[06:55] <wgrant> There are two types of derivation.
[06:55] <wgrant> Right.
[06:56] <lifeless> why do we have that relationship?
[06:56] <jtv> Arguably I suppose we _could_ model this as "parent_series is not of the same distro," but then you still can't model the Sid → 10.04 → 10.05 chain.
[06:56] <jtv> Why do we have which one?
[06:56] <lifeless> jtv: sure you could; linaro isn't ubuntu, its derived from. new distro
[06:56] <lifeless> jtv: we do we have a series->series relation within ubuntu, we don't have that for productseries.
[06:57] <wgrant> We use parent_series to do some fairly revolting build-related stuff right now.
[06:57] <jtv> Not to mention translations.
[06:57] <lifeless> details
[06:57] <lifeless> oh crud
[06:58] <jtv> There have been times I've wished for a parent_series on productseries, or a "trunk" series for Ubuntu, but I guess they're just different ways of workign.
[06:58] <jtv> *working.
[06:58] <lifeless> we loaded the bug subscription filters on qastaging didn't we
[06:58] <StevenK> Ubuntu does have trunk. It's called .currentseries
[06:58] <wgrant> jtv: The divergences are bugs.
[06:58] <jtv> wgrant: huh wha?
[06:59] <jtv> StevenK: sid is a trunk, natty is a current series.  Not the same to me.
[06:59] <jtv> Or if I'm wrong, I'll look mighty stupid for all the times I've told people "I'll do that when sid gets released."
[06:59] <StevenK> jtv: Huh? How is sid a trunk?
[06:59] <wgrant> Ah, I see your point.
[06:59] <StevenK> Sid will never get released
[07:00] <StevenK> But, right
[07:00] <lifeless> so take bzr; it has a trunk and a series that will be released
[07:00] <jtv> StevenK: which is exactly why I like to tell people I'll do their tedious work for them once it gets released. :)
[07:00] <StevenK> Yes, I get it
[07:00] <lifeless> our *data* model permits both
[07:00] <lifeless> why does our *data model* differ between productseries and distroseries in this fashion.
[07:01] <jtv> That's a good question.
[07:01] <StevenK> I have some people you could ask. They don't work for us any more, though.
[07:01] <lifeless> let me ask it differently.
[07:01] <jtv> If we take the view that There Has To Be a parent series, then either it's always trunk or things get a bit weird.
[07:01] <lifeless> what stops us removing 'parent_series'
[07:02] <StevenK> lifeless: The fact that Ubuntu O might want to be initialised
[07:02] <lifeless> StevenK: I don't understand the relevance
[07:03] <wgrant> i-f-p doesn't have to use parent_series.
[07:03] <jtv> But we're not actually making use of the tree structure that the current data model supports through parent_series, are we?
[07:03] <StevenK> It does currently, though
[07:03] <jtv> AFAIK it's all neatly linear.
[07:04] <jtv> Maybe it's really a holdover from when distroseries was distrorelease.
[07:04] <jtv> When you don't separate series from releases, then parent_series (or rather, parent_release) makes more sense.
[07:05] <jtv> Or am I getting my history screwed up and was it ProductSeries that used to be ProductRelease?  I _think_ I got it right the first time.
[07:05] <lifeless> grrr
[07:05] <lifeless> I *wish* the ++show decorator didn't trim the report.
[07:05] <lifeless> I think I'll fiddle that next
[07:05]  * jtv checks the vestigial test factory
[07:06] <wgrant> jtv: It was DistroRelease
[07:06] <jtv> Yup
[07:06] <wgrant> That's why we still have dr and dar everywhere.
[07:06] <jtv> But you see my point?  parent_release makes a lot more sense when you don't have series.
[07:07] <wgrant> A little.
[07:09] <jtv> AFAICS the series replace a generic tree structure of derived releases with a fixed two-level one: series are created in progressive order and within each series, releases are created in progressive order.
[07:10] <wgrant> Except that we don't model distroreleases yet, but yes.
[07:11] <jtv> Parenthood probably isn't a very good relationship between releases—you get issues like "what if nobody tagged the most recent common ancestor?"
[07:13] <jtv> And "if I backpatch a bugfix to a maintenance series, isn't it arbitrary to say that the resulting maintenance release is a child of the series' preceding release but not from the fix in the development series?"
[07:14] <jtv> So maybe lifeless has a point, and we want "predecessor" (which we could probably derive) rather than "parent" (which is more generic than AFAIK we actually use)
[07:14] <jtv> More importantly, of course,
[07:14] <jtv> I'm out of coffee.
[07:17] <wgrant> And out of Internet?
[07:18] <lifeless> we're still testfuxed, right ?
[07:19] <wgrant> Yes.
[07:19] <wgrant> Hudson should be testfixfixed, but buildbot needs an upgrade.
[07:35] <lifeless> oh my
[07:35] <lifeless> -fail-
[07:35] <lifeless>   File "/home/robertc/launchpad/lp-branches/working/lib/lp/bugs/browser/bugtask.py", line 512, in _get_task_for_context
[07:35] <lifeless>     for bugtask in list(bug.bugtasks):
[07:36] <stub> lifeless: Is NULL ever a valid feature flag value? I suspect not, since there is no way to add that via the web ui.
[07:37] <wgrant> lifeless: That looks like the NullBugTask infestation.
[07:37] <wgrant> Or is that somewhere else?
[07:38] <lifeless> stub: no, its not
[07:38] <lifeless> wgrant: no, its the traversal
[07:38] <lifeless> wgrant: the traversal lazy loads *every bugtask*
[07:38] <lifeless> wgrant: sorry, late evaluates every bugtask target
[07:38] <wgrant> lifeless: That shouldn't be lazy...
[07:38] <wgrant> Right.
[07:39] <lifeless> wgrant: its late, my phrasing is fubared
[07:39] <lifeless> stub: for clarity, NULL isn't valid - thats why staging is down
[07:39] <lifeless> stub: but it wasn't meant to be null, or '', it was meant to be 'on'
[07:39] <lifeless> stub: if you could fix staging that would rock
[07:40] <stub> Just clarifying Bug #726128
[07:40] <_mup_> Bug #726128: staging restore script creates invalid feature rule <oops> <Launchpad itself:Triaged> <Launchpad Staging Scripts:In Progress by stub> < https://launchpad.net/bugs/726128 >
[07:41] <stub> lifeless: staging db updated
[07:42] <lifeless> stub: brilliant, thanks, thats made it happy
[07:46] <lifeless> stub: , all - have a great day
[07:46] <lifeless> I'm going to call it a night for now
[07:46] <lifeless> I hope to be mass landing branches in the morning :)
[07:47] <lifeless> stub: you're on call reviewer now aren't you? if so - https://code.launchpad.net/~lifeless/launchpad/bug-722956/+merge/51481 and https://code.launchpad.net/~lifeless/launchpad/bug-711064/+merge/51491 are product from today.
[07:47] <stub> lifeless: k
[08:43] <jtv> StevenK: did you get my questions in this channel around one hour ago?  Or perhaps answer them already?  My connection broke not long after I asked.
[08:44] <StevenK> jtv: If the other context is "I am out of coffee" none of them looked like questions?
[08:44] <jtv> "This connection has been quiet for minutes now.  That's not normal for Internet (http, torrents, and games).  Let's drop it."
[08:45] <jtv> StevenK: then they didn't make it out.  Mind if I paste?  It's pretty basic but I like to have my assumptions confirmed sometimes.  :)
[08:45] <StevenK> jtv: Sure, go ahead
[08:46] <jtv> OK, here goes:
[08:46] <jtv> StevenK, to make sure that I still have the right picture: we're trying to get to a state where every new sourcepackagepublishinghistory record for a distroseries that's in a derivation relationship also triggers creation of zero or more distroseriesdifferencejobs for distroseries that it's derived from and ones that are derived from it… correct?
[08:46] <jtv> and if so, the processing of a distroseriesdifferencejob may result in a distroseriesdifference being created or updated, right?
[08:46] <jtv> Or deleted, if the difference goes away.  I guess that's how synchronizing a package would go through the system.
[08:48] <StevenK> jtv: "distroseries that it's
[08:48] <StevenK>                derived from"
[08:48] <StevenK> Only. Since the child didn't change, and we only do one level of indirection
[08:49] <jtv> StevenK: Oh—I thought reviews "upstream" from the derived series were to be reviewed (and optionally synchronized) through the same UI.
[08:49] <StevenK> jtv: Right, but not all the way upstram
[08:49] <StevenK> *upstream
[08:50] <jtv> OK, so all I need to worry about is "this new SPPH may constitute a new, or removed, difference from the parent DS."
[08:51] <StevenK> jtv: *Or* the child. Or both
[08:52] <StevenK> In the Debian Sid -> Ubuntu 10.04 -> Linaro 10.05 case, if a new SPPH is thrown to Ubuntu, we want new DSDs for the Debian <-> Ubuntu case and then Ubuntu <-> Linaro case
[08:53] <StevenK> s/then/the/
[08:53] <StevenK> wgrant: Tossing the ugly TAL branch at ec2
[08:53] <jtv> StevenK: okay, but then I don't understand the correction you made earlier—"distroseries that it's derived from, only."
[08:54] <StevenK> jtv: Following on from my earlier example, if there is new SPPH in Debian, I thought you meant Debian <-> Ubuntu and Debian <-> Linaro
[08:54] <jtv> Ah OK, no I meant exactly what you said.
[08:54] <jtv> So violent agreement there.
[08:55] <StevenK> Agreed
[08:55] <jtv> Cool.  Then I can start looking at how to approach implementation.
[08:58] <mrevell> Hello
[09:00] <wgrant> Morning mrevell.
[09:01] <jtv> hi mrevell!
[09:03] <jtv> StevenK: I suppose a derived series can have a SPPH with the same SPR as a SPPH in the parent release, in which case there's no need for a DSD?
[09:04] <StevenK> jtv: Exactly
[09:04] <jtv> s/parent release/parent DS/
[09:04] <jtv> (in case I'm not making my acronym quota)
[09:05] <jtv> I think there was mention of pre-existing derived series… how are those modeled?
[09:05] <StevenK> There was? I can't recall
[09:06] <wgrant> jtv: Just wait until you start dealing with recipes.
[09:06] <wgrant> Then you have SPRs producing SPRs.
[09:06] <wgrant> And then they end up creating DASBPRs!
[09:06] <jtv> cool
[09:07] <jtv> The last bit of course makes perfect sense—but I wouldn't think it was new.
[09:07] <jtv> Ahh, the days when an inches-thick A4-sized operating system manual would boast "this is the only acronym in the UI module"…
[09:08] <jtv> YKYBRUTLW…
[09:09] <wgrant> I think I got that one.
[09:10] <jtv> That is one of the many forms of YKYBRUTLW: YKYBRUTLWYUALT
[09:10] <jtv> You Know You've Been Reading Usenet Too Long When You Understand Acronyms Like These.
[09:11] <wgrant> Heh.
[09:11] <StevenK> Ooh, ITYJMTUOTS
[09:12] <StevenK> I Think You Just Made That Up On The Spot
[09:14]  * wgrant is beginning to suspect that checkwatches is in fact an elaborate trap set for those who want to write tests for it.
[09:14] <wgrant> It's like Soyuz, except with 10 extra levels on indirection, some of which are XML-RPC.
[09:14] <jml> heh
[09:15] <jtv> wgrant: yes… there are some helpers for it though; allenap knows
[09:15]  * jtv hates xmlrpc
[09:15] <StevenK> Vallium helps with checkwatches
[09:15]  * jtv once told one of the makers of XML it was all his fault
[09:16] <allenap> Strychnine is the checkwatches drug of choice.
[09:17] <allenap> wgrant: You have my unending sympathy. What are you trying to test?
[09:17] <allenap> The question "what are you trying to test" can be hard to answer with checkwatches.
[09:18] <wgrant> allenap: Exception handling in _updateBugTracker.
[09:19] <wgrant> I think I will just entirely patch out _getExternalBugTrackersAndWatches, rather than trying to get a custom ExternalBugTracker in.
[09:20] <allenap> wgrant: Yeah, good idea.
[09:25] <jtv> StevenK: when comparing SPPHs for two DSes, can I just compare the two SPPHs with the most recent base_versions?  Or do I need to do this separately for each base_version I find?  Or is there even some guarantee that all I need is the most recent SPPHs?
[09:26] <StevenK> jtv: You know, I did finish work about three hours ago, right? :-)
[09:26] <jtv> StevenK: oh yeah?  Then why are you here responding to my question?  :-P
[09:27] <StevenK> Because I have this OCD about red in my IRC client
[09:27] <jtv> The correct answer was a timeout.  :)
[09:28] <StevenK> jtv: If you feed in the two latest SPRs into DSD, it should set the base correctly, but I suspect that isn't your question
[09:28] <jtv> No, it's more how I find the right SPPHs with the right SPRs in them.
[09:29] <StevenK> An SPPH has one SPR. You already have the SPPH that caused the change, so grab the latest SPR for that SPN from the other DS
[09:31] <allenap> wgrant: Do you know if anyone figured out why ec2 runs were not reporting any results?
[09:31] <jtv> So that's the latest for that SPN, not the latest for that SPN plus base version?  I'm asking since I have to pre-populate based on existing data, so we'll have older SPPHs.
[09:33] <jtv> I guess a DS picks one base_version for an SPN and sticks with it?
[09:33]  * jtv should leave StevenK in peace now
[09:33] <StevenK> Heh
[09:33]  * StevenK goes to see how dinner is progressing
[09:33] <jtv> good night!
[09:42] <wgrant> allenap: I landed that fix this morning.
[09:43] <wgrant> allenap: jml's excellent new ec2 list had the not so excellent side-effect of breaking that.
[09:43] <wgrant> But it was an easy fix.
[09:45] <wgrant> StevenK: Confirmed does not exist :(
[09:46] <wgrant> jtv: buildbot seems happy now.
[09:46] <adeuring> good morning
[09:55] <allenap> wgrant: Fantastic! :)
[10:41] <gmb> henninge: I have a 69-line JS branch if you've got time to review it.
[10:42] <henninge> gmb: throw it at me!
[10:42]  * gmb lobs https://code.launchpad.net/~gmb/launchpad/fix-subscribe-form-preloading-bug-722450/+merge/51510 at henninge 
[10:43]  * henninge sometimes is a good catcher ... like just now.
[10:43] <gmb> :)
[11:47] <henninge> gmb: Sorry for being a bit slow. I got distracted but I also don't have much practice in JS reviews.
[11:48] <henninge> gmb: I don't see the last sentence of your cover letter reflected in the code.
[11:48] <gmb> henninge: That's okay. The diff looks a little funky anyway (I guess it's because of where I put the new function). If you'd rather wait for someone who's got JS experience to take a look, that's fine; it's not urgent.
[11:48] <henninge> no, I want the JS experience ... ;)
[11:49] <henninge> gmb: my other question is: why can you do away with the spinner?
[11:49] <gmb> henninge: Just a sec; someone at the door
[11:50] <henninge> as long as they are not trying to sell windows ...
[11:52] <LPCIBot> Project devel build #485: STILL FAILING in 5 hr 43 min: https://hudson.wedontsleep.org/job/devel/485/
[11:56] <henninge> gmb: I am off for lunch, we can continue later.
[11:57] <gmb> henninge: Okay, sure.
[11:59]  * gmb takes the opportunity to lunch, too.
[13:00] <jelmer> jml: are there any plans to remove the "Recipe builds are experimental" box on recipe pages?
[13:00] <jml> jelmer: there'd better be!
[13:09] <maxb> Are there plans to expose performDailyBuild() in the web UI ?
[13:14] <jelmer> maxb: There is a button for that actually
[13:14] <jelmer> maxb: but it only appears when there is a new version that can be built
[13:14] <maxb> hm
[13:15] <maxb> I have not seen this button
[13:15] <maxb> And I have usefully called it over the API
[13:16] <gmb> henninge: I'm back from lunch, so just ping me when you want to resume our discussion.
[13:16] <leonardr> maxb: my squad is working on that now
[13:16] <maxb> oh *there's* that link
[13:18] <maxb> Now that's shiny
[13:18] <jelmer> it is
[13:20] <tumbleweed> leonardr: care to give me a hand with getting the new launchpadlib behaving over ssh? I proposed for ubuntu-dev-tools, but it seems a bit of a nasty regression that I can't use it over ssh https://code.launchpad.net/~stefanor/ubuntu-dev-tools/launchpadlib-1.9/+merge/51475
[13:21] <leonardr> tumbleweed: try putting "export `gnome-keyring-daemon`" into your bashrc. that will make the gnome keyring run in your x session when you ssh in
[13:22] <tumbleweed> leonardr: I tried doing that (not in bashrc, and didn't seem to do anything
[13:23] <tumbleweed> do I really want one gnome-keyring-daemon per shell?
[13:23] <leonardr> tumbleweed: there's another workaround, let me try to find it
[13:23] <leonardr> i don't actually know which workaround is better
[13:24] <tumbleweed> me knows very little about gnome-keyring, which probably doesn't help
[13:25] <leonardr> i now know about gnome-keyring but not about x
[13:30] <leonardr> tumbleweed, what happens when you try this with gnome-keyring-daemon exported?
[13:46] <tumbleweed> leonardr: gnomekeyring.IOError
[13:48] <jelmer> we've seen that with bzr-gtk as well
[13:49] <tumbleweed> jelmer: yeah I have too
[13:49] <jelmer> we're working around it by ignoring gnomekeyring if it raises IOError
[13:52] <tumbleweed> well, we have to get the launchpad credentials from somewhere
[13:52] <tumbleweed> so if we ignore that error, we need a fallback
[13:53] <tumbleweed> is there a standard location for an on-disk credential store, or must that be provided to login_with?
[13:58] <jelmer> 'morning cr3
[13:59] <cr3> jelmer: hola senor!
[13:59] <leonardr> tumbleweed: python-keyring handles the on-disk credential store
[13:59] <leonardr> so, yes, there is a standard location
[13:59] <leonardr> but i would much rather figure out how to make gnome-keyring work for everyone
[14:48] <leonardr> tumbleweed, try this out:
[14:48] <leonardr> export `dbus-launch`
[14:48] <leonardr> it does look like you're supposed to have one daemon per session. maybe that's something the gnome-keyring people could optimize
[14:51] <tumbleweed> it would be nice if launchpadlib printed the auth URL, rather than diving straight into elinks
[14:52] <tumbleweed> i.e. make elinks optional. I've always quit it and pasted theURL into my desktop's open browser
[14:53] <tumbleweed> anyway, I can't seem to login via elinks
[14:54] <tumbleweed> leonardr: I grabbed the token-auth URL from the process command line, authed it, quit elinks, and now I get "keyring.backend.PasswordSetError
[14:55] <leonardr> tumbleweed: launchpadlib does both. it prints the auth url and opens a web browser. i guess you don't see it because elinks takes over the console?
[14:55] <tumbleweed> yeah
[14:55] <tumbleweed> IIRC it used to wait for one to press enter after quitting elinks?
[14:57] <leonardr> tumbleweed: right. i took that out because it was unnecessary. launchpadlib can see whether you've authorized the token on its own
[14:58] <tumbleweed> leonardr: yeah, but I used to be able to quit elinks, do the auth, then press enter
[14:58] <tumbleweed> unless it's polling launchpad, in which case ignore me :)
[14:58] <leonardr> tumbleweed: it should work the same now, except without pressing enter
[14:58] <leonardr> yeah, it's polling launchpad
[14:58] <leonardr> tumbleweed: this PasswordSetError you get
[14:58] <leonardr> is that when you export dbus-launch?
[14:59] <tumbleweed> yes
[14:59] <tumbleweed> I have a desktop session open on the machine I'm ssh-ing into
[14:59] <leonardr> ok, is it a gnome desktop?
[14:59] <tumbleweed> yeah
[14:59] <leonardr> can you paste me the traceback of the error?
[15:00] <tumbleweed> leonardr: http://paste.ubuntu.com/573478/
[15:00] <leonardr> tx
[15:01] <leonardr> argh, it's re-raised
[15:02] <leonardr> let me try dbus-launch and see what happens for me
[15:14] <leonardr> tumbleweed: for some random reason i seem to be using an unencrypted file instead of a keyring... solving that problem first and will then see how my setup compares to yours
[15:14] <tumbleweed> heh, cool
[15:15] <tumbleweed> I only have one machine running natty (my laptop), so I haven't played around too much
[15:16] <leonardr> tumbleweed: i would like to see the original context of that exception. if you wouldn't mind going into credentials.py and commenting out the try/except clause from CredentialStore.save()
[15:16] <leonardr> we could make some progress
[15:17] <tumbleweed> sure
[15:20] <tumbleweed> leonardr: http://paste.ubuntu.com/573490/
[15:21] <tumbleweed> sorry, haven't dived into this wholehartedly, busy writing an ubuntu-dev-week talk for this evening
[15:23] <leonardr> np
[15:32] <leonardr> benji, welcome to ocr
[15:32] <benji> leonardr: I'm a real boy now.
[15:58] <leonardr> did someone recently change the oauth 'invalid access token' message?
[15:59] <leonardr> i think it changed recently and broke launchpadlib
[16:00] <cr3> is there any reason why bugs can't be searched by date range?
[16:05] <henninge> gmb: let's finish this review ;-)
[16:05] <gmb> henninge: Ah, I asked benji to take over since you'd gone off-call.
[16:05] <gmb> Sorry, didn't realise you were still around for some reason.
[16:06] <henninge> gmb: that's ok, I wasn't feeling too great earlier and took a longer break.
[16:06] <gmb> henninge: Okay. Hope you feel better.
[16:06] <henninge> that's why I took myself off so I won't get more requests.
[16:06] <henninge> yes, pain killers kicked in ...
[16:06] <henninge> thanks
[16:10] <leonardr> salgado: i'm still asking you damn questions about oauth
[16:10] <leonardr> is there a mechanism (manual or otherwise) for clearing expired access tokens out of the database?
[16:11] <salgado> leonardr, heh, that's fine
[16:11] <leonardr> because it looks like they never used to be cleared out of the database, but now they are
[16:11] <leonardr> iow i encountered a problem that i would have encountered a long time ago if they were cleared from the database regularly
[16:12] <salgado> leonardr, I don't remember seeing anything that would delete access tokens
[16:13] <leonardr> ah, i know what it is. this is on staging
[16:13] <salgado> but I think we've always had working code to reject them when they were expired
[16:13] <leonardr> and on staging, the whole database is cleared
[16:13] <salgado> oh, right
[16:13] <leonardr> salgado: yeah, i had it working for expired tokens
[16:17] <leonardr> benji: an easy branch for you: https://code.launchpad.net/~leonardr/launchpadlib/handle-unknown-token/+merge/51563
[16:17] <benji> leonardr: thanks
[16:24] <jcsackett> gmb: have a moment?
[16:25] <gmb> jcsackett: Sure
[16:26] <jcsackett> gmb: i was told you landed some work at one point to allow admins to mark bug comments as not visible, but i can't find what that might be. could you point me in the right direction?
[16:26] <gmb> jcsackett: You were misinformed, sadly. I have no recollection of doing that.
[16:26] <gmb> It *might* have been intellectronica that did it, back in the day, but I honestly have no idea.
[16:26] <jcsackett> gmb: that's disheartening. :-p
[16:26] <gmb> Yeah.
[16:27] <jcsackett> gmb: thanks for clearing that up, though.
[16:27]  * jcsackett goes back to the hunt.
[17:19] <LPCIBot> Project devel build #486: STILL FAILING in 5 hr 26 min: https://hudson.wedontsleep.org/job/devel/486/
[17:25] <lifeless> moin
[19:53] <sinzui> jcsackett: ping
[19:53] <jcsackett> hi sinzui.
[19:54] <sinzui> jcsackett: do you have time to mumble about bug/726628
[19:54] <sinzui> bug 726628
[19:54] <_mup_> Bug #726628: flag-expired-memberships can trip an assertion check <teams> <Launchpad itself:Triaged> < https://launchpad.net/bugs/726628 >
[19:55] <jcsackett> sure.
[20:08] <manish> how does launchpadlib open the browser for authentication?
[20:08] <manish> use gnome-open?
[20:08] <sinzui> I think xdg-open
[20:08] <manish> thanks, trying
[20:09] <manish> sinzui: works. Thanks
[20:18] <jcsackett> sinzui: no need to chat later; found a fix.
[20:19] <sinzui> \o/
[20:22] <LPCIBot> Project db-devel build #402: STILL FAILING in 5 hr 54 min: https://hudson.wedontsleep.org/job/db-devel/402/
[20:48] <jcsackett> clear
[21:04] <thumper> leonardr: mumble?
[21:04] <leonardr> thumper: wow, it's 4 already. sure
[21:05] <thumper> wallyworld, leonardr: https://dev.launchpad.net/MaintenanceRotationSchedule
[21:12] <lifeless> leonardr: hi
[21:12] <leonardr> hi lifeless
[21:12] <lifeless> leonardr: I have a question about how to glue some stuff up in the webservice
[21:12] <leonardr> sure
[21:12] <lifeless> if you look at bug.bugtasks
[21:12] <lifeless> its exported
[21:12] <lifeless> but the code doesn't know the current user
[21:12] <lifeless> so we end up querying for all bugtasks
[21:13] <lifeless> then doing late evaluation access checks on each task
[21:13] <lifeless> how would I change it to use a method rather than a property, so that the user can be passed in
[21:13] <lifeless> (but still look like a collection to the web service)
[21:14] <leonardr> good question. you can use @call_with(user=CURRENT_USER) to pass in the current user
[21:14] <leonardr> i need to look at the code to see if you can do that and still make it look like a collection
[21:14] <leonardr> it may not be possible now
[21:14] <lifeless> ok
[21:14] <lifeless> well I'm currently hacking on BugTask:+index which shares the issue
[21:15] <lifeless> I'll add a new method for now
[21:15] <lifeless> and if we can figure out how to glue it up, that will be cool.
[21:23] <maxb> Hmm. It would appear that SourceForge runs anonymous mercurial access on port 8000. Should I file a question and assign to the LOSAs asking for accomodations in the firewalling of the importds?
[21:24] <leonardr> bug 271010
[21:24] <_mup_> Bug #271010: OOPS accessing a non-existent oauth token page. <api> <lp-foundations> <oauth> <oops> <Launchpad itself:Triaged> < https://launchpad.net/bugs/271010 >
[21:25] <leonardr> lifeless: you might want to file a bug about it. 'accessor method' would be a useful analogue to 'mutator method'
[21:25] <lifeless> leonardr: on lazr.restful ?
[21:25] <leonardr> lifeless: yes
[21:25] <leonardr> and when i put it like that, i know we don't have this feature
[21:26] <lifeless> we do it for /branches
[21:26] <lifeless> kindof
[21:28] <lifeless> leonardr: https://bugs.launchpad.net/lazr.restful/+bug/726803
[21:28] <_mup_> Bug #726803: not possible to export a method as a collection with bound parameters <lazr.restful:Triaged> < https://launchpad.net/bugs/726803 >
[21:29] <lifeless> leonardr: I hope I captured it clearly
[21:31] <leonardr> lifeless: looks great
[21:31] <huwshimi> jml: I'm available whenever you are.
[21:32] <thumper> maxb: yes
[21:32]  * StevenK glares at buildbot
[21:33] <leonardr> thumper: the python-keyring bug i filed: https://bitbucket.org/kang/python-keyring-lib/issue/40/failures-happen-at-random-points-in-the
[21:33]  * benji is startled to see buildbot glare back at StevenK.
[21:34] <leonardr> benji, you might be interested in that bug as well -^
[21:34] <StevenK> Haha
[21:34] <benji> leonardr: hmm, taking a look
[21:35] <StevenK> Windmill hang in the last devel run, and buildbot has completly ignored that devel has changed for about five hours
[21:36] <wgrant> Oh come on, that failed like 5 hours ago :/
[21:37] <wgrant> Nobody forced it :(
[21:37] <StevenK> Just did.
[21:40] <benji> leonardr: I concur very much with the intent of your bug report; in my opinion the proximate cause is the unnecessarily eager choosing of the backend
[21:41] <maxb> thumper: filed, thanks
[21:55] <lifeless> oh wow
[21:55] <lifeless> we've been disclosing the existence of private bugtasks all over the place forever.
[22:01] <lifeless> hmm
[22:01] <lifeless> current user isn't clearly visible to traversal code :<
[22:06] <jcsackett> benji: i know it's getting late, but is there any chance you have time to do a review on 150 line MP?
[22:07] <benji> jcsackett: if it's https://code.launchpad.net/~jcsackett/launchpad/bug-comment-visibility/+merge/51637, I just did. :)
[22:07] <jcsackett> benji: it is indeed. thanks a lot. :-)
[22:07] <benji> np
[22:20] <wgrant> :( QA
[22:36] <jcsackett> sinzui: standup?
[22:48] <huwshimi> sinzui: What did you want to investigate with light/regular?
[22:52] <LPCIBot> Project devel build #487: STILL FAILING in 5 hr 32 min: https://hudson.wedontsleep.org/job/devel/487/
[23:01]  * thumper sighs
[23:01] <thumper> qa-bad makes me sad
[23:02] <thumper> how to I say a new landing fixes a qa-bad?
[23:02] <wgrant> thumper: --rollback=1234
[23:02] <wgrant> And tag the bug bad-commit-1234
[23:02] <thumper> I don't want to roll it back
[23:02] <thumper> I want to fix it
[23:02] <wgrant> I know.
[23:02] <wgrant> But you have to --rollback=1234
[23:02] <thumper> that kinda blows
[23:03] <wgrant> Yup.
[23:03] <lifeless> so fix it
[23:03] <wgrant> What's bad?
[23:03] <lifeless> qatagger is the project
[23:04] <thumper> wgrant: the updating of the debversion and base branch
[23:04] <thumper> the context is updated
[23:04] <thumper> but there is a JS error on the page
[23:04] <thumper> I think it came from a weird merge
[23:04]  * thumper is fixing
[23:04] <wgrant> Is it trivial to fix?
[23:04] <thumper> yes
[23:04] <thumper> delete one line
[23:04] <wgrant> Great.
[23:04] <wgrant> Bypass ec2.
[23:20] <thumper> wgrant: what is the pqm commit message I need for the rollback syntax?
[23:20] <thumper> wgrant: I don't have a merge proposal for the tweak
[23:20] <thumper> wgrant: nm
[23:20] <wgrant> thumper: [rollback=$BADREVNO]
[23:20] <wgrant> No QA tags other than that.
[23:20] <sinzui> huwshimi: sabdfl replied the the regular/light discussion on warthogs. Light ishould look good with content. as 12px, I thought it was too light. Maybe my screen is too small to judge.
[23:21] <wgrant> sinzui: It looks too light next to the monospace font that we use.
[23:21] <wgrant> But apart from that i think it looks great.
[23:22] <huwshimi> sinzui: Yes I saw that comment.
[23:22] <sinzui> wgrant: are you looking at my branch that changes most of the font rules?
[23:22] <wgrant> sinzui: I was going to look at that at some point.
[23:23] <wgrant> sinzui: Is that your -1 branch?
[23:23] <lifeless> *sob*
[23:23] <lifeless> Distribution._init
[23:23] <lifeless> *stab stab stab*
[23:24] <huwshimi> sinzui: Not sure what to think really.
[23:24] <sinzui> if you think it is too light now, ~sinzui/launchpad/fixed-font-sizes-1 will make you cry with light
[23:24] <wgrant> lifeless: Yes, I pointed that out to you last week :)
[23:24] <lifeless> similarly Person._init
[23:24] <sinzui> I favour landing it. We can change the font easily if users think it is too dark
[23:24] <wgrant> That's fine.
[23:25] <wgrant> sinzui: Do you have screenshots?
[23:25] <huwshimi> sinzui: I'm happy with that
[23:26] <sinzui> one moment
[23:28] <wgrant> Hmm, all the heading styles have changed.
[23:30] <sinzui> wgrant: this is the proposal http://people.canonical.com/~curtis/new-font-rules.png
[23:30] <huwshimi> sinzui: I suspect there is a reason behind Mark saying that light is best for content. There must be some some data or research behind it and if it goes into the guidlines we can think about it more then.
[23:31] <wgrant> sinzui: The new monospace style is much nicer.
[23:31] <wgrant> But some of the headings are too big.
[23:31] <sinzui> huwshimi: I think the same. Since ubuntu.com is using 13px, I would not use it when judging light font
[23:31] <wgrant> eg. https://launchpad.dev/bugs/1, the CVE References is huge.
[23:31] <_mup_> Bug #1: Microsoft has a majority market share <iso-testing> <ubuntu> <Clubdistro:Confirmed> <Computer Science Ubuntu:Invalid by compscibuntu-bugs> <EasyPeasy Overview:Invalid by ramvi> <GNOME Screensaver:Won't Fix> <Ichthux:Invalid by raphink> <JAK LINUX:Invalid> <The Linux OS Project:In Progress> <metacity:In Progress> <OpenOffice:In Progress by lh-maviya> <Tabuntu:Invalid by tinarussell> <Tivion:Invalid by shakaran> <Tv-Player:New> <Ubuntu:I
[23:32] <sinzui> wgrant: h2's are meant to be huge. I made ours smaller than suggested
[23:33] <huwshimi> sinzui: It's possible that CVE heading should not be a h2
[23:33] <sinzui> wgrant: I noted in the css and in discussion that many headings should probably be h3.
[23:33] <wgrant> I think we probably want to fix that first.
[23:34] <wgrant> I don't read the MP diff before looking at this sort of change, because it can affect how I explore.
[23:34] <sinzui> A h2 for simple list seems to be an exageration
[23:34] <maxb> From https://answers.launchpad.net/launchpad/+question/147254, would anyone fancy telling me about OOPS-1885CMP2 and OOPS-1885CMP4 ?
[23:34] <wgrant> maxb: Sure.
[23:35] <huwshimi> sinzui: What this is helping us do is fix hour html as well
[23:36] <wgrant> maxb: I am trying to locate them, since they are not in the usual places.
[23:36] <sinzui> huwshimi: I agree. I want to stab the "see more" in the portlet first
[23:36] <maxb> fun
[23:36] <lifeless> CMP
[23:36] <lifeless> code imports?
[23:36] <wgrant> CreateMergeProposals.
[23:36] <maxb> Create Merge Proposal (from email)
[23:36] <lifeless> ah
[23:37] <wgrant> Possibly loganberry-bzrsyncd...
[23:37] <lifeless> wgrant: they should be in lp-oops
[23:37] <wgrant> They're not.
[23:37] <lifeless> wgrant: are they not? if not please file a bug on oopstools
[23:37] <wgrant> I plan to, once I work out where they are.
[23:37] <lifeless> (or better yet fix directly, but theres still a lot of black magic in there)
[23:37] <lifeless> wgrant: production-configs will tell you
[23:38] <wgrant> lifeless: It tells me the path.
[23:38] <wgrant> Not the machine.
[23:38] <wgrant> It appears to be crowberry, oddly.
[23:38] <lifeless> it also tells you the service
[23:38] <lifeless> and cronscripts tells you the machine from the service
[23:39] <lifeless> StevenK: please tell me you are about to kill Distribution._init as part of the derived distros work.
[23:40] <wgrant> maxb: They are not on devpad, which may just mean they are not part of the incremental sync. Just triggered a full sync, which will take a few minutes.
[23:42] <wgrant> sinzui: Interestingly, your branch almost fixes sprite alignment in Firefox 4.
[23:43] <wgrant> It's also less broken in Chromium now.
[23:43] <sinzui> wgrant: yes
[23:43] <lifeless> speaking of sprites
[23:43] <maxb> ok, thanks
[23:43] <lifeless> the sprite code generates ValidPersonChecks
[23:43] <lifeless> wtf
[23:43] <sinzui> wgrant: I still have not mastered all the variables in positioning
[23:44] <wgrant> lifeless: Yeah, since it shows a desaturated icon for invalid people.
[23:46] <wgrant> lifeless: lp-oops can see them, but they don't seem to sync regularly.
[23:47] <wgrant> maxb: ValueError: tag/value separator not found in line '=20\\n'
[23:47] <wgrant> In bzrlib.
[23:48] <wgrant> Let me check the content.
[23:49] <james_w> codebrowse, are you there?
[23:49] <wgrant> james_w: Is it down again?
[23:49] <wgrant> Yes.
[23:49] <wgrant> Not again...
[23:49] <james_w> 503 for me
[23:49] <wgrant> LOSA ping: ^^
[23:50] <wgrant> It started dying on the 27th.
[23:50] <wgrant> No obviously relevant changes :/
[23:50] <lifeless> wgrant: see anything wrong with r -1 of lp:~lifeless/launchpad/bug-724033
[23:51] <mbarnett> wgrant: seeing codebrowse issues again?
[23:51] <wgrant> mbarnett: Yes.
[23:51] <lifeless> mbarnett: hallelujah
[23:51] <wgrant> Restart one, please.
[23:51] <wgrant> Not the other.
[23:51] <mbarnett> interesting, not alerting yet
[23:51]  * mbarnett logs in 
[23:51] <lifeless> mbarnett: was anything changed on guava?
[23:51] <lifeless> last weekend
[23:53] <wgrant> lifeless: I will tell you once one of the codebrowses is awake again.
[23:53] <mbarnett> lifeless: not that i am aware of .
[23:53] <wgrant> mbarnett: It's died three or four times since last week.
[23:53] <wgrant> And not before that.
[23:55] <mbarnett> 2011-02-25 17:15:20 status installed libc-bin 2.11.1-0ubuntu7.8
[23:55] <mbarnett> there were a handful of changes when puppet was installed on the box
[23:55] <wgrant> No sudo upgrades? :P
[23:55] <mbarnett> heh
[23:55] <lifeless> just libc-bin; guess we need to check its changelog
[23:56] <mbarnett> hmm,
[23:56] <mbarnett> 2011-02-25 17:15:20 status half-configured libc-bin 2.11.1-0ubuntu7.8
[23:56] <wgrant> Nothing interesting in 7.8
[23:56] <wgrant> But who knows what the old version was.
[23:56] <lifeless> the apt log should say
[23:56] <lifeless> mbarnett: what was the replaced version ?
[23:56] <wgrant> The dpkg log should too.
[23:57] <mbarnett> there are a ton of changes with the puppet install
[23:57]  * mbarnett stops looking for a moment to restart codebrowse
[23:57] <wgrant> mbarnett: Leave one process hung, pls.
[23:58] <wgrant> And a list of packages changed for puppet would be nice.
[23:58] <mbarnett> codebrowse2 is left.
[23:58] <wgrant> Thanks.
[23:58] <wgrant> Still borked.
[23:59] <wgrant> And of course now it works.
[23:59] <mbarnett> https://pastebin.canonical.com/44061/
[23:59] <wgrant> Meh, all ruby.
[23:59] <mbarnett> yeah