Re: [asterisk-dev] Module Deprecation, Default Not Building, and Removal

ua C. Colp wrote: On Thu, Oct 1, 2020 at 2:18 PM Corey Farrell <mailto:g...@cfware.com>> wrote: Yes I'm suggesting documenting that it is deprecated in minor releases.  Ending support in a minor seems bad unless support already doesn't exist.  Could we add AST_MODULE_SUPP

Re: [asterisk-dev] Module Deprecation, Default Not Building, and Removal

Any reason we can't "documentation deprecate" things in minor releases?  No runtime warnings and keep building by default but if we deprecate a module in master right now it seems like the next minor release of all active branches should document the status of the module.  The fact that a

Re: [asterisk-dev] Proposal for New Major Version Process Change

With the current process new features can be added with tests can target 18 as soon as the branch is cut but would not go into 18.0.  What would happen with new features in this scheme, would they just get held open in gerrit until 18.0 is branched or be accepted as normal since 18.0.0 release

Re: [asterisk-dev] [BOUNTY] X-Header on SIP BYE

chan_sip is fragile and has no active maintainers.  Personally I think new features do not belong in chan_sip, should instead be implemented for chan_pjsip. On 11/19/19 8:06 AM, bala murugan wrote: Hi Ernst ,    I can develop this for you in chan_sip driver  on the version you are using

Re: [asterisk-dev] Asterisk and CentOS 8

iksemel-devel: To my knowledge library is not maintained and has been removed from Fedora because it no longer builds from source. Honestly I thought we had deprecated res_xmpp and chan_motif for this very reason. libedit-devel: This is mandatory since Asterisk 16.  The devel package is found

Re: [asterisk-dev] Memory leak since Asterisk 16.5.x / pjsip

Updating pjproject does take less time/effort than maintaining a fork for the many years of an LTS release.  That reduced effort isn't just free time to developers, the time is instead spent working on enhancements and bug fixes.  Maintaining a fork would prevent users from getting important

Re: [asterisk-dev] ARI, Stasis, and Dialplan

How will the ARI/dialplan integration handle specific extensions?  For example if I have a stasis app which registers itself to dialplan as 'somecontext', how does this integration decide which extensions are handled by the app?  Does that app get calls for all extensions or only specific

Re: [asterisk-dev] Strange issue with permissions and a third party module

If using Fedora / similar systems it could be an SELinux policy issue.  In Fedora /usr/sbin/asterisk is a confined process where python is not.  On Fedora/CentOS SELinux will forbid Asterisk from taking certain actions even if allowed by the file system permissions set by chmod.  It's possible

Re: [asterisk-dev] Testsuite python3 compatibility

Sorry for the delayed reply I've been busy with other projects lately. On 06/06/2018 04:38 AM, Alexander Traud wrote: I love to help. However, before I apply your patch, I need a running Test Suite first. In Ubuntu 18.04 LTS with branch Master, 11 test cases fail for me, for example

Re: [asterisk-dev] Testsuite python3 compatibility

An Asterisk WIKI page [1] exists.  It has the basics but it's a bit out of date. Some notes: * For the purpose of this test you should use Linux.  It may work on *BSD but that would introduce a new mostly untested variable.  If you are doing this in a VM the options which have been

[asterisk-dev] Testsuite python3 compatibility

I've posted python3 compatibility changes for the testsuite [1]. This has gotten some testing (which found issues that have been fixed), but really a full testsuite run is required to verify no errors.  I do not have adequate hardware to complete this task, I'm hoping someone in the community

[asterisk-dev] starpy

I'm working on some PR's to update the Asterisk testsuite to be compatible with Python3 (without breaking Python2).  An issue I've hit is starpy.  A PR to deal with compatibility was started but never finished.  Can we move starpy to gerrit.asterisk.org and convert the github repository to a

Re: [asterisk-dev] Compiler feature requirements

ilt-ins. I tested OSX El Capitain, the configure script detected __atomic built-ins so this will not create any new issues for Mac. [1] https://gist.github.com/coreyfarrell/c096dd335afee5502a6faee2a507b012 On 01/26/2018 03:20 PM, Matt Fredrickson wrote: On Wed, Jan 24, 2018 at 3:50 PM, Co

