| 00:02.17 | file | coreyfarrell: I don't buy into changing stuff to using bindep |
| 00:02.38 | file | >_> |
| 00:03.40 | coreyfarrell | yeah like I said if it worked like configure.ac where some maintainer tool could generate a pure /bin/sh script I might be open to it, but I don't think the tool used to install prereqs should have any prereqs. |
| 00:03.56 | file | I also don't think it works for all the platforms Alexander Traud added |
| 00:04.06 | coreyfarrell | it does not |
| 00:05.12 | coreyfarrell | that could likely be fixed easily but it definitely doesn't currently support the BSD packaging tools or zypper (I think that's one I saw) |
| 00:05.32 | file | more work for little gain in my eyes |
| 00:07.20 | coreyfarrell | also one of the main goals of my current review is to have a file that lists redhat/fedora packages, another to list debian packages, etc. specifically to not have one gigantic list of dependencies with platform based variants. |
| 00:08.07 | gtjoseph | i'm going to ask again to hold off. I'm >< close to publishing the internal stuff |
| 00:09.05 | coreyfarrell | gtjoseph: no problem, as I said I just wanted to resolve the merge conflict (a bit of an OCD I guess) |
| 00:09.14 | gtjoseph | no worries |
| 00:10.03 | gtjoseph | right now i'm trying to figure out why alexander's python patch broke my compiles. |
| 00:10.41 | rmudgett | Platform poisoning :) |
| 00:15.06 | coreyfarrell | the python2 -> python3 thing seems like it's going to be a real pain in general. |
| 00:15.32 | gtjoseph | probably |
| 00:15.39 | gtjoseph | but right now it's a pain for me |
| 00:15.49 | file | coreyfarrell: understatement |
| 00:16.29 | gtjoseph | i looked up quick and thought you said entertainment |
| 00:16.44 | coreyfarrell | hopes Alexander realizes the testsuite won't run in python3, starts working on compatibility in that and leaves the configure.ac alone for a while. |
| 00:16.49 | file | The Running Man WAS entertainment |
| 00:16.55 | file | such 80s |
| 00:24.54 | gtjoseph | ok, i'm reverting the python commits |
| 00:34.12 | gtjoseph | it's python3-devel. if you have it installed, then python is 2.7 but the headers and libs are 3.6 |
| 00:34.48 | gtjoseph | lesson learned again...no change should be rubber stamped |
| 00:35.03 | gtjoseph | just to quiet someone down |
| 00:35.34 | coreyfarrell | I just rubber stamped the revert :/ |
| 00:36.22 | gtjoseph | well, that's ok then. :) |
| 00:40.37 | *** join/#asterisk-dev jkroon_ (~jkroon@165.16.204.169) |
| 03:30.57 | *** join/#asterisk-dev leedm777 (~textual@2604:2d80:8404:ffae:e85e:4c59:11e7:e174) |
| 03:30.57 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 04:00.48 | *** join/#asterisk-dev leedm777 (~textual@2604:2d80:8404:ffae:a4d8:8d8a:a4d5:41b8) |
| 04:00.48 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 07:07.18 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 07:07.18 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 07:27.32 | *** join/#asterisk-dev tm1000 (sid6728@gateway/web/irccloud.com/x-qxgzlhczgpowqrdk) |
| 07:33.58 | *** join/#asterisk-dev tsearle (~tsearle@37.19.10.33) |
| 07:33.58 | *** mode/#asterisk-dev [+o tsearle] by ChanServ |
| 07:55.12 | *** join/#asterisk-dev dadrc (~quassel@unaffiliated/dadrc) |
| 08:21.21 | *** join/#asterisk-dev hehol (~hehol@gatekeeper.loca.net) |
| 09:13.31 | *** join/#asterisk-dev CELYA_ (~Thunderbi@ppp-seco11pareq2-46-193-150-23.wb.wifirst.net) |
| 09:43.09 | *** join/#asterisk-dev razzex (~razzex@77.48.251.5) |
| 09:53.21 | tzafrir | What is the point of channels/sig_analog.c ? It seems to replicate a whole bunch of code from chan_dahdi.c |
| 09:53.58 | tzafrir | Is there any other user of sig_analog besides chan_dahdi.c ? |
| 10:03.43 | file | there was in the past for a project, thus why it exists |
| 11:06.47 | *** join/#asterisk-dev CELYA_ (~Thunderbi@80.12.38.131) |
| 11:07.23 | *** join/#asterisk-dev scgm11_ (~scgm11@r186-50-190-129.dialup.adsl.anteldata.net.uy) |
| 11:16.20 | razzex | could anyone take a look at the current state of my module and help me understand why doesnt it work? Modul is registered, its running, calls and registers work, but nothing gets printed out as it should :( code here: https://pastebin.com/vphHRi2E |
| 11:31.45 | seanbright | razzex: pastebin the contents of your /etc/asterisk/logger.conf file |
| 11:31.59 | seanbright | ... for someone else to look at. i have to run for a bit |
| 11:53.08 | razzex | logger.conf is default from "make samples", but will do |
| 11:53.32 | razzex | (contains a line "console => notice,warning,error") |
| 11:54.45 | razzex | logger.conf https://pastebin.com/gMxVj3qJ , might have something to do with the "PJSIP_MOD_PRIORITY_APPLICATION" attribute, as any higher priority set results in a SIGSEGV error (module crash) |
| 12:01.35 | file | PJSIP modules can stop further execution of any higher modules, thus if a message is handled by it then the other modules won't see it, you have to find the right priority depending on what you are trying to accomplish in relation to the other modules in the stack - there is no magic bullet number, easiest way is to find another PJSIP module that you think makes sense to execute after and set your priority to that + 1 |
| 12:05.26 | *** join/#asterisk-dev stefan27 (~stefan27@static-212-247-4-149.cust.tele2.se) |
| 12:08.11 | razzex | I see, ill get on that |
| 12:28.57 | *** join/#asterisk-dev scgm11_ (~scgm11@2800:a4:1724:1800:71e0:9047:17b7:10ae) |
| 12:29.40 | seanbright | AsteriskRoss: have you tested richard's update: https://gerrit.asterisk.org/#/c/8455 |
| 12:48.01 | *** join/#asterisk-dev scgm11_ (~scgm11@2800:a4:1724:1800:71e0:9047:17b7:10ae) |
| 13:08.28 | *** join/#asterisk-dev scgm11_ (~scgm11@r186-52-135-44.dialup.adsl.anteldata.net.uy) |
| 13:12.54 | *** join/#asterisk-dev CELYA_ (~Thunderbi@80.12.27.128) |
| 13:28.30 | *** part/#asterisk-dev libardi (~libardi@187.64.235.152) |
| 14:08.28 | AsteriskRoss | I am currently testing, so far so good! |
| 14:11.22 | *** join/#asterisk-dev kharwell (kharwell@nat/digium/x-azalaueojgwumsyf) |
| 14:11.22 | *** mode/#asterisk-dev [+o kharwell] by ChanServ |
| 14:30.58 | *** join/#asterisk-dev jkroon_ (~jkroon@165.16.204.169) |
| 14:37.26 | *** join/#asterisk-dev cresl1n (Adium@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 14:37.26 | *** mode/#asterisk-dev [+o cresl1n] by ChanServ |
| 14:39.10 | *** join/#asterisk-dev bford (uid283514@gateway/web/irccloud.com/x-wzpuewcmiimphiqx) |
| 14:39.10 | *** mode/#asterisk-dev [+o bford] by ChanServ |
| 14:50.10 | *** join/#asterisk-dev jkroon_ (~jkroon@105.12.5.228) |
| 14:53.49 | *** join/#asterisk-dev rmudgett (rmudgett@nat/digium/x-cqgzbdcqpohqwvta) |
| 14:53.49 | *** mode/#asterisk-dev [+o rmudgett] by ChanServ |
| 15:19.03 | *** join/#asterisk-dev jkroon_ (~jkroon@165.16.204.169) |
| 16:00.37 | *** join/#asterisk-dev Worldexe (~Worldexe@95-107-33-134.dsl.orel.ru) |
| 16:09.27 | *** join/#asterisk-dev jkroon__ (~jkroon@165.16.204.164) |
| 16:11.23 | *** join/#asterisk-dev scgm11_ (~scgm11@r186-52-135-44.dialup.adsl.anteldata.net.uy) |
| 16:18.24 | *** join/#asterisk-dev scgm11_ (~scgm11@r186-49-67-199.dialup.adsl.anteldata.net.uy) |
| 16:45.11 | kharwell | I'm looking into some of the recent test failures on the jenkins. One I'm currently looking at fails due to a retransmission. It got me thinking that in most tests we have retrans turned on. I'm wondering now moving forward if we should not use that in tests unless it's a test testing retrans of course. Otherwise it can cause error if their is a system slow down at the right time |
| 16:46.21 | kharwell | There are a few ways to solve this of course, but wondering if it would be easiest to default sipp scenarios to turn off retrans for all tests unless an option is given to turn them on |
| 16:46.38 | file | kharwell: does the retrans expose a test scenario problem only? |
| 16:48.21 | kharwell | depends what you mean by "test scenario problem". Nothing wrong with this particular test, but if a retrans is sent and asterisk receives both messages then it sends back two replies, which the test does not expect |
| 16:48.53 | kharwell | hrm maybe in that case something is wrong in Asterisk? Probably shouldn't send back two replies I'd think |
| 16:49.23 | file | you should |
| 16:49.33 | rmudgett | SIP should be sending back the replies. |
| 16:49.45 | file | if a retransmission is received the transaction layer retransmits the response |
| 16:50.45 | file | kharwell: my question was more - does that itself reduce test coverage? |
| 16:50.46 | kharwell | okay so things are working as they should. So any test that sends a retransmission will fail due to an unexpected message coming into the scenario |
| 16:51.32 | kharwell | file: what turning off retrans? |
| 16:51.42 | file | oui |
| 16:53.24 | kharwell | I don't think so? I mean if a test covers a particular feature and is not setup to handle possible retransmissions then it'll fail of course. But that's not what it's testing |
| 16:53.44 | kharwell | it's testing the feature not retransmissions |
| 16:53.54 | kharwell | unless the feature is retransmissions |
| 16:54.40 | rmudgett | sipp scenarios don't handle retransmission responses very well. |
| 16:55.20 | file | then I'd be fine with it |
| 16:55.56 | file | tests aren't across a network link so if there's packet loss, all hope is lost |
| 16:57.51 | kharwell | right and if there is packet loss then the test will fail due to never receiving a response which will notify us of a more potentially serious underlying problem |
| 17:00.38 | kharwell | I guess another option is is to bump the retrans time up in tests. I'll create an issue and someone can decide the best solution later |
| 17:01.46 | rmudgett | I thought you were going to fix them if it was simple. We could add -nr to the default sipp parameters that the testsuite sets. |
| 17:02.39 | rmudgett | Though there isn't a turn on retransmissions option if some test really wants to have retransmissions. |
| 17:02.42 | kharwell | sure I can but in this case I don't think it is that simple. One could do what you said, but then if then all tests testing retransmission would need to be located and patched. |
| 17:03.22 | rmudgett | Are there any tests that test retransmission? |
| 17:03.53 | kharwell | dunno. but if so we'd have to add an option to the asterisk sipp handler to accept a custom param for those tests |
| 17:04.00 | rmudgett | It does seem like that would be a hard thing to test. |
| 17:04.14 | file | yeah I don't think we explicitly do it |
| 17:04.24 | file | and I don't think any test would be reliant on such behavior... |
| 17:05.16 | kharwell | I'll save it until the end then. I've got several more tests to look at. If they all are similar or turn out to be nothing then maybe I'll just fix it. |
| 17:05.56 | kharwell | unless you want to go ahead with it rmudgett since it's so easy :-D |
| 17:06.29 | rmudgett | I'm busy causing my own trouble in pjsip_scheduler.c |
| 17:06.58 | file | is excited for better OPTIONS |
| 17:07.53 | rmudgett | file: Are you needing more OPTIONS? |
| 17:08.09 | file | rmudgett: yes! and donuts, donuts are good |
| 17:10.49 | jpsharp | Ooooooh, donuts. |
| 17:11.38 | gtjoseph | kharwell: while you're looking at tests, there was one that could do with a sipp change... pjsip/subscriptions/ast_restart |
| 17:11.55 | gtjoseph | it sometimes barfs because the scenario gets an unexpected NOTIFY |
| 17:11.56 | kharwell | that's the next one I am looking at |
| 17:12.03 | kharwell | ya |
| 17:12.23 | gtjoseph | if you add -aa to the sipp parameters, sipp will auto answer it and not disturb the scenartio |
| 17:14.38 | kharwell | but why it is getting the extra NOTIFY in the first place? |
| 17:14.50 | kharwell | and wont' that auto answer all the notifies? |
| 17:15.42 | gtjoseph | true. hmmm. maybe it like the others where we're not OKing quicky enough |
| 17:16.38 | gtjoseph | that may be ok thoughif the test determines pass/fail based on the AMI events |
| 17:17.01 | gtjoseph | might ask rmudgett what the intent was. |
| 17:21.08 | seanbright | gtjoseph: i wish you never sent me this natex.us link |
| 17:21.17 | seanbright | i keep looking at it and thinking... "why not?" |
| 17:22.11 | seanbright | 624 cores, 312GB of ram, onboard SFP+ |
| 17:26.07 | file | lol |
| 17:26.25 | file | resist! |
| 17:27.09 | seanbright | but i have this $15,600 just burning a hole in my pocket |
| 17:27.10 | seanbright | heh |
| 17:27.16 | seanbright | LOL. free shipping. |
| 17:27.17 | seanbright | hah |
| 17:27.35 | file | invest in... squirrel food! |
| 17:33.24 | seanbright | can we require autoconf 2.69 at this point? |
| 17:33.36 | seanbright | it was released in 2012 |
| 17:33.40 | seanbright | i don't need it |
| 17:34.01 | seanbright | but i have to partially revert my configure changes because it adds other stuff |
| 17:34.19 | jsmith | seanbright: I'm telling you, let's just move to meson instead :-) |
| 17:34.36 | jsmith | wishes he had more hours in the day |
| 17:34.38 | seanbright | i think i'd vote for cmake first |
| 17:34.48 | jsmith | Have you tried meson? |
| 17:34.48 | seanbright | at least some of us have experience with that |
| 17:34.51 | seanbright | no |
| 17:34.53 | jsmith | I like it even better than CMake |
| 17:35.16 | jpsharp | is it faster than ./configure? |
| 17:35.44 | jsmith | yes |
| 17:36.23 | seanbright | or we rewrite in rust and use cargo |
| 17:36.31 | seanbright | i'll get started |
| 17:36.46 | seanbright | emacs asterisk.rs |
| 17:36.48 | seanbright | sorry, wrong window |
| 17:44.01 | jpsharp | Good, cause 80% of the build time for asterisk (and just about anything else) is waiting on ./configure to figure out who's on first. |
| 17:45.06 | seanbright | we make autoconf look for the superset of dependencies and then you reduce what is built via menuselect |
| 17:45.23 | seanbright | maybe we trim down the default behavior of configure and add a --kitchen-sink flag |
| 17:46.07 | jsmith | seanbright: I'm fine with --bathroom-sink |
| 17:46.10 | seanbright | i don't compile asterisk often enough to really care how fast configure is though, but that's just me |
| 17:46.22 | file | I do it many times a day and it doesn't bother me |
| 17:46.59 | *** join/#asterisk-dev CELYA_ (~Thunderbi@ppp-seco11pareq2-46-193-142-233.wb.wifirst.net) |
| 18:14.33 | kharwell | gtjoseph: it seems with the restart test Asterisk is sending out two notifies after receiving the refresh sub message |
| 18:16.09 | kharwell | the log files only has second resolution, but they are sent within the same second. |
| 18:16.50 | gtjoseph | Ah well. take it up with rmudgett :) |
| 18:17.00 | kharwell | if asterisk is retransmitting does the logger state that? For instance when it sends out an initial message it says "transmitting ..." Would it instead say "retransmitting ..."? |
| 18:17.31 | gtjoseph | i don't think so. the logger doesn't know what's going on. |
| 18:17.56 | rmudgett | The logger isn't that smart. |
| 18:22.11 | kharwell | Asterisk is sending two notifies out when it should be sending one. Makes me think the problem is in Asterisk. The first notify is sent, the 200 OK is received then Asterisk sends it again. So maybe there is a race between receiving the 200 OK and retransmitting |
| 18:24.47 | file | are they identical? |
| 18:25.21 | kharwell | they appear to be yes |
| 18:26.03 | file | yeah, sounds like a race |
| 18:29.46 | *** join/#asterisk-dev csavinovich (~KingDavid@ip98-169-120-168.dc.dc.cox.net) |
| 18:43.02 | *** join/#asterisk-dev snuff-work (~snuff-wor@210.9.148.102) |
| 18:43.02 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 19:00.31 | *** join/#asterisk-dev cresl1n (Adium@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 19:00.31 | *** mode/#asterisk-dev [+o cresl1n] by ChanServ |
| 19:05.26 | kharwell | seeing this for one of the tests: "Unable to bind video RTP socket (IP=::1, port=6011), errno = 98 (Address already in use)." |
| 19:05.38 | kharwell | I've seen that before. Wasn't that due to the next test executing before the one prior fully cleaned up or something? |
| 19:05.43 | gtjoseph | yes |
| 19:05.44 | file | I believe so, yes |
| 19:05.55 | gtjoseph | particilarly in the case of TCP/TLS |
| 19:06.07 | gtjoseph | the OS has the socket in TIME_WAIT status |
| 19:06.37 | gtjoseph | update the test to use a port not used in a while. :) |
| 19:06.58 | seanbright | test# + 1000 |
| 19:07.03 | seanbright | you're welcome |
| 19:07.17 | gtjoseph | too bad we don't have uniqqe test numbers |
| 19:07.23 | seanbright | FOILED AGAIN |
| 19:07.44 | gtjoseph | i'm sire kharwell could whip that up easily though. |
| 19:08.20 | kharwell | I already have something else in the queue to whip up so it'll have to wait |
| 19:45.22 | kharwell | more race conditions maybe! Does the pjsip presence state notification code send a notify for every presence state change or if two state changes happen quickly it only sends the second? |
| 19:46.42 | file | I think it should send a notify for each. |
| 19:46.52 | file | should/does |
| 20:07.28 | *** join/#asterisk-dev tzafrir (~tzafrir@62-90-199-247.barak.net.il) |
| 20:07.28 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 20:31.36 | coreyfarrell | seanbright: I had already proposed require autoconf-2.69 (it includes some macro's that make it easier to add test caching). centos-6 doesn't have it, that's why the proposal sputtered out. |
| 20:32.20 | seanbright | jesus. they support that for 9 years? |
| 20:32.22 | seanbright | my god |
| 20:32.42 | coreyfarrell | centos-6 is EOL after nov 2020 |
| 20:32.56 | seanbright | ok. i'll make a note to revisit this issue then. |
| 20:33.00 | seanbright | (not really) |
| 20:33.11 | seanbright | what version does centos 6 have? |
| 20:34.42 | coreyfarrell | I think 2.63. it also has an older version of m4 I think.. I had to do a follow-up to one of my configure patches because gtjoseph told me I broke ./bootstrap.sh in centos-6 |
| 20:35.05 | gtjoseph | yep |
| 20:36.28 | seanbright | pretty lame |
| 20:46.43 | *** join/#asterisk-dev cresl1n (Adium@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 20:46.43 | *** mode/#asterisk-dev [+o cresl1n] by ChanServ |
| 20:56.02 | *** join/#asterisk-dev cresl1n (Adium@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 20:56.02 | *** mode/#asterisk-dev [+o cresl1n] by ChanServ |
| 22:12.55 | *** part/#asterisk-dev kharwell (kharwell@nat/digium/x-azalaueojgwumsyf) |
| 22:43.35 | *** join/#asterisk-dev snuff-work (~snuff-wor@210.9.148.102) |
| 22:43.35 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |