| 02:19.04 | *** join/#asterisk-dev acidfu_ (~acidfoo@198-48-218-90.cpe.pppoe.ca) |
| 02:53.32 | *** join/#asterisk-dev luckman212 (~luckman21@unaffiliated/luckman212) |
| 03:55.04 | *** join/#asterisk-dev klow (~textual@c-98-247-49-57.hsd1.wa.comcast.net) |
| 04:19.45 | *** join/#asterisk-dev klow (~textual@c-98-247-49-57.hsd1.wa.comcast.net) |
| 04:27.39 | *** join/#asterisk-dev leedm777 (~leedm777@50-81-28-152.client.mchsi.com) |
| 04:41.39 | *** join/#asterisk-dev leedm777 (~leedm777@50-81-28-152.client.mchsi.com) |
| 05:00.09 | *** join/#asterisk-dev klow (~textual@c-67-161-106-89.hsd1.wa.comcast.net) |
| 05:25.01 | *** join/#asterisk-dev bof22 (~Thunderbi@185.13.183.107) |
| 05:41.53 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01cb0583d31d006166ff4b3ecc7488.ipv6.abo.wanadoo.fr) |
| 06:31.05 | *** join/#asterisk-dev klow (~textual@c-98-247-49-57.hsd1.wa.comcast.net) |
| 06:58.53 | *** join/#asterisk-dev klow (~textual@c-98-247-49-57.hsd1.wa.comcast.net) |
| 07:12.58 | *** join/#asterisk-dev pchero_work (~pchero@109.70.54.56) |
| 07:14.13 | *** join/#asterisk-dev hehol (~hehol@gatekeeper.loca.net) |
| 07:18.36 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 07:18.36 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 07:19.37 | *** join/#asterisk-dev CELYA_ (~Thunderbi@LStLambert-657-1-90-73.w80-13.abo.wanadoo.fr) |
| 08:39.33 | *** join/#asterisk-dev coreyfarrell (~coreyfarr@24-177-86-98.dhcp.nwtn.ct.charter.com) |
| 11:31.15 | *** join/#asterisk-dev acidfu_ (~acidfoo@198-48-218-90.cpe.pppoe.ca) |
| 12:07.43 | *** join/#asterisk-dev acidfu_ (~acidfoo@modemcable002.114-70-69.static.videotron.ca) |
| 13:04.56 | *** join/#asterisk-dev leedm777 (~leedm777@50-81-28-152.client.mchsi.com) |
| 14:01.04 | *** join/#asterisk-dev kharwell (kharwell@nat/digium/x-oxuaflhdpaahsvww) |
| 14:02.56 | *** join/#asterisk-dev snuff-work (~snuff-wor@203.87.61.22) |
| 14:02.56 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 14:03.44 | *** join/#asterisk-dev cresl1n (Adium@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 14:03.44 | *** mode/#asterisk-dev [+o cresl1n] by ChanServ |
| 14:05.37 | cresl1n | waves |
| 14:06.32 | file | hola |
| 14:11.09 | cresl1n | file!!!! |
| 14:20.19 | *** join/#asterisk-dev putnopvut (putnopvut@asterisk/master-of-queues/mmichelson) |
| 14:20.19 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 14:21.39 | file | A wild putnopvut appears. |
| 14:24.23 | gtjoseph | can I get some express love on 3385,6,7? They're holding up something else. |
| 14:25.04 | file | something else you're putting up for review? O.o |
| 14:25.50 | gtjoseph | yep and i forgot to base my new patch on these and don't want to have to atempt a rebase. |
| 14:34.59 | file | putnopvut, thoughts on pulling the silk change from 13 as well and keeping it consistent 13+? |
| 14:36.56 | file | kharwell, remember that SQLAlchemy issue? |
| 14:37.09 | kharwell | which one? |
| 14:37.21 | file | 1.1.0b2 |
| 14:38.08 | kharwell | yeah something about the beta release causing a problem. I can't remember the exact error it gave though |
| 14:38.11 | file | yeahhhhh |
| 14:38.18 | file | I think CentOS updated... to that... |
| 14:38.35 | kharwell | might be time to cross that bridge then |
| 14:38.45 | file | yeahhhhhh |
| 14:38.58 | kharwell | if it can be |
| 14:39.17 | gtjoseph | unlikely that centos updated. fedora 24 is still 0.8.3 |
| 14:39.24 | putnopvut | file: I'd be fine with that, I guess. We'd need to rebuild codec_silk for 13, then. And we'd need to make sure to get the 13 change into the 13.11 branch |
| 14:39.52 | file | putnopvut, we can keep it different - we'll just need to do another testsuite change |
| 14:39.55 | file | to take it into account |
| 14:40.12 | gtjoseph | divergence is bad. :) |
| 14:40.50 | putnopvut | "we can keep it different" What do you mean by "it" ? |
| 14:41.10 | file | well the two choices are: keep it as is in 13 and adjust the test, or remove it and make 13+ the same |
| 14:41.31 | file | if we're fine with rebuilding and pulling it into 13.11, then removing is gooooood |
| 14:43.39 | kharwell | why would it need to go into 13.11? Could it not wait for 13.12? |
| 14:45.19 | gtjoseph | file: centos6: python-sqlalchemy noarch 0.5.5-3.el6_2 |
| 14:45.22 | putnopvut | kharwell: it's more of a convenience thing. We could release 13.11 with silk payload stuff still in it and it would be compatible with the current build of codec_silk. But then we'd need to make a new codec_silk build for 13.12, and everyone would have to switch versions of codec_silk when they upgrade |
| 14:45.40 | gtjoseph | centos7: python-sqlalchemy.x86_64 0.9.8-1.el7 |
| 14:45.43 | putnopvut | So for convenience, throw it all in now so that hopefully we never have to rebuild codec_silk in the lifetime of 13. |
| 14:46.04 | file | gtjoseph, well somehow the broken version appeared on the Jenkins nodes and also in a CentOS 6.5 install from a user... |
| 14:46.15 | kharwell | aah okay yeah. Cutting an rc2 of 13.11 would be better than that |
| 14:46.20 | gtjoseph | installed from rpm or pip?? |
| 14:46.45 | file | I have no idea how the user installed, and I don't know how we installed - maybe pip |
| 14:47.09 | gtjoseph | well, we knew that the pip version was beta. that was from a while ago |
| 14:47.10 | file | puppet may have updated |
| 14:47.45 | file | gtjoseph, yeah but since a user has hit it too now... others likely have/will, so best to solve it |
| 14:48.33 | kharwell | I agree we're gonna have to fix it at some point |
| 14:48.40 | gtjoseph | no question. just sayin. |
| 14:49.09 | gtjoseph | might want to tell the user in question to use rpm though. |
| 14:49.30 | kharwell | and we know it is not a bug in SQLAlchemy right? Not something they need to fix? |
| 14:49.37 | file | kharwell, no idea |
| 14:49.38 | gtjoseph | no we don't know anything |
| 14:51.21 | kharwell | it is marked a beta (although I am not sure why that is set for the default when installing from pip). If it is their bug I guess it is possible it could get fixed before it is a problem for us |
| 14:51.29 | kharwell | so we may not need to put effort into a workaround |
| 14:54.29 | *** join/#asterisk-dev rmudgett (rmudgett@nat/digium/x-bcjrirlfqxyqsprq) |
| 15:53.36 | gtjoseph | rmudgett: lowered observer tp's to 5. none of them go above 80 but getting "Unable to register SUBSCRIBE transaction (key exists)" and slow throughput. |
| 15:54.19 | gtjoseph | this is with 600 simultaneous calls where I hsould be able to do 1000 |
| 15:55.45 | rmudgett | I thought you were still getting those key exists messages with the previous pjsip/distributor patches. |
| 15:56.25 | gtjoseph | not until i reached about 1100 simultaneous calls. |
| 15:56.35 | gtjoseph | certainly not at 600 |
| 15:57.41 | rmudgett | I'm not as confident about the rwlock change since the code may be depending on more serialization from the mutex. |
| 15:57.53 | gtjoseph | let me back it out again |
| 16:05.25 | gtjoseph | rmudgett: much better results without th elocking patch |
| 16:07.41 | rmudgett | There may just be too much contention for the write lock or the write lock has to wait too long to get it. |
| 16:09.37 | file | It favours reads if I remember right |
| 16:15.03 | rmudgett | Which would mean that writes would have to be fairly rare to make rwlocks a real benefit. |
| 16:27.19 | file | rmudgett, yes |
| 16:40.17 | *** join/#asterisk-dev newtonr (RustyNewto@nat/digium/x-ceazapxlvmpmofrx) |
| 16:40.17 | *** mode/#asterisk-dev [+o newtonr] by ChanServ |
| 16:40.34 | newtonr | hallo |
| 16:41.37 | file | newtonr, haylo |
| 16:41.58 | file | or Halo in the case Beyonce |
| 16:46.27 | *** join/#asterisk-dev luckman212 (~luckman21@unaffiliated/luckman212) |
| 16:50.00 | *** join/#asterisk-dev acidfu_ (~acidfoo@modemcable002.114-70-69.static.videotron.ca) |
| 17:01.13 | *** join/#asterisk-dev luckman212 (~luckman21@unaffiliated/luckman212) |
| 17:05.54 | *** join/#asterisk-dev babak (uid19622@gateway/web/irccloud.com/x-eeeomssocqegegpl) |
| 17:14.36 | *** join/#asterisk-dev luckman212 (~luckman21@unaffiliated/luckman212) |
| 17:19.40 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01cb0583d31d006cd0a6d843d84568.ipv6.abo.wanadoo.fr) |
| 17:42.49 | *** join/#asterisk-dev pchero (~pchero@109.70.54.56) |
| 17:48.32 | gtjoseph | rmudgett: noticed a side effect... although there are more taskprocessors, the limit is lower so of 1 hits the limit, the distributor stops. if another taskprocessor hits the limit before the first one clears, the distributor can be stopped fro long periods of time. |
| 17:48.51 | *** join/#asterisk-dev luckman212 (~luckman21@unaffiliated/luckman212) |
| 17:49.51 | rmudgett | Yes, it has to be that way because at least one taskprocessor is over the limit. |
| 17:50.38 | gtjoseph | but it's an issue. i think the observer trigger point should be twice what it is |
| 17:51.20 | rmudgett | The intention is to make it configurable. First we need to determine if it is even helpful. |
| 17:51.32 | gtjoseph | yeah makes sense |
| 17:52.11 | gtjoseph | do you set the limits in sorcery.c or let them default? |
| 17:52.23 | rmudgett | They are the default. |
| 17:52.59 | rmudgett | To change the levels you just call a routine with the new levels. |
| 17:53.19 | gtjoseph | yeah i'll try it after lunch |
| 17:53.44 | rmudgett | ast_taskprocessor_alert_set_levels() |
| 17:58.26 | *** join/#asterisk-dev luckman212 (~luckman21@unaffiliated/luckman212) |
| 18:02.04 | gtjoseph | preminary results: 5000 txs 800 simul |
| 18:02.26 | gtjoseph | current 13: 68% completion, 30.1 txs per sec |
| 18:03.02 | gtjoseph | just the 0003 patch: 20% completion, 26 txs per sec |
| 18:03.28 | gtjoseph | just the 0003 patch 7 taskprocessors: 50% completion, 26 tps |
| 18:03.58 | gtjoseph | just the 0003 patch 3 taskprocessors: 60% completion, 29 tps |
| 18:04.12 | gtjoseph | not lookin to good. |
| 18:04.30 | gtjoseph | even current 13 is worse than it was after you did your original patch series. |
| 18:04.44 | gtjoseph | i need to do a git bisect to see when it changed. |
| 18:17.23 | *** join/#asterisk-dev klow (~textual@73.109.63.12) |
| 18:21.22 | *** join/#asterisk-dev luckman212 (~luckman21@unaffiliated/luckman212) |
| 18:24.49 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-179-40-172.cust.bezeqint.net) |
| 18:24.49 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 18:35.30 | kharwell | For the publish rest-api docs changes that are currently up on gerrit. The rest api out of sync stuff will first need to be merged or the script will fail |
| 18:36.29 | file | kharwell, all sorted |
| 18:43.24 | file | https://wiki.asterisk.org/wiki/display/AST/Home is the left hand side out of order for anyone else? |
| 18:43.27 | *** join/#asterisk-dev klow (~textual@96.81.150.137) |
| 18:43.51 | zerohalo | looks okay to me |
| 18:43.59 | file | interesting |
| 18:44.06 | file | Asterisk 14 documentation is at the top for me, and then Reordering |
| 18:44.10 | zerohalo | oh - yes |
| 18:44.25 | zerohalo | it's the same - I interpreted 'out of order' as not working. :) |
| 18:44.59 | zerohalo | Asterisk 14, then Temporary Page for ReOrdering |
| 18:45.00 | file | ha |
| 18:46.16 | file | Confluence is Confluence |
| 19:02.35 | *** join/#asterisk-dev luckman212 (~luckman21@unaffiliated/luckman212) |
| 19:15.56 | gtjoseph | infrastructure seems kinda slow today or is it my imagination because I'm waiting for some merges. :) |
| 19:16.38 | rmudgett | gtjoseph: it's both |
| 19:16.38 | file | checks will jump ahead in the queue, so it can delay merges |
| 19:49.52 | *** join/#asterisk-dev cresl1n (Adium@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 19:49.52 | *** mode/#asterisk-dev [+o cresl1n] by ChanServ |
| 19:57.39 | *** join/#asterisk-dev luckman212 (~luckman21@unaffiliated/luckman212) |
| 20:06.57 | *** join/#asterisk-dev luckman212 (~luckman21@unaffiliated/luckman212) |
| 20:17.59 | *** join/#asterisk-dev luckman212 (~luckman21@unaffiliated/luckman212) |
| 20:28.40 | *** join/#asterisk-dev klow (~textual@c-98-247-49-57.hsd1.wa.comcast.net) |
| 20:38.22 | *** join/#asterisk-dev luckman212 (~luckman21@unaffiliated/luckman212) |
| 21:01.12 | gtjoseph | is there a good define for the maximum number of digits in an unsigned long? |
| 21:05.29 | rmudgett | There is a define for the maximum value of an unsigned long in limits.h |
| 21:05.46 | gtjoseph | yeah i just counted... 20 |
| 21:05.49 | gtjoseph | :) |
| 21:16.31 | *** join/#asterisk-dev luckman212 (~luckman21@unaffiliated/luckman212) |
| 21:35.15 | *** join/#asterisk-dev cresl1n (Adium@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 21:35.15 | *** mode/#asterisk-dev [+o cresl1n] by ChanServ |
| 21:52.57 | *** join/#asterisk-dev klow (~textual@c-98-247-49-57.hsd1.wa.comcast.net) |
| 23:04.32 | *** part/#asterisk-dev kharwell (kharwell@nat/digium/x-oxuaflhdpaahsvww) |
| 23:08.18 | gtjoseph | if you had your choice, would you rather have an external codec downloaded to /tmp, then erases after install, or downloaded to /tmp and kept so wget can compare the times and save the download step the next time make install is run? |
| 23:08.50 | file | neither - what do we do for sounds? |
| 23:09.25 | gtjoseph | we extract them in the sounds directory then delete |
| 23:09.35 | file | they don't download again on make install |
| 23:09.48 | gtjoseph | because the sounds are up to date. |
| 23:09.53 | gtjoseph | extracted sounds |
| 23:10.23 | gtjoseph | but they don't get erased on make unistall either |
| 23:10.56 | gtjoseph | codecs will have the .so + LICENSE and optionally README |
| 23:11.16 | gtjoseph | the license and readme go in /var/lib/asterisk/documentation/thirdparty |
| 23:11.20 | file | sure. |
| 23:11.29 | file | I don't think either option is good. :P |
| 23:12.04 | gtjoseph | got an alternative? |
| 23:12.15 | gtjoseph | i have to save the tarball somewhere to extract |
| 23:12.19 | file | sure |
| 23:12.59 | file | save a small file with it which contains enough information to know not to re-download? |
| 23:13.11 | file | it being the codec and other assorted stuff |
| 23:13.35 | gtjoseph | i still have to save the tarball then |
| 23:13.50 | file | you have to save the tarball somewhere in order to extract it... |
| 23:14.00 | file | or do you mean to check the file? |
| 23:14.15 | file | ultimately I don't think downloading the codec on every make install is acceptable |
| 23:14.43 | gtjoseph | check the file. i can't rely on "codec_silk.so" being in /usr/lib/asterisk/modules because it would require me to know what's ion the tarball |
| 23:15.01 | gtjoseph | which is why i want to save the tarball in /tmp |
| 23:15.10 | gtjoseph | like we do with the curren tpjproject download |
| 23:15.33 | gtjoseph | oops, gotta kill a wasp |
| 23:15.53 | file | if we absolutely have to, fine |
| 23:15.54 | file | however... |
| 23:16.39 | file | I still don't understand why you couldn't get the HEAD details of the file, store that in a small text file which represents what is currently installed and present, and then do a head check on a make install to see if server side is different |
| 23:16.52 | file | but that's just me |
| 23:18.36 | file | were you planning to just not download/compare if the tarball was already there? |
| 23:18.55 | gtjoseph | no, let wget compare the timestamps |
| 23:19.11 | gtjoseph | i can do the small file though. where do want THAT?? |
| 23:19.35 | file | shrugs |
| 23:19.40 | file | wherever seems reasonable! |
| 23:20.02 | gtjoseph | actually, looking at sounds again, there's a .asterisk-core-sounds-en-gsm-1.5 in the /var/lib/asterisk/sounds/en directory. |
| 23:20.11 | file | yeah, that's how it knows |
| 23:20.19 | gtjoseph | and you are no help at all. :) |
| 23:21.56 | file | nope! |
| 23:22.13 | gtjoseph | this is where it's going then... $(DESTDIR)$(ASTVARLIBDIR)/documentation/thirdparty/$(CODEC)/.version |
| 23:22.53 | gtjoseph | it's either that or $(DESTDIR)$(ASTMODDIR)/.$(CODEC).version |
| 23:24.20 | gtjoseph | coreyfarrell or rmudgett: do you have opinions? |
| 23:24.51 | rmudgett | not me |
| 23:25.21 | gtjoseph | actually i like $(DESTDIR)$(ASTMODDIR)/.$(CODEC).version better now since i don't know if there will be any documentation |
| 23:25.26 | gtjoseph | DONE |
| 23:52.46 | coreyfarrell | gtjoseph: I'd say it'd be better to use $(ASTMODDIR)/$(MODULE_NAME).version (no dot prefix). that way bash autocomplete would find both files if someone goes to manually 'rm'. |
| 23:53.00 | gtjoseph | good point |
| 23:53.26 | gtjoseph | i'm going to use the .manifest extension btw |
| 23:53.50 | coreyfarrell | fine with me. you going to use the same basic format? |
| 23:53.51 | gtjoseph | because it will actually be a manifest |
| 23:54.04 | gtjoseph | which format. :) |
| 23:55.57 | coreyfarrell | https://wiki.asterisk.org/wiki/display/AST/Module+Loader+Ideas#ModuleLoaderIdeas-ExampleManifest -- this is what I was going to use for the module loader.. obviously you won't need all those fields but the basic idea.. |
| 23:58.00 | gtjoseph | we'll see. i need to be able to parse it easily from a Makefile and it must contain a list of file pairs... path in the tarball, path on disk |
| 23:59.05 | gtjoseph | i can put the version in the [module] section an dmaybe list the files as <tarball_path>=<fs_path> in a [files] section |