Bug 1026337 - Review Request: nfs-ganesha — a user-mode file server for NFS (v3, 4.0,4.1 pNFS)
Review Request: nfs-ganesha — a user-mode file server for NFS (v3, 4.0,4.1 pNFS)
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
19
All Linux
medium Severity medium
: ---
: ---
Assigned To: Zbigniew Jędrzejewski-Szmek
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-11-04 08:13 EST by Kaleb KEITHLEY
Modified: 2014-01-13 09:13 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-11-26 10:18:03 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
zbyszek: fedora‑review+
limburgher: fedora‑cvs+


Attachments (Terms of Use)
systemd unit file (235 bytes, text/plain)
2013-11-04 16:25 EST, Zbigniew Jędrzejewski-Szmek
no flags Details

  None (edit)
Description Kaleb KEITHLEY 2013-11-04 08:13:37 EST
Spec URL: http://kkeithle.fedorapeople.org/nfs-ganesha.spec
SRPM URL: http://kkeithle.fedorapeople.org/nfs-ganesha-2.0.0-0.rc2.fc19.src.rpm

Description: Nfs-ganesha is a user-mode file server for NFS (v3, 4.0,4.1 pNFS)

 +:ok, =:needs attention, -:needs fixing

MUST Items:
[+] MUST: rpmlint must be run on every package.

rpmlint SPECS/nfs-ganesha.spec SRPMS/nfs-ganesha-2.0.0-0.rc2.fc19.src.rpm RPMS/x86_64/nfs-ganesha-2.0.0-0.rc2.fc19.x86_64.rpm 
SPECS/nfs-ganesha.spec:50: W: rpm-buildroot-usage %prep cmake -DCMAKE_BUILD_TYPE=Maintainer -DDEBUG_SYMS=ON -DBUILD_CONFIG=everything -DCMAKE_INSTALL_PREFIX=%{buildroot}/usr ./src
nfs-ganesha.src: W: spelling-error %description -l en_US pNFS -> snuffs
nfs-ganesha.src:50: W: rpm-buildroot-usage %prep cmake -DCMAKE_BUILD_TYPE=Maintainer -DDEBUG_SYMS=ON -DBUILD_CONFIG=everything -DCMAKE_INSTALL_PREFIX=%{buildroot}/usr ./src
nfs-ganesha.x86_64: W: spelling-error %description -l en_US pNFS -> snuffs
nfs-ganesha.x86_64: W: no-manual-page-for-binary ganesha.nfsd
nfs-ganesha.x86_64: W: no-manual-page-for-binary ganestat.pl
2 packages and 1 specfiles checked; 0 errors, 6 warnings.

[+] MUST: The package must be named according to the Package Naming Guidelines.
[+] MUST: The spec file name must match the base package %{name}
[+] MUST: The package must meet the Packaging Guidelines.
[+] MUST: The package must be licensed with a Fedora approved license and meet the Licensing Guidelines.
[+] MUST: The License field in the package spec file must match the actual license.
[+] MUST: If (and only if) the source package includes the text of the license(s) in its own file, then that file, containing the text of the license(s) for the package must be included in %doc.
[+] MUST: The spec file must be written in American English.
[+] MUST: The spec file for the package MUST be legible.
[+] MUST: The sources used to build the package must match the upstream source, as provided in the spec URL.

7d9352877359d53e89156ba7bfcb1a7d  libntirpc-0.1.11.tgz
06876b2c54c2d8e666f58a96738e3863  nfs-ganesha-2.0.0rc2.tgz

[+] MUST: The package must successfully compile and build into binary rpms on at least one supported architecture.
[+] MUST: If the package does not successfully compile, build or work on an architecture, then those architectures should be listed in the spec in ExcludeArch.
[+] MUST: All build dependencies must be listed in BuildRequires
[+] MUST: The spec file MUST handle locales properly. This is done by using the %find_lang macro.
[+] MUST: Every binary RPM package which stores shared library files (not just symlinks) in any of the dynamic linker's default paths, must call ldconfig in %post and %postun.
[+] MUST: If the package is designed to be relocatable, the packager must state this fact in the request for review
[+] MUST: A package must own all directories that it creates. If it does not create a directory that it uses, then it should require a package which does create that directory.
[+] MUST: A package must not contain any duplicate files in the %files listing.
[+] MUST: Permissions on files must be set properly. Executables should be set with executable permissions, for example. Every %files section must include a %defattr(...) line.
[+] MUST: Each package must have a %clean section, which contains rm -rf %{buildroot} (or $RPM_BUILD_ROOT).
[+] MUST: Each package must consistently use macros, as described in the macros section of Packaging Guidelines.
[+] MUST: The package must contain code, or permissible content. This is described in detail in the code vs. content section of Packaging Guidelines.
[+] MUST: Large documentation files should go in a doc subpackage.
[+] MUST: If a package includes something as %doc, it must not affect the runtime of the application.
[+] MUST: Header files must be in a -devel package.
[+] MUST: Static libraries must be in a -static package.
[+] MUST: Packages containing pkgconfig(.pc) files must 'Requires: pkgconfig' (for directory ownership and usability).
[+] MUST: If a package contains library files with a suffix (e.g. libfoo.so.1.1), then library files that end in .so (without suffix) must go in a -devel package.
[+] MUST: In the vast majority of cases, devel packages must require the base package using a fully versioned dependency: Requires: %{name} = %{version}-%{release} 
[+] MUST: Packages must NOT contain any .la libtool archives, these should be removed in the spec.
[+] MUST: Packages containing GUI applications must include a %{name}.desktop file, and that file must be properly installed with desktop-file-install in the %install section.
[+] MUST: Packages must not own files or directories already owned by other packages.
[+] MUST: At the beginning of %install, each package MUST run rm -rf %{buildroot} (or $RPM_BUILD_ROOT).
[+] MUST: All filenames in rpm packages must be valid UTF-8.

