| 01:58.20 | *** join/#asterisk-dev infobot (ibot@208.53.50.136) |
| 01:58.20 | *** 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 |
| 01:59.00 | *** join/#asterisk-dev leedm777 (~textual@2604:2d80:8404:ffae:cd07:374d:9acf:cbd1) |
| 01:59.00 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 03:19.13 | *** join/#asterisk-dev leedm777 (~textual@2604:2d80:8404:ffae:570:3a52:ab2c:ca54) |
| 03:19.14 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 03:43.02 | *** join/#asterisk-dev zopsi (~zopsi@dir.ac) |
| 06:06.02 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01:e0a:d:1111:603b:e09c:4155:ea9c) |
| 06:21.39 | *** join/#asterisk-dev tsearle (~tsearle@37.19.10.33) |
| 06:21.40 | *** mode/#asterisk-dev [+o tsearle] by ChanServ |
| 07:07.15 | *** join/#asterisk-dev hehol (~hehol@gatekeeper.loca.net) |
| 08:02.38 | *** join/#asterisk-dev ahmed89 (~ahmed89@85.154.169.183) |
| 08:27.25 | *** join/#asterisk-dev wdoekes (~walter@217.21.198.142) |
| 08:27.25 | *** mode/#asterisk-dev [+o wdoekes] by ChanServ |
| 12:01.58 | *** join/#asterisk-dev pc-m (~pcm@modemcable094.94-70-69.static.videotron.ca) |
| 12:06.07 | pc-m | Hello everyone, I updated the commit message on a Gerrit review as requested in the comments and pushed that new version without any code change. The review was updated but the Jenkins check from the previous patch set disappeared and I think Jenkins did not check that new patch set because the code did not change. Is there a button I can use to force Jenkins to check that patch set? https://gerrit.asterisk.org/#/c/asterisk/+/929 |
| 12:06.56 | file | there is no button, but you can comment "recheck" |
| 12:07.54 | pc-m | ok, thanks |
| 12:08.52 | *** join/#asterisk-dev AsteriskRoss (259d3426@gateway/web/freenode/ip.37.157.52.38) |
| 12:09.46 | *** join/#asterisk-dev leedm777 (~textual@2604:2d80:8404:ffae:a941:b9a2:54:8572) |
| 12:09.46 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 12:22.54 | *** join/#asterisk-dev leedm777 (~textual@2604:2d80:8404:ffae:a941:b9a2:54:8572) |
| 12:22.54 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 12:23.37 | *** join/#asterisk-dev leedm777 (~textual@2604:2d80:8404:ffae:a941:b9a2:54:8572) |
| 12:23.37 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 12:24.32 | *** join/#asterisk-dev leedm777 (~textual@2604:2d80:8404:ffae:a941:b9a2:54:8572) |
| 12:24.32 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 12:25.10 | *** join/#asterisk-dev leedm777 (~textual@2604:2d80:8404:ffae:a941:b9a2:54:8572) |
| 12:25.10 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 12:26.01 | *** join/#asterisk-dev leedm777 (~textual@2604:2d80:8404:ffae:a941:b9a2:54:8572) |
| 12:26.01 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 12:26.44 | *** join/#asterisk-dev leedm777 (~textual@2604:2d80:8404:ffae:a941:b9a2:54:8572) |
| 12:26.44 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 12:27.27 | *** join/#asterisk-dev leedm777 (~textual@2604:2d80:8404:ffae:a941:b9a2:54:8572) |
| 12:27.27 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 12:28.17 | *** join/#asterisk-dev leedm777 (~textual@2604:2d80:8404:ffae:a941:b9a2:54:8572) |
| 12:28.17 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 12:33.48 | *** join/#asterisk-dev leedm777 (~textual@2604:2d80:8404:ffae:a941:b9a2:54:8572) |
| 12:33.48 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 12:34.35 | *** join/#asterisk-dev leedm777 (~textual@2604:2d80:8404:ffae:a941:b9a2:54:8572) |
| 12:34.35 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 12:35.19 | gtjoseph | leedm777 is a flapper :) |
| 12:35.31 | *** join/#asterisk-dev leedm777 (~textual@2604:2d80:8404:ffae:a941:b9a2:54:8572) |
| 12:35.31 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 12:35.34 | tsearle | I blame ipv6 |
| 12:35.49 | gtjoseph | that's fair |
| 12:35.55 | file | he may be opening/closing his laptop ... a lot |
| 12:36.04 | gtjoseph | Ha! |
| 12:36.08 | tsearle | trying to fan himself on a hot day? |
| 12:36.19 | *** join/#asterisk-dev leedm777 (~textual@2604:2d80:8404:ffae:a941:b9a2:54:8572) |
| 12:36.19 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 12:36.54 | *** join/#asterisk-dev leedm777 (~textual@2604:2d80:8404:ffae:a941:b9a2:54:8572) |
| 12:36.54 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 12:37.04 | file | leedm777: calm down! |
| 12:37.23 | file | I'll ban him next time :D |
| 12:37.44 | *** join/#asterisk-dev leedm777 (~textual@2604:2d80:8404:ffae:a941:b9a2:54:8572) |
| 12:37.44 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 12:37.49 | *** mode/#asterisk-dev [+b leedm777!*@*] by file |
| 12:37.52 | *** kick/#asterisk-dev [leedm777!sid178970@asterisk/developer-and-muffin-lover/file] by file (leedm777) |
| 12:40.59 | tsearle | you didn't slap him with a giant trout? |
| 12:41.13 | file | negative! |
| 12:52.52 | seanbright | i'm not sure if there is anything that can be done about this, but - when you are on a review in gerrit and you click "Reply..." but you are not logged in, you get redirected to openid. once you submit your credentials, you are redirected back to an invalid URL |
| 12:53.12 | seanbright | so if i am here: https://gerrit.asterisk.org/#/c/asterisk/+/10226/ |
| 12:53.15 | tsearle | I've had an issue with that for a verly long time |
| 12:53.26 | seanbright | i get redirected back to here: https://gerrit.asterisk.org/#/c/asterisk/%20/10226/ |
| 12:53.28 | tsearle | quick fix is just to hit the back button :-P |
| 12:53.38 | seanbright | so a space instead of a + |
| 12:54.01 | tsearle | but isn't + supposed to be considered as a space in url encoding? |
| 12:54.21 | file | seanbright: yeah... it happened with a recent Gerrit update, but I don't know... why or how to make it not do that |
| 12:54.37 | file | it hasn't irked me enough to dig deep |
| 12:55.11 | seanbright | tsearle: i've never completely understood when + should be used and when it shouldn't be |
| 12:55.34 | seanbright | https://stackoverflow.com/questions/2678551/when-to-encode-space-to-plus-or-20 |
| 12:56.13 | seanbright | so given that the + is not part of the query string, it shouldn't be treated as a space |
| 12:56.22 | seanbright | but whatever |
| 12:56.51 | tsearle | ok so %20 before the ? and + after the ? |
| 12:57.05 | seanbright | no |
| 12:57.11 | seanbright | https://gerrit.asterisk.org/#/c/asterisk/+/10226/ |
| 12:57.16 | seanbright | that is a literal + |
| 12:57.20 | seanbright | oh wait... no it's not |
| 12:57.28 | seanbright | because it's after the # |
| 12:57.41 | tsearle | what does # mean in a url? |
| 12:57.54 | tsearle | an page anchor isn't it? |
| 12:57.58 | seanbright | basically |
| 12:58.07 | seanbright | only the part before the # is sent to the web server on a request |
| 12:58.25 | seanbright | it's how SPAs work |
| 12:59.01 | tsearle | perhaps we can write a greasemonkey plugin to compensate for the gerrit bug? |
| 12:59.02 | tsearle | :D |
| 12:59.15 | seanbright | i don't think it's gerrit. i think it's openid.asterisk.org |
| 12:59.39 | seanbright | and how it recontructs the 'return url' |
| 13:00.16 | seanbright | is openid.asterisk.org home grown? |
| 13:00.22 | seanbright | source available anywhere? |
| 13:00.55 | tsearle | it says it's atlassian crowdID |
| 13:01.00 | seanbright | ahhh |
| 13:01.04 | seanbright | well then nevermind |
| 13:01.08 | seanbright | it's NEVER get fixed |
| 13:01.35 | tsearle | I sense much love for Atlassian :-) |
| 13:01.48 | file | ponders |
| 13:01.55 | seanbright | they're just bad at writing java code |
| 13:02.03 | tsearle | well |
| 13:02.13 | tsearle | it seems openID hasn't been upgraded since 2014 |
| 13:02.21 | tsearle | so perhaps it's due for one |
| 13:03.40 | file | all of the Atlassian stuff is old versions, but upgrading isn't a "it'll take an hour thing" |
| 13:03.44 | file | we're hoping to do it after Astricon |
| 13:05.17 | gtjoseph | Our "after Astricon" list keeps getting bigger. :) |
| 13:07.27 | file | there is nothing in CrowdID for this |
| 13:08.22 | seanbright | let me look at the network trace |
| 13:08.33 | file | (configuration wise) |
| 13:11.05 | seanbright | https://gerrit.asterisk.org/loâ¦Fc%2Fasterisk%2F%2B%2F10226%2F |
| 13:11.16 | tsearle | https://gerrit.asterisk.org/login/%23%2Fc%2Ftestsuite%2F%2B%2F9847%2F |
| 13:11.33 | tsearle | we're digging the same way, heh |
| 13:11.52 | tsearle | don't see a %20 |
| 13:12.01 | file | hrm! |
| 13:12.33 | seanbright | when you decode that, you get "#/c/testsuite/+/9847/" |
| 13:12.37 | tsearle | + is %43 |
| 13:12.45 | seanbright | no |
| 13:12.54 | seanbright | + is %2B |
| 13:12.58 | seanbright | it's hex |
| 13:12.58 | tsearle | ha %2B |
| 13:13.00 | tsearle | 43 is dec |
| 13:13.20 | seanbright | i would argue it is encoded properly |
| 13:13.21 | tsearle | so gerrit is doing the right thing |
| 13:13.31 | tsearle | and openid is turning %2B into %20 |
| 13:13.34 | seanbright | assuming that crowdid uses the referer to return you |
| 13:13.41 | file | there's also an apache2 proxy in front |
| 13:13.53 | seanbright | well, it's turning %2B into + and then turning + into a space and then turning a space into %20 |
| 13:14.01 | tsearle | trying to vew the sorce of the openid page |
| 13:14.11 | tsearle | but I do'nt see the redir url encoded in it |
| 13:14.31 | gtjoseph | you guys are spending a lot of time on this :) |
| 13:14.39 | gtjoseph | I admire your dedication |
| 13:14.42 | tsearle | call it friday boredom |
| 13:15.50 | seanbright | i think it may actually be gerrit |
| 13:15.51 | seanbright | heh |
| 13:16.10 | tsearle | how so? |
| 13:16.19 | seanbright | https://gerrit.asterisk.org/OpenID?gerrit.mode=SIGN_IN&gerrit.token= |
| 13:16.32 | seanbright | in the response of that is a location header |
| 13:16.44 | seanbright | which has the space in it |
| 13:16.51 | seanbright | that's the first time i see the "bad" url |
| 13:17.02 | seanbright | let me look at the gerrit source |
| 13:17.39 | *** join/#asterisk-dev sh_smith (~sh_smith@cpe-76-174-26-91.socal.res.rr.com) |
| 13:21.27 | seanbright | i give up |
| 13:21.29 | seanbright | too hard |
| 13:21.31 | seanbright | :D |
| 13:22.04 | tsearle | https://gerrit.googlesource.com/gitiles/+/v0.2-6/java/com/google/gitiles/GitilesUrls.java |
| 13:26.05 | seanbright | encoding a space as %20 is correct |
| 13:26.15 | seanbright | going from %2B to a space is incorrect |
| 13:27.59 | seanbright | https://gerrit.googlesource.com/gerrit/+/stable-2.15/gerrit-openid/src/main/java/com/google/gerrit/httpd/auth/openid/OpenIdServiceImpl.java#481 |
| 13:29.40 | seanbright | so... moving on |
| 13:32.34 | seanbright | https://bugs.chromium.org/p/gerrit/issues/detail?id=9482 |
| 13:32.58 | seanbright | eh... maybe not |
| 13:34.17 | seanbright | https://gerrit.googlesource.com/gerrit/+/40471df546428fc7c47c2e038cbd302a31f4ee7f |
| 13:34.20 | seanbright | could be that |
| 13:44.44 | tsearle | a deeper question, why did the gerrit guys thing it was a good idea to have a + in their url in the first place? |
| 13:44.45 | coreyfarrell | does gerrit / openid allow the session timeout to be reconfigured? It would be *really* awesome if someone could set it to no less than 36 hours, very annoying being booted every day. |
| 13:45.09 | file | if someone finds an option and tells me what to set it to... |
| 13:46.43 | seanbright | cache.web_sessions.maxAge |
| 13:46.43 | file | ooh, auth.maxOpenIdSessionAge |
| 13:46.52 | seanbright | that works too |
| 13:47.04 | seanbright | yes, what you said |
| 13:47.07 | file | the openid one defaults to -1 which is infinite |
| 13:47.22 | tsearle | to infinity and beyond! |
| 13:47.43 | seanbright | so it might be cache.web_sessions.maxAge |
| 13:47.45 | seanbright | which is 12 hours |
| 13:47.49 | seanbright | by default |
| 13:48.56 | coreyfarrell | yeah I just found https://bugreports.qt.io/browse/QTQAINFRA-521 where QT says they set cache.web_sessions.maxAge |
| 13:49.16 | coreyfarrell | which shoudl hopefully be it if openid is infinite |
| 13:49.51 | file | let's seeeeeeeee |
| 13:50.51 | tsearle | a friday prod change |
| 13:50.55 | tsearle | what can possibly go wrong |
| 13:54.38 | file | it requires a restart, so I'll do it over the weekend |
| 13:55.01 | file | there's a new minor update too which I deployed internally fine, but hasn't been done public |
| 13:56.15 | *** join/#asterisk-dev gtjoseph_ (~gtjoseph@unaffiliated/gtj) |
| 13:56.15 | *** mode/#asterisk-dev [+o gtjoseph_] by ChanServ |
| 14:01.21 | *** join/#asterisk-dev kharwell (kharwell@nat/digium/x-rxnuizdxhevbubyh) |
| 14:01.21 | *** mode/#asterisk-dev [+o kharwell] by ChanServ |
| 14:05.47 | *** join/#asterisk-dev cresl1n (uid299068@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 14:05.47 | *** mode/#asterisk-dev [+o cresl1n] by ChanServ |
| 14:06.24 | *** join/#asterisk-dev bford (uid283514@gateway/web/irccloud.com/x-advfmrmcgjpcwfps) |
| 14:06.24 | *** mode/#asterisk-dev [+o bford] by ChanServ |
| 14:42.57 | *** join/#asterisk-dev rmudgett (rmudgett@nat/digium/x-fzxqvjmmliscjava) |
| 14:42.57 | *** mode/#asterisk-dev [+o rmudgett] by ChanServ |
| 15:50.54 | *** join/#asterisk-dev jameswf (uid27319@gateway/web/irccloud.com/x-tbkgzprkhalkdywi) |
| 16:21.09 | file | gtjoseph_: I haz question |
| 16:21.16 | gtjoseph_ | yep? |
| 16:21.21 | gtjoseph_ | why do i have a tail? |
| 16:21.38 | file | gtjoseph_: in your stasis travels did you ever examine message creation versus consumption - that is, what messages are actually used in certain scenarios? |
| 16:22.09 | gtjoseph_ | i did not. be easy to determine though |
| 16:22.35 | gtjoseph_ | just an ast_log in dispatch message |
| 16:22.44 | file | nods |
| 16:23.45 | gtjoseph_ | actually i did that but was only looking at certain mesasges |
| 16:24.07 | file | I'm just curious if consumers providing insight in to what they want could cut down on the fundamental creation of messages |
| 16:24.56 | gtjoseph_ | probably. i can do a quick test this afternoon. a debug in message createtion then a debug when a messages is dispatched to a subscriber |
| 16:25.15 | file | some act as a catch all, like AMI/ARI |
| 16:25.39 | file | yay my build finished |
| 16:25.44 | gtjoseph_ | yep but those are easy to instrument as well. there were no others that I saw. |
| 16:26.27 | gtjoseph_ | besides, unless someone is getting the ami or ari events, there's not much data to be gained there. |
| 16:26.42 | file | exactly |
| 16:27.01 | gtjoseph_ | so we'd need a real integrated scenario. |
| 16:27.08 | file | ahahahahahahaha I was wondering why my backpack was heavier than usual |
| 16:27.11 | file | there's a label maker in it still |
| 16:27.37 | file | someone remind me to take it out later in case I forget :P |
| 16:27.43 | gtjoseph_ | Ha |
| 16:32.14 | file | gtjoseph_: psst |
| 16:32.18 | file | gtjoseph_: you may as well do the upgrade then |
| 16:32.35 | file | awwww you're no fun |
| 16:32.39 | gtjoseph_ | what upgrade? |
| 16:32.44 | file | to .3 |
| 16:32.46 | file | it's on .2 |
| 16:32.51 | gtjoseph_ | oh |
| 16:33.05 | gtjoseph_ | actually it was only apache2 that needed to be restarted |
| 18:04.21 | *** join/#asterisk-dev jkroon (~jkroon@165.16.204.171) |
| 18:37.01 | *** join/#asterisk-dev jameswf (uid27319@gateway/web/irccloud.com/x-uowmjkgiccnxnogk) |
| 19:01.09 | jkroon | coreyfarrell, i actually missed what you said last night re {mysql,mariadb}-connector-odbc, I was only looking at {mysql,mariadb}-connector-c. myodbc == mysql-connector-odbc, which I've now swapped for mariadb-connector-odbc, and even startups is now extremely fast. reloads are nice and solid again. my only problem is cdr_mysql is now non-functional, but I'm sure cdr_odbc should not be easy enough to configure. |
| 19:03.18 | jkroon | i still do think that asterisk is wrong in allocating a new unixODBC ENV for each and every odbc "class", and I've also patched that (which is what I'm currently testing with, will revert and retest in a bit). |
| 19:04.25 | jkroon | i actually suspect a few problems we've observed will likely just "go away now" |
| 19:10.22 | coreyfarrell | jkroon: glad to hear your major issue is resolved. on the other issue I would not use cdr_mysql. you should use cdr_adaptive_odbc, that's the only 'core' supported module for asterisk writing cdr directly to mysql. |
| 19:13.03 | jkroon | cool. so we learn. |
| 19:13.20 | jkroon | not cdr_odbc but cdr_adaptive_odbc? what's the difference? |
| 19:14.07 | jkroon | cdr_adaptive_odbc.conf explains :) |
| 19:15.37 | coreyfarrell | features aside cdr_odbc is extended support, cdr_adaptive_odbc is core support. |
| 19:17.51 | jkroon | hmm, well, res_odbc won't cut it for my needs anyway. thanks for pointing me at that. |
| 19:21.37 | coreyfarrell | jkroon: all of the odbc modules use/depend on res_odbc |
| 19:21.45 | jkroon | hmm, interesting, not useful in this use-case, but does it support some form of calculated fields? eg, there are indications of static, and all of the custom stuff, but can say pass ${CDR(rate)} * ${CDR(billsec)} / 60 => callcost ? (There are mention of LCR ...) |
| 19:22.28 | jkroon | yea, that's what I'm bargaining on. Now that I'm wondering about it, I wonder if cdr_mysql use of mysql functions vs that from res_odbc via unixODBC was perhaps not also messing with the library. |
| 19:25.21 | jkroon | was never an issue with ast 11 though . |
| 19:59.08 | *** join/#asterisk-dev sh_smith (~sh_smith@cpe-76-174-26-91.socal.res.rr.com) |
| 20:08.44 | seanbright | gtjoseph_: something i am realizing (assuming that mailbox and context are arrays)... |
| 20:08.56 | seanbright | sizeof(mailbox) + sizeof(context) is all you need |
| 20:09.28 | gtjoseph_ | nah, they're passed in as char * |
| 20:09.36 | seanbright | right, i mean in the other situation |
| 20:09.49 | gtjoseph_ | oh, the earlier one? |
| 20:09.52 | seanbright | yeah |
| 20:10.07 | seanbright | 2x 80 byte char arrays |
| 20:10.24 | seanbright | means there are 2 bytes that are unused |
| 20:10.29 | seanbright | "unused" |
| 20:10.36 | gtjoseph_ | heh, you're right. |
| 20:10.39 | seanbright | which will fit the @ and the \0 |
| 20:10.40 | seanbright | but anyway |
| 20:11.49 | seanbright | #define MAILBOX_SPEC_LEN (AST_MAX_CONTEXT + AST_MAX_EXTENSION) |
| 20:12.09 | seanbright | and then get rid of all of the nonsense |
| 20:12.29 | seanbright | the defense rests |
| 20:16.34 | seanbright | OR |
| 20:16.39 | seanbright | git rm apps/app_voicemail.c |
| 20:16.45 | seanbright | which is sexy as hell |
| 20:16.56 | seanbright | highly efficient |
| 20:31.32 | seanbright | lol |
| 20:35.51 | seanbright | gtjoseph_: so that i know moving forward - is there a way that i could suggest changes on your reviews that would cause you to consider those changes? |
| 20:36.13 | seanbright | i am not trying to be confrontational, but i would like to know what i am doing wrong |
| 20:37.46 | gtjoseph_ | i think you're on the boundary of style and preference vs technical correctness. |
| 20:38.35 | gtjoseph_ | one of the reasons i don't like using the array is that it's harder to debug in gdb |
| 20:38.57 | gtjoseph_ | i like having a specific variable that has the length |
| 20:39.43 | seanbright | i don't completely follow - but thank you for the response regardless |
| 20:40.14 | gtjoseph_ | when you're gdb, you can select a frame and do "info locals" to see the local variables |
| 20:40.58 | gtjoseph_ | it's the same thing as assinging the return from a function to alocal variable then testing that rather then putting the function call in an "if" statement. |
| 20:41.42 | seanbright | 'info locals' won't show you the content of a char[]? |
| 20:42.49 | gtjoseph_ | it will, like i said, it's preference. |
| 20:43.07 | gtjoseph_ | in this case, we have to do the strlen because we're passign in pointers |
| 20:43.17 | seanbright | but you don't |
| 20:43.26 | seanbright | you don't have to do strlen |
| 20:43.37 | gtjoseph_ | although we could _assume_ that they are no longer than the arrays in the vmu |
| 20:43.58 | seanbright | it doesn't matter how long they are |
| 20:44.15 | seanbright | even if mailbox pointed to a 10,000 element char array, it wouldn't matter |
| 20:44.39 | gtjoseph_ | then i didn't follow. |
| 20:45.16 | gtjoseph_ | sizeof(box) is going to equal the size of a char * |
| 20:45.27 | seanbright | what i am saying is this |
| 20:46.21 | seanbright | based on the definition of ast_vm_user, a *valid* mailbox is < 80 chars and *valid* context is < 80 chars |
| 20:47.01 | gtjoseph_ | right but you have to _know_ that |
| 20:47.08 | seanbright | the *most* amount of space a *valid* mailbox spec could be is 160 bytes |
| 20:47.18 | seanbright | do you? |
| 20:47.19 | seanbright | why? |
| 20:47.30 | seanbright | we're talking in circles |
| 20:47.48 | seanbright | i guess we'll just agree to disagree |
| 20:48.18 | gtjoseph_ | no, you'd just have to create the define as you said above. |
| 20:48.39 | seanbright | yes |
| 20:48.51 | seanbright | correct, yes, so you have to know how big the mailbox and context arrays are |
| 20:49.02 | seanbright | but i don't see why that is problematic |
| 20:49.20 | gtjoseph_ | what I worry about is when someone decides that the mailbox needs to be something bigger so they don't use AST_MAX_EXTENSION anymore then forget to change the new define for max spec mailbox |
| 20:50.15 | seanbright | i don't worry about those types of things |
| 20:50.22 | gtjoseph_ | now since vmu-mailbox and vmu-context are arrays, I'd be fine with doing a sizeof(vmu->mailbox), etc |
| 20:50.44 | seanbright | we spent a great deal of time talking about how hesitant anyone is to making changes to app_voicemail |
| 20:50.54 | seanbright | and then there is gerrit |
| 20:51.03 | seanbright | i don't feel that is a realistic concern to have |
| 20:52.32 | gtjoseph_ | well, if someone changed the definition of vmu->mailbox the patch context probably wouldn't show the define of the max mailbox spec |
| 20:52.45 | gtjoseph_ | so it could easuly get overlooked |
| 20:53.04 | seanbright | and i think to address specifically what you are talking about, you would create two new #defines specifically for mailbox and context length and then the 'combined' define would be defined in terms of them |
| 20:53.08 | gtjoseph_ | until someone actually defined a mailbox bigger than the current length |
| 20:53.49 | gtjoseph_ | ok, that could work. |
| 20:54.04 | gtjoseph_ | give me a few minutes |
| 20:54.07 | seanbright | heh |
| 20:54.48 | seanbright | when gtjoseph_ and i come to consensus, there is no way in hell it is going to pass muster with rmudgett |
| 20:54.58 | seanbright | :) |
| 20:55.22 | gtjoseph_ | we jut get someone else to do the +2 |
| 21:08.29 | gtjoseph_ | seanbright: there |
| 21:11.43 | gtjoseph_ | and i'm done for the day |
| 21:16.22 | seanbright | app_voicemail.c is great... "skipped 11372 common lines" |
| 21:17.14 | rmudgett | Almost as bad as chan_sip.c |
| 21:21.41 | seanbright | isn't that deprecated yet? |
| 21:22.50 | seanbright | ugh, CCSS and AoC |
| 21:22.52 | seanbright | not it! |
| 21:26.19 | kharwell | coreyfarrell: regarding passing $JANSSON_INCLUDE into the macro. When doing non-bundled that value is empty (seems to cut off or overwrite the "jansson.h" text when I pass it in). Is that suppose to be set somewhere else if someone installed the dev files in a custom location? |
| 21:31.02 | coreyfarrell | kharwell: sorry I was wrong, ${JANSSON_INCLUDE} would contain '-I' so that won't work. looks like we should be setting CPPFLAGS with that variable the way that autoconf/ast_c_compile_check.m4 does. |
| 21:32.16 | kharwell | heh that was my next question about it containing the '-I'. (thought it might default to just the path when we don't set it) |
| 21:33.14 | coreyfarrell | I'd be happy to see chan_sip deprecated (and I still use it). pushing people away from it would cause less people to try using it with webrtc, SIP/TCP and realtime. less patches to chan_sip is a good thing for me since chan_sip works for my purpose, every patch is a risk with no reward. |
| 21:34.52 | coreyfarrell | kharwell: in theory you should be able to do something like: saved_cppflags="${CPPFLAGS}";CPPFLAGS="${CPPFLAGS} ${JANSSON_INCLUDE}';<<run the compile>>;CPPFLAGS="${saved_cppflags}" |
| 21:35.44 | coreyfarrell | kharwell: if you did that I think you would just "#include <jansson.h>" in the compile since JANSSON_INCLUDE should point to third-party/jansson/dest/include for bundled. |
| 21:39.12 | kharwell | what does ast_c_compile_check.m4 do? I'm unfamiliar with that. Heck most of the configure stuff for that matter. I'm only seeing it in a few places when I grep for it |
| 21:42.27 | coreyfarrell | kharwell: ast_c_compile_check is a wrapper around AC_COMPILE_IFELSE to detect a library for menuselect. we can't use it here because we've already detected the library so we have to use AC_COMPILE_IFELSE directly. |
| 21:45.44 | coreyfarrell | kharwell: would you like me to take over the configure.ac stuff? I'm pretty comfortable with the m4 stuff. |
| 21:48.35 | kharwell | ya sure if you want to take it over that's fine. I hate to dump it on ya and also want to learn more about this stuff, but might be easier to learn by example. |
| 22:02.35 | coreyfarrell | kharwell: just curious, what distro/version did you run ./bootstrap.sh from? |
| 22:02.57 | kharwell | ubuntu 14.04 |
| 22:04.31 | coreyfarrell | ah so --runstatedir must be an old option.. the fedora 28 autoconf removed that from the configure script. |
| 22:07.22 | coreyfarrell | kharwell: ok review is updated. let me know if you have any questions about what I did. |
| 22:07.39 | kharwell | coreyfarrell: will do and many thanks! |
| 22:17.50 | kharwell | coreyfarrell: aah I see now what you meant. When it compiles the test program it'll use the CPPFLAGS you specified. Neat! |
| 22:19.29 | coreyfarrell | yup. we still pass a direct path for the bundled library since third-party/jansson/dest doesn't exist yet (so for the bundled library our CPPFLAGS includes an invalid path) |
| 22:26.24 | *** part/#asterisk-dev kharwell (kharwell@nat/digium/x-rxnuizdxhevbubyh) |
| 23:07.55 | *** join/#asterisk-dev ahmed89_ (~ahmed89@5.36.27.76.dynamic-dsl-ip.omantel.net.om) |
| 23:18.49 | file | Gerrit is going down for le upgrade |
| 23:18.50 | file | ACHOO |
| 23:22.08 | file | done |