| 00:18.26 | snuff-work | mm.. with the 'make install' of asterisk 17+ almost feel like we should add a line about if you need to build third party asterisk modules remember to do 'make install-headers' |
| 00:27.27 | snuff-work | mm.. |
| 00:27.34 | snuff-work | got a compile error on trunk |
| 00:27.36 | snuff-work | 'chan_pjsip.so': /usr/lib/asterisk/modules/chan_pjsip.so: undefined symbol: ast_sip_cli_traverse_objects |
| 00:27.43 | snuff-work | well a 'runtime' error |
| 00:28.19 | file | res_pjsip.so didn't load |
| 00:30.32 | snuff-work | mm i see the module is there though.. |
| 00:30.42 | snuff-work | well no 'error' relating to it not loading |
| 00:31.27 | snuff-work | ok..manually tried.. found it |
| 00:31.28 | snuff-work | [Jan 14 11:31:13] ERROR[8555]: loader.c:281 module_load_error: Error loading module 'res_pjsip.so': /usr/lib/asterisk/modules/res_pjsip.so: undefined symbol: pj_ssl_cipher_name |
| 00:31.28 | snuff-work | Unable to load module res_pjsip.so |
| 00:31.28 | snuff-work | Command 'module load res_pjsip.so ' failed. |
| 00:31.56 | file | and res_pjproject.so? |
| 00:32.25 | snuff-work | that did load |
| 00:32.39 | file | bundled or unbundled? |
| 00:32.49 | snuff-work | bundled |
| 00:32.54 | snuff-work | let me 'retest' |
| 00:33.04 | snuff-work | i might not have ssl-devel related pkg |
| 00:33.54 | snuff-work | ok.. no openssl-devel installed.. going to re-do it all see if it works after installing |
| 00:40.49 | coreyfarrell | that's weird, asterisk 16+ should should refuse to load chan_pjsip.so unless res_pjsip.so is loaded. |
| 00:43.49 | coreyfarrell | oh I see what's happening, ast_sip_cli_traverse_objects is used through AST_CLI_DEFINE which means it is effectively being used by reference so it's not possible to see the module info as RTLD_LAZY cannot ignore a "reference to symbol" |
| 00:54.57 | snuff-work | ok.. after installing openssl-devel.. its all good |
| 00:55.04 | snuff-work | pjsip loads as expected |
| 02:47.39 | *** join/#asterisk-dev sahmed (~sahmed@cpe-70-114-236-63.austin.res.rr.com) |
| 03:12.05 | snuff-work | mm reviewing some 'module descriptions'.. app_mp3.. Silly MP3 Application... app_nbscat Silly NBS Stream application |
| 05:54.40 | *** join/#asterisk-dev jkroon (~jkroon@165.16.203.126) |
| 07:10.20 | *** join/#asterisk-dev pchero_work (~pchero@87.213.247.82) |
| 08:20.06 | *** join/#asterisk-dev hehol (~hehol@gatekeeper.loca.net) |
| 08:29.13 | *** join/#asterisk-dev sahmed (~sahmed@cpe-70-114-236-63.austin.res.rr.com) |
| 13:50.46 | *** join/#asterisk-dev dakudos (~dakudos@c-73-229-175-50.hsd1.co.comcast.net) |
| 13:58.41 | *** join/#asterisk-dev gtjoseph (~gtjoseph@unaffiliated/gtj) |
| 13:58.41 | *** mode/#asterisk-dev [+o gtjoseph] by ChanServ |
| 14:28.38 | *** join/#asterisk-dev hehol (~hehol@gatekeeper.loca.net) |
| 15:11.07 | *** join/#asterisk-dev kharwell (uid358942@gateway/web/irccloud.com/x-utxwvkjwhwjkmaha) |
| 15:11.07 | *** mode/#asterisk-dev [+o kharwell] by ChanServ |
| 15:17.42 | *** join/#asterisk-dev bford (uid283514@gateway/web/irccloud.com/x-kfxohaqafzlhcfdy) |
| 15:17.42 | *** mode/#asterisk-dev [+o bford] by ChanServ |
| 15:21.13 | *** join/#asterisk-dev moy (sid47040@gateway/web/irccloud.com/x-numxmklnecktmnpc) |
| 16:11.55 | *** join/#asterisk-dev jkroon (~jkroon@165.16.204.108) |
| 16:16.04 | *** join/#asterisk-dev sduthil (~sduthil@modemcable094.94-70-69.static.videotron.ca) |
| 16:20.44 | seanbright | ASTERISK-28689 - maybe consider fail2ban? jesus |
| 16:21.46 | seanbright | i don't see a core file in core.tar.gz either |
| 16:59.43 | seanbright | i would like to update the 'Resolution' on these to 'Suspended': |
| 16:59.45 | seanbright | project = ASTERISK AND resolution = Unresolved AND status = Closed AND text ~ "\"Suspended due to lack of activity\"" |
| 17:00.08 | seanbright | there are 277 issues that match that query |
| 17:00.33 | file | go for it, just make sure the thingy isn't selected to send email notifications |
| 17:00.41 | seanbright | i don't have bulk |
| 17:00.48 | seanbright | ohw ait |
| 17:00.53 | seanbright | oh wait* maybe i do |
| 17:02.46 | file | yay, or nay |
| 17:02.51 | seanbright | i do |
| 17:03.01 | file | excellent |
| 17:03.08 | seanbright | i might be killing jira though |
| 17:03.41 | file | it'll come back to life... eventually |
| 17:04.45 | seanbright | so i don't have a checkbox to turn off e-mails |
| 17:05.00 | seanbright | unless updating a resolution doesn't send one |
| 17:05.03 | seanbright | let me test that first |
| 17:09.54 | seanbright | file: can you update the resolution on ASTERISK-28690 |
| 17:10.01 | seanbright | to anything other than what it currently is |
| 17:10.13 | file | if I find the right tab... maybe |
| 17:10.29 | seanbright | it's a button for me: "Update Resolution" |
| 17:10.33 | file | done |
| 17:10.47 | file | did it not allow you? |
| 17:11.30 | seanbright | it does, but i want to make sure that it's not sending the e-mail because it doesn't send an e-mail and not that i am the reporter and the one doing the change |
| 17:11.33 | seanbright | if that makes sense. |
| 17:11.41 | file | ah |
| 17:11.56 | seanbright | ok, i don't have an e-mail, so LET'S DO THIS |
| 17:13.00 | seanbright | ok, here we go. last chance to tell me to stand down |
| 17:13.04 | seanbright | 3... |
| 17:13.07 | seanbright | 2... |
| 17:13.09 | seanbright | 1... |
| 17:13.31 | seanbright | it's happening |
| 17:14.39 | seanbright | and it's done |
| 17:15.01 | seanbright | the project 30 day summary looks much better now |
| 17:15.45 | file | what else shall you clean up? |
| 17:16.33 | seanbright | well anything that is closed should have a resolution |
| 17:16.39 | file | this is true |
| 17:16.44 | seanbright | but i think doing that in bulk would be dangerous |
| 17:17.20 | seanbright | 121 issues in that state |
| 17:17.37 | seanbright | information requests |
| 17:17.50 | seanbright | 'Not a Bug?' |
| 17:18.06 | file | what do we set them to right now... |
| 17:18.11 | seanbright | Unresolved |
| 17:18.19 | file | thought I fixed that, lemme look |
| 17:18.21 | seanbright | k |
| 17:18.30 | file | oh, or maybe it was the suspended one |
| 17:18.54 | file | yeah it was the suspended one I fixed |
| 17:19.27 | seanbright | project = ASTERISK AND issuetype = "Information Request" AND resolution = Unresolved AND status = Closed AND text ~ "\"We appreciate the difficulties you are facing\"" |
| 17:19.40 | seanbright | what is a reasonable resolution for those? |
| 17:19.48 | file | I think Not A Bug personally |
| 17:19.51 | seanbright | k |
| 17:19.55 | file | I'm trying to remember how to get the code for that... |
| 17:20.17 | seanbright | i'm going to bulk those 100 issues to Not A Bug |
| 17:20.42 | file | ah there it is |
| 17:20.45 | file | 7. |
| 17:21.12 | file | the automation should now set it to Not A Bug automatically |
| 17:21.16 | seanbright | nice |
| 17:22.05 | seanbright | "Per the Asterisk versions page [1], the maintenance (bug fix) support for the Asterisk branch you are using has ended." |
| 17:22.08 | seanbright | resolution for that? |
| 17:23.29 | file | hum |
| 17:23.47 | file | Won't Fix? |
| 17:24.33 | seanbright | ok, down to 6 closed issues that don't have a resolution |
| 17:25.22 | seanbright | and all of those have the "We appreciate the difficulties" comment |
| 17:25.33 | seanbright | so will transition those to Not A Bug |
| 17:26.03 | seanbright | and there we go |
| 17:26.31 | seanbright | hey, we resolved 456 issues in the last 30 days, nice work |
| 17:28.00 | file | and for your next trick? |
| 17:28.05 | seanbright | lunch |
| 17:28.10 | file | solid idea |
| 17:28.21 | file | I opted for a snack, going out for dinner with my mother |
| 18:00.21 | seanbright | i was kinda hoping for a -1 on https://gerrit.asterisk.org/c/asterisk/+/13588 |
| 18:00.33 | seanbright | it fixes the issue, but it feels wrong |
| 18:07.50 | kharwell | Seems like a reasonable approach? |
| 18:08.27 | kharwell | I mean I guess you could push the find_header check into the multiple_headers_allowed function too I suppose |
| 18:08.36 | seanbright | eh |
| 18:08.45 | seanbright | i mean more from a compliance stand point |
| 18:08.58 | seanbright | there are certainly more headers than Event that are only allowed to appear once |
| 18:09.32 | kharwell | ah you mean you'd like to go ahead an add those too? |
| 18:09.38 | file | quick! make a comprehensive list! |
| 18:09.43 | seanbright | if there was such a list, yes |
| 18:09.53 | seanbright | but with all of the RFCs that would be difficult |
| 18:10.30 | kharwell | I think file has them all memorized so he could prob tell you real quick |
| 18:10.35 | seanbright | perfect |
| 18:10.38 | file | for a price. |
| 18:11.34 | file | but I think if we find others we can add them in, it's probably not worth it right now to do an exhaustive search |
| 18:12.01 | seanbright | works for me |
| 18:45.27 | file | seanbright: prolonged JIRA exposure may cause eye bleeding |
| 18:50.55 | seanbright | yeah, i think i'm done for the day |
| 18:51.45 | kharwell | How feasible is https://gerrit.asterisk.org/c/asterisk/+/13501/1 really? Doesn't the session get created during the "request" phase? So after a pre-dial handler has been run? |
| 18:52.49 | kharwell | meaning there is no session to get and set items on in the pre-dial handler |
| 18:52.51 | file | pre-dial is run after request, before call |
| 18:53.14 | file | so you have a session and a channel |
| 18:53.56 | kharwell | it looks like even then some endpoint items are being used in the create outgoing session allocation |
| 18:55.05 | file | ah yeah, I forgot some of them would be controlling some of the INVITE session and other aspects at creation time vs later |
| 18:56.03 | kharwell | what about threading as well? I guess if the channel is in a pre-dial handler then could something else be accessing and/or setting the data on the session or endpoint information? |
| 18:56.17 | file | it's serialized |
| 18:56.29 | file | if you violate that contract, all hope is lost |
| 18:56.35 | kharwell | that's good at least |
| 18:57.18 | kharwell | I guess maybe it'll kinda work then. Some items might have already been set, but a decent number will have not been used yet I suppose |
| 18:57.46 | file | aye, it's probably a good idea to have it explicitly prevent/warn the ones that can't be |
| 18:58.03 | kharwell | yeah |
| 18:59.08 | kharwell | Is there a way to tell if it is outgoing or not? Makes no sense to do it for incoming |
| 18:59.46 | file | is there a way yes, do I recall it no |
| 18:59.55 | file | :D |
| 19:00.13 | file | oh I remember, the role on the INVITE session |
| 19:00.15 | file | tells you UAS or UAC |
| 19:34.30 | seanbright | https://issues.asterisk.org/jira/browse/ASTERISK-27622 |
| 19:34.40 | seanbright | does anyone know what "ARA" is? or does he mean ARI? |
| 19:35.10 | file | Asterisk Realtime Architecture |
| 19:35.17 | seanbright | ahh |
| 19:36.03 | seanbright | that makes it sound so much fancier than it is |
| 19:36.14 | file | not wrong |
| 19:39.34 | seanbright | bford: question |
| 19:39.41 | bford | shoot |
| 19:40.10 | seanbright | so the change to QueueMemberPause, nothing is changing in 13, 16, or 17 except for documentation |
| 19:40.16 | seanbright | in master, i am removing the field |
| 19:40.33 | seanbright | so the 13, 16, and 17 patch is the same |
| 19:40.36 | seanbright | master is different |
| 19:40.59 | seanbright | so should the 13, 16, and 17 patches _not_ have the UPGRADE file at all? |
| 19:41.18 | seanbright | i didn't quite understand when i would use Master-Only |
| 19:42.08 | bford | yeah, since the script will see "Master-Only" and put it in a different section |
| 19:42.08 | bford | for example, when releasing 18, it would get lumped in the "From 17 to 18" section |
| 19:42.28 | bford | but that would never happen for 13, 16, 17, etc |
| 19:42.36 | seanbright | ok, so what should i do here? |
| 19:42.46 | seanbright | remove the CHANGES file from the 13, 16, and 17 patches? |
| 19:42.54 | kharwell | I might be confused as well? I thought it should be in each with the master-only flag set? |
| 19:43.10 | bford | if you want to keep the documentation of the change, you can just remove the master only flag from 13, 16, 17 |
| 19:43.19 | kharwell | I thought that was the point so you could cherry pick to each branch without any changes |
| 19:44.20 | bford | the flag is there to keep changes that are limited to the next branch release separate from other changes |
| 19:44.39 | seanbright | let me ask this |
| 19:44.41 | seanbright | let |
| 19:44.50 | bford | if you added a change that went into all branches, you leave out "Master-Only" |
| 19:44.50 | bford | but if it only goes in master, it has the "Master-Only" flag to keep it separate |
| 19:45.01 | seanbright | and that is what is going on here |
| 19:45.33 | seanbright | the change being described by the UPGRADE entry is only being changed in master |
| 19:46.02 | bford | right, but you don't need "Master-Only" for the documentation changes in 13, 16, and 17 |
| 19:46.15 | seanbright | ok, so tell me specifically what to do |
| 19:48.47 | bford | it would be 2 different changes here - 13, 16, and 17 would not be "Master-Only" if you want the documentation of the change in the UPGRADE file |
| 19:48.47 | bford | master has a code change, and would therefore need a note of it and you can have the "Master-Only" tag there with probably a different message that explains what got changed |
| 19:49.17 | bford | if you don't want the change documented, you can just remove the .txt file from 13, 16, 17 |
| 19:49.42 | seanbright | ok |
| 19:49.42 | bford | up to you |
| 19:49.42 | seanbright | kinda weird |
| 19:50.05 | seanbright | so when _would_ i use the Master-Only header? |
| 19:50.08 | bford | "Master-Only" just serves to keep changes separate from normal branches and master for when we do the big release |
| 19:50.41 | bford | if the change went just into master (like the AudioSocket review), it would have the "Master-Only" tag |
| 19:50.48 | seanbright | ok, i'm confused, but whatever. i'll just remove the upgrade notes from the release branch changes |
| 19:50.55 | bford | that way, when 18 releases, it's lumped in the from 17 -> 18 section |
| 19:51.13 | bford | it's a history maintaining thing... it's kinda confusing |
| 19:51.27 | seanbright | but if the change goes only into master, then of course it's master-only |
| 19:51.31 | seanbright | which makes the header pointless |
| 19:51.45 | seanbright | i'm getting heated |
| 19:51.49 | seanbright | HEATED |
| 19:52.05 | bford | hides |
| 19:52.41 | seanbright | ok it's "fixed" |
| 19:53.55 | seanbright | kharwell: am i taking crazy pills? |
| 19:53.58 | bford | just think of it this way |
| 19:53.58 | bford | "Master-Only" stuff gets lumped in "New in 18" |
| 19:53.58 | bford | if it went into other branches too, it gets put in "From 17 to 18" |
| 19:53.58 | bford | so you can see what's new and what's not |
| 19:53.58 | bford | otherwise the script has no way of knowing what was introduced in 18 and what exists in other branches |
| 19:53.59 | kharwell | I think I've got it now. When you put a change into say 17 with stuff in CHANGES/UPGRADE then that gets cherry picked to master. When we do the next release, 18 in this case there needs to be a way to separate that change from changes that were done only in master (not a release branch), so it sets up like a "new feature" section in the 17->18 CHANGES sections when making the initial 18 release |
| 19:54.01 | bford | idk if that helps |
| 19:54.38 | seanbright | ok |
| 19:54.55 | seanbright | that makes sense now |
| 19:55.04 | seanbright | (not really, but i am tired of talking about id) |
| 19:55.06 | seanbright | it* |
| 19:55.13 | bford | :P |
| 19:55.15 | seanbright | i just won't make anymore master-only changes. problem solved. |
| 19:58.28 | seanbright | someone i know just called my mobile and left a voicemail |
| 19:58.31 | seanbright | a voicemail |
| 19:58.36 | seanbright | a. voicemail. |
| 19:58.38 | seanbright | it's 2020 |
| 19:58.44 | seanbright | and i have to listen to a voicemai |
| 19:58.47 | seanbright | voicemail* |
| 19:58.59 | kharwell | the future is now |
| 19:59.23 | seanbright | i'm going to text him back that i will give him $1,000 to never do that again |
| 20:00.26 | kharwell | careful he might fax you next time |
| 21:21.33 | snuff-work | seanbright: don't u have a voicemail to txt service? |
| 21:21.38 | snuff-work | most telcos have them =) |
| 21:21.52 | snuff-work | sometimes they make zero sense.. but they exist =D |
| 22:10.29 | seanbright | yeah, my iphone does transcription, but it's still annoying |
| 22:10.35 | seanbright | first world problems |
| 22:20.47 | file | my mobile provider does... voicemail to MMS >_> |
| 22:21.54 | file | and charges 65 cents a minute to call the US. |
| 22:28.41 | *** join/#asterisk-dev sh_smith (~sh_smith@cpe-172-88-21-24.socal.res.rr.com) |
| 22:31.04 | snuff-work | mm bit of fleecing going on there |
| 22:31.54 | seanbright | thought of the day: app_voicemail sucks |
| 22:32.01 | file | snuff-work: just a bit |
| 22:32.08 | file | or I can pay $10/mth for 1000 minutes |
| 22:32.32 | file | seanbright: tell us how you really feel |
| 22:32.42 | seanbright | sucks SO BAD |
| 22:33.57 | file | I knew the email would be you with a change there |
| 22:35.36 | seanbright | heh |
| 22:36.10 | seanbright | there is also code in there that makes me legitimately angry |
| 22:36.16 | seanbright | static char imapparentfolder[64] = "\0"; |
| 22:36.19 | seanbright | anger |
| 22:36.26 | seanbright | static char delimiter = '\0'; |
| 22:36.30 | seanbright | seething anger |
| 22:36.56 | seanbright | i need to get out more, clearly |
| 22:37.07 | snuff-work | mm my attempt to get sqlite to work across the whole realtime tables.. taking bit longer than expected =) |
| 22:37.34 | snuff-work | it did start with just updating the voicemail table to include additional fields |