SHOULD Items:
[+] SHOULD: If the source package does not include license text(s) as a separate file from upstream, the packager SHOULD query upstream to include it.
[] SHOULD: The description and summary sections in the package spec file should contain translations for supported Non-English languages, if available.
[+] SHOULD: The reviewer should test that the package builds in mock.
[+] SHOULD: The package should compile and build into binary rpms on all supported architectures.
[+] SHOULD: The reviewer should test that the package functions as described.
[+] SHOULD: If scriptlets are used, those scriptlets must be sane.
[+] SHOULD: Usually, subpackages other than devel should require the base package using a fully versioned dependency.
[+] SHOULD: The placement of pkgconfig(.pc) files depends on their usecase, and this is usually for development purposes, so should be placed in a -devel pkg. A reasonable exception is that the main pkg itself is a devel tool not installed in a user runtime, e.g. gcc or gdb.
[+] SHOULD: If the package has file dependencies outside of /etc, /bin, /sbin, /usr/bin, or /usr/sbin consider requiring the package which provides the file instead of the file itself.
[+] SHOULD: Packages should try to preserve timestamps of original installed files.
Comment 1 Zbigniew Jędrzejewski-Szmek 2013-11-04 10:22:28 EST
1. Remove %defattr(-,root,root)

2. Remove rm -rf %{buildroot}

3. Remove %clean

4. Why are libntirpc sources necessary? Shouldn't this be a separate package?

5. It would be nicer to use direct github url as Source0: https://github.com/%{name}/%{name}/archive/pre-2.0-RC2.tar.gz. This way it's easier to update, verify sources, etc.

6. %description could become Summary, and please extend the description a bit, saying a bit more what the project is useful for etc.

8. There's no need to say %{__tar}, %{__rm}, %{__make}, %{__chmod}. Just use plain tar, rm... Such indirection only makes sense for things that are likely to be substituted at some point, like %{__python2}.

9. Please add Provides: bundled(gnulib).

10. Please split out big docs into a separate package (size ~ 2MB).

11. Please change cmake to %cmake.

12. Please change %{__make} to make VERBOSE=1 %{?_smp_mflags}.

13. libzfswrap cannot be bundled (https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries). Please remove it in %prep.

Oh, and I think you have a very old fedora-review, which is provided outdated suggestions.
Comment 2 Kaleb KEITHLEY 2013-11-04 12:54:48 EST
> 1. Remove %defattr(-,root,root)
> 
> 2. Remove rm -rf %{buildroot}
> 
> 3. Remove %clean
> 
> 4. Why are libntirpc sources necessary?

If it is not already obvious, nfs-ganesha doesn't build without them.

> Shouldn't this be a separate package?

No, it shouldn't. libntirpc not ready to be a stand-alone package. When it's ready it will be packaged separately and removed from the nfs-ganesha build.

> 5. It would be nicer to use direct github url as Source0: https://github.com
> /%{name}/%{name}/archive/pre-2.0-RC2.tar.gz. This way it's easier to update, > verify sources, etc.

It doesn't exist. (Using it now would result in an additional rpmlint warning.)

Eventually it will be there and when it is then it'll be used. I don't consider this as a show stopper for the review.

> 
> 6. %description could become Summary, and please extend the description a 
> bit, saying a bit more what the project is useful for etc.

Say more about what an NFS server is useful for?

> 7. [ nothing here ]
> 
> 8. There's no need to say %{__tar}, %{__rm}, %{__make}, %{__chmod}. Just use > plain tar, rm... Such indirection only makes sense for things that are likely 
> to be substituted at some point, like %{__python2}.

https://fedoraproject.org/wiki/Packaging:ReviewGuidelines?rd=Packaging/ReviewGuidelines says "MUST: ... use macros".  I used macros.

> 9. Please add Provides: bundled(gnulib).

It doesn't provide gnulib, bundled or otherwise. I don't know what this refers to.

> 
> 10. Please split out big docs into a separate package (size ~ 2MB).
> 
> 11. Please change cmake to %cmake.

This RC doesn't build with %cmake. I will notify the upstream developers and maybe they can fix this for the next RC. (I am only kickstarting the packaging, as a favor.)

> 
> 12. Please change %{__make} to make VERBOSE=1 %{?_smp_mflags}.
> 
> 13. libzfswrap cannot be bundled (https://fedoraproject.org
> /wiki/Packaging:No_Bundled_Libraries). Please remove it in %prep.

There is no libzfswrap bundled. There is nothing in %prep about libzfswrap.

> 
> Oh, and I think you have a very old fedora-review, which is provided outdated > suggestions.

Do you mean the template? It's the one from 
https://fedoraproject.org/wiki/PackagingDrafts/ReviewTemplate. It is mostly consistent with https://fedoraproject.org/wiki/Packaging:ReviewGuidelines?rd=Packaging/ReviewGuidelines.

Updated files at

Spec URL: http://kkeithle.fedorapeople.org/update-1/nfs-ganesha.spec
SRPM URL: http://kkeithle.fedorapeople.org/update-1/nfs-ganesha-2.0.0-0.rc2.fc19.src.rpm
Comment 3 Zbigniew Jędrzejewski-Szmek 2013-11-04 13:24:04 EST
(In reply to Kaleb KEITHLEY from comment #2)
> > 1. Remove %defattr(-,root,root)
> > 
> > 2. Remove rm -rf %{buildroot}
> > 
> > 3. Remove %clean
> > 
> > 4. Why are libntirpc sources necessary?
> 
> If it is not already obvious, nfs-ganesha doesn't build without them.
> 
> > Shouldn't this be a separate package?
> 
> No, it shouldn't. libntirpc not ready to be a stand-alone package. When it's
> ready it will be packaged separately and removed from the nfs-ganesha build.
OK. It would be nice to have this as a comment in the spec, so people don't wonder if this is a bundled library.

> > 5. It would be nicer to use direct github url as Source0: https://github.com
> > /%{name}/%{name}/archive/pre-2.0-RC2.tar.gz. This way it's easier to update, > verify sources, etc.
> 
> It doesn't exist. (Using it now would result in an additional rpmlint
> warning.)
It exits, I actually tested the link before posting.