Re: [asterisk-dev] Which enviroments are supported, really?

If you are looking to work with FreeBSD I'd suggest starting at FreshPorts [1].  Someone has done the work to get Asterisk working on FreeBSD and they've got Asterisk 13.19.0 (they're keeping it current). [1] https://www.freshports.org/net/asterisk13/ On 01/26/2018 06:41 AM, Alexander Traud

Re: [asterisk-dev] Compiler feature requirements

need __sync_fetch_and_nand or __sync_nand_and_fetch we would need to require gcc-4.4.  I've looked into the ast_flags macro's, implementing them with atomic operations would would not require nand functions. [1] https://gerrit.asterisk.org/8049 On 01/24/2018 04:50 PM, Corey Farrell wrote: I've

[asterisk-dev] Compiler feature requirements

I've posted ASTERISK-27619 [1] proposing that we drop support for GCC versions older than 4.1.2.  Specifically we'd be requiring that either __sync or __atomic builtin functions be available (I'm unsure what this will do to clang requirements).  gcc-4.1.2 was released in February 2007 and was

Re: [asterisk-dev] Which enviroments are supported, really?

The only wiki page I found on non-Linux is [1].  Probably the clearest statement is in the README.md [2].  I think we should probably add a more negative spin to the comments about Other platforms, at minimum state that they are not actively tested and may break at any time. As for

Re: [asterisk-dev] Help understand TCP/TLS server error

I'd suggest opening a ticket at https://issues.asterisk.org, include full debug logs and minimal test case for reproducing the issue. See https://wiki.asterisk.org/wiki/display/AST/Collecting+Debug+Information for details about what to post on the new ticket. Just to ask have you tested

Re: [asterisk-dev] QueueLog Linkedid

I'd be interested in what Loway would have to say about this (or any other reporting systems).  ATTENDEDTRANSFER already uses 4 data fields, so I don't have any issue if CONNECT sets the 4th data field to linkedid.  I don't see this as a format change, if we were talking about adding a 5th

Re: [asterisk-dev] tags on the main branches [was: Re: Minor Release Branches]

On 12/22/2017 12:36 PM, George Joseph wrote: On Fri, Dec 22, 2017 at 9:50 AM, Corey Farrell <g...@cfware.com <mailto:g...@cfware.com>> wrote: On 12/22/2017 10:22 AM, George Joseph wrote: On Thu, Dec 21, 2017 at 1:44 PM, Corey Farrell <g...@cfware.com <mail

Re: [asterisk-dev] Adding a Key/Value Store mechanism to Asterisk

I hope we consider creating a res_redis first, then base everything off that.  If a redis library can be used directly by any module that would fine but I'd like to see us avoid following the example of curl where everything uses a dialplan function to perform requests.  Dialplan functions

Re: [asterisk-dev] tags on the main branches [was: Re: Minor Release Branches]

On 12/22/2017 10:22 AM, George Joseph wrote: On Thu, Dec 21, 2017 at 1:44 PM, Corey Farrell <g...@cfware.com <mailto:g...@cfware.com>> wrote: George asked that I post some scenarios where this would be useful. 1. You are about to create updated asterisk pack

Re: [asterisk-dev] tags on the main branches [was: Re: Minor Release Branches]

13.19.0-rc1 would appear out of order (before 13.19.0).  The difference between rc1 and final release is always small, but the number of new commits to mainline between that time can be quite large. On 12/21/2017 10:45 AM, Corey Farrell wrote: I just read `git help merge` again and I think

Re: [asterisk-dev] tags on the main branches [was: Re: Minor Release Branches]

nal step of mkrelease.py. No changes will be needed to our handling of '.lastclean', please ignore those comments as I was wrong. On 12/21/2017 08:19 AM, George Joseph wrote: On Wed, Dec 20, 2017 at 3:14 PM, Corey Farrell <g...@cfware.com <mailto:g...@cfware.com>> wrote: One thin

Re: [asterisk-dev] tags on the main branches [was: Re: Minor Release Branches]

One thing that might improve this is if releases were merged back to the major branch.  Currently the commit "Update for 13.19.0-rc1" is on the 13.19 branch and tagged as 13.19.0-rc1.  I believe that if we added 'git checkout 13 && git merge 13.19.0-rc1' we would get better information from

[asterisk-dev] Minor Release Branches

I'd like to propose that we make minor release branches temporary.  What I mean is 13.15, 15.0, etc.  The sole purpose of the '13.15' was to allow cherry-picking fixes to the 13.15.x series.  As soon as 13.16.0 was released the '13.15' branch was closed to new merges.  The latest commit on

Re: [asterisk-dev] Branching in the Testsuite

, Corey Farrell <g...@cfware.com <mailto:g...@cfware.com>> wrote: It would be nice to strip out some/most of the per version conditionals in tests.  The need to always cherry-pick changes is the only pitfall I see with your proposal.  If a test never had per version

Re: [asterisk-dev] Branching in the Testsuite

It would be nice to strip out some/most of the per version conditionals in tests.  The need to always cherry-pick changes is the only pitfall I see with your proposal.  If a test never had per version differences then the cherry-pick is trivial amount of extra work, but for tests with

Re: [asterisk-dev] Can someone please review something

From your configure.ac: > AST_EXT_LIB_CHECK([REDIS], [redis], [redisReaderCreate], [hiredis/hiredis.h]) This tries linking with '-lredis', but it needs to use '-lhiredis': AST_EXT_LIB_CHECK([REDIS], [hiredis], [redisReaderCreate], [hiredis/hiredis.h]) In addition instead of using variable

Re: [asterisk-dev] Can someone please review something

Where did you push this branch?  I'm not seeing it on gerrit or github. On 11/22/2017 06:01 PM, Nir Simionovich wrote: Hi All,   I've started a new branch at team/nirs/cdr-redis-support   I'm having some issues integrating the hiredis library into the automake. It seems to be configured

Re: [asterisk-dev] autoconf version requirement increase

, Le 01/11/2017 à 09:08, Matt Fredrickson a écrit : Hey Corey, On Tue, Oct 31, 2017 at 3:52 PM, Corey Farrell <g...@cfware.com> wrote: Hello all, autoconf is required to run ./bootstrap.sh after changing configure.ac or *.m4 in any folder of the Asterisk source tree (including menuselect and

Re: [asterisk-dev] autoconf version requirement increase

ovich" <nir.simionov...@gmail.com <mailto:nir.simionov...@gmail.com>> wrote: Hi Corey,   Our production environment is based on CentOS 6.9 and we're slowly migrating to 7.X I would be happy to check out your patches inside our testing facility. On Tue, Oct 31,

[asterisk-dev] autoconf version requirement increase

Hello all, autoconf is required to run ./bootstrap.sh after changing configure.ac or *.m4 in any folder of the Asterisk source tree (including menuselect and third-party folders).  Currently we require 2.60, I'm working on a patch that will require 2.64.  Note autoconf is not required to run

Re: [asterisk-dev] AstDB mySQL implementation

I think astdb itself is an inappropriate place to deal with this.  astdb is initialized well before module preloads so it would be nearly impossible for modules to provide the astdb implementation.  In my opinion astdb is a database "implementation", not a connector (and that shouldn't

[asterisk-dev] chan_sip maintenance mode

I propose that we restrict the kind of bugs/patches that are accepted against chan_sip to only major/critical bugs, regressions and security fixes.  This means rejecting all new features, improvements and most minor bugs (AKA known limitations) reported against chan_sip.  I am not proposing we

Re: [asterisk-dev] One sip stack to rule them all....

Correction on number of bugs, most PJSIP bugs are filed against resource modules.  If you select all of the "Resources/res_pj*" categories in addition to Channels/chan_pjsip it shows 121 open bugs.  People are reporting issues against the pjsip modules, most are not against the channel driver

Re: [asterisk-dev] CentOS 6 and Ubuntu 12 Testing Support

CentOS 6 "Full Updates" support ends May 10th [1], after that "only Security errata and select mission critical bug fixes will be released". I think this combined with testing difficulties justifies moving CentOS 6 into "extended" support for Asterisk. Probably worth announcing to

Re: [asterisk-dev] AST_MODULE_LOAD_FAILURE vs AST_MODULE_LOAD_DECLINE

Probably not the popular opinion, but I don't think any modules are "generally" important enough to abort Asterisk start-up. For any module that is important enough for a system the admin can use 'require' or 'preload-require' settings in modules.conf. The exception to this would be when a

Re: [asterisk-dev] AMI/ARI versioning

On 03/31/2017 10:47 AM, Kevin Harwell wrote: On Thu, Mar 30, 2017 at 6:54 PM, Corey Farrell <g...@cfware.com <mailto:g...@cfware.com>> wrote: On 03/30/2017 07:14 PM, Kevin Harwell wrote: I think it's worth referencing a previous discussion on this [1]. Yes, thank y

Re: [asterisk-dev] AMI/ARI versioning

On 03/30/2017 07:14 PM, Kevin Harwell wrote: [asterisk-branch-number].[minor].[patch] Actually, the proposal might be better represented as the following: [asterisk-branch-number].[major].[minor/patch] Or another way to state it: [asterisk-branch-number].[api breaking].[api non

Re: [asterisk-dev] Line length restrictions in code changes

On 03/16/2017 04:35 PM, Kevin Harwell wrote: On Thu, Mar 16, 2017 at 2:54 PM, Matthew Jordan > wrote: Questions than: (1) Should there even be a line length rule? I lean toward yes just to keep things sane (e.g. keeping someone

Re: [asterisk-dev] Problems with custom C-file: undefined reference

system.h* >> void ast_system_get_address(struct ast_sockaddr *us); >> >> *system.c* >> #include "asterisk/system.h" >> >> void ast_system_get_address(struct ast_sockaddr *us) >> { >>... >> } >> >> *chan_sip.c* >>

Re: [asterisk-dev] Problems with custom C-file: undefined reference

I'm not sure what you're trying to accomplish but this is not the approach I'd take for expanding chan_sip. My advice is to simply put your system.c into channels/sip. This will automatically link it into the binary chan_sip module, but allow you to keep your source code in a separate file. I

Re: [asterisk-dev] Anyone interested in having file/line number shown in dialplan show output?

Overall I like it. I think leaving pbx_ael out of this is best as it might not be straight forward. Anyone who wants pbx_ael to provide information about config sources can create a follow-up patch once the core functionality is implemented. Some thoughts: * It would be nice if the registrar

[asterisk-dev] tcptls: Use new certificate on reload

A review [1] has been posted to fix an issue where TLS servers would not be restarted unless the bind address was changed. This would prevent use of new certificates if available. Unfortunately this change does cause an ABI change. Fields are added to public structures 'struct ast_tls_config'

Re: [asterisk-dev] ARI versioning in 13 and 14

+1 for option 2. I'm against option 1 because the ARI version should be enough to verify that the features of 14.2.0 are available. One remaining question: how would we handle situations where a critical or security bug requires a breaking change to ARI in Asterisk 13? --

Re: [asterisk-dev] ARI StasisEnd event vs. channel variables

On Fri, Oct 21, 2016 at 12:32 PM, Kevin Harwell <kharw...@digium.com> wrote: > On Fri, Oct 21, 2016 at 10:49 AM, Corey Farrell <g...@cfware.com> wrote: >> >> >> I'm in favor per app config. I do not yet use ARI, but when I do I >> will have '#tryinclude

Re: [asterisk-dev] ARI StasisEnd event vs. channel variables

On Fri, Oct 21, 2016 at 9:37 AM, Sébastien Duthil wrote: > On 19/10/16 11:59 AM, Mark Michelson wrote: >> I had thought about making the list of channel variables per-ARI app >> instead of global, but I don't know if that's actually desired. > > The underlining

Re: [asterisk-dev] Viva Chan_Sip, may it rest in peace

On Mon, Oct 10, 2016 at 10:39 AM, Matthew Jordan <mjor...@digium.com> wrote: > > On Fri, Oct 7, 2016 at 10:31 AM, Corey Farrell <g...@cfware.com> wrote: > > Many people don't like chan_sip, most people hate working with the code. > > The rush to throw out c

Re: [asterisk-dev] Viva Chan_Sip, may it rest in peace

Many people don't like chan_sip, most people hate working with the code. The rush to throw out chan_sip when PJSIP isn't ready to be the only SIP stack annoys me a bit. Nobody is forcing anyone to use or contribute to chan_sip. Digium changed chan_sip from core to extended support so they can

Re: [asterisk-dev] Working Groups

On Thu, Oct 6, 2016 at 6:44 AM, Dan Jenkins wrote: > So if I understand properly you'd like to see a working group around "My > first Asterisk Commit" - which would drive forward making contributing to > the project easier - whether it was improving documentation, or

Re: [asterisk-dev] Using command line arguments in other file than asterisk.c

A custom command-line option is undesirable due to the limited number of possible option codes / chance of future conflict if we need to add a standard option. If you really need a custom option just for your own chan_sip, it would be better to add it to sip.conf and parse it during config load.

Re: [asterisk-dev] BRIDGEPEER on multi-party conferences: Thoughts?

d leaves, and you have a non-empty value for BRIDGEPEER when the > channel is with multiple parties in a bridge. You won't get VarSets on the > other channels in a bridge when a channel enters or leaves, though. I'm not > sure if that's something that people rely on or not. > &

Re: [asterisk-dev] BRIDGEPEER on multi-party conferences: Thoughts?

It might be a problem if BRIDGEPEER is being compared to an empty string to see if a channel is alone. What if you made BRIDGEPEER into a built-in channel variable (like ${EPOCH}). This would mean that you wouldn't be setting any channels, you'd only do a lookup when requested. One side-effect

[asterisk-dev] AO2 API changes for REF_DEBUG

Hello everyone, I've opened ASTERISK-26171 to track my effort to include a "%p" pointer (debugstorage) in the REF_DEBUG log. Providing this information to refcounter.py allows it to remove matching ref and unref from the output. It also allows detection of indirect leaks where one object leaked

Re: [asterisk-dev] Asterisk Docker Containers: Phase 1

I make use of a couple patches so the latest Fedora spec is a good enough base for me. If other people want to see current binaries for EPEL hopefully they'll speak up. I had a chance to look over the asterisk.spec from Fedora master, I have a couple comments. * res_ari_mailboxes.so should be

[asterisk-dev] Asterisk Docker Containers: Phase 1

in the > CentOS 6 container (gcc complained about not being able to result in a > binary or something). > > Long story short, use fedpkg to build the RPMs from the Fedora > repositories. Just clone the Fedora 23 version (which gets you Asterisk > 13.3.2 as of now), and then build it o

Re: [asterisk-dev] Asterisk Docker Containers: Phase 1

Jared, I just looked through the EPEL website at EPEL6 and EPEL7, only found Asterisk 1.8. Can you point me to the spec file you are using or an SRPM? Thanks, Corey On Thu, Nov 19, 2015 at 2:02 PM, Jared Smith wrote: > > On Thu, Nov 19, 2015 at 10:14 AM, Matthew

Re: [asterisk-dev] Journald support for Asterisk

CentOS/RHEL 6 are under production support until Nov 2020 [1] and journald is not available. Even if journald could improve Asterisk logging, that's not an acceptable reason to force Asterisk users to upgrade from a supported OS. If there was a module that allowed Asterisk logging to talk to

[asterisk-dev] asterisk.conf options override command-line options.

I've discovered that any option set in asterisk.conf cannot be overridden using the command-line. For example, if you have verbose=0 in asterisk.conf, 'asterisk -cvvv' will start with verbose 0. The same goes for -f / nofork or -F / alwaysfork. The only way to fix this is to change the

Re: [asterisk-dev] A Week with GIT/Gerrit

My additions to the list: 1) Procedure for 'git review' of security related patches. I think this could be done with an asterisk-security mirror repository setup in gerrit with restricted access. I know this is already being thought about, just wanted to make sure it on the list. 2) Is there a

Re: [asterisk-dev] [Code Review] 4580: Fix issue with Makefile that prevents use of ~/.asterisk.makeopts and /etc/asterisk.makeopts

thinking trunk only. If anyone disagrees let me know. Diffs - /trunk/Makefile 433966 Diff: https://reviewboard.asterisk.org/r/4580/diff/ Testing --- Repeatedly ran 'make menuselect' with and without files in the 3 locations. No one else has tested this. Thanks, Corey Farrell

Re: [asterisk-dev] [Code Review] 3603: func_jitterbuffer: fix audio failure caused by certain masquerade's

, Corey Farrell -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev

[asterisk-dev] Change in asterisk[1.8]: .gitignore: Ignore tarballs (*.gz)

Corey Farrell has posted comments on this change. Change subject: .gitignore: Ignore tarballs (*.gz) .. Patch Set 1: Code-Review+1 -- To view, visit https://gerrit.asterisk.org/86 To unsubscribe, visit https

[asterisk-dev] Change in asterisk[master]: git migration: Refactor the ASTERISK_FILE_VERSION macro

Corey Farrell has posted comments on this change. Change subject: git migration: Refactor the ASTERISK_FILE_VERSION macro .. Patch Set 5: Code-Review+1 Used grep, found a few tests that were still using parameters with the new

[asterisk-dev] Change in asterisk[13]: git migration: Remove support for file versions

Corey Farrell has posted comments on this change. Change subject: git migration: Remove support for file versions .. Patch Set 2: Code-Review-1 (1 comment) Missed one spot where we should conditionally return Asterisk Version

Re: [asterisk-dev] [Code Review] 4391: Add blank line between headers and output for Command action response

for failure in output. - Corey Farrell On April 13, 2015, 1 a.m., gareth wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4391

[asterisk-dev] Change in asterisk[master]: git migration: Refactor the ASTERISK_FILE_VERSION macro

Gerrit-PatchSet: 5 Gerrit-Project: asterisk Gerrit-Branch: master Gerrit-Owner: Matt Jordan mjor...@digium.com Gerrit-Reviewer: Corey Farrell g...@cfware.com Gerrit-Reviewer: George Joseph george.jos...@fairview5.com Gerrit-Reviewer: Matt Jordan mjor...@digium.com

[asterisk-dev] Change in testsuite[master]: PEP8 fixes

Corey Farrell has posted comments on this change. Change subject: PEP8 fixes .. Patch Set 2: (2 comments) The PJSIP tests no longer fail. I have a full run of the testsuite going now, so far no issues. https

Re: [asterisk-dev] [Code Review] 4586: AMI: Fix improper handling of lines that are exactly 1025 bytes long.

a single error is received for lines 1025 or more, lines 1024 or less succeed. Thanks, Corey Farrell -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update

[asterisk-dev] Change in asterisk[master]: AMI: Fix improper handling of lines that are exactly 1025 by...

Corey Farrell has uploaded a new change for review. https://gerrit.asterisk.org/74 Change subject: AMI: Fix improper handling of lines that are exactly 1025 bytes long. .. AMI: Fix improper handling of lines that are exactly

[asterisk-dev] Change in asterisk[master]: Optional API: Fix handling of sources that are both provider...

Corey Farrell has uploaded a new change for review. https://gerrit.asterisk.org/73 Change subject: Optional API: Fix handling of sources that are both provider and user. .. Optional API: Fix handling of sources that are both

[asterisk-dev] Change in asterisk[13]: res_monitor: Add dependency on func_periodic_hook.

Corey Farrell has uploaded a new change for review. https://gerrit.asterisk.org/72 Change subject: res_monitor: Add dependency on func_periodic_hook. .. res_monitor: Add dependency on func_periodic_hook. OPTIONAL_API has

Re: [asterisk-dev] [Code Review] 4590: Optional API does not work for sources that are both provider and user of optional API's.

. Thanks, Corey Farrell -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev

[asterisk-dev] Change in asterisk[master]: Optional API: Fix handling of sources that are both provider...

Corey Farrell has posted comments on this change. Change subject: Optional API: Fix handling of sources that are both provider and user. .. Patch Set 1: This was previously posted for review at https

[asterisk-dev] Change in asterisk[13]: git migration: Remove support for file versions

Corey Farrell has posted comments on this change. Change subject: git migration: Remove support for file versions .. Patch Set 3: Code-Review+1 -- To view, visit https://gerrit.asterisk.org/60 To unsubscribe, visit https

[asterisk-dev] Change in asterisk[11]: git migration: Remove support for file versions

Corey Farrell has posted comments on this change. Change subject: git migration: Remove support for file versions .. Patch Set 3: Code-Review+1 -- To view, visit https://gerrit.asterisk.org/61 To unsubscribe, visit https

[asterisk-dev] Change in testsuite[master]: PEP8 fixes

Corey Farrell has posted comments on this change. Change subject: PEP8 fixes .. Patch Set 2: -Code-Review It appears that it's not this change that is broken, it's my computer. -- To view, visit https://gerrit.asterisk.org

[asterisk-dev] Change in testsuite[master]: PEP8 fixes

Corey Farrell has posted comments on this change. Change subject: PEP8 fixes .. Patch Set 2: Code-Review-1 Still working out an issue. -- To view, visit https://gerrit.asterisk.org/40 To unsubscribe, visit https

[asterisk-dev] Change in asterisk[13]: git migration: Remove support for file versions

Corey Farrell has posted comments on this change. Change subject: git migration: Remove support for file versions .. Patch Set 1: Code-Review+1 -- To view, visit https://gerrit.asterisk.org/60 To unsubscribe, visit https

[asterisk-dev] Change in asterisk[11]: git migration: Remove support for file versions

Corey Farrell has posted comments on this change. Change subject: git migration: Remove support for file versions .. Patch Set 1: Code-Review+1 (1 comment) So I'm a bit indifferent about the finding against main/asterisk.c

[asterisk-dev] Change in asterisk[11]: git migration: Remove support for file versions

Corey Farrell has posted comments on this change. Change subject: git migration: Remove support for file versions .. Patch Set 1: (1 comment) https://gerrit.asterisk.org/#/c/61/1/main/asterisk.c File main/asterisk.c: Line

[asterisk-dev] Change in asterisk[11]: git migration: Remove support for file versions

Corey Farrell has posted comments on this change. Change subject: git migration: Remove support for file versions .. Patch Set 1: -Code-Review (1 comment) https://gerrit.asterisk.org/#/c/61/1/main/asterisk.c File main

Re: [asterisk-dev] [Code Review] 4108: Weak Proxy Objects

.c, lines 492-494 https://reviewboard.asterisk.org/r/4108/diff/5-6/?file=71780#file71780line492 The comment doesn't make sense. How is destructor_fn supposed to access values in the weak proxy? The real object is no longer linked with the weakproxy. Corey Farrell wrote

Re: [asterisk-dev] [Code Review] 4108: Weak Proxy Objects

the included test with REF_DEBUG enabled under valgrind. No reference leaks or improper memory access. Though this does not test for races, I don't know of an automated way to do that. Thanks, Corey Farrell -- _ -- Bandwidth

[asterisk-dev] Change in asterisk[master]: astobj2: Add support for weakproxy objects.

Corey Farrell has uploaded a new change for review. https://gerrit.asterisk.org/56 Change subject: astobj2: Add support for weakproxy objects. .. astobj2: Add support for weakproxy objects. This implements weak references

Re: [asterisk-dev] [Code Review] 4108: Weak Proxy Objects

. No reference leaks or improper memory access. Though this does not test for races, I don't know of an automated way to do that. Thanks, Corey Farrell -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk

[asterisk-dev] Change in asterisk[master]: git migration: Refactor the ASTERISK_FILE_VERSION macro

Corey Farrell has posted comments on this change. Change subject: git migration: Refactor the ASTERISK_FILE_VERSION macro .. Patch Set 3: Code-Review-1 (9 comments) https://gerrit.asterisk.org/#/c/54/3//COMMIT_MSG Commit

[asterisk-dev] Change in asterisk[master]: main/editline: Add .gitignore.

Corey Farrell has uploaded a new change for review. https://gerrit.asterisk.org/57 Change subject: main/editline: Add .gitignore. .. main/editline: Add .gitignore. This patch adds a .gitignore for main/editline to ignore all

[asterisk-dev] Change in asterisk[master]: git migration: Refactor the ASTERISK_FILE_VERSION macro

Corey Farrell has posted comments on this change. Change subject: git migration: Refactor the ASTERISK_FILE_VERSION macro .. Patch Set 1: Code-Review+1 -- To view, visit https://gerrit.asterisk.org/58 To unsubscribe, visit

[asterisk-dev] Change in asterisk[master]: Add .gitignore and .gitreview files

Corey Farrell has posted comments on this change. Change subject: Add .gitignore and .gitreview files .. Patch Set 2: Code-Review+1 -- To view, visit https://gerrit.asterisk.org/42 To unsubscribe, visit https

[asterisk-dev] Change in asterisk[master]: Add .gitignore and .gitreview files

Corey Farrell has posted comments on this change. Change subject: Add .gitignore and .gitreview files .. Patch Set 1: (2 comments) Couple minor things then this is good to go. https://gerrit.asterisk.org/#/c/42/1/.gitignore

[asterisk-dev] Change in asterisk[master]: sounds: Add a .gitignore file for downloaded sound tarballs

Corey Farrell has posted comments on this change. Change subject: sounds: Add a .gitignore file for downloaded sound tarballs .. Patch Set 1: Code-Review-1 Any reason we can't just add to the root .gitignore: *.gz This way

[asterisk-dev] Change in asterisk[master]: .gitignore: Ignore tarballs (*.gz)

Corey Farrell has posted comments on this change. Change subject: .gitignore: Ignore tarballs (*.gz) .. Patch Set 2: Code-Review+1 -- To view, visit https://gerrit.asterisk.org/55 To unsubscribe, visit https

Re: [asterisk-dev] [Code Review] 4108: Weak Proxy Objects

--- On April 3, 2015, 12:58 p.m., Corey Farrell wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4108

Re: [asterisk-dev] [Code Review] 4391: Add blank line between headers and output for Command action response

/#comment25830 These two lines should be replaced with 'goto done;'. This way we will return RESULT_FAILURE. - Corey Farrell On April 9, 2015, 1:05 a.m., gareth wrote: --- This is an automatically generated e-mail. To reply, visit

Re: [asterisk-dev] [Code Review] 4391: Add blank line between headers and output for Command action response

On April 3, 2015, 6:37 a.m., Corey Farrell wrote: /trunk/main/manager.c, line 4873 https://reviewboard.asterisk.org/r/4391/diff/3/?file=72904#file72904line4873 If we successfully ran the command, it seems unsafe to claim failure. We have to assume the the caller doesn't actually

Re: [asterisk-dev] [Code Review] 4608: res_pjsip_phoneprov_provider: Fix reference leak on unload

--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4608/#review15167 --- Ship it! Ship It! - Corey Farrell On April 9, 2015, 3:57

Re: [asterisk-dev] [Code Review] 4608: res_pjsip_phoneprov_provider: Fix reference leak on unload

April 9, 2015, 3:20 p.m.) Review request for Asterisk Developers and Corey Farrell. Bugs: ASTERISK-24935 https://issues.asterisk.org/jira/browse/ASTERISK-24935 Repository: Asterisk Description --- res_pjsip_phoneprov_provider was leaking references to phoneprov

Re: [asterisk-dev] [Code Review] 4604: loader/main: Don't set ast_fully_booted until deferred reloads are processed

--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4604/#review15154 --- Ship it! Ship It! - Corey Farrell On April 9, 2015, 10:57

  1   2   3   4   5   6   7   >