| 02:29.08 | *** join/#asterisk-dev philipp64|laptop (~chatzilla@mail.redfish-solutions.com) |
| 02:47.27 | *** join/#asterisk-dev philipp64 (~chatzilla@mail.redfish-solutions.com) |
| 03:26.03 | *** join/#asterisk-dev ApOgEE (apogee@gateway/shell/bshellz.net/x-zkzchibtiuocrrfn) |
| 03:52.42 | *** join/#asterisk-dev DarkRift (~dark@modemcable219.40-56-74.mc.videotron.ca) |
| 04:01.52 | *** part/#asterisk-dev Netgeeks (~chris@gw1.netgeeks.net) |
| 06:17.03 | *** join/#asterisk-dev mpe (~mpe@gate.ipvision.dk) |
| 06:21.54 | *** join/#asterisk-dev hehol (~hehol@buero-gw.dortmund.loca.net) |
| 07:04.37 | *** join/#asterisk-dev tzafrir_laptop (~tzafrir@local.xorcom.com) |
| 07:04.37 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 07:38.04 | *** join/#asterisk-dev Dovid (~annon@213.8.118.62) |
| 08:05.13 | *** join/#asterisk-dev CoderForLife (~Miranda@cpe-174-101-155-51.cinci.res.rr.com) |
| 08:08.55 | *** join/#asterisk-dev ivaxer (~ivaxer@palevo.sgu.ru) |
| 09:14.29 | *** join/#asterisk-dev mboehn (mathias@mboehn.alfa-skk.pr0jectX.net) |
| 09:16.52 | *** join/#asterisk-dev Qwell (~north@pdpc/sponsor/digium/Qwell) |
| 09:16.52 | *** mode/#asterisk-dev [+o Qwell] by ChanServ |
| 09:18.38 | *** join/#asterisk-dev CoderForLife (~Miranda@cpe-174-101-155-51.cinci.res.rr.com) |
| 09:18.38 | *** join/#asterisk-dev ApOgEE (apogee@gateway/shell/bshellz.net/x-zkzchibtiuocrrfn) |
| 09:18.38 | *** join/#asterisk-dev seanbright (~sean@asterisk/contributor-and-bug-marshal/seanbright) |
| 09:18.38 | *** join/#asterisk-dev xbp (~pbx@irc.wastate.net) |
| 09:18.39 | *** mode/#asterisk-dev [+o seanbright] by anthony.freenode.net |
| 09:31.36 | *** join/#asterisk-dev frawd (~francois@83.39.70.194) |
| 10:21.19 | *** join/#asterisk-dev michael-i (~michael-i@141.41.40.121) |
| 11:19.56 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 11:19.56 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 11:25.20 | *** join/#asterisk-dev guilhermebr (~Guilherme@189.50.119.172) |
| 11:29.10 | *** join/#asterisk-dev snuff-home (~snuffy@203-219-29-182.tpgi.com.au) |
| 11:29.10 | *** mode/#asterisk-dev [+o snuff-home] by ChanServ |
| 11:37.36 | *** join/#asterisk-dev Qwell (~north@pdpc/sponsor/digium/Qwell) |
| 11:37.36 | *** mode/#asterisk-dev [+o Qwell] by ChanServ |
| 12:10.36 | *** join/#asterisk-dev tamiel (~tamiel@213.30.183.226) |
| 12:12.00 | *** join/#asterisk-dev pabelanger-lap (~pabelange@CPE001fe2a8fd1d-CM0012254094b2.cpe.net.cable.rogers.com) |
| 12:23.18 | *** join/#asterisk-dev Dovid (~annon@213.8.118.62) |
| 12:41.30 | *** join/#asterisk-dev Pazzo (~ugelt@reserved-225136.rol.raiffeisen.net) |
| 12:57.53 | *** join/#asterisk-dev akshayb (8ccbd68e@gateway/web/freenode/ip.140.203.214.142) |
| 13:08.06 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 13:08.06 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 13:23.30 | *** join/#asterisk-dev rrb3942 (~rbullock@208.34.105.161) |
| 13:41.15 | *** join/#asterisk-dev n0tk (~n0tk@216.160.42.30) |
| 13:50.13 | *** join/#asterisk-dev rrb3942 (~rbullock@208.34.105.161) |
| 13:54.39 | *** join/#asterisk-dev minaguib (~mina@modemcable109.56-20-96.mc.videotron.ca) |
| 13:55.07 | *** join/#asterisk-dev jeffg (~jeffg@pdpc/supporter/professional/jeffg) |
| 14:01.13 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 14:01.13 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 14:03.10 | *** join/#asterisk-dev jpeeler (~jpeeler@asterisk/developer/jpeeler) |
| 14:03.10 | *** mode/#asterisk-dev [+o jpeeler] by ChanServ |
| 14:08.27 | *** join/#asterisk-dev hugorebelo (~hugo@200-171-132-124.completo.com.br) |
| 14:22.14 | pabelanger-lap | Anybody know how portable 'getent' is? |
| 14:27.17 | tzafrir_laptop | pabelanger, hmm... busybox does not have it. Does this imply uclibc doesn't have it? |
| 14:27.22 | *** join/#asterisk-dev bklang (~bklang@tesla.alkaloid.net) |
| 14:27.40 | *** join/#asterisk-dev GuilhermeBR (~Guilherme@200.103.96.98) |
| 14:35.11 | *** join/#asterisk-dev edguy3 (~edguy@c-98-221-27-224.hsd1.nj.comcast.net) |
| 14:42.32 | *** join/#asterisk-dev jpeeler1 (~jpeeler@nat/digium/x-prjubpyrrlgzyiaq) |
| 14:45.38 | *** join/#asterisk-dev sgimeno (~chatzilla@164.Red-83-36-101.dynamicIP.rima-tde.net) |
| 14:45.38 | *** join/#asterisk-dev The_Boy_Wonder (~vossel@asterisk/batman-developer/dvossel) |
| 14:45.38 | *** mode/#asterisk-dev [+o The_Boy_Wonder] by ChanServ |
| 14:46.14 | *** join/#asterisk-dev moy (~moy@UNVLON55-1176057127.sdsl.bell.ca) |
| 14:55.12 | jpeeler1 | <PROTECTED> |
| 14:55.15 | jpeeler1 | nice |
| 14:56.01 | kpfleming | jpeeler: you should join us in #2,000 ... lots of fun conversation <G> |
| 14:58.19 | russellb | oh man, I love that channel |
| 14:58.29 | russellb | everyone should join, in fact |
| 14:58.32 | jpeeler | yeahhhhhhhhhh |
| 14:59.29 | leifmadsen | burn |
| 15:02.19 | *** join/#asterisk-dev datachomper (~Adium@nat/digium/x-xjeibyzoylnggcvb) |
| 15:04.32 | *** join/#asterisk-dev elguero (~miguel323@ns1.nashuacs.com) |
| 15:09.48 | *** join/#asterisk-dev philipp64|laptop (~chatzilla@mail.redfish-solutions.com) |
| 15:12.19 | *** join/#asterisk-dev rrb3942 (~rbullock@208.34.105.161) |
| 15:16.12 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 15:16.12 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 15:32.10 | *** join/#asterisk-dev marv (~timr@router.asteriasgi.com) |
| 15:33.24 | philipp64|laptop | dumb question... when building from trunk, what should .version and .revision contain? |
| 15:34.11 | russellb | nothing? |
| 15:34.13 | kpfleming | .version should not exist |
| 15:34.26 | *** join/#asterisk-dev snuff-work (~aaa@210.9.82.197) |
| 15:34.26 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 15:34.27 | kpfleming | if it does, none of the svn version logic will be used |
| 15:45.50 | *** join/#asterisk-dev caio1982 (~caio1982@CAcert-br/caio1982) |
| 15:48.18 | philipp64 | so I should use .svn |
| 15:48.30 | philipp64 | (I'm generating my own tarballs from svn) |
| 15:48.57 | kpfleming | there is a makefile target you can call to generate the version tag before producing the tarball |
| 15:49.14 | philipp64 | well, having a valid .svn file doesn't seem to help either. |
| 15:49.34 | philipp64 | I doubt it would work since the tarball has all of the .svn directories purged. |
| 15:50.20 | kpfleming | it has to be done *before* you make the tarball. if you didn't , how could you make a reasonable tarball name? |
| 15:51.04 | Kobaz | how do you detect within AGI if your channel got a hangup request... like if i do a channel request hangup on a local channel |
| 15:51.14 | philipp64 | svn info | awk -F': ' '/^Revision:/ { print $2}' |
| 15:51.34 | kpfleming | philipp64: just use the makefile target we already provide. there is no need to reinvent the wheel here. |
| 15:51.45 | philipp64 | what's the target? |
| 15:52.53 | philipp64 | I'm looking but not seeing it... |
| 15:53.11 | kpfleming | actually, you just have to run build_tools/make_version |
| 15:53.18 | kpfleming | and you'll have to tell it where GREP and AWK live |
| 15:53.19 | Kobaz | it doesn't seem like there is any information at all at the dialplan level, to see if your channel is hanging up |
| 15:55.43 | Kobaz | if you do a soft hangup/channel request hangup on a channel that's currently running fastagi, the agi will run indefinitly until it decides it's done (ie: asterisk isn't going to end it) |
| 15:56.10 | *** join/#asterisk-dev Netgeeks (~chris@gw1.netgeeks.net) |
| 15:58.19 | *** join/#asterisk-dev mpe (~mpe@0x4dd624b2.adsl.cybercity.dk) |
| 15:58.48 | Kobaz | what about adding a pbx_setvar to ast_softhangup_nolock() |
| 15:59.27 | Corydon76-dig | Kobaz: what about adding a dialplan function that checks the value of _softhangup? |
| 15:59.43 | Kobaz | that too |
| 15:59.49 | philipp64 | "svn export" strips away the .svn stuff, doesn't it? |
| 15:59.54 | Kobaz | philipp64: it does |
| 16:00.11 | philipp64 | so I need to use "svn checkout" instead... |
| 16:00.19 | Kobaz | yeap |
| 16:00.20 | Corydon76-dig | Kobaz: I'd suggest CHANNEL(softhangup) |
| 16:00.25 | Kobaz | Corydon76-dig: sounds good |
| 16:18.39 | *** join/#asterisk-dev jsmith (~jsmith@asterisk/training-and-documentation-guru/jsmith) |
| 16:18.39 | *** mode/#asterisk-dev [+o jsmith] by ChanServ |
| 16:20.09 | *** join/#asterisk-dev ecrane (~ecrane@o1-69-19-166-10.static.o1.com) |
| 16:22.23 | Kobaz | Corydon76-dig: not working... |
| 16:22.42 | Kobaz | Corydon76-dig: i'm trying to use _softhangup... and i also tried ast_check_hangup() |
| 16:22.46 | Kobaz | both are zero |
| 16:26.39 | Kobaz | lemme make some small test cases |
| 16:31.38 | Kobaz | heh... checking the wrong channel |
| 16:31.41 | Kobaz | it works nicely |
| 16:31.49 | Kobaz | i added CHANNEL(hangingup) |
| 16:32.02 | Kobaz | which uses ast_check_hangup |
| 16:33.13 | Corydon76-dig | I'd suggest CHANNEL(softhangup) |
| 16:33.18 | Kobaz | this is awesome |
| 16:33.33 | Kobaz | Corydon76-dig: yeah but it checks more than just _softhangup |
| 16:33.54 | Kobaz | it checks _softhangup and chan->whentohangup |
| 16:34.11 | Corydon76-dig | I'd still look for an alternate name |
| 16:34.21 | Kobaz | k |
| 16:34.37 | Kobaz | i'll switch it to softhangup if it has a better chance of being accepted |
| 16:34.49 | Corydon76-dig | softhangup or checkhangup |
| 16:34.55 | leifmadsen | I like checkhangup better |
| 16:35.16 | leifmadsen | we don't have the 'softhangup' CLI command anymore, so it might be like, "why softhangup" ? |
| 16:35.22 | Kobaz | yeah |
| 16:35.32 | Kobaz | i like checkhangup |
| 16:35.37 | Corydon76-dig | leifmadsen: we do, it's just been renamed |
| 16:35.38 | leifmadsen | checkhangup makes more sense based on what it's doing |
| 16:35.43 | leifmadsen | Corydon76-dig: ya ya |
| 16:35.52 | leifmadsen | channel request hangup |
| 16:35.57 | leifmadsen | does not mention "soft hangup" |
| 16:36.03 | leifmadsen | that's what I meant |
| 16:36.09 | Kobaz | but internally it's all softhangup |
| 16:36.14 | Kobaz | i think was corys point |
| 16:36.29 | leifmadsen | ah snap... non-root branch has the adsi compile issue in it |
| 16:36.31 | Kobaz | this is so cool... now my agi scripts can know when to exit |
| 16:36.40 | leifmadsen | Corydon76-dig: was that fixed and just hasn't merged yet? |
| 16:36.56 | Corydon76-dig | leifmadsen: It's an involved fix |
| 16:37.10 | leifmadsen | gotcha |
| 16:37.10 | Corydon76-dig | Basically, res_adsi will need to be loaded into the core |
| 16:45.55 | *** join/#asterisk-dev pabelanger-lap (~pabelange@CPE001fe2a8fd1d-CM0012254094b2.cpe.net.cable.rogers.com) |
| 16:47.22 | Kobaz | https://issues.asterisk.org/file_download.php?file_id=26668&type=bug |
| 16:48.26 | edguy3 | Hi ALL >> anyone seen this before: trunk/include/asterisk/options.h:102:56: error: operator '&&' has no right operand |
| 16:48.26 | edguy3 | looks related to a recent configure change... but, it is not obvious to me yet ??? |
| 16:48.54 | edguy3 | ( BTW, that is on a DAHDI line) |
| 16:49.17 | Qwell | edguy3: what branch is this? |
| 16:49.29 | edguy3 | trunk |
| 16:50.05 | Qwell | best I can suggest is to do a `make distclean` |
| 16:50.52 | edguy3 | failing line is |
| 16:50.54 | edguy3 | #if (defined(HAVE_DAHDI_VERSION) && HAVE_DAHDI_VERSION >= 230) |
| 16:51.08 | edguy3 | and HAVE_DAHDI_VERSION is simple |
| 16:51.19 | edguy3 | s/simple/simply |
| 16:51.36 | Qwell | well, that code is broken. if HAVE_DAHDI_VERSION isn't set, it'll still try to use it. the line would end up looking like |
| 16:51.37 | edguy3 | #define HAVE_DAHDI_VERSION |
| 16:51.47 | Qwell | #if (defined() && >= 230) |
| 16:52.58 | Corydon76-dig | Could change the second one to 0##HAVE_DAHDI_VERSION |
| 16:53.15 | Qwell | yeah, or just put it inside the #if block |
| 16:53.16 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 16:53.34 | Qwell | wait no, that wouldn't work quite right |
| 16:54.15 | Corydon76-dig | Oh, right, because gcc works with octal |
| 16:54.20 | Qwell | do we not use factors for version numbers for the HAVE_FOO_VERSION stuff? |
| 16:54.39 | Qwell | like major * 10000 + minor * 100, or...whatever |
| 16:54.50 | Corydon76-dig | Probably not |
| 16:55.00 | Qwell | if we ever make a 2.10.x, that will break |
| 16:55.27 | Corydon76-dig | Some things are already going to break once we hit Asterisk 1.10 |
| 16:56.02 | leifmadsen | maybe we should just roll back to Asterisk 1.1, 1.3, 1.5, 1.7, and 1.9 then |
| 16:56.10 | edguy3 | in configure, it appears pretty simple. Corydon76-dig's solution looks ok. Google gave me a complaint from user. |
| 16:56.11 | leifmadsen | that would give us a while longer to avoid 1.10 |
| 16:56.23 | Corydon76-dig | leifmadsen: that's even worse |
| 16:56.31 | Qwell | leifmadsen: by then, nobody will care about 1.0 or 1.2, so we can reuse them |
| 16:56.31 | leifmadsen | I'm obviously joking |
| 16:56.38 | leifmadsen | Qwell: exactly! |
| 16:56.53 | *** join/#asterisk-dev frawd (~francois@83.39.70.194) |
| 16:57.11 | edguy3 | ah, the beauty of version numbers: there are so many to choose from. |
| 16:58.22 | tzafrir_laptop | btw: will the version following 1.8 be 1.9 or 1.10? |
| 16:58.46 | Corydon76-dig | tzafrir_laptop: 1.10, most likely |
| 16:58.57 | tzafrir_laptop | Is the current trunk versioned as 1.7 anywhere? |
| 16:59.04 | Corydon76-dig | Nope |
| 16:59.17 | tzafrir_laptop | If not, what's the point of skipping 1.9? |
| 16:59.19 | edguy3 | well. thanks. that will get me past my build issue. I'll dig for the root cause later. ;-) |
| 16:59.26 | Corydon76-dig | tzafrir_laptop: tradition |
| 17:27.53 | *** join/#asterisk-dev crowbar7 (~Crowbar7@12.2.84.2) |
| 17:36.02 | *** join/#asterisk-dev CunningPike (~CunningPi@204.239.8.157) |
| 17:43.25 | *** join/#asterisk-dev jeffg (~jeffg@pdpc/supporter/professional/jeffg) |
| 17:47.54 | *** part/#asterisk-dev crowbar7 (~Crowbar7@12.2.84.2) |
| 17:48.51 | Qwell | pabelanger: shouldn't that be $(INSTALL)? |
| 17:51.53 | pabelanger-lap | Qwell: possible, checking |
| 17:52.31 | pabelanger-lap | Qwell: Yup, thanks |
| 18:10.01 | *** join/#asterisk-dev infobot (~infobot@rikers.org) |
| 18:10.01 | *** topic/#asterisk-dev is Topic for #asterisk-dev is: Asterisk Development Discussion -=- http://www.asterisk.org/developers -=- Tier 2 and 3.14159265 support is in #asterisk -=- IAX2 is now RFC 5456. |
| 18:29.05 | *** join/#asterisk-dev pabelanger-lap (~pabelange@CPE001fe2a8fd1d-CM0012254094b2.cpe.net.cable.rogers.com) |
| 18:33.57 | pabelanger-lap | Corydon76-dig: ping? |
| 18:35.13 | Corydon76-dig | pong |
| 18:35.30 | Corydon76-dig | pabelanger-lap: pong |
| 18:36.49 | pabelanger-lap | Corydon76-dig: Trying to come up with a _clean_ way to set permissions on /dev/dahdi. In the past, init.d script usually handle this. However, I was wondering is asterisk could handle that responsibility if runuser and/or rungroup are set? |
| 18:37.27 | Qwell | pabelanger: if Asterisk is running as asterisk, it can't set permissions |
| 18:38.14 | pabelanger-lap | Qwell: true, but if you run asterisk as root, and runuser and rungroup are enabled in the .conf file, asterisk will downgrade to those permission. If I understand correct |
| 18:38.16 | seanbright | well then you set the perms before dropping privileges |
| 18:38.59 | Corydon76-dig | Well, because the devices are themselves part of udev, it's better to get the permissions set in a udev config file |
| 18:39.23 | Corydon76-dig | Otherwise, the permissions/ownership could change back to the original at random intervals |
| 18:48.32 | tzafrir_laptop | pabelanger-lap, dahdi devices may re-appear after asterisk is started |
| 18:48.42 | tzafrir_laptop | It's not asterisk's job to set their permissions |
| 18:49.24 | Kobaz | i set dahdi permissions in the wanpipe startup scripts |
| 18:49.42 | tzafrir_laptop | Kobaz, udev rules. Clear and simple |
| 18:49.51 | Kobaz | that's probably better |
| 18:49.54 | Kobaz | never got around to learning udev |
| 18:50.07 | tzafrir_laptop | it's actually already there |
| 18:50.11 | Kobaz | other than deleting z70_persistant_net_rules when my ethernet devices change on me |
| 18:50.31 | tzafrir_laptop | grep for 'dahdi' |
| 18:50.38 | Kobaz | markm {/etc/udev} root# ack dahdi |
| 18:50.47 | Kobaz | markm {/etc/udev} root# |
| 18:52.21 | pabelanger-lap | tzafrir_laptop: Ya, udev maybe the option to go. The trick is to sync the permissions between asterisk and DAHDI. |
| 18:53.31 | tzafrir_laptop | pabelanger-lap, what do you mean by "sync"? |
| 18:54.49 | tzafrir_laptop | asterisk needs to have write permissings to the device files. No need for exact sync |
| 18:57.02 | Corydon76-dig | pabelanger-lap: so in 'make install', if dahdi was found as a dependency, ensure the udev rules permit the AST_USER rw permissions to the file |
| 18:57.22 | Corydon76-dig | Well, two files. |
| 18:57.28 | Corydon76-dig | ctl and pseudo |
| 18:57.54 | Corydon76-dig | Four. timer and transcode, too |
| 18:58.15 | Corydon76-dig | Heck, just do all five |
| 18:58.48 | tzafrir_laptop | hmm... pabelanger-lap are all of those tests really intended for the install script? |
| 18:59.04 | pabelanger-lap | Corydon76-dig: Ya, make sense. |
| 18:59.08 | tzafrir_laptop | Or maybe for a separate script to run post-install? |
| 18:59.20 | tzafrir_laptop | (as in the case of using a package) |
| 18:59.27 | pabelanger-lap | tzafrir_laptop: That is what I'm trying to figure out right now. |
| 18:59.33 | tzafrir_laptop | I wonder what is exactly the use-case you have in mind |
| 18:59.58 | Corydon76-dig | The use case is to run as non-root by default, clearly |
| 19:00.26 | Corydon76-dig | (like most daemons) |
| 19:00.36 | pabelanger-lap | and not have the end user not set any permissions by hand |
| 19:00.49 | Corydon76-dig | Err, double negative |
| 19:00.59 | tzafrir_laptop | well, looking at it from the narrow perspective of a packager, many of the changes there (like specifiying the root user) won't help me |
| 19:01.17 | pabelanger-lap | Corydon76-dig: Ya pretty bad at that lately |
| 19:01.35 | Corydon76-dig | tzafrir_laptop: because you're determining that at package install time? |
| 19:02.16 | tzafrir_laptop | mostly, yes |
| 19:02.19 | Corydon76-dig | tzafrir_laptop: btw, been meaning to ask you... is there a specific tool to use in Debian/Ubuntu to get the 'next available system-level uid'? |
| 19:02.39 | tzafrir_laptop | the asterisk user is only created at package install time |
| 19:03.03 | tzafrir_laptop | (though rpm has a way to save use names in packages, rather than UIDs) |
| 19:03.17 | Corydon76-dig | system-level uids seem to be created at package time, incremental order, not preassigned at package creation time |
| 19:03.26 | tzafrir_laptop | (deb doesn't) |
| 19:03.36 | pabelanger-lap | That's one of the main difference between the .deb package. We require the end-user to create the 'asterisk' uid/gid. Though a script could be used to create it. |
| 19:04.16 | tzafrir_laptop | the debian package does create that user, and chowns directories accordingly at postinst |
| 19:04.18 | Corydon76-dig | tzafrir_laptop: I'm thinking that's an extremely common task for a package... to create its own system user (which differs from end-user) |
| 19:04.46 | Corydon76-dig | i.e. in the range 50-500, rather than 1000+ |
| 19:04.54 | tzafrir_laptop | adduser --system |
| 19:04.59 | Corydon76-dig | Ah |
| 19:05.13 | tzafrir_laptop | Not sure how portable it is |
| 19:05.30 | *** join/#asterisk-dev guilhermebr (~Guilherme@ns2.aser.com.br) |
| 19:06.31 | pabelanger-lap | That would be an option, to setup asterisk as a system level account, automagicly. |
| 19:06.50 | pabelanger-lap | And have DAHDI follow suit. |
| 19:07.50 | tzafrir_laptop | In Debian (and also in Gentoo?) dahdi device files are in group 'comm' and asterisk is a member of that group |
| 19:08.11 | tzafrir_laptop | sorry: dialout |
| 19:09.54 | pabelanger-lap | tzafrir_laptop: If we could handle that outside package-management, I think we'd have a solution |
| 19:10.21 | tzafrir_laptop | "that' == ? |
| 19:10.31 | tzafrir_laptop | err... syntax error |
| 19:12.42 | tzafrir_laptop | pabelanger, what do you mean by "that"? |
| 19:13.52 | pabelanger-lap | tzafrir_laptop: having asterisk and dahdi, from source, add itself to 'comm' and 'dialout'. Like you handle postinstall with dpkg |
| 19:15.08 | tzafrir_laptop | well, the default udev rules in dahdi set the user and group to 'asterisk', actually... |
| 19:15.34 | pabelanger-lap | Or make asterisk smart enough to inherit the permissions from DAHDI, if it exists on the system. |
| 19:15.50 | pabelanger-lap | tzafrir_laptop: Oh, didn't know that. |
| 19:16.06 | pabelanger-lap | off to download and install latest DAHDI |
| 19:16.38 | *** join/#asterisk-dev guilhermebr (~Guilherme@200.175.156.198) |
| 19:22.54 | pabelanger-lap | tzafrir_laptop: Ok, maybe you can help with this. If you install DAHDI before the 'asterisk' uid/gid exist, it will default to root:root. However, if you install DAHDI after 'asterisk' uid/gid exist, udev will set permissions to asterisk:asterisk. |
| 19:23.58 | pabelanger-lap | tzafrir_laptop: Can you have udev reapply permissions to asterisk:asterisk after you create the uid/gid? Rather then, uninstalling / installing dahdi? |
| 19:24.22 | pabelanger-lap | tzafrir_laptop: Does that make sense? |
| 19:25.40 | tzafrir_laptop | pabelanger-lap, not quite. If you load the dahdi modules before installing asterisk, then the devices are created as root |
| 19:26.16 | tzafrir_laptop | Fix: /etc/init.d/dahdi restart |
| 19:26.41 | tzafrir_laptop | hmm... but this will not work when asterisk is running |
| 19:28.34 | tzafrir_laptop | basically unloading / reloading (or reboot) will re-apply |
| 19:30.10 | pabelanger-lap | brb, rebooting to see if they are applied. Since restarting did not work |
| 19:30.51 | *** join/#asterisk-dev philipp64|laptop (~chatzilla@mail.redfish-solutions.com) |
| 19:41.48 | *** join/#asterisk-dev pabelanger-lap (~pabelange@CPE0013f7abc09a-CM0013f7abc096.cpe.net.cable.rogers.com) |
| 19:43.17 | pabelanger-lap | tzafrir_laptop: Ok, so rebooting my system seemed to reset the permissions properly. /etc/init.d/dahdi restart did not. Either way, this is good. We should not need to do anything special within asterisk or init.d script. |
| 19:44.17 | tzafrir_laptop | pabelanger-lap, if asterisk was running, you weren't able to unload dahdi modules |
| 19:44.43 | tzafrir_laptop | (well, apart from astribanks. and I have no idea about tdmoe ones) |
| 19:45.42 | pabelanger-lap | tzafrir_laptop: Let me do some research to see why restarting dahdi failed to user the new asterisk permissions. Perhaps udev also need to be reset to see the new uid/gid |
| 19:46.02 | tzafrir_laptop | pabelanger-lap, what system is that? |
| 19:46.12 | pabelanger-lap | tzafrir_laptop: Ubuntu 10.04 |
| 19:46.25 | tzafrir_laptop | maybe udev rules need to be reloaded. |
| 19:46.41 | tzafrir_laptop | Good luck trying to add a command for that. |
| 19:47.06 | tzafrir_laptop | On centos5 is is not really needed, but the command is: udevcontrol reload_rules |
| 19:47.31 | tzafrir_laptop | On Debian Lenny the command you need is: udevadm control --reload_rules |
| 19:47.53 | tzafrir_laptop | On later systems you have: udevadm control --reload-rules |
| 19:49.31 | pabelanger-lap | tzafrir_laptop: Yup, spot on. Did the trick |
| 19:50.27 | *** join/#asterisk-dev crowbar7 (~Crowbar7@12.2.84.2) |
| 19:50.38 | pabelanger-lap | So, after make install for asterisk, we can call a post-install script to restart udev / dahdi |
| 20:00.33 | philipp64|laptop | so you now can't use SIP without using STUN also? |
| 20:01.53 | philipp64|laptop | <PROTECTED> |
| 20:02.23 | tzafrir_laptop | pabelanger-lap, though I suspect it belongs in the install target of dahdi |
| 20:02.56 | tzafrir_laptop | That said, I have been bitten from trying to guess the installed version of udev in the install target of zaptel/dahdi |
| 20:03.59 | JunK-Y | yay, registration for astricon is done. |
| 20:04.45 | pabelanger-lap | tzafrir_laptop: Ya, we'll have to try and account for that. For now, I'm starting with Ubuntu, and Debian. Can add support from there |
| 20:05.08 | pabelanger-lap | JunK-Y: Flying or driving? |
| 20:06.25 | JunK-Y | not sure yet, prolly fyling |
| 20:06.42 | JunK-Y | u? |
| 20:08.21 | Qwell | JunK-Y: nice |
| 20:08.49 | JunK-Y | Qwell: are ya coming too? |
| 20:08.54 | Qwell | dunno |
| 20:09.10 | Qwell | It's up to jtodd. He totally owes me though. I should mention that. :p |
| 20:09.20 | JunK-Y | the last time i saw you was at etel back in 2006 iirc ? |
| 20:09.32 | Qwell | unless you went to astricon 07 |
| 20:09.48 | Qwell | you did. that was in AZ |
| 20:10.00 | Qwell | I think. |
| 20:10.13 | JunK-Y | i was there too |
| 20:10.21 | JunK-Y | but drunk 90% of that trip though |
| 20:10.22 | JunK-Y | hhhahaha |
| 20:10.35 | pabelanger-lap | JunK-Y: Going to drive down, Washington is not that far |
| 20:10.56 | leifmadsen | is hoping to join pabelanger-lap in that drive |
| 20:11.45 | pabelanger-lap | leifmadsen: Yup, jump on the train and will pick you up in Kingston :) |
| 20:11.59 | leifmadsen | pabelanger: are you going through Buffalo? |
| 20:12.56 | leifmadsen | pabelanger-lap: guess you're crossing at Alexandra Bay? |
| 20:13.43 | pabelanger-lap | leifmadsen: The fastest way would be for me to cross at 1000 islands. Just north-east of Kingston |
| 20:14.02 | leifmadsen | ah ya, I see that |
| 20:14.07 | leifmadsen | then it's basically straight south |
| 20:14.23 | JunK-Y | come and pass by montreal :) |
| 20:14.40 | leifmadsen | hmmm, wish the GO went to Kingston :) |
| 20:14.52 | pabelanger-lap | leifmadsen: Ya, otherwise Buffalo add + 5hours |
| 20:15.11 | leifmadsen | yep |
| 20:15.39 | pabelanger-lap | JunK-Y: Make your way to Ottawa and you can hitch a ride |
| 20:16.31 | *** join/#asterisk-dev datachomper (~Adium@nat/digium/x-plqnwcbrttendmxt) |
| 20:19.12 | JunK-Y | pabelanger-lap: when are you leaving and coming back? |
| 20:19.56 | *** join/#asterisk-dev miguel3239 (~miguel323@ns1.nashuacs.com) |
| 20:20.12 | pabelanger-lap | JunK-Y: Haven't decided yet. Need to plan it out |
| 20:20.28 | JunK-Y | actually, i'll be with my best friend, still have 2 places? |
| 20:21.28 | pabelanger-lap | JunK-Y: Maybe tight, I have a TDI golf. usually 3 people plus cargo is pretty full |
| 20:21.58 | leifmadsen | ya with bags for 3 people, that's like a whole person right there |
| 20:23.43 | JunK-Y | leif can be fit in the trunk, im sure :) |
| 20:23.55 | leifmadsen | put you on the roof! |
| 20:24.03 | leifmadsen | or behind on your rollerblades |
| 20:24.58 | JunK-Y | i will send ya a video tonight leif, a bad rollerblade accident i had like 6 years ago |
| 20:25.07 | leifmadsen | I've seen it :) |
| 20:25.13 | leifmadsen | hence my reference to rollerblades |
| 20:25.28 | JunK-Y | thanks, i will have nightmares back! |
| 20:39.56 | philipp64 | kpfleming: trying to build r276788 in trunk, but getting: ./configure: line 7192: ACX_PTHREAD: command not found |
| 20:40.06 | philipp64 | trunk was building this morning. |
| 20:50.23 | philipp64 | hmmm... except that kpfleming isn't here. sigh. |
| 20:50.47 | philipp64 | I think "svn blame" is misleading me anyway. |
| 20:53.38 | philipp64 | Corydon76-dig: actually, it looks like r276731 that broke the build. |
| 21:05.39 | philipp64 | leifmadsen: in M11688, please delete file id's 26553, 26535, and 26662... |
| 21:05.43 | MuffinMan | [ready for testing] [Asterisk] Channels/chan_sip/NewFeature 0011688: [patch] Allow Sipura handsets (SPA942) to use Asterisk SLA via implementation of Broadsoft Sip extensions reported by grossi https://issues.asterisk.org/view.php?id=11688 |
| 21:06.35 | philipp64 | Corydon76-dig: confirmed.... 276730 builds just fine. |
| 21:06.42 | philipp64 | should I file a regression bug? |
| 21:13.22 | russellb | philipp64: yup, that would be good |
| 21:14.34 | philipp64 | done. M17654 |
| 21:14.36 | MuffinMan | [new] [Asterisk] Core/BuildSystem 0017654: configure.ac now breaks when running bootstrap.sh reported by pprindeville https://issues.asterisk.org/view.php?id=17654 |
| 21:14.50 | philipp64 | that might need retitling. |
| 21:17.12 | philipp64 | can a bug marshal please delete file 26665? thanks. |
| 21:17.35 | philipp64 | (i.e. all but the last .patch file in M11688) |
| 21:17.38 | MuffinMan | [ready for testing] [Asterisk] Channels/chan_sip/NewFeature 0011688: [patch] Allow Sipura handsets (SPA942) to use Asterisk SLA via implementation of Broadsoft Sip extensions reported by grossi https://issues.asterisk.org/view.php?id=11688 |
| 21:26.19 | philipp64 | Qwell: gotta love that deferred evaluation in m4... testing now. |
| 21:26.21 | MuffinMan | Failed to retrieve issue page for 4. Does it exist? |
| 21:26.45 | russellb | MuffinMan: stfu |
| 21:39.29 | philipp64 | Qwell: seems to work. good to commit? |
| 22:11.54 | *** join/#asterisk-dev datachomper (~Adium@nat/digium/x-hsmmwxzqxlrnhawt) |
| 22:26.18 | *** join/#asterisk-dev mpe (~mpe@0x4dd624b2.adsl.cybercity.dk) |
| 22:34.46 | *** join/#asterisk-dev Skavin (kevins@202-180-69-27.me.tranzpeer.net) |
| 23:21.39 | Skavin | I am trying to use a " in a string in extensions.conf in 1.4 I backslashed it |
| 23:21.56 | Skavin | doc/tex/channelvariables.tex reads that I should backslash it |
| 23:22.33 | Skavin | this line exten => s,n,GotoIf($["${CALLERID(name)}" = '\"anonymous\"']?dolblkcid) |
| 23:23.23 | Skavin | generates this error ast_expr2.fl:445 ast_yyerror: ast_yyerror(): syntax error: syntax error, unexpected '<token>', expecting $end; Input: |
| 23:23.54 | Skavin | "" = "\"anonymous\"" |
| 23:24.16 | Skavin | with a ^ pointing at the " |
| 23:24.30 | Skavin | am I just misreading the docs or is this a bug? |
| 23:33.13 | philipp64 | Corydon76-dig: thanks. |
| 23:39.36 | Corydon76-dig | LLONG_MAX has a minimum acceptable value in POSIX |
| 23:40.35 | Corydon76-dig | Doing bit manipulations like that assumes that integers on a system are always represented the same way, which is not a safe assumption |
| 23:41.12 | Corydon76-dig | It's much safer to go with POSIX |
| 23:45.23 | Corydon76-dig | Wow. There are already a few filesystems which might support a file that large. A very few, none of which are mainstream. |
| 23:45.48 | *** part/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 23:52.57 | russellb | Corydon76-dig: did you see the non-linux build failures for trunk on bamboo? |