> Eventually it will be there and when it is then it'll be used. I don't
> consider this as a show stopper for the review.
Sure, just nice to have.
 
> > 
> > 6. %description could become Summary, and please extend the description a 
> > bit, saying a bit more what the project is useful for etc.
> 
> Say more about what an NFS server is useful for?
Well, I think that would be useful: not every user immediately knows what NFS stands for, some think that it stands for Need For Speed. What I had in mind, was why *this* NFS server, what does it do better than the other ones.

> > 7. [ nothing here ]
> > 
> > 8. There's no need to say %{__tar}, %{__rm}, %{__make}, %{__chmod}. Just use > plain tar, rm... Such indirection only makes sense for things that are likely 
> > to be substituted at some point, like %{__python2}.
> 
> https://fedoraproject.org/wiki/Packaging:ReviewGuidelines?rd=Packaging/
> ReviewGuidelines says "MUST: ... use macros".  I used macros.
Actually is says "must use macros *consistently*", which is not the same. If you follow the link it says "use macros instead of hard-coded *directory* names", "rm should be used in preference to %{__rm}".

> > 9. Please add Provides: bundled(gnulib).
> 
> It doesn't provide gnulib, bundled or otherwise. I don't know what this
> refers to.
Yeah, my error.

> > 10. Please split out big docs into a separate package (size ~ 2MB).
> > 
> > 11. Please change cmake to %cmake.
> 
> This RC doesn't build with %cmake. I will notify the upstream developers and
> maybe they can fix this for the next RC. (I am only kickstarting the
> packaging, as a favor.)
> 
> > 
> > 12. Please change %{__make} to make VERBOSE=1 %{?_smp_mflags}.
> > 
> > 13. libzfswrap cannot be bundled (https://fedoraproject.org
> > /wiki/Packaging:No_Bundled_Libraries). Please remove it in %prep.
> 
> There is no libzfswrap bundled. There is nothing in %prep about libzfswrap.
When I unpack the sources, I have

contrib/libzfswrap

This directory should be removed in %prep, according to https://fedoraproject.org/wiki/Packaging:Treatment_Of_Bundled_Libraries.
Possibly other steps must be taken later on, but this is the first one.

> > 
> > Oh, and I think you have a very old fedora-review, which is provided outdated > suggestions.
> 
> Do you mean the template? It's the one from 
> https://fedoraproject.org/wiki/PackagingDrafts/ReviewTemplate. It is mostly
> consistent with
> https://fedoraproject.org/wiki/Packaging:ReviewGuidelines?rd=Packaging/
> ReviewGuidelines.
Hm, indeed. So this template is in contradiction to the guidelines, e.g. because %clean is now discouraged, while it is a MUST in the template. 

> Updated files at
> 
> Spec URL: http://kkeithle.fedorapeople.org/update-1/nfs-ganesha.spec
> SRPM URL:
> http://kkeithle.fedorapeople.org/update-1/nfs-ganesha-2.0.0-0.rc2.fc19.src.
> rpm

There's now -rc3.
Comment 4 Kaleb KEITHLEY 2013-11-04 14:27:50 EST
>> Say more about what an NFS server is useful for?
> Well, I think that would be useful: not every user immediately knows what NFS > stands for, some think that it stands for Need For Speed. What I had in mind, > was why *this* NFS server, what does it do better than the other ones.

I'll see what upstream wants to add beyond what's there.

New files address all your other comments:

Spec URL: http://kkeithle.fedorapeople.org/update-2/nfs-ganesha.spec
SRPM URL: http://kkeithle.fedorapeople.org/update-2/nfs-ganesha-2.0.0-0.rc2.fc19.src.rpm
Comment 5 Kaleb KEITHLEY 2013-11-04 14:37:26 EST
Make that 
SRPM URL: http://kkeithle.fedorapeople.org/update-2/nfs-ganesha-2.0.0-0.rc3.fc19.src.rpm
Comment 6 Zbigniew Jędrzejewski-Szmek 2013-11-04 14:51:59 EST
Doesn't build on i686: http://koji.fedoraproject.org/koji/taskinfo?taskID=6137558
Comment 7 Zbigniew Jędrzejewski-Szmek 2013-11-04 15:03:04 EST
Neither on arm: http://koji.fedoraproject.org/koji/taskinfo?taskID=6137609
Comment 8 Kaleb KEITHLEY 2013-11-04 15:12:58 EST
> Doesn't build on i686: http://koji.fedoraproject.org/koji/taskinfo?taskID=6137558
> Neither on arm: http://koji.fedoraproject.org/koji/taskinfo?taskID=6137609

Upstream notified. 32-bit builds disabled in the mean time. New files at

Spec URL: http://kkeithle.fedorapeople.org/update-3/nfs-ganesha.spec
SRPM URL: http://kkeithle.fedorapeople.org/update-3/nfs-ganesha-2.0.0-0.rc2.fc19.src.rpm
Comment 9 Kaleb KEITHLEY 2013-11-04 15:20:51 EST
Upstream notified. 32-bit builds disabled in the mean time. New files at

Spec URL: http://kkeithle.fedorapeople.org/update-3/nfs-ganesha.spec
SRPM URL: http://kkeithle.fedorapeople.org/update-3/nfs-ganesha-2.0.0-0.rc3.fc19.src.rpm
Comment 10 Zbigniew Jędrzejewski-Szmek 2013-11-04 16:25:38 EST
Created attachment 819351 [details]
systemd unit file
Comment 11 Zbigniew Jędrzejewski-Szmek 2013-11-04 16:27:21 EST
Hm, the package doesn't build in mock --rebuild, but it works if I do mock --shell and rebuild it by hand there. Maybe a cmake bug? It builds in koji, so let's ignore that.

