[Nfs-ganesha-devel] Change in ffilz/nfs-ganesha[next]: Make code compatible for python2 and 3.

>From : supriti.si...@suse.com has uploaded this change for review. ( https://review.gerrithub.io/404787 Change subject: Make code compatible for python2 and 3. .. Make code compatible for python2 and

Re: [Nfs-ganesha-devel] nss_getpwnam: name 't...@my.dom@localdomain' does not map into domain 'nix.my.dom'

So, there is an option STRICT_PACKAGE that is supposed to enable this. It's not fully utilized, but it's mostly there. The problem is that we can't tell whether the default is being used (lots of options are on by default but disable themselves if the packages aren't installed) or if the user

[Nfs-ganesha-devel] Change in ffilz/nfs-ganesha[next]: Don't dec open_fd_count unless close succeeds

>From Daniel Gryniewicz : Daniel Gryniewicz has uploaded this change for review. ( https://review.gerrithub.io/404816 Change subject: Don't dec open_fd_count unless close succeeds .. Don't dec open_fd_count

Re: [Nfs-ganesha-devel] Release V2.6.1

On 03/20/2018 10:09 AM, Daniel Gryniewicz wrote: > I'd like to announce the release of the latest stable version of Ganesha: > 2.6.1 > As a convenience, "community" packages of nfs-ganesha-2.6.1, including (lib)ntirpc-1.6.2, are provided in or for the following Linux distributions: * Fedora 28

Re: [Nfs-ganesha-devel] nss_getpwnam: name 't...@my.dom@localdomain' does not map into domain 'nix.my.dom'

I don't think this works because of option(). This defines the value to it's default (OFF if no default is given), so the value is always defined. We can skip using option, but this will break anyone using any tools to automate their cmake. What we need is for option() to distinguish

Re: [Nfs-ganesha-devel] nss_getpwnam: name 't...@my.dom@localdomain' does not map into domain 'nix.my.dom'

No, we can't. I'm working on a set of macros that make this work (as far as I can tell) and aren't *too* ugly. Hopefully, this will work out. Daniel On 03/22/2018 12:13 PM, Malahal Naineni wrote: That could be a reason why I thought we need two symbols for a feature. For example,

Re: [Nfs-ganesha-devel] nss_getpwnam: name 't...@my.dom@localdomain' does not map into domain 'nix.my.dom'

That could be a reason why I thought we need two symbols for a feature. For example, USE_GPFS_FSAL could be used at cmake command line and GPFS_FSAL could be used in the option(). Can't we use this option() inside conditionals? regards, malahal. On Thu, Mar 22, 2018 at 8:43 PM, Daniel

Re: [Nfs-ganesha-devel] nss_getpwnam: name 't...@my.dom@localdomain' does not map into domain 'nix.my.dom'

Here is what I wanted. Let us say there is a compilation feature called USE_FSAL_GPFS. I want these possibilities: 1. If I enable this feature at the "cmake command line", enable this. If it can't be enabled due to missing packages, then please fail cmake! 2. If I disable this feature at the

[Nfs-ganesha-devel] Change in ffilz/nfs-ganesha[next]: Add new CMake option code

>From Daniel Gryniewicz : Daniel Gryniewicz has uploaded this change for review. ( https://review.gerrithub.io/404945 Change subject: Add new CMake option code .. Add new CMake option code CMake options were

Re: [Nfs-ganesha-devel] nss_getpwnam: name 't...@my.dom@localdomain' does not map into domain 'nix.my.dom'

On 3/22/2018 12:50 PM, Daniel Gryniewicz wrote: A side note, happy to test for you guy's once you have this done. No, we can't.  I'm working on a set of macros that make this work (as far as I can tell) and aren't *too* ugly.  Hopefully, this will work out. Daniel On 03/22/2018 12:13 PM,

[Nfs-ganesha-devel] Review request https://review.gerrithub.io/#/c/393642/

Hi Malahal, Since this change has an impact on FSAL_GPFS, please review this change: https://review.gerrithub.io/#/c/393642/ -- Thanks Girjesh -- Check out the vibrant tech community on one of the world's most