[00:18] wgrant, thanks I will take a look [00:37] * mwhudson lunches [01:46] x-warrior: triaged means we gave it a priority. Low means it will be fix opportunistically, not scheduled. trivial means it should be easy to fix, about 1 hour for a experienced engineer === abentley1 is now known as abentley [05:41] beuno: hello [05:42] beuno: have you seen https://code.edge.launchpad.net/~mnordhoff/loggerhead/yui-3.0.0? [05:42] beuno: it doesn't work [06:08] * mwhudson --> beer! [07:01] * wgrant directs a few torrents of hate at sampledata conflicts. === jtv is now known as jtv-sprint [09:04] Morning! [09:04] eyup [09:41] good morning === mrevell changed the topic of #launchpad-dev to: Code hosting offline 10.00-10.30 UTC | This is Launchpad Development Channel | Week 0 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/ [10:52] Morning, all. [11:06] * wgrant just successfully ec2tested a branch with the new official image. Yay. [11:15] allenap: Can you help me with a bit of ajaxy stuff? it's really easy (for you), honest :) [11:18] wgrant, grats :) === ursula is now known as Ursinha [11:24] mrevell: Hi, yes, sure. [11:24] thanks allenap. Bug 406394 deals with a rather annoying bug in the pop-up help. The "Continue" button doesn't show the word "Continue". [11:25] Bug #406394: The "Continue" button on help pop-ups has lost its text and is now tiny [11:25] * allenap looks [11:25] allenap: Someone's posted a comment pointing out what's wrong but I'm struggling to see where to fix that in the code. [11:25] allenap: I have lib/canonical/launchpad/icing/build/inlinehelp/inlinehelp.js open [11:28] mrevell: Line 35. [11:28] allenap: function findHelpLinks() { ? [11:29] mrevell: And lib/canonical/launchpad/icing/build/inlinehelp/inlinehelp.js is a symlink to lib/lp/services/inlinehelp/javascript/inlinehelp.js [11:29] mrevell: Doh, sorry, line 30. [11:30] When adding new attributes to a model class, do I stick with the class' existing completelyandutterlyunreadable style, or do I use_underscores like new stuff? === mrevell changed the topic of #launchpad-dev to: This is Launchpad Development Channel | Week 0 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/ [11:31] mrevell: This'll do it: http://pastebin.ubuntu.com/289212/ [11:32] allenap: Ahhhhhhhhhhhhhhhhh, right. I feel a cheat landing your work. heh. [11:33] mrevell: Well, it was the work of Anders Jørgensen really :) [11:33] allenap: :) I'll get it through review and testsuite. Cheers. [11:41] Anybody know the answer to my question? [11:41] wgrant, use_underscores [11:41] jml: thanks [11:41] wgrant, the policy is that we're in favour of incremental cleanup of our code. [11:42] wgrant, and a key part of that is not adding to things that need to be cleaned up, even if it means local stylistic inconsistency. [11:43] * wgrant begs PEP 8 for forgiveness. [12:19] MTecknology, ping === mrevell is now known as mrevell-lunch === matsubara-afk is now known as matsubara === mrevell-lunch is now known as mrevell [13:50] allenap: Do you have any thoughts as to why I'd be seeing the autoland problem again? [13:51] mrevell: Exactly the same problem? Can you paste it? [13:51] allenap: I think so. Lemme grab it [13:58] bigjools: Did anything end up happening with my branch? [14:15] wgrant: I submitted it, but it seems to have disappeared [14:15] ah pqm stopped for a CP [14:29] barry: I didn't know about http://www.python.org/dev/peps/pep-0382/ . yay. hope it happens. [14:30] gary_poster: i actually didn't know about it either, but i didn't think pep 381 was right so i went spelunking :). it seems like a good pep so i hope it gets implemented too [14:32] btw gary_poster, i totally failed yesterday to run anything we talked about. bzr pipelines roadblocked me (though i now have a much better understanding of it - something we should definitely look at). i'm still going to try to run some things today in the background while i ocr/chr [14:34] sinzui, ping [14:34] EdwinGrubbs: skype? [14:34] hi jml [14:34] sinzui, hi. [14:35] sinzui, I guess you're busy right now, but sometime today I'd like to have a chat with you about ISD's experience with privacy -- I was talking to Nigel yesterday & he said that you were the person to speak with. [14:35] indeed I am the teller of the sad tale [14:35] jml: I'll be available in 15 minutes [14:37] sinzui, cool. whenever you're ready. [14:53] jml: pong [14:58] MTecknology, hi [14:58] jml: how's it going? [14:59] MTecknology, good. [14:59] about that project.. [14:59] MTecknology, I've recently moved to London, slowly adjusting to a faster, greyer pace of life :) [14:59] MTecknology, yeah, I was going to ask :) [14:59] extremely busy this week and next week; but then open to start working on it [14:59] I'd like to play with the source this weekend though [15:00] MTecknology, cool. [15:00] I'd like to find a spelling mistake and fix it [15:06] MTecknology, heh. [15:06] MTecknology, if you search things tagged 'trivial' and 'ui', you'll probably find something like that. [15:06] jml: just something simple to learn the process [15:06] ok :) [15:07] MTecknology, not everything tagged 'trivial' is actually trivial, sadly. [15:07] * bigjools wonders how many bugs tagged trivial really are trivial [15:07] heh snap [15:07] jml: I saw you tag something "easy" once, I had a chuckle [15:08] bigjools, :D [15:09] bigjools, a lot of the time the change is easy and the hard thing is finding the 20 page tests that assumed the old behaviour but weren't actually devoted to testing it. [15:09] * bigjools cooks up a "nightmare" tag [15:10] bigjools, heh heh [15:10] it would apply to most soyuz bugs :/ [15:10] since we've open sourced, I've made a habit of adding a short howto to any bug I tag as trivial [15:10] yeah I try and add more info on how to fix as well [15:11] it's worth an email to the -dev list [15:11] bigjools, I think there actually was a thread about this a couple of months ago :) [15:11] jml: I am free. Do you want me to call? [15:11] my memory sucks [15:12] sinzui, yeah sure. [15:17] bigjools: "bug to assign to random person(me)" -> nightmare :P [15:17] :) === ursula is now known as Ursinha [16:29] rockstar: ping [16:33] barry, pong [16:34] rockstar: hi. was wondering if you were going to finish that review from yesterday. if not, i'll ping abel about it [16:35] barry, I JUST saw it come in. The new greylisting seems to be working, but I didn't get the email when I EOD'd last night. I'll do it now. [16:35] rockstar: thanks. greylisting == fun! [16:36] barry, yea, once it gets trained it's okay, but I moved around some infrastructure here, which meant a new mail server, so there are some hiccups to work out. [16:37] * barry nods [16:37] rockstar: i especially love the mail servers that don't know the difference between 4xx and 5xx :) [16:39] barry, eep. === ursula is now known as Ursinha === matsubara is now known as matsubara-lunch [17:02] deryck: hi [17:05] * rockstar reboots [17:08] bigjools: ping [17:08] hello citrus [17:09] bigjools I am starting a fix for bug 352374 [17:09] Bug #352374: IntegrityError: duplicate key value violates unique constraint "packaging_uniqueness" [17:10] bigjools: The simple way to avoid that error is to use PackagingUtil.packagingEntryExists() but that does not help the user accomplish his goal of getting rid of the insane link [17:10] MTecknology, hi [17:11] deryck: so.. you get the last email? [17:11] MTecknology, just about to lunch break, but we could chat briefly. Or I can reply to your mail when I'm back from eats. [17:11] either way - I'm in class now so a short chat is good [17:11] sinzui: my knowledge of packaging linkage is extremely limited [17:11] after this I'll follow you to food [17:12] bigjools: After some though, it occurred to me that we do not check because we assume that having the distroseries and sp, we can safely change the productseries. Then it occurred to me that the real issue here is that the distroseries+sourcepackage has multiple upstream packaging links, and that we are only showing one of them. Is that possible? [17:13] sinzui: the dsp page shows direct_packaging [17:13] but allows you to edit each series individually [17:15] bigjools: this is an SP link in this case: https://edge.launchpad.net/ubuntu/karmic/+source/metacity/+edit-packaging <- That should be trunk, but apparently that packaging link already exists...we get a db error [17:16] this is where my lack of knowledge about this stuff makes my eyes glaze :) [17:16] bigjools: In this very example, it pointed the wrong project and series, I decided that point it to another matacity series to get part of the link right [17:17] bigjools: okay. I'll try a query on staging to see if there is more objects then being shown in the ui [17:18] sorry, I feel useless [17:18] np. My goal is to learn this [17:19] There are a few bugs with linking that cannot be fixed until someone really know how they should work === beuno is now known as beuno-lunch === deryck is now known as deryck[lunch] [17:32] bigjools: My assumption was correct: bug 196774. <- I think I need to fix that to prevent the madness. In the cases documented, the user would be happy if we deleted the crack duplication [17:32] Bug #196774: It shouldn't be possible to link multiple productseries to a sourcepackage in a given distroseries [17:33] * jml is slowly learning that there a lot of interesting Launchpad emails that are no longer my business [17:33] sinzui, oh cool, I independently rediscovered that bug recently while exploring the schema to figure out source package branches. [17:33] sinzui, but never got around to actually finding the bug report in Launchpad :) [17:34] ok how do I run person.txt without running the other million tests that end in person.txt? [17:35] bigjools: be a man - run them all [17:35] bigjools: -t lp.soyuz.*doc/person.txt [17:35] bigjools, ./bin/test -1cvvt parent/of/person.txt [17:35] MTecknology: my office is already warm enough :) [17:35] jml: that's just too bleedin' obvious :) [17:36] the -1 is extremely useful. [17:36] yes [17:37] but not as groovy as -c [17:37] trial has better colours. [17:37] jml: you suck, it doesn't work! :) [17:38] it totally works. [17:38] you're doing it wrong. [17:38] oh. [17:38] lol [17:38] the answer is that zope sucks. [17:38] do you want the longer answer? [17:39] I considered using a regex for a moment, and then I came to my senses [17:39] '-t' does a regular expression search on the name of the test [17:39] where 'name of the test' is defined as str(test) [17:39] bigjools: you need .* because the doctest path is appended to the executor [17:39] for unit tests, this defaults to "test_foo (lp.foo.bar.BazTestCase)" [17:40] but a lot of our tests have custom __str__ methods that produce "lp.foo.bar.BazTestCase.test_foo" instead [17:40] for doctests, the str() is the path to the doctest [17:40] bigjools: -t lp.soyuz.*doc/person.txt <- only match the start and end of the test name [17:40] sinzui get's the prize [17:40] gets [17:40] jeez [17:41] for most such doctests, zope generates a path like "./lp/foo/tests/../doc/bar.txt" [17:41] lib/lp/registry/tests/../doc/person.txt [17:41] so -t matches that path, rather than "lp/foo/doc/bar.txt", which would be more sensible. [17:42] I tried to fix this bug once, and then learned again that zope.testing's code has a great face for radio. [17:43] :) [17:43] * bigjools chortles [17:43] on a different topic [17:43] I've just got around to reading the thread where sidnei talks about template performance [17:44] I'd really appreciate a three sentence summary :) [17:44] rockstar: chat? [17:44] abentley, sure. [17:45] abentley, I wonder if we might try chatting through Empathy today. [17:45] * bigjools wonders how relatively recently added model class methods are totally untested [17:45] rockstar: As an experiment, sure. But I prefer Pidgin. [17:46] abentley, well, yeah, I mean audio chatting through Google Talk, whatever client works. [17:46] rockstar: I am calling you. [17:47] abentley, I can't hear you, can you hear me? [17:47] No, I couldn't even see you pick up. [17:47] rockstar: Try calling me. [17:48] abentley, calling. [17:48] Apparently the call is in progress. [17:49] abentley, I still see "Connecting..." [17:49] rockstar: Well, maybe Empathy will do better than Pidgin. [17:49] abentley, let's go back to skype. I'm not sure that my USB headset us going to play nice with Empathy either. [17:50] Also, I don't really want to spend much time futzing with it... :) [17:51] abentley, I can hear you, but I don't think it likes my USB headset. [17:51] abentley, one sec. [17:52] abentley, did you have to configure your headset? [17:52] abentley, it's using your laptop mic I bet. [17:52] No, it turns out to be configured correctly already. [17:53] rockstar: It insists it's using "Logitech_USB_Headset Analog Mono". [17:53] abentley, I think you and I have the same headset. [17:54] rockstar: Yeah, same or similar. [17:54] abentley, let's just skype... :( [18:03] jml, sorry for the noise... [18:04] np. [18:04] rockstar, it doesn't look like anyone was interested in answering the question anyway [18:04] rockstar, which sadly means I'll have to think for myself :\ [18:04] jml, what question? [18:05] jml, I was talking about just calling you through Empathy to see if we could have conference calls with it. [18:05] (which it doesn't look like we can) [18:05] rockstar, oh, I'm not on empathy [18:06] jml, well, GTalk. [18:06] rockstar, what were you calling? [18:06] rockstar, pidgin merrily discarded any noise you generated :) [18:06] jml, your GTalk account. abentley and I were trying. [18:06] I've just got around to reading the thread where sidnei talks about template performance [18:06] I'd really appreciate a three sentence summary :) [18:07] that was my question, fwiw. === sidnei_ is now known as sidnei [18:10] i guess the summary is, chameleon is faster but can be made even faster if we spend some time either cleaning up the templates to do less traversal or improving the code in z3c.pt that does the tales namespace function traversal to have some kind of fastpath. [18:11] Have a great weekend folks === matsubara-lunch is now known as matsubara [18:12] sidnei, that's good, thanks. [18:12] sidnei, do we know how much work either of those two options would be, roughly? [18:14] jml: my suggestion was to take one page where lots of tales namespace functions are used, replace them all by python expressions and benchmark it to determine an upper bound of how fast it can go. [18:14] sidnei, sounds like a good plan. [18:14] jml: and only then worry about improving it further, if there are real gains [18:14] bye everyone, and have a great weekend [18:14] bigjools, g'night. [18:15] sidnei, although it doesn't quite answer the question I asked :) [18:15] jml: im great at dodging questions about estimates :) [18:16] jml: i suspect for someone with some skills in making python code fast (like someone from the bzr team *hint hint*), trying to optimize the python code would be the easy win, though im not sure there's much left to optimize there [18:17] jml: i would estimate about one week either way you go [18:17] sidnei, :D [18:18] sidnei, thanks :) [18:20] jml: someone mentioned that maybe some sort of local lookup cache (was it mwhudson?) could be used. it's basically doing a few try:excepts and adapter lookups === deryck[lunch] is now known as deryck [18:28] sidnei, cool. [18:28] * jml is off for beers with gnome folks [18:31] gary_poster: Getting distribution for 'pytz==2009l'. [18:31] make: *** [/home/barry/projects/launchpad/py25/bin/py] Error 1 [18:31] [18:32] barry: hm, may have inadvertently done some other tricks there; checking [18:32] barry: oh, no, I know what is up [18:33] gary_poster: cool [18:33] barry: you need the pytz 2.5 egg. the source distribution of pytz does not play well with easy install (and therefore buildout) for some reason [18:33] just download it from pypi and move on [18:33] drop it in eggs? [18:33] pytzl python2.5 egg, I should say [18:33] I would drop it in download-cache/dist, because that's where it would go if we were going to check things in [18:34] barry: ^^^ [18:34] gary_poster: ah, right. thanks [18:34] np [18:35] gary_poster: this page is only publishing 2009n now: http://pypi.python.org/pypi/pytz [18:35] gary_poster: plus, it's too bad we don't know the maintainer of the package to ask him to fix it for us :) [18:36] barry: http://pypi.python.org/simple/pytz -> http://pypi.python.org/packages/2.5/p/pytz/pytz-2009l-py2.5.egg#md5=b41c8cacb5f4a8a64db05afbdf3ef9ef [18:36] barry: stuart and I have both looked into it. We are not sure what is wrong. bug 438634 [18:37] Bug #438634: buildout not building pytz egg correctly [18:37] gary_poster: thanks! [18:37] np [18:39] gary_poster: just read the bug report. how truly odd! [18:39] barry: yeah :-( [18:47] gary_poster, maxb: https://dev.launchpad.net/PythonMigrationStatus [18:48] good idea [18:49] barry: awesome, thanks. so now you will be rerunning the tests? [18:49] gary_poster: i'm still not successfully building your branch :( [18:49] barry: no? what are the issues now? I will try too... [18:49] gary_poster: still investigating [18:49] ok [18:52] gary_poster: http://paste.ubuntu.com/289439/ [18:52] barry: move aside your sourcecode and get it again for 2.5. [18:53] barry: make sense? [18:53] barry: the problem is that _lsprof is in sourcecode, and is build for 2.4 [18:53] gary_poster: i think so ;) [18:53] ok :-) [18:53] fwiw, I just built it fine [18:53] after a make clean [18:53] gary_poster: is it in sourcecode because python2.4 doesn't have it? [18:54] gary_poster: yep, that seems to be it. it's in 2.5 and 2.6 [18:54] gary_poster: so once we migrate we won't need it in sourcecode anymore [18:54] barry: ok, I was about to say "that's a good guess." Great [18:56] flacoste, ping [18:56] hi rockstar! [18:56] flacoste, how's things? [18:57] things are great! how are you? [18:57] flacoste, good as well. [18:57] did you register for YUIConf? [18:57] flacoste, no, should I have? [18:57] flacoste, we're seeing an increase in bugs where javascript api changes aren't enough to blacklist us from the slave database. [18:58] rockstar: i think you should: http://www.yuiblog.com/blog/2009/09/29/yuiconf-2009-registration/ [18:58] flacoste, looks like "External developer" is "Sold out" [18:58] flacoste, is there anything we can do to force a slave db blacklist? [18:59] rockstar: sold out, that's unfortunate :-/ [18:59] for the slave db blacklist... [18:59] not really [18:59] it's based on the session [19:00] flacoste, hrm, that means that we have to duplicate the template is javascript. [19:00] ??? [19:00] what is the problem exactly? [19:01] flacoste, https://bugs.edge.launchpad.net/launchpad-code/+bug/447353 [19:01] Bug #447353: Subscribing to a branch does not insert your name into the subscriber list [19:01] flacoste, I make the API changes, and then get a small page fragment to reload the subscriber list. [19:01] If I hit the slave DB, I don't always get the new subscriber in the page fragment. [19:02] you shouldn't hit the slave db [19:02] flacoste, this is one of two bugs we have open due to thes. [19:02] flacoste, I know I shouldn't, but it is. [19:02] then the bug to fix is that one [19:02] ah, i know what is happening [19:03] API requests use the MasterStore policy [19:03] which doesn't update the last_write of the session [19:03] flacoste, yeah, I think someone in Foundations already knows about this (I thought it was you). [19:03] that would be stub or leonard [19:04] flacoste, I think there's even an open bug about this. [19:04] yeah, i think i saw something about that [19:04] rockstar: if you find the bug, i'm sure gary can put stub or leonard on it [19:05] flacoste, okay, great. [19:05] rockstar: sure, shoot it at me. [19:08] gary_poster: build succeeded, running the tests (gotta love the quad-core :) [19:08] barry: :-) cool === beuno-lunch is now known as beuno [19:13] gary_poster, I couldn't find the bug, so I filed a new one. https://bugs.edge.launchpad.net/launchpad-foundations/+bug/447453 [19:14] Bug #447453: Changes made through the API (via javascript) aren't blacklisting the Slave DBs [19:14] rockstar: ack, looking, thanks [19:14] gary_poster, it's possible that the bug I was looking for was never filed, but was a known issue. If it was filed, just mark it as a dupe. [19:14] ok [19:17] gary_poster, I'm willing to bet this breaks almost all of the code javascript, since I wrote most of what's landed so far in this manner. [19:18] rockstar: Does this affect production significantly? I marked this as high and am sending this to stuart, with an email to highlight it to him--is this critical? [19:19] gary_poster, well, yes, it affects production. It APPEARS to the user that the operation didn't take affect, even though it did, and a small delay (like, maybe a pageload) will illustrate that it's broken. [19:19] gary_poster, I think this may also affect what abentley is working on, and probably javascript from other teams. [19:19] rockstar: ok. /me goes to find the policy for the definition of critical... [19:20] rockstar: (IOW, is this stop the presses, or ask Stuart to do this first thing Monday) [19:20] gary_poster, whether that means "critical" to you is your decision, but I'd say I'd like to see it cherry picked before the rollout. [19:20] gary_poster, um, well, it's not a stop the presses thing, since we've been experiencing it for two weeks now. I thought it was already being worked on, which is why I hadn't discussed it before. [19:21] rockstar: ok, cool. then I'll have someone on it Monday. [19:21] gary_poster, thanks. [19:21] np [19:40] abentley, how are you running your windmill tests. [19:42] rockstar: bin/test -v --layer=CodeWindmillLayer test_merge_proposal_commenting [19:42] abentley, okay, good. [19:43] bac: did you see the buildbot launchpad-login.pt conflict? [19:44] sinzui: no [19:44] * bac looks [19:44] rockstar: Oh, one problem is that ensure_login fails when the user is already logged in. This means that bin/test -v --layer=CodeWindmillLayer fails. [19:45] bac I think you need to merge stable/lib/canonical/launchpad/templates/launchpad-login.pt into db-devel, then resolve. [19:45] abentley, yeah, I've seen that. [19:45] abentley, right now I'm getting: http://pastebin.ubuntu.com/289474/ [19:49] sinzui: that was a weird conflict. [19:50] rockstar: I dunno why that would be. [19:50] abentley, yeah, me neither, chasing now. [19:51] sinzui: we're not in testfix. so i can submit this to db-devel normally. rs=sinzui ? [19:51] bac: yes you can, but may I see the conflict? [19:51] /patch [19:52] sinzui: not sure how to do that [19:52] bac: then how do you know you have something to submit? [19:52] sinzui: the conflict was resolved as part of the merge from devel so it doesn't show up separately in a diff [19:53] bac: you mean merge3 is better than start merge? [19:54] bac: so I take your point that you have a branch of db-devel that is correct and it looks just like the login.pt that you intended to land? [19:55] sinzui: yes [19:55] sinzui: i updated my devel branch [19:55] sinzui: i updated my db-devel branch [19:55] sinzui: then i merged devel into db-devel, resulting in the one conflict [19:56] sinzui: after resolving that conflict there are 61 files that have changed to be committed, including my conflict fix [19:57] sinzui: so, given that i cannot show you exactly the changes from the conflict resolution. [19:57] beuno: did you ever try rebuilding devel? [19:57] bac: could you have just merged lib/canonical/launchpad/templates/launchpad-login.pt ? [19:58] gary_poster, I started from scratch [19:58] sinzui: hmm. perhaps. [19:58] sinzui: i can revert and try that [19:58] beuno: ok [19:59] sinzui: except merge does not take a single file [20:00] bzr merge ../db-devel/lib/canonical/launchpad/templates/launchpad-login.pt [20:01] bac ^ not that exact example, but you can merge a file [20:01] * sinzui did get a conflict going from db-devel to devel [20:01] ahh [20:02] bac: The conflict is with my indentation fix [20:02] sinzui: ok, i merged just that file (never tried that before). here is the diff: http://pastebin.ubuntu.com/289480/ [20:02] sinzui: the actual conflict was at line 27 of the diff [20:03] okay. the direction I went put the problem on 172. [20:03] * rockstar lunches [20:04] bac: can you fix the indentation of

