| 00:44.10 | *** join/#asterisk-dev sruffell (n=sruffell@asterisk/the-kernel-guy/sruffell) |
| 00:44.10 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 01:08.44 | *** join/#asterisk-dev Dovid (n=annon@tony09-121-90.inter.net.il) |
| 01:28.16 | *** join/#asterisk-dev djbelieny (n=djbelien@209-102-195-86.ipv4.intur.net) |
| 01:28.19 | *** part/#asterisk-dev djbelieny (n=djbelien@209-102-195-86.ipv4.intur.net) |
| 01:29.39 | *** join/#asterisk-dev eliel (n=eliels@151-202-114-200.fibertel.com.ar) |
| 01:29.39 | *** mode/#asterisk-dev [+o eliel] by ChanServ |
| 01:45.41 | *** join/#asterisk-dev eferro (n=eferro@124.127.217.87.dynamic.jazztel.es) |
| 01:47.02 | eferro | is setvar (at sip.conf, iax.conf, etc...) deprecated? |
| 01:47.32 | eferro | I have a setvar patch for mgcp, but I am not sure if it is interesting.... |
| 01:47.38 | jsmith-away | eferro: No, not in the slightest! |
| 01:48.05 | jsmith-away | eferro: (meaning that it's not deprecated, not trying to say it's not interesting) |
| 01:48.58 | eferro | jsmith-away, ok |
| 01:49.31 | jsmith-away | wanders off to dinner |
| 01:50.14 | russellb | yep, patch would be welcome |
| 01:51.50 | eferro | To implement the mgcp setvar support i copy&paste add_var function from sip... can this function be moved to chanvars.c for not duplicate??? |
| 01:56.15 | eferro | Should I send the mgcp setvar patch with the chan_sip::add_var funct replicated at chan_mgcp.c? or should I send another patch to move add_var funct to chanvar.c? |
| 02:29.41 | *** join/#asterisk-dev bbryant (n=brett@c-68-59-20-153.hsd1.sc.comcast.net) |
| 02:29.41 | *** mode/#asterisk-dev [+o bbryant] by ChanServ |
| 02:44.33 | *** part/#asterisk-dev eferro (n=eferro@124.127.217.87.dynamic.jazztel.es) |
| 02:47.18 | *** join/#asterisk-dev mog (n=mog@c-68-62-169-246.hsd1.al.comcast.net) |
| 02:47.19 | *** mode/#asterisk-dev [+o mog] by ChanServ |
| 02:51.24 | *** join/#asterisk-dev tzafrir_laptop (n=tzafrir@bzq-179-75-202.static.bezeqint.net) |
| 02:51.24 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 03:01.32 | *** join/#asterisk-dev moy (n=moy@CPE001cdfec4cee-CM00080dab8485.cpe.net.cable.rogers.com) |
| 03:49.14 | *** join/#asterisk-dev xpot (n=james@67.222.236.132) |
| 03:52.05 | *** join/#asterisk-dev shazaum (n=shazaum@unaffiliated/shazaum) |
| 06:08.13 | *** join/#asterisk-dev mort___ (n=mort@user-54405220.wfd76b.dsl.pol.co.uk) |
| 06:34.16 | oej | Morning |
| 06:48.07 | snuff-work | ello oej |
| 07:03.01 | *** join/#asterisk-dev flohack (n=fhackenb@lancelot.acoveo.com) |
| 08:00.21 | *** join/#asterisk-dev Pazzo (n=ugelt@reserved-225136.rol.raiffeisen.net) |
| 08:08.27 | mvanbaak | hey oej |
| 08:10.43 | *** join/#asterisk-dev tamiel (n=tamiel@213.30.183.226) |
| 09:04.13 | *** join/#asterisk-dev sergee (n=serg@voip1.west-call.com) |
| 09:40.07 | *** join/#asterisk-dev snuff-home (n=snuffy@203-219-29-182-bri-ts6-2600.tpgi.com.au) |
| 09:40.08 | *** mode/#asterisk-dev [+o snuff-home] by ChanServ |
| 09:46.02 | *** join/#asterisk-dev Daviey (n=Daviey@ubuntu/member/pdpc.gold.Daviey) |
| 09:54.50 | PDani | russellb, are you here? |
| 10:30.05 | mvanbaak | nope, he's not |
| 10:30.29 | mvanbaak | he's been away for 8 hours and 30 minutes |
| 11:13.54 | *** join/#asterisk-dev davevg (n=davevg__@nj-67-76-177-147.sta.embarqhsd.net) |
| 12:16.26 | *** join/#asterisk-dev caio1982 (i=caio1982@CAcert-br/caio1982) |
| 12:33.13 | *** join/#asterisk-dev eliel (n=eliels@200.61.172.61) |
| 12:33.13 | *** mode/#asterisk-dev [+o eliel] by ChanServ |
| 12:36.00 | *** join/#asterisk-dev DarkRift (n=dark@bas1-sthubert21-1096590430.dsl.bell.ca) |
| 12:38.09 | jsmith | waves |
| 12:40.52 | *** join/#asterisk-dev shazaum (n=shazaum@unaffiliated/shazaum) |
| 12:45.20 | *** join/#asterisk-dev kpfleming (n=kpflemin@asterisk/digium-director-of-software-tech/kpfleming) |
| 12:45.21 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 13:09.29 | *** join/#asterisk-dev putnopvut (n=putnopvu@asterisk/master-of-queues/mmichelson) |
| 13:09.29 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 13:22.07 | *** join/#asterisk-dev leifmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 13:22.08 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 13:57.32 | *** join/#asterisk-dev anthm (n=anthm@freeswitch/developer/anthm) |
| 14:07.08 | *** join/#asterisk-dev anonymouz666 (n=anonymou@189.24.24.187) |
| 14:22.24 | *** join/#asterisk-dev Deeewayne (n=dwayne@75.76.254.162) |
| 14:22.25 | *** mode/#asterisk-dev [+o Deeewayne] by ChanServ |
| 14:29.25 | *** join/#asterisk-dev moy (n=chatzill@74.12.124.89) |
| 14:35.48 | *** join/#asterisk-dev Rem| (n=remi@bg-fw2out.monmouth.com) |
| 14:59.54 | *** join/#asterisk-dev Juggie (n=Juggie@CPE001601df17fb-CM001ceac25ada.cpe.net.cable.rogers.com) |
| 15:06.06 | *** join/#asterisk-dev eliel (n=eliels@200.61.172.61) |
| 15:06.06 | *** mode/#asterisk-dev [+o eliel] by ChanServ |
| 15:09.50 | *** join/#asterisk-dev kpfleming (n=kpflemin@asterisk/digium-director-of-software-tech/kpfleming) |
| 15:09.50 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 15:12.53 | *** join/#asterisk-dev qdk (n=qdk@81.7.168.130) |
| 15:20.31 | *** join/#asterisk-dev marv[work] (n=timr@router.asteriasgi.com) |
| 15:42.04 | *** join/#asterisk-dev CunningPike (n=CunningP@204.239.10.119) |
| 15:46.53 | *** join/#asterisk-dev fred-tmft (n=fred-tea@c-69-244-180-112.hsd1.mi.comcast.net) |
| 15:47.06 | *** part/#asterisk-dev fred-tmft (n=fred-tea@c-69-244-180-112.hsd1.mi.comcast.net) |
| 15:51.32 | *** join/#asterisk-dev juanmacuevas (n=cuevasca@130.230.11.115) |
| 15:52.14 | *** part/#asterisk-dev juanmacuevas (n=cuevasca@130.230.11.115) |
| 16:08.19 | *** join/#asterisk-dev shazaum (n=shazaum@unaffiliated/shazaum) |
| 16:10.19 | *** join/#asterisk-dev djbelieny (n=djbelien@72-48-61-165.dyn.grandenetworks.net) |
| 16:10.23 | *** part/#asterisk-dev djbelieny (n=djbelien@72-48-61-165.dyn.grandenetworks.net) |
| 16:31.28 | *** join/#asterisk-dev msetim (n=setim@200.195.162.210) |
| 16:31.36 | *** join/#asterisk-dev Octothorpe (n=Octothor@pdpc/supporter/professional/octothorpe) |
| 16:54.28 | Juggie | what does digium use for svn server replication? |
| 16:55.40 | kpfleming | svnsync |
| 16:56.20 | Juggie | how about for backups, is it possible to do a live backup of a running svn server? or would i need to replicate using svnsync to a slave then shut it down to preform the backup. |
| 16:57.06 | kpfleming | this is documented in the svn book... there is 'svn hotcopy', or 'svnadmin dump', or you can just take your chances (assuming a flat-file repo, not a BDB repo) |
| 16:57.37 | Juggie | awesome thanks, i'll dig up our oriley virtual book subscription or whatever its called and take a look at that book. |
| 16:57.52 | leifmadsen | Juggie: svnbook.red-bean.com |
| 16:57.55 | kpfleming | the svn book is online and free... |
| 16:57.55 | leifmadsen | online and free |
| 16:57.58 | leifmadsen | :) |
| 16:58.02 | Juggie | even better :) |
| 16:58.06 | leifmadsen | Creative Commons license |
| 16:58.06 | Juggie | thanks. |
| 16:58.11 | leifmadsen | just like TFoT |
| 17:05.24 | tzafrir_laptop | there are also some derivative work: |
| 17:05.28 | tzafrir_laptop | http://svkbook.elixus.org/ |
| 17:08.27 | leifmadsen | and http://astbook.asteriskdocs.org |
| 17:08.28 | leifmadsen | :) |
| 18:02.41 | seanbright | also, install the svn bash completions |
| 18:02.43 | seanbright | <3 |
| 18:05.19 | *** join/#asterisk-dev msetim (n=setim@200.195.162.210) |
| 19:00.33 | eliel | hu, time is up for gsoc applications :) |
| 19:02.12 | JunK-Y | lets cross our fingers! |
| 19:02.31 | JunK-Y | why do i waste my time on that usb stick!!! |
| 19:02.42 | eliel | 5887 proposals |
| 19:02.58 | eliel | 3497 students |
| 19:03.12 | *** join/#asterisk-dev msetim (n=setim@200.195.162.210) |
| 19:03.14 | JunK-Y | so the count will decrease a lot |
| 19:03.45 | eliel | only 1000 students will get accepted |
| 19:04.09 | eliel | of the 3497 also 1000 proposals will get accepted of the 5887 |
| 19:05.27 | JunK-Y | we'll wait impatiently for google to make their decision |
| 19:06.03 | eliel | actually digium will make the decision putting an order to the received proposals |
| 19:06.31 | eliel | google will only assign a number of slots to each org |
| 19:06.34 | JunK-Y | eliel: but there's a limit on projects by google, no? |
| 19:06.45 | JunK-Y | do you know that number? |
| 19:06.54 | eliel | yes, the number of slots per org is limited, no i don't know |
| 19:07.09 | putnopvut | Holy crap. |
| 19:07.19 | putnopvut | The number of Asterisk proposals has skyrocketed since yesterday. |
| 19:07.29 | JunK-Y | ya, 18 apparently? |
| 19:07.34 | eliel | putnopvut: how many? |
| 19:07.36 | putnopvut | 20 |
| 19:08.40 | JunK-Y | putnopvut: probably the most are undergraduate, right? |
| 19:08.47 | eliel | ups, I will start praying, hehehe |
| 19:09.10 | putnopvut | JunK-Y: Not sure. I think I'm going to set aside some time tomorrow and make comments on all of them. |
| 19:09.16 | JunK-Y | eliel: what were ur proposal? |
| 19:09.23 | putnopvut | It looks like someone (probably russell) has made comments on 18 of them. |
| 19:09.41 | eliel | not mine |
| 19:10.03 | eliel | JunK-Y: generic data get api (the idea posted on the list) |
| 19:10.20 | JunK-Y | coool cool |
| 19:11.57 | eliel | JunK-Y: which one was your proposal? |
| 19:12.02 | eliel | s/one// |
| 19:12.16 | JunK-Y | CLI filtering |
| 19:12.42 | eliel | JunK-Y: that will be a useful project |
| 19:13.00 | JunK-Y | ohh yes! |
| 19:13.32 | JunK-Y | if that project is going, ive contact few companies that i know to be able to test, so feedback will be really fast |
| 19:15.10 | eliel | I have started coding for the API it is my data_retrieval branch, if I don't get selected, maybe that could help anyway |
| 19:18.35 | JunK-Y | no work is lost, true. |
| 19:28.08 | *** join/#asterisk-dev anthm (n=anthm@freeswitch/developer/anthm) |
| 19:29.05 | *** join/#asterisk-dev djbelieny (n=djbelien@72-48-61-165.dyn.grandenetworks.net) |
| 19:30.22 | *** part/#asterisk-dev djbelieny (n=djbelien@72-48-61-165.dyn.grandenetworks.net) |
| 19:44.42 | eliel | based on this: http://socghop.appspot.com/document/show/program/google/gsoc2009/studentallocations |
| 19:45.06 | eliel | having 5887 proposals and 20 are for asterisk, the project could get 3-4 slots |
| 19:47.09 | seanbright | OT question: does anyone know what the 'sync' user on my centos install is doing? |
| 19:47.19 | Qwell | seanbright: syncing |
| 19:47.27 | seanbright | Qwell: ohhhh |
| 19:47.28 | seanbright | thanks |
| 19:47.31 | Qwell | np |
| 19:47.33 | seanbright | ~thwack Qwell |
| 19:47.36 | Qwell | :p |
| 19:47.50 | seanbright | infobot: wtf? |
| 19:47.50 | infobot | it has been said that wtf is what that's fine? |
| 19:48.07 | seanbright | Qwell: so you don't know? |
| 19:49.31 | Qwell | seanbright: no clue |
| 19:49.34 | seanbright | k |
| 19:50.38 | Qwell | sruffell: am I missing something obvious with issue 13930? Are you suggesting that we remove RTC support from dahdi_dummy entirely, because the kernel timers are better? |
| 19:54.42 | sruffell | Qwell...yes |
| 19:55.05 | Qwell | I'm rather amused by that |
| 19:55.12 | sruffell | based on how I understand it to work, I think RTC causes more problems than it solves. |
| 19:55.42 | Qwell | that does seem to be the case |
| 19:56.38 | sruffell | the one assumption that I'm making is that the host system can accurately know how much real time has passed...if that is not true...then it won't work as well...but I think that's fair to say that an asterisk systems should have a good time source. |
| 19:57.21 | Qwell | so, this also fixes the tick failure stuff? |
| 19:57.42 | sruffell | what I would *really* like to do is remove dahdi_dummy entirely, just make dahdi.ko know how to find a time source always, and dahdi_dummy is an internal implementation detail of dahdi.ko |
| 19:58.00 | sruffell | Qwell..yes it should. |
| 19:58.09 | Corydon76-dig | sruffell: woot |
| 19:58.25 | Qwell | sruffell: how difficult would that be to do? |
| 19:58.31 | sruffell | but there is still an ongoing debate about how to best determine which span will be the timing source.... |
| 19:58.52 | sruffell | I don't think it would be very difficult at all....if we use a simplified method like tzafrir suggested for master span selection. |
| 19:59.22 | sruffell | http://bugs.digium.com/view.php?id=13205 |
| 20:00.41 | Qwell | sruffell: neat. is there anything holding up 13930? |
| 20:01.03 | Qwell | or is it likely that it would all happen at once? |
| 20:01.27 | sruffell | I would like to hear that someone tested it out on Xen. |
| 20:01.40 | sruffell | ...once I hear that...I think it's good to be merged (I would like it in the next release) |
| 20:02.09 | Corydon76-dig | sruffell: I think that's fine, as long as you can force a timing override in the conf file |
| 20:02.13 | Qwell | WELL... |
| 20:02.26 | sruffell | force a timing override? |
| 20:02.31 | Qwell | Nothing really changes for Xen, right? Xen falls over terribly with RTC already. |
| 20:02.43 | Corydon76-dig | Force which span generates timing for dahdi |
| 20:02.56 | Corydon76-dig | just in case the algorithm guesses wrong |
| 20:03.09 | sruffell | yeah...but there is an alternative suggestion of using the processor tsc that I know works under Xen. The way I have it patched there is intended to be more portable...but I want to know if it works as well. |
| 20:03.19 | Corydon76-dig | Think of it as a stopgap while a bug is fixed in the following release |
| 20:03.34 | Qwell | sruffell: I'll get somebody to test it |
| 20:03.53 | sruffell | Corydon76-gig: Yeah...but then there still needs to be an order...i.e. who becomes the timing source if the span goes into alarm, etc. |
| 20:04.28 | sruffell | and if that involves an interface change, I would rather not create too much churn on the release numbers since it for x.y.z, y would need to be bumped on an interface change. |
| 20:05.09 | sruffell | what I realize that I don't have alot of good experience with is taking timing from a dynamic span...that is why the others participants in 13205 probably need to sign on to anything we do. |
| 20:05.17 | sruffell | just my opinion. |
| 20:05.23 | Corydon76-dig | sruffell: I hear you, but wouldn't the removal of dahdi_dummy pretty much mean an interface change anyway? |
| 20:05.43 | sruffell | yes....which is why I would like to keep all those changes together in one release cycle. |
| 20:05.54 | sruffell | not the upcomming 2.2 release. |
| 20:07.41 | sruffell | actually...let me clarify...even after working on the drivers / kernel for over 18 months...what I don't know about how everything is used is still WAY more than what I do know. But at least I think I'm starting to realize most of what I don't know. |
| 20:08.10 | seanbright | we know |
| 20:08.20 | seanbright | (just wanted to say 'know' again) |
| 20:08.23 | sruffell | lol |
| 20:12.29 | tzafrir_laptop | sruffell, it also needs to be tested outside of Xen |
| 20:13.29 | sruffell | I've tested it across several different platforms outside of Xen...and with different HZ values....and the results have all been positive so far. |
| 20:13.43 | tzafrir_laptop | Corydon76-dig, what interface is changed there? |
| 20:14.25 | sruffell | tzafrir_laptop: there would be no user visibility that dahdi_dummy exists....that would be an interface change. |
| 20:14.46 | tzafrir_laptop | Making dahdi_dummy "internal" does change things if it automatically gets span no. 1 |
| 20:15.30 | sruffell | I don't even think it should get span 1. I think it should just be internal....pseudo channels will work whether the user believes there are any spans registered or not. |
| 20:15.54 | sruffell | there would be no need for any user to have to grok what dahdi_dummy is for. |
| 20:16.08 | sruffell | or what a "span" is if all they want to do is conference sip channels. |
| 20:19.11 | tzafrir_laptop | users don't care. But does this work with dahdi? |
| 20:19.26 | sruffell | does what work with dahdi? |
| 20:19.38 | sruffell | I'm talking about changing dahdi... |
| 20:19.38 | tzafrir_laptop | the timing source is not a span |
| 20:20.41 | sruffell | oh...it might still be implemented internally as a span (although I'm not sure that is needed...all that is really needed is that the "master" span processing in dahdi_receive and dahdi_transmit need to be called....doesn't matter if it comes in on a span) but the user shouldn't have to know how we've implemented internally. |
| 20:21.08 | sruffell | but it would then be a "special" span that isn't visibile. |
| 20:21.48 | sruffell | isn't that one of the biggest mistakes in UI design? That designers assume the user has a mental model of how the software is designed? |
| 20:54.50 | *** join/#asterisk-dev djbelieny (n=djbelien@209-102-195-86.ipv4.intur.net) |
| 20:54.54 | *** part/#asterisk-dev djbelieny (n=djbelien@209-102-195-86.ipv4.intur.net) |
| 21:10.02 | *** join/#asterisk-dev qdk (n=qdk@0x573d8dd1.bynqu2.dynamic.dsl.tele.dk) |
| 21:13.47 | Qwell | putnopvut: ping? |
| 21:16.18 | putnopvut | Qwell: the pong is on fire |
| 21:16.29 | Qwell | 1.6.0, r179220 |
| 21:16.36 | putnopvut | commit asterisk 179220 |
| 21:16.41 | MuffinMan | [179220] Committed by mmichelson on 2009-03-01T21:52:39.773606Z: Merged revisions 179219 via svnmerge from |
| 21:16.41 | MuffinMan | ..https://origsvn.digium.com/svn/asterisk/trunk |
| 21:16.41 | MuffinMan | .. |
| 21:16.41 | MuffinMan | .......... |
| 21:16.41 | MuffinMan | .. r179219 | mmichelson | 2009-03-01 15:45:08 -0600 (Sun, 01 Mar 2009) | 18 lines |
| 21:16.44 | MuffinMan | .. |
| 21:16.46 | MuffinMan | .. Properly free memory and remove scheduler entries when a transmission failure occurs. |
| 21:16.50 | MuffinMan | .. |
| 21:16.52 | MuffinMan | .. Previously, only the "data" field of the sip_pkt created during __sip_reliable_xmit |
| 21:16.53 | Qwell | ^^^says that only data was freed |
| 21:16.54 | MuffinMan | .. was freed when XMIT_FAILURE was returned by __sip_xmit. When retrans_pkt was called, |
| 21:16.57 | MuffinMan | .. this inevitably resulted in the reading and writing of freed memory. |
| 21:17.00 | MuffinMan | .. |
| 21:17.02 | MuffinMan | .. XMIT_FAILURE is a condition meaning that we don't want to attempt resending the packet |
| 21:17.06 | MuffinMan | .. at all. The proper action to take is to remove the scheduler entry we just created, |
| 21:17.08 | MuffinMan | .. free the packet's data as well as the packet itself, and unlink it from the list of |
| 21:17.11 | MuffinMan | .. packets on the sip_pvt structure. |
| 21:17.13 | MuffinMan | .. |
| 21:17.14 | *** mode/#asterisk-dev [+b MuffinMan!*@*] by seanbright |
| 21:17.16 | seanbright | you get the idea |
| 21:17.24 | putnopvut | yeah. |
| 21:17.25 | Qwell | So, is there some reason that the ast_free(pkt->data) was added, if it's already being freed? |
| 21:17.27 | putnopvut | I remember that one. |
| 21:17.30 | Qwell | M14819 |
| 21:17.42 | *** mode/#asterisk-dev [-b MuffinMan!*@*] by seanbright |
| 21:17.52 | putnopvut | M14819 |
| 21:17.53 | MuffinMan | [feedback] [Asterisk] Channels/chan_sip/General 0014819: Chan_sip core dump on program execution reported by cwolff09 (Karma: neutral) http://bugs.digium.com/view.php?id=14819 |
| 21:18.24 | putnopvut | Qwell: did you read the notes? |
| 21:18.27 | Qwell | somebody in #asterisk just reported the same thing. 1.6.0.6 is fine, 1.6.0.7 is not. he gets that warning message |
| 21:18.41 | Qwell | the notes on 14819? |
| 21:18.56 | putnopvut | Oh, I see. Hold on a sec. |
| 21:19.29 | Qwell | oh, woah. patch looks different from what was committed |
| 21:19.55 | putnopvut | Think it may have been a bad merge by me? |
| 21:20.07 | Qwell | trunk>1.6.0 looks bad, yeah |
| 21:20.35 | putnopvut | Hmm, current trunk vs. 1.6.0 are exactly the same. |
| 21:20.48 | Qwell | 1.6.0 didn't have the if (pkt->data) part |
| 21:21.10 | Qwell | which is bizarre |
| 21:21.15 | putnopvut | trunk doesn't have it either right now. |
| 21:21.32 | Qwell | right, but that means 1.6.0 was never freeing it |
| 21:21.53 | putnopvut | I think I need to look at the actual issue instead of trying to guess what's happening based on what you're telling me. |
| 21:21.56 | snuff-home | mm.. what's the go with falves.. he was happy with MS SQL.. now he switches to sybase? |
| 21:22.22 | Qwell | in trunk, pkt->data is a string field |
| 21:22.31 | Qwell | it is not such in 1.6.0 |
| 21:22.43 | putnopvut | ah |
| 21:22.47 | putnopvut | it's not? |
| 21:23.07 | Qwell | nope |
| 21:23.11 | putnopvut | #$*(&@ |
| 21:23.29 | Qwell | heh, there's no way you could've caught that in the merge |
| 21:23.47 | putnopvut | wait, you mean an ast_str, right? Not a string field. |
| 21:23.53 | Qwell | err, sorry, yeah |
| 21:24.06 | Qwell | I fail at reading |
| 21:24.07 | putnopvut | Yeah, you can't free pkt->data in 1.6.0. Now I get it. |
| 21:24.13 | putnopvut | All right. |
| 21:24.18 | putnopvut | I'll fix it. |
| 21:24.40 | seanbright | you know who would have caught that earlier? |
| 21:24.43 | Qwell | 1.6.1 appears to be correct |
| 21:24.48 | seanbright | that's right... stevie_ramjet |
| 21:24.55 | putnopvut | Yeah, it's only 1.6.0 that's wrong right now. |
| 21:25.33 | Qwell | think we'll need to do a new release for this? |
| 21:26.19 | putnopvut | It's probably a good idea. That condition pretty much could mean a crash whenever bad network conditions arise. |
| 21:26.35 | Qwell | 1.6.0.8.1! |
| 21:26.40 | seanbright | nope |
| 21:26.41 | Qwell | (I kid) |
| 21:26.57 | seanbright | you kidder you |
| 21:27.55 | putnopvut | fixed |
| 21:31.00 | snuff-home | question.. there was talk during week of using a different sip stack with a compatiable license.. |
| 21:31.25 | snuff-home | when would that be seriously looked at.. next astricon or similar? |
| 21:34.13 | tzafrir_laptop | Is there any code that relies on 'show file version' to show $Revision$ and will break if it will be replace with $Id$ ? |
| 21:34.19 | kpfleming | i am scheduled to start detailed research on it in the next couple of weeks |
| 21:34.35 | seanbright | blinks |
| 21:34.37 | seanbright | for serious? |
| 21:34.47 | kpfleming | tzafrir_laptop: there is no code, it's the AST_FILE_VERSION macro calls in each file that supply the version string |
| 21:34.51 | kpfleming | seanbright: yes, research only for now |
| 21:34.55 | seanbright | interesting |
| 21:35.18 | tzafrir_laptop | kpfleming, saw that. I asked about anything that uses its output |
| 21:35.48 | kpfleming | oh... that depends on what you mean, i guess |
| 21:36.06 | kpfleming | we have build test scripts here that verify that our binary builds were made from the expected sources |
| 21:36.09 | Corydon76-dig | tzafrir_laptop: you risk breaking people who use the output in their frameworks |
| 21:36.56 | Corydon76-dig | Those people also bitch the loudest about 'Digium' breaking their frameworks |
| 21:37.13 | tzafrir_laptop | I guess. On the bright side, it gives a much more meaningful output for a simple 'ident /usr/sbin/asterisk' or 'ident /usr/lib/asterisk/modules/*' |
| 21:37.38 | kpfleming | then build the ID string into the module in a different way that doesn't harm AST_FILE_VERSION |
| 21:43.56 | tzafrir_laptop | next question: any point filing a bug asking this to be changed? |
| 21:44.02 | kpfleming | no |
| 21:44.10 | kpfleming | because your 'ask' would have to include a patch :-) |
| 21:45.07 | tzafrir_laptop | grep -l ASTERISK_FILE_VERSION */*.c | xargs sed -i -e '/ASTERISK_FILE_VERSION/s/\$Revision/\$Id/' |
| 21:45.18 | kpfleming | no, you did not listen to what i said above |
| 21:45.22 | kpfleming | you can't change AST_FILE_VERSION |
| 21:45.28 | kpfleming | or ASTERISK_FILE_VERSION |
| 21:45.38 | kpfleming | but you could add an ASTERISK_FILE_ID macro that embedded the Id string |
| 21:46.09 | tzafrir_laptop | I'm not. I'm changing lines that use it: apps/app_adsiprog.c:ASTERISK_FILE_VERSION(__FILE__, "$Id: 154578 $") |
| 21:46.22 | kpfleming | you are changing the contents of what it stores in the file |
| 21:46.24 | tzafrir_laptop | ah, ok |
| 21:46.29 | kpfleming | which changes what the CLI command outputs |
| 21:49.46 | snuff-home | who looks after app_fax related stuff? file? |
| 21:51.14 | file | hrm? I could |
| 21:51.19 | file | why do you ask? |
| 21:51.34 | snuff-home | M14769 |
| 21:51.36 | MuffinMan | [ready for review] [Asterisk] Applications/app_fax 0014769: [patch] Improvements/fixes for app_fax reported by andrew (Karma: +18.25) http://bugs.digium.com/view.php?id=14769 |
| 21:51.55 | snuff-home | bout 3 ppl say it fixes their issue.. can't be all bad.. |
| 21:51.56 | file | yeah, I've been working on other issues |
| 21:52.43 | snuff-home | np.. |
| 21:54.16 | snuff-home | so should i assign to you that way ppl know someone is reviewing? |
| 21:54.43 | file | you can but I can't say when I will get to it |
| 21:56.01 | tzafrir_laptop | hmm... what's the impat of SPANDSP_EXPOSE_INTERNAL_STRUCTURES ? |
| 21:57.03 | kpfleming | someone would have to ask steve underwood |
| 21:58.17 | snuff-home | from memory tzafrir_laptop basically access a structure field directly i'd say.. not using the API |
| 21:59.07 | snuff-home | mm time for haircut.. |
| 22:09.24 | *** join/#asterisk-dev jameswf (n=james@unaffiliated/jameswf-home) |
| 22:19.58 | jameswf | dead all over did i miss a holliday |
| 22:20.11 | file | Friday. |
| 22:20.19 | jameswf | can we close for world cleavage day? |
| 22:22.08 | wedhorn | yeah, I checked my mailserver because of the lack of activity on -dev |
| 22:27.49 | Qwell | Way to break the silence there, jameswf |
| 22:51.34 | kpfleming | WOOT. 8824 is done. |
| 22:52.08 | tzanger | 6321 is done too, but not working :-( |
| 23:20.53 | *** join/#asterisk-dev djbelieny (n=djbelien@38.114.108.2) |
| 23:21.32 | *** part/#asterisk-dev djbelieny (n=djbelien@38.114.108.2) |
| 23:49.46 | wedhorn | it appears r186078 (the RTP stuff) killed skinny, did mvanbaak provide any feedback? |
| 23:51.52 | file | no |
| 23:53.56 | wedhorn | ok, can't see any obvious reason why it should have done so, maybe we were doing something wrong |
| 23:54.27 | wedhorn | mvanbaak: can you see if skinny in trunk is borked when you get a chance |