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