bac: This looks good to land, rs=me [20:05] ok [20:23] is it just me, or is code hosting down? [20:37] dobey, scheduled maintenance. [20:39] rockstar: i thought that was this morning, and it was already "back" ? [20:42] dobey, oh, my math is bad. [20:42] is PQM operating normally at present? [20:42] rockstar: or maybe mrevell's is [20:43] dobey, code hosting looks fine to me. [20:44] a branch of mine was submitted to PQM via "ec2 test" approx. one hour ago but I don't see it anywhere [20:44] rockstar: really? [20:45] rockstar: https://code.edge.launchpad.net/~dobey/ubuntuone-client/emblem-tweaking [20:45] rockstar: that should have been done 25 minutes ago... [20:46] dobey, okay, code hosting down and mirroring lag are two different things. :) [20:46] rockstar: i'm a user. to me "my code on launchpad" == "code hosting" [20:47] :) [20:47] dobey, you're in the wrong channel then. :) [20:47] * rockstar looks for failed scripts. [20:50] abentley, do you know how often crowberry:branch-puller runs? It looks like it died at 19:07:03 UTC today. [20:50] Is it really hourly? [20:50] rockstar: No idea. [20:51] rockstar: Actually, isn't it minutely? It mirrors hosted branches into the mirrored area. [20:53] abentley, yeah, that's what I thought too, except the mail to the list says: The script 'branch-puller' didn't run on 'crowberry' between 2009-10-09 18:07:03 and 2009-10-09 19:07:03 [20:53] rockstar: That's not a contradiction. [20:53] abentley, so it failed every minute for exactly an hour? [20:53] rockstar: That means that, regardless of how many times it should have run, it didn't run at all during that period. [20:54] rockstar: Probably for more than an hour, but ran at least once during the other periods. [20:55] So maybe it's time to look at some oopses. [21:25] gary: Total: 24511 tests, 56 failures, 2 errors in 124 minutes 53.859 seconds. [21:25] gary_poster: ^^ that is with your branch [21:25] barry: is my branch different at all from maxb's at this point? [21:26] gary_poster: i have not looked closely yet, since i'm ocr and chr today. i basically just branched your branch, got it to build, and then ran the test suite :) [21:26] Mine has nothing interesting in it at the moment. I was thinking about discarding it, replacing it with a bit of scripting to just sed some makefiles and shebangs [21:27] barry: cool, thanks. I don't expect they are different. For comparison, the last run maxb reported was 29 failures I think [21:27] maxb: eh, if you want, but this should happen soon enough [21:27] the transition should happen, I mean [21:28] gary_poster: i think />>> foo/>>> print foo/ would fix a lot of tests [21:28] ! [21:28] barry: cool [21:30] abentley, puller esploded: https://pastebin.canonical.com/23188/ [21:32] abentley, all the failing branches appear to belong to jelmer. [21:40] fun [22:04] gary_poster: we're going to need a new launchpadlib that prints its strings instead of reprs them [22:04]