[01:31] mwhudson: whats the lightest weight html-suitable template engine for python that you know of? [01:31] lifeless: i don't know really [01:31] lifeless: mako, perhaps/ [01:31] ? [01:31] * wgrant would suggest genshi [01:31] i don't really go in for light weight templating engines [01:32] wgrant: genshi is nice, but not particularly lightweight? [01:32] lifeless: what do you actually mean by lightweight? [01:32] by lightweight I mean 'easy for users of $somethingIwrite' to install -and- doesn't write to disk [01:33] i guess genshi fits those [01:33] mwhudson: I'm asking in the context of [01:33] https://bugs.edge.launchpad.net/subunit/+bug/426283 [01:33] Bug #426283: HTML formatter [01:33] pretty sure it's easy_installable, it's in debian and ubuntu, don't *think* it writes to disk [01:33] It doesn't write to disk. [01:33] That would be a bit ew. [01:34] wgrant: you haven't seen much of the templaters around then :P [01:34] lifeless: I have. But I ran away from those. [01:35] so what I concretely need is something that can output large (20K+ tests, some fraction of which have detailed diagnostics) collections, smoothly [01:37] lifeless: give genshi the ten minute trial [01:38] mwhudson: thanks [02:55] feedback@launchpad.net gets the oddest selection of random mails [07:59] * mwhudson eods [08:20] good morning [08:21] moin abel [10:07] mwhudson, still here? [10:07] ah, no he isn't [10:20] jtv: no [10:20] mwhudson: right, nm—sorry to bother you. [10:20] s'ok :) [10:28] jtv: do we have a bug about the bzr upload failure? I am not talking about "stuck in running" but the root cause to that. [10:29] henninge: the root cause as in, the reason why these particular jobs were getting oopses? [10:29] jtv: yes [10:29] henninge: if so, I don't know; ask Code people [10:29] don't think so [10:30] henninge: I think it's an error we've been seeing in unrelated code oopses [10:30] but then, those code oopses tend to look like Greek to me [10:30] (meaning "I'm supposed to understand them but I can't, or at least I can't be arsed) [10:32] jtv: I am not sure if it's a code bug or if I am using bzrlib wrong. I am still looking at that. [10:32] jtv: I should at least be able to provide a work-around quickly. [10:32] henninge: it's a missing file, right? It sounded highly Code/Codehosting-internal. [10:33] jtv: ah no, the missing file was the configuration for oopses missing on dev. Not the real cause. [10:34] jtv: the current problem is that I am doing "get_file_text" on the root folder ... [10:34] henninge: oh, I wasn't aware of that one [10:35] then that sounds like you're not getting the right id... lifeless knows this stuff, though this may not be a good time to trouble him [10:35] 'sup ? [10:35] (btw, use lifeless: to highlight my nick) [10:36] lifeless: henninge's script is doing get_file_text on the root folder for a branch, when presumably he's trying to read an actual file. [10:36] jtv: wait! you don't know all the detail ... ;-) [10:36] henninge: don't talk to me, un-confuse lifeless about what we're trying to say. :) [10:37] lifeless: wait a second [10:37] do you have some elevator muzak? [10:38] lifeless: ;-) [10:38] * jtv hums Greensleeves in an infuriating monotone [10:38] lifeless: ok, I am doing "iter_changes" with a "specific_files" parameter [10:39] lifeless: the specific_files only contains one file. [10:39] lifeless: the file is in a subdirectory [10:40] lifeless: I get three changes back: The file, the directory, the root. Does it always do that? Has it always been doing that? [10:41] "always" = within the last 6 months, I guess [10:42] henninge: since about 1.18 [10:42] henninge: it returns enough data to be sure that a delta made from the changes will be consistent [10:42] henninge: so, I can infer that the root and containing directory are new. [10:43] ah, so if they weren't, if only the file was changed, that's all I'd get, right? [10:43] just the file [10:43] right [10:43] lifeless: That would explain why this doesn't always file. [10:44] we have had many repeated bugs where new directories (and variations on a theme) do the wrong thing, so (and it is contentious) I fixed it by including more data when needed. [10:44] it fails btw. because I do get_file_text on all three of them ... [10:44] henninge: check kind :) - I mean, someone could have a directory en.po [10:44] or a symlink [10:46] lifeless: I was going to do that now. When I build the specific_files list, I check file_type and had thought that was enough. [10:46] lifeless: thanks [10:46] file_type is kind, I think [10:47] I'm sorry about the fallout; it was in the NEWS :P [10:50] Morning [10:51] mwhudson: *ping* [10:52] Fly-Man-: hi [10:52] Fly-Man-: it's very late for me i'm afraid [10:52] mwhudson: O, I'm in no hurry [10:52] but did you find something out of the pastebins I made for you ? [10:53] Fly-Man-: not really no :/ [10:53] Hmm, so what would be wise to do ? [10:53] install the bzr first, before I do a apt-get update ? [10:54] because i'm not sure if bzr 2.x works with puthon 2.6 [11:26] Wow. [11:26] Even Canonical people file Ubuntu bugs against Launchpad. [11:27] wgrant: *lol* [11:27] wgrant: we do? [11:29] lifeless: Some of you. [11:44] But any ideas on how to get 1.18 [11:44] maybe that'll not blow up [11:44] lifeless: Hi again ;-) [11:45] lifeless: nm === henninge_ is now known as henninge [12:07] lifeless: Ok, I got it fixed by checking kind. [12:08] lifeless: but I investigated further into why this only failed sometimes and I found this: http://paste.ubuntu.com/280287/ [12:08] lifeless: do you have an explanation? I can provide you with the branch that causes the oops. [12:44] Is there an Ubuntu server admin awake ? [12:44] Keyserver for Ubuntu is failing [12:48] * Fly-Man- found the solution [12:48] pool.sks-keyservers.net [12:48] Now how do I make a bug for the rocketfuelsetup ? [12:59] It seems to be failing a lot lately [12:59] Yeah, the keyserver seems to be getting it as well [12:59] so i just gotten the replacement [12:59] so it will try and find another one [12:59] but I hope someone can include that in the rocketfuelsetup [13:00] oh, I meant the keyserver. I've never run rocketfuel-setup [13:00] so that it doesn't blow [13:16] mrevell: Morning [13:16] hi there Fly-Man- [13:17] mrevell: Who creates the rocketfuel-setup file ? [13:17] I would like to have them change 2 bits in it [13:17] change the keyserver that's in there to pool.sks-keyservers.net [13:18] Fly-Man-: Could you please file a bug at https://bugs.launchpad.net/launchpad === matsubara-afk is now known as matsubara [13:21] mrevell: Added [13:22] https://bugs.launchpad.net/launchpad/+bug/438104 [13:22] Bug #438104: Changes for the rocketfuel-setup [13:23] thanks Fly-Man- [14:14] cprov, heads up: looks like the displayname for source packages was just changed and it's breaking tests in devel. [14:30] Tests on devel are breaking. === jtv1 is now known as jtv [14:31] jtv: uhm, bad ... did I break it in one of my last revisions ? [14:31] cprov: looks like source package display names have changed. [14:32] ah, title, not displayname. [14:33] yes, it's in the view -> r9580 [14:33] In the view? It seems to be a change in the model code... by Edwin? [14:35] EdwinGrubbs2: did you just change the title for sourcepackages? It seems to be breaking tests in devel. [14:35] EdwinGrubbs2: yes, I'm sorry, I'll fix that. [14:35] EdwinGrubbs2: here's the output: http://pastebin.ubuntu.com/280390/ [14:36] jtv: you are right, I can't read. [14:36] cprov: I didn't say you can't read, but if you can't read, you may not have a way of knowing that. :-P [14:37] jtv: exactly what happened ... [14:37] \action hides [14:40] cprov: another thing... I've got a script to look up and re-upload Soyuz translations tarballs to Rosetta, but AFAICS no sample data to debug it with. I don't suppose there's an easy way to get that? [14:40] Maybe get a package from somewhere, upload it to launchpad.dev somehow? [14:40] jtv: yes, re-uploading something thin is your best bet. [14:42] jtv: lib/lp/soyuz/doc/distroseriesqueue-translations.txt [14:47] cprov: testing my work is going to be hell if I have to reproduce most of that... Do you think I could sneak a "find Translations tarballs for last upload" into SourcePackage and check it from this doctest? [14:47] It'd save me a lot of test setup for what's basically Registry and Soyuz code. === EdwinGrubbs2 is now known as EdwinGrubbs [15:02] jtv: yes, that makes sense for a `SourcePackage` [15:03] allenap: I submitted a testfix branch to devel 0.5hrs ago now, but according to the following, the branch is still being updated: [15:03] https://code.edge.launchpad.net/~launchpad-pqm/launchpad/devel [15:03] Any ideas? [15:04] I'm not sure why it would take so long to be scanned? (Unless there was something wrong with my branch?) [15:06] noodles775_: I'm looking at the buildbot stuff, trying to understand that (!). I've seen the scanning problem too, I think we need a code ace. abentley, rockstar: branch scanning seems to be broken for lp:launchpad/devel, can you help out? [15:07] allenap: looks like it's a general scanning issue too (see #lp) [15:07] allenap: I can try. This stuff is usually handled by antipodeans. [15:07] abentley: Heh, thank you. [15:08] allenap: What are the symptoms? [15:08] abentley: https://code.edge.launchpad.net/~launchpad-pqm/launchpad/devel shows branch updating for a very long time. [15:09] abentley: I've sent a testfix r9581 to devel over 0.5hr ago, but on #lp it looks like it's not specific to the devel branch. [15:09] abentley: And people (for DBO in #launchpad) cannot pull his latest code, even though bzr says it's been pushed. [15:10] noodles775_: They can't get the latest revision in your branch? [15:11] abentley: sorry, no I was just saying that the issue is not related to one specific branch, others seem to be experiencing it with other branches too. [15:11] abentley: my main issue is that the testfix revision is not being picked up by buildbot :) [15:12] It looks like 9581 hasn't been pulled into the mirrored area. That needs to happen before it can be scanned. [15:13] noodles775_: It's unlikely that it's a problem with your branch, given that PQM was able to merge it and push to lp [15:14] abentley: good-to-know - thanks! [15:16] losa: Please update the puller log on devpad. [15:20] abentley: hi, ok, looking for you [15:20] abentley: hi [15:21] thumper: hi. [15:21] abentley: stub mentioned that the preview generation is being done within a transaction [15:21] abentley: can I get you to look at that? [15:21] * thumper is being ordered to close the laptop [15:21] That is my best guess. Either that or the script hung. [15:22] thumper, stub: Each diff is generated within its own transaction, so that seems reasonable. [15:24] abentley: some diffs are taking over 30 minutes [15:24] see a mysql one [15:24] * thumper has to close it now [15:24] thumper: We should not spend that kind of time on diffs. [15:25] Good morning everyone. [15:25] Any news on the report a bug link being re-linked on the pad again or has this been migrated into the application it self? [15:26] XDevHald: Is this specifically for Ubuntu? [15:27] abentley: That is correct. [15:27] XDevHald: That was removed at the request of Ubuntu. [15:27] Are their future plans of this being re-added for those who do not run the development distro and want to report a bug? [15:28] there* [15:28] abentley: So the solution might just be to abort diff generation if it is taking too long rather than move the diff generation outside of the database transaction. [15:29] stub: That seems right to me. More complicated, but it reduces the DoS surface area. [15:30] No hurry from my end then - that is exactly what is happening as far as the DB is concerned (transaction sits idle for 30 mins and we kill it) [15:30] XDevHald: What does running the development release have to do with anything? [15:30] stub: Cool. [15:31] XDevHald: There should be "Report a bug" in the help menu, even in non-development releases. I see it, and I'm running Jaunty. [15:31] My apologies, not the development release, but all developments of Ubuntu. [15:32] XDevHald: that is a question for #ubuntu-bugs [15:32] Excellent, thank you james_w [15:34] henninge: one is rich root [15:35] henninge: the 'content' of a dir is '' [15:35] gnight [15:36] lifeless: thanks [15:36] abentley: ^^ [15:37] henninge: If we follow the rule that "the content of a dir is ''", then the bug is in non-rich-root branches. [15:38] henninge: yup, my interpretation, too. [15:38] abentley: ^ ;) [15:38] talking to myself again [15:39] henninge: But your code shouldn't be doing get_file_text on a directory anyhow. Why are you doing that? [15:40] abentley: I know, that is a bug and I fixed it. Checking kind. [15:40] henninge: Ah. Thanks for reporting the issue anyhow. [15:41] henninge: What's the bug #? [15:41] abentley: I did not know (and if I understand it right it's a new behaviour) that iter_changes with specific_files returns the directories the files are stored in , too. [15:41] abentley: haven't reported yet, got distracted ... ;-) [15:41] I'll let you know [15:41] henninge: This was a change introduced by lifeless over my strong objections. [15:42] abentley: I don't think its intentional that get_file_text works on a dir; I was just explaining how it worked at all [15:48] Chex: Any luck? [15:50] abentley: sorry, having trouble finding it, do you have any suggestion on devpad where to look? [15:51] Chex: It's mirrored to /x/launchpad.net-logs/scripts/crowberry/puller.log [15:55] bigjools: I'm not entirely sure this getSourceBySourcePackageReleaseIDs thing you sold me is working. === Ursinha is now known as Ursinha-nom [16:09] Chex: How's it going? [16:16] abentley: sorry for the delay, the crowberry/scripts dir logs have been synced now [16:16] updated puller.log file [16:16] Chex: Thank you. [16:17] abentley: your welcome [16:17] Chex: Is there a long-running branch-puller process on crowberry? [16:17] abentley: looking [16:18] Chex: I believe the script name is supermirror-pull.py [16:22] abentley: thanks, I see it, yes there is a process of that name running for 2 hours now [16:24] Please kill it. This is causing an operational problem. Please monitor the next run to ensure it completes successfully. I suggest starting with SIGINT, but do whatever you have to. [16:32] Chex: any news? [16:33] abentley: process killed, and it automagically restarted, watching it do work in the logfile now [16:34] Chex: Sorry I forgot to use your nick before. [16:34] abentley: yes sorry, bit of a delay back to because of that, sorry too [16:34] (to you) [16:36] abentley: I just rsynced the puller.log over to devpad for you by hand, so you can see what it is doing now [16:37] Chex: Thank you. It looks like it's no longer stuck. [16:37] abentley: ok, great, your welcome [16:39] Chex: There may still be a problem, because I would expect the revno for http://bazaar.launchpad.net/~launchpad-pqm/launchpad/devel to be 9581 if the puller completes successfully. [16:45] abentley: ok, sure, I will keep an eye on the running job on crowberry, make sure it finishes cleanly or see if it has problems. [16:47] Chex: When it says "Stopping factory " I believe this means that a script run has terminated. [16:48] thumper: around? [16:49] abentley: not really [16:49] thumper: The puller is broken. [16:49] abentley: well ok, I am seeing that a lot, and constantly [16:49] abentley: do we know in what way? [16:50] thumper: No. It looks like it's running to completion, but http://bazaar.launchpad.net/~launchpad-pqm/launchpad/devel is stuck at revno 9580 instead of 9581 [16:50] thumper: I've manually taken a write lock to try and fix it, but that doesn't seem to have worked. [16:52] abentley: :( [16:52] abentley: I'm having to close the laptop again [16:52] abentley: plz email details to mwhudson so he is aware [16:52] abentley: anything in the logs? [16:53] thumper: This is affecting all of lp. Are you sure you need to close the laptop? [16:53] are the logs synced? [16:54] thumper: Yes. I got Chex to kill the puller, then it ran and he synced the logs after a successful run. === matsubara is now known as matsubara-lunch [16:54] I've unplugged and moved to the kitchen [16:54] thumper: I'm sorry, but it does seem urgent. I haven't been able to determine a cause in the logs. [16:56] the logs don't look that helpful [16:57] thumper: It would help if they indicated which *branch* mirrored successfully, or ideally, which branches were still pending. [16:58] * thumper nods [16:58] thumper: I'm filing a bug about that. [17:04] Chex: can I get you to sync the puller logs again please? [17:04] thumper: There was a long-running process, which grabbed the lock at /var/lock/launchpad-branch-puller.lock at 13:14:03 and didn't let go. I had Chex kill it at 15:32:04 [17:04] hmm... [17:04] do we know what it was grabbing? [17:04] probably not [17:05] thumper: It's hard to infer, but I can try. [17:05] do we know if it is just the launchpad branch that is failing to be mirrored properly [17:05] or if there are others? [17:05] thumper: We know there are others. [17:05] thumper: https://code.edge.launchpad.net/~matsubara/oops-tools/package-diff-oops is an example. [17:05] thumper: abentley : logs rsynced to devpad again [17:06] Chex: thanks [17:06] thumper: https://code.launchpad.net/~gagern/bzr-cvsps-import/lp437295 is another example. [17:06] crap [17:07] * thumper wonders WTF is going on [17:07] what has changed? [17:07] what happened at 13:14? [17:07] thumper: I believe the puller code has been significantly rewritten in this release. [17:07] thumper: I can try to work out which branches weren't mirrored. [17:08] it was [17:08] but it was working earlier [17:08] so something changed very recently [17:08] it seems the scanner also seems a small bit fubared [17:08] thumper: Or we've encountered a corner case. [17:08] bzr revno http://bazaar.launchpad.net/~allenap/launchpad/itch [17:08] 9582 [17:09] but https://code.edge.launchpad.net/launchpad shows the branch as not pushed to yet [17:09] not "not scanned" [17:09] which is suspicious [17:10] Chex: can you pastebin "select * from branch where unique_name="~launchpad-pqm/launchpad.devel" for me please? [17:10] thumper: Don't understand. https://code.edge.launchpad.net/~allenap/launchpad/itch appears up-to-date. [17:11] abentley: it wasn't when I looked just a minute ago :) === bac changed the topic of #launchpad-dev to: This is Launchpad Development Channel | Week 00 of 3.1.10 | PQM is OPEN | https://dev.launchpad.net/ | Get the code: https://dev.launchpad.net/Getting | On-call review in #launchpad-reviews | Use http://paste.ubuntu.com/ for pastes | This channel is logged: http://irclogs.ubuntu.com/ [17:12] thumper, didn't spm apply a cowboy db permission? [17:12] Chex: in the renaming of the puller, we now don't get the log file rolled [17:12] rockstar: yes, I think I did see something about that [17:14] thumper: I received an error on that, pmsging you [17:15] hmm [17:17] thumper: https://pastebin.canonical.com/22671/ [17:20] thumper: ok, I will take a look at the puller.log logrotate [17:20] Chex: is the puller still running? [17:20] thumper: yes it is [17:22] thumper: There are too many PQM commits for me to determine which went with which branch. [17:22] abentley: yeah [17:27] thumper, Chex: are logs in UTC or local london time? [17:32] abentley: I think they are UTC === Ursinha-nom is now known as Ursinha === matsubara-lunch is now known as matsubara === EdwinGrubbs is now known as Edwin-lunch [18:28] Chex: If there's a long-running update_preview_diffs process on loganberry, could you please SIGINT it and then sync the logs and oopses? [18:29] abentley: ok sure [18:29] thumper, http://pastebin.ubuntu.com/280563/ [18:30] abentley: we need a way to kill diffs that take too long to generate [18:32] thumper: I agree. We could change the job runner so that it forks before running the job, and then the moitor could kill it if it takes longer than the timeout. [18:32] s/moitor/monitor [18:32] * thumper nods [18:35] +1 [18:36] it would be nice if there were a really easy-to-use helper for that too, since it's probably a common thing for jobs. [18:36] jml, yeah, like the way imports work. [18:37] right, or the branch puller [18:37] modulo certain existing issues [18:38] abentley: ok, process killed, restarted automagically, and rsynced logs and oops, altho that gets done there every 3 minutes.. [18:43] Chex: Thanks. I didn't realize that was done so frequently. [18:45] Chex: /x/launchpad.net-logs/scripts/loganberry-bzrsyncd/updatepreviewdiffs.log does not look like it's been updated since 2009-09-28 00:07 [18:45] abentley: there are many varied syncs happening; its difficult to track what and when things run, no worries [18:45] abentley: looking [18:48] jml: If it's the job runner, then it will work for anything that implements IJob. [18:48] abentley, cool. [18:54] abentley: sorry, I haven't found that rsync yet, and I need to work on a rollout for Landscape right now [18:54] thumper: One thing that worries me is the possibility that if we fork, we'll end up running the cleanups in the child thread. [18:54] abentley: I will get back to it as soon as I can, or another losa could help you [18:56] losa who is not Chex: Please update /x/launchpad.net-logs/scripts/loganberry-bzrsyncd/updatepreviewdiffs.log [18:56] abentley: should be better now? [18:56] mthaddon: Thank you. [18:56] * mbarnett thinks mthaddon is too quick [19:01] thumper: there is a timeout on db connections, so the script will be killed after 30 minutes, but this is not a good long-term solution. [19:03] abentley: please put a bit of time into thinking about a good solution [19:03] abentley: poolie suggested filing a bug on bzr as it shouldn't take that long to generate the diff [19:03] abentley: the puller had a complete success run [19:04] abentley: I'm composing an email for mwhudson now [19:04] thumper, https://bugs.edge.launchpad.net/launchpad-code/+bug/438292 [19:04] Bug #438292: startMirroring called twice for each branch being mirrored [19:05] thumper: I agree we should file a bug on bzr, and then probably I should fix that bug. And we should also support timeouts in the job system. [19:05] yeah [19:11] thumper, https://bugs.edge.launchpad.net/launchpad-code/+bug/438298 [19:11] Bug #438298: Branch puller triggers false alarms [19:12] * rockstar lunches [19:36] good morning [21:13] rockstar, abentley: standup soon? [21:13] mwhudson, not for another hour, ent? [21:13] mwhudson: Sure, anytime. [21:13] rockstar: oh right, i'm in DST now [21:14] mwhudson, ah, okay. We can have the standup now, that's fine. I just wanted to make sure my computer wasn't the confused one. [21:14] rockstar, abentley: when is most convenient for you guys this week? [21:14] mwhudson, rockstar: I believe the plan was to stick with 9:15 NZ time. [21:14] ok [21:14] i'll be missing it in two days time, fwiw [21:14] mwhudson, on Fridays, abentley and I like to do it about now anyway, so he has his evening. [21:15] abentley: want to host? [21:15] mwhudson: sure [21:16] mwhudson, rockstar: don't see you on Skype. [21:16] i [21:16] abentley, booting the jaunty box, one sec. [21:16] 'm online [21:16] i can restart it i guess... [21:24] mwhudson: https://code.edge.launchpad.net/~thumper/launchpad/fix-puller-logging/+merge/12537 [22:14] herb: *ping* [22:14] wrong window .. [22:15] herb: If you have time, could you update the launchpad source in your folder ? [22:15] http://people.canonical.com/~herb/ [22:15] It's kinda ... old [22:15] and also it's the dbdevel one [22:15] Fly-Man-: it was kinda meant as a stopgap after release. Maybe someone from the LP team can come up with a more manageable solution? [22:17] herb: Okay :) [22:17] Fly-Man-: if you don't get any feedback over the next couple of days, ping me again and I'll see if I can help you. Might be worth filing a bug against launchpad to track. [22:17] Will do ... [22:17] Fly-Man-: cool. thanks! [22:17] Nice to have it there, but it's an other version [22:17] yeah. definitely. I didn't expect it to still be in the documentation. :) [22:21] Yupz [22:21] and since my bzr doesn't like the rocketfuel setup script [22:22] I was able to download that tarball [22:22] but then there's no lp-dependencies [22:22] so it's kinda useless :| === matsubara__ is now known as matsubara-afk [23:41] FWIW, I don't think that tarball is necessary any more. I can check out devel in less than half an hour, even from .au... [23:48] Presumably the tarball will become even less necessary after the LP su [23:48] source gets a post-2.0 bzr pack done on it [23:48] or has that been done already? [23:48] It hadn't a few days ago. [23:48] But it's not too badly fragmented. [23:49] (it was packed fourish weeks ago)