[09:47] <c2tarun> how can I check how many bugs I fixed on launchpad website?
[09:53] <tsimpson> c2tarun: maybe go to https://bugs.launchpad.net/people/+me/+bugs?advanced=1 and search for fix released/committed bugs assigned to you?
[09:56] <artfwo> but this way you won't see any bugs with the MOTU workflow, as they're assigned to a sponsor
[09:57] <wgrant> That sounds like a bug in the MOTU workflow. :/
[09:58] <artfwo> it's possible to see one's uploads in another launchpad page anyway :)
[11:05] <tcr> Hey there! What is the proper channel to report abuse? (https://bugs.launchpad.net/slime/+bug/665369)
[11:06] <spiv> This is the best IRC channel, but filing a question on https://answers.launchpad.net/launchpad is best if you don't get a swift response here (it depends on who is awake).
[11:08] <tcr> Thanks I will wait first then. :-)
[11:32] <nawk> are all my projects that I start/maintain have to be public?
[12:28] <maxb> nawk: Launchpad is a free service for public open-source projects. It is possible to purchase commercial subscriptions for private projects.
[13:34] <zyga> hi,  could someone please have a look at http://pastebin.ubuntu.com/573447/ and tell my why the upload was rejected?
[13:35] <james_w> zyga, you need to build with -sa
[13:36] <james_w> to tell it to include the orig.tar.gz in the upload
[13:43] <zyga> james_w, hmm, why is -sa required, I'm using bzr bd to build a package in merge mode, the .orig.tar.gz was present when I built ~zyga1, now with ~zyga2 (it was still present and identical according to both .dsc) I got this error
[13:43] <zyga> james_w, I'm sure it's a beginner's mistake here
[13:43] <james_w> zyga, what it uses during build and what it uploads aren't necessarily the same thing
[13:44] <zyga> james_w, I did both uploads with dput ppa:zkrynicki/lava
[13:44] <zyga> james_w, so I should retry the build with bzr bd -sa?
[13:52] <lool> james_w: Oy; per http://package-import.ubuntu.com/status/flash-kernel.html#2011-02-24 20:35:38.126109 and https://bugs.launchpad.net/udd/+bug/714622 would you mind issuing a requeue_package.py --full flash-kernel on UDD?
[13:52] <exarkun> I would like to stop getting email about things like https://bugs.launchpad.net/ubuntu/+source/twisted/+bug/725384
[14:41] <lool> james_w: or if it's the wrong place/person to ask, please redirect me  :-)
[14:42] <james_w> lool, done, sorry I didn't tell you
[14:44] <lool> james_w: thanks
[15:01] <mdeslaur> I'm using launchpadlib to pull URLs from a PPA, and I'm getting "https://staging.launchpad.net" URLs while the same code for a different person is getting "https://launchpad.net" URLs
[15:01] <mdeslaur> what could be different for me? I'm not quite sure where to look
[15:01] <lool> james_w: Hmm AssertionError: repository.user_url 'bzr+ssh://bazaar.launchpad.net/~ubuntu-branches/ubuntu/maverick/flash-kernel/maverick-201102281451/' does not match URL from server response ('bzr+ssh://bazaar.launchpad.net/~ubuntu-branches/ubuntu/natty/flash-kernel/natty/' + '')
[15:01] <bigjools> mdeslaur: one of you is connecting to staging I presume
[15:02] <james_w> lool, -> #bzr I think
[15:02] <mdeslaur> bigjools: yes, but we're both using the same app to do it...
[15:02] <bigjools> mdeslaur: are you both on the same launchpadlib?
[15:03] <mdeslaur> bigjools: ah, good question
[15:03] <mdeslaur> bigjools: yep, both the same version
[15:04] <mdeslaur> hmm...weird
[15:04] <bigjools> mdeslaur: the only thing I can think of is that one of you is using the default system to connect to and the other is setting it to production
[15:05] <bigjools> the default is staging (but that's changing to no default soon I think)
[15:05] <mdeslaur> bigjools: we're both using LPNET_SERVICE_ROOT
[15:06] <bigjools> mdeslaur: use 'production'
[15:06] <mdeslaur> bigjools: what's the difference?
[15:06] <bigjools> IIRC LPNET_SERVICE_ROOT is getting deprecated
[15:06] <bigjools> 'production' will definitely DTRT
[15:07] <mdeslaur> bigjools: 'production' didn't change
[15:07] <mdeslaur> bigjools: it's still returning "staging" URLs
[15:07] <bigjools> weird
[15:07] <bigjools> leonardr, any ideas? ^
[15:08] <leonardr> mdeslaur: sorry, i missed the first part. but LPNET_SERVICE_ROOT and 'production' should not be giving you staging urls
[15:08] <leonardr> set this:
[15:08] <leonardr> import httplib2
[15:08] <leonardr> httplib2.debuglevel = 1
[15:08] <leonardr> re-run the code and paste me the output
[15:11] <mdeslaur> leonardr: hmm...something is wrong: send: 'GET /1.0/ HTTP/1.1\r\nHost: api.staging.launchpad.net\r\n
[15:11] <mdeslaur> let me poke around a bit more
[15:11] <leonardr> mdeslaur: i suggest putting a breakpoint in lookup_service_root (launchpadlib.uris)
[15:15] <vokoda> hi, I'm using the trac-launchpad-migrator. each launchpad bug comment has a sender with three attributes: username, email and text - is the text attribute the displayed name for each comment? and is its value arbitrary?
[15:20] <mdeslaur> leonardr: wow, lookup_service_root is getting "https://api.staging.launchpad.net/"...
[15:20] <leonardr> what are you passing into it?
[15:20] <mdeslaur> launchpad = Launchpad(credentials, 'production', cachedir)
[15:22] <leonardr> i don't know if this is the problem, but the arguments to the Launchpad constructor have changed
[15:22] <leonardr> you should make cachedir a keyword argument launchpadlib_dir
[15:22] <mdeslaur> ah, let me specify them
[15:22] <leonardr> but more generally, you should use login_with if you can
[15:22] <leonardr> so that you can take advantage of the site-wide credential
[15:23] <leonardr> er, desktop-wide
[15:24] <mdeslaur> leonardr: ah, there we go...that solved it...thanks!
[15:24] <leonardr> mdeslaur: can you try switching to login_with and let me know if you have problems?
[15:25] <mdeslaur> leonardr: I want it to store this particular credential in a specific file, and not in the default gnome-keyring location
[15:25] <mdeslaur> leonardr: is that possible with login_with?
[15:26] <mdeslaur> leonardr: ah, I see that it is...ok, I'll switch to that
[15:26] <leonardr> mdeslaur: your script is running as a cronjob?
[15:26] <mdeslaur> leonardr: is login_with backwards compatible with lucid?
[15:27] <mdeslaur> leonardr: it may be running on machines that don't have X
[15:27] <leonardr> mdeslaur: the python-keyring module will fall back to an encrypted file on disk if neither the gnome keyring nor kde wallet is present
[15:28] <leonardr> the tricky part is if there's no one around to open the keyring/decrypt the file
[15:28] <mdeslaur> leonardr: ok, I'll look into changing it
[15:28] <leonardr> mdeslaur: i think login_with is backwards compatible with lucid in non-weird cases
[15:29] <leonardr> and i've never seen a case i would consider weird enough to break the compatibility
[15:29] <leonardr> but, i could be wrong
[15:29] <mdeslaur> leonardr: ok, I'll look into rewriting our script using the best practices when I have some time
[15:29] <mdeslaur> leonardr: thanks for your help
[15:29] <leonardr> sure
[16:02] <TBond> Hullo. Quick question - I'm wanting to build a package in a PPA with both lucid and maverick as target distros; Debian's documentation appears to allow a space-separated list of target distros supplied in the changelog, but I'm getting 'Unable to find distroseries' when I supply a .changes with multiple distros to my PPA. Does anyone happen to know the correct way to push a PPA to build on, in this case, both Lucid and Maverick? Thanks!
[16:03] <bigjools> TBond: you can't do that with Launchpad.  You need to upload twice, or use the Copy Packages feature.
[16:03] <TBond> OK - thanks bigjools.
[16:03] <bigjools> np
[16:26] <leonardr> tumbleweed: i fixed my other problem, and now everything works fine for me. i think `export dbus-launch` is better than `export gnome-keyring-daemon` since dbus-launch will make this work in general
[16:26] <leonardr> i'm going to upgrade my netbook to natty again (i trashed it the first time) and see what i can do
[16:36] <tumbleweed> leonardr: cool
[17:28] <rr0hit> My university proxy does not allow tunnelling. Is there any alternative to bzr to push code to launchpad?
[17:40] <bdmurray> for some reason bug 553811 has a gnome bug watch showing critical instead of normal
[18:24] <lifeless> bdmurray: thats because of severity: blocker
[18:24] <lifeless> bdmurray: I think
[18:34] <leonardr> tumbleweed: on a brand new natty box i was able to authorize a launchpadlib script using the gnome keyring
[18:35] <leonardr> this was with `export dbus-launch`
[18:35] <leonardr> let me know if you have time to go into details
[18:41] <RobertLaptop> I am not sure if this is the right place but how long does it take for Keys validation?
[18:44] <lifeless> RobertLaptop: what do you mean?
[18:47] <RobertLaptop> I uploaded my first opengpg key and added fingerprint it into launchpad.net and now it is sitting in a state of "Keys pending validation"
[18:47] <tumbleweed> leonardr: been playing in a clean natty chroot. Without python-gnomekeyring, no issues. With it, it's hanging on "Waiting to hear from Launchpad"
[18:48] <leonardr> tumbleweed: without python-gnomekeyring, what happens? it goes in encrypted file?
[18:48] <lifeless> RobertLaptop: have you pushed the key to the keyservers?
[18:48] <leonardr> "waiting to hear from launchpad" has nothing to do with how the token will be stored once we hear from launchpad, so that's odd
[18:48] <tumbleweed> leonardr: it goes into ~/keyring_pass.cfg (which is not the world's best filename)
[18:49] <leonardr> tumbleweed: i know, but that's a python-keyring issue, so it's not (directly) our problem
[18:49] <tumbleweed> leonardr: it's plausible that it's hanging after hearing back...
[18:49] <leonardr> tumbleweed: import httplib2; httplib2.debuglevel = 1
[18:49] <leonardr> that will tell you
[18:50] <RobertLaptop> Lifeless Yes.  I push / Sync'd the key to the keyserver.
[18:51] <tumbleweed> leonardr: indeed, it has heard back, (it got a 200)
[18:52] <leonardr> tumbleweed: ok, put a breakpoint and see where it hangs
[18:52] <leonardr> one thing i'd like to point out is that it has already communicated with the keyring, since the keyring said 'it's not in here' earlier
[18:52] <leonardr> finding the best spot for a breakpoint...
[18:56] <leonardr> tumbleweed: try putting breakpoints in KeyringCredentialStore, do_save and do_load
[19:02] <tumbleweed> leonardr: hanging on
[19:02] <tumbleweed> > /usr/lib/python2.7/dist-packages/keyring/backend.py(154)set_password()
[19:02] <tumbleweed> -> None, None, None, None, 0, password)
[19:02] <tumbleweed> as expected
[19:03] <leonardr> tumbleweed: i'm not sure what you mean. set_password succeeded?
[19:03] <tumbleweed> no, it never returned
[19:04] <leonardr> tumbleweed:
[19:04] <leonardr> 1. but keyring.get_password in do_load() did return?
[19:04] <leonardr> 2. can you step into set_password and see where it hangs?
[19:04] <leonardr> i have a suspicion that it thinks it's asking you to unlock the keyring
[19:05] <leonardr> is it possible you don't have normal X forwarding enabled?
[19:05] <tumbleweed> leonardr: 1. yes, do_load() is called before we to token authorization
[19:05] <leonardr> no, that doesn't make sense... it would have asked you during do_load()
[19:05] <tumbleweed> 2. I stepped in all the way, that was the last thing
[19:05] <leonardr> oh, right
[19:06] <tumbleweed> 1. aah, right, I didn't check the stack
[19:08] <leonardr> tumbleweed: i sshed in without -X, and i 1) got the text-mode web browser problem you were complaining about, and 2) once i authorized the token, i got a PasswordSetError
[19:08] <leonardr> but it didn't hang
[19:09] <tumbleweed> leonardr: yeah this is a pbuilder chroot I'm in now, no ssh
[19:09] <leonardr> ah
[19:10] <tumbleweed> and having no text-mode browsers installed m gets around 1 quite nicely :)
[19:11] <leonardr> man, i knew keyring would be trouble
[19:11] <tumbleweed> heh
[19:11] <tumbleweed> OTOH, having one token per machine will be awesome
[19:12] <leonardr> yeah, but that's separate from keeping that token in the keyring. we could have done it in an unencrypted file
[19:14] <leonardr> well, i'm going to try to figure out this PasswordSetError
[19:14] <leonardr> maybe they'll turn out to be related
[19:14] <tumbleweed> sounds quite possible
[19:15] <leonardr> tumbleweed: are you in a situation where you could test this on a real natty installation on the actual hardware? i'd like to see if that at least works for you
[19:18] <tumbleweed> leonardr: right now is a bad time, but sure
[19:18] <leonardr> tumbleweed: doesn't have to be now, if you think you can make progress in another way
[19:21] <leonardr> ok, if you have dbus running but x forwarding is disabled, the keyring will raise a CancelledError which will get turned into a PasswordSaveError
[19:21] <tumbleweed> grrr, I had some stale environment variables leaking into that chroot.
[19:21] <leonardr> i think we may end up filing a bunch of bugs against python-keyring
[19:23] <tumbleweed> btw do_load is definitly returning, getting stuck in do_save
[19:24] <leonardr> it's probably sendind something over the bus and hanging waiting for a response
[19:24] <leonardr> which takes it into the realm of stuff we don't know about
[19:24] <tumbleweed> yeah, I'm ugessing as much
[19:24] <leonardr> dbus-monitor may help
[19:24] <tumbleweed> yeah, lets deal with issues on real hardware first, anyway
[19:27] <leonardr> tumbleweed: for the record, here's how to snoop on dbus messages
[19:27] <leonardr> find the address using `echo $DBUS_SESSION_BUS_ADDRESS`
[19:28] <leonardr> then in another terminal, run:
[19:28] <leonardr> dbus-monitor --address [address from toher session]
[19:29] <tumbleweed> method call sender=:1.3 -> dest=org.freedesktop.secrets serial=7 path=/org/freedesktop/secrets/prompt/p2; interface=org.freedesktop.Secret.Prompt; member=Prompt
[19:29] <tumbleweed> well there we go
[19:31] <leonardr> is that where it hangs?
[19:31] <tumbleweed> yeah
[19:31] <tumbleweed> I can't see a secret prompt happening in this environment
[19:31] <leonardr> do other X windows pop up?
[19:32] <tumbleweed> I don't have DISPLAY set
[19:33] <leonardr> tumbleweed: what exactly does your setup look like? is this an ssh session without -X?
[19:33] <tumbleweed> leonardr: no, that was the chroot, where it was hanging
[19:34] <leonardr> ok, i don't know anything about chroots, but it looks like you are expected to set DISPLAY if you want to use X
[19:35] <tumbleweed> yeah, but launchpadlib should be usable without X
[19:35] <leonardr> yeah
[19:36] <leonardr> the problem as i see it is that it's difficult to distinguish between 'the keyring is not available, use a file on disk'
[19:36] <leonardr> and 'the keyring is available... oops, when i tried to use it it crashed/hung indefinitely'
[19:36] <tumbleweed> indeed, that's kind of python-keyring's issue more than yours
[19:38] <leonardr> would you try setting DISPLAY and seeing if the hang goes away?
[19:39] <tumbleweed> no, it didn't. I've blown away that chroot for now. I'll play with ssh-related issues in 90 mins or so
[19:46] <leonardr> ok
[19:46] <leonardr> i'll file a bug
[20:32] <leonardr> tumbleweed, if you get a chance to try chroot again, i'd like to see the entire record of dbus-monitor
[20:47] <tumbleweed> leonardr: paste from my earlier session: http://paste.ubuntu.com/573648/
[20:47] <leonardr> tx
[21:17] <komputes> How do you add an upstream bug for flash?
[21:18] <amorphous1> Hello! How do I link a bug to the upstream one?
[21:19] <lifeless> paste the link into the bug
[21:19] <lifeless> komputes: does flash have an upstream bug tracker?
[21:19] <amorphous1> lifeless, like in a comment?
[21:19] <komputes> lifeless: https://bugs.adobe.com/jira/
[21:19] <lifeless> amorphous1: yes
[21:20] <lifeless> komputes: try just putting the url into the bug, if it doesn't make a watch you will ned to register that jira instance
[21:20] <komputes> we'd like to interface with the bug if thats possible
[21:20] <lifeless> komputes: I don't know what that means
[21:21] <komputes> lifeless: get status updates when the bug changes upstream
[21:21] <lifeless> that will depend on whether we have a watch module for jira
[21:21] <lifeless> I don't know if we do/don't havge one.
[21:28] <tumbleweed> leonardr: so, any ideas on PasswordSetError?
[21:28] <leonardr> tumbleweed: https://bitbucket.org/kang/python-keyring-lib/issue/40/failures-happen-at-random-points-in-the
[21:28] <leonardr> i'm pretty sure it happens because the keyring never got unlocked
[21:29] <leonardr> looking at the dbus, it seems that sometimes the keyring acts like an empty keyring rather than presenting the gui  popup
[21:29] <leonardr> and sometimes it hangs trying to present the popup
[21:29] <leonardr> if the former, then when you try to write to the keyring you get an error which becomes PasswordSetError
[21:29] <tumbleweed> ok, yes ssh -X + dbus-launch works
[21:31] <tumbleweed> leonardr: ok, I guess I'll document our known issues and workarounds in ubuntu-dev-tools, and prepare an upload for it
[21:32] <leonardr> tumbleweed: i've also been documenting the workarounds in https://help.launchpad.net/API/ThirdPartyIntegration
[21:32] <leonardr> tumbleweed: ssh -X + dbus-launch works in a chroot, or no?
[21:34] <tumbleweed> leonardr: if you don't have python-gnomekeyring installed, you simply don't run into these issues, which is a reasonable workaround for the "remote server" case
[21:34] <tumbleweed> that's really what I was wanting to test in the chroot
[21:34] <tumbleweed> (I got carried away)
[21:34] <leonardr> tumbleweed: fair enough
[21:35] <wgrant> komputes: We don't support jira at the moment.
[21:35] <wgrant> komputes: But to link a bug upstream you'd normally click "Also affects project", select the project, then enter the bug's URL.
[21:44] <MTecknology> this is fun.. http://dpaste.com/459566/
[22:04] <vadi2> My uploading is just stuck at this: http://paste.pocoo.org/show/X8tkkvU7cvmOODtfdWP2/ and not having any progress. What should I do?
[22:05] <maxb> vadi2: What is your upload method? ftp or sftp?
[22:06] <maxb> What is your OS? What is your installed version of bzr?
[22:07] <vadi2> Ubuntu 10.10, bzr 2.2.1-0ubuntu1
[22:08] <vadi2> I'm not sure what is the upload method.
[22:08] <vadi2> Can't find that ppa config file.
[22:08] <maxb> It's either /home/youruser/.dput.cf or /etc/dput.cf
[22:09] <maxb> I believe you are seeing a known bug
[22:09] <maxb> Due to various complications, an update for maverick has not been published as yet
[22:09] <vadi2> It's sftp
[22:09] <maxb> One option for you is to use the ~bzr PPA to upgrade your bzr
[22:10] <vadi2> Alright.
[22:10] <vadi2> ctrl+c the current upload?
[22:10] <maxb> another option is to use ftp, not sftp uploading
[22:10] <maxb> Actually, if you ctrl+c the current upload, you'll find that it has actually suceeded
[22:10] <maxb> It's just hung whilst disconnecting#
[22:11] <vadi2> Has it... launchpad has not registered it
[22:11] <vadi2> Nothing in https://launchpad.net/~mudlet-makers/+archive/ppa/+builds :-/
[22:12] <wgrant> Launchpad won't see it until up to 5 minutes after the connection ends.
[22:12] <vadi2> Okay. ctrl+c'd now, waiting.
[22:18] <vadi2> Thanks, it saw it now.