| 00:03.41 | *** join/#asterisk-dev uluatu (n=uluatu@189.114.176.219.dynamic.adsl.gvt.net.br) |
| 00:04.45 | *** join/#asterisk-dev tzafrir_laptop (n=tzafrir@bzq-218-155-146.cablep.bezeqint.net) |
| 00:04.45 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 00:07.50 | *** join/#asterisk-dev uluatu_ (n=uluatu@200.146.5.244.dynamic.dialup.gvt.net.br) |
| 00:22.59 | *** join/#asterisk-dev uluatu (n=uluatu@189.114.176.219.dynamic.adsl.gvt.net.br) |
| 00:43.24 | *** join/#asterisk-dev snuff-work (n=aaa@120.19.232.37) |
| 00:43.24 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 01:23.49 | *** join/#asterisk-dev elguero (n=elguero@ns1.nashuacs.com) |
| 01:43.08 | *** join/#asterisk-dev uluatu (n=uluatu@189.114.176.219.dynamic.adsl.gvt.net.br) |
| 02:44.04 | *** join/#asterisk-dev xpot-mobile (n=xpot@70-91-210-233-BusName-Utah.hfc.comcastbusiness.net) |
| 04:56.58 | *** join/#asterisk-dev infobot (i=ibot@rikers.org) |
| 04:56.58 | *** topic/#asterisk-dev is Topic for #asterisk-dev is: Asterisk Development Discussion -=- http://www.asterisk.org/developers -=- Tier 2 and 3.14159265 support is in #asterisk -=- http://www.xkcd.org/664/ |
| 05:08.38 | *** join/#asterisk-dev sruffell (n=sruffell@asterisk/the-kernel-guy/sruffell) |
| 05:08.38 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 05:09.07 | Kobaz | hmmm |
| 05:09.17 | Kobaz | i think i found another bug with local channels |
| 05:09.58 | Kobaz | if you have a Dial with an L... once it plays the fist warning track, audio stops being bridged |
| 05:12.29 | Kobaz | actually.. i just tried without a local channel |
| 05:18.22 | Kobaz | very strange |
| 06:20.23 | *** join/#asterisk-dev kpfleming (n=kpflemin@asterisk/digium-director-of-software-tech/kpfleming) |
| 06:20.24 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 06:55.38 | *** join/#asterisk-dev |Cybex| (n=John@atwork-21.r-212.178.82.atwork.nl) |
| 07:08.54 | *** join/#asterisk-dev sgimeno (n=santiago@226.Red-80-33-64.staticIP.rima-tde.net) |
| 07:36.05 | *** join/#asterisk-dev infobot (i=ibot@rikers.org) |
| 07:36.05 | *** topic/#asterisk-dev is Topic for #asterisk-dev is: Asterisk Development Discussion -=- http://www.asterisk.org/developers -=- Tier 2 and 3.14159265 support is in #asterisk -=- http://www.xkcd.org/664/ |
| 08:05.13 | *** join/#asterisk-dev |Cybex| (n=John@atwork-21.r-212.178.82.atwork.nl) |
| 08:16.03 | *** join/#asterisk-dev sruffell (n=sruffell@asterisk/the-kernel-guy/sruffell) [NETSPLIT VICTIM] |
| 08:16.03 | *** join/#asterisk-dev |Cybex| (n=John@atwork-21.r-212.178.82.atwork.nl) |
| 08:16.03 | *** join/#asterisk-dev sgimeno (n=santiago@226.Red-80-33-64.staticIP.rima-tde.net) |
| 08:16.03 | *** join/#asterisk-dev xpot-mobile (n=xpot@70-91-210-233-BusName-Utah.hfc.comcastbusiness.net) |
| 08:16.03 | *** join/#asterisk-dev korihor (n=korihor@201.210.226.98) |
| 08:16.03 | *** join/#asterisk-dev key2 (n=key2@gob75-7-82-247-113-230.fbx.proxad.net) |
| 08:16.03 | *** join/#asterisk-dev philipp64 (n=chatzill@63.224.43.239) [NETSPLIT VICTIM] |
| 08:16.03 | *** join/#asterisk-dev atis_work (n=atis_wor@193.238.212.171) |
| 08:16.03 | *** join/#asterisk-dev Corydon76-dig (i=six@c-69-137-80-31.hsd1.tn.comcast.net) |
| 08:16.03 | *** join/#asterisk-dev file (n=file@asterisk/developer-and-muffin-lover/file) |
| 08:16.03 | *** join/#asterisk-dev russellb (n=russellb@asterisk/digium-open-source-team-lead/russellb) |
| 08:16.03 | *** mode/#asterisk-dev [+oooo sruffell Corydon76-dig file russellb] by irc.freenode.net |
| 08:16.04 | *** join/#asterisk-dev Qwell (i=north@pdpc/sponsor/digium/Qwell) |
| 08:16.04 | *** join/#asterisk-dev jmworx (n=jeval@mail.octasic.com) [NETSPLIT VICTIM] |
| 08:16.04 | *** join/#asterisk-dev ayrjola (n=ayrjola@gw.ccxtech.fi) |
| 08:16.04 | *** join/#asterisk-dev WHYS (n=drumm@137.28.94.209) |
| 08:16.04 | *** join/#asterisk-dev jmls (n=jmls@host217-36-208-155.in-addr.btopenworld.com) [NETSPLIT VICTIM] |
| 08:16.04 | *** join/#asterisk-dev ccesario (n=ccesario@189-19-6-236.dsl.telesp.net.br) |
| 08:16.04 | *** join/#asterisk-dev Amorsen (n=Amorsen@94.127.50.7) |
| 08:16.04 | *** join/#asterisk-dev MuffinMan (n=muffinma@asterisk/issue-tracker-bot/muffinman) |
| 08:16.04 | *** join/#asterisk-dev devmod (n=devmod@c-76-100-208-204.hsd1.md.comcast.net) |
| 08:16.04 | *** join/#asterisk-dev rbd_ (n=rbd@rrcs-98-101-33-14.midsouth.biz.rr.com) |
| 08:16.04 | *** join/#asterisk-dev mnicholson_ (n=mnichols@nat/digium/x-pxmeyohcxqmjzjqv) |
| 08:16.04 | *** join/#asterisk-dev angler (n=angler@pdpc/sponsor/digium/angler) |
| 08:16.04 | *** join/#asterisk-dev Daviey (n=Daviey@ubuntu/member/pdpc.gold.Daviey) [NETSPLIT VICTIM] |
| 08:16.04 | *** join/#asterisk-dev seanbright (n=sean@asterisk/contributor-and-bug-marshal/seanbright) |
| 08:16.04 | *** join/#asterisk-dev jetsnoc (n=brian@72.22.242.66) [NETSPLIT VICTIM] |
| 08:16.04 | *** join/#asterisk-dev xpot (n=xpot@70-91-210-233-BusName-Utah.hfc.comcastbusiness.net) |
| 08:16.04 | *** join/#asterisk-dev kn0x (n=pinochle@67.159.48.101) [NETSPLIT VICTIM] |
| 08:16.04 | *** join/#asterisk-dev mvanbaak (n=michiel@asterisk/contributor-and-bug-marshal/mvanbaak) |
| 08:16.04 | *** join/#asterisk-dev felipe_ (n=felipe@my.nada.kth.se) |
| 08:16.04 | *** join/#asterisk-dev mbranca (n=matteo@host139-217-static.224-95-b.business.telecomitalia.it) |
| 08:16.04 | *** join/#asterisk-dev dwayne (n=dwayne@c-71-207-214-190.hsd1.al.comcast.net) |
| 08:16.04 | *** mode/#asterisk-dev [+ooo Qwell seanbright mvanbaak] by irc.freenode.net |
| 08:19.16 | *** join/#asterisk-dev tamiel (n=tamiel@213.30.183.226) |
| 08:27.20 | *** join/#asterisk-dev ayrjola (n=ayrjola@gw.ccxtech.fi) |
| 08:34.34 | *** join/#asterisk-dev vrban (n=chatzill@p50997436.dip0.t-ipconnect.de) |
| 08:59.29 | *** join/#asterisk-dev sgimeno (n=santiago@226.Red-80-33-64.staticIP.rima-tde.net) |
| 09:08.49 | *** join/#asterisk-dev kpfleming (n=kpflemin@asterisk/digium-director-of-software-tech/kpfleming) |
| 09:08.49 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 09:49.41 | *** join/#asterisk-dev kpfleming (n=kpflemin@asterisk/digium-director-of-software-tech/kpfleming) |
| 09:49.41 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 10:20.28 | *** join/#asterisk-dev tamiel (n=tamiel@213.30.183.226) |
| 11:05.07 | *** join/#asterisk-dev puzzled (n=foobar@puzzled.xs4all.nl) |
| 11:15.22 | *** join/#asterisk-dev puzzled_ (n=foobar@puzzled.xs4all.nl) |
| 11:28.05 | *** join/#asterisk-dev caio1982 (i=caio1982@CAcert-br/caio1982) |
| 11:31.48 | *** join/#asterisk-dev ChanServ (ChanServ@services.) |
| 11:31.48 | *** mode/#asterisk-dev [+o ChanServ] by irc.freenode.net |
| 11:42.44 | *** join/#asterisk-dev ChanServ (ChanServ@services.) |
| 11:42.44 | *** mode/#asterisk-dev [+o ChanServ] by irc.freenode.net |
| 11:43.08 | *** join/#asterisk-dev tzafrir_laptop (n=tzafrir@bzq-218-155-147.cablep.bezeqint.net) |
| 11:43.08 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 11:57.13 | *** join/#asterisk-dev tzafrir_laptop (n=tzafrir@bzq-218-155-146.cablep.bezeqint.net) |
| 11:57.13 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 12:13.37 | *** join/#asterisk-dev uluatu (n=uluatu@189.114.176.219.dynamic.adsl.gvt.net.br) |
| 12:16.56 | *** part/#asterisk-dev puzzled_ (n=foobar@puzzled.xs4all.nl) |
| 12:23.46 | *** join/#asterisk-dev infobot (i=ibot@rikers.org) |
| 12:23.46 | *** topic/#asterisk-dev is Topic for #asterisk-dev is: Asterisk Development Discussion -=- http://www.asterisk.org/developers -=- Tier 2 and 3.14159265 support is in #asterisk -=- http://www.xkcd.org/664/ |
| 12:30.50 | *** join/#asterisk-dev Victor_Yure (n=victor@unaffiliated/victoryure/x-837844) |
| 12:55.30 | *** join/#asterisk-dev uluatu (n=uluatu@189.58.22.227.dynamic.adsl.gvt.net.br) |
| 13:05.33 | *** join/#asterisk-dev Kchehab (n=kchehab@212.98.141.202) |
| 13:06.02 | Kchehab | hi all ,how to know SIP RFC for asterisk V 1.6.0.6 |
| 13:06.34 | *** join/#asterisk-dev leifmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 13:06.34 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 13:06.35 | Kchehab | SIp RFC Version* |
| 13:08.59 | leifmadsen | Kchehab: please don't as the same question in multiple channels at the same time |
| 13:21.39 | *** join/#asterisk-dev tzafrir (n=tzafrir@212.179.75.202) |
| 13:21.39 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 13:34.35 | *** part/#asterisk-dev |Cybex| (n=John@atwork-21.r-212.178.82.atwork.nl) |
| 13:35.57 | *** join/#asterisk-dev msetim (n=setim@189.58.22.227.dynamic.adsl.gvt.net.br) |
| 14:09.42 | *** join/#asterisk-dev leifmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 14:09.42 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 14:17.05 | *** join/#asterisk-dev kpfleming (n=kpflemin@asterisk/digium-director-of-software-tech/kpfleming) |
| 14:17.05 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 14:26.28 | *** join/#asterisk-dev TheDavidFactor (n=chatzill@fw1.safedataisp.net) |
| 14:28.03 | *** join/#asterisk-dev Victor_Yure_ (n=victor@unaffiliated/victoryure/x-837844) |
| 14:37.48 | *** join/#asterisk-dev malcolmd (n=malcolmd@pdpc/sponsor/digium/malcolmd) |
| 14:37.48 | *** mode/#asterisk-dev [+o malcolmd] by ChanServ |
| 14:58.47 | *** join/#asterisk-dev malcolmd (n=malcolmd@pdpc/sponsor/digium/malcolmd) |
| 14:58.47 | *** mode/#asterisk-dev [+o malcolmd] by ChanServ |
| 15:00.37 | *** join/#asterisk-dev putnopvut (n=putnopvu@asterisk/master-of-queues/mmichelson) |
| 15:00.37 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 15:01.57 | *** join/#asterisk-dev grolloj (n=chatzill@h-68-166-73-162.nycmny83.static.covad.net) |
| 15:04.08 | *** join/#asterisk-dev moy (n=moy@bas1-unionville55-1177733883.dsl.bell.ca) |
| 15:16.31 | *** join/#asterisk-dev kpfleming (n=kpflemin@asterisk/digium-director-of-software-tech/kpfleming) |
| 15:16.31 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 15:24.18 | *** join/#asterisk-dev sruffell (n=sruffell@asterisk/the-kernel-guy/sruffell) |
| 15:24.18 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 15:34.42 | *** join/#asterisk-dev jpeeler (n=jpeeler@asterisk/digium-software-dev/jpeeler) |
| 15:34.42 | *** mode/#asterisk-dev [+o jpeeler] by ChanServ |
| 15:40.22 | *** join/#asterisk-dev The_Boy_Wonder (n=vossel@asterisk/batman-developer/dvossel) |
| 15:40.22 | *** mode/#asterisk-dev [+o The_Boy_Wonder] by ChanServ |
| 15:41.55 | kaii | !M16459 |
| 15:42.02 | kaii | !m 16459 |
| 15:42.44 | seanbright | M16459 |
| 15:42.47 | MuffinMan | [closed] [Asterisk] Channels/chan_sip/General 0016459: [patch] Change in sip show channels display format allowing more digits for CID reported by Rzadzins https://issues.asterisk.org/view.php?id=16459 |
| 15:43.17 | kaii | seanbright: i knew i was close |
| 15:44.22 | kaii | wonders why this patch went into 1.4 |
| 15:44.41 | kaii | is that considered a bugfix? |
| 15:44.59 | leifmadsen | in terms of interface usability -- yes. |
| 15:45.03 | russellb | slams head on desk |
| 15:45.28 | leifmadsen | russellb: don't do that -- we need your brain in optimum shape. |
| 15:45.33 | kaii | haha |
| 15:47.49 | Corydon76-dig | I think it probably should not have gone in at all |
| 15:48.37 | seanbright | i tend to agree. |
| 15:48.43 | seanbright | even though i hate doing that. |
| 15:48.55 | leifmadsen | seanbright: I hate it when you hate it |
| 15:49.29 | Corydon76-dig | He only hates agreeing with me |
| 15:49.36 | russellb | I have never seen so much discussion over a super trivial formatting change |
| 15:49.58 | seanbright | people parse CLI output |
| 15:50.11 | Corydon76-dig | russellb: Well, it has a tendency to break parsers when we do things like that |
| 15:50.25 | Corydon76-dig | and we all bear the brunt of such backlash |
| 15:50.51 | Corydon76-dig | This is why we make policy |
| 15:52.35 | Corydon76-dig | What do we tell people in the aftermath? "Well, it was a super trivial patch. Your parser was stupid and shouldn't have gotten broken." |
| 15:52.47 | Kobaz | it would be nice if much more data was available from the ami, so we don't have to parse cli output |
| 15:54.41 | russellb | obviously parsing CLI output is a terrible idea in the first place, especially in a case like this when the information _is_ available via AMI. |
| 15:54.51 | Kobaz | yeah |
| 15:54.57 | Kobaz | many things aren't available in the ami though |
| 15:55.22 | *** join/#asterisk-dev anthm (n=anthm@freeswitch/developer/anthm) |
| 15:55.26 | russellb | different issue, though. |
| 15:55.29 | Kobaz | yeah |
| 15:55.43 | Kobaz | speaking of new things, i wonder how my reviewboard thing is going |
| 15:56.50 | Kobaz | hmm |
| 15:56.58 | Kobaz | how do i know if someone is reviewing i |
| 15:57.00 | kaii | russellb: terrible idea or not, it doesn't change the fact people sometimes have terrible ideas |
| 15:57.10 | Kobaz | t |
| 15:57.54 | Corydon76-dig | Kobaz: you'll get an email when a review is posted |
| 15:58.00 | Kobaz | ah |
| 15:58.01 | Kobaz | k |
| 15:58.16 | russellb | "how my reviewboard thing is going" |
| 15:58.17 | russellb | what thing |
| 15:58.20 | Kobaz | https://reviewboard.asterisk.org/r/464/ |
| 15:58.27 | russellb | R464 |
| 15:58.32 | MuffinMan | [R464] Group Variables [Pending] Submitted by kobaz => https://reviewboard.asterisk.org/r/464/ |
| 15:58.41 | russellb | Is this also in mantis? |
| 15:58.44 | Kobaz | oh |
| 15:58.45 | Kobaz | nope |
| 15:58.53 | Kobaz | i thought it had to go there before it went into the issue tracker |
| 15:58.53 | russellb | btw, it's still pending, meaning that nobody else can see it |
| 15:58.58 | Kobaz | oh okay |
| 15:58.59 | russellb | opposite, actually |
| 15:59.01 | Kobaz | how do i make it unpending |
| 15:59.22 | russellb | http://www.asterisk.org/doxygen/trunk/Reviewboard.html |
| 15:59.26 | russellb | you click "Publish" |
| 15:59.29 | russellb | should be up top i think |
| 15:59.31 | Kobaz | k |
| 15:59.57 | Kobaz | i think it's published |
| 16:00.03 | russellb | R464 |
| 16:00.06 | Kobaz | i clicked on 'review' and then 'publish' |
| 16:00.08 | MuffinMan | [R464] Group Variables [Pending] Submitted by kobaz => https://reviewboard.asterisk.org/r/464/ |
| 16:00.22 | Kobaz | hmm |
| 16:00.23 | russellb | yup, it's good now |
| 16:00.28 | Kobaz | oh okay |
| 16:01.30 | Kobaz | okay so i'll make an issue for it then too |
| 16:01.47 | Kobaz | this is my first feature patch, so i'm figuring stuff out still |
| 16:02.33 | Kobaz | do i upload the diff to mantis too? |
| 16:03.03 | russellb | yes, please - see the reviewboard usage guidelines link I sent :-) |
| 16:03.22 | Kobaz | oh yeah |
| 16:03.24 | Kobaz | that link |
| 16:03.53 | russellb | mantis is still the patch submission system, with reviewboard an optional supplement to the process |
| 16:04.01 | Kobaz | ah k |
| 16:05.48 | Kobaz | https://issues.asterisk.org/view.php?id=16614 |
| 16:05.50 | Kobaz | there it is |
| 16:06.55 | *** join/#asterisk-dev Gugge (n=gugge@vlan2.dlxhosting.dk) |
| 16:08.01 | leifmadsen | thx |
| 16:08.42 | Kobaz | np |
| 16:08.49 | Kobaz | time to add the rest of my patches |
| 16:11.43 | TheDavidFactor | russellb, glad to see you made it back from your trip safe and sound. |
| 16:11.49 | russellb | thanks. |
| 16:12.38 | TheDavidFactor | when you have some time would review: |
| 16:12.40 | TheDavidFactor | R449 |
| 16:12.41 | TheDavidFactor | for me? I've finally gotten it to a place where I'm ready for review |
| 16:12.44 | MuffinMan | [R449] Add notification of interrupted file and fix bug [Pending] Submitted by thedavidfactor => https://reviewboard.asterisk.org/r/449/ |
| 16:15.47 | TheDavidFactor | russellb, also, are there other people I can pick on for reviews? so I'm not always bugging you? |
| 16:15.55 | *** join/#asterisk-dev marv[work] (n=timr@router.asteriasgi.com) |
| 16:16.01 | *** join/#asterisk-dev atis_work (n=atis_wor@193.238.212.171) |
| 16:16.11 | russellb | anyone with commit access, |
| 16:16.18 | russellb | but bugging people is generally frowned upon :-) |
| 16:17.06 | Kobaz | ah, i noticed CEL is in... that's some cool stuff |
| 16:17.17 | Kobaz | I've been doing my own custom call progress tracking to postgres |
| 16:19.56 | TheDavidFactor | russellb, is asking people, including you, for reviews an abuse? |
| 16:20.20 | Kobaz | help help we're being repressed |
| 16:20.38 | seanbright | your review request is posted |
| 16:20.48 | seanbright | if and when people want to review it, they will review it |
| 16:20.52 | Kobaz | heh |
| 16:21.13 | russellb | TheDavidFactor: you can ask, just don't be offended if I don't respond |
| 16:21.31 | TheDavidFactor | if you're not offended, I'm not offended |
| 16:21.44 | TheDavidFactor | :-) |
| 16:23.02 | Kobaz | would sending cookies and flowers speed up the process? |
| 16:23.42 | TheDavidFactor | I don't know know, there was a discussion the dev list about muffins and the response seemed to be more about money ;-) |
| 16:24.01 | seanbright | yeah, this is open source |
| 16:24.18 | *** join/#asterisk-dev leifmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 16:24.18 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 16:24.19 | seanbright | we don't do anything without funding and/or sponsorship |
| 16:24.33 | russellb | :-X |
| 16:24.49 | russellb | Kobaz: flowers not so much ... |
| 16:25.06 | file | I sent jpeeler blueberry muffins once :D |
| 16:25.15 | Kobaz | russellb: heh |
| 16:25.42 | Kobaz | the recruiting agency for the company i used to work for would always send us cookies |
| 16:26.19 | TheDavidFactor | I have committer status, but I don't want to step out of line, If I'm comfortable with the code and have done testing, is it ever ok to commit it without going through the review process? |
| 16:26.32 | seanbright | no one uses externalivr |
| 16:26.35 | seanbright | just commit the damn thing |
| 16:26.38 | seanbright | heh |
| 16:26.39 | Kobaz | haha |
| 16:26.44 | russellb | seanbright: harsh man |
| 16:26.47 | Kobaz | yeah what's externalivr for anyway |
| 16:26.53 | Kobaz | i've never used it |
| 16:26.53 | Qwell | external IVRs |
| 16:27.00 | seanbright | COMMMMITTTTTTTTTTT |
| 16:27.01 | russellb | TheDavidFactor: Ideally, I would like every change to have 2 sets of (committer) eyes on it |
| 16:27.15 | Kobaz | Qwell: that answer is surprisingly similar to your answer about what app_rpt was |
| 16:27.34 | Qwell | What was my answer about app_rpt? |
| 16:27.43 | Kobaz | that's it's for radios |
| 16:27.52 | russellb | TheDavidFactor: but I have not gone to the extent of proposing that as a hard project rule or anything |
| 16:27.55 | Qwell | ahh, yes |
| 16:28.04 | russellb | so, if you want, commit, and people will yell if you mess up :-) |
| 16:28.07 | seanbright | COMMMMITTTTTTTTTTT |
| 16:28.10 | russellb | but just don't make that your default |
| 16:28.13 | Qwell | points to ctooley |
| 16:28.13 | russellb | seanbright: go review it then |
| 16:28.34 | seanbright | i cannot devote anymore time to this project without sponsorship |
| 16:28.41 | Kobaz | uh oh |
| 16:29.02 | Kobaz | i used up seanbright's quota yesterday |
| 16:29.20 | TheDavidFactor | I prefer to keep the yelling to a minimum if at all possible ... tends to make things work better :-) |
| 16:29.36 | TheDavidFactor | is ctooley a committer? |
| 16:30.03 | Corydon76-dig | Yes |
| 16:30.06 | russellb | seanbright: I will mail you a digium pen |
| 16:30.27 | Corydon76-dig | seanbright: I will mail you a Digum screwdriver |
| 16:30.31 | TheDavidFactor | I talk to him a lot off list, I'll try to get him to review some of this stuff for me. |
| 16:31.03 | Corydon76-dig | seanbright: that's orange juice and vodka... |
| 16:31.18 | TheDavidFactor | with a Digum logo on the glass? |
| 16:31.19 | Kobaz | what's the rule for patch submission context |
| 16:31.32 | Corydon76-dig | No, just mixed by a Digium employee |
| 16:31.37 | Kobaz | like... are there rules saying that the patch must kind of address all the same stuff |
| 16:31.56 | Kobaz | or can different changes be mixed into one patch, if it's all in the same module |
| 16:32.25 | russellb | Kobaz: ideally as broken up as you can make them, much easier to review that way |
| 16:32.26 | Corydon76-dig | The rules say that everything contained in the patch must be detailed in the commit message |
| 16:32.55 | Corydon76-dig | or you will receive a beatdown |
| 16:33.21 | Kobaz | k, so i'll do two patches |
| 16:34.32 | seanbright | Kobaz: at a glance the other day, the only thing that jumped out at me that i didn't like was exposing the raw rd/wrlock stuff as functions |
| 16:34.44 | seanbright | rather than doing something kind callback-foreach thing |
| 16:35.08 | Kobaz | well |
| 16:35.08 | *** join/#asterisk-dev uluatu (n=uluatu@189.58.22.227.dynamic.adsl.gvt.net.br) |
| 16:35.16 | Kobaz | i modeled the same behavoir as the existing group functions |
| 16:35.26 | Kobaz | ideally the whole group infrastructure should be rewritten |
| 16:35.52 | seanbright | the existing group functions exposed linked list functions? |
| 16:35.56 | Kobaz | yes |
| 16:36.00 | seanbright | strange |
| 16:36.10 | Kobaz | same exact style |
| 16:37.37 | Kobaz | i was going to rewrite it all, but i wanted some input on my first go before i started ripping stuff apart |
| 16:38.50 | Kobaz | seems silly to have a linked list of group,category,channel |
| 16:39.18 | Kobaz | if you have thousands of groups in thousands of channels, why traverse the entire list to remove one channel |
| 16:40.06 | Kobaz | can you register custom data storage in a channel struct? |
| 16:40.34 | Kobaz | ideally the channel should have pointers into the groups it's in... and then have one linked list of groups... and then pointers from the groups to the channels |
| 16:41.16 | seanbright | yeah, it's called a datastore |
| 16:41.37 | Kobaz | k, then that could be used for the channel to group pointers then |
| 16:43.41 | Kobaz | i tried to keep the existing group functionality the same, and just tacked on the additional features unobtrusively |
| 16:45.22 | *** join/#asterisk-dev CunningPike (n=CunningP@204.239.8.157) |
| 16:51.04 | *** join/#asterisk-dev Deeewayne (n=dwayne@75.76.254.162) |
| 16:51.04 | *** mode/#asterisk-dev [+o Deeewayne] by ChanServ |
| 16:55.32 | *** join/#asterisk-dev jtodd (i=m2amrf88@asterisk/community-director-and-tie-dye-shirt-lover/jtodd) |
| 16:55.32 | *** mode/#asterisk-dev [+o jtodd] by ChanServ |
| 16:55.35 | seanbright | russellb: won't that configure change get blown away the next time configure is regenerated? |
| 16:56.20 | seanbright | oh i see. the committer didn't check that file in. nm. |
| 16:56.22 | russellb | configure.ac was previously modified. All I did is run bootstrap.sh |
| 16:56.40 | russellb | he didn't merge it because his autoconf version was different |
| 16:56.43 | seanbright | ah |
| 17:07.55 | *** join/#asterisk-dev elguero (n=_miguel3@12.187.84.162) |
| 17:53.05 | Kobaz | where did app_meetme go in mantis |
| 17:53.18 | Kobaz | never mind, i just can't see |
| 17:53.19 | *** join/#asterisk-dev puzzled_ (n=patrick@puzzled.xs4all.nl) |
| 18:00.46 | Kobaz | didn't it used to show your karma next to your name |
| 18:04.48 | leifmadsen | Kobaz: used to, yes |
| 18:06.32 | *** join/#asterisk-dev sruffell (n=sruffell@asterisk/the-kernel-guy/sruffell) |
| 18:06.32 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 18:10.07 | Kobaz | did karma go away? |
| 18:10.12 | russellb | yup |
| 18:10.16 | Kobaz | aw |
| 18:10.18 | Kobaz | i was up to 2.5 |
| 18:10.24 | Kobaz | all that hard work |
| 18:11.11 | russellb | it was no longer a fit for how our development community operates |
| 18:11.28 | Kobaz | so how does it operate now? |
| 18:11.48 | russellb | Well, when that was designed and implemented, virtually _all_ code went through mantis |
| 18:12.11 | russellb | now, a significant amount of work bypasses mantis |
| 18:12.17 | moy | russellb: may be should be kept for ppl without commit access? |
| 18:12.19 | russellb | at that point, it was all code going through a single person via mantis |
| 18:12.28 | Kobaz | ah |
| 18:12.37 | Kobaz | how do you track work that bypasses mantis |
| 18:12.38 | russellb | now people commit directly, review between each other via reviewboard, ... |
| 18:13.11 | russellb | we have release summary files that go with each release, that show who is commiting code, submitting patches, filing bug reports, etc., that resulted in changes going into a release |
| 18:13.34 | russellb | so, that is the current approach for giving credit to who contributed toward what became a release |
| 18:17.44 | *** join/#asterisk-dev atis_work (n=atis_wor@193.238.212.171) |
| 18:17.44 | seanbright | kpfleming: ping |
| 18:18.08 | kpfleming | pong... sort of |
| 18:18.51 | seanbright | ast_calloc_with_stringfields - should ast_string_field_free_memory() still be called on objects allocated that way? |
| 18:20.20 | kpfleming | yes |
| 18:20.35 | kpfleming | ast_free() cannot know that it has embedded stringfields |
| 18:20.35 | Kobaz | i gots a meetme question coming up |
| 18:20.45 | seanbright | cool |
| 18:20.46 | seanbright | thanks |
| 18:30.06 | Kobaz | okay so |
| 18:30.27 | Kobaz | when meetme is playing musiconhold... it uses it's own local variable for storing what music on hold class was passed to meetme |
| 18:30.44 | Kobaz | conf_start_moh |
| 18:31.29 | Kobaz | actually, hmm |
| 18:33.37 | *** join/#asterisk-dev puzzled (n=foobar@puzzled.xs4all.nl) |
| 18:42.44 | Kobaz | okay so |
| 18:42.48 | Kobaz | this function is really weird |
| 18:43.14 | Kobaz | http://pastebin.ca/1752648 |
| 18:43.36 | Kobaz | comments are mine, to just clarify what's going on |
| 18:44.35 | file | the musicclass on the channel takes priority |
| 18:44.48 | Kobaz | okay |
| 18:45.04 | Kobaz | but that function doesn't implement that idea |
| 18:45.22 | Kobaz | musicclass never gets used |
| 18:45.29 | file | sure it does. |
| 18:45.30 | Kobaz | other than copying back and fourth in the channe |
| 18:45.42 | file | the ast_string_field_set changes musicclass on the channel |
| 18:45.51 | Kobaz | to the original one |
| 18:45.52 | file | and res_musiconhold looks at that internally when determining what musicclass to use |
| 18:46.06 | Kobaz | ast_string_field_set(chan, musicclass, original_moh); |
| 18:46.14 | Kobaz | it puts back, what musicclass was, before the function was called |
| 18:46.14 | file | before ast_moh_start is called |
| 18:46.22 | file | yes. |
| 18:46.31 | file | before ast_moh_start is called: |
| 18:46.33 | file | ast_string_field_set(chan, musicclass, musicclass); |
| 18:46.34 | Kobaz | but ast_moh_start is called with the original musicclass too |
| 18:46.43 | file | doesn't matter |
| 18:46.55 | Kobaz | does it handle the override in ast_moh_start ? |
| 18:46.56 | file | internally in res_musiconhold the priority is chan->musicclass and THEN the value given to ast_moh_start |
| 18:47.07 | Kobaz | okay |
| 18:47.28 | Kobaz | i'm trying to find the proper way to start and stop the music in meetme, and i saw that function and it looked quite strange |
| 18:47.57 | Kobaz | it looked like it was backing up the current music, starting the current music, and putting the current music back |
| 18:50.00 | Kobaz | so if chan->musicclass is undefined it'll use the one passed in |
| 18:50.33 | Kobaz | i'm fixing meetmemute, so that it announces to the user that they have been muted/unmuted |
| 18:51.02 | Kobaz | but i don't have access to the music option that meetme was given since it's local to meetme_exec |
| 18:51.07 | Kobaz | er, conf_exec |
| 18:55.22 | Kobaz | http://pastebin.ca/1752662 |
| 18:56.07 | Kobaz | i don't think that's the correct way to start and stop music... because it's not taking into account optargs[OPT_ARG_MOH_CLASS] |
| 19:14.12 | Kobaz | eats some lunch |
| 19:17.18 | *** join/#asterisk-dev atis_work (n=atis_wor@193.238.212.171) |
| 19:44.17 | *** join/#asterisk-dev jeffg (n=jeffg@pdpc/supporter/professional/jeffg) |
| 20:18.13 | *** join/#asterisk-dev atis_work (n=atis_wor@193.238.212.171) |
| 20:23.33 | putnopvut | FYI, there is a bug in trunk right now which causes a crash on startup if MALLOC_DEBUG is selected in menuselect. I'm about to start looking for possible reasons why, but if anyone has any immediate ideas for why, that would be great. The crash appears to happen when the UpdateConfig manager action allocates space for string fields. |
| 20:27.40 | seanbright | i have no ideas off hand |
| 20:29.17 | putnopvut | Rev 240368 appears to be the culprit. |
| 20:29.50 | putnopvut | The actual code changed there seems right. I wonder if there's some incompatibility between calloc_with_stringfields and MALLOC_DEBUG. |
| 20:31.11 | seanbright | hmm |
| 20:32.24 | seanbright | i can just revert the patch |
| 20:32.38 | seanbright | sorry about that. |
| 20:32.54 | putnopvut | Well, you could, but I'd rather figure out what the actual problem is :) |
| 20:33.09 | putnopvut | :q |
| 20:33.12 | putnopvut | oops |
| 20:33.33 | seanbright | were you trying to quit me? |
| 20:33.40 | putnopvut | I'd never do that! |
| 20:33.45 | seanbright | heh |
| 20:35.59 | Kobaz | The following issue is now READY FOR TESTING. |
| 20:36.02 | Kobaz | Group Variables |
| 20:36.08 | Kobaz | I <3 you guys |
| 20:44.08 | seanbright | putnopvut: nothing is jumping out at me. |
| 20:44.29 | putnopvut | same here. And since it is Friday afternoon, trying to read string field code is like trying to read Japanese. |
| 20:44.47 | seanbright | you have a |
| 20:44.52 | seanbright | backtrace? |
| 20:45.00 | putnopvut | I sure do. I'll pastebin it, sir! |
| 20:45.01 | seanbright | i wrapped that perfectly. |
| 20:45.10 | putnopvut | color me impressed |
| 20:46.00 | putnopvut | omg my terminal is being stupid. |
| 20:46.11 | putnopvut | I'm unable to copy and past text for some strange reason... |
| 20:47.06 | putnopvut | seanbright: http://pastebin.ca/1752783 |
| 20:48.49 | russellb | so file and func are passed in as NULL ... |
| 20:49.39 | russellb | because the string_field_mgr's owner_file and owner_func are NULL |
| 20:50.01 | putnopvut | Interesting. I suppose that info should be filled in if __AST_DEBUG_MALLOC is defined. |
| 20:50.15 | putnopvut | I'll write up a quick patch, yo! |
| 20:50.34 | seanbright | hmm |
| 20:50.58 | russellb | they need to be filled in automatically, yes |
| 20:51.04 | russellb | ... and currently I don't see them filled in anywhere |
| 20:51.07 | russellb | but I haven't looked very hard |
| 20:51.13 | russellb | I'll leave it in your capable hands, though. |
| 20:51.14 | putnopvut | Should be done in ast_calloc_with_stringfields |
| 20:51.27 | russellb | needs to be done when that _isn't_ used, too though |
| 20:51.29 | putnopvut | Currently, ast_string_field_init does it if the stringfields are alloced separately. |
| 20:51.45 | putnopvut | Which is why the change to calloc_with_stringfields caused the crash. |
| 20:52.17 | russellb | ah, k |
| 20:52.24 | seanbright | ahh... does ast_string_field_init still have to be called? that wouldn't make much sense |
| 20:52.43 | putnopvut | No, it's not called at all if calloc_with_stringfields is used. |
| 20:53.00 | seanbright | m'kay |
| 20:53.25 | seanbright | there are some places in the code that later calls ast_String_field_init to "reset" the string fields |
| 20:53.34 | seanbright | hopefully that is still kosher |
| 20:53.44 | putnopvut | hmm, not certain yet. |
| 20:54.24 | putnopvut | Adding the lines to set owner_file, owner_line, and owner_func at least are causing Asterisk to last beyond initial startup now :) |
| 20:55.23 | seanbright | that's a win |
| 20:55.32 | seanbright | takes the rest of the week off |
| 20:55.46 | seanbright | goes off to work on asterisk-cpp |
| 20:55.51 | putnopvut | butt |
| 20:56.17 | seanbright | eh? |
| 20:56.41 | putnopvut | I didn't say anything |
| 20:57.12 | seanbright | oh |
| 20:58.34 | Qwell | adds namespace specifiers to seanbright |
| 20:58.35 | Qwell | Take THAT |
| 20:59.55 | seanbright | bam |
| 21:12.47 | Corydon76-dig | seanbright: do you have time to do a code review? https://reviewboard.asterisk.org/r/378/ |
| 21:13.51 | russellb | R378 |
| 21:13.55 | MuffinMan | [R378] Added ability to perform SRV lookups for AGI URIs [Pending] Submitted by _brent_ => https://reviewboard.asterisk.org/r/378/ |
| 21:16.25 | seanbright | i had looked at it before and had no problems with it other than the 'h' |
| 21:16.37 | seanbright | i didn't understand where that came from |
| 21:17.19 | Corydon76-dig | High Availability AGI |
| 21:17.24 | seanbright | ahh |
| 21:22.08 | snuff-home | afternoon ppls :) |
| 21:22.40 | leifmadsen | yo |
| 21:23.50 | Kobaz | hmm |
| 21:23.56 | Kobaz | how do you do dialplan reload in trunk |
| 21:24.09 | Kobaz | all i see is dialplay [set/show/debug] |
| 21:24.14 | Kobaz | *plan |
| 21:24.18 | leifmadsen | should be dialplan reload |
| 21:24.57 | Kobaz | demo1*CLI> dialplan |
| 21:24.57 | Kobaz | debug set show |
| 21:25.19 | leifmadsen | odd |
| 21:25.21 | leifmadsen | seems like a bug |
| 21:25.37 | snuff-home | Corydon76-dig: i can fix those 2 issues.. (i hope) ;) |
| 21:25.46 | seanbright | Kobaz: is pbx_config.so loaded? |
| 21:26.15 | seanbright | do you use extensions.conf or extensions.ael? |
| 21:26.27 | seanbright | or lua |
| 21:27.35 | Kobaz | yeah i use extensions.ael along with exteconf to load some stuff into extensions.conf |
| 21:28.09 | Kobaz | okay i just loaded pbx_config |
| 21:28.21 | Kobaz | and now i get dialplan reload, and it loaded my odbc extensions.conf |
| 21:28.27 | Kobaz | it didn't autoload for some reason |
| 21:28.42 | seanbright | do you have an extensions.conf file? |
| 21:29.07 | Kobaz | just extensions.ael and extensions.lua |
| 21:29.18 | Kobaz | this same setup works in 1.6.0.x |
| 21:29.21 | Kobaz | and 1.6.1 too |
| 21:29.38 | Kobaz | i don't have an extensions.conf since it's loaded via extconfig odbc |
| 21:30.00 | seanbright | that's probably why pbx_config.so isn't loading. you can just do ael reload. |
| 21:30.29 | Kobaz | yeah i did an ael reload |
| 21:30.36 | Kobaz | but it doesn't do a dialplan/extensions.conf reload |
| 21:31.22 | seanbright | i thought you said you didn't have an extensions.conf? |
| 21:31.32 | Kobaz | i don't |
| 21:31.35 | Kobaz | not a physical file |
| 21:31.38 | Kobaz | it's remapped in extconfig |
| 21:31.52 | Kobaz | extensions.conf => odbc,pbx,asterisk.v_asterisk_ext_config |
| 21:32.24 | Kobaz | i did a touch on extensions.conf, and pbx_config didn't load |
| 21:34.02 | Kobaz | hmm wait |
| 21:35.21 | Kobaz | okay so, here's what happens |
| 21:35.30 | Kobaz | without an extensions.conf, it doesn't load pbx_config |
| 21:35.46 | Kobaz | with an empty extensions.conf, it does load pbx_config, but it doesn't pull extensions.conf from odbc |
| 21:35.58 | Kobaz | and then i do a dialplan reload... and it will actually pull it from odbc |
| 21:36.11 | Kobaz | but doesn't do it automatically like in 1.6.0/1.6.1 |
| 21:36.48 | Corydon76-dig | snuff-home: I wonder if we could make that option pop up in the CDR modules, directly under the related module... and have it be an option that is only selectable when the module is activated |
| 21:36.51 | Kobaz | so something is broken somewhere |
| 21:38.10 | *** join/#asterisk-dev Qwell (i=north@pdpc/sponsor/digium/Qwell) |
| 21:38.10 | *** mode/#asterisk-dev [+o Qwell] by ChanServ |
| 21:41.27 | Kobaz | something is wrong with the ael/extensions.conf merging too |
| 21:42.22 | snuff-home | i can try.. my menuselect foo is non existant.. but will try |
| 21:42.28 | seanbright | http://issues.asterisk.org/ |
| 21:42.37 | Kobaz | seanbright: yeah, heh |
| 21:49.32 | Kobaz | what's the appropriate use of the 'block' severity in mantis |
| 21:49.56 | *** join/#asterisk-dev xpot-mobile (n=xpot@173-14-232-121-Utah.hfc.comcastbusiness.net) |
| 21:50.07 | Kobaz | i've submitted stuff as a blocker, but then it got downgraded to minor... even though it's a complete block to using a specific feature/module/etc |
| 21:55.44 | leifmadsen | Kobaz: because 'block' means "blocks for next release" |
| 21:55.51 | leifmadsen | it really shouldn't be available to anyone but bug marshals |
| 21:56.53 | Kobaz | oh okay |
| 21:59.02 | putnopvut | seanbright, Kobaz: I was just catching up on commits and noticed the commit to res_timing_timerfd that seanbright made yesterday. What system did you find that doesn't support CLOCK_MONOTONIC? |
| 21:59.54 | Corydon76-dig | putnopvut: Older kernels |
| 22:00.04 | Kobaz | putnopvut: 2.6.23 |
| 22:00.17 | Kobaz | putnopvut: kernels earlier than 2.6.25 in general |
| 22:00.23 | russellb | so they backported the timer fd API ... |
| 22:00.24 | putnopvut | 2.6.23 shouldn't have any sort of timerfd support at all and thus shouldn't have passed the test in the configure script. |
| 22:00.29 | putnopvut | oh geez |
| 22:00.36 | Kobaz | putnopvut: well it passed |
| 22:00.38 | russellb | i guess, if the test passed |
| 22:00.51 | russellb | 2.6.23-distroMegaModifiedVersion? |
| 22:00.55 | putnopvut | I was thinking it was something like 2.6.28 that introduced timerfd support. |
| 22:00.56 | Kobaz | nope |
| 22:01.07 | Kobaz | mainline 2.6.23.14 |
| 22:01.12 | russellb | huh. |
| 22:01.21 | russellb | yeah, like putnopvut, I thought it was new in 2.6.27 or so |
| 22:01.29 | Kobaz | that's the kernel i tested on |
| 22:01.37 | Kobaz | the fd timer completely wacked out asterisk |
| 22:01.57 | Kobaz | i have a feeling it was infintely trying to create timers and failing, creating all kinds of cpu load and deadlocks... is my guess |
| 22:02.58 | seanbright | i can revert if you like |
| 22:03.21 | Kobaz | the clock_monotonic check, completely fixes that, since it won't load the module if it doesn't have it |
| 22:03.55 | putnopvut | Interesting, according to this manpage from kernel.org: http://www.kernel.org/doc/man-pages/online/pages/man2/timerfd_create.2.html |
| 22:03.57 | Kobaz | seanbright: i vote for keeping the check (unless it causes some problem for some reason) |
| 22:04.08 | putnopvut | 2.6.25 was the first version to have that. |
| 22:04.15 | Kobaz | yeap |
| 22:04.16 | Corydon76-dig | russellb: could also be that some distribution, whose initials are RH, has once again backported something without changing the version number |
| 22:04.16 | putnopvut | Kobaz: any idea what glibc version you were using? |
| 22:04.30 | Kobaz | and on my box... i get timerfd_create function not implemented |
| 22:04.33 | Kobaz | yeah, sec |
| 22:04.53 | Kobaz | ii libc6 2.10.1-3 |
| 22:05.12 | seanbright | so the error message is wrong |
| 22:05.14 | Corydon76-dig | implemented in the library, but not in the kernel |
| 22:05.17 | putnopvut | Ah, timerfd support was added in 2.8 |
| 22:05.23 | russellb | that'll do it |
| 22:05.27 | putnopvut | yep, Corydon76-dig has it. |
| 22:05.29 | russellb | so glibc has it, but not the kernel part? |
| 22:05.34 | Kobaz | yeah |
| 22:05.34 | russellb | d'oh |
| 22:05.50 | russellb | and the world has returned to a state of making sense. |
| 22:05.55 | Kobaz | heh |
| 22:05.57 | putnopvut | sort of :) |
| 22:06.05 | russellb | in this particular case. |
| 22:06.11 | putnopvut | Okay, I'll give you that. |
| 22:07.35 | putnopvut | I wonder if I should just change the configure script to use CLOCK_MONOTONIC in its call to timerfd_create instead of using 0 like I do now. |
| 22:07.48 | seanbright | oh. woops. |
| 22:07.49 | putnopvut | That would take care of the problem at configure time. |
| 22:07.53 | seanbright | i might have fucked up again. |
| 22:08.01 | putnopvut | no! |
| 22:08.01 | putnopvut | you?! |
| 22:08.09 | seanbright | that was uncalled for |
| 22:08.47 | Corydon76-dig | putnopvut: again, that's a define that would be in headers, but may not actually be in the kernel |
| 22:09.15 | putnopvut | Corydon76-dig: ah that makes sense. The error was happening at runtime and not compile time. |
| 22:09.16 | Kobaz | heh |
| 22:09.25 | Kobaz | there should be a runtime check and a compile time check |
| 22:09.34 | Kobaz | because i build on my build box... and run on other boxes |
| 22:09.35 | Corydon76-dig | The only way to detect whether it's in the kernel is a runtime test, which if you do at configure time, you'll piss off everybody trying to do cross-compiles for embedded platforms |
| 22:09.44 | putnopvut | yep |
| 22:09.46 | Kobaz | exactly |
| 22:10.03 | Kobaz | well. the compile time check should be like a warning, but not prevent it from being built |
| 22:10.15 | putnopvut | I was thinking the problem was that the module wasn't compiling due to the use of the undefined CLOCK_MONOTONIC symbol. But then I re-read everything and realized that wasn't right. |
| 22:10.29 | Corydon76-dig | compile time check can only detect if there's no support at userlevel |
| 22:13.09 | Corydon76-dig | I suppose that there might be a possible compile-time check, if you tried to compile against kernel headers... |
| 22:13.09 | seanbright | so what should i revert? |
| 22:13.11 | Kobaz | -- Added extension 's' priority 8 (CID match '') to invalidHandler (0x883ec18) |
| 22:13.18 | Kobaz | what's this cid match thing? |
| 22:13.26 | seanbright | #asterisk |
| 22:13.33 | Kobaz | fine fine :P |
| 22:14.00 | Corydon76-dig | seanbright: I'd say that unless we come up with a configure check that runs against kernel headers, probably nothing |
| 22:14.06 | seanbright | ah. good. |
| 22:16.02 | putnopvut | And now we're all smarter! |
| 22:16.50 | Corydon76-dig | We are? |
| 22:17.22 | putnopvut | YES! |
| 22:18.05 | Corydon76-dig | Odd, I don't feel smarter |
| 22:18.20 | russellb | do you feel dumber? |
| 22:18.56 | Corydon76-dig | only after watching Walker Texas Ranger |
| 22:29.52 | putnopvut | I have a question regarding module refcounts. Richard and I had a discussion about what would happen if, for instance, there were a SIP call completion transaction up and running and somebody unloaded chan_sip. I imagine that I need to make sure that as long as the call completion transaction is up and going that the module cannot be unloaded. |
| 22:30.27 | putnopvut | I guess that wasn't really a question. |
| 22:30.35 | putnopvut | But here's one. |
| 22:31.10 | Corydon76-dig | putnopvut: use ast_module_ref to explicitly increase/decrease the module refcount |
| 22:31.23 | putnopvut | Should I act as I described above? That is, do I prevent chan_sip from being unloaded? Or is it better to just unload chan_sip and cancel all CC transactions since it could mean waiting minutes or hours for the CC transaction to time out or complete. |
| 22:31.41 | Corydon76-dig | err ast_module_unref for the decrease |
| 22:32.16 | Corydon76-dig | putnopvut: both, since you can FORCE an unload from the command line |
| 22:32.52 | putnopvut | Corydon76-dig: so if I place the module ref and unref calls in, the user still has the opportunity to force an unload if he wishes? |
| 22:33.00 | Corydon76-dig | a forced unload overrides the module refcount |
| 22:33.16 | putnopvut | Cool. I'll add the module ref/unref calls as appropriate then. |
| 22:33.20 | putnopvut | THanks for the help! |
| 22:33.41 | Corydon76-dig | Just note that in many cases, a forced unload crashes Asterisk anyway, but it's a risk that the user takes by using that option |
| 22:34.00 | putnopvut | Okay! |
| 22:34.27 | Corydon76-dig | But a soft unload that consults the refcount should always be safe |
| 22:36.03 | Corydon76-dig | One thing that I changed in the recent past was to ensure that refcounts are consulted for a shutdown, otherwise you could get a crash on a restart/stop |
| 22:41.29 | Corydon76-dig | Basic idea was to ensure that modules got unload_module called in reverse dependency order |
| 22:43.08 | *** join/#asterisk-dev seanbright (n=sean@asterisk/contributor-and-bug-marshal/seanbright) |
| 22:43.09 | *** mode/#asterisk-dev [+o seanbright] by ChanServ |
| 22:43.27 | *** join/#asterisk-dev Daviey (n=Daviey@ubuntu/member/pdpc.gold.Daviey) |
| 22:55.06 | *** join/#asterisk-dev file (n=file@asterisk/developer-and-muffin-lover/file) |
| 22:56.45 | *** mode/#asterisk-dev [+o file] by ChanServ |
| 23:04.07 | *** join/#asterisk-dev Corydon76-dig (i=six@c-69-137-80-31.hsd1.tn.comcast.net) [NETSPLIT VICTIM] |
| 23:09.44 | *** mode/#asterisk-dev [+o Corydon76-dig] by ChanServ |
| 23:21.19 | *** join/#asterisk-dev jtodd (i=m2amrf88@asterisk/community-director-and-tie-dye-shirt-lover/jtodd) [NETSPLIT VICTIM] |
| 23:21.19 | *** join/#asterisk-dev CunningPike (n=CunningP@204.239.8.157) [NETSPLIT VICTIM] |
| 23:21.19 | *** join/#asterisk-dev marv[work] (n=timr@router.asteriasgi.com) [NETSPLIT VICTIM] |
| 23:21.19 | *** join/#asterisk-dev Gugge (n=gugge@vlan2.dlxhosting.dk) [NETSPLIT VICTIM] |
| 23:21.19 | *** join/#asterisk-dev snuff-home (n=snuffy@203.219.29.182) |
| 23:21.19 | *** join/#asterisk-dev kaii (n=kai@ciphron.de) [NETSPLIT VICTIM] |
| 23:21.19 | *** join/#asterisk-dev Kobaz (n=kobaz@its.kobaz.net) [NETSPLIT VICTIM] |
| 23:21.19 | *** mode/#asterisk-dev [+oo jtodd snuff-home] by irc.freenode.net |
| 23:21.31 | *** join/#asterisk-dev jetsnoc (n=brian@72.22.242.66) |
| 23:26.47 | *** join/#asterisk-dev Corydon76-dig (i=blue@c-69-137-80-31.hsd1.tn.comcast.net) |
| 23:32.49 | *** join/#asterisk-dev Deeewayne (n=dwayne@75.76.254.162) |
| 23:32.49 | *** join/#asterisk-dev jeffg (n=jeffg@pdpc/supporter/professional/jeffg) |
| 23:32.49 | *** join/#asterisk-dev key2 (n=key2@gob75-7-82-247-113-230.fbx.proxad.net) [NETSPLIT VICTIM] |
| 23:32.49 | *** join/#asterisk-dev russellb (n=russellb@asterisk/digium-open-source-team-lead/russellb) |
| 23:32.49 | *** join/#asterisk-dev angler (n=angler@pdpc/sponsor/digium/angler) |
| 23:32.49 | *** mode/#asterisk-dev [+oo Deeewayne russellb] by irc.freenode.net |
| 23:36.43 | *** mode/#asterisk-dev [+o Corydon76-dig] by ChanServ |
| 23:47.09 | *** join/#asterisk-dev Amorsen (n=Amorsen@94.127.50.7) |
| 23:47.48 | mvanbaak | hey all |
| 23:54.15 | *** join/#asterisk-dev jetsnoc (n=brian@72.22.242.66) [NETSPLIT VICTIM] |