| 00:17.38 | *** join/#asterisk-dev moy (n=moy@CPE001cdfec4cee-CM00080dab8485.cpe.net.cable.rogers.com) |
| 00:34.11 | *** join/#asterisk-dev smurf (n=smurf@debian/developer/smurf) |
| 00:37.15 | *** join/#asterisk-dev seanbright (n=sean@asterisk/contributor-and-bug-marshal/seanbright) |
| 00:37.15 | *** mode/#asterisk-dev [+o seanbright] by ChanServ |
| 02:42.15 | *** join/#asterisk-dev pyite (n=pyite@unaffiliated/pyite) |
| 03:03.13 | *** join/#asterisk-dev tzafrir_laptop (n=tzafrir@212.179.75.202) [NETSPLIT VICTIM] |
| 03:03.13 | *** mode/#asterisk-dev [+o tzafrir_laptop] by irc.freenode.net |
| 03:22.28 | *** join/#asterisk-dev philipp64 (n=chatzill@63.224.43.239) |
| 04:16.00 | *** join/#asterisk-dev felipe_ (n=felipe@my.nada.kth.se) |
| 04:29.33 | *** join/#asterisk-dev ApOgEE (i=apogee@elite.bshellz.net) |
| 04:54.23 | *** join/#asterisk-dev Iamnach0 (i=Iamnacho@ip98-186-180-143.ks.ks.cox.net) |
| 05:37.22 | *** join/#asterisk-dev snuff-work (n=aaa@203.19.141.34) |
| 05:37.22 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 05:43.43 | *** join/#asterisk-dev fiddur (n=fiddur@dhcp08.textalk.com) |
| 06:06.30 | *** join/#asterisk-dev |Cybex| (n=John@atwork-26.r-212.178.82.atwork.nl) |
| 06:52.28 | *** join/#asterisk-dev tzafrir_laptop (n=tzafrir@local.xorcom.com) |
| 06:52.28 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 07:05.31 | tzafrir_laptop | So viewvc is back? |
| 07:07.13 | snuff-work | indeed |
| 07:41.22 | *** join/#asterisk-dev tamiel (n=tamiel@213.30.183.226) |
| 07:41.56 | *** join/#asterisk-dev |Cybex| (n=John@212.178.82.26) |
| 08:10.32 | tzafrir_laptop | DAHDI_EVENT_REMOVED is a message to Asterisk to disconnect a DAHDI channel as its hardware is now gone |
| 08:10.54 | tzafrir_laptop | It was basically fixed yesterday, but only for analog channels, aparantly |
| 08:11.26 | tzafrir_laptop | But it does "work": Asterisk gets the event, segfaults, dies and thus frees those channels :-) |
| 08:13.21 | fiddur | :D |
| 08:14.07 | fiddur | So you shouldn't unplug your usb astribank while asterisk is running? |
| 08:14.18 | tzafrir_laptop | why? |
| 08:14.31 | fiddur | if it segfaults? |
| 08:14.38 | tzafrir_laptop | nah, it's just a bug that needs fixing |
| 08:15.10 | tzafrir_laptop | fiddur, in the mean time, restart asterisk from the "offline" even of the astribank_hook :-) |
| 08:16.02 | fiddur | Heh ok... |
| 10:25.24 | tzafrir_laptop | fiddur, BTW: so far crash is only reproduced if I have a var set with setvar |
| 10:26.40 | *** join/#asterisk-dev Iamnacho (i=Iamnacho@ip98-186-180-143.ks.ks.cox.net) |
| 10:54.35 | *** join/#asterisk-dev kpfleming (n=kpflemin@asterisk/digium-director-of-software-tech/kpfleming) |
| 10:54.35 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 10:59.17 | kpfleming | if you fall in the pond, you will be boiled. |
| 11:02.12 | snuff-home | mm sounds like interesting bit of wisdom your trying to impart kp.. |
| 11:04.05 | kpfleming | from engrish.com this morning |
| 11:06.25 | snuff-home | ah yes.. the classic signage.. |
| 11:20.10 | tzafrir_laptop | well, I guess that's a side-effect of using Java |
| 11:38.52 | kpfleming | file is singing and talking to himself this moring |
| 11:38.57 | kpfleming | s/moring/morning/ |
| 11:42.16 | file | just like always! |
| 11:43.50 | snuff-home | mm.. its time to work soon for u guys ;) |
| 11:44.23 | file | in kpfleming's sane state he didn't schedule anything until 10 |
| 11:44.55 | file | hopes they have bacon at breakfast |
| 11:46.01 | snuff-home | wonders what will happen if file gets no bacon.. |
| 11:46.16 | file | just a sad face |
| 11:48.24 | snuff-home | aw.. no fun.. |
| 11:54.47 | file | there goes the laptop of kpfleming into a suspend state |
| 12:00.18 | kpfleming | i have now returned from suspended animation |
| 12:15.15 | snuff-home | hey file.. iax2 issue just popped up on tracker ;) |
| 12:15.23 | snuff-home | M15900 |
| 12:15.26 | MuffinMan | [new] [Asterisk] Channels/chan_iax2 0015900: Console flood & CPU load 100% when IAX2 channel falls reported by Newborn (Karma: neutral) https://issues.asterisk.org/view.php?id=15900 |
| 12:16.44 | *** join/#asterisk-dev caio1982 (i=caio1982@CAcert-br/caio1982) |
| 12:28.45 | *** join/#asterisk-dev caio1982 (i=caio1982@CAcert-br/caio1982) |
| 12:43.59 | *** join/#asterisk-dev oej (n=olle@132.177.253.250) |
| 12:43.59 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 12:45.25 | oej | Morning folks |
| 12:45.32 | snuff-home | mornin oej |
| 12:46.02 | snuff-home | ready to play 'omg chan_sip.. u been bad' ? |
| 12:47.16 | *** join/#asterisk-dev xpot (n=james@70-91-210-233-BusName-Utah.hfc.comcastbusiness.net) |
| 12:47.18 | oej | Yep. But I'm not really part of the Asterisk test team this time... I am just making sure that the Digium team are busy... ;-) |
| 12:50.12 | *** join/#asterisk-dev dwery (n=dwery@nslu2-linux/dwery) |
| 12:50.45 | dwery | hello. here is a patch that solves the double sip: in some SIP uris in notifications. http://pastebin.com/f25e93ed8 can someone pick it up? |
| 12:58.45 | *** join/#asterisk-dev leifmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 12:58.45 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 13:00.29 | snuff-home | dwery: post it urself |
| 13:00.46 | snuff-home | if you made it.. |
| 13:01.21 | snuff-home | just add issue to issues.asterisk.org .. u'll ahve to sign the license |
| 13:01.35 | snuff-home | it will take about 1-3 days to be approved |
| 13:01.44 | snuff-home | then we can look at integrating your patch |
| 13:02.27 | dwery | I need to sign a license and wait 1-3 days for a one liner? that's funny :D |
| 13:08.09 | dwery | Got lost after the first paragraph.. I hereby state that the above mentioned patch is released in the public domain. If you like it, pick it up... otherwise it will be bound in the darkness forever and ever. period. |
| 13:13.08 | leifmadsen | dwery: once you've attached the patch to the tracker and sign the electronic license, you can pretty much vanish. But without it, it won't be picked up. |
| 13:13.59 | dwery | leifmadsen: I can understand the reasons but cannot agree with them |
| 13:14.12 | leifmadsen | ok... |
| 13:14.22 | leifmadsen | the license only needs to be signed once for all patches |
| 13:14.30 | leifmadsen | so if you submit again, you don't have to re-sign |
| 13:14.33 | leifmadsen | it'll already be done |
| 13:14.47 | dwery | I know. But still can't agree. |
| 13:15.04 | leifmadsen | shrugs |
| 13:24.35 | *** join/#asterisk-dev leifmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 13:24.35 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 13:32.10 | *** join/#asterisk-dev kpfleming (n=kpflemin@asterisk/digium-director-of-software-tech/kpfleming) |
| 13:32.10 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 13:53.23 | seanbright | dwery: which mantis issue are you referring to? |
| 13:54.09 | seanbright | M15847 |
| 13:54.11 | MuffinMan | [ready for review] [Asterisk] Channels/chan_sip/Subscriptions 0015847: [patch] NOTIFY to contains double sip: reported by ebroad (Karma: neutral) https://issues.asterisk.org/view.php?id=15847 |
| 13:54.13 | seanbright | that one i'm guessing |
| 13:55.08 | seanbright | there is already a patch there. hrmm. |
| 13:55.20 | dwery | seanbright: it seems so. the fix has probably been wringly imported in asterisk 1.6 |
| 13:55.55 | dwery | seanbright: the test looks inverted. comparing against 0 is easirer to read than the ! btw |
| 13:56.21 | seanbright | i agree, but unfortunately the coding standards don't agree with us |
| 13:56.48 | seanbright | so i'm confused. is your patch any different than the one on that issue? |
| 13:57.27 | seanbright | other than possibly using ' == 0' rather than '!' |
| 13:59.16 | dwery | seanbright: It should be the same. |
| 13:59.23 | seanbright | ok great. |
| 13:59.36 | seanbright | once it's committed to trunk, it will be merged into 1.6.0 |
| 13:59.48 | seanbright | assuming the bug exists there (and i think you're implying that it is) |
| 14:00.19 | dwery | yes. I had not noticed that a bug was already open on that issue |
| 14:00.24 | seanbright | gotcha |
| 14:00.28 | seanbright | good times. |
| 14:01.12 | dwery | seanbright: there's still something wrong when mwi notifications are sent to the phone (st2030), as I get the usual "cannot match leg..) but I'm not sure it's asterisk fault |
| 14:01.18 | dwery | at fault* |
| 14:01.35 | *** join/#asterisk-dev Victor_Yure (n=victor@unaffiliated/victoryure/x-837844) |
| 14:01.51 | seanbright | i know very little about chan_sip, unfortunately. |
| 14:01.56 | *** join/#asterisk-dev Deeewayne (n=dwayne@75.76.254.162) |
| 14:01.56 | *** mode/#asterisk-dev [+o Deeewayne] by ChanServ |
| 14:02.01 | dwery | me too :D |
| 14:02.09 | dwery | but it ostly works :D |
| 14:02.23 | seanbright | and the price is right |
| 14:02.59 | dwery | absolutely |
| 14:15.15 | *** join/#asterisk-dev oej_ (n=olle@132.177.254.166) |
| 14:15.15 | *** mode/#asterisk-dev [+o oej_] by ChanServ |
| 14:16.02 | *** join/#asterisk-dev oej__ (n=olle@132.177.253.250) |
| 14:16.02 | *** mode/#asterisk-dev [+o oej__] by ChanServ |
| 14:17.37 | *** join/#asterisk-dev moy (n=moy@74.12.131.104) |
| 14:22.42 | *** join/#asterisk-dev mnt_real (n=sinan@bas12-montrealak-1167975649.dsl.bell.ca) |
| 14:22.42 | *** join/#asterisk-dev elguero (n=elguero@ns1.nashuacs.com) |
| 14:25.17 | *** join/#asterisk-dev sruffell (n=sruffell@asterisk/the-kernel-guy/sruffell) |
| 14:25.17 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 14:25.49 | *** join/#asterisk-dev anthm (n=anthm@freeswitch/developer/anthm) |
| 14:26.00 | *** join/#asterisk-dev Grof (n=dule@89.201.165.226) |
| 14:26.09 | Grof | hey guys |
| 14:26.14 | *** part/#asterisk-dev |Cybex| (n=John@212.178.82.26) |
| 14:26.40 | Grof | anyone into Confbridge here? |
| 14:26.54 | Grof | :D |
| 14:34.25 | seanbright | leifmadsen meant the asterisk-dev *mailing list* |
| 14:37.15 | Grof | omg |
| 14:37.19 | Grof | Z0MG |
| 14:43.57 | *** join/#asterisk-dev putnopvut (n=putnopvu@asterisk/master-of-queues/mmichelson) |
| 14:43.57 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 14:44.25 | *** part/#asterisk-dev dwery (n=dwery@nslu2-linux/dwery) |
| 14:57.03 | *** join/#asterisk-dev jpeeler (n=jpeeler@asterisk/digium-software-dev/jpeeler) |
| 14:57.03 | *** mode/#asterisk-dev [+o jpeeler] by ChanServ |
| 15:03.17 | *** join/#asterisk-dev |Cybex| (n=John@80.100.126.176) |
| 15:22.02 | *** join/#asterisk-dev jtexter3 (n=jtexter3@72.242.229.213) |
| 15:29.53 | *** join/#asterisk-dev hugorebelo (n=hugorebe@200-171-132-124.completo.com.br) |
| 15:45.36 | *** join/#asterisk-dev kpfleming (n=kpflemin@asterisk/digium-director-of-software-tech/kpfleming) |
| 15:45.36 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 15:46.26 | *** join/#asterisk-dev marv[work] (n=timr@router.asteriasgi.com) |
| 15:57.13 | *** part/#asterisk-dev dbrooks (n=dbrooks@nat/digium/x-qltmjqftmhrsywkd) |
| 15:57.48 | *** join/#asterisk-dev oej (n=olle@132.177.253.250) |
| 15:57.48 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 16:00.35 | Kobaz | how do you get a bracktrace in a core with all the asterisk thread stacks |
| 16:02.14 | kpfleming | doc/backtraces.txt |
| 16:15.36 | *** join/#asterisk-dev Iamnach0 (i=Iamnacho@ip98-186-180-143.ks.ks.cox.net) |
| 16:17.24 | *** join/#asterisk-dev DrDeth (n=DrDeth@mail.mexuar.net) |
| 16:19.12 | DrDeth | Does anyone know if the iaxclient project is still 'active', or if there are any updated alternatives? |
| 16:28.15 | kpfleming | mantis 15343 |
| 16:28.22 | Qwell | M15343 |
| 16:28.25 | MuffinMan | [ready for testing] [Asterisk] Channels/chan_sip/TCP-TLS 0015343: [patch] lock in sip_tcp_helper_thread reported by pj (Karma: +9.50) https://issues.asterisk.org/view.php?id=15343 |
| 16:28.41 | kpfleming | putnopvut: ^^^ |
| 16:39.32 | tzafrir_laptop | Speaking of IAX: any idea what other IAX2 implementations can work with laetst Asterisk? |
| 16:39.43 | putnopvut | kpfleming: yep, I've been looking at that patch for the past couple of minutes between bites of lunch. |
| 16:39.45 | kpfleming | all of them |
| 16:40.11 | tzafrir_laptop | (assuming Asterisk is not in compatibility mode, or whatever it is called) |
| 16:41.22 | *** join/#asterisk-dev jpeeler (n=jpeeler@asterisk/digium-software-dev/jpeeler) |
| 16:41.22 | *** mode/#asterisk-dev [+o jpeeler] by ChanServ |
| 16:43.02 | kpfleming | if asterisk is in secure mode, then probably no existing implementations will work, until they are updated |
| 16:50.56 | Corydon76-dig | putnopvut: does that patch make sense to you? |
| 16:55.26 | *** part/#asterisk-dev |Cybex| (n=John@80.100.126.176) |
| 16:56.52 | putnopvut | Corydon76-dig: I'm still doing analysis, but one thing that I immediately didn't like was the use of a goto and label where a while loop would make much more sense. |
| 16:57.42 | putnopvut | The other thing, and it may just be that pj meant to mention it but didn't, was that it appears this patch only affects TLS operation. |
| 16:58.06 | putnopvut | pj just mentioned that this peer was using TCP but never mentioned using TLS. |
| 17:00.26 | putnopvut | Actually, now that I look more, I don't understand why the locks were removed from chan_sip in that patch. Is the tcptls server instance's FILE pointer protected when fgets and fread are called? |
| 17:01.08 | *** join/#asterisk-dev Grof (n=krash@78.0.254.251) |
| 17:08.58 | *** join/#asterisk-dev ebroad (n=EB@72.11.213.195) |
| 17:10.06 | tzafrir_laptop | jpeeler, nice. Now DAHDI_EVENT_REMOVED also works for D-channels in PRI |
| 17:10.09 | tzafrir_laptop | is happy |
| 17:11.50 | jpeeler | yay |
| 17:24.09 | *** join/#asterisk-dev |Cybex| (n=John@80.100.126.176) |
| 17:27.43 | *** join/#asterisk-dev The_Boy_Wonder (n=davidvos@asterisk/batman-developer/dvossel) |
| 17:27.43 | *** mode/#asterisk-dev [+o The_Boy_Wonder] by ChanServ |
| 17:29.42 | ebroad | The_Boy_Wonder, check out m15854 |
| 17:29.58 | ebroad | i think i found your registration issu |
| 17:30.00 | ebroad | *issue |
| 17:30.25 | The_Boy_Wonder | ebroad: cool |
| 17:30.33 | The_Boy_Wonder | i'll take a look |
| 17:30.49 | ebroad | also, shouldnt port_str2int check the range |
| 17:31.29 | ebroad | i.e. port >= 1 && port <= 65535 |
| 17:31.54 | ebroad | came across it when looking at your patch |
| 17:46.15 | tzafrir_laptop | M15877 |
| 17:46.17 | MuffinMan | [acknowledged] [DAHDI-linux] dahdi (the module) 0015877: [patch] FreeBSD port reported by Max Khon (Karma: neutral) https://issues.asterisk.org/view.php?id=15877 |
| 17:46.52 | tzafrir_laptop | What do you think: any hope in keeping a single dahdi-{linux,bsd} tree? |
| 17:47.00 | tzafrir_laptop | A separate dahdi-freebsd ? |
| 17:47.07 | russellb | separate dahdi-freebsd IMO |
| 17:47.15 | The_Boy_Wonder | ebroad: adding range checking to port_str2int is a good idea |
| 17:47.41 | ebroad | ok |
| 17:48.22 | ebroad | The_Boy_Wonder, you could probably just copy the code out of 15880 |
| 17:48.49 | ebroad | The_Boy_Wonder, then i can modify that patch to use that function |
| 17:49.17 | ebroad | The_Boy_Wonder, also, sscanf should be %5d not %30d |
| 17:50.55 | kpfleming | tzafrir_laptop: yes, it will be separate |
| 17:57.54 | *** join/#asterisk-dev sruffell (n=sruffell@asterisk/the-kernel-guy/sruffell) |
| 17:57.54 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 17:58.36 | *** part/#asterisk-dev macli (n=macli@nmc.brc.ubc.ca) |
| 18:02.00 | philipp64 | lmadsen: you understand that stdexten has two separate things wrong with it, right? hence two different issues logged (because they might not both be fixed simultaneously). |
| 18:02.21 | philipp64 | so 15858 and 15857 are two unrelated issues. |
| 18:02.45 | philipp64 | oh, bugger. he's not around. |
| 18:02.49 | leifmadsen | Yes I am |
| 18:03.15 | philipp64 | ah... chatzilla shows you as being light green... which means you're either away or not yet ripe. |
| 18:03.37 | leifmadsen | I didn't see a difference between the issues, other than that something changed in the extensions.conf.sample which needs to be reviewed and fixed |
| 18:04.19 | leifmadsen | I'm treating 15857 as a more general issue than as reported by the reporter |
| 18:04.35 | leifmadsen | (i.e. that the entire thing needs to be reviewed as working) |
| 18:04.45 | philipp64 | one is references to non-existent priorities, and the other has to do with Gosub's sometimes failing to match up the priority (since there is no 's' priority in Tilghman's new version) |
| 18:05.06 | leifmadsen | huh? GoSub() doesn't care what extension you use |
| 18:05.08 | leifmadsen | it isn't Macro() |
| 18:05.16 | leifmadsen | which means it's still just a typo fix |
| 18:06.02 | philipp64 | 15858 see I didn't get that it. it worked in one place but not another, so I figured it was some corner case of how priority matching takes place that was being exposed. |
| 18:06.37 | leifmadsen | It's more likely to be a failed change in many places of the dialplan |
| 18:06.59 | philipp64 | in the included config, the redfish-internal invocations would match, but not the redfish-pstn ones. |
| 18:07.58 | philipp64 | the other reason for filing two bugs was, I figured the s-XXXX => stdexten-XXXX cleanup would be quick (it's trivial and the patch was already attached)... so that could come out quickly. |
| 18:08.27 | philipp64 | the other issue is more insidious, since it's only reproducible part of the time, and I can't figure out what triggers the defect. |
| 18:09.11 | philipp64 | so I didn't want to hold up the former while waiting for the latter... |
| 18:09.48 | Corydon76-dig | putnopvut: Instead of doing the locking from without, you do the locking from within the FILE * driver |
| 18:09.52 | philipp64 | on another topic: who owns the asterisk-biz mailing list? |
| 18:09.53 | leifmadsen | then the other issue is possible this issue: |
| 18:09.57 | leifmadsen | M15421 |
| 18:09.59 | MuffinMan | [ready for testing] [Asterisk] PBX/pbx_config 0015421: [patch] Serious problem in pattern matching reported by jsmith (Karma: +30.25) https://issues.asterisk.org/view.php?id=15421 |
| 18:10.09 | Corydon76-dig | John Todd owns all mailing lists |
| 18:10.33 | philipp64 | I'm not seeing him... |
| 18:10.41 | leifmadsen | jtodd |
| 18:10.54 | philipp64 | yeah, he's elsewhere. |
| 18:11.00 | leifmadsen | at <company_the_makes_asterisk> dot com |
| 18:11.08 | leifmadsen | errr... that :) |
| 18:11.15 | philipp64 | I keep getting unsubscribed from asterisk-biz... because my spam filters work better than yours. grrrr... |
| 18:11.38 | philipp64 | (no, I meant he's not on this channel right now...) |
| 18:12.06 | philipp64 | regrets that he's as brilliant as he is in his mastery of mimedefang and spamassassin... |
| 18:12.52 | *** join/#asterisk-dev errotan (n=errotan@5403E46D.catv.pool.telekom.hu) |
| 18:13.34 | philipp64 | M15421 -- this can be fixed by generating a Karnaugh map and checking for complete occlusion (overlap), right? |
| 18:14.01 | putnopvut | Corydon76-dig: it doesn't make any sense to me. I get the idea, but the execution in the patch doesn't seem to match that idea. |
| 18:14.44 | philipp64 | no, it doesn't. |
| 18:15.08 | philipp64 | because _N[2]. and _N2. are equivalent. |
| 18:15.23 | Corydon76-dig | putnopvut: sure it does |
| 18:15.44 | Corydon76-dig | putnopvut: When fread is called, the underlying implementation calls SSL_read, right? |
| 18:16.03 | kpfleming | the config parser should turn _N[2]. *into* _N2. |
| 18:16.13 | Corydon76-dig | Or not SSLread, but ssl_read (in tcptls.c) |
| 18:16.16 | putnopvut | Corydon76-dig: not to my knowledge |
| 18:16.24 | Corydon76-dig | putnopvut: Yes, it does |
| 18:16.33 | putnopvut | why in the world would it do that? |
| 18:16.39 | philipp64 | ok, different example: _N[234]. and _N[2-4]. |
| 18:16.51 | Corydon76-dig | putnopvut: see fopencookie() |
| 18:17.00 | putnopvut | Corydon76-dig: which file is that in? |
| 18:17.06 | russellb | yes, the FILE * for a TLS session is using an SSL* session underneath |
| 18:17.11 | russellb | it's not our code |
| 18:17.24 | Corydon76-dig | putnopvut: main/tcptls.c |
| 18:17.41 | Corydon76-dig | putnopvut: so the lock properly occurs within the implementation |
| 18:18.08 | putnopvut | ah, gotcha. But what about if TLS isn't being used? |
| 18:18.49 | Corydon76-dig | putnopvut: Ah, good point. We may need to do a tiny wrapper, so that it works the same way, then |
| 18:19.07 | ebroad | The_Boy_Wonder, i replied to 15854, when you get a chance |
| 18:19.13 | kpfleming | philipp64: it's still my opinion that the parser should normalize patterns to avoid the sorts of problems you are talking about |
| 18:20.17 | philipp64 | kpfleming: why? what would that solve? |
| 18:20.32 | kpfleming | it makes the scoring algorithm consistent |
| 18:20.33 | Corydon76-dig | putnopvut: I wonder, though, if the stdio implementations of fread/fwrite might not already have such a lock, internally |
| 18:20.47 | kpfleming | they do not |
| 18:20.53 | kpfleming | well, wait |
| 18:21.05 | philipp64 | ok, what about _N2. and _N22. ? |
| 18:21.08 | kpfleming | no, i don't think they do |
| 18:21.25 | kpfleming | because i'm pretty sure that a FILE * is not expected to be thread safe on its own |
| 18:21.39 | kpfleming | philipp64: sorry, i got into this discussion late, i misunderstood the problem you were talking about |
| 18:21.49 | jsmith | philipp64: _N2. and _N22. are *not* equivalent |
| 18:22.05 | philipp64 | no, they're not. but one occludes the other. |
| 18:22.25 | kpfleming | but in any case where there are multiple ways to express the same thing, a *proper* version should be chosen, and all incoming patterns should be normalized to that version |
| 18:22.42 | kpfleming | no, actually i don't think that's true |
| 18:22.55 | philipp64 | doing a karnaugh map would help you figure out if they are partial occlusion, superset occlusion, exact occlusion (i.e. equivalent), etc. |
| 18:22.58 | kpfleming | if you have those patterns, and the incoming string is 122, then _N22. should match |
| 18:23.09 | kpfleming | if the incoming string is 123, then _N2. should match |
| 18:23.12 | jsmith | Nope... the "." must match a character |
| 18:23.18 | kpfleming | oh right |
| 18:23.25 | kpfleming | add a '4' to the end of my examples then |
| 18:23.32 | jsmith | is happy to give a refresher course on pattern matching |
| 18:23.45 | philipp64 | shouldn't they match in order? or is it "greediest match first"? |
| 18:23.45 | kpfleming | _N22. is a better match for '1234' than _N2. is |
| 18:23.53 | jsmith | When more than one pattern matches, the following rules come into play: |
| 18:24.01 | jsmith | 1) go from left to right, digit by digit |
| 18:24.21 | jsmith | 2) For a given digit, the *most constrained* match gets priority |
| 18:24.35 | jsmith | 3) In the case of a tie, ASCII sort order wins |
| 18:24.45 | jsmith | 4) Move on the next digit to try to eliminate potential matches |
| 18:24.52 | philipp64 | that means you have to match all extensions in a given context! |
| 18:25.04 | jsmith | So if you dial 1234 and have _N2. and _N23.... |
| 18:25.18 | jsmith | We look at the first digit... and it matches for both patterns |
| 18:25.24 | jsmith | And there's a tie |
| 18:25.32 | jsmith | So we go on to the second digit... still a tie |
| 18:25.59 | philipp64 | argh. a karnaugh representation would tell you, for each digit, which extensions you need to try. |
| 18:26.03 | jsmith | So we go on to the third digit... the "." matches anything, while the "3" only matches on possible digit, so we give priority to the _N23. pattern |
| 18:26.10 | kpfleming | philipp64: you are confusing the matching rules and the implementation |
| 18:26.23 | kpfleming | the patterns are already sorted in memory so that we know which parts of the list to check |
| 18:26.27 | philipp64 | it's like Patricia in that way... you can figure out in advance what's interesting and what's not. |
| 18:26.50 | kpfleming | we do not check every pattern in the context |
| 18:27.46 | philipp64 | I haven't stared at the source, so I'll take your word for it. |
| 18:28.43 | jsmith | It's essentially an in-memory trie, right? |
| 18:28.47 | kpfleming | yes |
| 18:28.48 | philipp64 | did anyone try the patch in 15421 to see if that resolves the issue in 15857/8? |
| 18:28.57 | jsmith | hasn't had time to try it out |
| 18:29.29 | philipp64 | I'm guessing that not a lot of people use stdexten, or this would have been noticed (and fixed) sooner? |
| 18:30.01 | kpfleming | leifmadsen normally can make time to test stuff like that |
| 18:30.53 | Corydon76-dig | kpfleming: yes, there's an internal lock in libc |
| 18:30.55 | leifmadsen | M14421 |
| 18:30.58 | MuffinMan | [closed] [Asterisk] Channels/chan_sip/Interoperability 0014421: Issue with Initial call setup when Asterisk 1.6.1-rc1 integrated with Microsoft OCS 2007 reported by TheOldSaint (Karma: neutral) https://issues.asterisk.org/view.php?id=14421 |
| 18:31.06 | leifmadsen | M15421 |
| 18:31.09 | MuffinMan | [ready for testing] [Asterisk] PBX/pbx_config 0015421: [patch] Serious problem in pattern matching reported by jsmith (Karma: +30.25) https://issues.asterisk.org/view.php?id=15421 |
| 18:31.13 | philipp64 | on yet another topic... since when did console commands on a slow (serial) console that generate lots of output start timing out? is that something new? |
| 18:31.27 | leifmadsen | philipp64: already assigned to me, but the patch was only put up like...2 hrs ago I think |
| 18:31.49 | leifmadsen | I've been working on going through the 160 New issues in the issue tracker and getting them set correctly |
| 18:31.50 | seanbright | philipp64: yeah, and it's not only on slow consoles either |
| 18:31.56 | philipp64 | oh, yeah, didn't notice the timestamps. |
| 18:32.01 | *** join/#asterisk-dev dlynes (n=daniel@bas5-hamilton14-1242444747.dsl.bell.ca) |
| 18:32.11 | philipp64 | is there a bug for that? |
| 18:33.07 | philipp64 | I run regression tests over a 19200 console, and getting truncated output sort of hamstrings testing.. :-( |
| 18:33.30 | seanbright | i haven't looked |
| 18:33.37 | philipp64 | leifmadsen: 160, huh? yikes. |
| 18:33.42 | seanbright | it's been a minor annoyance to me, not a production issue |
| 18:37.36 | philipp64 | leifmadsen: can you please take M15370 out of "feedback" state? I gave the required feedback... |
| 18:37.55 | philipp64 | seanbright: err... which has? the console issue? |
| 18:37.58 | leifmadsen | philipp64: I will get to it when I review the responses from the 160 issues I've been working on |
| 18:38.07 | tzafrir_laptop | leifmadsen, what's "ready for testing " in https://issues.asterisk.org/view.php?id=15899 ? |
| 18:38.24 | seanbright | philipp64: yes |
| 18:38.31 | leifmadsen | tzafrir_laptop: oops, I read your comment wrong -- I thought that was a one-line fix |
| 18:38.44 | leifmadsen | tzafrir_laptop: appropriate status set now |
| 18:39.31 | philipp64 | ok. I replied 3 weeks ago. I figured they were being handled first-in/first-out. |
| 18:39.55 | leifmadsen | philipp64: it's possible I missed it |
| 18:40.13 | tzafrir_laptop | It basically requires the vars list to be copied rather than copying the pointer. |
| 18:40.45 | leifmadsen | philipp64: additionally, I'm changing my processes a bit this week in order to better control the flow of issues through the tracker |
| 18:40.45 | philipp64 | leifmadsen: consider yourself nudged then... |
| 18:40.56 | philipp64 | how so? |
| 18:41.02 | leifmadsen | more to follow |
| 18:42.23 | philipp64 | well, hopefully issues with an attached fix get a somewhat higher priority... |
| 18:42.35 | philipp64 | (of course, not all attached fixes are good fixes...) |
| 18:43.17 | philipp64 | On M15370... there's no way for me to replace an existing attachment, is there? |
| 18:43.33 | leifmadsen | no, just add a new one |
| 18:43.43 | philipp64 | I can only add new attachments, I can't delete/replace them, can I... not even if I submitted the original attachment. |
| 18:43.45 | philipp64 | sigh. |
| 18:43.56 | leifmadsen | just add a new one, and request the old one deleted by a bug marshal |
| 18:44.36 | philipp64 | is there an email address just for bug marshals, or do they have to be called out individually? |
| 18:44.44 | seanbright | philipp64: which ones do you want deleted? |
| 18:44.49 | seanbright | actually |
| 18:44.51 | seanbright | ask in -bugs |
| 18:45.15 | philipp64 | attachments through #5 for M15370... |
| 18:45.25 | philipp64 | only the latest is useful. |
| 18:47.04 | seanbright | done |
| 18:56.52 | philipp64 | thanks. |
| 18:59.40 | philipp64 | so... someone remind me... the Diversion: support for SIP is in 1.6.3 which isn't out, right? but not in the 1.6.2 beta... |
| 19:00.10 | russellb | RTFSC |
| 19:00.13 | russellb | i mean, yes, 1.6.3 |
| 19:00.52 | philipp64 | "the source is the manual"... got it. |
| 19:01.02 | philipp64 | where have I heard that before? |
| 19:01.04 | russellb | or the CHANGES file :-) |
| 19:01.22 | philipp64 | how far out is 1.6.3? |
| 19:01.53 | russellb | Q4/Q1 timeframe. |
| 19:02.26 | seanbright | kpfleming: re: configure check for soundcard.h... |
| 19:03.01 | seanbright | you're really talking abouut the difference between #if defined(__FreeBSD__) and #if SOUNDCARD_H_IN_SYS, aren't you? |
| 19:03.16 | seanbright | (or whatever the define ends up being) |
| 19:03.53 | kpfleming | something like that, yes |
| 19:04.17 | kpfleming | because then if there are other platforms that have sys/soundcard.h, they just magically work |
| 19:04.32 | seanbright | ah. i see. |
| 19:09.46 | seanbright | actually in that case you can just use sys/soundcard.h across the board i think |
| 19:10.00 | seanbright | my install has a sys/soundcard.h which includes linux/soundcard.h |
| 19:13.47 | kpfleming | well, then |
| 19:13.48 | kpfleming | yay |
| 19:14.14 | The_Boy_Wonder | ebroad: responded to 15854. |
| 19:14.21 | ebroad | ok |
| 19:23.55 | tzafrir_laptop | I'm looking at chan_skinny.c . There's a global array 'ourhost' , but I don't see where it is set |
| 19:24.22 | tzafrir_laptop | ah, ok: gethostname |
| 19:24.41 | ebroad | The_Boy_Wonder, wrote back |
| 19:24.51 | ebroad | you are correct about !value |
| 19:25.01 | ebroad | i tested it out |
| 19:25.24 | The_Boy_Wonder | ebroad: okay, good. also, i just committed the upward bound checking for the port num in port_str2int |
| 19:25.30 | ebroad | sweet |
| 19:25.33 | The_Boy_Wonder | i'm merging it into all the 1.6 branches |
| 19:26.21 | ebroad | ill update the patch in 15880 |
| 19:26.46 | ebroad | see my note re ast_sip_ouraddrfor() |
| 19:26.56 | The_Boy_Wonder | i didn't change the %30d part though... it seems like it may be possible/valid for someone in sip.conf to lead a port number with 0's for some reason |
| 19:27.42 | ebroad | why |
| 19:28.14 | ebroad | then port >= 1 && port <= 65535 will fail |
| 19:28.23 | ebroad | actually |
| 19:28.24 | ebroad | nvm |
| 19:28.29 | ebroad | itll still work |
| 19:28.37 | The_Boy_Wonder | 000000000005060 should still be 5060 i guess |
| 19:28.42 | ebroad | but we might get an integer overflow |
| 19:28.55 | ebroad | right, but 30 digits!? |
| 19:29.07 | The_Boy_Wonder | just a guess, i saw it other places in the code |
| 19:29.19 | The_Boy_Wonder | it should at least have a limit of some sort for stack overflow |
| 19:29.32 | ebroad | correct me if i am wrong the %30d was a fix for various DoS issues |
| 19:29.45 | ebroad | to keep sscanf from globbing forever |
| 19:29.51 | The_Boy_Wonder | right |
| 19:30.02 | ebroad | i guess some padding is ok |
| 19:30.12 | ebroad | but 30 seems over the top to me |
| 19:30.32 | The_Boy_Wonder | i don't think it will hurt, whether it is necessary or not is something else |
| 19:30.37 | ebroad | true |
| 19:31.17 | Corydon76-dig | tzafrir_laptop: re 15017 |
| 19:32.17 | Corydon76-dig | tzafrir_laptop: it's clear from the message that the function is there; you just don't have the right header file. You need to find out which HEADER FILE the functions are in, Without the HEADER FILE, reopening the issue isn't helping. |
| 19:35.34 | The_Boy_Wonder | ebroad: i read your comment on the issue, i don't have an answer right now. unfortunately i don't have time to investigate this any further at the moment :/ |
| 19:35.43 | ebroad | np |
| 19:36.26 | ebroad | The_Boy_Wonder, i did some limited testing on my end and it seems to work fine, then again i am doing most of my testing through nat(im at work, * box is at home) |
| 19:37.32 | ebroad | The_Boy_Wonder, i studied the contact code when i was looking it 15880 |
| 19:38.56 | ebroad | The_Boy_Wonder, my problem was that the wrong port was getting tacked on to the contact header when using TLS, by modifying us->sin_port per transport, it all worked |
| 19:40.07 | The_Boy_Wonder | ebroad, have you uploaded that patch? |
| 19:40.14 | The_Boy_Wonder | that you are testing? |
| 19:40.17 | ebroad | M15880 |
| 19:40.20 | MuffinMan | [new] [Asterisk] Channels/chan_sip/TCP-TLS 0015880: [patch] Contact header port ignores transport when using externip reported by ebroad (Karma: neutral) https://issues.asterisk.org/view.php?id=15880 |
| 19:53.12 | The_Boy_Wonder | I need to test transfers with SIP and the replaces header. does anyone know of a phone or softphone that uses the replaces header i can use to test this.... or any other way i can test this |
| 19:58.01 | ebroad | Counterpath's Bria supports replace |
| 19:59.17 | The_Boy_Wonder | ebroad: what about x-lite or eyeBeam? |
| 19:59.24 | ebroad | haven't tested then |
| 19:59.26 | ebroad | 3cx might |
| 19:59.30 | ebroad | ill test you right now |
| 19:59.31 | ebroad | 1 sec |
| 19:59.37 | The_Boy_Wonder | awesome |
| 20:00.16 | ebroad | yup 3cx supports it |
| 20:00.20 | ebroad | Supported: replaces |
| 20:00.27 | ebroad | confirmed with wireshark |
| 20:00.48 | ebroad | fyi, tls is broken in their softphone |
| 20:00.48 | *** join/#asterisk-dev snuff-home (n=snuffy@203-219-29-182-bri-ts6-2600.tpgi.com.au) |
| 20:00.48 | *** mode/#asterisk-dev [+o snuff-home] by ChanServ |
| 20:01.00 | ebroad | but tcp and udp work fine |
| 20:01.02 | The_Boy_Wonder | grrrr, its just for windows |
| 20:01.10 | ebroad | uhg |
| 20:01.13 | The_Boy_Wonder | i wonder if wine will run it |
| 20:01.18 | ebroad | i would test |
| 20:01.28 | ebroad | but im running slack x86_64 |
| 20:01.33 | ebroad | no wine :( |
| 20:01.53 | ebroad | how about qutecom |
| 20:02.44 | The_Boy_Wonder | i'll mess around and see if I can't get one of these to work |
| 20:02.51 | ebroad | whos marshalling |
| 20:03.41 | russellb | The_Boy_Wonder: you could try xlite, which runs on linux |
| 20:04.13 | The_Boy_Wonder | russellb: right, i was going to do that first, then give qutecom a try with wine if i needed to |
| 20:04.59 | ebroad | or technet subscription -> vmware server -> windoze ;) |
| 20:07.17 | seanbright | kpfleming: i was going to look at the DAHDI_LOADZONE issue too, but i am not that comfortable with the driver side of things. |
| 20:08.24 | kpfleming | ok |
| 20:08.39 | kpfleming | it's not terribly difficult, actually |
| 20:09.08 | seanbright | i didn't know what you were referring to in your email about the "compatibility mechanism" |
| 20:09.31 | Qwell | seanbright: some of the ioctl's have a _V2 version. That. |
| 20:09.39 | seanbright | ahh |
| 20:10.51 | leifmadsen | so I'm trying to use post-review, but I'm getting an error that says, "The repository path specified is not in the list of known repositories" |
| 20:11.21 | leifmadsen | I'm not sure what it is expecting. This is against trunk. |
| 20:12.12 | seanbright | svn pg reviewboard:url |
| 20:12.19 | seanbright | (in the root of trunk) |
| 20:12.32 | leifmadsen | https://reviewboard.asterisk.org |
| 20:12.46 | seanbright | hmm |
| 20:12.54 | seanbright | what command are you running? |
| 20:13.06 | leifmadsen | just running 'post-review -d' |
| 20:13.12 | leifmadsen | it asked for login and such |
| 20:14.19 | seanbright | strange |
| 20:14.38 | leifmadsen | does this have to be run against an origsvn checkout? |
| 20:14.48 | seanbright | worked just fine for me |
| 20:14.55 | seanbright | mayhaps |
| 20:15.37 | kpfleming | yes, it has to be run on an origsvn checkout |
| 20:15.46 | leifmadsen | ah ok, that explains it |
| 20:16.46 | leifmadsen | and now it works :) |
| 20:17.57 | seanbright | Qwell: i don't see _V2 ioctls |
| 20:18.37 | Qwell | I don't know if that's what they're actually called (I thought it was though..) |
| 20:19.30 | seanbright | i do see _V1 |
| 20:19.43 | Qwell | maybe that's it. Old ones were moved to _V1 for ABI |
| 20:20.22 | kpfleming | correct |
| 20:20.50 | Qwell | hrm, is DAHDI_SETCONF_V1 correct? |
| 20:20.53 | Qwell | I don't think it is |
| 20:21.38 | Qwell | I think the 2nd arg to _IOW should be 13... |
| 20:21.47 | kpfleming | it appears to be |
| 20:21.51 | kpfleming | no |
| 20:22.08 | kpfleming | the old ioctl had two problems |
| 20:22.24 | kpfleming | it was supposed to be WR, and both SET and GET were the same ioctl number, which is not ideal |
| 20:22.37 | kpfleming | when they moved to WR, they had to be different numbers anyway |
| 20:22.45 | Qwell | ahh |
| 20:28.52 | *** join/#asterisk-dev moy (n=moy@mail.e-contact.cl) |
| 20:29.51 | seanbright | i don't get it though, because DAHDI_LOADZONE takes a struct *, not a bare int. |
| 20:32.54 | seanbright | so on linux a dahdi_tone_def_header * is being passed, and on freebsd a dahdi_tone_def_header ** is being passed |
| 20:35.34 | kpfleming | oh |
| 20:35.41 | kpfleming | that's different then, but i see no reason for them to be passing a ** |
| 20:36.02 | kpfleming | so someone will have to explain why it was changed |
| 20:36.21 | seanbright | The third argument to ioctl() is traditionally named char *argp. Most |
| 20:36.21 | seanbright | uses of ioctl() in FreeBSD 3.0, however, require the third argument to be |
| 20:36.21 | seanbright | a caddr_t or an int. |
| 20:36.39 | seanbright | maybe it just needs a cast |
| 20:36.42 | seanbright | shrugs |
| 20:38.43 | *** join/#asterisk-dev hugorebelo (n=hugorebe@200-171-132-124.completo.com.br) |
| 20:39.58 | seanbright | and can someone make me an autoconf repository so i can centralize the autoconf stuff? |
| 20:40.02 | seanbright | :) |
| 20:40.04 | seanbright | kthx |
| 20:45.36 | *** join/#asterisk-dev ctooley (n=ctooley@c-76-22-246-7.hsd1.tn.comcast.net) |
| 20:45.36 | *** mode/#asterisk-dev [+o ctooley] by ChanServ |
| 20:58.32 | Kobaz | how do you get a bracktrace in a core with all the asterisk thread stacks |
| 20:58.54 | putnopvut | Kobaz: from gdb "thread apply all bt" |
| 20:59.00 | Kobaz | k |
| 20:59.03 | putnopvut | or "thread apply all bt full" for lots and lots of info |
| 21:09.02 | Qwell | or doc/backtraces.txt as you were pointed to this morning ;) |
| 21:09.23 | Qwell | -s though |
| 21:10.59 | ebroad | ouch, 4.6k/s when downloading sounds |
| 21:24.25 | *** join/#asterisk-dev Marquis42 (n=bfhbmw0@65-127-126-34.dia.static.qwest.net) |
| 21:36.07 | *** join/#asterisk-dev malcolmd (n=malcolmd@pdpc/sponsor/digium/malcolmd) |
| 21:36.07 | *** mode/#asterisk-dev [+o malcolmd] by ChanServ |
| 21:39.33 | *** join/#asterisk-dev tzafrir_laptop (n=tzafrir@212.179.75.202) |
| 21:39.33 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 21:42.07 | *** join/#asterisk-dev Grof (n=krash@78-0-254-251.adsl.net.t-com.hr) |
| 22:03.10 | *** join/#asterisk-dev ctooley (n=ctooley@c-76-22-246-7.hsd1.tn.comcast.net) |
| 22:03.10 | *** mode/#asterisk-dev [+o ctooley] by ChanServ |
| 22:20.37 | *** join/#asterisk-dev anthm (n=anthm@freeswitch/developer/anthm) |
| 23:25.12 | *** join/#asterisk-dev ctooley (n=ctooley@c-76-22-246-7.hsd1.tn.comcast.net) |
| 23:25.12 | *** mode/#asterisk-dev [+o ctooley] by ChanServ |
| 23:47.21 | *** join/#asterisk-dev Iamnacho (i=Iamnacho@ip98-186-180-143.ks.ks.cox.net) |
| 23:54.32 | *** join/#asterisk-dev tzafrir_laptop (n=tzafrir@212.179.75.202) |
| 23:54.32 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 23:55.02 | tzafrir_laptop | Corydon76-dig, __NO_LONG_DOUBLE_MATH is defined in armel and not in amd64 |
| 23:55.28 | tzafrir_laptop | in /usr/include/bits/mathdef.h . glibc-2.7 |