| 00:00.00 | snuff-work | could always just add another atlassian product.. crucible.. that does code review works with git etc |
| 00:23.28 | sruffell | email ftw: https://plus.google.com/u/0/111049168280159033135/posts/ReFS19DZNYD |
| 00:23.36 | sruffell | datachomper sent me that link this morning. |
| 00:26.46 | snuff-work | heh like this comment.. Gerrit is evil, prevents code-review and nice discussions. Moreover you miss the funniest part of development: "healthy insults on a mailing list" :) |
| 00:27.08 | snuff-work | healthy insults ;) |
| 00:27.25 | sruffell | heh |
| 00:30.39 | sruffell | I started to write a reply to asterisk-dev on why I like email-based workflows… but then didn't send it since I know I'm in the minority on this issue and since I don't really send in patches to Asterisk so much, thought it better just to keep my opinions to myself. http://dl.dropbox.com/u/57606151/email-based-workflows.txt |
| 00:33.48 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 00:33.48 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 00:34.07 | snuff-work | mm that reminds me.. need to test out skinny patches sometime today |
| 00:34.27 | snuff-work | first need to go fisty cuffs with zoho crm/support |
| 01:07.46 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 01:07.46 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 01:10.19 | *** join/#asterisk-dev mjordan (~mjordan@216.186.152.216) |
| 01:10.19 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 01:36.22 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 01:36.22 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 01:49.09 | *** join/#asterisk-dev mjordan (~mjordan@216.186.152.216) |
| 01:49.09 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 02:43.20 | *** join/#asterisk-dev mjordan (~mjordan@216.186.152.216) |
| 02:43.20 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 02:49.37 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 02:49.37 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 03:03.24 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 03:03.24 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 03:57.04 | *** join/#asterisk-dev drmessano (~nonya@pdpc/supporter/active/drmessano) |
| 04:36.20 | *** join/#asterisk-dev mjordan (~mjordan@216.186.152.216) |
| 04:36.20 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 06:43.15 | *** join/#asterisk-dev oej (~olle@2001:16d8:cc57:1000::42:1004) |
| 06:43.15 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 07:17.57 | snuff-work | file: found error with sorcery.. when trying to compile with debug FD leaks.. |
| 07:18.29 | snuff-work | sorcery.c:366: error: âstruct ast_sorcery_wizardâ has no member named '__ast_fdleak_close' / '__ast_fdleak_open'' |
| 07:19.05 | snuff-work | *disappears for few hrs* |
| 07:33.57 | *** join/#asterisk-dev bulkorok (~bulkorok@85.183.36.36) |
| 08:08.33 | *** join/#asterisk-dev oej (~olle@h87-96-134-129.dynamic.se.alltele.net) |
| 08:08.34 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 08:08.48 | *** join/#asterisk-dev oej_ (~olle@2001:16d8:cc57:1000::42:1005) |
| 08:08.48 | *** mode/#asterisk-dev [+o oej_] by ChanServ |
| 08:45.03 | oej | Good morning folks |
| 08:50.47 | *** join/#asterisk-dev hehol (~hehol@2001:1438:1009:200:1cb7:2a53:8c57:4caf) |
| 09:03.14 | *** join/#asterisk-dev alsuren_ (~dlaban@188-221-138-117.zone12.bethere.co.uk) |
| 09:10.32 | *** join/#asterisk-dev tzafrir_laptop (~tzafrir@local.xorcom.com) |
| 09:10.41 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 09:13.54 | *** join/#asterisk-dev WIMPy (~wimpy@e183095026.adsl.alicedsl.de) |
| 12:32.19 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-hdmisgiurexixeqp) |
| 12:32.19 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 12:50.14 | *** join/#asterisk-dev seanbright (~sean@asterisk/contributor-and-bug-marshal/seanbright) |
| 12:50.14 | *** mode/#asterisk-dev [+o seanbright] by ChanServ |
| 13:14.08 | *** part/#asterisk-dev mjordan (~mjordan@nat/digium/x-hdmisgiurexixeqp) |
| 13:45.02 | *** join/#asterisk-dev hurdman (~ygcheny@c3p0.r0b0t.fr) |
| 13:47.47 | hurdman | can anyone says to me the better way to make a sleep into an asterisk 1.6.20 module ( i know using 1.6.20 is bad, but i haven't enough time to migrate all to 11 right now ), i use ast_safe_sleep( but sometimes i have got a segfault on ast_readaudio_callback if (s->owner->timingfd > -1) { ... any idea ? |
| 13:50.50 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 13:50.50 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 13:55.25 | *** join/#asterisk-dev serafie (~erin@nat/digium/x-qedhgjbexwlhtcyv) |
| 14:19.34 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-fwogogrjnadwpqlc) |
| 14:19.34 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 14:23.11 | *** join/#asterisk-dev kpfleming (4173e21c@gateway/web/freenode/ip.65.115.226.28) |
| 14:34.08 | *** join/#asterisk-dev coreyf1513 (~coreyf151@108.244.237.92) |
| 14:48.00 | mjordan | interesting tidbit: bamboo runs 194 tests for 1.8; 296 tests for 11; 370 for trunk. |
| 14:57.30 | leifmadsen | is nice |
| 14:58.04 | mjordan | if you're going to break the world, you're going to need something telling you how broke it is :-D |
| 15:10.28 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 15:10.28 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 15:25.50 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 15:25.50 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 15:31.20 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 15:31.20 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 15:53.07 | sruffell | tzafrir_laptop: should I be able to clone http://git.tzafrir.org.il/git/dahdi-linux.git ? I'm getting fatal: http://git.tzafrir.org.il/git/dahdi-linux.git/info/refs?service=git-upload-pack not found: did you run git update-server-info on the server? |
| 15:53.33 | sruffell | since the switch I haven't added your repo as a remote yet so I was just getting around to doing that. |
| 15:54.39 | tzafrir_laptop | Problem with the server config ... |
| 15:54.49 | sruffell | is that your "master" wip repo? |
| 15:55.07 | sruffell | or should I be using another one? (or do you want to send me your public key and I'll add an account on git.asterisk.org for you if you want) |
| 15:59.58 | tzafrir_laptop | Should work now |
| 16:00.22 | tzafrir_laptop | and now, it's not updated automatically |
| 16:01.48 | sruffell | hmm….and it's slow here….I think since the protocol is http it's downloading a large pack... |
| 16:02.03 | sruffell | maybe I'll hold off adding that as a remote. |
| 16:02.42 | tzafrir_laptop | ssh key sent |
| 16:55.05 | mjordan | putnopvut: r.e. your bridge tests |
| 16:55.24 | mjordan | putnopvut: how would you feel about #including the extensions-extra.conf below the [default] context in alice/bob? |
| 17:06.01 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 17:22.31 | *** join/#asterisk-dev jmls (~somefake@109.68.14.110) |
| 17:23.03 | *** join/#asterisk-dev oej_ (~olle@h87-96-134-129.dynamic.se.alltele.net) |
| 17:23.03 | *** mode/#asterisk-dev [+o oej_] by ChanServ |
| 17:25.07 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 17:25.07 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 17:32.24 | *** join/#asterisk-dev oej (~olle@2001:16d8:cc57:1000::42:1004) |
| 17:32.24 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 17:34.41 | jmls | has anyone reported language bugs in a waitexten extension ? |
| 17:35.13 | jmls | playback(foo) works in the s exten, but doesn't in an extension selected by the user |
| 17:35.41 | jmls | exten => s,1,playback(foo) works |
| 17:36.03 | jmls | exten => 1,1,playback(foo) doesn't |
| 17:36.09 | jmls | asterisk 11 |
| 17:37.11 | jmls | (foo is a gsm file in the "sounds/custom" directory. set(CHANNEL(language)=custom)) is just before the waitexten |
| 17:46.14 | jmls | pastebin of extension and dir listing http://pastebin.com/Pc8tZHAq |
| 17:48.26 | pabelanger | jmls, change your order |
| 17:48.33 | pabelanger | move S,1,Answer to the top |
| 17:49.08 | pabelanger | or asterisk is not detecting dtmf |
| 17:50.25 | jmls | dtmf is detected - it jumps to option (3) for example, but then says |
| 17:50.28 | jmls | [Jan 29 17:30:03] WARNING[12759][C-0000007a]: file.c:698 ast_openstream_full: File promptrecord does not exist in any format |
| 17:50.50 | jmls | I will change order though and check |
| 17:51.17 | pabelanger | jmls, this belongs in #asterisk too |
| 17:51.21 | pabelanger | you have a dialplan issue |
| 17:51.26 | pabelanger | drop the gsm from your extensions.conf |
| 17:51.33 | pabelanger | exten => 9,1,set(new_file=/var/lib/asterisk/sounds/custom/${prompt}.gsm) |
| 17:51.35 | pabelanger | is wrong |
| 17:52.03 | pabelanger | actually |
| 17:52.11 | jmls | umm |
| 17:52.39 | pabelanger | Ya, my mistake |
| 17:52.42 | pabelanger | didn't see you recording |
| 17:52.47 | jmls | :) |
| 17:54.09 | pabelanger | exten => 3,1,Playback(custom/promptrecord) |
| 17:54.11 | pabelanger | try that |
| 17:55.43 | jmls | yeah. that worked. |
| 17:56.19 | jmls | *but* if I put playback(promptrecord) in the s extension, it also works |
| 17:56.51 | leifmadsen | maybe when you change extensions, output the current language and make sure it is still set? |
| 17:57.09 | pabelanger | sounds like path issues |
| 17:57.30 | leifmadsen | pabelanger: well he is changing the language, which is supposed to be used from the /var/lib/asterisk/sounds/<lang> directory |
| 17:57.33 | leifmadsen | which he showed as existing |
| 17:57.56 | pabelanger | ya |
| 17:58.02 | pabelanger | I'd just appent custom to my prompts |
| 17:58.08 | pabelanger | then you don't have to change the language |
| 17:59.42 | leifmadsen | still sounds like it could be a bug though |
| 17:59.54 | leifmadsen | I'd want to see if the language changed after entering an extension for some reason |
| 18:00.51 | pabelanger | Could be |
| 18:01.09 | pabelanger | but be faster just to prepend custom in jmls case |
| 18:01.30 | leifmadsen | possibly unless he wants to actually build in some language support |
| 18:01.48 | leifmadsen | then you don't have to track the prefixed path all over the place |
| 18:03.27 | jmls | exten => 3,1,Verbose(${CHANNEL(language)}) |
| 18:03.39 | jmls | hmm. gives me "en" ... :( |
| 18:03.46 | leifmadsen | well that seems off :) |
| 18:03.53 | jmls | right |
| 18:04.18 | leifmadsen | hold on, I'll try the same test on my system |
| 18:04.24 | jmls | thanks |
| 18:05.05 | jmls | hmm. I am using a local channel to get to this context/extension |
| 18:05.20 | leifmadsen | oh there you go |
| 18:05.37 | jmls | yeah |
| 18:05.43 | leifmadsen | well, the CHANNEL(language) is set in the Local right? |
| 18:05.57 | jmls | i'll check |
| 18:06.12 | pabelanger | set(_CHANNEL(blah)) |
| 18:06.12 | leifmadsen | like, you're not doing a Local channel after setting are you? |
| 18:06.17 | pabelanger | see what happens |
| 18:06.20 | leifmadsen | does that actually work with functions? |
| 18:06.27 | file | no. |
| 18:06.31 | leifmadsen | didn't think so |
| 18:06.35 | pabelanger | shrugs |
| 18:07.02 | leifmadsen | Set(__thisLanguage=custom) |
| 18:07.03 | leifmadsen | Local --> |
| 18:07.32 | leifmadsen | ExecIf($[${EXISTS(${thisLanguage})}]?Set(LANGUAGE(channel)=${thisLanguage}) |
| 18:07.33 | leifmadsen | or something |
| 18:07.40 | pabelanger | ya |
| 18:08.34 | jmls | _channel didn't work |
| 18:09.32 | pabelanger | sounds like variables are getting lost of something |
| 18:09.36 | jmls | this is called from manager api using originate |
| 18:09.54 | pabelanger | do a DumpChan() after you set CHANNEL(language) and after you get DTMF |
| 18:10.38 | jmls | pabelanger sorry, in which extension ? 3 (for example) ? |
| 18:10.43 | pabelanger | ya |
| 18:12.49 | jmls | http://pastebin.com/Vs351Z95 |
| 18:13.39 | pabelanger | which dump is that? |
| 18:13.47 | pabelanger | should have 2 |
| 18:14.21 | Corydon76-home | seanbright: ping |
| 18:14.35 | jmls | exten => 3,1,DumpChan() |
| 18:14.38 | jmls | same => n,Playback(hash42/hash42_promptrecord) |
| 18:15.15 | jmls | hash42 == custom |
| 18:17.14 | *** join/#asterisk-dev oej (~olle@h87-96-134-129.dynamic.se.alltele.net) |
| 18:17.14 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 18:17.48 | pabelanger | jmls, do a chandump after you set the channel language too |
| 18:17.51 | pabelanger | and compare them |
| 18:20.18 | Corydon76-home | jmls: after the Local split, do a Set(CHANNEL(language)=${MASTER_CHANNEL(CHANNEL(language))}) |
| 18:22.44 | seanbright | Corydon76-home: sir |
| 18:23.52 | jmls | grr. going to have to give up for tonight, gotta go out with a client. thanks _so_ much for all the help - I'll put together a simple dialplan showing the issue later in the week |
| 18:24.05 | jmls | thanks again. I'll put in the workaround in the meantime |
| 18:24.26 | Corydon76-home | seanbright: was just thinking, if you're doing that much work on chan_iax2, might do the other work of making callnos equally dependent upon the remote IP address |
| 18:25.02 | Corydon76-home | So instead of having a maximum 32k setups, you instead have a maximum of 32k setups per IP address |
| 18:25.16 | seanbright | i had thought of that, but wasn't trying to make that much of a sweeping change. |
| 18:25.52 | seanbright | assuming that patch does go in, i would probably have the callno by IP change on the short list of things i wanted to do |
| 18:26.05 | Corydon76-home | The only reason it wasn't done before is because it would require exactly the same type of change that you're making right now |
| 18:26.08 | seanbright | slightly higher on that list is timer per peer instead of timer per asterisk |
| 18:26.42 | Corydon76-home | Ah, that would be a good one, too |
| 18:27.55 | Corydon76-home | I was also thinking about a zero-state type of callno resolution by using a hash of the remote IP and offered callno, similar to SYN cookies |
| 18:28.31 | seanbright | you lost me a bit on that - can you explain? |
| 18:29.29 | Corydon76-home | One of the problems that we face, that we attempted to solve with the calltoken is an attacker flooding us with NEW packets. |
| 18:30.13 | Corydon76-home | What if we used the a hash of the remote IP address and its offered callno to determine our callno... we wouldn't have to keep state at all |
| 18:32.23 | seanbright | hmmm |
| 18:32.45 | seanbright | that's interesting |
| 18:33.09 | putnopvut | mjordan: sorry, I've been out, so didn't see your question until now. Would that force all of the extensions defined in extensions-extra.conf to be in the [default] context? |
| 18:33.12 | file | does any of that break native transfers? |
| 18:33.52 | mjordan | by default, yes, unless they define a new context |
| 18:36.06 | putnopvut | Oh, you mean below all the already-defined extensions in extensions.conf, not below the line with [default] |
| 18:37.01 | putnopvut | Why do you want to do it? |
| 18:40.24 | mjordan | alice/bob need a destination extension for a blind transfer |
| 18:40.37 | mjordan | that is, the blind transfer on the UUT wants to have something to Dial |
| 18:41.05 | mjordan | which is not strictly necessary but is probably good, as a blind transfer would (often) dial something else, and this tests that the blind transfer target actually gets bridged again |
| 18:41.19 | hurdman | can anyone says to me the better way to make a sleep into an asterisk 1.6.20 module ( i know using 1.6.20 is bad, but i haven't enough time to migrate all to 11 right now ), i use ast_safe_sleep( but sometimes i have got a segfault on ast_readaudio_callback if (s->owner->timingfd > -1) { ... any idea ? |
| 18:41.21 | mjordan | we could probably live without it however |
| 18:41.44 | putnopvut | I'm fine with the change. Just curious why it was needed. |
| 18:41.55 | mjordan | hurdman: why are you trying to sleep? |
| 18:42.06 | mjordan | and what is your module doing? |
| 18:44.39 | hurdman | mjordan: it's something like make a call, wait some seconds and make a second call to a different number before bridging the both calls |
| 18:45.27 | hurdman | sometimes, perhaps the firstcall hangup during the sleep, and it makes an segfault, or something like that |
| 18:45.45 | mjordan | you probably don't want ast_safe_sleep. If you want to put the channel safely into a waiting state, you should put it in autoservice |
| 18:46.01 | hurdman | autoservice ? |
| 18:46.24 | coreyf1513 | hurdman: why not call the built-in app Wait ? |
| 18:46.47 | mjordan | although that really should work... |
| 18:46.48 | mjordan | hm. |
| 18:47.39 | hurdman | i inherit the src coreyf1513 , so now, i have to make it a bit more stable ^^" |
| 18:48.06 | hurdman | mjordan: i read autoservice, and back if i have more problems, many thx |
| 18:48.19 | mjordan | although, if ast_readaudio_callback is set on the channel, then something is attempting to play a file on the channel while you're sleeping. So that's probably not good. |
| 18:48.27 | mjordan | /set/called |
| 18:48.59 | hurdman | mjordan: something like a waiting song before the bridge |
| 18:50.39 | mjordan | are you doing that while it's called into ast_safe_sleep? |
| 18:51.38 | *** join/#asterisk-dev kpfleming (4173e21c@gateway/web/freenode/ip.65.115.226.28) |
| 18:51.48 | hurdman | mjordan: mmh, i have to re-read the src, it's not mine so i haven't finished to understand all threads |
| 18:52.09 | hurdman | mjordan: but now, i know the direction :) |
| 18:54.11 | hurdman | many thx |
| 18:58.16 | mjordan | good luck |
| 18:58.34 | hurdman | :) |
| 19:05.34 | jsmith | sruffell: Is there a way to read the line voltage on an FXO port via DAHDI? |
| 19:05.54 | jsmith | sruffell: (trying to help debug some analog line issues for a friend) |
| 19:06.08 | sruffell | yes…if you set echo 1 > /sys/module/wctdm24xxp/parameters/fxovoltage every 100ms the voltage will be written to dmesg. |
| 19:06.45 | sruffell | The issue isn't a stuck red alarm on an FXO channel is it? |
| 19:06.59 | jsmith | sruffell: Funny you should say that... :-p |
| 19:07.11 | jsmith | sruffell: Still trying to figure it out, but it is in red alarm :-/ |
| 19:07.17 | sruffell | http://git.asterisk.org/gitweb/?p=team/sruffell/dahdi-linux.git;a=commit;h=41639330a59ea683cca0f6215a207a59a93f95bd |
| 19:07.31 | sruffell | ^^ could that commit (which is in 2.6.2-rc1) explain what you're seeing? |
| 19:07.53 | jsmith | OK, good to know |
| 19:08.04 | jsmith | This is a remote box, so I'm not confident they actually have it plugged in :-/ |
| 19:08.11 | sruffell | rerunning dahdi_cfg -vvf should clear the condition if that's it. |
| 19:08.25 | sruffell | (without reloading the driver) |
| 19:08.39 | sruffell | since that resets the state of the battery in the driver. |
| 19:08.59 | jsmith | Makes sense |
| 19:09.42 | jsmith | May I humbly suggest that the line voltage be able to be queried (one-shot) from a command-line utility? |
| 19:09.59 | jsmith | Might be a bit easier to find than catting random numbers in /sys :-p |
| 19:12.13 | sruffell | considered it suggested. I actually think there is something…. /me looks |
| 19:15.17 | sruffell | jsmith: yes..fxstest (I know, great name) will give you that information on FXO ports: |
| 19:15.20 | sruffell | # ./fxstest /dev/dahdi/channels/3/1 stats |
| 19:15.20 | sruffell | TIP: -42.0000 Volts |
| 19:15.20 | sruffell | RING: -42.0000 Volts |
| 19:15.20 | sruffell | VBAT: -43.0000 Volts |
| 19:15.31 | sruffell | fxstest is in dahdi-tools |
| 19:15.36 | jsmith | sruffell: Ah, cool... |
| 19:16.20 | sruffell | And if I disconnect: |
| 19:16.22 | sruffell | # ./fxstest /dev/dahdi/channels/3/1 stats |
| 19:16.22 | sruffell | TIP: 1.0000 Volts |
| 19:16.22 | sruffell | RING: 0.0000 Volts |
| 19:16.22 | sruffell | VBAT: 1.0000 Volts |
| 19:19.14 | tzafrir_laptop | jsmith, with xpp you have it in a proc interface (though only for the FXO interface) |
| 19:20.23 | tzafrir_laptop | I wonder if it makes sense stuffing this information to sysfs somehow |
| 19:20.41 | sruffell | I was just thinking " I wonder if I should dig out those debugfs patches" heh. |
| 19:20.51 | sruffell | I still would like to expose the hi-z stuff through that. |
| 19:21.07 | jsmith | high-z, w00t! |
| 19:22.06 | sruffell | jsmith: Unfortunately, it's only good for testing without a change to Digium's PCBs. But I was using it to automate the process of "unplugging" cables. |
| 19:22.09 | tzafrir_laptop | Last call for volunteers: anyone here with an old Tormenta(sp?) card to test a patch for tor2.c? |
| 19:22.11 | sruffell | without hooking up relays. |
| 19:22.49 | sruffell | no tormenta here... |
| 19:23.06 | leifmadsen | for those not in #asterisk.... |
| 19:23.07 | leifmadsen | fyi, Asterisk: The Definitive Guide 4e (based on Asterisk 11 LTS) is due to be submitted to O'Reilly on Thursday morning. Those who are interested in reviewing the book on OFPS have a last shot to do it tomorrow. The book review is available at http://ofps.oreilly.com/titles/9781449332426/ |
| 19:27.37 | file | mjordan, oh snap I forgot about OPTIONS support |
| 19:31.12 | kpfleming | OPTIONS is overrated |
| 19:31.47 | leifmadsen | also, please make it better than what is implemented now :) |
| 19:32.09 | mjordan | leifmadsen: cool :-) |
| 19:32.36 | mjordan | file: did you post something someplace? |
| 19:32.44 | file | no? |
| 19:32.50 | mjordan | ah |
| 19:32.55 | file | I just updated/ran things and saw an incoming OPTIONS get a 404 |
| 19:32.59 | mjordan | ah |
| 19:32.59 | mjordan | heh |
| 19:33.09 | mjordan | great success? |
| 19:33.29 | file | yes |
| 19:34.04 | mjordan | huzzah |
| 19:34.23 | file | well, I mean, it works :P |
| 19:37.50 | snuff-home | file: did u see my msg bout 12 hrs ago about sourcery and 'debug FD flags' |
| 19:37.57 | file | no |
| 19:38.36 | snuff-home | sorcery.c:366: error: âstruct ast_sorcery_wizardâ has no member named '__ast_fdleak_close' / '__ast_fdleak_open'' |
| 19:39.34 | file | what the. |
| 19:40.20 | file | oh that's pleasant |
| 19:40.24 | file | it #defines open |
| 19:41.10 | snuff-home | i have no idea.. the wonderful a with hats is cause i haven't set my puTTY to utf8 when term is utf8.. really need to set my term to be C instead.. |
| 19:41.31 | snuff-home | on the host.. |
| 19:45.36 | file | hum hum hum |
| 20:15.28 | *** join/#asterisk-dev snuff-home (~snuffy@203-219-29-182.tpgi.com.au) |
| 20:15.28 | *** mode/#asterisk-dev [+o snuff-home] by ChanServ |
| 20:16.58 | sruffell | Qwell: should I reopen ASTERISK-20703? I was just talking about being able to run bisect, and if menuselect can at least be added to trunk the easier it will be for people to bisect Asterisk when looking for problems that showed up between now and when Asterisk 12 is released. |
| 20:19.36 | file | snuff-home, fixed |
| 20:20.02 | snuff-home | file rox :) |
| 20:20.51 | Qwell | sruffell: It can be done when we move to git - doing so beforehand was just going to be a shortcut. |
| 20:22.31 | sruffell | not a shortcut…a way to ease people into it…anyone who is building off of trunk can just delete menuselect. It was a huge help to have the externals out of the subversion tree for DAHDI and nobody complained about having to delete it…. I think it will minimize the changes that people will see all at once, while making this history right now easier to use in the future *without* requiring people to switch to git right now.. |
| 20:24.34 | Qwell | sruffell: There have been 2 changes in the last 365 days. |
| 20:24.46 | Qwell | (1, in 363 days) |
| 20:24.57 | sruffell | in menuselect? |
| 20:25.01 | Qwell | correct |
| 20:25.43 | sruffell | and? Sounds like it's relatively static….won't be a huge burden (and probably the majority of changes are for new things..not things that would need to be put on a branch)? |
| 20:26.35 | Qwell | The benefit is zero. Everybody that updates (which is a significant number of people) will need to know how to clean their tree when it breaks. |
| 20:27.01 | Qwell | weighing the two makes the choice pretty clear to me |
| 20:27.23 | sruffell | Ahh the benefit is not zero. When Asterisk switches to git, are you going to provide a way to build older versions without adding back in the external on the release tags? The sooner that goes in, the better. |
| 20:27.48 | sruffell | having gone through this before make the benefit of *adding* it in clear to me... |
| 20:27.49 | Qwell | Yes. The external will be replaced, even on old tags. |
| 20:28.53 | sruffell | ok….I won't reopen it…but in general, the more you can do to allow people to start using it now…the less problems you have when it's time to swtich. Moving menuselect in now will ease the transition. |
| 20:28.58 | sruffell | IMO |
| 20:30.29 | sruffell | mjordan: just FYI… ^^ |
| 20:31.41 | mjordan | sruffell: completely agree. What does DAHDI switch to git? |
| 20:31.44 | mjordan | completely |
| 20:31.49 | sruffell | especially since figuring out that removing menuselect should be relatively easy for the developers who are working off of trunk to figure out. Just leaving the branches as is seems ok to me. |
| 20:31.59 | sruffell | DAHDI is switched (Tools is still in process...) |
| 20:32.07 | mjordan | k |
| 20:32.34 | mjordan | what is keeping tools in process? |
| 20:33.12 | sruffell | Writing the script to handle menuselect….heh….since that came out way later…and datachomper and I figured we should be able to go back to 2.4.0 release. |
| 20:33.19 | snuff-home | leifmadsen: looking through some of ur book.. very thorough.. (looked only at parking/conf section) |
| 20:33.27 | sruffell | oct612x was taken out of DAHDI then…. menuselect was much later…adds a complication. |
| 20:33.33 | sruffell | menuselect from tools that is. |
| 20:34.01 | leifmadsen | snuff-home: w00t! :) |
| 20:35.11 | snuff-home | really like the nice touch of the features map section.. listing what Dial options correspond to what option.. i forget that 1/2 the time :) |
| 20:35.45 | tm1000 | mjordan: sruffell whoooo excited for the git switch :) |
| 20:36.31 | snuff-home | still haven't gotten used to same => tag |
| 20:36.43 | leifmadsen | snuff-home: I <3 same => |
| 20:39.53 | tm1000 | snuff-home: Does digium have a github account. I see yours. |
| 20:40.18 | snuff-home | i have no idea.. i think u mean sruffell :) |
| 20:40.29 | sruffell | github.com/asterisk |
| 20:40.38 | sruffell | is the Asterisk projects… Digium the company does not maintain one. |
| 20:40.53 | leifmadsen | someone needs to upload high res graphic :) |
| 20:40.54 | tm1000 | Ok |
| 20:40.54 | sruffell | http://git.asterisk.org is the Digium official git server. |
| 20:41.02 | tm1000 | Nice |
| 20:41.23 | sruffell | leifmadsen: +1 russellb mentioned that before as well…. I don't know who has the keys to the Gravatar account... |
| 20:41.54 | tm1000 | snuff-home: Ya I meant sruffell. Whoops :) |
| 20:42.46 | leifmadsen | wonders why he can't follow asterisk.... |
| 20:43.00 | leifmadsen | guess just the repos themselves |
| 20:46.27 | *** join/#asterisk-dev tzafrir_laptop (~tzafrir@212.179.75.202) |
| 20:46.27 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 21:10.25 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 21:10.25 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 21:10.30 | sruffell | tm1000: are you alantham? |
| 21:12.05 | pabelanger | I'm Spartacus |
| 21:12.17 | sruffell | you're not going to kick me into a well are you? |
| 21:12.19 | file | sruffell, he is not |
| 21:12.43 | sruffell | makes note in irc <-> mailing list cross reference |
| 21:19.18 | *** join/#asterisk-dev coreyf1513 (~coreyf151@108.244.237.92) |
| 22:01.44 | mjordan | opticron: jrose_atDigium: how have you been generating your YAML for the CEL verification? |
| 22:02.17 | jrose_atDigium | mjordan: The painful way. By hand. |
| 22:02.52 | jrose_atDigium | I'm not sure if there is a better way to do it. |
| 22:03.12 | mjordan | hm |
| 22:03.18 | mjordan | well, I wrote a script that dumps YAML |
| 22:03.24 | mjordan | but it still needs a bit of formatting love |
| 22:03.35 | mjordan | I'll check-it in, under the knowledge that you may want to still tweak it |
| 22:05.09 | *** join/#asterisk-dev rmeyerriecks (~rmeyerrie@nat/digium/x-wongxmyafwxzrvuz) |
| 22:07.08 | tzafrir_laptop | rmeyerriecks, hi |
| 22:08.12 | rmeyerriecks | tzafrir_laptop: Howdy |
| 22:09.11 | sruffell | whoah? rip datachomper. |
| 22:09.44 | tzafrir_laptop | I'm preparing a new minor release of dahdi. I wonder which of the patches in the 2.6.y branch should go in there |
| 22:09.54 | tzafrir_laptop | (low risk, useful) |
| 22:10.05 | tzafrir_laptop | I'm not familiar with most of them |
| 22:10.15 | sruffell | tzafrir_laptop: what's the problem with 2.6.2-rc1? |
| 22:10.20 | rmeyerriecks | tzafrir_laptop: did you see the recent -rc1 I put out? |
| 22:10.36 | rmeyerriecks | sruffell beat me to it, just like everything else |
| 22:10.38 | tzafrir_laptop | I managed to miss it |
| 22:10.46 | sruffell | http://git.asterisk.org/gitweb/?p=dahdi/linux.git;a=commit;h=41639330a59ea683cca0f6215a207a59a93f95bd |
| 22:11.26 | sruffell | speed high. accuracy low. |
| 22:11.42 | rmeyerriecks | https://github.com/asterisk/dahdi-linux/tree/v2.6.2-rc1 |
| 22:12.19 | tm1000 | sruffell: no. we *may* have meet though. especially if you went to astricon |
| 22:12.27 | sruffell | nods |
| 22:12.37 | sruffell | tm1000: Qwell set me straight. |
| 22:13.01 | sruffell | next year, tzafrir will be there. |
| 22:13.02 | tm1000 | sruffell: I went to the steakhouse with you all….im just a lowly freepbx programmer ;-) |
| 22:13.03 | tm1000 | ah |
| 22:13.07 | tzafrir_laptop | I'd try pushing to use that. Though I suppose the release twam would not approve |
| 22:13.09 | tm1000 | nice! |
| 22:14.05 | sruffell | The commits to DAHDI that Eran Gal said he would like to see to fund Tzafrir's trip were committed a few weeks ago.... |
| 22:14.10 | rmeyerriecks | tzafrir_laptop: I expected to drop the -rc1 by this weekend, although i'm not sure how far off dahdi-tools release is |
| 22:14.44 | tm1000 | next year I obviously have to put names to faces better |
| 22:14.45 | sruffell | tzafrir_laptop: do you need a dahdi-linux-complete tarball? If not…DAHDI-Linux could just be made final.... |
| 22:14.56 | rmeyerriecks | tm1000: sruffell is kind of a big deal |
| 22:14.57 | tm1000 | I can only remember, mjordan, file, Qwell and rusty |
| 22:15.10 | tm1000 | rmeyerriecks: I noticed :-) |
| 22:15.11 | tzafrir_laptop | dahdi-linux is what I need |
| 22:15.26 | tm1000 | though I don't know if rusty is even on irc... |
| 22:15.31 | Qwell | tm1000: newtonr |
| 22:15.33 | sruffell | tm1000: I'll need to wear a fake parrot or something on my shoulder in order to be more memorable. |
| 22:15.38 | tm1000 | Qwell: thanks |
| 22:15.43 | tm1000 | lol |
| 22:15.53 | tm1000 | sruffell: too many people in that restaurant…so many names |
| 22:16.01 | sruffell | heh..yeah... |
| 22:16.29 | mjordan | woot! I'm remembered! |
| 22:16.31 | sruffell | either a fake parrot or I'll wear parachute pants and carry a piece of cardboard from impromptu break dancing. |
| 22:16.36 | sruffell | s/from/for/ |
| 22:16.44 | tm1000 | sruffell: or wear a white hat? |
| 22:16.47 | tm1000 | file: ^^ |
| 22:16.52 | file | :D |
| 22:16.52 | tm1000 | white fedora* |
| 22:16.59 | sruffell | heh |
| 22:17.04 | mjordan | http://www.youtube.com/watch?v=kOTDn2A7hcY |
| 22:17.18 | Qwell | tm1000: not a fedora. he yelled at me for that. :( |
| 22:17.23 | Qwell | glares at file |
| 22:17.26 | tm1000 | ahh oopps haha |
| 22:17.27 | sruffell | mjordan: a classic... |
| 22:18.15 | file | I wore a... bowler... didn't I? |
| 22:18.23 | mjordan | you did indeed |
| 22:18.29 | mjordan | speaking of which, tm1000. |
| 22:18.35 | mjordan | I never did hit you up for those pcaps |
| 22:18.47 | tm1000 | pcaps? |
| 22:19.01 | Qwell | from the testbed |
| 22:19.06 | mjordan | hm. IIRC, didn't you set up all the phones on the testbed? |
| 22:19.12 | tm1000 | ohhh yes |
| 22:19.16 | tm1000 | with tony and luke and bryan |
| 22:19.20 | mjordan | that thing is awesome |
| 22:19.35 | mjordan | y'all wouldn't still happen to have that, would you? |
| 22:19.43 | tm1000 | yes they do |
| 22:19.46 | tm1000 | (i work remote) |
| 22:19.47 | mjordan | ah |
| 22:19.50 | tm1000 | however |
| 22:19.51 | mjordan | welp. |
| 22:19.53 | tm1000 | the guys in the office do |
| 22:19.57 | tm1000 | they use it daily |
| 22:20.05 | mjordan | *someone* may get a plea from me in the next few weeks |
| 22:20.23 | mjordan | if I can but finish the godawful SIP test plan from hell |
| 22:20.26 | tm1000 | mjordan: just ping GameGamer43, me or tonyclewis |
| 22:20.30 | mjordan | kk, will do |
| 22:20.32 | newtonr | tm1000: i am here! :) you messaged me in #freepbx yesterday |
| 22:20.50 | tm1000 | I did? (i think I'm losing my mind today…very forgetful) |
| 22:21.01 | file | that reminds me! |
| 22:21.16 | Qwell | file: No. Stop that. |
| 22:21.36 | file | Qwell, a SIP module that outputs SIP traffic into pcaps, GO! |
| 22:21.39 | newtonr | tm1000: yeah i was asking about a patch mentioned on freepbx forums. Though I never did get an answer. I just need to send someone an E-mail I guess |
| 22:21.53 | tm1000 | *@schmoozecom.com |
| 22:21.56 | tm1000 | andrew.nagy |
| 22:21.56 | Qwell | file: kpfleming had a similar idea for other thingies. |
| 22:22.00 | tm1000 | bryan.walters |
| 22:22.02 | tm1000 | tony.lewis |
| 22:22.03 | file | Qwell, I knowz |
| 22:22.04 | tm1000 | you choose |
| 22:22.11 | Qwell | oh right, you were there for that conversation |
| 22:22.42 | newtonr | tm1000: i'll mail Bryan since you said he writes and submits the patches :) |
| 22:23.05 | tm1000 | usually yes. Oh I remember now about the patches conversation. yes. |
| 22:23.39 | tm1000 | mjordan: Im assuming you want to test the new sip stack with those devices? |
| 22:23.52 | tm1000 | (sorry I didn't understand what pcap meant…now I know the slang) |
| 22:25.47 | tm1000 | wait…sruffell do you have glasses? |
| 22:26.01 | sruffell | I do. |
| 22:26.07 | tm1000 | ok I remember yo uknow |
| 22:26.10 | tm1000 | you now* |
| 22:26.18 | rmeyerriecks | he's practically the only person at digium who wears glasses |
| 22:26.20 | sruffell | take that mjordan! |
| 22:26.24 | sruffell | lol |
| 22:26.28 | tm1000 | the night at the bar at the hotel when tony was complaining about the dahdi module |
| 22:26.33 | sruffell | nods |
| 22:26.38 | tm1000 | you were standing right next to me hahah |
| 22:27.14 | tm1000 | got the face now. ah thats five people I can remember now! |
| 22:27.54 | sruffell | next year…I might just be breakin' right next to you…. |
| 22:28.43 | rmeyerriecks | now I feel left out, maybe I made the top 10 |
| 22:29.11 | tm1000 | rmeyerriecks: note that astricon was the first time I've spoken to any digium folk… |
| 22:29.22 | rmeyerriecks | tm1000: Yea same here |
| 22:29.35 | sruffell | smirks |
| 22:29.52 | file | smacks rmeyerriecks |
| 22:30.02 | file | the beatings will continue until you move to VoIP! |
| 22:30.04 | mjordan | tm1000: yup, that's why |
| 22:30.29 | rmeyerriecks | file: hardware pays the bills, so ... |
| 22:30.35 | mjordan | owch |
| 22:30.52 | file | I do not subscribe to reality |
| 22:31.12 | mjordan | file: did you get a 404? |
| 22:31.19 | file | mjordan, segfault :( |
| 22:31.21 | kpfleming | Qwell: I wrote that other thing and it worked. |
| 22:33.09 | Qwell | kpfleming: yeah, I know |
| 22:50.24 | mjordan | jrose_atDigium: opticron: have either of you run into CEL verification failures due to unexpected ordering of events? |
| 22:50.41 | jrose_atDigium | mjordan: Yes. That's why I can't include CEL logs in call parking tests. |
| 22:51.56 | jrose_atDigium | Basically I have two channels (the parker and a zombie of the parked call) that go away at the same time and the order switches around and causes CEL logs to just be generally inconsistent. |
| 22:52.04 | jrose_atDigium | Frustrated me for a couple days. |
| 22:53.30 | mjordan | sp |
| 22:53.32 | mjordan | hm |
| 22:53.44 | mjordan | so, the way we should be matching CEL records is: do we have an entry that matches? If so, remove it |
| 22:53.52 | mjordan | if we have entries left over, we fail |
| 22:54.02 | mjordan | the ordering during transfers gets timing dependent |
| 22:54.27 | jrose_atDigium | yep |
| 22:54.29 | mjordan | jrose_atDigium: I think we'll need to add that back in, but I'll poke at the cel module tomorrow |
| 22:54.34 | jrose_atDigium | alrighty |
| 22:54.44 | mjordan | the matching stuff that otherwiseguy wrote is nifty, but complex |
| 22:55.12 | jrose_atDigium | I personally thought it should work in blocks... |
| 22:55.22 | jrose_atDigium | like for one block, you expect the events to be in order. |
| 22:55.35 | jrose_atDigium | Then you switch modes and the next set can be in any order until you switch modes again. |
| 22:55.41 | jrose_atDigium | But that's also complicated. |
| 23:02.08 | mjordan | and probably not worth it |
| 23:02.16 | mjordan | some of the CEL events are going to change |
| 23:05.59 | coreyf1513 | liefmadsen: how do you want to know of issues on the O'Reilly book? |
| 23:28.13 | *** part/#asterisk-dev mjordan (~mjordan@nat/digium/x-fwogogrjnadwpqlc) |
| 23:59.23 | *** join/#asterisk-dev snuff-home (~snuffy@203-219-29-182.tpgi.com.au) |
| 23:59.24 | *** mode/#asterisk-dev [+o snuff-home] by ChanServ |