[12:04] I got the failure notice [12:04] I'm just wondering what happened to the one I sent right after the failure [12:05] 15:49 [12:05] it was recieved [12:05] and then? [12:06] erm tz confusion [12:06] let me just check [12:06] lifeless, never mind, I think -- let's see if this merge request goes through [12:06] ok [12:07] salgado says it's me! === kiko waits === lifeless high fives salgado [12:08] mpt, around? [12:17] daf: you removed findSourcesByName, right? [12:18] bradb: yup [12:18] bradb: trying to merge it now [12:25] daf: did rosetta explode? i'm getting several large (3M+) batch error log emails [12:25] from a quick scan of about 10% of the file, it looks like it might be something to do with table perms [12:26] oo [12:26] maybe stub changed some permissions [12:27] daf: are you getting the error emails? [12:27] yep [12:30] Merge to rocketfuel@canonical.com/launchpad--devel--0: Long list of little UI tweaks and fixes that I've been working on for a week. r=BjornT on most of it. Fixes bug 1127, bug 1123 and possibly bug 688. Initial fix for bug 676, more work required there (patch-2022: christian.reis@canonical.com, bjorn.tillenius@canonical.com) [12:41] T L! [12:43] wooooo === mdz [~mdz@host217-37-231-22.in-addr.btopenworld.com] has joined #launchpad [01:01] Merge to rocketfuel@canonical.com/launchpad--devel--0: [trivial] Require launchpad.Admin to the reassignment of teams. Otherwise team administrators will be able to change the owner of a team. (patch-2023) [01:06] daf: can you please ask rosetta to not mail 3MB spam at me ? [01:16] hey [01:16] does anyone know if you can apply multiple fmt: rules to the same string? [01:18] probably [01:18] the first fmt should evaluate to a string, noL [01:18] ? [01:22] yeah, that's how it looks here [01:22] my tests seem to say "it works" [01:23] my 1gig box is swapping, whee [01:25] Merge to rocketfuel@canonical.com/launchpad--devel--0: Implements the karma framework (according to the KarmaImplementation spec) and hook it into Malone events. r=spiv,stub (patch-2024) [01:31] kiko: https://wiki.launchpad.canonical.com/PageTemplateHacking#head-193daf137ed8b89de36d47c3df5fd8f66c0e1d14 === kiko looks === cprov -> night, "nice time" for who stays [01:33] mpt, which are you pointing out to me [01:33] tables or lists? [01:33] tables [01:33] oh! [01:33] oh! [01:33] thanks! [01:33] specifically the bit about using [01:35] lifeless: complain to stub === debonzi [~debonzi@200-161-81-234.dsl.telesp.net.br] has joined #launchpad [01:36] daf: ? [01:36] mpt, thead and tbody are correct, right? [01:36] daf: its not rosetta ? [01:36] it is [01:36] kiko: correct [01:36] but (a) stub controls the scripts and (b) I think it was him that broke it === debonzi is looking for stub.. === debonzi found that stub is not here... === debonzi will be back later === mpt refuels to look at this calendar stuff [01:48] Merge to rocketfuel@canonical.com/launchpad--devel--0: Small fixes: move some functions (createPerson, personFromPrincipal and traverseTeam) to their right places and remove dead code from pofile-export.pt and potemplate-export.pt. r=SteveA (patch-2025) === bradb-away [~bradb@modemcable082.64-130-66.mc.videotron.ca] has joined #launchpad === koke_ [~koke@adsl229-164.unizar.es] has joined #launchpad [01:57] * Searching for best merge point .../pqm/build_dir/thelove@canonical.com/thelove@canonical.com---bazaar--devo--1.5/src/baz/libarch/namespace.c:595:botched invariant [01:57] !!version_end [01:57] baz: uncaught exception: -1:(exiting on botched invariant) === mpt wonders whether he should Ctrl+C or not [01:57] mpt: its finished [01:57] mpt: thats the second time I've seen that [01:57] this is very strange, I'm smelling a regression [01:58] so it's fully merged? [01:59] it didn't list any modified files [01:59] no [01:59] its failed [01:59] baz tree-id please [01:59] mpt@canonical.com/launchpad--devel--0--patch-84 [02:00] and baz msissing rocketfuel@canonical.com/launchpad--devel--0 [02:02] lifeless: everything from rocketfuel@canonical.com/launchpad--devel--0--patch-2011 to -patch-2025 [02:02] thanks [02:02] do a star-merge [02:02] yup [02:04] I'm assuming that, though star-merge works in ~90% of the cases where normal merge does not, it works in less than ~80% of the cases where normal merge does work ... otherwise why not use star-merge by default :-) [02:05] mpt: could you review a branch for me please, that has some new UI? [02:05] need it done today [02:06] sabdfl: sure, what branch [02:06] mpt, star-merge worked [02:06] for me when that happened [02:06] kiko: and it's just worked for me too [02:07] sabdfl, I just added auto-linkifying to malone for links and bugtext :-) === kiko is a tales hacker === mpt hugs kiko [02:07] thanks [02:08] kiko: superb! [02:08] how do you guys like today's be landing? any conflicts? [02:08] be? [02:09] I landed like a baby today, only 8 conflicts :-P [02:10] like a defenestrated baby? [02:12] heh [02:12] Keybuk is such an australian timezoner [02:12] lies [02:13] Merge to rocketfuel@canonical.com/launchpad--devel--0: [trivial] Fixed 100% #1036 + test added (but useless as the whitespaces are ignored :-( ) (patch-2026: carlos.perello@canonical.com) [02:13] and rosetta is SUCH A SPAMMER! [02:14] 3.7MB OMG [02:15] yes [02:20] so where's all this calendar? [02:21] I don't see links to calendars anywhere [02:25] mpt, click on the link to person12 [02:25] or person16 [02:25] one of the two have calendars [02:26] aha [02:28] So, people have calendars, not distros/releases/products yet [02:28] and I can add an event from the weekly/monthly calendar, but not from the daily/yearly calendar yet [02:30] maybe report bugs or write to jamesh cc launchpad-list [02:31] mpt: products and projects can have calendars -- however the owner of the product/project has to create it [02:31] lifeless, can you please check if stub can work around the rosetta permissions problem that is spewing 3MB email every 5 minutes to me? [02:31] kiko: me too [02:32] it's probably a set of grants and a slap on the wrist [02:32] but you know best [02:42] Merge to rocketfuel@canonical.com/launchpad--devel--0: [trivial] use thead and tbody in assigned bugs page (patch-2027: christian.reis@canonical.com) [02:46] mpt, the spacing when using