1. License is something like "BSD (3 clause) and LGPLv3+", because of libntirpc

2. It would be better to put the docs in /usr/share/doc/nfs-ganesha (not -docs).

3. docs package should also have a copy of the LGPLv3+ license.

4. Suggestion: change the she-bang line in /usr/bin/genestat.pl to /usr/bin/perl. This will help automatic requires at least.

5. Requires: krb5 seems to be unsatisfiable. Is it actually necessary to have anything kerberos-related installed locally?

6. systemd service file is missing.

Something like the attached unit file is a good start.
Please have a look at https://fedoraproject.org/wiki/Packaging:Systemd.
BuildRequires: systemd-units
Comment 12 Kaleb KEITHLEY 2013-11-04 18:06:09 EST
> 1. License is something like "BSD (3 clause) and LGPLv3+", because of libntirpc

yes, nfs-ganesha is LGPLv3+, and libntirpc is BSD (as is libtirpc, which it is derived from)

> 
> 2. It would be better to put the docs in /usr/share/doc/nfs-ganesha (not -docs).

??? In the RPMs I have built the docs are in /usr/share/doc/nfs-ganesha-2.0.0/

> 
> 3. docs package should also have a copy of the LGPLv3+ license.
>
> 4. Suggestion: change the she-bang line in /usr/bin/genestat.pl to /usr/bin/perl. This will help automatic requires at least.
> 
> 5. Requires: krb5 seems to be unsatisfiable. Is it actually necessary to have anything kerberos-related installed locally?
> 
> 6. systemd service file is missing.
> 
> Something like the attached unit file is a good start.
> Please have a look at https://fedoraproject.org/wiki/Packaging:Systemd.
> BuildRequires: systemd-units

new files at 

Spec URL: http://kkeithle.fedorapeople.org/update-4/nfs-ganesha.spec
SRPM URL: http://kkeithle.fedorapeople.org/update-4/nfs-ganesha-2.0.0-0.rc3.fc19.src.rpm
Comment 13 Kaleb KEITHLEY 2013-11-04 18:41:29 EST
>> 
>> 2. It would be better to put the docs in /usr/share/doc/nfs-ganesha (not -docs).
> 
> ??? In the RPMs I have built the docs are in /usr/share/doc/nfs-ganesha-2.0.0/

never mind.

new files at 

Spec URL: http://kkeithle.fedorapeople.org/update-5/nfs-ganesha.spec
SRPM URL: http://kkeithle.fedorapeople.org/update-5/nfs-ganesha-2.0.0-0.rc3.fc19.src.rpm
Comment 14 Kaleb KEITHLEY 2013-11-05 10:26:03 EST
>> 
>> 2. It would be better to put the docs in /usr/share/doc/nfs-ganesha (not -docs).
> 
> ??? In the RPMs I have built the docs are in /usr/share/doc/nfs-ganesha-2.0.0/

never mind, I was confused.

new files at 

Spec URL: http://kkeithle.fedorapeople.org/update-5/nfs-ganesha.spec
SRPM URL: http://kkeithle.fedorapeople.org/update-5/nfs-ganesha-2.0.0-0.rc3.fc19.src.rpm
Comment 15 Zbigniew Jędrzejewski-Szmek 2013-11-05 10:40:58 EST
Ooops, parallel build is borked:

[ 65%] [ 65%] make[2]: *** No rule to make target `libntirpc/src/libntirpc.a', needed by `FSAL/FSAL_PROXY/libfsalproxy.so.4.2.0'.  Stop.

It seems to be a race condition, because it sometimes worked. I removed %{_smp_flags} to get it to compile.

Build issue aside, I find it hard to justify how including this library doesn't violate https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries. You said that "it'll be split out when ready", but actually is seems to be
a totally separate project. I'd approve the package as is, otherwise.

nfs-ganesha.src:62: W: rpm-buildroot-usage %prep %cmake -DCMAKE_BUILD_TYPE=Maintainer -DBUILD_CONFIG=everything -DCMAKE_INSTALL_PREFIX=%{buildroot}/usr ./src
Yeah, %cmake step should be moved to %build.

[!]: Package must own all directories that it creates.
     Note: Directories without known owners: /usr/share/doc/nfs-ganesha-2.0.0
Directory ownership is missing.

Rpmlint (installed packages)
----------------------------
# rpmlint nfs-ganesha nfs-ganesha-docs
nfs-ganesha.x86_64: E: explicit-lib-dependency krb5-libs

Automatic requires should suffice. I get:

libgssapi_krb5.so.2()(64bit)
libgssapi_krb5.so.2(gssapi_krb5_2_MIT)(64bit)
libk5crypto.so.3()(64bit)
libkrb5.so.3()(64bit)
libkrb5.so.3(krb5_3_MIT)(64bit)

Isn't this enough?

Requires
--------
nfs-ganesha (rpmlib, GLIBC filtered):
    ...
    xfsprogs

Why are xfsprogs required?
Comment 16 Kaleb KEITHLEY 2013-11-05 11:21:21 EST
> Build issue aside, I find it hard to justify how including this library 
> doesn't violate https://fedoraproject.org
> /wiki/Packaging:No_Bundled_Libraries. You said that "it'll be split out when > ready", but actually is seems to be
> a totally separate project. I'd approve the package as is, otherwise.

Well, then we need an exception I guess. A) It's not really bundled, or I don't understand your definition of bundled. It's a static lib used during the build, not installed or even in the RPM, B) Upstream isn't ready to package it separately because they haven't settled on the final APIs and at the present time they are the only consumer of it. Its git repo is, at present, still a part of the nfs-ganesha project on github.  And C) if the license was incompatible I could definitely understand it, but since it's BSD then I don't see the license as an issue.

