[00:00] <jelmer> argh, still a surprising amount of people registering imports of http://code.launchpad.net/ URLs
[00:00] <bigjools> damn, I need to procrastinate but I can't be bothered
[00:01] <wgrant> jelmer: Yeah, I'm not quite sure how we have so many terrible users :(
[00:01] <wgrant> bigjools: Enjoying the slow Internet access, at least? :)
[00:01] <StevenK> Haha
[00:01] <bigjools> wgrant: it's actually quite quick
[00:02] <bigjools> better b/w than I had back at my house in the UK
[00:02] <wgrant> Bandwidth-wise, sure :)
[00:02] <bigjools> latency not so good but I'm not that fussed
[00:02] <bigjools> LP is noticably slower to start loading pages
[00:02] <StevenK> Yes
[00:03] <jelmer> wgrant: I think our UI (at least this bit of it) is worse than our users :)
[00:04] <lifeless> wgrant: I think we should blame our users, en masse, last, not first, when there is a repeated issue.
[00:04] <lifeless> its much more likely that we are confusing them, than that they all arrive pre-confused.
[00:04] <wgrant> lifeless: Mmm, seeing some of the questions that come through...
[00:04] <wgrant> We have some preeeeetty moronic users.
[00:04] <lifeless> I have no doubt that there are some which get excruciatingly confused; so far down the learning curve its hard to show them that they have stuff to learn
[00:05] <lifeless> but still
[00:05] <wgrant> Now, the UI around all this abominable.
[00:05] <StevenK> Note how many recipes are against lp:launchpad/stable
[00:05] <wgrant> But some of the mistakes are so incomprehensible that it can only be explained by users being braindead.
[00:10] <lifeless> wgrant: I think you underestimate the confusion causable by poor UI
[00:12] <wgrant> Does anyone know what one does about whoopsie crash reports?
[00:12] <wgrant> It does the WER thing.
[00:12] <lifeless> chat to ev
[00:12] <wgrant> Of just submitting and then disappearing.
[00:12] <lifeless> its the new shiny
[00:12] <wgrant> So I can't track the progress of the X crash that I see hourly.
[00:41] <wgrant> https://lpstats.canonical.com/graphs/WildcherryCPU/20111106/20120307/ is pretty
[00:42] <wgrant> In 3 months wildcherry should have no load at all :)
[00:48] <lifeless> hah
[00:48] <lifeless> its dropped 15%
[00:48] <lifeless> which is substantial
[00:49] <wgrant> Another 7% will go once slony dies.
[00:51] <wgrant> Now, with a few fixes to the store selection code, we can sensibly have downtime on wildcherry without hardware upgrades :)
[00:52] <wgrant> Which means that once slony is gone we will never have any reason to have downtime ever again.
[00:53] <wgrant> (we might just have to pause write requests for a few seconds here and there)
[00:54] <lifeless> wgrant: and reads...
[00:54] <wgrant> Nah. We can do a rolling upgrade on the DB servers to avoid that.
[00:56] <wgrant> Pause replication, pause writes, switch to slave-only, upgrade master, switch to master-only, unpause writes, reattach slaves, wait for slaves to sync, switch to normal.
[00:56] <wgrant> s/reattach slaves/unpause replication/
[00:57] <lifeless> wgrant: we've had this talk before
[00:57] <lifeless> wgrant: I know you're convinced; I'm not
[00:57] <lifeless> wgrant: I'd like to make sure that we don't count on something that isn't (yet) known to work-or-not work : decide at the last possible moment
[00:57] <wgrant> I'm hoping one day I'll catch you over-tired and you'll be convinced too.
[00:58] <lifeless> we can talk on skype now if you want
[00:58] <lifeless> I'm certainly over-tired ATM
[00:58] <wgrant> Nah.
[00:58] <wgrant> This is still a while off :)
[00:58] <wgrant> Heh
[00:59] <lifeless> the fundamental issue I see is that we don't have a hard timeout on scripts yet, don't have the hard timeout <=5 seconds everywhere, and without both of those things, downtime will be faster overall.
[00:59] <wgrant> Also, pg9.1 has some pretty nice lock reductions which let fkey modifications etc only take out exclusive read locks.
[00:59] <wgrant> Er
[00:59] <wgrant> exclusive *write* locks
[00:59] <wgrant> So reads can continue while you're adding constraints.
[00:59] <wgrant> Which is interesting.
[01:00] <wgrant> Sutre, there are those issues.
[01:00] <wgrant> This is a future thing :)
[01:01] <wallyworld> StevenK: discovered the ff issue - not a real issue. there's a "legit" try/catch in the yui code to handle new vs legacy querySelector behaviour and it seems firebug had "break on exception" on (i didn't turn it on). you turn it off using the toolbar button in the console panel
[01:03] <StevenK> Right
[01:04] <wallyworld> the other thing is that sadly even with the new html5 browser behaviour to use lucid's webkit the yui tests still pass locally
[01:05] <StevenK> Run ec2 with -p?
[01:05] <wallyworld> -p does?
[01:05] <wgrant> Or ec2 demo, ssh in, and test manually?
[01:06] <wallyworld> might try that. will ec2 demo do all the setup that ec2 test does?
[01:06] <StevenK> -p is --postmortem
[01:06] <wgrant> Pretty much
[01:06] <wallyworld> with -p i have to wait for failure, right? whereas with ec2 demo i can get straight in and try stuff
[01:07] <StevenK> Right
[01:07] <wgrant> wallyworld: Want me to try them locally?
[01:07] <wallyworld> with the html5 browser, i had to move and egg from lp-source out of the way so it would use the system version
[01:08] <wgrant> I think I have YUITestLayer working now.
[01:08] <wgrant> In my container.
[01:08] <wallyworld> wgrant: that would be nice if you could
[01:09] <wallyworld> wgrant: you would need to pull pillar-access-service-infrastructure,  more-accesspolicy-service, more-accesspolicy-service-2, more-accesspolicy-service-3, more-accesspolicy-service-4
[01:09] <StevenK> Or just more-accesspolicy-service-4?
[01:09] <wallyworld> and then bin/test -vvct test_observertable
[01:09] <wallyworld> it's a pipe, so the previous ones are needed
[01:10] <wgrant> s/are/are not/
[01:10] <StevenK> Not if you've used bzr pump
[01:10] <wallyworld> which i have
[01:10] <wallyworld> didn't realise that
[01:10] <wgrant> Pipelines aren't magical.
[01:10] <wgrant> They're just a series of branches with a command to merge between them, basically.
[01:11] <wallyworld> right, i didn't appreciate/forgot that pump did the merge
[01:12] <StevenK> It does mulitple if you pump from the first pipe :-)
[01:14] <wallyworld> yeah. and i've had several conflicts to resolve doing that the past week or so
[01:14] <StevenK> Welcome to pipelines
[01:14] <wgrant> Ah
[01:14] <wgrant> The tests run better when the JS has been built, it turns out.
[01:15] <wallyworld> indeed
[01:15] <wgrant> There we go, errors.
[01:15] <wallyworld> that is a new thing due to the combo loader work
[01:15] <wallyworld> so wonder why it errors for you and not me
[01:15] <wallyworld> given we are both using the lucid webkit etc
[01:15] <wgrant> This is on lucid
[01:15] <wgrant> You're not using lucid webkit
[01:16] <wallyworld> wonder why your lxc seup worked then
[01:16] <wgrant> You're using a possibly old version of webkit that's in precise, but might not actually be old.
[01:17] <wallyworld> wgrant: did you run "sudo lxc-create -t ubuntu -n lpdev -f /etc/lxc/local.conf -- -r lucid -a i386 -b $username" ?
[01:17] <wgrant> Different name and different config file, but yes.
[01:17] <wgrant> lxc.network.type = veth
[01:17] <wgrant> lxc.network.link = lxcbr0
[01:17] <wgrant> lxc.network.flags = up
[01:17] <wgrant> Was the config I used
[01:18] <wgrant> Note that the bridge device should be lxcbr0 in precise, rather than virbr0 in earlier releases.
[01:18] <wallyworld> i used virbr0
[01:18] <wgrant> Should still work, if you have a virbr0
[01:18] <wallyworld> but my issue what the container wouldn't start
[01:18] <wgrant> But it's not created by default when you install lxc
[01:18] <wgrant> Oh?
[01:18] <wallyworld> it said could not mount rootfs
[01:19] <wallyworld> and then other error messages from there
[01:19] <wgrant> Tried disabling the apparmor profile?
[01:20] <wgrant> sudo ln -s /etc/apparmor.d/usr.bin.lxc-start /etc/apparmor.d/disable/; sudo apparmor_parser -R /etc/apparmor.d/usr.bin.lxc-start
[01:20] <wallyworld> i think i tried that. will try again
[01:20] <wallyworld> well fuck me, that worked
[01:21] <wallyworld> i will go add that to the wiki
[01:21] <wallyworld> thanks
[01:21] <wallyworld> wonder why apparmor doesn't like lxc
[01:22] <wgrant> Bug #925024
[01:22] <_mup_> Bug #925024: apparmor makes it impossible to install postgresql-common on Precise <apport-collected> <bot-stop-nagging> <kernel-request-3.2.0-13.22> <kernel-request-3.2.0-14.23> <precise> <rls-p-tracking> <running-unity> <linux (Ubuntu):Confirmed> <lxc (Ubuntu):Confirmed> < https://launchpad.net/bugs/925024 >
[01:22] <wgrant> It seems to be a kernel bug.
[01:22] <wgrant> AFAICT the rejected operations should be permitted.
[01:22] <wgrant> So possibly cgroups and LSM don't like each other very much.
[01:22] <wgrant> Again.
[01:22] <wgrant> wallyworld: Note that for html5-browser to work in the container it'll need an X server.
[01:23] <wgrant> So either ssh in with -X, or use xvfb-run
[01:23] <wallyworld> will try that, thanks
[01:23] <wallyworld> wgrant: do you use a separate source tree for lp? otherwise you need to make each time you switch using lxc to metal
[01:23] <wallyworld> due to python 2.6 vs 2.7 etc
[01:24] <wgrant> wallyworld: I don't run on metal.
[01:24] <wallyworld> ah, ok
[01:24] <wgrant> Interestingly, the rest of the workarounds on /Running/LXC seem to be unnecessary on precise.
[01:24] <wgrant> All I needed was to apt-get install lxc, disable the apparmor profile, lxc-create, and rocketfuel-setup
[01:25] <wallyworld> i find it too much of a pita to start/login to lxc so i stick to metal
[01:25] <wgrant> I have stuff in ~/bin to handle that.
[01:25] <wgrant> Just tiny shell scripts
[01:25] <wallyworld> still extra typing
[01:25] <wgrant> lp-start, lp-sh, lp-stop
[01:25] <wallyworld> i need to run rocketfuel with --no-workspace too
[01:25] <wgrant> lp-sh handles sshing in with -A -X, and changing to the right dir
[01:25] <wgrant> And lp-bounce restarts the appserver in the current directory.
[01:26] <wgrant> Reasonably smooth.
[01:26] <wallyworld> yes, doesn't wound too bad. you also need to hack postgres config too i think
[01:26] <wallyworld> if you run postgres outside the container
[01:26] <wgrant> They should be unrelated.
[01:27] <wgrant> Oh, you mean run the client outside the container?
[01:27] <wgrant> You could, but I just do it through SSH
[01:27] <wallyworld> you need to alter the config to allow "external" connections. well i did last time i tried lxc
[01:27] <wallyworld> ah yes, client outside container i think was it
[01:30] <lifeless> the main thing for me is editing hsots all the time
[01:30] <lifeless> drives batty me
[01:30] <wallyworld> my view is that using lxc just isn't worth the hassle, expecially when lp dev is painless on metal
[01:31] <wgrant> lifeless: Why do you have to edit it frequently?
[01:31] <wallyworld> i'm only using it to try and reproduce a ec2 test failure
[01:31] <wgrant> My dnsmasq tends to be good about reassigning the address like once every 6 months.
[01:31] <lifeless> wgrant: so my primary lxc is on my desktop (which has 8 cores and 16GB ram); it doesn't keep the same IP (which is being allocated from my LAN dhcp server)
[01:32] <wgrant> Ah
[01:32] <wgrant> lifeless: It has a static MAC...
[01:32] <lifeless> I haven't tracked down how it gets a 'hwaddr' for its 'ethernet'
[01:32] <lifeless> wgrant: it should, but ..
[01:33] <wgrant> $ grep hwaddr /var/lib/lxc/lplucid/config
[01:33] <wgrant> lxc.network.hwaddr= 00:16:3e:24:3f:3e
[01:33] <lifeless>  grep hwaddr /var/lib/lxc/lucid-test-lp/config
[01:33] <lifeless> robertc@lifeless-64:~$
[01:33] <wgrant> loloneiric?
[01:33] <lifeless> natty
[01:33] <lifeless> I think
[01:33] <lifeless> anyhoo
[01:33] <wgrant> Yeah
[01:33] <wgrant> precise is muuuuch nicer
[01:34] <lifeless> how does that interact with ephemeral
[01:34] <wgrant> No workarounds required.
[01:34] <wgrant> Good question.;
[01:34] <lifeless> (I'm on precise)
[01:45] <wgrant> lifeless: https://code.launchpad.net/~wgrant/launchpad/more-bug-heat-murder/+merge/96033
[01:56] <poolie> bigjools, thanks :), 'instant virgin' or 'comic sans'?
[01:57] <poolie> oh dev tips :)
[01:57] <wallyworld> wgrant: can you recall the command to recompile things like svn libs in sourcecode since my lxc is 32bit and host is 64bit and stuff won't run atm
[01:58] <lifeless> wallyworld: make clean; make
[01:58] <wgrant> wallyworld: make -C sourcecode clean all
[01:58] <poolie> sudo make shorter
[01:58] <wgrant> s/all/build/, maybe
[01:58] <wallyworld> lifeless: did make clean; make, will try what wgrant said
[01:59] <wallyworld> ah -C sourcecode does delete all the .so files
[01:59] <StevenK> wgrant: What's the ppad user?
[02:07] <wallyworld> wgrant: faaaaark. now bin/test -vvct test_observertable gives me a core dump
[02:08] <lifeless> quick reminder
[02:08] <lifeless> does the job runner switch db user?
[02:09] <lifeless> or do they all run as one megaar user ?
[02:23] <wgrant> StevenK: Ancient, from before ArchiveRework
[02:23] <wgrant> lifeless: It switches sometimes.
[02:23] <wgrant> wallyworld_: You're running with -X?
[02:23] <wgrant> wallyworld_: It'll segfault or abort if there's no X server.
[02:23] <wallyworld_> wgrant: ah ffs. forgot that. thanks
[02:24] <wallyworld_> wgrant: i was recalling how previously we had issues running a 32 bit lxc container on a 64 bit host and there were seg faults
[02:24] <wgrant> wallyworld_: That's what I'm doing.
[02:24] <wgrant> Always have done.
[02:24] <wallyworld_> there were segfaults mid last year
[02:25] <wallyworld_> and curtis had to add changes to html5 browser
[02:25] <wgrant> Oh, for html5-browser
[02:25] <wallyworld_> strangely, some of the yui tests passed without X
[02:25] <wgrant> I've never really used it.
[02:25] <wallyworld_> wgrant: that's what's used to drive the yui tests
[02:25] <wgrant> I know.
[02:25] <wgrant> I hadn't run them before today.
[02:25] <wallyworld_> ah ok
[02:34]  * wallyworld_ sees a pommy git ^H^H^H^H^H bigjools arriving at his house to use the printer
[02:35] <wgrant> Heh
[02:35] <nigelb> haha
[02:35] <wgrant> lifeless: I suspect this branch will fail ec2.
[02:36] <wgrant> lifeless: Because person merge will still want to talk to the table.
[02:36] <wgrant> It should really have landed with the patch, to db-devel.
[02:36] <wgrant> But we'll see.
[02:39] <lifeless> should be able to drop bugjob tonight no ?
[02:39] <wgrant> Might *just* be in db-stable in time.
[02:39] <wgrant> Or did it make it through before the devel failure?
[02:39] <lifeless> enoidea
[02:41] <wgrant> It's been in db-stable for about 20 minutes.
[02:41] <wgrant> Er
[02:41] <wgrant> s/db-//
[02:41] <wgrant> So it will be in db-stable in about 6.5 hours
[02:41] <wgrant> So it's probably going to be tomorrow.
[02:41] <wgrant> Unless we violate the usually procedures and do the db-deploy from stable
[02:49] <lifeless> wgrant: whats the new shiny for db user switching ?
[02:51] <lifeless> StevenK: have you landed your enterprise id helper yet ?
[02:53] <wallyworld_> I'd just like to say that bigjools is awesome
[02:53]  * wallyworld_ decides to locks his screen next time he makes that pommy git a coffee
[02:56] <wgrant> lifeless: see lib/lp/testing/dbuser.py
[02:56] <wgrant> with dbuser('foo')
[02:56] <wgrant> Or with lp_dbuser()
[02:56] <wgrant> Or switch_dbuser('foo') if you hate life and context managers.
[02:57] <wgrant> lifeless: Unless you want to do it in production code, in which case you're approaching things the wrong way.
[02:58] <lifeless> nah, just writing smoke tests
[02:58] <lifeless> and oot of practice
=== mwhudson_ is now known as mwhudson
[03:13] <StevenK> lifeless: Playing in ec2 last I checked
[03:13] <StevenK> add-enterpriseid => devel                 [OK]       (up for 4:31:32) i-dbc91abf
[03:13] <StevenK> So, 30 minutes ago? :-P
[03:16] <StevenK> lifeless: Just landed. r14907
[03:40] <sinzui> wallyworld_, have you made progress? Is there a firefox defect in Lp's javascript?
[03:41] <wallyworld_> sinzui: html-browser still worked fine on precise with the older webkit, but i did get lxc working - needed to disable apparmor
[03:41] <StevenK> sinzui: Based on my investigation, public bugs with private branches work fine, and that bug can be closed.
[03:42] <wallyworld_> sinzui: the issue is that a Y.one() call is returning null when it shouldn't - i have printed the innerHTML and the requested node is there
[03:42] <sinzui> StevenK, really? okay
[03:42] <StevenK> sinzui: It worked for me on .dev, if you have a few minutes we can try it on prod
[03:43] <wallyworld_> sinzui: the one issue i can see is that there is an <img blah blah> with no closing tag within the <span> that is being selected and not returned
[03:43] <sinzui> wallyworld_, are events involved...is the node not there *yet*, but is byt the time print happens
[03:43] <sinzui> StevenK, sure
[03:43] <sinzui> wallyworld_, !
[03:44] <wallyworld_> sinzui: but the mustache template uses "<img blah />" and we do that same thing in lots of other places. using "<img blah></img>" makes no difference
[03:44] <StevenK> sinzui: Do you have a private branch that you can see and I can't?
[03:44] <sinzui> wallyworld_, invalid HTML does indeed lead to unpredictable DOM traversal
[03:45] <sinzui> wallyworld_, "<img blah></img> really is invalid and a *HTML* parser will throw a wobbly
[03:45] <wallyworld_> sinzui: weird thing - using "<img blah></img>" and logging innerHTML still prints "<img blah>" with no closing tag
[03:45] <sinzui> and <img ...> will also throw the *HTML* parser for a wobbly if the page claims it is xhtml
[03:45] <wallyworld_> so it should be <img blah /> ?
[03:46] <sinzui> wallyworld_, do not assume that the thing printing is the thing interpreting
[03:46] <wallyworld_> what's the correct syntax for img ?
[03:46] <sinzui> that is how lots of fucked up markup is introduced
[03:46] <sinzui> wallyworld_, we state we serve xhtml, the tag is a self-closing empty tag
[03:47] <wallyworld_> sinzui: like "<img blah />"? that's what's in the mustache template
[03:47] <sinzui> wallyworld_, yes
[03:47] <wallyworld_> but print innerHTML is leaving out the closing tag
[03:48] <wallyworld_> which i was thinking was the issue
[03:48] <wallyworld_> but is not
[03:48] <sinzui> wallyworld_, yes because that method is 1, not in any standards
[03:48] <sinzui> and 2 it predated xhtml by 3 years
[03:48] <wallyworld_> so it still makes no sense why the Y.one() is failing on lucid
[03:49] <wgrant> wallyworld_: What is the precise text of the template?
[03:51] <wallyworld_> wgrant: https://pastebin.canonical.com/61669/
[03:52] <wgrant> Is that valid?
[03:52] <wgrant> An img with no src?
[03:52] <sinzui> wgrant, I think you have a point
[03:53] <wgrant> You might mean <a href="#" class="editicon sprite edit">&nbsp;</a> or so
[03:53] <wgrant> I'm not sure what the usual pattern is.
[03:53] <wgrant> Since there's like 4 different ways to do it in the codebase already.
[03:53] <wgrant> Let's throw in a couple more :)
[03:54] <wallyworld_> wgrant: sinzui: got it working. used Y.one("[id=xxxx]") syntax
[03:54] <wallyworld_> instead of "#xxx"
[03:54] <wgrant> Still, not valid HTML
[03:54] <sinzui> wgrant, close enough. We use hidden text for TestBrowser, which will never see this anyway
[03:54] <bigjools> wallyworld_: I smell of Baldrick
[03:54] <wgrant>   src         %URI;          #REQUIRED -- URI of image to embed --
[03:54] <wgrant> QED
[03:54] <wallyworld_> bigjools: too much info
[03:55] <wallyworld_> wgrant: here there is no src, it's a sprite
[03:55] <sinzui> wallyworld_, I think that means an invalid id was generated. does it have dots in it
[03:55] <wgrant> wallyworld_: Then it's not an img
[03:55] <bigjools> wallyworld_: enjoying the pommy weather?
[03:55] <sinzui> or was it a duplicate...which is also invalid
[03:55] <wallyworld_> sinzui: nope, otherwise i would not haves used #
[03:55] <wallyworld_> not a dupe either
[03:56] <wallyworld_> bigjools: no
[03:56] <bigjools> wallyworld_: bwahaha :)
[03:56] <bigjools> wallyworld_: anyway strictly speaking, you're the pohm
[03:56] <wgrant> http://www.w3.org/TR/xhtml1/dtds.html#dtdentry_xhtml1-strict.dtd_img agrees
[03:56] <wgrant> So both XHTML1(.1) and HTML4.01 hate you
[03:57] <wallyworld_> wgrant: i see where i fucked up - i don't need the img
[03:57] <wallyworld_> i just needed to add class = "sprite edit" to the anchor
[03:58] <wgrant> Yeah, and probably an nbsp or similar inside it
[03:58] <wgrant> Otherwise it can end up zero-width
[03:58] <sinzui> wallyworld_, correct. we use sprites on other elements to avoid the img element
[03:58] <wgrant> Which isn't awesome for displaying bgimages.
[03:58] <sinzui> we do not want to tempt the browser to download
[03:58] <wallyworld_> sinzui: so webkit on precise must be more forgiving
[03:59] <wgrant> We've had problems like that before, yeah.
[03:59] <wgrant> Some old Firefoxes don't like self-closing <div>s, for example.
[03:59] <sinzui> wallyworld_, yes. the newer lib emulates the behaviours of gecko and trident better
[04:00] <wallyworld_> sinzui: i started out using img with src='@@/edit' or whatever and when i decided to use sprites instead messed up the conversion
[04:00] <sinzui> yes, a div is not allowed to be empty. the same is true for <p>
[04:00] <wgrant> Ah
[04:00] <wgrant> Easily fixed :)
[04:00] <wallyworld_> sinzui: there should be a strict xhtml or fail mode on the newer libs
[04:01] <sinzui> wallyworld_, that is from 2009. by 2010 we were supposed to stop using @@/ urls because they waste resources
[04:01] <wallyworld_> sinzui: yeah, i copied from elsewhere and realised sprites were preferred and messed up the fix
[04:01] <sinzui> wallyworld_, lots of old code still uses the spectacles/testicles style
[04:02] <sinzui> wallyworld_, IE 9 actually has a instruction to tell it not to fallback. ...do xhtml or html5 or die trying
[04:03] <wallyworld_> sinzui: i'm still perplexed at the behaviour - Y.one('#xxx') fails, Y.one('[id=xxx]') works, and in both cases, the offending <img> is well inside the containing element being selected
[04:03] <wgrant> You're invoking undefined behaviour.
[04:03] <wgrant> Of course it's perplexing :)
[04:04] <wallyworld_> sinzui: so no webkit library strict xhtml switch ?
[04:04] <sinzui> wallyworld_, The fact is some many people never learn the standards, that all the engines are written in a try/except pattern. Try to do the doc type. on exception slow down, choose to re-write the dom to be valid, or fallback to quirksmode
[04:04] <wgrant> wallyworld_: Serving as application/xhtml+xml will cause Gecko and WebKit to parse it as XML
[04:04] <wgrant> IE9 too
[04:05] <wgrant> But we can't do it, because Microsoft are fucktards and didn't support it until IE9
[04:05] <wallyworld_> sinzui: also, i hacked in hide_console_messages=False to see the logged output
[04:05] <wallyworld_> i think that's what you were going to put back in as a cmd line switch?
[04:06] <wallyworld_> wgrant: i was meaning xhtml for running the tests
[04:06] <sinzui> wallyworld_, I don't see anything wrong with id="P1-permission"
[04:07] <sinzui> Maybe we need to look at the whole file to see if something interfered with the block under test
[04:07] <wallyworld_> sinzui: me either. but since the <span> contains that invalid <img> it must bark
[04:07] <wallyworld_> barf
[04:08] <sinzui> wallyworld_, this test is from your 3rd branch right?
[04:08] <wallyworld_> sinzui: yes
[04:09] <wgrant> -4
[04:09] <wallyworld_> -3
[04:09] <wallyworld_> or -4
[04:09] <wallyworld_> introduced in -3
[04:09] <wgrant> Ah
[04:09] <wgrant> The test results were from -4
[04:09] <wallyworld_> wgrant: that's the one i was landing
[04:09] <wallyworld_> wgrant:  sinzui: but fixing the <img> still fails when i used Y.one('#xxx')
[04:10] <wallyworld_> s/fixing/deleting
[04:10] <wgrant> :(
[04:11] <wgrant> While it didn't make much sense that that would cause the problem, I had hoped the layout engine was retaliating to discourage people from writing blatantly invalid markup.
[04:11] <wallyworld_> but Y.one('[id=xxx]') works
[04:11] <sinzui> wallyworld_,  Can you convince the console to print everything in the body?
[04:11] <wallyworld_> sinzui: yes, believe so. let me do that
[04:12] <wgrant> the fuck
[04:12] <wgrant> Line 47 of base-layout.pt
[04:12]  * wgrant deletes
[04:13] <wallyworld_> sinzui: ah, ffs. i know why i left the img in there. lazr ChoiceSource requires an editcon img node
[04:13] <wallyworld_> i will have to look at the ChoiceSource src code to see if there's a way around that
[04:14] <sinzui> see, we wrote a lib that requires us to screw with things
[04:15] <wallyworld_> sinzui: so rather than go back to using <img src='@@/edit'/> i'll fix ChoiceSource or figure out how to call it differently
[04:15] <sinzui> wgrant, stab away
[04:15] <wallyworld_> i may just be able to pass in the anchor
[04:15] <wgrant> wallyworld_: Then we can fix the inline bug modifying stuff to not be terrible :)
[04:15] <wgrant> Currently the edit icon loads late
[04:15] <wgrant> Because it's not a sprite
[04:15] <wallyworld_> yeah :-(
[04:16] <wallyworld_> well, what a frustrating day or so
[04:16] <sinzui> wallyworld_, the image is secondary to the id-lookup-fail
[04:16] <wallyworld_> sinzui: ok, will get print the body, just a sec
[04:20] <wallyworld_> sinzui: https://pastebin.canonical.com/61671/
[04:21] <wallyworld_> let's see if it looks valid
[04:21] <sinzui> wallyworld_, looking at the source _observer_policy_template may be creating duplicate ids if there is more than one user
[04:22] <wallyworld_> sinzui: you may be correct there - this is in the li elements
[04:23] <wallyworld_> sinzui: and indeed, in the test, data for 2 users is rendered
[04:24] <sinzui> yep
[04:24] <sinzui> the ids are reused
[04:24] <sinzui> they MUST fail since they are invalid
[04:26] <wallyworld_> sinzui: scary that it passes on precise
[04:26] <sinzui> wallyworld_, I declare shenanigans. I see some of the test already looks up id as a normal attr. I think only the first id in the tree is returned
[04:27] <sinzui> or in the case of a tree fragement, only the child matches
[04:28] <wallyworld_> sinzui: all but one of those test lookups do lookup unique ids
[04:28] <wallyworld_> so should be changed to #
[04:28] <sinzui> I see this is common practice in out code too because zope is putting dots in our ids :(
[04:28] <wallyworld_> yes :-(
[04:29] <sinzui> wallyworld_, we do want to it be #, but we need to add the user to the id's string as was done with remove
[04:29] <wallyworld_> sinzui: the other workaround used is to Y.DOM.xxx
[04:29] <wallyworld_> yes, i need to fix the template
[04:33] <wallyworld_> sinzui: my point about it being scary that the tests pass on precise still stands though. we should see if something can be done
[04:34] <sinzui> wallyworld_, I am looking at http://webkitgtk.org/reference/index.html right now
[04:35] <wallyworld_> ok ;-). and i'm figuring out how to adjust my use of partials to get the required data available for the template to use
[04:35] <sinzui> I do not see a strict flag to ensure the test dies
[04:35] <wallyworld_> that is unfortunate
[04:35] <sinzui> wallyworld_, !
[04:35] <wallyworld_> ?
[04:35] <sinzui> wallyworld_, your test html does not claim to be xhtml strict
[04:36] <sinzui> wallyworld_, set this as the first two declarations
[04:36] <sinzui> <?xml version="1.0" encoding="UTF-8"?>
[04:36] <sinzui> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
[04:36] <wallyworld_> in the test harness html?
[04:36] <sinzui> change transitional to strict
[04:37] <sinzui> yes
[04:37] <sinzui> That will change how any browser written in the last 5 years interprets the content
[04:37] <wgrant> We should really be polyglot (X)HTML5 with a doctype of <!DOCTYPE html>
[04:38] <wallyworld_> sinzui: test_observertable.html has:
[04:38] <wallyworld_> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
[04:38] <wallyworld_>   "http://www.w3.org/TR/html4/strict.dtd">
[04:38] <wgrant> lolwut?
[04:38] <wgrant> Launchpad has *never* been HTML 4.01
[04:38] <wgrant> It's had a doctype of XHTML 1.0 Transitional from the very start.
[04:38] <StevenK> % bzr grep Transitional | grep -c 4.01
[04:38] <StevenK> 6
[04:39] <sinzui> wgrant, I was thinking about that last week. I suspect there will be some oddness that we need to test to ensure we do not gt stung. such as our ids
[04:39] <StevenK> lib/lp/registry/help/sharing.html:<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
[04:40]  * wgrant blames wallyworld and jcsackett for living in the 1990s :)
[04:40] <sinzui> wgrant, We tried html5 in the 2.0 design. IE hated it. we know know it is trivial to make it accept it
[04:40] <wgrant> sinzui: Well, AIUI IE6 is now dead to us.
[04:41] <wallyworld_> sinzui: given test_observertable.html appears correct, i'm not sure what else i should be changing
[04:41] <wgrant> IE7 and IE8 still only have HTML4.01 parsers, with no HTML5 or XHTML, but they should cope better.
[04:41] <sinzui> Ie 7 and 8 need a js initiate dom check to reenable css after it encounters html 5
[04:42] <StevenK> wgrant: I didn't think we could declare IE6 support dead?
[04:43] <wgrant> IE6 is more than 10 years old.
[04:43] <wgrant> Even if there's a good reason to support it, there's no good reason to support it.
[04:43] <sinzui> Like Jimmy Hoffa and Elvis, we do not need to declare them dead. They are dead, and we will ignore them
[04:44] <wgrant> Now, Microsoft continues to fuck the world over by preventing IE9 from running on Windows XP. But at least declaring IE6 and potentially IE7 dead gives us *some* freedom.
[04:44] <sinzui> regardless, the js-dom-creation hack works in IE 6 and restores CSS after the html5 element is encountered
[04:45] <sinzui> or at least say, you must try another OS, how about Ubuntu
=== jtv1 is now known as jtv
[04:46] <StevenK> sinzui: Are you undistracted now? :-)
[04:46] <sinzui> yes
[04:47] <StevenK> sinzui: Do you have a private branch on prod that you can see, but I can't?
[04:47] <sinzui> maybe
[04:49] <sinzui> StevenK, what bug do you want me to link it too?
[04:51] <StevenK> sinzui: https://bugs.launchpad.net/moblin-multimedia/+bug/221429 ?
[04:51] <_mup_> Bug #221429: moblin media fails to launch <intel> <acton:Invalid> <Moblin Applets:Invalid> <Moblin Multimedia:In Progress by prajwal-linux> <Ubuntu Mobile Edition:Fix Released> < https://launchpad.net/bugs/221429 >
[04:51] <sinzui> linked
[04:52] <sinzui> StevenK, can you still see the bug?
[04:52] <StevenK> sinzui: Looks good to me. No Linked branches.
[04:52] <StevenK> sinzui: Can you see the branch linked?
[04:52] <sinzui> fab. This tested private team and private branch
[04:53] <sinzui> I removed the link
[04:54] <StevenK> Oh, wait, it's talking about a different page
[04:54] <sinzui> is this a doh moment
[04:54] <sinzui> ?
[04:54] <StevenK> No, I'm wrong, the user says he can't see a bug page linked from +assigned-bugs
[04:55] <StevenK> So it is IBugTask:+index that is implicated.
[04:55] <sinzui> StevenK, that is still the bug page
[04:55] <StevenK> sinzui: I'll comment and mark it fix released, do you want me to just archive the card?
[04:55] <sinzui> yes. We did time on it
[04:56] <StevenK> sinzui: Plan to tackle 933759 for the rest of the day
[04:56] <StevenK> Sigh. bug 933759
[04:56] <_mup_> Bug #933759: Added information_visibility_policy to bug and branch <branches> <bugs> <disclosure> <Launchpad itself:Triaged> < https://launchpad.net/bugs/933759 >
[04:57] <StevenK> I just wrote 2 garbo jobs, what's one/two more
[04:57] <sinzui> Have fun storming the castle. I plan to take a Cadbury chocolate bar for the rest of my day
[04:57] <StevenK> I suppose it requires a DB patch first
[05:30] <StevenK> wallyworld_: Has your enum landed? If so, what is it called?
[05:33] <StevenK> Oh, duh, it's AccessPolicyType
[05:33] <StevenK> Does that mean bug 933759 is out of date and the column on bug and branch should be named differently?
[05:33] <_mup_> Bug #933759: Added information_visibility_policy to bug and branch <branches> <bugs> <disclosure> <Launchpad itself:Triaged> < https://launchpad.net/bugs/933759 >
[05:40] <lifeless> StevenK: cool
[05:57] <StevenK> wgrant: Am I right? I should be adding an accesspolicy column to bug and branch?
[05:58] <StevenK> lifeless: Can you untestable or something r14902?
[06:00] <wgrant> StevenK: Not accesspolicy
[06:00] <wgrant> Potentially accesspolicytype
[06:01] <StevenK> wgrant: A shorter form of what sinzui suggested is information_visibility, but the enum is AccessPolicyType.
[06:01] <StevenK> Perhaps visibility_policy
[06:01] <wgrant> It is complicated.
[06:01] <wgrant> Because there are public bits in AccessPolicyType
[06:01] <wgrant> Which I had not envisioned.
[06:02] <huwshimi> wgrant, wallyworld_: In a private project isn't everything Proprietary data?
[06:02] <wgrant> huwshimi: It should be, yes.
[06:02] <huwshimi> wgrant: Do you have the option for anything else?
[06:03] <wgrant> I'd hope not.
[06:03] <wgrant> Potentially you could argue that userdata and embargoedsecurity could exist in a private project.
[06:03] <wgrant> But I don't believe we've been asked to do that.
[06:03] <huwshimi> wgrant: and some public projects can have some Proprietary data?
[06:03] <wgrant> All three can exist in a public project with optional proprietary bugs.
[06:04] <huwshimi> wgrant: Gotcha
[06:06] <huwshimi> wgrant: Thanks for that
=== almaisan-away is now known as al-maisan
=== al-maisan is now known as almaisan-away
[07:09] <wallyworld_> wgrant: I am adding a mthod to IAccessPolicyGrantSource....
[07:09] <wallyworld_>     def delete(grants):
[07:09] <wallyworld_>         """Delete the specified grants.
[07:09] <wallyworld_>         :param grants: a collection of (`IAccessPolicy`, grantee `IPerson`)
[07:09] <wallyworld_>             pairs.
[07:09] <wallyworld_>         """
[07:09] <wallyworld_> that ok with you?
[07:09] <wallyworld_> i need it for the +sharing page
[07:11] <wallyworld_> wgrant: also, have you considered using named tuples for the various parameters and return types?
[07:12] <wgrant> wallyworld_: s/delete/revoke/
[07:12] <wallyworld_> ok
[07:12] <wgrant> wallyworld_: I avoided namedtuples because they're not very JSON-friendly.
[07:13] <wallyworld_> i thought there would be support for them
[07:13] <wallyworld_> seems like an expected thing to have
[07:13] <wallyworld_> but maybe not
[07:14] <wgrant> Why would you expect that?
[07:14] <wgrant> They're a native feature in just about 0 languages.
[07:14] <wgrant> They're an awkward hybrid of a map and a list.
[07:14] <wgrant> Which has very little reason to exist.
[07:15] <wallyworld_> they are implemented under the covers like a normal tuple
[07:15] <wgrant> Sure.
[07:16] <wallyworld_> so i thought the generated implementation might have something
[07:16] <wgrant> But you can't represent a namedtuple in JSON.
[07:16] <wallyworld_> since it would be such a common requirement
[07:16] <wgrant> Heh, common?
[07:16] <wgrant> There's no sensible way to represent a namedtuple in JSON, so it's unlikely that people would do it...
[07:16] <wallyworld_> but you can represrnt a dict in json which a named tuple can be mapped to i think
[07:17] <wgrant> No.
[07:17] <wgrant> namedtuples have order
[07:17] <wgrant> You could map a namedtuple to a dict.
[07:17] <wgrant> But you can't round-trip through a sensible JSON representation.
[07:17] <wallyworld_> sure, but the order could be encoded in the json
[07:18] <wgrant> How?
[07:18] <wgrant> Make JSON map definitions order-sensitive?
[07:18] <wallyworld_> as a list of names
[07:18] <wallyworld_> for example
[07:18] <wallyworld_> it would just need serial/deserialisation on the named tuple generation
[07:18] <wallyworld_> s/generattion/generated class
[07:19] <wgrant> You can't deserialise.
[07:19] <wgrant> Because you don't know what namedtuple to deserialise to.
[07:19] <wallyworld_> you'd encode that as well
[07:19] <wallyworld_> i used to do this sort of thing in java all the time
[07:19] <wgrant> Adding namedtuples to JSON would provide very minimal benefit for large additional complexity.
[07:20] <wallyworld_> surely pythin can support similar pluggable serialisation mechanisms
[07:20] <wgrant> Sure.
[07:20] <wgrant> But this isn't Enterprise Java XML SOAP Beans EE2 7.5
[07:20] <wallyworld_> anyways, it's more of a pub discussion :-)
[07:20] <wgrant> This is JSON
[07:20] <wgrant> It's simple.
[07:21] <bigjools> awesome - bugs.kde.org changed its design and now the crash reporting assistant fails to work...!
[07:21] <wallyworld_> it can be done simply in java, without any "enterprise" stuff, it's supported by the langiage
[07:21] <wgrant> wallyworld_: It's not supported by the format.
[07:21] <wallyworld_> bigjools: what, bugs in kde? surely not?
[07:21] <bigjools> wallyworld_: shocking I know
[07:21] <wgrant> wallyworld_: And I would damn well hope it's not supported by the language.
[07:21] <wgrant> By parts of the (potentially standard) libraries, perhaps.
[07:22] <wallyworld_> wgrant: what's so bad about pluggable serialisation?
[07:22] <wgrant> Nothing, but serialisation doesn't belong in the core language :)
[07:23] <wallyworld_> the language sh/could support mechanisms to add it
[07:23] <wallyworld_> easily
[07:23] <wallyworld_> via libraries available at runtime
[07:24] <wgrant> Anyway, there's no reason to serialise namedtuples to JSON.
[07:25] <wallyworld_> don't agree, but doesn't matter
[07:26] <wallyworld_> wgrant: another question - why in the impl for IAccessPolicyGrantSouuce call AccessPolicyGrant?
[07:26] <wallyworld_> and not AccessPolicyGrantSource?
[07:26] <wgrant> eparse
[07:26] <wallyworld_> the implementing class
[07:26] <wgrant> Oh, s/in/is/?
[07:26] <wallyworld_> is
[07:26] <wallyworld_> sorry, tying
[07:26] <wallyworld_> typing
[07:26] <wallyworld_> arrgh
[07:27] <wgrant> It's one of the two major conventions we have.
[07:27] <wgrant> Either you have Foo implementing IFoo, and FooSet implement IFooSet
[07:27] <wgrant> Or you have Foo implementing IFoo, and class methods implementing IFooSource
[07:27] <wgrant> That was used a bit more in code
[07:27] <wgrant> s/code/Code/
[07:28] <wgrant> Well, I guess technically Foo implements IFoo, and provides IFooSource.
[07:28] <wallyworld_> hmm. ok. i find that latter convention "interesting"
[07:29] <wgrant> Most of Launchpad is "interesting"
[07:29] <wallyworld_> lol
[07:31]  * wallyworld_ pauses new AccessPolicyGrant method implementation - off to have dinner with bigjools. he is even older today
[07:31] <bigjools> wallyworld_: where's my birthday pizza you aussie git?
[07:31] <wallyworld_> i am leaving to pick it up now you pommy whinger
[07:32] <StevenK> Haha
[07:32]  * bigjools hears aussies whinging
=== jtv1 is now known as jtv
[07:49] <wgrant> Ha ha hgwefwhui
[07:50] <wgrant> So it turns out that some of our pagetests only work because our HTML is invalid, preventing some directives from being parsed.
[07:50] <wgrant> eg. zope.testbrowser follows http-equiv refresh
[07:51] <wgrant> But currently they have an illegal <noscript> element before them.
[07:51] <wgrant> So mechanize doesn't see them.
[07:58] <bigjools> heh
[08:55] <adeuring> good morning
[09:02]  * StevenK stabs kanban
[09:05] <czajkowski> Good morning
[10:07] <wgrant> jelmer: https://code.launchpad.net/~elementary-os/+recipe/elementary-os-qt4-x11-patch dies with a bzr MemoryError... do you want a bug?
[10:07] <wgrant> Using 800MB so far in my test.
[10:11] <jelmer> wgrant: yes, please
[10:11] <jelmer> wgrant: any idea what's so particularly big about the branches in that recipe?
[10:12] <wgrant> jelmer: Qt :)
[10:12] <wgrant> Wow
[10:12] <wgrant> 5.4GB so far in bzr's progress meter
[10:12] <wgrant> over HTTP
[10:12] <wgrant> 431MB on disk so far
[10:12] <jelmer> urgh
[10:13] <wgrant> Up to 1GB resident
[10:13] <jelmer> that is one ginormous branch
=== gmb changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: gmb | Firefighting: - | Critical bugtasks: 4*10
[11:11] <StevenK> gmb: Ah ha, so evil BT managed to fix their crap.
[11:13] <gmb> StevenK, Wasn't their fault, as it happens; some electronics needed replacing at the exchange. I guess it's the telecoms equivalent of a NIC burning out.
[11:13] <gmb> They fixed it pretty quickly.
[11:14] <gmb> Oh, wow. I've been given a £0.01 refund on the Game of Thrones DVD set. Thanks Amazon, I'll try not to spend it all at once...
[11:14] <StevenK> gmb: Telstra here don't tend to admit that here. "Oh, it's affecting ... some other people. Which may or may not be geographically close to you."
[11:15] <gmb> StevenK, Ah, we're a small enough community for them not to be able to get away with that. Also, there's an engineer living in the village, so breakages tend to affect him, too.
[11:15] <StevenK> Heh
[11:16] <StevenK> The last time I can remember Telstra pulling that crap was when one of their conduits wasn't properly closed in. So within about five minutes of it raining, bang, DSL drops.
[11:16] <gmb> Nice
[11:17] <StevenK> With some bullying on my part I got the nice girl to admit that it was impacting ~ 200 people which is why it got fixed in 3 hours instead of 3 days.
[11:42] <StevenK> salgado! Why is workitems run from frequently? :-(
[11:43] <salgado> StevenK, because it's low-overhead
[11:43] <salgado> is it causing problems?
[11:44] <StevenK> It shouldn't be frequently, there is absolutely no need for it
[12:08] <salgado> StevenK, it's important to have it run frequently because then it will kick in as soon as we switch it on in production, thus reducing the time window where we have the new UI but not all work items migrated
[12:09] <StevenK> salgado: Utterly pointless. You are not going to lose much by using hourly, and even so, you can make sure the workitems are migrated before switching the UI on.
[12:09] <salgado> StevenK, I don't want to do the migration before the UI is live, for obvious reasons
[12:10] <StevenK> salgado: Frequently is used for things that will cause production issues if it lags, like OpenID gardening and so on. I am distinctly uncomfortable with it being in frequently
[12:12] <salgado> StevenK, that's not what the docstring says
[12:12] <StevenK> That was the entire reason it was added by stub.
[12:13] <StevenK> But, whatever, I'm tired of arguring.
=== matsubara-afk is now known as matsubara
[13:03] <jelmer> wgrant: did you end up filing a bug for that qt branch?
[13:47] <stub> salgado, StevenK: We have started moving stuff with low setup costs into frequently because the load gets distributed better (a small bit of work every 5 minutes vs. a larger chunk of work every hour). But things are trivial to shuffle between daily/hourly/frequently if one of them gets overfull or 'low overhead' turns out to be not so low.
[14:11] <deryck> Morning, all.
[14:12] <deryck> abentley, adeuring -- let's hold standup for 30 minutes past normal time.  so 15:00 UTC.
[14:12] <adeuring> deryck: ok
[14:12] <abentley> deryck: okay.
[14:12] <deryck> abentley, adeuring -- I have sick kids again. :(  And their aunt is coming for them at normal standup time.
[14:13] <abentley> deryck: That's too bad.
[14:14] <deryck> yeah, it's like we're on a flu/cold loop at my house.
[14:19] <sinzui> abentley, I restored my patch the bzr-pqm because ec2 land failed: https://bugs.launchpad.net/bzr-pqm/+bug/922741
[14:19] <_mup_> Bug #922741: AttributeError: 'BzrBranch7' object has no attribute 'get_config_stack' <amd64> <apport-bug> <patch> <precise> <running-unity> <Bazaar PQM Plugin:New> < https://launchpad.net/bugs/922741 >
[14:20] <sinzui> abentley, do you want me to retarget the bug to lp-dev-utils?
[14:20] <abentley> sinzui: did it fail locally?
[14:21] <sinzui> abentley, I don't understand
[14:21] <abentley> sinzui: Yesterday you tried it on your local machine and said it was fine.  I don't understand what's changed.
[14:21] <sinzui> abentley, I used bzr pqm-submit yesterday
[14:21] <sinzui> today I used ec2 land
[14:22] <abentley> sinzui: did you use the lp-dev-tools version of ec2 land?
[14:22] <sinzui> no I  used the one in the Lp tree
[14:23] <abentley> sinzui: I would be very surprised if the lp-dev-tools version was affected.
[14:24] <sinzui> I will revert and do it again
[14:26] <abentley> sinzui: because the problem with the launchpad-tree version is that it's using a beta version of 2.5.  The lp-dev-tools version will use your system bzr, and any non-beta bzr should work with it.
[14:30] <sinzui> abentley, I see you are correct
[14:30] <sinzui> I am now marking that bug invalid
[14:31] <abentley> sinzui: Or maybe affects: launchpad.
[14:31] <sinzui> Didn't you commit to removing the ec2 from Lp's tree
=== almaisan-away is now known as al-maisan
[14:33] <abentley> sinzui: Yes, but it may not be for a day or so, because I want to get a suitable version of bzr-pqm in the PPA.
[14:34]  * sinzui nods
[14:37] <abentley> sinzui: My plan to copy the package has been thwarted because only the Precise package built successfully.
[14:37] <sinzui> abentley, good enough for me
[14:38] <sinzui> abentley, Ubuntu is in beta...Lp engineers are supposed to be on Precise now
[14:39] <deryck> grrr, my home internet provider hates me some days.
[14:39] <abentley> sinzui: true.  Maybe that's good enough.
[14:40] <sinzui> abentley, stevenk deleted packages for unsupported series. I imagine he is already eyeing oneiric
[14:41]  * deryck is waiting on the new laptop to upgrade
[14:42] <sinzui> what are you getting? Are you joining the SSD party
[14:43] <abentley> sinzui: I believe deryck's getting a System76 with an SSD.
=== deryck_ is now known as deryck
[14:43] <salgado> danhg, hey there.  was wondering if you'd have some time to chat about the results of the user testing with those two new LP pages?
[14:43] <czajkowski> system 76 do nice machines alright
[14:44] <deryck> I am indeed getting system 76.  16 Gb RAM, Super hot graphics card, and 480 Gb SSD.
[14:45] <czajkowski> nice
[14:45] <al-maisan> "480 Gb SSD" -- wow!
[14:45]  * al-maisan envies deryck 
[14:45] <deryck> :)
[14:46] <sinzui> I was very disappointed with System76's quality and support. They would not admit there was a defect in the cdrom drive because it is revealed their source. I had to borrow someone's windows installer to install the free firmware fix that they did not want to admit existed. The display died 4 months later. Though they fixed it, the trackpad became unreliable 6 months after that.
[14:52] <deryck> ouch
[14:52] <deryck> I've heard stuff like that, and heard others who love them.
[14:52] <deryck> I'll let you all know what I think soon :)
[14:58] <deryck> adeuring, abentley -- standup in 2?
[14:59] <adeuring> ack
[14:59] <abentley> deryck: sure.
[15:02] <deryck> g+ is taking a bit, sorry
[15:14] <salgado> mrevell, hi there.  did you get my email about the notification about work-items that can't be migrated automatically?
[15:14] <salgado> (on launchpad-dev@)
[15:16] <czajkowski> sinzui: aye one reason I didnt buy one, lving in the UK wasnt sure of the level of customer care
[15:17] <czajkowski> sinzui: the last 2 licence review projects that I had waiting in there I was leaving to ask you stuff about them. one was eclisep but owned by us I think, and the other you'd left comments on the white board
[15:18] <sinzui> czajkowski,  I approved both
[15:18] <czajkowski> ok as I didnt know what the comments on the white board were referring to
[15:18] <sinzui> the epl is legitimate. There was a branch but the user did not set it as the focus of development
[15:18] <czajkowski> hence me leaving them, only noticed they were gone when I refreshed the page
[15:19] <sinzui> czajkowski, the other project was warning in the past the NC was not open and free, their project is fine now that they picked a license from the know good licenses.
[15:20] <czajkowski> nods it's hard for me to understand the comments as I dont know what is being referenced
[15:20] <czajkowski> aso hard for you to know I'm doing the licence review either as I leave al my tabs open and review them all durin the day
[15:20] <czajkowski> as going by the rotation maintence schedule
[15:22] <sinzui> I panic when I see 5 tabs open
[15:22] <czajkowski> sinzui: everyone has their own working method, I've a desktop for lp work and irc and mail, another desktop for browsing
[15:23] <czajkowski> everying has it's place
=== matsubara is now known as matsubara-lunch
[15:36] <mrevell> salgado, How would you send the notification email to people's whose blueprints haven't migrated? I don't understand because in your email you say that it wouldn't work if you sent the notification from the script.
[15:38] <salgado> mrevell, a separate, throw-away, script to send notifications to the owner/assignee of a list of BPs
[15:38] <mrevell> salgado, Ah, I see.
[15:38] <czajkowski> does that mean I'm going to get a ton of notifactions about bluerprints which are 4 cycles ago ?
[15:38] <mrevell> czajkowski, I'm guessing only if you're the owner. IS that right salgado?
[15:39] <salgado> only if you're the owner/assignee and the work items there can't be parsed
[15:39] <czajkowski> not if you're subscribed to them
[15:39] <czajkowski> ugh gonna create a filter now I'm gonna get a lotta mail
[15:39] <salgado> and even then we might decide to completely ignore BPs older than, say, 6 months
[15:40] <mrevell> czajkowski, Can you help salgado gauge how old a blueprint people in the Ubuntu community care about?
[15:41] <mrevell> salgado, Wouldn't it be better to email only the blueprint owner, rather than the subscribers as well?
[15:41] <salgado> mrevell, I don't have plans to email subscribers. I only considered owner/assignee
[15:41] <czajkowski> hmm owner would make sense, but not all blueprints may have an assingee can go and find out
[15:42] <salgado> if there's no assignee then just the owner
[15:42] <salgado> I mean, if a BP has no assignee we notify only the owner
[15:44] <czajkowski> salgado: and the driver?
[15:45] <salgado> sure, we can notify the driver as well
[15:46] <mrevell> Sounds good to me salgado
[15:47] <czajkowski> cool
[15:50] <salgado> mrevell, cool. I'll send you the notification text for review if that's ok with you?
[15:51] <czajkowski> salgado: 15:48 < cjohnston> not all BPs use cycles... would be my only concern
[15:51] <czajkowski> 15:48 < jussi> czajkowski: what cjohnston said.
[15:51] <mrevell> salgado, Do you mind sending it to danhg?
[15:51] <salgado> mrevell, not at all
[15:51] <mrevell> salgado, I'd love to look too but it's his area now.
[15:51] <danhg> Sending what?
[15:52] <danhg> Sorry, I've not been following the thread.
[15:52] <salgado> mrevell, btw, what about the announcement?  should I pester danhg about it as well?
[15:52] <czajkowski> salgado: those were comments fro folks who use blueprints reguarly each cycle.
[15:53] <salgado> czajkowski, right, and that means we may want to notify people about all WIs that can't be parsed and not just for the recent ones?
[15:53] <mrevell> danhg, A notification to tell people that we tried to migrate their work items from the whiteboard on their blueprint to the work items box, but it didn't work. If you read up you'll see the conversation.
[15:54] <mrevell> salgado, As for the announcement, yeah, I think danhg will handle that and I'll make sure he's up to speed.
[15:55] <salgado> mrevell, cool!  any idea when we can have that?  the code is done and we're just waiting for the announcement/notification-script to get it deployed :)
[15:55] <salgado> danhg, I guess you might be in a better position to answer that ;)
[15:55] <czajkowski> salgado: nods
[15:55] <mrevell> salgado, danhg and I have a catch-up now so I'll see how Dan's schedule is looking. It may be that it's quicker for me knock one out after that call.
[15:56] <czajkowski> salgado: possibly again the lists and contacts I suggested before to be sent to as well
[15:56] <mrevell> By "knock one out", I mean "carefully craft".
[15:57] <salgado> czajkowski, I don't think sending 200+ messages to those folks/lists will help.  the whole point of sending to the owner/assignee/driver is to email only the relevant people
[15:58] <salgado> the people who will know how to fix the WIs so that we can parse them
[15:58] <czajkowski> hmm ok
[16:06] <sinzui> I agree with salgado. only the assigned people can fix the data, and the data is not doing what they thought it was
[16:07] <sinzui> salgado, I had two rounds of emails when hardening bugs and teams. We set a cut off date and fixed the remaining data to meet our deadlines
[16:09] <salgado> sinzui, cool.  btw, what's the best way to write this one-of script to get a list of BPs and send a fixed notification to their owners/assignees/drivers?  can I do that as a script to be cowboyed into a LP tree and ran from there?
[16:10] <sinzui> salgado, I pulled email addresses from staging and deduped them. I then wrote a script that sent the email though canonical.
[16:11]  * sinzui looks for example script and data
[16:11] <salgado> sinzui, from your own email address?
[16:11] <sinzui> yes
[16:14] <salgado> yeah, that's probably easier
[16:15] <sinzui> salgado, I have a script that send an email to people found in a psql report. I did /massage/ the report to ensure no one got 2 emails. I think I had to research two email address for teams
[16:16] <sinzui> I will sed you the script, with the example sql and output that was used to test and send the email
[16:16] <salgado> sinzui, great, thanks a bunch!
=== salgado is now known as salgado-lunch
=== salgado-lunch is now known as salgado
=== matsubara-lunch is now known as matsubara
=== al-maisan is now known as almaisan-away
=== deryck is now known as deryck[lunch]
=== deryck[lunch] is now known as deryck
[20:04] <lifeless> sinzui: ♥ my hero
[20:07]  * sinzui wonders what he has done
[20:21] <lifeless> partial fix for person merge of proposed memberships
[20:22] <sinzui> ah.
[20:22] <lifeless> I say partial, because pg8.4 will let races exist still
[20:22] <sinzui> I am writing the SQL to fix the remaining production data now.
[20:22] <lifeless> but in practice we can probably ignore it, as long as once the merge is scheduled attempts to propose are rejected
[20:23] <lifeless> do we guard new proposals (in either direction) against being done after a merge is requested ?
[20:34] <sinzui> lifeless, we do not guard against new proposals. Merge does not need to know about it since the work is not calculated until the moment the merge happens. Since the merge process opens a cursor and starts updating and deleting, I assume it has a wrote lock preventing anyone from proposing a membership in the seconds needed to complete the merge
[20:34] <sinzui> The team being merged has a warning on its page explaining the scheduled merge.
[20:35] <sinzui> Someone with a stale browser could propose a merge the instant after a team is merged. It will error, just like it can happen now in cases like bug subscription
[20:56] <lifeless> sinzui: inserting a new row into another table is protected in 9.1, not in 8.4
[20:57] <lifeless> sinzui: here is a sequence that I believe will work in 8.4
[20:57] <lifeless> A: begin
[20:57] <lifeless> A: read person row
[20:57] <lifeless> B: begin
[20:57] <lifeless> B: read person row, insert proposed membership
[20:58] <lifeless> A: write to person row (blocks on B, blocks new inserts of related rows)
[20:58] <lifeless> B: commit
[20:58] <lifeless> A: read proposed memberships - does not see the one from B
[20:58] <lifeless> A: commit
[20:58] <lifeless> sinzui: so I think we need to guard against new proposals after the merge is scheduled
[20:58] <lifeless> sinzui: to be fully safe
[21:01] <sinzui> why
[21:02] <sinzui> lifeless, why. There is no db conflict.
[21:02] <lifeless> sinzui: exactly
[21:02] <lifeless> sinzui: if A is the merge job, and B is a stale browser POST request, we end up with bad data again.
[21:02] <sinzui> lifeless, I do not write jobs that presupose work. The pending merge will still remove the pending membersip
[21:03] <sinzui> membership
[21:03] <lifeless> sinzui: no, because A *is* the merge
[21:03] <sinzui> Then Lp should not let any user use any team that is in a pending merge job. This has nothing to do with pending memberships
[21:04] <sinzui> This condition exists to day with merge proposals, drivers, maintainers, supervisors, contacts, subscriptions
[21:04] <lifeless> sinzui: +1
=== matsubara is now known as matsubara-afk
[21:05] <sinzui> No user has ever reported there is an issue with one user scheduling a merge and another user putting the same team in a new relationship
[21:06] <lifeless> perhaps I'm paranoid.
[21:06] <lifeless> I'm not asking you to do the work now or anything.
[21:07] <lifeless> I am however sure that this race exists.
[21:08] <sinzui> I can show you sql that might make you cry. It shows everything I know of that is superfluous  data left behind by merge and deactivation. I might even consider some of it a security risk, but I think sharing policies fix that
[21:09] <lifeless> As long as we have a bug identifying this stuff, I won't cry. I might sob a little.
[21:11] <sinzui> There are no comprehensive bugs describing that merged/deactivated users continue to have artefact subscriptions.
[21:12] <lifeless> sinzui: may I impose on you to create one ?
[21:13] <sinzui> We have about 12,000 rows of data we search work with to send emails, but we abort because the user/team is gnoe
[21:13] <lifeless> sinzui: where is grackle at? Schema designed I know, but is it code-started? no-code-yet? ...
[21:14] <sinzui> There is code. The client lib is 50% ready and the browser code is 90% there
[21:14] <sinzui> No work on the server to show yet
[21:14] <sinzui> I only work on it on Fridays
[21:15] <lifeless> thats cool
[21:15] <lifeless> I want to let -tech know about the use of cassandra
[21:15] <sinzui> Actually, I failed to work on it last Friday. I owe it an day of labour?
[21:15] <lifeless> don't fear the grackle
[21:31] <abentley> deryck: There's no OCR.  Could you please review https://code.launchpad.net/~abentley/launchpad/upgrade-all-2/+merge/96247 ?
=== lifeless changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: - | Firefighting: - | Critical bugtasks: 4*10
[21:33] <deryck> abentley, sure
[21:34] <abentley> deryck: thanks.
[21:35] <abentley> deryck: btw, how does one claim ec2 expenses?  I've never done it before.
[21:39] <deryck> abentley, file expenses through canonical admin.  Send in copy of receipt to the email we normally send in receipts.
[21:39] <deryck> abentley, and the charges are listed as "misc" on the expense report.
[21:40] <deryck> abentley, and r=me on the proposal.
[21:41] <abentley> deryck: thanks.  I will ec2 land it, of course :-)
[21:42] <deryck> abentley, awesome :)
[21:59] <wgrant> lifeless: Are you referring to predicate locking?
[22:00] <lifeless> wgrant: SSIS or whatever it is
[22:04] <wgrant> lifeless: Right, with predicate locking.
[22:04] <wgrant> lifeless: To use that effectively we'd have to garboify the thing.
[22:04] <wgrant> (which we possibly should anyway, but it's complicated)
[22:06] <lifeless> wgrant: you're talking person merge?
[22:06] <lifeless> wgrant: I thought we already did that in a Job
[22:07] <james_w> hi wgrant, are you on the stakeholders mailing list?
[22:07] <lifeless> james_w: which one
[22:08] <james_w> LP\
[22:08] <lifeless> I think he is,yes.
[22:11] <wgrant> lifeless: Um, by garbo I mean looptune
[22:11] <wgrant> lifeless: Currently it's in a single transaction, I think.
[22:12] <lifeless> wgrant: I don't see the issue; as long as we do merge > Hard-timeout after any started transactions, and we reject use of to-be-merged persons, we're safe.
[22:13] <wgrant> lifeless: It could take minutes.
[22:13] <wgrant> lifeless: Keeping a serialised transaction open like that sounds dangerous.
[22:13] <lifeless> wgrant: ehhh
[22:14] <lifeless> wgrant: I think there is a massive comms fail happening here
[22:14] <lifeless> and planet earth is blue
[22:14] <wgrant> Oh?
[22:15] <lifeless> I didn't suggest minutes, nor keeping a serialised xaction open the whole time
[22:15] <lifeless> I didn't imply it either :)
[22:15] <StevenK> lifeless: Can you untestable or something r14902? Please?
[22:16] <wgrant> lifeless: Using SSI in something like the current implementation implies it
[22:16] <lifeless> wgrant: I am not proposing SSI, I was saying in the absence of it ...
[22:17] <lifeless> StevenK: Naturally. I was waiting for it to hit staging so it can be QA'd.
[22:17] <james_w> wgrant, did you see the discussions around creating commercial PPAs?
[22:18] <StevenK> lifeless: Bah, this whole devel versus db-devel thing.
[22:18] <lifeless> so, staging is running
[22:18] <lifeless> and has the right revno
[22:19] <lifeless> checking logs
[22:19] <wgrant> james_w: Yeah. IIRC we basically want to make commercial-ppa-uploaders a celebrity or add an extra field on distribution, which allows setting of commercial.
[22:19] <wgrant> I suspect the latter.
[22:20] <lifeless> 0.3 of a second
[22:20] <lifeless> StevenK: having looked in backlog I see you pinged me last night; if it was on staging already you could have qa'd it - no need to block on me.
[22:23] <StevenK> lifeless: I was implying that you should practise what you preach in terms of QA. :-P
[22:23] <lifeless> StevenK: I preach that we should qa each others stuff
[22:23] <wgrant> james_w: Are you looking at implementing it?
[22:24] <lifeless> StevenK: and I qa other folks stuff, so  :-P
[22:24] <james_w> wgrant, do we also want to make ~commercial-ppa-uploaders a private team, so that we don't have to worry about also being able to make archives private?
[22:24] <james_w> (the team loaded for me today, so I was able to see that it is currently public)
[22:24] <james_w> or maybe cleaning up Launchpad.CommericalAdmin would be a maintainance win that would offset the increased lines of code
[22:24] <james_w> wgrant, it's a blocker to the work we want to do next, so yeah
[22:26] <wgrant> james_w: Mmmm. That's a hard one.
[22:35] <sinzui> wgrant, this appears to generate sane ids http://pypi.python.org/pypi/z3c.form
[23:59] <wgrant> Anyone feel like reviewing https://code.launchpad.net/~wgrant/launchpad/html-wtf/+merge/96265?