| 00:17.52 | *** part/#asterisk-dev Deeewayne (n=Deeewayn@nat/digium/x-5d265ee7041eddd5) |
| 00:53.13 | *** join/#asterisk-dev anthm (n=anthm@freeswitch/developer/anthm) |
| 02:23.07 | *** join/#asterisk-dev jtodd (n=jtodd@blob.fox-den.com) |
| 03:13.58 | *** join/#asterisk-dev moy (n=moy@189.169.60.228) |
| 06:47.59 | *** join/#asterisk-dev denon (i=denon@synapse.subneural.net) |
| 06:48.37 | *** join/#asterisk-dev denon (i=denon@synapse.subneural.net) |
| 08:25.08 | *** join/#asterisk-dev oej (n=olle@ns.webway.se) |
| 08:25.08 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 08:54.29 | *** join/#asterisk-dev oej (n=olle@ns.webway.se) |
| 08:54.29 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 09:49.17 | *** join/#asterisk-dev sergee (n=serg@voip1.west-call.com) |
| 09:54.21 | *** join/#asterisk-dev vazir (i=anton@82.198.22.27) |
| 10:53.35 | *** join/#asterisk-dev vazir (i=anton@82.198.22.27) |
| 11:13.33 | *** join/#asterisk-dev caio1982 (i=caio1982@CAcert-br/caio1982) |
| 11:15.51 | *** join/#asterisk-dev bartpbx (n=bartpbx@217.24.210.202) |
| 11:15.55 | bartpbx | hello |
| 11:16.49 | *** join/#asterisk-dev eliel (n=eliel@200.61.172.61) |
| 11:16.49 | *** mode/#asterisk-dev [+o eliel] by ChanServ |
| 11:17.56 | tzafrir_laptop | hi |
| 11:19.17 | *** join/#asterisk-dev kamanashisroy (n=kamanash@119.30.34.7) |
| 11:30.48 | *** join/#asterisk-dev mbranca (n=matteo@93-62-230-243.ip24.fastwebnet.it) |
| 11:37.58 | bartpbx | i just filed a new bug report ( 13919) to the bugtracker |
| 11:42.55 | *** join/#asterisk-dev seanbright (n=sean@asterisk/contributor-and-bug-marshal/seanbright) |
| 11:42.55 | *** mode/#asterisk-dev [+o seanbright] by ChanServ |
| 11:51.46 | eliel | bartpbx: I just upload a candidate patch for that issue... |
| 12:10.03 | bartpbx | eliel: thanks for you quick response |
| 12:10.12 | bartpbx | i just applied the patch |
| 12:10.24 | bartpbx | <PROTECTED> |
| 12:11.27 | eliel | ok, no problem, report your test results in the bug tracker |
| 12:47.11 | oej | M13919 |
| 12:47.13 | MuffinMan | [ready for testing] [Asterisk] Channels/chan_iax2 0013919: [patch] Asterisk core dumps random reported by barthpbx (Karma: +1.00) http://bugs.digium.com/view.php?id=13919 |
| 13:43.48 | jsmith | Morning all... |
| 13:47.59 | eliel | good morning |
| 13:56.25 | *** join/#asterisk-dev shido6 (n=shido6@209.114.208.111) |
| 14:00.05 | *** join/#asterisk-dev lmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 14:00.05 | *** mode/#asterisk-dev [+o lmadsen] by ChanServ |
| 14:14.33 | *** part/#asterisk-dev bartpbx (n=bartpbx@217.24.210.202) |
| 14:39.48 | *** join/#asterisk-dev codefreeze-lap (n=murf@72.21.67.40) |
| 14:39.48 | *** mode/#asterisk-dev [+o codefreeze-lap] by ChanServ |
| 14:42.53 | *** join/#asterisk-dev mbranca (n=matteo@93-62-230-243.ip24.fastwebnet.it) |
| 15:05.04 | *** join/#asterisk-dev nicox (n=nicox@dsl-82-106.utaonline.at) |
| 15:05.40 | nicox | hi |
| 15:06.55 | nicox | i'm searching for a solution of a problem, is anyone open to help out a little bit? |
| 15:07.11 | lmadsen | nicox: see #asterisk |
| 15:09.05 | *** join/#asterisk-dev sruffell (n=sruffell@adsl-074-185-078-025.sip.bhm.bellsouth.net) |
| 15:09.05 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 15:09.48 | *** join/#asterisk-dev anthm (n=anthm@freeswitch/developer/anthm) |
| 15:11.25 | nicox | there is no configuration problem: i have some asterisk-boxes which speaks IAX between them and some of the calls are rejected, but there is no reason (no authority found) because other calls of the same type are working well |
| 15:12.09 | smurf | Quick question: how do I trace the layer-3 messages on a PRI line? |
| 15:15.03 | jsmith | smurf: "pri debug span 1" |
| 15:15.12 | jsmith | smurf: (or whichever span you're interested in) |
| 15:15.26 | jsmith | smurf: You can also turn on layer-2 debugging with "intense debug" |
| 15:17.28 | smurf | jsmith: ah. Thanks |
| 15:18.15 | jsmith | smurf: No worries... (as a matter of courtesy, mind asking in #asterisk next time? This channel is for questions about the Asterisk code itself. Thanks!) |
| 15:18.24 | smurf | NP |
| 15:23.22 | *** join/#asterisk-dev jameswf (n=james@dsl093-157-131.phx1.dsl.speakeasy.net) |
| 15:27.46 | nicox | what can i do for helping debug asterisk ( at this time no programming-experience)? |
| 15:28.17 | lmadsen | as jsmith mentioned above, your discussion is better suited to #asterisk |
| 15:28.36 | lmadsen | plus it looks like there are no devs here |
| 15:29.02 | nicox | i made a bug report which is ignored now for more then a month, how the hell can help asterisk-user with this ? |
| 15:29.28 | lmadsen | you haven't even mentioned the bug number |
| 15:29.37 | lmadsen | we're not psychic |
| 15:31.04 | seanbright | is psychic |
| 15:31.21 | seanbright | and lmadsen has a dirty mind |
| 15:31.28 | nicox | <PROTECTED> |
| 15:31.35 | seanbright | M13468 |
| 15:31.36 | lmadsen | seanbright: you don't need to be psychic to know that |
| 15:31.50 | lmadsen | the muffinman is dead! |
| 15:31.52 | lmadsen | file: ^^^ |
| 15:31.55 | seanbright | sniffle |
| 15:32.07 | file | oh, right, he died when the maintenance guy poked the wrong breaker |
| 15:32.21 | lmadsen | oops |
| 15:32.27 | *** join/#asterisk-dev MuffinMan (n=muffinma@asterisk/issue-tracker-bot/muffinman) |
| 15:32.34 | seanbright | MuffinMan: welcome back |
| 15:34.39 | *** join/#asterisk-dev korihor (n=korihor@201.210.239.172) |
| 15:36.54 | nicox | sorry for disturb you guys, i will try my luck at asterisk-bugs |
| 15:37.00 | nicox | have a nice day |
| 15:37.02 | *** part/#asterisk-dev nicox (n=nicox@dsl-82-106.utaonline.at) |
| 15:39.58 | *** join/#asterisk-dev mog (n=mog@nat/digium/x-71d11feb5c78c174) |
| 15:39.58 | *** mode/#asterisk-dev [+o mog] by ChanServ |
| 15:41.50 | *** join/#asterisk-dev IsUp (n=nocturne@unaffiliated/isup) |
| 15:44.56 | *** join/#asterisk-dev dbailey (n=doug@nat/digium/x-d7497a3b313efcd5) |
| 15:46.57 | *** join/#asterisk-dev Karlitoo (n=proscom@213.137.110.67) |
| 15:47.08 | *** part/#asterisk-dev Karlitoo (n=proscom@213.137.110.67) |
| 15:51.45 | *** join/#asterisk-dev Deeewayne (n=Deeewayn@nat/digium/x-5d265ee7041eddd5) |
| 15:51.45 | *** mode/#asterisk-dev [+o Deeewayne] by ChanServ |
| 16:01.14 | Damin | Hmm.. |
| 16:01.50 | Juggie | Hmmmmm |
| 16:03.32 | *** join/#asterisk-dev Marquis42 (n=bfhbmw0@65-127-126-34.dia.static.qwest.net) |
| 16:18.09 | *** join/#asterisk-dev anonymouz666 (n=anonymou@201.19.199.65) |
| 16:19.27 | *** join/#asterisk-dev putnopvut (n=putnopvu@nat/digium/x-d91de4d1a36c624c) |
| 16:19.27 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 16:20.47 | anonymouz666 | to add a custom header in 200 OK (answer) could I add a function similar try_suggested_sip_codec inside sip_answer()? |
| 16:22.12 | anonymouz666 | sometimes SipAddHeader isn't enough... because in initial INVITE I still don't have the value to add the header. |
| 16:22.42 | putnopvut | anonymouz666: you can use the add_header() function inside of sip_answer() to add your own header if you would like. |
| 16:23.36 | anonymouz666 | yes... my idea is.... use pbx_builtin_getvar_helper to get the var that the channel driver will set and after add_header() inside sip_answer() |
| 16:26.30 | anonymouz666 | but I have a question... answerinfo = pbx_builtin_getvar_helper(...) |
| 16:26.42 | anonymouz666 | I need to return if(!answerinfo) |
| 16:26.54 | anonymouz666 | I wonder how this will look like inside sip_answer |
| 16:30.03 | putnopvut | You can test the value of answerinfo using ast_strlen_zero. |
| 16:30.11 | putnopvut | I'm not sure what else you're asking about here. |
| 16:43.54 | moy | Qwell: I understand the decision of no support for g729 in trunk, but, is it too hard to just get it to compile with trunk? some people want to test my branch to provide feedback but that is holding them |
| 16:47.22 | Qwell | but then how often do we rebuild it? Seems very silly to spend a couple hours every week building it, publishing it, etc, etc... |
| 16:48.07 | Juggie | would it be that hard to create a private branch of trunk w/ the g729 code? |
| 16:48.26 | Juggie | and have it auto compile once a week or whatever |
| 16:49.03 | Qwell | if it compiled without us needing to touch it, we wouldn't need to rebuild it every week :D |
| 16:49.15 | moy | or at least do it once a month, does not sound like a titanic job (I myself would do it if allowed to), it has been more than a month since that guy tried to use it |
| 16:49.32 | Qwell | however, having said that |
| 16:49.41 | Qwell | there's no reason the 1.6.1 version wouldn't work |
| 16:49.51 | Qwell | (probably..) |
| 16:50.13 | moy | I think the problem was ast_verbose move from function to macro |
| 16:50.22 | moy | among other things probably |
| 16:50.30 | moy | but that was the load error anyway |
| 16:51.39 | kpfleming | that's bad |
| 16:52.09 | kpfleming | if we make ABI/API changes between 1.6.x releases, then we'll have to build new g729 modules for them |
| 16:59.27 | moy | which I think is exactly what happened just now, in 1.6.0 ast_verbose is a function but in current trunk is a macro |
| 16:59.39 | kpfleming | that is bad |
| 16:59.45 | *** join/#asterisk-dev CunningPike (n=arodgers@204.239.8.157) |
| 16:59.50 | kpfleming | is it still called ast_verbose? |
| 16:59.59 | kpfleming | otherwise that is an API change, which is a no-no as well |
| 17:00.43 | moy | yeah, the macro is exactly called ast_verbose just changed to be defined as #define ast_verbose __ast_verbose... |
| 17:03.11 | kpfleming | ok, so source code compatibility is preserved, but binary is not |
| 17:03.14 | Corydon76-dig | sounds like a candidate for AST_INLINE_API |
| 17:03.39 | kpfleming | different issue |
| 17:05.09 | Corydon76-dig | I just meant that it could be redefined as a function that is an AST_INLINE_API that just calls __ast_verbose |
| 17:05.36 | Corydon76-dig | That saves the stack frame inside Asterisk, but also allows ABI compatibility |
| 17:06.09 | kpfleming | well, as long as it accepts the same arguments |
| 17:06.18 | kpfleming | if it does, then we need to look at why the macro exists at all |
| 17:09.53 | Corydon76-dig | Ah, I see. It's to preserve the va_args as such |
| 17:10.30 | Corydon76-dig | Well, I can fix that with an ast_verbose_ap API call |
| 17:16.04 | *** join/#asterisk-dev outtolunc (n=me@adsl-66-218-53-172.dslextreme.com) |
| 17:20.15 | Damin | Can anyone tell me if this patch will actually work? http://pastebin.com/m62601676 |
| 17:20.31 | Damin | It's a simple patch to output Congestion / Channel information for 1.2's app_dial.c |
| 17:21.09 | Damin | The idea being if we get congestion, we want to log the channel it occurred on so that we can post-parse logs and do some traffic analysis.. |
| 17:21.38 | Damin | I'm sure it's not the most elegant solution, but it will provide the basic information we need.. |
| 17:21.45 | Corydon76-dig | Damin: It's not safe |
| 17:21.58 | Damin | Unless I'm missing something about congestion reporting that makes it a non-issue? |
| 17:22.03 | Corydon76-dig | Damin: you need to check if the channel is still in the list and have it locked |
| 17:22.29 | Damin | Yuck.. |
| 17:22.40 | Corydon76-dig | If the channel structure isn't locked, you cannot safely access any of its elements |
| 17:23.25 | Damin | Is there some way to pull the information into a variable at an earlier stage in the dial where the list actually is locked? |
| 17:25.36 | moy | so, ast_verbose will be converted to AST_INLINE_API? to preserve binary compat? |
| 17:29.29 | anonymouz666 | WARNING[27747]: chan_sip.c:5643 add_header: Out of space, can't add anymore (X-Answer:304)... the var:value is correct... where I am making mistakes here? |
| 17:32.04 | eliel | anonymouz666: trunk? |
| 17:32.10 | eliel | I think there is a bug in chan_sip |
| 17:32.21 | eliel | we are doing a sizeof(char *) |
| 17:33.11 | Corydon76-dig | moy: I'll look at it |
| 17:33.27 | Damin | Hmm.. |
| 17:33.29 | moy | thanks a lot, that would make my day |
| 17:34.07 | anonymouz666 | eliel: nops.. that's a specific piece of code that I am adding to sip_answer to add a custom SIP header in the 200 OK to INVITE. |
| 17:34.17 | anonymouz666 | 'cause only at that moment I have the value I want |
| 17:34.28 | eliel | anonymouz666: the bug is in add_line |
| 17:34.41 | eliel | I will submit a patch for that... |
| 17:35.25 | anonymouz666 | eliel: could you please explain? the debug says that the print is coming from add_header() |
| 17:35.53 | Damin | Let me see if I understand this process.. |
| 17:37.06 | Damin | The first thing it does is try to find an open channel.. |
| 17:37.34 | eliel | anonymouz666: are you using trunk? |
| 17:37.49 | anonymouz666 | eliel: no, sorry. it is latest 1.4. |
| 17:38.18 | Damin | If it find one, it proceeds.. otherwise it drops out w/ congestion.. |
| 17:40.21 | kpfleming | Corydon76-dig: can you get on jabber? |
| 17:41.49 | eliel | anonymouz666: What is the length of the headers you are adding? |
| 17:42.02 | eliel | anonymouz666: the max packet size is 4096 |
| 17:42.15 | anonymouz666 | X-Answer:304 (header:value) |
| 17:42.37 | anonymouz666 | let me print the MAXLEN |
| 17:45.03 | Damin | The more I look at this, the more it makes no sense.. |
| 17:45.49 | anonymouz666 | WARNING[28459]: chan_sip.c:5641 add_header: MAXLEN: -24367 |
| 17:46.04 | anonymouz666 | that's bizarre |
| 17:46.46 | anonymouz666 | if (maxlen <= 0) { ... } so this condition is true in add_header() |
| 17:47.47 | Damin | The more I think about this, the more it makes sense that this won't work. |
| 17:48.01 | Damin | o->chan->name doesn't exist because the channel couldn't be setup.. |
| 17:48.11 | Damin | So the patch is stupid.. for many reasons.. |
| 17:50.01 | *** join/#asterisk-dev dioedu (n=dioedu@201.7.117.114) |
| 17:50.23 | anonymouz666 | eliel: do you have any comment on this? |
| 17:52.35 | codefreeze-lap | awk_r: looks like the patch solves 13420? should I commit/close? Or are there other issues? |
| 17:52.53 | eliel | anonymouz666: no at the moment... that looks strange, i need more time.. |
| 17:54.07 | awk_r | codefreeze-lap, si! commit and close! |
| 17:54.40 | codefreeze-lap | awk_r: OK |
| 18:42.35 | anonymouz666 | hmmm it seems add_header() does not work if we already added the body content |
| 19:08.46 | anonymouz666 | ok, mission accomplished. the header was added. :) |
| 19:17.02 | *** join/#asterisk-dev Deeewayne (n=Deeewayn@nat/digium/x-547c915ba480e7ce) |
| 19:17.02 | *** mode/#asterisk-dev [+o Deeewayne] by ChanServ |
| 20:12.07 | Damin | Is there any way in Zaptel to get debugging information that would show you how many channels are in what state.. |
| 20:13.20 | bearded_blitz | Damin: how about 'core show channels verbose" ? |
| 20:13.22 | Damin | I'm trying to get an idea for what the state of Zaptel is at the time a call comes through.. The traffic reports from the switch on the other side do not indicate a full PRI when we are getting congestion messages.. so I'm wondering if Zaptel is "wrapping up" calls,... |
| 20:13.24 | bearded_blitz | does that give you what you need? |
| 20:13.55 | Damin | bearded_blitz: Nope.. this is 1.2. :) |
| 20:14.01 | bearded_blitz | ouch |
| 20:15.27 | Damin | bearded_blitz: It does provide me some information that is usfeul, but it also locks the channel list when you query it.. |
| 20:19.11 | snuff-home | only advice i have.. use zaptel / pri debug |
| 20:20.46 | *** join/#asterisk-dev X-Rob (n=Rob@ppp214-210.static.internode.on.net) |
| 20:22.10 | Damin | I guess what I'm looking for, short of debug messages in the actual code, is a nice little CLI app like "zttool" that shows you the status of all of the PRI B channels in real-time and does some "use counts" |
| 20:26.46 | *** join/#asterisk-dev shazaum (n=shazaum@unaffiliated/shazaum) |
| 20:27.57 | jsmith | Damin: You and me both :-) |
| 20:28.11 | jsmith | Damin: Use counts are easy, given the GROUP() and GROUP_COUNT() dialplan functions |
| 20:28.23 | jsmith | Damin: But actual channel status? That's harder |
| 20:36.01 | Qwell | M13667 |
| 20:36.03 | MuffinMan | [confirmed] [Asterisk] General 0013667: [patch] Asterisk init script for archlinux and patch for MakeFile reported by sherif (Karma: neutral) http://bugs.digium.com/view.php?id=13667 |
| 20:36.05 | Qwell | Do we really want to maintain that? |
| 20:37.26 | Damin | jsmith: What I'm trying to debug here is that there seems to be a disconnect between the number of channels in use at the Switch and the numbers of channels that Zaptel thinks are available on that span for bringing up new calls.. |
| 20:37.45 | jsmith | Damin: Oh? |
| 20:38.02 | Qwell | I may go ahead and close that with a "thanks for your contribution, but...". Thoughts? |
| 20:38.06 | Damin | jsmith: And I cannot, for the life of me, figure out how to get accurate information out of Asterisk in real time that doesn't cause potential performance / locking issues.. |
| 20:38.22 | jpeeler | Qwell: do we really maintain stuff in the contrib directory? |
| 20:38.26 | jsmith | Damin: Have you tried using GROUP and GROUP_COUNT? |
| 20:38.29 | Qwell | jpeeler: to some extent |
| 20:38.38 | Qwell | and we get bug reports about stuff in there, so... |
| 20:38.45 | jpeeler | hrm |
| 20:38.48 | X-Rob | ping, Qwell -- http://bugs.digium.com/view.php?id=13786 - should that be seperated into two bugs? I am tempted to think that the answer is 'yes' |
| 20:39.01 | Damin | jsmith: Not yet.. I'm trying to look at a deeper layer rather than adding a second level of "State machine" and counters to the mix.. |
| 20:39.25 | Damin | jsmith: There are so many potential places where groups can get messed up in our routing configuration.. |
| 20:39.26 | Qwell | Damin: How about you? Any thoughts on the above? I know you've updated the RH init scripts a time or two.. |
| 20:39.48 | Damin | Qwell: My thougts are.. "what the hell is archlinux?" |
| 20:39.55 | Qwell | yeah, exactly.. |
| 20:40.28 | Damin | Qwell: As long as it is in the contrib directory and is expressley noted as "contributed, but not supported" I don't have a problem with it being in there.. |
| 20:40.30 | Qwell | next we'll be getting scripts for Puppy, Sorcerer, ClarkConnect, ... |
| 20:41.16 | Damin | Qwell: At least if it is in the contrib directory, other people CAN contribute fixes if neccessary, but you can always tag them as low priority and not focus on them.. |
| 20:41.50 | Qwell | then the bugs sit there forever |
| 20:42.10 | Qwell | X-Rob: dunno |
| 20:43.06 | X-Rob | Qwell, I'm tempted just to create a new one and let Someone Else(tm) complain that it's a dupe. But there's definately brokenness with the latest 1.4 builds. |
| 20:44.11 | Damin | Qwell: Nature of the beast.. do you want a clean bug tracker? Or more functionality.. :) |
| 20:45.11 | Damin | Qwell: One thought I have is to make an add-on package that is "asterisk-users-contrib" or some such nonsense and let it be completely community driven.. I.E. don't even worry about it.. let the community update/release if if they care to.. |
| 20:45.25 | *** join/#asterisk-dev ctooley (n=ctooley@doc-24-32-196-69.concordia.ks.cebridge.net) |
| 20:45.25 | *** mode/#asterisk-dev [+o ctooley] by ChanServ |
| 20:45.54 | Damin | Qwell: I don't know.. There are so many issues to deal with.. |
| 20:46.25 | Damin | Qwell: But I agree having a narrow and deep focus helps to make for generally better code.. |
| 20:54.29 | *** join/#asterisk-dev tzafrir_laptop (n=tzafrir@bzq-179-75-202.static.bezeqint.net) |
| 20:54.29 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 20:56.46 | *** join/#asterisk-dev mnicholson (n=mnichols@nat/digium/x-be808b8e97f46420) |
| 21:02.58 | mvanbaak | hhmm, if a process does not react on 'kill -9' nor 'kill -11' |
| 21:03.02 | mvanbaak | any way to kill it |
| 21:03.04 | mvanbaak | ? |
| 21:03.15 | kpfleming | nope |
| 21:03.20 | kpfleming | it is unkillable |
| 21:03.53 | jsmith | kpfleming: Welcome back! |
| 21:03.54 | seanbright | init 0 |
| 21:03.59 | seanbright | that'll take it down |
| 21:04.44 | kpfleming | jsmith: thanks |
| 21:04.48 | mvanbaak | gheh |
| 21:05.00 | mvanbaak | yeah, init0 on a production box sounds like a good plan |
| 21:05.14 | seanbright | mvanbaak: so does kill -9 |
| 21:06.03 | mvanbaak | here it is |
| 21:06.16 | mvanbaak | it's a php fcgi child that lost it's parent |
| 21:07.03 | mvanbaak | but apache handled it pretty good and respawned all the fcgi managers |
| 21:07.21 | mvanbaak | so it's just this hanging child doing nothnig |
| 21:08.13 | mvanbaak | but maybe you're right seanbright |
| 21:08.22 | mvanbaak | let me take it out of production and reboot the box |
| 21:09.07 | seanbright | i was just suggesting that is a tried and true way to kill the process :) |
| 21:10.24 | *** join/#asterisk-dev ctooley (n=ctooley@doc-24-32-196-69.concordia.ks.cebridge.net) |
| 21:10.24 | *** mode/#asterisk-dev [+o ctooley] by ChanServ |
| 21:13.18 | seanbright | Qwell: did you mean to leave that echo in? |
| 21:13.30 | Qwell | probably. |
| 21:13.31 | Qwell | which one? |
| 21:13.43 | seanbright | echo "Archlinux is not currently supported, although an init script does exits for it." |
| 21:13.56 | seanbright | in the Makefile |
| 21:14.00 | Qwell | err, eh? |
| 21:14.01 | putnopvut | exits? |
| 21:14.06 | putnopvut | sweet |
| 21:14.21 | seanbright | the commit you _just_ did |
| 21:14.23 | Qwell | *shrug* |
| 21:14.24 | seanbright | i'm not making it up |
| 21:14.25 | seanbright | heh |
| 21:14.26 | Qwell | it was in the patch :p |
| 21:14.29 | seanbright | gotcha |
| 21:14.32 | Qwell | stupid context |
| 21:15.12 | Qwell | I don't know why the heck he put that there |
| 21:15.18 | mvanbaak | sorry |
| 21:15.37 | mvanbaak | I think it's a copy from one of the other ones |
| 21:22.30 | bearded_blitz | mvanbaak: not the first time you've rebooted a production box :D |
| 21:23.33 | mvanbaak | lol bearded_blitz |
| 21:23.51 | mvanbaak | yeah |
| 21:34.01 | Corydon76-dig | Do we still support FreeBSD 4? |
| 21:34.23 | Qwell | isn't 6 out now? |
| 21:34.44 | Corydon76-dig | There's a note in strings.h about how a convoluted interface is "only because FreeBSD 4 doesn't have va_copy" |
| 21:34.57 | Qwell | *shrug* |
| 21:35.04 | Qwell | You know the second you remove that, somebody will complain |
| 21:35.13 | Qwell | and, I was wrong - it's at 7.0 |
| 21:35.52 | Corydon76-dig | FreeBSD 7.0 is production ready now |
| 21:36.38 | Corydon76-dig | Qwell: yeah, but I'm dealing with something with ABI compat, which won't work without va_copy |
| 21:36.44 | Qwell | oh |
| 21:36.56 | Corydon76-dig | Actually, I think res_odbc uses va_copy extensively, so... |
| 21:37.18 | Corydon76-dig | res_config_odbc |
| 21:38.23 | Corydon76-dig | Also, menuselect/strcompat.c, and main/astmm.c |
| 21:44.59 | bearded_blitz | Corydon76-dig: ok, I've reproduced the issue, but I'm trying to figure out how to reliably reproduce it so that I know definitively whether the patch is doing something |
| 21:46.22 | *** join/#asterisk-dev anthm (n=anthm@freeswitch/developer/anthm) |
| 21:54.30 | bearded_blitz | ok... I think I have the scenario down now |
| 21:58.26 | Corydon76-dig | puts bearded_blitz in a scenario |
| 22:04.30 | *** join/#asterisk-dev johann8384 (n=johann83@intra.netlogic.net) |
| 22:09.15 | *** join/#asterisk-dev ctooley_ (n=ctooley@doc-24-32-196-69.concordia.ks.cebridge.net) |
| 22:18.29 | bearded_blitz | Corydon76-dig: eep! |
| 22:19.23 | Corydon76-dig | Heh |
| 22:28.00 | *** join/#asterisk-dev jsmith (n=jsmith@72.21.36.138) |
| 22:28.00 | *** mode/#asterisk-dev [+o jsmith] by ChanServ |
| 22:50.17 | putnopvut | applauds Qwell for his bug marshaling today |
| 22:50.22 | Qwell | 15, bitches. |
| 22:50.27 | putnopvut | excellent |
| 22:50.48 | Qwell | file says I can't stop until I close 73 :( |
| 22:50.59 | putnopvut | you're getting there. |
| 22:51.07 | putnopvut | or...do we all have to close 73? :( |
| 22:51.10 | file | _and_ smile |
| 22:51.16 | Qwell | putnopvut: uh huh |
| 22:51.28 | putnopvut | 73 total or 73 each? |
| 22:51.36 | Qwell | yes |
| 22:51.42 | putnopvut | perfect |
| 22:52.01 | putnopvut | oh gross |
| 22:52.09 | putnopvut | bad patch! |
| 22:52.14 | putnopvut | (the utility) |
| 22:55.08 | Corydon76-dig | 73's to all |
| 22:55.09 | putnopvut | Okay, I've got an svn problem here. |
| 22:55.32 | putnopvut | when I try to mergetrunk6 in my 1.6.0 branch, I get an error "svnmerge: no integration info available" |
| 22:55.33 | Corydon76-dig | or 88's, if you'd prefer |
| 22:58.48 | putnopvut | And now it's magically working. |
| 23:00.38 | Corydon76-dig | Did you "mergeinit" first, when you set up your branch? |
| 23:01.04 | Corydon76-dig | type 'svn pl .' |
| 23:01.52 | putnopvut | Corydon76-dig: it was in the 1.6.0 branch. |
| 23:01.57 | putnopvut | Not one of my own. |
| 23:02.07 | putnopvut | But now everything is working, so...not sure what was up with that. |
| 23:03.22 | Juggie | svn magic |
| 23:12.30 | seanbright | hmmmm |
| 23:21.27 | *** part/#asterisk-dev Deeewayne (n=Deeewayn@nat/digium/x-547c915ba480e7ce) |
| 23:30.56 | putnopvut | This is one of the first times in a long time that I've been able to just plug away at the bugtracker. It's been fun to see the things that bearded_blitz has been assigning to me :) |
| 23:31.21 | putnopvut | This leads me to ... |
| 23:31.30 | putnopvut | M13875 |
| 23:31.31 | MuffinMan | [confirmed] [Asterisk] Core/BuildSystem 0013875: [patch] missing DESTDIR for documentation reported by pabelanger (Karma: +33.50) http://bugs.digium.com/view.php?id=13875 |
| 23:32.04 | putnopvut | Patch looks fine, but build system issues are things that I typically avoid. Is this patch cool to commit? |
| 23:33.33 | putnopvut | Actually, just looking at the rest of the context in that section of the Makefile, I'm pretty sure that patch is right. |
| 23:37.48 | kpfleming | looking |
| 23:37.51 | *** join/#asterisk-dev eliel (n=eliel@151-202-114-200.fibertel.com.ar) |
| 23:37.51 | *** mode/#asterisk-dev [+o eliel] by ChanServ |
| 23:38.15 | kpfleming | yes, it's fine |
| 23:38.57 | putnopvut | thanks kpfleming, I'll get it committed soonly. |
| 23:43.22 | *** join/#asterisk-dev DarkRift (n=dark@65.92.251.135) |
| 23:52.13 | seanbright | so i have to admit i'm a little hazy on our release process... but reading the app_fax thing on the -dev mailing list... |
| 23:52.23 | kpfleming | yes |
| 23:52.36 | seanbright | am i right to assume that if a given release is broken you're basically S.O.L. until the next release? |
| 23:52.43 | kpfleming | so here it is: in 1.6.x, if a new feature appears in that release, which has a bug, it will be fixed in the next release |
| 23:52.54 | seanbright | assuming by "broken" i am referring to something that is not a regression |
| 23:52.58 | kpfleming | yes |
| 23:53.01 | kpfleming | exactly |
| 23:53.06 | seanbright | ok |
| 23:53.24 | seanbright | that's... interesting. |
| 23:53.25 | seanbright | :) |
| 23:53.29 | kpfleming | i would not agree with saying 'you are SOL', because before that release you didn't have the feature at all |
| 23:53.43 | kpfleming | having it appear in 1.6.x but not be bug-free until 1.6.x+1 (or +2) just means you have to wait a little longer for it |
| 23:54.46 | kpfleming | when it's a regression, that means we took away something that worked before, so it warrants pushing out a release to fix it |
| 23:56.03 | seanbright | alright. i'll just have to suck it up and accept it i s'pose. |
| 23:56.47 | kpfleming | we've offered to support a community team that wants to backport bug fixes and make sub-point releases, but we just don't have the manpower to do it |
| 23:56.59 | kpfleming | but so far nobody has stepped up as interested in leading such an effort |
| 23:57.37 | seanbright | i guess i don't see what the difficulty with sub-point releases is based on our current release process |
| 23:58.18 | seanbright | i get the impression that releases are "difficult" or "time consuming" |
| 23:58.23 | kpfleming | more work, more making tarballs, more testing of backports, more signing, etc. |
| 23:58.28 | kpfleming | no, it's the backporting |
| 23:58.48 | kpfleming | for example, fixing a bug in chan_sip in 1.6.1 could be very different than 1.6.0, so the patch may not apply |
| 23:59.03 | kpfleming | someone has to figure out how to backport it and make sure it both fixes the bug and causes no harm |