[00:18] <wgrant> lifeless: https://code.launchpad.net/~linaro-infrastructure/launchpad/workitems-migration-script/+merge/93883 <- I think that could/should be done as an API script, what's your opinion?
[00:19] <wgrant> poolie: Do you want to redo https://code.launchpad.net/~mbp/launchpad/remove-bsondump2/+merge/93778 with a proper whoami?
[00:19] <wgrant> You seem to have been setuplxc'd.
[00:19]  * StevenK prods wgrant to fix the topic
[00:19] <wgrant> I'm bac, what are you talking about.
[00:19] <StevenK> Haha
[00:33] <poolie> wgrant, ok
[00:34] <poolie> that was icky
[00:34] <poolie> i'm glad i caught it
[00:34] <poolie> these scripts that do lots of random modifications to your host machine :(
[00:34] <StevenK> You mean a lot like rf-setup?
[00:35] <poolie> yeah, but lxc ought to be a chance to get away from that
[00:35] <poolie> perhaps i should run setuplxc inside a vm :/
[00:48] <thumper> wallyworld_: oi, can I please have a link on the team code home page for the +recipes please
[00:48] <thumper> wallyworld_: I'll buy you a drink
[00:48] <thumper> wallyworld_: maybe a backrub?
[00:48] <wallyworld_> thumper: oooh, now you're talking
[00:49]  * StevenK reviews his breakfast
[00:49] <StevenK> TypeError: ('Incompatible metatypes', (<class 'lp.bugs.interfaces.bug.IBugLimitedView'>, <InterfaceClass lp.bugs.interfaces.bug.IBugView>))
[00:49]  * StevenK stabs Zope
[01:26] <thumper> StevenK or wgrant: do either of you know what is causing W: GPG error: http://archive.canonical.com precise Release: The following signatures were invalid: BADSIG 40976EAF437D05B5 Ubuntu Archive Automatic Signing Key <ftpmaster@ubuntu.com>
[01:27] <lifeless> thumper: intercepting proxy cache
[01:28] <wgrant> Or scandium being terrible again.
[01:28] <wgrant> But I think that's mostly fixed, so probably your ISP is shite.
[01:28] <lifeless> in NZ proxy caches you.
[01:33] <mwhudson> thumper: it can also be the file in /var/lib/apt/lists being corrupt
[01:39] <wgrant> lifeless: I'd like to remove feature rules for these removed flags: https://pastebin.canonical.com/60613/
[01:39] <wgrant> lifeless: And add this rule for my heat changes (not yet deployed): https://pastebin.canonical.com/60614/
[01:40] <lifeless> if the code is gone, thats a no-brainer
[01:40] <wgrant> The code is indeed gone.
[01:40] <wgrant> And it is a no-brainer, but I still need a +1 :)
[01:40] <lifeless> +1 on them both
[01:40] <wgrant> Thanks.
[01:43] <wgrant> Totally not cool, fglrx.
[01:43] <wgrant> Ooh
[01:43] <wgrant> New apport in precise, though.
[01:44] <wgrant> does this mean LP won't have 9 bazillion bugs filed daily...
[01:45] <wgrant> Ah, no, still uploads to LP
[01:57] <wgrant> lifeless: Bug comment searching has never been enabled on prod AFAICT. Can I remove the code, since the current implementation is never going to perform even vaguely acceptably?
[01:58] <lifeless> yes
[01:58] <wgrant> Thanks.
[01:58] <lifeless> or should I say 'no, I want the quota' :P
[01:58] <wgrant> I'm removing targetnamesearch too
[01:58] <wgrant> Heh
[02:24] <lifeless> flacoste: I'm not sure we define 'core functionality' anywhere :)
[02:54]  * wgrant massacres the branchscammer
[02:58] <StevenK> Sounds lke an apt name.
[02:58] <StevenK> Put up a branch renaming it and it'll mark it r=me
[02:58] <wgrant> Maybe it's choking on MySQL again.
[02:59] <StevenK> Plausible.
[03:16] <wgrant> StevenK: https://code.launchpad.net/~wgrant/launchpad/obliterate-targetnamesearch/+merge/93914
[03:16]  * wgrant is preparing for the LOCTS
[03:21] <StevenK> wgrant: Sorry, I was lunching. Looking now.
[03:23] <wgrant> k
[03:24] <StevenK> wgrant: r=me
[03:25]  * StevenK approves of all this code death
[03:25] <wgrant> Thanks.
[03:25] <lifeless> see #launchpad for some related ;P
[03:25] <wgrant> Makes my disclosure work easier, and puts me in a good position for the LOCTS that will surely eventuate.
[03:25] <StevenK> Haha
[03:25] <lifeless> TS?
[03:26] <StevenK> I've not wanted to find out how much code I've ripped out versus added.
[03:27] <StevenK> Specifying multiple revspecs would help
[03:28] <wgrant> lifeless: Lines of Code Trading Scheme
[03:28] <wgrant> lifeless: Like an ETS, but for maintenance burden.
[03:29] <StevenK> Sigh, defeated by PQM
[03:29] <StevenK> Since it's the committer for each rev.
[03:30] <StevenK> Because auditing is for chumps
[03:30] <lifeless> wgrant: so, you're committed to futures
[03:30] <lifeless> StevenK: pqm isn't the author though, which is what you care about; just uses the merged in revs. or annotate.
[03:32] <lifeless> wgrant: you've checked prodconf for the heat config key ?
[03:32] <wgrant> lifeless: Yup, nothing there
[03:33] <StevenK> lifeless: How does annotate help? What I'd like is a large diff of any rev I have or someone else has landed to devel
[03:33] <lifeless> StevenK: so, perhaps it doesn't :) but it can tell you loc last touched by you, for the current tree, which is a related q
[03:34] <wgrant> Ohloh gives lines changed, but not +-
[03:34] <lifeless> anyhow, use the merged in revs to determine author, and mainline diffs for the content
[03:35] <StevenK> Perhaps I should learn bzrlib
[03:35] <StevenK> I was hoping I could loop over bzr log
[03:36] <StevenK> wgrant: So, given IBug's definition in configure.zcml, I don't need to split it into IBugView and IBugLimitedView, I can just move id to LimitedView ?
[03:37] <wgrant> StevenK: Unfortunately, yes.
[03:38]  * StevenK reverts the split he did
[03:38] <wgrant> If you've got a split that works, by all means do it.
[03:39] <StevenK> I do -- but only in terms of Python. I wasn't sure how to shoehorn it into the ZCML
[03:42] <StevenK> wgrant: Given the branch I just reviewed, can MessageChunk.fti die a horrible death?
[03:42] <wgrant> I'd prefer not.
[03:42] <wgrant> It's write-once so pretty cheap.
[03:42] <wgrant> And I hope we'll do comment searching in future, even if we don't move to Solr soonish.
[03:43] <wgrant> tsvector concat should make it pretty easy to do comment searches.
[03:43] <lifeless> didn't you just remove comment searching?
[03:43] <wgrant> Yes
[03:44] <wgrant> But if we want to do a non-stupid implementation in future, it might well make use of MessageChunk.fti
[03:44] <wgrant> Since that table is never updated it's cheap to keep.
[03:46] <poolie> http://37signals.com/svn/posts/3112-how-basecamp-next-got-to-be-so-damn-fast-without-using-much-client-side-ui -- interesting
[03:46] <wgrant> Yeah, saw that a couple of days ago.
[03:47] <wgrant> Pretty interesting indeed.
[03:47] <wgrant> But it relies on having a cascading last_updated column on pretty much everything.
[03:47] <wgrant> Which has to increase write contention massively.
[03:48] <poolie> i wonder if it's in plain old sql
[03:48] <lifeless> they are caching into memcache I believe
[03:48] <wgrant> They cache into memcached, yes.
[03:48] <wgrant> But IIRC it's all ActiveRecord otherwise.
[03:48] <lifeless> so contention == redundant writes more than lock-slows
[03:48] <wgrant> lifeless: no, no
[03:48] <poolie> also i guess unlike lp they have relatively few objects read by millions of people
[03:48] <wgrant> lifeless: The whole caching scheme relies on having a last_updated field to generate the cache key from
[03:49] <poolie> though, would that really be more mtime fields than lp?
[03:49] <poolie> perhaps
[03:49] <wgrant> There's no project mtime field.
[03:49] <wgrant> max_heat is the closest, and I deleted that two weeks ago :)
[03:49] <wgrant> Partly because of contention, partly because of terrible implementation.
[03:50] <poolie> hm
[03:50] <poolie> an mtime on /ubuntu would probably suck
[03:50] <wgrant> Exactly.
[03:50] <poolie> but i wonder if you would really need it
[03:50] <lifeless> wgrant: I missed that; it looked like they just update the cache on any write, recursively, on all places affected.
[03:50] <wgrant> lifeless: They update the mtime all the way up the tree.
[03:50] <wgrant> lifeless: Cache contents never change for a given key.
[03:50] <lifeless> wgrant: sure, but that's just the mtime of the write
[03:50] <wgrant> The key includes in the update time.
[03:50] <poolie> anyhow, so it's interesting that they have headed down the course lp was going to take ~2y ago, and that lp abandoned
[03:51] <lifeless> wgrant: doesn't imply table storage of said value
[03:51] <poolie> and, the opposite of lp's handlebars approach
[03:51] <wgrant> poolie: Did you see the HN discussion?
[03:51] <lifeless> wgrant: or are you saying 'to find the cached entry they need a consistent mtime on all things' ?
[03:51] <poolie> no
[03:51] <wgrant> poolie: It goes into stuff like this. Let me find it.
[03:51] <wgrant> lifeless: Right.
[03:52] <wgrant> lifeless: The invalidation mechanism is that the object's mtime changes.
[03:52] <wgrant> So to change something 5 levels down, they need to write a new mtime on all 5 levels.
[03:53] <wgrant> http://news.ycombinator.com/item?id=3603367
[03:53] <wgrant> poolie: ^^
[03:53] <poolie> wgrant, so (perhaps hn answers this), i don't think you would necessarily have to have an mtime all the way up
[03:53] <wgrant> There is a bit of an argument over whether forcing everything to be server-side like this is smart.
[03:53] <poolie> in the db
[03:54] <wgrant> So, you could probably store the mtime in something more sensible.
[03:54] <poolie> for instance if you change a bugtask in /ubuntu, you would need to invalidate any caches of bugs/ubuntu
[03:54] <wgrant> Right.
[03:54] <poolie> it seems like the important thing is to have a pubsub-ish tree of "I changed!"
[03:55] <wgrant> And you only care about last-update-wins, so ACID is not useful.
 There is a bit of an argument over whether forcing everything to be server-side like this is smart.
