While attempting to build a (pre-)5.0 of glusterfs on Ubuntu
bionic and cosmic, it became apparent that there are some gremlins
hiding in the combination of the xlator export-symbols, the newish
addition of -Wl,--no-undefined, and the new switch to libuuid from
the old contrib/uuid.

Note: even though Fedora 28 (and later) and Ubuntu bionic (and
later) have the same nominal version of libtool, the Fedora version
appears to do a better job of recursing through dependencies to
determine the libraries to link with.

Examination of the build logs showed that despite appearing to work
on Fedora, not all xlators and shared libs were linked with -Wl,
--no-undefined, and -luuid. And in the case of the gnfs xlator, it
was not only not linked with -Wl,--no-undefined but alsos not linked
with -lgfxdr and -lgfrpc.

Added GF_XLATOR_LDFLAGS, similar to GF_XLATOR_DEFAULT_LDFLAGS.
GF_XLATOR_DEFAULT_LDFLAGS is for xlators that export/expose the
default or common set of symbols. GF_XLATOR_LDFLAGS is for those
remaining xlators that export/expose non-default symbols, e.g. dht
and glupy. This removes the need in the future to add things like
$(UUID_LIBS) to every xlator's Makefile.am. Just add it to
GF_XLATOR_LDFLAGS and GF_XLATOR_DEFAULT_LDFLAGS in configure.ac
and you're done.

This patch was tested on Fedora 28 (build, rpmbuild), Fedora
Rawhide/30 (rpmbuild), RHEL8 (rpmbuild), CentOS7 (rpmbuild), Fedora
koji --scratch build for f30/rawhide, and a Launchpad build for
Ubuntu cosmic/18.10.

Change-Id: Ieca104fa5c5d3c094e701c8ca4a73754dd0292b0
updates: bz#1193929
Signed-off-by: Kaleb S. KEITHLEY <kkeithle@redhat.com>

Change-Id: If3925191d23afe83cbbdbc3cf0554c0a9c76d043
updates: bz#1564149
Signed-off-by: Amar Tumballi <amarts@redhat.com>

Change-Id: Ia84cc24c8924e6d22d02ac15f611c10e26db99b4
Signed-off-by: Nigel Babu <nigelb@redhat.com>

Change-Id: I6f5d8140a06f3c1b2d196849299f8d483028d33b

The recent changes to use malloc instead
of calloc left the new_name and new_path
non-null terminated. We now use snprintf
instead of strncpy to fix this.

Change-Id: I1a31701ca9447efde38921be0ba2c73cde2e7976
fixes: bz#1626346
Signed-off-by: N Balachandran <nbalacha@redhat.com>

This patch is continuation of commit
fb4b914ce84bc83a5f418719c5ba7c25689a9251.

<snip>
mount/fuse: never fail open(dir) with ENOENT

    open(dir) being an operation on inode should never fail with
    ENOENT. If gfid is not present, the appropriate error is
    ESTALE. This will enable kernel to retry open after a revalidate
    lookup.
</snip>

Earlier commit failed to fix codepath where error response is sent
back on gfid resolution failures in fuse_open(dir)_resume. Current
patch completes that work

Change-Id: Ia07e3cece404811703c8cfbac9b402ca5fe98c1e
Signed-off-by: Raghavendra G <rgowdapp@redhat.com>
updates: bz#1627620

Surprisingly, there is not set_boolean() as there is a get_boolean()
In fact, it is stored as an INT dictionary type.

In some occasions it was stored using a string, and this caused
errors such as:
key gfproxy-server, integer type asked, has string type [Invalid argument]

I've fixed what I saw in some logs, I'm sure there are more.
The CORRECT fix is to create a boolean set and use it, but this
requires a bit more work. I'll see if I can do it later on.

Only compile-tested!

updates: bz#1193929
Signed-off-by: Yaniv Kaul <ykaul@redhat.com>

Change-Id: I45fd0c7a0824b2f42b8ce510296c9dfa4f32ad66

problem: NULL point dereferencing

solution: Adding a conditional statement before and then dereferencing it.

Updates: bz#1622665

Change-Id: I562ca90aebf2a4882cfea10114a90364d9ef1996
Signed-off-by: Harpreet Lalwani <hlalwani@redhat.com>

* One #!/usr/bin/env python and three #!/usr/bin/python were overlooked
  in all the other python fixups. Ugh.

* Two new python files missed the memo about #!/usr/bin/python3.

* One #!/usr/bin/env bash.
  Various distribution packaging policies have strong wording about
  the use of #!/usr/bin/env ...

  Note: this patch does not change the use of #!/usr/bin/env bash in
  the two files extras/{clang-checker.sh,check_goto.pl} as these are
  not included in any packages. (Although I'm not actually sure why
  anyone would ever use '/usr/bin/env {sh,bash}' as I'm not aware of
  any version-specific differences like there are with, e.g., python.)

* One #!/usr/bin/bash.
  On Fedora and CentOS > 6, /bin is a symlink to /usr/bin, so it
  makes little difference. But Debian & Ubuntu still have separate
  /bin and /usr/bin; and sh and bash are in /bin, not /usr/bin.
  (Historically, in BSD and SYSV Unix it was /bin/sh.)

  Note: Fedora and CentOS package build runs a script that converts
  all /bin/sh and /bin/bash to /usr/bin/sh and /usr/bin/bash.

Change-Id: I9171265829af78dd0cd7622c22b56d22179ff8a3
updates: bz#1193929
Signed-off-by: Kaleb S. KEITHLEY <kkeithle@redhat.com>

Fixes CID: 1388886

https://scan6.coverity.com/reports.htm#v42607/p10714/fileInstanceId=85287446&defectInstanceId=25997291&mergedDefectId=1388886

Change-Id: Ic4e558bba7e15d213c07bc31affb2e175ace5502
updates: bz#789278
Signed-off-by: Ashish Pandey <aspandey@redhat.com>