| 00:19.45 | *** join/#asterisk-dev dseeb_ (~Adium@CPE-124-187-225-74.lns1.dav.bigpond.net.au) |
| 00:19.53 | *** join/#asterisk-dev otherwiseguy (~terry@cpe-69-76-217-40.kc.res.rr.com) |
| 01:35.26 | *** join/#asterisk-dev sruffell (~Adium@asterisk/the-kernel-guy/sruffell) |
| 01:35.26 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 01:49.19 | *** join/#asterisk-dev seraphie (~erin@75.76.38.159) |
| 02:04.03 | *** join/#asterisk-dev mjordan (~mjordan@user-69-1-6-49.knology.net) |
| 02:04.03 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 02:22.08 | *** part/#asterisk-dev dseeb_ (~Adium@CPE-124-187-225-74.lns1.dav.bigpond.net.au) |
| 02:47.38 | *** part/#asterisk-dev mjordan (~mjordan@user-69-1-6-49.knology.net) |
| 03:01.20 | *** join/#asterisk-dev sruffell (~Adium@asterisk/the-kernel-guy/sruffell) |
| 03:01.20 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 03:34.14 | *** join/#asterisk-dev snuff-work (~snuff-wor@210.9.82.197) |
| 03:34.15 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 03:36.05 | Kobaz | where is everyone these days |
| 03:39.23 | snuff-work | sleeping? |
| 03:40.36 | Kobaz | mmm |
| 03:40.41 | Kobaz | could be |
| 04:34.38 | *** join/#asterisk-dev irroot (~irroot@41.123.188.35) |
| 05:14.11 | *** join/#asterisk-dev tzafrir (~tzafrir@212.179.75.202) |
| 05:14.11 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 05:54.49 | *** join/#asterisk-dev irroot (~irroot@41.122.163.3) |
| 06:27.53 | *** join/#asterisk-dev oej (~olle@ns.webway.se) |
| 06:27.53 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 06:56.33 | *** join/#asterisk-dev irroot (~irroot@pbx.distrotech.co.za) |
| 07:19.03 | *** join/#asterisk-dev tamiel (~tamiel@213.30.183.226) |
| 08:04.51 | *** join/#asterisk-dev hehol (~hehol@2001:1438:1009:200:5c93:3e5a:161:f376) |
| 08:09.30 | oej | Hello folks |
| 08:40.42 | jmls | lol |
| 08:40.44 | jmls | <PROTECTED> |
| 09:05.39 | jmls | so, what's the difference between VALID_EXTEN and DIALPLAN_EXISTS ? |
| 09:07.48 | oej | One begins with uppercase V and the other with D ? |
| 09:07.53 | oej | don't know. |
| 09:17.42 | *** join/#asterisk-dev irroot (~irroot@pbx.distrotech.co.za) |
| 10:32.29 | *** join/#asterisk-dev irroot (~irroot@pbx.distrotech.co.za) |
| 10:37.30 | irroot | https://reviewboard.asterisk.org/r/1385/ mnicholson there some problems with the gwtimeout code appologies for not been arround more been hectic with stuff here |
| 11:18.22 | oej | mnicholson: ping |
| 11:21.26 | mvanbaak | oej: still alive???? |
| 11:23.16 | irroot | oej is a bot mvanbaak |
| 11:23.24 | irroot | :P |
| 11:23.31 | oej | Me is a bot. Yes. |
| 11:29.37 | oej | 7#333333*****22222 sorry wrong window |
| 11:35.19 | oej | IRC doesn't support DTMF. Let's fix. |
| 11:37.41 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 11:37.42 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 11:38.59 | oej | Morning kpfleming :-) |
| 11:40.01 | kpfleming | morning. friday has arrived. |
| 11:40.11 | oej | Yes. DTMF-day. |
| 11:40.24 | kpfleming | inband signaling needs to die. |
| 11:40.48 | oej | Yes. I have a campaign to stop it from entering the halls of RTCweb |
| 11:40.58 | irroot | kpfleming for president !!!! |
| 11:41.19 | oej | As long as kpfleming as president can change ETSI standards, I'm fine with that. |
| 11:42.01 | irroot | oej perhaps it may take a bribe im fine with that too |
| 11:42.23 | oej | As long as we can kill inband signalling. Fax and DTMF needs to go away. |
| 11:42.36 | kpfleming | irroot: good grief... i don't want to be president. presidents can't get anything accomplished. |
| 11:50.25 | irroot | kpfleming true that ... but there cool perks and you can delegate with plausiable denyability |
| 11:50.54 | oej | I don't want to be president either. But I can accept the salary though. |
| 11:56.43 | oej | kpfleming: I found out how to make the jira issue hidden (I think). |
| 11:59.03 | kpfleming | yeah.. you change the security level to 'Reporter, Bug Marshals and Digium' |
| 12:05.54 | kpfleming | irroot: bad karma in the next 10 lives... nice |
| 12:11.53 | irroot | kpfleming ok perhaps not all 10 :P |
| 12:12.20 | irroot | been real busy of late so not been 100% on asterisk |
| 12:13.58 | oej | kpfleming: at least someone has to log in to see it... |
| 12:14.08 | oej | needs to become friends with Jira |
| 12:15.14 | oej | Hmm. I changed the viewable to "Community developers" and it still says "Report, Bug Marshals and Digium" |
| 12:15.44 | oej | I wonder if "security level" and "viewable by" is the same optin |
| 12:15.49 | oej | s/optin/option/ |
| 12:17.00 | oej | Changes in edit mode to "viewable" doesn't seem to affect "security level" and "security level" doesn't exist in "edit" mode |
| 12:20.44 | kpfleming | no, those are not the same thing |
| 12:20.50 | kpfleming | the 'viewable' setting is for specific comments on the issue |
| 12:21.34 | kpfleming | you have the issue properly secured now |
| 12:22.04 | oej | Ok, thanks |
| 12:22.24 | oej | dives back to DTMF and Wireshark |
| 12:49.30 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-cflbpligeshhfczn) |
| 12:49.30 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 13:04.13 | *** join/#asterisk-dev miguel3239 (~miguel323@2001:470:1f06:12c4::2) |
| 13:05.11 | *** join/#asterisk-dev serafie (~erin@nat/digium/x-cgkrdunwhxrtcqbi) |
| 13:09.20 | *** join/#asterisk-dev malcolmd (~malcolmd@pdpc/sponsor/digium/malcolmd) |
| 13:09.20 | *** mode/#asterisk-dev [+o malcolmd] by ChanServ |
| 13:13.44 | *** join/#asterisk-dev irroot (~irroot@41.122.176.139) |
| 13:20.02 | oej | Hello everyone! Where have you been all my frame? (20 ms) |
| 13:21.50 | Marquis42 | oej: LOL |
| 13:24.43 | kpfleming | oej: would your prefer 2.5ms frames? Opus can do that. |
| 13:27.34 | oej | Oh god. That will cause havoc with DTMF. What did they think of? |
| 13:27.35 | jsmith | signs up for the "Campaign for Equally Sized Frames", just to be contrarian |
| 13:28.09 | oej | starts the campaign "Variable frame sizes for all!" |
| 13:30.40 | jsmith | oej: Only if your frames support multiplexing like "IAX2 Trunking" |
| 13:31.26 | oej | don't want to mix my variable frames with your equal frames, jsmith. They don't blend. |
| 13:31.58 | jsmith | You could put a variable number of equal frames in one of your variable-sized frames :-) |
| 13:32.04 | jsmith | calls that compromise |
| 13:33.48 | oej | I'd rather put an equal number of variable size frames in my RTP frames... |
| 13:34.10 | oej | and RTP has variable sized frames . . . |
| 13:36.20 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 13:36.20 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 13:37.33 | oej | putnopvut: Welcome to the discussion. Today's topic: Barbecue recipies for rabbits (roadkill mostly) |
| 13:38.21 | putnopvut | Hm, how long has it already been dead? |
| 13:38.22 | jsmith | Mmmmn.... rabbit |
| 13:38.23 | kpfleming | i like rabbit. it's delicious. |
| 13:38.33 | jsmith | likes it with a bit of sage and oregano |
| 13:38.47 | jsmith | I've also had it with a nice creamy dill sauce |
| 13:38.53 | irroot | neighbour has rabits dont think they will miss a few |
| 13:39.04 | putnopvut | irroot: they'll breed new ones soon enough |
| 13:39.07 | irroot | warthog is still the best meat to BBQ/Braai |
| 13:39.20 | jsmith | You can also use rosemary, but don't use too much -- it tends to overpower the flavor of the rabbit |
| 13:39.54 | putnopvut | I like my rabbits gray and with a Brooklyn accent |
| 13:40.52 | oej | Isn't that bunnies, putnopvut? |
| 13:40.59 | irroot | putnopvut mmm these are south african multi colored and speak with zulu accent |
| 13:41.17 | putnopvut | oej: same thing :) |
| 13:41.34 | oej | I wonder if Hefner would agree... |
| 13:42.22 | irroot | i would not bbq hefner think he may be a bit tough ... old meat is not so good |
| 13:43.42 | kpfleming | rabbit tastes exactly how i would expect a chicken with fuzzy floppy ears to taste |
| 13:44.34 | oej | ha ha ha. In Sweden, we don't have that kind of chickens. |
| 13:44.49 | kpfleming | not yet. just wait. |
| 13:45.16 | irroot | in nigeria they will sell you snake and call it rabbit |
| 13:51.47 | *** join/#asterisk-dev jeffg (~jeffg@pdpc/supporter/professional/jeffg) |
| 14:03.41 | *** join/#asterisk-dev russellb (~russellb@asterisk/contributor-and-cool-guy/russellb) |
| 14:03.42 | *** mode/#asterisk-dev [+o russellb] by ChanServ |
| 14:03.53 | *** join/#asterisk-dev jsmith (~jsmith@fedora/jsmith) |
| 14:03.53 | *** mode/#asterisk-dev [+o jsmith] by ChanServ |
| 14:04.07 | jmls | <PROTECTED> |
| 14:04.15 | jmls | looks at jsmith .. |
| 14:04.27 | irroot | hes on honeymoon i believe |
| 14:05.04 | jmls | weeellll, his wife better not see that he entered the room at 3:02:59, then ;) |
| 14:05.14 | jsmith | Yeah, no kidding... |
| 14:05.19 | jmls | lol |
| 14:05.34 | serafie | irroot: that's leifmadsen who is on his honeymoon |
| 14:06.02 | Qwell | serafie: I think he wanted jsmith to check the data on his tracking anklet |
| 14:06.05 | irroot | ah ok another astridoc guru then |
| 14:06.09 | Qwell | I mean, what anklet? |
| 14:06.11 | irroot | hehe |
| 14:06.13 | serafie | hehe |
| 14:07.19 | irroot | you welcome to put a tracking anklet on me right foot any time oh wait yeah dont got one good luck with that :P |
| 14:07.57 | Qwell | <.< |
| 14:07.58 | Qwell | >.> |
| 14:08.06 | *** join/#asterisk-dev serafie (~erin@nat/digium/x-lqhnnyfgphmttnbd) |
| 14:09.42 | jsmith | jmls: Something in particular I can help with? |
| 14:10.10 | *** join/#asterisk-dev dwmw2 (~ctrlproxy@twosheds.infradead.org) |
| 14:10.57 | jmls | jsmith: thanks. was wondering what's the difference between VALID_EXTEN and DIALPLAN_EXISTS ? |
| 14:11.36 | jsmith | jmls: Ah, good one :-) |
| 14:12.00 | jmls | thinks "that's a good start" |
| 14:12.29 | jsmith | jmls: To me, they appear to be identical |
| 14:12.49 | jmls | yeah, me too. That's why I wanted to speak to a documentation expert ;) |
| 14:12.50 | jsmith | jmls: I haven't looked at the implementation |
| 14:12.50 | jsmith | wonders when VALID_EXTEN snuck in |
| 14:13.15 | Qwell | what are these we're talking about? |
| 14:13.32 | Qwell | I know DIALPLAN_EXISTS() is a func |
| 14:13.40 | jmls | so is VALID_EXTEN |
| 14:13.41 | irroot | did the DIALPLAN_EXISTS code for 1.6 |
| 14:13.42 | jmls | ;) |
| 14:13.55 | irroot | so perhaps i can help |
| 14:14.03 | Qwell | jmls: I'm not seeing any reference to it in main/ or funcs/ |
| 14:14.30 | jmls | Asterisk SVN-branch-10-r332447 |
| 14:14.32 | Qwell | app_readexten |
| 14:15.01 | jmls | <PROTECTED> |
| 14:15.38 | jmls | looks like DIALPAL_EXISTS returns "1" if the extension exists |
| 14:15.53 | irroot | mmm seems VALID_EXTEN checks c,e,p where as dialplan exists also checks c|c,e |
| 14:16.18 | Qwell | c| ? |
| 14:16.37 | irroot | context or context,exten or context,exten,priority |
| 14:16.47 | Qwell | ahh right. yeah that's not enough to justify both |
| 14:16.55 | irroot | qwell dialplan_exists checks any aspect of DP |
| 14:17.02 | Qwell | huh |
| 14:17.07 | Qwell | VALID_EXTEN has been there since 81378 |
| 14:17.28 | jmls | chuckles |
| 14:17.37 | Qwell | vs 94799 |
| 14:18.08 | jmls | so, which one should I use ? :-D |
| 14:18.20 | Qwell | I would say DIALPLAN_EXISTS() |
| 14:18.42 | jmls | excellent. |
| 14:18.49 | jmls | doesn't have to change the dialplan |
| 14:18.55 | irroot | qwell that is why i submited DIALPLAN_EXISTS() |
| 14:19.35 | irroot | to be more flexiable check all aspects of dialplan and hehe did not realise VALID_EXTEN exits :P |
| 14:20.07 | Qwell | I don't understand why this function went into an app ;9 |
| 14:20.21 | jmls | irroot: apparently neither did anyone reviewing the submission ........:-! |
| 14:20.40 | irroot | that was circa 1.4 still |
| 14:20.53 | oej | We should have extended one instead of adding a new one. |
| 14:21.03 | jmls | yeah |
| 14:21.07 | jmls | nm |
| 14:21.21 | irroot | should i work on a alias ?? and merge ?? |
| 14:21.27 | jmls | i just thought that I was being dense ;) |
| 14:24.07 | *** join/#asterisk-dev sruffell (~Adium@asterisk/the-kernel-guy/sruffell) |
| 14:24.07 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 14:29.25 | dwmw2 | continues trolling for testers of his obviously-correct patch |
| 14:31.54 | seanbright | which one is that? |
| 14:34.47 | dwmw2 | https://issues.asterisk.org/jira/browse/ASTERISK-18331 |
| 14:35.11 | dwmw2 | at least the two important bits are ObviouslyCorrect⢠|
| 14:37.16 | seanbright | sent_rel is either 1 or 0? |
| 14:38.37 | *** join/#asterisk-dev The_Boy_Wonder (~vossel@asterisk/batman-developer/dvossel) |
| 14:38.37 | *** mode/#asterisk-dev [+o The_Boy_Wonder] by ChanServ |
| 14:39.37 | irroot | dwmw2 have you posted it on review board ?? |
| 14:39.59 | dwmw2 | I didn't think I was supposed to do that until told to do so in jira? How? |
| 14:41.07 | irroot | there a couple formating guideline violations there |
| 14:41.24 | irroot | https://reviewboard.asterisk.org |
| 14:41.44 | seanbright | dwmw2: make sent_rel a bit field |
| 14:41.52 | seanbright | ... sent_rel:1; |
| 14:42.10 | dwmw2 | should I fix the other things that should be bitfields first, then? |
| 14:42.23 | dwmw2 | ISTR there was at least one, so I tried to be consistent |
| 14:42.24 | seanbright | that struct could probably be reorganized to actually make those useful |
| 14:42.31 | seanbright | i.e. put them all at the end |
| 14:42.39 | dwmw2 | I was going for "simple and obviously correct" :) |
| 14:42.44 | dwmw2 | but OK, I can certainly do that. |
| 14:42.59 | seanbright | well that's fine, that can be another patch for another time |
| 14:43.29 | seanbright | of the 3 hunks, 1 and 3 look like no brainers |
| 14:43.48 | seanbright | err, i take that back. the link -> rename change will need a gander |
| 14:44.03 | dwmw2 | on that topic, see https://issues.asterisk.org/jira/browse/ASTERISK-16764?focusedCommentId=181464&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-181464 |
| 14:44.22 | *** join/#asterisk-dev moy (~moy@173.239.155.74) |
| 14:44.22 | *** join/#asterisk-dev Mw3 (mw3@mw3.hu) |
| 14:45.07 | dwmw2 | I think it's a bug in the inotify code. But it's one that we don't *need* to tickle. |
| 14:46.20 | dwmw2 | if (!link(a,b)) unlink(a); *is* a rename :) |
| 14:46.49 | dwmw2 | it's just that it gets seen differently by the inotify code and gives you the tiniest possibility of an error on the unlink() which we weren't handling anyway |
| 14:49.30 | dwmw2 | oh, there are bitfields in there already too |
| 14:49.45 | dwmw2 | just that the field I *looked* at wasn't (and could have been) |
| 14:53.11 | dwmw2 | irroot: thanks for looking; what were the formatting issues? |
| 14:53.45 | *** join/#asterisk-dev Qwell (~north@pdpc/sponsor/digium/Qwell) |
| 14:53.45 | *** mode/#asterisk-dev [+o Qwell] by ChanServ |
| 14:54.24 | irroot | use of braces in the conditionals it must be used and on same line as conditional |
| 14:54.26 | irroot | if (something) { |
| 14:54.28 | irroot | } else { |
| 14:54.30 | irroot | } |
| 14:54.41 | irroot | even if there is only one line |
| 14:54.58 | dwmw2 | you mean in the link/rename change? That was already like that. |
| 14:55.06 | dwmw2 | but I suppose I could change it while I'm there... |
| 14:55.29 | irroot | yeah its good neighbourly :P |
| 14:55.30 | dwmw2 | oh, and the if/else on h->sent_rel |
| 14:55.30 | dwmw2 | ok |
| 14:56.24 | irroot | https://reviewboard.asterisk.org/r/1173/ Allow Setting Auth Tag Bit length and make SRTP optional chan_sip any takers to look at this one its been stagnating and ive been using it at > 50 sites |
| 14:57.13 | oej | I haven't used SRTP and/or worked with the code so I can't really help there. |
| 14:57.50 | oej | But I know the feeling |
| 14:58.32 | irroot | thx oej +1 i did it for some older phones snom / yealink the new firmware does support both now the other was to add a "optional" element to SRTP as found in most phones / RFC |
| 14:59.58 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 14:59.58 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 15:00.09 | oej | I do NOT like adding a new option with two values and a comma. That's always cause for confusion |
| 15:00.56 | oej | Why do we need encryption=try ? |
| 15:00.59 | irroot | yeah they now 2 options the original proposal was 2 |
| 15:01.25 | irroot | asterisk will fail if the srtp is used and it is not sucsesfull |
| 15:01.41 | irroot | the try option will fail to rtp |
| 15:01.50 | oej | When is that useful, really? |
| 15:02.51 | irroot | phones have a optional srtp setting |
| 15:03.00 | irroot | this will match that |
| 15:03.15 | oej | I REALLY think this should be a dialplan issue, not hidden behaviour in the SIP channel. |
| 15:03.25 | irroot | i use it when connecting to a ITSP as defualt |
| 15:03.26 | oej | If you want to do that, do it in the dialplan |
| 15:03.58 | oej | It's like Polycom can offer an SDP with both SRTP and RTP as optional alternatives. That's not very useful. |
| 15:04.10 | irroot | it does admitidly introduce some headaches as the site on the other side will need to honor this |
| 15:04.11 | oej | If you want encryption, you want it. |
| 15:04.14 | kpfleming | agreed. we have decided not to offer any way to do 'optional' SRTP in Asterisk SCF. it's just not needed. |
| 15:04.27 | irroot | its also a security risk as the user may assume secure but its not |
| 15:04.34 | oej | Exactly! |
| 15:04.47 | irroot | ok ill strip that option off |
| 15:04.57 | Kobaz | do de do |
| 15:05.08 | Kobaz | so i'm working on background-agi |
| 15:05.10 | *** join/#asterisk-dev Crowb4r (u1012@gateway/web/irccloud.com/x-lccydbuzncqfhvwb) |
| 15:05.13 | oej | irroot: But make sure you can do something like that in the dialplan. |
| 15:05.24 | Kobaz | what sort of pitfalls should i be concerned about? |
| 15:05.33 | Qwell | Kobaz: killing it when the channel dies |
| 15:05.45 | oej | I would also recommend separating the ",32" to a separate option. |
| 15:05.48 | Kobaz | basically i'm firing off another thread and handling agi while the channel goes and bridges audio |
| 15:05.56 | Kobaz | Qwell: yeah i noticed that one |
| 15:06.08 | Qwell | xfers and such too |
| 15:06.09 | irroot | oej it has been done now no longer , i must update the discription |
| 15:06.10 | kpfleming | Kobaz: why not just use ExternalIVR? |
| 15:06.38 | oej | I think externalivr is the most hidden cool feature in Asterisk. People just don't discover it. |
| 15:06.39 | Kobaz | kpfleming: because I don't believe you can have it bridge in audio at the same time from another endpoint |
| 15:07.00 | irroot | encryption_taglen <- option either 32,80 for now |
| 15:07.14 | kpfleming | neither does AGI, and it's not appropriate for AGI |
| 15:07.15 | Kobaz | i want to fire off code from a pickup macro in the background |
| 15:07.19 | oej | Do we have underscores in option names? |
| 15:07.36 | kpfleming | how does STREAM FILE from an AGI behave if there are two channels bridged? |
| 15:07.42 | Kobaz | i have enough stuff running on pickup that there is a noticable delay |
| 15:08.20 | *** part/#asterisk-dev pnlarsson (~niklas@fw1.gml.g.icnet.infracom.se) |
| 15:08.50 | irroot | oej there plenty options with _ cant use - it breaks realtime :P |
| 15:08.56 | Kobaz | i could do it from the ami, but generally i much prefer working with agi |
| 15:08.58 | dwmw2 | oh, tits. That rename() change isn't quite as obviously correct as I thought. |
| 15:09.15 | dwmw2 | or maybe the code was broken before |
| 15:09.32 | kpfleming | Kobaz: what are you going to do from the AGI script while the bridge is active? |
| 15:09.36 | dwmw2 | no, the link() won't overwrite an existing spool file with the same name. |
| 15:09.52 | Kobaz | get lots of variables and record data about the call |
| 15:10.19 | irroot | oej ill remove the "try" option and leave the code in and get CHANNEL(srtp)=XXX to work with it or something like that |
| 15:10.26 | oej | irroot: Just checking :-) |
| 15:10.29 | kpfleming | it sounds like AGI is really overkill for this then |
| 15:10.39 | Kobaz | it would be a limited agi |
| 15:10.48 | oej | CHANNEL should not have an option called SRTP, it should be generic, like MEDIAENCRYPTION |
| 15:10.54 | oej | We're multiprotocol, you know. |
| 15:10.58 | kpfleming | MEDIASECURITY |
| 15:10.59 | Kobaz | basically get/set and some other stuff... it makes no sense to be able to do more since you're already talking to someone |
| 15:11.08 | kpfleming | the security might be provided by a means other than encryption |
| 15:11.11 | oej | I remember that Terry worked with dialplan settings for SRTP before |
| 15:11.37 | kpfleming | Kobaz: but if you 'set' a variable in an AGI that is connected to a pair of channels, where does the variable get set? |
| 15:11.38 | oej | kpfleming: right. Obscurity. "We convert your media to Z80 assembler code and transmit it on punch tape." |
| 15:11.53 | Kobaz | it's not connected to a pair |
| 15:11.55 | kpfleming | oej: no, i was thinking of circuit-switched bearers in SDP ;-) |
| 15:11.58 | oej | Sorry, Friday. |
| 15:12.06 | Kobaz | kpfleming: it's connected to the callee leg |
| 15:12.08 | oej | kpfleming: I guessed something like that. |
| 15:12.26 | Kobaz | or which ever leg called bagi |
| 15:12.48 | kpfleming | this is really what AMI is designed for. |
| 15:12.51 | oej | But the Z-80 assembler code stenography was a pretty cool idea though. The only problem is that I have to terminate friends that actually understand Z-80 assembly. |
| 15:13.02 | Kobaz | kpfleming: yeap |
| 15:13.27 | jsmith | oej: My first assembly was in Z-80 on the Commodore 128 (dual-booting between CP/M and Basic!) |
| 15:13.33 | kpfleming | use System() to launch a script that backgrounds itself, connects to AMI and manipulates the channel the way you want to do it |
| 15:13.39 | jsmith | loved the Z-80 chip |
| 15:13.51 | oej | jsmith: I know your address and where to find you online. |
| 15:13.54 | Kobaz | there's something about doing this with agi that makes a lot more sense in my head |
| 15:13.55 | kpfleming | modified Z-80 computers to overclock the CPUs to make them run superfast |
| 15:14.14 | jsmith | oej: If you kill me, at least let me taste some good lingonberry jam before I die :-) |
| 15:14.17 | dwmw2 | http://www.voip-info.org/wiki/view/Asterisk+auto-dial+out says in big red letters "do not create the file directly in the /var/spool/asterisk/outgoing directory" |
| 15:14.19 | oej | Ok, that's scary. I'll surrender Z-80 and go to Tops-10 then. |
| 15:14.20 | dwmw2 | is that still true? |
| 15:14.38 | jsmith | dwmw2: Yes... create the file in another directory, and then move it to the outgoing directory |
| 15:14.39 | oej | Too many Z-80 people in the community. |
| 15:14.51 | jsmith | dwmw2: Otherwise, Asterisk will try grabbing the file before you've finished writing it |
| 15:14.57 | dwmw2 | jsmith: so why does the inotify code go to such lengths to pander to broken users? |
| 15:15.12 | dwmw2 | it *won't*. It waits for an IN_CLOSE_WRITE event after it sees the IN_CREATE event. Which broke smsq. |
| 15:15.35 | Kobaz | i think i'll handle masquerades and cleanups with datastore fixup/free callbacks |
| 15:15.36 | dwmw2 | smsq creates it elsewhere and *links* it into the queue dir. Because link() won't overwrite an existing file, while rename() will. |
| 15:15.42 | kpfleming | dwmw2: you are correct, that warning is no longer valid for versions of asterisk that use inotify(). |
| 15:16.02 | dwmw2 | but the inotify code sees that as an IN_CREATE event, and waits forever for a subsequent IN_CLOSE_WRITE. |
| 15:16.10 | dwmw2 | So the perfectly valid thing that smsq was doing, has now broken |
| 15:16.13 | kpfleming | yeah... oops |
| 15:16.36 | kpfleming | of course, the population of people that actually use smsq is probably you and one other :) |
| 15:16.37 | dwmw2 | My first patch just made smsq use rename() instead... but I just realised that's broken too because now it can write over an existing spoolfile |
| 15:17.08 | jsmith | didn't realize that code had been rewritten to use inotify -- woo hoo! (except for the subsequent breakage of app_smsq) |
| 15:17.32 | dwmw2 | wouldn't it have been better to *notice* people creating files in place, bitch and refuse to run them? |
| 15:17.35 | dwmw2 | rather than pandering? |
| 15:17.51 | dwmw2 | at least they'd get a coherent error message rather than weird failures as a half-written file gets used |
| 15:18.30 | kpfleming | that warning about moving files was not because that was the *only* way it could work... it was just the safest way to avoid problems. |
| 15:18.40 | irroot | thx oej kpfleming ill strip off the srtp "try" bits and have it purely handle the taglen corectly for now a call with taglen of 32 fails as asterisk only supports 80 |
| 15:18.55 | jsmith | From what (little?) I remember, call files were added as somewhat of a hack in the beginning |
| 15:19.13 | oej | Everything was a hack in the beginning. |
| 15:19.24 | jsmith | They just got widely adopted before AMI and the Originate() app came around |
| 15:19.27 | kpfleming | even the earth? |
| 15:19.30 | oej | Then there was light and maybe red-bull. Unsure about the order. |
| 15:20.01 | oej | But the hack was first. Darwin was all wrong. |
| 15:20.28 | Qwell | oej: isn't that all evolution is? a series of hacks? |
| 15:20.52 | oej | Qwell: A series of hacks and some people gathering around the bug tracker to try to find the real fix. |
| 15:24.07 | dwmw2 | at the moment you have to behave differently according to whether inotify is used or not, right? |
| 15:24.27 | dwmw2 | something that has always been "absolutely wrong and broken" might actually work, depending on the phase of the moon and the setting of inotify |
| 15:24.28 | oej | right, as kpfleming stated earlier. |
| 15:25.17 | dwmw2 | I can 'fix' smsq to use a more unique name so that it can get away with rename() instead of link(). But the bug really lies in the inotify code I think |
| 15:25.44 | dwmw2 | I'd rather fix that to catch the "error" instead of pandering to it, and so it doesn't break when clients use link(). |
| 15:26.02 | dwmw2 | would I have difficulty getting consensus on that change? |
| 15:26.10 | kpfleming | thinks |
| 15:27.07 | kpfleming | is there no way to make the inotify code work with link() as the non-inotify code does? |
| 15:27.23 | dwmw2 | probably |
| 15:27.37 | kpfleming | that would likely be ideal, as both modes would work fine |
| 15:28.03 | dwmw2 | to we *want* the broken 'create it in-place and then write to it' mode to work? |
| 15:28.11 | dwmw2 | even though it won't *always* work, because it depends on inotify? |
| 15:28.20 | dwmw2 | should we make inotify non-optional? |
| 15:28.25 | kpfleming | well, that is the issue. on systems with inotify support, it's not broken. |
| 15:28.42 | kpfleming | it was always desired that 'create in place' mode would work, but before inotify it never did. |
| 15:28.44 | dwmw2 | it encourages broken users :) |
| 15:28.51 | kpfleming | no, it's not broken. |
| 15:29.33 | dwmw2 | Should I just change smsq to create-in-place and make it depend on inotify? |
| 15:29.41 | kpfleming | that would work, yes. |
| 15:30.00 | oej | Leaving. Good evening, friends. |
| 15:30.07 | kpfleming | smsq is built as part of the asterisk install, right? |
| 15:30.09 | dwmw2 | ok |
| 15:30.10 | dwmw2 | yes |
| 15:30.33 | kpfleming | well, then when smsq is built, you will know whether asterisk is goign to have inotify support or not, because the configure script has tested for it. |
| 15:30.38 | dwmw2 | yeah |
| 15:30.48 | kpfleming | so it could auto-detect, if you wanted to. |
| 15:30.53 | dwmw2 | ick :) |
| 15:30.56 | kpfleming | i know |
| 15:31.17 | kpfleming | but inotify is pretty widespread now for linux systems... so a large percentage of users will have it. |
| 15:31.42 | dwmw2 | I could put a timeout into the inotify code, so if no IN_CLOSE_WRITE happens on a file within a reasonable period of time (and no writes either) then it'll handle the file rather than waiting forever. |
| 15:32.04 | dwmw2 | that way it'd cope with the link() |
| 15:32.34 | kpfleming | interesting... it'd be great if at IN_CREATE time we could know that it was a link and then not have to wait |
| 15:32.41 | dwmw2 | on the whole, easier just to include $pid and $timestamp in the filename and use rename(). The only reason for link() instead of rename() was to avoid overwriting existing queue files. |
| 15:33.13 | dwmw2 | I don't think we have that information at IN_CREATE time |
| 15:33.18 | dwmw2 | we could check the size of the file, but not atomically. |
| 15:33.24 | dwmw2 | I think |
| 15:33.37 | dwmw2 | that would work, if it can be done. |
| 15:33.47 | dwmw2 | If we get IN_CREATE and the file is zero-length, *then* wait for a close |
| 15:35.11 | dwmw2 | hm, wonder if we can filter for IN_OPEN too. a create would be IN_CREATE|IN_OPEN perhaps |
| 15:35.16 | dwmw2 | while a link would be IN_CREATE only |
| 15:35.33 | kpfleming | yes, that can be done |
| 15:35.40 | dwmw2 | I'll go test |
| 15:40.42 | dwmw2 | yeah, I think that works |
| 15:41.09 | kpfleming | oo... nice |
| 15:50.31 | pabelanger | mjordan: psst... #asterisk-testing |
| 16:02.56 | dwmw2 | kpfleming: it'll look something like http://david.woodhou.se/pbx-handle-link.patch |
| 16:02.59 | dwmw2 | building and testing now |
| 16:03.42 | kpfleming | that looks good! |
| 16:03.49 | kpfleming | no timers or excess waiting |
| 16:04.13 | dwmw2 | I depend on the kernel giving me IN_CREATE before IN_OPEN, but I think that's valid |
| 16:04.25 | dwmw2 | they are *ordered* events, and create does happen before open :) |
| 16:04.44 | kpfleming | i would hope so! |
| 16:05.00 | dwmw2 | also a little confused that we seem to get a buffer with four events for the same file. The event is a bitmask but still we get it listed four times, each time with only *one* bit set |
| 16:05.14 | dwmw2 | and I depend on that continuing to happen too |
| 16:11.02 | dwmw2 | [Aug 26 17:10:39] NOTICE[5237]: pbx_spool.c:543 queue_file_create: File 'smsq.motx.0.1314375039-5241.1.call' created... |
| 16:11.02 | dwmw2 | [Aug 26 17:10:39] NOTICE[5237]: pbx_spool.c:573 queue_created_files: File 'smsq.motx.0.1314375039-5241.1.call' being processed now; not opened... |
| 16:11.02 | dwmw2 | <PROTECTED> |
| 16:11.22 | kpfleming | woot |
| 16:11.36 | dwmw2 | well, let me check that the other way still works before you get too excited :) |
| 16:13.13 | dwmw2 | [Aug 26 17:12:54] NOTICE[5237]: pbx_spool.c:543 queue_file_create: File 'smsq.motx.0.1314375107-5265.1.call' created... |
| 16:13.13 | dwmw2 | [Aug 26 17:12:54] NOTICE[5237]: pbx_spool.c:573 queue_created_files: File 'smsq.motx.0.1314375107-5265.1.call' being processed now; not opened... |
| 16:13.13 | dwmw2 | [Aug 26 17:12:54] WARNING[5237]: pbx_spool.c:254 apply_outgoing: At least one of app or extension must be specified, along with tech and dest in file /var/spool/asterisk/outgoing/smsq.motx.0.1314375107-5265.1.call |
| 16:13.13 | dwmw2 | [Aug 26 17:12:54] WARNING[5237]: pbx_spool.c:415 scan_service: Invalid file contents in /var/spool/asterisk/outgoing/smsq.motx.0.1314375107-5265.1.call, deleting |
| 16:13.16 | dwmw2 | oops :) |
| 16:26.25 | *** join/#asterisk-dev oej_ (~olle@ns.webway.se) |
| 16:26.25 | *** mode/#asterisk-dev [+o oej_] by ChanServ |
| 16:33.29 | dwmw2 | dammit, we do need a timeout |
| 16:33.42 | dwmw2 | the IN_CREATE and IN_OPEN can come in separate reads from inotify even though we have a large enough buffer |
| 16:33.53 | dwmw2 | but we have a timeout there already. I'll see if I can use it |
| 16:34.09 | kpfleming | once you said they arrive as separate events, that was a concern |
| 16:34.36 | dwmw2 | yeah. Although it's actually an atomic operation in the kernel so I don't quite see why they can get split up |
| 16:35.22 | kpfleming | did you actually see it happen, or are you just trying to make it won't break the world? |
| 16:35.30 | dwmw2 | I saw it |
| 16:35.46 | dwmw2 | [Aug 26 17:32:56] NOTICE[7154]: pbx_spool.c:673 scan_thread: Read 32 bytes from inotify |
| 16:35.46 | dwmw2 | [Aug 26 17:32:56] NOTICE[7154]: pbx_spool.c:676 scan_thread: Event 256 for file 'foo' |
| 16:35.46 | dwmw2 | [Aug 26 17:32:56] NOTICE[7154]: pbx_spool.c:543 queue_file_create: File 'foo' created... |
| 16:35.46 | dwmw2 | [Aug 26 17:32:56] NOTICE[7154]: pbx_spool.c:574 queue_created_files: File 'foo' being processed now; not opened... |
| 16:35.58 | dwmw2 | [Aug 26 17:32:56] WARNING[7154]: pbx_spool.c:415 scan_service: Invalid file contents in /var/spool/asterisk/outgoing/foo, deleting |
| 16:35.58 | dwmw2 | [Aug 26 17:32:56] NOTICE[7154]: pbx_spool.c:673 scan_thread: Read 32 bytes from inotify |
| 16:35.58 | dwmw2 | [Aug 26 17:32:56] NOTICE[7154]: pbx_spool.c:676 scan_thread: Event 32 for file 'foo' |
| 16:35.58 | dwmw2 | [Aug 26 17:32:56] NOTICE[7154]: pbx_spool.c:551 queue_file_open: queue_file_open foo |
| 16:36.08 | kpfleming | oh, nice |
| 16:36.33 | dwmw2 | ok, baby needs wrangling. Will have to look at this later this evening. |
| 16:36.40 | dwmw2 | thanks for the feedback. |
| 16:36.54 | kpfleming | thanks for the work and testing! |
| 16:40.26 | dwmw2 | it was aboyut time I replaced my ancient 1.2 box :) |
| 16:47.56 | *** join/#asterisk-dev serafie (~erin@nat/digium/x-cedfwbvbhjccocbd) |
| 17:21.39 | Kobaz | ast_read should return if the channel is hung up right? |
| 17:43.04 | *** join/#asterisk-dev otherwiseguy (~terry@68-70-72-166.static.kc.surewest.net) |
| 17:57.17 | JonathanRose | Anyone around here ever use Early Media and have any opinions on Asterisk documentation for it? |
| 17:57.42 | jsmith | uses it all the time |
| 17:57.59 | jsmith | JonathanRose: And I've got plenty of opinions |
| 17:58.08 | JonathanRose | ah, excellent. |
| 17:58.09 | jsmith | JonathanRose: Something in particular you want me to discuss? |
| 17:58.42 | JonathanRose | Well yeah, we had some internal testing on call queues that turned out to just be a matter of early media being used without sending an initial progress message... |
| 17:58.58 | jsmith | Right... |
| 17:59.27 | jsmith | In general, you should call Answer() or Progress() or Proceeding() before calling Queue() |
| 17:59.33 | jsmith | That being said, it didn't used to be necessary |
| 17:59.37 | JonathanRose | Yes. |
| 17:59.41 | jsmith | but now, in some cases it is |
| 17:59.46 | JonathanRose | Once upon a time, I think those applications auto-answered. |
| 17:59.50 | jsmith | So many people got caught with dialplans that didn't do the right thing |
| 18:00.00 | jsmith | Well, I don't think they auto-answered |
| 18:00.13 | jsmith | But you could do Playback(hello-world,noanswer) for early media without calling Progress() first |
| 18:00.19 | jsmith | Now you're required to call Progress() |
| 18:01.06 | JonathanRose | Yes |
| 18:01.26 | JonathanRose | And that's what I'm getting at really, it isn't always super-obvious to people that they need to use Progress. |
| 18:01.37 | jsmith | Correct |
| 18:01.56 | jsmith | As I see it, we have two choices... document it better, or revert the change |
| 18:02.07 | jsmith | Personally, I think it's probably too late (and perhaps too invasive) to revert the change |
| 18:02.25 | JonathanRose | I don't believe it's really misbehaving in any way, so the answer in my opinion would be to document it better. |
| 18:02.39 | JonathanRose | I'm just wondering where would be appropriate. There is mention of it already in sip.conf |
| 18:03.00 | JonathanRose | It just isn't obvious what you'd do in the context of the dialplan, so I was thinking about putting something in extensions.conf along the lines of this: |
| 18:03.13 | jsmith | It really needs to be mentioned somewhere talking about early media, as it's not really specific to the SIP channel driver |
| 18:03.24 | jsmith | does early media over ISDN all the time |
| 18:04.08 | JonathanRose | I haven't really used it with anything other than sip, but that's good to note. I should probably change the documentation with that in mind. |
| 18:04.13 | Kobaz | it should be in the xml doc |
| 18:04.30 | Kobaz | something like "Before using Queue(), you must Answer() Progress() etc |
| 18:04.33 | JonathanRose | http://pastebin.com/5qy08R6x |
| 18:04.47 | JonathanRose | This was what I had going into extensions.conf, but I'm not sure it's an appropriate thing to document there. |
| 18:04.53 | JonathanRose | And it was sip specific anyway |
| 18:05.20 | JonathanRose | @Kobaz: Yes, but it isn't just Queue. |
| 18:05.34 | JonathanRose | There are lots of applications that won't answer or progress etc. on their own. |
| 18:05.46 | kpfleming | but most of them don't generate audio towards the caller either |
| 18:05.50 | JonathanRose | Mostly ones that play media without expecting input immediately. |
| 18:05.51 | JonathanRose | yes |
| 18:06.02 | JonathanRose | oh wait |
| 18:06.06 | JonathanRose | that's the opposite of what I said. |
| 18:06.24 | kpfleming | i guess really it depends on what problem you are trying to solve here |
| 18:06.34 | pabelanger | JonathanRose: I'd rather see it posted the the wiki, and not our configuration files. They are already bloated as they are |
| 18:06.38 | Kobaz | JonathanRose: but that was what i'm saying. The applications that need to have that prereq, need to be noted in the application help |
| 18:06.51 | kpfleming | there are (at least) two: the lack of media being sent *to* Asterisk if Progress() is not used, and the inability to keep a call alive for more than "n" seconds without using Progress() |
| 18:08.42 | JonathanRose | Alright, so I guess I'll hit the wiki and see if I can find anything already posted about it on there and if not, start working on an early media page or something. |
| 18:09.25 | kpfleming | that's a good plan |
| 18:10.19 | jsmith | FWIW, I always taught it in my Asterisk classes when I was doing training |
| 18:10.34 | jsmith | Not sure if it gets mentioned much anywhere else |
| 18:17.17 | JonathanRose | Hmmm, I also think this could probably be explained in better detail in the XML documentation for Progress as well as applications with a long expected time of living that don't automatically answer the channel like queue and musiconhold |
| 18:17.38 | JonathanRose | I don't think core show application Queue even mentions anything about it. |
| 18:18.17 | jsmith | Wouldn't hurt to do it both on the wiki and in the XML docs |
| 18:23.51 | pabelanger | +1 |
| 18:28.15 | kpfleming | dwmw2: are you still here? |
| 18:57.15 | pabelanger | JonathanRose: psst... #asterisk-testing |
| 19:17.13 | *** join/#asterisk-dev serafie (~erin@nat/digium/x-iibrrvuggnzrqncq) |
| 19:19.20 | *** join/#asterisk-dev tamiel (~tamiel@ip-183.net-81-220-86.toulouse.rev.numericable.fr) |
| 19:24.51 | *** join/#asterisk-dev serafie (~erin@nat/digium/x-fvngundnehfyraik) |
| 19:30.04 | *** join/#asterisk-dev serafie (~erin@nat/digium/x-xbhdrinqoxiurnsp) |
| 19:33.21 | dwmw2 | kpfleming: yeah, just got back |
| 19:33.41 | kpfleming | dwmw2: ok. i've updated JA-439. check it out when you can. |
| 19:35.58 | dwmw2 | I have email :) |
| 19:36.15 | dwmw2 | the log message shows that the mail was offered to my system *from* mail.digium.com |
| 19:36.18 | kpfleming | oh yeah... i guess you wouldn't have received the updates if i hadn't fixed it properly :-) |
| 19:36.29 | kpfleming | oh |
| 19:36.32 | kpfleming | that's fine then |
| 19:36.37 | dwmw2 | thanks |
| 19:36.55 | kpfleming | it's been sooooo long since i had to do any exim configs... had to dredge up old memories and refer to man pages. |
| 19:37.32 | dwmw2 | :) |
| 19:37.41 | dwmw2 | note that you only need to accept bounces; not normal email |
| 19:37.46 | kpfleming | yeah |
| 19:37.58 | kpfleming | i just fail anything that isn't noreply@... and noreply@ is blackholed |
| 19:38.05 | kpfleming | that's good enough for now |
| 19:38.11 | dwmw2 | for bonus points you could even feed the information back to jira and tell people that their mail is bouncing, when they log in |
| 19:38.16 | dwmw2 | but that's a pita to set up :) |
| 19:38.37 | kpfleming | especially since issues.asterisk.org isn't actually the same system as the one JIRA is on |
| 19:38.52 | dwmw2 | yeah |
| 19:39.22 | dwmw2 | so, I may have to put a timeout on those created spool files. But first I'll try to loop and read *all* events from libnotify each time round the loop |
| 19:39.56 | dwmw2 | $DEITY knows why we get only one at a time. Maybe because it's running at high priority so it wakes immediately or something |
| 19:40.41 | kpfleming | well, the code in the kernel must be generating them one at a time as well. i guess it's generating an event for each 'file_ops' operation that gets called |
| 19:41.00 | dwmw2 | wonders why the hell it's a bitmask in that case :) |
| 19:41.13 | kpfleming | right |
| 19:41.17 | kpfleming | 'future expansion' |
| 20:05.38 | *** join/#asterisk-dev Marquis42 (~bfhbmw0@65-127-126-34.dia.static.qwest.net) |
| 20:16.18 | *** join/#asterisk-dev irroot (~irroot@41.122.160.246) |
| 20:45.37 | dwmw2 | my brain hurts |
| 20:45.38 | dwmw2 | ast_log(LOG_NOTICE, "Read %zd bytes from inotify. Size %d, compare %d\n", res, |
| 20:45.39 | dwmw2 | sizeof(*iev), res >= sizeof(*iev)); |
| 20:45.44 | dwmw2 | [Aug 26 21:44:25] NOTICE[11154]: pbx_spool.c:675 scan_thread: Read -1 bytes from inotify. Size 16, compare 1 |
| 20:46.10 | dwmw2 | since when is -1 greater than 16? They *are* both signed types |
| 20:47.45 | dwmw2 | hm, or is sizeof() a size_t not ssize_t ? |
| 20:50.15 | kpfleming | sizeof() is size_t |
| 20:52.15 | dwmw2 | yeah. And promotion rules mean the comparison is signed. So that line was always buggy |
| 20:54.02 | dwmw2 | anyway, the while() loop when poll triggers doesn't help. I really do need a timeout |
| 20:54.41 | kpfleming | that sucks. |
| 20:54.51 | kpfleming | but... if it's the right thing to do, such is life. |
| 20:55.04 | dwmw2 | not as much as it would if we didn't already have the 'mtime' field in the queue entries, which I can abuse :) |
| 21:42.38 | *** part/#asterisk-dev mjordan (~mjordan@nat/digium/x-cflbpligeshhfczn) |
| 22:23.10 | dwmw2 | hrm |
| 22:23.18 | dwmw2 | the reviewboard hates me |
| 22:23.19 | dwmw2 | DiffParserError at /r/new/ |
| 22:23.20 | dwmw2 | No valid separator after the filename was found in the diff header |
| 22:23.27 | dwmw2 | when trying to submit http://david.woodhou.se/pbx-handle-link.patch |
| 22:32.31 | russellb | use post-review |
| 22:32.35 | russellb | it will save you much pain. |
| 22:32.42 | dwmw2 | working on that now |
| 22:32.51 | dwmw2 | casper /home/dwmw2/git/asterisk $ post-review pbx/pbx_spool.c |
| 22:32.51 | dwmw2 | There don't seem to be any diffs! |
| 22:33.02 | dwmw2 | reads the docs some more |
| 22:33.08 | russellb | needs to be from an svn checkout |
| 22:33.17 | russellb | and "svn diff" needs to show what you want to post |
| 22:33.19 | dwmw2 | really? Not git-svn? |
| 22:33.52 | russellb | reviewboard needs to know about the repo that you're posting from |
| 22:34.11 | russellb | because it needs to know how to go get the rest of the file for its fancy diff viewer |
| 22:34.38 | dwmw2 | it should be able to get that from the git-svn info, surely? |
| 22:34.55 | russellb | but it doesn't know how |
| 22:35.00 | dwmw2 | reviewboard doesn't sound like "less pain" if it forces me to use svn :( |
| 22:35.06 | dwmw2 | svn is always "more pain". |
| 22:49.58 | dwmw2 | https://reviewboard.asterisk.org/r/1391/ |
| 23:30.36 | dwmw2 | aha, it does work with git-svn |
| 23:30.41 | dwmw2 | thank $DEITY for that. |
| 23:34.54 | *** join/#asterisk-dev otherwiseguy (~terry@69.76.217.40) |
| 23:46.17 | dwmw2 | N |
| 23:51.45 | *** join/#asterisk-dev dseeb_ (~Adium@CPE-124-187-225-74.lns1.dav.bigpond.net.au) |
| 23:55.55 | Kobaz | i think i got my background agi stuff going nicely |