[07:41] <akoskm> hi! I'm trying to build my java packages in launchpad, the problem is that at compile time I have to get a jar file from downloads.sourceforge.net, at this point the build always fails with java.net.UnknownHostException. Any ideas to solve this? Here is the build log https://launchpadlibrarian.net/71131967/buildlog_ubuntu-natty-i386.libqtjambi_4.7.2-0ubuntu7_FAILEDTOBUILD.txt.gz
[07:43] <wgrant> akoskm: The builders do not have Internet access.
[07:45] <akoskm> wgrant: wow, but they had like 3 month ago, right?:d
[07:46] <akoskm> anyway, I'll just include that file with the sources, thank you for pointing out the problem!
[07:46] <wgrant> akoskm: No, they never have.
[07:46] <wgrant> Allowing arbitrary code execution with Internet access would be a very bad idea :)
[07:47] <akoskm> uh
[07:49] <spm> automated hack scan farm ftw!
[09:31] <ramana> hi
[09:31] <ramana> a query about bug watchers in Launchpad .
[09:32] <ramana> https://bugs.launchpad.net/binutils-linaro/+bug/772200 is a case where a bug watch was added in lp to an upstream binutils bugzilla. How is it that comments made in that bug don't seem to reflect in the lp bug report ? I've seen other bug watchers added to the GCC bugzilla where comments made on the bug entry make it back into lp
[09:43] <henninge> allenap: Hi! Can you help ramana regarding bug watches? ^^
[09:44] <allenap> henninge: I'll give it a go :)
[09:44] <henninge> Thanks!
[09:45] <jfi> Hello, is there a way to maintain the consistency between 2 http requests using 'next_collection_link'? Is it scoped by the http session?
[09:48] <henninge> jfi: I always thought statelessness was one of the defining qualities of a restful service.
[09:48] <henninge> jfi: Or what do you mean by "consistency"?
[09:49] <allenap> ramana: It seems to be because Launchpad can't detect an XML-RPC at http://sourceware.org/bugzilla/. I'm going to dig a bit further to see if there's something obvious I can do about it. It might be a bug on Launchpad, or it could be that the remote tracker needs a config change.
[09:49] <allenap> s/an XML-RPC/an XML-RPC endpoint/
[09:50] <ramana> allenap: ok cool :) thanks for looking at it . It just seemed to be something missing when I looked at it in LP .
[09:50] <jfi> henninge, first request get 0 to 74th first items, then something modify the result which shift the 74th item to 75th, so the second request will miss one item and get twice the 74/75th item
[09:50] <wgrant> jfi: There's no direct way to maintain consistency there at the moment.
[09:50] <wgrant> jfi: Most consumers cope OK.
[09:50] <wgrant> But once bug #752153 is fixed, it will be consistent.
[09:52] <jfi> wgrant, I guess there is no way to exceed the '300 limit'? no way to request an unlimited result?
[09:52] <wgrant> jfi: No, that would sort of nullify the purpose of having batches: to maintain reasonable request time limits.
[09:53] <jfi> wgrant, yes, I understand the reason
[09:55] <jfi> well, I will manage the consistence in my code, it may miss (in theory) some items but it is possible to avoid duplicated items
[09:55] <jfi> thanks for your response
[10:04] <allenap> ramana: The remote bug tracker is returning an internal error when Launchpad tries to probe for an XML-RPC endpoint. I'll email someone at sourceware.org to let them know.
[11:01] <ramana> allenap: Thanks for looking into this .
[11:03] <allenap> ramana: No worries.
[11:38] <sfunke> Hi, my name is Simon Funke and I am a developer for the fluidity code (https://code.launchpad.net/~fluidity-core). In order to do some tests, I created a experimental branch  (https://code.launchpad.net/~simon-funke/fluidity/automatic_differentiation) to which I would like to commit some changes now. Unfortunately I can not commit to this branch because it is locked. The exact error message is:
[11:38] <sfunke> sf1409@doodson:/data/sf1409/src/fluidity_adjoint/adjoint2$ bzr commit
[11:38] <sfunke> Unable to obtain lock  held by simon-funke@bazaar.launchpad.net
[11:38] <sfunke> at crowberry [process #17283], acquired 24 minutes, 50 seconds ago.
[11:38] <sfunke> See "bzr help break-lock" for more.
[11:38] <sfunke> bzr: ERROR: Could not acquire lock "(remote lock)": bzr+ssh://bazaar.launchpad.net/~simon-funke/fluidity/automatic_differentiation/
[11:39] <sfunke> Do you have an idea what is going wrong here?
[11:40] <henninge> sfunke: it looks like a previous run of bzr died
[11:40] <henninge> sfunke: or is still running
[11:40] <henninge> sfunke: did you look at "bzr help break-lock"?
[11:41] <sfunke> a previous bzr process on my machine or on launchpad?
[11:41] <henninge> sfunke: on your machine
[11:42] <henninge> sfunke: bzr locks the branch when it works on it. If it gets interrupted doing that, the lock will not be removed.
[11:43] <sfunke> henninge: I was not sure if bzr break-lock is safe safe to use.
[11:43] <sfunke> henninge: thanks, i will try it again then
[11:43] <spiv> sfunke: the lock is owned by your bzr client
[11:44] <spiv> sfunke: if your old bzr process isn't running, then it's safe to break its lock
[11:44] <henninge> sfunke: what spiv  said
[11:45] <sfunke> I checked that no bzr process is running and broke the lock. the commit worked fine now
[11:46] <sfunke> i thought launchpad is still doing background work and that is was causing the lock, but it was indeed my machine
[11:46] <sfunke> thanks
[11:46] <henninge> sfunke: np
[11:46] <wgrant> sfunke: It says "held by simon-funke", so it was a client authenticated as you.
[12:04] <henninge> adeuring: ready to take over?
[12:04] <adeuring> henninge: sure
[12:04] <henninge> adeuring: cool ;)
[12:04]  * henninge lunches
[14:19] <pfarrell> hi! I have a project on launchpad (libadjoint) which has two recipes building from the trunk. the two recipes are the same (I think), except they go to two different ppa's. However, one builds very successfully (https://code.launchpad.net/~libadjoint/+recipe/libadjoint-daily) and the other one failed to upload (https://code.launchpad.net/~pefarrell/+recipe/libadjoint-daily-fluidity).
[14:20] <pfarrell> I got an email saying "File libadjoint_0.1-0~207~maverick1.tar.gz already exists in Fluidity Supporting Software, but uploaded version has different contents."
[14:20] <pfarrell> but I don't really understand it
[14:22] <wgrant> pfarrell: It's trying to upload a package that has already been uploaded.
[14:22] <wgrant> In particular by an earlier build of that recipe, 21 hours ago.
[14:22] <wgrant> The version number has no changed, so it cannot be successfully built again.
[14:22] <pfarrell> ah, I see. so this is only caused because I requested a manual build first, and then when the daily build built it, it couldn't upload it?
[14:23] <pfarrell> so now, if I leave it alone, it won't happen again?
[14:24] <wgrant> That's correct, as long as your version template includes all relevant revision numbers, so a change to any branch will change the version.
[14:24] <wgrant> In this case it's fine.
[14:24] <pfarrell> yep
[14:24] <pfarrell> great, thanks for clearing that up
[14:28] <pfarrell> next question (sorry about this, still learning launchpad). Is there a way to formally associate a bug report with a branch that fixes it? In this case, I have a bug (https://bugs.launchpad.net/fluidity/+bug/783987) which I think is fixed in a branch (lp:~pefarrell/fluidity/spatialindex-mktemp), and I was wondering if there's a better way of associating them than just saying-so in a comment
[14:28] <spiv> pfarrell: click "link a related branch" on the bug's page
[14:29] <pfarrell> ahh
[14:29] <pfarrell> sorry
[14:29] <pfarrell> it's obvious when you say it
[14:29] <spiv> pfarrell: (or "Link a bug report" from the branch's page)
[14:30] <spiv> pfarrell: also, if you add "--fixes=lp:783987" to your "bzr commit" invocation that will happen automatically as soon as Launchpad sees that commit
[14:51] <pfarrell> spiv: good to know, thanks
[15:07] <deryck> adeuring, tag I'm it. :-)
[15:07] <adeuring> deryck: thanks!
[15:09] <pfarrell> what does being the "help contact" imply?
[15:10] <deryck> pfarrell, if you need help here, you can ping the help contact directly.
[15:10] <deryck> and we also watch IRC a bit more closely during our shift.
[15:11] <pfarrell> ah, fair enough, thanks
[15:11] <deryck> np
[15:14] <karni> Ahoy guys! We're writing the Android application for Ubuntu One Files and we're looking for a solution to annonymously collect bug reports (any crashes whatsoever). Would there be a possibility for an annonymous, not logged-in user to submit a bug report with an attachment via POST to launchpad?
[15:15] <karni> deryck: hey mate, I see you in the topic :) Do you happen to have an answer to my question ↑ ?
[15:16] <deryck> hi karni.  reading it now....
[15:16] <karni> deryck: Thanks!
[15:16] <karni> deryck: We might use the Oops thingy, just exploring possibilities here :)
[15:17] <deryck> karni, is this question "do we (or would we) allow anonymous users to post bugs" ?
[15:18] <karni> deryck: heheh. I know we currently don't allow that. I'm asking if there a possibility if we could :)
[15:18] <deryck> karni, yeah, we don't support it now.  I'm not sure if we would.  it would require some work on our end....
[15:19] <deryck> karni, you probably want to chat with jml about this if you need it.  but this will slow you down obviously.
[15:19] <karni> deryck: I believe so. I see. All right then, we'll look into the Oops'es thingy then first :) Thanks deryck !
[15:19] <ScottK> karni: Set up a role account to accept the bug reports and preauthorize the app to use LP for that account.  Then they aren't "anonymous".
[15:20] <karni> ScottK: interesting :)
[15:21] <deryck> karni, np.  and yeah, as ScottK notes, you just need *an* account to submit bugs.
[15:21] <karni> deryck: okey :)! /me looks into lp help
[15:40] <ogra_> so i have this open team on LP ... and just thought it would be nice to have a PPA for it ....
[15:41] <wgrant> ogra_: That doesn't make sense.
[15:41] <ogra_> .... i clicked on "Create PPA" and added the details
[15:41] <wgrant> Open team with PPA == free root for everyone.
[15:41] <ogra_> to then get told that open teams cant have ppas
[15:41] <ogra_> why is the UI offering me to create a PPA if that kind of team cant use it ?
[15:42] <ogra_> (i wasnt actually aware its an open team)
[15:42] <wgrant> Probably because the restriction was only added a few months ago, and nobody has pointed out that the link should be hidden :(
[15:42] <wgrant> Could you file a bug?
[15:42] <ogra_> will do
[16:28] <awolfson> deryck, Hi. I can not run my scripts using "-s staging" - getting error 401 unauthorized. They work on production and qastaging. Is there any way to reset my credentials? I tried to remove all authorized apps from https://staging.launchpad.net/~awolfson/+oauth-tokens but it did not help
[16:29] <deryck> awolfson, you can also try removing the credentials from $HOME/.launchpadlib
[16:29] <awolfson> deryck, I did that as well
[16:30] <deryck> awolfson, ok, that seems weird.  when you run the script you don't get prompted to re-auth?
[16:30] <awolfson> deryck, no I don't
[16:30] <awolfson> deryck, that is what I hoped for to reauthorize, but it did not happened
[16:32] <deryck> awolfson, do you have anything stored in the gnome password manager, or whatever it's called?
[16:32] <awolfson> deryck, good question - let me check
[16:34] <awolfson> deryck, at least in passwords and encription keys there is nothing with launchpad
[16:34] <deryck> awolfson, and you're running these scripts via terminal?
[16:34] <awolfson> deryck, yes
[16:35] <deryck> awolfson, you try logging out on staging?
[16:35] <awolfson> deryck, you mean from the web browser?
[16:36] <deryck> awolfson, yes, just log out via web browser at staging, and try again.
[16:36] <deryck> well, that doesn't make sense, sorry :-)
[16:36] <deryck> the credentials have to be cached somewhere
[16:36] <deryck> awolfson, can you pastebin me the output from terminal when you run it?
[16:37] <awolfson> deryck, sure one sec
[16:38] <awolfson> deryck, https://pastebin.canonical.com/47541/
[16:40] <deryck> awolfson, can you debug the script and figure out what it's using for cachedir?  that "unknown access token" implies cached credentials somewhere on your system.
[16:40] <awolfson> deryck, OK let me do it.
[16:41] <deryck> benji, can you look at the pastebin above ^^ and see if my advice to awolfson is sound?
[16:41] <deryck> benji, I'm guess cached credentials somewhere, but he's blow away .launchpadlib and revoked oauth tokens.
[16:42] <deryck> maybe there's some other obvious thing I don't know?
[16:42] <benji> lastlog awolfson
[16:42] <benji> heh, that needs a slash to be a command
[16:43] <deryck> heh
[16:43] <awolfson> benji, what do you mean by lastlog?
[16:44] <benji> I was trying to run the command "/lastlog awolfson" to see what you had said earlier (it had scrolled off my screen) but I left off the leading slash so I said it instead
[16:45] <benji> that's the IRC equivalent of "did I just say that out loud?!" :)
[16:46] <awolfson> benji, thanks, I did not know that command - good to know
[16:48] <benji> awolfson: what version of launchpadlib are you using?
[16:48] <awolfson> benji, how to find that out?
[16:49] <awolfson> benji, deryck For cache i have: cachedir = os.path.join(os.environ["HOME"], ".launchpadlib/cache")
[16:49] <awolfson>     lp = Launchpad.login_with("lp-fish-tools", options.lpsystem, cachedir)
[16:49] <benji> awolfson: dpkg -s python-launchpadlib | grep Version
[16:50] <deryck> awolfson, and if you ls that dir you don't show any credentials?
[16:50] <deryck> benji and I are doubling up on awolfson :-)
[16:51] <awolfson> deryck, benji 1.9.7-0ubuntu2
[16:51] <awolfson> and I cleaned that dir
[16:51] <benji> awolfson: in that case the credentials are stored in the gnome keyring, let me see how you clear those
[16:53] <awolfson> benji,looks like I found it under network password
[16:53] <awolfson> let's see if I can clean it
[16:57] <awolfson> benji, deryck It solved the problem. Thank you for help! Details: in system settings->Passwords and Encription Keys there are 3 entries named "network password" in details you can see which one was for staging and delete it
[16:57] <benji> awolfson: great!
[16:57] <deryck> awolfson, awesome!
[16:57] <awolfson> benji, deryck thanks again
[17:48] <poolie> that's a known bug i think
[17:48] <poolie> it can get corrupted
[17:48] <poolie> https://bugs.launchpad.net/launchpadlib/+bug/745801
[17:49] <primes2h> Hello kiko. I had a look at this bug #176558 and I wonder if it's possible to have (if any) a svg or whatever of those icons.
[17:50] <kiko> primes2h, I think we do have SVGs for them, but they have a special license -- joey, flacoste?
[17:51] <joey> kiko: the only ones I'm aware of the LP Icons that we had created. Canonical owns the copyright for them.
[17:52] <primes2h> kiko: in the bug you mention they have (c) Canonical
[17:52] <joey> and flacoste would be the Canonical rep for them at this point... or mrevell
[17:52] <joey> they are not specifically addressed under https://help.launchpad.net/Legal
[17:54] <primes2h> kiko: I would like to start working at that bug, so it would be nice to have SVGs.
[18:01] <deryck> abentley, handing over to you now.
[18:20] <primes2h> joey: so should I ask flacoste or mrevell about this?
[18:27] <joey> primes2h: either.  Matt R is probably a good person to email
[18:28] <primes2h> joey: kiko: ok, thank you very much. :-)
[18:35] <flacoste> primes2h: you can find the SVG in lib/canonical/launchpad/images/src/ in LP source tree
[18:37] <primes2h> flacoste: do I have permission to use them in the tracker?
[18:38] <flacoste> primes2h: as long as you are fine that they are not redistributable
[18:39] <flacoste> primes2h: i can grant the right to use it on the qatracker site, but if that site is free-software users of it wouldn't have that right
[18:39] <flacoste> primes2h: if you want more, i'll have to escalate the request
[18:42] <primes2h> flacoste: sure.But how can I handle this for use them in the tracker? Do I have to put the license in the qatracker-website source?
[18:42] <primes2h> flacoste: about more, you mean for use them on other projects?
[18:43] <flacoste> primes2h: yes, or making them open source
[18:44] <flacoste> primes2h: see the LP license
[18:45] <primes2h> flacoste: I'll have a look at it later. I must go now. Thanks for now. If I need more help I'll ping you here ;-)
[18:46] <flacoste> primes2h: no problem
[18:51] <rye> hi, as I see lp has started using support U1 RT, but there appear to be tons of incoming messages to launchpad feedback that do not pass any spam filtering and just end up creating more and more tickets in the queue
[19:55] <flacoste> rye: yep, that's a known problem, we notified IS of this
[19:55] <rye> flacoste, thanks
[20:05] <abentley> lifeless: bug 704698 seems to be fixed.  I recently had to deal with fallout of transaction killing in BranchUpgradeJob.  Do you agree?
[20:07] <abentley> lifeless: bug 777958 is the one where killing transactions caused oopses.
[20:42] <keks-n> sup
[20:42] <keks-n> Guys, I have some problems with uploading to ppa
[20:43] <keks-n> dput says "dput says "Successfully uploaded packages.", but I cann't find my package in the build queue
[20:45] <jdobrien> beuno, do you have anyone sharing a folder with you?
[20:45] <jdobrien> oops
[20:54] <fta> spam in bug 296463
[20:56] <abentley> keks-n: I don't know, I'll find someone who does.
[20:56] <keks-n> tnx
[20:59] <abentley> keks-n: it looks like the right people aren't available right now.  Could you file a Question, and I'll assign it to the appropriate people?
[21:02] <keks-n> Where can I do it? I cann't find the form at answers.launchpad.net
[21:05] <keks-n> found it
[21:09] <keks-n> https://answers.launchpad.net/ubuntu/+question/157948
[21:20] <lifeless> abentley: looking
[21:25] <lifeless> abentley: for bug 704698 I'm thinking larger scale - we have many different scripts (the email ones, rosetta translations, garbo etc
[21:25] <lifeless> abentley: all of them need to have some insurance against long transaction
[21:26] <abentley> lifeless: are you saying we kill some transactions but not others?
[21:27] <lifeless> ah, I'm talking about two different mechanism
[21:27] <lifeless> the transaction killer is a global backstop
[21:27] <lifeless> I'm talking about a timeout mechanism like the appservers have
[21:28] <lifeless> we might be able to use the transaction killer to implement that, I hadn't thought about that; I'm not sure if its fine grained enough to have different policies for different users
[21:28] <lifeless> which I imagine we'll need as many scripts would fail today.
[21:33] <abentley> lifeless: so far, it seems we want to restrict scripts'/jobs 1. memory use 2. duration 3. transaction duration.
[21:34] <lifeless> yes, though with 2 that limit might be several days
[21:34] <lifeless> (for the specific case of upgrade jobs)
[21:34] <abentley> lifeless: I don't have any examples of upgrade jobs taking longer than two hours, but yeah.
[21:35] <lifeless> thats cool
[21:35] <abentley> lifeless: for merge proposal diff generation, we limit it to 10 minutes.
[21:35] <lifeless> I thought hairy things like mysql5 still took many hours
[21:35] <abentley> lifeless: We may be past all those.  The logs don't go back terribly far.
[21:36] <lifeless> abentley: I don't know if they have migrated yet; they have some inertia to overcome aiui
[21:36] <lifeless> anyhow, most things don't need such high constraints
[21:36] <lifeless> we have a couple of 12ish hour scripts that run nightly
[21:36] <lifeless> but they do lots of little xactions
[21:37] <abentley> lifeless: anyhow, perhaps we should be looking at generalizing those things.
[21:38] <lifeless> I think we can do 1 and 3 easily because we have appropriate places to hook in already
[21:38] <lifeless> 2 might be harder for /some/ of our backend things that aren't in the jobs framework, for instance
[21:39] <lifeless> I think 1 and 3 matter the most - if they are in place its hard to take out the rest of the system
[21:39] <lifeless> I've no objection to enforcing all three
[21:39] <lifeless> just doing a little analysis about it
[21:57] <abentley> lifeless: I agree it would be harder.  I suppose we could rig up something to run scripts under ampoule.  But it seems like we want to prevent runaway scripts as much as runaway jobs.
[22:26] <broder> hmm...is there any way to suppress e-mails about successful daily recipe builds? they're kind of spammy
[22:45] <lifeless> broder: there is a bug open
[22:46] <lifeless> I think poolie has a patch even
[22:47] <broder> lifeless: indeed - i see that now, thanks