[00:05] <Daviey> lifeless: fwiw, the sign time looked correct.
[00:06] <lifeless> Daviey: ?
[00:06] <Daviey> lifeless: poolie commented "I wonder if this could be caused by a skewed client clock causing a"
[00:06] <Daviey> signature that seems invalid only for a certain time ...?"
[00:07] <Daviey> Unless i missed what he was conveying, for example - sign time in the future?
[00:07] <lifeless> Daviey: read the bug
[00:07] <lifeless> Daviey: oh right
[00:07] <lifeless> uhm no
[00:07] <poolie> hm
[00:07] <lifeless> we're pretty sure we know what causes this
[00:08] <lifeless> the daemons sets up a gpg home in /tmp on a machine with tmpreaper
[00:08] <lifeless> it then touches it periodically, but this is fallible
[00:08] <Daviey> ah
[00:44] <RAOF> Would an archive admin with shell access be able to copy bzr to natty-proposed without running into bug #817358?
[00:44] <RAOF> I'd like to know if I should start hunting admins :)
[01:04] <wgrant> RAOF: Yes.
[01:04] <RAOF> Let the hunt begin.
[01:05]  * StevenK peers at RAOF.
[01:06] <RAOF> 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] <StevenK> RAOF: Done.
[01:10] <RAOF> Funkalicious.
[01:19] <wgrant> RAOF: The copy takes <400ms, then the bug closing takes the rest of the 9s :/
[01:20] <wgrant> Efficiency!
[01:21] <RAOF> There aren't even that many bugs attached.  How does copying a kernel _ever_ work?
[01:21] <elmo> doing things inline that should be done out-of-line!
[01:22] <wgrant> RAOF: It doesn't.
[01:22] <wgrant> They are always done from cocoplum, AFAIK.
[01:22] <wgrant> elmo: Yes, and very slowly.
[01:22] <RAOF> Ah, of course!
[03:13] <scream> What is the recommended method for posting a screenshot file to a question?
[08:47] <elacheche_anis> Good morning every body :D
[08:47] <elacheche_anis> I have a question please :D
[08:49] <geser> We might have answers :)
[08:49] <henninge> elacheche_anis: ask you question ;)
[08:50] <elacheche_anis> 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] <elacheche_anis> thx geser & henninge
[08:53] <henninge> elacheche_anis: the LP API provides that information.
[08:53] <henninge> elacheche_anis: https://help.launchpad.net/API
[08:54] <elacheche_anis> cool, with an API it will be easiest to do that :D
[08:56] <elacheche_anis> 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] <henninge> elacheche_anis: you can host your project on Launchpad!
[08:57] <elacheche_anis> Of course I will :D
[08:57] <henninge> cool ;)
[08:58] <elacheche_anis> :D
[10:09] <lilstevie> I have a question about uploading packages for armel
[10:10] <lilstevie> when I upload my package I get an email saying it is rejected because the arch isn't supported
[10:10] <lilstevie> how do I go about uploading armel packages
[10:15] <maxb> armel is not a supported architecture for standard PPAs
[10:20] <lilstevie> damn
[10:21] <lifeless> lilstevie: also you can't upload binary packages full stop
[10:21] <lilstevie> lifeless,  I am aware of that
[10:22] <lilstevie> lifeless, it is a source package
[10:22] <lilstevie> just it is for armel only
[10:33] <wgrant> lilstevie: armel doesn't presently have a reasonable virtualisation solution, so we can't securely allow anyone to build for it yet.
[10:33] <lilstevie> wgrant, I see :( makes things harder
[10:48] <lilstevie> ok, well I guess seeing as that is the case, what are my alternatives, just run my own repo?
[12:01] <tseliot> hi all. Somehow I can't assign this bug to myself. Any ideas? LP: #741930
[12:04] <tseliot> hmm... it works when using firefox. It must be a chromium issue..
[12:05] <wgrant> tseliot: What do you mean you can't assign it to yourself?
[12:05] <tseliot> wgrant: it means that I click on "assign me" and it does nothing
[12:06] <wgrant> Did you try refreshing the page and clicking it again?
[12:07] <henninge> tseliot: wfm on qastaging, with chromium.
[12:07] <tseliot> wgrant: yes, I did
[12:08] <henninge> tseliot: can you try it here? https://bugs.qastaging.launchpad.net/ubuntu/+source/nvidia-graphics-drivers/+bug/741930
[12:08] <tseliot> henninge: it used to work fine here too
[12:09]  * tseliot tries
[12:09] <tseliot> henninge: no, it doesn't work there either
[12:10] <nigelb> compare chromium versions? :)
[12:10] <tseliot> I tried to assign -96 to me
[12:11] <tseliot> it's 12.0.743.0 (82420) here
[12:11] <tseliot> on natty
[12:13] <nigelb> wfm same version of chromium on maverick
[12:13] <wgrant> tseliot: Can you open up the developer tools and check the Network tab to see what requests there are at the time?
[12:17] <tseliot> 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] <wgrant> tseliot: No JS errors?
[12:17] <wgrant> It should make a request to check if you have had any bugs assigned to you before.
[12:18] <tseliot> wgrant: no, no errors
[12:18] <wgrant> tseliot: Does the "Assign me" link work on other bugs? On other tasks on that same bug?
[12:19] <tseliot> 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] <tseliot> the extension name is "Better Pop Up Blocker"
[12:21] <tseliot> thanks for your help
[12:28] <nigelb> heh
[14:52] <jo-erlend> 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?
[16:22] <abentley> adeuring: I relieve you.
[16:28] <nigelb> abentley: Star Trek quote? ;)
[16:31] <micahg> nigelb: that would be, "I relieve you, sir", I believe
[16:32] <ScottK> Actually that's standard US Navy deck watch change procedure.
[16:32] <nigelb> micahg: Right.
[16:32] <nigelb> ScottK: Ah.
[16:33] <ScottK> "I stand relieved" is the reply.
[16:33] <ScottK> This gets logged and so there's no doubt who's posterior is on the line if something goes wrong.
[16:34] <nigelb> ha
[16:34] <adeuring> abentley: thanks!
[18:08] <jaypipes> abentley: hi. is there some issues with connectivity to bazaar.launchpad.net today?
[18:08] <abentley> jaypipes: There have been reports that if a connection is idle too long, it's getting dropped.
[18:09] <abentley> jaypipes: is that what you're seeing?
[18:10] <jaypipes> abentley: https://jenkins.openstack.org/view/Glance/job/glance-tarmac/88329/console is an example
[18:11] <jaypipes> abentley: of what we're seeing (across the board on our builders trying to pull remote master and merge locally
[18:11] <jaypipes> abentley: look for the "Connection to bazaar.launchpad.net closed by remote host."
[18:11] <jaypipes> abentley: stopped working around 40 minutes ago or so..
[18:12] <abentley> jaypipes: seems like it could be the same issue, or it could be something else.
[18:12] <jaypipes> abentley: anything I can do to diagnose/assist?
[18:12] <abentley> jaypipes: Can you confirm that the script is taking > 50 seconds to run?
[18:15] <jaypipes> 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] <abentley> jaypipes: basically from the pre_merge_hook message to the error.
[18:18] <jaypipes> abentley: checking.
[18:19] <jaypipes> abentley: yes, it could def be more than 50 seconds...
[18:19] <jaypipes> abentley: did something recently change regarding that?
[18:19] <abentley> jaypipes: Yes, we've just moved codehosting behind haproxy.
[18:20] <jaypipes> abentley: hmm.
[18:21] <jaypipes> 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] <jaypipes> mtaylor: is there something we need to edit in tarmac to close/reopen the bzrlib connection while tests are run?
[18:21] <mtaylor> jaypipes: lovely
[18:21] <mtaylor> uhm. hrm
[18:24] <abentley> jaypipes: it doesn't look like there's built-in support for that.
[18:26] <jaypipes> abentley: you mean in tarmac?
[18:26] <abentley> jaypipes: I'm trying to see what the semantics of tarmac.branch.Branch.create are.
[18:26] <abentley> jaypipes: yes.
[18:29] <abentley> 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] <jaypipes> mtaylor: ^^
[18:31] <abentley> 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] <rockstar> Hm, I wonder why we would hold the connection open while we run the tests.
[18:35] <rockstar> abentley, ^^
[18:35] <rockstar> I think I may have missed something there.
[18:36] <abentley> 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] <rockstar> 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] <rockstar> abentley, and it seems like we're saying that bzr keeps the connection open after updating the checkout.  Is that true?
[18:37] <abentley> rockstar: Yes.  And reading from the source branch (source.authors) as part of the commit process.
[18:39] <rockstar> abentley, wow, that's weird, and probably sub-optimal in Tarmac's case.
[18:39] <rockstar> i.e. it might not be Tarmac's fault, but leaving connections open when you might not need them could be problematic.
[18:40] <rockstar> 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] <abentley> 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] <rockstar> Okay.
[18:41] <abentley> rockstar: anyhow, you can avoid this issue in Tarmac by reading source.authors earlier.
[18:42] <rockstar> 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] <abentley> rockstar: that leaves you with target, which is also open for the lifetime of _do_merges IIUC.
[18:45] <rockstar> abentley, ah, I see exactly what you're saying.  Crap.  I knew that was gonna bite us one day.
[18:45] <rockstar> abentley, so I guess that Tarmac should be a little smarter about this as well as haproxy needing to be tweaked then.
[18:47] <rockstar> jaypipes, mtaylor, so, in this case, launchpad is revealing some performance bugs in Tarmac.
[18:49] <jaypipes> rockstar: k. what can we do to help?
[18:49] <rockstar> jaypipes, fix all the bugs.
[18:49] <rockstar> :)
[18:49] <rockstar> jaypipes, -> #tarmac
[18:50] <jaypipes> rockstar: :)
[19:01] <abentley> 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] <jaypipes> abentley: sounds good. we're chatting on #tarmac about a possible resolution. I'll keep you updated.
[19:02] <jaypipes> abentley: thx :)
[19:02] <abentley> jaypipes: if we did retain a timeout, how long would it need to be?
[19:18] <dobey> abentley, rockstar: so this new behavior on lp seems quite bad
[19:19] <abentley> dobey: I agree.
[19:19] <dobey> abentley: it seems to make using remote branches hosted on lp, a useless feature in bzr, no?
[19:20] <abentley> dobey: No.
[19:20] <abentley> dobey: It only affects cases where the connection is held idle for >50 seconds, AFAIK.
[19:21] <abentley> 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] <abentley> dobey: but if the user commits locally and then pushes, they won't be affected either.
[19:22] <dobey> 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] <abentley> dobey: right.
[19:22] <dobey> abentley: well, you can't commit locally to a remote branch, right?
[19:22] <abentley> dobey: You can, using a checkout.
[19:24] <dobey> oh, if you do commit --local you mean?
[19:25] <abentley> dobey: Actually, I misunderstood your question.  But yes, commit --local can be used for local commits.
[19:29] <dobey> abentley: ok. i don't think that matters here though.
[19:29] <dobey> 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] <abentley> dobey: I don't think tarmac has to keep the connection open.  I think it just does at the moment.
[19:30] <abentley> dobey: There is no way of opening a lightweight checkout without having the remote connection stay open.
[19:31] <dobey> abentley: given your second answer, we must keep the connection open then :(
[19:31] <dobey> abentley: because we need to lock_write() on the branch, while we're doing things, and the connection will just be idle :-/
[19:33] <abentley> 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] <abentley> s/not *not*/not/
[19:34] <dobey> 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] <dobey> 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] <abentley> 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] <dobey> how would you even do that? i can't think of any possible way to handle that 'gracefully'
[19:36] <abentley> 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] <dobey> it's perfectly feasible for multiple copies of tarmac to be running at the same time, and operating on different branches
[19:39] <abentley> 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] <dobey> and i don't think tarmac should have to re-implement locking on target branches, when bzr already has locking :-/
[19:39] <abentley> dobey: You can do per-branch locking if you like.
[19:41] <dobey> 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] <dobey> i'm curious to know *why* this change was made on lp to close the connections, anyway
[19:42] <abentley> dobey: It was done because we switched to haproxy, so that we could have no-downtime codehosting deployments.
[19:43] <dobey> 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] <abentley> 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] <mbarnett> 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] <dobey> 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] <dobey> mbarnett: i'm guessing it should work similar to the ubuntuone api server haproxy setup. :)
[19:46] <dobey> also, 50s is a very odd number. 600s i could see as somewhat feasible, or maybe even 300s, but 50s is just odd :)
[22:12] <triune> anyone know what the name of the channel for LP translators is/
[22:12] <triune> ?
[22:13] <micahg> triune:  #ubuntu-translators
[22:13] <triune> danke :)
[22:13] <micahg> oh, wait, LP translators?
[22:13] <micahg> triune: LP translators are here
[22:13] <triune> oh, yes
[22:13] <triune> ahh, ok, I guess I can ask here then
[22:14] <triune> 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] <triune> we'd like to know if there is a "best practice" of how to "get around" this kind of scenario
[22:15] <triune> obviously, we don't want the translators to see the html/javascript
[22:16] <triune> 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] <triune> however, a number of our "translatables" are stored in a database and cached to disk upon checkin to BZR
[22:17] <triune> these are what sometimes contain html and javascript
[22:20] <triune> any suggestions?
[22:22] <poolie> what was the question?
[22:24] <triune> rewind >> http://pastebin.com/1RihyEmf
[22:39] <triune> bugger, guess not :(
[23:13] <poolie> triune: well, it seems like you need to distinguish them in the database