[00:06] <ancaemanuel> hloeung: thanks... , permission denied for me.
[00:13] <dx> hi, need some guidance to try to get a bug fixed in wily. the pidgin package has a patch for gstreamer 1.0 support with this bug: https://developer.pidgin.im/ticket/16752
[00:14] <dx> the bug can be summarized as a crash after playing sounds 1000 times (which can be a few hours of receiving messages), so it's quite bad
[00:15] <RAOF> dx: Sounds like a job for a StableReleaseUpdate!
[00:15] <RAOF> https://wiki.ubuntu.com/StableReleaseUpdates being the relevant wiki page.
[00:15] <dx> yup! the problem is that the first step says that i should ensure it's fixed in the testing version
[00:15] <dx> ..does that mean i have to get it fixed in debian, then in ubuntu devel, and then do the SRU?
[00:16] <RAOF> Doesn't have to be fixed in Debian (but it's nice to attach a patch to the relevant Debian bug)
[00:17] <dx> awesome.
[00:17] <RAOF> You should attach a fix for both the xenial and wily packages to the bug report, though.
[00:17] <RAOF> (Assuming you need sponsorship. If you don't need sponsorship, upload a fixed package to xenial and then wily-proposed ☺)
[00:18] <dx> yeah i need sponsorship. the fix would be https://bitbucket.org/pidgin/main/commits/902b1fd334bd4d41ffd217fa4e6864629b7d3edc/raw/
[00:18] <dx> i'll just ignore debian because pidgin 2.10.12 is going to be released very soon, which also includes the fix.
[00:19] <dx> next question: this ticket describes the bug but it's a terrible ticket https://bugs.launchpad.net/ubuntu/+source/pidgin/+bug/1479715
[00:20] <dx> do i create a new one or can i just edit that?
[00:20] <RAOF> Edit that one.
[00:20] <sarnold> try hitting the little yellow icon on the same horizontal level as 'bug description'
[00:20] <RAOF> It's the one that's associated with the error bucket!
[00:21] <dx> cool, thanks
[01:04] <dx> okay i think i'm done https://bugs.launchpad.net/ubuntu/+source/pidgin/+bug/1479715
[05:03] <pitti> Good morning
[05:03] <pitti> apw: \o/ http://autopkgtest.ubuntu.com/packages/s/systemd/xenial/i386/ is pass again
[05:05] <pitti> blake_r: that's quite simple -- nobody actually starts that unit :)
[05:06] <pitti> blake_r: it's actually a lot simpler than that; just put this "runcmd:" as the last thing in your cloud-init user-data:
[05:06] <pitti> - (while [ ! -e /var/lib/cloud/instance/boot-finished ]; do sleep 1; done; shutdown -P now) &
[05:06] <pitti> blake_r: this avoids all that indirection, does not depend on any particular init, and is much simpler
[05:07] <pitti> blake_r: also, if you create temporary units, please put them into /run/systemd/system/, not /lib
[05:08] <pitti> blake_r: merely creating a unit does not cause it to start -- something (a dependency from another unit) or someone (calling systemctl start) needs to do that
[05:10] <pitti> blake_r: oh sorry, this isn't just cloud-init, it's maas
[05:10] <pitti> blake_r: so, turn that dependency around -- drop the Wants=cloud-final.service and instead add [Install]\nWantedBy=cloud-final.service, then systemctl enable maas-poweroff.service
[05:11] <pitti> blake_r: then maas-final.service will start maas-poweroff.service
[05:11] <pitti> blake_r: but still, please put this into /run; it's dangerous to write it to /lib, you might forget to delete it after installation
[06:17] <pitti> utlemming: can you please build a ppc64el xenial cloud image?
[06:17] <pitti> stgraber: ^ reason for lxc/ppc64el regression, in case you wonder; I'll override
[07:38] <dholbach> good morning
[09:01] <pitti> infinity, cjwatson: do you know why this linux/amd64 upload got stuck in unapproved? (https://launchpad.net/ubuntu/xenial/+queue?queue_state=1)
[09:02] <pitti> I suppose we have a special-case for kernels with signed EFI bits, to manually verify the upload
[09:02] <pitti> but what am I supposed to verify for that?
[09:02] <pitti> LP stripped off the gpg signature of the .changes file, so I can't verify that it was actually uploaded by Tim
[09:06]  * apw believes it is the linux_4.3.0-5.16_amd64.tar.gz that is to be verified, that it only contains expected flavour .efi files, and that the kernel itself comes from a trusted source
[09:06] <pitti> but I have no way to see which source it came from
[09:07] <pitti> if it had rtg's gpg sig on the .changes, I could verify based on that I trust Tim
[09:07] <pitti> but so far I just know that it was uploaded by a core-dev or someone with linux package upload rights
[10:10] <cjwatson> pitti: the main point is just to stop arbitrary other packages being uploaded and gaining signatures
[10:12] <pitti> cjwatson: ah, ok; so I know that the source (https://launchpad.net/ubuntu/+source/linux/4.3.0-5.16) was uploaded by Tim (assuming that this is the signature, not the Changed-By:), and that it's linux where we expect new signatures
[10:26] <mardy> xnox: hi! I'd like to test a branch of libaccounts-glib on s390x; what would be the best way to do that?
[10:26] <mardy> xnox: I could ask for a silo, but is it possible to limit the builds to one arch only?
[10:27] <LocutusOfBorg1> can anybody please retry casablanca/arm64 on xenial?
[10:28] <cjwatson> LocutusOfBorg1: done
[10:29] <LocutusOfBorg1> thanks
[10:30] <LocutusOfBorg1> nobody seems processing backports anymore :(
[10:30] <LocutusOfBorg1> https://bugs.launchpad.net/wily-backports/+bug/1512982
[10:50] <xnox> mardy, you can give me a *.dsc and i can build it for you. Or build it in a silo, as you normally would - it has s390x enabled.
[10:51] <xnox> mardy, or e.g. a branch. where is it staged?
[10:52] <mardy> xnox: excellent; now I've added a commit to the existing silo, but if I will want to build some really experimental branches, I'll ping you then :-)
[10:52] <mardy> xnox: upstream is in gitlab.com, but we have bzr branches with debian packaging in lp
[10:53] <mardy> xnox: so, if the need arises, I might ping you back in a while
[12:51] <cyphermox> good morning!
[14:17] <blake_r> pitti: thanks for the info I gave that a try still didnt work, but I am going to just have cloud-init poweroff the machine which I believe is the more correct way anyway
[14:17] <pitti> blake_r: right, and much simpler too, if you don't have to do anythign after cloud-init
[14:18] <pitti> blake_r: more modern cloud-inits even have that feature builtin, but not yet in older releases (thus I'm not yet using it in autopkgtest)
[14:18] <blake_r> pitti: yeah I am going to use "power_state" in cloud-init
[14:18] <pitti> blake_r: http://cloudinit.readthedocs.org/en/latest/topics/examples.html#reboot-poweroff-when-finished right, that's what I meant
[14:19] <mardy> xnox: ok, I've got something I'd like to you to build on s390x, but I don't know how to generate the .dsc file: debuild complains that it cannot find the upstream tarball
[14:19] <xnox> mardy, i can work with branches too...
[14:19] <cjwatson> Download it from the Ubuntu archive and put it in your parent directory
[14:19] <pitti> blake_r: I just checked, power_state does exist in trusty now, but not yet in precise
[14:20] <blake_r> pitti: thanks for the info, we only support trusty to commision with so that will be perfect
[14:22] <mardy> xnox: ah, that makes it much easier :-) lp:~mardy/libaccounts-glib/s390-tests
[14:32] <xnox> mardy, fail - https://launchpadlibrarian.net/230340565/buildlog_ubuntu-xenial-s390x.libaccounts-glib_1.19-0ubuntu1_BUILDING.txt.gz
[14:35] <mardy> xnox: thanks -- I actually just added some debug messages, so failure was expected :-)
[14:51] <xnox> mardy, what tipe of db is it using?
[14:56] <doko> perl transition has arrived ... texinfo uninstallable
[14:56]  * xnox ponders if we should have used a silo for perl transition
[14:56] <cjwatson> doko: I've uploaded the key rebuilds
[14:56] <cjwatson> doko: working on it anyway
[14:56] <cjwatson> xnox: maybe, but too late now :)
[14:57] <xnox> cjwatson, cowboy developer =)
[14:58] <cjwatson> xnox: hey, it was auto-synced :P
[15:00] <xnox> .....
[15:00]  * xnox ponders if i should or should not point out who implemented autosync...
[15:00] <xnox> >_<
[15:00] <xnox> =)))))
[15:00] <pitti> good that we don't all run away into holidays in two days
[15:01] <cjwatson> xnox: *ahem* I ported it to its current implementation, I didn't write it to start with :)
[15:02] <xnox> cjwatson, ... Keybuk?
[15:02] <cjwatson> xnox: I doubt it
[15:02] <cjwatson> It was in LP
[15:03] <xnox> right. so somebody like lamont or some such then. anyway, history.
[15:13] <jgdxx> greyback, hey, is mir 0.17 too old to get back something that makes sense from mir_connection_create_display_config ?
[15:14] <greyback> jgdxx: no, that should work today
[15:14] <jgdxx> on the device, I'm getting two outputs, one lvds and one displayport (on mako), but only one of them have modes (lvds)
[15:15] <jgdxx> and the only lvds mode is 1280x768x60
[15:15] <greyback> jgdxx: this with mir-on-x?
[15:15] <jgdxx> greyback, on the device, so no x
[15:17] <jgdx> greyback, code http://pastebin.ubuntu.com/14074173/
[15:17] <jgdx> i'm only getting adding mode "1280x768x60"
[15:18] <greyback> jgdx: if you run "mirout" does it match what you're seeing?
[15:18] <jgdx> greyback, getting "Could not connect to a display server: Failed to connect: not accepted by server"
[15:20] <greyback> jgdx: ah, you've unity8 running. Instead run "MIR_SOCKET=/run/mir_socket mirout" as rooy
[15:21] <jgdx> greyback, hm, no. I guess I'm doing something wrong. http://pastebin.ubuntu.com/14074211/
[15:22] <jgdx> well no, that's an exact match
[15:22] <jgdx> hm
[15:22] <jgdx> it only supports that mode :P
[15:22] <jgdx> greyback, thanks!
[15:22] <greyback> jgdx: yep. lvds not flexible
[15:33] <lamont> xnox: not I
[15:35] <cjwatson> xnox: LP's original sync-source.py was ported from the Ubuntu dak instance by James; I believe James wrote the original dak version
[16:06] <infinity> cjwatson: Thanks for handling the perl transition.  I just noticed it had started and panicked that I was going to have to burn my first vacation day fixing it. :P
[16:06] <infinity> cjwatson: Do you need any help with that, or are you carrying state in your head and muscle memory?
[16:06] <cjwatson> infinity: I'll want to hand off at some point, but I'm good for now
[16:06] <infinity> cjwatson: Kay.  Using a tracker, I assume?
[16:07] <cjwatson> infinity: It'll be impeded by the PS4.5 outage anyway, since that's taken out x86 scalingstack
[16:07] <cjwatson> infinity: http://people.canonical.com/~ubuntu-archive/transitions/html/perl5.22.html
[16:07] <infinity> cjwatson: If so, just aim me at it when you're tired.
[16:07] <teward> blurgh... anyone know if it's possible to get a temporary PGP key and SSH key accepted for uploads to the repositories?  (Gotta ask since my main system with my keys and such is down for repairs, for a few days)
[16:07] <cjwatson> infinity: I'm doing lib*-perl from levels 1 and 2
[16:07] <pitti> FTR, autopkgtest workers are all down (PS4.5 too), so tehre won't be progress on that front anytime soon
[16:07] <infinity> cjwatson: Oh, joy.  (re: scalingstack)
[16:07] <cjwatson> teward: as long as you can get at your Launchpad account, you can add new PGP/SSH keys there
[16:08] <cjwatson> teward: if you can't do that, then no
[16:08] <teward> cjwatson, and that's  instantly accepted at upload.u.c?
[16:08] <cjwatson> teward: yes
[16:08] <pitti> but no SSO to add them, I figure :)
[16:08] <teward> cjwatson, thankfully I logged into launchpad *before* SSO took a crap
[16:08] <cjwatson> teward: upload.u.c authenticates against Launchpad
[16:08] <mardy> xnox: it's using sqlite
[16:08] <cjwatson> pitti: SSO was working last I checked
[16:08] <teward> pitti, i'm actually logged in now xD
[16:08] <cjwatson> but maybe flapping
[16:08] <teward> cjwatson, SSO broken on wiki.u.c as of 5 minutes ago
[16:08] <pitti> teward: I'm fairly sure that adding keys will ask you again, but good luck!
[16:08] <xnox> mardy, ack.
[16:08] <cjwatson> right, probably flapping with the PS4.5 outage
[16:08] <teward> i was already logged in on LP this morning around 6AM
[16:08] <cjwatson> and indeed, changing at least some keys (PGP, IIRC) will require reuath
[16:08] <cjwatson> *reauth
[16:08] <teward> pitti, indeed.  first, gotta spin up a temporary VM environment for stuff, being stuck on WINDOWS makes me cringe
[16:09] <teward> (fortunately i keep copies of ISOs, on a private ISO storage disk xD)
[16:09] <cjwatson> things are supposedly coming back up though
[16:09] <cjwatson> login.u.c is responding from here
[16:11] <cjwatson> let's see if x86 scalingstack likes life better now
[16:12] <teward> cjwatson, login.u.c was working for me fine, but the authentication from that -> wiki was timed out for me (10min+)
[16:12] <teward> finally got in just a few seconds ago
[16:12] <cjwatson> ah, well if login.u.c was working then that's not an SSO issue now is it?
[16:13] <cjwatson> I expect the wiki's in prodstack so would have been independently having network trouble
[16:13] <infinity> The wiki SSO bits seems to be rathe more problematic than most.
[16:13] <infinity> (always, not just today)
[16:13] <cjwatson> anyway, I hear things are returning
[16:13] <teward> infinity, true, though it worked fine until this morning :)
[16:13] <teward> cjwatson, thanks :)
[16:14] <infinity> cjwatson: Gave you a bit more ppc horsepower too (ie: revived doko's latest murder spree victims)
[16:15] <cjwatson> infinity: ta
[16:37] <pitti> ah, autopkgtests are back, and busy with perl :) http://autopkgtest.ubuntu.com/running.shtml
[17:04] <didrocks> barry: hey, do you have time for a stacktrace in python3-coverage? (I'm getting a stacktrace everything I'm enabling --cov-report=html)
[17:08] <barry> didrocks: let's see (tho i'm about to break for lunch)
[17:10] <didrocks> barry: I'm getting something like: http://paste.ubuntu.com/14075536/
[17:11] <didrocks> (.coverage is generated as expected)
[17:12] <barry> ran out of input!  that's a new one on me :)
[17:12] <didrocks> barry: if I replace --cov-report=html by xml, it generates the xml as expected
[17:12] <didrocks> yeah, sounds weird ;)
[17:36] <pitti> cjwatson: ah, your lgw buildds are AWOL too
[17:37] <cjwatson> pitti: Yeah, I know
[17:37] <pitti> so that's not just me
[17:37] <cjwatson> It's all dead
[17:37] <cjwatson> mabolo is apparently very very sad
[17:37] <pitti> one day before holidays, big perl 5.22, clouds dead -- what a perfect timing :)
[19:47] <ryao> When is 16.04 Beta 1?
[19:48] <ryao> Nevermind... I found it by googling slightly differently.
[19:48] <sarnold> hey ryao :) https://wiki.ubuntu.com/XenialXerus/ReleaseSchedule note that feature freeze is before that..
[20:25] <ryao> sarnold: Thanks.
[21:01] <mwhudson> i'd like to make a semi official ppa (or two) for golang testing
[21:01] <mwhudson> would it make sense for them to be on the ~ubuntu-toolchain-r team or would a new team be better?
[21:18] <slangasek> mwhudson: well, you'd have to be part of the ~ubuntu-toolchain-r team for that to be useful to you, I guess?  In which case you need to get doko to add you :)
[21:18] <mwhudson> slangasek: yeah, i guess this is a question for doko really
[21:18] <slangasek> it seems reasonable to me, but also not required since you can also easily get another team set up with a devirt ppa for all-arch building
[21:50] <xnox_2016> mwhudson, after all these years doko never added me to ~ubuntu-toolchain-r i would not hold my breath. setting up new team and/or ppa should be fine. I thought there already was devirt ppa for go.... i recall somebody was building golang like on every upstream commit in devirt ppas.
[21:50] <mwhudson> yeah ok new team seems sane then
[21:51] <mwhudson> xnox_2016: gustavo was doing that sort of thing for a while i think, but not recentaly afaik
[21:51] <xnox_2016> mwhudson, maybe you can take over those ppas.
[21:54] <mwhudson> there's https://launchpad.net/~gophers/+archive/ubuntu/go bug that's really pretty old


