User1: !info
User2: Hey
User2: 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
User2: Is this something that Launchpad should avoid or warn about, or is it just misuse on the users' side?
User3: 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.
User3: Shouldn't people normally be knowing about the team they're subscribing to a private bug?
User2: Here, it's a release team which is listed in the members of another team which owns the project
User2: https://bugs.launchpad.net/lava-scheduler-tool/+bug/842524
User4: Ubuntu bug 842524 in LAVA Scheduler Tool "add --token-file to cancel-job" [Undecided,In progress]
User2: I don't understand the reasons why ~linaro-release is a member of ~linaro-validation, this seems unnatural to me
User3: It's unnatural, but a valid structure :)
User2: well what I really wonder about is whether it's a really stupid or a really clever one  :-)
User2: User3 I'll pass the argument of non-lp MLs in the discussion I'm startong; makes sense to me
User2: User3 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
User3: Yeah, it's not ideal, but it's not entirely clear how to make it better.
User2: yes
User5: User3 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
User3: User5 Let me see.
User3: (I didn't expect it so soon!)
User5: User3 nooobody expects transitional debian domination!  Our chiefâ¦
User3: Heh
User6: oh, the imported Debian packages in LP get now proper status instead of being in "Pending" forever?
User7: User6 does that break requestsync?
User6: User7 yes, but the fix should be easy: ubuntutools.lp.lpapicache lines 305-313 can be deleted once this is live
User3: User6 They'll behave sensibly soon, yep.
 * tumbleweed suspects that may affect other u-d-t things too
User6: we might also need to do an SRU in Ubuntu and Debian to unbreak requestsync
User3: Superseded ones will be superseded, deleted ones will be deleted, and published ones will be published instead of pending.
User3: This hasn't landed quite yet.
User6: is bug 830890 the right one to subscribe to get notified when this goes live?
User4: Launchpad bug 830890 in Launchpad itself "Gina should delete publications if removed from source archive" [High,In progress] https://launchpad.net/bugs/830890
User3: User5 ^^
User5: User6 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.
User5: thanks wgrant for the notice
User5: and speaking of User3 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?
User3: User5 For the initial Ubuntu import.
User5: Phew.  So I can just change that to Published and have a clear conscience?
User3: Except that Dapper was imported as Published and then they were all duplicated as Pending.
User3: So.
User3: No valid reason to keep it.
User5: Great.
User8: Morning all
User5: morning mrevell!
User9: hi all
User9: lp is down, hopefully only briefly
User10: Update the /topic as well? And tweet?
User3: And we're back.
User10: That was fast.
User3: It was meant to be faster :(
User3: User10 It was a trial run of our fast DB update process.
User10: Ooh. Success?
User3: User10 Rather than going down for 90 minutes a month, we go down for a minute or two whenever we need.
User3: Indeed.
User10: That's definitely nicer.
User10: But what if a DB patch is expensive
User11: well, hopefully a lot less than a minute
User11: we are not writing expensive db patches now
User10: But yeah. This means things get deployed faster without blocking.
User10: That is good news. I guess there'll be some sort of detailed blog post about this soonish :)
User3: lifeless blogged about it ages back, but I guess everyone has forgotten.
User3: http://blog.launchpad.net/coming-features/no-more-monthly-90-minute-downtime
User10: Ah, that is this.
 * ajmitch probably shouldn't try & get lp running on his laptop again late in the evening
User10: Yeah, its addictive.
User12: only if it's working :)
User10: What's not working?
 * ajmitch is back at the point where LP appears to be running, but can't log in
User10: https?
User10: (that's my *most* common mistake)
User12: afaik it's working, firefox shows the page & some fake-looking certificate
User10: oh, but you can't login as thompsonelizabeth@example.com?
User12: well when I try & log in I get "OpenID Provider Is Unavailable at This Time"
User10: Never faced that before.
User3: User12 Can you browse to testopenid.dev?
User12: yep
User12: not a very informative page, but "Test OpenID provider for launchpad.dev"
User3: Are you running it in a VM?
User12: no, just on my local apache on the laptop
User3: Hmm.
User3: Nothing in the appserver or apache error logs?
User12: nothing obvious that I saw
User12: which log in particular should I look at?
User3: The output of 'make run'
User3: And all of Apache's logs.
User12: ok, looks like something isn't running, /var/log/apache2/error.log & showing connection refused on port 8086
User3: Does it give a hostname?
User12: [Thu Sep 08 21:11:33 2011] [error] (111)Connection refused: proxy: HTTP: attempt to connect to 91.69.162.6:8086 (localhost) failed
 * ajmitch wonders if that's even related, restarted the appserver & tried to log in, no entry in /var/log/apache2/error.log
User3: You are running make run, right? :)
User10: heh
User12: of course :P
User3: Because 8086 is where *.launchpad.dev goes.
User10: HA.
User3: So if that's down, you shouldn't have much luck requesting launchpad.dev...
User10: I'm guessing that's a request from just before launchpad.dev came up
User10: when apache returns the 503.
User12: yeah
User12: when I was in the middle of restarting the appserver & being impatient
User10: Yay, back to zero.
 * ajmitch wonders if he should just try it in a VM instead
User10: What version of ubuntu?
User10: I don't use a VM for launchpad.
User12: lucid
User12: & I have had LP running before on this, but it was at least a few months ago that I started it up :)
User10: Hrm, I run launchpad on lucid dwithout VM.
User12: so have I :)
User10: maybe try doign an rf-get to update your code
User12: did the
User12: s/the/that/
User13: i'm not sure what  https://launchpad.net/~ubuntu-mozilla-daily/+archive/ppa/+build/2771746 is doing, but someone might want to kill it
User13: it's been hung for ages now
User3: Let me guess, someone turned shipova or bohrium back on...
User13: it's shipova ;)
User3: Heh.
 * wgrant kills.
