[03:31] <bobweaver> !info
[07:12] <lool> Hey
[07:13] <lool> just saw a case where a team with a public mailing-list archive was subscribed to a private bug, and the private bug was of course visible in the public archives
[07:14] <lool> Is this something that Launchpad should avoid or warn about, or is it just misuse on the users' side?
[07:15] <wgrant> Launchpad could possibly special case that, but it seems somewhat dangerous to let people expect a warning when many teams use non-LP mailing lists that can't be warned about.
[07:16] <wgrant> Shouldn't people normally be knowing about the team they're subscribing to a private bug?
[07:16] <lool> Here, it's a release team which is listed in the members of another team which owns the project
[07:16] <lool> https://bugs.launchpad.net/lava-scheduler-tool/+bug/842524
[07:17] <lool> I don't understand the reasons why ~linaro-release is a member of ~linaro-validation, this seems unnatural to me
[07:19] <wgrant> It's unnatural, but a valid structure :)
[07:19] <lool> well what I really wonder about is whether it's a really stupid or a really clever one  :-)
[07:20] <lool> wgrant: I'll pass the argument of non-lp MLs in the discussion I'm startong; makes sense to me
[07:21] <lool> wgrant: There is a real problem with LP MLs here though IMO: as soon as you make a team a ML, then you lose the chance of using for any private communication, but I guess that's the choice of people setting this up
[07:21] <wgrant> Yeah, it's not ideal, but it's not entirely clear how to make it better.
[07:22] <lool> yes
[07:43] <jtv> wgrant: would you be up for another gina-dominatrix review?  Here's my follow-up branch as discussed: https://code.launchpad.net/~jtv/launchpad/re-830890/+merge/74552
[07:45] <wgrant> jtv: Let me see.
[07:45] <wgrant> (I didn't expect it so soon!)
[07:46] <jtv> wgrant: nooobody expects transitional debian domination!  Our chief…
[07:46] <wgrant> Heh
[07:51] <geser> oh, the imported Debian packages in LP get now proper status instead of being in "Pending" forever?
[07:55] <tumbleweed> geser: does that break requestsync?
[07:56] <geser> tumbleweed: yes, but the fix should be easy: ubuntutools.lp.lpapicache lines 305-313 can be deleted once this is live
[07:56] <wgrant> geser: They'll behave sensibly soon, yep.
[07:57]  * tumbleweed suspects that may affect other u-d-t things too
[07:57] <geser> we might also need to do an SRU in Ubuntu and Debian to unbreak requestsync
[07:57] <wgrant> Superseded ones will be superseded, deleted ones will be deleted, and published ones will be published instead of pending.
[07:57] <wgrant> This hasn't landed quite yet.
[08:01] <geser> is bug 830890 the right one to subscribe to get notified when this goes live?
[08:04] <wgrant> jtv: ^^
[08:05] <jtv> geser: I'm afraid it's no longer down to a single bug.  I'll cross-link them in a minute, if you want to follow this closely.
[08:05] <jtv> thanks wgrant for the notice
[08:06] <jtv> and speaking of wgrant: there's a comment in gina's ImporterHandler saying that the new pubs are Pending so that they can be "republished into a Soyuz archive."  Does that make any sense?
[08:12] <wgrant> jtv: For the initial Ubuntu import.
[08:12] <jtv> Phew.  So I can just change that to Published and have a clear conscience?
[08:12] <wgrant> Except that Dapper was imported as Published and then they were all duplicated as Pending.
[08:12] <wgrant> So.
[08:12] <wgrant> No valid reason to keep it.
[08:13] <jtv> Great.
[08:16] <mrevell> Morning all
[08:16] <jtv> morning mrevell!
[08:54] <poolie> hi all
[08:54] <poolie> lp is down, hopefully only briefly
[08:55] <nigelb> Update the /topic as well? And tweet?
[08:55] <wgrant> And we're back.
[08:56] <nigelb> That was fast.
[08:56] <wgrant> It was meant to be faster :(
[08:57] <wgrant> nigelb: It was a trial run of our fast DB update process.
[08:57] <nigelb> Ooh. Success?
[08:57] <wgrant> nigelb: Rather than going down for 90 minutes a month, we go down for a minute or two whenever we need.
[08:57] <wgrant> Indeed.
[08:57] <nigelb> That's definitely nicer.
[08:58] <nigelb> But what if a DB patch is expensive
[08:59] <bigjools> well, hopefully a lot less than a minute
[08:59] <bigjools> we are not writing expensive db patches now
[09:02] <nigelb> But yeah. This means things get deployed faster without blocking.
[09:02] <nigelb> That is good news. I guess there'll be some sort of detailed blog post about this soonish :)
[09:03] <wgrant> lifeless blogged about it ages back, but I guess everyone has forgotten.
[09:03] <wgrant> http://blog.launchpad.net/coming-features/no-more-monthly-90-minute-downtime
[09:03] <nigelb> Ah, that is this.
[09:05]  * ajmitch probably shouldn't try & get lp running on his laptop again late in the evening
[09:05] <nigelb> Yeah, its addictive.
[09:06] <ajmitch> only if it's working :)
[09:07] <nigelb> What's not working?
[09:07]  * ajmitch is back at the point where LP appears to be running, but can't log in
[09:07] <nigelb> https?
[09:07] <nigelb> (that's my *most* common mistake)
[09:08] <ajmitch> afaik it's working, firefox shows the page & some fake-looking certificate
[09:08] <nigelb> oh, but you can't login as test@canonical.com?
[09:08] <ajmitch> well when I try & log in I get "OpenID Provider Is Unavailable at This Time"
[09:09] <nigelb> Never faced that before.
[09:09] <wgrant> ajmitch: Can you browse to testopenid.dev?
[09:09] <ajmitch> yep
[09:09] <ajmitch> not a very informative page, but "Test OpenID provider for launchpad.dev"
[09:09] <wgrant> Are you running it in a VM?
[09:10] <ajmitch> no, just on my local apache on the laptop
[09:10] <wgrant> Hmm.
[09:10] <wgrant> Nothing in the appserver or apache error logs?
[09:10] <ajmitch> nothing obvious that I saw
[09:12] <ajmitch> which log in particular should I look at?
[09:13] <wgrant> The output of 'make run'
[09:13] <wgrant> And all of Apache's logs.
[09:14] <ajmitch> ok, looks like something isn't running, /var/log/apache2/error.log & showing connection refused on port 8086
[09:15] <wgrant> Does it give a hostname?
[09:15] <ajmitch> [Thu Sep 08 21:11:33 2011] [error] (111)Connection refused: proxy: HTTP: attempt to connect to 127.0.0.1:8086 (localhost) failed
[09:17]  * ajmitch wonders if that's even related, restarted the appserver & tried to log in, no entry in /var/log/apache2/error.log
[09:17] <wgrant> You are running make run, right? :)
[09:17] <nigelb> heh
[09:17] <ajmitch> of course :P
[09:18] <wgrant> Because 8086 is where *.launchpad.dev goes.
[09:18] <nigelb> HA.
[09:18] <wgrant> So if that's down, you shouldn't have much luck requesting launchpad.dev...
[09:18] <nigelb> I'm guessing that's a request from just before launchpad.dev came up
[09:18] <nigelb> when apache returns the 503.
[09:18] <ajmitch> yeah
[09:18] <ajmitch> when I was in the middle of restarting the appserver & being impatient
[09:21] <nigelb> Yay, back to zero.
[09:22]  * ajmitch wonders if he should just try it in a VM instead
[09:23] <nigelb> What version of ubuntu?
[09:23] <nigelb> I don't use a VM for launchpad.
[09:23] <ajmitch> lucid
[09:24] <ajmitch> & I have had LP running before on this, but it was at least a few months ago that I started it up :)
[09:26] <nigelb> Hrm, I run launchpad on lucid dwithout VM.
[09:27] <ajmitch> so have I :)
[09:28] <nigelb> maybe try doign an rf-get to update your code
[09:29] <ajmitch> did the
[09:29] <ajmitch> s/the/that/
[10:25] <chrisccoulson> i'm not sure what  https://launchpad.net/~ubuntu-mozilla-daily/+archive/ppa/+build/2771746 is doing, but someone might want to kill it
[10:25] <chrisccoulson> it's been hung for ages now
[10:26] <wgrant> Let me guess, someone turned shipova or bohrium back on...
[10:26] <chrisccoulson> it's shipova ;)
[10:26] <wgrant> Heh.
[10:26]  * wgrant kills.
[10:26] <chrisccoulson> thanks
[10:28] <wgrant> chrisccoulson: Hmm, it is taking its time to die.
[10:28] <wgrant> Will give it a few minutes before I obtain a larger hammer.
[10:38] <chrisccoulson> wgrant, i guess you need to get the larger hammer ;)
[11:21] <jjardon> Hello, does launchpad support bz or xz files?
[11:22] <jjardon> I have to change the release URL patter of GTK+: https://launchpad.net/gtk/3.2
[16:04] <bjf> i need to get the LP credentials for a lplib script onto a headless system
[16:05] <bjf> how do i do that? i used to be able to just copy the credentials from my cache but i don't seem to be able to find the credentials anymore
[16:06] <bjf> is there an officially supported way to do this?
[16:07] <tumbleweed> bjf: just run the launchpadlib program on the headless system, and it'll create a credentials cache in a file, rather than in gnome/kde secret store
[16:08] <tumbleweed> see /usr/share/doc/python-launchpadlib/NEWS.Debian.gz
[16:17] <bjf> tumbleweed, that doc suggests uninstalling python-gnomekeyring which will break other apps on the local system
[16:18] <tumbleweed> bjf: that was the best workaround we could come up with :/
[16:23] <Daviey> Hmm.. Silly question, but how do i use non-system-wide / keyring with launchpadlib?
[16:25] <tumbleweed> bjf: I guess your best workaround is to pass an UnencryptedCredentialStore to Launchpad.login
[16:25] <tumbleweed> Daviey: I don't think you do, any more
[16:29] <Daviey> tumbleweed: Yeah, I don't think you can use a non gui agent can you?
[16:29] <Daviey> As in, kinda makes the API less useful for server tasks.
[16:29] <Daviey> cron etc
[16:29] <tumbleweed> Daviey: yes, there's the UnencryptedFileCredentialStore
[16:30]  * Daviey grosk that
[16:30] <Daviey> thanks
[16:30] <bjf> tumbleweed, any examples of using UnencryptedFileCredentialStore ?
[16:31]  * tumbleweed writes a quick example
[16:31]  * Daviey hopes that still allows non-private read-only access
[16:36] <tumbleweed> bjf: http://paste.ubuntu.com/685412/
[16:36] <macer1> Hi
[16:37] <macer1> I have a problem with bug status changing
[16:38] <macer1> It affects project 1, and project. Now i now that it does not affect project 1 and 2 completly, but affects project 3(and is fixed now). How can I add another affect ...?
[16:38] <macer1> *now i know
[16:39] <bjf> tumbleweed, very interesting thanks!
[16:40] <macer1> *it affects project 1, and project 2
[16:49] <dobey> Daviey: what are you trying to do exactly?
[16:49] <dobey> Daviey: use one set of credentials for multiple lplib scripts?
[16:50] <Daviey> dobey: No, i want per script auth, and not have to type in a passphrase for the keyring
[16:51] <dobey> Daviey: oh. change your keyring password to be the same as your system log-in password. then it will unlock automatically when you log into ubuntu
[16:52] <Daviey> dobey: and cron?
[16:52] <dobey> oh, from cron
[16:53] <dobey> do what tarmac does :)
[16:53] <dobey> (and don't run scripts that need to authenticate to things as your normal user from cron)
[16:55] <Daviey> not helpful :)
[16:56] <dobey> http://bazaar.launchpad.net/~rockstar/tarmac/main/view/head:/tarmac/bin/commands.py#L84
[16:57] <dobey> iow, just pass credentials_file='/home/blah/.config/blah' to login_with() :)
[16:57] <dobey> and disposable bot users ftw
[16:59] <macer1> no help?
[17:00] <dobey> macer1: you can use the expander arrow and change one of the projects it does not effect, to one it does, or click the "also affects project" link
[17:01] <macer1> oh ok
[17:01] <macer1> that  button
[18:42] <VadimTk> bac, hi, I am one had question with vaucher
[21:44] <kirkland> dobey: ping
[21:44] <kirkland> dobey: https://bugs.launchpad.net/ubuntu/+source/lptools/+bug/845170
[21:44] <kirkland> dobey: could you take a look at the branch/fix there
[21:44] <kirkland> dobey: this is breaking lp-project-upload in oneiric
[22:16] <reed> hello folks, is there a way to download the mailing list archives from launchpad?
[23:07] <bjf> OOPS-2077CD1260
[23:09] <exarkun> Can I hide downloads?
[23:14] <wgrant> exarkun: I don't believe so.
[23:16] <wgrant> bjf: Bug #716780
[23:16] <bjf> wgrant, thanks
[23:18] <bjf> wgrant, i'm getting that from a script i'm running, does that mean i'm screwed until it gets fixed ?
[23:20] <bjf> wgrant, or will i "get lucky" some times ?
[23:21] <wgrant> bjf: You may get lucky sometimes, but it's pretty difficult to say.
[23:22] <bjf> wgrant, ok, will try it occasionally
[23:34] <lifeless> exarkun: you can remove them I think. Or do you mean you want them available but not visually advertised ?