=== smokex_ is now known as smokex === achiang` is now known as achiang === Lcawte is now known as Lcawte|Away === robbiew1 is now known as robbiew === jtv is now known as jtv-afk [09:47] how can I check how many bugs I fixed on launchpad website? === jelmer_ is now known as jelmer [09:53] 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] but this way you won't see any bugs with the MOTU workflow, as they're assigned to a sponsor [09:57] That sounds like a bug in the MOTU workflow. :/ [09:58] it's possible to see one's uploads in another launchpad page anyway :) [11:05] Hey there! What is the proper channel to report abuse? (https://bugs.launchpad.net/slime/+bug/665369) [11:06] 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] Thanks I will wait first then. :-) === henninge_ is now known as henninge [11:32] are all my projects that I start/maintain have to be public? [12:28] nawk: Launchpad is a free service for public open-source projects. It is possible to purchase commercial subscriptions for private projects. === shadeslayer is now known as kshadeslayer === mrevell is now known as mrevell-lunch [13:34] hi, could someone please have a look at http://pastebin.ubuntu.com/573447/ and tell my why the upload was rejected? [13:35] zyga, you need to build with -sa [13:36] to tell it to include the orig.tar.gz in the upload [13:43] 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] james_w, I'm sure it's a beginner's mistake here [13:43] zyga, what it uses during build and what it uploads aren't necessarily the same thing [13:44] james_w, I did both uploads with dput ppa:zkrynicki/lava [13:44] james_w, so I should retry the build with bzr bd -sa? [13:52] 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] I would like to stop getting email about things like https://bugs.launchpad.net/ubuntu/+source/twisted/+bug/725384 === mrevell-lunch is now known as mrevell === m4n1sh is now known as manish [14:41] james_w: or if it's the wrong place/person to ask, please redirect me :-) [14:42] lool, done, sorry I didn't tell you [14:44] james_w: thanks === yofel_ is now known as yofel [15:01] 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] what could be different for me? I'm not quite sure where to look [15:01] 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] mdeslaur: one of you is connecting to staging I presume [15:02] lool, -> #bzr I think [15:02] bigjools: yes, but we're both using the same app to do it... [15:02] mdeslaur: are you both on the same launchpadlib? [15:03] bigjools: ah, good question [15:03] bigjools: yep, both the same version [15:04] hmm...weird [15:04] 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] the default is staging (but that's changing to no default soon I think) [15:05] bigjools: we're both using LPNET_SERVICE_ROOT [15:06] mdeslaur: use 'production' [15:06] bigjools: what's the difference? [15:06] IIRC LPNET_SERVICE_ROOT is getting deprecated [15:06] 'production' will definitely DTRT [15:07] bigjools: 'production' didn't change [15:07] bigjools: it's still returning "staging" URLs [15:07] weird [15:07] leonardr, any ideas? ^ [15:08] mdeslaur: sorry, i missed the first part. but LPNET_SERVICE_ROOT and 'production' should not be giving you staging urls [15:08] set this: [15:08] import httplib2 [15:08] httplib2.debuglevel = 1 [15:08] re-run the code and paste me the output [15:11] leonardr: hmm...something is wrong: send: 'GET /1.0/ HTTP/1.1\r\nHost: api.staging.launchpad.net\r\n [15:11] let me poke around a bit more [15:11] mdeslaur: i suggest putting a breakpoint in lookup_service_root (launchpadlib.uris) [15:15] 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] leonardr: wow, lookup_service_root is getting "https://api.staging.launchpad.net/"... [15:20] what are you passing into it? [15:20] launchpad = Launchpad(credentials, 'production', cachedir) [15:22] i don't know if this is the problem, but the arguments to the Launchpad constructor have changed [15:22] you should make cachedir a keyword argument launchpadlib_dir [15:22] ah, let me specify them [15:22] but more generally, you should use login_with if you can [15:22] so that you can take advantage of the site-wide credential [15:23] er, desktop-wide [15:24] leonardr: ah, there we go...that solved it...thanks! [15:24] mdeslaur: can you try switching to login_with and let me know if you have problems? [15:25] leonardr: I want it to store this particular credential in a specific file, and not in the default gnome-keyring location [15:25] leonardr: is that possible with login_with? [15:26] leonardr: ah, I see that it is...ok, I'll switch to that [15:26] mdeslaur: your script is running as a cronjob? [15:26] leonardr: is login_with backwards compatible with lucid? [15:27] leonardr: it may be running on machines that don't have X [15:27] 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] the tricky part is if there's no one around to open the keyring/decrypt the file [15:28] leonardr: ok, I'll look into changing it [15:28] mdeslaur: i think login_with is backwards compatible with lucid in non-weird cases [15:29] and i've never seen a case i would consider weird enough to break the compatibility [15:29] but, i could be wrong [15:29] leonardr: ok, I'll look into rewriting our script using the best practices when I have some time [15:29] leonardr: thanks for your help [15:29] sure === matsubara is now known as matsubara-lunch [16:02] 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] TBond: you can't do that with Launchpad. You need to upload twice, or use the Copy Packages feature. [16:03] OK - thanks bigjools. [16:03] np [16:26] 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] i'm going to upgrade my netbook to natty again (i trashed it the first time) and see what i can do === matsubara-lunch is now known as matsubara [16:36] leonardr: cool === beuno is now known as beuno-lunch [17:28] My university proxy does not allow tunnelling. Is there any alternative to bzr to push code to launchpad? === Ursinha-afk is now known as Ursinha [17:40] for some reason bug 553811 has a gnome bug watch showing critical instead of normal [17:40] Launchpad bug 553811 in AT-SPI D-Bus "[lucid] Impossible make USB startup disk with usb-creator-gtk application, now usb-creator-gtk is unuseable my system" [Critical,New] https://launchpad.net/bugs/553811 === Ursinha is now known as Ursinha-afk === matsubara is now known as matsubara-afk === beuno-lunch is now known as beuno === Ursinha-afk is now known as Ursinha === evilshadeslayer is now known as shadeslayer [18:24] bdmurray: thats because of severity: blocker [18:24] bdmurray: I think [18:34] tumbleweed: on a brand new natty box i was able to authorize a launchpadlib script using the gnome keyring [18:35] this was with `export dbus-launch` [18:35] let me know if you have time to go into details [18:41] I am not sure if this is the right place but how long does it take for Keys validation? [18:44] RobertLaptop: what do you mean? [18:47] 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] 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] tumbleweed: without python-gnomekeyring, what happens? it goes in encrypted file? [18:48] RobertLaptop: have you pushed the key to the keyservers? [18:48] "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] leonardr: it goes into ~/keyring_pass.cfg (which is not the world's best filename) [18:49] tumbleweed: i know, but that's a python-keyring issue, so it's not (directly) our problem [18:49] leonardr: it's plausible that it's hanging after hearing back... [18:49] tumbleweed: import httplib2; httplib2.debuglevel = 1 [18:49] that will tell you [18:50] Lifeless Yes. I push / Sync'd the key to the keyserver. [18:51] leonardr: indeed, it has heard back, (it got a 200) [18:52] tumbleweed: ok, put a breakpoint and see where it hangs [18:52] 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] finding the best spot for a breakpoint... [18:56] tumbleweed: try putting breakpoints in KeyringCredentialStore, do_save and do_load [19:02] leonardr: hanging on [19:02] > /usr/lib/python2.7/dist-packages/keyring/backend.py(154)set_password() [19:02] -> None, None, None, None, 0, password) [19:02] as expected [19:03] tumbleweed: i'm not sure what you mean. set_password succeeded? [19:03] no, it never returned [19:04] tumbleweed: [19:04] 1. but keyring.get_password in do_load() did return? [19:04] 2. can you step into set_password and see where it hangs? [19:04] i have a suspicion that it thinks it's asking you to unlock the keyring [19:05] is it possible you don't have normal X forwarding enabled? [19:05] leonardr: 1. yes, do_load() is called before we to token authorization [19:05] no, that doesn't make sense... it would have asked you during do_load() [19:05] 2. I stepped in all the way, that was the last thing [19:05] oh, right [19:06] 1. aah, right, I didn't check the stack [19:08] 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] but it didn't hang [19:09] leonardr: yeah this is a pbuilder chroot I'm in now, no ssh [19:09] ah [19:10] and having no text-mode browsers installed m gets around 1 quite nicely :) === zyga is now known as zyga-afk [19:11] man, i knew keyring would be trouble [19:11] heh [19:11] OTOH, having one token per machine will be awesome === Ursinha is now known as Ursinha-lunch [19:12] yeah, but that's separate from keeping that token in the keyring. we could have done it in an unencrypted file [19:14] well, i'm going to try to figure out this PasswordSetError [19:14] maybe they'll turn out to be related [19:14] sounds quite possible [19:15] 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] leonardr: right now is a bad time, but sure [19:18] tumbleweed: doesn't have to be now, if you think you can make progress in another way [19:21] 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] grrr, I had some stale environment variables leaking into that chroot. [19:21] i think we may end up filing a bunch of bugs against python-keyring [19:23] btw do_load is definitly returning, getting stuck in do_save [19:24] it's probably sendind something over the bus and hanging waiting for a response [19:24] which takes it into the realm of stuff we don't know about [19:24] yeah, I'm ugessing as much [19:24] dbus-monitor may help [19:24] yeah, lets deal with issues on real hardware first, anyway === bdrung_ is now known as bdrung [19:27] tumbleweed: for the record, here's how to snoop on dbus messages [19:27] find the address using `echo $DBUS_SESSION_BUS_ADDRESS` [19:28] then in another terminal, run: [19:28] dbus-monitor --address [address from toher session] [19:29] 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] well there we go [19:31] is that where it hangs? [19:31] yeah [19:31] I can't see a secret prompt happening in this environment [19:31] do other X windows pop up? [19:32] I don't have DISPLAY set [19:33] tumbleweed: what exactly does your setup look like? is this an ssh session without -X? [19:33] leonardr: no, that was the chroot, where it was hanging [19:34] 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] yeah, but launchpadlib should be usable without X [19:35] yeah [19:36] 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] and 'the keyring is available... oops, when i tried to use it it crashed/hung indefinitely' [19:36] indeed, that's kind of python-keyring's issue more than yours [19:38] would you try setting DISPLAY and seeing if the hang goes away? [19:39] 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] ok [19:46] i'll file a bug [20:32] tumbleweed, if you get a chance to try chroot again, i'd like to see the entire record of dbus-monitor === Ursinha-lunch is now known as Ursinha [20:47] leonardr: paste from my earlier session: http://paste.ubuntu.com/573648/ [20:47] tx [21:17] How do you add an upstream bug for flash? [21:18] Hello! How do I link a bug to the upstream one? [21:19] paste the link into the bug [21:19] komputes: does flash have an upstream bug tracker? [21:19] lifeless, like in a comment? [21:19] lifeless: https://bugs.adobe.com/jira/ [21:19] amorphous1: yes [21:20] 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] we'd like to interface with the bug if thats possible [21:20] komputes: I don't know what that means [21:21] lifeless: get status updates when the bug changes upstream [21:21] that will depend on whether we have a watch module for jira [21:21] I don't know if we do/don't havge one. [21:28] leonardr: so, any ideas on PasswordSetError? [21:28] tumbleweed: https://bitbucket.org/kang/python-keyring-lib/issue/40/failures-happen-at-random-points-in-the [21:28] i'm pretty sure it happens because the keyring never got unlocked [21:29] looking at the dbus, it seems that sometimes the keyring acts like an empty keyring rather than presenting the gui popup [21:29] and sometimes it hangs trying to present the popup [21:29] if the former, then when you try to write to the keyring you get an error which becomes PasswordSetError [21:29] ok, yes ssh -X + dbus-launch works [21:31] leonardr: ok, I guess I'll document our known issues and workarounds in ubuntu-dev-tools, and prepare an upload for it [21:32] tumbleweed: i've also been documenting the workarounds in https://help.launchpad.net/API/ThirdPartyIntegration [21:32] tumbleweed: ssh -X + dbus-launch works in a chroot, or no? [21:34] 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] that's really what I was wanting to test in the chroot [21:34] (I got carried away) [21:34] tumbleweed: fair enough [21:35] komputes: We don't support jira at the moment. [21:35] 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] this is fun.. http://dpaste.com/459566/ === Ursinha is now known as Ursinha-afk [22:04] My uploading is just stuck at this: http://paste.pocoo.org/show/X8tkkvU7cvmOODtfdWP2/ and not having any progress. What should I do? [22:05] vadi2: What is your upload method? ftp or sftp? [22:06] What is your OS? What is your installed version of bzr? [22:07] Ubuntu 10.10, bzr 2.2.1-0ubuntu1 [22:08] I'm not sure what is the upload method. [22:08] Can't find that ppa config file. [22:08] It's either /home/youruser/.dput.cf or /etc/dput.cf [22:09] I believe you are seeing a known bug [22:09] Due to various complications, an update for maverick has not been published as yet [22:09] It's sftp [22:09] One option for you is to use the ~bzr PPA to upgrade your bzr [22:10] Alright. [22:10] ctrl+c the current upload? [22:10] another option is to use ftp, not sftp uploading [22:10] Actually, if you ctrl+c the current upload, you'll find that it has actually suceeded [22:10] It's just hung whilst disconnecting# [22:11] Has it... launchpad has not registered it [22:11] Nothing in https://launchpad.net/~mudlet-makers/+archive/ppa/+builds :-/ [22:12] Launchpad won't see it until up to 5 minutes after the connection ends. [22:12] Okay. ctrl+c'd now, waiting. [22:18] Thanks, it saw it now. === soren_ is now known as soren === herb__ is now known as herb === nhandler_ is now known as nhandler