| 01:02.08 | *** join/#asterisk-dev jeffg (i=MdPHlQcQ@pdpc/supporter/active/jeffg) |
| 02:12.23 | jsmith | starts hacking on some translation infrastructure for the XML docs stuff |
| 02:14.51 | *** join/#asterisk-dev Deeewayne (i=dwayne@76.29.245.9) |
| 02:14.51 | *** mode/#asterisk-dev [+o Deeewayne] by ChanServ |
| 02:28.35 | *** join/#asterisk-dev Iamnacho (i=Iamnacho@ip68-103-153-140.ks.ok.cox.net) |
| 02:48.23 | *** join/#asterisk-dev CunningPike (n=arodgers@S010600095b33697f.vc.shawcable.net) |
| 02:49.42 | *** join/#asterisk-dev russellb (n=russell@asterisk/digium-open-source-team-lead/russellb) |
| 02:49.42 | *** mode/#asterisk-dev [+o russellb] by ChanServ |
| 03:17.40 | *** join/#asterisk-dev codefreeze-lap (n=murf@72.21.67.40) |
| 03:17.40 | *** mode/#asterisk-dev [+o codefreeze-lap] by ChanServ |
| 03:23.50 | lmadsen | yo |
| 03:54.27 | jsmith | yo yo |
| 04:02.10 | lmadsen | yo yo yo |
| 04:02.14 | lmadsen | is also zzz |
| 04:27.10 | *** join/#asterisk-dev jmls (n=Julian@host217-36-208-155.in-addr.btopenworld.com) |
| 06:13.26 | *** join/#asterisk-dev schmooze_Tony (n=schmooze@rrcs-67-52-214-19.west.biz.rr.com) |
| 06:13.57 | *** join/#asterisk-dev steliosk (n=Stelios@79.107.29.93) |
| 06:42.15 | *** join/#asterisk-dev DarylVOIP_ (n=daryl@75.147.121.177) |
| 06:45.57 | jmls | yay! update worked ! |
| 06:46.29 | snuff-work | :-) |
| 08:21.54 | *** join/#asterisk-dev chainbreaker (n=wpichler@cm178-136.liwest.at) |
| 08:22.15 | chainbreaker | hi all |
| 08:23.01 | *** join/#asterisk-dev qdk (n=qdk@85.235.253.141) |
| 08:23.56 | chainbreaker | i am facing some really obscure thing - i have asterisk 1.4.22 - i do dial into it with 1 or two sip calls which gets answered - and then the echo applikation gets invoked - it does run fine - but cpu usage is around 50% on a quadcore 2,4 ghz system... |
| 08:24.15 | chainbreaker | there must be something terrible wrong with it... |
| 08:24.33 | chainbreaker | how can i find out where asterisk does consume the cpu power.... ? |
| 08:36.50 | *** join/#asterisk-dev oej (n=olle@193.136.47.146) |
| 08:36.50 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 08:53.39 | snuff-home | chainbreaker: i think from memory.. within * u can do a 'core show threads' or similar? |
| 08:59.14 | *** join/#asterisk-dev DarylVOIP (n=daryl@75.147.121.177) |
| 09:12.53 | *** join/#asterisk-dev ParsTR (n=tarik@88.255.144.18) |
| 09:12.58 | ParsTR | hello |
| 09:37.20 | chainbreaker | @snuff-home - i have already found whats the problem is |
| 09:38.07 | snuff-home | k :) |
| 09:43.13 | chainbreaker | @snuff-home i have a test setup where the first machine (1.4.21.1) does send calls to the second (1.4.22) - the first machine does plöay musiconhold when the call gets answered - the second machine does mixmonitor the call and does echo back.... |
| 09:43.36 | chainbreaker | @snuff-home as it seems - the 1.4.19 machine does have a bug where it does play musiconhold much to fast |
| 09:44.29 | chainbreaker | @snuff-home rtp stream was faster than allowed - 1 Minute call has had over 100MB data on disk - and this did consumed all the power.... |
| 09:44.59 | chainbreaker | @snuff-home after changing the tester system to use playback instead of musiconhold it did work.... |
| 09:45.48 | chainbreaker | does someone know - is musiconhold on 1.4.19 buggy ? (the machine does have a zaptel card - so zaptel timing is available... - but no trunk is connected) |
| 09:51.17 | snuff-home | there was some work lately on moh / recording |
| 09:51.57 | snuff-home | u can review the changelog probably see it there.. |
| 09:52.19 | snuff-home | i think 1.4 svn has another 1 or 2 more extra patches relating to that stuff.. |
| 10:06.46 | *** join/#asterisk-dev eliel (n=eliel@200.61.172.61) |
| 10:06.46 | *** mode/#asterisk-dev [+o eliel] by ChanServ |
| 10:12.26 | *** join/#asterisk-dev jeffspeff2 (n=jeff@c-69-245-31-86.hsd1.ky.comcast.net) |
| 10:14.24 | *** join/#asterisk-dev jeffspeff2 (n=jeff@c-69-245-31-86.hsd1.ky.comcast.net) |
| 10:17.10 | *** join/#asterisk-dev Laureano (n=Laureano@190.245.108.2) |
| 10:57.40 | *** join/#asterisk-dev eliel (n=eliel@200.61.172.61) |
| 10:57.40 | *** mode/#asterisk-dev [+o eliel] by ChanServ |
| 11:08.04 | *** join/#asterisk-dev caio1982 (i=caio1982@CAcert-br/caio1982) |
| 11:10.54 | oej | Morning |
| 11:11.01 | oej | Or afternoon, or something |
| 11:11.19 | eliel | morning here 9am |
| 11:14.06 | jsmith | oej: Good afternoon... |
| 11:14.18 | jsmith | eliel: Good morning. Did you see my email to the -dev list re: appdocsxml? |
| 11:14.19 | snuff-home | ello.. its only 2222 here.. |
| 11:14.19 | oej | Where are you, jsmith? |
| 11:14.27 | jsmith | oej: New York City |
| 11:14.35 | oej | is in Lissabon again |
| 11:14.42 | oej | Training starts, back later |
| 11:14.46 | jsmith | oej: Oooh... I'm jealous |
| 11:14.59 | jsmith | oej: How's your Portuguese coming along? |
| 11:15.14 | eliel | jsmith: yes, I will test it and fix it |
| 11:15.41 | jsmith | eliel: OK, cool. I'm really excited to get the ball rolling on the translation side... I did some testing last night, and it seemed to work fairly well |
| 11:16.33 | eliel | jsmith: great! i am working on russell's comments I think I will finish this today |
| 11:16.50 | jsmith | Oooh, cool. |
| 11:16.57 | jsmith | That's awesome. |
| 11:17.17 | jsmith | Thank you again for all your hard work on this... |
| 11:18.01 | jsmith | wanders off to get a shower and a quick bite of breakfast before he starts training |
| 11:25.45 | eliel | I have a problem with stringfields (dont know how tu use them! he), the problem is that I have an allocated buffer and I need to assign it to a stringfield, I need to use ast_string_field_ptr_str_set() or allocate again space for the string and assign it with a ast_string_field_set() ? |
| 11:29.14 | *** join/#asterisk-dev caio1982 (i=caio1982@CAcert-br/caio1982) |
| 11:31.39 | eliel | What I don't get is what if I don't know the total size I will need? is there a way to handle this? or I need to calc every string I will set in the fields and then init() the field? |
| 11:33.18 | *** join/#asterisk-dev jeffg (i=EdgYWAAf@pdpc/supporter/active/jeffg) |
| 11:36.52 | tzafrir_laptop | eliel, is there any reason to make our own languages infrastructure and not use gettext? |
| 11:37.20 | tzafrir_laptop | use gettext: maintain a source in English alone. |
| 11:37.36 | tzafrir_laptop | Every string printed is passed though _() first |
| 11:38.24 | eliel | yes I know gettext, but I think this will give more flexibility (if that word exists in english) |
| 11:38.36 | Qwell | flexibility is correct |
| 11:39.19 | tzafrir_laptop | can you demonstrate where it gives you more flexibility than gettext? |
| 11:39.37 | eliel | tzafrir_laptop: what if we want to add a new field in the documentation but it is not usefull for a 'core show application' ? |
| 11:40.04 | tzafrir_laptop | so? |
| 11:40.38 | eliel | for example (documentation maintainer) |
| 11:40.52 | tzafrir_laptop | same string appears twice translated to two different things? |
| 11:40.58 | eliel | we will need to add a field inside ast_app called docu_maintainer = _(""); |
| 11:41.29 | eliel | for nothing, because we don't need that info inside the code, but is part of the documentation |
| 11:42.42 | tzafrir_laptop | eliel, I think that this is inherent to resolving documentation at run time. regardless of using gettext |
| 11:43.12 | eliel | hmm, so where do you want to use gettext? |
| 11:43.40 | tzafrir_laptop | but actually the .pot file is generated from "the source code". We just have to make a smart enough filter to add this field but not add it to the code |
| 11:44.11 | tzafrir_laptop | for messages printed by asterisk at runtime |
| 11:44.29 | eliel | tzafrir_laptop: ok, we are talking about different things i think |
| 11:46.35 | tzafrir_laptop | hmm... I don't know if gettext can have different settings in different threads |
| 11:46.36 | eliel | don't know which is the best way to manage translations, it is nice to have the xml in every language, also that will be hard to maintain |
| 11:46.56 | tzafrir_laptop | (use case: different remote consoles with different languages) |
| 11:47.07 | tzafrir_laptop | but that's hardly an issue for now |
| 11:47.30 | eliel | we already discuss this, that is not an issue, I have a patch to implement that based on the branchs code |
| 11:47.38 | eliel | without using gettext at all |
| 11:47.44 | *** join/#asterisk-dev jeffg (i=0vKUZVYg@pdpc/supporter/active/jeffg) |
| 11:48.10 | eliel | but russell point me out that for the time being it is not necesary |
| 11:49.21 | eliel | maybe first we will need to diferentiate each remote console |
| 11:49.30 | eliel | language |
| 11:51.50 | tzafrir_laptop | eliel, http://transifex.org/ |
| 11:52.20 | tzafrir_laptop | there's a whole infrastructure around gettext |
| 11:52.38 | seanbright | what eliel has done is more than enough |
| 11:52.44 | seanbright | great work, by the way, eliel. |
| 11:52.51 | Qwell | seanbright: You aren't allowed to be awake so early. |
| 11:53.03 | seanbright | Qwell: my apologies |
| 11:53.07 | seanbright | goes back to sleep |
| 11:53.37 | Qwell | I'm still pondering whether to go crash on the couch in the swdev collaboration area later... |
| 11:54.44 | eliel | tzafrir_laptop: maybe I am not the ONE to discuss this stuff I will try to avoid a massive change to the code because I have done it (it is the human nature), so someone else will take better decisions than me |
| 11:55.25 | eliel | seanbright: thanks |
| 12:10.15 | *** join/#asterisk-dev davevg-btwtech (n=davevg-b@nj-67-76-177-147.sta.embarqhsd.net) |
| 12:11.41 | *** join/#asterisk-dev DarylVOIP (n=daryl@75.147.121.177) |
| 12:16.38 | *** join/#asterisk-dev russellb (n=russell@asterisk/digium-open-source-team-lead/russellb) |
| 12:16.38 | *** mode/#asterisk-dev [+o russellb] by ChanServ |
| 12:23.21 | *** join/#asterisk-dev lmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 12:23.21 | *** mode/#asterisk-dev [+o lmadsen] by ChanServ |
| 12:40.25 | jsmith | tzafrir_laptop: Sorry for the late response... I tried to respond earlier, but my internet connection dropped |
| 12:40.58 | jsmith | tzafrir_laptop: I'm all for internationalization and localization of Asterisk using things like gettext |
| 12:41.12 | jsmith | tzafrir_laptop: But that'd be a much bigger project than what we're trying to accomplish here |
| 12:41.50 | jsmith | tzafrir_laptop: Consider this the "low hanging fruit" of a much larger i18n/l10n project :-) |
| 13:26.01 | *** join/#asterisk-dev dbailey (n=doug@nat/digium/x-b0f498911fb275b2) |
| 13:37.45 | tzafrir_laptop | jsmith, which is why I would like to avoid reinventing a whole new localization framework |
| 13:38.28 | seanbright | you didn't work on it |
| 13:38.34 | seanbright | so you successfully avoided it |
| 13:38.35 | seanbright | heh |
| 13:40.41 | oej | I think we still have a mailing list for i18n |
| 13:53.47 | *** join/#asterisk-dev joetester2 (n=chatzill@216.191.34.13) |
| 13:54.40 | *** join/#asterisk-dev anonymouz666 (n=anonymou@201.19.199.65) |
| 13:59.03 | *** part/#asterisk-dev Kobaz (n=kobaz@64.27.7.21) |
| 14:11.49 | tzanger | morning |
| 14:11.59 | tzanger | can anyone tell me when crelin's expected in? |
| 14:12.14 | file | I could tell you except I would be making it up |
| 14:12.31 | tzanger | file: hahaha |
| 14:12.35 | tzanger | you're very helpful, thank you |
| 14:13.25 | *** join/#asterisk-dev steliosk (n=Stelios@79.107.29.93) |
| 14:15.00 | *** join/#asterisk-dev lmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 14:15.00 | *** mode/#asterisk-dev [+o lmadsen] by ChanServ |
| 14:15.00 | *** join/#asterisk-dev mog (n=mog@nat/digium/x-f2412b1cc8b379c0) |
| 14:15.00 | *** mode/#asterisk-dev [+o mog] by ChanServ |
| 14:19.03 | *** join/#asterisk-dev flujan (n=flujan@internet.nube.com.br) |
| 14:26.08 | lmadsen | tzanger: any chance of you looking at some chan_mobile bugs if I were to assign them to you? :) |
| 14:26.36 | tzanger | lmadsen: unlikely, only because I haven't got hte time right now, I'm under some pressure to get some other things completed quickly and they aren't |
| 14:26.49 | lmadsen | fair enough :) |
| 14:33.24 | oej | Have we used m4 before in Asterisk? I see that m4 scripts was added to 1.4 |
| 14:33.38 | Qwell | oej: they were moved from acinclude.m4 |
| 14:34.06 | oej | OK, cool. I must have missed that. It's a requirement we need to document too. |
| 14:34.18 | Qwell | requirement? |
| 14:34.36 | oej | Well, you need m4 to run configure I guess, so you need m4 installed |
| 14:34.46 | Qwell | just to run bootstrap |
| 14:35.19 | oej | Ok, so it's not a requirement for a normal installation then |
| 14:35.25 | Qwell | nope |
| 14:37.14 | oej | Ok, fine. Just checking that my training material is still correct ;-) |
| 14:38.29 | *** join/#asterisk-dev Juggie (n=Juggie@CPE001601df17fb-CM001ceac25ada.cpe.net.cable.rogers.com) |
| 14:38.44 | lmadsen | omg hi Juggie ! |
| 14:40.30 | lmadsen | files singing is 31337 |
| 14:40.44 | file | I am. |
| 14:41.26 | tzanger | heh |
| 14:41.34 | tzanger | my university library card # is 500001337 |
| 14:42.12 | lmadsen | niiiice |
| 14:42.23 | tzanger | yep :-) |
| 14:43.09 | Juggie | file sings? :P |
| 14:52.58 | jsmith | tzanger: I think Cresl1n has classes on Tuesdays and Thursdays... if I remember correctly |
| 14:54.13 | tzafrir_laptop | you need m4 to run autoconf . You only need shell (and sed and such) to run configure |
| 14:54.53 | *** join/#asterisk-dev Deeewayne (n=Deeewayn@nat/digium/x-cbf266da8c7899ef) |
| 14:54.53 | *** mode/#asterisk-dev [+o Deeewayne] by ChanServ |
| 14:55.48 | Qwell | lmadsen: O.o |
| 14:56.02 | Juggie | Qwell! |
| 14:57.01 | Qwell | blames file |
| 14:57.21 | Qwell | tzanger: where do you live? I'm gonna check me out some books |
| 14:57.31 | tzanger | Qwell: :-) |
| 14:57.37 | tzanger | jsmith: danke |
| 14:58.04 | lmadsen | Qwell: canada! :) |
| 14:58.13 | lmadsen | Qwell: good call |
| 14:58.44 | *** join/#asterisk-dev jameswf-home (n=james@dsl093-157-131.phx1.dsl.speakeasy.net) |
| 15:12.04 | *** join/#asterisk-dev russellb (n=russellb@asterisk/digium-open-source-team-lead/russellb) |
| 15:12.04 | *** mode/#asterisk-dev [+o russellb] by ChanServ |
| 15:12.58 | *** join/#asterisk-dev putnopvut (n=putnopvu@nat/digium/x-7baec24299ea17c8) |
| 15:12.58 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 15:13.39 | *** join/#asterisk-dev pgarcia (n=chatzill@yoda.kanatek.com) |
| 15:14.02 | *** join/#asterisk-dev anthm (n=anthm@freeswitch/developer/anthm) |
| 15:17.26 | *** join/#asterisk-dev bweschke (n=BJ_Wesch@74.94.3.214) |
| 15:17.26 | *** mode/#asterisk-dev [+o bweschke] by ChanServ |
| 15:46.20 | oej | russellb: If you read the commits, I promised Kevin a review of the user stuff after his fix last week. |
| 15:46.50 | oej | Kind of surprising that other people are changing stuff without asking, but well, that's just life I guess. |
| 15:47.34 | putnopvut | oej: who is somebody supposed to ask before changing Asterisk trunk besides the reporter of the issue? |
| 15:49.17 | oej | Well, to me it was obvious that we where working on this code, but I guess not. |
| 15:49.39 | russellb | calm down, sheesh. |
| 15:49.50 | oej | Yeah, right. |
| 15:49.51 | russellb | People just want to help. |
| 15:53.36 | *** join/#asterisk-dev CunningPike (n=arodgers@204.239.8.157) |
| 15:55.13 | *** join/#asterisk-dev mog (n=mog@nat/digium/x-ee0fcb199ac2c411) |
| 15:55.13 | *** mode/#asterisk-dev [+o mog] by ChanServ |
| 15:55.27 | bweschke | oej: there was no malice intended. only a desire to make a branch that wasn't /trunk "right" |
| 15:56.05 | bweschke | if you want to revert /trunk or you want me to do so, I certainly haven't any issue with that. |
| 15:58.06 | *** join/#asterisk-dev joetester2 (n=chatzill@216.191.34.13) |
| 15:59.30 | *** join/#asterisk-dev lmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 15:59.30 | *** mode/#asterisk-dev [+o lmadsen] by ChanServ |
| 16:00.09 | oej | bweschke: I don't think so either. |
| 16:00.56 | tzafrir_laptop | one completely off-topic comment: |
| 16:01.42 | tzafrir_laptop | when you something is posted to the list which is a reply to a commit, the subject line is normally quite meaningless in the long run |
| 16:01.45 | oej | The weather is very nice in Lissabon |
| 16:01.59 | oej | Oh, was that the off-topic? |
| 16:02.08 | oej | Yes, I agree, tzafrir. |
| 16:02.17 | oej | But some part of it is good to have for reference |
| 16:02.34 | oej | when is svn/view coming back? |
| 16:02.46 | tzafrir_laptop | What are you doing in Lissabon (besides enjoying the weather?) |
| 16:03.00 | oej | tzafrir: Training people in Asterisk, SIP and OpenSER |
| 16:03.03 | russellb | I'm not sure ... the reason it's down is that search engines keep trying to index it, and when they do, it takes out the server |
| 16:03.22 | russellb | so, i'm working on improving the situation .. |
| 16:03.24 | oej | I do miss svn view... |
| 16:03.28 | russellb | nods |
| 16:03.28 | oej | Thanks |
| 16:03.31 | russellb | no problem |
| 16:03.37 | jsmith | oej: I'd rather be in Lisbon right now taking your class than being here teaching mine :-/ |
| 16:03.41 | russellb | sorry it's down for now |
| 16:04.20 | russellb | maybe we we can put view on its own machine so when it does get taken out, it only takes out svn view ... |
| 16:04.21 | russellb | we'll see |
| 16:04.48 | russellb | oej: this weekend, a search engine took it out by trying to index "svn annotate" of every revision of chan_sip :) |
| 16:08.25 | Corydon76-dig | russellb: depending on how the user agent presents, you could create an apache.conf-level directive that sends the search engine into the ether |
| 16:08.44 | russellb | hm, not a bad idea |
| 16:09.14 | Corydon76-dig | May be able to add an artificial delay to each search engine query or put them into a pool that only allows X queries per minute, or something like that |
| 16:09.21 | oej | I guess they did not check robots.txt |
| 16:09.28 | russellb | oej: yeah ... |
| 16:09.48 | russellb | Corydon76-dig: that's a good idea. I'm currently working on getting the svn mirror and the bug tracker moved |
| 16:10.07 | russellb | after that, we can work on protecting view ... |
| 16:10.32 | Qwell | or just disable annotate |
| 16:10.45 | russellb | Qwell: yes, that crossed my mind as a short term thing, as well |
| 16:10.49 | russellb | that's actually what hurts the most ... |
| 16:11.39 | oej | Disabling annotate in the web view is ok for me. If you really want it, you can run it locally and go and watch a tv show while waiting |
| 16:11.49 | russellb | heh, yeah |
| 16:12.09 | russellb | let me take a quick look at the svnview code to see how hard that would be ... |
| 16:12.14 | russellb | if it's easy, i'll go ahead and put it back up |
| 16:13.19 | oej | There's a lot of links from Asterisk.org to the svn view, so we do need a solution |
| 16:14.03 | russellb | nods |
| 16:14.47 | lmadsen | russellb: thanks for looking into that stuff... I'm sure it feels like a big distraction right now |
| 16:15.11 | russellb | indeed, one of the many |
| 16:15.24 | file | pokes russellb with a socket wrench |
| 16:15.27 | russellb | wibbles |
| 16:15.29 | lmadsen | o.O) |
| 16:16.28 | Corydon76-dig | russellb: http://www.topology.org/src/bwshare/README.html |
| 16:18.50 | *** join/#asterisk-dev outtolunc (n=me@adsl-66-218-53-172.dslextreme.com) |
| 16:19.49 | Juggie | re: post on *-dev is svn still messed up? |
| 16:19.57 | Juggie | no svn viewer? |
| 16:20.14 | Juggie | ah i'm late too the party. |
| 16:30.27 | russellb | heh, everyone responded to the janitor projects question ... |
| 16:30.46 | putnopvut | lol |
| 16:38.15 | *** join/#asterisk-dev steliosk (n=Stelios@79.107.3.70) |
| 16:41.18 | russellb | so ... in viewvc.conf ... |
| 16:41.38 | russellb | # allow annotation of files. |
| 16:41.38 | russellb | allow_annotate = 1 |
| 16:41.43 | russellb | :) |
| 16:41.56 | *** join/#asterisk-dev Deeewayne (n=Deeewayn@nat/digium/x-22e1c244bf556a59) |
| 16:41.56 | *** mode/#asterisk-dev [+o Deeewayne] by ChanServ |
| 16:42.43 | russellb | svn view should be back up |
| 16:42.50 | seanbright | russellb: i estimate 4 hours to make the necessary change |
| 16:43.02 | russellb | can someone verify it? and also verify that annotate is not an option when looking at files? |
| 16:43.25 | russellb | (svn resolves to a local server for me, that's why it's a pain for me to check) |
| 16:43.42 | seanbright | it's up |
| 16:43.53 | seanbright | no annotate |
| 16:44.00 | russellb | perfect, thanks much seanbright |
| 16:44.04 | seanbright | my pleasure |
| 16:47.44 | Corydon76-dig | Ah, good, you can't get to it if you type in the URL directly, either |
| 16:47.53 | russellb | Corydon76-dig: good idea :) |
| 16:48.22 | Corydon76-dig | I have to test it... |
| 17:05.52 | *** join/#asterisk-dev L-info (n=L-info@80.169.133.251) |
| 17:09.15 | *** join/#asterisk-dev CunningPike (n=arodgers@204.239.8.157) |
| 17:11.22 | *** join/#asterisk-dev kamanashisroy (n=kamanash@119.30.35.36) |
| 17:12.53 | *** join/#asterisk-dev L-info (n=L-info@80.169.133.251) |
| 17:13.03 | *** join/#asterisk-dev pgarcia (n=chatzill@yoda.kanatek.com) |
| 17:30.54 | *** join/#asterisk-dev eliel (n=eliel@200.61.172.61) |
| 17:30.54 | *** mode/#asterisk-dev [+o eliel] by ChanServ |
| 17:35.39 | tzafrir_laptop | yey, dahdi echocan module |
| 17:36.18 | seanbright | doesn't have a ../staging/echo/oslec.h file |
| 17:37.37 | russellb | so, it shouldn't build by default, then ... |
| 17:37.57 | russellb | and it isn't |
| 17:38.07 | seanbright | oh |
| 17:38.08 | seanbright | ok |
| 17:38.48 | philipp64 | howdy all. |
| 17:39.28 | tzafrir_laptop | sees once again how great it is that the dahdi-linux is shaped like mainline |
| 17:39.46 | philipp64 | still having an issue with NAT and one-way voice on incoming calls. I suspect that my carriers SBC is at fault. |
| 17:39.54 | tzafrir_laptop | seanbright, you "just" need to grab it from the staging tree |
| 17:39.58 | philipp64 | I have traces... can someone help me find a work-around? |
| 17:40.14 | seanbright | philipp64: over in #asterisk, someone can |
| 17:41.06 | philipp64 | slinks off to #asterisk. |
| 18:05.11 | philipp64 | slinks back... too much sideband noise. anyone here a SIP guru that could help me finger an interoperability bug? |
| 18:06.48 | philipp64 | everyone must be in europe.... |
| 18:07.10 | bweschke | points at file |
| 18:07.32 | file | points at bweschke |
| 18:07.38 | seanbright | points at sergee |
| 18:07.40 | seanbright | heh |
| 18:07.45 | seanbright | meant to point at myself... but oh well. |
| 18:18.47 | sergee | doesn't mind |
| 18:19.26 | lmadsen | points at his drum kit |
| 18:19.32 | sergee | points at NULL |
| 18:19.58 | sergee | drumkilla? :) |
| 18:20.33 | bweschke | wow - haven't heard that nick in a while |
| 18:20.48 | jtodd | OK, I _must_ have a Tempest-ed Cisco 7962G. http://www.advprograms.com/accessories.htm |
| 18:22.32 | lmadsen | jtodd: what does Tempest do to the phone? |
| 18:22.45 | sergee | M8119 |
| 18:22.49 | MuffinMan | [closed] [Asterisk] Core/General 0008119: [branch] RT Storage for voicemail - initial release reported by sergee (Karma: +54.50) http://bugs.digium.com/view.php?id=8119 |
| 18:23.03 | *** join/#asterisk-dev jsolis (n=jimmy@190.232.181.63) |
| 18:23.11 | jtodd | Blocks radiation from escaping, so nobody can eavesdrop on your electronic signals remotely. |
| 18:23.27 | sergee | Corydon76-dig: just for the record: incomplete driver - means that driver is incomplete, it doesn't mean that framework broken. |
| 18:23.38 | file | eavesdrops on jtodd's conversations every day |
| 18:24.03 | *** part/#asterisk-dev jsolis (n=jimmy@190.232.181.63) |
| 18:24.17 | jtodd | Feh. Until SRTP is built into SIP, I'm sure that's any easy prospect. |
| 18:24.20 | jtodd | lmadsen: http://en.wikipedia.org/wiki/TEMPEST |
| 18:24.40 | sergee | Corydon76-dig: so you don't need to change 8118 or 8119, you just need to update your favourite RT driver to fit current * |
| 18:25.16 | lmadsen | jtodd: wow... neat |
| 18:25.33 | bweschke | wrapped his 7970 in aluminum foil... same effect. now all he has to do is figure out how to use it while wrapped |
| 18:25.40 | lmadsen | I'm waiting for some sort of projection screen which is "one-way" so the camera can sit behind the screen so you're actually "looking" at the person |
| 18:25.48 | lmadsen | bweschke: :) |
| 18:25.59 | jtodd | lmadsen: TEMPEST stuff is usually surrounded by copper mesh cages, or has copper mesh melted into the plastic case. |
| 18:26.12 | lmadsen | bweschke: I could barely even figure out how to use mine without the tinfoil |
| 18:27.32 | jtodd | Now that I think of it, I'm surprised I haven't seen more TEMPEST phone gear out there. |
| 18:28.45 | file | jtodd: thinking is not permitted |
| 18:28.53 | jtodd | Of course, it's all moot until everything is encrypted on the wire, and we're not quite there yet. |
| 18:30.01 | jtodd | Wow, I'm really behind the times with Cisco's gear - I didn't know they supported G.722 and iLBC on the 7962. |
| 18:34.18 | Corydon76-dig | sergee: the issue is that you've chosen a method that is not portable |
| 18:34.40 | Corydon76-dig | sergee: which is why it won't work on many native database drivers |
| 18:43.29 | *** join/#asterisk-dev mbranca (n=matteo@81.208.92.210) |
| 19:13.02 | *** join/#asterisk-dev eliel (n=eliel@200.61.172.61) |
| 19:13.02 | *** mode/#asterisk-dev [+o eliel] by ChanServ |
| 19:17.25 | putnopvut | Let it be known that the agent_devicestate function makes absolutely no sense to me. |
| 19:19.09 | russellb | heh, yes. |
| 19:20.10 | putnopvut | Seriously, how the crap does it work? |
| 19:21.49 | jpeeler | putnopvut: for queue call counts... should the count be incremented when an agent makes a call out? |
| 19:21.59 | bweschke | whistles a fairly innocent tune |
| 19:22.11 | jpeeler | this would be in the situation of using an originate, which was actually previously not possible |
| 19:22.17 | bweschke | jpeeler: no |
| 19:22.19 | putnopvut | jpeeler: no |
| 19:22.25 | bweschke | jinx! |
| 19:22.39 | jpeeler | ok cool, maybe there is nothing to fix :) |
| 19:22.43 | putnopvut | :) |
| 19:23.14 | bweschke | the device state in chan_agent was intended purely to indicate status for calls RECEIVED to Agent/XXXX |
| 19:23.30 | bweschke | so.. |
| 19:23.42 | bweschke | Originate is actually an interesting point |
| 19:24.11 | bweschke | because if you Originate a call to Agent/XXX and that's leg A of the call before calling leg B - it *might* work |
| 19:29.02 | eliel | russellb: I am working on moving ast_app to a stringfield, but I will not be able to move ast_custom_function to this schema without loosing backward compatibility, so, I think we can leave with that |
| 19:31.05 | russellb | eliel: Hm ... |
| 19:31.17 | russellb | why would you lose compatibility? |
| 19:31.22 | russellb | ABI compatibility you mean? |
| 19:31.38 | russellb | since you're changing the struct, and func modules fill in those structs directly? |
| 19:31.49 | eliel | that is why |
| 19:32.01 | russellb | how do you know now if you need to free those strings or not |
| 19:32.05 | eliel | string fields can't be writen directly without the wrapper |
| 19:32.24 | eliel | there is a doc_src |
| 19:32.32 | russellb | so you added a new field? |
| 19:32.53 | russellb | pulls up the diff |
| 19:33.01 | eliel | yes, but it is only modified inside custom_function_register |
| 19:33.13 | eliel | ups |
| 19:33.16 | eliel | :( |
| 19:33.25 | *** join/#asterisk-dev joetester2 (n=chatzill@216.191.34.13) |
| 19:34.31 | russellb | eliel: well, you're already breaking ABI compatibility by adding those fields to the ast_custom_function struct |
| 19:34.48 | russellb | you should be able to still declare those as stringfields and initialize them the same way files do it today ... |
| 19:35.02 | eliel | russellb: i can't |
| 19:35.07 | russellb | what error do you get? |
| 19:35.40 | eliel | well, i dont get any error, it is written in the documentation of stringfields |
| 19:35.57 | russellb | you read the documentation! |
| 19:35.58 | russellb | how dare you! |
| 19:36.00 | russellb | :) |
| 19:36.22 | russellb | well ... i'm telling you that it should be ok :) |
| 19:36.30 | russellb | you can blame me if someone complains! :) |
| 19:37.16 | eliel | ok, but I will need to free each allocated pointer and not use ast_string_field_free_memory |
| 19:37.41 | russellb | nope, you shouldn't have to do that. |
| 19:38.00 | russellb | you can call free_memory() if your docsrc says that xml docs were used, and that you allocated memory for stringfields |
| 19:38.34 | russellb | otherwise, if the module provided it, you can assume the module is taking care of it (and most likely just used some const global strings) |
| 19:38.46 | eliel | russellb: ok! |
| 19:38.59 | eliel | I will start working on that |
| 19:39.17 | russellb | k :) |
| 19:40.02 | Corydon76-dig | eliel: just out of curiosity, how are you going to handle how func_odbc populates the description and synopsis fields, since that all happens at load and reload times? |
| 19:40.32 | russellb | Corydon76-dig: in that case, there would not be XML documentation for it |
| 19:40.40 | eliel | Corydon76-dig: I was looking at that, I think it wont be a problem |
| 19:40.41 | russellb | Corydon76-dig: and it would just use whatever the module provides |
| 19:40.52 | eliel | as russellb said |
| 19:40.54 | russellb | when it registers/unregisters, just like today |
| 19:41.31 | Corydon76-dig | Aw, you mean we can't do as KDE and set description[en]=... description[es]=... description[it]=... |
| 19:42.05 | Corydon76-dig | ;-) |
| 19:42.27 | russellb | heh ... |
| 19:43.24 | russellb | Corydon76-dig: did you catch the stuff that came by on the list about what files to load docs from, and how documentation from 3rd party modules or backports can override the base docs? |
| 19:43.38 | Corydon76-dig | Yep |
| 19:43.47 | russellb | are you in support of that scheme? |
| 19:43.53 | russellb | or haven't had time to think about it? h eh |
| 19:44.09 | Corydon76-dig | Not really, no |
| 19:44.16 | russellb | fair enough |
| 19:44.18 | russellb | don't worry about it right now |
| 19:44.26 | Corydon76-dig | I support a schema where the naming system is unique per application |
| 19:44.47 | Corydon76-dig | and should include vendor and version number |
| 19:45.12 | russellb | hmm, ok, well let me think about it a bit |
| 19:45.16 | tzafrir_laptop | the topic still says viewvc is disabled... |
| 19:45.16 | Corydon76-dig | so that the unique name matches perfectly to the actual module which is loaded |
| 19:45.22 | eliel | Corydon76-dig: didn't forget about that (next version) |
| 19:45.47 | *** topic/#asterisk-dev by seanbright -> Asterisk Development Discussion -=- http://www.asterisk.org/developers -=- Asterisk trunk: res_telepathy release tomorrow -=- Tier 2 and Tier 3.14159265 support is in #asterisk -=- Congrats -dev on the release of 1.6.0! |
| 19:45.48 | Corydon76-dig | eliel: okay, as long as it's on the roadmap |
| 19:45.56 | tzafrir_laptop | hmm... forgot I was op |
| 19:46.12 | russellb | ok, well let's make it a little further through the code review, and then we can revisit this on the -dev list |
| 19:46.56 | eliel | appname="com.digium.application.dial" |
| 19:47.09 | seanbright | grrrr |
| 19:47.13 | seanbright | heh |
| 19:47.30 | Corydon76-dig | version="1234" |
| 19:47.51 | russellb | and the modules will have to have this information embedded in them? |
| 19:48.00 | Corydon76-dig | or version="1.4.22" vernum="102789" |
| 19:48.16 | russellb | could this be considered a phase2 type of thing? |
| 19:48.26 | russellb | or do you think this needs to be addressed for the initial cut |
| 19:48.39 | Corydon76-dig | russellb: I think the vernum, so the closest documentation version can be sourced |
| 19:48.56 | tzafrir_laptop | the interface to modules should have remained stable through the whole 1.4 series |
| 19:49.06 | Corydon76-dig | russellb: phase 2 is fine. Eliel has confirmed that it's on the roadmap, which is fine |
| 19:49.07 | tzafrir_laptop | what about 1.6.x ? |
| 19:49.32 | eliel | tzafrir_laptop: regex? maybe... i like it |
| 19:49.56 | tzafrir_laptop | that's implementation |
| 19:49.56 | Corydon76-dig | eliel: regex for what? |
| 19:50.08 | eliel | version number? |
| 19:50.10 | tzafrir_laptop | what do you actually want to guarantee? |
| 19:50.15 | lmadsen | eliel: re: the dynamic loading of docs for func_odbc... would it be possible to do it after mvanbaak does the stuff for res_clialiases that lets you make a callback just before asterisk finishes initializing? |
| 19:50.31 | Corydon76-dig | eliel: I think you should have a string form, for humans, and a numeric form, for comparison |
| 19:51.02 | Corydon76-dig | eliel: and the numeric form, at least internally to Asterisk, should probably be the revision number |
| 19:51.07 | eliel | lmadsen: why? it is using the basic schema for registering functions, it is just changing the documentation at runtime, and that is ok |
| 19:51.18 | eliel | Corydon76-dig: ok, +1 |
| 19:51.19 | lmadsen | coolio |
| 19:51.24 | Corydon76-dig | eliel: and then you do a comparison to find the highest number documentation which is lower than the module vernum |
| 19:51.37 | tzafrir_laptop | what's 102789? |
| 19:51.50 | Corydon76-dig | tzafrir_laptop: revision number in Asterisk |
| 19:52.09 | tzafrir_laptop | an SVN revision number? |
| 19:52.15 | Corydon76-dig | tzafrir_laptop: correct |
| 19:52.36 | tzafrir_laptop | svnrev? revnum? |
| 19:52.46 | Corydon76-dig | tzafrir_laptop: for external modules, it's whatever the distributor decides, as long as it continues to increment |
| 19:53.18 | russellb | so, just backing up a second ... all of this is to help avoid doc version / module version mismatch? |
| 19:53.40 | russellb | and do you really think this is that big of a problem? To me, just having to install a doc file along with installing a module seems simple enough |
| 19:53.41 | Corydon76-dig | russellb: to pick the most applicable documentation |
| 19:53.49 | jsmith | was perfectly fine with putting the burden on the administrator |
| 19:54.01 | russellb | i don't think picking the most applicable is that tough |
| 19:54.14 | russellb | the only complicated scenario we have come up with IMO is the case of a backport |
| 19:54.24 | russellb | where a module is documented in the core, but you have a new set of docs for it |
| 19:54.24 | Corydon76-dig | Consider that in many cases, we will have bundled documentation for a bunch of files, and if somebody upgrades just one module, we want the most current documentation |
| 19:54.27 | russellb | and that case is handled |
| 19:54.50 | russellb | then they put the documentation for that one custom upgraded module in the thirdparty dir |
| 19:54.58 | russellb | and the doc loading code prefers stuff in there before the base docs |
| 19:55.05 | De_Mon | Hmmm... I'm running 1.6.0 and 302 Temporarly Moved responses arn't getting handled as expected... |
| 19:55.05 | Corydon76-dig | so, bundled-doc-1.6.15.xml and single-doc-func_odbc.xml |
| 19:55.08 | De_Mon | http://pastebin.com/m62f427ef |
| 19:55.22 | tzafrir_laptop | how do you get the documentation from binary modules? |
| 19:55.26 | russellb | Corydon76-dig: yeah. |
| 19:55.36 | russellb | tzafrir_laptop: it would have to be distributed as a file along with it |
| 19:55.56 | Corydon76-dig | russellb: people get lazy and load multiple documentation sets |
| 19:56.06 | tzafrir_laptop | russellb, http://downloads.digium.com/pub/telephony/codec_g729/ |
| 19:56.17 | Corydon76-dig | russellb: it may slow the system down, but we should still select the right version |
| 19:56.29 | tzafrir_laptop | distributed separately: there will be a mismatch |
| 19:56.35 | russellb | tzafrir_laptop: right, so in those tarballs, we'd have a doc file |
| 19:56.54 | Corydon76-dig | We can tell people best practice, best practice, best practice, but there will still be lazy people |
| 19:56.54 | russellb | "people get lazy and load multiple doc sets" -- i don't understand what you mean |
| 19:57.07 | russellb | what error are we talking about that laziness would cause |
| 19:57.27 | Corydon76-dig | russellb: multiple sets of documentation for a single module in the third party directory |
| 19:57.36 | russellb | why would there be multiple? |
| 19:57.39 | Corydon76-dig | russellb: but each at different versions |
| 19:57.43 | russellb | use the same name every time you install the module |
| 19:57.54 | russellb | my_module.xml |
| 19:58.05 | russellb | the naming is stupid if you end up with multiple versions of it |
| 19:58.06 | Corydon76-dig | russellb: if only we controlled the world, everything would be perfect |
| 19:58.26 | russellb | well, we do control the rules on how this works |
| 19:58.29 | tzafrir_laptop | what happens if you have my_module.xml and also documentation for my_module in core.xml? |
| 19:58.52 | russellb | tzafrir_laptop: you put my_module.xml in the thirdparty directory, and docs in there get first priority |
| 19:58.54 | Corydon76-dig | russellb: I just want something that is more resilient than "you have to name it this way" |
| 19:59.06 | tzafrir_laptop | module was distributed separately and is now in the core. Or vice versa |
| 19:59.13 | Corydon76-dig | russellb: and let's not forget name case differences |
| 19:59.16 | russellb | and i dont want to overengineer the stuff when telling people not to name a file stupidly suffices :) |
| 19:59.53 | russellb | tzafrir_laptop: then it's a part of the upgrade process ... just like how when you upgrade asterisk, it is a problem if you still have some modules sitting around from an older version |
| 19:59.59 | russellb | and when installing from source, we warn people if that happens |
| 20:00.04 | Corydon76-dig | As I'm fond of saying, most of my most useful modules in Asterisk are due to me overengineering a solution. ;-) |
| 20:00.52 | russellb | heh, i'm not sure that is relevant :) |
| 20:01.10 | russellb | i'm very much not yet convinced that the scheme already in place is not sufficient |
| 20:01.10 | Corydon76-dig | Overengineering a solution is exactly what we're talking about |
| 20:01.30 | russellb | right ... but no witty saying is going to make overengineering this ok :-p |
| 20:01.59 | tzafrir_laptop | Corydon76-dig, I'm simply raising the issues from the fact that documentation is not part of the binary |
| 20:02.03 | Corydon76-dig | I just like solutions that don't depend on the user not doing something stupid |
| 20:02.25 | Corydon76-dig | tzafrir_laptop: and I agree with you, for once |
| 20:02.34 | *** join/#asterisk-dev flujan (n=flujan@internet.nube.com.br) |
| 20:02.56 | Corydon76-dig | Stop the presses! I agree with Tzafrir on something! |
| 20:03.18 | lmadsen | falls over |
| 20:05.06 | eliel | he |
| 20:06.09 | russellb | Corydon76-dig: heh, it's more like the people doing packing or writing install scripts for 3rd party modules |
| 20:06.28 | russellb | i'm not sure that this would affect end users that much ... |
| 20:06.32 | Corydon76-dig | russellb: well, it's the third party modules I'm most concerned with |
| 20:06.38 | russellb | nods |
| 20:06.56 | russellb | well, as long as we can agree that this effort can be considered a phase 2 thing in the roadmap, then i'm happy for now |
| 20:07.07 | Corydon76-dig | Yeah, our stuff, we can make the Makefiles remove stuff that shouldn't be there |
| 20:07.08 | eliel | me too |
| 20:07.18 | russellb | as i'm trying to help get this merged sooner rather than later, since it is _so_ invasive, and will be really hard to keep up to date |
| 20:07.56 | Corydon76-dig | Understood |
| 20:08.08 | russellb | ok, well i'm glad we're in agreement there :) |
| 20:08.11 | russellb | cheers! |
| 20:08.37 | Corydon76-dig | eliel: I am interested to see the conversion to func_odbc, though |
| 20:08.42 | eliel | russellb: oppps:func_odbc.c:787: error: assignment of read-only member âsynopsisâ |
| 20:08.49 | eliel | Corydon76-dig: he |
| 20:08.51 | Corydon76-dig | since it will be one of the few modules to still have embedded documentation, the way it works within the schema should be interesting |
| 20:08.52 | eliel | working on that |
| 20:08.54 | russellb | eliel: mark the struct as const |
| 20:09.21 | russellb | blames Corydon76-dig for making that module all ... dynamic |
| 20:09.21 | russellb | :-p |
| 20:09.26 | russellb | you probably can't do what i just said ... |
| 20:09.58 | russellb | how about this. run ast_string_fields_init() inside func_odbc, and use ast_stringfield_set() |
| 20:10.04 | russellb | and then also destroy the stringfields inside of func_odbc |
| 20:10.05 | Corydon76-dig | russellb: Heh, I like that one block of code controls what could be hundreds of functions |
| 20:10.06 | russellb | that should work |
| 20:10.20 | russellb | Corydon76-dig: I do, too. I think it's great :) i'm just trolling |
| 20:10.29 | Corydon76-dig | I know. ;-) |
| 20:11.08 | russellb | eliel: did that make sense? |
| 20:11.30 | eliel | russellb: yes, i will treat that functions as if they where loaded from xml |
| 20:12.05 | russellb | cool :) |
| 20:34.22 | eliel | russellb: done :-) at least the other functions are working, I will need to test func_odbc.so but don't know how |
| 20:34.36 | putnopvut | Can someone familiar with chan_dahdi explain to me what the AST_STATE_DIALING means? The comment in channel.h isn't especially helpful. I am asking this because of issue 13736 |
| 20:34.38 | putnopvut | M13736 |
| 20:34.41 | MuffinMan | [confirmed] [Asterisk] PBX/General 0013736: [patch] Answer() doesn't when the state is Dialing reported by smurfix (Karma: +6.25) http://bugs.digium.com/view.php?id=13736 |
| 20:36.23 | *** join/#asterisk-dev moy (n=moy@189.169.79.64) |
| 20:40.25 | eliel | Corydon76-dig: how i can test func_odbc runtime functions? is there a simple way? |
| 20:42.48 | Corydon76-dig | eliel: define simple |
| 20:43.02 | Corydon76-dig | eliel: you need to set up an ODBC connection |
| 20:43.35 | eliel | ok, that is not simple, hehe i will start seting up the enviroment |
| 20:44.13 | Corydon76-dig | Then you add the connection pool in res_odbc.conf, then you use one of those connections to set up a query in func_odbc.conf, then you call that function in extensions.conf, then you place a call, which hits that extension |
| 20:44.40 | eliel | Corydon76-dig: that will help me! |
| 20:45.21 | Corydon76-dig | eliel: once you've done it a few times, it seems very simple. |
| 20:46.04 | eliel | let me try |
| 20:46.53 | Corydon76-dig | eliel: but what you really want to test is probably just the docs... which means define a function in func_odbc.conf, then reload, then "core show function ODBC_WHATEVER" |
| 20:47.13 | eliel | hey!! that is simple! :-) |
| 20:48.19 | Corydon76-dig | eliel: although a command line function to test func_odbc wouldn't be a bad idea, either |
| 20:53.37 | eliel | Corydon76-dig: thanks! |
| 20:54.34 | jsmith | There are instructions for setting up ODBC in doc/odbc_voicemail_with_pgsql.txt (or something close to that) |
| 21:07.01 | eliel | thanks jsmith |
| 21:07.55 | jsmith | No worries |
| 21:08.01 | jsmith | is always happy to help |
| 21:10.48 | russellb | Corydon76-dig: we could have a CLI command that evaluates a string using global vars / dialplan functions ... |
| 21:11.09 | russellb | that would allow you to test func_odbc, among a number of other things |
| 21:11.25 | russellb | shrugs |
| 21:11.26 | russellb | just a thought |
| 21:11.48 | russellb | that could be helpful in dialplan development, too |
| 21:11.59 | russellb | an easy way to see if you have something written the right way |
| 21:14.58 | eliel | we only need to decide if libxml2 will be mandatory or not |
| 21:15.13 | russellb | votes no |
| 21:15.13 | Corydon76-dig | russellb: Thought of that, but that doesn't allow function writes |
| 21:15.35 | russellb | Corydon76-dig: ah, yeah, you're right ... though there is already "core set global" or whatever |
| 21:15.57 | russellb | core set global MY_WRITABLE_FUNC(foo) meh |
| 21:16.04 | russellb | not the most obvious thing in the world, heh |
| 21:16.20 | Corydon76-dig | russellb: but I'd also like something that will optionally not execute the SQL |
| 21:16.32 | Corydon76-dig | Fill-in-the-blank, for debugging purposes |
| 21:16.34 | russellb | ah, ok, no general solution for that :) |
| 21:16.56 | eliel | ok, based on russellb (counting as +10) I will continue with showing a big message warning after running configure if libxml2 is not installed |
| 21:17.09 | russellb | i'm honored to have +10, heh |
| 21:17.39 | russellb | i think it makes good sense though ... for some embedded thing where nobody is ever going to look at built-in docs, they don't have to be included |
| 21:17.44 | russellb | and asterisk gets a little bit smaller :) |
| 21:18.17 | ctooley | I'd suggest that we "fail" if libxml2 is not installed, but with a helpful message that says, "If you understand that you will have no documentation you can pass --without-docs to have configure complete" |
| 21:18.51 | eliel | ok, we have a disagreement here |
| 21:19.20 | ctooley | 's suggestions are usually on a +0.001 scale though |
| 21:20.02 | russellb | well, that's not a bad idea, either |
| 21:20.48 | ctooley | I just usually don't like the default to be that there's no help. And let's face it, no one that uses those docs is going to pay attention to the warning after configure either. |
| 21:21.02 | russellb | ctooley: ok, now i'm convinced. |
| 21:21.15 | russellb | I like that approach now :) |
| 21:21.17 | eliel | hey! that was easy |
| 21:21.22 | eliel | ok |
| 21:21.41 | ctooley | ducks out of the way before assignment of the task gets done. |
| 21:22.19 | russellb | hehe |
| 21:22.48 | eliel | --without-xmldoc (??) |
| 21:22.59 | lmadsen | +1 |
| 21:23.10 | outtolunc | that docs only, or including cli help |
| 21:23.21 | ctooley | russellb, on another note, I like the review board. The font appears a bit large and so there's a lot of scrolling involved, but overall, definitely +1 |
| 21:23.23 | russellb | eliel: sure, i don't care what it's called |
| 21:23.30 | russellb | ctooley: cool :) |
| 21:23.42 | russellb | ctooley: i've seen some mention of a UI re-write ... but no info beyond that .. |
| 21:23.44 | ctooley | eliel, are there non-xml docs that are going to be generated? |
| 21:23.47 | russellb | i'm actually happy with how it is |
| 21:23.55 | lmadsen | needs a monitor |
| 21:24.04 | russellb | ctooley: from the CLI, it will appear like it does now |
| 21:24.08 | russellb | in a human readable form |
| 21:24.12 | eliel | ctooley: yes, all the functions with the old fashion |
| 21:24.37 | ctooley | eliel, I specifically meant, if there's no libxml2. The CLI docs will still work? |
| 21:24.49 | eliel | ctooley: yeaph |
| 21:24.52 | ctooley | ah, ok |
| 21:25.02 | ctooley | then, yeah, --without-xmldoc |
| 21:25.21 | eliel | or --disable-xmldoc |
| 21:25.42 | ctooley | whichever way is the same verbage as other things in the configure script. |
| 21:25.45 | russellb | heh |
| 21:25.48 | russellb | there is some of both :-p |
| 21:26.01 | ctooley | which way is "the new preferred" way? |
| 21:26.08 | russellb | doesn't care |
| 21:26.13 | russellb | for libs, it's with/without |
| 21:26.30 | russellb | for other stuff ... well, i can't remember how much other stuff there is |
| 21:26.32 | russellb | --enable-dev-mode |
| 21:26.53 | russellb | looks like enable/disable is used for optional "features" |
| 21:26.57 | russellb | and with/without for packages |
| 21:27.00 | russellb | so, go with disable |
| 21:27.52 | russellb | SO ... if anyone is bored, try to do an svn checkout on http://svnhotblack.digium.com/svn/ |
| 21:28.04 | russellb | is about to switch over the public svn mirror to that server |
| 21:28.28 | ctooley | svnhotblack? |
| 21:28.59 | eliel | no dns |
| 21:29.13 | eliel | resolving it |
| 21:29.14 | russellb | heh, it's just a dns entry so i can specify which mirror i want to use, and i haven't pointed "svn" at it yet |
| 21:29.22 | russellb | eliel: ah, it was just recently added ... |
| 21:29.30 | ctooley | has tried, no love for svnhotblack |
| 21:29.37 | russellb | dns? |
| 21:29.42 | ctooley | russellb, yup |
| 21:29.44 | russellb | k |
| 21:29.48 | russellb | needs to be patient |
| 21:29.58 | russellb | that'll give me time to set up viewvc ... |
| 21:33.43 | *** join/#asterisk-dev anthm (n=anthm@freeswitch/developer/anthm) |
| 21:34.25 | *** join/#asterisk-dev mog (n=mog@nat/digium/x-2762c94b636575fe) |
| 21:34.26 | *** mode/#asterisk-dev [+o mog] by ChanServ |
| 21:59.03 | *** join/#asterisk-dev jsolis (n=jimmy@190.232.181.63) |
| 22:00.49 | *** join/#asterisk-dev DarkRift (n=dark@65.92.171.227) |
| 22:07.50 | eliel | configure 1 vs 0 eliel |
| 22:09.27 | bkruse | eliel: Heh, trying to add something to the configure script? |
| 22:09.41 | eliel | yes |
| 22:11.03 | ctooley | russellb, still no love for the dns entry of svnhotblack. |
| 22:14.08 | russellb | lamezorz |
| 22:15.26 | jsmith | tzafrir_laptop: You around? |
| 22:16.09 | jsmith | tzafrir_laptop: Just wanted to discuss the i18n/l10n stuff with you, now that I'm done teaching for the day |
| 22:16.23 | jsmith | tzafrir_laptop: If you're asleep/busy/not around, I'll try to catch you another time |
| 22:30.48 | putnopvut | I hate to be irritating, but last time I asked this, there was a lot of other talk going on so this may have gotten lost in the noise. What does the state AST_STATE_DIALING actually mean? I'm asking this because of issue 13736. |
| 22:31.26 | putnopvut | It appears to only be used by DAHDI channels, and since I'm not that familiar with chan_dahdi, I would like to know if someone has a quick answer before diving into the code to try to figure it out on my own. |
| 22:31.55 | file | putnopvut: I think it is for when chan_dahdi is dialing out a channel |
| 22:32.06 | russellb | yeah, something like that.... |
| 22:32.14 | russellb | i'd have to read chan_dahdi to remember exactly |
| 22:32.20 | russellb | but that's the only channel driver that uses that state IIRC |
| 22:32.26 | putnopvut | So it's kind of like a state that would happen before AST_STATE_RING |
| 22:32.49 | putnopvut | So then it should be possible to Answer a channel that is in the state AST_STATE_DIALING. |
| 22:35.26 | jsmith | putnopvut: As I understand it (and trust me, I don't)... it's in the AST_STATE_DIALING while it's sending inband audio of the number being dialed |
| 22:35.44 | jsmith | (In other words, after it goes off-hook and before it's done dialing the number) |
| 22:36.03 | jsmith | chan_sip and chan_iax2 obviously don't have that state, as dialing is done out-of-band and not in-band |
| 22:36.19 | russellb | that would make sense |
| 22:39.56 | *** part/#asterisk-dev russellb (n=russellb@asterisk/digium-open-source-team-lead/russellb) |
| 22:44.15 | putnopvut | Thanks for the feedback, fellas! |
| 22:48.46 | eliel | configure 2 vs 0 eliel |
| 22:50.17 | eliel | is there any reason why AC_ARG_ENABLE exist but AC_ARG_DISABLE appears to not be defined? |
| 22:54.10 | seanbright | eliel: because it doesn't exist |
| 22:54.20 | seanbright | there is no AC_ARG_DISABLE in autoconf |
| 22:55.29 | eliel | seanbright: how I could implement a --disable-FEATURE param to configure |
| 22:56.12 | seanbright | AC_ARG_ENABLE([something], [ --disable-something Something something something], ... |
| 22:56.25 | seanbright | and you just default the option to being in |
| 22:56.26 | seanbright | err |
| 22:56.33 | seanbright | you default the option to being *on* |
| 22:57.18 | eliel | AC_ARG_ENABLE([something], [ --disable-something Something something something], TRUE, FALSE) is this the correct syntax? |
| 22:57.28 | *** join/#asterisk-dev schmooze (n=schmooze@rrcs-67-52-214-19.west.biz.rr.com) |
| 22:57.29 | eliel | or just AC_ARG_ENABLE([something], [ --disable-something Something something something], CHECK) |
| 22:57.54 | seanbright | there are examples of --enable in configure.ac in trunk |
| 22:58.07 | seanbright | you would just, effectively, reverse the logic |
| 22:59.31 | eliel | it is not that simple I tried but when doing things like --disable-feature=no things go wrong.. when no passing parameter is an easy task, the problem is that parameter appear |
| 22:59.42 | seanbright | pastebin what you've done |
| 23:01.56 | eliel | http://pastebin.com/d3385bb07 |
| 23:02.20 | seanbright | first thing... line 1 |
| 23:02.25 | seanbright | change [dev-mode] to [xmldoc] |
| 23:03.08 | eliel | sorry, cause i wrote it quicly to pastebin |
| 23:03.10 | seanbright | line 8, change from: |
| 23:03.16 | eliel | I was trying other things |
| 23:03.16 | seanbright | esac]) |
| 23:03.17 | seanbright | to |
| 23:03.31 | seanbright | esac], [disable_xmldoc=no]) |
| 23:04.26 | eliel | testing |
| 23:09.33 | eliel | the last parameter is the default value if the parameter is not passed to configure? |
| 23:09.40 | seanbright | correct |
| 23:10.40 | seanbright | did it work? |
| 23:12.27 | eliel | I think so |
| 23:12.32 | eliel | thanks!! |
| 23:12.37 | seanbright | no problem. |
| 23:13.02 | seanbright | might be weird if you pass --enable-xmldoc |
| 23:13.10 | seanbright | which will also be recognized |
| 23:13.15 | seanbright | good luck with that one |
| 23:13.16 | seanbright | heh |
| 23:14.14 | eliel | ups |
| 23:39.21 | *** join/#asterisk-dev Corydon76-dig (i=indigo@pdpc/supporter/bronze/Corydon76-home) |
| 23:39.21 | *** mode/#asterisk-dev [+o Corydon76-dig] by ChanServ |
| 23:57.26 | *** part/#asterisk-dev Deeewayne (n=Deeewayn@nat/digium/x-22e1c244bf556a59) |