[00:50] <lifeless> -> monthly allergy shot. Urgent things you can SMS/ring.
[03:28] <mwhudson> wtf
[03:28] <mwhudson> how can bug 951365 be a regression
[03:28] <_mup_> Bug #951365: Accessing milestone on project group via webservice api returns has_bugs object <api> <milestones> <oem-services> <projectgroups> <regression> <Launchpad itself:Triaged> < https://launchpad.net/bugs/951365 >
[03:29] <mwhudson> wgrant: so i think that happens because a project groups milestones are IProjectGroupMilestones, not IMilestones
[03:29] <wgrant> mwhudson: The only thing I can think of is milestone tags.
[03:30] <wgrant> That may have changed things.
[03:30] <mwhudson> ah
[03:30] <mwhudson> i suppose that might have resulted in some shuffling
[03:34] <mwhudson> milestone tags was only a 3000 line change...
[03:34] <wgrant> Pfft
[03:35] <mwhudson> wgrant: good guess
[03:35] <wgrant> What happened?
[03:36] <mwhudson> wgrant: well, that was the change that made IProjectGroupMilestone not inherit from IMilestone
[03:37] <wgrant> Ah
[03:37] <wgrant> That would do it indeed.
[03:38] <mwhudson> i _guess_ the milestone collections in iprojectgroup need to be overridden to declare returning IProjectGroupMilestone
[03:43] <wgrant> ARGH
[03:43] <wgrant> I hate lazr.config
[03:44] <wgrant> Particularly some of the ways we use it.
[03:45] <wgrant> config.error_reports.error_dir can be overridden by error_dir in a script-specified config section.
[03:45] <wgrant> Except that the config schema has some dev paths as the codehosting sections' error_dirs.
[03:45] <wgrant> Which means that dropping the codehosting error_dirs from the prod configs won't fall back to the configured production default, but the dev default.
[03:54] <mwhudson> hm, i wonder if i've run rocketfuel-setup on this machine
[03:55] <StevenK> mwhudson: If /etc/hosts is 600,000 lines long, yep.
[03:56] <mwhudson> appears i have not
[03:56] <wgrant> LXC! LXC!
[03:57] <mwhudson> ah good point
[03:57] <wgrant> It's nice and easy on precise
[03:57] <wgrant> I cleaned up the howto on whatever day was earlier this week
[04:00] <StevenK> Speaking of precise, I'm trying to figure out how to upgrade my fileserver.
[04:01] <StevenK> It's Ethernet module isn't in Lucid's kernel, so it's dkms'd, but I don't want it to be dkms'd on upgrade, since the module is in Precise's kernel.
[04:01] <wgrant> '''
[04:05] <mwhudson> wgrant: this howto? https://dev.launchpad.net/Running/LXC
[04:05] <wgrant> That one
[04:06] <mwhudson> cool
[04:07] <lifeless> wgrant: fix the schema ? I don't see any reason for it to have dev data in it, we have a dev config for that
[04:07] <wgrant> lifeless: Yeah, fixed in devel a few minutes back.
[04:07] <wgrant> It's still full of crap, but it's slightly less offensive and stupid crap.
[04:19] <mwhudson> wgrant:   launchpad-dependencies: Depends: python-apt (>= 0.7.94.2ubuntu6.4) but 0.7.94.2ubuntu6 is to be installed
[04:19] <mwhudson> (in the lxc)
[04:20] <wgrant> mwhudson: Sure you ran rocketfuel-setup? That should be in the launchpad PPA
[04:20] <StevenK> mwhudson: No -updates?
[04:20] <wgrant> Or -updates
[04:20] <mwhudson> StevenK wins
[04:20] <wgrant> Hmm
[04:20] <wgrant> I'm pretty sure my fresh container had that by default
[04:20] <wgrant> mwhudson: Has this machine run LXC before?
[04:20] <lifeless> bad precise lxc cache probably
[04:20] <mwhudson> wgrant: yes, i lxc-destroy-ed the lxc i had
[04:20] <mwhudson> sources.list was 1 line
[04:21] <lifeless> mwhudson: there is a cache as well
[04:21] <mwhudson> oh excellent
[04:21] <wgrant> Ah
[04:21] <wgrant> I'd suggest restarting
[04:21] <mwhudson> oh ok
[04:21] <wgrant> sudo rm -r /var/cache/lxc/lucid
[04:21] <wgrant> Then lxc-create again
[04:21] <wgrant> Vast improvements were made in the last couple of months
[04:21] <wgrant> Such that it's no longer torture to get LXC working.
[04:21] <wgrant> It'll redebootstrap an environment that actually works
[04:22] <mwhudson> heh
[04:22] <mwhudson> ok
[04:22] <mwhudson> maybe a note along these lines could be added to the wiki
[04:22]  * wgrant adds
[04:39] <cody-somerville> mwhudson, Are you fixing LP #951365? :)
[04:39] <_mup_> Bug #951365: Accessing milestone on project group via webservice api returns has_bugs object <api> <milestones> <oem-services> <projectgroups> <regression> <Launchpad itself:Triaged> < https://launchpad.net/bugs/951365 >
[04:39] <mwhudson> cody-somerville: its a possibility
[04:41] <mwhudson> come on intertubes, go faster
[04:58] <wgrant> mwhudson: Going OK?
[04:58] <mwhudson> wgrant: yes
[04:58] <wgrant> Great.
[04:58] <wgrant> I haven't actually completely tested the latest version of the instructions from scratch :)
[04:58] <mwhudson> heh
[04:58] <mwhudson> well rocketfuel-setup --no-workspace is grinding away
[04:59] <wgrant> Great.
[05:04] <StevenK> wgrant, wallyworld: Either of you want to look at https://code.launchpad.net/~stevenk/launchpad/bugs-information_type-mail/+merge/104483 ?
[05:05] <wgrant> StevenK: Underscores?
[05:05] <wgrant> Really?
[05:06] <wgrant> I don't think we have underscores anywhere else in the UI
[05:06] <wgrant> Mail or Web.
[05:06] <StevenK> wgrant: 'information type' doesn't work for the command, 'information_type' does. :-(
[05:06] <wgrant> informationtype does as well :)
[05:07] <wgrant> Does this follow value parsing rules similar to status?
[05:09] <StevenK> wgrant: informationtype works, I guess
[05:10] <mwhudson> information-type
[05:10]  * mwhudson bikesheds
[05:10] <StevenK> wgrant: Status just calls transitionToStatus(), no checking
[05:11] <StevenK> I didn't think CreateBugParams supported that method, but ICBW.
[05:11] <wgrant> StevenK: But how does it parse the value?"
[05:11] <StevenK> wgrant: It's done via setAttributeValue, so the parsing is in the guts of the mail handler, I guess.
[05:12] <wgrant> StevenK: The behaviour of status and informationtype parsing has no reason to differ.
[05:12] <StevenK> It sets a dbschema = BugTaskStatus
[05:13] <StevenK> wgrant: Except for 'Private' and the forbidding of 'Proprietary'.
[05:14] <wgrant> True.
[05:14] <wgrant> The the latter is unrelated.
[05:14] <wgrant> It's a temporarily post-parse filter operation
[05:14] <wgrant> Bah
[05:14] <wgrant> It is too cold to type sensibly
[05:14] <StevenK> Oh?
[05:14] <StevenK> It's 24degC in my study
[05:18] <StevenK> wgrant: I think after we drop Private, we can change informationtype to be like Status
[05:21] <StevenK> Or we could just declare we won't support Private on the mail interface, and I can change it now.
[05:21]  * StevenK laughs
[05:31]  * mwhudson wonders if rocketfuel-setup has asked for his root password for the last time...
[05:32] <stub> Bug #992184  seems rather special
[05:32] <_mup_> Bug #992184: lib/lp/services/database/doc/textsearching.txt fails intermittently/rarely on parallel tests <paralleltest> <Launchpad itself:Triaged> < https://launchpad.net/bugs/992184 >
[05:33] <mwhudson> yes!
[05:33]  * mwhudson disappears
[05:36] <wallyworld> StevenK: i was doing school pickup, i assume you don't need me to look at your branch?
[05:37] <StevenK> wallyworld: I was having a discussion with wgrant until his Internet broke due to no power.
[05:37] <wallyworld> lol
[05:38]  * wallyworld remembers a time when there wasn't any internet even with power
[05:39] <spm> wallyworld: and where 9600 baud seemed like an impossible speed dream?
[05:39] <wallyworld> my first modem was 300/75
[05:39] <wallyworld> so yes :-)
[05:39] <spm>  Igot lucky. started on 1200
[05:39] <spm> LUXURY
[05:40] <wallyworld> took ages to download all that ascii 'porn'
[05:40] <StevenK> wallyworld: Download? Feel sorry for the poor bugger that had to type it in.
[05:40] <wallyworld> rotflmao
[05:41] <wallyworld> i still laugh every time an 80's movie shows a modem instantly connecting without the audible handshake
[05:41] <wallyworld> i used to love the handshake
[05:42] <StevenK> I had a friend at uni would could whistle 2400 baud
[05:42] <StevenK> s/would/who/
[05:42] <wallyworld> so he could connect to the CIA and order a nuclear strike?
[05:42] <StevenK> Haha
[05:44] <lifeless> spm: bah, 300/75? thats speedy
[05:44] <spm> lifeless: itym wallyworld
[05:45] <lifeless> ohbahdee
[05:45] <wallyworld> what was slower than 300/74?
[05:45] <lifeless> yesIdoo
[05:45] <wallyworld> 75
[05:48] <lifeless> wallyworld: a) I was trolling, b) 110 baud
[05:48] <wallyworld> i was genuinely curious :-)
[05:48] <wallyworld> 110 baud, wow that's slow
[05:49] <lifeless> http://en.wikipedia.org/wiki/Bell_101
[05:49] <wallyworld> but since baud refers to state changes per second, if each state change encoded 16 bits it wouldn't be soooo bad
[05:49] <lifeless> My first modem was a 300/75
[05:50]  * wallyworld is now reminiscing about the Hayes command set 
[05:50] <wallyworld> those were the days
[05:50] <lifeless> http://en.wikipedia.org/wiki/List_of_device_bandwidths is pretty good for reminiscing
[05:50] <wallyworld> they left off the 2 cans either end of a taught piece of string
[06:09] <spm> I'm rather pleased to say that I've compeltely forgotten all modem commands beyond AT. and I'm proud that I'm unsure if even that's correct.
[06:09] <StevenK> I can remember ATDT<number>
[06:22] <lifeless> +++
[06:23]  * wgrant stabs u-boot
[06:23] <wgrant> Or flash-kernel
[06:23] <wgrant> One of those
[06:23] <StevenK> Haha
[06:27] <wgrant> I started with a 56kbps modem, you old people.
[06:30] <bigjools> luxury
[06:38] <lifeless> wgrant: modern luxury
[07:38] <adeuring> good morning
[08:10] <wgrant> There we go
[08:11] <wgrant> Running/LXC tested and minimised and prettified
[09:32] <wgrant> https://dev.launchpad.net/Running/RemoteAccess is a bit sad.
[09:34] <wgrant> With SNI widely supported it seems like we don't really need the two IP addresses any more.
[09:36] <maxb> widely supported enough, really?
[09:37] <lifeless> for dev use
[09:37] <lifeless> yes
[09:37] <wgrant> The only thing in the config that needs it is private loggerhead, which will only be accessed by a web browser, and everything except those using Windows XP's crypto stack supports SNI.
[09:37] <lifeless> long as we don't use python to access anything
[09:37] <lifeless> wgrant: ^
[09:37] <wgrant> Yes
[09:38] <wgrant> As long as we have the main vhost first, python will be happy
[09:38] <lifeless> oh, is that the degraded behaviour ?
[09:39] <wgrant> I'm pretty sure it degrades the same as missing Host with HTTP
[09:39] <wgrant> It picks the first matching vhost
[09:40] <wgrant> I'm thinking I'll add a make target which tweaks the config to listen on * and allow a user-specified subnet.
[09:51] <jml> how can I set up an 'ec2 demo' server so that it's possible to log on?
[09:52] <wgrant> jml: What breaks when you try?
[09:52] <cjwatson> SNI - only ten years late
[09:52] <jml> wgrant: I get told that the openid provider is unavailable
[09:52] <jml> OpenID Provider Is Unavailable at This Time
[09:52] <jml> The openid provider was unavailable. Please try again in a moment.
[09:52] <jml> You can also join the #launchpad IRC support channel on irc.freenode.net to ask for further assistance.
[09:52] <wgrant> jml: That's slightly unpleasant of it.
[09:53] <jml> wgrant: yes. the capitalization is egregious.
[09:53] <wgrant> Both the fact that there's an error and the text content of the error
[09:53] <wgrant> Yes
[09:53] <wgrant> At least it doesn't say FreeNode
[09:53] <wgrant> Let's see.
[09:56] <wgrant> Slow ec2...
[10:04] <wallyworld> wgrant: can you run a query on dogfood for me?
[10:04] <wgrant> wallyworld: Sure
[10:04] <wallyworld> https://pastebin.canonical.com/65435/
[10:05] <wallyworld> it's for a job
[10:05] <wallyworld> so not 100% critical is blazingly fast
[10:05] <wallyworld> replace the policy ids
[10:05] <wgrant> Ubuntu?
[10:05] <wallyworld> sure, why not :-)
[10:06] <wallyworld> it's to select all bugs a person is subscribed to but doesn't have a grant for (including via a team)
[10:08] <wgrant> I expect it will be very slow, but let's see.
[10:09] <wallyworld> i may need to use a CTE
[10:09] <wallyworld> i have a bunch of tests passing, just need to optimise :-)
[10:10] <jml> wow
[10:10] <jml> it's so nice to have so many Australians around
[10:10] <wallyworld> hi jml :-)
[10:11] <allenap> lifeless: Do you have time to talk in about 10 or 11 hours, about MAAS architecture?
[10:11] <jml> wallyworld: hi
[10:11] <bigjools> hey jml!  Ah bugger, I'm not really Australian
[10:11] <wallyworld> jml: how are they hanin', mate?
[10:11] <jml> bigjools: bloody immigrants.
[10:11] <wallyworld> bigjools: fuck off
[10:12] <jml> wallyworld: all good, thanks
[10:12] <bigjools> wallyworld: I'd be quiet if I were you or I'd tell everyone you were listening to Britney today.  Oops, too late :)
[10:12] <jml> ow ow, it hurts to laugh
[10:12] <bigjools> jml: bastards eh :)
[10:13] <wallyworld> bigjools: lies, all lies
[10:13] <bigjools> and also you had Lady Gaga on
[10:13] <bigjools> I bet you wear a dress when nobody's looking
[10:14] <wallyworld> no, just panties
[10:14] <bigjools> with the peep hole
[10:14] <wallyworld> that way i can wear them when people are looking
[10:14] <wgrant> wallyworld: I'd spell it http://paste.ubuntu.com/964307/
[10:14] <wgrant> wallyworld: Which is fast
[10:14]  * wallyworld looks
[10:15] <wgrant> It satisfies my subscriptions to Ubuntu in 30ms
[10:15] <wgrant> ubuntu-crashes-universe in 1010ms hot
[10:15] <wgrant> Which is not bad.
[10:16] <wallyworld> wgrant: i didn't realise btf has access_grants
[10:16] <wgrant> That doesn't have the restriction to Ubuntu because i am forgetful
[10:16] <wgrant> But it's easy enough to add into the query
[10:16] <wgrant> wallyworld: Yeah, it has all the access info so searches can be fast.
[10:16] <wgrant> And this is a search :)
[10:17] <wallyworld> wgrant:  does && mean AND? i've not seen thhat before
[10:17] <wgrant> wallyworld: && is array intersection
[10:18] <wallyworld> ok. is that postgres specific? or standard sql?
[10:18] <wgrant> The array stuff is a postgres extension
[10:18] <wgrant> AIUI
[10:18] <wallyworld> i bet storm doesn;t support it, so i will have to hand code the query :-(
[10:18] <wgrant> It's 3 lines to define &&
[10:18] <bigjools> suck it up
[10:18] <wgrant> And I think we already have one in the codebase
[10:18] <wgrant> Bug subscriptions use it
[10:18] <wallyworld> pointer?
[10:19] <wgrant> lib/lp/bugs/model/structuralsubscription.py:    oper = "&&"
[10:19] <wallyworld> bigjools: i've said it before and i'll say it again: fuck off
[10:19] <wgrant> I'd move that into lp.services.database.stormexpr with the rest
[10:19] <wgrant> wallyworld: However
[10:19] <bigjools> wallyworld: muahaha :)
[10:19] <wgrant> wallyworld: Those access checks are the same as the ones in bugtasksearch
[10:19] <wgrant> wallyworld: You can probably reuse get_bug_privacy_filter
[10:19] <wgrant> See how the access checks are done in there
[10:19] <wgrant> It's not pretty yet, but eventually.
[10:20] <bigjools> night all
[10:20] <wgrant> Fuck off bigjools :)
[10:20] <bigjools> wgrant: wallyworld gets away with it but not you
[10:20] <wgrant> Aw
[10:20] <bigjools> get back to your basement
[10:20] <wallyworld> wgrant: i'll have a look. i may need to refactor what i've done. i've defined an indirect_bugs_filter helper method in accesspolicy.py
[10:21] <wgrant> wallyworld: get_bug_privacy_filter also handles public bugs, which I omitted from that query
[10:21] <wgrant> Mostly because I forgot
[10:21] <wallyworld> ok. thanks. will have a look
[10:27] <jml> :)
[10:30] <wgrant> jml: Ah
[10:30] <wgrant> jml: You still have that ec2 instance?
[10:31] <jml> wgrant: yes.
[10:31] <wgrant> jml: I suspect it will unbreak if you s/$INSTANCE_IP/*/ in /etc/apache2/sites-available/local-launchpad
[10:32] <jml> hmm.
[10:32] <wgrant> jml: ec2 demo forces it to listen on the external interface, when testopenid.dev will point to localhost
[10:32] <wgrant> So the local appserver can't talk to the provider.
[10:32] <jml> wgrant: ok, will try that.
[10:33] <wgrant> launchpad-developer-dependencies only suggests libapache2-mod-wsgi. I guess it should depend now.
[10:34] <wgrant> Ah
[10:34] <wgrant> No
[10:34] <wgrant> It also only suggests apache2, so I guess ec2 installs that manually.
[10:34] <jml> yeah, haven't looked sorry.
[10:36] <jml> wgrant: ok. Now I get "unknown email address" when I try to log in / register.
[10:36] <wgrant> jml: admin@canonicalcom?
[10:36] <wgrant> admin@canonical.com
[10:37] <jml> wgrant: that gives me the following: http://pastebin.ubuntu.com/964360/
[10:38] <wgrant> jml: Try clicking Log In / Register again
[10:38] <wgrant> I suspect your session might have died.
[10:38] <jml> wgrant: ooh, I only just noticed that when I got that error, the log in / register link was gone and replaced with Foo Bar (~name16)
[10:38] <wgrant> Aha
[10:39] <jml> which is weird but workaroundable.
[10:43] <wgrant> Retrying with my fixes now.
[10:54] <jml> wgrant: thanks.
[11:17] <wgrant> Fourth time lucky...
[11:24] <jml> wgrant: are your fixes to lp-dev-utils or to launchpad?
[11:27] <jml> wgrant: I'm going to leave now – I have a lunch appointment. My IRC proxy will be connected.
[11:31] <wgrant> jml: lp-dev-utils
[11:32] <jml> wgrant: ah, thanks. I was going to do a patch for the '*' thing but will await yours.
[11:32]  * jml really off
[11:32] <wgrant> Ah
[11:32] <wgrant> Neds an image rebuild to pick up the new package
[11:32] <wgrant> That's why it's not working.
[11:33]  * wgrant will commit and publish a new image.
[11:33] <wgrant> Thanks for letting us know.
[11:33] <StevenK> Hmm, then poolie can drop 523. Which might be difficult to organise.
[13:02] <wgrant> jml: lp-dev-utils is fixed, and there's an updated image
[13:02] <wgrant> so demo should work properly now
[13:02] <wgrant> Also, buildout is slow
[13:06] <StevenK> News at 11
[13:18] <jml> wgrant: thanks.
[14:15] <jml> can someone please land lp:~jml/lp-dev-utils/public-ip
[14:15] <jml> abentley approved it
[14:18] <abentley> jml: done.
[14:18] <jml> abentley: thanks!
[14:31] <jml> running a dev instance via 'ec2 demo', looks like the private xmlrpc server isn't running
[14:31] <jml> nothing is listening on 8097
[14:31] <jml> how do I start that up?
[14:38] <jml> hi
[14:38] <achuni> g'morning :)
[14:38] <rick_h_> sorry jml, not sure there. Looking at the makefile not sure which bits start up the xmlrpc
[14:41] <jml> fwiw, we're getting https://pastebin.canonical.com/65462/ when we try to do an xmlrpc request
[14:41] <jml> achuni: is that right?
[14:41] <jml> and are being redirected from http to https.
[14:42] <achuni> jml: that's just hitting the xmlrpc endpoint in a browser, I can try an xmlrpc request in a bit
[14:42] <jml> achuni: ah ok.
[14:42] <achuni> http->https redirect, yep.  afaict we should be using https anyway
[14:43] <jml> *ahem*
[14:43] <jml> 8087
[14:44] <jml> never mind
[14:44] <jml> it is running, and I'm a fool.
[14:47] <jml> achuni: I get http://pastebin.ubuntu.com/964783/
[14:47] <achuni> jml: looks good
[14:47] <jml> achuni: good? is that what you expect?
[14:47] <achuni> (does launchpadlib support proxies?  Can I ask it to use one?)
[14:48] <achuni> jml: well, up until the 403 response, yep
[14:48] <jml> achuni: if it didn't hurt so much, I would laugh bitterly
[14:49] <achuni> :D
[14:49] <jml> nothing on the help wiki
[14:49] <achuni> jml: you think that's authorizing by IP just? we don't do any kind of authentication for that call afaict
[14:49] <jml> it just uses httplib2 though
[14:49] <jml> so it's probably whatever that uses
[14:50] <achuni> right
[14:51] <jml> googling doesn't reveal much
[14:52] <jml> :(
[14:53] <achuni> httplib2 supports proxies via the socks module
[14:53] <jml> as in, by writing code
[14:53] <achuni> yeah, checking if I can ask launchpadlib to pass in the right args
[14:53] <jml> nothing in the stack seems to have environment-based http proxy support.
[14:54]  * achuni hacks /usr/lib/python2.7/dist-packages/httplib2/__init__.py
[14:55] <jml> :(
[14:55] <jml> achuni: just double checking, you're not waiting on me for any questions, right?
[14:56] <achuni> jml: nope, thanks
[15:04] <achuni> jml: kind of success.  It seems to have worked, I now get Permission denied: '/var/tmp/launchpad_mailqueue/tmp/1336057390.27818.domU-12-31-39-08-04-1D.1557865906
[15:04] <jml> achuni: hmm. that might be an fs thing.
[15:05] <jml> odd.
[15:05] <jml> achuni: I've made those writeable. Try again?
[15:06] <achuni> weird, let me pastebin
[15:07] <achuni> jml: https://pastebin.canonical.com/65469/
[15:07] <achuni> jml: still a Perm denied failure, but now on an unspecified location
[15:08] <jml> effing Python errors
[15:08] <jml> how many hours have been lost because the 'os' module doesn't raise errors with function arguments
[15:09]  * jml takes a deep, slow breath
[15:10] <jml> achuni: oh, my bad.
[15:10] <jml> achuni: there were more directories that needed permission changing
[15:10] <jml> (my criticism of Python is still valid though)
[15:11] <jml> achuni: try again?
[15:16] <achuni> jml: I haz creds :)
[15:16] <jml> achuni: \o/
[15:16] <jml> achuni: what's next?
[15:17] <achuni> jml: standup, but I'll try those creds out next, in a bit
[15:18] <jml> achuni: heh, thanks.
[15:24] <benji> bac: all clear
[16:25] <adam_> hi there, was wondering if anyone could help me figure out why a few mails from the openstack list are occasionally silently vanishing into a bitbucket instead of reaching me?
[16:25] <adam_> I receive most of them
[16:25] <adam_> and have checked my spam folder
[16:29] <czajkowski> adam_: are they showing up on the archive?
[16:29] <adam_> czajkowski: yes
[16:29] <adam_> e.g. https://lists.launchpad.net/openstack/msg11012.html
[16:36] <czajkowski> adam_: any issue with your email as nobody else has said there are any LP mail issues
[16:37] <adam_> czajkowski: not aware of any other issues or dropped mail from other sources, no
[16:38] <angeloc> hi guys, I'm writing an ubuntu accomplishment that should test if a person had personally verified an SRU bug to earn the tester trophy. I'm using python api for launchpad, any idea how it could be done?
[16:38] <adam_> czajkowski: don't suppose you'd be able to pinpoint that mail in the MTA logs and see if it was accepted by the MTA my end?
[16:39] <czajkowski> adam_: I can ask and see
[16:39] <adam_> if it was then I'll know I have to fight battles with our corporate email team ...
[16:39] <adam_> thanks!
[16:40] <czajkowski> adam_: and your email address it would have gone to is ?
[16:40] <adam_> aspiers@suse.com
[16:43] <czajkowski> adam_: checking
[16:44] <adam_> awesome, thanks :)
[16:55] <jcsackett> sinzui: thanks for helping out with the review queue. :-)
[16:59] <adam_> czajkowski: gotta go now, but I'll stay logged in to catch anything you might say ... thanks again!
[16:59] <czajkowski> adam_: I'll be gone shortly and no update yet
[16:59] <adam_> czajkowski: ok, I'll be around tomorrow too
[17:00] <czajkowski> ok
[17:00] <adam_> of course I'm reachable on that email address too ... well, hopefully ;-)
[17:00] <sinzui> jcsackett, I forgot it was Thursday
[17:00] <jcsackett> sinzui: it's all good. that was a sincere thank you. that branch was the largest in my queue. :-P
[17:01] <adam_> czajkowski: UK timezone, that is
[17:01] <sinzui> jcsackett, :)
[17:02] <adam_> czajkowski: hopefully we'll overlap by at least one hour but you never know on this channel ;-)
[17:05] <czajkowski> adam_: look like it did make it to that end
[18:09] <lifeless_> allenap: I'd be delighted to
[18:13] <lifeless> allenap: I'm going back to bed for a bit (0600 here) but will ping when I'm on deck
[18:23]  * deryck reboots, will brb
[18:34] <jml> does anyone know why launchpad_mailqueue is unwriteable on ec2test?
[18:35] <jml> ec2test/testrunner.py:426
[19:16] <benji> jcsackett: if you have time for a small review, I have a bite sized one for you: https://code.launchpad.net/~benji/launchpad/bug-992692/+merge/104599
[19:41] <jml> how do I create new users on a demo instance?
[19:41] <lifeless> jml: there is a script
[19:42] <lifeless> though we should really get demo talking to real openid
[19:42] <jml> oh wait, 'make-lp-user'?
[19:43] <lifeless> I believe so
[19:43] <jml> I think I wrote that.
[19:43] <jml> Anyway.
[19:44] <jml> achuni: you've got shell access, right?
[19:44] <achuni> jml: yep, logging in now
[19:45] <achuni> jml: where's the make-lp-user script?
[19:45] <jml> /var/launchpad/test/utilities/make-lp-user
[19:45] <achuni> neat
[19:48] <achuni> jml: https://pastebin.canonical.com/65498/
[19:48] <achuni> jml: kind of close?
[19:49] <jml> achuni: annoyingly, setting the email address does some gpg stuff
[19:50] <achuni> jml: I'd skip that, except it's the only way the user can log in, I think?
[19:50] <jml> achuni: probably best to run again without --email and then use the web UI to set  that.
[19:50] <jml> achuni: no, elachuni@example.com
[19:50] <achuni> ahhhh
[19:50]  * achuni tries
[19:54] <achuni> jml: "A confirmation message has been sent..." d'you think that'll arrive eventually, or should I retrieve it locally from the instance somewhere?
[19:55] <achuni> jml: this was when I added an email via the web UI
[19:55] <jml> achuni: tbh, I don't really know. Let's look in the mailqueue shall we?
[19:55] <achuni> ok
[19:56] <achuni> jml: ah, hm, and I'll probably need to stick my finger in the DB to make the openid for that user match my real life one
[19:56] <achuni> sigh
[19:56] <jml> achuni: psql launchpad_dev
[19:57] <achuni> yep
[19:57] <jml> achuni: sorry this is so hard. :(
[19:57] <achuni> np
[19:57] <jml> achuni: nothing in /var/log/mail.log
[19:57] <achuni> jml: once I've gone that far, I might as well straighten out the emails in the db
[19:58] <jml> achuni: it's 9pm here. I need to cook some food and start doing what I had meant to start at 7pm. Will still be around, just laggy.
[19:58] <achuni> jml: go, get some rest.  I'll fiddle with this and let you know how it went in an email
[20:00] <lifeless> gary_poster: do you think the test suite is robust enough for devs to use (tip) testr --parallel + lxc themselves and not expect egregious fallout ?
[20:04] <allenap> lifeless: My wife needs me so I have to go. I'll send an email about maas. It should be reasonably short. Sorry if you'd carved out some time for me.
[20:04] <lifeless> allenap: doh forgot to ping you back
[20:04] <lifeless> only about 20m wasted :(
[20:04] <allenap> lifeless: No worries :)
[20:04] <lifeless> allenap: am here if you get time later, otherwise yes email is cool
[20:05] <allenap> lifeless: Cool, okay.
[20:10] <gary_poster> lifeless, we're still seeing test suite failure 1/3 of time.  We closed a bunch of the known errors today so maybe tomorrow stats will be much better.  33% failure seems a bit egregious to me but that's subjective.
[20:10] <gary_poster> We're also starting to see repeats, which is good.
[20:11] <gary_poster> seeing a new, different failure every test run was a bit disheartening.
[20:19] <lifeless> gary_poster: yeah, I can well imagine
[20:19] <lifeless> gary_poster: I *knew* this would be a long tail :(
[21:04] <achuni> jml: \o/ success
[21:04] <jml> achuni: yay
[21:04] <jml> achuni: that was with non-commercial, right?
[21:05] <achuni> jml: that was with non-commercial, right.  I'll try with commercial next for completeness.  I'll let you know if I got email
[21:05] <jml> achuni: thanks.
[21:05] <achuni> jml: I got the 'proof of purchase' email from sca, but none from LP so far
[21:05] <achuni> jml: then again, I never got one for confirming my email either
[21:05] <jml> achuni: I reckon it's just disabled for the demo instance
[21:06] <achuni> yep
[21:06] <jml> achuni: I guess we can verify that behaviour when we check against staging?
[21:06] <jml> (does staging send email?)
[21:06] <achuni> yep, and... I don't know
[21:11] <achuni> jml: success with the commercial one too, I didn't expect that to fail, should I have been looking out for something?
[21:11] <jml> achuni: I don't think so.
[21:11] <achuni> jml: once again, got the email from sca but none from LP
[21:12] <jml> achuni: I guess if we had email, you should have received some for the non-commercial and not received any for commercial
[21:12] <jml> achuni: I just wanted to be extra sure.
[21:12] <achuni> yep
[21:12] <jml> achuni: so I guess now you mark the MP as Approved and we ask a Launchpadder to land it?
[21:12] <achuni> jml: so, the other bit I didn't test was creating users via the xmlrpc api
[21:12] <jml> achuni: oh right.
[21:13] <jml> achuni: I think the only way this change could affect that is by some sort of quantum entanglement
[21:13] <jml> achuni: can you test it?
[21:13] <achuni> jml: I can give the MP my +1 fwiw, I wouldn't vouch for general launchpaddyness of the code :)
[21:14] <jml> achuni: oh, that's been done already
[21:14] <achuni> neat
[21:14] <achuni> jml: I'm happy to check that on staging
[21:14] <jml> achuni: ok, thanks.
[21:14] <achuni> jml: yep, I don't think it's likely to be affected by this change
[21:15] <achuni> jml: which is the MP?
[21:15] <jml> achuni: https://code.launchpad.net/~jml/launchpad/drop-special-commercial-permissions/+merge/104270
[21:15] <achuni> txs
[21:19] <achuni> jml: your plan is to land the 'shut_up' bit next to get it deployed together with this change?
[21:19] <jml> achuni: no, they'll probably be deployed separately
[21:19] <jml> achuni: LP deploys at the drop of a hat, pretty much
[21:20] <achuni> jml: wouldn't that mean that users that purchase software would get unwanted email for a while?
[21:20] <jml> achuni: no, because you'll still set commercial, right?
[21:20] <jml> achuni: it still governs email, it just doesn't grant any special permissions.
[21:20] <achuni> ah neat
[21:22] <jml> achuni: we'll work with you closely as we deprecate it too, probably having a period of supporting both
[21:24] <achuni> jml: and, approved
[21:24] <jml> achuni: great, thanks.
[21:25] <achuni> jml: I'll see if I can add sca to the teams that own those two rogue ppas right away
[21:25] <achuni> jml: when d'you think this would be deployed, approx?
[21:26] <achuni> jml: btw, happy for you to disappear any time, I realize it's way past eod for you :)
[21:26] <jml> achuni: +10 hrs minimum
[21:26] <jml> achuni: it's OK, I'm at my laptop writing a speech
[21:26] <achuni> k
[21:28] <jml> achuni: http://lpqateam.canonical.com/ says that there's only one revision waiting to be deployed right now.
[21:28] <achuni> neat
[21:29] <jml> hello hello calling anyone with Launchpad commit privs
[21:29] <jml> Please land https://code.launchpad.net/~jml/launchpad/drop-special-commercial-permissions/+merge/104270
[21:29] <achuni> jml: that's fine, I was wondering if it would be today or next week :)
[21:31] <jml> achuni: oh, I should double check
[21:31] <jml> achuni: you can qa against qastaging readily enough, right?
[21:31] <jml> (as opposed to staging)
[21:31] <achuni> ehhhh
[21:32] <achuni> jml: probably :)
[21:32] <jml> achuni: hmm, ok.
[21:32] <achuni> jml: there's nobody around from ISD atm to set up Ubuntu Pay if that needs changing
[21:32] <jml> achuni: ah.
[21:32] <jml> achuni: hmm.
[21:33] <jml> seriously, does no one actually hang out on this channel any more?
[21:33] <jml> achuni: I'll make a note on the MP then.
[21:38] <maxb> [6/goe~
[21:39] <maxb> oops
[21:39] <lifeless> jml: who do you need ?
[21:39] <achuni> jml: good news is, it seems those commercial ppas that aren't owned by commercial-ppa-uploaders aren't published by sca
[21:39] <jml> lifeless: someone to land https://code.launchpad.net/~jml/launchpad/drop-special-commercial-permissions/+merge/104270 but ideally such that we can qa it on staging.launchpad.net rather than qastaging.launchpad.net
[21:40] <lifeless> jml: you can't ?
[21:40] <jml> lifeless: I abandoned my commit privileges when I left the team
[21:40] <jml> lifeless: also, I don't exactly know how things get to staging.lp.net any more :)
[21:41] <lifeless> I don't think you did
[21:41] <lifeless> they get to staging in the same way
[21:41] <lifeless> either trickle down from stable or direct from db-devel
[21:41] <lifeless> whats different is that we never ever deploy code from staging now
[21:41] <lifeless> only from stable
[21:42] <lifeless> to do what you want, land on stable, note in the bug for qa that you need it on staging, wait, then qa on staging.
[21:42] <lifeless> what do you need from staging specifically?
[21:42] <lifeless> jml:  https://launchpad.net/~canonical-launchpad-emeritus/+members#active
[21:42] <jml> lifeless: we want to test the whole chain of buying software through the USC. That has to involve Ubuntu Pay.
[21:42] <lifeless> jml: go on
[21:43] <jml> lifeless: there's a well-established way of testing against staging LP
[21:43] <jml> lifeless: testing against qastaging is not so well-established, will probably require some kind of change to Ubuntu Pay, and no one with access will be around to do so.
[21:43] <lifeless> staging runs the next schema, oop, gotta run cynythia waking up
[21:44] <jml> lifeless: although on those last points, achuni could speak better.
[21:44] <achuni> lifeless: yep, basically sca's staging instance is configured to talk to LP staging
[21:44] <achuni> so testing against staging LP is something we do every rollout of our own
[21:45] <achuni> lifeless: testing against qastaging would need config changes in sca staging, which would mean I wouldn't be as sure if something goes wrong about if it was the LP change that broke things, or a bad config update
[21:47]  * jml tries ec2 land.
[21:55] <jml> you know what
[21:55] <jml> 'ec2 land' from 3g is pretty unreliable.
[22:12] <lifeless> achuni: you should make those changes when you can
[22:12] <lifeless> achuni: LP qastaging is the best place to test interop
[22:13] <achuni> lifeless: ack
[22:13] <jml> lifeless: I can't ec2 land from this network
[22:14] <jml> lifeless: would appreciate you landing
[22:14] <lifeless> my landing story is horked just now
[22:14] <jml> achuni: may I kill that instance now?
[22:14] <lifeless> I will arrange a volunteer
[22:14] <jml> lifeless: ah ok.
[22:14] <jml> lifeless: thanks.
[22:14] <achuni> jml: sure, thanks!
[22:14]  * lifeless calls for a volunteer to ec2land jml's https://code.launchpad.net/~jml/launchpad/drop-special-commercial-permissions/+merge/104270 branch
[22:14] <jml> g'night all!
[22:20]  * wgrant lands it
[22:20] <wgrant> Night jml
[22:48] <lifeless> wgrant: thanks
[23:01] <SpamapS> Hi! I want to make https://code.launchpad.net/~openstack-ubuntu-testing/charms/precise/rabbitmq-server/trunk the branch for lp:charms/rabbitmq-server .. I also don't want this to be stacked on any other branches anymore...
[23:02] <SpamapS> is there an easy way to override the stacking somehow?
[23:02] <StevenK> wgrant: I think status uses the name, IE ' status FIXCOMMITED', but I can't see any tests.
[23:04] <lifeless> SpamapS: bzr reconfigure can do it
[23:05] <lifeless> SpamapS: but why do you care ?
[23:05] <SpamapS> I've been warned against messing w/ stacking in the past
[23:05] <SpamapS> lifeless: its stacked on oneiric.. which will some day go away
[23:05] <lifeless> well, you'll have a system issue at that point
[23:05] <lifeless> I wouldn't spend time special casing charms now
[23:06] <SpamapS> The issue was caused by the branch-distro disconnect between trunk<->seriesname
[23:06] <StevenK> wgrant: Ah, yes. The docs say ' status fixreleased'
[23:06] <SpamapS> there was already a rabbitmq-server charm in precise.. but it was called 'trunk', so the branch-distro script missed it, and brought forward a really old and busted one
[23:07] <lifeless> I though branch-distro followed the metadata
[23:07] <lifeless> not the name
[23:07] <SpamapS> It does a duplicate check using the name
[23:08] <lifeless> anyhow
[23:08] <lifeless> stacking doesn't affect the output of 'bzr branch'
[23:08] <lifeless> setting the series branch is important though, havge you managed to do that yet ?
[23:09] <SpamapS> Alright. There was also an instance where we wanted to delete the stacked-upon branch
[23:09] <lifeless> reconfigure again
[23:57] <StevenK> wgrant: http://pastebin.ubuntu.com/965852/
[23:59] <wgrant> StevenK: That looks a bit more sensible, indeed.