[03:56] <poolie> it's useful data that it can be made to work well
[03:56] <wgrant> Indeed.
[03:56] <poolie> i guess they need the FE to be close to the users
[03:56] <wgrant> Yep
[03:56] <poolie> but perhaps no more so than for a more ajaxy approach, if they are doing few requests
[03:57] <wgrant> DHH goes into the latency aspects.
[03:57] <lifeless> they are using ajax
[03:57] <lifeless> according to the HN thing, 50% of their code is coffeescript, or thereabouts
[03:57] <wgrant> Just over half-way down the HN comments.
[04:00] <poolie> lifeless, well i said 'more ajaxy', don't you think this is a less ajaxy approach?
[04:01] <poolie> if you accept a definition of ajax that the x means data comes down as xml or json
[04:01] <lifeless> I think this is equivalently ajaxy; it does what lp does in large part (which is one of the things that is terrible about LP client side support)
[04:02] <lifeless> we render on the server, ship html to the browser, the browser shoves it into the dom
[04:03] <lifeless> their big claim is less client-side /stuff/ - no MVC on the client, no template rendering on the client, so less surface area of e.g. browser variation to deal with
[04:04] <poolie> sure
[04:04] <poolie> what i meant was http://news.ycombinator.com/item?id=3604732
[04:09] <wgrant> I don't think LP's template caching thing should be abandoned.
[04:09] <wgrant> It was just applied in completely the wrong way.
[04:09] <wgrant> It was used to make slow things fast.
[04:10] <wgrant> Rather than fast things very fast.
[04:10] <wgrant> It was used as a means to stop timeouts.
[04:10] <wgrant> I think it still has a place in LP.
[04:10] <wgrant> But not for any of its current uses, except the blog caching thing.
[04:16] <lifeless> its causing plenty of complaints today :) - e.g. jono's why-is-the-list-of-projects-stale qeru from a few days back
[04:17] <wgrant> Oh yes, as I said, the current implementation is fucking terrible.
[04:20] <wgrant> rargh
[04:20] <wgrant> Must smash multitask bugs
[04:20] <wgrant> Slow branch vocab is slow
[04:55] <poolie> wgrant, i'm still shaving bzr yaks towards rebasing the bsondmp patch
[04:56] <poolie> and ubuntu bugs ftm
[04:59] <wgrant> poolie: There's a mostly working rewrite branch that I used for that purpose last week.
[05:06] <wgrant> translationstobranch and the gardener need a few good amputations :(
[05:57] <poolie> wgrant, https://code.launchpad.net/~mbp/launchpad/remove-bsondump2/+merge/93778 has the right userid now
[05:57] <poolie> any other comments?
[05:57] <wgrant> "good riddance"
[05:57] <wgrant> poolie: Can you land it yourself?
[05:58] <poolie> yes
[05:58] <wgrant> Great.
[06:01]  * wgrant touches Storm in inappropriate places.
[06:02]  * StevenK attempts to resist the urge to /nick Storm
[06:13] <nigelb> http://en.wikipedia.org/wiki/Storm_%28Marvel_Comics%29
[06:19] <nigelb> 33
[06:20] <nigelb> bah
[06:33] <wgrant> Ah, heh
[06:33] <wgrant> garbo runs tasks in threads, so of course the default script feature controller isn't always visible.
[07:25] <stub> wgrant: I think garbo's architecture would suite switching to multiprocess now that the new stdlib library is available.
[07:26] <wgrant> stub: Yeah, multiprocessing is pretty nice
[07:26] <wgrant> Might look at that once we're on 2.7
[07:26] <wgrant> Oh, it's in 2.6 too
[07:26] <stub> Oh... was thinking it was 2.6
[07:26] <stub> yer
[07:26] <wgrant> stub: https://code.launchpad.net/~wgrant/launchpad/garbo-feature-flags/+merge/93928 is a quick fix for now
[07:26] <wgrant> It's one line of significant change, if you want to review...
[07:27] <stub> sure. not sure what it is fixing yet...
[07:27] <stub> oic
[07:27] <wgrant> Feature controllers are thread-local.
[07:28] <wgrant> garbo calls login to set up an interaction in the fresh thread, but it also needs a feature controller now
[07:29] <stub> So what is that constant for anyway? I'm not sure how we calculate bug heat any more.
[07:29] <stub> (r=stub btw)
[07:29] <wgrant> Thanks.
[07:30] <wgrant> Bug heat no longer degrades over time, so it doesn't need to be updated weekly, just on changes to the bug.
[07:30] <wgrant> But we change the algorithm occasionally.
[07:30] <wgrant> So I adjusted the garbo job to read a timestamp from a feature flag -- anything older than that flag is considered invalid and gets recalculated.
[07:30] <stub> So the timestamp is for the last time we changed the algorithm. I see.
[07:31] <stub> I could argue that it gets hardcoded in the code somewhere rather than abusing feature flags, as it will change when the code changes.
[07:31] <wgrant> We don't know when the code is deployed, though.
[07:32] <stub> You don't need to know - pick a date a few days in the future and she'll be right.
[07:32] <wgrant> Heh
[07:32] <wgrant> Not quite
[07:32] <wgrant> It will then recalculate every bug every hour until then.
[07:32] <wgrant> Which sounds less than ideal for bloat.
[07:32] <stub> But it won't, as it will take a while to recalculate. Anyway... this has already been discussed I'm sure.
[07:32] <wgrant> An alternative is a version column, but meeeh
[07:32] <wgrant> It won't take long.
[07:33] <wgrant> Yeah, lifeless suggested this approach.
[07:34] <stub> Looks like rather than feature flags, we need some generic shared runtime configuration. Feature flags could be built on that. Zookeeper almost meets the needs, but I'd rather not call Zookeeper from inside stored procedures.
[07:35] <lifeless> aren't feature flags generic, shared and at runtime ?
[07:36] <stub> Yes, and if you renamed them you would have an implementation :)
[07:37] <stub> Like washing my dishes in a toilet. Technically, it is doable and done right no problems. But it is still called a toilet, and people still go euwww.
[07:55] <stub> What are we going to do about ProductSeries.name ? It is actually a version number, and should be using the debversion type.
[07:55] <stub> Quick fix and change the type with a dbpatch, or a correct fix and rename the column and change its type?
[07:56] <stub> Bug #718660
[07:56] <_mup_> Bug #718660: Drop version_sort_key, changing columns to debversion type <Launchpad itself:Triaged> < https://launchpad.net/bugs/718660 >
[07:56] <stub> I guess we can rename the column and keep 'name' around for compatibility, API clients etc.
[07:57] <wgrant> I'm not sure the rename is valuable.
[07:57] <wgrant> Or even correct.
[08:09] <stub> Mainly thinking about maintaining API compatibility. I haven't played with it so not sure what the policies and such are.
[08:16]  * wgrant feels dirty, but hopes for a review of https://code.launchpad.net/~wgrant/launchpad/bulk-insert/+merge/93930
[08:33] <lifeless> stub: api compat - its fairly loosely typed
[08:33] <lifeless> stub: that would cast into a string for instance (or at least I'd hope it does ;P)
[08:36] <stub> It will be a string from Python - I don't think we have a debversion type?
[08:36] <StevenK> We do
[08:36] <StevenK> We use it extensively in Soyuz
[08:38] <wgrant> But versions are normally handled as strings.
[08:39] <stub> wgrant: Your bulk insert - shouldn't Storm do that optimization, using multi row insert if it has several objects of the same type to create in sequence?
[08:40] <wgrant> stub: Yeah, but there are questions around how that works with ordering guarantees.
[08:41] <wgrant> And I need this now, not in 6 months when the Storm devs have worked out what the guarantees are :)
[08:41] <wgrant> Bug #411556
[08:41] <_mup_> Bug #411556: Storm should support multi-row inserts <Storm:New> < https://launchpad.net/bugs/411556 >
[08:41] <wgrant> Syntax also differs between DBMSes.
[08:43] <stub> wgrant: I don't see what the ordering problem is.
[08:44] <stub> wgrant: You have a list of things to flush. If you are about to do an INSERT, and the next item is also an INSERT of the same type, you do them together as one statement.
[08:47] <wgrant> There are also issues around populating the primary keys.
[08:47] <wgrant> MySQL provides no way to do it AFAICT
[08:47] <wgrant> And I'm not sure if postgres guarantees order.
[08:47] <stub> Not sure who on the team can review branches poking Storm privates anymore - allanap or bac?
[08:47] <wgrant> (Storm relies on knowing the PK for each inserted object)
[08:48] <wgrant> They're read-only storm privates, so they're mostly harmless :)
[08:48] <stub> You would invoke the database multiinsert you are landing, or aarons executemany
[08:50] <wgrant> stub: But the RETURNING order is undefined.
[08:50] <wgrant> AFAICT
[08:50] <wgrant> So we can't map them back to the objects.
[08:54] <stub> Really? That seems somewhat silly :-(
[08:56] <stub> Its a PostgreSQL extension, so I assume it is defined as the same order of the rows you are inserting. It isn't explicitly documented, but the extension would have been added for exactly this use case.
[08:57] <stub> (Inserting a set of records, and you want to know what the DB set your NULLs to and how the triggers munged your data)
[08:58] <wgrant> I guess.
[08:59] <mrevell> Hello
[09:03]  * jelmer is still strugging with his scanner branch
[09:04] <wgrant> jelmer: What's up?
[09:04] <adeuring> good morning
[09:06] <jelmer> wgrant: I'm trying to reproduce the timeout issue we've been seeing on qastaging but have failed so far
[09:07] <wgrant> jelmer: It's not just qastaging being terrible/
[09:07] <wgrant> jelmer: abentley is working on a scanner DB performance branch at present.
[09:07] <jelmer> I doubt it, we saw similar issues on production earlier (the incident)
[09:07] <wgrant> True.
[09:08] <jelmer> wgrant: oh, I didn't realize abentley was working on that bug now
[09:08] <jelmer> it was assigned to Graham for a while and then unassigned I think
[09:08] <wgrant> jelmer: He's batching the BranchRevision inserts AIUI
[09:08] <jelmer> I should talk to Aaron and make sure our changes don't conflict too badly
[09:09] <wgrant> stub: Also, about executemany, it seems it's implemented in psycopg2 as just a sequence of normal executes.
[09:10] <wgrant> stub: Which seems like it would have negligible benefit.
[09:10] <stub> If it isn't doing anything with prepared statements, yer
[09:12] <stub> It might be using prepared statements under the hood btw.
[09:12] <wgrant> It didn't seem to be.
[09:12]  * wgrant rechecks.
[09:13] <stub> If it is interpolating its own variables into the query string, it isn't.
[09:13] <stub> If the query string and parameters are being sent to libpq separately, it might :)
[09:15] <wgrant> https://bazaar.launchpad.net/+branch/ubuntu/psycopg2/view/head:/psycopg/cursor_type.c#L491
[09:15] <wgrant> 524 looks pretty suspicious.
[09:16] <wgrant> It parses the args into 'operation', then passes that straight into execute.
[09:16] <stub> That is really ugly Python
[09:16] <wgrant> Heh
[09:20] <stub> It isn't doing interpolation there... if it is happening, it is down in _psyco_curs_execute
[09:27] <stub> Might be write on multi value insert returning rows in an arbitrary order :-(
[09:27] <stub> c/write/correct
[09:29] <wgrant> stub: I didn't have any evidence either way, apart from the docs not specifying it and it seeming too good to be true.
[09:43] <wgrant> stub: Have you already created those indices?
[09:44] <stub> wgrant: No. Was waiting for the backups to complete before suggesting
[09:44] <wgrant> Yeah
[09:45] <wgrant> Finished early tonight.
[09:45] <wgrant> Actually, it's been quick for the last week
[09:45] <wgrant> Hmm
[09:56] <stub> wgrant: So https://code.launchpad.net/~wgrant/launchpad/more-indices/+merge/93916 ?
[09:57] <wgrant> stub: Yup
[09:57] <stub> k. I'll apply that now.
[09:59] <wgrant> Thanks.
[10:00] <lcanas> hey guys, good morning from Madrid
[10:01] <lcanas> one question about launchpadlib, how can I get the complete list of bugs for a given project? As far as I saw I have to get all the bugs and examine them one by one .. I'm pretty sure I'm missing something
[10:01] <wgrant> lcanas: lp.projects['fooproject'].searchTasks()
[10:05] <lcanas> wgrant, oh! great! thank you :D
[11:54] <rick_h> morning
[12:05] <ESphynx> hey guys, why do my daily builds show up as successful, yet I get these also what is up with 'ERROR: ld.so: object 'libfakeroot-sysv.so' from LD_PRELOAD cannot be preloaded: ignored.' errors?
[14:07] <deryck> Morning, everyone.
[14:07] <jelmer> hey Deryck
[14:10] <ESphynx> 'morning deryck :)
[14:23] <czajkowski> aloha
[14:24] <ESphynx> hey guys, what's with the 'You have not informed bzr of your Launchpad ID, and you must do this to...' ?
[14:32] <deryck> abentley, adeuring -- https://plus.google.com/hangouts/extras/talk.google.com/orange-standup
[14:33] <ESphynx>    Remove the following packages:
[14:33] <ESphynx> 1)     pbuilder-satisfydepends-dummy ?
[14:34] <czajkowski> ESphynx: copying and pasting the same question into multiple channels is not necesary, when someone can answer it they will.
[14:35] <ESphynx> czajkowski sorry I thought you were telling me I should ask here as well :P
[14:35] <czajkowski> ESphynx: not at the same time, pick one place perhaps :)
[14:35] <ESphynx> well it all depends whether the same people are in both places or not ;P
[14:36] <ESphynx> i'm trying to move ia32-libs ahead :|
[14:41] <rick_h>  https://launchpad.net/lpjsmin
[14:44] <nigelb> man, someone should tel stub his part message probably needs some cleaning/fixing.
[14:46] <rick_h> adeuring: http://pypi.python.org/pypi/modern-package-template as well, <3
[14:46] <adeuring> rick_h: thanks!
[14:50] <rick_h> deryck: https://dev.launchpad.net/JavaScriptIntegrationTesting?highlight=%28yuixhr%29 looks like what you were talking about?
[14:50] <deryck> rick_h, indeed.  Was having a hard time finding it myself.
[14:50] <deryck> rick_h, didn't think to try the wiki. :)
[14:50] <rick_h> deryck: ok cool, will go from there. Thanks for the heads up.
[14:51] <deryck> rick_h, np.  Thanks for handling it.
[15:14] <salgado> sinzui, can you land https://code.launchpad.net/~salgado/launchpad/bug-937310/+merge/93987 for me?
[15:14] <sinzui> Yes I can
[15:15] <salgado> thanks!
[15:35] <ESphynx>  <tumbleweed> launchpad doesn't use pbuilder -- meh ?
[15:53] <czajkowski> sinzui: aloha there! thanks for the mail over the weekend
[15:53] <sinzui> youy welcome
[15:53] <czajkowski> sinzui: worked my way through the review projects and manged ok
[15:53] <czajkowski> there are 11 there am which I am sunsure of
[15:53] <czajkowski> and didnt want to just ack them
[16:05] <sinzui> czajkowski, I ran this : ./disable_projects.py ielix campus vinfolio ptchiang+test
[16:05] <czajkowski> ahh
[16:06] <sinzui> czajkowski, I am deactivating the three ~registry projects
[16:06] <czajkowski> nods those were the ones I wasn't sure about
[16:06] <sinzui> This one needs a fix first https://launchpad.net/madrasah
[16:07] <sinzui> madrasah is not the upstream for edubuntu-live. We need to remove the package link to deactivate it.
[16:07] <czajkowski> yes they had picked too many liciences
[16:07] <sinzui> The licenses are fine
[16:07] <sinzui> Anything like a distro will have them all
[16:08] <sinzui> czajkowski,  I followed the All packages link from the project page to find https://launchpad.net/madrasah/+packages
[16:09] <sinzui> We want to remove the package, then this will be an empty, meaningless project that we will deactivate
[16:09] <czajkowski> ok
[16:09] <sinzui> and I have done that
[16:09] <sinzui> The four remaining projects can be approved
[16:10] <czajkowski> sinzui: thanks
[16:10] <czajkowski> glad I checked with you
[16:13] <rick_h> deryck: so just a heads up, added a card to see about updating the yui xhr tests to be combo loader friendly. Not sure the best way to do that off the top of my head yet.
[17:47] <salgado> flacoste, around? when you moved me to ~launchpad-emeritus I ceased being a member of https://launchpad.net/~launchpad-dev and because of that lost my subscription to launchpad-dev@
[17:47] <salgado> what's the correct way to get me subscribed again? do I need to join https://launchpad.net/~launchpad-dev?
[17:50] <lifeless> moin
[17:50] <lifeless> salgado: just join it, its an open list
[17:51] <lifeless> -> no privileges are granted by membership in it :>
[17:52] <salgado> oh, right, missed that
[17:52] <salgado> lifeless, btw, I've sent a mail a few hours ago so it's probably stuck waiting for moderation. care to let it through?
[19:02] <salgado> lifeless, you don't want to let my message through? ;)
[19:07] <lifeless> salgado: haven't seen it - I'm doing my morning mail scan
[19:07] <lifeless> salgado: plus giving czajkowski a hand
[19:09] <czajkowski> salgado: I dont see you mail in the queue either
[19:09] <salgado> lifeless, oh, ok, thought you didn't see my previous msg
[19:09] <salgado> hm, maybe it's dropped if I'm not subscribed to the list
[19:10] <salgado> but I should have good "standing", no?  do we still have the concept of good standing in LP?
[19:10] <jcsackett> sinzui: got a second to mumble?
[19:11] <lifeless> salgado: I think so :)
[19:42] <sinzui> jcsackett, I can mumble. X just gave me some problems, but I think I am stable again
[19:42] <jcsackett> sinzui: cool.
[19:44] <lifeless> salgado: I can't see the moderate mail for you
[19:44] <lifeless> salgado: I have no idea why not. I suspect a bug due to your odd state.
[19:44] <sinzui> jcsackett, http://people.canonical.com/~ianb/picker-demo.ogv
[19:44] <lifeless> sinzui may know.
[19:44] <salgado> lifeless, my odd state?
[19:44] <lifeless> salgado: you didn't leave the team directly
[19:45] <sinzui> salgado, yes we have standing
[19:45] <sinzui> We can make you excellent so that you can post to any list
[19:46] <sinzui> salgado, you have excellent standing now
[19:46] <salgado> sinzui, heh, no need to worry; was just wondering because a message sent to launchpad-dev@ while I was not subscribed seems to have been discarded
[19:46] <salgado> oh, well, thanks
[19:47] <sinzui> salgado, I see messages I moderate arrive. Maybe out list is ours/days behind again
[19:48] <salgado> sinzui, I resent it and it's arrived already, so I think that's unlikely?
[19:49] <sinzui> I agree
[19:52] <lifeless> right, the lack of moderation notice is what was odd
[19:52] <lifeless> I'm thinking its because of a glitch in that you didn't 'leave' the team - you had indirect membership. I am probably wrong.
[19:55] <lifeless> sinzui: speaking of IE9 937722
[19:55] <lifeless> bah
[19:55] <lifeless> sinzui: speaking of IE9 - bug 937722
[19:55] <_mup_> Bug #937722: error loading Inkscape page on IE9 <bugs> <ie> <javascript> <Launchpad itself:Triaged> < https://launchpad.net/bugs/937722 >
[19:55] <lifeless> sinzui: I'd like to get your thoughts on IE* + js compat.
[19:56] <lifeless> sinzui: and chrome frame. Do you have time to talk (voice) today ?
[19:56] <sinzui> in a few minutes
[20:01] <lifeless> cool
[20:03] <rick_h> lifeless: that looks like a dupe of bug 894797, should be pretty simple fix for that one at least
[20:03] <_mup_> Bug #894797: bug portlet ajax calls break in IE and break js for other features <bugs> <ie> <javascript> <markup> <ui> <Launchpad itself:Triaged> < https://launchpad.net/bugs/894797 >
[20:04] <rick_h> though not sure since that ie9 and my test/bug was ie8 I believe
[20:05] <lifeless> rick_h: sure, its more the overall challenge we're setting ourselves I'm interested in
[20:05] <rick_h> lifeless: gotcha, ok.
[20:05] <lifeless> rick_h: (I mean, please do dupe it :P)
[20:06] <rick_h> well, I'm not 100% sure, it's a different error string it looks like
[20:06] <lifeless> rick_h: do you have any thoughts; is supporting IE9 harder than running parallel form implementations for all of LP ?
[20:06]  * rick_h is trying to follow the screenshot vs error message
[20:06] <rick_h> no, supporting IE9 isn't a huge issue. There's really just a couple of things we hit like this portlet stuff
[20:06] <rick_h> which should never have happened anyway
[20:07] <rick_h> the big thing is that as we get more client side and worry about the html5 history things that's currently causing issues for IE and opera
[20:07] <rick_h> that's a larger chunk of work, but still think that should be done
[20:07] <rick_h> imo
[20:07] <lifeless> what do you think of chrome frame ?
[20:07] <rick_h> I've never used it, and not sure it's always available as an option.
[20:08] <rick_h> should be good/nice, but then again it's kind of like tossing a towel over some issues and allowing things to be a bit lazier in a way.
[20:08] <lifeless> you're thinking locked down corporate w/activeX white-listing ?
[20:08] <rick_h> lifeless: yea, I know you can install it sans-root now, but still not tested to see if it's availin all situtations
[20:09] <rick_h> plus just the whole default non-technical user experience of first time ubuntu users/etc
[20:09] <rick_h> that might not have chrome frame in their heads anyway
[20:09] <lifeless> I don't think users really see it do they ?
[20:09] <rick_h> there's a certain amount of just 'good practice' that I feel falls away
[20:09] <lifeless> its just a signed control, then the whole browser engine is handed over
[20:09] <rick_h> lifeless: no, I just mean that they don't know to go find frame and install it
[20:10] <lifeless> rick_h: they don't have to
[20:10] <lifeless> oh hmm
[20:10] <lifeless> I *thought* you didn't have to but perhaps recent IE makes it a separate step
[20:10] <rick_h> my understanding is that they did?
[20:10] <rick_h> right, you can hint to them to go install it
[20:10] <lifeless> http://www.chromium.org/developers/how-tos/chrome-frame-getting-started#TOC-Detecting-Google-Chrome-Frame-and-P
[20:10] <rick_h> but it's a local change to the client's browser
[20:11] <rick_h> If Google Chrome Frame is not installed, you can direct your users to an installation page.
[20:11] <rick_h> If Google Chrome Frame is installed, it detects the tag you added and works automatically.
[20:11] <sinzui> lifeless, sorry. X/Xinit is dying and not restoring.
[20:11] <lifeless> sinzui: \o/
[20:12] <lifeless> sinzui: I swear, you have a magic magnet
[20:12] <sinzui> I am going to restart to hope I get 6 hours of stability.
[20:13] <rick_h> lifeless: yea, so this link you sent loads up the "install chrome frame" bit in a modal popup served via them (iframe?) and then once the install is done it can try to reload your page or another page
[20:14] <lifeless> I see that now :)
[20:14] <lifeless> I was sadly hopeful for magic
[20:14] <rick_h> yea, it's magic once you get past the install parts, but that's a big step
[20:16] <rick_h> comparing UA in GA it looks like nearly 10% of users don't get the buglisting history stuff
[20:16] <rick_h> 9.86ish
[20:18] <rick_h> heh, and 3% of FF users are still 3.6 which doesn't either ugh. Not bad though I guess, that 96% of FF users are 7.0 or greater
[20:30] <sinzui> lifeless, I can talk now. Which technology...preferably something I can use my phone with. skype or hangout
[20:30] <lifeless> skype is easy
[20:32] <sinzui> I am on skype
[20:34] <wallyworld> thumper: your +recipes change is merged and in buildbot now. will be deployed tomorrow at the latest
[20:37] <rick_h> lifeless: if you get a sec can you ok this: https://code.launchpad.net/~rharding/lp-source-dependencies/add_lpjsmin/+merge/94051 ? As part of the moving the js min into a package in pypi as we discussed
[20:42] <lifeless> rick_h: we don't review changes to lp-source-deps, just commit :)
[20:43] <rick_h> lifeless: ok, wasn't sure if I needed sign off based on the comments in buildout.cfg there
[20:45] <lifeless> rick_h: you may need a review of the change in LP to use it
[20:45] <lifeless> rick_h: or it may be up to you, based on the OptionalReviews policy
[20:45] <rick_h> lifeless: yea, I'll definitely have that
[20:46] <rick_h> I'll probably even ask StevenK to do it since it's around stuff he's done recently and he'll kick me into place best :)
[21:00] <rick_h> StevenK: so yea, when you're around can you peek at this and make sure it's ok? I've updated the lp-source-deps repo with the two new packages. https://code.launchpad.net/~rharding/launchpad/use_lpjsmin/+merge/94054
[21:32] <thumper> wallyworld: so, backrub?
[21:34] <sinzui> backrub? I didn't know this was the channel to get some man-on-man action
[21:36] <james_w> can anyone see the link to download the file on http://pypi.python.org/pypi/oops_amqp ?
[21:36] <lifeless> sinzui: you call them men ? :P
[21:36] <lifeless> james_w: its missing, possibly wallyworld did something unusual
[21:37] <lifeless> wallyworld: when yo udid the release what exact command did you run ?
[21:41] <wallyworld> thumper: ok. you bring the oil
[21:42] <wallyworld> lifeless: i can't recall exactly. something like "setup.py sdist upload --sign"
[21:42] <wallyworld> sinzui: thumper had to bribe me to get that +recipes fix done :-)
[21:43] <sinzui> wallyworld, You mustn't manage many. I would have done that for free so that I could stop looking through my browser history
[21:44] <wallyworld> sinzui: i would also have done it anyway "for free". i was joking about the bribe
[21:44] <sinzui> wallyworld, I know you well enough to see the joke
[21:45] <lifeless> wallyworld: that should have done it, but th efile is missing
[21:45] <lifeless> wallyworld: if you login and go to the files view for it, you can upload it now ;)
[21:45] <wallyworld> lifeless: will do. not sure what happened
[21:45] <lifeless> me neither
[21:45]  * sinzui takes a break to listen to Sonic Youth on rte 2fm
[21:46] <lifeless> wallyworld: doing 'setup register' would have updated the metadata but not uploaded the file
[21:46] <wallyworld> lifeless: i did that also
[21:48] <lifeless> wallyworld: ah; and let me guess, you ran that second ?
[21:48] <wallyworld> lifeless: perhaps, not sure
[21:48] <lifeless> don't
[21:48] <lifeless> only register once
[21:49] <lifeless> when claiming the name, after that sdist upload -s will update the metadata *and* attach the file
[21:50] <wallyworld> that makes sense. i thought i ran the upload last, but not sure now
[21:50] <james_w> https://dev.launchpad.net/HackingLazrLibraries
[21:51] <james_w> https://dev.launchpad.net/HackingLazrLibraries#releases is wrong then
[21:51] <james_w> or is right but expects the tarball to be uploaded to LP and to be picked up from there
[21:51] <wallyworld> james_w: file uploaded. can you see if you can access it?
[21:51] <james_w> thanks wallyworld
[21:51] <wallyworld> np
[21:51] <wallyworld> sorry about the stuff up
[21:53] <james_w> np
[21:55] <james_w> and it's in the ppa
[21:55]  * james_w moves on to patch datedir-repo
[21:58] <wgrant> lifeless: Chrome frame is pretty pointless now
[21:59] <wgrant> lifeless: IE8 and 9 are sufficiently unterrible now that it is simply embarrassing to not support them reasonably.
[21:59] <lifeless> wgrant: indeed; see my reply to curtis
[21:59] <wgrant> Didn't actually read the conversation, just saw a mention of /chrome frame/i and decided you were insane.
[22:01] <lifeless> I'm so glad you're making informed judgements now
[22:01] <wgrant> :)
[22:01] <wgrant> But our browser support policy seems stuck in 2008
[22:04] <sinzui> wgrant, stuck in 2008? I was surprise Lp supported IE 6 when I joined in 2007
[22:05] <wgrant> sinzui: Sorry, stuck in the common world of 2008.
[22:05] <wgrant> Where people had given up on IE6
[22:05] <wgrant> But now treated IE8 with less disdain.
[22:07] <StevenK> rick_h: Beh?
[22:08] <sinzui> jcsackett, mumble?
[22:09] <rick_h> StevenK: I can't translate beh
[22:10] <StevenK> rick_h: What do you need me to do?
[22:10] <rick_h> StevenK: just wondered if you can review that branch for me. You've done so much of the combo dir and such that you're best to sanity check I've caught all the places and the buidlout/etc should go together right?
[22:11] <StevenK> The source-deps change?
[22:12] <rick_h> StevenK: the lp branch for using lpjsmin (that depends on the source deps change)
[22:22] <lifeless> StevenK: whats the thing to setup combo ?
[22:22] <lifeless> (in an existing environment)
[22:22] <StevenK> lifeless: You should read the mail I sent about it
[22:23] <lifeless> StevenK: I should, but you're closer.
[22:23] <StevenK> lifeless: I am on the stand-up, so the mail will be quicker
[22:28] <rick_h> lifeless: make copy-apache-config install libapache2-mod-wsgi, and make jsbuild
[22:28] <rick_h> and set the FF
[22:29] <StevenK> No
[22:29] <rick_h> no?
[22:29] <StevenK> No.
[22:29] <rick_h> ok, nvm then. I'm recalling incorrectly
[22:30] <rick_h> ok, so make and not make jsbuild: https://pastebin.canonical.com/60685/
[22:31] <StevenK> And libapache2-mod-wsgi is not a make target
[22:31] <StevenK> And you need root for the first make
[22:31] <rick_h> sorry, that was a missing comma
[22:31] <rick_h> my bad, long day typo, please forgive :)
[22:32] <rick_h> ok, well lifeless there's the email in the pastebin. Sorry for leading astray.
[22:32] <lifeless> bah
[22:32] <lifeless> touch /var/tmp/bazaar.launchpad.dev/rewrite.log
[22:32] <lifeless> chmod 777 /var/tmp/bazaar.launchpad.dev/rewrite.log
[22:32] <lifeless> chmod: changing permissions of `/var/tmp/bazaar.launchpad.dev/rewrite.log': Operation not permitted
[22:34] <StevenK> Remove it
[22:36] <lifeless> StevenK: oh, I figured that was a bug so guarded it in the makefile
[22:38] <lifeless> StevenK: if [ -d /srv/launchpad.dev ]; then \
[22:38] <lifeless>                 ln -sfn /home/robertc/source/launchpad/lp-branches/working/build/js /srv/launchpad.dev/convoy; \
[22:38] <lifeless>         fi
[22:38] <lifeless> ln: creating symbolic link `/srv/launchpad.dev/convoy': Permission denied
[22:40] <StevenK> for j in be the for we will of ; do for i in $(bzr grep -l " $j $j ") ; do sed -e "s/\( $j \)$j /\1/" < $i | sponge $i ; done ; done
[22:40] <lifeless> WTF
[22:40] <StevenK> lifeless: /srv/launchpad.dev would have been created as root and then chowned to $SUDO_USER
[22:41] <StevenK> That was for sinzui's benefit
[22:41] <lifeless> ls -l /srv/launchpad.dev/ -d
[22:41] <lifeless> drwxr-xr-x 2 root root 4096 2012-02-21 22:31 /srv/launchpad.dev/
[22:42] <lifeless> echo $SUDO_USER
[22:42] <lifeless> (nothing)
[22:42] <StevenK> Oh, sorry, $SUDO_UID
[22:43] <lifeless> echo $SUDO_UID
[22:43] <lifeless> (nothing)
[22:43] <StevenK> It's an existing pattern in the Makefile
[22:43] <lifeless> that is, I'm ssh'd into my lxc container, I'm not root
[22:43] <lifeless> sudo should have no reason to be confused
[22:43] <lifeless> StevenK: so what should exist and what should it look like
[22:44] <StevenK> lifeless: It should be owned by your user
[22:45] <lifeless> ok, no errors now
[22:51] <StevenK> sinzui: https://code.launchpad.net/~stevenk/launchpad/double-word-death/+merge/94065
[22:59] <lifeless> ahahahahahahahaahahahah http://www.rabbitmq.com/memory.html
[22:59] <lifeless> and this is why appservers hung after rabbit saturated
[23:03] <sinzui> StevenK, while yuou are fixing spelling...https://bugs.launchpad.net/launchpad/+bug/931575
[23:03] <_mup_> Bug #931575: typo "There is no package name blah". <trivial> <ui> <Launchpad itself:Triaged> < https://launchpad.net/bugs/931575 >
[23:30] <wgrant> lifeless: You didn't actually approve.
[23:38] <wgrant> Blargh
[23:38] <wgrant> lifeless: It seems that mortals can't see the Ubuntu subscribe link still.
[23:38]  * wgrant links to the page directly.
[23:39] <wgrant> baaaaaah
[23:39] <wgrant> The form on +subscriptions doesn't have a team selector.
[23:40]  * wgrant gives up.