| 00:26.44 | *** join/#asterisk-dev superscrat (~asanders@173-21-89-217.client.mchsi.com) |
| 01:13.32 | *** join/#asterisk-dev mjordan (mjordan@nat/digium/x-bfisuhaupmioqsnh) |
| 01:13.32 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 01:13.41 | mjordan | file: definitely one of those nights. |
| 01:13.53 | file | run. away. now. |
| 01:14.33 | mjordan | mutters |
| 01:15.13 | file | related: I'm going to bed :P |
| 01:15.26 | mjordan | GO! |
| 01:15.27 | file | after I convince the dog to go outside |
| 01:18.42 | file | g'night |
| 01:18.50 | mjordan | g'night |
| 01:19.11 | mjordan | ah, debug scheduler was still enabled |
| 01:19.12 | mjordan | HEH |
| 01:19.26 | mjordan | if you slow things down 10x, a lot of things go away |
| 01:22.25 | file | silly |
| 01:42.43 | mjordan | still didn't reproduce it locally. |
| 01:42.54 | mjordan | Pretty sure I know what the issue is ... but this should have been crashing for a LOOONG time |
| 02:40.43 | mjordan | coreyfarrell: thanks for the +1's there. Probably going to merge those in tonight so the nightly builds can verify that I fixed the glitch. |
| 02:40.50 | coreyfarrell | mjordan: not sure what's up with the certified/11.6 zuul failure, your change looks good though |
| 02:41.01 | coreyfarrell | no problem |
| 02:41.12 | mjordan | It's an old branch; there's a build warning that newer versions of gcc catch that we fixed later on |
| 02:41.23 | coreyfarrell | ah |
| 02:41.23 | mjordan | we really should merge it back at some point |
| 02:42.00 | mjordan | I'm honestly confused how we haven't seen that crash before. Something must have really changed the timing. |
| 02:42.04 | coreyfarrell | or use a newer version for the certified branch :) |
| 02:42.09 | mjordan | Heh |
| 02:42.16 | mjordan | Believe me, it's on the list |
| 02:42.22 | mjordan | The list is just loooonnngg |
| 02:43.09 | coreyfarrell | always is |
| 02:51.47 | coreyfarrell | mjordan: about your retaining core dumps change, any reason we can't change PWD to the test instance folder, that way each core dump will be associated with a specific instance of asterisk? |
| 02:55.35 | mjordan | I've wondered why we don't dump the backtraces there as well, as opposed to putting them outside of the specific run |
| 02:55.44 | mjordan | coreyfarrell: but you are right... |
| 02:55.45 | mjordan | hm. |
| 02:55.52 | coreyfarrell | it's because of $PWD |
| 02:56.30 | mjordan | I suspect that there are tests (mostly older ones) that depend on the base path during test execution being the root directory of the testsuite |
| 02:56.59 | mjordan | some have local resources that they feed into the test, and construct a path to those local resources assuming that the cur dir is at that location |
| 02:57.12 | coreyfarrell | we'd probably need symlinks for the lib and tests folders into the specific instance, still probably end up with a few broken tests |
| 03:00.10 | mjordan | yeah. I don't mind just using shutil.copy to copy the core file if we want to keep em |
| 03:00.26 | mjordan | It's not as elegant, but it at least is no worse than what we do with backtraces |
| 03:00.52 | coreyfarrell | unless 2 instances crash for different reasons then we only get one of the dumps |
| 04:54.50 | *** join/#asterisk-dev babak (uid19622@gateway/web/irccloud.com/x-ybslyqiajrwipxlv) |
| 05:16.26 | *** join/#asterisk-dev doome_ (~doome@82.150.48.146) |
| 06:31.21 | *** join/#asterisk-dev hehol (~hehol@gatekeeper.loca.net) |
| 06:54.23 | *** join/#asterisk-dev pchero_work (~pchero@109.70.54.56) |
| 07:32.00 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 07:32.00 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 08:10.03 | *** join/#asterisk-dev stefan27 (~stefan27@212.247.4.149) |
| 08:20.47 | stefan27 | how do I un-draft a gerrit review request |
| 08:23.53 | stefan27 | aha, probably 'Publish' from the GUI worked |
| 09:51.31 | *** join/#asterisk-dev doome_ (~doome@82.150.48.146) |
| 11:08.25 | *** join/#asterisk-dev fornax (~fornax@p5B2C424D.dip0.t-ipconnect.de) |
| 11:30.54 | stefan27 | Joshua Colp/file, what did you mean with 'recheck' |
| 11:33.02 | file | stefan27, it causes Jenkins to re-run a build check and verify the change |
| 11:33.46 | stefan27 | Jenkins merely builds right? Jenkins do no automated tests? |
| 11:34.32 | file | Jenkins does, but it does not currently do it against changes until +2 and even then we're still working on it so they don't block merge |
| 11:35.35 | file | that will change in the future but not for a bit |
| 12:13.26 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@216-191-106-163.dedicated.allstream.net) |
| 12:47.42 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 12:47.42 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 12:49.27 | *** join/#asterisk-dev fornax (~fornax@p5B2C424D.dip0.t-ipconnect.de) |
| 12:52.38 | *** join/#asterisk-dev mjordan (mjordan@nat/digium/x-kuezzifrmwucpulu) |
| 12:52.39 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 13:53.23 | *** join/#asterisk-dev newtonr (RustyNewto@nat/digium/x-heciupzhgnwqtvkd) |
| 13:53.23 | *** mode/#asterisk-dev [+o newtonr] by ChanServ |
| 13:56.40 | *** join/#asterisk-dev fornax (~fornax@p5B2C424D.dip0.t-ipconnect.de) |
| 13:58.06 | *** join/#asterisk-dev kharwell (kharwell@nat/digium/x-dxjegsnkmvzuptoc) |
| 14:17.08 | *** join/#asterisk-dev rmudgett (rmudgett@nat/digium/x-symaqxpmjvoosfwh) |
| 14:30.54 | *** join/#asterisk-dev mjordan (mjordan@nat/digium/x-xsaydvaigalrrpnf) |
| 14:30.54 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 14:31.00 | mjordan | progress: https://jenkins.asterisk.org/jenkins/job/periodic-asterisk-13/14/#showFailuresLink |
| 14:32.24 | file | quite |
| 14:39.05 | mjordan | for the attended transfers tests, it looks like the 3pcc crap in SIPp ... crapped out. |
| 14:39.07 | mjordan | I'm not surprised. |
| 14:39.23 | file | I'm not either |
| 14:40.02 | mjordan | there's a feature we need to not rely on. For anything. |
| 14:43.08 | file | I should see what I have for sipp on those two agents and upgrade... |
| 14:44.05 | file | SIPp v3.4.1-TLS-PCAP-RTPSTREAM built Jun 28 2015, 13:23:12. |
| 14:44.32 | file | that's latest 3.4 |
| 14:44.36 | file | sad |
| 14:51.51 | *** join/#asterisk-dev fornax (~fornax@p5B2C424D.dip0.t-ipconnect.de) |
| 14:58.13 | stefan27 | which attended test? some attended transfer issue? I got an attended transfer crash on the test system with that non-digium module, but it looked like it was the extra modules fault |
| 14:58.32 | file | testsuite tests for attended transfers in PJSIP |
| 14:58.33 | stefan27 | some issue that affects the existing 13.5? |
| 14:58.43 | file | it's the test itself |
| 14:58.45 | stefan27 | aha, ok |
| 15:03.44 | mjordan | the attended transfer tests are pretty complex. Some rely on the 3PCC features in SIPp, which sporadically doesn't work causing the entire test to fail |
| 15:39.05 | *** join/#asterisk-dev fornax (~fornax@p5B2C424D.dip0.t-ipconnect.de) |
| 15:43.46 | *** join/#asterisk-dev babak (uid19622@gateway/web/irccloud.com/x-ghnjzefrqzsoicut) |
| 16:33.34 | *** join/#asterisk-dev Stefan26 (~Stefan27@195-67-255-105-no207.tbcn.telia.com) |
| 16:39.09 | wdoekes | file: there have been 270 commits in master since 3.4.1. I'm not saying anything related has been fixed, but it might |
| 16:42.38 | wdoekes | I do use the 3pcc for attn. xfer tests (and sort of latest sipp), and they haven't randomly failed on me yet, afaict. but I don't run the tests automatically, so I can't claim more than 100 runs. (not sure how often you're seeing failure.) |
| 16:44.43 | *** join/#asterisk-dev doome_ (~doome@77-234-67-65.pool.digikabel.hu) |
| 16:49.15 | Stefan26 | i only used python pjsua calling robots, is sipp hard to configure |
| 16:54.05 | file | wdoekes, yeah... Not sure I want to go down that road |
| 16:54.24 | file | Stefan26, you don't configure it exactly... you write scenario files which describe SIP message flows |
| 16:55.11 | wdoekes | file, you pessimist ;) |
| 16:59.14 | coreyfarrell | is bamboo permanently gone? |
| 17:00.12 | file | effectively, yes, but everything has not yet been moved over |
| 17:00.34 | file | we could have either sunk a lot of time into getting Bamboo working again or worked on Jenkins now (which was close to working) |
| 17:02.19 | coreyfarrell | file: thanks, that makes sense. I'll ask about getting the REF_DEBUG job recreated once the issues are worked out with the normal testsuite. |
| 17:13.40 | Stefan26 | aha |
| 17:15.12 | file | coreyfarrell, the stuff is actually in the infrastructure repo in gerrit, you can add jobs and such there |
| 17:15.40 | file | although the crontab that mjordan added to automatically update the running infrastructure may or may not work |
| 17:24.55 | mjordan | file: so... the record file AGI test that is failing doesn't fail on older versions of 13, and does fail consistently on the latest checkout. |
| 17:24.58 | mjordan | is investigating now |
| 17:25.14 | file | mjordan, geez you're back quickly |
| 17:25.23 | mjordan | from lunching? |
| 17:25.27 | file | yes |
| 17:25.30 | mjordan | it was successful |
| 17:28.53 | Stefan26 | what do americans eat? |
| 17:29.06 | mjordan | In this case, a gyro. |
| 17:29.18 | mjordan | My new favorite warning message:ast_log(LOG_WARNING, "Huh??\n"); |
| 17:30.33 | file | mjordan, Huh?? |
| 17:31.15 | mjordan | exactly. |
| 17:35.02 | coreyfarrell | file: do we have a how-to wiki page for that? :) |
| 17:35.12 | file | I wish. |
| 17:38.58 | *** join/#asterisk-dev oej (~oej@h87-96-134-129.dynamic.se.alltele.net) |
| 17:38.58 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 17:39.56 | mjordan | coreyfarrell: the zuul layout stuff/jenkins jobs stuff is actually pretty well documented via their project documentation |
| 17:40.06 | mjordan | the openstack project also has really good examples |
| 17:40.10 | mjordan | which I used as a basis for both |
| 17:41.47 | mjordan | coreyfarrell: https://wiki.asterisk.org/wiki/display/AST/Continuous+Integration |
| 17:41.55 | mjordan | that also contains a high level picture of the workflow |
| 17:43.28 | coreyfarrell | mjordan: thanks I'll check it out |
| 17:55.40 | *** join/#asterisk-dev oej (~oej@h87-96-134-129.dynamic.se.alltele.net) |
| 17:55.40 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 18:27.55 | *** join/#asterisk-dev fornax (~fornax@85.183.43.221) |
| 19:09.48 | *** join/#asterisk-dev newtonr (RustyNewto@nat/digium/x-uqkrvznddesifuog) |
| 19:09.48 | *** mode/#asterisk-dev [+o newtonr] by ChanServ |
| 19:23.47 | *** join/#asterisk-dev doome_ (~doome@77-234-67-65.pool.digikabel.hu) |
| 19:47.00 | *** join/#asterisk-dev luckman212_ (~luckman21@unaffiliated/luckman212) |
| 19:48.44 | *** join/#asterisk-dev Qwell (north@asterisk/developer/Qwell) |
| 19:48.44 | *** mode/#asterisk-dev [+o Qwell] by ChanServ |
| 19:49.06 | *** join/#asterisk-dev dustinm (~dustinm@105.ip-167-114-152.net) |
| 20:32.49 | *** join/#asterisk-dev fornax (~fornax@85.183.43.221) |
| 20:51.25 | *** join/#asterisk-dev [TK]D-Fender (~joe@64.235.216.2) |
| 21:08.50 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-179-40-172.cust.bezeqint.net) |
| 21:08.50 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 22:37.40 | *** join/#asterisk-dev snuff-work (~blatus@203.87.61.22) |
| 22:37.40 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 22:53.33 | *** part/#asterisk-dev kharwell (kharwell@nat/digium/x-dxjegsnkmvzuptoc) |