| 00:00.44 | seanbright | i see |
| 00:02.12 | seanbright | but for some reason we still commit changes to 1.4 that aren't fixing anything |
| 00:02.27 | seanbright | it all feels a little arbitrary to me i guess |
| 00:02.28 | seanbright | i dunno |
| 00:02.30 | seanbright | shrugs |
| 00:04.18 | kpfleming | do you have anything specific in mind? we really aren't supposed to be commiting non-functional changes to 1.4, except for build system, documentation, stuff like that |
| 00:04.34 | seanbright | heh |
| 00:04.40 | seanbright | you added that clause at the end |
| 00:04.43 | seanbright | so i have no argument |
| 00:04.51 | seanbright | "build system" |
| 00:04.54 | kpfleming | right |
| 00:05.04 | kpfleming | if it won't build with new compilers, new distros, etc. we have to fix that |
| 00:05.08 | kpfleming | otherwise people can't use it |
| 00:05.27 | kpfleming | and of course we always want better docs :-) |
| 00:05.42 | snuff-work | seanbright: i will get around to trying that patch hopefully by end of week.. (stupid solaris old builtins of automake/conf) |
| 00:05.56 | seanbright | snuff-work: i can just rebuild configure if that makes your life easier |
| 00:06.02 | snuff-work | yes much :) |
| 00:06.06 | seanbright | hold |
| 00:07.29 | seanbright | ok, i updated the patch |
| 00:07.45 | snuff-work | k |
| 00:09.36 | seanbright | snuff-work: that patch i uploaded doesn't include your changes to the -z tests, just so you know |
| 00:09.46 | seanbright | when i commit i will commit those fixes as well |
| 00:10.01 | snuff-work | yep no prob |
| 00:10.42 | seanbright | kpfleming: so are we going to release another 1.6.0.x? |
| 00:12.11 | seanbright | i can see us getting into a situation where something with SIP is broken in 1.6.x but it's fixed in 1.6.x+1 except now IAX is broken which is fixed in 1.6.x+2 but now CDRs are broken, etc. |
| 00:13.39 | seanbright | and if those "somethings" are "new" then we are basically telling the guy starting off with 1.6.whatever that he has to keep waiting |
| 00:13.47 | seanbright | it just feels... weird. |
| 00:14.03 | seanbright | i guess i should have piped up when the discussion was on the -dev list |
| 00:14.18 | seanbright | ah well. |
| 00:16.49 | snuff-work | seanbright: promising.. |
| 00:16.53 | snuff-work | checking for gmd5sum... no |
| 00:16.54 | snuff-work | checking for digest... digest |
| 00:17.03 | seanbright | that's a good start |
| 00:17.51 | snuff-work | now with it detecting digest it 'should' add the -a md5 when it comes around to using right? |
| 00:17.56 | seanbright | yes |
| 00:21.54 | seanbright | snuff-work: right after you type 'make' and start seeing the stuff in utils/ get compiled, you should be able to ^C the compile and then 'cat include/asterisk/buildopts.h' |
| 00:22.05 | seanbright | and it should have the md5 sum at the bottom |
| 00:22.09 | snuff-work | ok |
| 00:24.15 | snuff-work | #define AST_BUILDOPT_SUM "b063714582ba841b8fab6b8652cd2b77" |
| 00:24.18 | seanbright | hooray |
| 00:24.32 | *** join/#asterisk-dev anthm (n=anthm@freeswitch/developer/anthm) |
| 00:24.38 | seanbright | ok, i'll commit |
| 00:24.55 | seanbright | does that need to go into 1.4 as well? |
| 00:25.03 | seanbright | hrmmm |
| 00:25.06 | seanbright | i'd assume not |
| 00:25.22 | snuff-work | haven't tested against 1.4 .. |
| 00:25.26 | seanbright | yeah... don't |
| 00:25.27 | seanbright | :) |
| 00:25.34 | seanbright | not going to commit it there |
| 00:31.04 | seanbright | hmmmm |
| 00:31.27 | putnopvut | eats a suitcase filled with money. |
| 00:31.42 | snuff-work | mm leather.. |
| 00:32.37 | seanbright | putnopvut: that sounds unpleasant |
| 00:33.01 | putnopvut | yes...it does |
| 00:33.39 | eliel | putnopvut: about #13893, what about backward compatibility? which is the right option name being used in older versions? |
| 00:34.04 | putnopvut | eliel: in 1.4, the only option allowed is "followme-pls-hold-prompt" |
| 00:34.04 | seanbright | M13893 |
| 00:34.06 | MuffinMan | [new] [Asterisk] Applications/app_followme 0013893: [patch] Non existent option in the sample configuration file followme.conf (typo) reported by eliel (Karma: +176.50) http://bugs.digium.com/view.php?id=13893 |
| 00:34.25 | putnopvut | Allowing "hold-prompt" has only been around since mid-August. |
| 00:34.41 | putnopvut | So it's not in any released versions of Asterisk. |
| 00:35.31 | snuff-work | doesn't follow releases anymore just svn rev numbers.. nice not having to worry about prod environments anymore ;) |
| 00:35.33 | seanbright | pls-hold-prompt... sigh |
| 00:35.57 | seanbright | how about... please-hold-prompt |
| 00:35.58 | seanbright | heh |
| 00:36.14 | seanbright | that's like "creat()" |
| 00:36.15 | snuff-work | pls-hold-prompt.. should be talk-to-the-hand-prompt.. maybe dont-go-there-gf |
| 00:36.18 | seanbright | i will never understand |
| 00:36.18 | putnopvut | seanbright: if I had designed it from the beginning, definitely yes on spelling out the word "please" |
| 00:36.18 | seanbright | :) |
| 00:36.20 | jpeeler | vowels are expensive |
| 00:36.23 | eliel | for me is the same, i just whant to be consistent |
| 00:36.42 | putnopvut | creat has always bugged me too. |
| 00:36.43 | seanbright | jpeeler: on the wheel, mayhaps. |
| 00:36.57 | jpeeler | heh |
| 00:37.03 | eliel | is there any problem with bugs.digium.com? |
| 00:37.07 | seanbright | yes |
| 00:37.09 | putnopvut | I also don't like some of the unpronounceable names like "strrchr" |
| 00:37.10 | seanbright | too many open bugs |
| 00:37.13 | putnopvut | lol |
| 00:37.30 | putnopvut | Qwell closed like forty-two billion bugs today. |
| 00:37.34 | seanbright | 15 |
| 00:37.38 | putnopvut | eh, close. |
| 00:37.47 | seanbright | 15 < 42,000,000,000 |
| 00:38.08 | Qwell | only by a little |
| 00:38.11 | seanbright | yeah. i need to do my part instead of just bitching :) |
| 00:38.25 | seanbright | so far i've closed... 1 |
| 00:39.51 | putnopvut | I knocked out a couple myself today. Today has been good. |
| 00:39.53 | eliel | hmm, sorry, is my provider... |
| 00:40.14 | snuff-work | poked his only assigned bug reporter |
| 00:40.35 | seanbright | M13912 |
| 00:40.37 | MuffinMan | [closed] [Asterisk] Core/BuildSystem 0013912: My server explodes when runnin astrisk core reported by dickster (Karma: -5) http://bugs.digium.com/view.php?id=13912 |
| 00:40.40 | seanbright | <3 |
| 00:40.57 | snuff-work | thinks that guy was trippin |
| 00:41.06 | seanbright | that was just balls-out trolling |
| 00:41.09 | seanbright | god bless him |
| 00:42.42 | seanbright | when are russellb and file going to be allowed to work on asterisk again? |
| 00:42.52 | seanbright | can russellb and file come out to play!? |
| 00:42.52 | seanbright | heh |
| 00:44.02 | Corydon76-dig | seanbright: well, they are working on Asterisk |
| 00:44.38 | seanbright | semantics |
| 00:44.45 | seanbright | you know what i meant to think to say |
| 00:45.08 | Corydon76-dig | plays with seanbright |
| 00:45.59 | putnopvut | seanbright: file is so starved for working on Asterisk stuff that he has voluntarily taken on a bug whose fix will involve inheritable datastores, audiohooks, and channel masquerades. |
| 00:46.05 | putnopvut | god bless him |
| 00:46.20 | seanbright | the transfer monitor wackiness? |
| 00:46.55 | file | yes. |
| 00:47.19 | seanbright | you are a god amongst men |
| 00:47.40 | seanbright | ^H^H^Hputnopvut |
| 00:49.31 | seanbright | man... there's no easy bugs to fix |
| 00:49.38 | seanbright | i'm just going to go drinking |
| 00:49.48 | file | good idea |
| 00:50.15 | eliel | look at my reported bugs, they are always easy :) |
| 00:51.42 | putnopvut | eliel speaks the truth |
| 00:51.55 | putnopvut | but that's because he always has a patch handy. |
| 00:52.06 | putnopvut | It's easy when someone reports the problem and has a fix for it. |
| 00:52.31 | eliel | M13836 |
| 00:52.32 | MuffinMan | [assigned] [Asterisk] Channels/chan_dahdi 0013836: [patch] Use comma as the parameter separator. reported by eliel (Karma: +176.50) http://bugs.digium.com/view.php?id=13836 |
| 00:52.53 | eliel | M13858 |
| 00:52.55 | MuffinMan | [new] [Asterisk] Core/AstMM 0013858: [patch] On memory allocation failure return NULL or we will crash. reported by eliel (Karma: +176.50) http://bugs.digium.com/view.php?id=13858 |
| 00:54.46 | putnopvut | sighs at 13858 |
| 00:54.55 | putnopvut | Yes, that is a definite bad thing. |
| 00:55.02 | putnopvut | I'll go ahead and fix it. |
| 00:55.49 | seanbright | M12866 |
| 00:55.51 | MuffinMan | [new] [Asterisk] PBX/pbx_spool 0012866: Bad quality audio when using Local channel with a call file reported by ZX81 (Karma: +11.25) http://bugs.digium.com/view.php?id=12866 |
| 00:56.00 | seanbright | could that have something to do with GCC optimizations + gsm? |
| 00:56.41 | putnopvut | It could. If that's the case, we probably could have closed that issue months ago. |
| 00:56.51 | putnopvut | Too bad we don't know what codecs are being used or anything like that. |
| 00:57.16 | putnopvut | I don't know why using a local channel would have any bearing on audio quality. |
| 00:57.50 | eliel | seanbright: maybe asking to avoid optimization when compiling asterisk is a way to test if gcc is the problem... |
| 00:57.59 | Corydon76-dig | putnopvut: does using a Local channel force slin? |
| 00:58.04 | file | n. |
| 00:58.05 | file | erm no. |
| 00:58.26 | putnopvut | file answered for me... |
| 00:58.29 | file | it's a simple frame exchange without transcoding inside of chan_local |
| 00:59.01 | file | so if it was going to Echo the contents of the frame would be the same as that which came from the channel driver |
| 00:59.03 | Corydon76-dig | putnopvut: start worrying when file answers your sentences |
| 00:59.15 | Corydon76-dig | err, completes your sentences |
| 00:59.22 | putnopvut | yes, that will be scary. |
| 01:01.43 | putnopvut | with regards to the issue that seanbright brought up, it may be worthwhile to see if the issue still persists considering it's been five months since the bug was reported and there has been zero activity on it. |
| 01:02.00 | seanbright | already asked the user if it happens with 1.4.22 |
| 01:02.10 | seanbright | should have asked about 1.4 svn |
| 01:02.15 | seanbright | but we'll get to that |
| 01:02.26 | seanbright | ZX81 floats around in here on occasion as well |
| 01:03.12 | putnopvut | That's right. |
| 01:22.42 | seanbright | heh... |
| 01:22.43 | seanbright | *CLI> quit |
| 01:22.43 | seanbright | No such command 'quit' (type 'core show help quit' for other possible commands) |
| 01:22.46 | seanbright | *CLI> core show help quit |
| 01:22.49 | seanbright | No such command 'quit'. |
| 01:22.58 | putnopvut | oh, isn't the cli fun. |
| 01:23.15 | seanbright | indeed |
| 01:23.43 | putnopvut | Time to go home! |
| 01:23.45 | putnopvut | WONK |
| 01:32.24 | *** join/#asterisk-dev anthm (n=anthm@freeswitch/developer/anthm) |
| 01:33.20 | *** part/#asterisk-dev anthm (n=anthm@freeswitch/developer/anthm) |
| 02:04.17 | *** join/#asterisk-dev Marquis42 (n=bfhbmw0@65-127-126-34.dia.static.qwest.net) |
| 03:57.52 | Damin | Anyone seen JerJer around lately? |
| 04:02.34 | *** join/#asterisk-dev ta^3 (n=tacvbo@190.154.36.86) |
| 04:17.17 | tzanger | ~seen jerjer |
| 04:17.19 | jbot | jerjer <n=PhatJ@pdpc/supporter/bronze/jerjer> was last seen on IRC in channel #asterisk-dev, 18d 5h 35m 32s ago, saying: 'been tweaking on it all damn day'. |
| 04:23.34 | *** join/#asterisk-dev ta^3 (n=tacvbo@190.154.36.86) |
| 04:54.15 | *** join/#asterisk-dev mosty (n=mosty@ppp191-34.static.internode.on.net) |
| 05:06.06 | *** join/#asterisk-dev CunningPike (n=arodgers@S010600095b33697f.vc.shawcable.net) |
| 07:11.12 | *** join/#asterisk-dev oej (n=olle@ns.webway.se) |
| 07:11.12 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 07:38.14 | *** join/#asterisk-dev tzafrir_laptop (n=tzafrir@local.xorcom.com) |
| 07:38.14 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 08:06.58 | *** join/#asterisk-dev bartpbx (n=bartpbx@217.24.210.202) |
| 08:07.07 | bartpbx | hello |
| 08:09.48 | tzafrir_laptop | hi |
| 08:12.07 | bartpbx | today i discovered a interessting issue in 1.4.22 |
| 08:12.29 | bartpbx | i'm unsure if i understand issue 13383 correctly |
| 08:13.30 | bartpbx | i have the issue that i see is duzend of "peer is now unreacable.." messages and chan_sip is no longer responding |
| 08:13.45 | bartpbx | but the peers are cached |
| 08:18.23 | oej | M13883 |
| 08:18.25 | MuffinMan | [new] [Asterisk] Applications/app_queue 0013883: Join event uses CallerID header for caller ID number, when other events now use CallerIDNum reported by davidw (Karma: +5.75) http://bugs.digium.com/view.php?id=13883 |
| 08:18.39 | oej | M13383 |
| 08:18.40 | MuffinMan | [closed] [Asterisk] Channels/chan_sip/General 0013383: [patch] Turn off qualify on uncached realtime peers reported by Corydon76 (Karma: +444.00) http://bugs.digium.com/view.php?id=13383 |
| 08:29.09 | *** join/#asterisk-dev sergee (n=serg@voip1.west-call.com) |
| 09:22.03 | *** join/#asterisk-dev kamanashisroy (n=kamanash@119.30.34.3) |
| 10:04.16 | *** join/#asterisk-dev mvanbaak (n=michiel@asterisk/contributor-and-bug-marshal/mvanbaak) |
| 10:04.17 | *** mode/#asterisk-dev [+o mvanbaak] by ChanServ |
| 10:12.57 | *** join/#asterisk-dev ccesario (n=ccesario@189-19-9-100.dsl.telesp.net.br) |
| 10:55.31 | *** join/#asterisk-dev shazaum (n=shazaum@unaffiliated/shazaum) |
| 11:19.52 | *** join/#asterisk-dev caio1982 (i=caio1982@CAcert-br/caio1982) |
| 11:24.05 | *** join/#asterisk-dev eliel (n=eliel@200.61.172.61) |
| 11:24.05 | *** mode/#asterisk-dev [+o eliel] by ChanServ |
| 12:16.23 | *** join/#asterisk-dev DarkRift (n=dark@65.92.170.221) |
| 13:23.22 | *** join/#asterisk-dev lmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 13:23.22 | *** mode/#asterisk-dev [+o lmadsen] by ChanServ |
| 13:30.41 | *** join/#asterisk-dev lmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 13:30.41 | *** mode/#asterisk-dev [+o lmadsen] by ChanServ |
| 13:31.12 | lmadsen | howdy doody! |
| 13:31.57 | *** join/#asterisk-dev anonymouz666 (n=anonymou@201.19.199.65) |
| 13:32.17 | tzafrir_laptop | wonders if iy would be a good idea to open a bug report: "dahdi_dummy does not work with soem boards / kernels" |
| 13:32.52 | lmadsen | o.O |
| 13:33.20 | tzafrir_laptop | s/soem/some/ |
| 13:41.12 | *** join/#asterisk-dev Victor_Yure (n=victor@unaffiliated/victoryure/x-837844) |
| 14:10.07 | jsmith | tzafrir_laptop: Sure... I have one it's not working (correctly) for. |
| 14:32.57 | *** join/#asterisk-dev magumbade (n=magumbad@p5497FD1B.dip.t-dialin.net) |
| 14:33.21 | *** join/#asterisk-dev magumbade (n=magumbad@p5497FD1B.dip.t-dialin.net) |
| 14:34.59 | tzafrir_laptop | M13930 |
| 14:35.01 | MuffinMan | [new] [DAHDI-linux] dahdi_dummy 0013930: dahdi_dummy does not tick on some systems reported by tzafrir (Karma: +112.25) http://bugs.digium.com/view.php?id=13930 |
| 14:35.22 | tzafrir_laptop | Before just asking for data, any idea what to ask? |
| 14:35.55 | tzafrir_laptop | Is it just a problem of RTC? Also a problem with newer clocking (>= 2.6.22)? |
| 15:07.26 | *** join/#asterisk-dev Juggie (n=Juggie@CPE001601df17fb-CM001ceac25ada.cpe.net.cable.rogers.com) |
| 15:12.37 | *** join/#asterisk-dev mog (n=mog@nat/digium/x-8c04ba92f360eaf0) |
| 15:12.37 | *** mode/#asterisk-dev [+o mog] by ChanServ |
| 15:15.55 | *** join/#asterisk-dev putnopvut (n=putnopvu@nat/digium/x-f619f6f7b37feb65) |
| 15:15.55 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 15:28.15 | *** part/#asterisk-dev am88b (i=siim@uba.linux.ee) |
| 15:40.53 | *** join/#asterisk-dev Deeewayne (n=Deeewayn@nat/digium/x-ed9cab03995b843d) |
| 15:40.53 | *** mode/#asterisk-dev [+o Deeewayne] by ChanServ |
| 15:41.20 | *** join/#asterisk-dev Juggie (n=Juggie@CPE001601df17fb-CM001ceac25ada.cpe.net.cable.rogers.com) |
| 16:00.25 | *** join/#asterisk-dev shazaum (n=shazaum@unaffiliated/shazaum) |
| 16:15.57 | *** join/#asterisk-dev CunningPike (n=arodgers@204.239.8.157) |
| 16:16.34 | *** join/#asterisk-dev ctooley (n=ctooley@doc-24-32-196-69.concordia.ks.cebridge.net) |
| 16:16.34 | *** mode/#asterisk-dev [+o ctooley] by ChanServ |
| 16:18.14 | *** mode/#asterisk-dev [+o awk_r] by bearded_blitz |
| 16:22.13 | *** join/#asterisk-dev ccesario (n=ccesario@linux.unialco.com.br) |
| 16:31.55 | *** join/#asterisk-dev eliel (n=eliel@200.61.172.61) |
| 16:31.55 | *** mode/#asterisk-dev [+o eliel] by ChanServ |
| 17:06.22 | *** mode/#asterisk-dev [+o mnicholson] by Qwell |
| 17:33.53 | *** join/#asterisk-dev ccesario (n=ccesario@linux.unialco.com.br) |
| 18:07.50 | *** join/#asterisk-dev ccesario_ (n=ccesario@linux.unialco.com.br) |
| 18:16.42 | putnopvut | Okay, I'm stuck. I wanted to commit the res_timing_timerfd work (should take about 5 minutes), but the svn merge --ignore-ancestry command used to merge changes from my branch back into trunk always skips the actual res/res_timing_timerfd.c file. If I copy it into trunk and then svn add it, then the diff will duplicate the entire contents of the file for some reason (you can see this phenomenon on reviewboard for the diff I uploa |
| 18:16.42 | putnopvut | ded there). |
| 18:17.30 | putnopvut | s/copy it into trunk/copy it into my working directory of trunk/ |
| 18:17.56 | tzafrir_laptop | putnopvut, why --ignore-anscestry ? |
| 18:18.14 | putnopvut | because that's what the instructions say to do at http://www.asterisk.org/developers/svn-branching-merging |
| 18:20.49 | putnopvut | Just as a test, I tried without --ignore-ancestry, and a lot more files got updated, but still res/res_timing_timerfd.c was skipped. |
| 18:33.44 | *** join/#asterisk-dev ccesario (n=ccesario@linux.unialco.com.br) |
| 19:07.31 | putnopvut | I believe I have figured my problem out. |
| 19:09.49 | jsmith | putnopvut: All of them? Or just the svn merge ones? |
| 19:09.53 | jsmith | ducks and hides |
| 19:12.00 | putnopvut | Actually, I may not have fixed my problem. |
| 19:12.02 | putnopvut | grumbles |
| 19:12.07 | Corydon76-dig | jsmith: He just said he figured the problem out, not that he has a fix for it. So he's still as crazy as ever. |
| 19:12.23 | jsmith | Corydon76-dig: Touche' |
| 19:12.34 | putnopvut | I at least realized why the svn merge command was skipping res/res_timing_timerfd.c |
| 19:12.39 | kpfleming | orly? |
| 19:12.40 | seanbright | whyzat? |
| 19:12.59 | putnopvut | because I had that file by that name in my working copy of trunk. |
| 19:13.18 | seanbright | aha |
| 19:13.27 | putnopvut | When I removed that file and reran the svn merge command, I properly saw the 'A' next to res/res_timing_timerfd.c |
| 19:13.39 | seanbright | is there a "but" in there somewhere? |
| 19:13.55 | putnopvut | Actually, there appears not to be. |
| 19:14.14 | seanbright | super |
| 19:14.17 | putnopvut | And I have figured out why my original diff to reviewboard did not include the res/res_timing_timerfd.c file |
| 19:14.28 | tzafrir_laptop | BTW: spandsp 0.0.6.pre2 created includes/private/ |
| 19:14.33 | putnopvut | svn diff does not include svn added files, apparently. |
| 19:14.45 | kpfleming | sure it does |
| 19:14.51 | kpfleming | if you've done 'svn add' already on them |
| 19:15.07 | putnopvut | I did svn add it in my development branch. |
| 19:15.13 | tzafrir_laptop | and then callweaver's SVN version went along and included files from <spandsp/private/> |
| 19:15.29 | kpfleming | putnopvut: so how did you generate the diff for reviewboard upload from that branch? |
| 19:16.05 | putnopvut | what I ended up doing was doing an explicit svn add in my working copy of trunk. |
| 19:16.23 | putnopvut | But, because the file had already been added, apparently, the content of the file was duplicated in the diff I uploaded to reviewboard. |
| 19:16.40 | putnopvut | This is all very tricky to explain since I'm not sure that I'm using the correct terminology at all times. |
| 19:18.15 | seanbright | i understood the "because" "content" and "was" portions |
| 19:20.01 | Qwell | putnopvut: what was the command you ran? |
| 19:20.32 | Qwell | also, wow.. svn merge --accept |
| 19:20.52 | Qwell | edit seems nifty |
| 19:20.58 | putnopvut | Qwell: I ran several, let's see if I can summarize it all. |
| 19:21.28 | putnopvut | So, let's start from my working copy of the res_timing_timerfd branch. |
| 19:21.38 | putnopvut | I used svn add to add the res/res_timing_timerfd.c file |
| 19:22.02 | putnopvut | Then, from my working copy of trunk, I used the svn merge --ignore-ancestry command to merge the changes from the res_timing_timerfd branch to trunk. |
| 19:22.24 | putnopvut | When I do that, I can see the 'A' next to the res/res_timing_timerfc.c file. |
| 19:22.40 | putnopvut | Then an svn diff does *not* contain the contents of the res/res_timing_timerfd.c file. |
| 19:23.04 | kpfleming | that's odd |
| 19:23.04 | putnopvut | So, to get my change up to reviewboard, I used svn add from my working copy of trunk to re-add res/res_timing_timerfd.c |
| 19:23.07 | *** join/#asterisk-dev ccesario (n=ccesario@linux.unialco.com.br) |
| 19:23.21 | putnopvut | Then an svn diff contained the contents of res/res_timing_timerfd.c ... twice. |
| 19:23.29 | putnopvut | You can see this on reviewboard. |
| 19:24.03 | putnopvut | Furthermore, I've found that if I continually svn add a file, then a diff will continue appending copies of the content to the end of the file in the repo. |
| 19:24.27 | putnopvut | But I think I have things under control now and everything seems to be ready for committing. |
| 19:24.46 | putnopvut | But I still find it weird that an svn diff after an svn merge did not include the added res/res_timing_timerfd.c file. |
| 19:26.11 | seanbright | i just added a b.s. file to a wc |
| 19:26.14 | seanbright | did an 'svn diff' |
| 19:26.18 | seanbright | and saw the newly added file |
| 19:27.18 | seanbright | ofcourse i then deleted that file by accident... :-/ |
| 19:27.39 | seanbright | what is the reverse operation of 'svn add' before a checkin? |
| 19:27.45 | seanbright | svn revert? |
| 19:28.14 | kpfleming | yep |
| 19:29.07 | seanbright | that makes sense. |
| 19:31.17 | Qwell | putnopvut: svn merge --ignore-ancestry https://origsvn.digium.com/svn/asterisk/trunk/ https://origsvn.digium.com/svn/asterisk/team/mmichelson/res_timing_timerfd/ . |
| 19:31.26 | Qwell | putnopvut: that put an A for the res_timing_timerfd.c for me |
| 19:31.51 | seanbright | putnopvut: you running svn 1.5 yet? |
| 19:32.16 | putnopvut | Qwell: correct, now do an svn diff and see if you see the contents of res_timing_timerfd.c |
| 19:32.20 | Qwell | though it isn't in the diff...hmm |
| 19:32.32 | putnopvut | seanbright: on my laptop I am, and that's where I did the bulk of my work. |
| 19:32.45 | putnopvut | But on my work machine, I'm not running 1.5 |
| 19:32.58 | putnopvut | I tried the same operation on my laptop and had the same results, though. |
| 19:33.01 | seanbright | ah |
| 19:33.31 | Qwell | putnopvut: it shows up if you diff between the branches |
| 19:33.38 | Qwell | svn diff https://origsvn.digium.com/svn/asterisk/trunk/ https://origsvn.digium.com/svn/asterisk/team/mmichelson/res_timing_timerfd/ |
| 19:33.53 | putnopvut | Qwell: ah, okay. I'll keep that in mind if something like this happens again. |
| 19:33.57 | Qwell | the merge does a direct copy, so it sort of makes sense that it doesn't show up |
| 19:34.16 | putnopvut | sort of but not really. |
| 19:35.30 | seanbright | kpfleming: btw, good tip re: svnmerge + interactive-conflicts |
| 19:35.49 | *** join/#asterisk-dev ccesario_ (n=ccesario@189.20.219.10) |
| 19:36.18 | kpfleming | thanks |
| 19:36.27 | kpfleming | was biting me on the posterior until i figured that out |
| 19:36.29 | seanbright | saved me some hair-pulling |
| 19:42.48 | seanbright | ohhh... [auto-props] = hawt |
| 19:42.48 | *** join/#asterisk-dev outtolunc (n=me@adsl-66-218-53-172.dslextreme.com) |
| 19:42.59 | seanbright | i'm sure that's been there forever. just noticing it now. |
| 19:46.29 | seanbright | ok, i know we've moved on from this, but i just did this |
| 19:46.38 | seanbright | svn diff -rHEAD res/res_timing_timerfd.c |
| 19:46.47 | seanbright | svn: File not found: revision 157821, path '/team/mmichelson/res_timing_timerfd/res/res_timing_timerfd.c' |
| 19:47.02 | seanbright | (i did this in a trunk wc with putnopvut's branch merged in via svn merge) |
| 19:47.34 | putnopvut | seanbright: well, I did just svn rm the res_timing_timerfd branch. |
| 19:47.51 | seanbright | right, but why would it know about that branch anymore? |
| 19:48.00 | Qwell | you're specifying HEAD |
| 19:48.13 | Qwell | to the previous rev |
| 19:48.41 | seanbright | so it knows where the file came from? |
| 19:48.54 | *** part/#asterisk-dev Rem| (n=remi@bg-fw2out.monmouth.com) |
| 19:49.58 | seanbright | hrm. ok whatever. |
| 19:50.55 | kpfleming | yeah, that is odd that it looked there for the file |
| 19:51.28 | Qwell | seanbright: you're running that from trunk? |
| 19:51.32 | seanbright | yes |
| 19:51.45 | seanbright | 14:47 <@seanbright> (i did this in a trunk wc with putnopvut's branch merged in via svn merge) |
| 19:52.21 | Qwell | that's with the branch merged. it knows the file was copied |
| 19:52.46 | seanbright | gotcha |
| 19:59.01 | kpfleming | svn is smrt |
| 19:59.21 | seanbright | for realz |
| 20:08.02 | tzafrir_laptop | M13786 |
| 20:08.04 | MuffinMan | [new] [Asterisk] Channels/chan_dahdi 0013786: [patch] DAHDI_CHECK_HOOKSTATE automatically defined when chan_dahdi is built with zaptel support reported by tzafrir (Karma: +112.25) http://bugs.digium.com/view.php?id=13786 |
| 20:09.48 | tzafrir_laptop | Could anybody please look at there? I's something I now need to fix in every binary distribution of Asterisk |
| 20:12.56 | bearded_blitz | jpeeler: ping? ^^ |
| 20:18.52 | jpeeler | i don't know if i'm the best person to handle it, but i guess i can if nobody else is going to |
| 20:26.12 | tzafrir_laptop | well, take a look at what actually changes |
| 20:26.24 | jpeeler | i did, it looks reasonable |
| 20:27.10 | tzafrir_laptop | In 1.4.21 that code was conditioned on ZT_CHECK_HOOKSTATE, which was only set manually |
| 20:27.41 | tzafrir_laptop | in 1.4.22 the code is conditioned on DAHDI_CHECK_HOOKSTATE which is only set manually, |
| 20:27.56 | tzafrir_laptop | or if you build chan_dahdi with zaptel |
| 20:28.04 | tzafrir_laptop | in 1.6 that code is always used |
| 20:30.43 | tzafrir_laptop | There are two separate issues here: (1) why this code fails in some cases and (2) should this code be used |
| 20:31.17 | tzafrir_laptop | As for (1), so far it seems that all the reports of problems are regarding TDM400P cards and Astribanks |
| 20:32.14 | tzafrir_laptop | I looked at those bits in Zaptel/DAHDI and I'm not completely sure how they are supposed to get properly initialized |
| 21:16.57 | tzafrir_laptop | commit dahdi 5334 |
| 21:17.01 | MuffinMan | [5334] Committed by tzafrir on 2008-11-19T21:16:35.002757Z: LSB init script comments. |
| 21:17.01 | MuffinMan | .. |
| 21:17.01 | MuffinMan | .. http://svn.digium.com/view/dahdi?view=rev&revision=5334 |
| 21:17.14 | tzafrir_laptop | any comments on that one? |
| 21:32.56 | kpfleming | about to commit some goodness to the asterisk 1.4 branch |
| 21:33.27 | kpfleming | tzafrir_laptop: that commit looks ok to me |
| 21:34.00 | putnopvut | awaits the goodness. |
| 21:34.50 | kpfleming | committed |
| 21:35.14 | kpfleming | prompted by the changes you made to chan_sip yesterday, in fact, which i had to make a very small change to this morning (accidentially included in another commit) |
| 21:35.56 | putnopvut | Oh really? What change was that? |
| 21:36.25 | kpfleming | that pu_lock variable was reported by the compiler to be used without initialization |
| 21:36.36 | kpfleming | that wasn't really true, it just can't follow the code path well enough to know for sure |
| 21:36.50 | putnopvut | right, I was going to say that it's not actually possible for it to be used without being initialized. |
| 21:37.03 | putnopvut | But yeah, it doesn't hurt to NULL it out at the beginning anyway. |
| 21:37.09 | putnopvut | Thnaks for the correction. |
| 21:37.10 | kpfleming | yeah. but without compiler optimization turned on, you never even saw the warning |
| 21:37.19 | kpfleming | now you will! |
| 21:37.50 | putnopvut | cool |
| 21:38.23 | putnopvut | And actually, to be more consistent, I suppose that in 1.6.0, I shouldn't directly call ast_mutex_lock on the astobj1-provided lock, but should actually use ASTOBJ_WRLOCK instead. |
| 21:38.38 | putnopvut | even though that's actually the same thing. |
| 21:39.13 | putnopvut | eh, it doesn't matter. |
| 21:42.14 | kpfleming | i am getting a compile failure in res_timing_timerfd |
| 21:42.23 | kpfleming | i wasn't aware that my system could even support it :-) |
| 21:42.41 | kpfleming | res_timing_timerfd.c: In function âtimerfd_timer_ackâ: |
| 21:42.41 | kpfleming | res_timing_timerfd.c:161: error: format â%lluâ expects type âlong long unsigned intâ, but argument 7 has type âuint64_tâ |
| 21:44.03 | kpfleming | and menuselect does not appear to be handling the conflicts between the modules properly |
| 21:44.20 | kpfleming | this will require some work, as my system went from building res_timing_dahdi by default to only building the timerfd flavor |
| 21:48.17 | putnopvut | okay, I made some notes in my commit of the res_timing_timerfd stuff that the timing system could use some work regarding the selection of timers, but that it wasn't really within the scope of the work done for timerfd. |
| 21:48.24 | kpfleming | right |
| 21:48.40 | putnopvut | The %llu thing, though...what is the proper specifier for a uint64_t? |
| 21:48.44 | kpfleming | but changing the default away from building res_timing_dahdi will have to be fixed before we branch off 1.6.2 |
| 21:48.47 | putnopvut | %llu is what worked for me. |
| 21:48.59 | kpfleming | are you on 32-bit or 64-bit? |
| 21:49.10 | putnopvut | I built it on both system types. |
| 21:49.13 | kpfleming | huh |
| 21:49.15 | putnopvut | oh wait. |
| 21:49.18 | putnopvut | That's not true. |
| 21:49.19 | putnopvut | Just 32. |
| 21:49.23 | putnopvut | my mistake. |
| 21:49.24 | kpfleming | so |
| 21:49.38 | kpfleming | on 32-bit long long is probably 64-bit, but on 64-bit it's 128-bit |
| 21:49.52 | putnopvut | Yes, that would make sense. |
| 21:49.54 | kpfleming | let me try to find the correct format specifier |
| 21:50.04 | putnopvut | thanks. |
| 21:51.03 | kpfleming | it does not appear that there is a format specifier that would always be 64 bit integer |
| 21:51.08 | putnopvut | it would be cool if there were a way to explicitly specify the number of bits. |
| 21:51.13 | kpfleming | so you will have to cast |
| 21:51.45 | putnopvut | Yeah, I'll just cast to unsigned long and use %lu. |
| 21:51.49 | kpfleming | cast up to unsigned long long int and it should be fine |
| 21:51.58 | kpfleming | will that be big enough for the values it will hold? |
| 21:52.13 | putnopvut | It is a uint64_t, so the most it will need is 64-bits. |
| 21:52.22 | kpfleming | unsigned long is 32 |
| 21:52.28 | kpfleming | wait... it's 64 |
| 21:52.30 | kpfleming | never mind |
| 21:52.45 | putnopvut | well, on 32-bit platforms, it would be 32-bit actually. |
| 21:52.54 | putnopvut | since a long is the same size as a pointer. |
| 21:52.55 | kpfleming | yeah |
| 21:53.01 | putnopvut | but |
| 21:53.06 | kpfleming | so explicitly casting to long long should be fine |
| 21:53.13 | putnopvut | Yeah, I guess I'll just do that. |
| 21:53.43 | putnopvut | Although I find it highly unlikely that we would need to acknowledge more than 400 quadrillion timer expirations or whatever it is that the max 64-bit unsigned int is. |
| 21:54.08 | kpfleming | true enough |
| 21:55.23 | putnopvut | fixed |
| 21:55.39 | putnopvut | kpfleming: are you running intrepid? |
| 21:57.13 | kpfleming | yes |
| 21:58.02 | putnopvut | Ah, yes, Intrepid uses a 2.6.27 kernel and glibc 2.8, so you are perfectly capable of using res_timing_timerfd. |
| 21:58.13 | kpfleming | ok, makes sense |
| 21:58.46 | *** join/#asterisk-dev codefreeze-lap (n=murf@72.21.67.40) |
| 21:58.46 | *** mode/#asterisk-dev [+o codefreeze-lap] by ChanServ |
| 22:00.17 | bearded_blitz | mnicholson: ping? |
| 22:00.47 | bearded_blitz | mnicholson: do you have an account on the bug tracker? |
| 22:01.30 | bearded_blitz | aha... funny enough... mnicholson exists :) |
| 22:04.32 | *** join/#asterisk-dev mm_202 (n=mm_202@unaffiliated/mm-202) |
| 22:04.55 | mnicholson | bearded_blitz, yup |
| 22:05.04 | mnicholson | bearded_blitz, what's shakin? |
| 22:05.10 | bearded_blitz | I just upgraded you to 'developer' so I could assign issues to you :) |
| 22:05.14 | mnicholson | ok |
| 22:05.18 | bearded_blitz | just assigned the first of hopefully many issues to you |
| 22:05.19 | mm_202 | Hey guys, quick question: Why does Asterisk not support SMP? |
| 22:05.33 | *** join/#asterisk-dev snuff-work (n=jsewell@203.176.96.250) |
| 22:05.34 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 22:05.34 | Qwell | mm_202: Who says it doesn't? |
| 22:05.47 | bearded_blitz | I was just thinking the same thing... |
| 22:05.50 | Qwell | mm_202: They are both wrong, and do not understand what it means to "support SMP". |
| 22:05.50 | mm_202 | Qwell: top and my CPU load.. |
| 22:06.06 | mnicholson | bearded_blitz, oh yay |
| 22:06.17 | bearded_blitz | mnicholson: glad you're excited! :) |
| 22:06.28 | Qwell | mm_202: It is very heavily multi-threaded. If you're running an SMP kernel, the kernel will spread the load |
| 22:07.01 | mm_202 | hmm, then it could be CentOS... ... let me look into that. |
| 22:07.20 | bearded_blitz | I run asterisk on CentOS for a few clients, and it always uses all the CPUs at a high enough load |
| 22:08.15 | mm_202 | bearded_blitz: what is a 'high enough load'? At around 350+ channels, it'll start to run into locks and the load will jump to 10+ (and this is just a Dual Xeon box..) |
| 22:08.39 | mnicholson | where can I find instructions on fixing bugs and merging changes to branches and trunk and what not |
| 22:08.40 | snuff-work | mm.. putnopvut when i try to compile / bison/flex ast_expr2.c it comes up with NONE:0: ERROR: EOF in string.. (granted its oold bison like 1.875 but i'm pretty sure it used to work |
| 22:08.42 | bearded_blitz | mm_202: anything beyond insignificant.... |
| 22:08.52 | bearded_blitz | mnicholson: www.asterisk.org/developers I think |
| 22:09.27 | bearded_blitz | (at least the developers link at the top on asterisk.org) |
| 22:09.48 | putnopvut | mnicholson: also feel free to come and ask anyone around the office for help, too. |
| 22:09.56 | mnicholson | ok |
| 22:10.05 | bearded_blitz | errrr.... I can't seem to get to it from here for some reason |
| 22:10.09 | bearded_blitz | anyone else having that issue? |
| 22:10.49 | mnicholson | bearded_blitz, nope works for me |
| 22:10.56 | bearded_blitz | hrmmm odd |
| 22:10.59 | bearded_blitz | kicks rogers |
| 22:11.17 | bearded_blitz | should 216.207.245.13 respond to ICMP? |
| 22:11.58 | Juggie | works for me bearded_blitz |
| 22:12.06 | bearded_blitz | ugh... annoying |
| 22:12.09 | Juggie | grr, the stupid gas people are such a pain |
| 22:12.10 | bearded_blitz | thanks though, must be local |
| 22:12.14 | Juggie | they come to the door and i tell him to pack off |
| 22:12.20 | Juggie | as he's trying to sign me up to a distributor |
| 22:12.29 | Juggie | and he keeps going on and on asking if he can see my bill |
| 22:12.38 | Juggie | and i'm like dude, i get electronic bills, i dont even have one to show you |
| 22:13.02 | Juggie | i shoulda told him i'd be right back with a bill |
| 22:13.06 | Juggie | and just never came back |
| 22:13.10 | bearded_blitz | sweet |
| 22:13.20 | snuff-work | mm.. who was asking the other day were juggie disappeared to.. 18days without u is long time ;) |
| 22:13.33 | Juggie | i was not on irc for 18days? |
| 22:13.42 | putnopvut | snuff-work: um, no idea why you'd be getting that error in ast_expr2.c |
| 22:13.45 | Juggie | i highly doubt that |
| 22:13.55 | bearded_blitz | snuff-work: or do you mean junky? |
| 22:13.57 | putnopvut | I haven't touched that stuff...ever. |
| 22:14.12 | Juggie | i might not talk for weeks at a time but i am usually online. |
| 22:14.14 | snuff-work | oh my bad.. that was jerjer |
| 22:14.17 | bearded_blitz | ah |
| 22:14.30 | snuff-work | both begin with a j.. is my excuse |
| 22:14.31 | Juggie | unless i reboot and forget to start up my client. |
| 22:14.46 | Juggie | ya, try finding juggie on the bug tracker when you want to search on a bug you reported |
| 22:14.54 | Juggie | theres like 500 names that start w/ j. |
| 22:15.16 | snuff-work | almost wish it didn't load ALL the names when asking someone to respond.. |
| 22:15.24 | Juggie | they really need to do a dynamic list in JS for that or something, so you pick the first letter and it gives you a short list of names starting w/ that letter |
| 22:15.31 | Juggie | or you can start typing it and it gives you a list of matches |
| 22:15.53 | Juggie | because if you do an advanced search it takes friggen forver to load that control |
| 22:15.54 | snuff-work | i was even thinking based on activity.. some are long dead users.. |
| 22:16.33 | Juggie | OR |
| 22:16.37 | Juggie | ah this could work |
| 22:16.41 | Juggie | in the reporter list |
| 22:16.49 | Juggie | actually only include people who have reported bugs |
| 22:16.57 | Juggie | that would shorten it a ton |
| 22:17.08 | Juggie | because right now its just everyone in the system |
| 22:17.14 | Juggie | that would probally work |
| 22:17.25 | Juggie | yells at the mantis maintainer |
| 22:17.44 | Juggie | should be a reasonabally fast query, select distinct blah blah |
| 22:17.49 | Corydon76-dig | I saw 'long dead users' and immediately thought 'Tron' |
| 22:18.30 | Juggie | ah, who works on the mantis code these days |
| 22:18.47 | bearded_blitz | interesting... there are some spot lights lighting up the sky outside my window |
| 22:19.15 | Corydon76-dig | Juggie: jpeeler |
| 22:19.27 | Juggie | k, i'll suggest it to him, that would be a worthy fix. |
| 22:19.36 | Juggie | no reason to list every user in that control if they have not actually reported anything |
| 22:19.42 | Juggie | the search would turn up empty anyway |
| 22:33.13 | *** join/#asterisk-dev telecos (n=sergio@84.166.219.87.dynamic.jazztel.es) |
| 23:00.49 | *** join/#asterisk-dev sruffell (n=sruffell@nat/digium/x-4b38ffa8e2606bd8) |
| 23:00.49 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 23:05.33 | snuff-work | putnopvut: out of interest.. i tried 1.4 svn and it got past the bison/flex thing.. |
| 23:07.43 | putnopvut | hmmm, that's strange. |
| 23:08.14 | putnopvut | I'm trying a recompile of trunk right now...hold on a sec. |
| 23:08.30 | putnopvut | Just trying to see if any bison commands are even executed. |
| 23:09.11 | snuff-work | just remember.. i'm using 1.875 and its made with 2.3 ;) but 1.4's does work aka i can see that it regen'd the .c file |
| 23:10.08 | putnopvut | snuff-work: just out of curiosity, revert your trunk checkout to a revision prior to 157820, and see if they same error occurs. |
| 23:10.16 | snuff-work | k |
| 23:10.26 | putnopvut | I just want to make sure I didn't screw anything up with the timerfd commit. |
| 23:10.55 | snuff-work | mm.. when did u do that.. last 5 hrs right? |
| 23:11.35 | snuff-work | my checkout is still operating from 18hrs ago.. 157592 |
| 23:12.26 | putnopvut | snuff-work: yeah I committed that revision...a little under four hours ago. |
| 23:14.10 | snuff-work | k well my rev is 157592.. which is a from bout 24hr ago |
| 23:30.48 | otherwiseguy | tzafrir_laptop: do you have any idea why xrobau opened a new bug (13927) referencing your 13786? Can I just close the new one (since you marked it duplicate)? |
| 23:31.59 | tzafrir_laptop | otherwiseguy, can be closed, indeed |
| 23:32.38 | otherwiseguy | tzafrir_laptop: was weird, posting in your bug saying hey I created another bug that points to this one... |
| 23:47.05 | *** join/#asterisk-dev jtodd (n=jtodd@blob.fox-den.com) |