| Daviey | lifeless: fwiw, the sign time looked correct. | 00:05 |
|---|---|---|
| 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:06 |
| 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:07 |
| 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:08 |
| RAOF | Would an archive admin with shell access be able to copy bzr to natty-proposed without running into bug #817358? | 00:44 |
| ubot5 | 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 |
| RAOF | I'd like to know if I should start hunting admins :) | 00:44 |
| wgrant | RAOF: Yes. | 01:04 |
| RAOF | Let the hunt begin. | 01:04 |
| * StevenK peers at RAOF. | 01:05 | |
| 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:06 |
| StevenK | RAOF: Done. | 01:10 |
| RAOF | Funkalicious. | 01:10 |
| wgrant | RAOF: The copy takes <400ms, then the bug closing takes the rest of the 9s :/ | 01:19 |
| wgrant | Efficiency! | 01:20 |
| 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:21 |
| 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! | 01:22 |
| scream | What is the recommended method for posting a screenshot file to a question? | 03:13 |
| === 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 | ||
| elacheche_anis | Good morning every body :D | 08:47 |
| elacheche_anis | I have a question please :D | 08:47 |
| geser | We might have answers :) | 08:49 |
| henninge | elacheche_anis: ask you question ;) | 08:49 |
| 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:50 |
| elacheche_anis | thx geser & henninge | 08:51 |
| henninge | elacheche_anis: the LP API provides that information. | 08:53 |
| henninge | elacheche_anis: https://help.launchpad.net/API | 08:53 |
| elacheche_anis | cool, with an API it will be easiest to do that :D | 08:54 |
| 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:56 |
| henninge | elacheche_anis: you can host your project on Launchpad! | 08:57 |
| elacheche_anis | Of course I will :D | 08:57 |
| henninge | cool ;) | 08:57 |
| elacheche_anis | :D | 08:58 |
| === EyesIsMine is now known as EyesIsServer | ||
| lilstevie | I have a question about uploading packages for armel | 10:09 |
| 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:10 |
| maxb | armel is not a supported architecture for standard PPAs | 10:15 |
| lilstevie | damn | 10:20 |
| lifeless | lilstevie: also you can't upload binary packages full stop | 10:21 |
| lilstevie | lifeless, I am aware of that | 10:21 |
| lilstevie | lifeless, it is a source package | 10:22 |
| lilstevie | just it is for armel only | 10:22 |
| 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:33 |
| lilstevie | ok, well I guess seeing as that is the case, what are my alternatives, just run my own repo? | 10:48 |
| === Ursinha-afk is now known as Ursinha | ||
| === menesis1 is now known as menesis | ||
| === stub1 is now known as stub | ||
| tseliot | hi all. Somehow I can't assign this bug to myself. Any ideas? LP: #741930 | 12:01 |
| tseliot | hmm... it works when using firefox. It must be a chromium issue.. | 12:04 |
| 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:05 |
| wgrant | Did you try refreshing the page and clicking it again? | 12:06 |
| henninge | tseliot: wfm on qastaging, with chromium. | 12:07 |
| tseliot | wgrant: yes, I did | 12:07 |
| henninge | tseliot: can you try it here? https://bugs.qastaging.launchpad.net/ubuntu/+source/nvidia-graphics-drivers/+bug/741930 | 12:08 |
| ubot5 | Ubuntu bug 741930 in nvidia-graphics-drivers-96 (Ubuntu) "[natty] nvidia binary packages for older cards - dependencies not met" [Medium,In progress] | 12:08 |
| tseliot | henninge: it used to work fine here too | 12:08 |
| * tseliot tries | 12:09 | |
| tseliot | henninge: no, it doesn't work there either | 12:09 |
| nigelb | compare chromium versions? :) | 12:10 |
| tseliot | I tried to assign -96 to me | 12:10 |
| tseliot | it's 12.0.743.0 (82420) here | 12:11 |
| tseliot | on natty | 12:11 |
| 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:13 |
| 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:17 |
| 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:18 |
| 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:19 |
| tseliot | the extension name is "Better Pop Up Blocker" | 12:20 |
| tseliot | thanks for your help | 12:21 |
| nigelb | heh | 12:28 |
| === 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 | ||
| 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? | 14:52 |
| === 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 | ||
| abentley | adeuring: I relieve you. | 16:22 |
| === beuno is now known as beuno-lunch | ||
| nigelb | abentley: Star Trek quote? ;) | 16:28 |
| micahg | nigelb: that would be, "I relieve you, sir", I believe | 16:31 |
| ScottK | Actually that's standard US Navy deck watch change procedure. | 16:32 |
| nigelb | micahg: Right. | 16:32 |
| nigelb | ScottK: Ah. | 16:32 |
| 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:33 |
| nigelb | ha | 16:34 |
| adeuring | abentley: thanks! | 16:34 |
| === beuno-lunch is now known as beuno | ||
| === matsubara-lunch is now known as matsubara | ||
| 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:08 |
| abentley | jaypipes: is that what you're seeing? | 18:09 |
| jaypipes | abentley: https://jenkins.openstack.org/view/Glance/job/glance-tarmac/88329/console is an example | 18:10 |
| 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:11 |
| 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:12 |
| 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:15 |
| abentley | jaypipes: basically from the pre_merge_hook message to the error. | 18:17 |
| jaypipes | abentley: checking. | 18:18 |
| 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:19 |
| jaypipes | abentley: hmm. | 18:20 |
| 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:21 |
| abentley | jaypipes: it doesn't look like there's built-in support for that. | 18:24 |
| 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:26 |
| 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:29 |
| jaypipes | mtaylor: ^^ | 18:30 |
| 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:31 |
| * rockstar reads backchat | 18:32 | |
| * mtaylor defers to rockstar | 18:33 | |
| rockstar | Hm, I wonder why we would hold the connection open while we run the tests. | 18:34 |
| rockstar | abentley, ^^ | 18:35 |
| rockstar | I think I may have missed something there. | 18:35 |
| 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:36 |
| 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:37 |
| 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:39 |
| 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:40 |
| 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:41 |
| 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:42 |
| abentley | rockstar: that leaves you with target, which is also open for the lifetime of _do_merges IIUC. | 18:43 |
| 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:45 |
| rockstar | jaypipes, mtaylor, so, in this case, launchpad is revealing some performance bugs in Tarmac. | 18:47 |
| 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:49 |
| jaypipes | rockstar: :) | 18:50 |
| 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:01 |
| 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:02 |
| dobey | abentley, rockstar: so this new behavior on lp seems quite bad | 19:18 |
| 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:19 |
| abentley | dobey: No. | 19:20 |
| abentley | dobey: It only affects cases where the connection is held idle for >50 seconds, AFAIK. | 19:20 |
| 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:21 |
| 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:22 |
| dobey | oh, if you do commit --local you mean? | 19:24 |
| abentley | dobey: Actually, I misunderstood your question. But yes, commit --local can be used for local commits. | 19:25 |
| 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:29 |
| 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:30 |
| 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:31 |
| 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:33 |
| 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:34 |
| dobey | how would you even do that? i can't think of any possible way to handle that 'gracefully' | 19:35 |
| 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:36 |
| 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:39 |
| 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:41 |
| abentley | dobey: It was done because we switched to haproxy, so that we could have no-downtime codehosting deployments. | 19:42 |
| === matsubara is now known as matsubara-afk | ||
| 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:43 |
| 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:44 |
| 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:45 |
| 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 :) | 19:46 |
| === 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 | ||
| triune | anyone know what the name of the channel for LP translators is/ | 22:12 |
| triune | ? | 22:12 |
| 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:13 |
| 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:14 |
| 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:15 |
| 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:16 |
| 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:17 |
| triune | any suggestions? | 22:20 |
| poolie | what was the question? | 22:22 |
| triune | rewind >> http://pastebin.com/1RihyEmf | 22:24 |
| triune | bugger, guess not :( | 22:39 |
| poolie | triune: well, it seems like you need to distinguish them in the database | 23:13 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!