| 00:21.10 | *** join/#asterisk-dev infobot (ibot@208.53.50.136) |
| 00:21.10 | *** 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 |
| 04:20.41 | *** join/#asterisk-dev tuxd00d (~tuxd00d@ip70-190-32-9.ph.ph.cox.net) |
| 04:23.38 | *** join/#asterisk-dev tuxd00d (~tuxd00d@unaffiliated/tuxd00d) |
| 05:05.39 | *** join/#asterisk-dev jkroon (~jkroon@165.16.204.170) |
| 06:52.17 | *** join/#asterisk-dev kg6hum (~kg6hum@protovision.org) |
| 07:25.12 | *** join/#asterisk-dev CELYA_ (~Thunderbi@LStLambert-657-1-90-73.w80-13.abo.wanadoo.fr) |
| 07:31.59 | *** join/#asterisk-dev hehol (~hehol@gatekeeper.loca.net) |
| 07:55.28 | *** join/#asterisk-dev tsearle (~tsearle@37.19.10.33) |
| 07:55.28 | *** mode/#asterisk-dev [+o tsearle] by ChanServ |
| 08:08.48 | *** join/#asterisk-dev jkroon (~jkroon@165.16.203.57) |
| 09:10.10 | *** join/#asterisk-dev pchero (~pchero@176-23-78-252-cable.dk.customer.tdc.net) |
| 10:06.29 | *** join/#asterisk-dev hehol (~hehol@gatekeeper.loca.net) |
| 11:40.56 | *** join/#asterisk-dev opticron (~opticron@75.76.209.103) |
| 11:40.56 | *** mode/#asterisk-dev [+o opticron] by ChanServ |
| 11:55.23 | seanbright | FINALLY getting solaris 11 support |
| 11:59.02 | file | seemingly. |
| 11:59.31 | seanbright | now if i can only get enum support on solaris 11 i'll be in business |
| 13:10.50 | snuff-work | i tried long time ago getting more solaris working support =) |
| 13:56.10 | coreyfarrell | if anyone has suggestions about the python encoding thing in https://gerrit.asterisk.org/#/c/8854/ it would be nice, otherwise that review is at a dead-end. |
| 14:00.07 | *** join/#asterisk-dev tsearle_ (~tsearle@37.19.10.33) |
| 14:00.07 | *** mode/#asterisk-dev [+o tsearle_] by ChanServ |
| 14:21.50 | seanbright | coreyfarrell: i don't really understand the problem. what is the ELI5 version? |
| 14:23.27 | *** join/#asterisk-dev kharwell (kharwell@nat/digium/x-wddpkpojgdkpbafb) |
| 14:23.27 | *** mode/#asterisk-dev [+o kharwell] by ChanServ |
| 14:24.26 | coreyfarrell | seanbright: the way python deals with character encoding is miserable. Alexander received errors like `UnicodeEncodeError: 'ascii' codec can't encode character u'\ufffd' in position 155` which crashed the entire testsuite. |
| 14:24.41 | *** join/#asterisk-dev tsearle__ (~tsearle@37.19.10.33) |
| 14:24.41 | *** mode/#asterisk-dev [+o tsearle__] by ChanServ |
| 14:24.44 | *** join/#asterisk-dev cresl1n (uid299068@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 14:24.44 | *** mode/#asterisk-dev [+o cresl1n] by ChanServ |
| 14:24.46 | seanbright | what is generating that character code? |
| 14:25.53 | seanbright | i mean, given that 0xff is not valid ascii that seems like a reasonable error |
| 14:25.54 | cresl1n | waves |
| 14:26.56 | coreyfarrell | the crash is happening at https://gerrit.asterisk.org/#/c/8854/6/runtests.py@152 so it's being produced by the subprocess (the actual test). I supposed I could add UnicodeEncodeError to be ignored but that seems wrong since this wasn't an issue without the code to deal with python3. |
| 14:27.28 | coreyfarrell | I guess I expected 'ascii' would permit 8-bit/high ascii :( |
| 14:28.14 | seanbright | so something in the test is generating a high ascii characters but we don't know what |
| 14:28.18 | seanbright | is that right? |
| 14:28.58 | seanbright | is it a term color code or something? |
| 14:29.06 | coreyfarrell | something in random tests is generating high ascii. his last message acknowledged that it isn't the same test. |
| 14:29.37 | seanbright | hmm |
| 14:30.29 | seanbright | https://www.fileformat.info/info/unicode/char/fffd/index.htm |
| 14:30.31 | seanbright | lulz |
| 14:30.49 | seanbright | so this is only happening in his environment? |
| 14:30.57 | seanbright | or does this happen to you as well? |
| 14:31.25 | coreyfarrell | he's the only one who's run the full testsuite. I've run a bunch of tests but haven't had the issue. |
| 14:31.49 | seanbright | do these tests generate raw output files that could be examined? |
| 14:33.54 | coreyfarrell | not sure. could probably be forced to do so but I don't know how. |
| 14:34.56 | coreyfarrell | the fact that fffd is the replacement character is a clue (thanks for finding that), it means something else did .decode('unicode', 'replace') and python replaced an invalid character. I'll have to dig up the docs for .decode against I'm pretty sure it has a way to simply drop invalid characters. |
| 14:35.08 | *** join/#asterisk-dev bford (uid283514@gateway/web/irccloud.com/x-kkradyzvhmysvrmu) |
| 14:35.08 | *** mode/#asterisk-dev [+o bford] by ChanServ |
| 14:38.49 | seanbright | my two cents - asterisk should be generating utf-8 across the board |
| 14:38.56 | seanbright | if it's not, that is a bug |
| 14:40.47 | seanbright | by "generating" i mean - "outputting to CLI, manage, ARI, etc" |
| 14:40.59 | seanbright | manager* |
| 14:43.40 | coreyfarrell | agree but when asterisk does something buggy it should fail one test not crash the whole testsuite. |
| 14:44.30 | seanbright | can we catch UnicodeEncodeError, fail the current test, and move on? |
| 14:47.46 | coreyfarrell | we can catch it, I'm not sure about failing. I'm also going to update the code across the board to use .decode('utf-8', 'backslashreplace') since the fffd was probably added by python itself. |
| 14:48.14 | *** join/#asterisk-dev rmudgett (rmudgett@nat/digium/x-qsixslvruwgorzsw) |
| 14:48.14 | *** mode/#asterisk-dev [+o rmudgett] by ChanServ |
| 14:53.10 | seanbright | okie |
| 15:08.09 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01cb0583d31d00e8e57717bb51c322.ipv6.abo.wanadoo.fr) |
| 15:39.12 | rmudgett | dokie |
| 15:39.43 | rmudgett | is it brokie? |
| 17:11.42 | seanbright | i think we're safe to have alexander compress all of these solaris reviews in to 1, no? |
| 17:34.28 | kharwell | maybe? they are small but mostly distinct changes except that they're all for solaris. I would think it would be fine to group them all if so inclined |
| 17:38.59 | rmudgett | smaller reviews are easier to review. |
| 17:39.24 | rmudgett | The larger they get the more difficult it becomes to review |
| 17:42.25 | seanbright | well, agree to disagree |
| 17:43.29 | seanbright | without CI that builds on unsupported OSs these changes are pointless |
| 17:43.39 | seanbright | but WHATEVER |
| 19:03.09 | *** join/#asterisk-dev jkroon (~jkroon@165.16.204.170) |
| 19:44.19 | cresl1n | seanbright: as long as it doesn't break our supported OSs I'm fine |
| 19:44.34 | cresl1n | or make them significantly less maintainable |
| 20:07.28 | *** join/#asterisk-dev jkroon_ (~jkroon@165.16.204.162) |
| 20:19.56 | coreyfarrell | I actually had a nearly successful run of the testsuite, apparently I had REF_DEBUG so that's why it was previously too slow. not sure why I used to get lockups, didn't get it this time. |
| 20:21.44 | coreyfarrell | the main process crashed while generating the xml for asterisk-test-suite-report.xml. still got the pass/fail list from scrollback, 792 pass, 82 fail and 128 skipped |
| 20:22.51 | coreyfarrell | so apparently an invalid character is still getting out from somewhere but it's not causing a failure until after all the tests have run and the status is printed. |
| 20:24.05 | coreyfarrell | I'm rerunning the 82 failures to see if the xml encoding error happens again. unfortunately catching the exception won't do much good for this. |
| 21:03.16 | rmudgett | <PROTECTED> |
| 21:04.10 | rmudgett | Question: Should I continue to use the above code? It seems fragile because of how the vector macro is implemented. |
| 21:07.01 | coreyfarrell | rmudgett: I think all vector functions are similar, I'd say just check for the error and ao2_cleanup. |
| 21:07.48 | coreyfarrell | I had patched across the board for AST_VECTOR_APPEND or something like that, added cleanup to all the error conditions. |
| 21:08.04 | rmudgett | In this case using ao2_bump on the parameter it would never happen if the vector cannot be grown. So a failure would unref something that was never ref bumped. |
| 21:11.15 | coreyfarrell | ouch, AST_VECTOR_APPEND is the same. that means those are broken in at least 2 places. |
| 21:12.44 | rmudgett | The pain of using macros. |
| 21:12.54 | coreyfarrell | I'm not sure what to say, part of me thinks that it's a bug for those macros to not unconditionally evaluate the elem argument, not sure if that would be acceptable though. |
| 21:13.35 | rmudgett | It is a fragile implementation detail when dealing with macros. |
| 21:16.20 | rmudgett | If you want to treat macros like functions then you have to make the macro truly behave like a function. |
| 21:51.37 | seanbright | or you know... just use functions |
| 21:51.44 | coreyfarrell | is anyone able to get a pass from testsuite tests/realtime/static run against master? I just got a failure, based on the error I'm not sure how this passes on jenkins. |
| 21:53.23 | coreyfarrell | apparently the new module loader refused to load because res_config_curl is being preloaded but modules it requires are not. |
| 22:41.11 | coreyfarrell | what is the 'mockd' python module used by a bunch of statsd tests? |
| 22:45.52 | kharwell | it was used by them. That module should now be deleted. Was replaced with the matcher(.py) stuff |
| 22:46.38 | kharwell | hrm I see it is still referenced by one file |
| 22:47.08 | coreyfarrell | it's in 10 tests `git grep mockd` for the list |
| 22:48.39 | kharwell | I'm only seeing it in the one: tests/endpoints/statsd/test-config.yaml |
| 22:48.46 | kharwell | searching on 13 branch |
| 22:49.30 | coreyfarrell | oh I'm on master |
| 22:49.45 | coreyfarrell | kharwell: probably different on each branch |
| 22:50.02 | kharwell | heh I am seeing no references on master |
| 22:51.07 | kharwell | oh whoops I was on the asterisk master when I searched the second time. I am seeing several now in the testsuite |
| 22:51.39 | coreyfarrell | ha |
| 22:51.45 | kharwell | so yeah more tests were added in later branches it seems. |
| 22:52.45 | kharwell | I'll need to look into fixing those up it seems |
| 23:14.01 | *** part/#asterisk-dev kharwell (kharwell@nat/digium/x-wddpkpojgdkpbafb) |