| 01:10.40 | *** part/#asterisk-dev mjordan (~mjordan@nat/digium/x-yughepvzswxheddq) |
| 01:39.48 | pabelanger | bye digium |
| 01:40.43 | pabelanger | So, I'm trying to track down an issue with ast_random() creating tab (\t) chars. Is that possible? |
| 01:40.57 | pabelanger | check out this: WWW-Authenticate: Digest algorithm=MD5, realm="asterisk", nonce="4f18baa6 " |
| 01:41.11 | pabelanger | the space in nonce is actual a tab |
| 02:15.39 | *** join/#asterisk-dev sruffell (~Adium@asterisk/the-kernel-guy/sruffell) |
| 02:15.39 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 02:16.00 | snuff-work | mm interesting |
| 02:23.14 | pabelanger | Ya, I'm not sure it is ast_random() but that is the only real change I can see from 1.4 to 1.8. It now uses /dev/urandom |
| 02:23.22 | snuff-work | nonce=\"%08lx\" |
| 02:23.49 | snuff-work | seems to imply that it can only return hex |
| 02:24.48 | pabelanger | indeed |
| 02:24.59 | pabelanger | the only other thing it maybe is: snprintf(tmp, sizeof(tmp), "Digest algorithm=MD5, realm=\"%s\", nonce=\"%s\"%s", p->realm, randdata, stale ? ", stale=true" : ""); |
| 02:25.09 | pabelanger | and some how stale contains it |
| 02:26.04 | WIMPy | That's to the wrong side of the ". |
| 02:26.31 | pabelanger | how so? |
| 02:26.59 | pabelanger | nevermind |
| 02:27.03 | pabelanger | brain is fried |
| 02:27.05 | WIMPy | The tab is between the 8 hex digits and the ". |
| 02:27.16 | WIMPy | So it has to be in randdata. |
| 02:27.39 | WIMPy | knows that issue. |
| 02:29.11 | pabelanger | which comes from the sip_pvt structure |
| 02:29.57 | WIMPy | thinks of a type/alignment issue. |
| 02:32.08 | WIMPy | The ARM can't do misaligned word (or if available half word) access. |
| 02:32.43 | pabelanger | Not sure, out of my scope of knowledge |
| 02:34.56 | WIMPy | They really should cause aborts, but I think they are usually disabled, wich seems like a very bad idea. |
| 02:38.27 | tzafrir_laptop | Was srtp and video support available in 1.6.2? Available but broken? |
| 02:38.59 | tzafrir_laptop | WIMPy, rather: IIRC it can, but there's a performance penalty |
| 02:40.44 | snuff-work | i know sparc can't do unaligned.. goes *barf* |
| 02:41.46 | *** join/#asterisk-dev WIMPy (~wimpy@e183095026.adsl.alicedsl.de) |
| 02:42.27 | WIMPy | I'm not that familar with the new ones, but the ones I know can't. |
| 02:42.28 | pabelanger | tzafrir_laptop: SRTP is 1.8+ |
| 02:42.36 | WIMPy | Or at least the result is not what you'd expect. |
| 02:44.43 | WIMPy | just reads about compilers doing less smart things. |
| 02:49.10 | pabelanger | going to pass on that, learning how compilers work is low on the list of things to learn |
| 02:49.17 | pabelanger | thanks for your help however |
| 02:49.23 | pabelanger | learned something new |
| 02:49.42 | WIMPy | Looks like ARMv6 and above can do misaligned access. |
| 02:50.13 | WIMPy | The more interesting thing may be that compilers seem to align chars to word boundaries. |
| 02:51.18 | WIMPy | For a for loop operating on chars would actually (1) operate on one char, then on 3 unused bytes (goto 1). |
| 03:12.16 | *** join/#asterisk-dev bklang (~bklang@tesla.alkaloid.net) |
| 03:25.33 | *** join/#asterisk-dev otherwiseguy (~otherwise@75.76.71.96) |
| 03:59.02 | *** join/#asterisk-dev sruffell (~Adium@asterisk/the-kernel-guy/sruffell) |
| 03:59.02 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 04:34.38 | *** join/#asterisk-dev sruffell (~Adium@asterisk/the-kernel-guy/sruffell) |
| 04:34.38 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 07:42.00 | *** join/#asterisk-dev schmidts (~schmidts@Lo20-rt01.lm33.sil.at) |
| 07:42.24 | schmidts | good morning |
| 07:59.28 | wdoekes2 | indeed WIMPy, I've experienced "wrong" results without sigbus on arm too. better have it sigbus like the sparc so you know it's broken |
| 07:59.49 | *** join/#asterisk-dev Tim_Toady (~fuzzy@188.4.71.108.dsl.dyn.forthnet.gr) |
| 08:27.14 | schmidts | is someone very familiar with doxygen? |
| 08:33.45 | schmidts | s/someone/anyone |
| 08:33.47 | schmidts | ;) |
| 08:34.08 | schmidts | the problem is, the channels/sip/reqresp_parser.c and also .h file isnt included in doxygen |
| 09:11.25 | wdoekes2 | schmidts: ./contrib/asterisk-ng-doxygen RECURSIVE = NO, INPUT = ... doesn't list them |
| 09:14.04 | schmidts | ok so adding channels/sip \ to this file should bring it in then? |
| 09:14.18 | schmidts | its not only about my local doxygen its also not in the official asterisk doxygen |
| 09:15.26 | wdoekes2 | I would think so. although I don't know how often the offical docs are regenerated (nor do I even know where to find them) |
| 09:17.28 | schmidts | doxygen trunk files for example for chan_sip.c was last build on Thu Jan 19 06:35:02 2012 |
| 09:51.29 | *** join/#asterisk-dev black187 (~black187@93-103-22-42.static.t-2.net) |
| 09:53.40 | *** join/#asterisk-dev hehol (~hehol@2001:1438:1009:200:84ac:b918:ac6c:39a3) |
| 10:17.21 | *** join/#asterisk-dev ccesario (~ccesario@187.17.166.162) |
| 10:31.42 | *** join/#asterisk-dev tzafrir_laptop (~tzafrir@212.179.75.202) |
| 10:31.42 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 11:16.45 | tzafrir_laptop | Any reason why issue ASTERISK-19202 shouldn't be public? I don't see anything confidential there at first glance. |
| 11:16.54 | tzafrir_laptop | (And now the issue was disclosed) |
| 11:33.52 | schmidts | tzafrir_laptop IMHO this was an digium internal security fix thing, look here: downloads.asterisk.org/pub/security/AST-2012-001.pdf |
| 11:35.04 | tzafrir_laptop | schmidts, I read it before writing the above. I don't see anything there woth hiding anymore. |
| 11:35.21 | tzafrir_laptop | It was probably made private as it is a security issue |
| 11:35.48 | tzafrir_laptop | Which is generally a good idea for unpublished security issues |
| 11:37.49 | schmidts | i am with you, but i dont know how to this is normally handled when a security issue is allready resolved |
| 11:38.18 | schmidts | imho it would be a good idea to let this bug stay private, cause many people will not update so soon. |
| 11:39.08 | wdoekes2 | tzafrir_laptop: the debug files/comments do make it easier for script kiddies. but I don't have an opinion here |
| 11:40.12 | tzafrir_laptop | wdoekes2, right. But the patches are already there. What more do you need? |
| 11:42.06 | wdoekes2 | underlines "easier" and "don't" |
| 11:43.20 | tzafrir_laptop | There's a bug report in Debian asking me to export 'UMASK' in the init.d script running safe_asterisk |
| 11:43.55 | tzafrir_laptop | I wonder if adding this variable to the environment of Asterisk should have any grave ill-effect |
| 11:45.26 | wdoekes2 | what is it supposed to fix? |
| 11:47.26 | wdoekes2 | oh.. the script that calls safe_asterisk, ah |
| 11:48.56 | wdoekes2 | I think there will be no side-effects, but couldn't you do umask from the init script instead? |
| 11:49.53 | *** join/#asterisk-dev merbanan (~benjamin@c-94-255-221-48.cust.bredband2.com) |
| 12:24.49 | schmidts | would it be ok to just change the doxygen settings or should i make a review for this? |
| 12:25.00 | schmidts | i have tested it with adding the channel/sip folder and it works |
| 12:33.16 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 12:33.16 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 12:56.32 | wdoekes2 | I think you can safely commit it |
| 12:58.03 | schmidts | wdoekes2 ok thx |
| 13:09.52 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-xvyrqcgdxorqnglf) |
| 13:09.52 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 13:16.17 | *** join/#asterisk-dev bklang (~bklang@2001:470:8:5de:225:ff:fe49:f8cd) |
| 13:42.21 | *** join/#asterisk-dev ccesario (~ccesario@187.17.166.162) |
| 13:53.01 | *** join/#asterisk-dev tamiel (~tamiel@85-171-171-179.rev.numericable.fr) |
| 14:04.15 | *** join/#asterisk-dev serafie (~erin@nat/digium/x-ehjmawtrhngbjwoe) |
| 14:16.29 | tzafrir_laptop | Any CVE for the new asterisk security issue? |
| 14:17.09 | kpfleming | it has been requested, but not delivered yet |
| 14:17.16 | kpfleming | the advisory will be updated once we have it |
| 14:26.22 | leifmadsen | usually takes a few days |
| 14:30.09 | kpfleming | apparently there is *one* person that issues CVEs. hope he's not on holiday. |
| 14:34.35 | file | I just received it, it'll be updated when I get into the office |
| 14:35.19 | seanbright | so i'm running a test with pjsip and asterisk, and pjsip is reporting that the rtcp address is changing frequently (every 5 seconds or so) |
| 14:35.25 | seanbright | is that just a function of how rtcp works? |
| 14:37.26 | seanbright | actually it syncs with the value set for rtcpinterval, so i guess it's by design |
| 14:37.37 | seanbright | i just don't understand why it jumps around |
| 14:40.55 | kpfleming | not sure what the 'rtcp address' is, but it shouldn't be changing |
| 14:41.59 | seanbright | you make me feel dumb |
| 14:42.00 | seanbright | heh |
| 14:42.57 | kpfleming | not intentionally |
| 14:43.57 | seanbright | kpfleming: http://pastebin.com/raw.php?i=GagHLuRJ |
| 14:44.08 | seanbright | as an example |
| 14:45.54 | kpfleming | that's pretty bizarre... the port number appears to be changing |
| 14:46.00 | kpfleming | it should not be doing that |
| 14:46.24 | kpfleming | can you grab a packet capture and see whether this is real or a reporting problem in pjsip (you are using pjsua, i assume)? |
| 14:46.33 | seanbright | i am, yes. |
| 14:46.36 | seanbright | will do |
| 14:46.37 | file | I lied, CVE now added to advisory |
| 14:47.18 | file | that's very weird... it's like two senders of RTCP are just sending to the same port |
| 14:47.26 | kpfleming | runs away |
| 14:47.31 | seanbright | damn |
| 14:47.49 | seanbright | i'll send the packet capture to you house |
| 14:47.58 | seanbright | USPS |
| 14:51.12 | *** join/#asterisk-dev leifmadsen (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 14:51.12 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 14:51.15 | *** join/#asterisk-dev newbe (~Newb@c-98-226-119-225.hsd1.il.comcast.net) |
| 14:53.42 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 14:53.42 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 14:56.01 | seanbright | how do you give ngrep a port range? |
| 14:56.05 | seanbright | any idea? |
| 14:57.13 | putnopvut | Nope. I've only ever given a single port. |
| 14:57.37 | putnopvut | I wonder if it accepts wildcards or ranges, like "port 100[1-3]" ? |
| 14:57.52 | seanbright | doesn't support ranges... tried that already |
| 14:58.05 | putnopvut | I figured you might've. Worth mentioning though :) |
| 14:58.14 | WIMPy | `seq` ;) |
| 14:59.17 | seanbright | yikes |
| 14:59.28 | seanbright | might be too long of a command line |
| 14:59.30 | seanbright | but i'll try it |
| 15:01.01 | seanbright | tcpdump takes a port range |
| 15:05.39 | *** join/#asterisk-dev malcolmd (~malcolmd@pdpc/sponsor/digium/malcolmd) |
| 15:05.39 | *** mode/#asterisk-dev [+o malcolmd] by ChanServ |
| 15:05.56 | *** join/#asterisk-dev moy (~moy@173.239.155.74) |
| 15:07.53 | leifmadsen | seanbright: I tend to use tshark now |
| 15:13.53 | seanbright | nice. will give it a shot. |
| 15:38.57 | seanbright | i think i know what was happening |
| 15:39.15 | *** join/#asterisk-dev sruffell (~Adium@asterisk/the-kernel-guy/sruffell) |
| 15:39.16 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 15:39.24 | seanbright | i was ^Cing my app instead of quitting gracefully |
| 15:39.46 | seanbright | so asterisk was still sending RTCP from older calls to me when i re-launched |
| 15:39.51 | seanbright | that is my theory anyway |
| 15:41.51 | putnopvut | ugh, post-review is choking on me. It seems to think reviewboard is sending a bad HTTP response, apparently. |
| 15:43.21 | mjordan | putnopvut: it does that sometimes. Just smack it a few times. |
| 15:43.29 | putnopvut | heh, trying that now |
| 15:53.28 | *** join/#asterisk-dev bklang (~bklang@c-66-56-12-125.hsd1.ga.comcast.net) |
| 15:58.04 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 15:58.04 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 15:59.30 | file | seanbright, naughty |
| 16:11.58 | *** join/#asterisk-dev otherwiseguy (~otherwise@nat/digium/x-benlffzepkhdwpzf) |
| 16:13.50 | kpfleming | Corydon76-home: can you test whether the libasteriskssl stuff builds properly on OSX if you pull from my branch? |
| 16:15.16 | kpfleming | mjordan: small problem with adding the iLBC code into the tree... anyone with an svn checkout that they've already pulled the iLBC code into will get errors when they attempt to 'svn update' as I just did |
| 16:15.26 | kpfleming | not much that can be done about it, other than being aware of it |
| 16:19.06 | Corydon76-home | Does a 'make distclean' get rid of the downloaded code? |
| 16:19.15 | Corydon76-home | It probably should, if it doesn't |
| 16:19.19 | kpfleming | i did not try |
| 16:20.55 | mjordan | Corydon76-home: doesn't appear to affect the code in codecs/ilbc - which, since we've now added the code to svn, is probably not a terrible thing (although it doesn't resolve the problem either) |
| 16:21.11 | mjordan | is it worth sending a note out to asterisk-dev? |
| 16:21.19 | kpfleming | yep |
| 16:22.06 | Corydon76-home | Just a future thought... in the tarball, if you 'make distclean', we might could have a list of files to check against, and spit out a warning of 'Hey, these files aren't mine, you might want to delete them' |
| 16:23.21 | Corydon76-home | Or some other similar note, like we do for modules in the installed path on the 'install' target |
| 16:25.03 | Corydon76-home | kpfleming: still a link error on OS X: ld: in /usr/local/lib/libasteriskssl.so, can't link with a main executable for architecture x86_64 |
| 16:26.05 | kpfleming | that's the whole error? |
| 16:26.23 | Corydon76-home | Yes |
| 16:26.45 | Corydon76-home | That occurs on the final link step (after I removed the problems from the original error) |
| 16:26.46 | kpfleming | i have no idea what that means |
| 16:27.03 | kpfleming | we're just linking a binary to a shared library |
| 16:27.08 | Corydon76-home | Basically, the way the library was linked was the wrong way |
| 16:27.16 | kpfleming | for OSX :-) |
| 16:27.27 | Corydon76-home | It's not a shared library on OS X |
| 16:27.35 | kpfleming | oh... i think i know why |
| 16:27.41 | Corydon76-home | /usr/local/lib/libasteriskssl.so: Mach-O 64-bit executable x86_64 vs /opt/local/lib/libpostproc.dylib: Mach-O 64-bit dynamically linked shared library x86_64 |
| 16:27.58 | kpfleming | the Makefile rules for producing .so files in the asterisk tree don't produce shared objects, they produce loadable objects |
| 16:28.02 | kpfleming | on OSX, those are different |
| 16:28.06 | kpfleming | on Linux, they are not |
| 16:28.10 | Corydon76-home | Ah, okay |
| 16:28.37 | kpfleming | so that's why i posted the note... on OSX, the Makefile for doing this will need to be quite a bit different (produce a .dylib instead of a .so) |
| 16:29.12 | *** join/#asterisk-dev leifmadsen (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 16:29.12 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 16:29.39 | Corydon76-home | and yet another type: /Library/Application Support/Asterisk/Modules/chan_iax2.so: Mach-O 64-bit bundle x86_64 |
| 16:29.46 | kpfleming | right |
| 16:30.42 | Corydon76-home | What I did to get past the compile error was to remove the useless redirects in libasteriskssl.c |
| 16:31.20 | Corydon76-home | Since I can't get it to link, no idea if that's valid, but I suspect it is |
| 16:41.02 | kpfleming | there aren't any 'useless' redirects. i added all the ones that are necessary, and nothing more. |
| 16:42.36 | Corydon76-home | The defines that do nothing but pull up their own curtain and reference the function behind them aren't 'useless'? |
| 16:42.52 | kpfleming | i fail to understand your question |
| 16:43.41 | Corydon76-home | You have a define for TLSv1_client_method, which does nothing but to reference the function hidden by libasteriskssl.so |
| 16:43.53 | kpfleming | that is correct. it has a purpose. |
| 16:43.57 | Corydon76-home | If you simply don't define that method, what happens? |
| 16:44.23 | kpfleming | then linking the main asterisk binary fails, because it can't find that symbol, as the main asterisk binary is no longer directly linked against libssl |
| 16:44.31 | Corydon76-home | Ah |
| 16:44.49 | kpfleming | and we can't have the main library linked against libssl or libcrypto, or this method will be defeated |
| 16:44.58 | kpfleming | s/library/binary/ |
| 16:45.09 | Corydon76-home | Is the issue that on Linux, you can't define the search order? |
| 16:45.31 | Corydon76-home | On OS X, the command line imposes the direct search order for the symbols |
| 16:45.58 | kpfleming | i don't know what you mean |
| 16:46.24 | Corydon76-home | So symbols are always searched from the first library specified on the command line, to the last |
| 16:46.28 | kpfleming | ahh |
| 16:46.32 | Corydon76-home | in the link command |
| 16:46.50 | kpfleming | to be honest, i did not investigate that specifically, i did this because it was clearly safer than relying on such behavior on all platforms |
| 16:47.13 | kpfleming | if the dynamic linker loaded libssl before libasteriskssl at runtime, then the whole thing falls down |
| 16:47.22 | Corydon76-home | I'd be surprised if that behavior was not required by POSIX |
| 16:47.37 | Corydon76-home | and since we already require POSIX compliance... |
| 16:47.42 | kpfleming | if so, and you can provide a suitable reference, then that would simplify things somewhat |
| 16:47.53 | Qwell | I'd be surprised if that silly OS from Cupertino followed POSIX. :p |
| 16:47.53 | kpfleming | we could go back to only overriding the init and shutdown functions |
| 16:48.52 | Corydon76-home | Aha. It's required by C89. |
| 16:48.54 | kpfleming | i also considered doing this via LD_PRELOAD, but i was not thrilled with requiring everyone to change the way that they start asterisk |
| 16:49.53 | Corydon76-home | http://pubs.opengroup.org/onlinepubs/7908799/xcu/c89.html |
| 16:50.32 | Corydon76-home | "The -l library operands have the format of options, but their position within a list of operands affects the order in which libraries are searched." |
| 16:50.46 | kpfleming | for the static linker, yes |
| 16:50.55 | kpfleming | not necessarily for the dynamic linker |
| 16:53.03 | Corydon76-home | Given that it's defined behavior for the C standard, seems realistic to assume the same behavior for static or dynamic linking |
| 16:54.36 | Corydon76-home | gcc specifies the same behavior. |
| 16:54.45 | Corydon76-home | and we also require GCC. |
| 16:54.51 | kpfleming | i am not comfortable relying on assumptions here. the symptoms of the problem this patch is trying to solve are extremely subtle and hard to debug. if we put the patch in place, it better work, all the time, period. |
| 16:55.05 | kpfleming | this is not part of the compiler. what the compiler specifies is not relevant. |
| 16:55.16 | Corydon76-home | http://gcc.gnu.org/onlinedocs/gcc/Link-Options.html |
| 16:56.16 | kpfleming | the GCC docs do not specify the behavior of the run time linker |
| 16:56.25 | Corydon76-home | I understand, but POSIX makes no distinction between static and dynamic linking, therefore they should behave the same |
| 16:56.47 | Corydon76-home | It's just "linking" as far as POSIX is concerned |
| 16:57.02 | kpfleming | that POSIX page you referenced is not relevant, in my opinion. it specifies the behavior of compile-time linking. nothing can be extrapolated from that. |
| 16:58.00 | Corydon76-home | Approach it from a system implementors perspective. |
| 16:58.46 | kpfleming | yes, i understand that what you are saying is a logical assumption to make. i'm just not comfortable relying on assumptions for this situation. |
| 16:58.57 | Corydon76-home | How does POSIX allow different compile time and runtime link order behavior? |
| 16:59.29 | kpfleming | i have no idea. if it does not define the behavior, then by specification the behavior is implementation-specific. just like most standards. |
| 17:00.02 | kpfleming | it doesn't have to specifically allow the behavior to be different. failing to mandate that the behavior must be the same allows it to differ. |
| 17:01.07 | kpfleming | if this is really that big of a concern, i can ask some people that i've worked with in the past for pointers to standards/docs/etc. that might shed light on this. |
| 17:02.02 | Corydon76-home | I think this is a reasonable assumption to make that does not merit the additional complexity |
| 17:02.41 | Corydon76-home | We're not the first project to have negotiated the issue of duplicate symbols in a binary |
| 17:03.06 | kpfleming | then i can look into it. it won't be done quickly though. |
| 17:03.10 | Corydon76-home | Well, in the namespace of a binary |
| 17:25.59 | Corydon76-home | kpfleming: there's an additional problem with the current logic. You're also assuming that symbols in libasteriskssl.so will be found before symbols in the linked libssl.so. Can you similarly find a standard which suggests that this must be so? |
| 17:26.47 | Corydon76-home | We're already depending upon ordering for that mask to work correctly. |
| 17:27.47 | Corydon76-home | If a runtime linker was free to ignore compile-time link symbol resolution order, then it's also free to ignore dependency ordering. |
| 17:29.09 | Corydon76-home | So with such a linker, there's no guarantee that the current solution would function correctly, either. |
| 17:32.14 | Corydon76-home | It's logical to assume that when you load a library it won't pollute (or override) the current namespace. But there's no requirement that it won't. |
| 17:46.27 | Corydon76-home | Actually, there is a requirement that it won't override the current namespace. |
| 17:46.51 | Corydon76-home | But the current plan still requires the assumption that you're refusing to make. |
| 17:48.00 | Corydon76-home | BTW, without those symbols in libasteriskssl.dylib, it still links fine on Mac OS X, because the linker sees the dependent symbols from libssl in the link to libasteriskssl |
| 18:44.36 | kpfleming | sorry, just got back from lunch |
| 18:45.04 | kpfleming | the symbols in libasteriskssl.so *will* be found before the symbols from libssl.so, because the former library will always be loaded into the process before the latter |
| 18:45.22 | kpfleming | and once a symbol is resolved, it is resolved for the lifetime of that process (the one definition rule applies here) |
| 18:54.48 | kpfleming | tzafrir_laptop: ping |
| 19:08.15 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 19:11.07 | tzafrir_laptop | kpfleming, pong |
| 19:19.31 | kpfleming | tzafrir_laptop: so i agree that having an unversioned library in /usr/lib is not ideal. do you know of any other place we can put a shared library so that the dynamic linker can find it, without having to mess with LD_LIBRARY_PATH or install a magic file in /etc/ld.so.<foo>? |
| 19:25.27 | seanbright | if you set LD_LIBRARY_PATH after the process is loaded (putenv()) does that have any affect? or is it too late at that point? |
| 19:26.09 | tzafrir_laptop | without playing with LD_LIBRARY_PATH? no |
| 19:26.20 | kpfleming | it's too late, the binary won't get run if it can't find libasterikssl.so |
| 19:26.35 | kpfleming | tzafrir_laptop: ok, so then we need some basic versioning on the library, i suppose |
| 19:26.42 | tzafrir_laptop | You can add your own path on ld.so.conf.d/*, but that would be cheating |
| 19:26.58 | kpfleming | right |
| 19:27.05 | kpfleming | and outside of linux, it could be much harder |
| 19:27.30 | Corydon76-home | Alternatively, you could just set the version of the library to 1, knowing it will never be incremented |
| 19:27.58 | tzafrir_laptop | (0 is the base number) |
| 19:28.10 | Corydon76-home | Not on all platforms |
| 19:28.58 | Corydon76-home | Specifically, on Mac, 0 means the library is unversioned |
| 19:34.30 | kpfleming | Corydon76-home: i've sent off a detailed question to the binutils mailing list... we'll see what the experts have to say |
| 19:35.59 | kpfleming | i would be fine with just giving it a simple version number like we do for libpri, libss7, etc. |
| 20:23.22 | seanbright | is there any benefit to making the ilbc code an svn:external? |
| 20:23.46 | seanbright | looks like it's code that won't change often, and when it does it would affect all branches. |
| 20:23.48 | Corydon76-home | Not unless it's included in more than one place |
| 20:24.09 | seanbright | k |
| 21:43.47 | kpfleming | would really like to rip all mingw32 and cygwin related stuff out of the asterisk build system... it doesn't work, and nobody cares |
| 21:44.14 | jsmith | kpfleming: You've got my vote, for what little it counts :-) |
| 21:44.45 | mjordan | kpfleming: that's not technically true. There is at least one person who cares. |
| 21:45.14 | kpfleming | is that person in your pocket? |
| 21:45.18 | mjordan | I give you: ASTERISK-18105 |
| 21:45.25 | kpfleming | i refuse to accept it |
| 21:45.41 | mjordan | so did I |
| 21:45.46 | kpfleming | so i will rephrase: "an insufficient number of people care" |
| 21:50.26 | leifmadsen | kpfleming: +1 from me -- that guy cares enough to report issues, but is not of technical ability to do anything about it, which in and of itself isn't a reason to rip out that stuff, but when he is the ONLY one, then yes, I suggest it should be just removed. |
| 21:50.59 | leifmadsen | plus then multiple cygwin related issues could be closed :) |
| 21:51.12 | pabelanger | Q: if dnsmgr is disabled, should ast_dnsmgr_lookup() still be polling? My guess is yes, but I suspect we simply return 0 sooner if it is disabled |
| 21:52.32 | kpfleming | pabelanger: define 'polling' |
| 21:53.43 | pabelanger | well, on the console I see "doing dnsmgr_lookup for 'blah'" every few seconds. But dnsmgr is disabled. Looking at the code, I can see some logic to exit when dnsmgr is disabled, but I would have expected it to be close to the top of the function then bottem |
| 21:53.54 | tzanger | head asplode |
| 21:54.04 | tzanger | writing a driver for a new e1 framer |
| 21:54.54 | tzanger | the HDLC controller config allows you to select even and/or odd frames of the rx datastream |
| 21:55.00 | tzanger | ... don't you want all the frames? |
| 21:55.00 | kpfleming | pabelanger: even if dnsmgr is disabled, chan_sip still uses it for doing DNS queries. |
| 21:55.13 | kpfleming | it just won't update the results of those queries in the background. |
| 21:56.13 | pabelanger | Okay, I guess I misunderstood dnsmgr purpose then. |
| 21:56.21 | kpfleming | so dnsmgr can never be fully disabled, just its background update mode can be disabled |
| 21:56.35 | pabelanger | ack'd |
| 21:56.57 | *** part/#asterisk-dev mjordan (~mjordan@nat/digium/x-xvyrqcgdxorqnglf) |
| 21:57.51 | tzanger | e1 is so... weird |
| 21:58.25 | pabelanger | FWIW: I also +1 the removal of win32 support |
| 22:25.21 | tzafrir_laptop | Well, if someone actively works on that, why not break it? |
| 22:26.01 | leifmadsen | tzafrir_laptop: you mean the win32 stuff? |
| 22:26.05 | tzafrir_laptop | yes |
| 22:26.12 | leifmadsen | no one is actively working on it |
| 22:26.35 | tzafrir_laptop | I figure that the actual requirement is someone to actively test it |
| 22:27.02 | kpfleming | we have one person interested in it, he has proven that it is broken, and he does not have the skills to fix it |
| 22:59.54 | kpfleming | Corydon76-home: it looks like the ABI docs for the way things behave on Unix-like platforms do indeed dictate that if the main asterisk binary was linked against both libasteriskssl and libssl, in that order, that the symbols from libasteriskssl would take precedence. this is good. |