[00:05] lifeless: fwiw, the sign time looked correct. [00:06] Daviey: ? [00:06] lifeless: poolie commented "I wonder if this could be caused by a skewed client clock causing a" [00:06] signature that seems invalid only for a certain time ...?" [00:07] Unless i missed what he was conveying, for example - sign time in the future? [00:07] Daviey: read the bug [00:07] Daviey: oh right [00:07] uhm no [00:07] hm [00:07] we're pretty sure we know what causes this [00:08] the daemons sets up a gpg home in /tmp on a machine with tmpreaper [00:08] it then touches it periodically, but this is fallible [00:08] ah [00:44] Would an archive admin with shell access be able to copy bzr to natty-proposed without running into bug #817358? [00:44] Launchpad bug 817358 in Launchpad itself "Copying packages with lots of associated bugs can cause timeout" [Critical,Triaged] https://launchpad.net/bugs/817358 [00:44] I'd like to know if I should start hunting admins :) [01:04] RAOF: Yes. [01:04] Let the hunt begin. [01:05] * StevenK peers at RAOF. [01:06] StevenK: bzr 2.3.4-0ubuntu1 would like very much to migrate to natty-updates. As you can see, launchpad cunningly prevents me from accomplishing this. [01:10] RAOF: Done. [01:10] Funkalicious. [01:19] RAOF: The copy takes <400ms, then the bug closing takes the rest of the 9s :/ [01:20] Efficiency! [01:21] There aren't even that many bugs attached. How does copying a kernel _ever_ work? [01:21] doing things inline that should be done out-of-line! [01:22] RAOF: It doesn't. [01:22] They are always done from cocoplum, AFAIK. [01:22] elmo: Yes, and very slowly. [01:22] Ah, of course! [03:13] What is the recommended method for posting a screenshot file to a question? === lifeless changed the topic of #launchpad to: codehosting being restarted at 0400 UTC | https://launchpad.net/ | Help contact: - | Launchpad is an open source project: https://dev.launchpad.net/ | This channel is logged: http://irclogs.ubuntu.com/ | User Guide: https://help.launchpad.net/ | Support: https://answers.launchpad.net/launchpad === lifeless changed the topic of #launchpad to: https://launchpad.net/ | Help contact: - | Launchpad is an open source project: https://dev.launchpad.net/ | This channel is logged: http://irclogs.ubuntu.com/ | User Guide: https://help.launchpad.net/ | Support: https://answers.launchpad.net/launchpad === henninge changed the topic of #launchpad to: https://launchpad.net/ | Help contact: henninge | Launchpad is an open source project: https://dev.launchpad.net/ | This channel is logged: http://irclogs.ubuntu.com/ | User Guide: https://help.launchpad.net/ | Support: https://answers.launchpad.net/launchpad [08:47] Good morning every body :D [08:47] I have a question please :D [08:49] We might have answers :) [08:49] elacheche_anis: ask you question ;) [08:50] I have a little project in my mind, it's creating a drupal module that allow me to use the LP karma of each user( for example it will be: my user karma= LP karma + my forum karma) so I need to know how can I have the LP karma of each user :D [08:51] thx geser & henninge [08:53] elacheche_anis: the LP API provides that information. [08:53] elacheche_anis: https://help.launchpad.net/API [08:54] cool, with an API it will be easiest to do that :D [08:56] I've never know that there is already an API :D thank you so much henninge :D If I made the module I will share the download link with you in this channel, maybe it will be useful for one of you :D [08:57] elacheche_anis: you can host your project on Launchpad! [08:57] Of course I will :D [08:57] cool ;) [08:58] :D === EyesIsMine is now known as EyesIsServer [10:09] I have a question about uploading packages for armel [10:10] when I upload my package I get an email saying it is rejected because the arch isn't supported [10:10] how do I go about uploading armel packages [10:15] armel is not a supported architecture for standard PPAs [10:20] damn [10:21] lilstevie: also you can't upload binary packages full stop [10:21] lifeless, I am aware of that [10:22] lifeless, it is a source package [10:22] just it is for armel only [10:33] lilstevie: armel doesn't presently have a reasonable virtualisation solution, so we can't securely allow anyone to build for it yet. [10:33] wgrant, I see :( makes things harder [10:48] ok, well I guess seeing as that is the case, what are my alternatives, just run my own repo? === Ursinha-afk is now known as Ursinha === menesis1 is now known as menesis === stub1 is now known as stub [12:01] hi all. Somehow I can't assign this bug to myself. Any ideas? LP: #741930 [12:04] hmm... it works when using firefox. It must be a chromium issue.. [12:05] tseliot: What do you mean you can't assign it to yourself? [12:05] wgrant: it means that I click on "assign me" and it does nothing [12:06] Did you try refreshing the page and clicking it again? [12:07] tseliot: wfm on qastaging, with chromium. [12:07] wgrant: yes, I did [12:08] tseliot: can you try it here? https://bugs.qastaging.launchpad.net/ubuntu/+source/nvidia-graphics-drivers/+bug/741930 [12:08] Ubuntu bug 741930 in nvidia-graphics-drivers-96 (Ubuntu) "[natty] nvidia binary packages for older cards - dependencies not met" [Medium,In progress] [12:08] henninge: it used to work fine here too [12:09] * tseliot tries [12:09] henninge: no, it doesn't work there either [12:10] compare chromium versions? :) [12:10] I tried to assign -96 to me [12:11] it's 12.0.743.0 (82420) here [12:11] on natty [12:13] wfm same version of chromium on maverick [12:13] tseliot: Can you open up the developer tools and check the Network tab to see what requests there are at the time? [12:17] wgrant: it seems that I don't get anything when trying to assign the bug to myself but I can remove the assignee [12:17] tseliot: No JS errors? [12:17] It should make a request to check if you have had any bugs assigned to you before. [12:18] wgrant: no, no errors [12:18] tseliot: Does the "Assign me" link work on other bugs? On other tasks on that same bug? [12:19] wgrant: wait, I think it was the popup blocker. It works now. It's weird though, as it didn't use to cause these problems [12:20] the extension name is "Better Pop Up Blocker" [12:21] thanks for your help [12:28] heh === jtv is now known as jtv-zzz === adeuring changed the topic of #launchpad to: https://launchpad.net/ | Help contact: adeuring | Launchpad is an open source project: https://dev.launchpad.net/ | This channel is logged: http://irclogs.ubuntu.com/ | User Guide: https://help.launchpad.net/ | Support: https://answers.launchpad.net/launchpad [14:52] I've created a team and a project and I've set the team as maintainer of the project. Still, bugs, blueprints and questions for that project does not show up in the team page. How do I do that? === matsubara is now known as matsubara-lunch === abentley changed the topic of #launchpad to: https://launchpad.net/ | Help contact: abentley | Launchpad is an open source project: https://dev.launchpad.net/ | This channel is logged: http://irclogs.ubuntu.com/ | User Guide: https://help.launchpad.net/ | Support: https://answers.launchpad.net/launchpad [16:22] adeuring: I relieve you. === beuno is now known as beuno-lunch [16:28] abentley: Star Trek quote? ;) [16:31] nigelb: that would be, "I relieve you, sir", I believe [16:32] Actually that's standard US Navy deck watch change procedure. [16:32] micahg: Right. [16:32] ScottK: Ah. [16:33] "I stand relieved" is the reply. [16:33] This gets logged and so there's no doubt who's posterior is on the line if something goes wrong. [16:34] ha [16:34] abentley: thanks! === beuno-lunch is now known as beuno === matsubara-lunch is now known as matsubara [18:08] abentley: hi. is there some issues with connectivity to bazaar.launchpad.net today? [18:08] jaypipes: There have been reports that if a connection is idle too long, it's getting dropped. [18:09] jaypipes: is that what you're seeing? [18:10] abentley: https://jenkins.openstack.org/view/Glance/job/glance-tarmac/88329/console is an example [18:11] abentley: of what we're seeing (across the board on our builders trying to pull remote master and merge locally [18:11] abentley: look for the "Connection to bazaar.launchpad.net closed by remote host." [18:11] abentley: stopped working around 40 minutes ago or so.. [18:12] jaypipes: seems like it could be the same issue, or it could be something else. [18:12] abentley: anything I can do to diagnose/assist? [18:12] jaypipes: Can you confirm that the script is taking > 50 seconds to run? [18:15] abentley: that build job is actually a number of things, so I'm not sure what you are referring to in the >50 seconds? The python setup.py test might take more than 50 seconds, but I'm not sure how that would impact the merge of remote master to a local branch? [18:17] jaypipes: basically from the pre_merge_hook message to the error. [18:18] abentley: checking. [18:19] abentley: yes, it could def be more than 50 seconds... [18:19] abentley: did something recently change regarding that? [18:19] jaypipes: Yes, we've just moved codehosting behind haproxy. [18:20] abentley: hmm. [18:21] mtaylor: ok, so there was a change recently where haproxy is closing connections to bazaar.launchpad.net held for >50 seconds. It looks like tarmac holds the bzrlib connection open whlie it runs post_commit_hook (which includes python setup.py test in our case) [18:21] mtaylor: is there something we need to edit in tarmac to close/reopen the bzrlib connection while tests are run? [18:21] jaypipes: lovely [18:21] uhm. hrm [18:24] jaypipes: it doesn't look like there's built-in support for that. [18:26] abentley: you mean in tarmac? [18:26] jaypipes: I'm trying to see what the semantics of tarmac.branch.Branch.create are. [18:26] jaypipes: yes. [18:29] jaypipes: I think you'd be okay to insert source = Branch(source.lp_branch, config=source.config, target=source.target) anywhere needed to reopen the connection. What do you think, rockstar? [18:30] mtaylor: ^^ [18:31] jaypipes: tarmac is doing nothing wrong. bzrlib expects you to hold connections open while you're using them. However, you can reopen source as a workaround while codehosting is dropping connections. [18:32] * rockstar reads backchat [18:33] * mtaylor defers to rockstar [18:34] Hm, I wonder why we would hold the connection open while we run the tests. [18:35] abentley, ^^ [18:35] I think I may have missed something there. [18:36] rockstar: Well, it's supposed to be okay to do that. It's just that right now, launchpad appears to be dropping connections that have been idle > 50 seconds. [18:37] abentley, so what we're doing here is creating or updating a lightweight checkout, running a command, and committing of the command is successful. [18:37] abentley, and it seems like we're saying that bzr keeps the connection open after updating the checkout. Is that true? [18:37] rockstar: Yes. And reading from the source branch (source.authors) as part of the commit process. [18:39] abentley, wow, that's weird, and probably sub-optimal in Tarmac's case. [18:39] i.e. it might not be Tarmac's fault, but leaving connections open when you might not need them could be problematic. [18:40] When you say "it's supposed to be okay to do that", are you saying bzr is smart enough to figure it out? [18:41] rockstar: No, I'm not saying bzr is smart enough to figure it out, I'm saying the connection should not be dropped.. [18:41] Okay. [18:41] rockstar: anyhow, you can avoid this issue in Tarmac by reading source.authors earlier. [18:42] abentley, yeah, we definitely need to do that. I've been meaning to turn on HPSS debugging in Tarmac and make sure we're not being too chatty as well. [18:43] rockstar: that leaves you with target, which is also open for the lifetime of _do_merges IIUC. [18:45] abentley, ah, I see exactly what you're saying. Crap. I knew that was gonna bite us one day. [18:45] abentley, so I guess that Tarmac should be a little smarter about this as well as haproxy needing to be tweaked then. [18:47] jaypipes, mtaylor, so, in this case, launchpad is revealing some performance bugs in Tarmac. [18:49] rockstar: k. what can we do to help? [18:49] jaypipes, fix all the bugs. [18:49] :) [18:49] jaypipes, -> #tarmac [18:50] rockstar: :) [19:01] jaypipes: This doesn't quite meet the definition of "critical incident", because it affects a limited number of use cases, but I take it seriously, and am discussing what to do with IS. [19:02] abentley: sounds good. we're chatting on #tarmac about a possible resolution. I'll keep you updated. [19:02] abentley: thx :) [19:02] jaypipes: if we did retain a timeout, how long would it need to be? [19:18] abentley, rockstar: so this new behavior on lp seems quite bad [19:19] dobey: I agree. [19:19] abentley: it seems to make using remote branches hosted on lp, a useless feature in bzr, no? [19:20] dobey: No. [19:20] dobey: It only affects cases where the connection is held idle for >50 seconds, AFAIK. [19:21] dobey: pushes, pulls will rarely do that. Commits may do that if the user edits the commit message in an editor rather than supplying -m. [19:22] dobey: but if the user commits locally and then pushes, they won't be affected either. [19:22] abentley: right. so lock, do stuff, unlock, will fail, if "do stuff" takes a while and doesn't involve using the bzr connection, right? [19:22] dobey: right. [19:22] abentley: well, you can't commit locally to a remote branch, right? [19:22] dobey: You can, using a checkout. [19:24] oh, if you do commit --local you mean? [19:25] dobey: Actually, I misunderstood your question. But yes, commit --local can be used for local commits. [19:29] abentley: ok. i don't think that matters here though. [19:29] abentley: so, tarmac basically has to keep the connection open, afaik. is there any way to open a lightweight checkout without having the remote connection stay open? [19:30] dobey: I don't think tarmac has to keep the connection open. I think it just does at the moment. [19:30] dobey: There is no way of opening a lightweight checkout without having the remote connection stay open. [19:31] abentley: given your second answer, we must keep the connection open then :( [19:31] abentley: because we need to lock_write() on the branch, while we're doing things, and the connection will just be idle :-/ [19:33] dobey: an alternative would be not *not* hold a write lock while you're doing things, and recover gracefully if operations happened while you were doing things. [19:33] s/not *not*/not/ [19:34] abentley: we need to hold a write lock though, to prevent other processes from writing to the branch while we're doing stuff [19:34] abentley: otherwise, if the tests take too long, and another tarmac process starts up, it can create a contention and cause both to get spunlock :( [19:34] dobey: An alternative would be to not hold a write lock, and then recover gracefully if other processes write the branch while you're doing stuff. [19:35] how would you even do that? i can't think of any possible way to handle that 'gracefully' [19:36] dobey: I think it would require re-doing the merge. It would probably also make sense for *tarmac* to prevent other tarmac processes from starting up, so that you don't get tarmac competing with itself. [19:39] it's perfectly feasible for multiple copies of tarmac to be running at the same time, and operating on different branches [19:39] dobey: I suppose it wouldn't be too horrible to take a write lock on the remote branch, kill the connection, do stuff, reconnect and break the lock. [19:39] and i don't think tarmac should have to re-implement locking on target branches, when bzr already has locking :-/ [19:39] dobey: You can do per-branch locking if you like. [19:41] and it doesn't help us if the other process isn't tarmac, to do our own locking. where as if we use lock_write() on the branch, then other bzr/bzrlib-using processes will already just "do the right thing" since it will be locked [19:41] i'm curious to know *why* this change was made on lp to close the connections, anyway [19:42] dobey: It was done because we switched to haproxy, so that we could have no-downtime codehosting deployments. === matsubara is now known as matsubara-afk [19:43] and you can't just drop all the current connections when there's a new deployment, as opposed to every 50s if it's idle? [19:44] dobey: I'm not familiar enough with haproxy and our deployment of it to answer that. But I've been discussing the issue with mbarnett. Perhaps he can answer that. [19:45] it is possible, though i will need to discuss this further with the team to figure out exactly how it will all work. [19:45] ok, because i'm pretty sure we don't drop idle connections for ubuntu one file sync api like this. and it's behind haproxy as well. [19:46] mbarnett: i'm guessing it should work similar to the ubuntuone api server haproxy setup. :) [19:46] also, 50s is a very odd number. 600s i could see as somewhat feasible, or maybe even 300s, but 50s is just odd :) === abentley changed the topic of #launchpad to: https://launchpad.net/ | Help contact: - | Launchpad is an open source project: https://dev.launchpad.net/ | This channel is logged: http://irclogs.ubuntu.com/ | User Guide: https://help.launchpad.net/ | Support: https://answers.launchpad.net/launchpad === Quintasan_ is now known as Quintasan === yofel_ is now known as yofel [22:12] anyone know what the name of the channel for LP translators is/ [22:12] ? [22:13] triune: #ubuntu-translators [22:13] danke :) [22:13] oh, wait, LP translators? [22:13] triune: LP translators are here [22:13] oh, yes [22:13] ahh, ok, I guess I can ask here then [22:14] working on my GSoC project with my student, and we cant solve this issue where our code has strings that may/may not contain html and/or javascript in addition to the actual paragraphs of text [22:15] we'd like to know if there is a "best practice" of how to "get around" this kind of scenario [22:15] obviously, we don't want the translators to see the html/javascript [22:16] this would be pretty easy with a static codebase, answer: you just wrap the string u want translated with something gettext will pick up [22:17] however, a number of our "translatables" are stored in a database and cached to disk upon checkin to BZR [22:17] these are what sometimes contain html and javascript [22:20] any suggestions? [22:22] what was the question? [22:24] rewind >> http://pastebin.com/1RihyEmf [22:39] bugger, guess not :( [23:13] triune: well, it seems like you need to distinguish them in the database