> nfs-ganesha.src:62: W: rpm-buildroot-usage %prep %cmake -DCMAKE_BUILD_TYPE=Maintainer -DBUILD_CONFIG=everything -DCMAKE_INSTALL_PREFIX=%{buildroot}/usr ./src
> Yeah, %cmake step should be moved to %build.
>
> [!]: Package must own all directories that it creates.
>     Note: Directories without known owners: /usr/share/doc/nfs-ganesha-2.0.0
> Directory ownership is missing.

Not sure what the fix is for this. I made a WAG.

> Rpmlint (installed packages)
> ----------------------------
> # rpmlint nfs-ganesha nfs-ganesha-docs
> nfs-ganesha.x86_64: E: explicit-lib-dependency krb5-libs
> 
> Automatic requires should suffice. I get:
>
> libgssapi_krb5.so.2()(64bit)
> libgssapi_krb5.so.2(gssapi_krb5_2_MIT)(64bit)
> libk5crypto.so.3()(64bit)
> libkrb5.so.3()(64bit)
> libkrb5.so.3(krb5_3_MIT)(64bit)
> 
> Isn't this enough?
> 
> Requires
> --------
> nfs-ganesha (rpmlib, GLIBC filtered):
>    ...
>    xfsprogs
>
> Why are xfsprogs required?

new files at 

Spec URL: http://kkeithle.fedorapeople.org/update-6/nfs-ganesha.spec
SRPM URL: http://kkeithle.fedorapeople.org/update-6/nfs-ganesha-2.0.0-0.rc3.fc19.src.rpm
Comment 17 Zbigniew Jędrzejewski-Szmek 2013-11-05 12:14:50 EST
(In reply to Kaleb KEITHLEY from comment #16)
> > Build issue aside, I find it hard to justify how including this library 
> > doesn't violate https://fedoraproject.org
> > /wiki/Packaging:No_Bundled_Libraries. You said that "it'll be split out when > ready", but actually is seems to be
> > a totally separate project. I'd approve the package as is, otherwise.
> 
> Well, then we need an exception I guess. A) It's not really bundled, or I
> don't understand your definition of bundled. It's a static lib used during
> the build, not installed or even in the RPM,
It is bundled, in the sense that this project A contains a snapshot of project B as part of it's sources.
So if B makes a new release independently from A, than our compiled A will be stuck with the old version.

> B) Upstream isn't ready to
> package it separately because they haven't settled on the final APIs and at
> the present time they are the only consumer of it. Its git repo is, at
> present, still a part of the nfs-ganesha project on github.
OK, this is the crucial information I was missing. This information was obscured by the Source1 link
not being a link to upstream. In this case bundling them could be OK, if it
was really one project in two tarballs. But I don't think that's really the case.
Even if nfs-ganesha is the new upstream for libntirpc, libntirpc has been packaged
for redhat and other distributions. So we have a situation where it was a seperate
project, is packaged separately, and is intended to be separate in the future, so it's
very hard to argue that it is part of the nfs server.

If can apply for an exception, but I think it's unlikely to pass. And I'm *quite* sure
that making a second package will be faster than waiting for Fesco.

> And C) if the
> license was incompatible I could definitely understand it, but since it's
> BSD then I don't see the license as an issue.
> > nfs-ganesha.src:62: W: rpm-buildroot-usage %prep %cmake -DCMAKE_BUILD_TYPE=Maintainer -DBUILD_CONFIG=everything -DCMAKE_INSTALL_PREFIX=%{buildroot}/usr ./src
> > Yeah, %cmake step should be moved to %build.
> >
> > [!]: Package must own all directories that it creates.
> >     Note: Directories without known owners: /usr/share/doc/nfs-ganesha-2.0.0
> > Directory ownership is missing.
> 
> Not sure what the fix is for this. I made a WAG.
Hm, I'm not sure what a WAG is, but it should be enough to just add
'%dir /usr/share/doc/nfs-ganesha-2.0.0/' to '%files docs'.

I see that I missed one more thing: https://fedoraproject.org/wiki/Changes/UnversionedDocdirs.
Basically, if you use %{_pkgdocdir} as the documentation directory, things should work in F >= 19.
I'm not sure though how this macro will work out with the single docs directory, you might have to adjust
to keep -docs docs in the same directory as main package docs.
Comment 18 Kaleb KEITHLEY 2013-11-05 12:38:18 EST
>> > Build issue aside, I find it hard to justify how including this library 
>> > doesn't violate https://fedoraproject.org
>> > /wiki/Packaging:No_Bundled_Libraries. You said that "it'll be split out when > ready", but actually is seems to be
>> > a totally separate project. I'd approve the package as is, otherwise.
>> 
>> Well, then we need an exception I guess. A) It's not really bundled, or I
>> don't understand your definition of bundled. It's a static lib used during
>> the build, not installed or even in the RPM,
>It is bundled, in the sense that this project A contains a snapshot of project B as part of it's sources.
>So if B makes a new release independently from A, than our compiled A will be stuck with the old version.

libntirpc != libtirpc. I'll change it to libnfsganesharpc.a Does that make it  better?

>> B) Upstream isn't ready to
>> package it separately because they haven't settled on the final APIs and at
>> the present time they are the only consumer of it. Its git repo is, at
>> present, still a part of the nfs-ganesha project on github.
>OK, this is the crucial information I was missing. This information was >obscured by the Source1 link
>not being a link to upstream. In this case bundling them could be OK, if it
>was really one project in two tarballs. But I don't think that's really the case.
>Even if nfs-ganesha is the new upstream for libntirpc, libntirpc has been packaged
>for redhat and other distributions. 

That's not true. As I alluded to above, you're probably thinking of libtirpc.

> So we have a situation where it was a separate
> project, is packaged separately, and is intended to be separate in the future, so it's
> very hard to argue that it is part of the nfs server.

At present that actually is the case.

> If can apply for an exception, but I think it's unlikely to pass. And I'm *quite* sure
> that making a second package will be faster than waiting for Fesco.

Upstream are quite clear that they do not want separate packaging at this time.