is still not optimal, can you try tweaking it a bit? [02:47] the vertical alignment looks looks kinda fishy too [02:47] Yes, I think that's a problem with the GIFs [02:47] it's interesting that using the tags it worked well, no? [02:48] Some of them have padding on the top and bottom, so when the browser arranges their "bottom" on the baseline, it looks wrong [02:48] was just closer, I think [02:48] maybe [02:48] horizontally better, but not vertically better [02:48] fix that and rs=kiko [02:49] but I can fix that [02:49] I'll send you a screenshot [02:50] mpt, I'll also send you some tal changes to see if I'm doing the right thing or not in the portlets [02:52] mpt, sent [02:52] night all [02:55] night sab [02:57] kiko: figured out the datetime bug you found [02:59] you are such a hacker [02:59] thanks a million === kiko hates tests [02:59] the timezone name was unknown [02:59] but it worked for mark and pqm because unknown timezones were treated as localtime, which happened to match :) [03:00] it's great when at least the owner can run tests successfully :-) [03:01] so you can fix the problem by moving to sunny London [03:03] jamesh: i have a zinger of a datatime bug for you [03:03] good weather can't be expensed [03:03] kiko: cant be dispensed either [03:03] sabdfl: oh? [03:08] jamesh: add a fmt:date to line 103 of templates/productseries-ubuntupkg.pt [03:08] now visit http://localhost:8086/products/evolution/+series/main/+ubuntupkg [03:09] and change the source package to something like pmount [03:09] boom [03:09] you get a security proxied thing in the result of a totally different query [03:09] i've tried flush_database_updates and object.sync() [03:09] with no joy [03:10] so... i just left the date unformatted, because that works (!) [03:10] I'll check in a sec. Just want to get this test fixed [03:11] jamesh: btw - very smooth landing of the calendar bits [03:14] thanks [03:19] sabdfl: the SQLConstant thing is almost definitely UTC_NOW [03:20] when I reload the page after changing the packaging, it displays a valid date === stub [~stub@203-217-37-199.dyn.iinet.net.au] has joined #launchpad [03:20] jamesh: yes, but interestingly flush_database_updates does not convert it to a real sql object [03:20] yeah [03:21] i was just amazed that it would come back like that through a totally different query [03:25] sabdfl: problem seems to go away when I add a line "pkg.sync() # convert UTC_NOW to real datetime" at lone 145 in database/productseries.py [03:28] jamesh: ah.... i tried it on line 152 and of course that's not the codepath for an update, but a create... [03:28] could you see if it's required for the create as well? [03:28] and fix-n-land with your next landing, no rush? [03:28] just slip it into whatever branch you are currently working on? [03:29] jamesh: and thank you! [03:29] now,.. night - for real! === sabdfl [~mark@sabdfl.silver.supporter.pdpc] has left #launchpad [] [03:29] heh [03:30] jamesh, is the issue SQLObject not invalidating the cached object state? [03:31] anyway [03:31] NIGHT [03:35] SQLObject should be clearing its caches on commit, and I think this is being/has been fixed upstream [03:35] (not that I have any idea if this is relevant, having missed the start of the conversation) [03:38] I think this is happening within a single transaction [03:38] set new package (which sets date), then display results [03:46] the create new packaging code path seems broken too (in a different way) === bradb-aw1y [~bradb@modemcable082.64-130-66.mc.videotron.ca] has joined #launchpad [03:55] stub, any luck you can fix the permission issue generating 3MB email from rosetta? :-) [03:55] kiko-zzz: In a tick ;) [03:56] heh [03:56] lifeless, is PQM busy? I've sent two merges and no output after a few hours... === kiko-zzz should really go to bed [03:58] kiko-zzz: hung twisted process [03:58] aha [03:58] killed [03:58] thanks [03:58] lunchtime [03:58] bbiab [03:58] tell this twisted dude to stop hanging [03:58] gone for good [03:59] kiko-zzz: he's on leave [03:59] :) [03:59] Someone should review that autokill the tests patch I put in... [05:26] hi stub [05:27] debonzi: Hi [05:28] stub, did you get the patch I did for your gina branch? [05:28] New Malone bug 1246 filed on product The Launchpad by Matthew Paul Thomas: Events only addable from week/month views, not day/year [05:28] https://launchpad.ubuntu.com/malone/bugs/1246 [05:28] debonzi: Yes - looks good. Do you want to stick it in the review queue or should I? [05:29] jamesh: What is the relationship between launchpad/lib/schoolbell/ and upstream schoolbell? Will they be merged regularly? [05:29] debonzi: Or maybe we should just commit it rs=kiko ;) [05:30] dilys, you forgot bug 1244 and bug 1245 [05:30] stub, just the same for me.. as you prefer.. may be it is easy for you since you can commit on your branch and I can't [05:30] stub, hehe.. I like this rs=kiko :) [05:30] mpt: it is a fork at the moment that needs to be merged. Once we have subversion syncing working, it should be a proper bazaar branch off the mainline [05:31] debonzi: oh - I thought you would have created a local branch in your own archive. I'll merge your patch and chase it through to rocketfuel. === stub tries to remember how to apply patches manually [05:31] stub, no, I worked in your branch [05:32] stub, maybe you want to change/remove the modification I did on launchpad.conf [05:33] stub, are you going to setup this "version" on staging/production or are you going to use the "old" gina? [05:33] debonzi: We need something there for documentation, even if it is specific to your workstation. This can be removed when we have a proper Gina functional test (which will pull its config out of the section) [05:33] debonzi: I was going to run with this version against staging, and then production if people think its updates are sane. I don't know anything about old gina. [05:35] stub, uhmmm .. I think I was not clear :) this version = your branch ; old gina = gina before your changes [05:36] debonzi: oh. I will run this version. I suspect the old version will generate too much noise to be useful. With the new version, I can run it with '-q' and ony the warnings get reported (and I can switch it to '-v' if things are screwing up and people need to see the debugging output). [05:37] stub, thats cool for me.. your changes realy rocks :) [05:38] stub, and how do you want to coordinate that? will you take responsability off it? [05:38] Should it run now against the staging database? old gina died due to missing distro releases or something, and I'm not sure if these need to be created manually by somebody or if gina handles all that. [05:39] stub, right... good point [05:39] debonzi: I'll give it another run. If it looks like it needs more tweaking, I'll enable access to the staging database from gina@macquarie and hand it over to you and/or salgado to get going. [05:40] debonzi: All production code will be the joint responsibility of myself, lifeless and salgado once we have gangotri and launchpad.net all sorted. [05:40] stub, gina just creates: people and emails (maintainers), sourcepackage and binarypackage names, sourcepackagerelease, build, binarypackage, sourcepackagepublishinghistory, packagepublishinghistory, source and binarypackage files [05:41] stub, she needs: [05:42] debonzi: ok. We will need somebody to setup any missing distributions or distroreleases. I suspect Kinnison will be designated victim for this, unless you know enough about the Ubuntu distro to do it. [05:42] the distribution, distrorelease, the distroarchreleases, the components, processor and processorfamily [05:42] Or sabdfl [05:43] stub, does he (Kinninson) have access to do that? [05:43] debonzi: I think he is a Launchpad administrator, and I can make him one if he isn't already. [05:43] debonzi: Although I'll need to do anything that there is no web UI for. [05:44] debonzi: I could hack it up, but I'd rather get the descriptions, owners, maintainers etc. all sorted correctly because it is important to Mark. [05:45] stub, thats what I was writing to you about get me creating this stuff... but you are faster than me :) [05:45] debonzi: We should be able to get gina going for at least one distrorelease though - everything should be setup for Hoary already. [05:46] stub, thats true... I think before cape town, salgado was working on that and created this stuff. [05:46] stub, for hoary [05:48] ok. I think I have enough to run with for now. I'll merge your patch and chase it through to Rocketfuel. You will need to write at least one test for the gina script (by setting up a miniature distro mirror in scripts/ftests/gina_test_archive or something) and running it. [05:49] debonzi: Either branching off my archive or rocketfuel if I can get it in today. [05:50] debonzi: This will involve setting up a section in the part of launchpad.conf, which the test runner will use automatically. It might also need you to make Gina handle relative paths to the archive root properly. [05:51] stub, ok I will take care of it.. [05:52] stub, but I am not sure about the test itself.. would the test be just a call to the gina script using the launchpad.conf section and the miniature distro mirror [05:52] ? [05:54] debonzi: Yes. subprocess.Popen([sys.executable, 'gina.py', 'porky'] , stdout=PIPE, stderr=PIPE). [05:54] stub, cool... [05:54] debonzi: p.wait() for the process to terminate, p.returncode to check for major errors, ensure output is empty or contains the warnings or errors you expect to be triggered [05:55] ok [05:55] err. p.communicate() is better for this... [05:55] whatever ) === stub stops telling debonzi to suck eggs [06:00] arrrrrrr, crap [06:01] stub, ok.. I think I got it... again about the gina production run, something else I can do to help? can you check with Kinninson and/or mark about the distro,distrorelease,distroarchreleases production setup? [06:02] I will chase that up with Kinnison and Mark when they come online this afternoon. [06:03] But don't worry, I'm sure there will be bugs for you to fix ;) [06:03] stub, as you cold see, kiko is in our back and It will start blocking people [06:03] stub, yes.. I think she is a bug :) [06:12] stub, well, I will get some sleep because a realy need it.. please, every problem I got from gina (I hope you get none) report to me.. [06:13] debonzi: Yup. No problem. [06:13] stub, thanks dude.. [06:40] lifeless: PQM is dead [06:41] checking [06:41] oh wow [06:41] it really is [06:42] nukified [07:12] Merge to rocketfuel@canonical.com/launchpad--devel--0: [trivial] linkify assignee's name in the bug task headlines (patch-2028: christian.reis@canonical.com) [07:37] Merge to rocketfuel@canonical.com/launchpad--devel--0: [rs=stub] Remove cruft from our Makefile; I should note I added a 'schema' shortcut target a while back (patch-2029) [08:07] Merge to rocketfuel@canonical.com/launchpad--devel--0: [trivial] use rfc2822 date format to fix test failure (patch-2030: james.henstridge@canonical.com) [08:24] stub: morning [08:26] SteveA: Morning [08:26] i tracked down a bug in sqlos / sqlobject yesterday [08:27] where when an sqlobject transaction is GCed, it will often clear the in-progress transaction's stuff out of the object cache [08:28] look at the "rollback" method of [08:28] Transaction, sqlobject/dbconnection.py [08:28] for subCache, ids in subCaches: [08:28] for id in ids: [08:28] inst = subCache.tryGet(id) [08:28] if inst is not None: [08:28] SteveA: I think this has been discussed on the mailing list recently. The fix is to make commit() clear the caches. === stub looks for the email he sent spiv [08:29] # so, we get an instance from this transaction's [08:29] # cache. then we tell the instance to expire itself. [08:29] # The instance is from this dying transaction. [08:29] # But, the instance will get hold of the current [08:29] # connection to expire itself by its id. So, it will [08:29] # be expiring an equivalent object in the current [08:29] # transaction's cache. [08:29] # [08:29] # To fix, consider in sqlos that once the connection [08:29] # descriptor has been used on an object, that object [08:29] # will always be associated with that connection. [08:29] so, i'd say the fix is to write the connection to the instance the first time it is used with that instance. [08:30] as, i don't know what other cases there are of an object being used with an inappropriate connection [08:31] but, the thread-bound connection descriptor that sqlos uses is prone to such bugs [08:32] making commit() clear the caches would not be enough anyway. rollback() would need to clear the caches too, and you'd always need to do an explicit commit or rollback before a transaction gets GCed [08:33] i believe my proposed fix is more robust. [08:33] http://sourceforge.net/mailarchive/forum.php?thread_id=7559932&forum_id=30269 [08:33] http://sourceforge.net/mailarchive/forum.php?thread_id=7559933&forum_id=30269 [08:34] rollback already does clear the caches. Not clearing them in commit is a bug (IMO, and will probably be fixed this way upstream if it hasn't already) [08:37] the issue is more one of threading [08:37] Your fix would help the situation where you 'lose' a transaction without committing it or rolling it back (and in this case, you should bitch loudly!) [08:37] if the commit or rollback occurs in a different thread than the transaction was operated in [08:38] then the wrong objects will be uncached [08:38] SteveA: That is a bug - I don't think you should be sharing transactions across threads (?) [08:39] so, for sqlos, making a transaction bound to an object once that object has been used with that transaction, avoids all such ambiguity [08:39] the code in dbconnection makes an assumption [08:39] it assumes that when it gets an object, and calls that object's expire() method [08:39] that the object will expire itself [08:39] right now, that is the assumption that is broken [08:40] the object will expire the object with that classname and id from the cache of the current transaction [08:40] not of the transaction the object was used in [08:40] one fix for exactly this to to allow the transaction to be given in object.expire() [08:40] another fix is to ensure that an object always talks to the same transaction [08:40] An SQLObject instance will only get used with one transcation anyway (?) [08:41] yeah, right [08:41] not when sqlos is in the mess^Wmix [08:41] That is the bug then. [08:41] sqlos replaces the class-level connection object with a thread-local-style connection-lookup descriptor [08:42] so, the object will be used with whatever transaction is associated with the current thread [08:42] Yes, but the cache is part of the connection, so objects cannot be pulled out of another threads cache [08:42] that sentence doesn't add up [08:43] yes, the cache is part of the connection [08:43] but, an sqlos object can have an inappropriate ._connection [08:43] when it is accessed outside of the thread it was first used in [08:43] How do you do that? [08:43] or outside of the normal transaction boundary it was first used in [08:44] in GC [08:44] or, in the case of various errors that people might make [08:44] such as keeping objects around between transactions / sharing them accidentally among threads [08:44] you can get objects with the wrong state associated with a transaction [08:44] So you forgot to call commit() or abort() in your thread (trying to rollback in the __del__ method is the real breakage IMHO) [08:45] yes, that is one case [08:45] ok. I don't think the fix is to try and cope though. I think the fix is to bitch loudly and raise an exception. [08:45] i agree [08:45] the current case is not to try and cope [08:45] the current behaviour is to happily remove another object from a different transaction from the cache [08:46] what i am suggesting is not "coping" [08:46] it is ensuring that an object does't shit over other transaction's caches [08:47] to do that, i'd change sqlos's connection descriptor to write the connection to the instance the first time it is used with that instance [08:47] interestingly, this will also speed things up a little [08:48] i consider this orthogonal to fixes in sqlobject to ensure the cache is cleared on commit [08:48] and any refactoring to remove __del__ [08:48] then, when you can reliably identify the transaction an object is associated with [08:49] you can raise errors if that object is used when its transaction is no longer the current one [08:49] right now, such errors are not straightforward to detect [08:49] because an object "pretends" it is part of whatever the current transaction is [08:49] If we replace the objects _connection with a real reference, when the transaction is committed what stops that instance continuing to use the same transaction? Is the transaction invalidated on commit/rollback? Or is the same one kept in use? [08:50] it is invalidated [08:50] the transaction's _obsoete flag is set [08:50] and guards at each method ensure it can no longer be used [08:50] exactly appropriate "complaining loudly" behaviour [08:51] and complaining with a useful message [08:51] I think we also need to fix commit to nuke the caches though or else any instances left around for garbage collection are going to bitch in their __del__ methods. [08:51] Because they cannot rollback, because their transaction is obsolete [08:51] yeah, that's fine. but that's orthogonal to the issue i'm trying to get your support on ;-) === SteveA is having an orthogonal day [08:52] also, it's an sqlobject issue, and i'm talking about an sqlos issue. although, it wouldn't be a bad thing to make sqlobject bind objects with the transaction they were first used in [08:52] heres a square rule [08:52] I agree that replacing the instances _connection is a good idea. We might lose some functionality, but I would call it dangerous functionality (being able to reuse an instance across transactions and/or threads) [08:53] that is not supported in sqlobject's model [08:53] it is supported in the zodb, btw [08:53] because the zodb has richer and better-defined semantics for when an object needs to get new state [08:54] but, has lead to "George Bailey" objects [08:54] which was one of the more entertaining ZODB developers discussions === SteveA digresses [08:54] It is supported in SQLObject I think, provided your underlying database api does (such as psycopg). Probably not thread safe through without locking. [08:54] okay, cool. [08:55] it cannot be supported, because of how the caches work [08:55] it cannot be supported because of what i'm describing. [08:55] stub: I notice you went with pound, even after my extra data on the wiki :[ [08:55] maybe it was designined in there, in a half-arsed way [08:55] Your extra data on the wiki? [08:55] stub: I updated the wiki page you put up with specifics for squid [08:55] SteveA: Nah - it would have been purely by accident ;) [08:55] but, it is quarter-arsed support [08:56] okay, so plan: make an object bound to the connection it is first used in. make caches get cleared on commit. [08:58] stub: I suppose it would be a bad idea to make the test suite pick a random time zone for each run ... [08:58] random ain't good in tests [08:58] just ask tom lord [08:59] just so long as we don't end up with tests that only pass in Calcutta. [08:59] jamesh: I would support randomly choosing between Asia/Calcutta and Pacific/Pitcairn. Fully random has a chance of getting your current timezone ;) [09:00] SteveA: Random test environment in an attempt to ensure things are environment neutral [09:00] Pitcairn Island is where they molest children, right? [09:00] jamesh: That is the one [09:01] stub: no randomness in tests. [09:01] if we need to do that, run the tests twice [09:01] once in each timezone [09:01] but don't introduce randomness [09:01] unless you set the seed first ;-) [09:03] SteveA: We already have randomness - every developer runs in a subtly different environment. [09:04] But I suspect running tests in a known timezone is good enough - it doesn't really matter if they are timezone specific tests, as long as the tests always run in that timezone [09:04] that is not randomness. that is stable, but different in multiple locations. [09:04] we have randomness due to python's GC, though [09:05] but that only hurts when there's a bug in sqlobject, or other similar things. [09:07] jamesh: do I have r=jamesh without mucking with that iterator foo ? [09:07] lifeless: yes. [09:08] btw you missed a PEP8 violation ;) [09:08] the sortedDictIterator's docstring was multiline - the ending """ should be on a line of its own [09:09] how is this for a docstring ? [09:09] Topologically sort a list of dicts by the length of a a keyfield and provide an iterator to the result. [09:09] sounds good. [09:10] ok, can I ask a small favour ? [09:10] sure [09:10] can you review the patch robert.collins@canonical.com/cscvs--devel--1.0--patch-366 [09:10] its mingled with the same branch - my bad - which is why its a favour that I am asking [09:13] jamesh: also, your patch for added files is applied to mainline courtesy of matthieu moy [09:13] stub: btw, rosetta script is triggering permissions [09:13] 3Mb emails are not cool. [09:13] the length of a a keyfield [09:14] two "a" s [09:14] lifeless: It still happening? I fixed a permission issue for Carlos earlier. [09:14] lifeless: I'll get to the patch in a bit -- I've got some others I'm working on right now. [09:15] stub: as of 1652 yes [09:15] jamesh: thanks [09:16] SteveA: good catch [09:16] stub: just looking at your branch testrunner branch. I think it could easily deadlock while reading from the test script [09:16] since it is doing blocking reads [09:17] jamesh: That code is the same as the mechanism the subprocess module does it. If you do foo.read() it will block. If you do read(foo.fileno(),1024) it won't. [09:17] I think :-) [09:23] lifeless: does it give a particular topological sort, where there's more than one possible sort? [09:25] stub: you are right [09:26] SteveA: uhm [09:26] just curious [09:27]