| 00:09.11 | *** join/#asterisk-dev jolucara (n=jlcaiced@186.83.70.58) |
| 00:11.13 | *** part/#asterisk-dev jolucara (n=jlcaiced@186.83.70.58) |
| 00:38.13 | *** join/#asterisk-dev eliel (n=eliels@120-17-235-201.fibertel.com.ar) |
| 00:38.13 | *** mode/#asterisk-dev [+o eliel] by ChanServ |
| 01:44.40 | *** join/#asterisk-dev kamanashisroy (n=kamanash@119.30.36.8) |
| 02:12.16 | *** join/#asterisk-dev kerx (n=root@adsl-69-105-171-127.dsl.irvnca.pacbell.net) |
| 02:12.52 | neuro9 | hey are applications run before or after the priority is incremented in the channel run loop |
| 02:19.29 | *** join/#asterisk-dev Deeewayne (n=dwayne@c-76-29-245-9.hsd1.al.comcast.net) |
| 02:19.29 | *** mode/#asterisk-dev [+o Deeewayne] by ChanServ |
| 02:23.11 | neuro9 | I am trying to write a Halt application, that halts the channel from executing until an AMI redirect or a Hangup |
| 03:08.54 | Corydon76-dig | neuro9: Just use AsyncAGI |
| 03:18.34 | neuro9 | is AsyncAGI included in the default install of 1.6? |
| 03:20.32 | neuro9 | haha, nevermind. found it. yeah thats exactly what i was wanting to do |
| 03:20.39 | neuro9 | kudos to Corydon |
| 03:37.35 | neuro9 | wait.. asyncagi is new to 1.6 right? |
| 03:37.43 | neuro9 | i am getting conflicted documentation |
| 03:43.10 | neuro9 | the patch is failing on certain chunks in 1.6 |
| 03:45.05 | snuff-work | mm async agi should be listed in changes file as to which version it came with.. |
| 03:45.11 | snuff-work | of 1.6.x |
| 03:45.41 | neuro9 | okay |
| 03:46.48 | snuff-work | async was most likely added in 1.6.2 |
| 03:46.58 | snuff-work | going from the CHANGES file |
| 03:48.00 | neuro9 | 1.6.2 is still in beta2 correct |
| 03:48.08 | neuro9 | just making sure im not missing something |
| 03:48.18 | snuff-work | last time i remember.. yes |
| 03:48.40 | leifmadsen | beta2 yes |
| 03:48.41 | neuro9 | yea i see asyncagi in beta2 |
| 03:48.43 | leifmadsen | released this morning |
| 03:48.46 | leifmadsen | created on friday |
| 03:48.49 | neuro9 | ha |
| 03:48.51 | neuro9 | perfect timing |
| 03:49.40 | snuff-work | looks @ unloved ao2 conversion and ponders what to do about it |
| 04:01.57 | neuro9 | hmm |
| 04:02.11 | neuro9 | asyncagi seems to crash asterisk when i hang up the channel |
| 04:02.58 | neuro9 | any ideas? |
| 04:18.10 | *** join/#asterisk-dev ctooley (n=ctooley@65.99.197.74) |
| 04:18.10 | *** join/#asterisk-dev angler (n=angler@pdpc/sponsor/digium/angler) |
| 04:18.10 | *** join/#asterisk-dev wedhorn (n=nnnnnnnw@123-243-209-34.static.tpgi.com.au) [NETSPLIT VICTIM] |
| 04:18.11 | *** join/#asterisk-dev dwayne (n=dwayne@c-76-29-245-9.hsd1.al.comcast.net) |
| 04:18.11 | *** join/#asterisk-dev xpot (n=james@70.91.210.233) |
| 04:18.11 | *** join/#asterisk-dev festr_ (n=festr@ns.hiro.cz) [NETSPLIT VICTIM] |
| 04:18.11 | *** mode/#asterisk-dev [+o ctooley] by irc.freenode.net |
| 04:18.56 | *** join/#asterisk-dev Qwell (i=north@pdpc/sponsor/digium/Qwell) |
| 04:18.56 | *** join/#asterisk-dev jpeeler (n=jpeeler@asterisk/digium-software-dev/jpeeler) |
| 04:18.56 | *** join/#asterisk-dev The_Boy_Wonder (n=davidvos@asterisk/batman-developer/dvossel) |
| 04:18.56 | *** join/#asterisk-dev janinge (i=j@ninge.net) |
| 04:18.56 | *** join/#asterisk-dev JT (n=j@unaffiliated/jt) [NETSPLIT VICTIM] |
| 04:18.56 | *** join/#asterisk-dev file (n=file@asterisk/developer-and-muffin-lover/file) |
| 04:18.56 | *** join/#asterisk-dev russellb (n=russellb@asterisk/digium-open-source-team-lead/russellb) |
| 04:18.56 | *** mode/#asterisk-dev [+oooo Qwell jpeeler file russellb] by irc.freenode.net |
| 04:18.56 | *** join/#asterisk-dev JunK-Y (n=junky@modemcable206.69-20-96.mc.videotron.ca) |
| 04:18.56 | *** join/#asterisk-dev sergee (n=serg@voip1.west-call.com) [NETSPLIT VICTIM] |
| 04:19.21 | *** join/#asterisk-dev jcollie (n=jcollie@fedora/jcollie) [NETSPLIT VICTIM] |
| 04:19.21 | *** join/#asterisk-dev Daviey (n=Daviey@ubuntu/member/pdpc.gold.Daviey) [NETSPLIT VICTIM] |
| 04:19.21 | *** join/#asterisk-dev Corydon76-dig (i=six@pdpc/supporter/bronze/Corydon76-home) |
| 04:19.21 | *** join/#asterisk-dev Marquis42 (n=bfhbmw0@65-127-126-34.dia.static.qwest.net) |
| 04:19.21 | *** join/#asterisk-dev snuff-home (n=snuffy@203-219-29-182-bri-ts6-2600.tpgi.com.au) [NETSPLIT VICTIM] |
| 04:19.21 | *** join/#asterisk-dev ChanServ (ChanServ@services.) |
| 04:19.21 | *** mode/#asterisk-dev [+ooo Corydon76-dig snuff-home ChanServ] by irc.freenode.net |
| 04:24.54 | Juggie | is using a macro inside agi reliable? |
| 05:07.43 | mvanbaak | mornin all |
| 05:22.48 | neuro9 | hey |
| 05:23.02 | neuro9 | i need some help patching 1.6.0 with the asyncagi patch |
| 05:33.43 | mvanbaak | neuro9: cant you run 1.6.2 ? |
| 05:36.16 | mvanbaak | anywayz, I'm off |
| 05:36.21 | mvanbaak | latero al |
| 07:12.51 | *** join/#asterisk-dev ck_28 (n=CK@212.98.141.199) |
| 07:17.01 | *** join/#asterisk-dev tamiel (n=tamiel@213.30.183.226) |
| 08:49.26 | *** join/#asterisk-dev michael-i (n=michael-@141.41.40.153) |
| 08:54.08 | *** join/#asterisk-dev ck_28 (n=CK@212.98.141.199) |
| 08:54.42 | ck_28 | hi i am using hylfax as a fax server with asterisk ,while i am sending fax |
| 08:54.57 | ck_28 | i am recieving at sip debug SIP/2.0 488 Not acceptable here why ? |
| 08:59.06 | tzafrir_laptop | ck_28, err.. maybe because this question is acceptable in #asterisk? |
| 08:59.24 | tzafrir_laptop | ;-) |
| 10:28.57 | *** join/#asterisk-dev wildzero-cw (n=Kristija@213.216.10.219) |
| 10:34.37 | wildzero-cw | tzafiri_laptop: hi, i made some small success, if you fake the value for pri->q921_state with Q921_LINK_CONNECTION_ESTABLISHED in q921_transmit_iframe/q921.c then on the receiving side you get some (error) log. errors, but some data start to moving :) |
| 10:35.45 | wildzero-cw | tzafrir_laptop: ^ |
| 10:37.15 | tzafrir_laptop | wildzero-cw, where should q921_state have been set? |
| 10:38.23 | wildzero-cw | in pri_event *q921_dchannel_up, |
| 10:39.30 | wildzero-cw | pri_event *q921_dchannel_up is called when d-chan is going up and pri->q921_state is set, but when you start a call it's 0 again |
| 10:47.35 | tzafrir_laptop | It seems you get trace messages (pri, level 2) before every change to q921_state |
| 11:34.01 | *** join/#asterisk-dev kpfleming (n=kpflemin@asterisk/digium-director-of-software-tech/kpfleming) |
| 11:34.01 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 11:49.59 | *** join/#asterisk-dev caio1982 (i=caio1982@CAcert-br/caio1982) |
| 11:57.31 | *** join/#asterisk-dev eliel (n=eliels@200.61.172.61) |
| 11:57.31 | *** mode/#asterisk-dev [+o eliel] by ChanServ |
| 11:58.14 | wildzero-cw | tzafrir_laptop: on the receiving side, if i comment out the return NULL in q921_receive_qualified after: if (pri->q921_state != Q921_LINK_CONNECTION_ESTABLISHED) {pri_error(pri, "!! 1 Got I-frame while link state %d\n", pri->q921_state); i can call from NT ptmp -> TE ptmp. it's a wild testing hack, but basically a call is possible now also outgoing |
| 11:58.29 | *** join/#asterisk-dev leifmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 11:58.29 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 12:03.05 | wildzero-cw | so it seems, to get it work with real isdn devices, the change from Q921_TEI_ASSIGNED, to Q921_LINK_CONNECTION_ESTABLISHED is missing |
| 12:03.27 | leifmadsen | is there a bug opened for that? |
| 12:03.57 | wildzero-cw | for this nt ptmp issue ? |
| 12:06.48 | kpfleming | no, because we don't claim to support NT PTMP at all right now |
| 12:10.42 | wildzero-cw | it's not a bug, it's a new feature: http://bugs.digium.com/view.php?id=15048 |
| 12:16.30 | leifmadsen | aha, sorry, I came into the conversation way too late |
| 12:16.59 | leifmadsen | and I'm trying to train myself to say "issue" not "bug", but I slipped because I just woke up |
| 12:45.07 | *** join/#asterisk-dev qdk (n=qdk@81.7.168.130) |
| 12:50.46 | *** join/#asterisk-dev malcolmd (n=malcolmd@pdpc/sponsor/digium/malcolmd) |
| 12:50.46 | *** mode/#asterisk-dev [+o malcolmd] by ChanServ |
| 13:11.09 | *** join/#asterisk-dev anonymouz666 (n=anonymou@189.24.138.206) |
| 13:33.14 | *** join/#asterisk-dev corramor (n=corramor@nat/digium/x-a308885e77af9b32) |
| 13:58.39 | *** join/#asterisk-dev outtolunc (n=me@c-71-198-197-201.hsd1.ca.comcast.net) |
| 14:06.42 | eliel | kpfleming: const char * const makes the variable moooore contant than just "const char *" ? what is the rule there? |
| 14:07.12 | tzanger | it makes sure it's good and constant. :-) |
| 14:07.13 | kpfleming | it makes the pointer const as well |
| 14:07.21 | kpfleming | you can't change the pointer or the stuff it points to |
| 14:07.29 | tzanger | interesting |
| 14:07.32 | kpfleming | so it will be put into read-only memory and could be more optimized by the compiler |
| 14:07.46 | tzanger | so const char *foo = "blah" just makes sure "blah" can never change, but foo can be pointed elsewhere? |
| 14:08.02 | tzanger | (to another const array) |
| 14:08.10 | eliel | kpfleming: uou, you are the gcc master, amen! |
| 14:08.14 | eliel | thanks |
| 14:08.31 | seanbright | helps if you read it right to left |
| 14:09.07 | tzanger | that doesn't help me at all |
| 14:09.17 | tzanger | I see const * (right to left) ok, got that |
| 14:09.22 | tzanger | but then I see char const |
| 14:09.44 | seanbright | const char * const == const * to a const char |
| 14:10.25 | kpfleming | yes, in the example above foo could be changed to point to any other 'const char' |
| 14:10.34 | seanbright | http://en.wikipedia.org/wiki/Const-correctness#Pointers_and_references |
| 14:10.57 | kpfleming | the 'canonical' way to right that is 'char const * const' |
| 14:11.03 | kpfleming | so then reading right-to-left works |
| 14:11.11 | kpfleming | but most people put const before the raw type |
| 14:11.39 | tzanger | this is an interesting lesson |
| 14:11.47 | tzanger | thank you for taking the time to explain it to us |
| 14:11.54 | seanbright | just never use const |
| 14:11.55 | atis_work | ooh, damn pointers.. how about char * const |
| 14:11.57 | seanbright | it's evil |
| 14:11.58 | seanbright | heh |
| 14:12.04 | tzanger | I've been programming in C for many, many years and there are still little nuances that I find I never knew about |
| 14:12.21 | seanbright | char * const is a pointer that can't be changed, but what it points to can |
| 14:12.48 | kpfleming | eliel: this is not gcc, it's just C :-) |
| 14:13.03 | Corydon76-dig | tzanger: you mean like declaring a variable static within a function? |
| 14:13.20 | seanbright | and it can ALL be made worthless just by adding: |
| 14:13.22 | seanbright | (char *) |
| 14:13.24 | seanbright | heh |
| 14:13.43 | tzanger | Corydon76-dig: nah I do that all the time (when I need it) |
| 14:13.44 | eliel | kpfleming: you talked about optimization, that is gcc :) |
| 14:14.21 | tzanger | static int first = 1 type of thing |
| 14:14.32 | Corydon76-dig | tzanger: I'd love a simple convention for declaring persistent thread-specific variables... |
| 14:14.50 | tzanger | Corydon76-dig: that would be nice |
| 14:14.53 | kpfleming | there is one in gcc |
| 14:15.00 | kpfleming | unfortunately it sucks, because they can't be pointers |
| 14:15.18 | kpfleming | well, they can be pointers if you don't care about freeing what they point to :-) |
| 14:15.21 | *** join/#asterisk-dev Victor_Yure (n=victor@unaffiliated/victoryure/x-837844) |
| 14:15.42 | Corydon76-dig | kpfleming: heh |
| 14:16.33 | kpfleming | there is one place in there where we use 'char const * const *'... more fun stuff |
| 14:16.59 | tzanger | wtf |
| 14:17.07 | tzanger | I would curl up in a ball I think :-) |
| 14:17.31 | Corydon76-dig | tzanger: the option is still available to you. ;-) |
| 14:17.59 | tzanger | haha |
| 14:18.01 | seanbright | kpfleming: cli code yeah? |
| 14:18.56 | seanbright | oh, no. |
| 14:19.08 | seanbright | char * const cmda[AST_MAX_CMD_LEN] |
| 14:19.10 | seanbright | but that is still fun |
| 14:19.29 | eliel | "char const * const *" you loose the rule of thumb.... :( |
| 14:21.38 | kpfleming | seanbright: yes, i've got a another big patch in the works that will improve const usage in the cli code |
| 14:21.43 | kpfleming | it touches a lot of places |
| 14:22.09 | seanbright | what are you changing in the cli? |
| 14:22.12 | seanbright | just constness? |
| 14:22.23 | seanbright | (if i can inquire, that is) |
| 14:22.31 | kpfleming | yes |
| 14:22.35 | kpfleming | just const-ness |
| 14:22.51 | seanbright | cool. |
| 14:22.54 | kpfleming | of course you can inquire... this is open source :-) |
| 14:23.13 | kpfleming | time to head in to the office... bbiab |
| 14:23.28 | seanbright | well it might have been part of a super secret project |
| 14:23.56 | seanbright | like take-over-the-world.diff |
| 14:24.00 | seanbright | :) |
| 14:24.01 | outtolunc | no 'const' it can change <G> |
| 14:40.40 | russellb | we should put "const const" to tell the compiler we really mean it |
| 14:41.17 | *** join/#asterisk-dev Deeewayne (n=dwayne@75.76.254.162) |
| 14:41.17 | *** mode/#asterisk-dev [+o Deeewayne] by ChanServ |
| 14:45.57 | eliel | getting a crash while closing a manager session in trunk |
| 14:46.19 | file | M14974 |
| 14:46.21 | MuffinMan | [feedback] [Asterisk] Core/General 0014974: [patch] erros messages astobj2.c INTERNAL_OBJ reported by pj (Karma: +9.25) http://bugs.digium.com/view.php?id=14974 |
| 14:46.25 | file | eliel: ...that? |
| 14:46.35 | eliel | let me check |
| 14:48.52 | eliel | file: it looks "similar" |
| 14:49.12 | eliel | getting the crash when calling fclose(session->f) on line 922 of manager.c |
| 14:50.01 | eliel | session is valid, and session->f looks valid too, maybe we are trying to close an already closed file stream... taking a look at the code.. |
| 14:50.33 | *** join/#asterisk-dev moy (n=moy@74.12.124.89) |
| 14:52.21 | eliel | ok, i have a fix... |
| 14:54.01 | *** join/#asterisk-dev anthm (n=anthm@freeswitch/developer/anthm) |
| 14:56.46 | eliel | file: i have uploaded a patch. |
| 14:57.07 | eliel | but i think that report is about many issues... |
| 14:57.44 | *** join/#asterisk-dev kpfleming (n=kpflemin@asterisk/digium-director-of-software-tech/kpfleming) |
| 14:57.44 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 15:02.44 | Deeewayne | eliel, I also think that report is about many issues. My involvement in that issue is the same as yours. |
| 15:03.11 | eliel | Deeewayne: could you try the uploaded patch??? |
| 15:03.47 | Deeewayne | I made that same change last week and it did not work, but for completeness, I did just try your patch and confirmed that it does not fix the issue. I'll update the issue w/ a comment |
| 15:04.05 | eliel | huh? |
| 15:05.06 | eliel | Deeewayne: you are logging into the manager session and logging out |
| 15:06.40 | Deeewayne | yes |
| 15:06.52 | eliel | could yo upload a backtrace?? |
| 15:06.53 | Deeewayne | did that change work for you ? |
| 15:07.05 | eliel | yes, it id |
| 15:07.11 | eliel | s/id/did |
| 15:07.19 | Deeewayne | hrm. yes, I'll upload a backtrace |
| 15:07.53 | Corydon76-dig | eliel: it's crashing in astobj2, so a backtrace isn't all that helpful |
| 15:08.47 | eliel | Corydon76-dig: ok, I will create a new issue, my problem was another... in my code it was crashing when doing an fclose... |
| 15:13.23 | Corydon76-dig | eliel: orly? |
| 15:13.34 | Corydon76-dig | was the fclose on a NULL? |
| 15:14.38 | eliel | Corydon76-dig: nop, it was on a possible address |
| 15:15.26 | eliel | that is why the check for null didn't work... what i notice is that in some places it was being put to null after the fclose, but in some other places it wasn't... |
| 15:15.45 | Corydon76-dig | Ah, okay |
| 15:16.45 | *** join/#asterisk-dev atis_work (n=atis_wor@193.238.212.171) |
| 15:18.38 | Deeewayne | eliel, the backtrace is exactly the same as the one I uploaded last week |
| 15:19.24 | eliel | Deeewayne: could you do a 'bt full' instead of a 'bt' |
| 15:21.15 | seanbright | memset in build_mansession is redundant |
| 15:21.24 | seanbright | in case anyone is actively working on that code :) |
| 15:21.48 | russellb | seanbright: you have commit :-p |
| 15:22.22 | seanbright | touche |
| 15:22.30 | Corydon76-dig | has seanbright committed |
| 15:22.48 | *** join/#asterisk-dev bkruse (n=bkruse@76.73.154.120) |
| 15:22.49 | *** mode/#asterisk-dev [+o bkruse] by ChanServ |
| 15:23.28 | seanbright | Deeewayne: how about with 'manager set debug on'? |
| 15:23.34 | seanbright | should dump ao2 stuff |
| 15:25.33 | Deeewayne | seanbright, for you.... anything. :-) |
| 15:28.12 | eliel | M0015088 |
| 15:28.14 | MuffinMan | [new] [Asterisk] Core/ManagerInterface 0015088: [patch] Asterisk crash when logging out from a manager session. reported by eliel (Karma: +184.50) http://bugs.digium.com/view.php?id=0015088 |
| 15:29.00 | eliel | I have uploaded the backtrace, it looks similar as the one uploaded in 14974, but the uploaded patch fix the issue in my case |
| 15:32.42 | Deeewayne | eliel, seanbright: full backtraces uploaded |
| 15:35.32 | eliel | Deeewayne: our backtraces look similiar, mine has additional simbols, but your code is crashing when calling free_session where the fclose occurs, could you try the patch in 15088 and if it crashes upload the backtrace? (a pastebin is enough) |
| 15:38.43 | Deeewayne | sure. I need a couple minutes |
| 15:44.26 | *** join/#asterisk-dev siera08 (n=chatzill@218.207.141.90) |
| 15:46.56 | kpfleming | seanbright: want to test something for me? |
| 15:53.03 | *** join/#asterisk-dev marv[work] (n=timr@router.asteriasgi.com) |
| 16:09.20 | seanbright | kpfleming: sure |
| 16:30.11 | mvanbaak | sup? |
| 16:30.47 | jsmith | mvanbaak: My weight! |
| 16:31.01 | mvanbaak | ;) |
| 16:42.53 | *** join/#asterisk-dev lasko (n=lasko@70.102.15.210) |
| 16:43.17 | *** part/#asterisk-dev lasko (n=lasko@70.102.15.210) |
| 16:49.13 | Deeewayne | eliel, http://pastebin.com/d833a9c4 |
| 16:50.23 | eliel | Deeewayne: thanks |
| 16:52.26 | eliel | in ao2 after calling the destructor callback it will free() the object? or it is up to the callback to do so? |
| 16:52.32 | mnicholson | Deeewayne, eliel, check the bug report, I know what is causing the crash |
| 16:52.50 | file | eliel: it will free the object |
| 16:52.58 | eliel | file: thanks |
| 16:53.20 | eliel | mnicholson: yes, i am checking the code based on your comments |
| 16:58.23 | mnicholson | eilel, to detect this i put debug debug messages in session_destructor and in free_session and got the following result: http://pastebin.com/d320e802e |
| 16:59.13 | eliel | mnicholson: i think i have found a fix.. i will post it as soon as my VM finish compiling :) |
| 17:01.19 | eliel | M15088 |
| 17:01.21 | MuffinMan | [new] [Asterisk] Core/ManagerInterface 0015088: [patch] Asterisk crash when logging out from a manager session. reported by eliel (Karma: +184.50) http://bugs.digium.com/view.php?id=15088 |
| 17:01.35 | eliel | Deeewayne: ^^ Could you test this patch? |
| 17:02.08 | kpfleming | seanbright: checkout something (anything) from svn.digium.com, then use 'svn switch --relocate' to edit the URL to svn.asterisk.org instead of svn.digium.com, and see if 'svn update' still works |
| 17:02.30 | eliel | new repository? |
| 17:03.50 | kpfleming | new name |
| 17:03.56 | kpfleming | currently just a DNS alias |
| 17:06.52 | seanbright | sean@elixer:~/dev/thirdparty$ svn switch --relocate http://svn.digium.com/svn/thirdparty http://svn.asterisk.org/svn/thirdparty |
| 17:06.55 | seanbright | sean@elixer:~/dev/thirdparty$ svn update |
| 17:06.57 | seanbright | At revision 109. |
| 17:08.49 | *** join/#asterisk-dev jetsnoc (n=brian@root.pmt.org) |
| 17:08.56 | kpfleming | seanbright: thanks! |
| 17:09.01 | seanbright | no sweat |
| 17:09.23 | kpfleming | will have to try again after i reconfigure svn.digium.com to send a 301 redirect instead of being an alias |
| 17:09.33 | mnicholson | eliel, your patch seems to work, but i think the memory is still getting freed twice |
| 17:10.23 | eliel | mnicholson: the memory is being freed when calling ao2_unlink(), and it was being free twice because free_session was calling ast_free inside it.. |
| 17:11.02 | eliel | also, we were closing twice the file stream |
| 17:11.20 | kpfleming | you never, ever, ever call ast_free on an ao2 object |
| 17:11.28 | mnicholson | eliel, i am looking at the wrong code |
| 17:11.42 | mnicholson | eliel, there are still issues with this patch |
| 17:11.51 | mnicholson | eliel, it fixes the crash though |
| 17:12.41 | eliel | mnicholson: there are still issues with this path or with the code? |
| 17:12.56 | mnicholson | eliel, free_session should just call unref_mansession() |
| 17:15.16 | mnicholson | does ao2_unlink() decrease the reference count for a particular item twice? |
| 17:16.01 | *** join/#asterisk-dev atis_work (n=atis_wor@193.238.212.171) |
| 17:16.16 | kpfleming | no |
| 17:16.18 | kpfleming | once |
| 17:16.59 | eliel | mnicholson: the refcount is 1 before calling ao2_unlink (though)... let me check that |
| 17:17.22 | kpfleming | do you have REF_DEBUG enabled for ao2 objects? that will help you track reference counts |
| 17:20.21 | eliel | mnicholson: the session_destructor (ao2 callback) is being called when logging out, so, i think i am right saying that the refcount == 1 before calling ao2_unlink |
| 17:20.26 | mnicholson | this is kinda messy. There is session_destroy, destroy_session, and session_destructor. session_destroy an destroy_session can be merged into one function |
| 17:20.43 | eliel | yes!!! i notice |
| 17:21.12 | mnicholson | there is also free_session, which should be merged with session_destructor |
| 17:21.31 | eliel | yeaph, I am working on it |
| 17:21.44 | eliel | also there are many bogus code based on the ao2 warning messages... |
| 17:22.47 | russellb | btw, refcount _better_ be at least 2 before calling ao2_unlink() |
| 17:22.57 | russellb | the caller should have a reference, and the container should have a reference |
| 17:23.45 | mnicholson | russellb, that is what I was thinking |
| 17:24.33 | russellb | otherwise, it's broken :-) |
| 17:27.21 | eliel | mnicholson: the problem is that build_mansession is doing a refcount-- before returning... |
| 17:28.03 | Corydon76-dig | So how 'bout that mansession_session_session_session_session object? |
| 17:28.13 | mnicholson | eliel, is that wrong? |
| 17:28.15 | *** join/#asterisk-dev Iamnach0 (i=Iamnacho@ip68-103-153-140.ks.ok.cox.net) |
| 17:28.30 | putnopvut | mnicholson: yes, that is wrong. |
| 17:28.32 | mnicholson | eliel, ahh yes that is wrong |
| 17:28.35 | kpfleming | is it returning a pointer to the session it created |
| 17:28.54 | eliel | mnicholson: I think so, we have a refcount = 1 when creating the object and refcount = 2 when linking we should return it with refcount==2 |
| 17:29.02 | mnicholson | kpfleming, yes it is, and then it does ao2_link, and then it unrefs |
| 17:29.23 | eliel | Corydon76-dig: that object is being freed with destroy_mansession_session that then calls session_session_destroy |
| 17:29.43 | kpfleming | yes, that is all correct |
| 17:29.46 | putnopvut | mansession_session_destroy_session_destructor |
| 17:29.56 | putnopvut | yo |
| 17:29.58 | kpfleming | if it is returning a pointer to the object, it just maintain the reference that pointer represents |
| 17:30.08 | kpfleming | its caller then becomes responsible for cleaning up that reference |
| 17:32.05 | mnicholson | eliel, there are also a bunch of places where session->f is closed, these should probably be consolidated in session_destructor |
| 17:32.33 | eliel | mnicholson: ok |
| 17:33.39 | eliel | also look at line ~ 4245 |
| 17:33.43 | eliel | ugly! |
| 17:34.09 | eliel | we are checking for session != NULL but before we have already check for session->f |
| 17:34.11 | eliel | huh.. |
| 17:35.28 | mnicholson | eliel, that should probably just call session_destroy(session) if blastaway is set |
| 17:35.51 | mnicholson | maybe |
| 17:36.27 | mnicholson | eliel, but yeah, that code looks pretty wrong |
| 17:36.45 | eliel | i am trying to understand if it is possible that we need there to close the file stream but not calling the session_destroy() |
| 17:37.11 | seanbright | remove the memset in build_mansession while you're working in there |
| 17:37.15 | seanbright | hehe |
| 17:37.36 | eliel | seanbright: that was your job! |
| 17:37.42 | eliel | seanbright: :-) |
| 17:37.43 | seanbright | you guys are working in there |
| 17:37.47 | seanbright | just makes sense |
| 17:37.54 | eliel | seanbright: no problem! |
| 17:45.25 | eliel | for some reason this is just wrong... why mansession_session has an inuse?? we are using that as a reference counter and using ao2 for the container... |
| 17:45.58 | mnicholson | this whole thing is like one big practical joke |
| 17:46.07 | mnicholson | mansession_session should give it away |
| 17:46.57 | mnicholson | eliel, in use appears to be used for http sessions |
| 17:47.31 | eliel | yes, but if refcounting with ao2 is being used as expected we could avoid that |
| 17:47.42 | mnicholson | yes, probably |
| 17:48.21 | mnicholson | eliel, in fact there is a check_manager_session_inuse() function |
| 17:48.42 | mnicholson | eliel, it is somewhat unrelated though |
| 17:49.48 | mnicholson | eliel, see purge_session() |
| 17:55.14 | eliel | mnicholson: purge_sessions is also wrong.. you should first ao2_lock()/ao2_unlock and then ao2_ref(, -1)! |
| 17:56.00 | eliel | it is doing a ao2_ref(-1) and then locking... this is because it is not using refcounting at all.. he knows the session is there based on the inuse... |
| 18:03.26 | kpfleming | ok, as of about 90 seconds ago, bugs.digium.com officially became issues.asterisk.org and is now SSL-enabled for all connections |
| 18:03.35 | kpfleming | a more public announcement will be made later today |
| 18:03.47 | kpfleming | all existing links should continue to work via redirects |
| 18:04.08 | *** join/#asterisk-dev MuffinMan (n=muffinma@asterisk/issue-tracker-bot/muffinman) |
| 18:04.27 | file | M1234 |
| 18:04.33 | MuffinMan | Failed to retrieve issue page for 1234. Try again later. |
| 18:04.45 | seanbright | uh oh |
| 18:05.31 | Qwell | M802.11b |
| 18:05.41 | Juggie | M14811 |
| 18:05.42 | MuffinMan | Failed to retrieve issue page for 14811. Try again later. |
| 18:05.49 | kpfleming | and now reviewboard has been renamed as well |
| 18:05.57 | file | he's offline for the moment... |
| 18:05.58 | eliel | R77 |
| 18:06.00 | MuffinMan | Error calling said() for reviewboard: malformed JSON string, neither array, object, number, string or atom, at character offset 0 ["<!DOCTYPE HTML PUBLI..."] at /usr/share/perl5/JSON.pm line 154. |
| 18:06.00 | MuffinMan | Error calling said() for reviewboard: malformed JSON string, neither array, object, number, string or atom, at character offset 0 ["<!DOCTYPE HTML PUBLI..."] at /usr/share/perl5/JSON.pm line 154. |
| 18:06.02 | MuffinMan | Error calling said() for reviewboard: malformed JSON string, neither array, object, number, string or atom, at character offset 0 ["<!DOCTYPE HTML PUBLI..."] at /usr/share/perl5/JSON.pm line 154. |
| 18:06.13 | eliel | ups, sorry for that |
| 18:06.13 | eliel | he |
| 18:06.22 | seanbright | why is reviewboard screwed? |
| 18:06.30 | seanbright | blames himself |
| 18:07.04 | kpfleming | does muffinman not know about ssl connections? |
| 18:07.31 | file | he might not at the moment. |
| 18:07.32 | seanbright | probably needs another perl module installed |
| 18:07.40 | seanbright | so that makes... |
| 18:07.46 | seanbright | 1827 dependencies |
| 18:07.48 | seanbright | heh |
| 18:08.15 | Qwell | M1234 |
| 18:08.22 | seanbright | he's not here |
| 18:08.22 | file | glares |
| 18:08.24 | seanbright | smart guy |
| 18:08.25 | Qwell | :( |
| 18:08.30 | *** join/#asterisk-dev MuffinMan (n=muffinma@asterisk/issue-tracker-bot/muffinman) |
| 18:08.34 | seanbright | M1234 |
| 18:08.35 | seanbright | heh |
| 18:08.45 | kpfleming | stop abusing muffinman |
| 18:08.58 | MuffinMan | Failed to retrieve issue page for 1234. Try again later. |
| 18:09.03 | seanbright | there's a sentence i never expected to hear. |
| 18:09.06 | seanbright | or read. |
| 18:09.07 | file | yeah, in fact I'm not bringing him back until he is all fixed :P |
| 18:09.23 | seanbright | didn't i update him to use the soap api? |
| 18:09.27 | seanbright | or have i not committed that yet? |
| 18:10.07 | file | you are as capable as answering that question as any of us. |
| 18:10.15 | seanbright | ... |
| 18:10.28 | *** join/#asterisk-dev sikanrong (n=sikanron@20.104.219.87.dynamic.jazztel.es) |
| 18:10.37 | seanbright | imagine i was going to chic-fil-a |
| 18:10.44 | seanbright | and you were craving some waffle fries |
| 18:10.54 | seanbright | and as i am about to walk out the door, you say "get me some waffle fries" |
| 18:11.00 | seanbright | i respond "you have legs... and a car..." |
| 18:11.10 | seanbright | that's how i feel right now |
| 18:11.15 | seanbright | i just want some fucking waffle fries |
| 18:11.15 | seanbright | heh |
| 18:11.24 | putnopvut | waffle fries get cold too fast. |
| 18:12.06 | Qwell | putnopvut: larger surface area |
| 18:12.15 | seanbright | would appear to not use the soap api |
| 18:12.15 | putnopvut | indeed |
| 18:12.18 | seanbright | i will check that in one day |
| 18:12.45 | *** join/#asterisk-dev MuffinMan (n=muffinma@asterisk/issue-tracker-bot/muffinman) |
| 18:12.59 | seanbright | shhh. nobody move. |
| 18:13.06 | seanbright | his vision is based on movement. |
| 18:13.30 | file | all good. |
| 18:13.46 | seanbright | R77 |
| 18:13.50 | MuffinMan | [R77] CLI command 'manager logout <username> [from <ipaddress>]' [Pending] Submitted by eliel => https://reviewboard.asterisk.org/r/77/ |
| 18:13.53 | seanbright | hot |
| 18:14.00 | seanbright | Mbacon |
| 18:14.05 | eliel | nice |
| 18:14.10 | atis_work | M1234 |
| 18:14.13 | MuffinMan | [closed] [Asterisk] Core/General 0001234: [patch] Discontinous RTP transmission (DTX) support reported by PCadach (Karma: +90.75) https://issues.asterisk.org/view.php?id=1234 |
| 18:14.18 | atis_work | what the waffle api is about? |
| 18:14.18 | eliel | M1 |
| 18:14.20 | MuffinMan | Failed to retrieve issue page for 1. Does it exist? |
| 18:14.23 | eliel | :( |
| 18:14.23 | atis_work | ooh, works |
| 18:14.31 | putnopvut | M1A1 thousand miles an hour |
| 18:14.40 | seanbright | kpfleming: the api/soap directory is giving me a 401 now. wasn't before the switch. |
| 18:14.46 | atis_work | M1 A1 thousand miles an hour |
| 18:14.49 | seanbright | (in mantis) |
| 18:14.51 | atis_work | nope |
| 18:15.02 | mnicholson | M5 |
| 18:15.03 | kpfleming | seanbright: what URL exactly? |
| 18:15.04 | MuffinMan | [closed] [Asterisk] Core/General 0000005: SIP re-invites failing with certain proxies reported by jtodd (Karma: +26.75) https://issues.asterisk.org/view.php?id=5 |
| 18:15.16 | seanbright | kpfleming: let me triple check before i start lying |
| 18:15.16 | kpfleming | please stop that |
| 18:15.28 | kpfleming | we don't need to see all this random crap when we have real stuff to do... |
| 18:15.56 | seanbright | kpfleming: no, i'm wrong. just wasn't giving me a directory listing. looks good. |
| 18:16.04 | kpfleming | ok, good |
| 18:16.10 | seanbright | ( specifically https://issues.asterisk.org/api/soap/mantisconnect.php ) |
| 18:16.48 | *** join/#asterisk-dev atis_work (n=atis_wor@193.238.212.171) |
| 18:17.06 | russellb | wonders if his mantis scripts will still work ... |
| 18:17.27 | russellb | appear to still work without modification, neat. |
| 18:17.43 | atis_work | kick from mantis? :D |
| 18:23.13 | eliel | karma details are dead |
| 18:24.48 | jpeeler | where? |
| 18:25.34 | eliel | https://issues.asterisk.org/karma_view_transactions.php?id=3802 |
| 18:27.39 | seanbright | where'd you get that link from? |
| 18:27.46 | jpeeler | yeah that's what i am wondering |
| 18:27.52 | seanbright | i just followed the karma link from a bug page and it worked fine |
| 18:28.50 | jpeeler | oh |
| 18:28.58 | jpeeler | that's my bad |
| 18:30.34 | eliel | jpeeler: try to click a user on the list... you should get the list of karma transactions... |
| 18:30.56 | kpfleming | seanbright: anyone have a checkout of something from svn.digium.com? |
| 18:31.17 | jpeeler | eliel: yeah i know exactly what the issue is |
| 18:31.51 | seanbright | maybe here at work, let me check. |
| 18:33.28 | seanbright | kpfleming: does not appear so, unfortunately. |
| 18:33.37 | seanbright | kpfleming: unless i can just re-use the checkout i just did |
| 18:33.38 | kpfleming | ok, checkout something small then |
| 18:33.43 | kpfleming | i want to test the redirect |
| 18:33.53 | kpfleming | it needs to be from svn.digium.com and not yet switched |
| 18:34.20 | seanbright | svn co http://svn.digium.com/svn/repotools/muffinman ohai |
| 18:34.22 | seanbright | that worked. |
| 18:34.28 | kpfleming | ok, here we go |
| 18:34.46 | kpfleming | try an update |
| 18:34.53 | seanbright | without switching, correct? |
| 18:34.56 | kpfleming | yes |
| 18:35.14 | seanbright | sean@elixer:~/dev/ohai$ svn update |
| 18:35.15 | seanbright | svn: Repository moved permanently to 'http://svn.asterisk.org/svn/repotools/muffinman'; please relocate |
| 18:35.21 | kpfleming | nice |
| 18:35.23 | kpfleming | very nice |
| 18:35.34 | kpfleming | that is much better than i expected |
| 18:35.46 | kpfleming | let me try a temp redirect to see what happens |
| 18:35.58 | seanbright | i am running subversion 1.6.something at home though |
| 18:36.03 | seanbright | not sure if that is 'nicer' or not |
| 18:36.08 | kpfleming | ok, one more update try please |
| 18:36.21 | seanbright | sean@elixer:~/dev/ohai$ svn update |
| 18:36.21 | seanbright | svn: Server sent unexpected return value (405 Method Not Allowed) in response to PROPFIND request for '/svn/repotools/muffinman' |
| 18:36.26 | kpfleming | weird |
| 18:36.28 | seanbright | (i'll stop pasting the first line) |
| 18:36.44 | kpfleming | again? |
| 18:37.12 | seanbright | svn: Repository moved temporarily to 'http://svn.asterisk.org/svn/repotools/muffinman'; please relocate |
| 18:37.20 | kpfleming | ok, so you still get the message either way |
| 18:37.22 | kpfleming | permanent is better then |
| 18:37.41 | kpfleming | does it also do the update? |
| 18:37.47 | seanbright | not sure |
| 18:37.52 | seanbright | oh |
| 18:37.58 | seanbright | there is no "at revision blah" afterwards |
| 18:38.01 | seanbright | so i'd assume not |
| 18:38.03 | kpfleming | ok, so probably not then |
| 18:38.27 | kpfleming | so anyone who has automatically updated checkouts is not going to like this... hmm |
| 18:38.31 | kpfleming | this requires more thinking |
| 18:39.28 | seanbright | ugh |
| 18:39.40 | kpfleming | i'll put it back for now |
| 18:39.53 | seanbright | not sure there is a way |
| 18:39.59 | seanbright | short of some kind of proxy |
| 18:40.17 | kpfleming | well, but that means people won't change to the new hostname |
| 18:40.25 | kpfleming | we'll just have to let it be this way for a long time and watch the logs |
| 18:40.28 | kpfleming | you should be able to update now |
| 18:40.42 | seanbright | sure enough. |
| 18:40.50 | kpfleming | ok, thanks for the help |
| 18:40.53 | seanbright | no sweat |
| 18:40.55 | seanbright | i accept paypal. |
| 18:40.56 | seanbright | :P |
| 18:43.06 | seanbright | orig will not be changing i assume. |
| 18:44.31 | russellb | correct |
| 18:53.00 | eliel | mnicholson: i am wrong or we are calling ao2_lock/ao2_unlock in a mansession structure BUT mansession is not an ao2 object, that is why we are getting a list of warnings in the CLI and also we are not getting any structure locked... |
| 18:53.54 | eliel | says, please tell me i am wrong or we have A problem here... |
| 19:40.05 | eliel | yes, i am right... |
| 20:25.50 | mnicholson | eliel, nice |
| 20:28.23 | eliel | mnicholson: that will fix the warning messages, will make the locks work, and fix the issue, but a review is neccesary |
| 20:31.36 | mnicholson | good stuff |
| 20:36.55 | putnopvut | eliel: good work! |
| 20:37.22 | putnopvut | eliel: I only saw one problem with the code, and I noted it on review board (no calls to ast_mutex_destroy). |
| 20:38.47 | eliel | putnopvut: yes, i notice that, it is necessary to call ast_mutex_destroy for a structure that will be destroyed when the main function returns? |
| 20:39.09 | eliel | because the structure is defined in the block of that function... |
| 20:39.44 | kpfleming | yes, all mutexes must be destroyed safely |
| 20:39.50 | eliel | amen |
| 20:39.52 | eliel | :) |
| 20:49.29 | Corydon76-dig | Here's an interesting question... We have a signal on a PRI when a trunk desires an account code to be entered. One place that would be logical to store said accountcode would be in CDR(accountcode). So would it be reasonable when that signal is received on a PRI, to take that CDR(accountcode) and pass it on? |
| 20:49.59 | kpfleming | what sort of 'signal' are you talking about? |
| 20:50.04 | Corydon76-dig | IE 50 |
| 20:50.09 | kpfleming | ahh |
| 20:50.15 | *** join/#asterisk-dev qdk (n=qdk@0x573d8dd1.bynqu1.dynamic.dsl.tele.dk) |
| 20:50.45 | Corydon76-dig | One of the 4 possible subtypes is accounting code |
| 20:50.50 | *** join/#asterisk-dev Deeewayne (n=dwayne@c-76-29-245-9.hsd1.al.comcast.net) |
| 20:50.50 | *** mode/#asterisk-dev [+o Deeewayne] by ChanServ |
| 20:51.03 | kpfleming | yeah, i'd think that would be reasonable |
| 20:51.06 | seanbright | i just googled for ie 50 and found the mantis issue i think you are working on :) |
| 20:51.11 | kpfleming | controlled via configuration option |
| 20:51.13 | Corydon76-dig | and it's sent back via DTMF |
| 20:51.55 | kpfleming | oh |
| 20:52.01 | kpfleming | that's very very different then |
| 20:52.12 | kpfleming | i don't know how we can handle that in asterisk |
| 20:52.21 | Corydon76-dig | No, the IE50 isn't DTMF |
| 20:52.28 | kpfleming | i undersand |
| 20:52.32 | kpfleming | but the response is |
| 20:52.35 | Corydon76-dig | Right |
| 20:52.47 | Corydon76-dig | Well, digitally sent |
| 20:53.21 | Corydon76-dig | The spec says that if no response is received within a certain period of time, it is to take other measures |
| 20:53.35 | Corydon76-dig | which usually means to present a tone on the line, for human intervention |
| 20:53.58 | Corydon76-dig | I think it's 2 seconds |
| 20:54.33 | Corydon76-dig | It's an interesting feature that might be helpful for a trunk shared between multiple tenants, each accountcode billed separately |
| 20:55.05 | Corydon76-dig | especially if you don't want the tenants' employees to have to deal with the accountcode |
| 20:55.30 | seanbright | so you would make it dependent on a configuration flag, then? |
| 20:55.51 | kpfleming | i don't really know that this can be done without a bunch of work in the applications that can create outbound channels |
| 20:55.52 | Corydon76-dig | Something along the lines of usecdraccountcode=yes |
| 20:56.07 | kpfleming | accountcodes are very frequently not numeric |
| 20:56.30 | Corydon76-dig | kpfleming: that's an easy test |
| 20:56.50 | Corydon76-dig | If numeric send, otherwise wait for the trunk to signal otherwise |
| 20:57.23 | Corydon76-dig | but you're right; it may be a bit of work, since this is all slave channels |
| 20:57.40 | Corydon76-dig | better to add it to the dialstring and pass it in the request |
| 21:13.53 | *** join/#asterisk-dev anthm (n=anthm@freeswitch/developer/anthm) |
| 21:18.12 | *** join/#asterisk-dev kamanashisroy (n=kamanash@119.30.36.7) |
| 21:45.42 | kpfleming | tzafrir_laptop: ping |
| 21:45.50 | tzafrir_laptop | kpfleming, pong |
| 21:46.15 | kpfleming | are you famlliar with why debian lenny 32-bit x86 kernel packages set ARCH to 'x86' instead of 'i386' like the mainline kernel does? |
| 21:47.54 | tzafrir_laptop | kpfleming, where do you see that, exactly? uname -m seems to return 'i686' on a test machine here |
| 21:48.01 | kpfleming | yes |
| 21:48.21 | kpfleming | we have a customer machine that claims to be running lenny but dahdi won't build properly because ARCH (as computed by the kernel makefiles) is x86 |
| 21:48.23 | kpfleming | not i386 |
| 21:48.35 | kpfleming | not uname -m, that reports i686 as expected |
| 21:48.42 | kpfleming | but ARCH in the kernel build system |
| 21:49.45 | tzafrir_laptop | is that a problem? |
| 21:49.53 | kpfleming | hang on, may be a false alarm |
| 21:51.13 | kpfleming | how can i see who signed the linux-image package that is installed? |
| 21:52.44 | tzafrir_laptop | normally it should be whoever is listed in the last changelog entry |
| 21:53.32 | kpfleming | looks like a normal debian linux-image-2.6.26-2-686 |
| 21:57.01 | *** join/#asterisk-dev Laureano (n=Laureano@190.245.100.86) |
| 21:59.30 | *** join/#asterisk-dev leifmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 21:59.30 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 22:19.26 | *** join/#asterisk-dev eliel (n=eliels@120-17-235-201.fibertel.com.ar) |
| 22:19.26 | *** mode/#asterisk-dev [+o eliel] by ChanServ |
| 22:23.26 | eliel | it is possible in a commit message to close multiple issues? |
| 22:24.06 | mnicholson | yes |
| 22:24.28 | eliel | thanks |
| 22:30.36 | *** join/#asterisk-dev DarkRift (n=dark@65.92.165.123) |
| 22:30.38 | *** part/#asterisk-dev DarkRift (n=dark@65.92.165.123) |
| 22:36.50 | Laureano | I'm trying to set the value for a CDR field inside a channel driver, to be used by CDR ODBC adaptive. Should I use ast_cdr_setvar() or pbx_builtin_setvar_helper() in conjunction with the CDR() dialplan function? I've tried both but none of them worked as expected. |
| 22:37.29 | Corydon76-dig | Laureano: make sure that you're setting the values on the right channel |
| 22:37.45 | Corydon76-dig | If you set the values on the wrong channel, you'll never see any results |
| 22:38.10 | Corydon76-dig | gotta set the values on the master (originating) channel, not the slave (destination) channel |
| 22:38.50 | Laureano | Thanks for the tip. I'll double check my results to see what's the name of the channel where I'm defining the values. |
| 22:39.31 | mnicholson | do we favor ast_copy_string over strcpy in all cases? |
| 22:39.39 | kpfleming | no |
| 22:39.54 | kpfleming | when the target buffer is known to be the proper size, strcpy is faster |
| 22:39.58 | kpfleming | but then so is memcpy |
| 22:40.12 | mnicholson | ok |
| 22:40.36 | russellb | but does memcpy + strlen do better than strcpy ... |
| 22:40.43 | russellb | probably not, *shrugs* |
| 22:40.59 | kpfleming | if you just allocated the buffer to the proper size, you don't need strlen |
| 22:41.10 | russellb | but how do you know the proper size? |
| 22:41.18 | kpfleming | if you didn't, but you know for sure it's big enough, then strcpy is better than memcpy |
| 22:41.27 | russellb | if it's just the size of the source buffer, the you may end up writing more than you have to (or maybe a lot more) |
| 22:41.28 | kpfleming | because you already used strlen |
| 22:41.32 | russellb | true |
| 22:41.47 | russellb | hugs std::string :-p |
| 22:42.33 | eliel | (closes issue #XXXX) <- I need to duplicate this line to close more than issue or we have a comma separated way? |
| 22:43.09 | russellb | duplicate it would be best |
| 22:43.16 | eliel | k |
| 22:43.16 | russellb | please use the commit message template for each closed issue |
| 22:43.25 | russellb | so that you get all of the relevant info |
| 22:43.39 | russellb | the release summary script, and future similar tools, will thank you :-D |
| 22:49.43 | russellb | yay bugs closed |
| 22:51.16 | eliel | russellb: did i put something wrong in the review url?? |
| 22:51.25 | eliel | the review wasn't set as submited.. |
| 22:51.27 | russellb | I don't know |
| 22:51.31 | russellb | Oh, I know what happened ... |
| 22:51.33 | russellb | what URL did you use? |
| 22:51.42 | russellb | https://reviewboard.asterisk.org ? |
| 22:51.47 | russellb | I need to change the hook to look for the new URL |
| 22:52.23 | eliel | no, http |
| 22:52.43 | kpfleming | different host name too :-) |
| 23:02.15 | mnicholson | merging fixes takes too long |
| 23:03.08 | russellb | :'-( <---- that tear is for you, mnicholson ! |
| 23:04.50 | mnicholson | i don't know of any ways to make it faster though... |
| 23:06.02 | eliel | and you are on digiums lan? |
| 23:06.06 | jpeeler | well something that could help is if the release cycles were a little faster. but perhaps we are right on target right now? |
| 23:06.11 | kpfleming | you should try it over the VPN from a hotel in northern germany |
| 23:06.21 | eliel | or from argentina :( |
| 23:06.30 | jpeeler | oh he meant actually committing... |
| 23:10.04 | mnicholson | well more like, running merge4trunk, doing fixes, and then (mergetrunk6, doing fixes) * 3 |
| 23:10.44 | mnicholson | i wrote a little script to help me resolve conflicts, but it still takes significant effort |
| 23:11.23 | mnicholson | it's fine for smaller fixes that don't generate conflicts |
| 23:11.32 | jpeeler | sure, so i was right about what you meant |
| 23:13.56 | putnopvut | yeah, the mergeXY scripts are horribly slow from !digium |
| 23:14.11 | putnopvut | well, that's not entirely true. Things are pretty quick at, say, my house. |
| 23:14.20 | putnopvut | But when I was in Germany last week, it was awful. |
| 23:14.49 | eliel | darcs downloads the entire repo so then the local copy is a repository? that could make things faster (??) |
| 23:21.06 | mnicholson | eliel, yes, that is correct, same for most dvcs systems (although that would not help in my case) |
| 23:24.27 | Laureano | Corydon76-dig, you were right. I was setting the values on the slave channel. Thanks again. |
| 23:25.00 | eliel | Laureano: hello tommy :) |
| 23:25.27 | Laureano | Hi eliel |
| 23:26.45 | Corydon76-dig | Tommy, can you hear me? |
| 23:28.12 | eliel | lol |
| 23:28.30 | Laureano | :-) |
| 23:31.11 | putnopvut | would make a pinball wizard comment except that he's not sure if that's what Corydon76-dig was referencing. |
| 23:32.27 | snuff-work | i see bugs is now.. 'issues' .digium and over https.. |
| 23:33.07 | Corydon76-dig | putnopvut: No, you got it |
| 23:42.30 | Laureano | Is there any structure where I can find the parent channel for a given slave channel? The channel is not bridged yet. |