| 00:00.03 | Corydon76-lap | russellb: because it saves disk space |
| 00:00.06 | paravoid | security vulnerabilities are unlikely? :) |
| 00:00.17 | russellb | easier updates ... saves disk space ... saves memory |
| 00:00.21 | russellb | a number of things |
| 00:00.24 | Corydon76-lap | russellb: and saves memory, if the same library is loaded in more than one process |
| 00:00.28 | russellb | right. |
| 00:00.37 | Corydon76-lap | but both of those reasons are optimizations |
| 00:01.07 | russellb | except for the security case, which for a network access library (which has some terrible code, by the way), is important to consider |
| 00:01.18 | Corydon76-lap | Remember, I'm not arguing against application, only against application in a branch that gets bugfixes only |
| 00:01.19 | paravoid | fwiw, we had a DSA fixing an arbitrary code execution vulnerability in uw-imap 2 years ago |
| 00:02.12 | russellb | but sometimes the rule has to take into account reasonable expectation for obvious functionality ... |
| 00:02.16 | Corydon76-lap | paravoid: so you're arguing we're about due for another security vulnerability in uw-imap? |
| 00:02.25 | paravoid | russellb: truth be told, I haven't looked how trunk fixes the problem, so my diff is not exactly a backport |
| 00:02.26 | tzafrir | in trunk the default is still the same, but you have --with-imap=system |
| 00:02.27 | russellb | making c-client linking just like every other library is a reasonable expectation |
| 00:02.39 | tzafrir | which is why this patch won't apply |
| 00:02.49 | paravoid | Corydon76-lap: I'm arguing that security vulnerabilities are possible and you should do your best to avoid them in all branches. |
| 00:03.05 | Corydon76-lap | russellb: it's your decision, and you have my opinion. |
| 00:03.25 | paravoid | the other points about dynamic linking stand but with a lower priority imho |
| 00:03.34 | Corydon76-lap | paravoid: we link other libraries into Asterisk statically |
| 00:03.38 | paravoid | security and data corruption bugs seem the most important to me |
| 00:03.40 | paravoid | such as? |
| 00:03.44 | Corydon76-lap | libmmime and libeditline |
| 00:04.24 | paravoid | why? |
| 00:04.35 | russellb | paravoid: those are ones included in the tree |
| 00:04.43 | russellb | anyway, i'm off ... |
| 00:05.00 | Corydon76-lap | So if you're going to argue imap, you need to argue those two, as well |
| 00:05.06 | tzafrir | wow, there's actually a user for libeditline: firebird2.0 |
| 00:05.21 | paravoid | Corydon76-lap: I can happily do that |
| 00:05.27 | paravoid | static linking is Bad(tm) |
| 00:05.37 | Corydon76-lap | I disagree |
| 00:05.51 | Corydon76-lap | I think static linking is useful in limited circumstances |
| 00:06.15 | paravoid | ok, I can agree to that, embedded comes to mind |
| 00:06.19 | Corydon76-lap | while I wouldn't suggest linking everything statically, it has its place in certain areas |
| 00:06.36 | paravoid | c-client doesn't seem to have this place though |
| 00:06.36 | tzafrir | static linking of libeditline is useful, because non-debian users probably don't have it installed |
| 00:06.50 | Corydon76-lap | So if you want to submit patches for trunk, knock yourself out |
| 00:07.03 | paravoid | Corydon76-lap: we're going in circles... |
| 00:07.16 | paravoid | I'm not going to argue again why I think this is important for 1.4 |
| 00:07.18 | Corydon76-lap | tzafrir: and actually, I've modified it within Asterisk to be threadsafe |
| 00:08.05 | paravoid | and tbh, I don't care that much |
| 00:08.05 | Corydon76-lap | paravoid: it's ultimately neither your decision nor my decision |
| 00:08.05 | paravoid | I've patched it for us |
| 00:08.15 | paravoid | and I didn't have a choice, since c-client in Debian doesn't provide the .a |
| 00:08.35 | paravoid | for the reasons I mentioned above |
| 00:08.49 | Corydon76-lap | btw, you might want to check the patches against unixodbc on Debian. At least for Ubuntu, unixodbc from the packages is horrendously unstable |
| 00:08.52 | paravoid | our users and our security and stable teams have been bitten before by embedded libraries in programs |
| 00:09.04 | paravoid | could you file a bug report? |
| 00:09.12 | paravoid | I'm not very familiar with unixodbc |
| 00:09.26 | paravoid | I presume that its maintainers are and you'll have better luck :) |
| 00:09.28 | Corydon76-lap | paravoid: yeah, I'm going to file a bug about Ubuntu against Debian... riiiiiiiiiight |
| 00:09.44 | paravoid | file it against Ubuntu in launchpad |
| 00:09.50 | tzafrir | do you have an ubuntu bug report? |
| 00:09.53 | paravoid | it should propagate |
| 00:10.04 | paravoid | esp. since the unixodbc Debian maintainer is an Ubuntu release manager |
| 00:10.10 | Corydon76-lap | Ah |
| 00:10.13 | paravoid | (and a Debian release wizard for that matter :) |
| 00:10.22 | Corydon76-lap | At some point, I might. |
| 00:10.37 | paravoid | he's *very* responsive |
| 00:10.47 | paravoid | one of the most respected developers out there |
| 00:10.52 | paravoid | tzafrir: vorlon :) |
| 00:11.00 | tzafrir | yeah, I figured |
| 00:11.01 | Corydon76-lap | Manoj? |
| 00:11.09 | paravoid | lol, no |
| 00:11.30 | Corydon76-lap | He lives in this area... |
| 00:11.46 | tzafrir | Steve Langasek |
| 00:11.59 | paravoid | btw, about your libeditline patches |
| 00:12.05 | paravoid | did you try moving them upstream? |
| 00:12.09 | Corydon76-lap | I won't remember that, but if you remind me tomorrow |
| 00:12.14 | Corydon76-lap | paravoid: nope |
| 00:12.17 | jpeeler | Corydon76-lap: i'm about to commit to trunk, do i need add any properties to the files? |
| 00:12.30 | paravoid | would love to dynamically link against it but if asterisk is using a fork that's going to be difficult |
| 00:12.35 | Corydon76-lap | jpeeler: yes; I'll come over |
| 00:12.45 | tzafrir | jpeeler, if you don't add those properties, your commit is rejected |
| 00:12.59 | Qwell | <3 pre-commit |
| 00:14.06 | tzafrir | long ago I tried, but this was 1.2 |
| 00:14.14 | tzafrir | ah, sorry |
| 00:14.34 | tzafrir | libeditline (as opposed to libedit) is actively maintianed? |
| 00:27.36 | paravoid | Corydon76-lap: btw, vorlon is online now if you'd like to discuss it with him |
| 00:27.43 | paravoid | even though he'll probably refer you to one of the BTSes |
| 00:43.27 | Corydon76-lap | paravoid: maybe tomorrow, I'm 15 minutes away from teaching a class |
| 00:43.44 | paravoid | np |
| 01:04.53 | *** join/#asterisk-dev outtolunc (n=me@c-67-174-216-60.hsd1.ca.comcast.net) |
| 01:47.03 | *** join/#asterisk-dev tzafrir_laptop (n=tzafrir@62.90.10.53) |
| 01:47.03 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 02:07.36 | *** join/#asterisk-dev tzafrir_laptop (n=tzafrir@62.90.10.53) |
| 02:07.36 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 02:15.07 | *** join/#asterisk-dev tzafrir_laptop (n=tzafrir@62.90.10.53) |
| 02:15.07 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 02:59.25 | *** join/#asterisk-dev ZaVoid (n=zavoid@c-67-165-25-195.hsd1.pa.comcast.net) |
| 02:59.27 | ZaVoid | morning |
| 03:03.13 | *** join/#asterisk-dev mtaht4 (n=m@190.212.11.64) |
| 03:03.42 | *** part/#asterisk-dev mtaht4 (n=m@190.212.11.64) |
| 03:22.20 | *** join/#asterisk-dev puzzled (n=patrick@puzzled.xs4all.nl) |
| 03:56.45 | ZaVoid | hey russel you around? |
| 04:20.50 | *** join/#asterisk-dev g0mb0 (n=root@external.micom.mng.net) |
| 04:36.19 | g0mb0 | can somebody tell me whether my patches are correct or not? |
| 04:36.31 | g0mb0 | http://lists.digium.com/pipermail/asterisk-dev/attachments/20080212/7ec8a960/attachment.obj |
| 04:36.39 | g0mb0 | http://lists.digium.com/pipermail/asterisk-dev/attachments/20080212/7ec8a960/attachment-0001.obj |
| 04:54.10 | paravoid | hm, David Miller just posted a patch on netdev that removes the CAP_NET_ADMIN limitation for all the values of ToS/DSCP |
| 04:54.35 | paravoid | which probably means that Asterisk should not retain that capability on such kernels since there's no reason to |
| 04:55.48 | paravoid | tricky |
| 06:31.16 | *** join/#asterisk-dev oej (n=olle@soll4-125.cust.blixtvik.net) |
| 06:31.16 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 06:53.07 | g0mb0 | can somebody tell me whether my patches are correct or not? |
| 06:53.13 | g0mb0 | http://lists.digium.com/pipermail/asterisk-dev/attachments/20080212/7ec8a960/attachment.obj |
| 06:53.19 | g0mb0 | http://lists.digium.com/pipermail/asterisk-dev/attachments/20080212/7ec8a960/attachment-0001.obj |
| 07:03.48 | Corydon76-dig | g0mb0: You need to submit patches to bugs.digium.com. We won't even look at them until you've signed a licensing agreement |
| 07:04.47 | g0mb0 | ok, thank you |
| 07:04.51 | g0mb0 | will do that |
| 07:22.26 | paravoid | Corydon76-dig: they are for ooh323 which iirc is in addons |
| 07:22.50 | paravoid | does he need to sign the license agreement for that? |
| 07:24.57 | snuff-work | paravoid: i would have thought for any digium project it would be required |
| 07:29.03 | g0mb0 | ooh323 is Objective systems', right? |
| 07:33.49 | paravoid | g0mb0: yes but it's merged into Digium's svn |
| 07:33.50 | paravoid | not sure |
| 07:34.07 | paravoid | I highly doubt that Objective Systems have signed the license agreement for the whole thing |
| 07:34.17 | paravoid | so presumably you won't have to either |
| 07:34.50 | paravoid | imho, ianal, iana digium employee |
| 07:36.05 | g0mb0 | you mean digium employee can tell about license issue |
| 07:36.07 | g0mb0 | ? |
| 07:37.32 | paravoid | some of then can, yeah |
| 07:37.42 | paravoid | certainly the ones that work on the legal dept. :P |
| 07:43.34 | g0mb0 | well then it is no use I guess |
| 07:43.58 | g0mb0 | it might take long time when it comes to legal dep |
| 07:48.10 | Corydon76-dig | paravoid: there are no exceptions |
| 07:50.19 | *** join/#asterisk-dev agx (n=AGX@host63-216-static.34-88-b.business.telecomitalia.it) |
| 08:11.04 | g0mb0 | http://bugs.digium.com/view.php?id=11976 |
| 08:11.10 | g0mb0 | will it do? |
| 08:26.18 | *** join/#asterisk-dev steliosk (n=Stelios@85.75.208.185) |
| 09:10.55 | *** part/#asterisk-dev oej (n=olle@soll4-125.cust.blixtvik.net) |
| 09:29.20 | *** join/#asterisk-dev Sajjad_Ali_Musht (n=Sajjad_A@octroi.enst-bretagne.fr) |
| 09:32.28 | tzafrir | g0mb0, here? |
| 09:33.04 | tzafrir | regarding bug 11976: could you please attach the patch as a file? |
| 09:33.21 | g0mb0 | ok, hold on |
| 09:38.34 | g0mb0 | done |
| 09:50.07 | *** join/#asterisk-dev Dovid (n=Dovid@bzq-79-182-143-236.red.bezeqint.net) |
| 09:50.58 | *** join/#asterisk-dev snuff-home (i=snuff@220-253-11-146.VIC.netspace.net.au) |
| 10:23.14 | *** join/#asterisk-dev dioedu (n=dioedu@201.7.117.114) |
| 10:51.21 | *** join/#asterisk-dev Greek-Boy (n=email@41.221.58.4) |
| 11:03.06 | *** join/#asterisk-dev NokVoda (n=root@122.161.30.191) |
| 11:03.26 | NokVoda | Hi :) |
| 11:08.36 | *** join/#asterisk-dev steliosk (n=Stelios@athedsl-121101.home.otenet.gr) |
| 11:13.52 | *** join/#asterisk-dev steliosk (n=Stelios@athedsl-121101.home.otenet.gr) |
| 12:01.54 | *** join/#asterisk-dev michael-i (n=michael-@141.41.40.225) |
| 12:41.05 | *** join/#asterisk-dev anonymouz666 (n=anonymou@201.19.127.250) |
| 12:56.50 | *** join/#asterisk-dev RoyK (n=roy@fw.fortel.no) |
| 12:57.24 | *** join/#asterisk-dev ZaVoid (n=zavoid@66-95-182-90.client.dsl.net) |
| 13:01.21 | *** join/#asterisk-dev flujan (n=flujan@200-160-115-020.static.spo.ctbc.com.br) |
| 13:16.31 | *** join/#asterisk-dev agx (n=AGX@88.34.216.63) |
| 13:17.28 | *** join/#asterisk-dev sergee (n=serg@voip1.west-call.com) |
| 13:39.29 | *** join/#asterisk-dev russellb (n=russell@asterisk/developer-and-stable-maintainer/drumkilla) |
| 13:39.30 | *** mode/#asterisk-dev [+o russellb] by ChanServ |
| 13:40.36 | *** join/#asterisk-dev pnlarsson (n=pnlarsso@c83-248-96-159.bredband.comhem.se) |
| 13:59.00 | *** join/#asterisk-dev anthm (n=anthm@CPE-72-131-113-50.wi.res.rr.com) |
| 13:59.00 | *** mode/#asterisk-dev [+o anthm] by ChanServ |
| 13:59.42 | *** part/#asterisk-dev flujan (n=flujan@200-160-115-020.static.spo.ctbc.com.br) |
| 14:01.11 | *** join/#asterisk-dev anthm (n=anthm@CPE-72-131-113-50.wi.res.rr.com) |
| 14:01.11 | *** mode/#asterisk-dev [+o anthm] by ChanServ |
| 14:03.43 | *** join/#asterisk-dev fakhir (n=fakhir@unaffiliated/fakhir) |
| 14:04.57 | *** join/#asterisk-dev flujan (n=flujan@200-160-115-020.static.spo.ctbc.com.br) |
| 14:05.58 | *** join/#asterisk-dev miguel3239 (n=elguerom@ns1.nashuacs.com) |
| 14:06.54 | flujan | hi russelb. Yesterday I just saw a comment from you about adding python inside asterisk. No more agi. :) I really have interest in looking this code. If I understand it I would like to create a similar one that supports ruby. |
| 14:07.18 | flujan | russellb: could you please point me to this source? |
| 14:08.23 | ZaVoid | i like agi! |
| 14:10.37 | mvanbaak | ZaVoid: this is way cooler |
| 14:11.38 | flujan | hi mvanbaak :) |
| 14:13.43 | russellb | flujan: asterisk/team/russell/bindings |
| 14:14.02 | russellb | essentially, you need to create res_ruby that does what i have done in res_python |
| 14:14.30 | russellb | and also, you have to do some work in the bindings directory to make it so it will generate the ruby type wrappers ... |
| 14:14.54 | flujan | russellb: thanks, a place to start. :D |
| 14:15.01 | russellb | yeah |
| 14:15.26 | russellb | i was thinking about doing perl here pretty soon to go ahead and make sure i'm making it as language agnostic as i can |
| 14:16.21 | *** join/#asterisk-dev ManxPower (n=manxpowe@34.sub-70-220-73.myvzw.com) |
| 14:16.31 | russellb | i will do that this week |
| 14:16.42 | mvanbaak | res_php |
| 14:16.44 | russellb | but first ... need to work on a more important project ... *kicks device state* |
| 14:17.27 | flujan | russellb: what do you think about the creation of a "generic" interface and them creating additional "modules" for all languages. Third part developers could join this cause... :D |
| 14:17.37 | flujan | mvanbaak: could create the res_php. :) |
| 14:17.42 | tzafrir | someone once wrote a res_js. Considering that, res_php sounds reasonable :-) |
| 14:17.55 | russellb | flujan: yeah, that's the idea ... |
| 14:18.03 | russellb | res_python doesn't do anything terribly interesting |
| 14:18.05 | ZaVoid | what makes ti cooler mvanbaak ? |
| 14:18.24 | russellb | loads a module ... calls the wrapper to generate a python type from the C object ... calls the python function ... |
| 14:18.36 | flujan | russellb: just a newbie question, what is the problem with device state? |
| 14:18.47 | flujan | russellb: cool... |
| 14:18.50 | russellb | well, making it distributeed |
| 14:18.58 | flujan | russellb: will check this code... |
| 14:19.35 | tzafrir | what do I need to do to update the running python code? reload? |
| 14:20.04 | russellb | nothing right now |
| 14:20.56 | flujan | russellb: but the idea behind dynamic languages is no need to restart/reload it... |
| 14:21.24 | tzafrir | flujan, but do you want the overhead of parsing at the time of taking a call? |
| 14:21.49 | tzafrir | mod_perl vs. mod_php, I guess |
| 14:22.03 | *** join/#asterisk-dev puzzled (n=patrick@puzzled.xs4all.nl) |
| 14:46.08 | *** join/#asterisk-dev jameswf-home (n=james@dsl093-157-131.phx1.dsl.speakeasy.net) |
| 14:48.43 | *** join/#asterisk-dev anthm (n=anthm@CPE-72-131-113-50.wi.res.rr.com) |
| 14:48.43 | *** mode/#asterisk-dev [+o anthm] by ChanServ |
| 15:02.58 | *** join/#asterisk-dev moy (n=moyhu@nat/ibm/x-a8871bd6ad3b2e08) |
| 15:18.40 | *** join/#asterisk-dev seanbright (n=elixer@65.207.74.18) |
| 15:35.15 | *** join/#asterisk-dev joetester (n=patrick@216.191.34.13) |
| 15:36.40 | *** join/#asterisk-dev anthm (n=anthm@CPE-72-131-113-50.wi.res.rr.com) |
| 15:36.40 | *** mode/#asterisk-dev [+o anthm] by ChanServ |
| 15:40.16 | *** join/#asterisk-dev oej (n=olle@soll4-125.cust.blixtvik.net) |
| 15:40.16 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 15:57.07 | ZaVoid | hey russellb and guys.. what debug can i do to capture the DTMF or lack thereof |
| 15:57.28 | jsmith | ZaVoid: Turn on DTMF debugging in logger.conf, then type "logger reload" at the Asterisk CLI |
| 15:57.29 | russellb | logger.conf => dtmf |
| 15:57.35 | ZaVoid | thanks |
| 15:57.37 | file | dtmf in logger.conf to console, otherwise depends on how it is being sent... if over RFC2833 then rtp debug will show it, if over SIP INFO then sip set debug on... |
| 15:58.17 | ZaVoid | debug => debug,dtmf right? |
| 15:58.37 | *** join/#asterisk-dev putnopvut (n=putnopvu@216.207.245.1) |
| 15:58.37 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 15:58.42 | jsmith | ZaVoid: That'll create a log file called /var/log/asterisk/debug, which will contain both your debug and DTMF logs |
| 15:58.50 | ZaVoid | ok thats fine |
| 15:59.00 | russellb | debug is very noisy ... |
| 16:00.48 | *** join/#asterisk-dev CunningPike (n=arodgers@vpn.dnv.org) |
| 16:01.35 | ZaVoid | [2008-02-12 16:00:11] DTMF[12838] channel.c: DTMF begin '1' received on SIP/carrier1 |
| 16:01.36 | ZaVoid | got it |
| 16:02.28 | file | are they possibly using Asterisk 1.2? |
| 16:02.37 | ZaVoid | ok interesting.. its ignoreing it |
| 16:02.39 | ZaVoid | [2008-02-12 16:01:32] DTMF[12860] channel.c: DTMF begin ignored '[2008-02-12 16:01:32] DEBUG[12860] app_macro.c: Executed application: Background |
| 16:02.49 | ZaVoid | lol why would it ignore it? |
| 16:03.10 | file | because depending on the code it doesn't need to know when the DTMF started |
| 16:03.28 | file | only when it ends. |
| 16:04.16 | ZaVoid | and i get "user entered nothing" in console |
| 16:04.50 | file | without a complete log it is extremely difficult to respond to your statements |
| 16:05.31 | file | there are two DTMF issues open right now though, so make sure either of them aren't your issue... |
| 16:07.01 | agx | When a phone Hold button is pressed and a re-invite is sent to the pbx/proxy does the CSeq have to be changed? |
| 16:07.13 | ZaVoid | so which more log do you want me to turn on? |
| 16:08.36 | ManxPower | agx: What evidence do you have that a reinvite happens when you press HOLD? |
| 16:09.05 | file | agx: incremented. |
| 16:09.55 | file | ZaVoid: what you have is fine, just nobody here can see it ... |
| 16:10.10 | ManxPower | sorry, wrong channel |
| 16:10.23 | ZaVoid | http://www.woot.us/dtmf.html |
| 16:10.25 | ZaVoid | that help file? |
| 16:11.36 | file | well that is curious. |
| 16:11.59 | tzafrir | what's the point of trying to limit CreateConfig when System(touch) is still there? |
| 16:12.11 | file | add rfc2833compensate=yes to their entry in sip.conf |
| 16:12.28 | agx | ManxPower, evidence? "sip debug peer snom13" :) |
| 16:14.13 | agx | file: ugly, got a snom that does not does this :-( |
| 16:14.30 | ZaVoid | to which side? |
| 16:14.32 | tzafrir | If one can create custom dialplan, one might as well add System-s in to a few places there |
| 16:14.32 | file | is it causing chan_sip to freak out? |
| 16:14.38 | ZaVoid | i have it on the sip_buddies side and i think all the carriers too |
| 16:15.00 | file | ZaVoid: adding it to general might be easiest then... but you don't currently |
| 16:15.50 | ZaVoid | yeah general will overirde anything in more specific peers right? |
| 16:16.08 | file | more like other way around. |
| 16:16.33 | joetester | Specific overrides general, right file? |
| 16:16.55 | ZaVoid | ahh then shold be ok |
| 16:16.57 | ZaVoid | let me recheck |
| 16:17.00 | file | ZaVoid: the option *might* work... but it seems as though your carrier is not sending very nice RFC2833 |
| 16:17.01 | seanbright | admiral overrides general, too. |
| 16:17.02 | joetester | For a moment I thought I'd been mistaken all my life, turns out I was ok. |
| 16:17.54 | joetester | And the dreaded rear admiral overrides your admiral, I'm sure. |
| 16:19.46 | *** join/#asterisk-dev jpeeler (n=jpeeler@216.207.245.1) |
| 16:20.00 | Corydon76-dig | Morning, jpeeler |
| 16:20.15 | jpeeler | good morning |
| 16:20.36 | Corydon76-dig | Good? You're pushing it... |
| 16:22.37 | tzafrir | Corydon76-dig, ah, so you were just stating your time zone? |
| 16:22.44 | ZaVoid | yeah file it might seem that way but this is over multiple carriers too |
| 16:22.55 | ZaVoid | did i mention the number being dialed is a cell phone in qatar? |
| 16:22.57 | Corydon76-dig | tzafrir: basically |
| 16:23.06 | tzafrir | Evening |
| 16:23.19 | ZaVoid | the thing i don't get is that the log does say it received the correct Digits.. and then ignores them.... |
| 16:23.21 | Corydon76-dig | jpeeler: hope you packed lunch, the storms look like they'll hit HSV at around noon |
| 16:23.29 | putnopvut | What sort of storms? |
| 16:23.41 | putnopvut | I guess I could always just check the ol' internet for that... |
| 16:23.55 | jpeeler | Corydon76-dig: no i didn't actually... |
| 16:24.01 | Corydon76-dig | http://wtvf.images.worldnow.com/images/incoming/NC5Wx/radar_TnAreaWin.html |
| 16:24.02 | ZaVoid | noaa.gov is your friend putnopvut |
| 16:24.02 | file | ZaVoid: DTMF in 1.4 is two separate frames... a begin and an end, whatever is currently executing is only looking for end frames... which never arrive |
| 16:24.14 | ZaVoid | Read is executed |
| 16:24.30 | Corydon76-dig | This local station (to me) produces some of the best radar maps, IMHO |
| 16:24.34 | ZaVoid | exten => s,6,Read(DESTINATION) |
| 16:24.53 | joetester | Here we go with the local pride. |
| 16:25.37 | Corydon76-dig | joetester: No, I'm serious. They blow noaa.gov out of the water |
| 16:25.43 | jpeeler | Corydon76-dig: have you tried using the radar images with the gnome weather applet? |
| 16:25.55 | Corydon76-dig | joetester: I know it's the same data, but they render it so much better |
| 16:26.06 | Corydon76-dig | jpeeler: KDE here |
| 16:26.18 | jpeeler | guess that's a definite no then :) |
| 16:26.23 | Corydon76-dig | Heh |
| 16:26.47 | Corydon76-dig | There's probably a KDE equivalent, if I bothered |
| 16:27.15 | joetester | All right, all right, I trust you. |
| 16:28.05 | russellb | i trust noone! |
| 16:28.25 | Qwell | </3 russellb |
| 16:28.52 | joetester | He doesn't even trust me. :( |
| 16:29.05 | Qwell | I don't blame him |
| 16:29.16 | Qwell | I'll bet your name isn't even Joe! |
| 16:29.21 | joetester | Sounds like nobody does! |
| 16:29.35 | joetester | It's a typo. |
| 16:29.41 | Qwell | Jose? |
| 16:29.41 | joetester | I'm hoe tester. |
| 16:29.44 | Qwell | heh |
| 16:30.20 | joetester | I'm not joe, jack, john, eric, enrique or even manuel! |
| 16:33.24 | Corydon76-dig | jpeeler: btw, did you see the BuildBot failures? |
| 16:33.32 | Qwell | they were fixed |
| 16:33.35 | Qwell | BUT... |
| 16:33.49 | Qwell | as I pointed out in #asterisk-commits, it should be 0644 and not 0744 |
| 16:34.09 | Qwell | I don't have commit setup on my new machine yet, otherwise I'd fix it :( |
| 16:34.14 | jpeeler | no, my fault? |
| 16:34.41 | Qwell | jpeeler: freebsd didn't like the permission constants you used in open() |
| 16:34.45 | Corydon76-dig | jpeeler: you were on the blamelist, no big deal, though |
| 16:34.46 | russellb | Qwell: rsync avz qwell@oldbox:/home/qwell/.subversion /home/qwell |
| 16:35.07 | Qwell | russellb: yeah... grabbing all of /home |
| 16:35.13 | russellb | that works, too |
| 16:35.44 | Qwell | hopefully it won't recurse symlinks |
| 16:35.51 | Corydon76-dig | jpeeler: but it might be a good opportunity to learn how to connect to the FreeBSD VMs and do checks there... |
| 16:35.59 | jpeeler | wow i meant to do 0644 |
| 16:36.05 | russellb | jpeeler: you did |
| 16:36.10 | russellb | i screwed it up and made it 744 |
| 16:36.24 | file | it is documented on the wiki how you can test your builds on any of the builders |
| 16:37.20 | jpeeler | file: you mean outside of trunk? |
| 16:37.37 | Corydon76-dig | jpeeler: outside of Linux |
| 16:37.47 | Qwell | or inside of linux |
| 16:38.00 | jpeeler | right, multiple platforms and such |
| 16:38.12 | jpeeler | but does the buildbot only test trunk or can it do other branches |
| 16:38.19 | Qwell | it can do 1.4 too |
| 16:38.24 | file | it doesn't exactly work like that |
| 16:38.30 | file | it accepts a diff |
| 16:38.37 | file | and applies it to the builder's checkout (be it 1.4 or trunk) |
| 16:39.15 | file | the way I have it documented assumes you want to test modifications of your current checkiut |
| 16:39.17 | file | erm checkout |
| 16:39.48 | file | but you can pass the --diff=<filename> argument to specify a diff you already have |
| 16:40.11 | Corydon76-dig | So is 2.6.25 out now? |
| 16:40.24 | russellb | totally off topic, but does anyone know a pager that doesn't suck with terminal colors? |
| 16:40.32 | russellb | svn diff | colordiff | somepagerthatworks |
| 16:40.45 | Corydon76-dig | russellb: nope |
| 16:40.49 | russellb | oh well. |
| 16:41.12 | jpeeler | file: i'll go check the wiki |
| 16:41.16 | Corydon76-dig | Now that there's a critical vulnerability known for 2.6.23 and 2.6.24 |
| 16:41.39 | file | jpeeler: it's under ABC on our page, or search for it |
| 16:41.57 | Qwell | russellb: try most |
| 16:42.04 | Qwell | (no, really) |
| 16:42.07 | russellb | Qwell: ok |
| 16:42.50 | russellb | fail |
| 16:42.51 | Corydon76-dig | Ah, it's fixed in 2.6.24.2 |
| 16:43.04 | Qwell | local root exploits are funny |
| 16:43.12 | russellb | more is close ... |
| 16:43.20 | Qwell | mantra: If you don't trust your users with root, don't give them an account. |
| 16:43.32 | putnopvut | What all pagers are there? more, less, most, ??? |
| 16:43.34 | Qwell | nothing is going to stop a user from fork bombing you |
| 16:43.41 | Qwell | putnopvut: vim can be a pager |
| 16:43.56 | denon | Qwell: you know, in the days of shell servers, I might disagree |
| 16:43.57 | putnopvut | yeah, but that's not its primary purpose. |
| 16:44.02 | denon | but these days .. yeah.. |
| 16:44.11 | denon | except, I don't trust that darn apache guy with root ;) |
| 16:47.07 | tzafrir | russellb, svn diff | vim - |
| 16:47.20 | russellb | ooh |
| 16:47.30 | Qwell | <Qwell> putnopvut: vim can be a pager |
| 16:47.31 | Qwell | :p |
| 16:47.41 | tzafrir | oh |
| 16:47.56 | russellb | hm, vim blows up on it, too |
| 16:48.09 | Qwell | vimdiff? |
| 16:48.21 | Qwell | what're you trying to do, just make colors not suck? |
| 16:48.48 | putnopvut | What does "not suck" mean in this scenario? |
| 16:50.04 | atis_work | svn diff > /tmp/asdf ; mcedit /tmp/asdf |
| 16:50.34 | russellb | Qwell: have a colorized svn diff in a pager that ... works |
| 16:51.08 | russellb | svn diff | highlight --syntax=C -A | somethingthatworkshere |
| 16:51.22 | Qwell | vimdiff + syntax highlighting? |
| 16:52.03 | russellb | but i don't want vimdiff, i want a unified diff :) |
| 16:52.26 | Qwell | picky picky |
| 16:52.33 | russellb | heh, yeah |
| 16:52.39 | Qwell | more doesn't keep color? |
| 16:53.43 | Qwell | or less -r maybe |
| 16:53.51 | Qwell | erm -R? |
| 16:53.54 | *** join/#asterisk-dev outtolunc (n=me@adsl-66-218-53-172.dslextreme.com) |
| 16:54.16 | Qwell | I assume the -A to highlight means ansi color |
| 16:54.29 | *** join/#asterisk-dev jeffg (i=4HRvxxWs@pdpc/supporter/active/jeffg) |
| 16:54.58 | russellb | Qwell: correct |
| 16:55.02 | Qwell | try less -R |
| 16:55.30 | russellb | Qwell: w00t ! |
| 16:55.31 | russellb | you win! |
| 16:55.41 | Qwell | I rtfm'd :p |
| 17:01.51 | jpeeler | Corydon76-dig: where is the VM documentation you were speaking of? |
| 17:02.29 | Corydon76-dig | jpeeler: I wasn't, actually |
| 17:03.08 | jpeeler | jpeeler: but it might be a good opportunity to learn how to connect to the FreeBSD VMs and do checks there... |
| 17:03.16 | jpeeler | referring to buildbot? |
| 17:03.34 | russellb | just using the vmware server in general |
| 17:03.56 | kpfleming | hi! |
| 17:04.01 | russellb | kpfleming: hi2u |
| 17:04.08 | file | kpfleming: what are YOU doing here? |
| 17:04.30 | kpfleming | wouldn't you like to know |
| 17:08.53 | *** join/#asterisk-dev Greek-B0y (n=email@41.221.58.4) |
| 17:16.28 | seanbright | my favorite new warning: WARNING[24163]: chan_zap.c:6416 ss_thread: CallerID feed failed: Success |
| 17:16.46 | Qwell | seanbright: stop running asterisk on windows |
| 17:16.50 | seanbright | hehe |
| 17:17.23 | Qwell | weird, why is it strerror()ing there? |
| 17:17.26 | jsmith | seanbright: Didn't you get the memo? Failure is the new success! |
| 17:17.56 | outtolunc | successful failure is an option <G> |
| 17:17.59 | seanbright | jsmith: that just about sums up my career. |
| 17:18.04 | seanbright | ;-) |
| 17:18.33 | jsmith | outtolunc: That's what golden parachutes are for! |
| 17:18.35 | Qwell | yeah, that usage of strerror there is so wrong |
| 17:18.57 | Qwell | callerid_feed can return < 0 in lots of different ways, many of which wouldn't set errno |
| 17:30.03 | *** join/#asterisk-dev techie (n=techie@adsl-76-214-27-74.dsl.lsan03.sbcglobal.net) |
| 17:41.57 | *** join/#asterisk-dev MuffinMan (n=muffins@neutrino.joshua-colp.com) |
| 17:48.02 | denon | someone refresh my memory, who's the zoiper/idefisk guy? (and isn't he on irc once in a while?) |
| 17:48.13 | file | zoa |
| 17:48.26 | denon | ah ic |
| 17:48.37 | denon | not on at the moment.. |
| 17:59.12 | *** join/#asterisk-dev Victor_Yure (n=Victor_Y@unaffiliated/victoryure/x-837844) |
| 18:15.28 | *** join/#asterisk-dev lmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 18:15.28 | *** mode/#asterisk-dev [+o lmadsen] by ChanServ |
| 18:18.43 | *** join/#asterisk-dev puzzled (n=patrick@puzzled.xs4all.nl) |
| 18:20.06 | tzafrir | I just don't see the point in preventing Asterisk from writing to an config arbitrary file. Because this has its uses |
| 18:20.24 | tzafrir | Just like with sound / image files |
| 18:20.32 | kpfleming | i agree |
| 18:21.01 | Corydon76-dig | I would tend to agree, though I agree with also prohibiting "../" in filenames |
| 18:21.44 | ZaVoid | so file should i try the current asteirsk build beforei submit a bug report? |
| 18:21.58 | Corydon76-dig | That is almost always used for bad things. If you want to compromise your own system by symlinking a directory to root, that's fine, though |
| 18:22.10 | kpfleming | and realpath() solves that problem |
| 18:22.24 | kpfleming | well, maybe not |
| 18:22.30 | tzafrir | realpath has some scary notes in the man page |
| 18:22.37 | Corydon76-dig | realpath() only resolves it |
| 18:23.02 | kpfleming | but adding something that only covers 10% of the cases for the purposes of 'security' is really scary, because then people will assume we have a higher level of security than we do (or care about) |
| 18:23.02 | Corydon76-dig | You'd still need to prohibit certain prefixes, if you went that route |
| 18:23.23 | kpfleming | i'd much rather either do it all the way, or not at all |
| 18:24.06 | Corydon76-dig | I think the security community would roast us over an open pit if we did not at least provide some methods of reducing the risk |
| 18:24.47 | Corydon76-dig | and I think limiting out "../" as a substring would be fine for that purpose |
| 18:24.58 | kpfleming | it's no worse than allowing System() |
| 18:25.12 | kpfleming | we are not introducing any new problems here |
| 18:25.39 | Corydon76-dig | I'm working towards limiting the exposure of the Manager Command interface, so that not every client needs to have that permission |
| 18:25.51 | kpfleming | what permission? |
| 18:25.59 | Corydon76-dig | Action: command |
| 18:26.18 | kpfleming | then this can be hidden under 'config' |
| 18:26.58 | Corydon76-dig | Eventually, we'll make it possible to give someone the ability to see system statuses without giving them root |
| 18:27.13 | Corydon76-dig | Well, root in a roundabout way |
| 18:27.23 | kpfleming | if all this stuff is optional (as it is) and is marked with suitable warnings for people who want to enable it, i just don't see why this is an issue now when it wasn't before |
| 18:28.05 | Corydon76-dig | I hear you, but we're moving towards better security, so this might as well go in without some obvious gotchas |
| 18:29.08 | kpfleming | only if the mitigation of those gotchas is 100% solid and reliable and understood... not "well, this is good enough for some of the problems" |
| 18:29.10 | Corydon76-dig | Right now, the vast majority of remote interfaces are built with Command privs (simply because there was no other way to get the necessary info) |
| 18:30.11 | kpfleming | but that is not the issue that is being talked about here |
| 18:30.33 | kpfleming | we are talking about the 'config' commands |
| 18:30.33 | Corydon76-dig | The issue is that there are other ways to get root on the machine |
| 18:30.56 | kpfleming | or worse |
| 18:30.59 | Corydon76-dig | Oh, right... |
| 18:31.10 | Corydon76-dig | direct access to build a System command, not roundabout |
| 18:31.32 | *** join/#asterisk-dev oej (n=olle@soll4-125.cust.blixtvik.net) |
| 18:31.32 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 18:32.37 | oej | evening folks |
| 18:32.44 | Corydon76-dig | Okay, never mind. I wasn't thinking about it in that way. |
| 18:33.38 | Corydon76-dig | oej: hey, I saw the private email you sent out |
| 18:33.54 | oej | Private email? |
| 18:33.55 | Corydon76-dig | oej: why are you encouraging people not to try the 1.6 beta? |
| 18:34.17 | oej | I did say that with testing it will be good |
| 18:34.26 | oej | I wonder how you read it |
| 18:34.33 | kpfleming | that is the point of a beta process |
| 18:34.35 | oej | And why you assume the worst |
| 18:34.35 | Corydon76-dig | Yeah, but the tone was "don't try this for the next 6 months" |
| 18:34.56 | oej | For production, yes |
| 18:35.11 | kpfleming | who suggested anyone would? |
| 18:35.17 | Corydon76-dig | Well, duh, it's a beta |
| 18:35.22 | oej | I don't think it is worth evaluating for production for a long time |
| 18:35.30 | oej | The chan_sip driver is in alpha state |
| 18:36.04 | oej | I have customers asking me about the 1.6 release |
| 18:36.28 | Corydon76-dig | We don't know when it will be released yet. That's part of the reason behind doing a beta |
| 18:36.41 | oej | So what's your problem? |
| 18:36.53 | Corydon76-dig | and if we don't get feedback, because nobody will try it, then we assume fewer problems |
| 18:37.20 | oej | I clearly state in the mail: "If you have some spare cycles and systems - start testing 1.6 now and report all bugs you find in the bug tracker." |
| 18:37.43 | oej | I still wonder why you assume the worst from me, and gets kind of upset at that. |
| 18:37.56 | tzafrir | when will 1.6.0 be released? |
| 18:38.06 | Qwell | <Corydon76-dig> We don't know when it will be released yet. That's part of the reason behind doing a beta |
| 18:38.09 | Corydon76-dig | tzafrir: we don't know |
| 18:38.39 | anonymouz666 | Google releases some great BETA products ;) |
| 18:38.40 | oej | And it wasn't a "private mail" - it was an e-mail to Edvina's customers |
| 18:39.23 | Corydon76-dig | oej: well, it didn't go out to one of the lists, I got it secondhand by someone who thought it was concerning |
| 18:39.25 | tzafrir | suppose you announce a feature freeze for a month (or maybe two) up to the release of 1.6 |
| 18:40.14 | tzafrir | if it is a month, new features can wait. If it is longer, it starts becoming a pain, I guess |
| 18:40.17 | oej | Well, I am concerned about the 1.6 release process, like I wrote |
| 18:40.33 | Corydon76-dig | It was discussed openly on the -dev list |
| 18:40.42 | Corydon76-dig | and on the -users list, IIRC |
| 18:41.00 | oej | And I missed it being off line with my bad back, as you very well know. I was offline a lot during the fall. |
| 18:41.02 | Corydon76-dig | I don't know how much more open we could have gotten |
| 18:41.17 | oej | I still have the right to have another opinion, even if I missed that process, right? |
| 18:41.55 | Corydon76-dig | It's frustrating when we have a discussion, we wait for more opinions and hear not a peep |
| 18:42.11 | Corydon76-dig | then we move forward, and now you're in the middle of the street, waving your hands |
| 18:42.28 | oej | I guess you did not bother to read that mail at all. |
| 18:42.47 | tzafrir | anywhere I could read that mail? |
| 18:42.49 | oej | But go on, piss at me. |
| 18:43.25 | Corydon76-dig | We're supposed to be a team. If you have a problem, I'd like to hear about it, when we're having the discussion |
| 18:43.35 | oej | I was sick, damn. |
| 18:43.39 | oej | I was mostly off line. |
| 18:44.13 | Corydon76-dig | Yes, but it comes across in the email as if we ignored you the entire time. |
| 18:44.35 | Corydon76-dig | like we ignored your feedback, ignored your branches, when we weren't hearing anything from you |
| 18:44.37 | oej | Fine, that's your interpretation. |
| 18:44.52 | oej | The videocaps stuff has been ignored. Really. |
| 18:45.00 | kpfleming | it is actually the interpretation of many people, not just those at digium |
| 18:45.09 | Corydon76-dig | <PROTECTED> |
| 18:45.22 | oej | Oh, I updated that branch just recently. |
| 18:45.31 | Corydon76-dig | When? |
| 18:45.34 | oej | I guess it's no point to go on in this discussion, you've made up your minds. |
| 18:45.41 | *** part/#asterisk-dev oej (n=olle@soll4-125.cust.blixtvik.net) |
| 18:45.49 | Corydon76-dig | Argh |
| 18:50.53 | *** join/#asterisk-dev ctooley (n=ctooley@doc-72-47-33-80.maryville.mo.cebridge.net) |
| 19:06.30 | russellb | argh, indeed. |
| 19:06.41 | russellb | Corydon76-dig: sorry i was off to lunch when that occurred ... |
| 19:06.49 | russellb | i had plenty to say :) |
| 19:07.22 | Corydon76-dig | russellb: I'm hearing right now that I may have been to harsh, too soon... |
| 19:12.45 | kpfleming | i don't agree |
| 19:13.12 | kpfleming | you didn't render any judgement or even really any opinion |
| 19:14.04 | mvanbaak | oej is having a hard time |
| 19:14.08 | Corydon76-dig | Well, I agree with that, but I work to improve my people skills, and if that made oej drop Asterisk development, then it was badly phrased |
| 19:14.09 | mvanbaak | I'm not judging here |
| 19:14.13 | mvanbaak | just telling what I know |
| 19:14.28 | mvanbaak | it wont make him drop asterisk dev |
| 19:14.42 | kpfleming | if that is the result, it will not be because of today's conversation |
| 19:15.02 | kpfleming | or conversely, if it is, then it is doubtful we could have done anything to avoid that result |
| 19:15.02 | Corydon76-dig | mvanbaak: I certainly hope not. While I don't always agree with oej's opinions, he is a strong force for improvement |
| 19:15.04 | mvanbaak | this channel is too public for me to talk about it |
| 19:15.27 | mvanbaak | anywhere only digium folks are ? |
| 19:15.40 | russellb | you can email us directly, that's about it |
| 19:15.45 | mvanbaak | ok |
| 19:15.46 | Corydon76-dig | mvanbaak: not on this network, sorry |
| 19:15.47 | russellb | or private message |
| 19:15.52 | kpfleming | yes, but you are not digium, so you can't get there :-) |
| 19:15.57 | russellb | heh |
| 19:15.59 | mvanbaak | lol |
| 19:16.10 | mvanbaak | kevin: I'm working on that one ;) |
| 19:16.14 | russellb | ooh |
| 19:16.17 | Qwell | O.o |
| 19:16.38 | mvanbaak | ah well |
| 19:16.47 | *** join/#asterisk-dev agx (n=badpengu@81-174-45-76.dynamic.ngi.it) |
| 19:16.52 | mvanbaak | oej lost almost all of his income |
| 19:16.53 | *** join/#asterisk-dev dlynes (n=dlynes@mail.247communications.com) |
| 19:16.59 | mvanbaak | and with his back and stuff |
| 19:17.06 | Corydon76-dig | mvanbaak: ouch |
| 19:17.11 | mvanbaak | he's strugling to survive right now |
| 19:17.32 | mvanbaak | voop gave him money to develop asterisk |
| 19:17.35 | jsmith | mvanbaak: To make a long story short, I've been talking with him most of the day |
| 19:17.42 | mvanbaak | but voop is gone *poof* |
| 19:19.31 | jsmith | mvanbaak: I tried to get him to open a public dialog with the developers about the future direction of Asterisk, which led to this |
| 19:21.26 | mvanbaak | jsmith: sorry to see it went this way |
| 19:21.36 | jsmith | mvanbaak: So am I |
| 19:21.49 | *** join/#asterisk-dev CtRiX (n=CtRiX@aretha.navynet.it) |
| 19:21.50 | mvanbaak | but I think oej was a bit too fast with his judgement there |
| 19:22.07 | kpfleming | 'future direction of Asterisk' is far too large a topic to talk about in that sense |
| 19:22.28 | kpfleming | most of us are focused on what is happening right now |
| 19:22.34 | tzafrir | Anything specific he complained about? |
| 19:23.51 | russellb | tzafrir: not in public, no |
| 19:24.06 | russellb | i have encouraged him on multiple occasions to discuss his 1.6 concerns on the -dev list, which he never did |
| 19:24.06 | *** join/#asterisk-dev otherwiseguy (n=otherwis@CPE-75-81-49-192.kc.res.rr.com) |
| 19:24.27 | russellb | in short, he doesn't like the 1.6 plan ... but never said anything specifically, really |
| 19:24.54 | tzafrir | Frankly I must admit I don't fully understand what the 1.6 plan is |
| 19:25.02 | Qwell | tzafrir: think linux kernel |
| 19:25.09 | Qwell | (2.6) |
| 19:25.11 | russellb | basically ... |
| 19:25.48 | tzafrir | they have a relatively short merge window, and then a period of ~2 monthes (maybe longer) of stabilization |
| 19:26.39 | russellb | i'm minimizing IRC for a while so I can write some code ... |
| 19:26.50 | mvanbaak | russellb: good thinking there |
| 19:27.10 | mvanbaak | actually, the last 2 weeks I had my irc client set to '/away you can contact me at michiel@vanbaak.info' |
| 19:27.14 | mvanbaak | worked out great |
| 19:29.34 | mvanbaak | oh, btw |
| 19:29.41 | mvanbaak | I like the new 1.6 plan |
| 19:34.59 | *** part/#asterisk-dev techie (n=techie@adsl-76-214-27-74.dsl.lsan03.sbcglobal.net) |
| 19:37.37 | *** topic/#asterisk-dev by Qwell -> Asterisk Development Discussion -=- http://www.asterisk.org/developers -=- IAX2/guest@misery.digium.com/asterisk-dev -=- Asterisk trunk: res_telepathy release tomorrow-=- Tier 2 and Tier 3.14159 support is in #asterisk -=- Lost: Sanity Found: Banana -=- Congrats sruffell! |
| 19:58.41 | *** join/#asterisk-dev simbol76 (n=simbol@host242-226-dynamic.35-79-r.retail.telecomitalia.it) |
| 20:05.27 | putnopvut | russellb: ping. reply at your leisure. |
| 20:05.48 | russellb | putnopvut: just hit a good break point |
| 20:05.50 | russellb | what's up. |
| 20:06.13 | putnopvut | So, I was wondering if event IE's are meant to always be of the same type. |
| 20:06.28 | russellb | that is the intention, yes |
| 20:06.37 | putnopvut | Okay, then I want to propose something. |
| 20:06.59 | putnopvut | Create a lookup table of IE's and their corresponding payload type so that you don't have to pass the payload type to ast_event_new. |
| 20:07.04 | russellb | an API call to convert IE type to payload type? |
| 20:07.14 | putnopvut | and that too :) |
| 20:07.19 | russellb | hm ... |
| 20:07.56 | russellb | i guess that could work for creating an event |
| 20:08.00 | russellb | but it won't work for everything |
| 20:08.16 | russellb | because for some of the API calls, you have the option of saying that you care about its value or that you just care that the IE exists |
| 20:08.31 | putnopvut | Yeah, I'm just talking about the ast_event_new call right now. |
| 20:09.08 | putnopvut | Because I realized it's a bit redundant to always declare an IE and its payload type on each event creation if the IE will always have the same type. |
| 20:09.20 | russellb | i think i may have some code for that |
| 20:09.22 | russellb | let me check |
| 20:09.25 | putnopvut | ooh |
| 20:09.41 | putnopvut | I've written something for this manager2 branch, but only for the informational IE's I've defined so far. |
| 20:10.31 | russellb | ah, well the stuff i have in pbx_dundi isn't generic |
| 20:10.53 | russellb | it's mapping text to event types |
| 20:11.14 | russellb | and then event IE text to event IE types (and restricted to the IEs valid for that event type) |
| 20:11.20 | russellb | it's very specific to the code i was doing in dundi, so ... |
| 20:12.15 | russellb | anyway, yeah, i am ok with that |
| 20:12.25 | russellb | i don't think PLTYPE_EXISTS would event be used in ast_event_new ... |
| 20:12.35 | russellb | actually, it is used. |
| 20:12.43 | putnopvut | Interesting... |
| 20:12.49 | russellb | reason is ... |
| 20:12.57 | putnopvut | And actually, I've come across a snag... |
| 20:13.03 | russellb | there are events to indicate that a new subscription was made |
| 20:13.36 | russellb | and the event includes the subscription paramaters |
| 20:13.36 | russellb | and the sub parameters can include that certain IEs exists |
| 20:13.36 | russellb | s/exists/exist/ |
| 20:14.05 | putnopvut | I am defining IE's in a file outside event_defs.h and renumbering starting at 0, so I wouldn't be able to do that if the event API used a single global lookup table to find the payload type. |
| 20:14.25 | russellb | um ... why would you be doing that? |
| 20:14.39 | putnopvut | Why not? |
| 20:14.52 | russellb | because the IE numbers have to be unique |
| 20:14.56 | putnopvut | Why? |
| 20:15.04 | tzafrir | hmmm... new config files are created 644 . What do I need to change to make the newly-generated files writable to the group asterisk? |
| 20:15.23 | russellb | tzafrir 0664 ? :) |
| 20:15.25 | Qwell | tzafrir: using CreateConfig from manager? |
| 20:15.31 | tzafrir | yes |
| 20:15.49 | Qwell | tzafrir: see the commit I just made - change that open() call. r103447 |
| 20:15.52 | kpfleming | i thought we had compile-time settings for that now, so that people could override the default permissions |
| 20:16.00 | kpfleming | not everyone wants 0664 |
| 20:16.10 | kpfleming | we went through this with app_voicemail, for example |
| 20:16.59 | Qwell | #define VOICEMAIL_DIR_MODE 0777 |
| 20:16.59 | Qwell | #define VOICEMAIL_FILE_MODE 0666 |
| 20:17.01 | Qwell | erm |
| 20:17.07 | Qwell | /* Don't modify these here; set your umask at runtime instead */ |
| 20:17.17 | kpfleming | right |
| 20:17.23 | kpfleming | exactly my point |
| 20:17.32 | kpfleming | don't code in a value that people can't change |
| 20:17.36 | russellb | putnopvut: i don't know if I can verbalize it very well :) ... but i really just want a single table of IE values that are all unique, because these things are sent over the network and making them unique makes the events easy to interpret |
| 20:18.00 | Qwell | there's also AST_FILE_MODE in asterisk.h |
| 20:18.18 | Qwell | (and AST_DIR_MODE) |
| 20:18.19 | putnopvut | russellb: hmmm, well, I was thinking that IE's would really only need to be unique per event type. |
| 20:18.33 | Qwell | So, I guess the correct thing to do there would be to change it from 0644 to AST_FILE_MODE |
| 20:18.34 | russellb | putnopvut: well don't worry about it right now ... |
| 20:18.46 | russellb | putnopvut: we don't need to resolve this for you to continue what you're doing |
| 20:19.03 | putnopvut | Well, it would be nice to now since it might save me a lot of backtracking later. |
| 20:19.06 | Qwell | kpfleming: if that sounds right, I can fix |
| 20:19.20 | putnopvut | russellb: unless that's a not-so-subtle way of saying you want to do something else ;) |
| 20:19.24 | russellb | putnopvut: why does it matter? isn't it just moving values from one enum toanother? |
| 20:19.26 | mvanbaak | <--- reading up on swift |
| 20:19.31 | kpfleming | Qwell: do those default to 0777 and 0666? |
| 20:19.33 | mvanbaak | to create res_php |
| 20:19.34 | Qwell | yes |
| 20:19.39 | kpfleming | then use them, for sure |
| 20:19.50 | putnopvut | russellb: it also means getting rid of this lookup table I have for informational IE's, their types, and their "names" |
| 20:20.03 | putnopvut | It's also difficult for me to verbalize. |
| 20:20.12 | kpfleming | and maybe we should take the time to wrap the file creation APIs into ast_* variants that don't take mode settings and then make the underlying versions unavailable at compile time |
| 20:20.34 | Qwell | kpfleming: hmm |
| 20:20.55 | Qwell | that's not a bad idea - I'm sure we do it tons of different (and incorrect) ways right now |
| 20:21.22 | Qwell | it'd make ast_storage easier in the long run too |
| 20:21.30 | Qwell | ...maybe |
| 20:21.53 | russellb | putnopvut: i don't know about getting rid of it ... maybe slightly changing it, you're going to need that either way |
| 20:32.22 | *** join/#asterisk-dev simbol76 (n=simbol@host242-226-dynamic.35-79-r.retail.telecomitalia.it) |
| 20:40.47 | jpeeler | so it looks like i missed the realpath discussion in multiple channels while i was at lunch... was a decision made? |
| 20:41.58 | mvanbaak | jpeeler: not that I know off |
| 20:43.09 | mvanbaak | I'm fine with the realpath, as long as you dont do something like: if (realpath != ast_config_dir) |
| 20:43.32 | mvanbaak | because my /etc/asterisk is symlinked to /mnt/netapp/linux/configs/asterisk |
| 20:44.01 | mvanbaak | I had the same trouble with 3 other pieces of software I use |
| 20:44.28 | mvanbaak | hate it when I have to keep my own patchset up-to-date just because the configfiles are not in a 'legal' place |
| 20:44.32 | jpeeler | yeah, in which case it really is going to be hard to do completely right |
| 20:45.14 | mvanbaak | know what ? |
| 20:45.20 | mvanbaak | ignore my comment |
| 20:45.34 | mvanbaak | I'll go with the 'mount -o bind' stuff |
| 20:46.15 | mvanbaak | and next upgrade I'll use the --sysconfigdir configure parameter |
| 20:46.36 | mvanbaak | or whatever it was |
| 20:47.40 | mvanbaak | that's the best way to do it anyways |
| 20:48.22 | tzafrir | mvanbaak, actually this is not a problem if you place all of your conifg there |
| 20:48.23 | mvanbaak | but since we are using stock bristuff install on our cluster we could not set this (bristuff stable still uses 1.2) |
| 20:48.50 | tzafrir | you can just set astetcdir in asterisk.conf |
| 20:48.54 | mvanbaak | tzafrir: well, in rdiffweb and amanda I had those trouble |
| 20:49.23 | mvanbaak | they check realpath against the configure time supplied sysconfdir |
| 20:50.05 | mvanbaak | ln -s /mnt/netapp/linux/configs/amanda /etc/amanda |
| 20:50.09 | mvanbaak | that would break it |
| 20:50.23 | mvanbaak | because (naturally) those are not the same |
| 20:51.18 | *** join/#asterisk-dev lvl- (n=lvl@145.52.248.101) |
| 20:59.23 | *** join/#asterisk-dev jmesquita (n=jmesquit@201.7.117.114) |
| 21:00.21 | *** part/#asterisk-dev simbol76 (n=simbol@host242-226-dynamic.35-79-r.retail.telecomitalia.it) |
| 21:00.43 | *** join/#asterisk-dev simbol76 (n=simbol@79.35.226.242) |
| 21:03.06 | snuff-work | putnopvut: some functions in app_queue have vars they dont read.. 3 funcs (trunk) member_hash_fn/member_cmp_fn (int flags) and device_state_cb (void* unused) |
| 21:03.53 | Corydon76-dig | snuff-home: Yes, they're supposed to be that way |
| 21:04.05 | Corydon76-dig | snuff-home: those are callback functions |
| 21:04.31 | putnopvut | Yes, Corydon76-dig has it right on. Their parameters are defined by the astobj2 API. |
| 21:04.48 | snuff-work | k thought they'd be a reason |
| 21:04.50 | putnopvut | Except the device_state_cb, which is defined by the event API. |
| 21:09.10 | russellb | device state handling is about to get another layer of complication |
| 21:09.12 | russellb | :-/ |
| 21:10.14 | putnopvut | (ironic) yay! |
| 21:10.21 | mvanbaak | yeah, but it would be cool to have it available in a cluster of machines |
| 21:11.22 | snuff-work | in a couple of the queue_function functions.. there is logerror "FUNC req args".. but in only one is it just '"%s req args",cmd' (using cmd seems logical since it was passed into func) |
| 21:11.36 | Corydon76-dig | Hmmm, 5 years later and my first Grandstream finally dies |
| 21:12.17 | mvanbaak | Corydon76-dig: I find the grandstreams pretty stable |
| 21:12.31 | putnopvut | snuff-work: which functions are you talking about? |
| 21:12.33 | Corydon76-dig | mvanbaak: BT102 on 1.03 firmware? |
| 21:12.43 | mvanbaak | gxp2000 |
| 21:13.09 | mvanbaak | I dont like the way the BT10X looks |
| 21:13.16 | mvanbaak | weird huge plastic keys |
| 21:13.26 | snuff-work | putnopvut: queue_function_queuewaitingcount / queue_function_queuememberlist |
| 21:14.02 | mvanbaak | Corydon76-dig: the BT ones look like 'My First Sony^wVoipPhone' |
| 21:15.29 | Corydon76-dig | mvanbaak: and if something works with those phones... imagine how wow it works with any other phone |
| 21:15.38 | Corydon76-dig | s/wow/well/ |
| 21:15.47 | mvanbaak | Corydon76-dig: point taken |
| 21:16.04 | mvanbaak | you are right |
| 21:17.25 | putnopvut | snuff-work: I see what you mean now. |
| 21:17.41 | putnopvut | Yeah, they should just use %s and cmd. |
| 21:18.18 | snuff-work | figure i'd tell u since i'm just going through for doco |
| 21:19.09 | putnopvut | Cool. It's much appreciated. |
| 21:20.38 | mvanbaak | btw, what machine do you need for buildbot obsd ? |
| 21:20.45 | mvanbaak | I'm willing to maintain it |
| 21:20.53 | mvanbaak | and I have some hardware laying around |
| 21:23.39 | snuff-work | i've just checked size of my doxy patch.. 23k :) |
| 21:23.50 | Corydon76-dig | mvanbaak: well, one x86, one sparc, one PowerPC... |
| 21:24.05 | putnopvut | snuff-work: Impressive! |
| 21:24.07 | mvanbaak | I can donate the X86 |
| 21:24.12 | Corydon76-dig | We're already covered on the x86, actually |
| 21:24.22 | Corydon76-dig | mvanbaak: virtual machines |
| 21:24.26 | russellb | we don't have openbsd on the buildbot though ... |
| 21:24.37 | mvanbaak | Corydon76-dig: no obsd on the buildbot |
| 21:24.48 | file | it's on my list, but sruffell's requests trump it |
| 21:24.49 | Corydon76-dig | Wouldn't be a big deal to add... |
| 21:24.55 | russellb | if we have obsd on the server, it should be easy to add |
| 21:24.59 | russellb | dunno if it's there though |
| 21:25.00 | file | if anyone else wants to... feel free |
| 21:25.18 | Qwell | not it! |
| 21:25.27 | mvanbaak | like I said: I can imagine you dont want to get into obsd |
| 21:25.28 | russellb | not it |
| 21:25.31 | Qwell | though I would be more than happy to help, if somebody would like :D |
| 21:25.32 | mvanbaak | and I can manage it |
| 21:25.50 | russellb | buildbot isn't accessible on the intarweb :( |
| 21:25.55 | mvanbaak | obsd is the biggest part of my realtime job |
| 21:26.05 | mvanbaak | s/realtime/daytime/ |
| 21:27.35 | Corydon76-dig | russellb: when destroying the SIP channel, is there a reason that we unlink the channel from the sip pvt AFTER we destroy RTP structures, instead of before? |
| 21:28.08 | russellb | not a good one, no |
| 21:28.41 | russellb | of course the pvt lock should be able to be used to make sure that's not a problem either way |
| 21:29.31 | Corydon76-dig | We have a race |
| 21:29.37 | Corydon76-dig | M11960 |
| 21:29.38 | MuffinMan | [new] [Asterisk] Channels/chan_sip/Interoperability 0011960: Call from '' to extension '7104' rejected because extension not found reported by norman http://bugs.digium.com/view.php?id=11960 |
| 21:29.44 | Qwell | M11980 |
| 21:29.45 | MuffinMan | [new] [Asterisk] General 0011980: 'sip show registry' shows wrong registration reported by rbrunka http://bugs.digium.com/view.php?id=11980 |
| 21:29.57 | Qwell | missing the first char of one of the lines...didn't we fix that? |
| 21:30.23 | putnopvut | citats did some work with that but I can't remember how that ended. |
| 21:30.26 | mvanbaak | Qwell: that's what I thought |
| 21:30.39 | Qwell | hmm |
| 21:30.59 | Qwell | citats: ping? |
| 21:31.00 | Qwell | (does he ever talk on here?) |
| 21:31.06 | mvanbaak | nope |
| 21:33.56 | russellb | yeah, there was a previous bug about that, citats fixed it |
| 21:34.02 | Corydon76-dig | Well, looks like my new machine will be gadolinium |
| 21:34.29 | Qwell | anybody recall what the summary of that other bug was? having trouble searching for it |
| 21:35.03 | putnopvut | Sorry, I can't remember. |
| 21:35.10 | putnopvut | Can you search by who it's assigned to? |
| 21:35.13 | Qwell | let's see |
| 21:35.41 | Qwell | M9325 |
| 21:35.43 | MuffinMan | [closed] [Asterisk] Channels/chan_sip/General 0009325: After some time Sip show peers cut 1 symbol (first) reported by slavon http://bugs.digium.com/view.php?id=9325 |
| 21:35.48 | Qwell | putnopvut++ |
| 21:35.51 | Qwell | jbot: putnopvut++ |
| 21:36.07 | Qwell | oej fixed it apparently |
| 21:36.12 | mvanbaak | that was on osx right ? |
| 21:36.38 | russellb | oej committed it |
| 21:36.40 | russellb | it was james' pathc |
| 21:36.43 | Qwell | ahh |
| 21:36.51 | *** join/#asterisk-dev fakhir (n=fakhir@unaffiliated/fakhir) |
| 21:36.54 | Qwell | ...1.4 |
| 21:37.01 | Qwell | didn't get fixed :( |
| 21:37.12 | russellb | lame!!!! |
| 21:37.35 | mvanbaak | lol |
| 21:40.29 | mvanbaak | we are not going to fix strcpy and strcat right ? |
| 21:40.44 | russellb | there are some valid uses of it |
| 21:40.52 | russellb | so no, we're not changing them all |
| 21:40.56 | mvanbaak | yeah, that's what I remembered |
| 21:41.07 | Qwell | I'm gonna see if that patch applies to 1.4, and point the guy in 11980 to it |
| 21:41.23 | mvanbaak | utils/frame.c line 381 and line 1000 |
| 21:41.37 | russellb | patch is trivial |
| 21:41.41 | Qwell | wow, it applies |
| 21:50.49 | *** part/#asterisk-dev simbol76 (n=simbol@79.35.226.242) |
| 22:08.01 | kpfleming | catching up on asterisk-users mail (yeah, i read that), brings to mind a possible improvement in chan_iax2 |
| 22:08.05 | putnopvut | So with regards to the system IMAP configure change that was discussed yesterday, does anyone know the Ubuntu package that corresponds to the system IMAP? |
| 22:08.50 | kpfleming | people are concerned about the IAX2 NEW packet being unencrypted when encryption is going to be used, but IAX2 supports sending the dialed-number and other IEs later, after the NEW packet |
| 22:09.28 | kpfleming | so maybe we could *always* send a minimal NEW when encryption is in use, and delay sending the details of the call until after encryption has been negotiated and the channel is secure |
| 22:10.02 | jsmith | kpfleming: Sounds good to me |
| 22:10.05 | mvanbaak | kevin: |
| 22:10.07 | mvanbaak | http://pastebin.ca/901745 |
| 22:10.36 | kpfleming | that was for putnopvut, not me |
| 22:11.03 | mvanbaak | sorry |
| 22:11.08 | mvanbaak | putnopvut: http://pastebin.ca/901745 |
| 22:11.15 | Juggie | kpfleming: sounds good, except its likely invitable that somewhere there is code, be it a softphone, or a iax2 hard phone, etc.. which will break on that change. |
| 22:11.29 | putnopvut | mvanbaak: yeah, I did an apt-cache search for imap, but none of the packages seemed to be correct. |
| 22:11.34 | kpfleming | as long as we don't change the spec, nothing should break |
| 22:12.08 | Qwell | putnopvut: on debian it was like libc-client2007 |
| 22:12.15 | Qwell | well, presumably |
| 22:12.26 | Juggie | kpfleming: well yeah, the change does not fall outside spec which is fine, just there is likely some iax2 code out there that implemented it not completly correctally... which of course is not asterisk's fault... just saying :) |
| 22:12.27 | putnopvut | That's actually not the correct one. |
| 22:12.44 | Juggie | kpfleming: i would go for it though. |
| 22:12.46 | kpfleming | Juggie: true |
| 22:12.49 | putnopvut | Qwell: either that or the trunk code is just wrong. |
| 22:14.19 | tzafrir | libc-client-dev (virtual package) in recent enough versions of that package |
| 22:14.35 | putnopvut | Hmm, then I think the trunk code is a bit off. |
| 22:14.43 | tzafrir | libc-client2007-dev , specifically |
| 22:14.50 | putnopvut | Because trunk looks for <imap/mail.h> |
| 22:14.50 | tzafrir | (now that we're in 2008) |
| 22:15.12 | putnopvut | But libc-client2007-dev installs the headers in the c-client directory, not imap. |
| 22:15.37 | putnopvut | Oh, and the versions of the c-client are consistently one year behind the current year. |
| 22:15.44 | Juggie | kpfleming: it might not be a bad idea to offer some sort of secondary option to do the old encryption behaviour, should there be any misbehaving iax2 endpoints. |
| 22:15.48 | putnopvut | imap-2007 was released in December of last year. |
| 22:16.05 | Corydon76-dig | Why couldn't they have gone with a sensible name, like libuwimapclient? |
| 22:16.13 | kpfleming | Juggie: yeah, thinking about that... 'delayencyrpteddial' or something like that |
| 22:16.44 | putnopvut | Corydon76-dig: because it wouldn't be as much of a challenge then? |
| 22:16.59 | russellb | i don't know of _any_ other implementations of iax2 encryption |
| 22:17.03 | joetester | putnopvut knows his crispin. |
| 22:17.08 | russellb | i wouldn't complicate configuration with making it optional |
| 22:17.19 | Juggie | kpfleming: that sounds perfect. |
| 22:17.23 | tzafrir | in Debian I see that it is under the directory /usr/include/c-client |
| 22:17.32 | putnopvut | Yeah, same on ubuntu. |
| 22:18.04 | putnopvut | So the #includes should actually be #include <c-client/mail.h>, etc. |
| 22:18.20 | Qwell | 2006 probably used imap |
| 22:18.44 | putnopvut | Oh dear god... |
| 22:19.10 | putnopvut | I hope that's not the case. |
| 22:19.33 | putnopvut | I guess we could implement some configure magic to see where the system imap headers are? |
| 22:20.17 | kpfleming | that is what --with-imap is for |
| 22:24.11 | tzafrir | I checked a number of debian packages of various versions and they were all /usr/include/c-client . |
| 22:24.29 | tzafrir | Now this could be something of the Debian packagers... |
| 22:24.57 | tzafrir | look for imap in http://snapshot.debian.net/cgi-bin/packages.cgi |
| 22:25.03 | kpfleming | packaging c-client at all is a scary prospect |
| 22:25.11 | kpfleming | there are lots of compile-time options |
| 22:25.12 | tzafrir | and specifically http://snapshot.debian.net/archive/2007/08/23/debian/pool/main/u/uw-imap/ |
| 22:25.48 | putnopvut | kpfleming: I'm trying to backport the --with-imap=system functionality from trunk. |
| 22:25.56 | kpfleming | oh |
| 22:26.02 | kpfleming | any particular reason? |
| 22:26.07 | putnopvut | I was voluntold. |
| 22:26.38 | kpfleming | is there something that it does that cannot be done by the user just specifying the proper path to the configure script? |
| 22:26.40 | putnopvut | But in doing so, I found that my c-client headers are not in /usr/include/imap, like trunk uses. |
| 22:26.47 | putnopvut | They're in /usr/include/c-client. |
| 22:27.00 | kpfleming | who did the changes in trunk? |
| 22:27.18 | putnopvut | It was issue 10047 on the bugtracker. |
| 22:27.39 | putnopvut | Patch was submitted by the reporter of that issue. |
| 22:27.43 | kpfleming | but anyway... what is the reason this needs to be backported? |
| 22:28.14 | putnopvut | I'm still not 100% sure why, myself. It was discussed in here yesterday and the other developers came to the conclusion that it should be. |
| 22:28.30 | putnopvut | And so I got to work on it. |
| 22:28.35 | Qwell | it doesn't appear to build correctly unless you have the sources at ../imap-2004g/ |
| 22:28.44 | putnopvut | Qwell: you have to specify the directory |
| 22:28.47 | kpfleming | or you tell it where the sources are |
| 22:28.52 | kpfleming | that is how it has always been |
| 22:28.53 | putnopvut | --with-imap=/path/to/my/imap/stuff |
| 22:29.04 | kpfleming | and is the normal mode of operation for c-client, as that library was never intended to be 'packaged' |
| 22:29.16 | putnopvut | If you put --with-imap it will assume you have ../imap-2004g installed |
| 22:29.24 | russellb | why can't c-client be packaged? |
| 22:29.28 | russellb | i mean, it is packaged ... |
| 22:29.42 | russellb | the trunk version of the check lets you build against system installed versions |
| 22:29.52 | jsmith | Yeah, it's about time ;-) |
| 22:29.53 | russellb | which seems to be a reasonable expectation for any library for a number of reasons |
| 22:30.13 | kpfleming | i did not say it can't be packaged, i said the producers of the library didn't intend for it to be |
| 22:30.15 | putnopvut | russellb: right, but I'm saying that what's in trunk may be looking in the wrong place for the headers based on what distro you use. |
| 22:30.24 | kpfleming | for example, until recently it didn't have the ability to build an .so at all |
| 22:30.25 | russellb | including the most important one for network access libraries, which is security issues |
| 22:30.39 | kpfleming | and there are important compile time options that get chosen |
| 22:31.14 | kpfleming | so because it was never intended to be packaged, the packages that are out there are not going to be consistent |
| 22:31.55 | kpfleming | russellb: here is the most obvious indication that the library maintainers did not intend for this to be packaged... it doesn't even *have* an 'make install' target |
| 22:32.01 | kpfleming | it's not intended to be installed and shared |
| 22:32.05 | russellb | most packages aren't consistent, distros patch stuff, etc ... but you have a better chance of getting a known result from a package versus building it yourself |
| 22:32.18 | russellb | well ... |
| 22:32.38 | russellb | to answer the question directly, the discussion was about backporting the ability to build against system installed libs, which i think is reasonable |
| 22:32.44 | russellb | now, if that's bad to have .... |
| 22:32.53 | russellb | we have 2 options IMO ... backport it ... or remove it completely |
| 22:33.00 | russellb | no reason to have it in trunk but not 1.4 |
| 22:33.07 | russellb | i don't really care either way |
| 22:33.34 | jpeeler | what's the policy for submitted patches not applying/not compiling |
| 22:33.34 | kpfleming | that i would agree with |
| 22:33.53 | putnopvut | jpeeler: is it an old patch or something? |
| 22:34.00 | jpeeler | not too old |
| 22:34.19 | kpfleming | so let's get a representative sample of various common distros and see how hard it would be to make --with-imap=system work on all of them |
| 22:34.30 | putnopvut | jpeeler: You can just tell them to update their patch so it will apply now. |
| 22:34.31 | jpeeler | putnopvut: couple weeks |
| 22:34.35 | kpfleming | jpeeler: depends also on the reason it doesn't apply |
| 22:34.59 | kpfleming | if it's because of formatting changes or something else minor that doens't affect the code, just update the patch and apply it |
| 22:35.14 | jpeeler | well i did merge the changes manually |
| 22:35.20 | kpfleming | but if the code has changed in some substantial way then it may be better to have the contributor update the patch |
| 22:35.43 | jpeeler | so i'm seeing if i can get it to compile, but if i can't then i guess i'll do that |
| 22:35.50 | kpfleming | right |
| 22:36.27 | putnopvut | kpfleming: I think that an extra check can be put in the configure script to see where the system imap installation is, if they're using a package. |
| 22:36.53 | putnopvut | I think that's all that's necessary here, then depending on where it is, we know where to look for the header files. |
| 22:37.03 | kpfleming | where 'what' is? |
| 22:37.15 | putnopvut | In this case, the header files. |
| 22:37.22 | kpfleming | that sounds redundant |
| 22:37.38 | kpfleming | if they say 'use the system version', follow the same logic we do for --with-gsm=system |
| 22:37.46 | kpfleming | look in the most standard place, and if it's not there, then punt |
| 22:37.50 | russellb | i think we have had this problem with some other lib(s) ... where the header location was not consistent |
| 22:37.52 | putnopvut | Gotcha. |
| 22:38.05 | putnopvut | Okay, now to figure out where the most common location is... |
| 22:38.11 | kpfleming | you may need to look in two directories under that common location |
| 22:38.16 | russellb | ah, GSM is one of them, yeah |
| 22:38.26 | tzafrir | is it in Fedora? SUSE? |
| 22:38.31 | kpfleming | but having to change the #include statements in the code would be very bad |
| 22:38.48 | putnopvut | I'll look at the gsm logic. |
| 22:39.10 | tzafrir | any fedora equivalent to packages.debian.org ? |
| 22:39.10 | russellb | kpfleming: i did that in codec_gsm i think :( |
| 22:39.18 | kpfleming | ugh |
| 22:39.31 | russellb | used a define from configure to determine which path to include |
| 22:39.35 | russellb | gsm.h or gsm/gsm.h |
| 22:40.15 | kpfleming | oh well |
| 22:40.20 | kpfleming | the precedent has been set |
| 22:40.35 | kpfleming | we could have HAVE_IMAP_INCLUDE or HAVE_C-CLIENT_INCLUDE i gues |
| 22:41.05 | putnopvut | Yeah assuming those are the two most common places for them. |
| 22:41.10 | russellb | yeah, doubt any other places are used |
| 22:41.32 | putnopvut | The problem is that aside from the patch on 10047, I don't know what distros use the imap directory for the headers? |
| 22:41.35 | jsmith | tzafrir: http://www.fedoratracker.org/ |
| 22:42.19 | tzafrir | hmmm... I can't find any place we patch the #include line for <c-client.h> |
| 22:43.39 | tzafrir | we only patch autoconf/configure |
| 22:43.56 | russellb | then you must add CFLAGS |
| 22:44.05 | russellb | so that it finds it in the right place ... |
| 22:44.54 | tzafrir | hmm... in 1.4 there is: |
| 22:45.07 | tzafrir | #include "c-client.h" |
| 22:45.07 | tzafrir | #include "imap4r1.h" |
| 22:45.16 | tzafrir | that's in app_voicemail.c |
| 22:46.26 | putnopvut | Right, that's if you have specified where the imap-installation is. |
| 22:46.43 | putnopvut | If you look in trunk, there's a USE_SYSTEM_IMAP define that will look in <imap/c-client.h> etc. |
| 22:49.18 | tzafrir | the thing is, that the simple patch from http://bugs.digium.com/view.php?id=10813 works |
| 22:49.34 | tzafrir | (without adding <>-s) |
| 22:49.43 | lmadsen | evening all! |
| 22:49.57 | tzafrir | I figure some autoconf macro adds to CFLAGS |
| 23:00.08 | paravoid | I am the only one that can see a different issue? |
| 23:00.13 | putnopvut | M10813 |
| 23:00.14 | MuffinMan | [closed] [Asterisk] Core/BuildSystem 0010813: Should be able to dynamically link against libc-client for IMAP storage reported by paravoid http://bugs.digium.com/view.php?id=10813 |
| 23:00.20 | paravoid | --with-imap=/foo/bar should be ok |
| 23:00.25 | paravoid | and *not* link statically |
| 23:00.33 | paravoid | --with-imap=system is ambiguous |
| 23:00.46 | kpfleming | it should only link statically if there is no .so available |
| 23:00.51 | paravoid | does it mean use the development headers from the system or does it mean link dynamically? |
| 23:00.57 | paravoid | kpfleming: well, yes, of course |
| 23:01.10 | paravoid | the issue here is |
| 23:01.10 | kpfleming | those should be separate options to ./configure |
| 23:01.29 | paravoid | Debian does: |
| 23:01.35 | paravoid | <PROTECTED> |
| 23:01.35 | paravoid | <PROTECTED> |
| 23:01.35 | paravoid | <PROTECTED> |
| 23:01.35 | paravoid | <PROTECTED> |
| 23:01.44 | paravoid | none of these should be linked statically |
| 23:01.55 | paravoid | currently, only imap is |
| 23:01.57 | paravoid | (without our patch) |
| 23:02.21 | paravoid | and from what I've understand, this is fixed in trunk with --with-imap=system |
| 23:02.28 | kpfleming | unless --disable-shared is used |
| 23:02.36 | paravoid | which links dynamically but also requires that the headers are in a specific location |
| 23:02.52 | paravoid | why can't I set an arbitrary location of the headers but still link dynamically? |
| 23:03.08 | paravoid | hardcoding all the possible combinations doesn't exactly seem like a good solution to me |
| 23:03.11 | kpfleming | because we never supported dynamic linking to this stuff before |
| 23:03.15 | paravoid | (not my call though :) |
| 23:03.31 | paravoid | kpfleming: and that was a bug, imho |
| 23:03.33 | kpfleming | remember, this library was never designed to be installed on the system and shared |
| 23:03.43 | kpfleming | only distro packagers have made that happen |
| 23:03.54 | jsmith | FWIW, Fedora does: --with-imap=system --with-gsm=/usr |
| 23:04.18 | kpfleming | i'm fine with dynamic linking if --with-imap=system was specified |
| 23:04.44 | kpfleming | if we are using a direct source build, dynamic linking isn't an option anyway |
| 23:04.50 | paravoid | kpfleming: =system means two different things there |
| 23:05.13 | kpfleming | but that is normal for configure scripts |
| 23:05.22 | paravoid | that doesn't leave a way to specify the hearder locations AND dynamically link |
| 23:05.29 | kpfleming | true |
| 23:05.44 | paravoid | which kinda sucks, since there isn't a standard location for the headers |
| 23:05.51 | kpfleming | so that would mean that the configure script should try to dynamically lnk and fall back to static |
| 23:06.14 | kpfleming | or... if the with-imap location is clearly a source checkout and not just headers, then static link, otherwise dynamic |
| 23:06.22 | paravoid | ...and that the configure script should try all possible headers locations |
| 23:06.38 | kpfleming | there are only two we've found so far |
| 23:06.48 | kpfleming | /usr/include/c-client and /usr/include/imp |
| 23:06.52 | kpfleming | crap... can't type |
| 23:06.55 | kpfleming | s/imp/imap/ |
| 23:07.16 | paravoid | (fwiw, I would choose /usr/include/uw-imap...) |
| 23:07.22 | kpfleming | me too |
| 23:07.58 | paravoid | well |
| 23:08.01 | paravoid | yeah, that would work |
| 23:08.17 | paravoid | and it seems like a reasonable solution, even tough I don't like ambiguous configuration options |
| 23:08.17 | kpfleming | my last suggestion? |
| 23:08.50 | paravoid | I'd vote with --with-imap=/foo/bar should link dynamically, if there's a .so and --disable-shared is not passed |
| 23:08.56 | paravoid | but this changes existing behavior |
| 23:09.05 | paravoid | and may not be suitable for 1.4 at least |
| 23:09.11 | kpfleming | we dont have to worry about --disable-shared, i don't think we even pay attention to that right now |
| 23:09.23 | kpfleming | and there won't be a .so in a source build |
| 23:09.41 | kpfleming | so it should be backward compatible |
| 23:10.23 | paravoid | well yeah, but you could have a distribution's package installed and a source tarball extracted |
| 23:10.37 | kpfleming | that should not be a problem |
| 23:10.48 | putnopvut | Right, since you have to specify the location of the source. |
| 23:11.02 | paravoid | location of the source != location of the library :) |
| 23:11.14 | putnopvut | How true. |
| 23:11.28 | kpfleming | so the logic would be that if they specify 'system', do the simple checks for common header locations, and dynamically link |
| 23:11.39 | kpfleming | don't use a source build, even if one happens to be around |
| 23:11.39 | paravoid | you could use headers from ~/uw-imap/ but -lc-client would dynamically link against /usr/lib/libc-client.so if found |
| 23:12.24 | kpfleming | not if we specify -L~/uw-imap on the command line to the linker |
| 23:12.33 | paravoid | kpfleming: I don't disagree with that, feels a little weird though |
| 23:12.57 | paravoid | that passing --with-imap=/usr/include has a different behavior than --with-imap=system |
| 23:13.06 | paravoid | hm |
| 23:13.14 | paravoid | and what about --with-imap, without an argument? |
| 23:13.16 | kpfleming | why would it? it shouldn't |
| 23:13.34 | kpfleming | with no argument it should look for a source build like we always did, and fall back to 'system' if that works |
| 23:13.37 | paravoid | yes it would, the first will statically link, the second will link dynamically |
| 23:13.42 | kpfleming | no |
| 23:13.46 | kpfleming | you didnt listen |
| 23:13.53 | paravoid | no? |
| 23:13.56 | paravoid | ok, sorry. |
| 23:14.09 | kpfleming | the only time we would ever statically link is if the path supplied to --with-imap is *known* to be a source build, not just a directory of headers |
| 23:14.19 | paravoid | how would you know that? |
| 23:14.22 | kpfleming | or if there is no .so around, but we don't control that |
| 23:14.24 | kpfleming | look for a magic file |
| 23:14.33 | paravoid | ahhh |
| 23:14.36 | paravoid | that makes more sense |
| 23:14.43 | paravoid | sure, sounds reasonable |
| 23:14.55 | paravoid | look for a .c file basically |
| 23:15.18 | kpfleming | or something like that |
| 23:15.46 | kpfleming | something we can rely on being there no matter what version of the toolkit is there (that we support) |
| 23:16.45 | paravoid | great, yet another patch dropped from our distribution :) |
| 23:17.34 | paravoid | fixing the dynamic loader and rewriting safe_asterisk in C |
| 23:17.38 | paravoid | ...properly :) |
| 23:19.09 | tzafrir | regarding safe_asterisk: someone recently mentioned making asterisk -rx only answer after module initialization is complete |
| 23:21.42 | kpfleming | M10047 |
| 23:21.43 | MuffinMan | [closed] [Asterisk] Core/General 0010047: Allow linking against system IMAP library reported by jcollie http://bugs.digium.com/view.php?id=10047 |
| 23:21.56 | paravoid | M10813 |
| 23:21.57 | MuffinMan | [closed] [Asterisk] Core/BuildSystem 0010813: Should be able to dynamically link against libc-client for IMAP storage reported by paravoid http://bugs.digium.com/view.php?id=10813 |
| 23:22.14 | paravoid | wasn't aware of the first when i reported it, sorry. |
| 23:24.00 | tzafrir | if you can ask asterisk for the status of the startup and only get it when modules have ended loading (block till then), it simplifies error handling |
| 23:35.31 | kpfleming | tzafrir: someone will have to define what 'finished loading' means |
| 23:35.36 | kpfleming | it's not obvious, in case you think it is |
| 23:36.13 | tzafrir | all modules initialization run? |
| 23:36.17 | kpfleming | nope |
| 23:36.34 | kpfleming | for example, you might not be able to place SIP calls out through your provider until you have registered to them |
| 23:36.37 | tzafrir | this is the place where asterisk might get easily killed on startup |
| 23:38.15 | tzafrir | proper functioning of the module (after its initialization fuction exited) is of less interest to me |
| 23:38.24 | tzafrir | It probably won't kill Asterisk |
| 23:38.41 | kpfleming | well, with the support for cli.conf in trunk, you could just run some command to generate a log message, or a userevent, or dump some text to a file |
| 23:38.53 | kpfleming | that won't happen until module loading is complete |
| 23:39.27 | tzafrir | the original motivation for that was different: |
| 23:40.11 | tzafrir | a script that stops asterisk and starts asterisk and then checks the version with asterisk -rx 'core show version' |
| 23:40.59 | tzafrir | And if the command 'core show version' is not available, tries again: "show version" |
| 23:41.12 | tzafrir | and believes it has asterisk 1.2 |
| 23:41.28 | tzafrir | (running it immediately after startup was my smartness) |
| 23:41.29 | kpfleming | i have no idea what you are talking about |
| 23:41.45 | kpfleming | so just have asterisk tell you when it is done starting up |
| 23:41.55 | kpfleming | oh, you want this to work on old versions... sorry |
| 23:41.58 | kpfleming | no way that i can think of |
| 23:42.16 | tzafrir | with the right timing, the first asterisk -rx happens before "core show version" is registered |
| 23:43.37 | tzafrir | I was trying to think how can I use -rx relibly without excessive sleeps |
| 23:44.31 | kpfleming | i don't think you can |
| 23:44.34 | tzafrir | after all modules have loaded, I'm guaranteed to have all the commands (for -rx, for the manager, whatever) |
| 23:45.04 | tzafrir | and no: I don't think that this is something to be added to 1.4 |
| 23:45.56 | Corydon76-dig | You could potentially delay the Manager response while loads and reloads are happening |
| 23:46.31 | Corydon76-dig | Say, if the first thing the manager thread does is a sleep(2) or something like that |
| 23:47.39 | kpfleming | well, if you are fine with this being 1.6/trunk only, then you already have what you need |
| 23:47.49 | tzafrir | Is it possible that a module would try to access the manager as part of its initialization? |
| 23:48.04 | Corydon76-dig | Shouldn't, no |
| 23:48.27 | Corydon76-dig | It's possible that some third party module might, though |
| 23:48.38 | Corydon76-dig | Although that's the height of silliness |
| 23:49.26 | tzafrir | all the new "binding" stuff, how does it run? |
| 23:50.28 | tzafrir | kpfleming, you mean through cli.conf? |
| 23:50.34 | kpfleming | yes |