| 00:05.18 | *** join/#asterisk-dev zopsi (~zopsi@dir.ac) |
| 02:06.44 | *** join/#asterisk-dev joshelson (~joshelson@206.81.147.110) |
| 06:04.58 | *** join/#asterisk-dev sh_smith (~sh_smith@cpe-76-174-26-91.socal.res.rr.com) |
| 07:11.59 | *** join/#asterisk-dev snuff-work (~snuff-wor@210.9.148.102) |
| 07:11.59 | *** join/#asterisk-dev wdoekes (~walter@wjd.osso.nl) |
| 07:11.59 | *** mode/#asterisk-dev [+oo snuff-work wdoekes] by card.freenode.net |
| 07:56.06 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01:e0a:d:1111:1dd7:b42:3b85:c2f5) |
| 08:03.25 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 08:03.25 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 08:09.57 | *** join/#asterisk-dev pchero_work (~pchero@109.70.54.56) |
| 08:25.31 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01:e0a:d:1111:1dd7:b42:3b85:c2f5) |
| 08:29.06 | *** join/#asterisk-dev jkroon (~jkroon@uls-154-73-35-201.wall.uls.co.za) |
| 08:52.00 | *** join/#asterisk-dev hehol (~hehol@gatekeeper.loca.net) |
| 09:07.56 | *** join/#asterisk-dev tsearle (~tsearle@37.19.10.33) |
| 09:07.57 | *** mode/#asterisk-dev [+o tsearle] by ChanServ |
| 09:14.21 | *** join/#asterisk-dev anthm (~anthm@freeswitch-10.freeswitch.org) |
| 09:14.38 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 09:45.01 | *** join/#asterisk-dev tsearle (~tsearle@37.19.10.33) |
| 09:45.01 | *** mode/#asterisk-dev [+o tsearle] by ChanServ |
| 10:39.31 | *** join/#asterisk-dev Worldexe (~Worldexe@95-107-33-134.dsl.orel.ru) |
| 11:12.36 | *** join/#asterisk-dev startups (~startups@cpe-76-175-177-156.socal.res.rr.com) |
| 12:31.03 | *** join/#asterisk-dev pc-m (~pcm@modemcable094.94-70-69.static.videotron.ca) |
| 12:37.52 | *** join/#asterisk-dev jkroon_ (~jkroon@165.16.204.36) |
| 12:56.19 | *** join/#asterisk-dev joshelson (~joshelson@206.81.147.110) |
| 12:56.40 | *** join/#asterisk-dev jkroon_ (~jkroon@uls-154-73-35-201.wall.uls.co.za) |
| 12:59.28 | *** join/#asterisk-dev hehol (~hehol@gatekeeper.loca.net) |
| 13:42.52 | coreyfarrell | I have some reviews blocked due to testsuite failures, the testsuite fix was just merged. do I just reply "regate" to them? |
| 13:43.19 | gtjoseph | that's it |
| 13:44.43 | gtjoseph | coreyfarrell: are you going to fix the download cache relative paths issue? |
| 13:48.59 | coreyfarrell | I'll take a look at it (maybe not today though).. I'm thinking if the path doesn't start with '/' I can prepend $ASTTOPDIR. |
| 13:49.37 | gtjoseph | no worries. i created an internal issue for it anyway |
| 13:51.01 | seanbright | file: i figured someone would get tired of waiting for me to create an issue for it :P |
| 13:51.17 | file | get there eventually :P |
| 13:54.32 | coreyfarrell | gtjoseph: do you know what we require for make? wondering if I can use $(realpath ...)? |
| 13:55.01 | gtjoseph | i don't remember exactly but iirc it was freebsd what was the gate |
| 13:55.08 | gtjoseph | s/what/that/ |
| 14:19.05 | file | hrm! |
| 14:23.33 | seanbright | file: for what reason have you "hrm!'d?" |
| 14:24.00 | file | seanbright: oh - was just thinking that whether a field can be empty or not could be pushed down into sorcery |
| 14:24.20 | seanbright | that would probably be cleaner |
| 14:24.58 | seanbright | it almost feels like a realtime issue though |
| 14:25.01 | seanbright | well, kinda |
| 14:25.18 | seanbright | NULL in the db vs "" in the db |
| 14:25.27 | file | we can be more forgiving |
| 14:25.40 | seanbright | i think we should be more strict |
| 14:25.42 | seanbright | heh |
| 14:25.58 | file | ha |
| 14:26.04 | seanbright | i didn't look too closely at it, so i might be talking out of my ass |
| 14:26.37 | gtjoseph | you _can_ specify an empty value in config files. |
| 14:29.13 | seanbright | k |
| 14:35.15 | *** join/#asterisk-dev leedm777 (textual@nat/digium/x-omjexxdbxnniqzbz) |
| 14:35.15 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 14:45.27 | *** join/#asterisk-dev joshelson (~joshelson@206.81.147.110) |
| 14:54.29 | coreyfarrell | gtjoseph: do we have a way to determine if something in a makefile would work under BSD? I can't find their manual so I don't know if the macro I need can be used. |
| 14:55.07 | coreyfarrell | I tried another approach that was not using $(realpath ...) and it failed. |
| 14:56.21 | gtjoseph | i may have a vm somewhere i can try. we do require gmake so it's a matter of version. |
| 14:56.52 | gtjoseph | do you know what the earliest version that supports realpath is? |
| 14:57.44 | gtjoseph | another option might be readlink |
| 14:58.14 | gtjoseph | i'm not at my desk but iirc we use that elsewhere |
| 15:02.34 | *** join/#asterisk-dev bford (d8cff501@gateway/web/freenode/ip.216.207.245.1) |
| 15:02.34 | *** mode/#asterisk-dev [+o bford] by ChanServ |
| 15:07.43 | coreyfarrell | doesn't matter realpath won't work either. |
| 15:15.27 | *** join/#asterisk-dev kharwell (kharwell@nat/digium/x-gmofohgpcnctrari) |
| 15:15.27 | *** mode/#asterisk-dev [+o kharwell] by ChanServ |
| 15:33.21 | *** join/#asterisk-dev cresl1n (~Adium@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 15:33.21 | *** mode/#asterisk-dev [+o cresl1n] by ChanServ |
| 15:50.56 | *** join/#asterisk-dev rmudgett (rmudgett@nat/digium/x-ljkzohvdnigkyqvs) |
| 15:50.56 | *** mode/#asterisk-dev [+o rmudgett] by ChanServ |
| 16:32.56 | coreyfarrell | looks like jenkins check doesn't catch dev-mode errors. I accidentally tested with DONT_OPTIMIZE but without COMPILE_DOUBLE and jenkins does the same thing so we both missed an uninitialized variable warning. |
| 16:37.08 | *** join/#asterisk-dev JunK-Y (~junky@pdpc/supporter/active/junk-y) |
| 16:40.25 | gtjoseph | COMPILE_DOUBLE caught an uninitialized error? |
| 16:40.29 | gtjoseph | hmmm |
| 16:40.49 | gtjoseph | i would have thought that would have been caught without it |
| 16:43.08 | coreyfarrell | DONT_OPTIMIZE causes error's to be lost unless you COMPILE_DOUBLE. |
| 16:46.28 | rmudgett | The problem with COMPILE_DOUBLE on the build agents is that it increases the build time. |
| 16:46.39 | gtjoseph | yeah which is why i removed it |
| 16:47.04 | gtjoseph | i'm testing again now |
| 16:47.05 | coreyfarrell | maybe the 'check' stage needs to not use DONT_OPTIMIZE then? |
| 16:47.33 | coreyfarrell | only use DONT_OPTIMIZE for the gate stage so test crashes produce good backtraces? |
| 16:47.36 | gtjoseph | so DONT_OPTIMIZE masked an error? Maybe we should investigate that |
| 16:48.15 | gtjoseph | what was the exact code error that got missed. |
| 16:48.23 | rmudgett | Its how the compiler operates. It was why the double compilation was done in the first place. |
| 16:48.43 | rmudgett | It was a not used variable. |
| 16:48.55 | *** join/#asterisk-dev cresl1n (~Adium@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 16:48.55 | *** mode/#asterisk-dev [+o cresl1n] by ChanServ |
| 16:50.07 | coreyfarrell | it was an uninitialized local variable. |
| 16:51.59 | rmudgett | Oh. Yeah, the optimizer is going to have a better chance of finding those. |
| 16:53.46 | gtjoseph | well, the build slaves are much more powerful than they were so maybe turning it back on isn't an issue. I'll test more |
| 16:54.06 | coreyfarrell | rmudgett: do you know if DONT_OPTIMIZE causes stack variables to be initialized or would it produce a binary with potential uninitialized memory access? |
| 16:55.04 | rmudgett | Stack variables are not initialized unless you initialize them. |
| 16:55.33 | rmudgett | global and static variables are initialized on load. |
| 16:56.05 | coreyfarrell | BTW https://gerrit.asterisk.org/7009 should make it possible for the testsuite to pass on master. |
| 16:56.27 | rmudgett | s/on load/to zero on load unless explicitly initialized to something else. |
| 17:01.22 | rmudgett | Ug. Disabling app_macro effectively disables some tests. :( |
| 17:02.17 | coreyfarrell | true.. gtjoseph if you are tinkering with the jenkins build options do you want to add an explicit '--enable app_macro'? |
| 17:02.35 | file | yesssss |
| 17:02.39 | gtjoseph | is it disabled by default? |
| 17:02.52 | file | it is now, in master |
| 17:02.58 | gtjoseph | heh, oh yeah |
| 17:03.22 | gtjoseph | then yes |
| 17:04.45 | file | we'd also like some cookies |
| 17:08.27 | file | seanbright: so on non-custom string types the ast_strlen_zero can already be pushed into the core, it's just the custom ones where you have to do it - so that's all well and good |
| 17:30.30 | *** join/#asterisk-dev leedm777 (textual@nat/digium/x-drmflnkqxqzvfjhy) |
| 17:30.30 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 17:55.54 | *** join/#asterisk-dev jkroon (~jkroon@165.16.204.167) |
| 18:05.41 | rmudgett | coreyfarrell: Responded to your optimize comment. |
| 18:07.05 | coreyfarrell | rmudgett: switched to +1 |
| 18:12.56 | coreyfarrell | what is the compatibility requirements between asterisk remote and daemon? is it supported for 'asterisk -r' to connect to a daemon running a different version of Asterisk? |
| 18:14.35 | file | that's a question, it's not really defined afaik and has certainly gotten broken in the past |
| 18:17.22 | *** join/#asterisk-dev joshelson (~joshelson@64.55.128.243) |
| 18:22.10 | *** join/#asterisk-dev tsearle (~tsearle@2a02:2788:1004:636:aeb5:7dff:feca:81d6) |
| 18:22.10 | *** mode/#asterisk-dev [+o tsearle] by ChanServ |
| 18:48.20 | *** join/#asterisk-dev gtjoseph (~gtjoseph@unaffiliated/gtj) |
| 18:48.20 | *** mode/#asterisk-dev [+o gtjoseph] by ChanServ |
| 19:06.54 | seanbright | man... comcast us "fucked up" right now |
| 19:06.59 | seanbright | sorry for the technical jargon |
| 19:08.03 | file | seanbright: yes. |
| 19:17.28 | *** join/#asterisk-dev cresl1n (Adium@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 19:17.29 | *** mode/#asterisk-dev [+o cresl1n] by ChanServ |
| 19:21.01 | gtjoseph | hmmm. i seem to be having sporadic comcast issues right now as well |
| 19:30.57 | seanbright | it's nationwide |
| 19:37.04 | cresl1n | nationwide is on your side |
| 19:43.03 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01cb0583d31d0085abb1eda1da6c06.ipv6.abo.wanadoo.fr) |
| 20:12.01 | seanbright | new rule - you can't close a bug and leave it in an unresolved state |
| 20:13.03 | file | I think your rules scope doesn't extend far |
| 20:13.43 | seanbright | that hurts |
| 20:21.49 | *** join/#asterisk-dev joshelson (~joshelson@64.55.128.243) |
| 20:26.06 | *** join/#asterisk-dev tzafrir (~tzafrir@62-90-199-170.barak.net.il) |
| 20:26.06 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 22:06.32 | coreyfarrell | rmudgett: do you have a minute? |
| 22:07.11 | rmudgett | wass up doc? |
| 22:07.23 | coreyfarrell | I might have confused myself with res_ari_events JSON cleanup. https://gerrit.asterisk.org/7047 |
| 22:08.13 | coreyfarrell | in one of the conditional paths it adds the JSON message to vector session->message_queue, and later that gets ast_json_unref called on it. |
| 22:09.04 | coreyfarrell | so I thought that stasis_app_message_handler was responsible for eating the JSON message reference given to it. but looking at the callers makes me second guess that. |
| 22:09.33 | coreyfarrell | like maybe the message needs a ref bump when it is successfully added to session->message_queue. |
| 22:18.24 | rmudgett | Looks like all callers unref message themselves but one. So at this point, the json ref should be bumped when it is put into the vector. |
| 22:18.57 | rmudgett | The place where the caller doesn't unref the json object is res/stasis/app.c:message_received_handler() |
| 22:19.21 | coreyfarrell | ah thanks.. I'll fix that when I update the review. |
| 22:32.43 | *** join/#asterisk-dev bford (d8cff501@gateway/web/freenode/ip.216.207.245.1) |
| 22:32.43 | *** mode/#asterisk-dev [+o bford] by ChanServ |
| 23:18.49 | rmudgett | coreyfarrell: You going to fix the one caller that doesn't unref the json message object? ^^^ |
| 23:19.56 | coreyfarrell | yeah I'm going to post it with the other res_stasis leak. |