pooliehi all00:00
poolieour wiki software is going to be upgraded today, there may be glitches00:00
jelmerhi poolie00:04
Noldorin_hi jelmer01:09
Noldorin_you still around?01:09
Noldorin_i've done a bit more research...01:09
Noldorin_jelmer, the problem is that branching and uncomitting back to r46 makes the branches diverge...01:11
Noldorin_(no common ancestor, it days)01:11
Noldorin_so i can't merge in :-S01:11
Noldorin_from r4701:11
Noldorin_how eird01:11
cody-somervilleIs there a function I can call that'll basically parse what I might pass to bzr at the command line and transform it into whatever Branch.open will be looking for?02:41
lifelessdirectory service lookup is the difference there I think02:42
cody-somervillelifeless, How do I use that? I assume there must be some function I need to call to get things initialized and get a DirectoryServiceRegistry object?02:47
lifelessthere is probably a module level instance you can use02:48
lifelessyou'll need a library context as usual02:48
cody-somervilleFigured it out.02:53
cody-somervilleBranch.open and stuff automatically do directory service lookup02:53
cody-somervilleI had to call bzrlib.initialize() and bzrlib.plugin.load_plugins() first though02:53
lifelessyes :)03:09
pooliewgrant, lifeless, i was going to say, people are getting things done at a good rate but it may feel a bit like one thing after another04:28
pooliewithout them so much adding up04:28
pooliejohn commented on something like this04:28
poolieone idea is to borrow the rotation idea from lp, but for the whole team:04:28
pooliefor say 2 weeks all focus on one area, eg bfbia or lp bzr-git integration, or whatever04:29
poolieprobably for as long as it takes to get that area adequately complete04:29
wgrantI think that's a good strategy, particularly for something like bzr.04:29
poolieinterrupted only by actually critical bugs04:29
wgrantAs long as the thing is of reasonable scope.04:29
poolie(in the bzr definition, meaning data loss or total use blockage or whatever)04:30
poolieand then do say 2 weeks of reactive work on general bugs04:30
mwhudsonthe tricky part of this, from experience and observation is getting to the point where you can stop04:30
pooliewe would still continue with piloting but people would have less discretion to pick their day-to-day work04:30
lifelesswhats your average cycle time ?04:30
mwhudsonjames_w can tell you lots about this too :)04:31
pooliethe feature you pick could easily turn out to be 3 days or 3 months instead04:31
pooliei don't know, where does lp show that? :-704:31
pooliebut, the mean is probably about a week04:31
lifelesslpkanban should be emitting that :)04:31
lifelessso, that means 2 complete patches end to end for each person (on a 2 week cycle), and if you're doing concurrent work, whatever your concurrency is in WIP when you come to change.04:32
lifelessdo you have a few ideas you want to run up the flag pole, or just this particular one ?04:32
pooliei don't think it follows it would be 2 patches per person, because i'm including stalls there, which this could reduce04:33
pooliefor example its skewed by 660264 being something like 18 months old04:33
pooliethis is my central idea04:33
pooliei think the 'typo fix' time is somewhere around 24h or less04:34
poolieso, a fairly sized feature could get done in 2w04:34
pooliethere are some variations04:34
poolie0- change nothing04:34
poolie1- put one person (or two) on bugs, and have others ignore bugs and work on a feature04:34
poolie2- anyone can do either bugs or features on any day, but there are fewer features in play to choose from04:35
lifelesshow much does a [human] context switch cost in bzr?04:35
poolie3- just generally shift the bar of which bugs ought to come ahead of feature type work04:36
poolie(obviously i'm using the word 'feature' here to mean proactive work rather than reactive, it may have a bug number)04:36
poolielifeless, as in, switching from one bug to another, or one area of the code to another?04:36
pooliehm it seems a bit hard to generalize04:37
pooliethe harder issues might need a bit of mental state04:37
lifelesspoolie: bit of A, bit of B04:37
lifelesslike, if you said 'lets spend 2 weeks on looms'04:37
lifelesshow long before things started flowing?04:38
pooliei think generally speaking if I did an hpss bug today and a udd bug tomorrow it would not hurt04:38
pooliegreat example; i think the costs are going to be04:38
poolie- i already have these other mps underway and i need to finish them off (kind of queue-draining)04:38
poolie- deciding what in particular we're going to do04:39
poolie- to some extent, getting familiar with the code, though .. perhaps that's not enormous, and having a specific impetus to get into eg the loom code could be beneficial04:39
poolieperhaps the biggest cost of timeslicing is going to be queue draining/filling04:40
lifelessa few random thoughts04:40
lifelesshaving > 1 person on a task is enjoyable04:40
lifelessjelmer: bzr-search trunk is now owned by ~bzr04:41
lifelessjelmer: I've left a branch reference behind for convenience04:41
poolie(yes, that's one thing i'd like to have happen more often)04:41
lifelesswaste [in the lean sense: time in the production of something that isn't actively moving a product through to the customer] can make things really drag out04:42
lifelessand for me at least that draggy feeling can numb the sense of variety that one would otherwise get04:42
lifelesse.g. exec rather than fork on lp :)04:43
poolieyes, that's very true04:43
lifelessso, you can either switch while you have stuff to drain, or you can switch 'new stuff' but continue to drain.04:44
lifelesssomething that makes these behaviours closer is reducing the time to drain/time to fill figures04:44
lifelessI suspect you're already pretty vigorous on that04:45
pooliei think our average time from an mp to getting it merged is moderately low now04:45
lifelessbut its worth having in mind when considering new scheduling approaches04:45
pooliei think having more people on one project tends to reduce it more, because there are informed reviewers04:45
lifelesse.g. doing something that will increase the time-in-queue (like less piloting) may have a negative impact04:46
poolieyes, very much04:46
pooliei wouldn't cut back on piloting for this04:46
pooliethis is all within the slice of non-piloting work04:46
lifelesssure, I'm just thinking through it all04:46
lifelessreleases will interact with this.04:46
lifelessunless you can automate them totally out of existence.04:47
poolieyep, they too are a kind of 'hygene' task04:47
poolieas are srus (kind of related)04:48
poolieand answering user questions04:48
poolievery likely we can or should automate them more04:48
lifelessI don't know if whole-team rotations make sense, I suspect you may pay in context switches04:50
lifelessOTOH if everyone is looking at the same stuff you should get some network effect.04:50
lifelessmy 2c: give it a go for 3 cycles.04:50
lifelessmeasure it,04:50
lifelessreturn to what you have now04:50
lifelessmeasure that.04:50
lifeless(return because otherwise the act of changing may be a placebo)04:50
poolieyou say placebo like it's a bad thing :)04:51
lifelessit is if you want things to -stay- better ;_04:51
pooliewgrant, any other thoughts?04:57
wgrantIt's hard to say how well it would work for bzr. I think you probably have less interrupts, so it would work well.04:58
wgrantAnd, as you say, it would be nice to have multiple people working together on one thing.04:59
vilahi all !06:46
=== _nyuszika7h_ is now known as nyuszik7h
=== nyuszik7h is now known as nyuszika7h
pooliehi vila07:48
vilapoolie: hey !07:48
pooliehi there07:49
vilawarming up for the standup ?07:50
poolieapparently it was still owned by spiv so i was just trying to fix that07:50
pooliehe's still pretty much welcome to come but i doubt he wants calendar remindres07:50
=== vila is now known as babune
babuneRiddell: thanks :)07:57
=== babune is now known as vila
pooliefor a second there i thought you set up a bot07:58
vilahehe, not yet...07:58
vilaacting bot only so far ;)07:58
pooliejam, jelmer, hi?08:02
poolieo/ mrevell08:05
vilalp is down ? At least the high failure rate on the package importer suggests so08:37
poolienot as far as i know08:44
vila~600 spurious failures08:46
vilapoolie, jam, jelmer, Riddell : Did one of you want to post the standup summary or should I ?09:19
jamvila: Fine with me if you want to do it.09:20
vilapoolie, jam, jelmer, Riddell : I'll do it then, still 5 secs to shout otherwise 4... 309:21
Riddellgo ahead09:21
pooliejelmer, what's the tag for bfbia bugs?09:31
pooliei know i've seen them but the link from https://dev.launchpad.net/LEP/BuildFromBranchIntoArchive has nothing09:32
jamjelmer: maybe that just means the code is perfect? (*crosses fingers*)09:32
pooliejam, https://code.launchpad.net/~jelmer/launchpad/bfbia-db/+merge/6899009:35
pooliejelmer, what's actually up with that? it looks like it's mostly merged?09:37
jelmerpoolie: bfbia is the relevant tag09:44
poolieso there are no bugs?09:44
jamjelmer: k, there just doesn't seem to be any matches09:44
jelmerpoolie: though I think most of the bugs that have been closed were actually in bzr-builder/bzr-builddeb09:44
pooliejust the db proposal?09:44
poolieoh ok09:44
poolieno bugs in lp09:44
jelmerpoolie: there's one, but it lacks the tag :-)09:44
poolienice :)09:44
jelmerbug 31360209:44
ubot5Launchpad bug 313602 in Launchpad itself "Please add "build this branch" option" [High,In progress] https://launchpad.net/bugs/31360209:44
jelmerthe relevant changes for bfbia are that db branch, which is trivial. I haven't looked at landing because of lp's changing of its deployment process.09:45
jelmerand there's the proof of concept branch at https://code.launchpad.net/~jelmer/launchpad/bfbia/+merge/64036 which works but had too many database changes. I've been working on getting it to use the existing recipe-based infrastructure instead.09:46
jelmermy guess is that it's fairly close now that the other Launchpad related stuff has landed09:49
pooliejam, https://bugs.launchpad.net/udd/+bug/72489009:51
ubot5Ubuntu bug 724890 in Ubuntu Distributed Development "excessive memory consumption for nexuiz-data" [Critical,Confirmed]09:51
jampoolie: https://bugs.launchpad.net/bugs/819604 ?09:58
ubot5Ubuntu bug 819604 in Bazaar 2.4 "when an idle ssh transport is interrupted, bzrlib errors; should reconnect instead" [High,Confirmed]09:58
=== zyga is now known as zyga-afk
jelmerRiddell: hi10:02
jelmerRiddell: just followed up to your i18n patch10:02
jelmerRiddell: I'm also wondering more generally about i18n what the best way is to translate plugins.10:03
RiddellI haven't really thought about that so far10:09
Riddellbut they should load a separate gettext domain with their translations10:09
pooliecould someone look into https://bugs.launchpad.net/bzr/+bug/848064 ?10:14
ubot5Ubuntu bug 848064 in Ubuntu Distributed Development "Revision not present branching from LP" [Critical,Confirmed]10:14
poolieif it is similar to the earlier bugs max dealt with, it should be able to be fixed by clearing and requeuing the imports10:15
poolieor something like that10:15
poolienight all10:19
pooliejelmer, so does that small db patch still make sense to merge?10:23
pooliejust +ALTER TABLE SourcePackageRecipeData ALTER COLUMN deb_version_template DROP NOT NULL;10:23
poolieif so, can i remind you to push for a review, or for clarification on how/where/when to merge it?10:23
jelmerpoolie: I think it still makes sense, but I'd like to finish my other branch first to be sure.10:27
jelmerRiddell: it would be nice to have some convenience functions in bzrlib.i18n for that10:29
Riddelljelmer: for plugins?10:29
jelmerRiddell: yeah10:29
Riddellyes I agree, I'd like to do that10:30
Riddellvila: at what stage in the release process do we make a new stable branch?10:58
vilaRiddell: I'd prefer an easier question before my lunch10:59
vilaRiddell: you mean on pqm ?10:59
Riddellvila: I mean when will lp:bzr/2.5  be separate from lp:bzr10:59
vilaor rather you mean a branch associated with a stable series10:59
vilaso, that should be in releasing.txt, but from memory, the branch is created to release 2.x.011:00
vilaaka when we create the first stable release in a series11:00
vilait shouldn't be hard to do that for the *last* beta before the first stable if that makes it easier for translations11:01
vilawe freeze the API after the last beta already11:01
Riddellok, I'll write that up11:02
vilaRiddell: search for 'Kick off the next cycle' in releasing.txt11:04
* vila off for lunch11:04
=== zyga-afk is now known as zyga
Riddellvila: for your release manager eyes https://code.launchpad.net/~jr/bzr/i18n-release-process-doc/+merge/7516111:59
vilamaxb, jam : Any issue blocking 2.4.1 ?12:00
vilajelmer: oops ^ :)12:00
jamvila: anything blocking me from building it? (just not having done it for me)12:04
vilajam: yeah, I mean, any reason to delay the announce12:05
jamwell, windows installers aren't built yet...12:05
vilajam: discussed numerous times, unless critical bugs block building, availability should not block announce12:06
vilalack of availability for that matter12:06
jelmervila: not afaik12:09
vilajelmer: IIUC you're first to shoot by releasing on debian right ?12:14
vilasid even12:14
jelmernot sure what you mean by first to shoot :)12:14
vilajelmer: once it's released on debian, the ubuntu releases can be done12:15
jelmerah, yeah12:15
jelmervila: I usually upload to sid and ubuntu at the same time12:16
vilajelmer: any ETA ? :D12:16
vilaRiddell: reviewing, can we discuss it a bit ?12:18
jelmervila: I'll have a look now, if the tarball is up12:18
jelmervila: looks like the 2.4.1 tag is missing12:19
vilajelmer: it's up since last Thursday. Did my '[ANN] 2.4.1 has gone gold' mail got lost ? Ha crap12:20
vilait's here :-/12:20
vilajelmer: oh, may be you mean not on trunk ?12:21
jelmervila: not on lp:bzr/2.412:21
jamjelmer: bzr-2.4.1            6042.1.412:21
jamlooks like it is here12:21
jamjelmer: also in lp:bzr/2.4 (I just confirmed)12:22
vilapfew, thanks jam, I was starting to suspect pqm (I *did* sent 2 submissions with this tag (AFAIK) but just when we migrated)12:22
vilaand there has been some weird branch shuffling during the migration12:22
jelmersorry, my bad - we don't have the right magic in the 2.4 packaing branch yet12:23
vilanp np12:23
vila(and I just pulled lp:bzr/2.4 and didn't get any updated tags message :-D)12:24
vilaand 2.4 hasn't been merged on trunk yet so trunk doesn't have the bzr-2.4.1 tag, all is well :)12:25
Riddellvila: of course12:35
=== zyga is now known as zyga-afk
vilaRiddell: reviewed locally, I was surprised by the 27+The final beta - branching and translations12:35
vilaRiddell: but it's correct12:35
vilaRiddell: you used (AT) in emails, why ?12:36
vilaRiddell: I mean, we didn't do this for the others, should we change ?12:36
Riddellthere's enough special casing for the last beta that I think it needs its own section12:36
vilayeah, yeah, good idea, I agree12:36
Riddellvila: the e-mails were just copied off what dpm gave me, I can change them to @12:36
vilaand enclose them in `` ``12:36
vilai.e. only tweaks, I'll vote12:37
vilaRiddell: generally when we say tweak, it means, no need for a second review, go :)12:39
jamvila: poke for great justice!12:49
jamI have a question about some interactions with threading and socket receiving12:49
vilajam: la la la , I can't hear you12:50
jamspecifically, I'm trying to add a 'select()' call before we start reading the next data stream12:50
vilakidding :)12:50
jamso that I can timeout if a connection goes idle12:50
jamhowever, in doing so, some tests start getting "hung threads"12:50
jamhowever, when I run the test it claims is a problem12:50
jamit passes in 0.1s12:51
viladon't mix timeouts and blocking calls12:51
jamvila: specifically, the socket is set to blocking, and I just select.select(... timeout)12:51
jamwhich generally seems to work12:51
vilayeah, generally12:51
vilabut, just no12:51
vilait's in the docs, let me find it again12:51
vilajam: re-reading as the wording seems different from what I remember and things may have changed12:54
vilaha, yeah, I think it's even more forbidden when using sockets *and* makefile() objects(which we do)12:54
vilaile objects returned by the makefile() method must only be used when the socket is in blocking mode;12:55
vilaquteo: "File objects returned by the makefile() method must only be used when the socket is in blocking mode"12:55
vilaso, don't do that12:55
vilamost of the issues in the socket/thread leaks in selftest saga (part I) were caused by timeouts12:56
vilajam: IIRC, the bzr server itself cheats a bit by using a timeout but it does so on the listening socket where we don't use makefile() objects12:57
vilajam: ping ?13:01
jamvila: there is a difference from setting a timeout on the socket, and using select with a timeout13:01
jamI'm not setting a timeout on the socket13:01
jam(and, unfortunately, empathy still refuses to make noise when I get mentioned.. :(13:01
vilaha, ok (empathy)13:01
jamI'll probably switch to Pidgin soon13:01
jamIt used to work13:01
jamBut  I think it stopped when I installed natty13:02
jamI have to see the little blue icon in the corner.13:02
vilayou may be right about select, but the symptom you describe reminded me of so many issues I encountered13:02
vilaso, back tracking,13:03
vilawhat do you mean by "before we start reading the next data stream" ?13:03
jamugh, still so much pain. If I run the test suite, I can see what test is failing, if I run *just* those tests, no failures13:04
jamvila: In SmartServerStreamMedium.serve() we loop over _build_protocol() _serve_one_request(protocol)13:04
jamso for every message that comes in from the client13:05
jamwe read the first line, then dispatch the request and process it in 'blocking' mode13:05
jamI'm trying to add a "select(..., timeout)" just before reading the first line13:05
jamso if a client connects, chats with us a bit, and then never hangs up13:05
jamwe'll hang up after a time13:05
jamas long as they *initiate* an RPC, we won't timeout on them (until that RPC has been fully responded to, and they haven't started a new one)13:06
jamfunny enough, I can set the select timeout to 4.0s, which is shorter than the 'hung_thread' timeout of 5s.13:07
jamAnd then I get the exception in my code.13:07
jamRunning a bunch of tests, seems to deterministically pick what test will fail13:07
jamrunning just that test, no failure13:07
vilajam: hmm, my gut feeling is that this won't mix up well with the rest (and the test failure kind of confirm that, but well, easy )13:07
vilaDoes the serve actually capture the connections or is it only the test server that does that for now ?13:08
vilajam: and do you include errors in your select ?13:09
viladuring tests we close the sockets with prejudice so if you don't include errors in your select, you may miss that13:10
vilaalternatively, if the connections are captured you can update a stamp and let the main thread close/kill the idle connections13:10
vilawhether you want to kill a connection taking too long to process a request or not may be worth considering too13:11
jamvila: currently I'm just doing select([r], [], []) however I get EBADF if the socket was closed on the server side.13:24
jamI don't do any special capturing, etc.13:24
jamvila: i don't *think* bzr serve --inet runs any threads13:24
jamI could be wrong13:24
jam(that particular case is also a PipeStreamMedium, which is not the same code path)13:26
jamplain 'bzr serve' creates a SmartTCPServer that dispatches to threads13:27
jambut "bzr serve --inet" just hooks up a SmartServerPipeStreamMedium to stdin/stdout13:27
jamso there isn't a master process monitoring the 'connections'13:27
=== zyga-afk is now known as zyga
jamfurther, it only fails during teardown parts of the test suite. Never in 'live' code.13:53
jamso i'm tempted to say it is something incomplete with out test infrastructure, not sure what yet13:53
vilaI don't remember issues with SmartServerPipe, may be because I didn't work much with it13:55
vilajam: which tests are failing ?13:56
jamA random selection (different each run) from: ugh, still so much pain. If I run the test suite, I can see what test is failing13:57
jamsorry bad paste13:57
jambzr selftest -s bt.per_branch.test_branch Remote -v13:57
jamNote, I did just find:         self.clients.pop()13:58
jam        self.clients.append((request, client_address, t))13:58
jamwhich doesn't actually check that the thing popped off is the same thing we are appending13:58
=== zyga is now known as zyga-afk
jamso there is at least the possibility that between 'get_request' and 'process_request' the order changes13:58
jamand we close the same object 2 times, but never close another object, etc.13:58
vilabut why is that involved if you focus on SSPipe ?14:00
jamI'm not focussing on SSPipe14:00
jamsince most of our test suite uses the other14:00
jamand I'd *like* them to act roughly the same14:00
jam*Launchpad* wants us to support the TCP stuff as well14:01
jamso that stale connections get reaped14:01
jamyes, we *could* do it in 2 different ways14:01
jameven weirder. sometimes you clearly get a 2s timeout, but the test still passes14:02
jamugh. it seems to pass if I add a 'print' statement14:05
jamsys.stderr.write is enough14:06
vilatiming issues are generally caused by a lack of synchro somewhere, addind timeouts in the mix.... shouldn't help14:07
jamI guess that gives the other thread a chance to say "oh hey, he must be shutting down"14:07
vilayeah, kind of adding sleep(abit)14:08
jamvila: oddly enough adding time.sleep(0.1) does *not* fix it. but print "data" *does*14:12
blackarchonhi guys :)14:13
blackarchonI don't see a windows build for bazaar 2.4.1 yet14:13
jamI have the feeling it is just the test suite failing to see the exception.14:13
jamblackarchon: it isn't built yet14:14
blackarchonis there an ETA?14:14
jamblackarchon: nothing concrete. I have it building now, but if there are any failures I probably won't have time to address them14:19
blackarchonjam: ok, thx :)14:28
jamblackarchon: looks like the build went fine. Uploaded14:44
* Riddell nudges jelmer into reviewing https://code.launchpad.net/~jr/bzr/i18n-enable-translations-everywhere/+merge/75040 again before the end of the day14:52
jelmerRiddell: I'll have a look14:52
jelmeroh, actually14:53
jelmerjam, vila: do you have an opinion on whether installation of gettext should happen by bzrlib.initialize() or lazily in bzrlib.i18n.gettext()?14:53
vilaboth :)14:54
vilait sounds like something that should be done in bzrlib.initialize() but if the cost is too high to be done unconditionally, then it should be lazy14:55
vilathe test suite itself doesn't really respect bzrlib.initialize though14:56
jelmerRiddell: is there a way to disable i18n explicitly?14:56
jelmerRiddell: I don't really want to bikeshed on this, as I'm not sure how important it is14:57
Riddelljelmer: currently unset LANGUAGE and the other envirnment variables14:57
jelmerRiddell: but it would be nice to give 3rd party users of bzrlib the ability to disable i18n14:58
Riddella function in i18n.py to do that would be easy enough14:59
jamRiddell: you said it was "slightly less than 0.1s to slightly more than". Anything more quantifiable?14:59
jamLike 0.01s or 0.08s, etc?14:59
jamI do like the idea that if a command has nothing to say, it doesn't have to load the mappings14:59
jamI have the feeling that the mappings will get more expensive to load when15:00
jama) they aren't just english15:00
jamb) we have more stuff that gets translated15:00
jamI don't know if gettext() loads all the mappings preemptively, or if it has an index and can only load the ones that are actually15:00
jamI would hope the latter15:01
jelmerI think it has the latter because it has some kind of binary file that it loads rather than the plain text15:02
blackarchonjam: thank you, I will test it! :)15:02
Riddelljam: for example http://paste.kde.org/121057/15:13
=== bigjools is now known as bigjools-otp
nigelbRiddell: Interesting post re:OpenSuse :)15:21
jelmervila: bzr-2.4.1-1 uploaded to debian, 2.4.1-1ubuntu1 now building..15:30
Riddelljelmer: i18n.disable_i18n() added15:35
jelmerRiddell: r=me15:47
jelmersorry, Launchpad jargon15:48
jelmerRiddell: I've approved your merge proposal.15:48
=== beuno is now known as beuno-lunch
=== bigjools-otp is now known as bigjools
=== zyga-afk is now known as zyga
=== deryck is now known as deryck[lunch]
Noldorinhi again jelmer16:39
jelmerhey Noldorin16:41
jamvila: I think I've tracked it down. My guess is that we enter select.select([socket]), and then the TestCase teardown code does socket.close()16:58
jamIf the teardown happened *first* we would get EBADF16:59
jambecause it happens second, we don't see it until after the timeout.16:59
jamI changed it to a loop, and now I get socket.error(EBADF) often16:59
jamAbout 1 time in 500 or so, I get something that looks just like socket.error16:59
jambut doesn't catch "exception socket.error"16:59
jambut it gets caught by a generic "except Exception"16:59
jamNow I have something that gets EBADF about 1-in-3 tests, but never causes the test suite to hang or crash17:00
vila...an socket.error that is not a socket.error... rings a bell, windows ?17:00
jamvila: this is on Ubuntu Natty17:00
vilano ssl involved ?17:00
jamIt *sounds* like if someone re-imported socket, so you had 2 real modules involved17:01
jamvila: This is mostly loop-back stuff.17:01
jamIt just str(e) says "error"17:01
jamerror(9, "bad file descriptor")17:01
jamI'll check, just a sec17:01
vilabut first things first17:01
vilayour enter the teardown while in select() ?17:01
vilayou have a thread running and you don't join it ?17:02
jamvila: I think it is your "issue a connect but don't write anything" connection17:02
jamwhich starts a new "oh, someone wants to talk to me" thread17:02
jamI'm not positive yet17:02
vilaoh, the hackish 'last connection to unblock the server in listen' ?17:03
vilaand I'll stop asking more questions, 3 pending ones is already a lot...17:04
jamvila: Right, racing threads. If the select() thread happens first, it doesn't see EBADF, if it happens second, it does17:05
jamif it doesn't see EBADF, it waits until timeout17:05
jambefore it fails17:05
jamwith nothing to read from17:05
jamwe *are* joining from it, but it fails in the mean-time with a timeout17:05
jamjoining to it17:05
jamAnd maybe the hackish last connection17:05
jammaybe just a connection that is still open, but gets randomly closed by the test suite17:06
jamvila: Exception: <class 'socket.error'> socket [Errno 9] Bad file descriptor17:06
jamthats "type(e), getattr(e, '__module__'), e"17:06
jamso it is completely "socket.error", just not *this* socket.error17:06
jamIf you get someone who, for example, reload(socket)17:07
* vila puke17:07
jamvila: I don't think that is the case here. But I've seen cases where a module gets loaded twice.17:07
jamonly times I know of are relative vs absolute imports17:07
jambut there should be only one "socket" module17:08
jamI suppose someone could do: "sys.modules.pop('socket'); import socket"17:08
jamor something like "during teardown we  "import socket; raise socket.error()"17:08
jamso socket got deleted by the garbage collector17:08
jamand just after that17:08
jamwe re-import it creating a new socket module with all new classes.17:08
jamvila: I know we have other code that does "socket_error = socket.error" with a comment17:09
jamabout socket.error not being around during teardown time17:09
jamoh, 1 sec, I just realized I was logging all errors, not just the ones that miss "socket.error". Trying again. It takes a while to trigger.17:09
vilaonly in the case of the threaded smart server for threads finishing after the main thread AIUI, but the explanation wasn't very clear17:10
vilawhen you say teardown, you're referring to the server teardown shutting down the client sockets ?17:10
jamvila: ah, not socket.error: select.error17:11
jam<class 'select.error'> select (9, 'Bad file descriptor')17:11
jamso 99/100 times it is a socket.error17:11
jamand less than 1:100 times it is a select.error17:11
vilahaaa, makes more sense17:12
vilayou may need to add select.error to the  expected exception list for the test server then17:12
jamvila: well, in the timeout code, I'm treating EBADF as "yeah, stop what you're doing". So no problem there. It shouldn't have to propagate to the test suite.17:14
jamvila: thanks for the hint on type(e)17:14
jamI *really* don't like the generic "error" classes17:14
vilaespecially when they create aliasing problems like this17:15
jamvila: yeah, I guess if __repr__ included __module__, that might be sufficient17:15
vilaso you're catching both select.error and socket.error and they both specify EBADF ?17:16
=== beuno-lunch is now known as beuno
Noldorinjelmer: hey17:24
jamvila: bonus points. select.error doesn't have an 'errno' attribute, instead it just has e.args[0] == EBADF.17:28
mgzis that still the case in 2.6?17:28
jammgz: python 2.7.117:28
vilajam: isn't that nice :)17:28
mgzI was under the impression it became a IOError subclass17:28
mgzbut that may well be py3k only.17:28
vilajam: and forget that windows will probably a different idiom17:28
vilas//don't/ don't forget !17:29
jamvila: certainly. That gets tested before this gets submitted.17:29
jamI probably *can't* select.select() at all for Pipes17:29
jambut at least we can do select(socket )17:29
vilajam: yeah, sorry :)17:29
vilajam: I think the required interface is fileno() so pipes should work (well, at least on posix)17:30
vila. o O (I't be so nice if all this crap was hidden in osutils once and for all...)17:30
=== deryck[lunch] is now known as deryck
JonOomphHi! I am trying to test a LaunchPad recipe using the command "bzr dailydeb openshot.recipe working-dir".  It generates a folder inside the working-dir with "{" and "}" characters.  Is there a way to configure the name of the "build" folder?  Thanks!18:04
JonOomphThe name of the folder it creates is "openshot-{debupstream}+{revno}+{revno:packaging}"18:04
JonOomphThis breaks one of my build steps... which call the "xml2po" command.  Apparently, xml2po hates the { and } characters18:05
AuroraBorealisseems that launchpad is overloaded or somethng19:26
Noldorinhi jelmer20:44
Noldoringuess i missed you earlier20:44
Noldorinjelmer, having trouble testing here a bit..20:44
jelmerhi Noldorin20:44
Noldorinjelmer, the problem is that once i uncommit, i cann't merge into the testing branch :-S20:44
jelmerNoldorin: how do you mean?20:45
NoldorinPS C:\Users\Alex\Documents\Visual Studio 2010\Projects\IRC.NET\0.4-test> bzr merge ..\0.4\tests -r 4720:45
Noldorinbzr: ERROR: Branches have no common ancestor, and no merge base revision was specified.20:45
jelmerwhat is in the testing branch?20:45
Noldorinthe testing branch is the 0.4 branch, uncommited to r46, then reverted20:46
jelmerNoldorin: what does "bzr missing ..\0.4\tests" say?20:47
Noldorinjelmer, ERROR: not a branch20:49
jelmersorry, what about ..\0.4 ?20:50
Noldorinjelmer, "you are missing 49 revision:" etc. etc.20:50
jelmerNoldorin: ah, but one of them has been dpushed?20:53
Noldorini think so20:53
Noldorinthe 0.4-test branch20:53
Noldorinsince it's on r4620:53
jelmerin that case you indeed won't be able to merge between them20:53
jelmerdpush changes the history20:53
Noldorinoh i see20:54
* jelmer ponders having a look20:54
jelmerI'll bbiab, give me a minute or two20:55
jelmer_Noldorin, back21:07
jelmer_Noldorin, so, the easiest way to reproduce the issue is to dpush r47 from your ircnet branch/21:08
Noldorini know this much21:08
Noldorinit's testing it that i've been trying to do the past 3/4 days21:09
jelmer_Noldorin, where is the bzr version of your ircnet branch again?21:10
jelmer_(Sorry, I know you mentioned it earlier but I don't have the link here)21:11
Noldorinjelmer: lp:ircdotnet/0.4 should demonstrate the issue21:11
Noldorinno prob21:11
jelmer_ok, reproduced21:21
Noldorinjelmer, btw, writing a little script for testing here... how can i run bzr commands *without* it prompting me?21:22
Noldorini.e. no confirmation for bzr commands21:22
jelmer_I think the only command that prompts is uncommit21:22
jelmer_it has a --force option21:22
Noldorinok cool21:23
Noldorinjelmer, written a test powershell script now, so i'm getting closer!21:58
Noldorinjelmer, do i have to do one commit per merge?22:00
jelmer_Noldorin, not sure I follow22:05
Noldorinjelmer, well if i try to do two merges in a row, it gives ERROR: Working tree "..." has uncommitted changes.22:06
Noldorin....no away around this?22:06
Noldorinor do i have to do merge, commit, merge, commit, merge, commit, ... ?22:06
maxbYou can --force it, but it's recommended to commit each merge individually22:08
jelmer_Noldorin, you probably want to commit each merge to be able to actually see where things break22:12
Noldorinjelmer, well i have to do them each at once...because as soon as i do dpush, bam, the branch is fucked22:12
Noldorincan't merge in..22:12
Noldorin(history has changed)22:12
jelmer_Noldorin, you can push an entire branch with all the changes split up into individual commits though, and then see which one has problems22:16
Noldorinthat's my plan22:16
Noldorinjelmer, okay, i have interesting results here..22:27
jelmer_Noldorin, cool22:33
jelmer_Noldorin, what are they?22:33
Noldorinjelmer, if you look at the log for -r 47, it is specifically one line that causes the problem22:34
Noldorinthat is, tests/22:34
Noldorinjelmer, you thought src/ i guess...but i don't think so22:40
Noldorinit seems to be hte line:22:47
NoldorinRM  src/IrcDotNet.Tests/README.md => tests/README.md22:47
Noldorinjelmer, yo uthere?23:05
jelmer_Noldorin: sorry, yep23:35
Noldorinjelmer, okay, more news if you're ready!23:35
jelmer_I am :)23:36
Noldorinright, so firstly i took all the changes from the r47 log individually and applied them in a series of merges to r4623:37
jelmer_Noldorin, so if you reduce the changes in r47 to just that change the bug occurs?23:37
Noldorinjelmer, if i then force merge (and only one commit at the end), it *works* fine23:37
Noldorinhowever, if i commit after each merge, it fails as usual23:37
Noldorinhowever, even in the case with force merges/single commit, it is necessary for both tests/ and samples/ (or neither) to me merged -- otherwise i get the error23:39
Noldorinjelmer, beyond that, i'm struggling to find the ultimate cause23:41
jelmer_Noldorin, hmm, that's interesting23:41
Noldorinjelmer, but then, if the "tests/" merge is not present, everything works fine, regardless of how it's merged it :-S23:42
Noldorinso evidently the tests/ change is the root of the issue23:43
Noldorinbut something about the samples/ change resolves it, *if* done simultaneously.23:43
Noldorin(i.e. 2 forced merges in the same commit)23:43
Noldorinjelmer, you see what i'm getting at?23:44
jelmer_Noldorin, yep, I do23:44
jelmer_Noldorin, we're getting somewhere23:44
Noldoringood good23:44
jelmer_I suspect the order in which we process the changes in bzr-git might be relevant23:45
Noldorinbzr init --git23:50
Noldorinbzr: ERROR: No module named posix23:50
Noldorinjelmer, any idea why that is happening? ^23:51
jelmer_Noldorin, that should be fixed in newer versions of bzr-git23:51
Noldorinoh ok cool23:51
Noldorini should update first indeed23:51

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!