| 00:01.06 | russellb | it's more A than B, really. |
| 00:01.13 | russellb | B could be addressed, A can not. |
| 00:04.01 | russellb | There's no reason in debating any of the other details, given that A is a show-stopper. |
| 00:08.29 | paravoid | agreed, even though he left :) |
| 00:09.12 | paravoid | I'd really like a plan to have mainline support for all known cards (analog and digital) and a common ISDN stack for everything (telephony BRI/PRI, ppp etc.) |
| 00:09.36 | paravoid | and it'd the best for telephony applications, like asterisk, from a technical standpoint |
| 00:09.43 | paravoid | not sure about its business viability though. |
| 00:34.54 | jpeeler | LOW_MEMORY doesn't do anything restrictive to mallocing memory does it? |
| 00:35.18 | jpeeler | because that's my first planned approach in reducing the stack usage |
| 00:43.37 | putnopvut | jpeeler: I don't think it does. |
| 00:43.50 | putnopvut | But I've been wrong before :) |
| 00:44.07 | jpeeler | putnopvut: heh, i'm pretty lost on this one |
| 00:44.17 | putnopvut | What was your plan, by the way? |
| 00:45.01 | jpeeler | well there is a huge buffer in config_text_file_load |
| 00:45.15 | jpeeler | i was going to try and malloc it instead and see if that helps things |
| 00:45.25 | jpeeler | problem is i don't know how far i need to go |
| 00:45.38 | jpeeler | although you just made me realize i can find an estimate out |
| 00:46.08 | jpeeler | i don't know of any other good strategies for reducing usage of the stack |
| 00:46.12 | jpeeler | do you? |
| 00:47.39 | putnopvut | Let me take a look at config_text_file_load |
| 00:48.04 | putnopvut | Ah yes, an 8K buffer. Nice. |
| 00:48.15 | *** join/#asterisk-dev outtolunc (n=me@c-67-170-211-86.hsd1.ca.comcast.net) |
| 00:48.21 | jpeeler | yeah it's huge |
| 00:48.38 | Qwell | and with #includes, I would imagine it's 8k per recursion |
| 00:49.19 | putnopvut | There are two potential approaches. |
| 00:49.53 | putnopvut | You can port it to use ast_str so that the buffer grows dynamically as needed. Or you can just malloc that 8k. |
| 00:50.13 | jpeeler | this is for 1.4, can i use that? |
| 00:50.25 | putnopvut | I'm fairly certain you can, but I'll double-check. |
| 00:50.38 | putnopvut | Er, maybe not. |
| 00:51.15 | jpeeler | yes i just did the API docs |
| 00:51.26 | putnopvut | Heh, yeah, you'd know ;) |
| 00:51.53 | jpeeler | Qwell: so you think it's a good target too then? |
| 00:52.16 | Qwell | yes |
| 00:52.26 | Corydon76-dig | paravoid: I've never quite understood why we dual-license Linux kernel drivers... |
| 00:52.27 | jpeeler | interestingly i used some perl script for static analysis, ast_log is one of the top 5 functions for stack usage |
| 00:53.03 | Corydon76-dig | paravoid: but it's not my decision. :-) |
| 00:53.16 | paravoid | Corydon76-dig: me neither, but I think it's important for your managers :) |
| 00:54.38 | Corydon76-dig | Considering there is no such thing as "Linux proprietary kernel", it doesn't make any sense to me |
| 00:55.59 | paravoid | actually, I don't think that you can even provide them under a different license |
| 00:56.11 | paravoid | I mean, it's code derived from the Linux kernel... |
| 00:56.26 | Corydon76-dig | but it's not code derived |
| 00:56.32 | paravoid | of course it is |
| 00:56.46 | paravoid | it's a kernel module |
| 00:56.54 | Corydon76-dig | It is not considered a derivative work under copyright law |
| 00:57.16 | paravoid | yes it is |
| 00:57.18 | Corydon76-dig | The issue is one of linking not derivation |
| 00:57.35 | paravoid | copyright law doesn't understand linking, just derivation |
| 00:57.46 | Corydon76-dig | Specifically, the license on the kernel itself forbids the linking of modules not distributed under the GPL |
| 00:58.12 | Corydon76-dig | So it's licensing, not copyright, that is the issue |
| 00:58.30 | paravoid | you're calling functions from the Linux kernel |
| 00:58.38 | paravoid | you're using Linux's API |
| 00:58.44 | paravoid | that's derivation... |
| 00:59.00 | Corydon76-dig | Not under copyright law it's not |
| 00:59.19 | paravoid | you could only avoid that by having an abstracted os-agnostic layer |
| 00:59.20 | *** join/#asterisk-dev [hC] (n=hardcore@vpn.voxter.com) |
| 00:59.27 | paravoid | think madwifi's HAL, nvidia's modules etc. |
| 00:59.42 | Corydon76-dig | the modules contain a separate expression of ideas that are not derived from the kernel |
| 00:59.53 | paravoid | so, are you essentialy saying that I can distribute non-GPL asterisk modules and sell them? :) |
| 01:00.06 | paravoid | s/and sell them// |
| 01:00.09 | Corydon76-dig | paravoid: if you write them, yes |
| 01:00.25 | outtolunc | just like aheeva does |
| 01:00.48 | paravoid | without getting a license from Digium? |
| 01:00.59 | paravoid | I hardly think so but I'd be happy if your legal department thinks so. |
| 01:01.08 | Corydon76-dig | I believe so, yes. |
| 01:01.19 | Corydon76-dig | The issue is one of linking |
| 01:01.33 | outtolunc | what the lic from digium is for is if you rebrand asterisk (iirc) |
| 01:01.56 | Qwell | rebranding is fine. distributing it as binary only is not. |
| 01:02.03 | outtolunc | ah |
| 01:02.20 | Corydon76-dig | outtolunc: no, the license from Digium is if you wish to distribute the Asterisk core and your modifications to the core without also distributing the source |
| 01:02.43 | outtolunc | stands corrected |
| 01:02.56 | paravoid | Corydon76-dig: http://www.kroah.com/log/linux/ols_2006_keynote.html |
| 01:03.11 | paravoid | "That's it, it is very simple. I've had the misfortune of talking to a lot of different IP lawyers over the years about this topic, and every one that I've talked to all agree that there is no way that anyone can create a Linux kernel module, today, that can be closed source. It just violates the GPL due to fun things like derivative works and linking and other stuff. Again, it's very simple." |
| 01:03.16 | Corydon76-dig | The alternate license is to escape your obligations that you would otherwise have if you distributed under the GPL |
| 01:03.17 | paravoid | --Greg KH |
| 01:03.53 | Corydon76-dig | paravoid: our modules aren't closed source |
| 01:04.07 | Corydon76-dig | paravoid: apples and oranges |
| 01:04.33 | paravoid | when you distribute them under a different license they're essentialy are |
| 01:04.45 | paravoid | by "closed source" he means non-GPL there |
| 01:04.57 | paravoid | "When you take the Linux kernel code, and link **or build with the header files against it**, with your code, and not abide by the well documented license of our code, you are saying that for some reason your code is much more important than the entire rest of the kernel. In short, you are giving every kernel developer who has ever released their code the finger." |
| 01:04.58 | Corydon76-dig | If that's what he meant, he should have said that |
| 01:05.02 | paravoid | emphasis mine |
| 01:05.17 | paravoid | clear enough now? |
| 01:05.35 | Corydon76-dig | Your opinion is clear |
| 01:05.44 | paravoid | that isn't my opinion, that's gregkh |
| 01:05.49 | paravoid | more specifically gregkh's lawyers. |
| 01:05.51 | Corydon76-dig | His opinion, too |
| 01:06.07 | paravoid | right |
| 01:06.24 | Corydon76-dig | Unless he wants to make a case, it's going to stay an individual opinion |
| 01:06.32 | paravoid | heh :) |
| 01:07.06 | paravoid | it's an argument that could be made to stop dual-licensing your code though |
| 01:07.21 | paravoid | and possibly integrate better with mainline, whatever that means. |
| 01:07.28 | Corydon76-dig | Just remember, in all legal cases that go to judgement, half of all lawyers are wrong. ;-) |
| 01:08.02 | Qwell | paravoid: I have no opinion on the matter, so not going to enter the discussion, but you do have to remember that distros lag behind kernel releases |
| 01:08.23 | paravoid | Qwell: well, distros lag behind zaptel releases as well :) |
| 01:08.51 | Qwell | this is true, but if they are in the kernel, it's very unlikely that people will replace them |
| 01:09.10 | paravoid | I can't disagree with that |
| 01:09.12 | Qwell | just something to consider |
| 01:09.19 | paravoid | it's a valid argument |
| 01:09.42 | paravoid | you can't go on ignoring the rest of the telephony world however |
| 01:09.44 | Corydon76-dig | or find it difficult to keep them replaced, especially when you're not thinking and you do a kernel upgrade |
| 01:09.51 | Qwell | Corydon76-dig: right.. |
| 01:09.59 | Qwell | we've all done that with nvidia drivers, I'm sure |
| 01:10.05 | paravoid | there'll be a time when another driver/stack gets into the kernel |
| 01:10.06 | Corydon76-dig | If zaptel isn't in the new release, you're going to find out very quick. |
| 01:10.15 | paravoid | and you'll be practically forced to switch to it |
| 01:10.39 | Corydon76-dig | Highly doubtful |
| 01:10.40 | paravoid | I've heard that mISDN is getting rewritten with the aim of merging |
| 01:10.54 | paravoid | you already have chan_misdn and you actually suggest it for BRI users |
| 01:10.58 | paravoid | (never understood that...) |
| 01:11.19 | paravoid | if it works out well, PRI support could be added to chan_misdn |
| 01:11.26 | Corydon76-dig | I can't comment on that at this time. |
| 01:11.31 | paravoid | er, kernel's mISDN that is |
| 01:12.24 | paravoid | and if more and more people switch to it you'll be practically forced to use it, imho. |
| 01:12.38 | paravoid | there are other vendors in the market nowdays you know... |
| 01:12.47 | paravoid | anyway, this is just speculation |
| 01:12.52 | Corydon76-dig | I think you've been drinking too much of your own KoolAid there |
| 01:13.11 | paravoid | and based on the grounds that mISDN will get merged, which I find it highly doubtful |
| 01:13.27 | lmadsen | hmmm... Kool-Aid seems like a great idea |
| 01:13.32 | lmadsen | s/Kool-Aid/beer |
| 01:13.43 | Corydon76-dig | From everything I've heard, every single ISDN layer ever put in the Linux kernel has sucked |
| 01:13.45 | Qwell | lmadsen: never mix the two. |
| 01:13.49 | lmadsen | Qwell: noted |
| 01:14.03 | lmadsen | I mixed beer and redbull once... just to see how bad it would be |
| 01:14.08 | lmadsen | oddly enough... it wasn't really all that bad |
| 01:14.10 | Qwell | ... |
| 01:14.11 | paravoid | Corydon76-dig: the only ISDN "layer" that is in the kernel is i4l, afaik |
| 01:14.35 | paravoid | and there are two other isdn stacks, mISDN (which, right now, totally and utterly sucks) |
| 01:14.41 | Corydon76-dig | paravoid: i4l, visdn, misdn |
| 01:14.44 | paravoid | and vISDN/vstuff, which is actually good code |
| 01:14.50 | paravoid | which is actually great code |
| 01:15.22 | paravoid | but after a year of improving its core for GSM development, it doesn't actually work with ISDN cards anymore :> |
| 01:15.44 | paravoid | but vstuff's code is waaay better than zaptel/libpri/chan_zap |
| 01:15.47 | Corydon76-dig | Is it great code that actually does everything that is needed or just well-crafted code that might as well be useless? |
| 01:15.51 | paravoid | it's _good_ code, imo. |
| 01:16.07 | paravoid | and I think it's Q.931 implementation is euroISDN-certified |
| 01:16.17 | paravoid | s/it's/its/ |
| 01:16.38 | codefreeze | atis_work: svn update trunk, and verify that I fixed the problem you reported about 15 hours ago |
| 01:16.46 | Corydon76-dig | Given what I know about certifications, I'd find that difficult to believe |
| 01:16.50 | paravoid | it's unfortunate that the author is buried into GSM development for his employer. |
| 01:17.20 | paravoid | anyway, my point was |
| 01:17.32 | paravoid | there will be a time that *something* will get merged into the kernel |
| 01:17.51 | paravoid | and it'll probably be of good quality |
| 01:17.53 | Corydon76-dig | Your point was that you think we could be forced, and the reality is that we can't |
| 01:18.13 | paravoid | of course you can, you work with the community. |
| 01:18.43 | paravoid | sticking your head into the sand isn't going to work for you ;) |
| 01:19.15 | Corydon76-dig | We advance based on merits, not based on mob think |
| 01:20.18 | paravoid | using a standard (because a Linux API is essentialy a standard) instead of your own "specification" is a merit. |
| 01:20.25 | Corydon76-dig | Sometimes someone from the community has a good idea, sometimes I hear bad ideas. The merits of the proposal are what make it go forwards or not, not what the mob thinks |
| 01:20.40 | Corydon76-dig | paravoid: no, it really isn't |
| 01:21.27 | Corydon76-dig | If the Linux API does what we need in the way that we think it should be done, that would be a merit |
| 01:21.47 | paravoid | well, of course that was the point |
| 01:21.48 | ctooley | The great thing about someone else coming up with a really great kernel level driver that happens to support all the Digium hardware is that it provides a great kernel level driver without Digium having to maintain code in-house. |
| 01:21.55 | paravoid | I wasn't suggesting to replace zaptel by e.g. i4l. |
| 01:22.20 | Corydon76-dig | paravoid: My point is that we judge the code independently |
| 01:23.01 | Corydon76-dig | There is no forcing us to take a direction that we think would be to our (and our users') detriment |
| 01:23.26 | paravoid | my whole point is that if you don't try to cooperate with mainline, someone else eventually will and provide everything that you do and possibly more |
| 01:23.40 | Corydon76-dig | So? |
| 01:24.22 | paravoid | and then people will switch to it, like it or not |
| 01:24.31 | Corydon76-dig | You're thinking in the old proprietary ways. Somebody who comes up with a better way of doing things and releases it to the kernel is NOT a competitor |
| 01:24.31 | paravoid | whether you support it or not... |
| 01:24.33 | ctooley | And? |
| 01:24.53 | Corydon76-dig | Why would it matter who writes it? |
| 01:25.19 | paravoid | I'm actually suggesting you to cooperate better with the community |
| 01:25.28 | paravoid | I really can't see how am I thinking in "the old proprietary ways" |
| 01:25.32 | Corydon76-dig | What community is that? |
| 01:25.36 | paravoid | the Linux kernel community. |
| 01:25.50 | Corydon76-dig | Not my community, sorry |
| 01:26.04 | ctooley | I'd be willing to venture a guess that the profitability of the zaptel code-base as pure software revenue is negative. It's a means to an end, so having the community support a driver is not a negative to the company. |
| 01:26.38 | paravoid | like it or not, however, you (as a company) are tracking that community |
| 01:26.44 | Corydon76-dig | You're talking to a guy who may have perused kernel sources, but has never done any significant kernel work. I am NOT a member of the kernel community |
| 01:26.53 | paravoid | and using its code |
| 01:27.00 | paravoid | neither are your kernel developers, unfortunately. |
| 01:27.22 | paravoid | writing a kernel driver doesn't make you a member of the community; working _WITH_ the community makes you a member of it. |
| 01:27.31 | paravoid | and Digium isn't doing that atm. |
| 01:27.44 | Corydon76-dig | I don't see how that would benefit us atm |
| 01:28.01 | Corydon76-dig | or how we could contribute |
| 01:28.16 | paravoid | now, who's thinking in the "old proprietary ways"? :) |
| 01:29.17 | Corydon76-dig | paravoid: I'll tell you what. I'll send you 30 5yo children and they can contribute to the kernel community |
| 01:29.17 | ctooley | paravoid, I'm butting in here, but I still don't see how someone else coming up with another kernel driver that gets integrated is a problem for Digium. |
| 01:29.44 | paravoid | Corydon76-dig: I don't see how this helps this conversation. |
| 01:30.36 | Corydon76-dig | paravoid: you never stated the qualifications of someone to contribute to the kernel community |
| 01:30.51 | paravoid | do I need to state the obvious? |
| 01:30.57 | Corydon76-dig | I'll send you 30 people who not only next to useless, but likely to actually cause more problems. |
| 01:31.06 | Corydon76-dig | Now how does that help? |
| 01:31.24 | paravoid | you're writing kernel code, you track the kernel for *years* but you haven't ever contributed anything back |
| 01:31.33 | Corydon76-dig | It would be far more helpful to keep people who cannot contribute AWAY from the Linux kernel community |
| 01:32.08 | paravoid | we're not talking about you as a person, but collectively as a company |
| 01:32.16 | paravoid | and I think that as a company you *can* contributei |
| 01:32.18 | Corydon76-dig | I don't speak for the company |
| 01:32.51 | paravoid | if you thought that this whole discussion was about you as a person, you highly overrate yourself :) |
| 01:32.54 | Corydon76-dig | It was a business decision, and I cannot usurp that |
| 01:33.31 | paravoid | neither can I, but I can judge it |
| 01:33.39 | Corydon76-dig | No, we're talking about contributing, and a company cannot contribute, only individuals can (from a code perspective) |
| 01:33.56 | paravoid | ?! |
| 01:34.00 | paravoid | a company cannot contribute?! |
| 01:34.37 | paravoid | so, someone cannot state that "redhat is contributing to the Linux kernel"? |
| 01:34.40 | paravoid | is that a false statement? |
| 01:34.44 | Corydon76-dig | The company is a business entity. It can sponsor developers, but the company, itself, can't contribute |
| 01:35.21 | Corydon76-dig | paravoid: I believe RedHat is indirectly contributing, by sponsoring individuals |
| 01:35.28 | paravoid | of course it can; the work that you do for the company is intellectual property of the company and the company can contribute that back |
| 01:35.57 | paravoid | the copyright stays with the company |
| 01:36.00 | paravoid | you can't call that "sponsoring". |
| 01:36.18 | paravoid | and, anyway, I think we're into technicalities atm. |
| 01:36.31 | Corydon76-dig | Actually, we're into my dinnertime. |
| 01:55.42 | *** join/#asterisk-dev jameswf-home (n=james@ip72-223-0-183.ph.ph.cox.net) |
| 02:06.37 | tzafrir_home | zaptel is not the only kernel module distros lag in |
| 02:06.44 | tzafrir_home | kvm is another example |
| 02:09.41 | tzafrir_home | In Debian the up-to-date kvm kernel code is packaged in a separate package that overrides the vanilla kvm modules |
| 02:10.45 | tzafrir_home | Zaptel^Wdahdi is not the only instance of this problem, and there are ways to solve it |
| 02:12.00 | tzafrir_home | Also recall that half the people who build zaptel build it just in order to use the highly morhping ztdummy module |
| 02:15.36 | tzafrir_home | ctooley, one problem of Digium is that its hardware is not supported on RHEL |
| 02:31.43 | Corydon76-dig | tzafrir_home: supported by whom? |
| 02:32.15 | tzafrir_home | By RH |
| 02:33.36 | Corydon76-dig | Yes, but if you're buying commercial support, you might as well buy Business Edition, too, which is supported on RHEL |
| 02:34.26 | Corydon76-dig | If you're not buying commercial support, then RH's support is pretty much worth only the electrons their people are willing to devote to you |
| 02:34.37 | *** join/#asterisk-dev outtolunc (n=me@c-67-170-211-86.hsd1.ca.comcast.net) |
| 02:34.49 | Corydon76-dig | So I really don't see that as a problem |
| 02:34.55 | tzafrir_home | If you're buying a server from Dell and alike |
| 02:35.59 | Corydon76-dig | Not our recommendation |
| 02:36.15 | tzafrir_home | now, looking at this as a potential customer: my pool of support providers is much more limited |
| 02:36.57 | Corydon76-dig | tzafrir_home: that doesn't stop anybody from buying Oracle |
| 02:37.07 | Corydon76-dig | or Cisco |
| 02:38.59 | tzafrir_home | or maybe someone will decide that enough is enough and fork a version of dahdi on his own. One that will get into mainline kernel |
| 02:39.25 | Corydon76-dig | tzafrir_home: maybe they will |
| 02:40.20 | Corydon76-dig | tzafrir_home: but it will be kind of strange when it's incompatible with Asterisk |
| 02:45.25 | *** part/#asterisk-dev mcargile (n=mcargile@mail.in-florida.net) |
| 04:27.39 | *** join/#asterisk-dev CunningPike (n=arodgers@S010600095b33697f.vc.shawcable.net) |
| 04:55.56 | *** join/#asterisk-dev DarkRift (i=dark@bas10-montreal02-1177585339.dsl.bell.ca) |
| 05:18.14 | lmadsen | is happy his install is done |
| 07:23.34 | *** join/#asterisk-dev agx (n=AGX@host63-216-static.34-88-b.business.telecomitalia.it) |
| 09:40.40 | *** join/#asterisk-dev agx (n=AGX@host63-216-static.34-88-b.business.telecomitalia.it) |
| 09:41.10 | *** join/#asterisk-dev dlu_ (n=dlu@dus-ix-pos-002.dus.net) |
| 09:48.39 | *** join/#asterisk-dev RoyK (n=roy@fw.fortel.no) |
| 09:56.20 | *** join/#asterisk-dev _ys (i=yuri@91.151.196.254) |
| 10:21.12 | *** join/#asterisk-dev jmls_work (n=jmls_wor@mail.tessera.co.uk) |
| 10:30.37 | atis_work | codefreeze: thanks, it's fixed :) |
| 10:43.15 | *** join/#asterisk-dev ccesario (n=ccesario@189-19-9-100.dsl.telesp.net.br) |
| 11:03.25 | *** join/#asterisk-dev jmls_home (n=jmls_hom@mail.tessera.co.uk) |
| 11:54.41 | *** join/#asterisk-dev caio1982 (i=caio1982@CAcert-br/caio1982) |
| 12:15.23 | *** join/#asterisk-dev jeffg (i=34KnXYJN@pdpc/supporter/active/jeffg) |
| 12:16.53 | *** join/#asterisk-dev jmls_work (n=jmls_wor@mail.tessera.co.uk) |
| 12:17.07 | *** join/#asterisk-dev jeremy_g (i=jeremy_g@m83-178-150-146.cust.tele2.se) |
| 12:17.34 | *** join/#asterisk-dev jmls_home (n=jmls_hom@mail.tessera.co.uk) |
| 12:20.05 | jeremy_g | does anyone know where can i find RoyK |
| 12:22.24 | RoyK | waves |
| 12:22.26 | agx | jeremy_g, India :) |
| 12:22.49 | RoyK | agx: never been there... |
| 12:23.48 | RoyK | jeremy_g: 'sup? |
| 12:31.18 | agx | RoyK, ups sorry :) |
| 12:32.05 | RoyK | eh |
| 12:33.11 | *** part/#asterisk-dev agx (n=AGX@host63-216-static.34-88-b.business.telecomitalia.it) |
| 12:36.07 | *** join/#asterisk-dev shido6 (n=shido6@209.114.208.192) |
| 12:54.23 | *** join/#asterisk-dev jmls_home (n=jmls_hom@mail.tessera.co.uk) |
| 12:55.26 | *** join/#asterisk-dev jmls_work (n=jmls_wor@mail.tessera.co.uk) |
| 12:58.04 | ctooley | jpeeler, OK, Found the problem with 1.6 and socket support. It wasn't the move to ast_tcptls_client_start that was the problem per se. I'll submit a single line patch to trunk that is a bug fix which will hopefully make it in to 1.6.0 |
| 12:58.20 | ctooley | ExternalIVR()'s socket support will not work at all without the patch. |
| 13:05.23 | ctooley | Patch submitted to bug 12697. |
| 13:12.22 | *** join/#asterisk-dev shido6 (n=shido6@209.114.208.192) |
| 13:13.33 | Corydon76-dig | ctooley: I have a small problem with this patch, namely, that you're checking if a FD is 0... That is a legitimate file descriptor |
| 13:13.42 | Corydon76-dig | -1 is not, however. |
| 13:16.10 | ctooley | ah, so you want me to set it to -1 instead of 0. I am checking 0 because that's what it was set to earlier. I'll change it to -1 and submit a new patch. |
| 13:17.07 | Corydon76-dig | Thank you |
| 13:17.33 | *** join/#asterisk-dev jeremy_g (i=jeremy_g@m83-178-159-233.cust.tele2.se) |
| 13:18.29 | jeremy_g | Hello girls! |
| 13:18.39 | Corydon76-dig | Hi, honey! |
| 13:21.24 | ctooley | Corydon76-dig, I guess I'm mistaken. 1.6.0 doesn't have socket support anyway, so it's not irrelevant. |
| 13:22.02 | ctooley | will submit a new trunk patch. |
| 13:22.47 | Corydon76-dig | double negative? |
| 13:22.57 | *** join/#asterisk-dev ccesario (n=ccesario@189-19-9-100.dsl.telesp.net.br) |
| 13:24.22 | ctooley | yeah |
| 13:24.33 | ctooley | hasn't had enough coffee |
| 13:24.44 | ctooley | Corydon76-dig, that patch better? |
| 13:25.47 | *** join/#asterisk-dev moy (n=moyhu@nat/ibm/x-c5509dbe521d808b) |
| 13:26.16 | jeremy_g | is the great oej alive? |
| 13:27.01 | Corydon76-dig | ctooley: almost. In the second part of the patch, you need to remove the first clause |
| 13:27.10 | jeremy_g | i am changing chan_sip.c on asterisk 1.2 so that if i receive a register request, and the useragent header does not contain asterisk's default text, it should send it authorization failure message |
| 13:27.21 | Corydon76-dig | ctooley: and really, it should be "> -1" |
| 13:27.22 | jeremy_g | oej! |
| 13:28.11 | Corydon76-dig | jeremy_g: Uh, you're not going to allow phones to register? |
| 13:28.13 | *** join/#asterisk-dev lmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 13:28.13 | *** mode/#asterisk-dev [+o lmadsen] by ChanServ |
| 13:29.16 | ctooley | if(eivr_errors_fd > -1) { |
| 13:31.11 | Corydon76-dig | Right |
| 13:31.19 | *** join/#asterisk-dev anthm (n=anthm@CPE-72-131-113-50.wi.res.rr.com) |
| 13:31.30 | Corydon76-dig | ctooley: because any negative number is an invalid fd |
| 13:33.06 | ctooley | Right. I was going to let the next check catch that but, patch uploaded |
| 13:33.53 | *** join/#asterisk-dev anonymouz666 (n=anonymou@201.19.207.130) |
| 13:34.15 | ctooley | I will say I have spent more time on that single line of Asterisk code than any other 100 lines put together. That's the third time I've debugged that exact issue and since there's 6-9 months between every time it crops up, I never remember it. |
| 13:34.31 | Corydon76-dig | Heh |
| 13:35.00 | ctooley | And once you see what's happening, it's entirely obvious |
| 13:37.50 | Corydon76-dig | ctooley: and the reason why the call worked is because 0 is legit for an FD |
| 13:38.10 | Corydon76-dig | ctooley: if it saw -1, I think the select call would have ignored it |
| 13:38.24 | Corydon76-dig | or poll, rather |
| 13:38.53 | ctooley | hmm |
| 13:39.29 | ctooley | In the parsing of options, I don't need an option_arg enum if there aren't any arguments to the existing options do I? |
| 13:41.48 | Corydon76-dig | No, you can leave that one out |
| 13:42.05 | ctooley | thought so. |
| 13:42.07 | Corydon76-dig | I suspect an empty enum is an error, anyway |
| 13:44.36 | _ys | hello. small question: if in astobj2 called container destructor, linked object destructed too? |
| 13:47.19 | *** join/#asterisk-dev janinge (i=j@ninge.net) |
| 13:52.59 | Corydon76-dig | _ys: only if the object refcount drops to 0 |
| 13:54.15 | Corydon76-dig | which should only occur if there are no outstanding handles |
| 13:54.17 | *** join/#asterisk-dev putnopvut (n=putnopvu@216.207.245.1) |
| 13:54.17 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 14:00.40 | _ys | Corydon76-dig: hm. CLI cmd "astobj2 test 1" not destruct linked object. |
| 14:01.23 | _ys | ah. missed one unref |
| 14:01.39 | _ys | Corydon76-dig: tnx |
| 14:03.25 | *** join/#asterisk-dev sruffell (n=sruffell@adsl-074-185-078-025.sip.bhm.bellsouth.net) |
| 14:03.25 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 14:04.16 | *** join/#asterisk-dev russellb (n=russell@asterisk/developer-and-stable-maintainer/drumkilla) |
| 14:04.16 | *** mode/#asterisk-dev [+o russellb] by ChanServ |
| 14:04.17 | *** join/#asterisk-dev sergee (n=serg@voip1.west-call.com) |
| 14:29.09 | *** join/#asterisk-dev ManxPower (n=manxpowe@131.sub-70-221-188.myvzw.com) |
| 14:29.36 | ManxPower | It sure would be nice if this notice message "[May 21 16:36:49] NOTICE[3679]: chan_sip.c:13952 handle_request_invite: Call from '' to extension '123' rejected because extension not found." also included the context that was searched. |
| 14:36.33 | *** join/#asterisk-dev joetester2 (n=joeteste@216.191.34.13) |
| 14:36.51 | tzafrir | Is Creslin around today? |
| 14:43.37 | *** join/#asterisk-dev snuff-home (n=bradl@60-240-117-7-nsw-pppoe.tpgi.com.au) |
| 14:58.55 | *** join/#asterisk-dev jameswf-home (n=james@dsl093-157-131.phx1.dsl.speakeasy.net) |
| 15:00.50 | *** join/#asterisk-dev shido6 (n=shido6@209.114.208.192) |
| 15:19.52 | jpeeler | ctooley: thanks, sorry i wasn't here earlier |
| 15:20.19 | ctooley | jpeeler, np |
| 15:20.52 | ctooley | turned out not to be related to using ast_tcptls_client_start, as I said. And since I'd fixed the bug 2 other times, I should have been able to find it faster. :( |
| 15:21.18 | ctooley | Besides, Corydon76-dig give me plenty of feedback that made the new fix better anyway. |
| 15:21.41 | jpeeler | yeah i see, thanks Corydon76-dig |
| 15:21.54 | ctooley | And... I'm getting close to having something for you guys to reject on the other stuff. ;) |
| 15:22.37 | ctooley | ast_test_flag returns 1 if the flag is set, correct? |
| 15:22.53 | putnopvut | it returns non-zero for sure. |
| 15:22.58 | putnopvut | I can't remember if it returns 1 or -1 though. |
| 15:23.12 | ctooley | ok, good |
| 15:23.44 | ctooley | now... why isn't this working. :( |
| 15:34.19 | Corydon76-dig | putnopvut: it may even return the actual bit that is set |
| 15:35.15 | putnopvut | Corydon76-dig: yeah, it appears to return the bitwise and of the flags and the bit that you're testing. |
| 15:36.20 | *** join/#asterisk-dev JerJer (n=PhatJ@pdpc/supporter/bronze/jerjer) |
| 15:36.20 | *** mode/#asterisk-dev [+o JerJer] by ChanServ |
| 15:36.31 | Corydon76-dig | Morning, JerJer |
| 15:36.44 | JerJer | what is the appropriate command line to tcpdump dump to create a file that wireshark can decode? (it seems i needed to add some parameter) |
| 15:37.46 | Corydon76-dig | JerJer: Are you using "-s 1500"? |
| 15:38.41 | JerJer | hmm no - tcpdump -x port 4569 (so far) |
| 15:39.04 | Corydon76-dig | Try that. That should capture the entire packet, instead of only the first 68 bytes |
| 15:39.10 | JerJer | ahh |
| 15:39.31 | Corydon76-dig | (i.e. only the headers) |
| 15:39.58 | Corydon76-dig | Assuming your MTU isn't higher, of course |
| 15:50.44 | jsmith | Corydon76-dig: I think you can do -s0 as well, to make sure it grabs the whole packet |
| 15:51.33 | ctooley | And you can use "-w FILENAME" to create a pcap file that Wireshark decodes. |
| 15:51.59 | JerJer | ugh - anyone know either how to make wireshark show a GUI on OS X or a native sniffer for OS X ? |
| 15:52.16 | jsmith | Yeah... I typically do tcpdump -vv -s1500 -w /tmp/capture.pcap port 4569 |
| 15:52.16 | ctooley | JerJer, you might want to just try ngrep instead. |
| 15:52.39 | JerJer | i need iax2 decoded and I cannot do it on the asterisk box |
| 15:53.13 | JerJer | ngrep-ing iax2 doesn't show anything useful - to me |
| 15:53.40 | *** join/#asterisk-dev CunningPike (n=arodgers@204.239.12.183) |
| 15:54.02 | *** join/#asterisk-dev techie (n=techie@adsl-76-214-2-200.dsl.lsan03.sbcglobal.net) |
| 15:54.54 | jsmith | JerJer: Wireshark works on OS X -- you just have to run it inside X11 |
| 15:55.04 | jsmith | JerJer: Unfortunately, the Aqua port never got finished |
| 15:55.34 | ctooley | JerJer, ah |
| 15:56.10 | JerJer | i am in x11 - but no gui shows |
| 15:56.41 | jsmith | JerJer: Does this link help? http://nielsolson.us/Haversian/2007/05/getting_wireshark_to_work_on_y.php |
| 15:56.48 | JerJer | cool - reading now |
| 15:58.29 | JerJer | not so much |
| 15:58.39 | jsmith | :-( |
| 15:58.46 | *** join/#asterisk-dev outtolunc (n=me@adsl-66-218-53-172.dslextreme.com) |
| 15:58.49 | JerJer | the wireshark app loads - but spews a couple GTK errrors |
| 15:58.51 | jsmith | JerJer: Gimme a few minutes, and I'll reboot into OSX and give it a shot |
| 15:59.06 | JerJer | sweeet |
| 15:59.07 | Corydon76-dig | JerJer: check that $DISPLAY is set |
| 15:59.10 | JerJer | it just took for damn ever |
| 15:59.14 | JerJer | gui just popped |
| 15:59.23 | Corydon76-dig | Ah |
| 16:02.48 | JerJer | ugh - it doesn't play nice with VirtueDesktops :( |
| 16:02.50 | JerJer | thanks |
| 16:03.20 | ctooley | Juggie, You'll be happy to know that I just got done with the changes that make DeadExternalIVR unnecessary in trunk. :) |
| 16:03.31 | JerJer | jsmith: i have to restrict to a single host - got a few thousand chattering IAX2 endpoints hitting this box |
| 16:03.43 | JerJer | nice - seems to be working |
| 16:04.14 | ctooley | I'm sure Corydon76-dig or someone else will cut my patch to pieces and tell me to start over again (again), but I have something that works the way I'm expecting it to. |
| 16:04.50 | Corydon76-dig | Heh |
| 16:05.43 | jsmith | JerJer: Glad it's working for you! |
| 16:09.21 | *** join/#asterisk-dev DarkRift (i=dark@bas10-montreal02-1177584781.dsl.bell.ca) |
| 16:13.03 | JerJer | ok - next question... anyone know of a way to filter wireshark to only show iax2 DTMF packets? :) |
| 16:16.56 | JerJer | haha - sort differently |
| 16:21.56 | lmadsen | JerJer: oh god you're alive! |
| 16:21.59 | lmadsen | I was so worried! |
| 16:23.49 | jpeeler | is there a way to use sizeof to determine the size of a malloced block of memory, specifically in the case of a character array? |
| 16:24.20 | bbryant | nope, sizeof is a compiler macro |
| 16:24.24 | JerJer | lmadsen: been traveling lately |
| 16:24.55 | bbryant | so it only gets executed before the code is compiled |
| 16:26.10 | JerJer | ok - i think have have found a problem with SIP -> IAX dtmf |
| 16:26.28 | JerJer | after chasing this for a while with a single customer I now can duplicate it for myself |
| 16:26.54 | jpeeler | bbryant: even so, i still don't understand why for a static allocation it doesn't work more intelligently |
| 16:28.16 | JerJer | i don't totally understand the variable length DTMF stuff - but our provider is sending us 8 DTMF events - with the event duration incrementing each time |
| 16:28.48 | JerJer | but then sends us 6 DTMF ends - again with the event duration incrementing |
| 16:29.31 | bbryant | jpeeler: yea, it should do more to predict it |
| 16:29.50 | JerJer | somehow the conversion from SIP -> IAX2 causes two dtmf begins and ends |
| 16:30.58 | bbryant | but it wouldn't be very consistent... |
| 16:31.28 | ctooley | grrr, forgot the all important changes to description.... not even sure how I'm going to document it since there's so many different ways to call ExternalIVR() now. |
| 16:31.44 | Corydon76-dig | ctooley: just document the new way |
| 16:31.55 | ctooley | Corydon76-dig, ok |
| 16:32.17 | Corydon76-dig | The old way will still work, but we want to encourage new users to transition |
| 16:40.44 | ctooley | I'm going to also update doc/externalivr.txt as it's missing several commands and some commands have seen updates. |
| 16:47.48 | paravoid | asterisk -rx cmd won't return bogus verbose messages? |
| 16:47.51 | paravoid | coool! |
| 16:47.58 | paravoid | has been bitten by this before |
| 16:51.46 | lmadsen | ya... didn't Corydon76-dig fix that a couple weeks ago? |
| 16:51.49 | ctooley | Now that I'm writing this documentation up I'm curious. Should there be two options to ExternalIVR(), one (n) for "don't answer the channel" and one (i) for "ignore hangup status"? The way I've gotten it written right now it does both but 'n'oanswer has the non-intuitive side-effect of ignoring hangup status. |
| 16:59.14 | jsmith | ctooley: Sounds like they need to be separate to me ;-) |
| 16:59.19 | jsmith | ctooley: But what do I know?!? |
| 16:59.53 | ctooley | Especially there are 3 different use cases. Pre-answer means that we _do_ want to check for hangup and stop execution. Post-answer interactive IVR communications. Post-hangup meaning we _don't_ want to check hangup. |
| 17:00.48 | ctooley | I'm thinking of a 'd' which implies 'n' |
| 17:02.54 | mvanbaak | hey all |
| 17:03.08 | jsmith | ctooley: WORKSFORME |
| 17:09.04 | jpeeler | merge4trunk 117462, correct usage? getting: svnmerge: unknown command: '117462' |
| 17:11.20 | tzafrir | A117462 |
| 17:11.29 | mvanbaak | jpeeler: should be |
| 17:11.54 | mvanbaak | jpeeler: if you did a 'make install' in repotools and the correct mergetool and svnmerge are in your path |
| 17:12.24 | tzafrir | jpeeler, mkintf is not guaranteed not to change the contents of conf |
| 17:13.02 | tzafrir | Specifically, it actually does in the case conf.is_sig_auto is set |
| 17:14.20 | jpeeler | tzafrir: is that true in 1.4 as well? |
| 17:14.47 | tzafrir | I don't think so |
| 17:15.49 | tzafrir | But conf should be marked as read-only or whatever if you want to pass it as a pointer |
| 17:17.34 | jpeeler | actually conf could be modified in 1.4 as well |
| 17:17.44 | jpeeler | so i guess that just isn't going to work |
| 17:18.22 | tzafrir | Hmm... is there any other place where the conf structure changes? |
| 17:18.38 | tzafrir | If not, it might work, with minor changes |
| 17:19.03 | jpeeler | true, let's see |
| 17:19.15 | tzafrir | I was waiting for someone to start getting rid of all of those excessive copyings I added there in chan_zap |
| 17:20.00 | jpeeler | oh you're the culprit! |
| 17:20.53 | tzafrir | jpeeler, even worse: for the is_sig_auto hack as well :-( |
| 17:22.59 | jpeeler | it does appear that only chan.sig and chan.radio are modified |
| 17:35.31 | *** join/#asterisk-dev bkruse (n=bkruse@216.207.245.1) |
| 17:35.31 | *** mode/#asterisk-dev [+o bkruse] by ChanServ |
| 17:38.27 | *** join/#asterisk-dev ctooley_ (n=ctooley@209.33.108.203) |
| 17:38.56 | ctooley_ | Not sure how much of what I said got missed because my network connection was gone. Did anyone see the messages about ExternalIVR coming in multiple patches? |
| 17:44.20 | russellb | Corydon76-dig: are you looking into 12702? |
| 17:44.34 | russellb | M12702 |
| 17:44.36 | MuffinMan | [assigned] [Asterisk] Core/General 0012702: Console displays strange "spade" characters at the start of every line reported by johnlange (Karma: +5.00) http://bugs.digium.com/view.php?id=12702 |
| 17:44.51 | wwalker | ctooley: no patches messages |
| 17:44.56 | ctooley | Corydon76-dig, Yeah.... I'm going to be splitting up what I'm actually going to have a finished product into several patches.... |
| 17:45.07 | ctooley | Options to ExternalIVR(): 'n' -- noasnwer Does not answer the channel (for pre-answer operations), 'i' -- ignore_hangup Does not hangup the ExternalIVR() connection when the channel is hung up, instead sends the remote end an "I" event (for live calls), 'd' -- dead allow operations on a hung up channel regardless of answer state. |
| 17:45.12 | ctooley | New Commands: 'T' -- Answer a channel that has not been answered yet. Allows an external application to tell Asterisk to answer the channel and start a generator. |
| 17:45.15 | ctooley | New Events: 'I' -- Inform. A general purpose informational message. I,TIMESTAMP,Hangup,channel-id is sent when the 'i' option is set. |
| 17:46.09 | ctooley | I'd kind of liked kpfleming to look at that too and give his input. |
| 17:54.26 | Corydon76-dig | russellb: I'm trying; I cannot reproduce it. |
| 17:55.47 | russellb | perhaps your terminal just isn't displaying them, even though they really are there |
| 17:56.56 | Corydon76-dig | !!! |
| 17:57.06 | russellb | O.O |
| 17:57.26 | russellb | plz don't yell at me :( |
| 17:57.34 | *** join/#asterisk-dev joetester2 (n=joeteste@216.191.34.13) |
| 17:58.45 | *** part/#asterisk-dev jmls_work (n=jmls_wor@mail.tessera.co.uk) |
| 17:59.23 | file | russellb: perhaps he got an idea! |
| 18:02.17 | Corydon76-dig | My idea is to assign it to file. :-P |
| 18:02.57 | file | well I noticed that |
| 18:03.57 | russellb | why did you assign it to file? |
| 18:04.14 | russellb | it's clearly introduced by your verbosity changes ... |
| 18:05.39 | *** join/#asterisk-dev eliel (n=eliel@151-202-114-200.fibertel.com.ar) |
| 18:07.32 | russellb | Corydon76-dig: can you point me to where you think you're filtering out the character for verbosers? |
| 18:07.38 | russellb | I'm looking at ast_verbose() and I see nothing. |
| 18:08.08 | file | fix_header in main/asterisk.c |
| 18:08.21 | russellb | looks |
| 18:08.23 | file | is at least one place. |
| 18:08.45 | russellb | ok, so it's broken for anything that doesn't use a verbose prefix, then |
| 18:08.53 | russellb | the else case in console_verboser. |
| 18:09.46 | russellb | ill fix it ... |
| 18:11.35 | file | hugs russellb |
| 18:12.29 | russellb | which means 1.4.20.1 |
| 18:12.33 | russellb | sighs |
| 18:13.00 | putnopvut | Is that really something to merit a 1.4.20.1? |
| 18:13.18 | russellb | it's a regression ... |
| 18:13.20 | putnopvut | My feeling is that it doesn't impede the operation of the PBX. |
| 18:13.33 | russellb | no, but it will annoy people and we'll keep hearing about it |
| 18:13.45 | jsmith | votes for 1.4.20.1 |
| 18:17.10 | russellb | and actually, it prints that character for every ast_verbose() call on a remote console |
| 18:17.10 | Corydon76-dig | russellb: because file assigned it to me |
| 18:18.19 | Corydon76-dig | and if someone else wants to take a crack at a problem before I get to it, then having it assigned to me doesn't really help the process |
| 18:18.49 | file | well, you were talking back and forth with the individual on the mailing list so I thought you would want to continue |
| 18:18.55 | file | but all is well now |
| 18:21.31 | Corydon76-dig | file: I would, unless someone else got to it first |
| 18:24.15 | Corydon76-dig | russellb: that's the wrong fix |
| 18:24.36 | Corydon76-dig | russellb: that completely undoes the fix for 'asterisk -rx' |
| 18:25.08 | mvanbaak | gheh, file and Corydon76-dig are fighting over this issue ? |
| 18:25.41 | Corydon76-dig | The character needs to be filtered AFTER it reaches the other side, not before it's transmitted over the pipe |
| 18:26.51 | russellb | ah, true |
| 18:27.53 | russellb | so the change to the network_verboser is wrong |
| 18:27.59 | russellb | but the rest is correct ... |
| 18:28.00 | Corydon76-dig | Right |
| 18:28.03 | russellb | thanks |
| 18:29.16 | Corydon76-dig | russellb: I suppose there's something wrong with the filter mechanism in ast_remotecontrol |
| 18:30.25 | *** join/#asterisk-dev joetester2 (n=joeteste@216.191.34.13) |
| 18:30.29 | shido6 | i fixed the pesky forward problem |
| 18:31.44 | Corydon76-dig | russellb: I know what the problem is; I'll fix it |
| 18:31.48 | russellb | Corydon76-dig: where is the filtering done for non -rx |
| 18:31.53 | russellb | looking at the last for loop |
| 18:31.57 | shido6 | the immediate user and the time they sent the message gets forwarded instead of the ORIGINAL sender and time |
| 18:31.59 | Corydon76-dig | Right, that's the problem |
| 18:32.19 | putnopvut | shido6: cool! |
| 18:32.35 | *** join/#asterisk-dev qdk (n=qdk@195.242.194.41) |
| 18:33.00 | russellb | Corydon76-dig: k, i'll wait for you to commit that change |
| 18:36.18 | russellb | Corydon76-dig: you committing now? |
| 18:36.27 | Corydon76-dig | Testing |
| 18:36.30 | russellb | pfft. |
| 18:36.31 | russellb | :-p |
| 18:40.28 | Corydon76-dig | ack, crap |
| 18:41.14 | Corydon76-dig | Oh, well, that's a good fix anyway |
| 18:41.46 | Corydon76-dig | russellb: do you want me to revert the accidental fix to pbx_spool.c ? |
| 18:42.38 | russellb | it's up to you |
| 18:42.42 | russellb | but it would probably be good |
| 18:42.50 | russellb | so you can provide an appropriate commit message with it |
| 18:43.14 | Qwell | if it's an unrelated fix, it wouldnt be appropriate for a 1.4.20.1 release, would it? |
| 18:43.40 | russellb | correct |
| 18:43.43 | russellb | i will handle that |
| 18:45.29 | Corydon76-dig | Okay, we're better |
| 18:49.58 | jpeeler | is there any performance penalty for changing a huge if statement into a switch with fall through? |
| 18:50.08 | jpeeler | it just looks so much cleaner |
| 18:53.00 | Corydon76-dig | jpeeler: no, that should be fine |
| 18:53.11 | russellb | they compile to the same thing .. |
| 18:53.32 | Corydon76-dig | A switch, with optimization, is just turned into a large jump table |
| 18:53.37 | jsmith | jpeeler: Any changes in efficiency are probably negligible, and the cleanliness of the code would more than make up for it |
| 18:54.04 | Corydon76-dig | Actually, the switch/case may be more efficient |
| 18:54.33 | Corydon76-dig | Because there's only a single conditional, really |
| 19:09.31 | Juggie | sobs |
| 19:12.38 | *** join/#asterisk-dev philipp64 (n=chatzill@nat/microsoft/x-4089d9265dc9126f) |
| 19:24.33 | *** join/#asterisk-dev kamanashisroy (n=kamanash@202.56.7.137) |
| 19:25.49 | codefreeze | Juggie: what's wrong? |
| 19:26.18 | putnopvut | Is there a way in Mantis to specify a section to use monospaced font? For instance, when giving output from certain CLI commands, the spacing gets mangled pretty badly when the note is posted. |
| 19:26.39 | Juggie | codefreeze, someone managed to steal my wow password (though i hardly play, bliz emailed me to say my password was changed |
| 19:26.44 | Juggie | but its also the same password i used for everything, banking, etc, so i had to go change all that |
| 19:26.48 | Qwell | Juggie: O.o |
| 19:27.09 | putnopvut | I know on some forums you can use things like [code][/code], but I was curious if Mantis had some sort of similar option. |
| 19:28.03 | Juggie | they also deleted every thing i had on the characters and sent all my money away, etc. |
| 19:29.02 | Damin | Is progressinband=never in sip.conf global only? Or can it be applied on a per-peer basis? |
| 19:29.49 | bbryant | putnopvut: not that i know of, but that would be useful... |
| 19:29.53 | codefreeze | Saw a court case on that sort of thing in the SANS notices... The kids that did it were charged with theft, among other things... the virtual money they stole had a relationship to hard cash in that case.... |
| 19:30.33 | Qwell | putnopvut: probably just have to have them upload it, and open it in something that can do monospace |
| 19:32.00 | putnopvut | Damin: it would appear to be global only |
| 19:32.27 | file | stabs chan_sip |
| 19:32.41 | putnopvut | file: you don't even want to know what I want to do to it. |
| 19:32.51 | ctooley | hands file a gun for the next attempt. |
| 19:32.53 | Qwell | putnopvut: pervert |
| 19:33.06 | Damin | putnopvut: Interesting.. because in the asterisk 1.4 sample sip.conf, it shows up under the client/peer settings.. |
| 19:33.06 | Qwell | (I kid) |
| 19:33.22 | ctooley | file, what's it doing wrong now? |
| 19:33.28 | Damin | Sorry.. users and peers.. |
| 19:33.50 | file | ctooley: wrong? nothing... just an option wasn't global that should be |
| 19:33.55 | putnopvut | Ugh. Xchat is misbehaving again. brb |
| 19:34.20 | ctooley | file, uh oh, which one? |
| 19:34.24 | file | autoframing |
| 19:34.27 | *** join/#asterisk-dev putnopvut (n=putnopvu@216.207.245.1) |
| 19:34.27 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 19:34.37 | ctooley | oh, nice |
| 19:43.35 | *** join/#asterisk-dev kamanashisroy (n=kamanash@202.56.7.137) |
| 19:55.41 | bbryant | putnopvut: as i found it out, you can actually get monospaced text by using <pre></pre> |
| 19:55.51 | bbryant | in mantis.. |
| 19:55.58 | putnopvut | Oh, cool. Thanks. |
| 19:56.23 | Corydon76-dig | bbryant: does <tt> work as well? |
| 19:56.44 | bbryant | nope |
| 19:57.00 | Corydon76-dig | Err, yeah, that only changes the font, doesn't it? |
| 19:57.38 | bbryant | yep, that just makes it a monospace font |
| 20:01.55 | *** join/#asterisk-dev caio1982 (i=caio1982@CAcert-br/caio1982) |
| 20:08.06 | *** join/#asterisk-dev netstv (n=stv@phoenix.u4eatechinc.com) |
| 20:11.02 | netstv | any pointers to building mips cross compile? |
| 20:11.09 | netstv | where to find docs? |
| 20:11.29 | putnopvut | netstv: sorry, I can't say I've seen anything detailing that. |
| 20:12.33 | netstv | ok.. thanks. |
| 20:23.18 | caio1982 | netstv: have you tried scratchbox.org? it has some mips support |
| 20:23.42 | caio1982 | i used that to port a few things to SH3 once, maybe it might help you |
| 20:24.15 | *** join/#asterisk-dev qdk (n=qdk@0x573fe57e.bynqu2.broadband.tele.dk) |
| 20:38.54 | Damin | Anyone have any ideas on why I would get this on a 302 re-direct? |
| 20:38.56 | Damin | 1211402296 NOTICE[28021]: channel.c:2005 ast_read: Dropping incompatible voice frame on Local/2164104184@outgoing-8630,2 of format slin since our native format has changed to ulaw |
| 20:39.14 | Damin | It produces a really horrible audio sound to one leg of the call.. :) |
| 20:46.19 | ctooley | Damin, the leg that the call is being redirected to is not using the right audio format. I'm not sure if Asterisk will attempt a new codec negotiation with the new leg. |
| 20:55.01 | Damin | ctooley: Interesting.. here is the Audio path.. |
| 20:55.44 | Damin | ctooley: PSTN -> PRI -> Asterisk 1.2 -> SIP (G711) -> Switchvox (* 1.2) -> SIP (G.729) -> Polycom 501 |
| 20:56.41 | ctooley | Damin, don't know, it was a guess. |
| 20:56.52 | Damin | ctooley: The Polycom 501 sends back a "302 Redirect" because the phone has the "Forward" feature enabled, so the Switchvox then establishes the outbound call leg.. which is Ulaw. |
| 20:57.55 | Damin | ctooley: So your assessment makes sense... Asterisk sets up the call on the Local channel to communicate w/ the Polycom as G729, but when it gets the re-direct, attempts to connect hte g729 channel to the Ulaw channel outbound.. |
| 20:58.17 | Damin | ctooley: I just want to know how to fix it! ;) |
| 21:03.36 | ctooley | OK, Options are confusing me... http://pastebin.com/m31d6ae91 |
| 21:05.02 | Corydon76-dig | ctooley: you realize that you're using exactly the same bit for each, right? |
| 21:05.50 | ctooley | uhhh no? |
| 21:05.54 | Corydon76-dig | 1 << 0 is always bit 0 |
| 21:05.59 | Corydon76-dig | Look at your enum |
| 21:06.01 | ctooley | oh. :) |
| 21:06.19 | ctooley | that'd do it. |
| 21:09.56 | jpeeler | tzafrir: ping |
| 21:10.05 | tzafrir | jpeeler, hi |
| 21:10.10 | tzafrir | looked at your commit |
| 21:10.22 | tzafrir | I can't poke any hole in it |
| 21:10.33 | ctooley | I had a feeling that someone looking at that would be able to tell me what I was doing wrong easily |
| 21:10.59 | Corydon76-dig | ctooley: I have a special message for you at 888-HACK-615 |
| 21:11.03 | jpeeler | tzafrir: that's good |
| 21:11.07 | jpeeler | tzafrir: i'm in the process of modifying trunk, i just wanted to make sure that line 8547 is not necessary (it's conf->chan.vars = NULL;) |
| 21:11.14 | ctooley | oh goodie |
| 21:12.47 | tzafrir | hmm... not sur eexactly why it's there |
| 21:13.18 | ctooley | haha thanks, I needed that. |
| 21:13.20 | jpeeler | is it possible process_zap depends on it actually being changed? |
| 21:13.27 | Corydon76-dig | ctooley: gotcha |
| 21:15.30 | tzafrir | http://svn.digium.com/view/asterisk?view=rev&revision=82329 |
| 21:16.41 | jpeeler | ok, i'll proceed then |
| 21:17.46 | tzafrir | jpeeler, because someone else is responsible for releasing them? |
| 21:18.52 | jpeeler | tzafrir: i was just checking that something was not depending for the vars to be set to NULL |
| 21:35.55 | jpeeler | is everything merged to trunk also merged to 1.6.0? |
| 21:37.01 | seanbright | jpeeler: no |
| 21:37.25 | seanbright | jpeeler: 1.6.0 should be feature frozen. only bug fixes go into it. |
| 21:37.32 | seanbright | all other revisions should be blocked. |
| 21:39.40 | jpeeler | i wasn't sure if small unnecessary fixes were to go in |
| 21:39.53 | Corydon76-dig | jpeeler: depends |
| 21:40.07 | Corydon76-dig | jpeeler: just use your best judgement. |
| 21:40.26 | Corydon76-dig | or you could just ask about a particular case |
| 21:40.57 | jpeeler | well, i just made come modifications to chan_zap mkintf function |
| 21:41.30 | jpeeler | it's actually what you remember from before, passing the pointer instead of the entire structure |
| 21:41.54 | jpeeler | but i also made it const and had to modify a few things to make that work |
| 21:41.54 | seanbright | i'd say that if the behavior hasn't changed then its safe to merge |
| 21:41.56 | Corydon76-dig | Right |
| 21:42.14 | jpeeler | if the behavior changed, i broke something :( |
| 21:42.22 | Corydon76-dig | Yeah, that one is tricky |
| 21:42.35 | Corydon76-dig | I'd say no. |
| 21:42.36 | jpeeler | i'd almost rather not put it in |
| 21:42.48 | jpeeler | ok |
| 21:44.04 | jpeeler | although i did put it in for 1.4... |
| 21:45.06 | Corydon76-dig | Err, yeah... generally if it goes into 1.4, it goes into 1.6.0 |
| 21:46.23 | jpeeler | so put it in 1.6.0 then? |
| 21:47.04 | Corydon76-dig | If it went into 1.4, then yes. |
| 21:48.47 | ctooley | OK, I'm going to submit the patch first, once it's reviewed and picked apart, I'll update the descrip and documentation and submit a real patch for inclusion. |
| 21:49.25 | Corydon76-dig | ctooley: if you went ahead and fixed the descrip and docs, it might be committed straight away |
| 21:49.32 | ctooley | hahahaha |
| 21:49.54 | ctooley | You've seen the last several attempts, what exactly do you think are the odds of that. |
| 21:50.15 | Corydon76-dig | Generally if I only have to make tiny tweaks (like a few spaces here and there), I'll approve and commit it like that |
| 21:50.45 | Corydon76-dig | ctooley: I think the odds are good that as you weather the criticism, your code will get better each time. |
| 21:50.58 | ctooley | yeah |
| 21:51.22 | ctooley | Corydon76-dig, this is a fairly large patch (several hundred lines). |
| 21:52.28 | ctooley | new argument format, options handling, a new "event" (based on one of the options), and a new command (also due to one of the options). |
| 21:52.46 | Corydon76-dig | woot |
| 21:53.15 | russellb | volunteers ctooley to be the official EIVR maintainer |
| 21:53.24 | Qwell | +1 |
| 21:53.44 | ctooley | heh, russellb I kind of thought that was a default as I'm the only one using it for any heavy usage. |
| 21:53.50 | russellb | yep |
| 21:54.08 | russellb | perhaps commit access would make this easier? :) |
| 21:54.36 | ctooley | Corydon76-dig, has seen the first several attempts, I'm willing to bet he'd prefer that I not have that, at least for a while. |
| 21:54.56 | russellb | heh, ok. |
| 21:55.05 | russellb | I just wanted to throw out the offer, even if it's just for developer branch usage |
| 21:55.12 | russellb | makes it easier to maintain large patches sometimes |
| 21:55.20 | Corydon76-dig | Are we sure that ctooley isn't the ONLY one using it? |
| 21:55.23 | ctooley | I _would_ like that. (the ability to create a development branch. |
| 21:55.32 | russellb | ok, well I'd be happy to grant that |
| 21:55.42 | russellb | just give me an email address so I can send you the info i need |
| 21:55.48 | ctooley | Corydon76-dig, I know that's not the case, I have seen other people both report bugs and ask for help. |
| 21:55.58 | Corydon76-dig | Ah, okay |
| 21:56.01 | ctooley | Though they typical email _me_ for help. |
| 21:56.06 | russellb | heh |
| 21:56.11 | ctooley | There aren't many out there that use it though, that's for sure. |
| 21:56.21 | ctooley | chris@tooley.com |
| 21:56.24 | russellb | k |
| 21:56.38 | Corydon76-dig | ctooley: you don't use your company email address for that? |
| 21:56.56 | ctooley | I suppose I could. |
| 21:57.16 | Corydon76-dig | Actually, I didn't, for the longest time |
| 21:57.17 | ctooley | But, Excel prefers that I do these submissions as me instead of as the company. |
| 21:57.40 | Corydon76-dig | Ah, okay |
| 21:58.21 | ctooley | Not that they're worried about me doing a bad job per se, but my boss doesn't want me to have to go through "Legal" ever time I submit something. |
| 21:58.59 | Corydon76-dig | Some companies consider it as a kind of marketing |
| 21:59.23 | russellb | and some lawyers don't get open source |
| 21:59.48 | russellb | they see the license agreement and say OMGWTFHELLNO |
| 22:00.05 | ctooley | My boss assumes that the people that matter (ie: you guys) will get that since I'm working on it during work hours it's because Excel has "supported" the work |
| 22:00.54 | Corydon76-dig | ctooley: yes, but we're not the guys who are looking around for a SIP provider... |
| 22:01.29 | russellb | unless it's free. |
| 22:01.50 | russellb | in which case I will take an account and about 8 DIDs |
| 22:02.04 | Corydon76-dig | ctooley: do you have service to Utah? |
| 22:02.06 | file | scratches his head |
| 22:02.06 | ctooley | Corydon76-dig, Our marketing department have already decided that me talking at Astricon, our booth there, and the Hosted Asterisk Server product are enough "Asterisk" marketing. |
| 22:02.15 | file | what was I going to do... |
| 22:02.30 | russellb | gives file a fresh cookie |
| 22:02.46 | Corydon76-dig | hands file a "what" |
| 22:03.11 | file | schedules more meetings for russellb |
| 22:05.33 | ctooley | russellb, replied |
| 22:06.26 | russellb | eeeeeeep |
| 22:06.42 | russellb | ctooley: cool. i'll do it either tonight or tomorrow |
| 22:07.22 | ctooley | no worries |
| 22:14.08 | jpeeler | i'd like feedback as if this will be an acceptable approach to fixing reloading chan_zap with LOW_MEMORY, http://www.pastebin.ca/1025337 |
| 22:15.01 | jpeeler | i could make it occur only if LOW_MEMORY was enabled |
| 22:16.05 | ctooley | M12705 |
| 22:16.08 | MuffinMan | [new] [Asterisk] Applications/app_externalivr 0012705: [patch] Change the ExternalIVR() argument method, add 'I'nform event, add 'T'alk (answer channel) command, add options reported by ctooley (Karma: +2.00) http://bugs.digium.com/view.php?id=12705 |
| 22:22.29 | ctooley | Corydon76-dig, our network covers everywhere in North America and most of the world for termination, but we have orig from pretty much everywhere in the domestic 48. (sorry, didn't see your message earlier) |
| 22:32.34 | mvanbaak | russellb: you here |
| 22:33.54 | russellb | yes |
| 22:33.58 | russellb | jpeeler: i think you're on the right track |
| 22:34.02 | russellb | let me take a look at the func real quick |
| 22:34.59 | mvanbaak | russellb: any of you had a change to look at the hangup/ast_frame stuff I did ? |
| 22:35.15 | mvanbaak | I think it's in a way better stage then current trunk is |
| 22:35.17 | russellb | a little bit, what i saw looks good |
| 22:35.26 | mvanbaak | so if no objections are there, I'll commit it |
| 22:35.33 | russellb | let me do a quick diff |
| 22:35.38 | mvanbaak | sure thing |
| 22:35.45 | russellb | jpeeler: i'm wondering if simply just changing that to 1024 would be ok |
| 22:35.52 | russellb | jpeeler: or maybe making it 1024 in LOW_MEMORY |
| 22:36.07 | russellb | jpeeler: from what it looks like, that buffer simply holds one line from a config file at a time |
| 22:36.17 | russellb | who in the $OIWIEHRO is going to have an 8000 character line in their config? |
| 22:36.39 | mvanbaak | hides |
| 22:36.45 | mvanbaak | ow wait, it's comments |
| 22:36.51 | russellb | including comments, yes |
| 22:36.57 | russellb | but still ... |
| 22:37.05 | mvanbaak | we have comments like that |
| 22:37.21 | mvanbaak | thanks to the guy who wrote our config file generation shit |
| 22:37.27 | russellb | heh |
| 22:37.34 | russellb | i just say jpeeler walk by ... |
| 22:37.34 | mvanbaak | I'm working on sanitizing it |
| 22:37.41 | russellb | s/say/saw/ |
| 22:37.55 | mvanbaak | it's in no way interesting |
| 22:37.56 | russellb | waits for him to notice and read the scrollback |
| 22:38.28 | mvanbaak | "we add this here bla bla because this and that border case and we forget to split it up in multiple lines yepyepyep" |
| 22:38.32 | mvanbaak | stuff like that |
| 22:39.08 | russellb | ok ... on an embedded environment, do you think anyone would ever have a line of config like that? |
| 22:39.09 | mvanbaak | this same guy used a TEXT field in our mysql database for 'Application_name' |
| 22:39.10 | jpeeler | russellb: ok, i can try that |
| 22:39.26 | Qwell | isn't TEXT like...a mb? |
| 22:39.32 | mvanbaak | 16MB |
| 22:39.33 | Qwell | or something just stupidly large |
| 22:39.36 | Qwell | nice |
| 22:39.40 | jpeeler | i was afraid you were going to be concerned with malloc being too expensive, but it's only used per file load |
| 22:39.48 | russellb | i'm torn. |
| 22:39.54 | russellb | it's only config loading, so you would think it's not a big deal |
| 22:39.57 | mvanbaak | like 'MeetMe' wont fit in a varchar |
| 22:40.04 | russellb | but at the same time, config reloading often blocks operation of a module |
| 22:40.12 | russellb | so it should be as fast as possible ... |
| 22:40.55 | jpeeler | well i can look at other places, but one was glaring at me |
| 22:41.02 | Corydon76-dig | ctooley: I have a friend at a SLC ISP who is asking about SIP termination for his customers |
| 22:41.03 | russellb | you're right |
| 22:41.14 | russellb | jpeeler: after thinking about it, i think your patch is fine |
| 22:41.19 | mvanbaak | jpeeler: ur correct. |
| 22:41.20 | ctooley | Corydon76-dig, Chris.Tooley@Excel.com |
| 22:41.22 | russellb | jpeeler: anything else is going to get ugly, without much benefit |
| 22:41.30 | ctooley | I'll put him in touch with the right people. |
| 22:41.42 | jpeeler | yay |
| 22:41.45 | russellb | jpeeler: so, +1, nice job. |
| 22:41.50 | mvanbaak | ?2 |
| 22:41.51 | ctooley | We've got a heck of a network. :) |
| 22:41.56 | russellb | now, to mvanbaak's branch ... |
| 22:41.58 | Corydon76-dig | ctooley: I already told him to use you and Jeremy for the referral |
| 22:41.59 | mvanbaak | s/?/+/ |
| 22:42.06 | jpeeler | russellb: but it be for LOW_MEMORY only? |
| 22:42.11 | jpeeler | *should |
| 22:42.36 | ctooley | Corydon76-dig, Jeremy is probably a better contact, he actually works with the Sales group more than I do. |
| 22:42.43 | russellb | jpeeler: i suppose you could do that, yeah |
| 22:43.26 | mvanbaak | in low_mem a line above 512 would be too much |
| 22:43.44 | Corydon76-dig | ctooley: I was thinking that perhaps y'all got referral bonuses |
| 22:43.45 | russellb | yeah, i would think so ... |
| 22:43.47 | mvanbaak | so if the limit is 8000 in low mem you are set |
| 22:44.00 | russellb | it's 8192 always right now |
| 22:44.07 | russellb | but it takes too much stack space for low mem |
| 22:44.11 | mvanbaak | that's HUGE in low_mem |
| 22:44.29 | russellb | so we can either 1) reduce the limit in low mem mode, or 2) malloc it instead |
| 22:44.38 | mvanbaak | reduce it |
| 22:45.03 | mvanbaak | if you compile in low_mem mode, you know the platform is limited |
| 22:45.13 | mvanbaak | so you dont make lines above 512 |
| 22:45.19 | mvanbaak | that's my opinion |
| 22:45.20 | jpeeler | yeah, it's roughly the second largest user of the stack (under tzload) |
| 22:45.29 | putnopvut | what's the largest? |
| 22:45.35 | jpeeler | tzload |
| 22:45.39 | russellb | jpeeler: ok, then yeah ... keep it on the stack, but change the size to 1024 in low mem |
| 22:45.41 | russellb | see if that does it |
| 22:45.42 | mvanbaak | I have a couple of installs on 16MB embedded systems, and I usually set my vim to 120 chars |
| 22:46.25 | jpeeler | ok, i'll give it a go |
| 22:46.33 | mvanbaak | if it's more than that, I use fastagi to connect to a full blown box |
| 22:46.50 | jpeeler | if the config file overflows, i guess it'll just get truncated |
| 22:47.02 | mvanbaak | or redo my stuff so it fits in lines under 120 chars |
| 22:47.14 | russellb | jpeeler: correct |
| 22:47.19 | *** join/#asterisk-dev snuff-home (n=bradl@60-240-117-7-nsw-pppoe.tpgi.com.au) |
| 22:47.20 | mvanbaak | jpeeler: that is what I would expect from it yeah |
| 22:47.29 | jpeeler | could produce interesting issues if that is not remembered |
| 22:48.10 | russellb | mvanbaak: ping |
| 22:48.18 | russellb | so ... even with the named union, you can't use initializers ? |
| 22:48.19 | mvanbaak | russellb: PONG ! |
| 22:48.28 | russellb | struct ast_frame f = { .data.ptr = NULL }; |
| 22:48.29 | russellb | ? |
| 22:48.36 | ctooley | Corydon76-dig, If we do, I need to figure out how to collect them. |
| 22:48.43 | mvanbaak | russellb: hhmm, where is that |
| 22:48.55 | mvanbaak | I think I used that |
| 22:49.10 | russellb | main/audiohook.c, for example |
| 22:49.12 | russellb | - .data = buf, |
| 22:49.12 | russellb | <PROTECTED> |
| 22:49.12 | russellb | <PROTECTED> |
| 22:49.12 | russellb | <PROTECTED> |
| 22:49.12 | russellb | + frame.data.ptr = buf; |
| 22:49.34 | mvanbaak | ah |
| 22:49.43 | russellb | aside from a few places where that was changed, it looks good |
| 22:49.49 | Corydon76-dig | ctooley: in send_eivr_event, what was the point of increasing the buffer from 256 to 2048? |
| 22:49.54 | mvanbaak | that must be because of my earlier work on the anonymous union |
| 22:50.26 | ctooley | Corydon76-dig, because we've got some "events", primarily 'P' that are a lot larger than 256 bytes. |
| 22:50.30 | russellb | mvanbaak: yeah |
| 22:50.36 | mvanbaak | russellb: do you have a line number ? |
| 22:50.50 | ctooley | an ast_str dynamic struct would probably be a better case there. |
| 22:50.59 | Corydon76-dig | ctooley: right |
| 22:51.09 | mvanbaak | hhmm |
| 22:51.12 | ctooley | hey! I got something right! |
| 22:51.15 | mvanbaak | let me produce a diff |
| 22:51.15 | ctooley | :) |
| 22:51.47 | russellb | have a nice evening, everyone |
| 22:52.16 | mvanbaak | latero russellb |
| 22:52.17 | ctooley | Corydon76-dig, let me know the rest of the changes and I'll resubmit. |
| 22:52.34 | Corydon76-dig | ctooley: in the arguments of eivr_comm, you could keep that argument a 'const char *' |
| 22:52.52 | ctooley | which one? |
| 22:53.05 | Corydon76-dig | ctooley: args |
| 22:53.26 | ctooley | uhhh, is the patch I submitted showing as a non-const? |
| 22:53.35 | Corydon76-dig | Just pass in foo->str, instead of foo |
| 22:53.46 | Corydon76-dig | No, you're passing a const struct ast_str * |
| 22:53.57 | ctooley | oh |
| 22:54.20 | ctooley | I passed in the struct ref so something could use the ->used if it needed the length. |
| 22:54.31 | ctooley | since it's just a pointer it didn't seem to make much of a difference. |
| 22:54.38 | mvanbaak | 00:49 <@ russellb> aside from a few places where that was changed, it looks good |
| 22:54.50 | mvanbaak | 00:51 <@ russellb> have a nice evening, everyone |
| 22:55.00 | mvanbaak | I take that as: fix those, and commit |
| 22:55.10 | mvanbaak | correct ? |
| 22:55.11 | Corydon76-dig | ctooley: also, you're declaring an options argument in AST_DECLARE_APP_ARGS, but you're never using it |
| 22:55.47 | mvanbaak | <--- carefull about what he commits |
| 22:56.04 | ctooley | Corydon76-dig, Ooops, thought I removed that. I was still trying to figure out how "options" worked and when it didn't work I was trying to emulate app_skel.c exactly. |
| 22:58.02 | ctooley | Corydon76-dig, So, based on my rationale, should I change the "args" to a const char * or leave it as a pointer to the struct? |
| 22:58.16 | Corydon76-dig | ctooley: Oh, also, when you're constructing the pipe-delim args, there's a neat trick you can do to avoid having to truncate the final character: ast_str_append(&pipe_delim_args, 0, "%s%s", j == 0 ? "" : "|", application_args.cmd[j]); |
| 22:58.52 | Corydon76-dig | ctooley: I just thought it looked strange is all |
| 22:59.12 | ctooley | Corydon76-dig, that truncates the first |, but I'm still not sure how I truncate the last one. |
| 22:59.25 | ctooley | oh... uhh... ok |
| 22:59.29 | Corydon76-dig | ctooley: there's no trailing pipe to truncate |
| 22:59.57 | Corydon76-dig | It avoids the issue altogether |
| 22:59.58 | ctooley | Yeah, I see now. |
| 23:00.41 | Corydon76-dig | Also, please change your ast_log(LOG_DEBUG, to ast_debug(1, |
| 23:01.39 | Corydon76-dig | also, change strncpy() to ast_copy_string() |
| 23:02.15 | Corydon76-dig | otherwise there's a bug, as strncpy can copy n+1 characters, which could overflow the buffer |
| 23:02.55 | *** join/#asterisk-dev lesouvage (n=lesouvag@cc341200-a.assen1.dr.home.nl) |
| 23:03.04 | ctooley | ok |
| 23:04.36 | Corydon76-dig | The rest of it looks good |
| 23:05.57 | *** join/#asterisk-dev file (n=file@asterisk/developer-and-muffin-lover/file) |
| 23:05.57 | *** join/#asterisk-dev codefreeze-lap (n=murf@216.166.159.235) |
| 23:05.58 | *** join/#asterisk-dev seanbright (n=sean@c-69-251-175-43.hsd1.md.comcast.net) |
| 23:05.58 | *** join/#asterisk-dev citats (n=james@mrplow.gnuinternet.com) |
| 23:05.58 | *** mode/#asterisk-dev [+o file] by irc.freenode.net |
| 23:07.24 | ctooley | ok |
| 23:09.48 | ctooley | just "ast_log(LOG_DEBUG", or "ast_chan_log(LOG_DEBUG" as well? |
| 23:10.45 | ctooley | doesn't really know the difference between the two anyway |
| 23:14.32 | Corydon76-dig | are there any that are ast_chan_log(LOG_DEBUG ? |
| 23:14.43 | Corydon76-dig | I didn't see any |
| 23:20.37 | ctooley | dunno, probably not |
| 23:20.46 | lesouvage | I have lots of errors from eagi-test.c while do a make on a svn checkout. Is this because of the code or am I missing something on my system. (see: http://www.pastebin.be/11472 ) |
| 23:20.51 | ctooley | yeah, some. |
| 23:21.33 | ctooley | there were 4 (not necessarily in the patch), I converted them to ast_debug(1, |
| 23:22.43 | Corydon76-dig | lesouvage: try #asterisk |
| 23:24.12 | lesouvage | Corydon76-dig: sorry I thoght this kind a questions should be asked here. |
| 23:25.31 | Corydon76-dig | Not here, possibly in -bugs, but only if you have an open issue |
| 23:26.26 | mvanbaak | ugh |
| 23:26.35 | mvanbaak | tomorrow is gonna be a hard day |
| 23:26.55 | mvanbaak | Thu May 22 01:26:54 CEST 2008 |
| 23:27.03 | mvanbaak | 6 AM is wakey wakey time |
| 23:29.45 | mvanbaak | ok, I'm done with the changes russellb said |
| 23:29.57 | mvanbaak | ping him or commit ? |
| 23:31.28 | mvanbaak | A117710 |
| 23:31.45 | Corydon76-dig | commit asterisk 117710 |
| 23:31.49 | MuffinMan | [117710] Committed by mvanbaak on 2008-05-21T23:16:39.395757Z: 00:48 <@ russellb> so ... even with the named union, you can't use initializers ? |
| 23:31.49 | MuffinMan | ..00:48 <@ russellb> struct ast_frame f = { .data.ptr = NULL }; |
| 23:31.49 | MuffinMan | ..00:48 <@ russellb> ? |
| 23:31.49 | MuffinMan | ..00:48 < mvanbaak> russellb: hhmm, where is that |
| 23:31.50 | MuffinMan | ..00:48 < mvanbaak> I think I used that |
| 23:31.52 | MuffinMan | ..00:49 <@ russellb> main/audiohook.c, for example |
| 23:31.55 | MuffinMan | ..00:49 <@ russellb> - .data = buf, |
| 23:31.58 | MuffinMan | ..00:49 <@ russellb> .datalen = sizeof(buf), |
| 23:32.00 | MuffinMan | ..00:49 <@ russellb> .samples = samples, |
| 23:32.03 | MuffinMan | ..00:49 <@ russellb> }; |
| 23:32.07 | MuffinMan | ..00:49 <@ russellb> + frame.data.ptr = buf; |
| 23:32.10 | MuffinMan | ..00:49 < mvanbaak> ah |
| 23:32.13 | MuffinMan | ..00:49 <@ russellb> aside from a few places where that was changed, it looks good |
| 23:32.15 | MuffinMan | ..00:49 < mvanbaak> that must be because of my earlier work on the anonymous union |
| 23:32.18 | MuffinMan | ..00:50 <@ russellb> mvanbaak: yeah |
| 23:32.21 | MuffinMan | .. |
| 23:32.23 | MuffinMan | ..Fixed that. Now I can use it in in an initializer. |
| 23:32.26 | MuffinMan | .. |
| 23:32.28 | MuffinMan | ..Please have a look at this so I can commit it (or you can) |
| 23:32.30 | MuffinMan | ..This looks better then current trunk anyways |
| 23:32.46 | mvanbaak | let me put that as bugnote there |
| 23:34.31 | ctooley | Corydon76-dig, new patch uploaded |
| 23:34.31 | *** join/#asterisk-dev moy (n=moyhu@189.169.69.205) |
| 23:34.42 | mvanbaak | see you tomorrow |
| 23:34.44 | mvanbaak | latero all |
| 23:35.30 | *** join/#asterisk-dev file (n=file@asterisk/developer-and-muffin-lover/file) |
| 23:35.30 | *** join/#asterisk-dev codefreeze-lap (n=murf@216.166.159.235) |
| 23:35.30 | *** join/#asterisk-dev seanbright (n=sean@c-69-251-175-43.hsd1.md.comcast.net) |
| 23:35.30 | *** join/#asterisk-dev citats (n=james@mrplow.gnuinternet.com) |
| 23:35.30 | *** mode/#asterisk-dev [+o file] by irc.freenode.net |
| 23:36.00 | ctooley | Corydon76-dig, if you decide to commit it though, don't close the bug, I'll upload the additional docs |
| 23:42.30 | ctooley | Corydon76-dig, nm, documentation submitted. |
| 23:46.25 | *** join/#asterisk-dev Corydon76-dig (i=green@pdpc/supporter/bronze/Corydon76-home) |
| 23:46.25 | *** mode/#asterisk-dev [+o Corydon76-dig] by ChanServ |