> > And C) if the
>> license was incompatible I could definitely understand it, but since it's
>> BSD then I don't see the license as an issue.
>> > nfs-ganesha.src:62: W: rpm-buildroot-usage %prep %cmake -DCMAKE_BUILD_TYPE=Maintainer -DBUILD_CONFIG=everything -DCMAKE_INSTALL_PREFIX=%{buildroot}/usr ./src
>> > Yeah, %cmake step should be moved to %build.
>> >
>> > [!]: Package must own all directories that it creates.
>> >     Note: Directories without known owners: /usr/share/doc/nfs-ganesha-2.0.0
>> > Directory ownership is missing.
>> 
>> Not sure what the fix is for this. I made a WAG.
> Hm, I'm not sure what a WAG is, but it should be enough to just add
> '%dir /usr/share/doc/nfs-ganesha-2.0.0/' to '%files docs'.
> 
> I see that I missed one more thing: https://fedoraproject.org/wiki/Changes/UnversionedDocdirs.
> Basically, if you use %{_pkgdocdir} as the documentation directory, things > should work in F >= 19.
> I'm not sure though how this macro will work out with the single docs directory, you might have to adjust
> to keep -docs docs in the same directory as main package docs.

new files at 

Spec URL: http://kkeithle.fedorapeople.org/update-7/nfs-ganesha.spec
SRPM URL: http://kkeithle.fedorapeople.org/update-7/nfs-ganesha-2.0.0-0.rc3.fc19.src.rpm
Comment 19 Kaleb KEITHLEY 2013-11-05 14:15:05 EST
> and please extend the description a bit, 

new files at 

Spec URL: http://kkeithle.fedorapeople.org/update-8/nfs-ganesha.spec
SRPM URL: http://kkeithle.fedorapeople.org/update-8/nfs-ganesha-2.0.0-0.rc3.fc19.src.rpm
Comment 20 Zbigniew Jędrzejewski-Szmek 2013-11-05 15:15:12 EST
Package looks very nice now, apart from the bundling issue.
Fedora does have libtirpc, which complicates things. I don't see a way around
applying for an exception. This case falls squarely into https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries#Modified_beyond_a_certain_extent.
Comment 21 Kaleb KEITHLEY 2013-11-05 16:10:27 EST
https://fedorahosted.org/fpc/ticket/363
Comment 22 Kaleb KEITHLEY 2013-11-11 08:25:33 EST
update to RC4 and "release" version of ntirpc from github (instead of from kkeithle.fedorapeople.org)

new files at 

Spec URL: http://kkeithle.fedorapeople.org/update-9/nfs-ganesha.spec
SRPM URL: http://kkeithle.fedorapeople.org/update-9/nfs-ganesha-2.0.0-0.rc4.fc19.src.rpm

(And yes, we're still waiting for https://fedorahosted.org/fpc/ticket/363)
Comment 24 Kaleb KEITHLEY 2013-11-21 15:02:46 EST
bundling exception approved, add virtual Provides

new files at
Spec URL: http://kkeithle.fedorapeople.org/update-11/nfs-ganesha.spec
SRPM URL: http://kkeithle.fedorapeople.org/update-11/nfs-ganesha-2.0.0-0.1.rc5.fc19.src.rpm
Comment 25 Zbigniew Jędrzejewski-Szmek 2013-11-21 16:36:04 EST
Issues:
=======
- Please seem my note about %{_smp_mflags} in comment #15. Parallel build is still broken, so you should remove %{_smp_mflags} and add a note why.

- Package does not contain duplicates in %files.
  Note: warning: File listed twice: /usr/share/doc/nfs-ganesha
  See: http://fedoraproject.org/wiki/Packaging/Guidelines#DuplicateFiles
Not very important... %dir %{_defaultdocdir}/%{name} can be removed from %files because it is already added by %doc.

OTOH, nfs-ganesha-docs should have '%dir %{_defaultdocdir}/%{name}'
added to its %files.

===== MUST items =====

C/C++:
[x]: Package does not contain kernel modules.
[x]: Package contains no static executables.
[x]: Package does not contain any libtool archives (.la)
[x]: Rpath absent or only used for internal libs.

Generic:
[x]: Package is licensed with an open-source compatible license and meets
     other legal requirements as defined in the legal section of Packaging
     Guidelines.
[x]: License field in the package spec file matches the actual license.
     Note: Checking patched sources after %prep for licenses. Licenses found:
     "GPL", "CDDL", "LGPL (v2.1 or later) (with incorrect FSF address)", "LGPL
     (v2) (with incorrect FSF address)", "Unknown or generated", "BSD (4
     clause)", "MIT/X11 (BSD like)", "CDDL (v1.0 only)", "ISC", "LGPL (v3 or
     later)", "*No copyright* LGPL (v3 or later)", "LGPL", "*No copyright*
     BSD", "BSD (3 clause)", "BSD (2 clause)", "GPL (v2 or later) (with
     incorrect FSF address)". 211 files have unknown license. Detailed output
     of licensecheck in /home/zbyszek/fedora/nfs-ganesha/review-nfs-
     ganesha/licensecheck.txt
[x]: License file installed when any subpackage combination is installed.
[x]: Package must own all directories that it creates.
     Note: Directories without known owners: /usr/share/doc/nfs-ganesha
(see note above)
[x]: %build honors applicable compiler flags or justifies otherwise.
(but see note above)

[x]: Package contains no bundled libraries without FPC exception.
[x]: Changelog in prescribed format.
[x]: Sources contain only permissible code or content.
[-]: Package contains desktop file if it is a GUI application.
[-]: Development files must be in a -devel package
[x]: Package uses nothing in %doc for runtime.
[x]: Package consistently uses macros (instead of hard-coded directory names).
[x]: Package is named according to the Package Naming Guidelines.
[x]: Package does not generate any conflict.
[x]: Package obeys FHS, except libexecdir and /usr/target.
[-]: If the package is a rename of another package, proper Obsoletes and
     Provides are present.
[?]: Requires correct, justified where necessary.
[x]: Spec file is legible and written in American English.
[x]: Package contains systemd file(s) if in need.
[x]: Useful -debuginfo package or justification otherwise.
[ ]: Package is not known to require an ExcludeArch tag.
[x]: Package complies to the Packaging Guidelines
[x]: Package successfully compiles and builds into binary rpms on at least one
     supported primary architecture.
[x]: Package installs properly.
[x]: Rpmlint is run on all rpms the build produces.
     Note: There are rpmlint messages (see attachment).
[x]: If (and only if) the source package includes the text of the license(s)
     in its own file, then that file, containing the text of the license(s)
     for the package is included in %doc.
[x]: Package requires other packages for directories it uses.
[x]: Package does not own files or directories owned by other packages.
[x]: All build dependencies are listed in BuildRequires, except for any that
     are listed in the exceptions section of Packaging Guidelines.
[x]: Package uses either %{buildroot} or $RPM_BUILD_ROOT
[x]: Package does not run rm -rf %{buildroot} (or $RPM_BUILD_ROOT) at the
     beginning of %install.
[x]: Each %files section contains %defattr if rpm < 4.4
[x]: Macros in Summary, %description expandable at SRPM build time.
[x]: Permissions on files are set properly.
[x]: Package use %makeinstall only when make install' ' DESTDIR=... doesn't
     work.
[x]: Package is named using only allowed ASCII characters.
[x]: Package do not use a name that already exist
[x]: Package is not relocatable.
[x]: Sources used to build the package match the upstream source, as provided
     in the spec URL.
[x]: Spec file name must match the spec package %{name}, in the format
     %{name}.spec.
[x]: File names are valid UTF-8.
[x]: Packages must not store files under /srv, /opt or /usr/local

Perl:
[ ]: Package contains the mandatory BuildRequires and Requires:.
     Note: Requires: perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo
     $version)) missing?

===== SHOULD items =====

Generic:
[!]: Uses parallel make %{?_smp_mflags} macro.
It does, but it shouldn't.

[-]: If the source package does not include license text(s) as a separate file
     from upstream, the packager SHOULD query upstream to include it.
[x]: Final provides and requires are sane (see attachments).
[x]: Fully versioned dependency in subpackages if applicable.
     Note: No Requires: %{name}%{?_isa} = %{version}-%{release} in nfs-
     ganesha-docs
Not necessary.
[x]: Package functions as described.
[x]: Latest version is packaged.
[x]: Package does not include license text files separate from upstream.
[x]: Patches link to upstream bugs/comments/lists or are otherwise justified.
[x]: Description and summary sections in the package spec file contains
     translations for supported Non-English languages, if available.
[ ]: %check is present and all tests pass.
[x]: Packages should try to preserve timestamps of original installed files.
[x]: Packager, Vendor, PreReq, Copyright tags should not be in spec file
[x]: Sources can be downloaded from URI in Source: tag
[x]: Reviewer should test that the package builds in mock.
[x]: Buildroot is not present
[x]: Package has no %clean section with rm -rf %{buildroot} (or
     $RPM_BUILD_ROOT)
[x]: Dist tag is present (not strictly required in GL).
[x]: No file requires outside of /etc, /bin, /sbin, /usr/bin, /usr/sbin.
[x]: SourceX tarball generation or download is documented.
[x]: SourceX is a working URL.
[x]: Package should compile and build into binary rpms on all supported
     architectures.
[x]: Spec use %global instead of %define unless justified.

===== EXTRA items =====

Generic:
[x]: Rpmlint is run on all installed packages.
     Note: There are rpmlint messages (see attachment).
[x]: Large data in /usr/share should live in a noarch subpackage if package is
     arched.
[x]: Spec file according to URL is the same as in SRPM.


Rpmlint
-------
Checking: nfs-ganesha-2.0.0-0.1.rc5.fc20.x86_64.rpm
          nfs-ganesha-docs-2.0.0-0.1.rc5.fc20.noarch.rpm
          nfs-ganesha-2.0.0-0.1.rc5.fc20.src.rpm
nfs-ganesha.x86_64: W: spelling-error %description -l en_US pNFS -> snuffs
nfs-ganesha.x86_64: W: no-manual-page-for-binary ganesha.nfsd
nfs-ganesha.x86_64: W: no-manual-page-for-binary ganestat.pl
nfs-ganesha-docs.noarch: W: spelling-error %description -l en_US pNFS -> snuffs
nfs-ganesha.src: W: spelling-error %description -l en_US pNFS -> snuffs
nfs-ganesha.src:24: W: unversioned-explicit-provides bundled(libntirpc)
nfs-ganesha.src:85: W: rpm-buildroot-usage %build %cmake -DCMAKE_BUILD_TYPE=Maintainer -DBUILD_CONFIG=everything -DCMAKE_INSTALL_PREFIX=%{buildroot}/usr ./src
3 packages and 0 specfiles checked; 0 errors, 7 warnings.




Rpmlint (installed packages)
----------------------------
# rpmlint nfs-ganesha nfs-ganesha-docs
nfs-ganesha.x86_64: W: spelling-error %description -l en_US pNFS -> snuffs
nfs-ganesha.x86_64: W: no-manual-page-for-binary ganesha.nfsd
nfs-ganesha.x86_64: W: no-manual-page-for-binary ganestat.pl
nfs-ganesha-docs.noarch: W: spelling-error %description -l en_US pNFS -> snuffs
2 packages and 0 specfiles checked; 0 errors, 4 warnings.
# echo 'rpmlint-done:'