[17:12] <flocculant> ochosi: wasn't talking about that - just the comepletely different icon there :p
[17:12] <flocculant> anyway - noted it :)
[18:32] <ochosi> flocculant: yeah, that's symbolic vs non-symbolic. in adwaita those two types are extremely inconsiste t
[18:32] <ochosi> also not easy to draw the powerline and adapter in a monochrome 16px version
[18:38] <flocculant> ochosi: ok - wasn't sure about that - and yea I can imagine it being a pita doing that in monochrome 16px :p
[19:05] <ochosi> that's why i went for the very generic circle with the flash


[00:06] <wgrant> cody-somerville: Hi, can you QA your authorized_size thing?
[00:06] <StevenK> And jelmer's thing
[00:07] <wgrant> jelmer's QAed half of his, but bug #296153 is still pending
[00:07] <_mup_> Bug #296153: does not mirror bzr branches over ftp <lp-code> <qa-needstesting> <Launchpad itself:Fix Committed by jelmer> < https://launchpad.net/bugs/296153 >
[00:08] <StevenK> wgrant: Your testfix switched to rSP() in the factory?
[00:08] <wgrant> No, rSP doesn't work there.
[00:09] <wgrant> I logged in as an admin instead.
[00:22] <wallyworld> abentley: hi, with the mustache/handlebars template in a file, i notice there's no reference to it in the buglisting yui tests
[00:24] <wallyworld> so it doesn't appear the rendering aspects are tested in that case, whereas in the pillar sharing stuff, i have yui tests for the rendering and therefore need the load the template in the tests
[00:25] <wallyworld> that was one of the reasons for having the template in the javascript
[00:25] <wallyworld> i guess i could pull in the template in the test html
[00:30] <jelmer> StevenK, wgrant: bug 296153 is qa-ok
[00:30] <_mup_> Bug #296153: does not mirror bzr branches over ftp <lp-code> <qa-ok> <Launchpad itself:Fix Committed by jelmer> < https://launchpad.net/bugs/296153 >
[00:31] <rick_h_> wallyworld: yea, that's a big issue we've got to figure out for JS testing as we move more client side rendering
[00:33] <wallyworld> rick_h_: i'll seeing how it flies pulling it out in a file, as per the code review request. i was happy enough to leave it in the js for now but there's been a couple of objections
[00:33] <wallyworld> rick_h_: in this case, there's NO server side rendering, it's all client
[00:34] <rick_h_> wallyworld: right, but you want the tests and the live site using the same template if possible so that they match and test correctly
[00:34] <rick_h_> but it'sa bit tough/pia
[00:34] <rick_h_> pita that is
[00:35] <wallyworld> rick_h_: of course i want to use the same stuff :-) that's why it was in the js
[00:35] <wallyworld> i think i can put in a file and load the file in the test html
[00:35] <wallyworld> trying that now to see if it has legs
[00:46] <wgrant> jelmer: Thanks.
[00:48] <rick_h_> wallyworld: yea, that's what I've done in my app is create a jstemplate file that I include in both places
[00:53] <wallyworld> rick_h_: if i have a script element with a src attribute, what's the magic to get yui to be able to get at the contents of the referenced file?
[00:54] <rick_h_> Y.one('#id').getContent() I think
[00:54] <rick_h_> oh, it's got a src attribute? hmmm, not sure if that works
[00:54] <wallyworld> yeah, getContent() fails
[00:55] <wallyworld> well, i used src since i wanted to reference the single copy of the mustache template file
[00:55] <wallyworld> that same copy that the view passes to the js in prod
[00:57] <wallyworld> maybe ScriptNodeDataSource
[00:59] <wgrant> wallyworld: I would hope that you couldn't get at the content.
[00:59] <wgrant> That would be a security issue unless very carefully restricted.
[00:59] <wallyworld> wgrant: it's in the test html
[00:59] <wallyworld> to load the mustache template data from a file to pass to the widget
[01:00] <wallyworld> on prod, the pythov view does this
[01:00] <wallyworld> but i want to use the same template for testing
[01:00] <wgrant> Ah, interesting.
[01:00] <wallyworld> i currently have the template in the js but people don't like this
[01:01] <wallyworld> so i'm trying to find another way
[01:01] <wallyworld> buglistings does it this way but there' no yui rendering tests using the template
[01:01] <wallyworld> so they didn't need to solve this
[01:05] <wallyworld> so it appears html5 has a File api which may be useful
[01:07] <wgrant> rofl
[01:07] <wgrant> glwt
[01:08] <wallyworld> well spec draft is from oct 2011 so it's "ancient" :-)
[01:28] <wgrant> Hmm
[01:28] <wgrant> I can't talk to bits of the DC
[01:30] <wgrant> Ah, there we go.
[01:33] <lifeless> wallyworld: hi
[01:33] <wallyworld> lifeless: hello
[01:33] <lifeless> wallyworld: you should deliver the template via the API/view involved - combo loader eventually
[01:33] <lifeless> wallyworld: is there a reason that that won't work ?
[01:34] <wallyworld> lifeless: that's all well and good but i need the same content for yui tests
[01:34] <lifeless> I don't see the problem
[01:34] <wallyworld> that's the issue here
[01:34] <wallyworld> tests have a html file and a js file
[01:34] <wgrant> There's no API or view in a YUI test.
[01:34] <lifeless> the yui tests are loaded and run by the lp test driver which is part of our regular python stack
[01:35] <lifeless> how will the yui tests work in a non-launchpad.js world ?
[01:35] <wallyworld> yui tests don't have our python stack, just html and javascript
[01:35] <rick_h_> the yui tests are just calling .html files iwth JS that runs on them
[01:35] <rick_h_> our test stack is just a vessel to load .html files and parse response
[01:35] <wallyworld> eg you can load the test html file in a browser
[01:35] <lifeless> rick_h_: and the html5-browser wrapped around that
[01:35] <wallyworld> and the tests will run
[01:35] <wallyworld> with no lp running at all
[01:36] <wallyworld> just pure js
[01:36] <rick_h_> we'd need to find some way to write templates to a .html file and include it into the test.html file (iframe or something?) and pull that html file into the zope template as required for the JS on page to use
[01:36] <lifeless> no yui ?
[01:36] <wallyworld> yui, yes
[01:36] <lifeless> rick_h_: guh what
[01:36] <wallyworld> but reasd off disk locally
[01:36] <rick_h_> I've not had a chance to think it through 100% yet. I just know I hit it when updating the tests and it's on my list.
[01:37] <wallyworld> lifeless: so you see the problem now?
[01:37] <lifeless> rick_h_: so lets skip mustache
[01:37] <lifeless> wallyworld: I see the corner we've painted ourselves into
[01:37] <rick_h_> so for instance, in my outside application, tests are run via the application so that I can import the same template file in the tests that the application uses
[01:37] <lifeless> wallyworld: we've violated abstractions and are now suffering
[01:37] <wallyworld> lifeless: well, it's how yui tests have been written since day 1
[01:38] <wgrant> lifeless: You might be thinking of YUIXHR
[01:38] <wgrant> Which uses an appserver.
[01:38] <lifeless> I might be
[01:38] <lifeless> so, lets break this into bits
[01:38] <wallyworld> lifeless: there's no server side rendering here
[01:38] <lifeless> unit tests should not be testing the template outputs; thats orthogonal
[01:38] <wallyworld> so involing the view is bogus
[01:39] <lifeless> testing that a template is rendered and executed is sensible, but the code under test is supplied the template by the server
[01:39] <wallyworld> the view unit tests do need to test the rendering of data
[01:39] <wallyworld> sure, but we need a way to test without the server where the yui unit tests can get at the template
[01:39] <wallyworld> single sourced
[01:39] <wallyworld> and that's the issue
[01:40] <lifeless> so, I think I'm going to get my nose out of this discussion, because I clearly have a different model for whats going on
[01:40] <wgrant> lifeless: What about the unit tests for the template rendering?
[01:40] <wgrant> Surely they need to be testing the template output.
[01:40] <lifeless> I will throw a few key constraints in though to save us later
[01:41] <lifeless> firstly, the templates -must not- be inline in our js or tal files
[01:41] <wallyworld> impossible to write yui unit tests without code copying then
[01:41] <lifeless> we will be compiling them and shipping the compiled result as js to use, accessed probably via the combo loader, or in a pinch via the json cache
[01:42] <lifeless> if the template is inline in our js or tal, that won't work, and we'd be screwed. This is just around the corner when the combo loader comes live && YUI 3.5
[01:42] <wallyworld> nope, the combo loader can handle that ust fine
[01:42] <lifeless> orly
[01:43] <wallyworld> the template is built up inside our javascript
[01:43] <wallyworld> and accessed via a method on the view widget
[01:43] <lifeless> it will extract the template from another file, compile it with nodejs, write that to a temp file and then we'll serve that?
[01:44] <lifeless> I feel very confused.
[01:44] <wallyworld> no, and we use this in several places, we use Node.create(template) where template is a concatenated string of html
[01:44] <lifeless> I'm talking about handlebars templates.
[01:44] <wallyworld> on in the case of mustache, to_html(template)
[01:44] <wgrant> wallyworld: The template is rendered
[01:44] <wallyworld> same thing
[01:44] <wgrant> The rendered template is given to Node.create
[01:44] <wallyworld> yes, i was using an example
[01:44] <lifeless> wallyworld: its not the same thing, the template gets *compiled*
[01:44] <lifeless> wallyworld: it comes down as javascript, in its own source file.
[01:45] <wallyworld> i was trying to issultrate that the template does not have to come from server side
[01:45] <wallyworld> it can be constucted the the js
[01:45] <wallyworld> we use that right now in the code
[01:45] <wgrant> The template has to.
[01:45] <wallyworld> no
[01:45] <wgrant> The JS can't calculate it client-side.
[01:45] <wallyworld> yes, it does
[01:46] <wgrant> No.
[01:46] <wallyworld> we use it now
[01:46] <lifeless> wgrant: handlebars compiler can run client-side, but it is overhead
[01:46] <wgrant> It can't, because we have to specify it somehjow.
[01:46] <wgrant> I mean a (potentially compiled) template.
[01:46] <wgrant> Has to be transmitted from the server
[01:46] <wgrant> at some point.
[01:46] <wallyworld> no, let me find the example
[01:46] <lifeless> we wouldn't want a compiled template from a foreign site, but from LP itself, we want compiled templates I think.
[01:47] <lifeless> this 'no' business doesn't really elucidate the issues
[01:47] <wgrant> wallyworld: You are *rendering* the template client-side.
[01:47] <wallyworld> we concatentate strings to form a mustache template and then call to_html
[01:47] <wgrant> Oh god
[01:47] <wgrant>  /wrists
[01:47] <lifeless> wallyworld: thats a creative use of mustache
[01:47] <lifeless> wallyworld: its not how it is intended to be used though, so I'm curious why that is done
[01:47] <wallyworld> lifeless: it's an extenstion of a prior "pattern" in our js
[01:48] <lifeless> wallyworld: Possibly, but humour me
[01:48] <lifeless> wallyworld: assume I've no prior knowledge and need to be taught why we do this to a mustache template
[01:48] <wallyworld> lifeless: going way back, people used Y.Node.create(html) where the html was ['stuff', 'stuff'].join(' ')
[01:49] <lifeless> wallyworld: ok; but what joins that into how we use mustache? why is it relevant?
[01:49] <wallyworld> then, in some previous code review, it was suggested that a mustache template be used to get the html
[01:49] <wallyworld> so, html = Y.lp.mustache.to_html(template) where template = [xxx].join(' ')
[01:49] <lifeless> wallyworld: ok, I'm clear on what is being done, I'm not clear on why.
[01:49] <wallyworld> it was used for a local popup dialog or something
[01:50] <lifeless> wallyworld: you may not know, which is fine.
[01:50] <lifeless> wallyworld: if you don't, we can skip trying to understand as a group, and move on; if you do know, I'd really like to grok this.
[01:50] <wallyworld> lifeless: so, it wasn't for main view content, but for a confirmation dialog
[01:51] <wallyworld> where the data to ask for confirmation for was best rendered using mustache
[01:51] <wallyworld> since it contained a list of things
[01:51] <wallyworld> easier than building the html by hand
[01:51] <lifeless> wallyworld: that would normally be to_html(template, data)
[01:51] <wallyworld> yes
[01:51] <lifeless> where data has that list in it
[01:51] <wallyworld> yes
[01:51] <lifeless> so why was this done differently ?
[01:51] <wallyworld> define "this"?
[01:51] <lifeless> 14:49 < wallyworld> so, html = Y.lp.mustache.to_html(template) where template = [xxx].join(' ')
[01:52] <wallyworld> i left out the data param
[01:52] <wallyworld> pseudo code and all that
[01:52] <lifeless> why isn't template static though ?
[01:52] <wallyworld> it is
[01:52] <lifeless> Perhaps I misunderstand
[01:52] <rick_h_> it is, but it has to live somewhere. Usually, you write out a <script type="text/template"> block that contains the static html.
[01:52] <lifeless> template = [xxx].join(' ') looks like it is string joining to create the template
[01:52] <lifeless> that is not static
[01:52] <rick_h_> that ends up getting made available on the page via your template
[01:52] <lifeless> its dynamic
[01:53] <lifeless> rick_h_: not helping
[01:53] <wallyworld> lifeless: our coding standard dictate that approach
[01:53] <wallyworld> lifeless: no static, but coding standards force us to do it that way
[01:53] <wallyworld> break up the string into bits
[01:53] <rick_h_> lifeless: ok, can we do a hangout or something? I can hop on the phone. wallyworld is correct, this is a known issue I've seen coming.
[01:53] <wallyworld> line length and all that
[01:53] <lifeless> rick_h_: sure, we can do that
[01:53] <rick_h_> and I can walk through it
[01:53] <wallyworld> mumble ?
[01:54] <wgrant> Oh
[01:54] <rick_h_> I can't, I'm out at a coffee shop without headset/etc
[01:54] <rick_h_> I can use skype or hangout via my cell
[01:54] <wgrant> You mean just as a replacement for """?
[01:54] <lifeless> skype or hangout - they have echo cancellation
[01:54] <wallyworld> wgrant: js dorsn't have """
[01:54] <rick_h_> yea, but in a noisy coffee shop with 10 other techies talking/hacking
[01:54] <wgrant> Right, but that's a faaaaaaaaaaaaaaaaaaaaaaar more restricted case than what you said :)
[01:54] <wallyworld> let's try skpe but mine is flakey
[01:55] <rick_h_> ok, my skype is mitechie
[01:55] <wgrant> It made it sound like you were generating the template dynamically, rather than just concatenating strings in a static way because JS is hideous.
[01:55] <wallyworld> wgrant: oh, i didn't mean to imply that
[01:55]  * wallyworld installs skpye
[01:55] <lifeless> wallyworld: you said it had to be in the js file because it was built up like this
[01:56] <lifeless> wallyworld: but if it is only built up like this because it is in the js file, then that is circular logic
[01:56] <rick_h_> lifeless: it *needs* to be in the JS file for the unit test .html file to have access to it
[01:56] <wgrant> Exactly.
[01:56] <wallyworld> lifeless: i meant to convey it was in the js to avoid code cut and paste for tests
[01:56] <wgrant> @lifeless
[01:56] <wallyworld> i believe that's what i said, but it has been misinterpreted :-)
[01:56] <lifeless> rick_h_: I get that, but see my point about compilation above.
[01:57] <lifeless> who wants in on this kall ?
[01:57] <wallyworld> me as soon as i install skype
[01:58] <timrc> I have a general yui testing question (that I also asked in #yui) and since you guys have a bit of experience, perhaps you would know... I'm trying to test DOM events on a form, e.g. when I select an item from this dropdown it updates a textarea based on the choice, but do not know how to do this short of embedding the tests in the page
[01:59] <lifeless> timrc: sounds like you are testing across abstractions
[02:00] <timrc> probably ;) I accomplished this with jasmine using fixtures, but now I must yui
[02:00] <rick_h_> timrc: check out node-event-simulate to trigger events and then check callbacks are run/processed
[02:00] <timrc> rick_h_, but can I actually load the form into the dom in a seperate test page?
[02:01] <rick_h_> timrc: so no, you'd use the setUp of the suite to generate the html required
[02:01] <rick_h_> the .html page the tests run on is a giant fixture
[02:02] <rick_h_> you can preload with html, use setup/teardown to setup html/clear it between tests
[02:02] <rick_h_> timrc: see lib/lp/app/javascript/indicator/tests/test_indicator.js
[02:03] <rick_h_> if you can access the LP source for an example
[02:03] <timrc> rick_h_, will do. damn typing with a 7 mo old in your lap is challenging
[02:03] <rick_h_> heh, understand completely :)
[02:03] <wgrant> http://bazaar.launchpad.net/~launchpad-pqm/launchpad/devel/view/head:/lib/lp/app/javascript/indicator/tests/test_indicator.js
[02:03] <rick_h_> thanks wgrant, wifi here is awesome and didn't want to try to pull it up on my phone :)
[02:04] <lifeless> short urls R us
[02:04] <rick_h_> by awesome I mean fail
[02:04] <wgrant> rick_h_: What sort of phone do you have?
[02:04] <rick_h_> nexus
[02:04] <wgrant> rick_h_: I need someone with an iPhone to try that page
[02:04] <lifeless> handheld
[02:04] <wgrant> Ah
[02:04] <rick_h_> sorry, galaxy nexus
[02:04] <lifeless> wgrant: grab anyone from design
[02:04] <wgrant> iOS Safari doesn't like my CSS
[02:04] <wgrant> Making the line numbers crap.
[02:04] <wgrant> lifeless: Hah
[02:04] <rick_h_> guy here has one, sec let me get him the url
[02:05] <rick_h_> wgrant: have a guy tring it out
[02:06] <wgrant> rick_h_: Ah, thanks. We've had one report that it sucks, mostly want confirmation before I work out how to dig further.
[02:06] <wgrant> But I suspect that I have to throw it at someone else, since I don't have any way of running iOS Safari
[02:06] <wgrant> I love Apple so much.
[02:07] <rick_h_> wgrant: well it *looks* ok, the only issue is that the line number font is < code font so they don't line up
[02:07] <timrc> rick_h_, no way to say "load this url into the DOM" and then test the result? :)
[02:07] <wgrant> rick_h_: Yeah, that's the issue.
[02:07] <rick_h_> wgrant: so you run out of line numbers, but it reads ok otherwise
[02:07] <wgrant> Thanks.
[02:08] <rick_h_> timrc: so what'd you'd have to do is iframe into the .html page the content you want loaded, and then copy it out via JS in your setUp method
[02:08] <wgrant> The CSS needs redoing, but it works on desktop Trident/WebKit/Gecko/Presto :(
[02:08] <rick_h_> timrc: off the top of my head, the issue is that it's raw plain .html so you can't *include*
[02:08] <timrc> rick_h_, ah clever, but I can sort of see where lifeless is comin from when he says "testing across abstractions"
[02:08] <rick_h_> wgrant: yea, I mean the colors/etc look ok
[02:08] <rick_h_> timrc: definitely
[02:09] <timrc> rick_h_, maybe jasmine encouraged bad behavior... typically you would test form interactions with selenium, no?
[02:09] <rick_h_> timrc: so if your code is responsible for the generation of the html it's less an issue
[02:09] <rick_h_> timrc: well you're hitting BDD vs TDD
[02:09] <rick_h_> timrc: it's a root thing that behaviour is much higher up the stack of a functional test
[02:10]  * wallyworld stabs apt-get update... sooooo sloooow
[02:10] <rick_h_> timrc: so the stuff you're doing with jasmine are really where the sst type stuff would come into play, or in YUI would be if you're creating full Y.Widgets that the html/interactions are tied into a single unit to test with
[02:10] <timrc> rick_h_, I think what I'll do for at least now is take my jasmine fixture and copy-paste it into my yui test html file that should achieve what you're talking about
[02:11] <rick_h_> timrc: rgr
[02:11] <rick_h_> timrc: it's something we've got to work on as we start to get more complicated and need higher level behavior tests than we currently run
[02:12] <lifeless> mmm
[02:12] <lifeless> so BDD doesn't want to test the whole stack
[02:12] <lifeless> thats a false meme
[02:12] <timrc> apparently people want to build armhf images yesterday, so I'll take the path of least resistance, here
[02:12] <rick_h_> timrc: yea, like that example wgrant posted, we generate bootstrap html in the test to run against, it's a common 'fixture' practice
[02:12] <lifeless> BDD wants to test the interactions between components - e.g. when A is the SUT test that asking A to do X results in A asking B for help
[02:13] <lifeless> TDD might also look at the state of A before and after, and BDD frowns more on that than pure TDD does
[02:13] <lifeless> but even within TDD there are huge differences of opinion there
[02:13] <rick_h_> right
[02:13] <lifeless> the key thing that *both* TDD and BDD say here
[02:13] <lifeless> is that if you are using a known good component
[02:13] <lifeless> DO NOT TEST IT
[02:13] <lifeless> test /how/ you use it.
[02:14] <rick_h_> right, so he's starting with a BDD "fixture" and wanting to copy/pull that into his TDD somehow as a "fixture"
[02:14] <lifeless> not what it does
[02:14] <rick_h_> in jasmine, it's including an external html file so he wants to "import" that into the YUI .html test file, but not a good way to do that since it's raw .html without server side includes/imports of any sort
[02:17] <lifeless> yeah
[02:17] <timrc> jasmine structures tests as it("should do this when this condition is met", function())
[02:17] <rick_h_> timrc: yea, and you can create a test in YUI that's "should do this ..." that get run after setUp()
[02:18] <rick_h_> we use the test_something_does_something: function format
[02:18] <rick_h_> but the text string "this should that" also work
[02:18] <rick_h_> it just doesn't nest like a jasmine tests would
[02:18] <lifeless> so I think I'm saying that testing here is really checking that the event is raised, and that the widget is subscribed to it
[02:19] <lifeless> testing between them is a bit odd
[02:19] <timrc> so maybe this is actually a job for something higher up the stack, when the user selects item A, the textarea is populated with X, Y, Z ?
[02:19] <rick_h_> yea, normally we'd split the test. One that the event is fired by mocking the callback
[02:20] <rick_h_> and secondly, that given a method with the right/wrong input data that the callback does what we think it should do
[02:20] <rick_h_> timrc: right, that starts to sound like a live functional test which might be run via sst
[02:20] <rick_h_> or you could test that when the user selects an item, an event is fired with A's data
[02:21] <rick_h_> and then, firing a custom fake event with data XXX, the textarea will populate with other stuff
[02:21] <rick_h_> so two different sets of tests, one against the select/drop down, and one against the textarea
[02:21] <rick_h_> that'd be breaking it more into unit tests, using two suites, you could have different setUp() and tearDown() and those would bootstrap a select element to test against
[02:22] <rick_h_> and the second suite would setup a textarea that you test against
[02:22] <wgrant> StevenK: How goes the AccessPolicy creation?
[02:23] <rick_h_> oh StevenK so I heard convoy RT is right after the librarian san stuff fyi
[02:26] <timrc> rick_h_, I'm quickly learning why QA is its own discipline, but I'm happy to learn.  I fear that the complexity of testing is going to prevent me from getting very flashy in Offspring :)
[02:26] <rick_h_> timrc: yea, I mean that's why it's a giant can of compromise
[02:26] <wgrant> rick_h_: librarisan is hopefully only a couple of days away :)
[02:26] <rick_h_> the idea is that you get somehting that tests, you can add things you break to, but it's always going to have gaps/wholes
[02:27] <rick_h_> wgrant: ooh, that makes me so happy
[02:27] <rick_h_> it sounded like it was something rather large/far out
[02:27] <wgrant> Well
[02:27] <wgrant> It's actually running partly on the SAN atm
[02:27] <wgrant> Just on the old machine via NFS.
[02:27]  * timrc hisses at the mention of NFS
[02:27] <wgrant> The firewall was opened this morning, so it's just a couple of deployment and monitoring things left before we can switch.
[02:29] <wallyworld___> rick_h_: lifeless: finally got skype installed
[02:29] <rick_h_> wallyworld___: cool
[02:30] <lifeless> wallyworld___: rick_h_: ok, gimme a couple minutes to put a load of washing on
[02:30] <wallyworld___> ok
[02:30] <rick_h_> lifeless: rgr
[02:31] <rick_h_> I've got 30min before close
[02:31] <wallyworld___> rick_h_: i tried calling you but my request was rejected
[02:32] <rick_h_> wallyworld___: sorry, missed your request, added you to my contact list now
[02:36] <lifeless> wallyworld___: ah, if you're hosting, call me in
[02:38] <timrc> rick_h_, anyway, thanks for the help, I think I have enough to go forward.  Really appreciate it
[02:53] <StevenK> wgrant: I still have test failures. :-(
[02:53] <wgrant> StevenK: Oh?
[02:54] <StevenK> wgrant: Let me pastebin a diff and the failures
[02:54] <wgrant> That would be ideal.
[02:57] <StevenK> wgrant: http://pastebin.ubuntu.com/862865/
[02:59] <wgrant> StevenK: What happens if you try to run it manually?
[03:00] <wgrant> It's also not inconceivable that you might have to commit/abort the transaction before you can see the result.
[03:00] <StevenK> wgrant: http://pastebin.ubuntu.com/862870/
[03:01] <StevenK> But __call__ in the job calls commit :-(
[03:01] <wgrant> That's in the job.
[03:02] <wgrant> Which is hopefully a separate process, and therefore a separate transaction.
[03:02] <StevenK> No other test calls commit after self.runHourly()
[03:03] <wgrant> Ah
[03:03] <StevenK> I'm of the opinion that I've missed something utterly stupid and I've been chasing it for hours.
[03:03] <wgrant> You've run make schema to ensure that the security change made it to launchpad_ftest_template?
[03:03] <StevenK> Yup.
[03:04] <wgrant> Ensure that statement logging is enabled and watch your postgres log during the test run.
[03:04] <wgrant> also, most of __call__  can be replaced with a list comprehension.
[03:04] <StevenK> Oh?
[03:05] <StevenK> I'm already using one in what I thought was a clever way.
[03:05] <wgrant> You construct an empty list, then iterate over a tuple, on each iteration adding some tuples to the list.
[03:06] <wgrant> policies = [(distro, policy) for distro in self.findDistributions()[:chunk_size] for policy in (USERDATA, PROPRIETARY)]
[03:07]  * StevenK sprinkles in AccessPolicyType
[03:07] <wgrant> Although this is unfiltered, so you can also just use itertools.product
[03:08] <lifeless> ok, skype call done
[03:08] <lifeless> tl;dr for folk here:
[03:08] <lifeless>  - handlebars really wants to be treated more like C - server side compile, separate source, mustache is a middle ground
[03:09] <lifeless>  - can possible just use an iframe to suck in templates we need, ian is trying that, should work on mustache too [for the tests]
[03:10]  * StevenK laughs at bigjools new profile picture
[03:10] <wgrant> Heh, yes.
[03:11] <StevenK> wgrant: LP_DEBUG_SQL=1 isn't good enough?
[03:11] <wgrant> StevenK: Not sure if that works for garbo subprocesses in tests.
[03:11] <StevenK> Right
[03:11] <wgrant> We often run subprocesses in a sanitised env.
[03:11]  * StevenK reaches for postgres' conf
[03:12] <lifeless> can whitelist that parameter probably
[03:13] <StevenK> I leave it off so /var doesn't fill up after a days test runs
[03:14] <lifeless> sure
[03:14] <lifeless> I meant for subprocs
[03:14] <lifeless> so that when you set it, it wrks
[03:14] <wgrant> I leave it on because my hard disk isn't from 1990.
[03:14] <StevenK> /dev/mapper/sys-var   4.6G  1.6G  2.8G  37% /var
[03:17]  * StevenK sighs at the hidden scrollbars crap
[03:17] <StevenK> Makes dealing with long output bloody tedious
[03:18] <wgrant> Does gnome-terminal have scrollbars at all any more?
[03:18] <wgrant> Oh, it does.
[03:18] <wgrant> But the thumb is invisible afaict.
[03:19] <StevenK> Right, 100,000 lines of output later
[03:19] <StevenK> (I wish I was joking)
[03:20] <lifeless> rick_h_: oh, and the site I was pointed at demoing yui_handlebars has the precompiled templates referenced by its combo loader
[03:21] <lifeless> rick_h_: so I think that is actually more common than you may think :)
[03:23] <StevenK> wgrant: http://pastebin.ubuntu.com/862893/
[03:24] <wgrant> StevenK: So, garbo seems to be behaving properly. What about the test?
[03:25]  * StevenK is just about to dump everything containing accesspolicy into a paste
[03:28] <StevenK> wgrant: http://pastebin.ubuntu.com/862902/
[03:30] <wgrant> StevenK: So, I would suggest breaking with pdb and then poking around in psql
[03:30] <wgrant> Or potentially from within pdb if you are brave.
[03:30] <StevenK> Perhaps my find* and isDone methods are to blame
[03:31] <wgrant> I doubt it.
[03:31] <wgrant> We can see they're being inserted.
[03:32] <wgrant> Ah, you may be right.
[03:32] <wgrant> Distro 3 is not new.
[03:32] <StevenK> Oh?
[03:33] <wgrant> Also, calling AccessPolicy.create like that is illegal
[03:33] <wgrant> getUtility(IAccessPolicySource).create
[03:38] <StevenK> What the? Now it's working?
[03:39] <rick_h_> lifeless: linky?
[03:39] <rick_h_> lifeless: on the precompiles template stuff?
[03:39] <StevenK> rick_h_: I think's awesome you're using using convoy with bookie
[03:39] <StevenK> s/'s/ it's/
[03:40] <rick_h_> StevenK: yea, getting some good tests out of it and swapping code back/forth
[03:40] <rick_h_> StevenK: though it's nginx vs apache
[03:40] <rick_h_> well, gunicorn in dev, but in prod nginx
[03:40] <StevenK> The nginx fanbois turn me off trying it
[03:41] <rick_h_> heh, I'm a fan. I read through an apress book (I think) and since I"m running ec2, lower memery usage ftw
[03:41] <StevenK> There are a bunch of them in #linode and anytime someone turns up with an Apache problem, regardless of the problem, they spend hours trying to convert the guy to use nginx
[03:41] <rick_h_> heh
[03:42] <rick_h_> yea, well I know apache has a lot more uses
[03:42] <rick_h_> but for lower memory it's a win
[03:43] <StevenK> wgrant: So here's an interesting data point. If I run test_AccessPolicyDistributionAddition in isolation it works, but running test_garbo causes it to fail
[03:48] <lifeless> rick_h_: grah, uhm, lets see
[03:48] <rick_h_> lifeless: np, just curious
[03:50] <lifeless> rick_h_: beta.tdp.me
[03:50] <lifeless> rick_h_: http://tdp.me/combo?template/template-goal-table/template-goal-table-min.js
[03:51] <rick_h_> lifeless: ah cool
[03:52] <lifeless> irssi-2012-02-09:09:00 #launchpad-dev: < rick_h> lifeless: so this guys in #yui gave me this for some handlebar exapmles: http://beta.tdp.me/static/scripts/bundle.js http://beta.tdp.me
[03:53] <lifeless> :)
[03:53] <rick_h_> yea, I remember seeing it now
[03:53] <lifeless> dunno who, jshirley I think
[03:53] <rick_h_> yep
[03:53] <lifeless> the nginx casual approach to http turns me off :)
[03:55] <StevenK> wgrant: Running under garbo I never see the created distribution
[03:57] <rick_h_> wallyworld___: http://jsfiddle.net/83xZY/ seems to work
[03:59] <rick_h_> wallyworld___: note that it's running off the on load event
[03:59] <wallyworld___> rick_h_: i get an internal yui error
[03:59] <wallyworld___> will try of the onload
[03:59] <wallyworld___> i also tried via the dom element directly but got a permission error
[04:00] <rick_h_> wallyworld___: bah, that's what I was afraid of, it has to be same domain and prefix
[04:00] <rick_h_> file://
[04:01]  * wallyworld___ tries that
[04:01] <wgrant> sameorigin on the file scheme is a bit awkward :/
[04:02] <rick_h_> yea, but it's meant to prevent http/https crossing
[04:02] <rick_h_> I'm guessing more https making http calls
[04:02] <wgrant> I mean I don't think any two URLs from the file scheme are considered same-origin.
[04:02] <rick_h_> ah, yea I'm not sure of that
[04:03] <rick_h_> I was hoping maybe the issue he hit was that the browser was file:// while his iframe src="../../" without an explicit file:// :/
[04:03] <wgrant> (the scheme distinction is most often useful to prevent HTTP from doing HTTPS XHR)
[04:03] <wgrant> Ah
[04:03] <wgrant> "Starting in Gecko 1.9, files are allowed to read only certain other files.  Specifically, a file can read another file only if the parent directory of the originating file is an ancestor directory of the target file. Directories cannot be loaded this way, however."
[04:03] <rick_h_> but I'm guessing at this point
[04:03] <wallyworld___> rick_h_: nah, still permission denied
[04:04] <rick_h_> heh, because it's not hard enough...
[04:04] <rick_h_> well then ajax requests won't fly either...
[04:07] <StevenK> Why the heck isn't this new distro turning up in the store? :-(
[04:07] <wallyworld___> rick_h_: i'm about to give up and say that i need to land the mp with the template in the js
[04:08] <rick_h_> wallyworld___: I'll +1 that with a note that it's something I'll investigate as I work on fixing hte combo loader going forward
[04:08] <wallyworld___> ok, excellent. thanks
[04:09] <rick_h_> it'll be a large todo item so it doesn't fall away, but as part of the combo loader completion story
[04:09] <rick_h_> it's going to require more testing than I can do past my bedtime :)
[04:09] <wallyworld___> yeah :-)
[04:09] <rick_h_> sorry again that it fell into your lap like this
[04:09] <wallyworld___> i just want to get myself unblocked for now
[04:09] <rick_h_> wallyworld___: definitely
[04:10] <wallyworld___> rick_h_: no need to say sorry, i was dreading this issue as well
[04:10] <StevenK> What's the issue?
[04:10] <rick_h_> StevenK: long story :)
[04:10] <rick_h_> wheee, and mailman day approacheth!
[04:10] <wallyworld___> StevenK: we want to have the mustache template in one place
[04:10] <wallyworld___> availabole for yui tests
[04:10] <wallyworld___> and for prod
[04:10] <StevenK> rick_h_: It's been Mailman day here for 15 hours
[04:11] <wallyworld___> and it's hard to do
[04:11] <rick_h_> StevenK: heh, just got my first one of the day
[04:11] <StevenK> Oh yeah, mail. I guess I should read that.
[04:11] <rick_h_> wallyworld___: you try out the auto js builder bits I emailed the list about?
[04:12] <rick_h_> I need to find people that can try/test that if you get some future JS work to tinker with
[04:12] <stub> w00t. pg9.1.3 packages out, containing the plpythonu fix we want for inplace upgrades
[04:12] <rick_h_> wallyworld___: or someone else on your team
[04:12] <wallyworld___> rick_h_: not yet, but it looks nice
[04:12] <rick_h_> wallyworld___: k, let me know if you guys can give it a spin and such
[04:13] <rick_h_> eventually want to see if we can mail the -tech about it if it works out ok
[04:13] <wallyworld___> rick_h_: will do. it's on my todo list to try out for sure
[04:13] <rick_h_> ok, time to go pass out, night
[04:13] <wallyworld___> rick_h_: see ya. thanx for your time
[04:25] <wgrant> oops
[04:25] <wgrant> Was wondering why one of my triggers was taking 25ms to reflatten a bug and all its tasks.
[04:25] <wgrant> Forgot that I hadn't removed the 250 tasks I'd created on the bug yesterday.
[04:41] <stokachu> http://pastebin.com/ah8aLQdL - ive managed to setup the authorization header which then seems to redirect me properly from /people/+me to /~adam-stokes
[04:41] <stokachu> but then i get a 303 see other error
[04:41] <stokachu> any ideas
[04:41] <wgrant> stokachu: 303 is the redirect
[04:42] <wgrant> It's not an error.
[04:42] <wgrant> Also, *really* not a good idea to give your OAuth tokens to the world.
[04:43] <wgrant> You probably want to revoke that one.
[04:43] <stokachu> i will
[04:43] <stokachu> is staging still down?
[04:43] <wgrant> It should be up.
[04:44] <wgrant> Has only been down for a couple of hours over the last few weeks.
[04:44] <stokachu> ah , there was a code update an hour ago
[04:44] <wgrant> Hmmm
[04:44] <wgrant> That should only take it down for a couple of minutes, I'd expect.
[04:44] <wgrant> Perhaps something is going wrong with the updates.
[04:45] <wgrant> It's up now.
[04:45] <stokachu> ah ok... so im in this redirect from the last response
[04:45] <stokachu> but should i be calling ~adam-stokes directly?
[04:46] <wgrant> Depends on your HTTP library.
[04:46] <wgrant> Some will follow the redirect automatically, others won't.
[04:46] <stokachu> hmm let me try to hardcode my name in and see what i get
[04:47] <wgrant> /people/+me does an HTTP redirect to the current logged in user.
[04:47] <StevenK> Or /~
[04:48] <stokachu> ah yea so this oauth library isn't following redirect
[04:48] <stokachu> i dont guess anyone is familiar with drupal 7 and its oauth stuff
[04:49] <StevenK> There's a Drupal 7 now?
[04:49] <StevenK> :-)
[04:49] <stokachu> lol
[05:04] <wgrant> You know
[05:04] <wgrant> It would be really nice if we had a sensible data access layer.
[05:04] <wgrant> So we could, like, not be terrible.
[05:06] <stokachu> its only a little complicated
[05:06] <stokachu> not to bad
[05:06] <wgrant> Not talking about the API, but that's not ideal either :)
[05:06] <stokachu> haha
[05:08] <StevenK> Hmmmmm, what database user does mail handling use?
[05:09] <wgrant> StevenK: Should be processmial
[05:09] <wgrant> processmail
[05:16] <stokachu> so if anyone is curious i have a 90% working drupal module for launchpad
[05:17] <stokachu> it just doesn't do anything yet but auth
[05:17] <stokachu> :X
[05:19] <wgrant> stokachu: What are you planning to use it for?
[05:20] <StevenK> wgrant, wallyworld___: Either of you feel like reviewing https://code.launchpad.net/~stevenk/launchpad/change-bug-privacy-via-mail/+merge/95312 ?
[05:20] <stokachu> mainly a dashboard between lp private and salesforce
[05:20] <wallyworld___> StevenK: i'm deep in some code changes, can do soon
[05:20] <wgrant> StevenK: OMG SOMEONE FIXED IT
[05:20]  * wgrant +1s
[05:20] <StevenK> Hahah
[05:21] <StevenK> I tagged the bug disclosure, I figured it was tiny enough we could claim it as a feature branch
[05:21] <stokachu> and possibly some helper stuff for submitting SRU's
[05:40] <StevenK> wgrant: So, looking at the not found page, you'd like some vertical whitespace between the heading and the first paragraph?
[05:41] <wgrant> StevenK: I don't know.
[05:41] <wgrant> Users currently don't get it.
[05:41] <wgrant> So the page needs *some* change.
[05:42]  * StevenK sprinkles in <strong> along with changing the heading to "Not Found" and puts it up for review
[05:43] <StevenK> IE, let's make a token effort and see what Dan comes back with
[07:46] <czajkowski> aloha
[07:49] <stub> Didn't I add a 'previous OOPS' feature?
[07:50] <stub> OOPS caused due to thread state, so I need to know the previous screwup. Could have sworn I added that into the OOPS already...
[08:04] <stub> Did... so why isn't it in my OOPS?
[08:05] <lifeless> stub: you did
[08:07] <stub> Yer, found other OOPSes with the key. But the one I'm interested in doesn't have it. Might mean it was the first OOPS generated by that thread, but I somehow doubt it.
[08:08] <stub> But it is generated from beforeTraverse, so things might get weird.
[08:52] <adeuring> good morning
[09:02] <mrevell> hi
[10:14] <StevenK> danhg: Hai, have you seen https://code.launchpad.net/~stevenk/launchpad/not-found-page/+merge/95313 ?
[10:15] <danhg> Hmmm.... thanks StevenK
[10:21] <mabac> StevenK, hi there. did you get a chance to look at salgado's changes on https://code.launchpad.net/~linaro-infrastructure/launchpad/workitems-migration-script/+merge/93883 ? just wondering if there's anything I can handle it before he wakes up. :)
[10:28] <StevenK> mabac: Hai. I have commented.
[10:29] <mabac> StevenK, cool, thank you
[10:36] <mabac> StevenK, let's see if I understand that. :) you don't want us to revert the last change, it's only about setting that feature flag, right?
[10:41] <StevenK> mabac: So, I'd like to see the loop move from the experimental loops to the usual one, and a feature flag a guard when it runs
[10:42] <mabac> StevenK, ok got it. thanks
[10:43] <StevenK> mabac: Of course, along with adding two tests, one to see the job doesn't run with no feature flag, and the inverse.
[10:44] <mabac> StevenK, of course
[12:51] <rick_h_> morning
[12:54] <czajkowski> rick_h_: ello
[13:33] <mabac> rick_h_, good morning. thanks for reviewing my branch! I have separated the parsing and validating parts of parseLine but don't know if there is a better error to raise when parsing than LaunchpadValidationError?
[13:34] <rick_h_> mabac: I'm not sure on that end. I'll see what jcsackett brings up on that front
[13:34] <mabac> rick_h_, ok thanks
[14:55] <jcsackett> rick_h_, mabac: almost done with that MP. i see no problem with LaunchapdValidationError, since ulitmately the method is only used as part of the set of calls from validate.
[14:55] <jcsackett> if you didn't raise it as such there, you would probably want to reraise from within validate anyway.
[14:56] <rick_h_> jcsackett: ok cool
[14:57] <mabac> jcsackett, cool thanks.
[15:10] <jcsackett> mabac: questions/comments posted on your MP.
[15:11] <mabac> jcsackett, thank you. I'm on it
[15:11] <jcsackett> mabac: cool. there's nothing major, just a few little things.
[15:16] <mabac> jcsackett, doesn't look to bad. ;) I'll fix it up today.
[15:16] <jcsackett> mabac: awesome. thanks. :-)
[15:17] <mabac> jcsackett, I can remove that assert entirely btw. it can just catch programming errors as you noted
[15:17] <jcsackett> mabac: that's what i thought.
[15:17] <jcsackett> glad i wasn't off base.
[15:33] <salgado> mrevell, did you see my email about announcing the work items changes we're doing in LP?
[15:35] <mrevell> salgado, Sorry yes. I'll be on the phone for another 20-30 minutes then I'll replu.
[15:35] <mrevell> s/replu/reply
[15:36] <salgado> mrevell, that's cool, thanks!
[15:51] <salgado> jcsackett, StevenK reviewed https://code.launchpad.net/~linaro-infrastructure/launchpad/workitems-migration-script/+merge/93883 and said he was happy with it but wanted a new feature flag to prevent it from running on production until we're ready.  I was wondering if you'd be willing to review the feature flag changes and land it for me so that we can start QAing it in production?
[15:51] <salgado> s/production?/staging?/
[15:52] <sinzui> danhg, do you want try a screen share where we build a mockup together?
[16:07] <danhg> Hey sinzui, That sounds great. I'm also working with Matthew on a broader process for testing -> mock-ups -> implementation.
[16:08] <sinzui> danhg, great We can try this now and when you are ready
[16:08]  * sinzui has never tied hangouts screen sharing
[16:12] <salgado> matsubara, if you'd like to try and break the new work-items UI, it's at lp:~linaro-infrastructure/launchpad/workitems-widget
[16:12] <matsubara> salgado, thanks
[16:12] <matsubara> salgado, is it being reviewed?
[16:15] <salgado> matsubara, yes, although most of the changes requested were in tests
[16:15] <matsubara> ok
[16:16] <matsubara> salgado, by tomorrow it'll be on qastaging, do you think?
[16:17] <salgado> matsubara, that depends on QAing the migration script, I'd say.  do you need to wait until it's there to QA it?
[16:17] <matsubara> yeah, it's better to do it on staging or qastaging with the full db
[16:18] <jcsackett> salgado: sure, i'll take a look at it.
[16:19] <salgado> matsubara, in this case the UI is just a text entry, similar to the whiteboard.  the only way to break it is by entering unparsable stuff and hoping for the worse, so having it on staging won't make any difference
[16:20] <matsubara> ok
[16:25] <salgado> mrevell, I guess you also didn't have time for the help text (https://bugs.launchpad.net/launchpad/+bug/944119)?
[16:25] <_mup_> Bug #944119: Add help popup to the new work-item editor <Launchpad itself:New> < https://launchpad.net/bugs/944119 >
[16:31] <mrevell> salgado, Hey, I can still do this. Is it okay if I just give you the text?
[16:31] <salgado> mrevell, definitely!
[16:32] <salgado> mrevell, as for the announcement, do you guys take care of that as well or should we write it ourselves?
[16:33] <mrevell> salgado, We can take care of that. It'd be great to have an idea of anything in particular you want us to say, though. When do you expect to be ready to make the announcement?
[16:33] <salgado> mrevell, ok, I'll write down the important points.  hopefully early next week
[16:34] <mrevell> Thanks. I'll get the help text to you tomorrow.
[16:34] <salgado> mrevell, great, thanks!
[16:37] <mabac> jcsackett, there I believe I've fixed your suggestions for lp:~linaro-infrastructure/launchpad/workitems-widget
[16:39] <mabac> jcsackett, I'll clock off now but if there's anything that's not clear salgado-lunch will be able to answer and I'm back online in ~14 hrs :)
[16:40] <czajkowski> salgado-lunch: give me a shout when you;'re back
[16:40] <czajkowski> we should talk :)
[16:41] <abentley> adeuring: I've got tests that prove a job runs under Celery.  Any advice on how to clean them up? ~abentley/lazr.jobrunner/run-via-celery
[16:41]  * adeuring is looking
[16:46] <adeuring> abentley: "make check" just gives me "TypeError: 'NoneType' object is not callable" ...
[16:46] <abentley> adeuring: Yeah, I talked to barry about that and he couldn't help me, so for now I'm using nosetests.
[16:46] <adeuring> abentley: how do I start one?
[16:47] <abentley> bin/python `which nosetests` should do it.
[16:47] <adeuring> ah, got it
[16:48] <abentley> adeuring: I particularly dislike the way I'm finding the celeryd binary.  Seems there should be a better way.
[16:49] <abentley> adeuring: Also, the fact that config files are python modules prevents me from generating a config in a temp directory as I normally would.
[16:52] <adeuring> abentley: what is your problem with the cleanup?
[16:53] <abentley> adeuring: I don't know what you mean.  The 'NoneType' is not callable thing?
[16:53] <adeuring> abentley: I menat your quetion "Any advice on how to clean them up?"
[16:55] <abentley> adeuring: I think the implementation is dirty, particularly the way I find the celeryd binary and the fact that the testing config is a file in the tree.
[16:56] <abentley> adeuring: Do you have any suggestions for improving the test implementation?
[16:56] <adeuring> abentley: "cmdname = os.path.join(get_root(), 'bin/celeryd')" ? I don't see any better option
[16:59] <adeuring> abentley: regarding the configuration of celeryd: the config module could read the parameters from a temp file, in order to set things like BROKER_HOST etc
[16:59] <abentley> adeuring: How would it find the temp file?  Environment variables?
[17:00] <adeuring> abentley: rigt. Or use some hard wired path: /tmp/celery_test.cfg or whatever
[17:02] <adeuring> abentley: slightly crazy idea: pipe the config data: you use popen()...
[17:03] <abentley> adeuring: And then config.py reads stdin?
[17:03] <adeuring> abentley: yes, but may be soimply crazy...
[17:03] <adeuring> I don't know if celeryd itself checks stdin...
[17:46] <salgado> hi czajkowski
[18:09] <czajkowski> salgado: howdy
[18:09] <czajkowski> salgado: are you free tomorrow to talk re getting information out about blurprints?
[18:10] <jelmer> pun intentional ? :)
[18:11] <salgado> czajkowski, sure. tomorrow around 11:00 UTC ok with you?
[18:16] <czajkowski> salgado:
[18:16] <czajkowski> salgado: you on the canonical calender?
[18:18] <salgado> czajkowski, yep, salgado should be my username there
[18:18] <salgado> I see you've found me already :)
[18:19] <wilx> Hi.
[18:20] <jelmer> hi wilx
[18:20] <czajkowski> salgado: lovely talk tomorrow so
[18:44] <salgado> deryck, hi there. do you have any idea how hard it'd be to fix bug 415365?
[18:44] <_mup_> Bug #415365: Errors are not handled properly in inline text editing <lp-bugs> <Launchpad itself:Triaged> < https://launchpad.net/bugs/415365 >
[18:44] <deryck> salgado, hey, let me look....
[18:47] <deryck> salgado, by fix, do you mean prevent the error, or do you mean cope with the error better?
[18:48] <salgado> deryck, just display the body of the http response when it's not a 200, I'd say
[18:49] <deryck> salgado, right.  so to do that, it should be fairly straightforward, making showError do the right thing, rather than inserting into the inline widget as it's trying to do now.
[18:49] <salgado> deryck, some of those widgets are used on fields that have validators (e.g. bug tags and the new blueprint work-item) so there will always be errors; we just need to display them
[18:51] <salgado> deryck, oh, so showError already has the error message from the response? I thought that's what we were missing and I'd have to get that
[18:52] <deryck> salgado, I think it has the error, and just not dealing with it well.
[18:52] <deryck> salgado, but it's been awhile since I touched that :)
[18:54] <salgado> deryck, yeah, and I'm completely clueless when it comes to YUI.  can I stick a "debug" call in there to inspect it in the browser?  I seem to recall doing something like that
[18:54] <deryck> salgado, yup.  add "debugger;" on the line you want to break on and firebug or chrome console with break there.
[18:54] <salgado> ah, debugger
[18:54] <salgado> cool, will try that
[18:54] <deryck> salgado, you can also open the file in those tools and manually click lines to add break points without editing code.
[18:57] <salgado> deryck, sounds more promising as it looks like I'd need to regenerate launchpad.js after changing showError in the code itself, no?
[18:57] <deryck> salgado, yes, you'd need to run make jsbuild again.
[19:03] <salgado> deryck, what's weird is that the validate() method uses showError (when the widget doesn't accept empty input) and in that case it works fine, correctly displaying the message passed to it
[19:04] <deryck> salgado, so maybe the message is getting dropped somehow?
[19:05] <salgado> deryck, nope, showError is being passed the body of the response
[19:15] <salgado> deryck, showError inserts the error on the correct place but since this is a multi-line field the text area appears on top of that
[19:18] <deryck> salgado, I'd have showError open an overlay, rather than try to insert into the page.
[19:18] <deryck> there's tons of error_overlay examples lying around
[19:18] <salgado> yeah, that makes sense; /me tries that
[19:24] <lifeless> james_w: you should show pkgme to gary_poster
[19:24] <james_w> lifeless, for use in something
[19:24]  * gary_poster googles pkgme
[19:24] <james_w> lifeless, or just to get some stuff packaged?
[19:25] <lifeless> james_w: I believe he is, or has, someone packaging up a new thing
[19:25] <lifeless> james_w: which is in python
[19:25] <lifeless> james_w: and so a prefect candidate
[19:25] <gary_poster> james_w, yes.  Very simple package, and bac is writing up descriptions on how to do it
[19:25] <james_w> gary_poster, a standard setup.py app?
[19:25] <gary_poster> yes james_w
[19:26] <james_w> it should work then
[19:26] <gary_poster> and bac found the existing packaging instructions worthy of simplifying and rewriting
[19:26] <james_w> that's a good thing to do anyway
[19:26] <gary_poster> cool
[19:26] <james_w> but pkgme may take the pain out of simple things entirely
[19:27] <gary_poster> thanks lifeless, james_w .  bac, http://pkgme.net/ fwiw
[19:27] <james_w> lp:pkgme
[19:27] <gary_poster> saw that too, but the instructions seemed nicer to link to :-)
[19:27] <lifeless> right, thats my good deed for the day, off to create havoc
[19:28] <gary_poster> heh
[19:31] <rick_h_> jcsackett: ping, can you peek at: https://code.launchpad.net/~rharding/launchpad/911857_extract_js/+merge/95438
[19:31] <rick_h_> sorry for the big add/remove due to tabbing in
[19:36] <jcsackett> sure, rick_h_.
[19:36] <rick_h_> jcsackett: ty
[19:48] <bac> thanks gary_poster and james_w
[19:50] <bac> gary_poster: it may be useful for the py part of charm-tools
[19:50] <gary_poster> bac, makes sense
[19:56] <bac> james_w: should pkgme work for precise?  there is no ppa and the description says only natty and oneiric
[19:57] <james_w> bac, yes it should
[19:57] <bac> great
[19:57] <james_w> bac, where do you see natty and oneiric?
[19:57] <james_w> I'll update it
[19:58] <bac> james_w: https://launchpad.net/~pkgme-committers/+archive/dev/+packages ... but now that i look closely that seems to be generated text
[19:58]  * james_w copies forward
[19:59] <james_w> done
[19:59] <james_w> yeah, the text is autogenerated, it has updated now
[20:03] <salgado> jcsackett, if you have a few more minutes, I've just proposed a new one. this time it's trivial: https://code.launchpad.net/~salgado/launchpad/bug-415365/+merge/95447
[20:12] <salgado> how do I run a test under lib/lp/app/javascript/tests/?
[20:12]  * salgado tries lading the html files on his browser
[20:12] <rick_h_> salgado: yep, that works for dev
[20:13] <rick_h_> and then you can load it with the test runner based on the filename
[20:13] <rick_h_> which test file are you running?
[20:13] <jcsackett> rick_h_: r=me.
[20:14] <rick_h_> jcsackett: ty
[20:14] <jcsackett> salgado: can you include a screenshot, since this is changing some of what's displayed on error?
[20:17] <salgado> jcsackett, sure, https://bugs.launchpad.net/launchpad/+bug/415365/+attachment/2798570/+files/overlay-error.png
[20:17] <_mup_> Bug #415365: Errors are not handled properly in inline multi-line text editing <lp-bugs> <Launchpad itself:Triaged> < https://launchpad.net/bugs/415365 >
[20:18] <salgado> rick_h_, inlineedit/tests/test_inline_edit.js (adding a test for the bug above)
[20:18] <rick_h_> salgado: yea, so ./bin/test -x -cvvt inline_edit would run those tests
[20:19] <salgado> rick_h_, nice, I'd never have expected that to work
[20:19] <rick_h_> salgado: but yea, I'd just run from the browser usually in dev and the cmd line just to make sure things are cool from the html5 browser
[20:19] <rick_h_> autoreload makes the browser version nice
[20:30] <rick_h_> salgado: replied to your MP
[20:30] <rick_h_> let me know if it doesn't make any sense
[20:31] <salgado> rick_h_, heh, just found that out myself; one of the tests was failing :)
[20:31] <salgado> I added lp.app.errors but that wasn't enough
[20:31] <rick_h_> salgado: yep, figured you were onto that when you asked about running tests
[20:31] <rick_h_> right, errors requires someoverlay modules
[20:32] <rick_h_> make sure you link to them out of the build directory like the others pls
[20:36] <bac> hi james_w, i've grabbed the trunk of pkgme and installed it with setup.py.  attempting to run errors due to non-execute bits on all of the 'wants'.  i manually chmod all of them but get a different error.  did i do something fundamentally wrong?
[20:38] <rick_h_> salgado: running away, but ping me if you hit any issues and I'll be checking in later
[20:38] <salgado> rick_h_, link to what?
[20:38] <james_w> bac, nope
[20:38] <rick_h_> salgado: ok, just that the html files links should be like the current ones, through build/...
[20:38] <james_w> bac, the executability thing is a known problem with distutils
[20:39] <james_w> bac, what's the other error you got?
[20:39] <rick_h_> salgado: such as <script type="text/javascript" src="../../../../../../build/js/lp/app/formoverlay/formoverlay.js"></script>
[20:39] <salgado> oh, I see
[20:39] <bac> james_w: vala backend returning non-integer
[20:39] <james_w> bac, hmm, odd
[20:39] <salgado> rick_h_, let me double check, but I guess it'd fail if I had it wrong (I copied from another test.html file)
[20:39] <james_w> bac, did it say what it did return?
[20:40] <rick_h_> salgado: you should be good then if you copied since I updated them all recently
[20:40] <salgado> rick_h_, yep, it looks just like the others in that template :)
[20:40] <rick_h_> salgado: coolio
[20:41] <bac> james_w, wait that seems to be another permission problem with with auto_conf_config
[20:42] <bac> james_w, i'll go forward fixing the execute privileges
[20:42] <james_w> bac, ah, helpers/* will need to be +x too
[20:42] <bac> ok
[20:44] <rick_h_> deryck: jcsackett had to run, can you second my ok on this please? https://code.launchpad.net/~salgado/launchpad/bug-415365/+merge/95447
[20:46] <deryck> rick_h_, done.
[20:46] <rick_h_> ty
[20:46] <salgado> I'm trying to run js tests inside an lxc and am getting "RuntimeError: Gtk couldn't be initialized".  any ideas what I'm missing?
[20:49] <rick_h_> salgado: http://bazaar.launchpad.net/~sinzui/html5-browser/trunk/view/head:/README installed?
[20:49] <salgado> rick_h_, I think I do; I get that when import html5browser
[20:49] <rick_h_> ok
[20:50] <rick_h_> so most of these things need  xvfb  but not sure why you'd get a gtk issue
[20:50] <rick_h_> sinzui: any ideas? ^
[20:50] <rick_h_> salgado: have a traceback to paste perhaps?
[20:51] <salgado> this is what actually happens when the test imports html5browser: http://paste.ubuntu.com/864114/
[20:51] <lifeless> folk who would like a nicer deploy report should check out lp:~james-w/+junk/deploy-tracker
[20:52] <salgado> rick_h_, seems to work with xvfb-run
[20:53] <lifeless> http://ec2-23-20-113-165.compute-1.amazonaws.com/ - turn on 'team info' during SSO handshaking
[20:56] <sinzui> salgado, that looks like the wrong screen.
[20:57] <sinzui> salgado, does html5browser work when run from a console on out owne machine?
[20:57]  * sinzui should have added the show_browser option so we could see it run
[20:58] <salgado> sinzui, I tried 'bin/test -t inline_edit' inside a container and it failed with that traceback when html5browser tried to import Gtk.  running with xvfb-run worked
[20:58] <salgado> I don't have html5browser installed on my machine; only on that container where I run LP
[20:59] <sinzui> salgado, okay. This is a bit out of my realm of confidence
[20:59] <sinzui> salgado, Is this lucid, oneiric or precise in the container
[20:59] <salgado> sinzui, oneiric
[21:00] <sinzui> okay, that is the version I wrote first and actually expect to work
[21:04] <sinzui> salgado, the official answer is that Gtk cannot find the display. If you always run in a container you may need to pass the display in the env. Maybe we need to smarten up our test script to warn if there is no display set
[21:04] <salgado> rick_h_, would you mind landing https://code.launchpad.net/~salgado/launchpad/bug-415365/+merge/95447 for me as well? :)
[21:07] <sinzui> I think html5browser should catch the check error and explain the display it thinks it has.
[21:08] <salgado> sinzui, indeed, with the DISPLAY set it works
[21:12] <sinzui> salgado, I reported Bug #944348 about this
[21:12] <_mup_> Bug #944348: warn when display is not set. <HTML5-browser:Triaged> < https://launchpad.net/bugs/944348 >
[21:14] <salgado> sinzui, nice, thanks!
[21:16] <rick_h_> salgado: ok, working on getting landing going
[21:23] <salgado> rick_h_, great, thanks again :)
[21:24] <rick_h_> salgado: np
[21:37] <abentley> deryck: There's no OCR.  Would you be able to review https://code.launchpad.net/~abentley/lp-dev-utils/ec2/+merge/95468 ?
[21:37] <deryck> abentley, sure.
[21:38] <abentley> deryck: thanks.
[21:42] <deryck> abentley, that's alot of python. :)  Is it all straight cut over from lp tree, except for the change about commit tags in MPs?
[21:44] <abentley> deryck: Here are the changes I made: http://pastebin.ubuntu.com/864191/
[21:44] <deryck> abentley, ah, that's very helpful thanks.
[21:45] <abentley> deryck: Mostly it's import name changes, but there are some minor tweaks.
[21:49] <deryck> abentley, looks fine.  And we know it works. :)  r=me
[21:51] <abentley> deryck: thanks!
[21:52] <lifeless> abentley: btw the location of trunk has changed
[21:52] <lifeless> abentley: its now lp:~canonical-launchpad-branches/lp-dev-utils/trunk (if you aren't using hte lp:lp-dev-utils alias)
[21:52] <abentley> lifeless: I used lp:lp-dev-utils
[21:58] <mtaylor> lifeless: hey! is it worth filing a ticket about slowness of mailing list messages?
[21:59] <lifeless> no
[21:59] <lifeless> we like it slow
[21:59] <mtaylor> awesome
[21:59] <lifeless> mtaylor: actually, there is one I think, and its a well known issue
[21:59] <lifeless> mtaylor: I can point you at the discussion on the -dev list if you like
[21:59] <lifeless> we're || close to a solution
[22:00] <mtaylor> I'll just take your word for it that you're aware and have it almost fixed
[22:00] <mtaylor> as you rarely lead me astray
[22:00] <lifeless> quadratic archive page writes
[22:00] <lifeless> sinzui has a grackle.
[22:00] <mtaylor> jeez
[22:00] <bigjools> has he seen a doctor?
[22:00] <mtaylor> that doesn't sound good
[22:01] <sinzui> I have not, but having spent about 9 hours out of my skull I think I might
[22:01] <sinzui> I still fear that If I yawn, the a hole in the universe will open and I will fall though it again
[22:02] <deryck> Later on, everyone.
[22:02] <sinzui> mtaylor, There is a specific critical bug that is the causes of slowness. I speculated about how to address the immediate concern
[22:04] <mtaylor> sinzui: awesome
[22:04] <sinzui> mtaylor, lifeless, wgrant: I think this bug needs fixing: bug #942305 right away
[22:04] <_mup_> Bug #942305: forster is load spiking due to LP mailman integration <canonical-losa-lp> <mailing-lists> <Launchpad itself:Triaged> < https://launchpad.net/bugs/942305 >
[22:05] <sinzui> I have an idea in it that need validation
[22:10] <lifeless> looking
[22:10] <mtaylor> sinzui: looking as well - as is jeblair
[22:10] <lifeless> sinzui: which lists are key?
[22:11] <sinzui> ubuntu-x-swat is the leading cause
[22:11] <wgrant> It was a few months ago, at least.
[22:11] <wgrant> By a significant margin.
[22:12] <wgrant> Similar to the way we don't generate<EMAIL_ADDRESS>HTML archives.
[22:12] <sinzui> we can look at the messages in the arch queue to see which are the pathological lists
[22:14] <wgrant> lifeless: Heh, slony takes 80%+? Try 98-99.5%
[22:14] <lifeless> wgrant: understate overdeliver


[03:37] <zkriesse> akgraner: you 'round?
[05:11] <maco> pleia2: crimsun and i were both at a concert seeing victor wooten, perhaps the best jazz/funk bassist alive
[05:11] <maco> (we didnt know we were both there. i got on a metro train with a mutual acquaintance who had gone with crimsun and we both went "wait...you're familiar..."
[05:11] <maco> (he uses linux too. we all met in a coffee shop going "hey wait... you use linux??")
[05:11] <scott_ev> maco...better than stanley clarke?
[05:12] <maco> hmmmmm
[05:12] <scott_ev> difficult choice, huh?
[05:13] <maco> dunno, but since jaco died there's a crown to be handed out
[05:13] <maco> pleia2: so that calendar thing is just an event set to recur indefinitely
[05:13] <maco> afaik
[05:13] <maco> it theoretically happens
[05:13] <maco> but... since there's no rsvp system...
[05:44] <nigelb> akgraner: when you're around can you link me the doc for this week?
[05:56] <nigelb> I manage to lose it every time thanks to working on different computers :/
[14:14] <akgraner> nigel no worries one sec
[14:14] <akgraner> maco, going to see victor wooten sometime soon but I forgot the date ;-/
[14:14] <akgraner> anywho on to UWN
[14:15] <akgraner> nigelb, just use the wiki - https://wiki.ubuntu.com/UbuntuWeeklyNewsletter/Issue200
[14:16] <akgraner> however if the google doc is easier here is the link to that as well - https://docs.google.com/Doc?docid=0AdKZelXU8Y2LZGNrcHRkYmhfODlkODNxNnRnZA&hl=en
[14:17] <akgraner> maco your calendar you linked me to  - is great but why not just use the FOSSEvents one and if you know of an event that is not on there just add it?
[14:17] <akgraner> This way the whole FOSS community gets to know about it?
[15:20] <akgraner> highvoltage, ping (in the right channel - I'll be dropping in planet links to the wiki in about 10 mins are you still good to go with writing the summaries?
[15:36] <zkriesse> hey akgraner
[15:36] <akgraner> zkriesse, hey
[15:50] <scott_ev> no sleep for the wicked....
[15:50] <scott_ev> so....I'm exhausted
[15:50] <akgraner> :-(
[15:50]  * scott_ev is really an angel
[15:50] <scott_ev> ''flutter eye lashes"
[16:08] <highvoltage> akgraner: yep! and this weekend is way more relaxed than last weekend so it should go much better :)
[16:08] <highvoltage> (I'm finally in Canada)
[16:08] <akgraner> highvoltage, awesome!
[16:08] <akgraner> ok I'll drop them in now for you then
[16:08] <akgraner> thank you
[16:21] <akgraner> highvoltage, they are on the wiki now
[16:58] <maco> akgraner: uhhh because i didnt know about it when i started that one 2 years ago? and still dont?
[17:02] <akgraner> maco, http://fossevents.org/ check it out :-)
[17:07] <maco> akgraner: do they have little widgety things?  my gcal i have embedded at the bottom of my blog
[17:08] <maco> O_o they put HOPE on it?
[17:08] <akgraner> maco, ask laura or issy they both help with that one
[17:08] <maco> thats not foss.... thats hardware and phone hacking mostly
[17:09] <akgraner> maco anyone can add stuff to it - "they" is not FOSSevents they would be anyone who wants to add what "they" consider to be related to FOSS
[17:09] <maco> i see
[17:09] <akgraner> Pendulum, I have added some ITB stuff to the wiki...
[17:10] <akgraner> are you still ok with working on that section this week?
[17:10]  * maco likes own calendar... not watered down with little things like LUGs
[17:10] <akgraner> nigelb, who posted the Cleansweep stats for last week  - you david or jorge or someone else?
[17:11] <akgraner> making sure I am snagging the right stats
[17:11] <akgraner> maco, that's cool - it's all about choice :-)  was just pointing out another source of information you may want to use/add to
[17:11] <Pendulum> akgraner: yep. I can do ITB
[17:11] <Pendulum> (I'd have told you before this if I thought I couldn't)
[17:12] <akgraner> Pendulum, :-)  thanks!
[17:12] <nhandler> akgraner: This is where the cleansweep stats come from: http://daniel.holba.ch/review/report
[17:12] <akgraner> I just like to double check with everyone so I know how to plan my sunday mornings
[17:13] <akgraner> nhandler, yep that's the link I have but I know they talked about rotating who posts them and since they were in the same format as last time I was just double checking
[17:13] <maco> akgraner: it looks like fossevents wants to have *everything* ... i wanted something thats a quick glance at whats going on in the larger foss world, so release dates and regional/national/worldwide events, not city-wide ones
[17:14] <akgraner> and they like to include them on their blogs so I was trying to see who listed them
[17:16] <nhandler> akgraner: In terms of blog posts, I saw http://castrojo.tumblr.com/post/745744996/cleansweep-updates  and http://daniel.holba.ch/blog/?p=709
[17:16] <akgraner> yep jorge posted them this week on his blog  - I should note these things earlier in the week - I hate when life gets in the way of my Ubuntu Fun
[17:27] <akgraner> zkriesse, thanks for updating the wiki did you update the UWN issue as well for the list of contributors?
[17:28] <akgraner> if not the UWN 200 issue list needs to be in the paragraph form like it is showing now not the column for as the wiki list... let me know if that makes sense to you?
[17:34] <akgraner> internalkernel, hey if holstein can't do the In Other News Section can you?
[17:36] <akgraner> johnc4510, if you have a moment can you add a comment to the comments from past/present editors from UWN - please and thank you!
[17:40] <internalkernel> akgraner: yeah, we'll hit it... mike is here too.
[17:40] <internalkernel> we're at the wnclug...
[17:41] <akgraner> ahh thank you!!
[17:42] <akgraner> internalkernel, tell everyone hello - wish I could be there...thanks for working on those sections
[17:42] <internalkernel> for sure, no worries...
[17:49] <akgraner> so stats and updates will get added tomorrow  and I think everyone has their links and knows what's happening  - if you see a link I missed or think things should go in let me know - I have to finish editing some interviews and some special things to go into the issue tomorrow - need to step away for a while...
[17:51] <akgraner> I have asked mako, bueno, johnc4510 and boredandblogging to add to the comments from past/present editors  - if you want to touch base with other editors you all know please do and ask them to add a few lines to that section..:-)
[17:52] <akgraner> I think I am missing some loco news so if someone wants to look into that an drop some links into the LoCo section that's cool as well if not I'll work on it later today... :-)
[17:53] <akgraner> highvoltage, Pendulum internalkernel holstein johnc4510 scott_ev and nhandler thanks in advance for the work on your sections!  You all rock!
[18:26] <nhandler> akgraner: You rock as well. You have been doing a great job with the UWN!
[19:28] <scott_ev> nhandler: agreed - akgraner works way too hard
[19:29] <scott_ev> but the pursuit of perfection has it's price
[19:30] <zkriesse> akgraner: RE: Wiki Page
[19:41] <scott_ev> awesome; matthew helmke gave me his endorsement
[19:42] <zkriesse> scott_ev: so going for membership on the 6'th?
[19:42] <scott_ev> yes
[19:42] <scott_ev> 20:00UTC
[19:42] <zkriesse> HOOOAH!
[19:42] <scott_ev> I think.  it's on my calendar
[19:43] <zkriesse> it's at 20:00 UTC
[19:43] <scott_ev> outstanding; I had it right
[22:55] <newboon2age_> akgraner: OpenOffice gets Ubuntu-media friendly  http://www.theregister.co.uk/2010/07/02/openoffice_adopts_gstreamer/
[23:13] <zkriesse> scott_ev: ping
[23:14] <scott_ev> pong
[23:14] <zkriesse> scott_ev: want to work on your wiki page?
[23:14] <scott_ev> man I have to calm down after that...
[23:14] <zkriesse> calm down after what
[23:14] <scott_ev> I'll pm
[23:14] <zkriesse> ok
[23:15] <scott_ev>                   up.  with their 'power boost' it tests out as high as 55 down and 8 up with pfSense
[23:15] <scott_ev>                   in place on an appliance that is all gigabit.  When I put the WRT back in place the
[23:15] <scott_ev>                   tests slow to ~25 and 5.  Is this due to the hardware of the Linksys all being 10/100
[23:15] <scott_ev>                   or can firmware be slowing things down? This Linksys has DD-WRT on it and because of
[23:15] <scott_ev>                   things I've heard and read I really don't want it on there any longer.  I'm just
[23:15] <scott_ev>                   wondering if the firmware change to OpenWRT will result in any better speeds.  Either
[23:15] <scott_ev>                   way I plan on switching..
[23:15] <scott_ev> 14:22 <+scott_ev> [mbm]: any input?
[23:15] <scott_ev> 14:24 <@[mbm]> I'm from openwrt, not dd-wrt .. that's like asking for cyanogen support in droidmod
[23:15] <scott_ev> 14:26 <+scott_ev> no it's not.  I'm asking if openwrt would possibly show any gains
[23:15] <scott_ev> 14:26 <+scott_ev> I'm going to switch anyway
[23:15] <scott_ev> 14:27 <+scott_ev> or is the limited speed due to a 10/100 nic being overloaded by overhead?
[23:15] <scott_ev> 14:28 <+scott_ev> my thinking is that a 10/100 nic should move more than 25bm/s...
[23:15] <scott_ev> 14:36 <+scott_ev> so am I to believe you can't even be bothered to tell me you have a great product and
[23:15] <scott_ev>                   I should be very hapy with it especially since it's not in violation of licensing?
[23:15] <scott_ev> 14:36 <+scott_ev> hah
[23:15] <scott_ev> 14:56 <@[mbm]> I don't give a damn what you run, I don't make any money off openwrt and having you run
[23:15] <scott_ev>                it would just be further annoyance
[23:15] <scott_ev> 14:59 <+scott_ev> haha
[23:16] <scott_ev> 15:00 <@[mbm]> from my point of view dd-wrt is great, it means I don't have to deal with self entitled
[23:16] <scott_ev>                idiots like you
[23:16] <scott_ev> 15:01 <+scott_ev> just flashed.  worry not oh great one - I'll not be annoying you with further
[23:16] <scott_ev>                   questions
[23:16] <zkriesse> ok scott_ev
[23:16] <scott_ev> brb in 5 - 10 min
[23:18] <scott_ev> back