| 00:29.16 | *** join/#asterisk-dev jmls (~Julian@host217-36-208-155.in-addr.btopenworld.com) |
| 00:33.06 | *** join/#asterisk-dev elguero (~miguel323@2001:470:1f06:12c4::2) |
| 00:43.05 | *** join/#asterisk-dev otherwiseguy (~terry@69.76.217.40) |
| 01:05.52 | *** join/#asterisk-dev mjordan (~mjordan@user-69-1-6-49.knology.net) |
| 01:05.52 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 01:17.01 | *** join/#asterisk-dev micols (~0x2AA7F64@2001:16d8:dd54::2000) |
| 02:13.48 | *** join/#asterisk-dev philipp64|laptop (~chatzilla@50-39-144-127.bvtn.or.frontiernet.net) |
| 02:37.37 | *** join/#asterisk-dev zerohalo (~zerohalo@74.60.136.128) |
| 03:36.53 | *** part/#asterisk-dev mjordan (~mjordan@user-69-1-6-49.knology.net) |
| 04:21.10 | *** join/#asterisk-dev irroot (~irroot@41.53.66.3) |
| 05:14.36 | *** join/#asterisk-dev tzafrir (~tzafrir@212.179.75.202) |
| 05:14.36 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 05:32.13 | *** join/#asterisk-dev schmidts (~schmidts@Lo20-rt01.lm33.sil.at) |
| 05:32.16 | schmidts | good morning |
| 06:21.25 | *** join/#asterisk-dev irroot (~irroot@197.169.192.33) |
| 07:31.37 | *** join/#asterisk-dev tamiel (~tamiel@213.30.183.226) |
| 07:32.10 | *** join/#asterisk-dev irroot (~irroot@pbx.distrotech.co.za) |
| 07:49.29 | *** join/#asterisk-dev anonymouz666 (~anonymouz@187-28-37-118.poolip.RJO.embratel.net.br) |
| 07:49.29 | *** join/#asterisk-dev seraphie (~erin@75.76.38.159) |
| 07:49.29 | *** join/#asterisk-dev felipe_ (~felipe@unaffiliated/felipe) |
| 07:49.29 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 07:49.29 | *** join/#asterisk-dev Daviey (~Daviey@ubuntu/member/daviey) |
| 07:49.29 | *** join/#asterisk-dev merbzt (~benjamin@193.12.106.2) |
| 07:49.29 | *** mode/#asterisk-dev [+o pabelanger] by niven.freenode.net |
| 07:51.27 | *** join/#asterisk-dev philipp64|laptop (~chatzilla@50-39-144-127.bvtn.or.frontiernet.net) |
| 07:51.28 | *** join/#asterisk-dev jmls (~Julian@host217-36-208-155.in-addr.btopenworld.com) |
| 07:51.28 | *** join/#asterisk-dev mickecarlsson (~Micke@h10n3c1o1101.bredband.skanova.com) |
| 07:51.28 | *** join/#asterisk-dev jsmith-away (~jsmith@fedora/jsmith) |
| 07:51.28 | *** join/#asterisk-dev seanbright (~sean@asterisk/contributor-and-bug-marshal/seanbright) |
| 07:51.28 | *** mode/#asterisk-dev [+oo jsmith-away seanbright] by niven.freenode.net |
| 07:51.42 | *** join/#asterisk-dev moy (~moy@173.239.155.74) |
| 07:51.43 | *** join/#asterisk-dev opticron (~opticron@pianoben.ch) |
| 07:51.43 | *** mode/#asterisk-dev [+o opticron] by niven.freenode.net |
| 07:52.12 | *** join/#asterisk-dev mvanbaak (~michiel@asterisk/contributor-and-bug-marshal/mvanbaak) |
| 07:52.12 | *** join/#asterisk-dev pnlarsson (~niklas@fw1.gml.g.icnet.infracom.se) |
| 07:52.12 | *** mode/#asterisk-dev [+o mvanbaak] by niven.freenode.net |
| 07:52.19 | *** join/#asterisk-dev malcolmd (~malcolmd@pdpc/sponsor/digium/malcolmd) |
| 07:52.19 | *** join/#asterisk-dev Kobaz (~kobaz@its.kobaz.net) |
| 07:52.19 | *** join/#asterisk-dev voxter (~hardcore@macpro.daytonhome.voxter.net) |
| 07:52.19 | *** join/#asterisk-dev Marquis42 (~bfhbmw0@65-127-126-34.dia.static.qwest.net) |
| 07:52.19 | *** mode/#asterisk-dev [+o malcolmd] by niven.freenode.net |
| 07:52.44 | *** join/#asterisk-dev elguero (~miguel323@2001:470:1f06:12c4::2) |
| 07:54.07 | *** join/#asterisk-dev Juggie (~Juggie@unaffiliated/juggie) |
| 07:54.42 | *** join/#asterisk-dev Micc (~Micc@c-98-232-46-178.hsd1.wa.comcast.net) |
| 07:54.42 | *** join/#asterisk-dev acidfoo (~nib@modemcable094.94-70-69.static.videotron.ca) |
| 07:54.42 | *** join/#asterisk-dev russellb (~russellb@asterisk/contributor-and-cool-guy/russellb) |
| 07:54.42 | *** join/#asterisk-dev Qwell (~north@pdpc/sponsor/digium/Qwell) |
| 07:54.42 | *** mode/#asterisk-dev [+oo russellb Qwell] by niven.freenode.net |
| 07:55.25 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 07:55.25 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 08:08.23 | *** join/#asterisk-dev oej (~olle@ns.webway.se) |
| 08:08.23 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 08:20.30 | *** join/#asterisk-dev oej (~olle@ns.webway.se) |
| 08:20.30 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 08:21.11 | *** join/#asterisk-dev oej (~olle@ns.webway.se) |
| 08:21.11 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 08:25.21 | irroot | oej is the patch on RB1164 recent ?? [i know its not] i suspect tat it wont apply with recent changes to hangup for parking fixup |
| 08:26.20 | *** join/#asterisk-dev Corydon76-home (four@c-69-137-80-31.hsd1.tn.comcast.net) |
| 08:26.20 | *** mode/#asterisk-dev [+o Corydon76-home] by ChanServ |
| 08:26.36 | irroot | ok it applies |
| 08:26.48 | irroot | Corydon76-home o/ |
| 08:37.50 | oej | Which patch? |
| 08:39.00 | irroot | hangup patch |
| 08:39.17 | irroot | ive tested it its ok |
| 08:39.30 | irroot | there were changes to ast_hangup |
| 08:40.21 | oej | Oh, that one. No, it's propably pretty old. April 15th |
| 08:40.56 | irroot | mmm |
| 08:41.07 | irroot | but it still applies fuzz but applies |
| 08:45.49 | irroot | oej i suspect that 183 is causing frames to go through the SRTP and generating warnings |
| 08:46.01 | irroot | cant decrypt .... |
| 08:46.05 | oej | If you like it, then please add a comment. I don't see why we can't commit it. |
| 08:52.57 | mvanbaak | we now have proof that linux sux big time. It's because of the people working on it! |
| 08:53.00 | mvanbaak | https://lkml.org/lkml/2011/9/18/144 |
| 09:00.24 | irroot | mvanbaak that is quite harsh eish |
| 09:21.08 | mvanbaak | yeah, maybe |
| 09:21.20 | mvanbaak | I have been fighting with problems in Linux the last two weeks |
| 09:21.30 | mvanbaak | and everytime I find the problem, and look at the code .... |
| 09:21.36 | mvanbaak | it makes me very sad |
| 09:22.49 | irroot | mvanbaak not harsh what you said but that things are done that way |
| 09:25.21 | oej | Good to see that even gods can loose temper |
| 09:27.32 | irroot | yeah crack the whip is needed at times |
| 09:28.54 | mvanbaak | yeah |
| 09:33.31 | oej | mvanbaak: STAND UP AT YOUR DESK WHEN I'M CHATTING WITH YOU! do it NOW! |
| 09:33.37 | oej | just checking |
| 09:34.08 | oej | Guess the whip did not work in that case. |
| 09:34.42 | mvanbaak | lol |
| 09:36.02 | irroot | oej did kind of turn me on :P |
| 09:36.16 | oej | Ouch. |
| 09:36.24 | oej | Side effects not expected. |
| 09:36.26 | oej | ;-) |
| 09:36.53 | mvanbaak | hahaha |
| 09:37.03 | mvanbaak | 9 weeks to go, and I will be in Brazil \o/ |
| 09:37.25 | irroot | mvanbaak you going there or just getting a brazilian |
| 09:37.35 | mvanbaak | I'll be there for 2 weeks |
| 09:37.45 | mvanbaak | and hopefully come back with a nice brazilian lady ;) |
| 09:38.25 | mvanbaak | I _AM_ staying at the house of a very nice lady ;) |
| 09:38.28 | mvanbaak | who knows |
| 09:38.33 | oej | Well, those magazines exist everywhere, mvanbaak |
| 09:38.41 | oej | A REAL lady? |
| 09:38.42 | mvanbaak | lol |
| 09:38.43 | oej | :_) |
| 09:38.46 | mvanbaak | yeah, a REAL lady |
| 09:38.51 | mvanbaak | I already met her in .nl |
| 09:39.46 | oej | Ok, two changes committed that can affect users. I'm going on a holiday for a few days starting tomorrow :-) |
| 09:39.55 | mvanbaak | hahahaha |
| 09:43.19 | oej | The funny part is that I'm really going to Portugal :-) |
| 09:50.10 | irroot | mvanbaak oej have a good one |
| 09:52.14 | mvanbaak | and the funny part is that I'm really going to Brazil |
| 09:52.17 | mvanbaak | irroot: latero ! |
| 10:00.41 | *** join/#asterisk-dev lister_ (~lister@scarda1.lnk.telstra.net) |
| 10:38.12 | *** join/#asterisk-dev mjordan (~mjordan@user-69-1-6-49.knology.net) |
| 10:38.12 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 10:43.12 | *** part/#asterisk-dev mjordan (~mjordan@user-69-1-6-49.knology.net) |
| 11:03.06 | *** join/#asterisk-dev kchehab (~kchehab@77.42.241.66) |
| 11:03.25 | kchehab | hi where i can ask a question related to a2billing call cut for the last call duration |
| 11:52.27 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 11:52.27 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 11:59.28 | kpfleming | uh-oh, it's morning again |
| 11:59.55 | russellb | sadly |
| 12:00.13 | file | kpfleming, I have tried to petition against this 'morning' thing but so far no go |
| 12:02.28 | kpfleming | wednesdays are the most evil mornings for me, as tuesday nights are when i play pool |
| 12:04.09 | leifmadsen | kpfleming: if you start staying up really late and sleeping in, you can avoid mornings |
| 12:04.30 | leifmadsen | unless you consider morning a feeling and not a time |
| 12:05.20 | irroot | well where i am its lunch so all relative |
| 12:07.05 | kpfleming | oh yay... more facebook user interface changes today |
| 12:07.42 | oej-away | Afternoon folks |
| 12:08.13 | irroot | kpfleming you still bothered with FB ?? |
| 12:08.34 | kpfleming | no, they fixed the login issues |
| 12:09.02 | leifmadsen | for anyone who enjoys photography, my wife found this site the other night: http://www.500px.com |
| 12:09.08 | leifmadsen | some good photos there |
| 12:12.35 | russellb | leifmadsen: speaking of that, has the eagle landed? |
| 12:13.55 | oej | Irroot: While checking app originate - did you see if it was affected by the pbx_run stuff? |
| 12:14.27 | irroot | oej the patch was to the timeout value i did not look at anything else |
| 12:14.57 | irroot | ill look now for you ... you refering to the s@defauly |
| 12:15.17 | russellb | speaking of facebook interface, for the lulz: http://bit.ly/oiseq3 |
| 12:23.58 | kpfleming | russellb: yeah... that too |
| 12:32.23 | *** join/#asterisk-dev grEvenX (~even@apb9hb.ip.ssc.net) |
| 12:32.27 | *** join/#asterisk-dev elguero (~miguel323@2001:470:1f06:12c4::2) |
| 12:34.25 | leifmadsen | russellb: I'm not sure which eagle you're referring to :) |
| 12:34.45 | russellb | leifmadsen: wife, photography. |
| 12:34.52 | leifmadsen | russellb: yes it has :) |
| 12:35.15 | irroot | ok these SRTP warnings are driving me mad |
| 12:35.23 | grEvenX | http://dpaste.com/618241/ |
| 12:35.25 | oej | App_originate.c doesn't check if the extension exists. Argh. |
| 12:35.32 | grEvenX | having a huge problem with some of our asterisk installs |
| 12:35.54 | irroot | suspect its to do with early media or audio before up |
| 12:36.08 | grEvenX | oej: any chance of taking a look at it? |
| 12:36.53 | irroot | oej that is a pain but then that should be left to the users intelligence [or lack of] |
| 12:37.07 | russellb | grEvenX: was that all of the "core show locks" output? |
| 12:37.10 | russellb | it looks incomplete. |
| 12:41.59 | tzanger | morning |
| 12:42.57 | grEvenX | russellb: http://dpaste.com/618242/ |
| 12:45.21 | grEvenX | russellb: that should contain all |
| 12:46.33 | irroot | ok when using srtp we cannot process early media |
| 12:54.16 | irroot | oej how you feel about sip_rtp_read returning null frame when srtp is on and early media |
| 12:56.36 | russellb | grEvenX: guess you'll have to file a bug report. it's not obvious from just that. whoever looks at it will need a full backtrace as well. |
| 12:58.41 | oej | yes, it looks incomplete to me too. |
| 13:00.34 | irroot | as SRTP can only work once the invite is confirmed we only generating warnings in the srtp core and rather return null frames to driver |
| 13:01.17 | kpfleming | irroot: not confirmed... once the dialog has been established, so yes, that seems reasonable. |
| 13:05.23 | *** join/#asterisk-dev serafie (~erin@nat/digium/x-ytbkpihjwahpgyyo) |
| 13:05.46 | mnicholson | oej, ping |
| 13:07.06 | oej | mnicholson: pong |
| 13:09.07 | mnicholson | oej, I need to know exactly how to reproduce what you are seeing with ASTERISK-17066, thus far in my testing I have not been able to do it |
| 13:09.25 | mnicholson | oej, alternatively, you could provide access to a system experiencing this issue |
| 13:28.31 | leifmadsen | mnicholson: was it you I was talking to about ASTERISK-18566 yesterday? |
| 13:28.56 | mnicholson | leifmadsen, nope |
| 13:29.03 | leifmadsen | ugh... that DocAwesome bot is so not stable... |
| 13:29.40 | *** join/#asterisk-dev DocAwesome (~DocAwesom@asterisk/documenteur-extraordinaire/blitzrage) |
| 13:29.45 | leifmadsen | oh maybe it was richard |
| 13:29.46 | oej | Question: In chan_sip if I have the iflock - should I just assume that I'm the ruler of the world and no one else have any locks? |
| 13:29.53 | oej | I don't think that's a valid assumption. |
| 13:29.58 | *** mode/#asterisk-dev [+o DocAwesome] by ChanServ |
| 13:34.27 | russellb | oej: nope |
| 13:35.17 | oej | Ok, then we agree. |
| 13:35.55 | oej | In grEvenX's logs I see that we hang in find_call which is not a good place to hang for getting a lock forever. |
| 13:36.41 | russellb | it's not waiting on a lock though, according to the locks output |
| 13:36.56 | russellb | need to see a backtrace to see what it's sitting around doing |
| 13:38.35 | *** join/#asterisk-dev Aurs (~ove@nidaros.netcore.no) |
| 13:51.18 | *** join/#asterisk-dev jeffg (~jeffg@pdpc/supporter/professional/jeffg) |
| 13:54.43 | *** join/#asterisk-dev seraphie (~erin@75.76.38.159) |
| 14:21.23 | *** join/#asterisk-dev zerohalo (~zerohalo@173-13-92-27-NewEngland.hfc.comcastbusiness.net) |
| 14:30.38 | *** join/#asterisk-dev sruffell (~Adium@asterisk/the-kernel-guy/sruffell) |
| 14:30.38 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 14:35.25 | oej | It's not waiting for a lock, it's just standing still with the lock. |
| 14:35.54 | oej | Somehow it gave up and continued, so we can't get a new backtrace right now. |
| 14:36.55 | irroot | oej blocking in a read or the like with a lock held will do this |
| 14:38.33 | oej | Something is blocking the whole monitor thread for a long time. I don't see a deadlock. We do see a malformed SIP packet. I'll test with that and see if I can see something strange. But while the monitor thred is blocked there's no SIP messages coming in, so all peers get unreachable of course. |
| 14:39.23 | oej | I am suspecting it's somewhere in sipsockread we block the socket and fail on parsing and hit some bad code. I have no idea of what type of code, more than it's obviously really bad :-) |
| 14:43.16 | *** join/#asterisk-dev wdoekes2 (~walter@wjd.osso.nl) |
| 14:50.38 | *** part/#asterisk-dev Micc (~Micc@c-98-232-46-178.hsd1.wa.comcast.net) |
| 14:54.32 | *** join/#asterisk-dev The_Boy_Wonder (~vossel@asterisk/batman-developer/dvossel) |
| 14:54.32 | *** mode/#asterisk-dev [+o The_Boy_Wonder] by ChanServ |
| 15:01.24 | *** join/#asterisk-dev malcolmd_ (~malcolmd@pdpc/sponsor/digium/malcolmd) |
| 15:01.24 | *** mode/#asterisk-dev [+o malcolmd_] by ChanServ |
| 15:08.42 | irroot | cant get to the bottom of eliminating the warnings |
| 15:08.46 | irroot | in srtp |
| 15:09.04 | irroot | idea of making sure sip dialog was complete is a bust |
| 15:09.31 | irroot | i still get 3 RTP and 3 RTCP packets reporting errors on all calls |
| 15:10.09 | irroot | so ive made it a ast_debug(1, not log_warning |
| 15:10.17 | irroot | any ideas welcome |
| 15:21.21 | *** join/#asterisk-dev oron_laptop (~oron_lapt@local.xorcom.com) |
| 15:21.47 | oron_laptop | sruffell: hi (a quick question...) |
| 15:22.19 | sruffell | ducksâ¦â¦we've been running the patches hereâ¦I just still need to clean them up into one series.... |
| 15:22.51 | sruffell | there was only one other thing I found that I don't think I've sent to you yet (but it was pushed onto the sysfs branch) |
| 15:23.19 | sruffell | but then I haven't been stressing the new interfacesâ¦primarily just been making sure none of our old tests are broken. |
| 15:23.29 | oron_laptop | sruffell: I think there is some confusion about span_list sort order |
| 15:23.40 | sruffell | ...ok |
| 15:23.56 | oron_laptop | sruffell: It is said to be sorted by span no (when list_add_tail is called), but... |
| 15:24.29 | oron_laptop | sruffell: assumed to be 'basechanno' ordered when looking for channels. |
| 15:25.06 | oron_laptop | sruffell: I can fix this, but I'm not sure what other assumptions are hiding there. |
| 15:25.08 | sruffell | hmmâ¦.it should be both is my understandingâ¦..spanno *and* basechanno orderedâ¦. |
| 15:25.20 | sruffell | so span 1 cannot have a higher basechan on it than span 2 |
| 15:26.00 | oron_laptop | sruffell: Yes, I found that (the hard way). Do we really need both sorting orders to match? |
| 15:26.03 | sruffell | that simplifies the search (done infrequently) and I think preserves the principle least surprise |
| 15:26.59 | sruffell | need might be strongâ¦.does it drastically simplify things to not do it that way?: |
| 15:27.09 | oron_laptop | sruffell: 1. The current error DOES surprised me ("No channel for number 15", when lsdahdi shows it clearly) |
| 15:27.28 | oron_laptop | 2. Why add this restriction? |
| 15:28.00 | sruffell | I was trying to avoid a situation where dahdi_scan would show higher number spans with lower numbered channels. |
| 15:28.12 | sruffell | relative to other spans... |
| 15:28.46 | oron_laptop | sruffell: That's in itself isn't bad, but it should be checked/enforced during span assignment and not cause later unrelated errors. |
| 15:29.09 | sruffell | agreedâ¦that was the intentâ¦.and if it's not that way, it's my mistake. |
| 15:29.28 | oron_laptop | sruffell: OK, if that'll be easy I'll fix that now. |
| 15:29.36 | sruffell | wait..and I mean where dahdi_scan would *not* show higher numbered spans with lowered number channels. |
| 15:30.56 | sruffell | but isn't keeping the span list sorted like that easiest? Maybe the sorting is brokenâ¦but the goal still seems valid if that is what we're trying to do. Push the burden when a span is addedâ¦and not have it encoded around in the lookups. |
| 15:31.36 | oron_laptop | agreed and gone to try and code this enforcement... |
| 15:32.23 | oron_laptop | code by itself -- no use for oron anymore surprise |
| 15:33.56 | sruffell | lol |
| 16:02.16 | *** join/#asterisk-dev malcolmd (~malcolmd@pdpc/sponsor/digium/malcolmd) |
| 16:02.16 | *** mode/#asterisk-dev [+o malcolmd] by ChanServ |
| 16:15.36 | *** join/#asterisk-dev otherwiseguy (~otherwise@69.76.217.40) |
| 16:16.57 | *** join/#asterisk-dev otherwiseguy (~otherwise@69.76.217.40) |
| 16:20.37 | *** join/#asterisk-dev malcolmd (~malcolmd@pdpc/sponsor/digium/malcolmd) |
| 16:20.37 | *** mode/#asterisk-dev [+o malcolmd] by ChanServ |
| 16:21.14 | *** join/#asterisk-dev malcolmd (~malcolmd@pdpc/sponsor/digium/malcolmd) |
| 16:21.14 | *** mode/#asterisk-dev [+o malcolmd] by ChanServ |
| 16:23.32 | *** join/#asterisk-dev irroot (~irroot@41.51.142.97) |
| 16:25.07 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 16:25.07 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 16:26.28 | irroot | ideas ... add a cli "srtp debug" and turn off the warnings on results from libsrtp unless this is on ?? |
| 16:50.35 | *** join/#asterisk-dev chazzam (~chazz@173-24-236-90.client.mchsi.com) |
| 16:50.53 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 16:56.55 | leifmadsen | irroot: if it's a warning shouldn't it be shown? if it's a debug level thing, then ya it should be moved to it |
| 16:57.00 | leifmadsen | but I'm not sure what you're referencing |
| 16:58.57 | irroot | leifmadsen its bit complicated as it happens outside asterisk in libsrtp and seems to happen for every call the first few packets return auth_fail i suspected early media but rulled that out so it could be part of srtp setup |
| 16:59.28 | irroot | it seems normal for srtp so there should be no warning set in that case |
| 16:59.57 | irroot | but it could continue into the call and scroll one error per frame of audio also not ideal |
| 17:00.11 | irroot | s/error/warning/ |
| 17:00.41 | irroot | having a cli as with "rtp debug" will help track it down |
| 17:01.34 | leifmadsen | irroot: 'rtp set debug {on,off,<level>}' |
| 17:01.41 | leifmadsen | I'm ok with a setting if you want to make it available |
| 17:02.34 | irroot | also perhaps only warn on the 10th frame once controled by flag |
| 17:02.55 | irroot | this is done in the dtmf dsp bits |
| 17:03.14 | irroot | one warning per call is enough no need to have 1 per frame |
| 17:04.24 | irroot | ive seen the confusion i have techies turning srtp off seen this warning thinking its causing the ..... <- fill in the blank jitter / quality / ... |
| 17:15.08 | leifmadsen | irroot: totally agreed -- only need it once per call, not per frame |
| 17:25.21 | Corydon76-home | leifmadsen: Not quite true. When it's only once per call, it's easy to miss. That's why there are lots of places where we do a simple calculation of count % 10 |
| 17:27.27 | leifmadsen | Corydon76-home: oh ok, I'd not noticed those before, but something like that is fine too :) |
| 17:27.31 | irroot | Corydon76-home in this case its going to be hard to miss as there will be no audio |
| 17:27.32 | leifmadsen | once per frame is just crazy |
| 17:28.45 | Corydon76-home | irroot: Unless the admin sees a message, it's easy to chalk it up to "that crazy secretary" |
| 17:29.40 | Corydon76-home | If you want to hide warnings from the console, then modify the console line in logger.conf and reload. |
| 17:31.29 | irroot | Corydon76-home indeed the warning volume is a problem you miss all context with 1per frame so the stream is not helpfull |
| 17:32.48 | irroot | perhaps % 10 with max of 20 thats a few seconds of audio |
| 17:32.51 | Corydon76-home | I'm not disputing the amount is a problem. I'm saying that hiding all (or all but one) of the messages makes the message easy to miss/ignore |
| 17:33.25 | Corydon76-home | %10 basically means 1 message every 2 seconds, with the typical frame length |
| 17:34.08 | irroot | +1 ill make it so no 1 |
| 17:34.09 | Corydon76-home | Or no, that's %100 |
| 17:34.34 | Corydon76-home | %100 should be fine for frames |
| 17:34.56 | irroot | yeah then no limit |
| 17:40.35 | oron_laptop | sruffell: OK, fixed span sorting problems (mail en route), planning to go home... |
| 17:41.01 | sruffell | ok, thanks |
| 17:45.23 | *** join/#asterisk-dev hehol (~Adium@2a01:198:71d:0:21f:d0ff:fea1:568e) |
| 18:04.58 | *** part/#asterisk-dev irroot (~irroot@41.51.142.97) |
| 18:10.46 | *** join/#asterisk-dev bob_kelso (~john@nat/digium/x-cqyqecgedmbafywj) |
| 19:05.30 | *** join/#asterisk-dev DocAwesome (~DocAwesom@asterisk/documenteur-extraordinaire/blitzrage) |
| 19:05.30 | *** mode/#asterisk-dev [+o DocAwesome] by ChanServ |
| 19:52.08 | pabelanger | BTW: Should we stop adding new features to Asterisk 10? |
| 19:52.42 | pabelanger | Seems everything new is going in, regardless of it already being branches |
| 19:52.49 | pabelanger | s/es/ed/ |
| 19:52.58 | pabelanger | fail |
| 19:53.36 | kpfleming | umm... what? what is 'everything new'? |
| 19:54.21 | kpfleming | the only new feature that i am aware of that was expected to enter the branch after beta1 was the sip security event reporting stuff |
| 19:59.52 | pabelanger | kpfleming: I could compose a list, but it looks like new features from reviewboard are getting merged into branches/10 |
| 20:00.06 | kpfleming | that should not be happening |
| 20:00.19 | kpfleming | so yes... we need a list, and some of them might need to be reverted |
| 20:00.20 | Corydon76-home | pabelanger: I think there's very limited sets of that, and usually classified as bugs |
| 20:00.56 | pabelanger | Right, but I think a reminder email might be in order |
| 20:02.42 | tzanger | infobot needs a /g there, but that was still worth a smile "regardleds" |
| 20:02.46 | tzanger | sounds like you have a cold |
| 20:05.48 | pabelanger | well at first glace, here are the changes to CHANGES since we branched: http://svnview.digium.com/svn/asterisk/branches/10/CHANGES?view=log |
| 20:08.13 | kpfleming | so 336042 should probably be reverted |
| 20:08.21 | pabelanger | app_originate and app_meetme look to be new features |
| 20:08.35 | kpfleming | yes... 337261 also |
| 20:10.20 | pabelanger | okay, I'll make the changes |
| 20:10.44 | kpfleming | and we need an email to -dev describing why this is being done, i guess |
| 20:10.47 | malcolmd | those are both pretty low impact things... |
| 20:10.59 | kpfleming | doesn't matter.. a feature freeze is a freeze. |
| 20:11.12 | pabelanger | kpfleming: Yes, I was going to draft up an email for review |
| 20:11.13 | kpfleming | otherwise, we need to go find all the low impact new features and merge them. |
| 20:11.56 | jmls | as 10 is going to be a big new shiny release, why not include the low impact stuff ? |
| 20:12.08 | jmls | stop people from playing with trunk in production ;) |
| 20:12.25 | leifmadsen | jmls: I think because we've already branched 10, and the branch is technically the feature freeze |
| 20:12.32 | jmls | technically, yes |
| 20:12.36 | leifmadsen | features == trunk |
| 20:12.41 | Corydon76-home | Because there are always going to be low impact stuff, and you have to draw the line somewhere |
| 20:12.44 | pabelanger | new features should have been submitted a few months ago, when we're developing 10. Not after we branch |
| 20:12.54 | jmls | ducks for cover |
| 20:12.57 | jmls | disagree |
| 20:13.06 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-218-155-170.cablep.bezeqint.net) |
| 20:13.06 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 20:13.12 | malcolmd | agrees with jmls |
| 20:13.17 | jmls | yay |
| 20:13.25 | kpfleming | the request for new features for asterisk 10 went out in june |
| 20:13.31 | kpfleming | if stuff appears after that, so be it |
| 20:13.31 | pabelanger | ^ |
| 20:13.43 | kpfleming | after is after... asterisk 11 |
| 20:13.59 | jmls | what, in 2 years ? the new stuff is then stale |
| 20:14.07 | kpfleming | have you read the wiki lately? |
| 20:14.08 | malcolmd | jmls: only 1 year |
| 20:14.24 | jmls | only ?? |
| 20:14.31 | leifmadsen | that's not a lot of time really :) |
| 20:14.38 | kpfleming | we've already tried the 'put everything in an release every six months' thing. users hated it. |
| 20:14.39 | jmls | it is in tech world ;_ |
| 20:14.59 | leifmadsen | people don't tend to upgrade their phone systems every 6-12 months |
| 20:16.01 | pabelanger | leifmadsen: ! |
| 20:16.07 | malcolmd | but new users show up constantly, and new features are often features that appeal to new users (they're new, they're current, they're tied together), so some amount of catering to new users with new features is a good idea. (awaits the flames) |
| 20:16.37 | kpfleming | malcolmd: you take over then |
| 20:16.39 | jmls | yeah, I understand that - however, I want to supply the latest and greatest to my customers |
| 20:16.39 | kpfleming | have fun |
| 20:16.49 | kpfleming | jmls: this is open source, you have the patches. |
| 20:17.02 | jmls | ouch. someone is touchy today ;) |
| 20:17.17 | pabelanger | Nightly builds would fix that, but I don't think anybody here is going to produce them |
| 20:17.22 | kpfleming | i am touchy whenever people demand that we do everything they want because they want it |
| 20:17.29 | kpfleming | pabelanger: what? how would that fix anything? |
| 20:17.34 | jmls | where's the "demand" ??? |
| 20:17.47 | jmls | it was an opinion voiced in a forum |
| 20:17.58 | kpfleming | fine... i used the wrong word |
| 20:18.09 | kpfleming | we've had this discussion over and over again, and again, and again |
| 20:18.12 | Corydon76-home | pabelanger: This is open source. If somebody wants to provide a nightly build, they are welcome to provide infrastructure to do so |
| 20:18.22 | kpfleming | we post publicly the release plans, we post publicly the 'call for features' |
| 20:18.34 | kpfleming | i don't understand how nightly builds help anything at all |
| 20:18.45 | kpfleming | the issue is not making builds, it's someone taking the time to integrate patches |
| 20:18.50 | pabelanger | poor choice of words. If new users want new features, grab them from trunk. If they don't know subversion, nightbuilds or snapshots could be a solution. But like I said, I don't think anybody here is going to set it up |
| 20:18.54 | jmls | hey, kpfleming, I'm one of * greatest fans, and I think that the -dev guys are awesome. Doesn't mean I have to agree with you all the time |
| 20:19.02 | kpfleming | no, it doesn't |
| 20:19.42 | kpfleming | and if you want to produce your own version of asterisk with a bunch of stuff added in that we decided to delay until asterisk 11, you are both free and encouraged to do so, if that better meets your needs |
| 20:20.02 | jmls | agreed. |
| 20:20.50 | jmls | What I suppose I am trying to say is that it would be nice if the "small" features that went into trunk were easily backported into -10 , as it is such a new release. |
| 20:21.51 | Corydon76-home | jmls: how do you determine what is small and unlikely to break a branch? |
| 20:22.01 | jmls | that's why we need you guys. |
| 20:22.13 | malcolmd | ...given that it's still at beta 1, and some amount of "omg last minute features that missed the posted deadline and aren't likely to hose up the world" isn't entirely unreasonable |
| 20:22.42 | kpfleming | malcolmd: do you have some more people we can employ to check out these features and be ready to deal with any problems they may cause? |
| 20:22.43 | jmls | you are the ultimate arbitrators of what is small and what is big - a small feature may have a big impact (and that is not obvious to small fry like me) |
| 20:22.49 | Corydon76-home | malcolmd: the problem is that we're not exactly good at making the prediction of 'not likely to hose up the world' |
| 20:23.29 | Corydon76-home | Or rather, we're not good at making that prediction reliably |
| 20:23.44 | jmls | aren't you getting a shit load better, though ? Your test suites and stuff must aid identification of problems. |
| 20:23.53 | kpfleming | adding stuff to the beta extends the beta test period |
| 20:24.07 | kpfleming | we planned this beta test period taking into account very, very few new features after beta1 |
| 20:24.25 | kpfleming | jmls: the test suite doesn't even cover 10% of asterisk's functionality |
| 20:24.35 | kpfleming | granted, it's a huge improvement over not having one |
| 20:24.37 | jmls | ok. |
| 20:24.38 | kpfleming | massive, even |
| 20:25.02 | jmls | any little helps, that's for sure |
| 20:25.27 | Corydon76-home | At this point, I really think we ought to hold off on the sip security event reporting stuff. Making any exception at all really causes enormous problems, as we're seeing now. |
| 20:26.04 | Corydon76-home | 1.4 had the same issue with the DTMF rewrite. If we don't have all the features in place, then we shouldn't branch. Period. |
| 20:26.04 | jmls | Corydon76-home: or make a strategic decision that this warrants delaying the beta / rc |
| 20:26.56 | kpfleming | i committed to putting the sip security event stuff in weeks ago, and the only reason it's happening now instead of then is because it didn't get any reviews until we had JonathanRose do it this week |
| 20:26.57 | Corydon76-home | jmls: that's the same as delaying the branch |
| 20:27.11 | kpfleming | it would have been in quite some time ago if it had had community review, but such is life |
| 20:27.27 | Corydon76-home | Once we create a branch, the very next step is to create a beta |
| 20:29.00 | Corydon76-home | kpfleming: I understand your position, but the inconsistency in "no new features once we've branched" is clearly causing a problem. |
| 20:29.34 | malcolmd | inconsistency is inevitable. |
| 20:30.06 | kpfleming | the sip security events stuff is not causing this problem. they haven't even been merged yet, and i don't see anyone using them as an excuse to merge their own stuff. |
| 20:30.10 | Corydon76-home | malcolmd: Not really, no. If we hold the window open on a particular feature, that just means not branching. It's fairly simple. |
| 20:30.29 | kpfleming | no, that's very different |
| 20:30.46 | kpfleming | it's quite common to make a decision that a release is going to consist of "this revision plus a few selected changes" |
| 20:31.01 | kpfleming | as opposed to "anything that happens to get committed in the next two weeks" |
| 20:31.56 | Corydon76-home | Well, and then there's the process of stabilization. Until now, there have been very few cases where we intentionally remove a feature from a branch because it's just not ready for release |
| 20:31.58 | jsmith | May I make a suggestion? In Fedora we freeze for beta, and any new feature added after that point has to be granted an exception |
| 20:32.25 | kpfleming | that's exactly the situation we are in. i granted an exception for the sip security events work. |
| 20:32.55 | jsmith | We've found that it works quite well -- it's not so strict as to keep reasonable things from being added, but it's enough of a speedbump that it does a good job of separating the important items from the not-so-important items |
| 20:33.06 | Corydon76-home | Maybe it's time that a feature in before branch doesn't guarantee that it goes into the release, only if the feature is stabilized. We could remove features that aren't yet ready for primetime. |
| 20:34.04 | malcolmd | Corydon76-home: that's not bad general practice; something that was supposed to work turns out to work very poorly, yank it. |
| 20:34.22 | Corydon76-home | I specifically remember ganking the optional api stuff in one of the 1.6 branches, because it was not yet stable |
| 20:34.29 | kpfleming | and that's relevant if we were actually talking about removing anything that went in before we branched, right? |
| 20:34.37 | malcolmd | ;) |
| 20:35.11 | Corydon76-home | kpfleming: We're talking about a flexible deadline for new features in a release. |
| 20:35.24 | pabelanger | jsmith: right, I think that is a reasonable policy. The problem we have now, is new features are still being added into Asterisk 10, mostly likely by mistake, without the approval process. |
| 20:35.34 | kpfleming | for future releases. we aren't changing the deadline for Asterisk 10. |
| 20:35.40 | jmls | that's part of the nub of the problem. Something that needs to be stablised needs to be tested, however, if it is only in trunk then a lot of people won't install and test. If that new feature is available in a branch that I am running , then I am much more likely to try it out - if it fails, it's a simple reversion |
| 20:35.54 | kpfleming | that's why we make betas! |
| 20:35.58 | jsmith | pabelanger: If people can do that by mistake, it's not much of a freeze :-/ |
| 20:36.04 | Corydon76-home | If we extend the window out to get big new features... then we're really opening the door to smaller stuff, too |
| 20:36.06 | jsmith | pabelanger: More like a slush? |
| 20:36.10 | pabelanger | jsmith: I know :( |
| 20:36.26 | jmls | needs food |
| 20:36.38 | jmls | nobody is feeding this troll ;) |
| 20:36.58 | Corydon76-home | jmls: people don't run trunk or betas much anyway. That's why the first few releases tend to be a little bumpy |
| 20:37.03 | kpfleming | so... all of this is useful, but not for Asterisk 10. we are already in feature freeze, except for the one exception that has been made. anything else that is clearly a new feature and has already been merged needs to be reverted. |
| 20:37.11 | jmls | Corydon76-home: exactly |
| 20:37.16 | jsmith | ~buy jmls donut |
| 20:37.16 | infobot | ACTION goes to S-Mart and gets a dozen donuts for jmls |
| 20:37.35 | pabelanger | Corydon76-home: Well, a call for new features was posted to -dev mailing in June, but it didn't have a deadline attached to it. In the future should it be added? |
| 20:37.57 | jmls | say I'm running 10. I'm not going to beta test 11 - but I would probably try app_originate in my -10 system |
| 20:38.16 | kpfleming | pabelanger: yes it did |
| 20:38.26 | Corydon76-home | pabelanger: It's a difficult problem, because deadlines tend to be extended. But yes, it would be good to create a deadline, even if it will be extended |
| 20:38.35 | jmls | wife has just called to say "dinner is served" |
| 20:38.42 | jmls | :-D |
| 20:38.47 | jmls | runs for dinner |
| 20:38.49 | jmls | later |
| 20:38.49 | Corydon76-home | kpfleming: link? |
| 20:39.07 | kpfleming | i don't have time to look it up, i'm in the middle of something a bit more important, sorry |
| 20:40.06 | pabelanger | http://lists.digium.com/pipermail/asterisk-dev/2011-June/049508.html |
| 20:40.12 | pabelanger | That is the only I found |
| 20:40.23 | Corydon76-home | I'm seeing "end of June" as the deadline. |
| 20:40.57 | pabelanger | Same |
| 20:41.04 | pabelanger | So, that would have been to deadline for new features |
| 20:41.58 | Corydon76-home | and then the branch actually occurred on July 21st, with no intermediate suggestions of how the deadline was to be extended |
| 20:42.38 | kpfleming | IIRC, the deadline for suggesting things to be included was the end of june, and then the branch was created once all those things had been merged |
| 20:43.06 | kpfleming | that's about as flexible as a deadline could be |
| 20:44.31 | pabelanger | So, question / suggestion. What about creating some sort of timeline for our next Asterisk release? Kinda like how fedora does it? EG: http://fedoraproject.org/wiki/Releases/16/Schedule |
| 20:44.47 | kpfleming | isn't that already on the wiki? |
| 20:45.03 | pabelanger | Hmm, I don't believe we have the break down of the release process |
| 20:45.09 | pabelanger | just the expected ship dates |
| 20:45.19 | pabelanger | Unless I am missing something |
| 20:45.29 | kpfleming | sure, that would probably not be a terrible addition |
| 20:45.46 | seanbright | heh |
| 21:00.00 | jsmith | pabelanger: If only you understood how painful it is to build those schedules... See http://rbergero.fedorapeople.org/schedules/f-16/f-16-all-tasks.html |
| 21:00.01 | *** join/#asterisk-dev alecdavis (~alec@202.36.76.21) |
| 21:02.16 | Corydon76-home | kpfleming: could you add 'repotools' as a repository to reviewboard please? |
| 21:02.34 | kpfleming | i don't know how :-) |
| 21:02.40 | Corydon76-home | Who does? |
| 21:02.58 | kpfleming | unknown at this time.. i have not spent any time working with it since russell left |
| 21:04.20 | Corydon76-home | pokes seraphie |
| 21:04.29 | kpfleming | she has never looked at it either |
| 21:04.37 | kpfleming | honestly, russell was the only one who worked with it |
| 21:04.44 | kpfleming | we haven't had time to mess with it since he left |
| 21:05.21 | seraphie | Yeah, I have admin privileges, but I've never messed with the repos. |
| 21:05.47 | *** part/#asterisk-dev bob_kelso (~john@nat/digium/x-cqyqecgedmbafywj) |
| 21:06.10 | Corydon76-home | There were some discussions of modifying the default commit message of svnmerge, which I've spent a little time on |
| 21:06.40 | Corydon76-home | So that the original message was in the first line instead of the horribly nondescriptive "Merge revisions..." |
| 21:10.35 | pabelanger | jsmith: Wow, that is impressive! |
| 21:11.03 | Qwell | Corydon76-home: it's still got weird stuff at the start of the merged commit msg |
| 21:11.30 | Corydon76-home | Qwell: I know, I haven't figured out where that is generated |
| 21:11.46 | jsmith | pabelanger: We use a program called "TaskJuggler" to build our schedule (and handle schedule slips, so that everything cascades) |
| 21:11.49 | russellb | leifmadsen: email me to remind me and i can add repotools to reviewboard |
| 21:11.54 | jsmith | pabelanger: but it's not for the faint of heart |
| 21:12.03 | leifmadsen | 302 redirects to Corydon76-home |
| 21:12.21 | russellb | oops, thought you asked |
| 21:14.53 | Corydon76-home | Qwell: found it, fixing |
| 21:17.35 | malcolmd | jsmith: yeah, that's a lot of work just to generate fancy charts :D |
| 21:18.12 | russellb | Corydon76-home: repotools added to reviewboard |
| 21:18.16 | jsmith | malcolmd: It does a lot more than generate fancy charts... but OK :-) |
| 21:18.20 | Corydon76-home | russellb: Danke |
| 21:18.23 | russellb | np |
| 21:20.56 | leifmadsen | russellb: did you document that?! :) |
| 21:21.06 | leifmadsen | jsmith: +1 |
| 21:36.24 | Corydon76-home | Okay, review request posted |
| 21:36.59 | russellb | leifmadsen: document what, how to add a repo? no, reviewboard.org has it documented in their admin manual though (probably) |
| 21:37.05 | russellb | it's easy ... asuming you have admin access |
| 21:37.49 | leifmadsen | :) |
| 21:37.53 | leifmadsen | russellb: I was trolling |
| 21:38.01 | leifmadsen | it's past 5pm here |
| 22:17.52 | *** part/#asterisk-dev alecdavis (~alec@202.36.76.21) |
| 22:55.39 | *** join/#asterisk-dev tamiel (~tamiel@ip-183.net-81-220-86.toulouse.rev.numericable.fr) |
| 23:58.35 | *** join/#asterisk-dev sruffell (~Adium@asterisk/the-kernel-guy/sruffell) |
| 23:58.36 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |