| 00:25.32 | *** join/#asterisk-dev leedm777 (~leedm777@50-81-28-152.client.mchsi.com) |
| 01:38.08 | *** join/#asterisk-dev philippel (uid10480@gateway/web/irccloud.com/x-bgxoeircvmjaqnlf) |
| 01:38.09 | *** join/#asterisk-dev tm1000 (sid6728@gateway/web/irccloud.com/x-mbabzlykjttmvomo) |
| 01:40.25 | *** join/#asterisk-dev moy (sid47040@gateway/web/irccloud.com/x-pseikmpothworhng) |
| 01:40.37 | *** join/#asterisk-dev jameswf (uid27319@gateway/web/irccloud.com/x-dqdedoyslwditcuu) |
| 01:44.21 | *** join/#asterisk-dev GameGamer43 (sid5533@gateway/web/irccloud.com/x-ifoekapdzmavylfk) |
| 02:47.14 | *** join/#asterisk-dev leedm777 (~leedm777@50-81-28-152.client.mchsi.com) |
| 03:07.33 | *** join/#asterisk-dev leedm777 (~leedm777@50-81-28-152.client.mchsi.com) |
| 03:28.17 | *** join/#asterisk-dev superscrat (~asanders@99-194-177-34.dyn.centurytel.net) |
| 04:16.57 | *** join/#asterisk-dev leedm777 (~leedm777@50.81.28.152) |
| 05:47.24 | *** join/#asterisk-dev kasanop (~kasanop@ivanpoddubny.com) |
| 06:44.06 | *** join/#asterisk-dev hehol (~hehol@gatekeeper.loca.net) |
| 07:11.06 | *** join/#asterisk-dev pchero_work (~pchero@109.70.54.56) |
| 07:18.54 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 07:18.54 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 08:03.20 | *** join/#asterisk-dev oej (~oej@2a03:f0c0:1001:1000:fdc7:ca1d:a2be:27df) |
| 08:03.42 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 08:34.55 | *** join/#asterisk-dev snuff-home (~brad@203-219-29-182.tpgi.com.au) |
| 08:34.55 | *** mode/#asterisk-dev [+o snuff-home] by ChanServ |
| 08:37.05 | *** join/#asterisk-dev wdoekes (~walter@wjd.osso.nl) |
| 10:13.20 | *** join/#asterisk-dev doome_ (~doome@82.150.48.146) |
| 10:59.53 | *** join/#asterisk-dev mjordan (~mjordan@75.76.55.191) |
| 10:59.53 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 11:14.31 | *** join/#asterisk-dev oej (~oej@2a03:f0c0:1001:1000:fdc7:ca1d:a2be:27df) |
| 11:14.31 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 11:22.16 | *** join/#asterisk-dev mjordan (mjordan@nat/digium/x-jsubykusfawpnurw) |
| 11:22.16 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 12:13.30 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@216-191-106-163.dedicated.allstream.net) |
| 12:20.28 | *** join/#asterisk-dev leedm777 (~leedm777@50-81-28-152.client.mchsi.com) |
| 12:47.01 | *** join/#asterisk-dev gtjoseph (~gtj0@unaffiliated/gtj) |
| 13:28.03 | *** join/#asterisk-dev leedm777 (leedm777@nat/digium/x-xzdrjmhmumqxetrv) |
| 13:42.30 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 13:43.27 | *** join/#asterisk-dev sgalarneau (Adium@nat/digium/x-xtfsncfncqtfivwm) |
| 13:49.40 | *** join/#asterisk-dev sgriepentrog (sgriepentr@nat/digium/x-ydsjtyonpvcxtejt) |
| 13:58.00 | nbjoerg | hm. why is the function called ast_variable*s*_destroy? |
| 13:58.54 | coreyfarrell | because it destroys the list of variables, not just the first one |
| 13:59.08 | mjordan | dear god, we named a function correctly |
| 13:59.17 | coreyfarrell | amazing |
| 13:59.54 | nbjoerg | hm. so it is the type that is not consistently named :) |
| 13:59.58 | coreyfarrell | although since 'struct ast_variable' represents a list we kind of named that wrong |
| 14:00.08 | coreyfarrell | probably |
| 14:00.31 | sgalarneau | naming is hard |
| 14:01.24 | nbjoerg | hm. ast_xml_free_attr is nasty with the const casting... |
| 14:03.22 | coreyfarrell | nbjoerg: it happens. sometimes you want a variable to be const as far as the rest of the world is concerned, but in the end you need to free it. |
| 14:06.42 | coreyfarrell | any bamboo admin have a minute to look at the ref checks test job? master is broken, I think since git migration. |
| 14:10.17 | *** join/#asterisk-dev sruffell (sruffell@asterisk/the-kernel-guy/sruffell) |
| 14:10.17 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 14:15.38 | mjordan | coreyfarrell: since I'm (somewhat) back in the realm of the living, I can take a look at it today |
| 14:15.48 | mjordan | jenkins, jenkins, my kingdom for a jenkins |
| 14:17.04 | *** join/#asterisk-dev kharwell (kharwell@nat/digium/x-yjygnxqazukuxsdc) |
| 14:17.17 | coreyfarrell | great, thanks mjordan. if you can spare the build agent time it would be awesome to get a manual run once it's fixed. I want to compare the whole testsuite run against other work, but my system is too slow to run the full testsuite against two branches. |
| 14:19.36 | coreyfarrell | ^^ master is all I need to compare against, so if it's tight don't worry about 11 or 13. |
| 14:21.39 | mjordan | I'll run master in a sec |
| 14:26.37 | *** join/#asterisk-dev putnopvut (putnopvut@asterisk/master-of-queues/mmichelson) |
| 14:26.37 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 14:55.52 | *** join/#asterisk-dev rmudgett (rmudgett@nat/digium/x-umxjkaaeexbuzpuh) |
| 15:39.50 | *** join/#asterisk-dev oej (~oej@kosmos2.upsys.se) |
| 15:39.50 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 15:40.29 | gtjoseph | leedm777: got a few minutes for a endpoint stasis discussion? |
| 15:49.49 | leedm777 | gtjoseph: I've got a few minutes. Whassup? |
| 15:50.04 | gtjoseph | re: https://issues.asterisk.org/jira/browse/ASTERISK-25137 |
| 15:50.13 | nbjoerg | res/statis/control.c <-- does that currently give warnings about the const violations in line 150? |
| 15:50.14 | gtjoseph | and https://gerrit.asterisk.org/541 |
| 15:51.05 | gtjoseph | nbjoerg: not for me in 13 |
| 15:51.23 | nbjoerg | but do you agree that it does violate the constness? |
| 15:53.20 | gtjoseph | nbjoerg: hmmm. not sure.. you're not altering the structure in any way |
| 15:54.11 | gtjoseph | leedm777: my issue is that the patch works in normal asterisk operation but test_stasis_endpoint fails |
| 15:55.09 | gtjoseph | basically, i'm creating the endpoint's cached topic from all but never forwardng it to the tech topic's cached not all's cache |
| 15:55.29 | gtjoseph | oops... meant forwarinf to tech not all |
| 15:55.34 | coreyfarrell | nbjoerg: AO2 is interesting when it comes to const objects. for example __ao2_ref does not accept a const object, but technically it doesn't modify contents of the object, it modifies AO2 memory before the object. same with ao2_lock |
| 15:55.36 | nbjoerg | gtjoseph: it's locking a member of control, const is transitive? |
| 15:56.02 | nbjoerg | coreyfarrell: right |
| 15:56.37 | nbjoerg | the const seems to be artifical too |
| 15:56.42 | nbjoerg | none of the callers have it |
| 15:56.57 | coreyfarrell | nbjoerg: that's the thing, it's not actually locking a member of control, it's locking the AO2 object immediately before the control object in memory... |
| 15:57.30 | nbjoerg | http://www.netbsd.org/~joerg/control.c.diff |
| 15:57.52 | nbjoerg | the functions calling them don't have const on the control argument, so this seems to just ask for trouble unnecessarily? |
| 15:58.12 | nbjoerg | coreyfarrell: agreed |
| 15:58.30 | coreyfarrell | pretty sure the C compiler can make optimizations if it knows that an argument will not be modified during a procedure.. |
| 15:58.35 | gtjoseph | leedm777: are you pondering or waiting for more info from me? |
| 15:58.43 | leedm777 | pondering |
| 15:58.55 | mjordan | gtjoseph: I missed why the unit test fails |
| 15:58.57 | nbjoerg | coreyfarrell: not easily |
| 15:59.16 | nbjoerg | coreyfarrell: since it also has to proof that there are no aliases |
| 15:59.26 | gtjoseph | mjordan: I *think* it's trying to remove something from the all cache that isn't there |
| 16:00.10 | gtjoseph | but this is my first exposure to stasis so it's a little hard to follow |
| 16:00.53 | gtjoseph | ERROR[9633]: stasis_cache.c:845 caching_topic_exec: Attempting to remove an item from the TEST-cached cache that isn't there: ast_endpoint_snapshot_type TEST/state_changes |
| 16:00.55 | mjordan | well, this is also one of the more goofy uses of it. |
| 16:01.32 | coreyfarrell | nbjoerg: point is that it's possible for that optimization with the argument const.. without the const no attempt is made. this might be crazy but maybe ao2_lock / ao2_unlock could accept const void *user_data. |
| 16:02.42 | coreyfarrell | nbjoerg: ao2_ref can't be const since delta=-1 can destroy the object... but ao2_lock/ao2_unlock don't actually change any part of the structure pointed to by user_data. |
| 16:02.55 | mjordan | nbjoerg: not to argue with the semantics of what you are looking at, but is there a reason why you are looking at this kind of thing? |
| 16:03.19 | nbjoerg | mjordan: yes, the reason why I wanted to talk with you in first place :) |
| 16:03.31 | nbjoerg | mjordan: getting rid of nested functions and blocks dependency... |
| 16:03.59 | mjordan | gtjoseph: so, the idea was that subscribing to the technology topic gets you all the updates from all endpoints of that technology, and that all endpoints get all updates from all channels related to them. However, the tricky part is that you need both caching changes, as well as non-caching changes. |
| 16:04.04 | mjordan | er |
| 16:04.09 | mjordan | nbjoerg: probably not going to happen. |
| 16:04.24 | mjordan | I think I'd have a *VERY* concrete plan in place before tackling that. |
| 16:04.36 | mjordan | That is, understand RAII_VAR and what it is doing |
| 16:04.55 | nbjoerg | I know what it is and how it works |
| 16:05.03 | mjordan | k, so what's the concrete plan? |
| 16:05.23 | gtjoseph | mjordan: the idea was that since tech forwards to all anyway, don't forward endpoints to both, just to tech. |
| 16:05.44 | gtjoseph | the cache part is confusing |
| 16:05.54 | gtjoseph | why do we need both? |
| 16:05.54 | mjordan | so the non-caching messages were forwarded? |
| 16:05.55 | nbjoerg | let me put that back for a moment. there is one small API change I want to propose first to simplify some things |
| 16:05.58 | nbjoerg | http://www.netbsd.org/~joerg/scoped_rwlist.diff |
| 16:06.02 | mjordan | gtjoseph: they're technically two different topics |
| 16:06.11 | mjordan | and messages sent to a caching topic are not sent to the other topic |
| 16:06.16 | gtjoseph | yeah but why do there need to be 2? |
| 16:06.24 | mjordan | they have different purposes |
| 16:06.31 | mjordan | the caching topic shows diffs in a particular object state |
| 16:06.37 | mjordan | where that object is a struct |
| 16:06.42 | mjordan | messages are just "meh, here's some stuff" |
| 16:06.49 | mjordan | doesn't even have to represent a change in an object struct |
| 16:06.56 | mjordan | for example "someone start monitoring this channel" |
| 16:07.03 | mjordan | nothing changes on the channel snapshot |
| 16:08.00 | gtjoseph | ok, so i'm forwarding to both the tech's topic and the tech's cached topic ok |
| 16:08.13 | gtjoseph | that part works |
| 16:08.36 | gtjoseph | but i'm creating the endpoint's cached_topic in all's cache |
| 16:08.53 | gtjoseph | and I think that's where the test is getting confused |
| 16:09.05 | mjordan | that seems odd. |
| 16:09.32 | mjordan | everyone should have their own caching topic (endpoint, tech), and things should get forwarded along. The only forwarding relationship that shouldn't be created is endpoint => all |
| 16:10.16 | gtjoseph | yep, that'[s what i'm doing |
| 16:10.16 | mjordan | ah |
| 16:10.33 | mjordan | but stasis_cp_single_create always creates an implicit forwarding from the endpoint to the all topic |
| 16:10.41 | gtjoseph | not any more |
| 16:10.47 | mjordan | er |
| 16:10.50 | mjordan | it probably should |
| 16:10.54 | gtjoseph | i split that function so it doesn't auto forward to all |
| 16:11.02 | mjordan | and instead of specifying ast_endpoint_cache_all, just specify the tech topic |
| 16:11.16 | gtjoseph | can't |
| 16:11.20 | gtjoseph | different objects |
| 16:11.32 | gtjoseph | tech doesn't have a cache |
| 16:11.38 | gtjoseph | only all has a cache |
| 16:11.49 | nbjoerg | tcptls.c needs some DO_SSL love, it currently doesn't build without openssl headers btw |
| 16:11.59 | mjordan | gtjoseph: you could give the tech endpoint a cache |
| 16:12.01 | mjordan | or an all cache |
| 16:12.04 | nbjoerg | see __ssl_setup_certs |
| 16:12.30 | mjordan | nbjoerg: don't think we try building it without openssl. What you trying to compile it with? |
| 16:13.38 | nbjoerg | mjordan: I just didn't have the headers installed and it failed on that |
| 16:13.43 | gtjoseph | mjordan: so if a tech endpoint is created, create it as a stasis_cp_all instead of a stasis_cp_single? |
| 16:13.57 | nbjoerg | mjordan: from the conditionals, it looks like it is intended to be optional |
| 16:14.14 | mjordan | nbjoerg: as for the patch you pastebined, if you think the pattern of usage there will benefit from a RWLock, that's fine, but you may want to profile it a bit to see how it does when an ARI user does make some repeated subscribe/unsubscribes. |
| 16:14.40 | nbjoerg | mjordan: the patch is just shifting the definition |
| 16:14.44 | nbjoerg | mjordan: the locking itself is the same |
| 16:15.17 | mjordan | ah, missed that. |
| 16:15.47 | nbjoerg | mjordan: the original version needs the head type for the expansion of the dtor, that's what I want to avoid |
| 16:15.48 | mjordan | I'm ... ambivalent? I'm not sure having scoped macros for the list lock macros is that much clearer, but I'm not against it. |
| 16:16.38 | mjordan | nbjoerg: if tcptls.h is missing a conditional someplace, than by all means, please submit a patch |
| 16:16.50 | nbjoerg | ok |
| 16:16.52 | leedm777 | gtjoseph: I've gotta run. It's not immediately obvious to me what's going on, but maybe mjordan has some ideas. |
| 16:17.01 | leedm777 | I'll look again when I get back. |
| 16:17.02 | gtjoseph | no worries |
| 16:24.18 | gtjoseph | mjordan: are there other scenarios where we're publishing to an intermediate topic? |
| 16:24.44 | mjordan | I don't think so. Endpoints are the most complex. Device state might be the next one |
| 16:26.04 | gtjoseph | doesn't look like it's doipng an intermediate publish |
| 16:27.50 | mjordan | hm. Technically, manager would have that, although it's still simpler. channel caching topic => all caching => ami topic |
| 16:28.02 | mjordan | but again, nothing does the gyrations quite like endpoints. |
| 16:41.01 | nbjoerg | yay, gerrit kills firefox. go mozilla, go! |
| 16:41.16 | mjordan | works on my firefox... :-P |
| 16:42.01 | nbjoerg | and 100% reproducable too! just open a review and hit cursor down :) |
| 16:43.15 | mjordan | still works fine for me... |
| 16:51.15 | gtjoseph | mjordan: ran testsuite res_api with my original patch and 91/94 passed with 3 that fail even without my patch. I'm *thinking* the issue is with the unit test. |
| 16:51.26 | gtjoseph | s/res_api/rest_api/ |
| 16:52.09 | mjordan | gtjoseph: that's quite possible |
| 16:52.30 | gtjoseph | i'm running pjsip now |
| 16:52.41 | mjordan | gtjoseph: one thing I've done in the past when debugging that unit test is instrument the fake stasis callbacks with log messages that dump out the exact messages that they get |
| 16:52.56 | gtjoseph | yeah good idea |
| 16:52.58 | mjordan | it may be just that the ordering of the messages is different, which will cause them to fail |
| 16:53.06 | gtjoseph | my eyes hurt when i look at that test |
| 16:53.09 | mjordan | heh |
| 16:53.15 | mjordan | it's a bit confusing |
| 17:03.33 | file | rmudgett, did you want to wait on further response from Y Ateya on 169? |
| 17:04.36 | rmudgett | file: A few more days. That patch will need to be cherry picked to 13 at least |
| 17:04.40 | gtjoseph | mjordan: figured it out. when the endpoint is shut down, the forwards are canceled but it's not being removed from the cache. The test is waiting for the cache remove notification and not getting it. |
| 17:04.48 | file | rmudgett, k |
| 17:05.20 | file | 16 patch sets, yow'sa |
| 17:05.27 | mjordan | gtjoseph: interesting |
| 17:05.38 | gtjoseph | makes perfect sense now |
| 17:05.39 | mjordan | file: twas quite the review |
| 17:05.51 | file | well - chan_iax2 |
| 17:05.56 | mjordan | file: exactly |
| 17:32.51 | rmudgett | Looks like I broke the build on master. :( |
| 17:35.45 | file | that you did, that you did |
| 18:06.38 | mjordan | heh |
| 18:06.42 | mjordan | and I ran your patch on 13 with the tests |
| 18:06.45 | mjordan | that's funny |
| 18:07.50 | *** join/#asterisk-dev JunK-Y (~junky@pdpc/supporter/active/junk-y) |
| 18:18.40 | nbjoerg | hm. in addons/ooh323c/src/Makefile.in, isn't the path to mkinstalldirs wrong? |
| 18:21.28 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-179-40-172.cust.bezeqint.net) |
| 18:21.28 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 18:22.08 | *** join/#asterisk-dev Jayka__ (9edeee1e@gateway/web/freenode/ip.158.222.238.30) |
| 18:38.22 | coreyfarrell | nbjoerg: most of us don't work with addons |
| 18:39.02 | nbjoerg | just saw it while grepping around |
| 18:39.17 | nbjoerg | seems like a left over from some code moves? |
| 18:41.12 | coreyfarrell | dunno, addons don't get much attention. |
| 19:36.38 | *** join/#asterisk-dev leedm777 (~leedm777@50-81-28-152.client.mchsi.com) |
| 20:43.07 | *** join/#asterisk-dev sgriepentrog (~sgriepent@2602:30a:2ef2:840:20c:29ff:fe4f:cac8) |
| 20:54.21 | X-Rob | Ooh |
| 20:54.24 | X-Rob | I think I found a new bug. |
| 20:54.32 | X-Rob | can't mixmon calls picked up from a parking lot. |
| 20:54.52 | X-Rob | with a lot of this in the log audiohook.c: Read factory 0x282f0f8 and write factory 0x282fb38 both fail to provide 160 samples |
| 20:58.13 | *** join/#asterisk-dev Marquis42 (~mrbmw@d14-69-246-193.try.wideopenwest.com) |
| 21:02.10 | *** join/#asterisk-dev superscrat (~asanders@99-194-177-34.dyn.centurytel.net) |
| 21:02.26 | X-Rob | https://issues.asterisk.org/jira/browse/ASTERISK-25145 |
| 21:16.30 | *** join/#asterisk-dev [TK]D-Fender (~joe@64.235.216.2) |
| 21:17.54 | mjordan | X-Rob: so that in the log is actually normal (although SUPER misleading) |
| 21:18.08 | X-Rob | mjordan: ahha. |
| 21:18.15 | X-Rob | did not know that. |
| 21:18.27 | mjordan | yeah, I hate that debug message |
| 21:18.39 | mjordan | you might be getting hit with a bug that just got fixed |
| 21:18.42 | mjordan | what version is that, 13.3? |
| 21:19.00 | mjordan | someone (meaning me) broke MixMonitor in a few caess |
| 21:19.01 | mjordan | er, cases |
| 21:19.01 | X-Rob | mjordan: 13.3.2 |
| 21:19.12 | mjordan | mind trying with the latest from the tip of git, or with 13.4.0-rc1? |
| 21:19.50 | mjordan | it will be fixed in 13.4.0, which really should be out already except that I've been in Germany and then got hit with a virus that caused me to see alligators wearing funny hats |
| 21:19.52 | X-Rob | <PROTECTED> |
| 21:19.56 | mjordan | yup |
| 21:19.58 | mjordan | that's the bug |
| 21:20.05 | mjordan | it only happens with wide-band audio |
| 21:20.19 | mjordan | try with 13.4.0 or the latest, but I'd guess that it's fixed |
| 21:20.28 | X-Rob | I told you in Canada I was the bastard that wants everyone to run g722 |
| 21:21.13 | X-Rob | Also, that virus sounds awesome. |
| 21:23.59 | mjordan | X-Rob: it was, except that it really hit halfway across the Atlantic |
| 21:24.10 | mjordan | looongest plane trip of my life |
| 21:27.23 | X-Rob | mjordan: bugger. Also, confirmed only exists when there's a wideband leg involved. Commenting on the ticket. |
| 21:27.37 | mjordan | yeah, that's pretty much identical of the issue we just fixed |
| 21:27.42 | mjordan | hold on, I'll get you that issue number |
| 21:28.16 | mjordan | https://issues.asterisk.org/jira/browse/ASTERISK-24944 |
| 21:28.33 | mjordan | along with ASTERISK-25005 and ASTERISK-25142 |
| 21:28.35 | mjordan | er |
| 21:28.45 | mjordan | I need to resurrect a bot in here. |
| 21:28.55 | mjordan | https://issues.asterisk.org/jira/browse/ASTERISK-25005 |
| 21:28.59 | mjordan | https://issues.asterisk.org/jira/browse/ASTERISK-25142 |
| 21:29.27 | mjordan | X-Rob: I'll probably get the release made tomorrow, if you want to wait a day |
| 21:29.49 | mjordan | of course, GamerGate is on honeymoon, so who's going to make the packages? :-) |
| 21:29.53 | X-Rob | mjordan: sounds fine. I was going to link them, but I don't have permissions |
| 21:30.01 | mjordan | X-Rob: I'll take care of it |
| 21:30.23 | X-Rob | Cool |
| 21:30.35 | X-Rob | So yeah, mark it as fixed and I'll check it out in 13.4 |
| 21:30.47 | X-Rob | thanks! |
| 21:31.25 | mjordan | no prob, I'll close it out once you've got a chance to confirm it though, just in case it is something funky and strange that we missed |
| 21:32.30 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 21:32.31 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 21:46.37 | *** join/#asterisk-dev sgalarneau (~Adium@user-24-96-87-214.knology.net) |
| 22:12.45 | roramirez | i have seen repeated code related to PostgreSQL in res_config_pgsql cel_pgsql cdr_pgsql. I think should be only one part. Could add in res_config_pgsql but i dont know is a good idea. |
| 22:15.36 | coreyfarrell | roramirez: the problem is that cel_pgsql and cdr_pgsql do not require res_config_pgsql, they all link to the pgsql system libs directly |
| 22:27.08 | roramirez | coreyfarrell: yes, this a good point. Other idea could be a "utils" functions for pgsql |
| 22:31.52 | coreyfarrell | depends on if there is enough to warrant a pgsql utils module. users would have to preload the utils module before you preload res_config_pgsql. |
| 22:35.15 | roramirez | where it should go this module ?, exists other these kind? |
| 22:37.02 | coreyfarrell | I don't understand the question |
| 22:39.48 | roramirez | where to go this module? (utils pgsql) |
| 22:40.30 | roramirez | ... in the tree of code |
| 22:47.33 | *** join/#asterisk-dev X-Rob (X-Rob@gateway/web/irccloud.com/x-vhlxpchpymvipckz) |
| 22:49.06 | coreyfarrell | probably res/ |
| 23:00.21 | *** join/#asterisk-dev moy (sid47040@gateway/web/irccloud.com/x-zwshoambeoteynwq) |
| 23:10.12 | roramirez | ok coreyfarrell, thanks you! |
| 23:13.48 | *** part/#asterisk-dev kharwell (kharwell@nat/digium/x-yjygnxqazukuxsdc) |
| 23:17.32 | *** join/#asterisk-dev X-Rob_ (sid14615@gateway/web/irccloud.com/x-hjtbottfjmlyeupp) |