| 00:00.49 | Kobaz | gonna go clean up some reviewboards |
| 02:49.03 | *** join/#asterisk-dev tzafrir_laptop (~tzafrir@bzq-218-155-145.cablep.bezeqint.net) |
| 02:49.04 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 04:00.07 | *** join/#asterisk-dev sruffell (~Adium@asterisk/the-kernel-guy/sruffell) |
| 04:00.07 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 04:30.12 | *** join/#asterisk-dev wdoekes2 (~walter@wjd.osso.nl) |
| 05:24.41 | *** join/#asterisk-dev tzafrir_laptop (~tzafrir@212.179.75.202) |
| 05:24.41 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 05:30.47 | *** join/#asterisk-dev irroot (~irroot@pbx.distrotech.co.za) |
| 05:37.07 | *** join/#asterisk-dev Qwell (~north@pdpc/sponsor/digium/Qwell) |
| 05:37.07 | *** mode/#asterisk-dev [+o Qwell] by ChanServ |
| 06:40.36 | *** join/#asterisk-dev schmidts (~schmidts@Lo20-rt01.lm33.sil.at) |
| 06:40.37 | schmidts | good morning |
| 07:03.17 | *** join/#asterisk-dev irroot (~irroot@pbx.distrotech.co.za) |
| 07:05.34 | *** join/#asterisk-dev Aven (~user@95.52.229.140) |
| 07:11.57 | *** join/#asterisk-dev tamiel (~tamiel@213.30.183.226) |
| 07:34.49 | *** join/#asterisk-dev hehol (~hehol@2001:1438:1009:200:dbc:9866:66b3:b841) |
| 09:28.38 | irroot | looks like i broke svn sync again :) |
| 09:34.42 | schmidts | bad boy! |
| 09:36.04 | irroot | well the rule is the first person to notice it gets blamed |
| 09:36.09 | irroot | eliminating a step |
| 09:36.27 | schmidts | :D |
| 09:37.58 | tzafrir_laptop | Anybody able to build asterisk 1.4 with gcc 4.6? |
| 09:45.12 | irroot | sorry dont got 4.6 yet maybe ill start building that :P |
| 10:19.34 | irroot | cancel issue with svn was link failure ... |
| 11:24.18 | *** join/#asterisk-dev jsmith (~jsmith@fedora/jsmith) |
| 11:24.18 | *** mode/#asterisk-dev [+o jsmith] by ChanServ |
| 11:38.14 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 11:38.14 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 12:28.32 | *** join/#asterisk-dev t_dot_zilla (~chatzilla@firewall-a.buf.ny.i-evolve.net) |
| 13:17.25 | *** join/#asterisk-dev t_dot_zilla (~chatzilla@firewall-a.buf.ny.i-evolve.net) |
| 13:34.46 | opticron | tzafrir_laptop, I've seen some issues with gcc-4.6 generating code with illegal instructions on 64bit machines with the build optimized |
| 13:35.08 | opticron | but I only see it intermittently |
| 13:35.34 | opticron | right now, I'm unable to reproduce it |
| 13:35.47 | kpfleming | what is 'the build' in this context? |
| 13:36.07 | opticron | asterisk, without DONT_OPTIMIZE set |
| 13:36.18 | opticron | so the default asterisk optimization setting |
| 13:36.45 | kpfleming | well... then gcc 4.6 would appear to have a bug or two :-) |
| 13:36.54 | opticron | yep |
| 13:42.58 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 13:42.58 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 14:21.38 | tzafrir_laptop | ASTERISK-18065 |
| 14:21.39 | CaptainPants | [ASTERISK-18065] [Status: Triage] 1.4 fails to build with gcc 4.6 in dev-mode: chan_phone.c:307:9: error: the comparison will always evaluate as 'true' - https://issues.asterisk.org/jira/browse/ASTERISK-18065 |
| 14:22.26 | tzafrir_laptop | This is not a DONT_OPTIMIZE issue. This is gcc-4.6 refusing to build with an actual bug |
| 14:22.41 | tzafrir_laptop | (because in dev-mode warnings are made errors) |
| 14:23.32 | *** join/#asterisk-dev anonymouz666 (~anonymouz@187-28-37-118.poolip.RJO.embratel.net.br) |
| 14:23.47 | tzafrir_laptop | I really could not care less about that bug in chan_phone. But I want to still be able to build it |
| 14:29.08 | kpfleming | you want to be able to build an unsupported release of asterisk with a bleeding edge compiler |
| 14:29.25 | Corydon76-home | tzafrir_laptop: I think you're about a month too late on that one, with 1.4 at security-fix-only |
| 14:30.39 | tzafrir_laptop | gah. I reported the issue before the latest release was tagged |
| 14:30.57 | tzafrir_laptop | I do expect to be able to build it, yes |
| 14:30.59 | Corydon76-home | What about before the latest release candidate was tagged? |
| 14:31.41 | tzafrir_laptop | I posted it once I discovered it (sans a day or two of delay) |
| 14:32.04 | Corydon76-home | Future note: set the Target Release Version in the issue, so that it shows up on the list of blockers |
| 14:32.39 | kpfleming | why didn't you just fix it? |
| 14:33.09 | tzafrir_laptop | I asked on IRC |
| 14:33.24 | tzafrir_laptop | I don't want to commit to a version that is in deep freeze |
| 14:33.25 | kpfleming | asked who? |
| 14:33.58 | *** join/#asterisk-dev sruffell (~Adium@asterisk/the-kernel-guy/sruffell) |
| 14:33.58 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 14:34.28 | kpfleming | in any case, i find it extremely unlikely that the security-fix-only policy is going to be lifted for something that hardly anyone uses |
| 14:35.20 | kpfleming | so if you really must build packages of it using gcc 4.6, feel free to patch that code so that it will compile |
| 14:37.09 | tzafrir_laptop | I test-build on my laptop |
| 14:37.18 | tzafrir_laptop | and my laptop is 4.6 |
| 14:37.34 | kpfleming | now i'm really confused... if you are building packages, don't build in dev-mode. dev-mode is not for building packages, it's for development. |
| 14:38.41 | tzafrir_laptop | I needed to figure out what was the advisory of 1.4 about. |
| 14:39.08 | tzafrir_laptop | According to the text, a specific advisory did not apply to our package (branched off older 1.4) |
| 14:39.23 | tzafrir_laptop | So I wanted to look at current 1.4 |
| 14:39.46 | tzafrir_laptop | and compare it to 1.4.21.2 |
| 14:39.48 | Corydon76-home | tzafrir_laptop: why not download the associated patch from the security advisory? |
| 14:40.34 | Corydon76-home | Those patches were created explicitly with people not running the current release in mind |
| 14:40.36 | tzafrir_laptop | Corydon76-home, either way, I would need a build environent. I could start things in a chroot. But this is less comfortable |
| 14:40.49 | kpfleming | and why not do package test builds using the actual environment the packages would be built in? |
| 14:41.13 | kpfleming | this is like saying that you need to get it to build with clang, because that's what on your system, even though the real packages will be built with gcc |
| 14:41.13 | tzafrir_laptop | And anyway, that patch was created for someone running 1.4.40, not for someone running a heavily patched 1.4.21 |
| 14:41.22 | tzafrir_laptop | (not that I'm complaining) |
| 14:41.44 | tzafrir_laptop | I eventually do test-build packages in a chroot |
| 14:41.46 | Corydon76-home | tzafrir_laptop: correct, but the idea is to give people a leg up to fixing their own branches |
| 14:42.22 | tzafrir_laptop | But for simple things, and especially when I need to play with the code, it is often nicer to use a native environment |
| 14:43.20 | tzafrir_laptop | Anyway, newer gcc warns of a bug. This is a plain bug. |
| 14:43.48 | tzafrir_laptop | Previously the code of chan_phone did not properly check the return code of a function |
| 14:44.03 | kpfleming | yes, it is. it's a bug in a seldom-used module, and it missed the window for non security fixes. there are probably dozens of others in the same situation. |
| 14:44.27 | Corydon76-home | Just thought of a reason why somebody might use devmode... the better_backtraces flag. Should we move that to cflags.xml? (from cflags-devmode.xml)? |
| 14:45.45 | kpfleming | it's probably not good that MALLOC_DEBUG, DEBUG_THREADS and others are tied to --enable-dev-mode anyway. they serve different purposes. |
| 14:45.50 | tzafrir_laptop | kpfleming, again, none of those other bugs break building. |
| 14:46.14 | kpfleming | this doesn't break building, except with a buggy bleeding edge compiler and dev-mode enabled. regular users will not have an issue. |
| 14:46.27 | tzafrir_laptop | The compiler is not buggy |
| 14:46.35 | tzafrir_laptop | It has exposed a real bug |
| 14:46.47 | kpfleming | i was not stating that a compiler bug was the cause of this, but the compiler is buggy |
| 14:47.03 | kpfleming | we have a number of things that don't compile properly with gcc 4.6 where the code is not at fault |
| 14:47.06 | tzafrir_laptop | And eventually is will be used in standard distributions |
| 14:47.14 | kpfleming | like any major gcc release, it won't be ready for regular usage for a while |
| 14:47.32 | kpfleming | yes, it will be in standard distributions. and if people want to build asteisk 1.4, they can. just not in dev-mode. |
| 14:47.50 | kpfleming | or they can patch the code, or they can turn off chan_phone (which most of them will do, since nobody cares about it) |
| 14:48.22 | tzafrir_laptop | kpfleming, fine. please disable building chan_phone. That's another resolition to this bug |
| 14:48.42 | kpfleming | point that out in the issue, and russell/leif and the others can decide. |
| 14:49.13 | kpfleming | but i'm pretty sure that anyone doing development on asterisk 1.4 is capable of disabling chan_phone themselves. someone who is not doing development on it shouldn't be building in dev-mode. |
| 14:50.52 | tzafrir_laptop | BTW: target-release: is this something I (as reported) should set? Or is it whoever triaging the bugs should? |
| 14:51.16 | tzafrir_laptop | Or should I be triaging my own bugs? |
| 14:51.23 | kpfleming | that's for when the bug is triaged, yes |
| 14:51.37 | kpfleming | the reporter doesn't get to decide when the issue will be addressed :-) |
| 14:56.47 | *** join/#asterisk-dev The_Boy_Wonder (~vossel@asterisk/batman-developer/dvossel) |
| 14:56.47 | *** mode/#asterisk-dev [+o The_Boy_Wonder] by ChanServ |
| 15:01.31 | tzafrir_laptop | BTW: can anybody here with a non-Digium HFC-4S/8S (Junghanns, Bero, whatever) card and DAHDI drivers tried latest trunk? |
| 15:02.17 | tzafrir_laptop | I tried it with one card and I see that it does not use any EC (no hardware and no software) even though it is configured to use software |
| 15:02.30 | tzafrir_laptop | (latest trunk: of dahdi) |
| 15:02.46 | tzafrir_laptop | But sadly I had no time to examine this |
| 15:05.08 | opticron | sruffell, ^^ |
| 15:05.32 | sruffell | I don't have a non-Digium card. |
| 15:08.07 | sruffell | ahhâ¦tzafrir, I do think I see a problem though... |
| 15:08.16 | sruffell | one secâ¦I'll post a patch |
| 15:13.11 | sruffell | tzafrir_laptop: if https://github.com/sruffell/dahdi-linux/commit/6a6c009fb works for you feel free to just go ahead an commit it. |
| 15:38.08 | tzafrir_laptop | sruffell, yes, that's better |
| 15:38.40 | tzafrir_laptop | Could you please commit it? (Acked-By me) |
| 15:38.47 | tzafrir_laptop | I'm not with a proper tree there |
| 15:38.48 | sruffell | willd o |
| 15:38.49 | sruffell | will do |
| 15:39.55 | sruffell | what about https://github.com/sruffell/dahdi-linux/commit/2622a1a5ac? Just commit that too or do you want Oron's feedback? |
| 15:40.08 | sruffell | tzafrir_laptop^^? |
| 15:41.10 | tzafrir_laptop | The problem is: what happens when you compare those? |
| 15:41.32 | sruffell | that's just casting on assignmentâ¦.compares would be the same as they are now... |
| 15:41.38 | tzafrir_laptop | PTR_TYPE is actually 16bit in the kernel |
| 15:41.44 | sruffell | I'm just taking an implicit truncation and making it explicit there |
| 15:41.59 | tzafrir_laptop | So is there any case you compare a PTR_TYPE value to one that isn't? |
| 15:42.58 | sruffell | yesâ¦all those compares to invalidâ¦.but the compiler doesn't warn about those (because they are all unsignedâ¦as opposed to when I originally wanted to make the invalid a -1) |
| 15:43.18 | irroot | has a question regarding CDR's either i missing it or there is problem in app_queue |
| 15:44.19 | irroot | a CDR does not always match upto queue_log this can be a PITA |
| 15:44.38 | irroot | this happens when a call getes attn-xfer to a Queue |
| 15:45.13 | irroot | as Queue replaces dial in dealing with the calls it should as dial would add a CDR |
| 15:45.21 | tzafrir_laptop | sruffell, IIRC there was one specific case where there was such a comparison (to the 32bit value) |
| 15:46.37 | sruffell | that patch doesn't change any comparisonsâ¦.only assigment to initial values. So if there is a problemâ¦it's a problem in trunk currently. okâ¦I'll hold off on that one. I sent it to Oron and you in an email. I don't know what his plan was to eliminate the compiler warnings. |
| 15:51.07 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 15:51.07 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 15:52.50 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 16:20.53 | irroot | looks arround nervously wonder if anyone will notice i broke CHANGES file |
| 16:21.13 | kpfleming | it doesn't break the build :-) |
| 16:21.40 | irroot | causes user confusion that can be many times worse :P |
| 16:22.23 | irroot | there 2 other misplaced comments fall under 1.8 not 1.10 |
| 16:29.29 | irroot | ok confirmed r296249 r318141 misplace items in CHANGES |
| 16:29.59 | kpfleming | feel free to fix it |
| 16:30.08 | irroot | on it captain |
| 16:30.49 | kpfleming | and hey... seriously, thanks for all the effort you put into that t.38 gateway stuff. i personally started that project so long ago i can barely remember, and now it's real. great work. |
| 16:35.00 | irroot | its a pleasure its something that needed to be done and your notes were most useful think that the end result is what you penned way back when russellb also had some info on wiki |
| 16:35.08 | kpfleming | yep |
| 16:36.44 | irroot | ok CHANGES cleaned |
| 16:38.42 | irroot | its 18:30 way past beer 'o clock have a super weekend .... |
| 16:38.44 | irroot | in parting here is the 15h00 post on popular local blog |
| 16:38.46 | irroot | "its weekend lets dive [depart]" |
| 16:38.48 | irroot | http://www.watkykjy.co.za/2011/07/dis-naweek-kom-ons-fokken-duik-32/ |
| 16:44.11 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 16:44.11 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 16:51.22 | *** part/#asterisk-dev seraphie (~erin@207.98.195.107) |
| 17:06.12 | *** join/#asterisk-dev irroot (~irroot@41.54.188.233) |
| 17:23.55 | *** join/#asterisk-dev hehol (~hehol@2001:1438:1009:200:dbc:9866:66b3:b841) |
| 17:45.20 | *** part/#asterisk-dev t_dot_zilla (~chatzilla@firewall-a.buf.ny.i-evolve.net) |
| 17:45.32 | *** join/#asterisk-dev e_dot_zilla (~chatzilla@firewall-a.buf.ny.i-evolve.net) |
| 17:45.36 | e_dot_zilla | hi |
| 17:48.20 | *** join/#asterisk-dev irroot (~irroot@197.174.66.107) |
| 18:09.33 | e_dot_zilla | haters |
| 20:09.25 | *** join/#asterisk-dev tamiel (~tamiel@ip-196.net-81-220-93.rev.numericable.fr) |
| 21:17.08 | *** part/#asterisk-dev mjordan (~mjordan@nat/digium/x-madbricanpekhoge) |
| 21:50.40 | *** join/#asterisk-dev sruffell (~Adium@asterisk/the-kernel-guy/sruffell) |
| 21:50.40 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |