Branch next
Tag:V2.3-rc2
NOTE: This tag includes a libntirpc update, please make sure your
submodule is updated before pushing additional submissions.
Highlights
* NFS v4 state bug fixes
* NLM bug fixes
* Debug improvements
* Added FORK command to multilock tool
* Update FSAL Major version
On 9/11/15 4:00 PM, Matt Benjamin wrote:
> There is probably no need to pullup ntirpc twice.
>
Only for bisection, and getting the gerrit autocompiles to
work. RDMA depends on the RDMA commits. CMAKE depends on the
_later_ CMAKE commits.
Just ensure Dan's CMAKE patch comes after my RDMA patch,
o
There is probably no need to pullup ntirpc twice.
Matt
--
Matt Benjamin
Red Hat, Inc.
315 West Huron Street, Suite 140A
Ann Arbor, Michigan 48103
http://www.redhat.com/en/technologies/storage
tel. 734-761-4689
fax. 734-769-8938
cel. 734-216-5309
- Original Message -
> From: "Willia
On 9/11/15 3:07 PM, William Allen Simpson wrote:
> I've redone the entire sequence for the umpteenth time and sent the
> entire log to Dan. Maybe he can see the issue with every bit of
> data I've got, unexpurgated.
>
All praise to Dan! It was in the script that I've been using to
setup and run g
On 9/11/15 2:33 PM, Daniel Gryniewicz wrote:
> I want to understand the sequence. This is what I'm reading (in
> pseudocode...)
>
> git clone ganesha
> cmake ...
> make install
> rm -rf build
> patch < gerrithub
> cmake ...
> make install
>
> Is that correct? Nowhere in that sequence involved ch
I want to understand the sequence. This is what I'm reading (in pseudocode...)
git clone ganesha
cmake ...
make install
rm -rf build
patch < gerrithub
cmake ...
make install
Is that correct? Nowhere in that sequence involved checking out
duplex-12 from ntirpc?
It should not be installing anyth
Hi Bill,
If it installed libntirpc.so.1.3.0 (*) in 2 places, it's broken.
If it installed FSALs in lib64/ganesha and ntirpc in lib64, then it did what
Dan intended, iirc.
In order to be -looking for them- there, the end user will need to update
LD_LIBRARY_PATH and/or
edit /etc/ld.so.conf (Linu
On 9/11/15 2:01 PM, Matt Benjamin wrote:
> I think this patch is as ready as it can be. What Dan sent to gerrit will
> behave correctly for anyone
> not updating ntirpc branches by hand.
>
Sorry, Matt, but this was a fresh install with no updating ntirpc.
I compiled and installed before Dan's pa
I think this patch is as ready as it can be. What Dan sent to gerrit will
behave correctly for anyone
not updating ntirpc branches by hand.
Matt
--
Matt Benjamin
Red Hat, Inc.
315 West Huron Street, Suite 140A
Ann Arbor, Michigan 48103
http://www.redhat.com/en/technologies/storage
tel. 734-
> I have +2 code reviewed all the patches I am considering staged for rc2. I
will
> start the merge Friday morning.
>
> I figured out the problem with cthon04, turns out we actually had a bug in
> RELEASE_LOCKOWNER that has been there for quite some time...
>
> I was also wrong about lock owners,
My first "attempt" at versioning is still the one we're using, but Dan:
a) put the ntirpc version on the output file (which I forgot to do)
b) put the libntirpc.so in a better location
c) moved Ganesha CMakeLists.txt into a subdir so the standalone build could
have a CMakeLists.txt
The install d
> On 9/11/15 5:16 AM, Malahal Naineni wrote:
> > pycheckpatch is only run when you explicitly run it. checkpatch.pl is
> > run as part of a githook, so this must be it!
> >
> > What git command were you running to get this? In any case, looks like
> > you don't have ganesha checkpath config file in
>From Malahal :
Malahal has uploaded a new change for review.
https://review.gerrithub.io/246447
Change subject: Add get grace status dbus method
..
Add get grace status dbus method
dbus method to know if ganesha is in grace
On 9/11/15 1:34 PM, William Allen Simpson wrote:
> The date on the latter libntirpc.so seems slightly off. Is this an
> old place for storing it? Or confusing the loader?
>
Yes, my next older log shows:
-- Installing: /home/bill/rdma/install/var/run/ganesha
-- Installing: /home/bill/rdma/install
Okay, this is probably left over from you having Matt's first attempt
at .so versioning. Try nuking your /lib* and re-running make
install?
Daniel
On Fri, Sep 11, 2015 at 1:34 PM, William Allen Simpson
wrote:
> On 9/11/15 1:18 PM, William Allen Simpson wrote:
>>
>> Stayed up w-a-y too late last
On 9/11/15 1:18 PM, William Allen Simpson wrote:
> Stayed up w-a-y too late last night poking at this.
>
> Somebody else has to verify things are working for them.
>
> On 9/11/15 8:19 AM, Daniel Gryniewicz wrote:
>> It's installed in /lib[64]. If you're not installing into a
>> standard location,
On 9/11/15 5:16 AM, Malahal Naineni wrote:
> pycheckpatch is only run when you explicitly run it. checkpatch.pl is
> run as part of a githook, so this must be it!
>
> What git command were you running to get this? In any case, looks like
> you don't have ganesha checkpath config file in the correct
Stayed up w-a-y too late last night poking at this.
Somebody else has to verify things are working for them.
On 9/11/15 8:19 AM, Daniel Gryniewicz wrote:
> It's installed in /lib[64]. If you're not installing into a
> standard location, you will need to add /lib[64] to your
> LD_LIBRARY_PATH, bu
-Original Message-
From: linux-nfs-ow...@vger.kernel.org [mailto:linux-nfs-ow...@vger.kernel.org]
On Behalf Of Steve Dickson
Sent: Thursday, September 10, 2015 2:33 PM
To: Linux NFS Mailing list
Subject: BAT-Oct-15 Who's in Who's out
Hello,
Just a quick reminder the deadline for hotel
>From :
ka...@redhat.com has uploaded a new change for review.
https://review.gerrithub.io/246442
Change subject: MainNFSD: 32-bit compile errors on Fedora Koji rawhide
..
MainNFSD: 32-bit compile errors on Fedora Koji rawhid
>From :
ka...@redhat.com has uploaded a new change for review.
https://review.gerrithub.io/246444
Change subject: SAL: 32-bit compile errors on Fedora Koji rawhide
..
SAL: 32-bit compile errors on Fedora Koji rawhide
fixes f
>From :
ka...@redhat.com has uploaded a new change for review.
https://review.gerrithub.io/246437
Change subject: all: 32-bit compile errors on Fedora Koji rawhide
..
all: 32-bit compile errors on Fedora Koji rawhide
fixes f
>From :
ka...@redhat.com has uploaded a new change for review.
https://review.gerrithub.io/246441
Change subject: config_parsing: 32-bit compile errors on Fedora Koji rawhide
..
config_parsing: 32-bit compile errors on Fedora
>From :
ka...@redhat.com has uploaded a new change for review.
https://review.gerrithub.io/246439
Change subject: cache_inode: 32-bit compile errors on Fedora Koji rawhide
..
cache_inode: 32-bit compile errors on Fedora Koji
>From :
ka...@redhat.com has uploaded a new change for review.
https://review.gerrithub.io/246424
Change subject: all: 32-bit compile errors on Fedora Koji rawhide
..
all: 32-bit compile errors on Fedora Koji rawhide
fixes f
>From :
william.allen.simp...@gmail.com has uploaded a new change for review.
https://review.gerrithub.io/246391
Change subject: Integrate Mooshika into RPC RDMA
..
Integrate Mooshika into RPC RDMA
Change-Id: I0fa62c2cf0
Hi,
If we permit conditional linkage against a static libntirpc, I would
strongly prefer that it be explicit (config option that defaults to
OFF).
I don't think static linkage actually adds much to ease of use, since
everybody should understand platform rules for shlibs.
Matt
- "Daniel Gryn
Correct, however the non-VFS FSALs all need external libraries (such
as libcephfs for Ceph) that would not be in lib/ganesha.
Also, since FSALs are dlopen()'d by full path, it's not necessary to
have lib/ganesha in your LD_LIBRARY_PATH.
Is it worth making a static version of libntirpc that Ganesh
FSALs are typically installed under ganesha directory, so if he is using
a non-standard location, he probably is already using ".../ganesha"
path, now he needs to add "..." directory as well, correct?
Regards, Malahal.
Daniel Gryniewicz [d...@redhat.com] wrote:
> It's installed in /lib[64]. If y
It's installed in /lib[64]. If you're not installing into a
standard location, you will need to add /lib[64] to your
LD_LIBRARY_PATH, but it probably should have been there before.
Certainly that would have been necessary if any non-VFS FSALs were in
use.
ntirpc used to be statically linked, it's
On 09/10/2015 06:47 PM, Frank Filz wrote:
> Could you push this patch to gerrithub?
>
yeah yeah. I had other things to do yesterday and ran out of time. But I
wanted to get it out there in case anyone thought it was urgent.
> Thanks
>
> Frank
>
>> -Original Message-
>> From: Kaleb KEIT
William Allen Simpson [william.allen.simp...@gmail.com] wrote:
> On 9/10/15 7:42 PM, Frank Filz wrote:
> > Dan - no one has reviewed your patch yet, so I did not stage that. If it
> > gets positive review by morning I will add it to the staging. If anyone
> > wants to review:
> >
> > https://review
32 matches
Mail list logo
