| 00:04.12 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 00:04.13 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 00:18.18 | file | falls back into existence |
| 00:18.35 | file | seanbright, are you still there and in need of a g729 bump? |
| 00:21.40 | file | oh no! I made mjordan disappear! |
| 00:24.31 | WIMPy | wonders where file is the rest of the time. |
| 00:24.44 | WIMPy | Are you a schrödingers file? |
| 00:27.22 | *** join/#asterisk-dev mjordan (~mjordan@75.76.55.191) |
| 00:27.22 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 00:29.43 | file | WIMPy, usually I exist at all times! |
| 00:29.49 | file | and mjordan is not permanently disappeared! yay! |
| 00:30.49 | WIMPy | So where do you fall from? |
| 00:32.09 | file | classified |
| 00:47.01 | mjordan | I am around-ish |
| 00:47.45 | mjordan | file: how goes the ... stuff & things/ |
| 00:52.20 | opticron | finally found this leak... https://reviewboard.asterisk.org/r/3772/ |
| 01:16.30 | snuff-work | nice opticron |
| 01:20.11 | opticron | mjordan, I'm to the point where I can do nominal-path calls on pjsip with core bridging, p2p rtp bridging, and remote rtp bridging with no leaks or crashes |
| 01:20.54 | opticron | cracks open the issue to see what other requirements there were |
| 01:22.17 | opticron | hmm...needs to pass integration tests, too |
| 01:24.20 | opticron | kicks off a compile |
| 01:30.55 | coreyfarrell | what happened to https://bamboo.asterisk.org/bamboo/browse/ATB-MRCD/latest ? |
| 01:57.24 | mjordan | stuck |
| 01:57.35 | mjordan | some tests don't like it when Asterisk crashes. |
| 01:57.42 | mjordan | Until we get a few of those fixed, we probably should stop it. |
| 01:58.35 | mjordan | hm |
| 01:58.37 | mjordan | or not! |
| 01:59.39 | mjordan | opticron: nice |
| 02:23.44 | coreyfarrell | rmudgett: thanks for the fix to my failed removal of those files.. not sure what I did wrong :( |
| 02:25.19 | rmudgett | coreyfarrell: I think you applied a patch that just deleted the contents of the file. |
| 02:26.16 | coreyfarrell | could be, I had a bunch of stuff on reviewboard at the same time and I use a script that downloads the patch from reviewboard and applies it |
| 02:27.04 | rmudgett | That would do it. A patch can only change the contents of a file. It doesn't realize that the file should no longer exist. |
| 02:33.55 | coreyfarrell | so what's special about review 3773? mjordan got a fish trophy on it |
| 02:35.19 | opticron | it's a palindrome |
| 02:37.41 | coreyfarrell | hm surprised I haven't seen it before |
| 02:38.29 | rmudgett | They are getting farther apart. |
| 03:21.12 | opticron | hmmm...so normally when I get a piece of audio stuck in my head it's music |
| 03:21.22 | opticron | this time it was allison via demo-congrats |
| 03:26.38 | mjordan | ow |
| 03:26.45 | mjordan | that's a sign |
| 03:31.32 | coreyfarrell | I recently had nightmares about unsolvable REF_DEBUG logs |
| 03:34.20 | mjordan | that, too, is a sign |
| 03:34.44 | mjordan | coreyfarrell: Might be time for a vacation :-) |
| 03:36.14 | coreyfarrell | and I just picked up a project to upgrade an AMI based outbound dialer from 1.6 to 11 |
| 03:36.40 | coreyfarrell | at least that's different work |
| 03:37.28 | mjordan | which language? |
| 03:38.00 | coreyfarrell | perl :( |
| 03:38.28 | mjordan | ow |
| 03:38.31 | mjordan | well, that's different |
| 03:38.35 | mjordan | :-) |
| 03:39.19 | coreyfarrell | yeah.. unfortunately I have a bunch of perl code... I've started working on C replacements but that takes a lot of time |
| 03:39.54 | coreyfarrell | I actually like perl source code, but I've run into a couple situations where I was unable to determine the cause of a problem |
| 03:44.52 | coreyfarrell | speaking of AMI stuff, I was recently looking at moving NewExten / VarSet AMI events to modules (like res_manager_devicestate), but couldn't make heads or tails of how to accomplish that |
| 03:52.48 | mjordan | Hm. |
| 03:53.28 | mjordan | You could theoretically move most of manager_channels to a separate module |
| 03:53.33 | mjordan | or module(s) |
| 03:53.39 | mjordan | which then publish to the manager topic. |
| 03:54.02 | mjordan | NewExten/VarSet are looking for specific changes in channel state, or channel message types |
| 03:54.17 | coreyfarrell | NewExten / VarSet are the chattiest events, that's why they were the first I considered |
| 03:54.22 | mjordan | so they should be movable. |
| 03:55.04 | mjordan | There's actually a few 'levels' of this |
| 03:55.33 | mjordan | the first is to prevent Stasis messages from getting made in the first place. We've though about having a central stasis.conf that could be read by the core, that would kill a message type if it tried to get made that matched some filter |
| 03:55.54 | mjordan | That would reduce the most processing, but would also break things internally if you turned off a message that the core needed |
| 03:55.58 | mjordan | or some other module needed |
| 03:56.08 | mjordan | however, in terms of fine tuning a system, you could get the most bang for the buck |
| 03:56.14 | mjordan | VarSet comes to mind there. |
| 03:56.26 | mjordan | NewExten is trickier since it really is looking at differences in channel state |
| 03:56.47 | mjordan | for something like that, you could do what you're suggesting and put the channel cache state handling for manager in a separate module |
| 03:57.18 | mjordan | the big thing is that they need to use either the manager message router and/or re-forward their messages back to the manager topic |
| 03:57.20 | coreyfarrell | my goal of VarSet is that I will eventually be able to distribute a replacement for the module that publishes it to AMI, and only publish variable names m/PRODUCT_.*/ |
| 03:57.24 | mjordan | otherwise, messages get out of order |
| 03:57.36 | coreyfarrell | but also because VarSet/NewExten are very chatty |
| 03:57.39 | mjordan | yeah |
| 03:57.47 | mjordan | RTCP/AGI events are another subset of messages |
| 03:58.03 | mjordan | the final layer of course already exists - filtering out messages in manager.conf |
| 03:58.16 | mjordan | but by that point, you're really just preventing the client from having to handle them. Asterisk already did all the work. |
| 03:58.35 | coreyfarrell | I don't like manager.conf filtering, it actually adds overhead to Asterisk |
| 03:59.41 | coreyfarrell | also there is some debug mode that adds a serial number to each event, I'd like to be able use it to determine on AMI reconnect that no events were missed |
| 04:00.51 | coreyfarrell | I know I probably sound silly since ARI is the new thing, but AMI is a much simpler protocol to parse. |
| 04:04.44 | mjordan | Hm. I just use a JSON library :-) |
| 04:05.06 | mjordan | but AMI isn't going anywhere |
| 04:05.17 | mjordan | anywho, going to call it a night here. |
| 04:05.19 | mjordan | later! |
| 04:10.40 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 04:10.52 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 06:29.47 | *** join/#asterisk-dev bulkorok (~Benjamin@85.183.61.47) |
| 06:34.50 | *** join/#asterisk-dev hehol (~hehol@2001:1438:1009:200:d156:d034:df25:3ee2) |
| 06:45.53 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 06:45.53 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 07:13.07 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 07:13.07 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 10:24.11 | file | Monday Monday Monday |
| 10:53.18 | jameswf | Developers, developers, developers, developers |
| 10:56.01 | file | some restrictions apply for developers, please see README for details |
| 11:04.24 | seanbright | file: no, i emailed support |
| 11:06.10 | file | seanbright, k |
| 11:07.36 | seanbright | thanks though :-) |
| 11:08.27 | file | I don't think there are many left in here at Digium who have been around long enough to know how to get into activations and licensing... |
| 11:43.18 | seanbright | file: that's why i come to you. the man with access. |
| 12:03.03 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@216-191-106-163.dedicated.allstream.net) |
| 12:24.38 | *** join/#asterisk-dev sgriepentrog (~sgriepent@107-220-72-78.lightspeed.brhmal.sbcglobal.net) |
| 12:29.41 | *** join/#asterisk-dev pc-m (~pcm@modemcable094.94-70-69.static.videotron.ca) |
| 13:02.10 | *** join/#asterisk-dev otherwiseguy (~otherwise@23-228-175-118.mci.googlefiber.net) |
| 13:03.57 | *** join/#asterisk-dev bulkorok (~Benjamin@85.183.61.47) |
| 13:18.30 | *** join/#asterisk-dev newtonr (~newtonr@nat/digium/x-ebucodgyaoykkdck) |
| 13:18.30 | *** mode/#asterisk-dev [+o newtonr] by ChanServ |
| 13:19.13 | file | nods to newtonr |
| 13:20.49 | newtonr | file, greetings! how goes joshvoxnetvoxtelcomcolp ? |
| 13:21.22 | file | classified |
| 13:22.01 | newtonr | acceptable |
| 13:31.30 | *** join/#asterisk-dev protocoldoug (~quassel@unaffiliated/protocoldoug) |
| 13:34.10 | *** join/#asterisk-dev sgriepentrog (~sgriepent@nat/digium/x-phxncifpswhxvnfe) |
| 13:39.03 | skrusty | afternoon |
| 13:52.17 | opticron | fixing format cache case sensitivity: https://reviewboard.asterisk.org/r/3778/ |
| 13:53.13 | file | opticron, since that failed I'm assuming the old stuff was case insensitive? |
| 13:53.29 | opticron | appears to be |
| 13:53.47 | file | that's what I thought |
| 13:54.09 | *** join/#asterisk-dev kharwell (~kharwell@nat/digium/x-oaiszqelamqyrusy) |
| 13:54.54 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-xkozjlxlyznahqtk) |
| 13:54.54 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 13:55.43 | opticron | yeah, strcasecmp in ast_getformatbyname |
| 13:57.09 | file | opticron, you haz ship-it |
| 13:57.50 | opticron | yarr |
| 13:57.54 | opticron | and committed |
| 14:05.00 | *** join/#asterisk-dev rmudgett (~rmudgett@nat/digium/x-tlqbfvzqdmllimxg) |
| 14:08.28 | *** join/#asterisk-dev gtjoseph (~gtj0@unaffiliated/gtj) |
| 14:10.21 | opticron | :q |
| 14:13.59 | rmudgett | opticron@pc:~$ _ |
| 14:14.24 | file | sudo kill -9 1 |
| 14:19.40 | file | opticron, what's the dealio on r3763? |
| 14:20.18 | opticron | I'm working up a new patch at the moment |
| 14:20.28 | file | kk |
| 14:20.45 | opticron | I have to be careful with chan_sip |
| 14:21.03 | mjordan | indeed |
| 14:21.24 | opticron | right now, it's between working on that and getting a fax test working again |
| 14:22.16 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 14:22.16 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 14:28.20 | *** join/#asterisk-dev hehol (~hehol@217.9.101.222) |
| 14:38.25 | *** part/#asterisk-dev bulkorok (~Benjamin@85.183.61.47) |
| 14:43.50 | *** join/#asterisk-dev otherwiseguy (~otherwise@69.76.221.33) |
| 14:47.25 | *** join/#asterisk-dev lirakis (~lirakis__@c-67-174-120-116.hsd1.co.comcast.net) |
| 15:05.07 | *** join/#asterisk-dev miguel3239 (~miguel323@2001:470:1f06:12c4::2) |
| 15:08.37 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 15:08.37 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 15:17.01 | *** join/#asterisk-dev coreyfarrell (~cfarrell@2001:4830:117f:2:e4ee:cf3:ebac:9e94) |
| 15:21.29 | *** join/#asterisk-dev tzafrir__ (~tzafrir@local.xorcom.com) |
| 15:21.29 | *** mode/#asterisk-dev [+o tzafrir__] by ChanServ |
| 15:22.50 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 15:22.50 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 15:43.48 | sgriepentrog | Just realized we don't have linkedid being output in an ARI GET of a channel. Should we? |
| 15:45.42 | opticron | is that not part of the standard ARI channel snapshot json blob? |
| 15:45.50 | sgriepentrog | Apparently not. |
| 15:46.18 | sgriepentrog | I mean, I think it's in the snapshot, but gets sanitized out of the ARI json. |
| 15:50.28 | *** join/#asterisk-dev Kobaz (~kobaz@173.234.39.101) |
| 15:56.12 | mjordan | Hm. |
| 15:56.36 | mjordan | I have mixed feelings :-) |
| 16:04.20 | mjordan | on the one hand, linkedid is useful for billing systems, and tying together who talked to whom. In particular, it was originally written as a concept for CEL and CDRs |
| 16:04.33 | mjordan | however, with ARI, there's no question who you are talking to. |
| 16:04.55 | *** join/#asterisk-dev terryw (~otherwise@69.76.221.33) |
| 16:07.49 | mjordan | Asterisk isn't putting people into bridges itself. |
| 16:08.04 | mjordan | ARI does that. So if an ARI app wants to know who all talked to whom, it just has to bother writing it down |
| 16:08.15 | opticron | lobs a Bridge() at mjordan |
| 16:08.31 | mjordan | What's more, if someone steals a channel out of an ARI app - say due to a redirect or a bridge (exactly opticron!) - then you don't know where they're necessarily going anyway |
| 16:08.40 | mjordan | they're out of your app |
| 16:09.08 | mjordan | unless you build a switchboard by subscribing to all endpoints, in which case: you once again have the information you need (generally) to know who is talking to whom |
| 16:09.18 | mjordan | linkedids don't make much sense when you have the events telling you what is going on |
| 16:09.30 | mjordan | they make much more sense when you don't have all of the information, and you're trying to piece the world back together |
| 16:09.31 | file | Mable is talking to Klondike 5 9 2! |
| 16:09.50 | sgriepentrog | Or trying to write an ARI based linkedid test ;-) |
| 16:09.59 | mjordan | That being said... it's not like there's much "work" that happens to add linkedid. |
| 16:10.02 | mjordan | Well... AMI! |
| 16:10.33 | sgriepentrog | Yeah, that's what I told him to do - just wanted to bounce that off people to see if there was a reason why/not |
| 16:10.50 | mjordan | I don't feel super strong about it |
| 16:11.03 | mjordan | I am of the mind that we should think carefully before adding things to an ARI event |
| 16:11.08 | sgriepentrog | Agreed. |
| 16:11.12 | mjordan | looks at the dreaded RTCP events |
| 16:18.53 | *** join/#asterisk-dev stevePearPear (~stevePear@cm244.epsilon47.maxonline.com.sg) |
| 16:22.57 | *** join/#asterisk-dev otherwiseguy (~otherwise@69.76.221.33) |
| 16:38.16 | file | opticron, r3763 - are you back at it? |
| 16:40.07 | opticron | I am |
| 16:40.15 | file | what's your current approach? |
| 16:42.25 | opticron | trying to figure out exactly what that code should do so I can rewrite it in terms of the new API |
| 16:43.09 | opticron | since there are still behavioral differences between pre/post media formats work that I hadn't accounted for |
| 16:45.32 | file | I have a feeling that you went down the wrong road |
| 16:46.06 | file | that the problem lives elsewhere |
| 16:46.31 | file | what was the original problem? |
| 16:46.33 | opticron | it's possible |
| 16:46.51 | opticron | the original problem was that I got 1-way audio in the media formats branch |
| 16:47.08 | opticron | in trunk, the remote endpoint rejected the call |
| 16:47.54 | opticron | (gsm) offered in trunk, (gsm|ulaw|alaw) offered in media formats branch |
| 16:48.23 | file | what channels? PJSIP? |
| 16:48.32 | opticron | both pjsip |
| 16:48.45 | file | I ... bet ... I know what |
| 16:49.04 | file | and now I try to remember |
| 16:50.00 | file | did you track down what formats were in the various caps involved? |
| 16:52.32 | opticron | yes, ast_request was called with (gsm) and that got added to the endpoint's caps and the combination of those went out on the wire |
| 16:53.20 | file | and the 1-way occurred because? |
| 16:54.31 | opticron | asterisk never received any rtp audio from the phone |
| 16:54.37 | opticron | afaict, anyway |
| 16:54.56 | file | and what was the configuration on the phone? |
| 16:54.59 | file | in pjsip.conf |
| 16:55.27 | opticron | ulaw only |
| 16:55.36 | file | interesting |
| 16:55.54 | opticron | let me reproduce it again and get caps of all the messages involved |
| 16:56.15 | opticron | it was a long weekend and I may be fuzzy on the details |
| 16:56.17 | file | so I'd say the bug is that the capabilities are a joint versus requested like trunk |
| 16:56.24 | opticron | right |
| 16:56.30 | opticron | that's the path I've gone down |
| 16:56.42 | file | it's probably PJSIP specific |
| 16:57.23 | opticron | also the direction I went |
| 16:57.29 | file | k |
| 16:57.58 | opticron | I found that ast_format_cap_append in trunk was replaced with ast_format_cap_append_from_cap in media formats |
| 16:58.06 | opticron | these two things have fairly different behaviors |
| 16:58.46 | file | how so? |
| 16:59.38 | opticron | the former checks compatibility and replaces the format in dest cap if they're equal or subset |
| 16:59.56 | opticron | the latter blindly appends (which is what you'd actually expect for a function of that name) |
| 17:01.45 | opticron | it's probably easier to look at the code in trunk than it is for me to describe how it operates |
| 17:02.10 | file | are you sure? I just looked at the trunk code and it doesn't replace it in dest cap |
| 17:02.51 | file | it only adds the format if it's not already there, otherwise it leaves it alone |
| 17:03.33 | opticron | looks again |
| 17:03.48 | file | same for the mf code - it just does the check slightly differently |
| 17:05.05 | opticron | we're both looking at ast_format_cap_append in trunk, right? |
| 17:05.29 | file | yes |
| 17:06.12 | file | it does an ao2_callback on the formats container of the source caps, in the callback it does an iscompatible check which returns 1 if the format is equal or subset, if it returns 0 the code then adds the format to the result |
| 17:06.39 | file | if the format is already in the result it becomes a noop |
| 17:06.46 | *** join/#asterisk-dev sgriepentrog (~sgriepent@nat/digium/x-vdjqavgipljtqidf) |
| 17:07.08 | opticron | ah-ha, I've been missing a ! this whole time |
| 17:07.14 | file | :D |
| 17:07.29 | file | behavior wise they are equivalent |
| 17:07.43 | opticron | well crud |
| 17:07.54 | opticron | now I have to find the real cause of the change |
| 17:08.24 | opticron | ugh |
| 17:08.26 | file | yeah, it sounds like a caps isn't getting cleared - to match trunk behavior it should be the requested caps and not both |
| 17:08.35 | opticron | right |
| 17:09.25 | file | hrm |
| 17:10.10 | mjordan | so. In PJSIP land, why wouldn't we always offer the configured formats on the endpoint? |
| 17:10.31 | opticron | also what I was thinking |
| 17:10.36 | mjordan | The 'requested capability' thing is nice if you're trying to minimize transcoding, I'll grant that. But I'm of the mind that we try to do way too much in chan_sip down that path. |
| 17:10.56 | mjordan | If you want to prevent transcoding, then use the media functions to set the preferred format on the outbound call. |
| 17:10.59 | file | I think requested capability is a mess and should be eliminated |
| 17:11.03 | file | well, replaced |
| 17:11.37 | mjordan | All of that should be via dialplan or the user in some fashion. We kept that in chan_sip this time around because, well, chan_sip. |
| 17:11.47 | mjordan | The only thing you do have to carry across are the requested formats. |
| 17:11.57 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 17:11.59 | mjordan | If those formats match a format on your endpoint, you want to use the requested formats, not yours |
| 17:12.05 | mjordan | otherwise you won't get any attributes they sent your way |
| 17:12.37 | mjordan | other then that, you don't want to use things they gave you. Screw em. If someone said "use ulaw for this endpoint", and a call came in as g729, then barring other instructions from the dialplan, use ulaw. |
| 17:13.44 | mjordan | keeping in mind that with a pre-dial handler, someone can manipulate the formats on the outbound channel (theoretically at least) before Asterisk makes the call |
| 17:14.01 | mjordan | so let them do it there. They have all the information at that point to determine what they really want to be used on the outbound channel. |
| 17:15.04 | file | I do not disagree with any of that. |
| 17:39.27 | opticron | I'm going to drop 3763 in light of a new approach and probably more work to do |
| 17:40.29 | file | k |
| 17:53.29 | opticron | ok, so I have ast_format_cap A and ast_format_cap B (guaranteed to be a subset of A format-wise, but with possibly different attributes) |
| 17:53.48 | opticron | how do I replace instances of B-formats in A without changing the preference order? |
| 17:55.31 | file | I don't think a mechanism exists to manipulate an existing cap to that level, you'd need to construct another |
| 17:55.53 | opticron | ok, just wanted to make sure |
| 17:56.00 | opticron | I didn't see one |
| 17:57.13 | *** join/#asterisk-dev sgriepentrog (~sgriepent@nat/digium/x-xansnnncfevifkax) |
| 19:25.35 | opticron | ok, new try for pjsip media offer correctness: https://reviewboard.asterisk.org/r/3784/ |
| 19:25.44 | *** join/#asterisk-dev otherwiseguy (~otherwise@75.87.131.147) |
| 19:29.57 | *** join/#asterisk-dev ipengineer (~zconkle@static-71-252-134-63.dllstx.fios.verizon.net) |
| 19:42.09 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-218-28-58.cablep.bezeqint.net) |
| 19:42.10 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 19:44.10 | TazzNZ | hey all |
| 19:56.52 | *** join/#asterisk-dev sgriepentrog (~sgriepent@nat/digium/x-eezgqsvlzxbxrzep) |
| 20:17.12 | *** join/#asterisk-dev bulkorok (~Benjamin@gw1.pinguin.ag) |
| 20:19.34 | mjordan | opticron: nice job |
| 20:19.46 | mjordan | opticron: will probably need a unit test for that new API call |
| 20:39.48 | seanbright | mjordan: sorry about R3777. i added the patch to sort the module list :/ |
| 20:40.24 | mjordan | seanbright: I know, I SVN blamed you. I laughed. |
| 20:40.31 | mjordan | It wasn't a bad idea |
| 20:40.39 | mjordan | And it's not like Asterisk unloaded things properly before that |
| 20:40.43 | mjordan | so you didn't make anything worse :-) |
| 20:41.10 | seanbright | phew |
| 20:41.34 | mjordan | Asterisk module loader is ... bad. |
| 20:41.43 | mjordan | Dependencies are "suggestions" |
| 20:41.56 | mjordan | this patch isn't much better, but it at least tries to unload things :-P |
| 20:42.11 | seanbright | someone had a wiki page one a new mechanism |
| 20:42.14 | seanbright | on* |
| 20:42.33 | mjordan | yup |
| 20:42.36 | mjordan | leedm777 |
| 20:42.41 | mjordan | It's the "right" thing to do |
| 20:42.50 | mjordan | it also is really hard and would break all modules outside of the core |
| 20:42.58 | mjordan | and it also won't get done in time for Wednesday |
| 20:43.15 | mjordan | This is my lame ass response to that glorious ideal |
| 20:43.18 | seanbright | heh |
| 20:47.17 | seanbright | oh my... dl_iterate_phdr |
| 20:47.44 | seanbright | linux be crazy |
| 20:47.53 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 20:47.54 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 20:49.30 | mjordan | that would be smarter |
| 20:49.56 | mjordan | we do a lot of weird things loading modules. |
| 20:50.00 | file | with great power... comes great fun |
| 20:50.13 | mjordan | My initial patch (which died Sunday morning in a fit of rage) failed miserably |
| 20:54.19 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@64.235.216.2) |
| 21:06.54 | seanbright | who handles the user certs for origsvn these days? |
| 21:21.09 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-cgohptdtbppmrvvy) |
| 21:21.09 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 21:21.24 | mjordan | sruffell: so, about ASTERISK-20703 |
| 21:21.43 | mjordan | There were a reasonable number of modifications I had to make to menuselect, particularly to the build system |
| 21:21.57 | seanbright | mjordan: who handles the user certs for origsvn these days? |
| 21:22.09 | mjordan | seanbright: mostly me. Need a renewal? |
| 21:22.14 | mjordan | hence why I decided to just punt on a clean pull in of the svn repo |
| 21:22.14 | seanbright | do i ever |
| 21:22.28 | mjordan | sruffell: can you think of a way to pull in an svn external repo and keep the history? |
| 21:22.39 | mjordan | Not sure if it is really worth it for menuselect, given the rather small history of it |
| 21:22.51 | mjordan | seanbright: will do |
| 21:23.28 | seanbright | mjordan: if the "when" of the commit is not that important, you could just replay the commits |
| 21:23.32 | sruffell | mjordan: not in subversion and make it nice. I think what we could do is "fix" menuselect when making an "official" git repo for Asterisk. |
| 21:24.15 | sruffell | I know russellb had indicated that if possible he would like that history preserved. |
| 21:24.51 | seanbright | menuselect_newt is my single greatest contribution to asterisk... i would like to be remembered for that |
| 21:24.53 | sruffell | when we last talked about it: https://issues.asterisk.org/jira/browse/ASTERISK-20703?focusedCommentId=214194&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-214194 |
| 21:25.35 | mjordan | seanbright: renewed. Can't recall if I have to reissue it or not |
| 21:26.04 | seanbright | the cert i have has an expiration date in it |
| 21:26.04 | mjordan | sruffell: If we can still re-create the history if I svn add the whole thing, that would be ideal. if not, I could re-create what I've got |
| 21:26.08 | seanbright | i'll give it a whirl |
| 21:26.15 | mjordan | seanbright: sounds like a 'yes' to me :-) |
| 21:26.24 | seanbright | yeah, still no go |
| 21:27.27 | sruffell | mjordan: we will be able to. I had to do some git filter-branch magic to add in menuselct on some older branches when we made DAHDI. I could do something like that for Asterisk when we are ready to make an official repo. |
| 21:28.13 | sruffell | although, in that vein..it would be preferable if the copy of the external could be a separate commit from any changes you make to it. |
| 21:28.13 | mjordan | sruffell: cool |
| 21:28.21 | mjordan | hm |
| 21:28.35 | mjordan | I could probably fake it out. It will break the crap out of trunk when it happens |
| 21:30.54 | mjordan | seanbright: sent |
| 21:31.01 | seanbright | mjordan: received |
| 21:32.32 | seanbright | still not working... |
| 21:32.32 | seanbright | svn: E120171: Error running context: An error occurred during SSL communication |
| 21:32.44 | seanbright | i'm guess there is a config setting that i am missing |
| 21:33.55 | mjordan | hrm. |
| 21:35.10 | mjordan | or something is blocking SSL? |
| 21:35.57 | mjordan | (HTTPS) |
| 21:36.44 | mjordan | what is your ssl-authority-files in .subversion/server? |
| 21:41.04 | sruffell | mjordan: could the first commit of the menuselect work be the result of "rm -fr menuselect; svn pd svn:externals; svn export https://origsvn.digium.com/svn/menuselect/trunk menuselect; svn add menuselect" ? Then in the commit message put the revision of menuselect that was exported for traceability. Then the result is identical to what svn grabbed when processing the external. Then any additional changes could be made on top of |
| 21:45.39 | seanbright | works now |
| 21:45.43 | seanbright | must have been a cache or something |
| 21:47.07 | mjordan | file: if you get an object out of sorcery, can you lock that object? |
| 21:49.24 | sruffell | (which makes looking at that change in the future easier as well for similar reasons as articulated https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/SubmittingPatches#n681 ) |
| 21:49.39 | file | mjordan, no |
| 21:54.14 | mjordan | file: bummer. |
| 21:54.41 | file | they are allocated without any lock |
| 21:55.00 | mjordan | there's a potential race condition with updating external MWI |
| 21:55.08 | mjordan | basically, the race is omnipresent :-) |
| 21:55.17 | mjordan | we just require the end system to synchronize themselves, which is a bit of a shame |
| 21:55.38 | mjordan | sruffell: sure |
| 21:55.44 | mjordan | sruffell: that shouldn't be a problem |
| 21:55.50 | mjordan | seanbright: \o/ |
| 21:56.04 | sruffell | cool, thanks. |
| 22:11.36 | rmudgett | file: That was not the only difference in the snipet I put on the review. |
| 22:12.08 | rmudgett | ast_format_create can fail. I also added a check for that. |
| 22:12.26 | file | mine also covers that |
| 22:13.58 | rmudgett | file: Oh. I see it now. |
| 22:16.29 | file | yolo |
| 22:33.01 | *** join/#asterisk-dev SGjunior (~sgjunior@out-pq-193.wireless.telus.com) |
| 23:06.04 | *** part/#asterisk-dev kharwell (~kharwell@nat/digium/x-oaiszqelamqyrusy) |
| 23:23.50 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 23:57.14 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@64.235.216.2) |