Requires
--------
nfs-ganesha (rpmlib, GLIBC filtered):
    /bin/sh
    /usr/bin/perl
    dbus
    jemalloc
    libc.so.6()(64bit)
    libcap.so.2()(64bit)
    libcom_err.so.2()(64bit)
    libdbus-1.so.3()(64bit)
    libdl.so.2()(64bit)
    libgcc_s.so.1()(64bit)
    libgcc_s.so.1(GCC_3.0)(64bit)
    libgcc_s.so.1(GCC_3.3.1)(64bit)
    libgssapi_krb5.so.2()(64bit)
    libgssapi_krb5.so.2(gssapi_krb5_2_MIT)(64bit)
    libjemalloc.so.1()(64bit)
    libk5crypto.so.3()(64bit)
    libkrb5.so.3()(64bit)
    libkrb5.so.3(krb5_3_MIT)(64bit)
    libnfsidmap.so.0()(64bit)
    libpthread.so.0()(64bit)
    librt.so.1()(64bit)
    libwbclient.so.0()(64bit)
    libwbclient.so.0(WBCLIENT_0.9)(64bit)
    perl(English)
    perl(File::Basename)
    perl(Getopt::Std)
    rtld(GNU_HASH)
    systemd

nfs-ganesha-docs (rpmlib, GLIBC filtered):



Provides
--------
nfs-ganesha:
    bundled(libntirpc)
    libfsalgpfs.so.4()(64bit)
    libfsalnull.so.4()(64bit)
    libfsalproxy.so.4()(64bit)
    libfsalvfs.so.4()(64bit)
    nfs-ganesha
    nfs-ganesha(x86-64)

nfs-ganesha-docs:
    nfs-ganesha-docs



Source checksums
----------------
https://github.com/nfs-ganesha/nfs-ganesha/archive/pre-2.0-RC5.tar.gz :
  CHECKSUM(SHA256) this package     : 2e900fc95bb4c4a4396026a7ea60f5da0b4df6f1b40790e4e4af321280c187ed
  CHECKSUM(SHA256) upstream package : 2e900fc95bb4c4a4396026a7ea60f5da0b4df6f1b40790e4e4af321280c187ed
https://github.com/nfs-ganesha/ntirpc/archive/v1.0.0.tar.gz :
  CHECKSUM(SHA256) this package     : 63d8cbf3e8af403ba95683cbfb43f7af33bdba96efd04a2da1f018c4d27345ef
  CHECKSUM(SHA256) upstream package : 63d8cbf3e8af403ba95683cbfb43f7af33bdba96efd04a2da1f018c4d27345ef

Q: When configure is run, is see:
Cannot find GLUSTER GFAPI runtime.  Disabling GLUSTER fsal build
Cannot find CEPH runtime.  Disabling CEPH fsal build
Cannot find LUSTRE runtime.  Disabling LUSTRE fsal build
Cannot find ZFS runtime.  Disabling ZFS build

I have no idea what functionality is added when those dependencies are provided... Would it be useful to compile with glusterfs-api-devel and ceph-devel?

Cosmetic issues and one question. Package is APPROVED.
Comment 26 Kaleb KEITHLEY 2013-11-21 17:25:04 EST
address issues in comment 25 (pro forma)

new files at
Spec URL: http://kkeithle.fedorapeople.org/update-12/nfs-ganesha.spec
SRPM URL: http://kkeithle.fedorapeople.org/update-12/nfs-ganesha-2.0.0-0.1.rc5.fc19.src.rpm

Thank you.
Comment 27 Kaleb KEITHLEY 2013-11-21 17:28:26 EST
WRT gluster_gfapi, we're waiting for upstream glusterfs to update gfapi before enabling it in nfs-ganesha. 

Ceph is not a priority (for me anyway) at this time. After I hand off the package to the Ganesha devs they may choose to enable it.
Comment 28 Kaleb KEITHLEY 2013-11-21 17:33:23 EST
New Package SCM Request
=======================
Package Name: nfs-ganesha
Short Description: Ganesha NFS Server
Owners: kkeithle
Branches: f19 f20 el6
InitialCC:
Comment 29 Gwyn Ciesla 2013-11-22 08:01:43 EST
Git done (by process-git-requests).
Comment 30 Fedora Update System 2013-12-11 08:04:33 EST
nfs-ganesha-2.0.0-1.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/nfs-ganesha-2.0.0-1.fc20
Comment 31 Fedora Update System 2013-12-11 08:06:38 EST
nfs-ganesha-2.0.0-1.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/nfs-ganesha-2.0.0-1.fc19
Comment 32 Fedora Update System 2013-12-20 21:26:40 EST
nfs-ganesha-2.0.0-1.fc20 has been pushed to the Fedora 20 stable repository.
Comment 33 Fedora Update System 2013-12-20 21:26:56 EST
nfs-ganesha-2.0.0-1.fc19 has been pushed to the Fedora 19 stable repository.
Comment 34 Kaleb KEITHLEY 2014-01-02 10:36:23 EST
Package Change Request
=======================
Package Name: nfs-ganesha
Short Description: Ganesha NFS Server
Owners: kkeithle
New Branches: el6

Unretire el6 branch
Comment 35 Gwyn Ciesla 2014-01-02 10:42:28 EST
Complete.
Comment 36 Kaleb KEITHLEY 2014-01-13 07:38:28 EST
Package Change Request
=======================
Package Name: nfs-ganesha
Short Description: Ganesha NFS Server
Owners: kkeithle
New Branches: el7

create el7 branch
Comment 37 Gwyn Ciesla 2014-01-13 08:53:19 EST
Please resubmit with epel7 as the branch, there's a character in the BZ our
script can't handle, and while I'm working on that I don't want to delay
your work.
Comment 38 Kaleb KEITHLEY 2014-01-13 08:55:48 EST
Package Change Request
=======================
Package Name: nfs-ganesha
Short Description: Ganesha NFS Server
Owners: kkeithle
New Branches: epel7

create epel7 branch
Comment 39 Gwyn Ciesla 2014-01-13 09:13:09 EST
Git done (by process-git-requests).

Note You need to log in before you can comment on or make changes to this bug.