| 02:18.14 | *** join/#asterisk-dev infobot (ibot@208.53.50.136) |
| 02:18.14 | *** topic/#asterisk-dev is Asterisk Development Discussion -=- http://www.asterisk.org/developers -=- Tier 2 and 3.14159265 support is in #asterisk -=- Check out our blog! blogs.asterisk.org -=- Follow on Twitter at @AsteriskDev |
| 07:09.52 | *** join/#asterisk-dev tsearle (~tsearle@37.19.10.33) |
| 07:09.52 | *** mode/#asterisk-dev [+o tsearle] by ChanServ |
| 07:23.11 | *** join/#asterisk-dev pchero_work (~pchero@87.213.240.121) |
| 08:06.29 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01:e0a:d:1111:b749:768d:ed77:7c9a) |
| 09:58.55 | *** join/#asterisk-dev jkroon (~jkroon@165.16.204.34) |
| 10:19.55 | tsearle | I was going to say @file is up early today |
| 10:20.11 | tsearle | but then I realized we have had a timechange and North america hasn't yet |
| 11:09.05 | coreyfarrell | when the time changes I'm just going to set my alarm an hour later. I hate daylight savings. |
| 11:10.56 | file | I like trains! |
| 11:18.17 | *** join/#asterisk-dev jameswf (uid27319@gateway/web/irccloud.com/x-ytoggvaunzpexkdz) |
| 11:18.17 | *** mode/#asterisk-dev [+o jameswf] by ChanServ |
| 11:35.46 | *** join/#asterisk-dev jkroon (~jkroon@105.12.5.148) |
| 12:21.53 | *** join/#asterisk-dev russellb (~rustlebee@redhat/russellb) |
| 12:21.53 | *** mode/#asterisk-dev [+o russellb] by ChanServ |
| 12:22.20 | *** part/#asterisk-dev russellb (~rustlebee@redhat/russellb) |
| 12:39.05 | tsearle | coreyfarrell: if you hate daylight savings, then you should be happy it's ending :-) |
| 12:46.53 | *** join/#asterisk-dev bford (uid283514@gateway/web/irccloud.com/x-xfvezclkkzuqetfb) |
| 12:46.53 | *** mode/#asterisk-dev [+o bford] by ChanServ |
| 12:52.49 | coreyfarrell | tsearle: ah I'm thinking backwards, so I guess I'll be setting my alarm an hour earlier. I'd prefer to stay on permanent summer time. annoying that a week from now it'll start getting dark before 5pm. |
| 12:55.38 | tsearle | I'm on the opposite stance. I hate waking up in the dark. I'm glad that it's light again for a little wile longer |
| 12:58.29 | *** join/#asterisk-dev sduthil (~sduthil@modemcable094.94-70-69.static.videotron.ca) |
| 13:05.10 | tsearle | but I'm alot farther north than you, so winter makes a huge difference |
| 13:07.07 | coreyfarrell | I'm in CT, use the grill a lot even in the winter and don't have good lighting on the deck, annoying to make dinner in the dark. |
| 13:48.30 | *** join/#asterisk-dev hehol (~hehol@gatekeeper.loca.net) |
| 13:56.00 | *** join/#asterisk-dev dandann00dle (~dandann00@2601:840:8401:d7ee:cd87:f9f3:b237:db82) |
| 14:22.01 | *** join/#asterisk-dev kharwell (kharwell@nat/digium/x-euzuuntyawopqlwg) |
| 14:22.01 | *** mode/#asterisk-dev [+o kharwell] by ChanServ |
| 14:25.46 | *** join/#asterisk-dev cresl1n (uid299068@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 14:25.46 | *** mode/#asterisk-dev [+o cresl1n] by ChanServ |
| 14:39.01 | *** join/#asterisk-dev vicp (~vicp@37.19.10.33) |
| 14:39.52 | tsearle | https://gerrit.asterisk.org/#/c/testsuite/+/10528/ |
| 14:40.20 | tsearle | could somebody give this gerrit some love? it's fixing bugs in existing test cases & improving testcoverage |
| 14:40.39 | tsearle | no asterisk patches are required for it to be merged in |
| 14:41.16 | gtjoseph | will get to it today. |
| 14:42.02 | tsearle | thanks! :-) |
| 14:44.01 | *** join/#asterisk-dev sahmed (~sahmed@63.65.120.22) |
| 14:44.07 | tsearle | aso gtjoseph: rcipps added a testsuite test to the jira that reproduces the packetisation problem |
| 14:44.31 | tsearle | I see you updated the jira for asking for feedback, I hope the testsuite case should clear things up :-) |
| 14:45.10 | gtjoseph | ah, i didn't look closely at the testsuite review. thanks. |
| 14:45.30 | tsearle | it's introducing rtpdump again |
| 14:45.38 | tsearle | but this time w/o the proprietary flag for dtmf events |
| 14:45.43 | tsearle | so stock rtpdump should work |
| 14:47.39 | file | the tests don't answer my question about why some code was added in a place |
| 14:48.35 | file | they cover the other case I had a comment on |
| 14:48.52 | tsearle | ok |
| 14:50.07 | file | the confusion I have is that some code was added in SDP negotiation when there is no joint format in offer/answer - when the stream in SDP is rejected |
| 14:50.32 | file | to set the framing, and I don't understand why that is needed or the particular scenario |
| 14:50.51 | tsearle | yeah, I'm afraid I cant give an honest answer there |
| 14:51.31 | tsearle | my understanding was that place of code was where it was decided that transcoding has to happen (and the codec object gets destroied & framing lost on the very next line) |
| 14:51.52 | file | it's not, it's strictly for SDP offer/answer negotiation |
| 14:52.18 | tsearle | ok, so then perhaps there is a better place for that copy to happen |
| 14:52.25 | tsearle | but the copy does resolve the issue |
| 14:52.36 | *** join/#asterisk-dev rmudgett (rmudgett@nat/digium/x-iyrztlrejwlevlwp) |
| 14:52.36 | *** mode/#asterisk-dev [+o rmudgett] by ChanServ |
| 14:52.38 | tsearle | trying to encourage rcripps on irc |
| 14:52.59 | tsearle | but not sure he'll jump on, he's on a train to london atm to goto the hospital |
| 14:54.31 | file | responding on the review is fine, it just needs further information including the scenario, the SDP interaction, deeper info |
| 14:59.34 | tsearle | https://jenkins2.asterisk.org/job/asterisk-gatetests/job/16/233/ |
| 14:59.39 | tsearle | this a false alarm? |
| 15:00.17 | tsearle | I suppose so as blind xfer tests were also merged into this jenkins test |
| 15:19.27 | *** join/#asterisk-dev vicp (~vicp@37.19.10.33) |
| 15:35.50 | gtjoseph | tsearle: 2 things... I don't immediately see how Robert's tests reproduce the issue. Also, didn't you rewrite your tests to not use rtpdump? |
| 15:36.28 | tsearle | those were different tests |
| 15:36.48 | tsearle | ref packetization, it's kind of hard to validate that w/o actually looking at the packets |
| 15:37.00 | gtjoseph | yeah i know, i just wanted to confirm that they don't use rtpdump anynore because robert's do. |
| 15:37.33 | tsearle | as far as I know, robert's should be the only tests you have with rtpdump |
| 15:38.27 | tsearle | the nat rewrite_contact tests and the tests for callerid in contact do not use rtpdump |
| 15:38.28 | gtjoseph | are they using the options you added to rtpdump? |
| 15:38.59 | tsearle | no, I removed the -n flag from the tests, Roberts rtpdump tests should be able to work with stock rtpdump |
| 15:39.01 | gtjoseph | (i don't remember which options they were) |
| 15:39.06 | gtjoseph | gotcha |
| 15:39.08 | gtjoseph | thanks |
| 15:39.15 | tsearle | -n was for validating dtmf events, which isn't needed in this test |
| 15:39.41 | tsearle | I hope that should make the tests a bit more acceptable |
| 15:41.32 | gtjoseph | any chance he could write his verify_* scripts in python instead of perl? :) |
| 15:42.12 | tsearle | they don't have any imports do they? |
| 15:42.33 | tsearle | thought perl was ok so long as the scripts didn't have any library dependencies |
| 15:43.00 | gtjoseph | no imports. |
| 15:44.15 | cresl1n | I'd prefer keeping things in python |
| 15:44.37 | cresl1n | <--- cresl1n the engineer, not cresl1n the project lead |
| 15:44.44 | tsearle | hehe |
| 15:45.15 | cresl1n | I think things will be more likely to be maintained if we keep languages consistent |
| 15:45.21 | tsearle | well one thing at a time then I guess, I suppose top priority for Robert should be to address the concerns ref the corresponding patch |
| 15:45.32 | gtjoseph | yep. |
| 15:46.56 | tsearle | though our entire fleet of rtpdump based validation scripts are in perl, perhaps I should look into migrating them to prevent future headaches |
| 15:48.46 | tsearle | we have scripts to validate received codecs, sequence numbers, ssrc changes, rtp jitter, dtmf event validation |
| 15:49.30 | seanbright | these perl scripts are pretty basic |
| 15:49.44 | tsearle | yeah, it's just parsing a text file |
| 15:49.46 | seanbright | read a file line by line, match with a regex, do some simple comparisons, bail out |
| 15:49.58 | seanbright | this is 15 lines of python code |
| 15:50.07 | seanbright | and i don't know python |
| 15:50.32 | tsearle | I python by google too |
| 15:50.51 | seanbright | it's not even idiomatic perl |
| 15:50.56 | seanbright | and i sorta know perl |
| 15:51.40 | tsearle | perl written by C programmers, heh |
| 15:52.20 | *** join/#asterisk-dev jkroon (~jkroon@165.16.204.34) |
| 15:56.48 | tsearle | goodnite all! |
| 15:59.50 | *** join/#asterisk-dev voxadam (~adam@fedora/voxadam) |
| 16:03.20 | voxadam | I was just reading an article on LWN about a conversation at the Kernel Maintainer Summit about the removal of old hardware drivers from the Linux kennel. Arnd Bergmann mentioned that the ISDN subsystem might be a candidate for removal. I was wondering do Linux based PBX systems still depend on ISDN hardware? |
| 16:04.51 | file | depend? no |
| 16:06.29 | voxadam | Let me rephrase that. Are there a non-negligible number of users of ISDN subsystem in the world of Linux based PBX systems? |
| 16:07.08 | file | cresl1n: I don't think any in our world use the ISDN subsystem - do they? |
| 16:07.12 | voxadam | I'm not terribly well acquainted with PBX systems. |
| 16:07.47 | cresl1n | Dependence is a product of circumstances |
| 16:07.52 | cresl1n | some people still have ISDN lines |
| 16:08.02 | cresl1n | although that is becoming less and less of an issue |
| 16:08.13 | cresl1n | (as telcos phase them out) |
| 16:08.24 | file | cresl1n: my query was more from within the kernel itself |
| 16:08.31 | voxadam | Sounds like it's not so much of an issue. |
| 16:08.40 | cresl1n | Probably less so as time goes on |
| 16:08.55 | cresl1n | I don't think many people in the Asterisk user base use the kernel ISDN drivers |
| 16:09.09 | cresl1n | closest thing to it was the mISDN subsystem a few years ago |
| 16:09.19 | cresl1n | but that probably sees a lot less use time nowadays |
| 16:09.30 | cresl1n | most people have moved to DAHDI based ISDN support |
| 16:09.47 | voxadam | That's good to hear. |
| 16:24.05 | coreyfarrell | chan_misdn is deprecated in 16+ |
| 16:41.57 | rmudgett | Not to mention that the version of mISDN supported by chan_misdn will not build on current os versions |
| 16:48.29 | voxadam | It sounds like if the ISDN subsystem were to be remove from the Linux kernel it would result in little, if any, trouble for Asterisk. |
| 16:48.45 | file | correct |
| 17:03.00 | *** part/#asterisk-dev voxadam (~adam@fedora/voxadam) |
| 17:47.03 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01cb0583d31d00818abd875aaa8c3a.ipv6.abo.wanadoo.fr) |
| 17:50.30 | kharwell | coreyfarrell: regarding commit issue tagging - just putting the issue id closes it now? |
| 17:50.38 | seanbright | yes |
| 17:50.48 | kharwell | totally missed that. When did that happen? |
| 17:50.56 | seanbright | at least a year |
| 17:50.58 | file | two years ago? |
| 17:51.18 | kharwell | ha oh well |
| 17:51.31 | file | it's due to it being Gerrit that does the closure, that Java plugin for Gerrit does not have the concept of "smart tags" like the barely working JIRA one did |
| 17:52.00 | kharwell | coreyfarrell: using a ~ will somewhat break the release scripts. At least when it builds the summaries and such. I don't think it will be able to locate that issue in jira as I assume it doesn't parse against a '~' |
| 17:52.22 | file | I don't think it cares with those tbh |
| 17:52.45 | rmudgett | Any references to issues closes that issue even if you are just mentioning it for some other reason in the commit message. |
| 17:52.45 | file | unless we really wanted it to be in the notes I guess |
| 17:53.30 | kharwell | rmudgett: brings up a good point too. I've seen some commits reference other issues and that means those get auto-closed as well. |
| 17:53.45 | kharwell | Unless you alter the id in some way |
| 17:53.48 | file | yes |
| 17:53.56 | rmudgett | The release scripts only care about the issue the patch is for. Referencing other issues won't matter if you break the issue id format. |
| 17:54.24 | kharwell | It won't link in gerrit though right? Without having to modify the url? |
| 17:54.45 | file | define link |
| 17:55.17 | kharwell | right now in gerrit it gives me a link to the asterisk issue. Using something like a '~' will break that |
| 17:55.37 | file | that is correct |
| 17:55.39 | rmudgett | Gerrit won't reconginize an issue tag if you replace the '-' with something else like '~' or '_' |
| 17:55.45 | kharwell | the release scripts *I'm guessing* will just mark it as a commit without an issue |
| 17:55.47 | file | you can't have it both ways, unless you want to write Java. |
| 17:55.59 | file | :P |
| 17:57.41 | kharwell | at the very least then we should agree on an alternate specifier ('~'?) and should prob update the release script(s) to check for that |
| 17:58.03 | rmudgett | Putting the issue tag as the gerrit topic gets it displayed in the gerrit review section of the JIRA issue |
| 17:58.11 | file | I'm fine with ~, it doesn't matter that much |
| 17:58.50 | coreyfarrell | kharwell: the release summary for asterisk doesn't list testsuite patches |
| 17:59.06 | rmudgett | Why should the scripts need to decipher the altered issue identifiers? |
| 17:59.47 | kharwell | coreyfarrell: that's true for this, but would be a problem for Asterisk source |
| 18:00.26 | coreyfarrell | kharwell: yeah I agree it's unfortunate JIRA doesn't support 'related to' tagging, any reference to the issue closes the ticket. |
| 18:00.43 | kharwell | rmudgett: when it builds the release summary it categorizes the issues. It uses the issue id in the log to search in jira for that id |
| 18:01.30 | kharwell | one's it can't find are marked as commits with no associated issue |
| 18:02.31 | rmudgett | Yes that is why you should reference the explicit id in that case because that patch is for that issue. If you reference another issue in the commit message as 'may fix' or was 'caused by' you want to use the altered id so as to not close the wrong issue. |
| 18:03.53 | seanbright | can we just fix the gerrit plugin? |
| 18:03.57 | seanbright | to require #close? |
| 18:05.08 | file | it's open source. |
| 18:05.11 | file | (so yes) |
| 18:05.12 | seanbright | link? |
| 18:05.14 | seanbright | name? |
| 18:05.17 | seanbright | ANYTHING? |
| 18:05.33 | file | https://gerrit.googlesource.com/plugins/its-jira/ |
| 18:05.45 | file | https://gerrit.googlesource.com/plugins/its-base/ |
| 18:06.09 | file | it's a rules based system - kind of like an IFTTT |
| 18:06.21 | file | our config is simple, |
| 18:06.24 | file | https://www.irccloud.com/pastebin/2yl1PpdS/ |
| 18:08.18 | file | ooh |
| 18:08.21 | file | I think they added what we need |
| 18:08.50 | file | https://gerrit.googlesource.com/plugins/its-base/+/master/src/main/resources/Documentation/config-rulebase-common.md |
| 18:08.57 | file | Property: association |
| 18:11.35 | file | so could probably do, Closes: ASTERISK-42 |
| 18:12.55 | seanbright | might be easier to just ~ it |
| 20:21.02 | *** join/#asterisk-dev pchero_work (~pchero@dhcp-077-249-058-090.chello.nl) |
| 20:36.02 | *** join/#asterisk-dev pchero_work (~pchero@dhcp-077-249-058-090.chello.nl) |
| 21:35.28 | *** join/#asterisk-dev pchero_work (~pchero@dhcp-077-249-058-090.chello.nl) |
| 22:00.06 | *** join/#asterisk-dev pchero_work (~pchero@dhcp-077-249-058-090.chello.nl) |
| 22:33.09 | *** join/#asterisk-dev CELYA_1 (~Thunderbi@be.celya.fr) |
| 23:07.47 | *** part/#asterisk-dev kharwell (kharwell@nat/digium/x-euzuuntyawopqlwg) |