| 00:12.48 | Corydon76-dig | pong |
| 00:14.14 | eliel | Corydon76-dig: sorry, already fixed.. |
| 00:14.30 | eliel | Corydon76-dig: thanks |
| 00:16.18 | *** join/#asterisk-dev moy (n=moy@189.169.62.96) |
| 01:04.07 | *** join/#asterisk-dev pabelanger (n=pabelang@OTWAON23-1242541604.sdsl.bell.ca) |
| 01:34.23 | *** join/#asterisk-dev jeffg (i=zB5JkkmX@pdpc/supporter/active/jeffg) |
| 01:52.44 | *** join/#asterisk-dev bkruse (n=bkruse@76.73.154.120) |
| 01:52.44 | *** mode/#asterisk-dev [+o bkruse] by ChanServ |
| 02:40.52 | *** join/#asterisk-dev stevie_ramjet (n=putnopvu@c-71-228-178-34.hsd1.al.comcast.net) |
| 02:40.53 | *** mode/#asterisk-dev [+o stevie_ramjet] by ChanServ |
| 03:32.27 | *** join/#asterisk-dev eliel (n=eliel@host-cotesma-162-8.smandes.com.ar) |
| 03:39.37 | *** join/#asterisk-dev gones (n=gones@203.193.37.251) |
| 03:55.11 | *** join/#asterisk-dev gones (n=gones@203.193.37.251) |
| 04:13.07 | *** join/#asterisk-dev ZX81_ (n=matt@202.20.97.211) |
| 04:26.29 | *** join/#asterisk-dev ZX81_ (n=matt@202.20.97.211) |
| 04:33.44 | *** join/#asterisk-dev kamanashisroy (n=kamanash@202.56.7.139) |
| 04:35.28 | *** join/#asterisk-dev CunningPike (n=arodgers@vpn.dnv.org) |
| 06:46.09 | *** join/#asterisk-dev grEvenX (n=even@ap39pb.ip.ssc.net) |
| 07:33.40 | *** join/#asterisk-dev oej (n=olle@ns.webway.se) |
| 07:33.41 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 07:43.19 | *** join/#asterisk-dev xrg_ (n=panos@cpe-77-83-154-127-dsl.netone.gr) |
| 08:33.21 | *** join/#asterisk-dev ZX81 (n=matt@202.20.97.211) |
| 08:39.25 | *** join/#asterisk-dev ZX81 (n=matt@202.20.97.211) |
| 08:39.48 | ZX81 | hi, I think I've found the commit that caused the crash in iax I've been seeing: |
| 08:39.49 | ZX81 | http://svn.digium.com/view/asterisk/branches/1.4/channels/chan_iax2.c?r1=127069&r2=127067&pathrev=127069 |
| 08:40.08 | ZX81 | http://bugs.digium.com/view.php?id=13063#90329 |
| 08:40.50 | ZX81 | iax2 causes Asterisk to crash in times of high network loss |
| 08:41.22 | ZX81 | it may be that high loss just causes it to happen faster |
| 08:42.23 | ZX81 | but I've run pretty extensive tests: http://bugs.digium.com/view.php?id=13063#90181 |
| 08:42.23 | ZX81 | I have over 400 cores :) |
| 08:44.06 | mvanbaak | so, 127067 is running ok, and 127069 is crashing ? |
| 08:44.09 | *** join/#asterisk-dev obnauticus (n=obnautic@c-67-160-181-107.hsd1.wa.comcast.net) |
| 08:45.12 | ZX81 | correct |
| 08:45.22 | ZX81 | actuall 126999 |
| 08:45.26 | ZX81 | *actually |
| 08:45.36 | ZX81 | but there are no commits to 1.4 between them |
| 08:45.47 | ZX81 | so the diff only has chan_iax2.c |
| 08:45.48 | ZX81 | :) |
| 08:46.56 | ZX81 | i.e. the above url is the same as http://svn.digium.com/view/asterisk/branches/1.4/channels/chan_iax2.c?r1=127069&r2=126999&pathrev=127069 |
| 08:47.11 | ZX81 | (r1=127069 and r2=126999) |
| 08:48.16 | ZX81 | I've tried reading through it, and it kinda makes sense, but there are a few sections I don't get |
| 08:48.28 | ZX81 | the actual line it crashes in was added in that commit |
| 08:48.44 | ZX81 | it was doing AST_SCHED_DEL(sched, iaxs[callno]->pingid); |
| 08:49.08 | ZX81 | but now there are two sections that do it |
| 08:49.29 | ZX81 | :) I've got another 3 cores while I've been typing :) |
| 08:50.26 | ZX81 | make that 4 |
| 08:50.27 | ZX81 | :) |
| 08:50.47 | ZX81 | anyway, I'm going to sign off for the night :) hopefully it'll make sense to someone :) |
| 08:59.03 | mvanbaak | thanks for the work on this one |
| 09:19.05 | *** join/#asterisk-dev oron (n=oron@local.xorcom.com) |
| 09:21.28 | *** join/#asterisk-dev oej (n=olle@ns.webway.se) |
| 09:21.28 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 09:23.01 | *** join/#asterisk-dev Gwayne (n=Gwayne@bb220-255-225-154.singnet.com.sg) |
| 09:48.10 | *** join/#asterisk-dev friendly12345 (n=friendly@ppp59-167-145-230.lns4.mel6.internode.on.net) |
| 09:54.18 | *** join/#asterisk-dev puzzled (n=patrick@puzzled.xs4all.nl) |
| 10:01.12 | *** join/#asterisk-dev oron (n=oron@local.xorcom.com) |
| 10:37.10 | *** join/#asterisk-dev kamanashisroy (n=kamanash@202.56.7.139) |
| 10:50.32 | *** join/#asterisk-dev RoyK (n=roy@ti211210a080-3097.bb.online.no) |
| 11:01.17 | *** join/#asterisk-dev eurodrew555 (n=andrews@83-244-164-142.cust-83.exponential-e.net) |
| 11:03.34 | *** join/#asterisk-dev _ys (i=yuri@91.151.196.254) |
| 11:05.11 | *** join/#asterisk-dev ccesario (n=ccesario@189-19-9-100.dsl.telesp.net.br) |
| 11:43.12 | *** join/#asterisk-dev russellb (n=russell@asterisk/developer-and-stable-maintainer/drumkilla) |
| 11:43.13 | *** mode/#asterisk-dev [+o russellb] by ChanServ |
| 11:46.42 | *** join/#asterisk-dev DagMoller (n=aguirre@unaffiliated/dagmoller) |
| 12:00.14 | *** join/#asterisk-dev RoyK (n=roy@ti211210a080-3097.bb.online.no) |
| 12:00.29 | *** join/#asterisk-dev RoyK (n=roy@ti211210a080-3097.bb.online.no) |
| 12:06.44 | *** join/#asterisk-dev caio1982 (i=caio1982@CAcert-br/caio1982) |
| 12:33.42 | *** join/#asterisk-dev xilun (n=xilun@office.proformatique.com) |
| 12:36.20 | *** join/#asterisk-dev jeffg (i=B7vjM84M@pdpc/supporter/active/jeffg) |
| 13:02.08 | *** join/#asterisk-dev anthm (n=anthm@CPE-72-131-113-50.wi.res.rr.com) |
| 13:31.55 | *** join/#asterisk-dev RoyK (n=roy@ti211210a080-3097.bb.online.no) |
| 13:38.07 | *** join/#asterisk-dev ctooley (n=ctooley@209.33.108.119) |
| 13:38.07 | *** mode/#asterisk-dev [+o ctooley] by ChanServ |
| 13:38.12 | ctooley | morning folks |
| 13:41.45 | tzanger | ping |
| 13:53.13 | *** join/#asterisk-dev putnopvut (n=putnopvu@216.207.245.1) |
| 13:53.14 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 14:02.23 | lmadsen | morning |
| 14:12.39 | Corydon76-dig | Morning |
| 14:14.05 | lmadsen | Corydon76-dig: did you see my response yesterday to the bug tracker workflow thread? I sent another one with some thoughts on what I think the status messages mean. Could you reply back and let me know if I'm way off base on anything? |
| 14:14.33 | Corydon76-dig | lmadsen: looked okay to me |
| 14:14.51 | lmadsen | ok, I figured everyone must have been in agreement if no one responded :) |
| 14:24.54 | *** join/#asterisk-dev xpot (n=jim@75.149.224.186) |
| 14:26.06 | *** part/#asterisk-dev xpot (n=jim@75.149.224.186) |
| 14:27.38 | *** join/#asterisk-dev oej (n=olle@ns.webway.se) |
| 14:27.39 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 14:27.58 | oej | Afternoon |
| 14:28.26 | *** join/#asterisk-dev sruffell (n=sruffell@216.207.245.1) |
| 14:28.27 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 14:28.53 | *** join/#asterisk-dev russellb (n=russell@asterisk/developer-and-stable-maintainer/drumkilla) |
| 14:28.54 | *** mode/#asterisk-dev [+o russellb] by ChanServ |
| 14:31.12 | mvanbaak | hello all |
| 14:31.18 | *** join/#asterisk-dev Laureano (n=Laureano@190.245.121.203) |
| 14:31.22 | Laureano | Hello |
| 14:33.12 | Corydon76-dig | mvanbaak: ping |
| 14:34.06 | mvanbaak | Corydon76-dig: pong |
| 14:34.22 | Corydon76-dig | mvanbaak: on your xmldocs, have you yet described GotoIf ? |
| 14:34.33 | mvanbaak | nope |
| 14:34.57 | Corydon76-dig | That one might throw a wrench in |
| 14:34.59 | mvanbaak | the big bunch of converting has been suspended while we are discussing the whole thing on the mailinglist |
| 14:35.14 | mvanbaak | hhmm, good one |
| 14:35.15 | jsmith-busy | Corydon76-dig: Why's that? |
| 14:35.34 | mvanbaak | the ? and : |
| 14:35.38 | Corydon76-dig | jsmith-busy: there are 3 different delimiters in GotoIf: '?', ':', ',' |
| 14:36.08 | jsmith-busy | Yeah... but don't we just make a special option called "ternary" or something like that? |
| 14:36.43 | jsmith-busy | GotoIf(), GotoIfTime(), IF() function |
| 14:36.52 | Corydon76-dig | ExecIf |
| 14:37.27 | jsmith-busy | Yeah... they all use basically the same syntax |
| 14:37.35 | Corydon76-dig | ExecIf provides an even bigger challenge, as there are two possible syntaxes that it will work with |
| 14:37.58 | jsmith-busy | $[expression]?optional-true-destination:optional-false-destination |
| 14:38.17 | Corydon76-dig | jsmith-busy: and arguments |
| 14:38.48 | Corydon76-dig | And the values for the true and false need to reference back to known applications |
| 14:39.01 | jsmith-busy | Yowsers... |
| 14:39.18 | Corydon76-dig | ExecIf($[...]?AppThatDoesntExist) should fail on syntax checking |
| 14:39.55 | *** join/#asterisk-dev joetester2 (n=chatzill@216.191.34.13) |
| 14:39.57 | jsmith-busy | Yup... the only thing I can think of right now is to use a special tag that says "This option should be sanity-checked as an application with arguments" |
| 14:40.09 | jsmith-busy | I don't know how else we'd do it |
| 14:40.22 | Corydon76-dig | Recursive parsing |
| 14:40.23 | mvanbaak | something like that indeed |
| 14:41.14 | Corydon76-dig | Even worse: ExecIf(...?${LOADED_APP_NAME}(${LOADED_APP_ARGS})) |
| 14:41.51 | Corydon76-dig | Possible now, but really, really difficult to validate |
| 14:42.04 | mvanbaak | erm, yeah |
| 14:42.13 | mvanbaak | hhmm |
| 14:43.50 | Corydon76-dig | And just to double your pain... anything in an Exec gets EVALed, so you can have variables within variables |
| 14:44.32 | mvanbaak | yup, was thinking about that as well |
| 14:44.38 | Corydon76-dig | i.e. the variable ${foo} might contain "${bar}baz" |
| 14:49.59 | *** join/#asterisk-dev codefreeze-lap (n=murf@216.166.159.235) |
| 14:49.59 | *** mode/#asterisk-dev [+o codefreeze-lap] by ChanServ |
| 14:51.23 | codefreeze-lap | yuck! I'm using gdb 6.8-debian and it's.... very.... frustrating? disappointing? maddening? all of the above? |
| 14:51.46 | putnopvut | "poopy?" |
| 14:51.59 | codefreeze-lap | putnopvut: you are getting the idea |
| 14:52.51 | codefreeze-lap | Whole chunks of my exec are as if they don't have debug symbols; these chunks are within files where large chunks are just fine |
| 14:53.34 | codefreeze-lap | Murphy's Law kicks in and places the blind chunks where you need critically to know what's going on |
| 14:53.59 | codefreeze-lap | so you have to use stupid debug statements |
| 14:54.26 | codefreeze-lap | which turn an investigation that could have taken a few minutes into an ordeal that could take an hour |
| 14:54.42 | *** join/#asterisk-dev kamanashisroy (n=kamanash@202.56.7.136) |
| 14:55.00 | kpfleming | so do we have any clue if that's the fault of gdb or the compiler? should be able to compile using an older version of the compiler and see if the results differ |
| 14:55.27 | codefreeze-lap | good question |
| 14:56.02 | codefreeze-lap | Why, oh, why, do I feel like a poster boy for Murphy's Law? |
| 14:56.23 | Juggie | your last name is murphy |
| 14:56.28 | Juggie | its fate. |
| 14:56.46 | codefreeze-lap | Juggie: thanks for reminding me |
| 14:58.09 | Juggie | anytime :) |
| 14:59.35 | codefreeze-lap | Well, at least I got the water pump going again. Stringing the new cable under the road was extremely challenging. I almost lost my life rewiring the darn thing into the circuit breaker. The darn new switch didn't have a diagram, and I wired it wrong. The clay I had to hand dig 3 feet into was peppered with rocks. And before I could start I had to have power, telephone, and gas lines marked. |
| 15:01.21 | codefreeze-lap | I won't even mention mosquitos around the irrigation lateral. |
| 15:02.34 | codefreeze-lap | So, having a debug tool that works.... would be nice |
| 15:02.49 | Juggie | codefreeze-lap, move to the city. |
| 15:05.40 | *** join/#asterisk-dev puzzled (n=patrick@puzzled.xs4all.nl) |
| 15:15.41 | *** join/#asterisk-dev shido6 (n=shido6@209.114.208.192) |
| 15:20.15 | codefreeze-lap | gcc is 4.2.3 (4.2.3-2ubuntu7) |
| 15:36.45 | *** join/#asterisk-dev jpeeler (n=jpeeler@asterisk/digium-software-dev/jpeeler) |
| 15:36.45 | *** mode/#asterisk-dev [+o jpeeler] by ChanServ |
| 15:40.52 | *** join/#asterisk-dev agx (n=AGX@host63-216-static.34-88-b.business.telecomitalia.it) |
| 15:50.38 | *** join/#asterisk-dev outtolunc (n=me@adsl-66-218-53-172.dslextreme.com) |
| 15:51.57 | tzanger | russellb: ping? |
| 15:52.47 | ctooley | oej, ping? |
| 15:52.56 | oej | Here |
| 15:53.26 | oej | What's up? |
| 15:54.07 | *** part/#asterisk-dev pgarcia (n=pedgarci@yoda.kanatek.com) |
| 15:54.17 | ctooley | oej, the IM I sent you |
| 15:54.47 | oej | Ok |
| 15:55.00 | oej | Busy replicating stuff. |
| 15:55.05 | oej | Ah. What a nice cup of tea! |
| 15:55.09 | ctooley | fun |
| 15:55.39 | oej | Well, yes and no. |
| 15:55.52 | oej | Setting up mysql replication |
| 15:55.57 | oej | Anyone tested mysql proxy? |
| 15:56.00 | oej | Seems like a lot of fun. |
| 15:59.37 | *** part/#asterisk-dev agx (n=AGX@host63-216-static.34-88-b.business.telecomitalia.it) |
| 15:59.40 | mvanbaak | oej: yes, we have it running in production |
| 15:59.56 | oej | And? |
| 16:00.06 | mvanbaak | it works |
| 16:00.31 | mvanbaak | I really love that you can inject stuff ;) |
| 16:00.34 | oej | Just for failover? |
| 16:00.41 | oej | Or are you adding lua stuff? |
| 16:00.51 | oej | Well, you can never trust the database again... |
| 16:00.58 | mvanbaak | we did some tests with the lua stuff |
| 16:01.01 | mvanbaak | it's fun |
| 16:01.11 | mvanbaak | I think we have some of that still active |
| 16:01.17 | mvanbaak | but we mainly use it for failover |
| 16:01.53 | oej | And you're happy with that? |
| 16:02.07 | mvanbaak | nope |
| 16:02.16 | mvanbaak | we're moving away from it |
| 16:02.26 | oej | For what reason? |
| 16:02.28 | mvanbaak | in our new setup all boxen will have a local mysqld |
| 16:02.39 | mvanbaak | a 6 node master-master setup |
| 16:02.40 | oej | With replication? |
| 16:02.45 | mvanbaak | yup |
| 16:02.50 | mvanbaak | master-master replication |
| 16:03.41 | mvanbaak | that way all our machines will be selfserving |
| 16:05.16 | mvanbaak | but other then that |
| 16:05.23 | mvanbaak | mysql-proxy is nice |
| 16:06.18 | *** join/#asterisk-dev bkruse (n=bkruse@216.207.245.1) |
| 16:06.18 | *** mode/#asterisk-dev [+o bkruse] by ChanServ |
| 16:06.20 | mvanbaak | but since we already have to do replication we figured to rely on that and move the mysqld to the local boxen |
| 16:06.33 | mvanbaak | it's a complete new setup, so it was a good time to do it |
| 16:06.47 | mvanbaak | slowely replacing all our homemade boxen with sun gear |
| 16:06.55 | mvanbaak | bkruse: ! |
| 16:07.20 | mvanbaak | bkruse: there's a nice task for us in the appdocsxml branch |
| 16:07.43 | mvanbaak | 16:34 <@ Corydon76-dig> mvanbaak: on your xmldocs, have you yet described GotoIf ? |
| 16:07.46 | mvanbaak | 16:34 <@ mvanbaak> nope |
| 16:07.49 | mvanbaak | 16:34 <@ Corydon76-dig> That one might throw a wrench in |
| 16:08.54 | mvanbaak | bkruse: see this: http://pastebin.com/m1f2970a3 |
| 16:14.13 | *** join/#asterisk-dev Schmooze (n=Schmooze@rrcs-67-53-189-178.west.biz.rr.com) |
| 16:21.02 | tzanger | russellb: ping? |
| 16:24.50 | file | he is not currently present. |
| 16:30.19 | jeffg | tzafrir, thanks for sucking me into the schneier facts vortex, i may never escape the urge to reload! |
| 16:36.18 | JerJer | putnopvut: remember the chan_spy delay issue i had last week? It only shows itself when using G.729 vocoder from Digium |
| 16:37.52 | *** join/#asterisk-dev anonymouz666 (n=anonymou@201.19.92.35) |
| 16:57.34 | *** join/#asterisk-dev emiller (n=ed@UNUSED-216-37-164-100.UNUSED.epix.net) |
| 16:57.44 | *** part/#asterisk-dev emiller (n=ed@UNUSED-216-37-164-100.UNUSED.epix.net) |
| 17:07.30 | bkruse | mvanbaak: ! |
| 17:07.57 | mvanbaak | wow, huge latency ! |
| 17:12.34 | tzanger | hmm |
| 17:19.29 | *** join/#asterisk-dev netstv (n=stv@phoenix.u4eatechinc.com) |
| 17:20.17 | netstv | I'm cross-compiling zaptel (latestest 1.4 branch checked out this morning) |
| 17:20.22 | netstv | using a mips compiler |
| 17:20.29 | netstv | I get this error message when compiling |
| 17:21.21 | netstv | zttranscode.c:400: error: 'PAGE_SHARED' undeclared |
| 17:21.46 | netstv | I searched all over the place and it was suppose to be fixed.. my kernel version is 2.6.21 |
| 17:22.02 | netstv | and I see where the code checks for kernel revs etc.. |
| 17:22.22 | tzanger | hmm |
| 17:22.28 | netstv | And I see that pgtable.h is being included |
| 17:22.31 | tzanger | nommu archs and mmu archs both have that defined |
| 17:22.42 | tzanger | is there a compelling reason to need zttranscode in your environment/ |
| 17:22.44 | netstv | and that _PAGE_NO_EXEC is defined.. |
| 17:23.05 | netstv | no.. no real reason I guess.. |
| 17:23.20 | netstv | I just wanted to have "everything" just in case... I can remove it... easy enough |
| 17:23.48 | tzanger | well zttranscode is for the zaptel transcode card |
| 17:23.51 | tzanger | er transcoder |
| 17:24.02 | sruffell | netstv: I would remove it.....the interface for the transcoder is changing so it's not worth hunting down. |
| 17:24.06 | netstv | oh.. ok.. then no .. I don't need it. |
| 17:24.11 | netstv | Thanks guys |
| 17:26.08 | tzafrir_laptop | netstv, is that the only error? |
| 17:26.18 | tzafrir_laptop | ah, ok |
| 17:26.46 | tzafrir_laptop | but zaptel does build on blackfin, which is mmu-less |
| 17:30.39 | mvanbaak | Corydon76-dig: if I want to test that failover patch.... |
| 17:30.49 | Corydon76-dig | Go for it |
| 17:31.03 | mvanbaak | is it enough if I do two DSN's, one with read-only access to the db and the failover with read-write access ? |
| 17:31.27 | mvanbaak | or should I setup two db servers ? |
| 17:31.39 | Corydon76-dig | Right, the failover only works on a server with writes |
| 17:31.58 | Corydon76-dig | and only after the previous write succeeded, but affected 0 rows |
| 17:32.21 | mvanbaak | so two servers |
| 17:32.41 | netstv | tzafrir_laptop, sorry walked away.. so far.. |
| 17:32.44 | Corydon76-dig | It's not really failover in the DB sense as much as it is a backup query if the first one didn't do anything |
| 17:33.02 | Corydon76-dig | mvanbaak: why two servers? |
| 17:33.25 | mvanbaak | hhmm |
| 17:33.26 | Corydon76-dig | insertsql uses the writehandle, same as the writesql |
| 17:33.45 | mvanbaak | two databases on the same server will work as well |
| 17:33.59 | Corydon76-dig | I'm not seeing why two databases |
| 17:34.13 | mvanbaak | an update that affected 0 rows |
| 17:34.21 | mvanbaak | that means the change was already there |
| 17:34.24 | mvanbaak | right ? |
| 17:34.47 | Corydon76-dig | The intent is that the WHERE matched 0 rows |
| 17:35.00 | mvanbaak | aaaaaaaaaah |
| 17:35.05 | mvanbaak | now it makes sense |
| 17:35.33 | Corydon76-dig | So the query runs fine, but it affects 0 rows |
| 17:37.45 | mvanbaak | bkruse: did you read the stuff I put on the pastebin ? |
| 17:39.45 | Corydon76-dig | mvanbaak: I don't know how the db reports if you set a value that was already there |
| 17:40.06 | mvanbaak | 0 rows for pgsql and mysql |
| 17:40.14 | Corydon76-dig | mvanbaak: it might be backend-defined |
| 17:40.15 | mvanbaak | that's what I know. dont know about others |
| 17:48.03 | Corydon76-dig | mvanbaak: if you have a better idea on how to handle it, I'm all ears |
| 17:48.15 | mvanbaak | not right now |
| 17:48.41 | mvanbaak | been trying some ideas, but all fail even before I touch code |
| 17:51.26 | bkruse | mvanbaak: I am going to now |
| 18:04.17 | mvanbaak | gheh |
| 18:04.37 | mvanbaak | "I think the OpenBSD crowd is a bunch of masturbating monkeys, in |
| 18:04.37 | mvanbaak | that they make such a big deal about concentrating on security to the |
| 18:04.38 | mvanbaak | point where they pretty much admit that nothing else matters to them." |
| 18:04.45 | mvanbaak | who said that ? |
| 18:06.03 | bkruse | hides |
| 18:06.07 | bkruse | :P |
| 18:06.53 | bkruse | mvanbaak: That is very very cool, however, we are far from that. Add it to the todo list :] |
| 18:30.56 | Juggie | hrmf... google tells me its 25c & Icy |
| 18:31.41 | putnopvut | those don't mix |
| 18:31.49 | Juggie | no kidding |
| 18:32.07 | Juggie | it was sunny before and now my google desktop just updated to 25C& Icy |
| 18:33.07 | russellb | Canada is a messed up place |
| 18:33.15 | Juggie | hahah well there is no ice :) |
| 18:34.22 | Juggie | given that its 25c w/ 32c humidex |
| 18:35.00 | Juggie | which is 77f/89f w/ humidity |
| 18:35.09 | Juggie | for you imperial morons. |
| 18:35.10 | *** join/#asterisk-dev unpaidbill (i=bill@420nugs.info) |
| 18:35.12 | Juggie | :) |
| 18:43.15 | Qwell | hey codefreeze-lap - any idea how difficult it would be to add support for some of the crazy variable substitution syntax that bash has? Like ${parameter:-word} ? |
| 18:43.34 | Qwell | "parameter expansion", per the man page |
| 18:45.01 | codefreeze-lap | Qwell: Corydon76-dig is the expert on vars. I don't think beefing up the ${..} syntax should be that awful.... but Tilghman may not concur... |
| 18:45.39 | Qwell | the folks in #bash showed me ${parameter:+word}, which is pretty awesome |
| 18:46.24 | Qwell | showed me an interesting use of it, anyhow. ${var:+"${var}"} (if var is non-null, output $var in quotes - otherwise output nothing) |
| 18:47.02 | *** join/#asterisk-dev oej (n=olle@ns.webway.se) |
| 18:47.02 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 18:47.05 | *** join/#asterisk-dev jameswf-home (n=james@dsl093-157-131.phx1.dsl.speakeasy.net) |
| 18:47.57 | russellb | what is ${param:-word} ? |
| 18:48.05 | Qwell | the opposite |
| 18:48.18 | *** join/#asterisk-dev davevg-btwtech (n=davevg-b@nj-67-76-177-147.sta.embarqhsd.net) |
| 18:48.18 | Qwell | well, sort of |
| 18:48.28 | Qwell | "If parameter is unset or null, the expansion of word is substituted. Otherwise, the value of parameter is substituted." |
| 18:48.41 | russellb | oh, yes, i've seen that in a few scripts |
| 18:48.49 | russellb | namely -- ${EDITOR:-vi} |
| 18:48.52 | Qwell | right |
| 18:48.56 | Qwell | though |
| 18:48.57 | russellb | now that makes sense :-p |
| 18:49.05 | Qwell | ${EDITOR:-"nano -w"} is more correct |
| 18:49.11 | russellb | only for nubs |
| 18:49.15 | bkruse | :] |
| 18:49.22 | russellb | but seriously, you have a better chance of "vi" being present than "nano" |
| 18:49.36 | Qwell | no vi on Gentoo live CD. |
| 18:49.46 | russellb | srsly? that is so lame |
| 18:49.54 | Qwell | vi is like 80gb |
| 18:50.04 | Juggie | well why do you need vi on a live cd |
| 18:50.07 | Juggie | what are you editing |
| 18:50.21 | Qwell | on Gentoo? half the system. |
| 18:50.22 | russellb | Juggie: Gentoo. |
| 18:50.30 | Qwell | mostly make.conf though :p |
| 18:50.39 | Juggie | ya but when you boot from live isnt that mostly a read only system? |
| 18:50.44 | *** join/#asterisk-dev ccesario (n=ccesario@linux.unialco.com.br) |
| 18:50.49 | Juggie | or are you talking theres no vi once you do a live->hdd install |
| 18:51.36 | Qwell | Juggie: that too |
| 18:51.44 | Qwell | vi is not in system |
| 18:52.17 | putnopvut | *nix without vi seems weird to me. |
| 18:52.27 | bkruse | putnopvut: Same |
| 18:53.27 | Juggie | oh i agree then, i thought it just wasnt in the live image. which would of been fine as on a live system you cant edit anything |
| 19:04.59 | seanbright | what about emacs |
| 19:04.59 | seanbright | ? |
| 19:05.38 | putnopvut | it's an anagram of "maces." |
| 19:05.50 | seanbright | ~slap putnopvut |
| 19:05.51 | jbot | ACTION slaps putnopvut, keep your grubby fingers to yourself! |
| 19:06.18 | seanbright | ... or something |
| 19:17.41 | Corydon76-dig | It's also an anagram of 'e-scam' |
| 19:18.07 | Corydon76-dig | which approximately describes what RMS has been foisting on the public for the last 20 years |
| 19:18.17 | seanbright | zzzzzzzzzzzzzzzz... |
| 19:18.19 | seanbright | heh |
| 19:18.26 | Corydon76-dig | (in the form of an editor) ;-) |
| 19:27.18 | bkruse | mvanbaak: I am about to propose a new solution for the appdocsxml stuff on the ML |
| 19:27.36 | russellb | bkruse: specifically, re: the storage method, right? |
| 19:29.47 | bkruse | russellb: Correct, I even called it XML documentation (implementation), and named it geared towards storage and generation, and NOT the use of the XML in any other form |
| 19:34.17 | jsmith | bkruse: What good does it do to come up with another way of storage and generation if we can't put it to good use?!? |
| 19:34.38 | jsmith | bkruse: Don't get me wrong -- I'd love to see your proposal, but as I see it, we: |
| 19:35.03 | jsmith | 1) Need to figure out *what* we're going to do with the docs (dialplan checking, for example) |
| 19:35.13 | jsmith | 2) Figure out *how* we're going to do step 1 |
| 19:35.23 | jsmith | 3) Make sure the XML format supports step number 2 |
| 19:35.24 | bkruse | jsmith: Because this is a major concern. If we cannot properly, or efficiently store the docs, dialplan checking, etc, won't ever come along. |
| 19:35.44 | bkruse | We can worry about the features when we come to that bridge, but we will never see the bridge if we do not :] |
| 19:35.45 | jsmith | would argue just the opposite |
| 19:36.01 | jsmith | If you make the features work and work well, people will fix the efficiency problem later |
| 19:38.34 | ctooley | has to agree with jsmith |
| 19:45.07 | mvanbaak | bkruse: cant wait to see what you have in mind |
| 19:45.57 | tzanger | russellb!! |
| 19:46.03 | russellb | WHAT |
| 19:52.37 | bkruse | mvanbaak: sent |
| 20:03.53 | *** join/#asterisk-dev CunningPike (n=arodgers@vpn.dnv.org) |
| 20:12.45 | Laureano | Could be possible to call ast_rtp_get_quality before the end of a SIP call? i.e., by using a new manager action. I would like to keep track a the QoS for a particular call in realtime. |
| 20:15.39 | *** join/#asterisk-dev anthm (n=anthm@mbe0736d0.tmodns.net) |
| 20:16.46 | *** join/#asterisk-dev paravoid (n=paravoid@zebra.cslab.ece.ntua.gr) |
| 20:17.54 | bkruse | mvanbaak: check that out |
| 20:20.52 | mvanbaak | +N from me (where N is close to infinite) |
| 20:32.46 | *** join/#asterisk-dev Juggie (i=Juggie@CPE001601df17fb-CM001a6682d7b6.cpe.net.cable.rogers.com) |
| 20:35.48 | bkruse | nice |
| 20:35.52 | bkruse | Good mvanbaak :) |
| 20:36.13 | codefreeze-lap | russell: on 13089, I'm at the brink of closing it down, but for just one little thing |
| 20:37.46 | codefreeze-lap | Before I updated my mtxprof branch today (and it's been a while since I last updated it), I could not see *some* locks I had taken out; it appeared like they were maybe there, just messed up. |
| 20:38.33 | codefreeze-lap | Now, they look much better, and it looks like Tilghman's fix at 125794 might have done that trick. |
| 20:39.01 | codefreeze-lap | Just one thing: the lockaddr is not the same.... and it's not obvious to me why. |
| 20:40.04 | codefreeze-lap | hmmm |
| 20:49.05 | russellb | o.O |
| 20:50.03 | russellb | i asked bbryant to work with you to see if he could reproduce it, as well |
| 20:50.22 | russellb | so, we need a test case that anyone can run to see it ... |
| 20:53.57 | codefreeze-lap | well, I've got a pretty reproducible test in my mtxprof (team/murf/mtxprof) branch. |
| 20:54.26 | codefreeze-lap | All you need is a sip phone or two and a dialplan to let you call from one to the other. |
| 20:54.57 | Corydon76-dig | codefreeze-lap: I love fixes that you don't even have a crash for, you just think, hmm, that's probably bad, and it later turns out, you're right. |
| 20:55.34 | codefreeze-lap | Corydon: I'm going to make sure you get a karma cookie for that fix! |
| 20:56.25 | russellb | so if it's reproducible, then it doesn't fix it.. ? |
| 20:56.45 | russellb | or at least not fix all of ti |
| 20:58.10 | codefreeze-lap | russellb: The example is: there's a channel_lock call in the __ast_answer routine. I put a log_show_lock before it and after it. Now, you can see the lock added to the list after the lock is aquired. BUT, the lockaddr doesn't match. Is there like any way on earth that shortly after a channel gets a lock, it like masquerades into a different channel struct or something? |
| 20:58.55 | putnopvut | codefreeze-lap: if it's a local channel, then yes. But that shouldn't change the channel's lock address. |
| 21:00.48 | codefreeze-lap | Well, the same channel between all 3 calls, but... the addr of the channel lock is 0xbb32104, but the lockaddr field in the lock_info says 0xbb3271c.... weird |
| 21:00.50 | russellb | your log_show_lock would only show the lock info for a specific lock |
| 21:01.08 | russellb | so i'm not sure how that demonstrates the problem |
| 21:01.11 | codefreeze-lap | russellb: well, I jimmied it to show all the locks |
| 21:01.47 | russellb | how do you determine the address in the lock info array? |
| 21:01.49 | russellb | show me that code ... |
| 21:02.05 | codefreeze-lap | Since I can't match by lockaddr, I match by eyeball and elimination |
| 21:03.08 | codefreeze-lap | russellb: see team/murf/mtxprof/main/utils.c, around line 898 |
| 21:03.45 | russellb | looks |
| 21:05.19 | russellb | that code is going ot show you the info of the first lock, in the first thread's array that has any locks, and that's it |
| 21:06.20 | russellb | i assume you meant to remove the break there ... |
| 21:07.01 | putnopvut | "first thread's array" ... My eye says that it will print all the threads' first lock in the array. |
| 21:07.16 | russellb | putnopvut: ah yes, you're right |
| 21:07.30 | russellb | so yeah, it will print the first (and only the first) lock for each thread that holds any number of locks |
| 21:07.40 | russellb | and the _last_ lock will be in position N-1, not position 0 |
| 21:07.45 | russellb | if N > 1, it won't be printed |
| 21:08.11 | russellb | so, remove your break, and i presume you will see your lock as expected |
| 21:08.15 | russellb | and the world will be happy again |
| 21:09.35 | codefreeze-lap | pokes self |
| 21:10.04 | codefreeze-lap | duh, forgot to hit the break for the special case |
| 21:10.13 | codefreeze-lap | OK |
| 21:10.20 | codefreeze-lap | We'll see |
| 21:11.44 | putnopvut | is mtxprof built off of trunk? |
| 21:12.25 | ctooley | <PROTECTED> |
| 21:15.06 | codefreeze-lap | putnopvut: yes, it's trunk based |
| 21:15.26 | codefreeze-lap | ctooley: still looking at the numbers |
| 21:16.36 | codefreeze-lap | russellb: well, not breaking after the first lock shows one more lock than it did before (an ao2_lock)... so, by dumb luck, I've been seeing the right lock in the lock_infos, but the lock_addr is still wrong. |
| 21:18.50 | putnopvut | codefreeze-lap: do you mind pastebinning the output? I tried to compile mtxprof and had compilation problems. |
| 21:18.52 | mvanbaak | the fix for res_agi.c that went in yesterday totally fixed the instability of my trunk box |
| 21:18.56 | mvanbaak | thanks again |
| 21:19.33 | mvanbaak | 'core show channels' now reports: 1500 calls processed |
| 21:19.40 | russellb | yay |
| 21:19.42 | mvanbaak | not one deadlock |
| 21:20.17 | mvanbaak | before the fix, I had to kill asterisk with signal 9 after every 2nd or 3rd call |
| 21:23.30 | codefreeze-lap | On this run, the channel lock addr is 0xbb2f98c; but the lock_info says it is 0xbb2ffa4 |
| 21:24.03 | codefreeze-lap | see http://www.pastebin.ca/1073766 |
| 21:24.12 | Corydon76-dig | bkruse: hopefully the email that got delivered to the -dev list today was just stuck in some queue somewhere for several days |
| 21:27.30 | codefreeze-lap | Interesting! both sets of lock address differ by 1560 (base 10) |
| 21:27.38 | *** join/#asterisk-dev ZX81 (n=matt@202.20.97.211) |
| 21:27.49 | kpfleming | is DEBUG_THREADS on? |
| 21:28.10 | codefreeze-lap | kpfleming: yes, DEBUG_THREADS is on |
| 21:28.29 | codefreeze-lap | and so is MTX_PROF |
| 21:28.38 | kpfleming | so the difference is probably the difference between the address of the ast_mutex_t structure and the embedded pthread_mutex_t which is the actual lock |
| 21:28.57 | codefreeze-lap | aha! |
| 21:29.19 | ZX81 | hi all, it would be cool if someone could take a look at: http://bugs.digium.com/view.php?id=13063 (Crash in iax2_destroy at chan_iax2.c:1309) I've narrowed it down to one commit, and if you understand IAX2 it will probably make sense to you |
| 21:29.47 | ZX81 | machine leaves for production tonight, and so I won't be able to test patches unless we get one soon :) |
| 21:30.45 | bkruse | Corydon76-dig: it FINALLY got sent |
| 21:32.55 | bkruse | Corydon76-dig: That answer would simply be whoever installed last |
| 21:33.06 | russellb | kpfleming: codefreeze-lap ... yes that would perfectly explain it, and in that case, codefreeze-lap is seeing expected behavior |
| 21:33.22 | bkruse | Corydon76-dig: You think the xml file should reflect the file installed? (eg app_stack.xml), that way, there could only be one |
| 21:33.35 | russellb | and the address being passed to log_lock or whatever is not valid |
| 21:33.49 | Corydon76-dig | bkruse: that's why we've been discussing embedding the documentation directly into the module |
| 21:34.04 | Corydon76-dig | bkruse: object file, not source |
| 21:34.52 | russellb | he proposed a method of having external docs, that allows easily overriding originally installed versions to avoid the (potentially unnecessary) complexity of embedding it with magic |
| 21:35.01 | ZX81 | The patch that broke it was 127068/127069 by tilghman |
| 21:35.13 | russellb | i'm not sure that the approach he described was discussed directly |
| 21:35.41 | Corydon76-dig | bkruse: what about apps that do not directly relate to their module name? |
| 21:35.46 | russellb | forget the name |
| 21:35.51 | russellb | i think having a magic filename is silly |
| 21:35.58 | russellb | and i think his email said that the filename was irrelevant |
| 21:36.04 | russellb | (we should be doing this on the list so it gets recorded) |
| 21:36.31 | Corydon76-dig | russellb: My point was, I think we already had this discussion (on the list) and it was rejected |
| 21:37.01 | russellb | about having a separate directory for the data from 3rd party modules, and always looking in those files for the data first? |
| 21:37.28 | Corydon76-dig | russellb: It still ignores multiple apps of the same name from multiple third parties |
| 21:38.15 | russellb | you can't fix all the possible ways users can be stupid |
| 21:38.17 | russellb | :) |
| 21:38.27 | Corydon76-dig | That's why embedding it into the object module works well. Whatever module is loaded, that's both the object code AND the documentation that is used |
| 21:39.11 | russellb | well, i do agree that is the "technically superior" solution. However, it also feels overly complex. I'm not even sure what a reasonable implementation of that would be ... |
| 21:39.52 | russellb | while the method of doing it in files is easy and can be done right now |
| 21:40.16 | russellb | in any case, regardless of the resolution of the storage debate, if we can agree on the format, then the Asterisk coding, and conversions can continue |
| 21:40.31 | russellb | and we can leave the storage method as an implementation detail to be resolved before merging |
| 21:40.44 | russellb | the 2 issues, storage and the format itself, should not be dependent on each other |
| 21:40.52 | Corydon76-dig | I have no problems so far with the format, as long as he addresses the points I made earlier today |
| 21:40.58 | russellb | nods |
| 21:41.36 | russellb | then maybe we should just make that point on the list. Let's focus on the format, and the code in Asterisk that makes use of it. We'll figure out the storage implementation detail before merging, but later |
| 21:41.43 | russellb | since that really shouldn't hinder the rest of the development |
| 21:41.49 | Corydon76-dig | Besides, Kevin is already looking into how to store data is a separate section of an object file, for another purpose, already |
| 21:42.08 | russellb | we have some of that already for embedded modules ... |
| 21:42.33 | mvanbaak | sexy |
| 21:42.39 | russellb | we store a copy of the initialized data section, so that when the module is "unloaded" and "loaded" again, we can reinitialize the global data |
| 21:42.54 | mvanbaak | we have to fix the doc formats for the *If stuff |
| 21:42.57 | russellb | of course, that only works when using gnu ld |
| 21:43.09 | russellb | and that's not the only linker used for asterisk ... |
| 21:43.15 | Corydon76-dig | I think we already require gnu ld |
| 21:43.18 | russellb | we do not |
| 21:43.26 | putnopvut | why don't we? |
| 21:43.27 | russellb | mac osx for example, does not use gnu ld |
| 21:43.37 | Corydon76-dig | Ah |
| 21:43.42 | russellb | probably the bsd's, too, not sure |
| 21:43.45 | Qwell | somebody would have to rebuild gcc to use gnu ld :D |
| 21:44.07 | mvanbaak | we should stop using gcc, and go with pcc |
| 21:44.11 | russellb | and forcing people to use it may not even be an option. i'm not sure |
| 21:44.16 | mvanbaak | a nice BSD licensed c compiler |
| 21:44.31 | russellb | mvanbaak: unlikely. we use about 928347239 gcc specific features |
| 21:44.31 | Qwell | or we could write everything in x86 assembly |
| 21:44.32 | russellb | :-p |
| 21:44.40 | mvanbaak | gheh |
| 21:44.48 | mvanbaak | nah, depending on gcc is not a problem |
| 21:45.05 | putnopvut | Yes, and I have a feeling that the number of gcc installations outnumbers the number of pcc installations by about 384921347891 |
| 21:45.05 | mvanbaak | and I think depending on gnu ld wont be that much of a problem |
| 21:45.14 | mvanbaak | we already depend on gcc, gnu make etc |
| 21:45.15 | russellb | anyway. let's shelve the storage debate for now |
| 21:45.18 | mvanbaak | so why not gnu ld |
| 21:45.33 | Qwell | mvanbaak: because if your gcc doesn't use gnu ld, I think you have to build it yourself |
| 21:45.39 | mvanbaak | putnopvut: you're being pessimistic there |
| 21:45.50 | Qwell | it=gcc |
| 21:46.03 | mvanbaak | Qwell: cant you instruct it to use $linker |
| 21:46.05 | mvanbaak | ? |
| 21:46.18 | mvanbaak | erm |
| 21:46.23 | Qwell | I don't believe so |
| 21:46.23 | mvanbaak | linker/loader |
| 21:46.42 | mvanbaak | --with-ld=/foo/bar |
| 21:46.44 | mvanbaak | ? |
| 21:46.58 | Qwell | --with-ld when building gcc :) |
| 21:47.08 | Corydon76-dig | ZX81: try revision 131480 |
| 21:47.46 | mvanbaak | I think you are right |
| 21:48.39 | Juggie | the only real issue with storeing the translations directally within the source would be adding new translations |
| 21:48.57 | Juggie | you'd end up having to touch every file unless you could come up with some kind of include system to do it simpler |
| 21:48.59 | Corydon76-dig | Juggie: not within the source |
| 21:49.10 | mvanbaak | inside an object file |
| 21:49.19 | mvanbaak | or whatever |
| 21:49.26 | Corydon76-dig | Juggie: why are we even discussing changing the source at this point? |
| 21:49.30 | mvanbaak | we delayed that for now |
| 21:49.32 | Juggie | good point :) |
| 21:49.40 | Juggie | i just was catching up on the conversation was afk for a few |
| 21:52.48 | ZX81 | Corydon76-dig: ok cool will do |
| 21:53.42 | mvanbaak | Corydon76-dig: that thing is only present in 1.4 ? |
| 21:53.52 | mvanbaak | (the iax fix you just committed) |
| 21:54.27 | Corydon76-dig | Yes |
| 21:54.43 | mvanbaak | I think the duplicate new fix is as well |
| 21:54.55 | mvanbaak | the OP reports it works on 1.4 |
| 21:55.11 | mvanbaak | I can prove it trashes incoming calls in trunk |
| 21:55.29 | mvanbaak | but dont have time this week to convert my iax testbed to 1.4 |
| 21:56.31 | Corydon76-dig | mvanbaak: I'm not eager to commit that issue |
| 21:57.25 | mvanbaak | me neither |
| 21:57.26 | Corydon76-dig | He's just going to have to deal with the fact that his iax client retransmits the NEW too fast |
| 21:57.41 | mvanbaak | that's my idea as well |
| 21:57.44 | ZX81 | wow, the longer I leave my stovetop coffee maker, the stronger it gets, I've managed to get three cups into one now :D |
| 21:57.58 | mvanbaak | cant reproduce on my trunk and 1.6 setup |
| 21:58.09 | mvanbaak | and my 1.0 and 1.2 boxen dont have it neither |
| 21:58.20 | mvanbaak | and I use all those in a mixed env |
| 21:58.28 | mvanbaak | and my ITSP is using asterisk 1.4 |
| 21:58.37 | mvanbaak | it's an IAX2 ITSP |
| 21:58.40 | *** join/#asterisk-dev codefreeze-lap (n=murf@216.166.159.235) |
| 21:58.40 | *** mode/#asterisk-dev [+o codefreeze-lap] by ChanServ |
| 21:58.43 | mvanbaak | so I think the problem is his |
| 21:58.49 | mvanbaak | just my 2 cents |
| 21:58.52 | Qwell | ZX81: youtube search 'how to make coffee' |
| 21:59.00 | Corydon76-dig | seanbright: ping |
| 21:59.01 | ZX81 | :D |
| 21:59.09 | Qwell | http://youtube.com/watch?v=ELZSeiTpOUw |
| 21:59.11 | Qwell | it's quite funny |
| 21:59.22 | ZX81 | kk |
| 21:59.29 | mvanbaak | s/coffee/money/ |
| 21:59.34 | Qwell | it gets pretty absurd, but it's funny |
| 22:01.55 | ZX81 | wishes there was a way to download *no* sounds for asterisk with a configure switch |
| 22:03.20 | mvanbaak | amen ! |
| 22:03.38 | mvanbaak | ./configure --enable-dev-mode --no-sounds |
| 22:03.53 | mvanbaak | wait |
| 22:04.02 | kpfleming | just run the individual makefile targets instead of 'make install' |
| 22:04.05 | russellb | cat menuselect.makeopts | grep -v SOUNDS > tmp && mv tmp menuselect.makeopts |
| 22:04.06 | mvanbaak | you can go into 'make menuselect' and simply deselect them |
| 22:04.10 | kpfleming | you don't have to run the sound file install |
| 22:04.11 | Corydon76-dig | --disable-sounds... not to be confused with --disable-sound |
| 22:04.20 | Qwell | it's easier than all of that |
| 22:06.14 | mvanbaak | yup |
| 22:06.31 | mvanbaak | echo "127.0.0.2 downloads.digium.com" >> /etc/hosts |
| 22:06.39 | ZX81 | lol @ making coffee! |
| 22:06.53 | Qwell | echo "MENUSELECT_CORE_SOUNDS=-CORE-SOUNDS-EN-GSM" > ~/.asterisk.makeopts |
| 22:06.56 | Qwell | make install |
| 22:06.59 | Qwell | done and done |
| 22:07.05 | ZX81 | ah cool |
| 22:07.14 | Qwell | (do the same for moh) |
| 22:07.22 | mvanbaak | and extra |
| 22:07.29 | Qwell | MENUSELECT_MOH=-MOH-FREEPLAY-WAV |
| 22:07.33 | Qwell | extra has nothing by default |
| 22:07.40 | mvanbaak | really ? |
| 22:07.41 | mvanbaak | ah |
| 22:07.57 | mvanbaak | I must have selected it somewhere in the past then |
| 22:08.00 | mvanbaak | cant remember |
| 22:08.10 | Qwell | MENUSELECT_CORE_SOUNDS=-CORE-SOUNDS-EN-GSM |
| 22:08.10 | Qwell | MENUSELECT_MOH=-MOH-FREEPLAY-WAV |
| 22:08.10 | russellb | Qwell: you should document that in the README or something |
| 22:08.19 | russellb | Qwell: i think it already covers building asterisk to some degree |
| 22:08.20 | mvanbaak | must be for nancy, so she has them all to do the dutch translation |
| 22:08.21 | Qwell | so, put that into ~/.asterisk.makeopts, and you're golden |
| 22:09.09 | Qwell | russellb: I don't even know where would be appropriate |
| 22:10.06 | mvanbaak | README.nosounds |
| 22:10.14 | Qwell | it applies to more than just sounds |
| 22:10.56 | mvanbaak | README.no_sounds_andor_moh_download_mkay_thanks_your-welcome_now_be_happy |
| 22:11.49 | mvanbaak | or doc/tex/install-without-sounds-moh.tex |
| 22:12.10 | putnopvut | README.i_want_to_disable_sounds_but_im_2_1337_4_menuselect |
| 22:12.25 | mvanbaak | putnopvut: or that :) |
| 22:13.39 | Corydon76-dig | Anybody else read Totaro's -users suggestion on dahdi? |
| 22:13.40 | mvanbaak | or some obscure form of: I dont have and dont want to have the dependecies to run make menuselect so tell me how to disable the downloading and installing of the moh and sounds tarballs |
| 22:14.03 | *** join/#asterisk-dev obnauticus (n=obnautic@c-67-160-181-107.hsd1.wa.comcast.net) |
| 22:14.33 | mvanbaak | to be honest his mail ended up in my /dev/null |
| 22:14.52 | Corydon76-dig | Clearly, he's a user and not a developer |
| 22:15.08 | mvanbaak | if ( /^From:*........ ) |
| 22:15.10 | mvanbaak | { |
| 22:15.15 | mvanbaak | <PROTECTED> |
| 22:15.16 | mvanbaak | } |
| 22:15.22 | mvanbaak | I have that on his email address |
| 22:15.52 | mvanbaak | after the last three threads where he was being non-constructive and an *ss |
| 22:15.57 | Corydon76-dig | Occasionally, he has good content |
| 22:16.03 | mvanbaak | ah |
| 22:16.11 | mvanbaak | then I'll remove that filter |
| 22:16.24 | Corydon76-dig | This last time, though, wasn't one of them |
| 22:16.26 | Qwell | Corydon76-dig: yeah... |
| 22:16.28 | outtolunc | when he isn't saying 'dump iax, use sip' <G> |
| 22:16.29 | Qwell | diffs are hard |
| 22:16.51 | mvanbaak | outtolunc: that is one of his main things yeah |
| 22:18.12 | mvanbaak | I wonder if sf.net svn will be read-write again tomorrow |
| 22:18.22 | mvanbaak | it has been read-only for the whole day |
| 22:18.41 | mvanbaak | they are migrating to a new datacenter with a new setup |
| 22:18.55 | mvanbaak | I hope all goes well. they made the move to svn 1.5 |
| 22:19.05 | Qwell | so early? |
| 22:19.06 | Qwell | ouch |
| 22:19.25 | mvanbaak | I can remember someone here trying 1.5 on the digium svn server and reverting to 1.4 because it was a mess |
| 22:19.29 | mvanbaak | yup |
| 22:19.42 | mvanbaak | I just did a full rsync of our stuff there |
| 22:19.44 | russellb | i see commits for another project in sourceforge from today |
| 22:19.44 | mvanbaak | just in case |
| 22:20.06 | mvanbaak | russellb: yeah. they started noon EDT I think |
| 22:20.07 | russellb | last commit about 45 minutes ago |
| 22:22.02 | Qwell | r131491 scares me |
| 22:22.10 | mvanbaak | ah |
| 22:22.13 | mvanbaak | scheduled for 2008-07-16 starting 04:00 Pacific for 12 hours during which the Subversion service will be in read-only mode. |
| 22:22.24 | Qwell | mvanbaak: that's about 40 minutes |
| 22:22.24 | russellb | Qwell: that was totally wrong |
| 22:22.33 | russellb | Qwell: plenty of other code used strcmp() (as was the intention) |
| 22:22.46 | russellb | so anything that "worked" because of it, would have half-worked |
| 22:22.50 | Qwell | ok |
| 22:22.57 | mvanbaak | anyways |
| 22:23.02 | mvanbaak | time to get some sleep |
| 22:23.11 | russellb | g'night! |
| 22:23.12 | mvanbaak | Thu Jul 17 00:23:11 CEST 2008 |
| 22:23.18 | mvanbaak | way past midnight |
| 22:23.29 | mvanbaak | I have to work less |
| 22:23.57 | mvanbaak | 6AM - 11:30PM is normal for me nowedays :( |
| 22:24.32 | mvanbaak | latero, and thanks for all the feedback and time spent on the xmldocs stuff |
| 22:31.17 | ZX81 | Corydon76-dig: new revision looks like it's holding up |
| 23:23.00 | *** join/#asterisk-dev RoyK (n=roy@ti211210a080-3097.bb.online.no) |
| 23:23.26 | *** join/#asterisk-dev RoyK (n=roy@ti211210a080-3097.bb.online.no) |
| 23:31.45 | netstv | quit |
| 23:43.21 | *** join/#asterisk-dev russellb (n=russell@asterisk/developer-and-stable-maintainer/drumkilla) |
| 23:43.22 | *** mode/#asterisk-dev [+o russellb] by ChanServ |
| 23:44.54 | *** join/#asterisk-dev Iamnacho (i=Iamnacho@ip68-103-153-140.ks.ok.cox.net) |