IRC log for #asterisk-bugs on 20090130

00:08.59*** part/#asterisk-bugs Deeewayne (n=Deeewayn@nat/digium/x-30026985dab3097d)
01:14.57*** join/#asterisk-bugs Entomologist (n=nobody@76.164.171.226) [NETSPLIT VICTIM]
01:31.15*** join/#asterisk-bugs guax (n=guaxinim@unaffiliated/guaxinim)
03:07.01*** join/#asterisk-bugs angler_ (n=angler@nat/digium/x-9c4a2a2b7643e5f0)
03:20.32*** join/#asterisk-bugs mnicholson (n=mnichols@nat/digium/x-d5739f07ac479de2)
03:39.24*** join/#asterisk-bugs Deeewayne (n=dwayne@c-76-29-245-9.hsd1.al.comcast.net)
03:39.25*** mode/#asterisk-bugs [+o Deeewayne] by ChanServ
04:26.15*** join/#asterisk-bugs Entomologist (n=nobody@76.164.171.226) [NETSPLIT VICTIM]
04:42.08*** join/#asterisk-bugs JunK-Y (n=junky@modemcable156.137-20-96.mc.videotron.ca)
04:42.08*** mode/#asterisk-bugs [+o JunK-Y] by ChanServ
08:02.05*** join/#asterisk-bugs oej (n=olle@ns.webway.se)
10:42.51*** join/#asterisk-bugs oej (n=olle@80.251.192.3)
11:24.40*** join/#asterisk-bugs caio1982 (i=caio1982@CAcert-br/caio1982)
11:33.42*** join/#asterisk-bugs guax (n=guaxinim@unaffiliated/guaxinim)
12:26.47*** join/#asterisk-bugs oej (n=olle@ns.webway.se)
13:42.07*** join/#asterisk-bugs russellb (n=russell@asterisk/digium-open-source-team-lead/russellb)
13:42.07*** mode/#asterisk-bugs [+o russellb] by ChanServ
14:00.45*** join/#asterisk-bugs lmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage)
14:00.45*** mode/#asterisk-bugs [+o lmadsen] by ChanServ
14:12.17lmadsenwtf?! Every morning I wake up to 352 bugs open
14:19.27Deeewaynelmadsen, ever see the Blair Witch Project ?
14:31.53lmadsenno :)
14:35.47Entomologist*** CLOSED (14043) [General] Crash (included coredump)
14:35.47EntomologistAssigned to: putnopvut
14:35.47EntomologistReported by: ibc  Karma: 3.25
14:35.47Entomologisthttp://bugs.digium.com/view.php?id=14043
14:35.47Entomologist*********************************************************
14:36.03lmadsendecides not to wait 10-20 days for a report back
14:59.16oejibc not reporting back? That's strange. He's a Kamailio developer, like klaus3000
14:59.46oejHere in Europe, there's posters everywhere for "File an Asterisk bug today, before Leif wakes up! Make him stay busy!"
14:59.52lmadsenoej: :)
15:00.09oejAnd the bumper stickers are not fun any more either. "Bug a Madsen - file a report!"
15:00.16oejGood morning, Leif!
15:00.22lmadsenoej: he was going to report back in 10-20 days, but putnopvut is 99.999% sure that the problem is solved, so I decided just to close it, and he can reopen if it is really still an issue
15:00.35lmadsenoej: godmorgen!
15:00.41oejYep, I was just surprised. He answers my e-mails within minutes
15:00.54lmadsenya, it's because the problem only manifests itself after several days
15:01.04lmadsenthat's why the long lead time to a report
15:01.10oejibc has written a 150% compliant SIP parser... Very detailed code, mostly based on the RFC syntax.
15:03.27lmadsenoh, so it doesn't work then
15:03.29lmadsen:)
15:04.44*** join/#asterisk-bugs putnopvut (n=putnopvu@nat/digium/x-5e73f9b25601b35e)
15:04.44*** mode/#asterisk-bugs [+o putnopvut] by ChanServ
15:05.03lmadsenM14043
15:05.05MuffinMan[closed] [Asterisk] General 0014043: Crash (included coredump) reported by ibc (Karma: +3.25) http://bugs.digium.com/view.php?id=14043
15:10.47lmadsenputnopvut: I have 20 more bugs for you today
15:10.54lmadsenand I need them closed by lunch
15:10.55putnopvutlmadsen: excellent
15:11.15lmadsenoej is already hard at work on the other 20
15:11.36lmadsenwe're gonna get below 300 bugs today damnit!
15:12.10oejHa ha
15:12.16lmadsendon't you laugh
15:12.33oejBtw, the CHANGES change I did, was only committed to 1.6.1 branch. I don't know if that should go in trunk too
15:12.36putnopvutlmadsen: you could just close them all as "won't fix"
15:13.02oejis working on some SIP bugs and cancel_elsewhere take 3
15:13.28lmadsenoej: hmmmm... that is a good quesiton... I would assume it should under a new heading at the top for the 1.6.2 branch?
15:15.05oejI would suggest that we copy the release version when we release
15:15.18oejOtherwise it would be a lot of extra job before release with keeping them in synch
15:15.30oejSo I would delegate that to our release manager to handle at release time ;-)
15:15.56lmadsenbut what about changes that only go into trunk and not a branch? How are we tracking those?
15:16.11lmadsendoes the CHANGES file get cleaned each time we branch?
15:16.20lmadsen(cleaned in trunk I mean)
15:19.20lmadsencurses dd-wrt
15:19.33lmadsenbrb... gonna try rebooting the router to see if it fixes this problem, but I'm pretty sure it won't
15:22.01oejI think you might want a CHANGES in trunk that only covers trunk
15:22.17oejAnd when we branch to a release branch, you want to update that CHANGES with previous CHANGES files
15:27.36lmadsenthat would work for me
15:28.13lmadsenI mostly agree on the CHANGES in trunk only affecting what is currently in trunk, then when we branch, we update to put the previous CHANGES under it, and add a header that says Changes Between 1.6.x and 1.6.X
15:28.21lmadsen(like what we have now)
15:28.40lmadsenotherwise it'll be too hard to keep up to date I would think
15:35.39*** join/#asterisk-bugs Deeewayne (n=Deeewayn@nat/digium/x-6e367bc594bc4f23)
15:35.39*** mode/#asterisk-bugs [+o Deeewayne] by ChanServ
15:39.14*** join/#asterisk-bugs russellb (n=russell@asterisk/digium-open-source-team-lead/russellb)
15:39.14*** mode/#asterisk-bugs [+o russellb] by ChanServ
15:55.23*** join/#asterisk-bugs jpeeler (n=jpeeler@asterisk/digium-software-dev/jpeeler)
17:47.45Entomologist*** CLOSED (14274) [Applications/app_parkandannounce] Revision 169154 One Touch Park cannot be more than once per call
17:47.45EntomologistAssigned to: otherwiseguy
17:47.45EntomologistReported by: aragon  Karma: 3.25
17:47.45Entomologisthttp://bugs.digium.com/view.php?id=14274
17:47.45Entomologist*********************************************************
18:30.59Entomologist*** CLOSED (14016) [General] [patch] include linux/semaphore.h for kernel 2.6.26 and onwards
18:30.59EntomologistReported by: travishein  Karma: 2.75
18:30.59Entomologisthttp://bugs.digium.com/view.php?id=14016
18:30.59Entomologist*********************************************************
18:58.58*** join/#asterisk-bugs russellb (n=russell@asterisk/digium-open-source-team-lead/russellb)
18:58.58*** mode/#asterisk-bugs [+o russellb] by ChanServ
19:13.02*** join/#asterisk-bugs eliel (n=eliels@201.220.173.63)
22:05.36putnopvutcodefreeze-lap: ping
22:05.47codefreeze-lapyou rang?
22:05.51putnopvutI did.
22:05.59putnopvutI have an issue that I wanted to ask you about.
22:06.01putnopvutM14347
22:06.03MuffinMan[feedback] [Asterisk] Channels/chan_sip/Transfers 0014347: Transfer executes callers channel in wrong context reported by alesz (Karma: neutral) http://bugs.digium.com/view.php?id=14347
22:06.12putnopvutThe title of the bug is actually a bit misleading.
22:06.18putnopvutLet me explain things a bit.
22:07.06*** join/#asterisk-bugs seanbright (n=sean@asterisk/contributor-and-bug-marshal/seanbright) [NETSPLIT VICTIM]
22:07.06*** join/#asterisk-bugs eliel (n=eliels@201.220.173.63) [NETSPLIT VICTIM]
22:07.06*** mode/#asterisk-bugs [+o seanbright] by irc.freenode.net
22:07.33putnopvutParty A is in a macro and uses Dial to call party B. Party B then blind transfers A
22:07.35putnopvutThe TRANSFER_CONTEXT is set to some context.
22:07.44putnopvutNow, party A immediately executes the h exten in the transfer context and then moves on to the actual extension dialed by B.
22:08.07putnopvutYou can see a good example here: http://bugs.digium.com/view.php?id=14347#99115
22:08.37putnopvutI was just wondering if this might be covered by any other work you've been doing.
22:09.16*** join/#asterisk-bugs lmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage)
22:09.16*** mode/#asterisk-bugs [+o lmadsen] by ChanServ
22:10.40*** join/#asterisk-bugs russellb (n=russellb@asterisk/digium-open-source-team-lead/russellb)
22:10.40*** mode/#asterisk-bugs [+o russellb] by ChanServ
22:10.59codefreeze-lapWell, the jmls patch (14241) might affect that.... but then, maybe not; while I was working on it, I spotted a strangeness in blind xfers as far as what channel got the h exten run on it. So I fixed that; and it might have a bearing on this situation. I think it was happening when the peer did the xfer, and that *is* this situation.
22:11.48*** join/#asterisk-bugs eliel_ (n=eliels@201.220.173.63)
22:11.54codefreeze-lapso, have him try it again. I applied that patch to 1.4, trunk, and both 1.6.x's
22:13.50putnopvutcodefreeze-lap: excellent, that makes good sense actually.
22:14.10putnopvutI'll have him test it out.
22:14.59putnopvutThanks for the help. I'm glad I talked to you first before trying to go and fix this :)
22:19.49*** join/#asterisk-bugs eliel (n=eliels@201.220.173.63)
22:20.02putnopvutyikes, codefreeze-lap looks like the merge from 1.4 to trunk of that patch didn't go exactly smoothly.
22:20.24putnopvutYou redefined the 1 << 17 hangup flag in channel.h
22:20.42putnopvutAST_FLAG_BRIDGE_HANGUP_RUN and AST_FLAG_BRIDGE_HANGUP_DONT have the same value.
22:20.56putnopvutmind if I correct it?
22:21.02codefreeze-lapputnopvut: uh-oh...   yes, please!
22:22.07codefreeze-lapputnopvut: so much for an easy port to trunk...
22:22.07putnopvutyeah, if it seems too easy, probably something was off.
22:22.28codefreeze-lapputnopvut: very good! and you don't even have Murphy as your last name!
22:25.27lmadsenlol
22:26.26lmadsenI'm excited for 1.4.24. I think it'll be a good release
22:26.41lmadsenlots of issues appear to be getting resolved (issues that have been present for years too)
22:30.23putnopvutyears? really? That's pretty cool.
22:30.30codefreeze-lapUh, I feel fear about the patch for 13892; It's an important patch for cleaning up CDR's; I limited its scope as much as I could... the reporter will try it out tonight. Most of my other patches depend on it... but it got bigger today.
22:32.41putnopvutcodefreeze-lap: cool, it appears that your patch fixed the issue in 1.6.0 that I referred to earlier.
22:35.57codefreeze-lapgroovy
22:36.22lmadsenrad
22:39.23lmadsenputnopvut: ya, it seems some of the things terry has been working on w/r to parking and transfers have been there for a very long time (if not forever)
22:40.07lmadsencodefreeze-lap: if it is in re: to CDRs, I say whatever changes you need to make to "fix" the CDRs is encouraged, as how they are now appear to be somewhat broken
22:40.59lmadsenI'd like to get the CDRs into a state of being stable, even if they don't solve the problems for everyone. Get them into as good a shape as you can, and explain how they work, and keep them that way. We'll encourage the use of the Simple CDR and CEL stuff as we move forward once those are ready for use.
22:41.32lmadsenas you've said -- the way CDRs work now are going to be too much of a whack-a-mole thing, so we just need to get them into a state where they are at least predictable between version releases
23:37.31Entomologist*** CLOSED (14137) [Utilities/General] menuselect sets defaults too late
23:37.31EntomologistAssigned to: jpeeler
23:37.31EntomologistReported by: jnemeth  Karma: 0
23:37.31Entomologisthttp://bugs.digium.com/view.php?id=14137
23:37.31Entomologist*********************************************************
23:38.55*** part/#asterisk-bugs russellb (n=russellb@asterisk/digium-open-source-team-lead/russellb)

Generated by irclog2html.pl Modified by Tim Riker to work with infobot.