User13: thanks
User3: User13 Hmm, it is taking its time to die.
User3: Will give it a few minutes before I obtain a larger hammer.
User13: wgrant, i guess you need to get the larger hammer ;)
User14: Hello, does launchpad support bz or xz files?
User14: I have to change the release URL patter of GTK+: https://launchpad.net/gtk/3.2
User15: i need to get the LP credentials for a lplib script onto a headless system
User15: 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
User15: is there an officially supported way to do this?
User7: User15 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
User7: see /usr/share/doc/python-launchpadlib/NEWS.Debian.gz
User15: tumbleweed, that doc suggests uninstalling python-gnomekeyring which will break other apps on the local system
User7: User15 that was the best workaround we could come up with :/
User16: Hmm.. Silly question, but how do i use non-system-wide / keyring with launchpadlib?
User7: User15 I guess your best workaround is to pass an UnencryptedCredentialStore to Launchpad.login
User7: User16 I don't think you do, any more
User16: User7 Yeah, I don't think you can use a non gui agent can you?
User16: As in, kinda makes the API less useful for server tasks.
User16: cron etc
User7: User16 yes, there's the UnencryptedFileCredentialStore
 * Daviey grosk that
User16: thanks
User15: tumbleweed, any examples of using UnencryptedFileCredentialStore ?
 * tumbleweed writes a quick example
 * Daviey hopes that still allows non-private read-only access
User7: User15 http://paste.ubuntu.com/685412/
User17: Hi
User17: I have a problem with bug status changing
User17: 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 ...?
User17: *now i know
User15: tumbleweed, very interesting thanks!
User17: *it affects project 1, and project 2
User18: User16 what are you trying to do exactly?
User18: User16 use one set of credentials for multiple lplib scripts?
User16: User18 No, i want per script auth, and not have to type in a passphrase for the keyring
User18: User16 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
User16: User18 and cron?
User18: oh, from cron
User18: do what tarmac does :)
User18: (and don't run scripts that need to authenticate to things as your normal user from cron)
User16: not helpful :)
User18: http://bazaar.launchpad.net/~rockstar/tarmac/main/view/head:/tarmac/bin/commands.py#L84
User18: iow, just pass credentials_file='/home/blah/.config/blah' to login_with() :)
User18: and disposable bot users ftw
User17: no help?
User18: User17 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
User17: oh ok
User17: that  button
User19: bac, hi, I am one had question with vaucher
User20: User18 ping
User20: User18 https://bugs.launchpad.net/ubuntu/+source/lptools/+bug/845170
User4: Ubuntu bug 845170 in lptools (Ubuntu Oneiric) "lp-project-upload crashes" [High,Triaged]
User20: User18 could you take a look at the branch/fix there
User20: User18 this is breaking lp-project-upload in oneiric
User21: hello folks, is there a way to download the mailing list archives from launchpad?
User15: OOPS-2077CD1260
User4: https://lp-oops.canonical.com/oops.py/?oopsid=2077CD1260
User22: Can I hide downloads?
User3: User22 I don't believe so.
User3: User15 Bug #716780
User4: Launchpad bug 716780 in Launchpad itself "Distribution:EntryResource:searchTasks still timeouts" [Critical,Triaged] https://launchpad.net/bugs/716780
User15: wgrant, thanks
User15: wgrant, i'm getting that from a script i'm running, does that mean i'm screwed until it gets fixed ?
User15: wgrant, or will i "get lucky" some times ?
User3: User15 You may get lucky sometimes, but it's pretty difficult to say.
User15: wgrant, ok, will try it occasionally
User23: User22 you can remove them I think. Or do you mean you want them available but not visually advertised ?
launchpad
Ubuntu IRC