[00:01] <wallyworld> wgrant: there's some stuff from 23rd Nov and also 29th: http://paste.ubuntu.com/538152/
[00:04] <wgrant> wallyworld: Any references in the p-u log to the directory mentioned in that b-m line?
[00:04] <wgrant> I wonder if this is the race where p-u will have moved it to failed.
[00:04] <wgrant> Because it ran before the status was set.
[00:05] <lifeless> does anyone else get a 404 on this - http://ppa.launchpad.net/testing-cabal/ppa/ubuntu/dists/maverick/main/source/Sources.gz ?
[00:06] <wallyworld> wgrant: you mean this directory? 20101129-213106-2078946-PACKAGEBUILD-2081126
[00:06] <wgrant> wallyworld: That one.
[00:06] <wgrant> lifeless: Yes. Should it be there?
[00:06] <lifeless> I assume so
[00:06] <lifeless> there are packages...
[00:06] <lifeless> http://ppa.launchpad.net/testing-cabal/ppa/ubuntu/dists/maverick/main/binary-amd64/Packages.gz
[00:06] <lifeless> is 404ing for me too
[00:07] <lifeless> https://code.launchpad.net/~testing-cabal/+archive/archive
[00:07] <lifeless> reckons theres a bunch of stuf in the ppa
[00:08] <wgrant> Ugh, indeed.
[00:09] <lifeless> I'd like to use this stuff
[00:09] <wgrant> lifeless: er, the PPA is named 'archive', not 'ppa'.
[00:09] <wgrant> Your URL is wrong.
[00:09] <lifeless> oh right
[00:09] <lifeless> apt-add-repository fail
[00:09] <wgrant> Hm, it let you do that?
[00:09] <lifeless> yes
[00:10] <wallyworld> wgrant: don't appear to be any references to that exact directory. there are references to 213106 from earlier dates eg 20101115
[00:10] <wgrant> wallyworld: That's just a timestamp.
[00:11] <wallyworld> wgrant: yeah but i was thinking earlier uploads may have worked
[00:12] <wallyworld> wgrant: so you think it may be a race condition? can we kick off a manual upload?
[00:13] <wgrant> spm: Do you have a moment?
[00:19] <spm> wgrant: sure
[00:19] <wgrant> spm: Can you see if there's a 20101129-213106-2078946-PACKAGEBUILD-2081126 directory in cesium's buildd-manager upload root somewhere?
[00:19] <wgrant> /srv/launchpad.net/builddmaster
[00:21] <spm>  ./failed/20101129-213106-2078946-PACKAGEBUILD-2081126
[00:21]  * jelmer is here but was about to get some sleep
[00:21] <wgrant> jelmer: You've been working on this, right?
[00:21] <wgrant> I wonder if we should just throw it back into incoming.
[00:21] <jelmer> wgrant: I haven't read the context - what's going on exactly?
[00:22] <wgrant> jelmer: Binary upload stuck UPLOADING, with its directory in 'failed'.
[00:22] <wgrant> jelmer: No logs.
[00:23] <jelmer> wgrant: Yeah, moving it back to failed should be ok in that case. I did a fix recently to not move things to failed as quickly but keep them in incoming until we've committed the change to the build status.
[00:23] <jelmer> wgrant: That hasn't been deployed yet though.
[00:24] <wgrant> spm: Could you move that dir from failed back to incoming?
[00:26] <spm> sure, one sec (was encoffeenating)
[00:26] <spm> done
[00:28] <jelmer> spm: Thanks
[00:28] <wgrant> spm: Thanks.
[00:28] <wgrant> And now we have an upload log.
[00:28] <spm> np, and heyo jelmer
[00:28] <wgrant> Hah, it's been superseded already.
[00:28] <wallyworld> wgrant: spm: thanks for helping with this. i'll let the user know the upload is retrying
[00:29] <lifeless> wgrant: at what point should a ppa package become installable on client machines
[00:30] <wgrant> lifeless: After the binaries are built and published.
[00:31] <lifeless> grrr
[00:31] <lifeless> why isn't apt seeing it
[00:31] <lifeless> ahh
[00:31] <lifeless> http://ppa.launchpad.net/testing-cabal/archive/ubuntu/pool/main/p/python-testtools/
[00:31] <lifeless> i386 for all.
[00:31] <lifeless> https://code.launchpad.net/~testing-cabal/+archive/archive/+packages
[00:31] <lifeless> wgrant: expand ython-testtools - 0.9.7+bzr146~ppa116~maverick1
[00:31] <lifeless> Publishing details
[00:31] <lifeless>     * Published 15 minutes ago
[00:32] <wgrant> lifeless: That be the source.
[00:32] <wgrant> Note how it has a green flashing gear.
[00:32] <lifeless> no
[00:32] <wgrant> And it says the binaries aren't pblished.
[00:32] <lifeless> is that what it is?
[00:33] <wgrant> lifeless: Which series?
[00:33] <lifeless> wgrant: colour means approximately nothing to me in UIs
[00:33] <wgrant> Natty is still building, and Maverick and Lucid should have a warning about unpublished binaries when you expand their row.
[00:33] <lifeless> wgrant: i see a dark octagon, which might be greed.
[00:33] <wallyworld> thumper: ping
[00:33] <lifeless> *might be green*
[00:33] <thumper> wallyworld: aye
[00:34] <lifeless> someone needs to do user testing on this
[00:34] <wgrant> lifeless: Right, there's that, but you'll get more details if you expand the row.
[00:34] <lifeless> wgrant: i did
[00:34] <wgrant> lifeless: Launchpad does not do UI.
[00:34] <lifeless> wgrant: Launchpad does.
[00:34] <wallyworld> thumper: unknown dailydeb implies out of date bzrlib?
[00:34] <lifeless> some things have more room to improve than others.
[00:34] <lifeless> wgrant: is there a 'this needs work' bug ?
[00:35] <thumper> wallyworld: eh?
[00:35] <wgrant> lifeless: I don't think so.
[00:35] <wallyworld> thumper: https://pastebin.canonical.com/40235/ see the error at the end. i seem to recall dailydeb is a recent addition to bzrlib?
[00:36] <thumper> Unable to load plugin 'builder' from '/usr/lib/python2.6/dist-packages/bzrlib/plugins'
[00:36] <thumper> line 434
[00:37]  * wallyworld slaps forehead
[00:37] <thumper> which hints at a bigger problem
[00:39] <wallyworld> thumper: the log came from https://launchpadlibrarian.net/59824676/buildlog.txt.gz
[00:40] <wallyworld> thumper: does that mean we have something to look at on our end?
[00:40] <thumper> certainly looks like it
[00:40] <thumper> I would have thought that this would have come up in QA testing
[00:42] <wallyworld> thumper: yeah. so is it a matter of updating some servers to get the necessary plugin installed?
[00:42] <thumper> wallyworld: I'm not entirely sure
[00:42] <thumper> wallyworld: check with abentley or lamont
[00:43] <wallyworld> thumper: thanks, will do
[00:48] <thumper> GRRR!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!1111
[00:49]  * thumper runs bzr blame
[00:49] <wallyworld> thumper: ?
[00:49] <thumper> wallyworld: I think I've found "my" bug
[00:49] <wallyworld> thumper: you mean the test isolation one
[00:50] <wallyworld> ?
[00:50] <thumper> yep
[00:50] <thumper> a monkeypatch
[00:50] <thumper> Hierarchy.makeBreadcrumbForRequestedPage = lambda self: None
[00:50] <wallyworld> what was it put there for?
[00:51] <thumper>     # Monkey patch Hierarchy.makeBreadcrumbForRequestedPage so that we don't
[00:51] <thumper>     # have to create fake views and other stuff to test breadcrumbs here. The
[00:51] <thumper>     # functionality provided by that method is tested in
[00:51] <thumper>     # webapp/tests/test_breadcrumbs.py.
[00:51] <thumper> but the method is never put back
[00:53] <wallyworld> doh!
[00:54] <thumper> aye
[00:55] <thumper> lifeless: do you know if we have a way to nicely run something at the end of a doctest?
[00:55] <thumper> can we use addCleanup?
[00:55] <lifeless> no
[00:55] <thumper> :(
[00:55] <lifeless> you could add an empty fixture to globs
[00:55] <lifeless> e.g. 'test_fixture' : Fixture()
[00:56] <lifeless> then in the setUp set it up, and in the teardown do cleanUp
[00:56] <lifeless> and in the test do test_fixture.addCleanup(...)
[00:56] <wallyworld> rockstar: ping!
[00:56] <thumper> that sounds like a good idea...
[00:56] <thumper> I may well do it
[00:57] <thumper> I'm running all the tests in the layer again to see if my monkey patch reversal now makes it work
[00:57] <thumper> I think my test failed due to adding more tests caused some re-ordering
[00:57] <thumper> which caused the failure to be shown
[00:57] <thumper> the problem was there before
[01:01] <wallyworld> thumper: you know the rules: last person to touch it broke it :-P
[01:01] <thumper> :P
[01:06] <spm> ugh. does anyone happen to know which table project groups live in? need to rename a new one.
[01:06] <lifeless> project
[01:06] <lifeless> projects are products
[01:06] <lifeless> project groups are projects
[01:06] <spm> so projects are in product; and project groups are in project? logical :-)
[01:06] <spm> snap!
[01:06] <lifeless> echangingourmindisn'teasy
[01:06] <spm> :-)
[01:06] <lifeless> spm: so how about that proxypass rule
[01:06] <spm> slowly atm
[01:18] <thumper> why do I not have memcached working?
[01:19] <thumper> anyone got any ideas?
[01:24] <rockstar> wallyworld, hi
[01:25] <wallyworld> rockstar: just wondering if you wanted to review the product merge queue branch :-)
[01:25] <thumper> rockstar: also, you have a qa task on our board
[01:25] <thumper> rockstar: can you move it / do it?
[01:25] <rockstar> thumper, sure.
[01:26] <thumper> ta
[01:29] <abentley> wallyworld: It looks like bzr-builder is there, but apt_pkg is not.
[01:31] <wallyworld> abentley: so this is on one of our servers I think? wonder how that could have happened?
[01:31] <abentley> wallyworld: This would be on one of our builders.
[01:31] <abentley> wallyworld: Please post a link to the actual build-- the build log doesn't provide navigation to it.
[01:32] <wallyworld> abentley: i'll have to get it. i got the log from someone on #launchpad. i'll see if i can ping him
[01:39] <abentley> wallyworld: I believe it is this one: https://code.launchpad.net/~audacity-team/+recipe/daily.karmic/+build/9502
[01:40] <wallyworld> abentley: right you are
[01:41] <wallyworld> abentley: so, who do i talk to to get the issue looked at?
[01:42] <abentley> wallyworld: james_w could tell you what's apt_pkg, because it doesn't look like it's bzr-builder directly.
[01:42] <thumper> \o/
[01:42] <abentley> wallyworld: lamont can install updated packages on the builders.
[01:42] <thumper> finally landing the binary build change
[01:43] <thumper> I emailed the list with my problem resolution
[01:43] <wallyworld> abentley: thanks. so it seems we just need to install and/or update apt_pkg on that server?
[01:44] <wallyworld> thumper: most importantly, did you figure out who to blame? :-)
[01:44] <abentley> wallyworld: No, there's detective work needed.  What is apt_pkg used by?  Why didn't apt install it when it installed whatever requires it?
[01:44] <thumper> yes
[01:44] <thumper> but I won't publicly shame
[01:45] <abentley> wallyworld: Possibly we need to fix the dependencies on some packages.
[01:45] <wallyworld> thumper: didn't expect you to, just having the satisfaction of knowing it wasn't you is enough :-)
[01:45] <thumper> :)
[01:45] <thumper> yes, it was not me
[01:46] <wallyworld> abentley: thanks. will pass on the details. does it seem like it may only be an issue with one server? should I tell the user try again?
[01:47] <abentley> wallyworld: it seems likely this is a single-server issue.  We also had another bug with the wrong version of something being installed: https://bugs.launchpad.net/bugs/682941
[01:47] <_mup_> Bug #682941: no such option --append-version in recipe build <Launchpad Bazaar Integration:New> <https://launchpad.net/bugs/682941>
[01:47] <wallyworld> abentley: cool. many thanks for your help.
[01:50] <abentley> wallyworld: It appears that a few servers were recently added to the build farm.  That may be at the root of this: https://lpstats.canonical.com/graphs/BuildersActiveVirtual/
[01:51] <thumper> abentley: I'm smiling at the daily build spikes :)
[01:51] <wallyworld> abentley: could be
[01:54] <abentley> thumper: They're nice, but we may want to look into staggering them to make the build farm's responsiveness more consistent.
[01:54] <thumper> abentley: yeah.  I've heard bigjools request as much
[01:54]  * thumper goes to collect kids
[01:55] <spm> wgrant: fyi. patched, zapped, unpatched. looks good. thanks!
[01:58] <abentley> wallyworld: in the meantime, see if any new reports were built on sandpaperfig or lansones, because maybe only those two are problematic.
[01:59] <wallyworld> abentley: ok
[02:00] <lifeless> [02:00] <lifeless>     Hard / Soft  Page ID
[02:00] <lifeless>      287 / 6525  Archive:+index
[02:00] <lifeless>      170 /  390  BugTask:+index
[02:00] <lifeless>       43 /  260  Distribution:+bugs
[02:00] <lifeless>       27 /  140  ProjectGroupSet:CollectionResource:#project_groups
[02:00] <lifeless>       18 /    1  Archive:EntryResource:syncSource
[02:00] <lifeless>       14 /   35  DistroSeries:+queue
[02:00] <lifeless>       13 /  259  Distribution:+bugtarget-portlet-bugfilters-stats
[02:00] <lifeless>       12 /   38  Milestone:+index
[02:00] <lifeless>       12 /   28  MailingListApplication:MailingListAPIView
[02:00] <lifeless>       12 /    4  Person:+bugs
[02:02] <wgrant> spm: Yay, thanks.
[02:16] <lifeless> wgrant: I can has Archive fix.
[02:16] <lifeless> wgrant: iz getting worse.
[02:48] <thumper> \o/ db-devel builder passed third time lucky
[03:17] <poolie> wow: http://odata.stackexchange.com/ubuntu/s/665/too-many-comments
[03:17] <poolie> > Stack Exchange Data Explorer allows you to run arbitrary SQL queries on the Stack Exchange family of sites, share those queries with your friends and explore interesting queries.
[03:23] <wgrant> I imagine it's not really SQL.
[03:23] <wgrant> Well, at least not direct.
[03:26] <poolie> i think it is
[03:26] <poolie> but it's against a warehouse db, not the real one
[03:27] <wgrant> Ah.
[03:27] <lifeless> may still be filtered
[03:27] <poolie> i think they strip private stuff on the way to the warehouse
[03:28] <poolie> they may have much less private stuff, and a simpler delineation of it, than lp would have even now
[03:28] <wgrant> Yeah, true.
[03:38] <beuno> thumper, these new incremental diffs in merge proposals are the best thing since slide bread
[03:39] <thumper> beuno: I'm glad you like them, abentley is fixing a bug in them :)
[03:39] <beuno> I lovez em!
[03:39] <wgrant> They are really great.
[03:40] <wgrant> Now all we need is comments on lines, somehow.
[03:40] <beuno> yes we do
[03:40] <abentley> beuno, thumper: they're disabled until we can get that bug sorted, which unfortunately is a bzr bug, but I've submitted a fix.
[03:41] <beuno> abentley, that's fine, I already got a taste of them, will keep me warm and fuzzy for a good week
[03:45] <spiv> abentley, thumper: yes they're nice, thanks for adding them!
[03:46] <abentley> spiv: you're welcome.
[03:46] <wgrant> Are they restricted to betatesters?
[03:47] <spiv> abentley, thumper: I was wondering if it might be nice to be able to have a javascript thing to collapse them all for times when you want to just skim the conversation
[03:47] <wallyworld> thumper: why does self.assertEqual(x, y) fail unless i removeSecurityProxy(x) and removeSecurityProxy(y)? i'm logged in as the owner of x and y
[03:47] <wgrant> +1
[03:47] <spiv> e.g. if you are a patch pilot and want to quickly get a sense of where the discussion is at
[03:48] <lifeless> wallyworld: probably a buggy __eq__
[03:48] <abentley> spiv: Could be.
[03:48] <lifeless> wallyworld: sp(x).__eq__(sp(y)) -> x.__eq__(sp(y))
[03:48] <abentley> lifeless: Or __eq__ falling back to is.
[03:49] <lifeless> abentley: sure, which in the absense of sp's is reasonable. In our context its arguably buggy though
[03:49] <wallyworld> in this case i have two sets of branches, and i have to iterate over the contents of each set and remove the security proxies
[03:50] <wallyworld> for now, i would like to do the workaround and file a bug, does that sound ok?
[03:56] <wgrant> StevenK:
[03:56] <wgrant> StevenK: Morning.
[06:05] <spm> publicrestrictedlibrarian	default	0	on <== re-enabled
[06:06] <lifeless> wgrant: give it a spin ?
[06:08] <wgrant> lifeless: It's unbroken! Well done.
[06:08] <lifeless> spm: looks good to me too
[06:08] <spm> \o/
[06:12] <wgrant> lifeless: Is it intentional that bzr won't stack if you terminate the initial push?
[06:14] <lifeless> wgrant: there is a bug
[06:15] <wgrant> Ugh. Why do project bug pages now advertise Ubuntu?
[06:16] <lifeless> the downstream link?
[06:16] <wgrant> Yes.
[06:16] <lifeless> they should show any distro packages, not just ubuntu
[06:16] <wgrant> The last thing Launchpad needs is more Ubuntu-specific stuff.
[06:16] <lifeless> I suspect the links are only in place for Ubuntu.
[06:16] <wgrant> Big upstreams *do not want that sort of thing*.
[06:17] <lifeless> mmmm
[06:18] <lifeless> wgrant: I think the placement needs tuning
[06:18] <lifeless> wgrant: but I don't buy your assertion - I think its overstated.
[06:18] <lifeless> wgrant: many upstreams *want* easier querying of bugs in their stuff in Ubuntu.
[06:18] <wgrant> lifeless: Hm? I thought it was an undeniable fact that Ubuntu-specificity was hurting Launchpad adoption.
[06:19] <lifeless> wgrant: including bug ones.
[06:19] <lifeless> s/bug/big/
[06:19] <wgrant> Sure.
[06:19] <lifeless> poolie: http://rbtcollins.wordpress.com/2010/11/30/testrepository-iteration-for-python-projects/ fyi
[06:19] <wgrant> But it needs to not just scream about Ubuntu on every page.
[06:20] <lifeless> wgrant: file bugs on making it more subtle - point out that it needs to scale to baltix, linaro etc.
[06:20] <wgrant> Ah yes, I keep forgetting that Linaro might force people to be less insane.
[06:20] <lifeless> wgrant: Ubuntu specificity is a mixed blessing
[06:21] <lifeless> wgrant: its totally unclear whether its a net win or negative
[06:21] <wgrant> lifeless: It will get you lots of nice little projects.
[06:21] <wgrant> But scare away any big ones.
[06:21] <lifeless> wgrant: !cite
[06:21] <lifeless> wgrant: seriously, hyperbole doesn't help analyse this.
[06:22] <lifeless> wgrant: Ubuntu specific stuff can be harmful in at least two distinct ways
[06:22] <lifeless> there may be defaults or hardcoded behaviour that make less sense for upstreams
[06:23] <lifeless> which is a special case of 'less than the best of breed $tool than LP could be'
[06:25] <lifeless> wgrant: secondly theres stuff that presents Ubuntu where it isn't welcome.
[06:25] <lifeless> wgrant: its my opinion that the former has been a frequent problem in the past
[06:25] <lifeless> wgrant: but I don't think this falls into that category.
[06:26] <wgrant> lifeless: There have been both progressions and regressions around the former over the last few months, but it's probably not too bad now apart from the portlet on Product:+index.
[06:27] <wgrant> And maybe this bug listing thing, but that may just be an artifact of the portlet.
[06:28] <lifeless> on the positive side
[06:28] <lifeless> Ubuntu is a very demanding and large customer
[06:29] <wgrant> Indeed.
[06:29] <lifeless> many things that Ubuntu experiences problems with other large users experience problems with.
[06:29] <wallyworld> lifeless: what do i do about bug 615788? it's been fixed but the user has reopened it against launchpad because they don't agree with the resolution. should i change to Invalid and ask them to file a new bug against ubuntu-website?
[06:29] <_mup_> Bug #615788: gpg should use port 443 by default in order to work from behind firewalls <Launchpad itself:Opinion> <synaptic:New> <Ubuntu Website:Fix Released> <https://launchpad.net/bugs/615788>
[06:29] <wgrant> But the Ubuntu-specificity reduces Launchpad adoption, which reduces bzr adoption, which reduces Launchpad adoption, which...
[06:29] <lifeless> wallyworld: file an rt ticket asking for a gpg server on port 80
[06:30] <lifeless> wgrant: Ubuntu may sometimes ask for things to solve their issues that don't work well for other users, but its *our job* to find a way to solve their problem creatively, in a way other folk also benefit from.
[06:30] <wallyworld> lifeless: ok. but we don't want the bug to stay assigned to launchpad do we?
[06:30] <lifeless> wallyworld: why not?
[06:30] <rockstar> lifeless, because it's not launchpad's issue?
[06:30] <rockstar> "(I don't have permissions to reopen the original bug for ubuntu-website, so I reopened for launchpad instead - sorry for the hassle)"
[06:31] <LPCIBot> Project devel build (260): STILL FAILING in 4 hr 5 min: https://hudson.wedontsleep.org/job/devel/260/
[06:31] <wallyworld> lifeless: the bug when first filed was tiraged to ubuntu-website so i assumed that's where we wanted it to go
[06:31]  * lifeless shrugs
[06:31] <lifeless> I'm on leave.
[06:31] <lifeless> I'm telling you what I'd do.
[06:31] <lifeless> but I really don't want to go deep on the discussion.
[06:31] <wallyworld> lifeless: ok. i wasn't going to bother you but you keep popping up :-)
[06:31] <rockstar> wallyworld, I'd close it as "Won't Fix" for launchpad.
[06:31] <wgrant> wallyworld: It doesn't need an RT.
[06:31] <wgrant> It's Invalid in Launchpad.
[06:31] <lifeless> and reading the bug, its already fixed.
[06:32] <lifeless> he wants a bug open on gpg upstream.
[06:32] <lifeless> that will need some clear communication.
[06:32] <wgrant> It needs a fix in python-software-properties, and possibly Soyuz.
[06:32] <rockstar> Er, yeah, Invalid.  What wgrant said.
[06:32] <wgrant> And maybe gnupg.
[06:32] <lifeless> gnupg could certainly try 80 if the default fails epically.
[06:33] <lifeless> wgrant: back to reputation
[06:33] <lifeless> wgrant: Ubuntu may ask for crack, and we may do it occasionally, in response to its [large] scaling problems.
[06:33] <wgrant> lifeless: Sure.
[06:33] <wallyworld> rockstar: so should the user file his own bug upstream?
[06:34] <lifeless> wgrant: its up to us to help them solve their issues in such a way that our other users are helped too.
[06:35] <lifeless> wgrant: the pressure to solve these issues is a positive pressure
[06:35] <rockstar> wallyworld, well, he certainly shouldn't just re-open the bug on another project just because he doesn't like the fix.
[06:36] <wgrant> rockstar: Well, what he did was more correct than what he initially tried to do.
[06:36] <lifeless> wgrant: and secondly many upstreams care passionately about the quality of their *delivered to users* software.
[06:36] <wgrant> It needs an LP config change and possibly an Ubuntu gnupg or python-software-properties change.
[06:36] <wgrant> The sysadmin side is done.
[06:36] <rockstar> wgrant, I guess I'm confused on how this issue relates to Launchpad at all.
[06:36] <lifeless> wgrant: tighter reporting and easier analysis of their bugs in Ubuntu is desired and positive
[06:36] <rockstar> It's a keyserver/client issue.
[06:36] <lifeless> rockstar: it doesn't, he's confused.
[06:37] <wgrant> rockstar: Launchpad produces links to the keyserver. It uses port 11371
[06:37] <lifeless> wgrant: we should change those links.
[06:37] <wgrant> lifeless: Hence the config change.
[06:37] <lifeless> I'd file a new bug for that though.
[06:37] <lifeless> rockstar: so it does apply, though he is confused about how it all hangs together.
[06:37] <rockstar> wallyworld, ^^ Close the bug as invaled, reference a new bug about ports for 11371
[06:37]  * rockstar goes to bed
[06:37] <wallyworld> rockstar: thanks
[06:38] <wgrant> wallyworld: Also Invalidate the synaptic task, while you're there.
[06:38] <wallyworld> wgrant: what should i ask for the 11371 port number to be changed to in the new bug?
[06:39] <lifeless> 80
[06:39] <wallyworld> lifeless: thanks. just wanted to make sure so i didn't enter something stupid in the bug report
[06:42] <wgrant> gpghandler.port is the relevant config key.
[06:43] <wallyworld> wgrant: thanks to you too
[06:44] <lifeless> wgrant: anyhow, think on those points
[06:44] <lifeless> wgrant: I think its very much undecided whether the net influence is win or lose
[06:44] <wgrant> Hmmm.
[06:52] <lifeless> and we have plenty of room to make great decisions going forward to make the most of having a huge customer
[07:43] <LPCIBot> Project db-devel build (175): FAILURE in 4 hr 16 min: https://hudson.wedontsleep.org/job/db-devel/175/
[08:29] <wgrant> losa ping
[08:31] <mthaddon> wgrant: hi
[08:32] <wgrant> mthaddon: germanium's publisher has issues.
[08:32] <wgrant> Hasn't published anything for a couple of hours, AFAICT.
[08:33] <mthaddon> ok, what stage are we at in terms of troubleshooting it?
[08:33] <wgrant> mthaddon: 0
[08:33] <wgrant> Well.
[08:33] <wgrant> I know that process-accepted.py isn't finishing.
[08:33] <wgrant> I'm not sure if it's starting.
[08:33] <lifeless> am?
[08:33] <lifeless> 19:35 < lifeless> wgrant: its up to us to help them solve their issues in such a way that our other users are helped too.
[08:33] <lifeless> 19:36 < lifeless> wgrant: the pressure to solve these issues is a positive pressure
[08:33] <lifeless> bah, copy paste faillll
[08:42] <mthaddon> wgrant: would that be cron.publish-ppa or cron.daily-ppa (I'm assuming the former)?
[08:42] <wgrant> mthaddon: The former.
[08:43] <mthaddon> wgrant: it seems to be doing stuff - the logfile is being written to fine with non-error messages (things like: 2010-11-30 08:42:53 INFO    Processing http://ppa.launchpad.net/some/url)
[08:43] <wgrant> mthaddon: What time does cron.daily-ppa run?
[08:44] <mthaddon> wgrant: 5:59 UTC
[08:44] <wgrant> Hah.
[08:44] <mthaddon> er, 05:59 UTC, that is
[08:44] <wgrant> Then I bet it takes a little over two hours to run, blocking publication.
[08:45] <wgrant> Since everything woke up about 10 minutes ago.
[08:45] <wgrant> As it did last time I poked you about this.
[08:45] <mthaddon> interesting - they write to the same log file
[08:45] <wgrant> They share a lock too.
[08:45] <mthaddon> yeah
[08:45] <mthaddon> but it does look like it's cron.publish-ppa running now
[08:45] <wgrant> Yeah, it's all good now.
[08:45] <mthaddon> k
[08:45] <wgrant> I just have awful timing.
[08:45] <wgrant> Again.
[08:46] <bigjools> hello
[08:46] <StevenK> s/Again/Still/
[08:46] <wgrant> Morning bigjools.
[08:46] <bigjools> I love the smell of burning Soyuz in the morning
[08:47] <wgrant> bigjools: It's been a pretty boring day, apart from the usual hardy linux cowboy.
[08:47] <wgrant> And a b-m race.
[08:48] <StevenK> Oooh, I missed the race
[08:48] <bigjools> ?
[08:49] <wgrant> Uploads stuck in UPLOADING, fixed by moving them back from failed to incoming.
[08:49] <wgrant> But I believe that bug is fixed?
[08:50] <bigjools> the race is not fixed
[08:50] <wgrant> :(
[08:50] <bigjools> *cough* jelmer
[08:55] <bigjools> wgrant: I can't fathom why cron.daily-ppa takes so long
[08:55] <wgrant> bigjools: It shouldn't.
[08:55] <wgrant> The tree isn't that huge.
[08:56] <bigjools> 2.5 hours ....
[08:56] <wgrant> I guess we should make DiskPool take care of it.
[08:57] <bigjools> and why does it need to share a lock
[08:57] <wgrant> Because otherwise it'll crash the publisher.
[08:57] <bigjools> how
[08:57] <wgrant> It could remove a dir just after the publisher creates it.
[08:57] <wgrant> Boom.
[08:58] <bigjools> grar
[08:58] <wgrant> Jar.
[08:58] <bigjools> this Is Bad
[08:58] <wgrant> Barelt.
[08:58] <wgrant> DiskPool can do it easily.
[08:58] <wgrant> Hmm.
[08:58] <wgrant> But not easily all the way up.
[08:58] <wgrant> I guess we could.
[08:58] <bigjools> I want to know why this is so slow first
[08:59] <bigjools> and, I am sick to death of PFOE
[08:59] <wgrant> bigjools: Did you get anywhere with that logparser error? Did my theory about postgres 32-bit integer limits being exceeded hold any water?
[08:59] <bigjools> wgrant: yes, that is it
[08:59] <wgrant> Hah.
[09:00] <wgrant> Does bigint work?
[09:00] <bigjools> yes
[09:00] <wgrant> Yay.
[09:00] <bigjools> did you see my bug about dupe builds?
[09:01] <wgrant> Vaguely.
[09:01] <bigjools> there's 2 PPAs like that now
[09:01] <bigjools> same looking problem
[09:12] <mrevell> Hello
[09:13] <bigjools> hey
[09:40] <allenap> mrevell: Bug imports are quite manual; someone files a question to request it, provides us with some XML, we massage that and check it imports (and go back to the requester if there are problems, rinse, repeat), import it to staging so they can see it, then import into production.
[09:41] <allenap> mrevell: The whole process can take a few days or a few weeks depending on what issue crop up.
[09:41] <mrevell> allenap, So, same as before pretty much. How long do they take ... on average? I'm wondering how strongly we should offer this as a service.
[09:41] <mrevell> allenap, Ah right ... how much dev time?
[09:41] <mrevell> roughly
[09:41] <allenap> mrevell: Right now they do suck up the team's time quite a lot. Best talk to deryck before promoting things too heavily,
[09:42] <allenap> mrevell: On the other hand, if we don't promote it, we won't spend time improving the story.
[09:42] <mrevell> allenap, We barely mention them at all, right now, precisely because we don't want to overload ourselves. I think you're right, though, probably best to speak Dezza as this is somewhere that we do a really good job and make people happy.
[10:04] <LPCIBot> Yippie, build fixed!
[10:04] <LPCIBot> Project devel build (261): FIXED in 3 hr 32 min: https://hudson.wedontsleep.org/job/devel/261/
[10:04] <LPCIBot> Launchpad Patch Queue Manager: [r=abentley][ui=rockstar][bug=602508] Show related binary builds on
[10:04] <LPCIBot> the recipe index page.
[10:15] <bigjools> wgrant: can you check the ppa stats on DF?  the log parser process has been busy this morning
[10:17] <wgrant> bigjools: When are the logs from?
[10:18] <bigjools> wgrant: production logs, latest is from Oct 27
[10:18] <wgrant> bigjools: Ah, I see.
[10:18] <wgrant> bigjools: re. bug #663562, I recall we discussed this last time and worked it out.
[10:18] <_mup_> Bug #663562: duplicate orig for "linux" package in hardy <soyuz-core> <soyuz-security> <Soyuz:Incomplete> <https://launchpad.net/bugs/663562>
[10:18] <wgrant> The upload file checker only looks for published files.
[10:18] <bigjools> wgrant: shame that wasn't logged on the bug :(  I can't remember
[10:19] <wgrant> linux was uploaded with one orig.tar.gz, deleted, then uploaded a while later with a different one.
[10:19] <bigjools> ah
[10:19] <bigjools> that sucks
[10:19] <bigjools> that reall sucks
[10:19] <bigjools> that explains how people are doing it in PPAs
[10:19] <bigjools> sigh
[10:20] <wgrant> bigjools: DF seems to be from Oct 7 or so. Do the logs go back that far?
[10:20] <bigjools> wgrant: yes, it's catching up
[10:21] <bigjools> it has all the prod logs evar
[10:21] <wgrant> .. oh.
[10:24] <wgrant> bigjools: I've checked a few and they are all 0, but I've no idea what date range to look for.
[10:24] <bigjools> ok
[10:24] <bigjools> erm
[10:25] <bigjools> it's catching up, try later
[10:26] <bigjools> it just did the file for Oct 27 actually
[10:27] <wgrant> That won't have done anything, since DF doesn't have data that late.
[10:27] <wgrant> Will have to wait.
[10:36] <wgrant> bigjools: !!
[10:36] <wgrant> https://dogfood.launchpad.net/api/devel/~launchpad/+archive/ppa/+binarypub/10649139?ws.op=getDownloadCounts
[10:36] <wgrant> One download of python-psycopg2 from the launchpad PPA.
[10:36] <wgrant> Hopefully more will show up eventually..
[10:36] <bigjools> GTK file open dialog is a total utter shambolic PoS
[10:41] <wgrant> You're using a GTK application!?
[10:41] <bigjools> Firefox
[10:41] <bigjools> about the only one
[10:41] <wgrant> Ah.
[10:41] <wgrant> Chromium FTW :)
[10:42] <bigjools> you'd think that when it wants an application to run for a file download, it would match stuff in the PATH, but no, you need to type the full path out.
[10:42] <wgrant> Oh yes, that bit is just stupid.
[10:42] <bigjools> I use Chromium on my laptop.  I am thinking of using it as default everwhere now
[10:43] <bigjools> but I hate its windown decorations
[10:43] <bigjools> window, even
[10:43] <wgrant> I tell it to use the system ones.
[10:43] <bigjools> then you get two lots .... :/
[10:44] <wgrant> ... not for me.
[10:44] <bigjools> I mean - you get none at all, sorry
[10:44] <bigjools> it doesn't like kwin
[10:44] <wgrant> https://chrome.google.com/extensions/detail/elnmibmpefhmfgphdphdncoogpbfmlbp
[10:44] <wgrant> That's what it looks like in sane WMs :P
[10:45] <bigjools> it's using GTK, no?
[10:45] <wgrant> Maybe.
[10:45] <bigjools> the world is heading to QT anyway
[10:46] <wgrant> Both of them suck.
[10:46] <bigjools> qt is great
[10:46] <wgrant> It has its own C++ preprocessor.
[10:46] <wgrant> That disqualifies it from greatness.
[10:46] <bigjools> heh
[10:46] <wgrant> It is otherwise less abhorrent than GTK, though, I agree.
[10:53] <henninge> jtv: the old updateStatistics method relied a lot on the filtering methods "getPOTMsgset*". Your last branch seems to break that relationship. I assume you are aware of that?
[10:53] <jtv> henninge: yes
[10:54] <henninge> jtv: I see the advantage in the old approach because it keeps filters and statistics in sync.
[10:54] <jtv> yes
[10:54] <jtv> it was unfortunately also intractably slow
[10:54] <henninge> but I understand you did that for performance reasons, right?
[10:54] <henninge> no need to react like that .... ;)
[11:16] <LPCIBot> Yippie, build fixed!
[11:16] <LPCIBot> Project db-devel build (176): FIXED in 3 hr 33 min: https://hudson.wedontsleep.org/job/db-devel/176/
[11:16] <LPCIBot> * Launchpad Patch Queue Manager: [rs=buildbot-poller] automatic merge from stable. Revisions: 11999
[11:16] <LPCIBot> included.
[11:16] <LPCIBot> * Launchpad Patch Queue Manager: [r=stub][ui=none][bug=368600,
[11:16] <LPCIBot> 678289][rollback=9997] Revert database patch application timing
[11:16] <LPCIBot> report,
[11:16] <LPCIBot> which isn't working as expected when patches are all applied in a
[11:16] <LPCIBot> single transaction.
[11:25] <LPCIBot> Project devel build (262): FAILURE in 8 min 19 sec: https://hudson.wedontsleep.org/job/devel/262/
[11:26] <bigjools> StevenK: ^ it's run out of disk space :)
[11:26] <StevenK> Yes, I saw
[11:49] <wgrant> bigjools: What are we doing for builds that were failure-counted to death?
[11:50] <wgrant> They appear at the top of recipe build listings.
[11:50] <bigjools> wgrant: nothing
[11:50] <wgrant> wallyworld_: ^^
[11:50] <wgrant> They will appear there forever.
[11:50] <bigjools> url?
[11:50] <wgrant> https://code.edge.launchpad.net/~videolan/+recipe/master-daily
[11:51] <bigjools> what's the problem?
[11:51] <wallyworld_> wgrant: i was being asked a question about that just now in #launchpad
[11:51] <wgrant> wallyworld_: That's why I pinged you.
[11:51] <wallyworld_> wgrant: just realised :-)
[11:51] <wgrant> bigjools: That build is from two weeks ago.
[11:52] <wgrant> bigjools: It was failure-counted out, so has no finish time.
[11:52] <wgrant> It sorts above all others.
[11:52] <wgrant> (this affects binary build listings too)
[11:52] <wgrant> (failing a build without setting a finish time is crack)
[11:52] <bigjools> wgrant: then that's a UI bug
[11:52] <wgrant> I don't think so.
[11:52] <bigjools> not really, it didn't finish
[11:56] <bigjools> this makes me sad that people don't understand packaging: https://edge.launchpad.net/~stilia-johny/+archive/xwinwrap-gui/+packages?field.name_filter=&field.status_filter=&field.series_filter=
[11:56] <bigjools> I need to fix that file re-upload bug
[11:56] <bigjools> did you investigate where in the code the bug is, before I waste time?
[11:59] <wgrant> bigjools: _getFileByName in lp.archiveuploader.dscfile, which uses Distribution.getFileByName.
[11:59] <wgrant> It should probably use Archive.getFileByName instead.
[11:59] <bigjools> ta
[12:00] <wallyworld_> bigjools: do you know if all members of a team should be notified of recipe and ppa build failure/success
[12:00] <wallyworld_> or wgrant: ^^^^
[12:00] <bigjools> BFNs go to the team, yes
[12:00] <bigjools> dunno about recipes though
[12:00] <wgrant> Members should.
[12:00] <wgrant> But owners probably won't, despite having privs.
[12:00] <wallyworld_> a guy on #launchpad says he gets notified for a team he owns, but not a team he is admin of
[12:00] <jelmer> wallyworld_: same thing for recipes
[12:01] <wallyworld_> so i should just tell him to make himself a member?
[12:02] <wgrant> wallyworld_: The issue is that ~videolan has a contact address set.
[12:02] <wgrant> So failure emails will go to that mailing list, not the members.
[12:02] <wgrant> Also, it's 11pm.
[12:03] <wgrant> EOD was a while ago?
[12:03] <wallyworld_> wgrant: ok. i would have expected members get notified too but i can see that if the contact address is a mailing list for eg that you wouldn't want that
[12:03] <wgrant> wallyworld_: It's pretty horrible, but that's how LP works.
[12:03] <wallyworld_> wgrant: it's only 10pm here - we don't have daylight saving :-(
[12:04] <wgrant> If there is no team address, it goes to the members. If there is, it doesn't.
[12:04] <wgrant> wallyworld_: Oh, right. Lucky people.
[12:04] <wallyworld_> wgrant: since i'm on chr, i figured i should hang around as long as i could :-)
[12:04] <wallyworld_> wgrant: i wish we had dls. you don't like it?
[12:04] <wgrant> We do need more CHR coverage, but I'm not really sure that's the solution...
[12:04] <wgrant> wallyworld_: It's confusing and pointless!
[12:05] <wallyworld_> wgrant: well, each is entitled to their opinion :-)
[12:06] <jelmer> wallyworld_: What are dls?
[12:06] <wallyworld_> jelmer: daylight saving
[12:06] <jelmer> ah :-)
[12:06] <wallyworld_> jelmer: it's too late for me to type properly and my typing is bad enough as it is :-)
[12:06] <jelmer> heh
[12:06] <bigjools> we need permanent DLS here but the Scots get all huffy about it :)
[12:07] <wallyworld_> bigjools: thanks for not mentioning the cricket :-)
[12:07]  * jelmer hadn't realized there was a difference in daylight saving across Australia
[12:07]  * jelmer wonders what this "cricket" thing is people keep talking about...
[12:08] <wgrant> jelmer: Western Australia a couple of years back decided to trial DST... with three weeks of notice.
[12:08] <wallyworld_> jelmer: where you from?
[12:09] <bigjools> the funny thing about Aus is the lack of DST in the north, coupled with the 1/2 hour TZs makes for an interesting time if you're travelling
[12:09] <wallyworld_> wgrant: so, there is *no* way a user can get notifications if a contact address has been set for a team?
[12:09] <wgrant> Yeah, SA just had to be different...
[12:09] <wgrant> wallyworld_: They'll go the ML.
[12:09] <bigjools> and NT
[12:09] <wgrant> wallyworld_: The ML might reject them.
[12:10] <wgrant> bigjools: Everyone ignores NT.
[12:10] <bigjools> heh
[12:10] <jelmer> wallyworld_: the Netherlands
[12:10] <wallyworld_> wgrant: :-( we need a checkbox to say "send to team members" *and* contact address
[12:10] <wgrant> wallyworld_: No, we need to redesign Launchpad notifications :/
[12:10] <wallyworld_> jelmer: the netherlands had a cricket team in the last world cup :-)
[12:11] <wallyworld_> wgrant: well maybe, but I was conceptualising :-)
[12:15] <wallyworld_> jelmer: cricket for dummies :-P http://www.angelfire.com/dragon2/kamrantariq/
[12:16] <jelmer> wallyworld_: Apparently we do, but nobody seems to care about cricket.. I didn't know we had a team until somebody congratulated me with our victory over (I think) the UK.
[12:16] <jelmer> wallyworld_: heh, thanks :-)
[12:18] <wallyworld_> jelmer: i guess football is your thing. what else do you play over there?
[12:19] <jelmer> yeah, the popular things to watch on tv here are football, (indoor) speed skating and cycling
[12:20] <bigjools> UK?!  The UK does not have a cricket team.
[12:21] <jelmer> Wait.. there's separate teams for England, Wales, Scottland and Northern Ireland?
[12:21] <jelmer> *Scotland
[12:22] <bigjools> yep
[12:23] <bigjools> "United" Kingdom :)
[12:26] <bigjools> jtv: reckon we should change the make at the bottom of utilities/rocketfuel-get to use -j2?
[12:27] <jtv> bigjools: yes… I'll bet there will be more failures, but we'll want to solve those not hide them.
[12:27] <bigjools> indeed
[12:27] <bigjools> I tried it on dogfood and get failures after a make clean
[12:27] <jtv> Something to be announced on the mailing list.  We also want to maintain healthy interest in the topic of faster builds.  :-)
[12:27] <bigjools> hell yes
[12:28] <jtv> How about an environment variable, and asking everyone to experiment and look for failures?
[12:29] <jtv> Once we feel we've ironed out the immediate failures, we can jack that variable up to -j2 by default.
[12:29] <bigjools> yup
[12:30] <jtv> And then we go to work on zcml time.  :)
[12:30] <bigjools> fun
[12:30] <jtv> Pickle their data and maintain them with "make."
[12:31] <wgrant> bigjools: Why'd the buildd-manager async thing land on db-devel?
[12:32] <bigjools> I can't remember
[12:32] <bigjools> probably a dodgy MP
[12:32] <wgrant> It seems like the sort of thing that we want to get out ASAP so we can revert it, since it's going to break....
[12:33] <bigjools> ?
[12:33] <wgrant> All major buildd-manager changes break at least twice.
[12:33] <bigjools> sigh
[12:33] <wgrant> It's far easier to roll back if we don't have a DB rollout in the middle.
[12:33] <wgrant> Like last time.
[12:35] <wgrant> Although this one does look safe enough.
[12:35] <bigjools> hmmm, how is Distrubution.getFileByName() failing for deleted orig files
[12:36] <wgrant> bigjools: From the views:
[12:36] <wgrant>   WHERE securesourcepackagepublishinghistory.dateremoved IS NULL;
[12:36] <bigjools> nope
[12:36] <wgrant> Oh?
[12:37] <bigjools> it's using SPFP.selectBy(distro, lfa, archive)
[12:37] <bigjools> then ordering on ID
[12:37] <bigjools> which sucks that it has to order at all
[12:38] <wgrant> bigjools: SPFP is a view.
[12:38] <wgrant> bigjools: That view has the WHERE clause that I just pasted.
[12:38] <bigjools> I..... hate views
[12:38] <wgrant> :D
[12:38]  * wgrant hugs FTPArchiveHandler.
[12:41] <bigjools> I hate  regex
[12:41] <bigjools> trying to work out if re_issource will match orig fiels
[12:41] <bigjools> ah yes, it will
[12:42]  * bigjools back later, fud time
[14:09] <LPCIBot> Project devel build (263): STILL FAILING in 2 hr 38 min: https://hudson.wedontsleep.org/job/devel/263/
[14:25] <deryck> gmb or allenap -- what was the bug # you guys used for "use notification level for structural subscriptions" ?
[14:25]  * allenap looks
[14:29] <allenap> deryck: Ah, what am I thinking. Structural subscriptions have always worked with levels, but levels were not exposed in the UI. I think gmb knows about that part.
[14:30] <deryck> allenap, gmb, yeah, that's what I mean, the ui bit.  the recent work we've done.  There's an older bug, but I'd like to dupe it against the recent one we worked on.
[14:30] <deryck> I think bug 213261 could be duped against the bug representing the work we just did.
[14:30] <_mup_> Bug #213261: Allow specifying the notification level for structural subscriptions <email> <story-better-bug-notification> <Launchpad Bugs:In Progress by gmb> <Launchpad Bugs 1.2:Triaged> <https://launchpad.net/bugs/213261>
[14:31] <gmb> deryck: bug 672507 is the one I used.
[14:31] <_mup_> Bug #672507: Add bug_notification_level to the structural +subscribe view <qa-ok> <story-better-bug-notification> <Launchpad Bugs:Fix Released by gmb> <https://launchpad.net/bugs/672507>
[14:32] <deryck> ah ha.  Thanks, gmb!
[14:32]  * gmb notices that he has a branch called "lp:~gmb/launchpad/oh-my-god-my-eyes". No idea what that's about.
[15:12] <LPCIBot> Project db-devel build (177): FAILURE in 3 hr 47 min: https://hudson.wedontsleep.org/job/db-devel/177/
[15:12] <LPCIBot> Launchpad Patch Queue Manager: [r=gary,
[15:12] <LPCIBot> stub][ui=none][bug=682728][no-qa] Make ParsedApacheLog.bytes_read a
[15:12] <LPCIBot> bigint so that it can cope with larger files.
[16:51] <jelmer> mrevell: hi
[16:51] <mrevell> Hello jelmer
[16:52] <jelmer> mrevell: I vaguely recall that Launchpad used to have a small banner on the top or bottom of all pages saying "Launchpad will go down for 1 hour 23 hours from now.". What happened to that?
[16:52] <mrevell> jelmer, AFAIK we have the facility to do that 15 minutes from the impending down-time and mthaddon and friends switch that on.
[16:53] <mrevell> jelmer, There has been talking, on several occasions, of creating a general purpose notification system.
[16:54] <jelmer> mrevell: Something like that seems useful for this sort of thing. Before I was a lp developer I know the only thing I'd really notice for sure would be the notification on Launchpad itself.
[16:59] <mrevell> jelmer, I'd love to see something like that. I guess it's a lower priority than implementing features that stakeholders need.
[19:03] <LPCIBot> Project db-devel build (178): STILL FAILING in 3 hr 50 min: https://hudson.wedontsleep.org/job/db-devel/178/
[19:03] <LPCIBot> * Launchpad Patch Queue Manager: [r=gmb][ui=none][bug=662631,
[19:03] <LPCIBot> 668060] Make file uploads from builders asynchronous so that it
[19:03] <LPCIBot> doesn't block the rest of the build manager. This is the last
[19:03] <LPCIBot> part of the build manager to be made asynchronous.
[19:03] <LPCIBot> * Launchpad Patch Queue Manager: [rs=buildbot-poller] automatic merge from stable. Revisions: 12000
[19:03] <LPCIBot> included.
[19:07] <gary_poster> sinzui: could you take a look at https://bugs.launchpad.net/canonical-identity-provider/+bug/556680 for me and then talk with me?  I'm hoping you will have some brilliant insight, or at least that you will agree with Anthony
[19:07] <_mup_> Bug #556680: attempting to create a new account with an existing email address at login.ubuntu.com oopses after you follow the email link back to create the name/password <isd-logging-sprint> <Canonical SSO provider:Incomplete by stuartmetcalfe> <Canonical ISD QA:New> <https://launchpad.net/bugs/556680>
[19:08] <gary_poster> 's analysis and be able to help me come up with an actionable plan for his description of "let Launchpad refuse an account when it tries to sign in, it it notices it's related to a team Person."
[20:53] <lifeless> http://pypi.python.org/pypi/injector/0.3.1 looks kindof interesting
[20:53] <lifeless> poolie: ^
[21:01] <poolie> hi lifeless
[21:28] <poolie> lifeless: it is a bit interesting
[21:30] <poolie> it seems like it brings quite high-proof abstraction
[21:30] <poolie> or rather, indirection
[21:30] <poolie> such that you wouldn't want it unless you needed it
[21:30] <poolie> what do you think?
[21:36] <lifeless> I'm reminded of greenspuns law, or whatever it is
[21:36] <lifeless> about half baked lisp implementations
[21:36] <poolie> indeed
[21:36] <poolie> :(
[21:37] <lifeless> I think that 'injector' would be overkill quite often
[21:37] <lifeless> OTOH perhaps its solid, thought out, reliable
[21:37] <poolie> it seems like having the option of dynamic scope would mostly obsolete this
[21:38] <poolie> the decorators to mark what's injected are kind of nice
[21:38] <lifeless> perhaps... might bend folks brains a bit much
[21:38] <lifeless> anyhow
[21:38] <lifeless> I'm not proposing to use it, just thought it was interesting
[21:41] <poolie> it is
[21:59] <benji> is anyone else getting a "Error: Couldn't find a distribution for 'testtools==0.9.8-r137'.
[22:00] <benji> ... error when running make?
[22:00] <benji> I've updated the download-cache with no effect.
[22:03] <mars> benji, check the mailing list, Nov 10th, message from Gary 'Fix your testtools', looks relevant?
[22:03] <benji> looking
[22:04] <mars> benji, ah, maybe not.  There was something about this recently though
[22:04] <benji> mars: nope; it's simply that the r137 version is missing
[22:05] <benji> I've changed the versions.cfg in my branch to let me build, but it looks like someone checked in a new requirement without adding the distribution for that version
[22:05] <james_w> anyone have a clue how specification-bug links should be exported?
[22:05] <rockstar> james_w, specs can be linked to bugs?
[22:05] <james_w> the only other user of IBugLinkTarget is answers, which is not exported either
[22:05] <james_w> rockstar, they can indeed
[22:05] <james_w> rockstar, through different code to branches apparently
[22:06] <wgrant> benji: You download-cache update succeeded?
[22:06] <mars> benji, bzr annotate versions.cfg, then check the revision history of download-cache for something in the same day
[22:06] <wgrant> benji: The format changed recently, so you'll need upgrade before you can update.
[22:07] <benji> wgrant: that's the problem; it attempted an on-the-fly upgrade, but I didn't notice that that failed
[22:08] <mars> ah
[22:08] <mars> gary_poster, ping, ^ do we need to tell everyone to manually upgrade their download-cache?
[22:08] <gary_poster> mars, I did
[22:09] <mars> gary_poster, ah, sorry, I just saw it got threaded (darn Thunderbird :)
[22:09] <gary_poster> :-)
[22:10] <benji> mars: at least you have an excuse; I saw the thread but didn't realize its significance
[22:24] <maxb>  $ bin/jslint -a
[22:24] <maxb> jslint: No files to lint.
[22:25] <maxb> Help? I want to test an updated spidermonkey (/usr/bin/js) package I just built
[22:29] <wgrant> maxb: Have you built the JS?
[22:29] <maxb> I need something other than "make" ?
[22:30] <wgrant> No.
[22:30] <wgrant> jslint is currently consuming all of one core, so I presume it's working for me.
[22:31] <maxb> hah - it did that to me, then eventually just stated "jslint: No files to lint."
[22:31] <wgrant> Oh.
[22:31] <wgrant> Well, I guess we'll see.
[22:31] <wgrant> Eventually.
[22:34] <maxb> Oh. That would be it doing "for file_id in self.tree" on the LP bzr tree, I guess
[22:34] <maxb> And skipping lib/* and build/* ???
[22:36] <maxb> Seeing as all the versioned .js files in the tree are under lib/, this is rather stupid
[22:38] <wgrant> Where's this? In lazr.js?
[22:39] <wgrant> Huh, that is a bit special.
[22:40] <wgrant> I'm wondering whether I want to remove that check or not. I fear the number of errors...
[22:46] <maxb> $ wc -l jslint-all.out
[22:46] <maxb> 1449 jslint-all.out
[22:46] <maxb> lots of lint
[22:46] <maxb> lib/canonical/launchpad/icing/yui_2.7.0b/ ?!
[22:47] <maxb> someone explain to the novice why we still have YUI 2 in tree? :-)
[22:49] <maxb> jslint: Lint found in '/home/maxb/launchpad/lp-branches/devel/lib/lp/app/javascript/tests/test_lp_collapsibles.js':
[22:49] <maxb> Line 20 character 9: Expected '}' and instead saw '}'.
[22:49] <maxb> uhm thanks :-)
[22:54] <wgrant> maxb: IIRC YUI2 is used for the calendar widget.
[22:54] <maxb> yuck
[22:54] <maxb> that is all I have to say
[22:54] <wgrant> Of course we should never have had any YUI version at all in the tree.
[23:24] <maxb> Can someone delete these for me? https://launchpad.net/~launchpad/+archive/ppa/+delete-packages?field.name_filter=xulrunner
[23:25] <maxb> The binaries packages built from that source are now overridden by the spidermonkey source package
[23:27] <wgrant> maxb: Is that going to end up in the primary archive at some point?
[23:28] <maxb> I've given up following that saga
[23:28] <maxb> It's easier to just PPAize the thing
[23:28] <wgrant> Heh.
[23:28] <wgrant> Also, we can probably delete psycopg2 now.
[23:28] <wgrant> Since I'm running it fine with 2.2
[23:28] <wgrant> Which must mean that launchpad-dependencies has been fixed.
[23:28] <maxb> oh, point
[23:29] <maxb>   * Remove dependency on python-debian, now in sourcedeps.
[23:29] <maxb> too
[23:29] <wgrant> I was just wondering about that.
[23:30] <wgrant> So, can someone in ~launchpad please remove xulrunner, psycopg2 and python-debian from all series in the ~launchpad PPA?
[23:31]  * maxb copies lp-deps 0.85 to lucid too, and sighs a bit that people don't follow the instructions
[23:32] <wgrant> When did you do the spidermonkey copy?
[23:33] <maxb> About a minute before I asked for deletion here
[23:33] <wgrant> Hm.
[23:33] <wgrant> Publisher is being slow again :(
[23:34] <wgrant> But soon I will have logs, so I can maybe optimise it without harrassing too many people.
[23:37] <lifeless> wgrant: A r c h i v e : + i n d e x
[23:39] <wgrant> I tried to find my branch for that yesterday, but failed.
[23:39]  * wgrant looks harder.
[23:56] <poolie> mkanat: so it seems to me that if we're going to have a stable branch
[23:56] <poolie> if there's going to be any point in it
[23:56] <poolie> first, launchpad needs to deploy it
[23:56] <poolie> second, we ought to do non-intrusive fixes onto that
[23:56] <mkanat> poolie: Oh, launchpad is already running identical code to the stable branch (except for a fix in start-loggerhead, which they don't use).
[23:57] <mkanat> poolie: Yeah, I agree about non-intrusive fixes.
[23:57] <poolie> can you expand 'identical code'?
[23:57] <poolie> if you land new fixes on 1.18, will they get them?
[23:57] <mkanat> poolie: I branched the stable branch at the same point that launchpad is currently running from, I believe. I can double-check that, though.
[23:58] <mkanat> poolie: They'll get them if I merge the stable branch into their branch when there are fixes.