| 00:47.11 | *** join/#asterisk-dev itamarjp (n=itamar@189-015-164-078.xd-dynamic.ctbcnetsuper.com.br) |
| 01:49.05 | *** join/#asterisk-dev bbryant (n=brett@c-76-26-221-79.hsd1.sc.comcast.net) |
| 01:49.05 | *** mode/#asterisk-dev [+o bbryant] by ChanServ |
| 02:43.02 | *** join/#asterisk-dev moy (n=moy@173.33.253.89) |
| 02:57.38 | *** join/#asterisk-dev murdock_ut (n=chatzill@mail.kimballequipment.com) |
| 03:13.03 | *** join/#asterisk-dev fred-tmft (n=fred-tea@c-69-244-180-112.hsd1.mi.comcast.net) |
| 05:28.28 | *** join/#asterisk-dev fiddur (n=fiddur@192.121.104.122) |
| 05:37.26 | *** join/#asterisk-dev oej (n=olle@ns.webway.se) |
| 05:37.26 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 05:40.04 | *** join/#asterisk-dev obnauticus (n=rofl@about/windows/regular/obnauticus) |
| 05:58.39 | *** join/#asterisk-dev |Cybex| (n=John@212.178.82.26) |
| 06:32.54 | *** join/#asterisk-dev oej (n=olle@ns.webway.se) |
| 06:32.54 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 07:09.28 | *** join/#asterisk-dev tamiel (n=tamiel@213.30.183.226) |
| 07:44.31 | *** join/#asterisk-dev DarkRift (n=dark@65.92.251.221) |
| 08:00.28 | *** join/#asterisk-dev brookshi1e (i=mbrooks@hijacked.us) |
| 08:04.10 | *** part/#asterisk-dev korihor (n=korihor@190.205.251.61) |
| 10:22.29 | *** join/#asterisk-dev puzzled (n=foobar@puzzled.xs4all.nl) |
| 10:37.05 | *** join/#asterisk-dev mvanbaak (n=michiel@asterisk/contributor-and-bug-marshal/mvanbaak) |
| 10:37.06 | *** mode/#asterisk-dev [+o mvanbaak] by ChanServ |
| 10:42.08 | *** join/#asterisk-dev mvanbaak_ (n=michiel@asterisk/contributor-and-bug-marshal/mvanbaak) |
| 10:42.08 | *** mode/#asterisk-dev [+o mvanbaak_] by ChanServ |
| 11:22.03 | *** join/#asterisk-dev mattzerah (n=matt@121.50.217.178) |
| 11:36.22 | *** join/#asterisk-dev kpfleming (n=kpflemin@asterisk/digium-director-of-software-tech/kpfleming) |
| 11:36.22 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 11:38.25 | *** join/#asterisk-dev snuff-home (n=snuffy@203-219-29-182-bri-ts6-2600.tpgi.com.au) |
| 11:38.25 | *** mode/#asterisk-dev [+o snuff-home] by ChanServ |
| 11:41.28 | *** join/#asterisk-dev leifmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 11:41.28 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 11:58.17 | *** part/#asterisk-dev fred-tmft (n=fred-tea@c-69-244-180-112.hsd1.mi.comcast.net) |
| 12:19.31 | *** join/#asterisk-dev Iamnacho (i=Iamnacho@ip98-186-180-143.ks.ks.cox.net) |
| 12:20.42 | *** part/#asterisk-dev Iamnacho (i=Iamnacho@ip98-186-180-143.ks.ks.cox.net) |
| 12:27.04 | *** join/#asterisk-dev qdk (n=qdk@81.7.168.130) |
| 12:29.56 | *** join/#asterisk-dev eliel (n=eliels@200.61.172.61) |
| 12:29.56 | *** mode/#asterisk-dev [+o eliel] by ChanServ |
| 12:38.56 | *** join/#asterisk-dev Pazzo (n=ugelt@reserved-225136.rol.raiffeisen.net) |
| 13:31.38 | *** join/#asterisk-dev Victor_Yure (n=victor@unaffiliated/victoryure/x-837844) |
| 13:43.31 | *** join/#asterisk-dev Victor_Yure_ (n=victor@unaffiliated/victoryure/x-837844) |
| 13:44.31 | *** join/#asterisk-dev putnopvut (n=putnopvu@asterisk/master-of-queues/mmichelson) |
| 13:44.31 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 13:59.51 | *** join/#asterisk-dev oej (n=olle@ns.webway.se) |
| 13:59.51 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 14:06.49 | *** join/#asterisk-dev kpfleming (n=kpflemin@asterisk/digium-director-of-software-tech/kpfleming) |
| 14:06.49 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 14:09.22 | *** join/#asterisk-dev Laureano (n=Laureano@190.245.108.131) |
| 14:15.59 | *** join/#asterisk-dev Deeewayne (n=dwayne@75.76.254.162) |
| 14:15.59 | *** mode/#asterisk-dev [+o Deeewayne] by ChanServ |
| 14:18.36 | *** join/#asterisk-dev mvanbaak (n=michiel@asterisk/contributor-and-bug-marshal/mvanbaak) |
| 14:18.36 | *** mode/#asterisk-dev [+o mvanbaak] by ChanServ |
| 14:21.06 | *** part/#asterisk-dev |Cybex| (n=John@212.178.82.26) |
| 14:28.32 | leifmadsen | http://www.xkcd.com/619/ <-- nice |
| 14:46.52 | *** join/#asterisk-dev |Cybex| (n=John@80.100.126.176) |
| 14:55.20 | *** join/#asterisk-dev voipmonk (n=voipmonk@CPE000fb5620979-CM0014f859c1f2.cpe.net.cable.rogers.com) |
| 14:56.11 | *** part/#asterisk-dev voipmonk (n=voipmonk@CPE000fb5620979-CM0014f859c1f2.cpe.net.cable.rogers.com) |
| 15:01.55 | *** join/#asterisk-dev jpeeler (n=jpeeler@asterisk/digium-software-dev/jpeeler) |
| 15:01.55 | *** mode/#asterisk-dev [+o jpeeler] by ChanServ |
| 15:12.39 | *** join/#asterisk-dev anthm (n=anthm@freeswitch/developer/anthm) |
| 15:15.37 | *** join/#asterisk-dev seanbright (n=sean@asterisk/contributor-and-bug-marshal/seanbright) |
| 15:15.37 | *** mode/#asterisk-dev [+o seanbright] by ChanServ |
| 15:15.42 | *** join/#asterisk-dev Laureano (n=Laureano@190.245.108.131) |
| 15:16.28 | *** join/#asterisk-dev atis_work (n=atis_wor@193.238.212.171) |
| 15:26.27 | *** join/#asterisk-dev outtolunc (n=me@c-98-248-96-110.hsd1.ca.comcast.net) |
| 15:29.29 | *** join/#asterisk-dev Victor_Yure_ (n=victor@unaffiliated/victoryure/x-837844) |
| 15:32.41 | *** join/#asterisk-dev voipmonk (n=voipmonk@CPE000fb5620979-CM0014f859c1f2.cpe.net.cable.rogers.com) |
| 15:52.38 | *** join/#asterisk-dev CunningPike (n=CunningP@204.239.8.157) |
| 16:16.04 | *** join/#asterisk-dev oej (n=olle@ns.webway.se) |
| 16:16.04 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 16:16.24 | kaii | leifmadsen: so true .. |
| 16:18.08 | *** join/#asterisk-dev davevg-btwtech (n=davevg__@75.97.64.33) |
| 16:23.12 | *** join/#asterisk-dev qdk (n=qdk@0x573d8d8b.bynqu1.dynamic.dsl.tele.dk) |
| 16:33.21 | putnopvut | http://pastebin.ca/1545969 |
| 16:33.44 | putnopvut | Unfortunately, I'm heading out to lunch pretty soon, so if you have any insight into what's wrong there, just leave a comment here and I'll see it when I get back. |
| 16:34.51 | seanbright | do you want strlen(debug) + 1? |
| 16:34.57 | seanbright | (i doubt that is the problem) |
| 16:35.03 | seanbright | oh, nm. |
| 16:35.25 | putnopvut | thanks for looking. It's bugging me quite badly. |
| 16:37.02 | *** join/#asterisk-dev xpot-mobile (n=james@173-14-225-193-Utah.hfc.comcastbusiness.net) |
| 16:39.22 | seanbright | putnopvut: your ternary |
| 16:39.27 | seanbright | putnopvut: parenthesize it |
| 16:40.52 | seanbright | that's definitely a bug if not the cause of your problem. |
| 16:44.05 | *** join/#asterisk-dev xpot-mobile (n=james@173-14-225-193-Utah.hfc.comcastbusiness.net) |
| 16:48.15 | *** join/#asterisk-dev xpot-mobile (n=james@173-14-225-193-Utah.hfc.comcastbusiness.net) |
| 17:32.19 | *** join/#asterisk-dev xpot-mobile (n=james@173.8.94.1) |
| 17:34.35 | *** join/#asterisk-dev atis_work (n=atis_wor@193.238.212.171) |
| 17:41.56 | philipp64 | Corydon76-dig: got a minute? having an issue with func_curl.so... it links, but when I load the module, I get: "asterisk: can't resolve symbol 'curl_easy_setopt'" |
| 17:43.45 | philipp64 | the odd part is that (from what I can tell, anyway) the only dynamic dependencies in func_curl.so are for libgcc_s.so.1, libpthread.so.0, libc.so.0, and ld-uClibc.so.0. |
| 17:44.02 | *** join/#asterisk-dev hugorebelo (n=hugorebe@200-171-132-124.completo.com.br) |
| 17:44.20 | putnopvut | seanbright: giving it a try, and if that doesn't work, russellb had suggested doing the size argument separately and storing it in a size_t and passing that to ast_calloc |
| 17:45.26 | putnopvut | seanbright: yep, parenthesizing the ternary did the trick. Thanks! |
| 17:45.30 | russellb | nice. |
| 17:45.42 | russellb | order of operations fail :-( |
| 17:46.07 | putnopvut | Silly me |
| 18:00.23 | Corydon76-dig | philipp64: then it's not linking against libcurl.so |
| 18:00.51 | philipp64 | well, no. it's probably linking against libcurl.a instead. |
| 18:02.29 | Corydon76-dig | curl_easy_setopt is in libcurl |
| 18:02.29 | philipp64 | I'll do a noisy-build and see if I can track it down. |
| 18:05.58 | *** join/#asterisk-dev errotan (n=errotan@5403E5B8.catv.pool.telekom.hu) |
| 18:08.36 | seanbright | i'm a genius |
| 18:11.40 | Corydon76-dig | I'm not |
| 18:16.33 | *** join/#asterisk-dev atis_work (n=atis_wor@193.238.212.171) |
| 18:49.24 | philipp64 | Corydon76-dig: so who has the loader dependency on libcurl.so? Is it asterisk or func_curl.so? |
| 18:50.06 | *** join/#asterisk-dev Victor_Yure (n=victor@unaffiliated/victoryure/x-837844) |
| 18:54.47 | philipp64 | hmmm... also, the CFLAGS that I'm passing in seem to be ignored. grrr. |
| 18:56.09 | kpfleming | how are you passing them in? |
| 19:04.00 | philipp64 | configure ... CFLAGS='...' |
| 19:04.51 | philipp64 | configure --help tells me that "CFLAGS" is one of "Some influential environment variables" ... no, not hardly... |
| 19:04.53 | kpfleming | does autoconf create configure scripts that support that? i've always seen them set as env variables before the script name, not arguments to the script |
| 19:05.02 | kpfleming | 'environment variables' |
| 19:05.07 | kpfleming | not command line arguments |
| 19:05.11 | kpfleming | they are different, you know |
| 19:05.37 | philipp64 | Usage: ./configure [OPTION]... [VAR=VALUE]... |
| 19:05.38 | philipp64 | To assign environment variables (e.g., CC, CFLAGS...), specify them as |
| 19:05.40 | philipp64 | VAR=VALUE. See below for descriptions of some of the useful variables. |
| 19:06.15 | kpfleming | well, our script code does nothing special with CFLAGS, it just lets it pass through and is preserved when we modify it |
| 19:06.32 | kpfleming | but i do not believe it is carried over into the asterisk build system |
| 19:07.05 | kpfleming | that's probably an oversight, but that's how it is |
| 19:08.55 | philipp64 | egrep '\<CFLAGS\>' Makefile* |
| 19:09.27 | *** join/#asterisk-dev mvanbaak (n=michiel@asterisk/contributor-and-bug-marshal/mvanbaak) |
| 19:09.27 | *** mode/#asterisk-dev [+o mvanbaak] by ChanServ |
| 19:10.15 | kpfleming | philipp64: was that a question of some sort? |
| 19:11.38 | philipp64 | I'm only ever seeing it get clobbered. I don't see where it's value is actually used. am I missing something? |
| 19:11.50 | kpfleming | which version of asterisk are you looking at? |
| 19:14.29 | philipp64 | 1.6.2.0-beta4 |
| 19:15.23 | kpfleming | i see absolutely no places in our Makefiles where CFLAGS is getting 'clobbered' |
| 19:16.00 | kpfleming | since our Makefiles don't expect custom flags to be in CFLAGS in the first place |
| 19:16.18 | kpfleming | they are supposed to be in ASTCFLAGS or COPTS (although i'd like to see the latter stop being used) |
| 19:16.30 | *** join/#asterisk-dev atis_work (n=atis_wor@193.238.212.171) |
| 19:17.30 | kpfleming | right now, we have no method of providing custom CFLAGS to the configure script and having those get carried over to the build system |
| 19:19.00 | philipp64 | so... what's the fix? or what will be the fix? |
| 19:19.22 | kpfleming | someone will have to enter a feature request, preferably with a patch, to add this ability |
| 19:19.30 | kpfleming | it's not a bug, because we never said it would work :-) |
| 19:19.44 | philipp64 | and equally importantly, when configure is running and building various things to see if they link, etc. will it use CFLAGS and LDFLAGS, or ignore them? |
| 19:19.52 | kpfleming | it will use them |
| 19:19.57 | philipp64 | well, configure says it does... |
| 19:20.09 | philipp64 | and someone signed off on the configure.ac file... |
| 19:20.57 | kpfleming | configure says it does because that text comes from autoconf and it can't be changed |
| 19:21.09 | kpfleming | a 2-second look would show you it does not come from configure.ac |
| 19:21.26 | kpfleming | the configure script will use them, but it does not preserve them for the build system |
| 19:21.32 | kpfleming | because we never thought about that requirement |
| 19:21.50 | kpfleming | i can try to fix that right now, give me a few minutes |
| 19:22.12 | philipp64 | thanks. |
| 19:24.17 | kpfleming | they are going to get inserted into the command after _ASTCFLAGS (the flags computed by the build system) and before ASTCFLAGS (the flags specified on the 'make' command line, if any) |
| 19:24.57 | philipp64 | oh. that might be an issue. |
| 19:25.28 | philipp64 | we specify the architecture, the default optimization, things like the inline optimization, not aligning functions, etc. |
| 19:25.50 | kpfleming | that should be fine |
| 19:25.55 | philipp64 | if you want to override them, they'll have to come first so whatever you add on last gets used. |
| 19:26.08 | philipp64 | also, is ASTCFLAGS used for host, or target, or both? |
| 19:26.10 | kpfleming | umm. that was my point exactly. |
| 19:26.18 | kpfleming | we don't make any host binaries |
| 19:26.23 | kpfleming | there is no 'host' |
| 19:26.38 | philipp64 | menuselect? |
| 19:26.38 | kpfleming | well, menuselect i guess |
| 19:26.48 | kpfleming | really, this whole system was not designed for proper cross-compilation |
| 19:26.53 | *** join/#asterisk-dev jmls (n=jmls@host217-36-208-155.in-addr.btopenworld.com) |
| 19:27.07 | kpfleming | and it will take someone else with experience to make it work, because we don't have it and we don't have any need for cross compilation |
| 19:27.16 | philipp64 | if I had a dollar for everytime I've been told that... :-) |
| 19:27.38 | kpfleming | it's about a million times better than it was in asterisk 1.2, but still isn't there |
| 19:27.38 | philipp64 | (about the not working with proper cross-compilation, I mean.) |
| 19:27.59 | jmls | shuffles back into the blinding light of #asterisk-dev. It's been a while ... |
| 19:28.05 | *** join/#asterisk-dev errotan (n=errotan@62.201.123.132) |
| 19:28.30 | Qwell | jmls: *wave* |
| 19:28.32 | kpfleming | in any case... if you specify CFLAGS, they'll go after any flags the build system produces, which means they'll take precedence |
| 19:28.40 | kpfleming | i don't know why you think that is a problem |
| 19:29.16 | jmls | Qwell: Hey! how you doing ? |
| 19:30.30 | Corydon76-dig | pokes jmls with a blunt instrument |
| 19:30.49 | jmls | ow! |
| 19:30.57 | jmls | ~jbot swat Corydon76-dig |
| 19:31.08 | jmls | oh. |
| 19:31.19 | jmls | heh, it's been a _really_ long time :) |
| 19:31.50 | seanbright | it's infobot now |
| 19:32.01 | seanbright | ~swat jmls |
| 19:32.02 | infobot | ACTION swats jmls with a jmls swatter |
| 19:32.11 | seanbright | ~fist russellb |
| 19:32.12 | infobot | ACTION rules russellb with an iron fist |
| 19:32.14 | philipp64 | but I don't want them to take precedence. |
| 19:32.19 | seanbright | teehee. |
| 19:32.20 | jmls | eek! |
| 19:32.22 | philipp64 | I want them to be the default if nothing else is specified. |
| 19:32.28 | philipp64 | that's the nature of cross-compiling. |
| 19:32.44 | russellb | /kick seanbright |
| 19:32.59 | philipp64 | if a project has an API that uses -fomit-frame-pointer, then you let it do that. |
| 19:33.03 | Corydon76-dig | ~abuse seanbright |
| 19:33.04 | infobot | ACTION smacks seanbright across the face. "Take that, sucker!" |
| 19:33.14 | russellb | ~leavethebotalone |
| 19:33.15 | philipp64 | otherwise, cross-language calls (like in Mathlab) get royally screwed up. |
| 19:33.22 | seanbright | ~no |
| 19:33.29 | kpfleming | so you never want to override the project's CFLAGS and LDFLAGS? |
| 19:33.35 | seanbright | ~youarenotthebossofme |
| 19:33.39 | seanbright | ~booyah |
| 19:33.40 | infobot | it has been said that booyah is A substance simalar to chicken noodle soup often leaving chicken bones and such in the mix |
| 19:34.03 | jmls | ~quieten seanbright |
| 19:34.18 | jmls | gives up |
| 19:34.29 | philipp64 | let's start again. |
| 19:34.51 | philipp64 | I want to be able to say: -O2 -Os -march=k6-2 for instance.... |
| 19:35.07 | kpfleming | even though that doesn't make any sense? |
| 19:35.15 | kpfleming | trolls |
| 19:35.16 | philipp64 | if the project wants to override the optimization (or warnings, or whatever) it can. |
| 19:35.28 | philipp64 | but it should never override the architecture, for instance. |
| 19:35.35 | jmls | philipp64: it was a long time ago I was speaking to you about getting lib_curl to work on astlinux ;) Seems as if the damn thing is still giving you grief .. |
| 19:36.07 | kpfleming | alright, i suppose i can make that work |
| 19:36.16 | philipp64 | (it actually does make sense... O2 is a superset of optimizations, and Os tells it to prefer smaller code over faster code.) |
| 19:36.58 | philipp64 | jmls: well, I had a breakthrough... part of the grief is the fault of the Makefile ignoring certain environment variables. |
| 19:37.06 | philipp64 | that was unexpected. |
| 19:37.47 | kpfleming | not really, because the Makefile does not document that it pays any attention to those variables |
| 19:38.07 | philipp64 | so anyone: who needs to get linked with -lcurl? is it asterisk, or func_curl.so? because neither is... |
| 19:38.18 | kpfleming | func_curl.so |
| 19:38.44 | philipp64 | well, UNIX leans heavily on defacto standards and conventions. |
| 19:38.46 | Qwell | which likely means it isn't set in makeopts (CURL_LIB) |
| 19:38.51 | philipp64 | break those at your own peril. |
| 19:39.08 | seanbright | no |
| 19:39.12 | seanbright | break them at *your* peril |
| 19:39.14 | seanbright | :) |
| 19:39.45 | kpfleming | wishes that people could just ask questions instead of being accusatory and inflammatory |
| 19:39.54 | philipp64 | S["_libcurl_config"]="" |
| 19:39.56 | philipp64 | S["PBX_CURL"]="1" |
| 19:39.57 | philipp64 | S["CURL_DIR"]="/home/philipp/asterisk/build_i586/staging_dir" |
| 19:39.59 | philipp64 | S["CURL_INCLUDE"]="" |
| 19:40.00 | philipp64 | S["CURL_LIB"]="" |
| 19:40.02 | philipp64 | S["CURL"]="/usr/bin/curl" |
| 19:40.03 | philipp64 | S["LIBS"]="-lssl -lz -lcurl" |
| 19:40.05 | philipp64 | D["HAVE_CURL"]=" 1" |
| 19:40.07 | philipp64 | grrrr... ok, how do I force it? |
| 19:40.20 | kpfleming | how do you force what? |
| 19:40.27 | philipp64 | who's being inflammatory? |
| 19:40.38 | philipp64 | CURL_LIB... |
| 19:40.56 | kpfleming | if the configure script changes that tilghman made aren't setting CURL_LIB, then they are broken |
| 19:41.29 | kpfleming | what is that output from? |
| 19:45.38 | jmls | a little "underhand" comment on the fs list came through about "nastiness" in asterisk code. Perhaps it would be good to remove the comment ? |
| 19:45.48 | Corydon76-dig | They're being set fine on 1.4 Linux (not cross-compiled) |
| 19:45.57 | Qwell | jmls: huh? |
| 19:45.59 | jmls | quotes "Any software that openly admits that a function is "pure nastiness" but doesn't change it from version 1.0, 1.2, 1.4, or 1.6 has questionable leadership IMHO" |
| 19:46.24 | Corydon76-dig | This is why we went through this process of testing. If it didn't work, I'm not sure why philipp64 confirmed that it did. |
| 19:48.44 | philipp64 | grep -i curl config.status |
| 19:48.56 | philipp64 | ok, so tilghman's changes are broken then. |
| 19:49.11 | philipp64 | I tried passing CURL_LIB in by hand, and that also gets clobbered. |
| 19:49.35 | kpfleming | it can't be being clobbered if the system has no intention of you being able to supply it |
| 19:49.55 | kpfleming | it's not being clobbered, the system is doing its job and computing it |
| 19:50.45 | Corydon76-dig | The proper way to override it is to specify an alternative path for curl detection, i.e. --with-curl=... |
| 19:52.49 | Corydon76-dig | In the future, please do NOT confirm that something works, if it's not working |
| 19:53.14 | Qwell | jmls: well, if they have some specific complains beyond "look at the comment that displays intellectual honesty".. |
| 19:53.38 | Qwell | complaint too |
| 19:53.50 | seanbright | it had an "... IMHO" attached to it |
| 19:53.53 | kpfleming | especially since the comment is not about the code, it's about the operations it has to perform |
| 19:54.19 | kpfleming | it has to do those things because working differently would require architectural changes that aren't worth making without serious thought |
| 19:54.40 | kpfleming | and that would likely destabilize the code base for quite some time |
| 19:54.55 | philipp64 | Corydon76-digI tried setting it explicitly. |
| 19:55.40 | kpfleming | Marquis42: good thing we all know what XEP-0248 mode is :-) |
| 19:56.34 | Marquis42 | heh.... |
| 19:56.51 | Qwell | XEP is like an RFC, right? |
| 19:56.56 | *** join/#asterisk-dev korihor (n=korihor@190.205.251.61) |
| 19:57.04 | Marquis42 | I really need to write up a doc so some of that stuff can be explained. |
| 19:57.12 | Marquis42 | Yes, and XEP is just like an RFC for XMPP. |
| 19:57.25 | kpfleming | yep |
| 19:57.27 | Corydon76-dig | jmls: any software that doesn't admit that it has problems has questionable leadership, IMHO |
| 19:57.39 | kpfleming | they just don't give their XMPP features names |
| 19:57.43 | seanbright | shhhh, they are *here* |
| 19:57.50 | Qwell | seanbright: so? :) |
| 19:57.50 | seanbright | heh |
| 19:58.12 | seanbright | i just think it's odd |
| 19:58.29 | seanbright | i guess we could all go lurk over in #freeswitch-dev |
| 19:58.48 | seanbright | i have enough channels open as it is |
| 19:58.49 | Marquis42 | Well, you could call it "collection nodes". And, in fact, the config option to enable it currently has that name (collection_nodes). But, technically, older versions of the regular PubSub spec (XEP-0060) had collection nodes specified before they were broken off into XEP-0248. |
| 19:59.02 | Qwell | seanbright: You don't have enough channels until you run out of screen space to fit them all. |
| 19:59.13 | putnopvut | 7 is plenty for me. |
| 19:59.28 | Qwell | 19? |
| 19:59.29 | file | 21 is healthy for me. |
| 19:59.36 | seanbright | 6 is my upper limit |
| 19:59.42 | Qwell | seanbright: wussy |
| 19:59.52 | Corydon76-dig | Qwell: That's not a question of enough channels. That's a question of not having a large enough monitor |
| 19:59.55 | kpfleming | i have 7, but 5 of them are jabber, not IRC |
| 20:00.03 | Qwell | Corydon76-dig: point |
| 20:00.17 | Corydon76-dig | Qwell: or the font is too large |
| 20:00.22 | Marquis42 | Corydon76-dig: That's why you need to dedicate an entire monitor to various jabber MUCs and IRC channels. ;) |
| 20:00.30 | Qwell | Marquis42: I already do |
| 20:00.36 | Corydon76-dig | Marquis42: I already do |
| 20:00.48 | Marquis42 | Haha... Excellent. Glad I'm not the only one. :) |
| 20:01.20 | Corydon76-dig | What I actually lack is a good quad-port video card |
| 20:01.56 | Corydon76-dig | Well, and desk space to fit 5 screens |
| 20:02.26 | kpfleming | nope, you need a monitor arm that holds them in 2x2 configuration |
| 20:02.32 | Qwell | I dunno.. I could fit 2 more pretty reasonably on my desk |
| 20:02.36 | kpfleming | and two PCI-Express slots for two video cards |
| 20:02.36 | Marquis42 | Don't build out, build up. That's what custom screen mounts are for. Not that I have, I've just got a pair of 24" screens right now. |
| 20:02.37 | kpfleming | done! |
| 20:02.52 | Corydon76-dig | Qwell: I already have 4 monitors on this desk... |
| 20:03.02 | Corydon76-dig | for 3 different computers |
| 20:03.11 | putnopvut | Maybe someone could explain this one to me. Why is ast_register_application_xml declared in module.h and not app.h? |
| 20:03.41 | putnopvut | It seems weird to have to #include module.h in a core file just because it registers an application. |
| 20:03.56 | Corydon76-dig | Because app.h is an overflow of utils.h, not a master file for applications |
| 20:04.04 | jmls | Corydon76-dig: I agree with all that you say. It's just not nice for people to be able to point at the source and say "hey! even they say it's bad!" |
| 20:04.14 | *** part/#asterisk-dev pyite[A] (n=pyite@unaffiliated/pyite) |
| 20:04.35 | seanbright | jmls: we're over it |
| 20:04.41 | jmls | cool. |
| 20:04.45 | jmls | gets over it |
| 20:04.45 | Corydon76-dig | jmls: that's still better than people not being able to point at the source |
| 20:05.53 | jmls | Heh. I'm just glad you can't see my code ... |
| 20:05.53 | Corydon76-dig | If you come up with an improved comment, we'll look at changing it, but I'm not going in merely to delete a long-standing comment |
| 20:05.54 | jmls | I thought that we were over it ;) |
| 20:05.54 | seanbright | - nastiness |
| 20:05.54 | seanbright | + super fun-time nastiness |
| 20:06.13 | kpfleming | philipp64: ok, CFLAGS and LDFLAGS to the configure script should now work |
| 20:06.25 | *** join/#asterisk-dev voipmonk (n=voipmonk@CPE000fb5620979-CM0014f859c1f2.cpe.net.cable.rogers.com) |
| 20:06.50 | putnopvut | Corydon76-dig: Maybe I should have rephrased and asked if anyone had a *good* reason why the function is declared there ;) |
| 20:06.58 | jmls | "we changed this comment just to please jmls and remove a chance of nastiness appearing on the fw list in the future. See. We do care." |
| 20:07.53 | Qwell | jmls: there will be nastiness no matter what we do. |
| 20:08.06 | kpfleming | embrace the nastiness! |
| 20:08.25 | jmls | feel the nastiness! Rejoice in the loathing! |
| 20:09.09 | jmls | ah. feels like I never left O:-) |
| 20:09.13 | kpfleming | Loathe in the rejoicing! |
| 20:10.17 | *** part/#asterisk-dev voipmonk (n=voipmonk@CPE000fb5620979-CM0014f859c1f2.cpe.net.cable.rogers.com) |
| 20:10.48 | jmls | I did have a question when I joined here. for the life of me I can't think of it now :-$ |
| 20:12.31 | putnopvut | jmls: were you going to ask for my mailing address so you could mail me lots of chocolate? |
| 20:15.12 | philipp64 | kpfleming: where? |
| 20:15.17 | seanbright | Corydon76-dig: we need a point release of 1.4 now |
| 20:15.18 | seanbright | :) |
| 20:15.33 | kpfleming | philipp64: all the 1.6 branches and trunk |
| 20:16.04 | jmls | putnopvut: I didn't think that it was chocolate that you consumed on a Friday night ;) |
| 20:16.18 | jmls | seanbright: LOL. Just read the commit message ... |
| 20:16.24 | putnopvut | jmls: well, it probably wouldn't arrive until early next week :) |
| 20:17.37 | jmls | putnopvut: wot ? nothing for the weekend, Sir ? |
| 20:17.47 | philipp64 | kpfleming: can you send me a link? |
| 20:18.17 | kpfleming | http://svn.digium.com/svn/branches/1.6.2 |
| 20:18.21 | seanbright | heh |
| 20:18.30 | seanbright | svn checkout http://svn.freeswitch.org/svn/freeswitch/trunk freeswitch |
| 20:18.35 | seanbright | woops |
| 20:18.36 | seanbright | heh |
| 20:18.40 | jmls | hah |
| 20:18.56 | seanbright | i admit NOTHING |
| 20:18.57 | Qwell | awesomely weird... nice |
| 20:19.34 | russellb | o.o |
| 20:22.07 | jmls | we should introduce something like Heisenberg uncertainty principle to the codebase. "whatever you study, you also change" (Jurassic Park, 1997) |
| 20:23.48 | putnopvut | wait wait wait |
| 20:23.51 | putnopvut | 1997? |
| 20:23.58 | putnopvut | more like 1993 *scoff* |
| 20:24.49 | jmls | Sorry, "Jurassic Park: The lost world" |
| 20:25.03 | kpfleming | (TM)(R)(C)(XYZ) |
| 20:25.21 | jmls | damn! you are so pernickity (http://www.urbandictionary.com/define.php?term=pernickity) |
| 20:25.37 | jmls | nice word, that. ;) |
| 20:26.08 | kpfleming | no, i am frasmotic |
| 20:26.22 | jmls | kpfleming: I was talking to putnopvut ;) |
| 20:26.34 | kpfleming | that's your problem, not mine |
| 20:26.47 | jmls | but frasmotic is also a very cool word .. |
| 20:27.17 | putnopvut | jmls: I think everyone who works for kpfleming becomes pernickity |
| 20:27.27 | putnopvut | Which is not to be confused with "persnickety" I take it? |
| 20:27.31 | seanbright | i've always said persnickity |
| 20:27.34 | Qwell | pernickitification? |
| 20:27.53 | putnopvut | http://dictionary.reference.com/browse/persnickety |
| 20:28.20 | kpfleming | Q: who can break down the word 'fictionalization' and tell me what it actually means? |
| 20:28.43 | putnopvut | A: I can |
| 20:28.48 | Qwell | winner! |
| 20:29.05 | jmls | http://www.wordwebonline.com/en/FICTIONALIZATION |
| 20:29.09 | jmls | damn |
| 20:29.13 | jmls | loser |
| 20:29.29 | kpfleming | you all failed |
| 20:29.36 | seanbright | taking something that is factual and making it something not factual? |
| 20:29.42 | seanbright | like "a beautiful mind" |
| 20:29.49 | kpfleming | nope |
| 20:29.51 | seanbright | fail. |
| 20:29.57 | jmls | was that man |
| 20:30.17 | kpfleming | step 1: the '-ation' suffix means the result of something having been fictionalized |
| 20:30.29 | jmls | I've come back to reclaim all those pens YOU BASTARDS STOLE FROM ME |
| 20:30.34 | kpfleming | step 2: the '-ized' suffix means that something was made fictional |
| 20:30.42 | jmls | oh. did I really say that out loud ? |
| 20:31.01 | kpfleming | so... it's the result of something have been made fictional... in other words, fiction |
| 20:31.15 | seanbright | i feel like i just said that. |
| 20:31.19 | kpfleming | but on car commercials they don't want to say 'fiction', so they say 'fictionalzation' |
| 20:31.49 | jmls | ~thwack jmls |
| 20:31.50 | infobot | ACTION hits jmls on the arm with a Cisco Manual |
| 20:31.55 | jmls | EEK |
| 20:32.10 | jmls | thats, like torture .. |
| 20:32.43 | philipp64 | kpfleming: that's broken. |
| 20:32.56 | kpfleming | thanks for the detailed analysis |
| 20:33.04 | philipp64 | ("This XML file does not appear to have any style information..." |
| 20:33.31 | kpfleming | it's a link to code in our subversion repository |
| 20:33.32 | seanbright | http://svn.digium.com/svn/asterisk/branches/1.6.2 |
| 20:33.39 | seanbright | (you forgot the 'asterisk' bit) |
| 20:33.43 | kpfleming | oops |
| 20:33.47 | kpfleming | friday got me again |
| 20:33.53 | seanbright | philipp64: what version of asterisk are you working against? |
| 20:35.07 | seanbright | philipp64: ^^^^ |
| 20:36.01 | philipp64 | 1.4.26.1, 1.6.1.4, and 1.6.2.0-beta4 |
| 20:36.42 | seanbright | hold |
| 20:37.02 | kpfleming | the changes were not made for 1.4.x |
| 20:37.18 | seanbright | no they weren't. |
| 20:37.23 | seanbright | ah well. |
| 20:37.36 | philipp64 | how can I see the revision history? |
| 20:37.44 | seanbright | svn log |
| 20:38.03 | philipp64 | via browser... |
| 20:38.09 | kpfleming | you can't right now |
| 20:38.14 | kpfleming | our web interface is down |
| 20:38.31 | Corydon76-dig | kpfleming: what changes weren't made in 1.4? |
| 20:38.48 | kpfleming | the changes i just made to support CFLAGS/LDFLAGS passing from configure to makefile |
| 20:38.56 | Corydon76-dig | Ah |
| 20:39.14 | seanbright | http://lists.digium.com/pipermail/svn-commits/2009-August/051050.html |
| 20:39.17 | seanbright | philipp64: ^^^^ |
| 20:40.47 | *** join/#asterisk-dev obnauticus (n=l@about/windows/regular/obnauticus) |
| 20:41.01 | Corydon76-dig | pokes obnauticus |
| 20:42.25 | jmls | Corydon76-dig: is that wise ? |
| 20:43.01 | Corydon76-dig | jmls: He never responds |
| 20:43.44 | seanbright | who is he? |
| 20:44.01 | jmls | he is the Stig ! |
| 20:44.05 | jsmith | A bot? A logger? |
| 20:44.11 | jsmith | A lurker? |
| 20:44.20 | Corydon76-dig | A younger version of file |
| 20:44.29 | kpfleming | is that possible? |
| 20:44.47 | jmls | can he be restored from backup then ? |
| 20:44.58 | file | hopefully not a branch of me |
| 20:46.55 | russellb | o.O |
| 20:46.58 | russellb | about/windows ? |
| 20:47.02 | Corydon76-dig | merges file into obnauticus |
| 20:48.03 | jmls | that *had* to hurt. Was there a lot of conflicts ? |
| 20:48.28 | Corydon76-dig | Dunno, the merge takes a bit longer than that... |
| 20:50.12 | jmls | "Obnauticus: a disco ball that the german aliens seek wisdom from on the tv show" |
| 20:50.16 | jmls | wtf? |
| 20:54.07 | Corydon76-dig | jmls: btw, have you seen photos of my "kitty"? |
| 20:54.21 | jmls | eek!. No .... |
| 20:54.59 | Corydon76-dig | http://www.facebook.com/photo.php?pid=2112870&l=2bc447f28e&id=734754650 |
| 20:55.50 | jmls | yikes! Was this kitty from Chernobyl ? ;) |
| 20:56.31 | Corydon76-dig | 5 month old Flemish Giant bunny |
| 20:56.39 | Corydon76-dig | size of a cat |
| 20:57.02 | jmls | sh*t |
| 20:57.29 | jmls | that would scare any burglar ... |
| 20:57.51 | Corydon76-dig | He's approximately half size now |
| 20:59.10 | Marquis42 | Corydon76-dig: What's he weigh right now? |
| 20:59.40 | Corydon76-dig | Marquis42: 9 lbs |
| 21:00.02 | Marquis42 | That's a mighty big rabbit. |
| 21:00.23 | philipp64 | seanbright: is there a bug # associated with that? |
| 21:00.37 | Corydon76-dig | A gentle giant |
| 21:02.46 | Marquis42 | Cool. I used to have quiet a menagerie, including one rabbit. But now I'm pared down to a couple of giant cats. |
| 21:03.37 | jmls | my wife is trying to buy an Irish wolfhound ... |
| 21:04.15 | Marquis42 | Those are cool. I really like animals that are big for their species. |
| 21:05.17 | jmls | heh. that means you won't like my wife ;) She's short for her species ... |
| 21:05.26 | Marquis42 | lol |
| 21:05.52 | Marquis42 | Is she going to get a saddle for the wolfhound then? ;) |
| 21:06.44 | jmls | That's why she went to the http://www.thesaddleryshop.co.uk/ |
| 21:16.27 | Marquis42 | OK, a question that doesn't involves rabbits or wolfhound saddles ;) : Is there an API function that allows writing to the console when you haven't been passed the file descriptor? |
| 21:16.41 | kpfleming | nope |
| 21:16.52 | Marquis42 | Alrighty then, that answers that question. :) |
| 21:17.17 | Corydon76-dig | Well, you can use ast_verbose, though that's not limited to the console |
| 21:18.54 | Marquis42 | Yeah, I can do that. Basically, the output for some CLI commands in my res_jabber work isn't known until the callback function to handle the result is called by which time the function for the command has long since exited. So outputting that result doesn't look very pretty. |
| 21:24.09 | Corydon76-dig | Marquis42: if it's a callback, why not store the fd in the struct handed to the function? |
| 21:24.44 | Marquis42 | I suppose that's entirely possible. I guess I hadn't really thought of that. :/ |
| 21:24.52 | *** part/#asterisk-dev |Cybex| (n=John@80.100.126.176) |
| 21:25.11 | Corydon76-dig | The only risk is if the FD gets recycled for another purpose before the results are ready |
| 21:25.47 | Marquis42 | True, although the latency isn't huge. Is there a big risk that it'll happen within a short time span? |
| 21:26.36 | Corydon76-dig | It's especially possible when it comes to AMI |
| 21:26.58 | Corydon76-dig | and AMI won't get results from an ast_verbose anyway |
| 21:27.29 | philipp64 | seanbright: ^^^^^^ |
| 21:27.41 | Corydon76-dig | So really, you should be blocking CLI exit until the results are in |
| 21:28.28 | Corydon76-dig | I suppose you could dup2 the fd, and that would ensure that the stream wouldn't close until your command was done |
| 21:28.51 | Corydon76-dig | Whether AMI would see the results or not is another thing entirely |
| 21:29.27 | Corydon76-dig | but at least you wouldn't be using a recycled FD |
| 21:30.17 | Corydon76-dig | The best option is still to block progress until results are ready |
| 21:30.38 | Marquis42 | Hrmmm... OK, I'll play with a couple of ideas then and see what I can do. It's not a huge problem, the output is just different from other CLI commands. Thanks! |
| 21:30.47 | Corydon76-dig | and do a native AMI command if you want to do delayed results |
| 21:31.49 | Marquis42 | OK |
| 21:43.09 | *** join/#asterisk-dev bbryant (n=brett@c-76-26-221-79.hsd1.sc.comcast.net) |
| 21:43.09 | *** mode/#asterisk-dev [+o bbryant] by ChanServ |
| 21:56.44 | putnopvut | I'm having another mysterious crash in the CCSS branch while attempting to test. This one seems even more bizarre to me. I'll pastebin what is happening. |
| 21:57.09 | russellb | putnopvut: good thing you planned on having this periodic test time in your schedule :-) |
| 21:58.33 | putnopvut | russellb: indeed |
| 21:59.35 | putnopvut | http://pastebin.ca/1546348 |
| 22:00.06 | putnopvut | Oh, crash is happening when ast_register_application_xml is called. |
| 22:04.25 | putnopvut | Somehow valgrind is saying that it's reading something at address 0x0 |
| 22:04.33 | putnopvut | That doesn't make sense though. |
| 22:04.44 | putnopvut | ccreq_app and ccreq_exec are both non-NULL. |
| 22:04.57 | putnopvut | Wait a sec... |
| 22:05.16 | putnopvut | hm, nope. |
| 22:09.18 | russellb | putnopvut: I don't know what line it is talking about |
| 22:09.39 | putnopvut | russellb: it's the ast_register_application_xml line |
| 22:09.50 | russellb | that is a macro |
| 22:09.57 | russellb | and it expects to be used from within a module, not the core |
| 22:10.00 | russellb | that's your problem. |
| 22:10.11 | putnopvut | Why does it matter? |
| 22:10.25 | russellb | look at it and you'll see :-) |
| 22:10.30 | putnopvut | what, the macro? |
| 22:10.33 | putnopvut | I looked at it. |
| 22:10.34 | russellb | yup |
| 22:10.47 | putnopvut | It just calls through another macro to ast_register_application2, which is in pbx.c |
| 22:10.54 | putnopvut | I'll admit I hadn't looked at that yet, though. |
| 22:11.04 | russellb | no, it calls into ast_register_application() |
| 22:11.06 | russellb | which is another macro |
| 22:11.11 | russellb | which includes ast_module_info->self |
| 22:11.18 | russellb | and that part is where it breaks |
| 22:11.34 | russellb | you'll have to use ast_register_application2() directly |
| 22:11.35 | file | kaboommmmm |
| 22:11.41 | putnopvut | @#*($& |
| 22:12.55 | russellb | awwww, it's okay :-) |
| 22:13.03 | putnopvut | ast_register_application2(ccreq_app, ccreq_exec, NULL, NULL, NULL) ? |
| 22:13.09 | putnopvut | (with a semicolon of course) |
| 22:13.18 | russellb | nods |
| 22:13.20 | putnopvut | That appears to be working. |
| 22:13.22 | putnopvut | Thanks :) |
| 22:13.24 | russellb | np |
| 22:13.29 | russellb | That will cost you $5.99 |
| 22:13.42 | putnopvut | now understands why people sometimes aren't that crazy about macros :) |
| 22:14.09 | putnopvut | I hadn't looked at the args to ast_register_application to see that mod->self was there. |
| 22:14.20 | putnopvut | I just saw that it was calling ast_register_application2 |
| 22:16.55 | russellb | I only knew this off of the top of my head because I have done the same thing :-) |
| 22:33.11 | Marquis42 | russellb: I really hate to ask this, since I know you've got lots on your plate, but is there any chance you might get a chance to look at issue 15753 soon-ish? It makes testing a vanilla checkout of my branch a bit harder. :( |
| 22:36.23 | Qwell | M15753 |
| 22:36.25 | MuffinMan | [assigned] [Asterisk] Functions/func_devstate 0015753: [patch] Custom devices do not interoperate with distributed events properly reported by Marquis (Karma: +16.25) https://issues.asterisk.org/view.php?id=15753 |
| 22:48.52 | paravoid | russellb: any ETA for the next 1.6.2.x release? |
| 22:49.09 | paravoid | also, any chances that the -addons merge may be backported to 1.6.2? that would be cool, from a distributor PoV |
| 22:51.10 | russellb | I originally thought that I wanted to, but merging it in was a bit more invasive than I felt like backporting. :-) |
| 22:51.23 | snuff-home | paravoid: the eta can kinda be seen by looking @ roadmap on issues ;) |
| 22:52.03 | russellb | also, 1.6.2.0-rc1 should be out this weekend |
| 22:52.12 | paravoid | cool |
| 22:52.39 | paravoid | what's invasive about cp'ing -addons 1.6.2 to asterisk/addons/ 1.6.2? |
| 22:52.47 | paravoid | (I'm not being sarcasting, just wondering) |
| 22:53.26 | russellb | there were some code changes to make, too, I think |
| 22:53.32 | paravoid | also, since you're shipping a binary channel driver (skype) nowadays |
| 22:53.34 | russellb | and additions to configure ... |
| 22:53.40 | paravoid | does that mean that the ABI is frozen? |
| 22:53.44 | russellb | nope |
| 22:53.49 | paravoid | per major version or what? |
| 22:53.51 | paravoid | oh? |
| 22:53.57 | russellb | chan_skype is delivered as source |
| 22:54.03 | paravoid | damn, that sucks :) |
| 22:54.05 | russellb | and uses a binary library for the meat of it. |
| 22:54.09 | paravoid | ah |
| 22:54.16 | russellb | it should be frozen per 1.6.X |
| 22:54.24 | paravoid | ok |
| 22:54.27 | russellb | unless something happens that we can't get around ... *shrugs* |
| 22:54.42 | paravoid | we're shipping at least -addons in binary, which means I have to express that in a binary package dependency |
| 22:54.56 | paravoid | besides that, I think it's just chan_oh323 nowadays... |
| 22:55.07 | paravoid | we had spandsp too, but that was thankfully merged :) |
| 22:55.16 | paravoid | oh, we also have chan_capi |
| 22:55.41 | paravoid | so, merging -addons would be very very cool :) |
| 22:56.05 | paravoid | what's the ETA for 1.6.3.0 (as in final version)? mid-2010 or later? |
| 22:56.18 | russellb | hopefully by the end of this year |
| 22:56.39 | russellb | Q4 sometime |
| 22:56.50 | paravoid | .3.0? |
| 22:56.54 | paravoid | not .2.0 |
| 22:56.55 | russellb | nods |
| 22:56.59 | russellb | .2.0 in Q3 |
| 22:57.11 | paravoid | oh, cool! |
| 22:57.25 | paravoid | well, .1.0 was ~1y after -beta1, iirc |
| 22:57.31 | russellb | heh |
| 22:57.51 | russellb | that's what happens when you set huge blocking issues, heh |
| 22:58.00 | russellb | 1.6.0 was hit really hard by dealing with DAHDI |
| 22:58.04 | russellb | schedule wise |
| 22:58.13 | russellb | and the vast underestimation of how long that transition would take |
| 23:00.50 | paravoid | I was talking about 1.6.1.0 |
| 23:00.52 | paravoid | not 1.6.0 |
| 23:01.32 | Qwell | yes, well, 1.6.1 followed 1.6.0 |
| 23:01.39 | Qwell | so the same still applies |
| 23:01.44 | russellb | is confused |
| 23:02.05 | paravoid | heh |
| 23:02.32 | paravoid | the new release model is great, because new features reach us, users, much sooner |
| 23:02.39 | paravoid | and it's more of a Linux 2.6.x model |
| 23:02.40 | russellb | glad you think so |
| 23:02.42 | russellb | nods |
| 23:02.46 | russellb | Linux 2.6.X was the model, yeah. |
| 23:02.49 | snuff-home | heh some aren't so happy ;) |
| 23:02.52 | paravoid | otoh, I think you're maintaining too many branches concurrently |
| 23:02.59 | russellb | paravoid: yeah, I would agree with that. |
| 23:03.02 | russellb | it is sucking in reality. |
| 23:03.05 | russellb | looked good on paper |
| 23:03.15 | paravoid | I mean, I don't see the point e.g. of having 1.6.3 |
| 23:03.19 | russellb | also, 1.6.1.0-beta1 was 6 months before 1.6.1.0 fwiw :-) |
| 23:03.20 | paravoid | 1.6.3 could just as well be trunk |
| 23:03.45 | murdock_ut | So when 1.6.2 get released with 1.4 get security only updates like 1.2 is now? |
| 23:03.49 | Qwell | paravoid: nope, it can't. not if we want to do only bug fixes. |
| 23:03.54 | paravoid | or releasing 1.2 point releases... but I guess that's business-related |
| 23:04.02 | murdock_ut | Man my English sucks today. |
| 23:04.08 | russellb | 1.4 is a different story |
| 23:04.10 | snuff-home | 1.4 not dying anytime soon |
| 23:04.15 | paravoid | Qwell: but isn't that what 1.6.2 is for? |
| 23:04.24 | Qwell | paravoid: not once 1.6.3 gets branched |
| 23:04.28 | russellb | based on the community reaction to 1.2 going security-only, 1.4 will be around for a while |
| 23:04.29 | snuff-home | the new rls sched was only for 1.6.x |
| 23:04.40 | paravoid | Qwell: isn't 1.6.3 branched already? |
| 23:04.43 | murdock_ut | Gotcha. |
| 23:04.46 | russellb | paravoid: nope |
| 23:04.47 | Qwell | paravoid: no |
| 23:05.04 | Qwell | it'll likely be branched when 1.6.2 gets released |
| 23:05.08 | russellb | nods |
| 23:05.15 | russellb | and then we'll have 4 1.6 branches |
| 23:05.17 | russellb | cringes |
| 23:05.28 | Qwell | umm, yeah |
| 23:05.32 | russellb | heh, I can't complain much, it was my idea :-) |
| 23:05.35 | russellb | but we'll figure something out. |
| 23:05.39 | russellb | policy changes aren't quick and easy to make. |
| 23:05.42 | murdock_ut | That sounds like a lot of work. |
| 23:05.46 | Qwell | svn rm branches/1.6.0/ ? :D |
| 23:05.56 | paravoid | oh, right, I was thinking +1 |
| 23:06.13 | russellb | Qwell: potentially. |
| 23:06.40 | russellb | so here is what I have been thinking about ... |
| 23:06.55 | paravoid | so, you're essentially having bug-only fixes on 4, soon-to-be 5 releases (1.4, 1.6.0, 1.6.1, 1.6.2 and soonish 1.6.3) |
| 23:07.03 | russellb | a proposal to a single 1.6.X at a time, with plans for eventually choosing a 1.6.X-LTS (long term support) |
| 23:07.04 | paravoid | plus security-only fixes on 1.2 |
| 23:07.08 | russellb | so we would only have 2 at most ... |
| 23:07.08 | paravoid | isn't that excessive? |
| 23:07.10 | Qwell | paravoid: s/releases/branches/, yes |
| 23:07.19 | paravoid | right. |
| 23:07.25 | russellb | well, the plan was 3 1.6.X's at a time. |
| 23:07.34 | russellb | so once 1.6.3 was released, no more on 1.6.0 ... |
| 23:07.53 | Qwell | paravoid: release vs branch is subtle but important |
| 23:07.55 | russellb | I need to put thoughts together and write up a proposal. |
| 23:08.03 | paravoid | also, you currently have e.g. 1.6.0.13 and 1.6.0.14-rc1 |
| 23:08.07 | murdock_ut | Which should be fine because each release is just baby steps compared to the 1.2 - 1.4 jump. |
| 23:08.21 | paravoid | and 1.6.1.4 and 1.6.1.5-rc1 |
| 23:08.23 | snuff-home | mm making an lts.. sounds ok |
| 23:08.30 | russellb | murdock_ut: yeah, and part of the problem with those other jumps was how we treated backwards compatibility |
| 23:08.40 | russellb | we removed things that we considered the old ways of doing things |
| 23:08.47 | paravoid | russellb: I'm not in position to propose everything, I know far too little about the problems and challenges of Asterisk release engineering |
| 23:08.50 | russellb | which was a really bad idea, and we have stopped doing that in 1.6.X releases |
| 23:08.53 | murdock_ut | They should not have any huge regressions. |
| 23:08.57 | russellb | yeah, that's my problem :-) |
| 23:08.59 | paravoid | I'm just brainstorming, hope you don't mind :) |
| 23:09.00 | russellb | i'm just thinking out loud |
| 23:09.10 | russellb | not that I don't know the problems, I mean it's my problem to deal with |
| 23:09.15 | russellb | sure, don't mind at all |
| 23:09.59 | paravoid | russellb: so, what's the point on doing 1.6.N.X-rcY releases, where X != 0? |
| 23:10.03 | murdock_ut | I personally think the releases have been pretty good. I think the review board has made a big difference. |
| 23:10.11 | Qwell | paravoid: bug fixes |
| 23:10.16 | russellb | murdock_ut: awesome, me too :-) |
| 23:10.30 | paravoid | but 1.6.N.X - 1.6.N.X+1 are bug-fixes only |
| 23:10.34 | Qwell | or do you mean the RCs specifically? |
| 23:10.39 | paravoid | yes, the RCs specifically |
| 23:10.44 | Qwell | it was what the community wanted |
| 23:10.44 | paravoid | it seems a bit excessive |
| 23:10.45 | russellb | paravoid: Asterisk can be fragile and hard to test, and regressions are a big deal to people ... so even bug fixes have high regression probability at times |
| 23:10.50 | paravoid | ETOOMANYBRANCHES |
| 23:11.00 | paravoid | esp. with SVN :) |
| 23:11.10 | russellb | I'll agree with ETOOMANYBRANCHES, but that's unrelated to bug fix RCs |
| 23:11.12 | murdock_ut | People expect phones to just work. |
| 23:11.30 | paravoid | 1.2.34, 1.4.26.1, 1.6.0.13, 1.6.0.14-rc1, 1.6.1.4, 1.6.1.5-rc1, 1.6.2.0-beta4 |
| 23:11.34 | paravoid | 1.2.34, 1.4.26.1, 1.6.0.13, 1.6.0.14-rc1, 1.6.1.4, 1.6.1.5-rc1, 1.6.2.0-beta4 |
| 23:11.34 | russellb | and the best way that we have to get the best test converage is to throw the code out there and get it installed in different environments |
| 23:11.37 | paravoid | argh, sorry |
| 23:11.39 | russellb | the RCs have worked out _very_ well for us |
| 23:11.44 | paravoid | all of these are up-to-date, in some sense |
| 23:11.47 | murdock_ut | If the phones don't work then they think the world has ended. |
| 23:11.49 | russellb | compared to just "throw out a release and hope it works" |
| 23:12.43 | murdock_ut | I haven't been very good about testing RC's. But I am testin 1.6.1.5-rc1 and it fixed a bunch of parking issues I was having. Seems to run pretty good. |
| 23:12.54 | Qwell | I think RCs have been absolutely justified too. |
| 23:12.55 | russellb | I think I'm headed home. However, if any of you would like to rant about or bainstorm ideas or proposals in email, feel free to email me - russell@digium.com. I am going to work on some kind of proposal soonish. |
| 23:13.03 | Qwell | There *have* been issues found in them that weren't in the previous release. |
| 23:13.10 | Qwell | if we would have just released, that bug would have been there. |
| 23:13.15 | russellb | Qwell: yup |
| 23:13.31 | Qwell | also.. |
| 23:13.36 | paravoid | my point was, you can think of rc1s as .0s |
| 23:13.38 | Qwell | it lets people get "early access" to fixes |
| 23:13.42 | paravoid | so you have 1.6.1.5.0 |
| 23:13.51 | paravoid | that's one digit too many, IMO. |
| 23:13.52 | russellb | yeah, but it's all about managing expectations |
| 23:13.52 | Qwell | no. baby jesus would cry if we used 5. |
| 23:14.02 | paravoid | right |
| 23:14.12 | russellb | "rc1" sets a different expectation than a release number without a qualifier. |
| 23:14.14 | murdock_ut | I run the RC's at home and if they pass they get moved to work. :) |
| 23:14.33 | murdock_ut | I'm not sure how my wife feels about that though. |
| 23:14.35 | paravoid | so, release 1.6.1-rc1/rc2/rc3/.0 and then 1.6.2-rc1/rc2/rc3 |
| 23:14.46 | paravoid | i.e. get rid of one depth of branches |
| 23:15.10 | murdock_ut | I like the current versioning. |
| 23:15.15 | russellb | murdock_ut: I'm sure you know _very_ well how she feels when you break the phone :-) |
| 23:15.17 | paravoid | in comparison, Linux has 2.6.N, occassionaly (i.e. 2-3 releases) 2.6.N.M |
| 23:15.28 | paravoid | and that's about it |
| 23:15.41 | russellb | nods |
| 23:15.50 | paravoid | there's also a semi-maintained 2.4 which is roughly equivalent to asterisk 1.2 |
| 23:23.52 | Corydon76-dig | Are you saying 1.4 is the bastard child of nothingness? |
| 23:35.24 | *** join/#asterisk-dev mvanbaak_ (n=michiel@asterisk/contributor-and-bug-marshal/mvanbaak) |
| 23:35.25 | *** mode/#asterisk-dev [+o mvanbaak_] by ChanServ |