Spec URL: http://jdarcy.fedorapeople.org/cloudfs.spec SRPM URL: http://jdarcy.fedorapeople.org/cloudfs-0.5-1.fc15.src.rpm Description: From the specfile: CloudFS is a cloud-capable filesystem based on GlusterFS (http://gluster.org) 32 with additional authentication/encryption/multi-tenancy features. This package depends on the just-updated glusterfs-devel-3.1.2-2 package, but is otherwise pretty straightforward.
Here's the output from rpmlint 1.0 on the produced RPM: cloudfs.x86_64: W: spelling-error %description -l en_US filesystem -> file system, file-system, systematic cloudfs.x86_64: W: spelling-error %description -l en_US multi -> mulch, mufti cloudfs.x86_64: W: no-manual-page-for-binary cloudfs 1 packages and 0 specfiles checked; 0 errors, 3 warnings.
Package doesn't build in mock: ... In file included from /usr/include/glusterfs/gf-dirent.h:29:0, from /usr/include/glusterfs/xlator.h:70, from cloud.c:26: /usr/include/glusterfs/iatt.h:34:18: fatal error: uuid.h: No such file or directory compilation terminated. ... This is an obvious packaging bug in glusterfs-devel: It lacks a dependency on uuid-devel (rsp. the package owning /usr/include/uuid.h) Please file a BZ against the glusterfs package and have it fixed.
Are you sure about that "obvious bug" Ralf? The intended reference is actually to /usr/include/glusterfs/uuid.h which is owned by glusterfs-devel, not /usr/include/uuid.h which is owned by uuid-devel. This file was not installed prior to glusterfs-devel-3.1.2-2, which is why I mentioned it above, but with that version it does build. Is it possible that 3.1.2-2 just hasn't hit the repo yet?
(In reply to comment #3) > Are you sure about that "obvious bug" Ralf? Hmm, /usr/include/glusterfs/iatt.h contains #include "uuid.h" This means this file want to include /usr/include/uuid.h > The intended reference is actually > to /usr/include/glusterfs/uuid.h which is owned by glusterfs-devel, not > /usr/include/uuid.h which is owned by uuid-devel. Then the glusterfs headers' design is questionable, because they depend upon -I/usr/include/glusterfs and fail otherwise (cf. above). This also is a questionable and error-prone design, because passing -I/usr/include/glusterfs then will shadow /usr/include/uuid.h, i.e. render including both headers from inside of the same build directory will become difficult. I'd recommend glusterfs to change their headers to using <glusterfs/...h>. > This file was not installed > prior to glusterfs-devel-3.1.2-2, which is why I mentioned it above, but with > that version it does build. In this case, your build requires are not strict enough. BR: glusterfs >= <minimum version> > Is it possible that 3.1.2-2 just hasn't hit the > repo yet? Probably - I was building your package in mock with what was current then (And yes, Fedora's repos being out of sync and/or being broken is an often occuring and long-term persisting issue to me).
(In reply to comment #4) > /usr/include/glusterfs/iatt.h > contains > #include "uuid.h" > > This means this file want to include /usr/include/uuid.h To be more precise, it means that it wants to include uuid.h from the first place in its include path where it exists, where said include path by default has /usr/include and some gcc-version-specific directories unless -nostdinc is used. It's not uncommon at all for programs to include their own headers without full qualification, and the use of quotes instead of angle brackets is commonly taken as a hint that they're doing so. > This also is a questionable and error-prone design, because > passing -I/usr/include/glusterfs then will shadow /usr/include/uuid.h, > i.e. render including both headers from inside of the same build directory will > become difficult. I completely agree. Nonetheless, they are the upstream for that package and that's the way their headers are structured. I guess the most relevant issue is whether this questionable practice in the glusterfs package should be a blocker for cloudfs. They might understandably be reluctant to change a working (though inelegant) header structure for Fedora-packaging purposes, and rearranging the headers ourselves in our glusterfs package would seem to violate the "stay close to upstream" guideline. What I can do, within cloudfs, is eschew "-I/usr/include/glusterfs" in the makefiles and use "#include <glusterfs/..." instead. Would that be satisfactory? > I'd recommend glusterfs to change their headers to using <glusterfs/...h>. > > > This file was not installed > > prior to glusterfs-devel-3.1.2-2, which is why I mentioned it above, but with > > that version it does build. > In this case, your build requires are not strict enough. Thanks for catching that. I did update Requires, but I see that I missed updating BuildRequires as well. > Probably - I was building your package in mock with what was current then > (And yes, Fedora's repos being out of sync and/or being broken is an often > occuring and long-term persisting issue to me). FWIW, I did compile using a virtual machine that had never even seen mock before, to ensure that it was a clean environment. As long as I mock-installed last night's version of glusterfs-devel first (pulled via wget) the cloudfs SRPM seemed able to compile fine.
(In reply to comment #5) > (In reply to comment #4) > > /usr/include/glusterfs/iatt.h > > contains > > #include "uuid.h" > > > > This means this file want to include /usr/include/uuid.h > > To be more precise, it means that it wants to include uuid.h from the first > place in its include path where it exists, Correct, ... => a package using -I/usr/include/glusterfs will not get the real /usr/include/uuid.h (unless resorting to dirty tricks such as -I/usr/include/glusterfs -I/usr/include or #include_next <uuid.h>). > where said include path by default > has /usr/include and some gcc-version-specific directories unless -nostdinc is > used. It's not uncommon at all for programs to include their own headers > without full qualification, and the use of quotes instead of angle brackets is > commonly taken as a hint that they're doing so. Well, ... I can't prevent people from stopping to stick with bad habits and them being addicted by questionable designs ;) > I completely agree. Nonetheless, they are the upstream for that package and > that's the way their headers are structured. I guess the most relevant issue > is whether this questionable practice in the glusterfs package should be a > blocker for cloudfs. To be able to answer this, I'll have to recheck your rpm (Not today, it's 17:00 local time and I've got go AFK).
Jeff: Are you still working on this package? (seems like I recall some talk about merging some things into gluster, and it appears to be stagnant for some time.) I'll be happy to help you with it, and work to sponsor you if needed.
Yes, I am still working on it. The inactivity is due mainly to the fact that the team is growing and I'm spending most of my time either getting them up to speed or changing fundamental stuff in preparation for future development. It hasn't made much sense to pursue packaging stuff which is sure to change e.g. as we change the basic translator structure or add management components. If you're interested in helping with it, that's great! Let's find each other on IRC or something and I can describe where things are going in the F16 timeframe.
IMO it's sort of a spurious argument to claim that some arbitrary package built -I/usr/include/glusterfs can't get /usr/include/uuid.h without resorting to unusual measures. In all likelihood the only package that will use it is CloudFS, and CloudFS doesn't need /usr/include/uuid.h at all, and so doesn't need to resort to any measures whatsoever. Is there a concrete example of another package besides CloudFS that would use glusterfs-devel? NB. The glusterfs uuid.h is, apart from an extra #include "config.h", identical to Ted T'so's libuuid-devel uuid.h installed in /usr/include/uuid/uuid.h. (These are _not_ the same as uuid-devel /usr/include/uuid.h.) Note too that it doesn't work to just change the '#include "uuid.h"' in iatt.h to "glusterfs/uuid.h". The glusterfs headers come from different subdirs in the glusterfs source changing their iatt.h or their source tree upstream is, as jdarcy said, highly unlikely. The only way this would work would be to patch all the gluster headers while building glusterfs-devel to change all the #include "foo.h" to #include <glusterfs/foo.h>. Finally note that the extraordinary lengths suggested above (-I/usr/include or #include_next<uuid.h>) don't work anyway. At least not with F14's gcc-4.5.1 or F15's gcc-4.6.0, which appear to be overly clever in determining that they have already included uuid.h from somewhere and won't include it again. (And no, it's not a function of #ifndef _UUID_H_/#define _UUID_H_ type protection.) It might make more sense to remove the uuid.h from the glusterfs-devel package and fix cloudfs to use the libuuid-devel version. However doing this means we add a dependency to libuuid-devel.
All these hypothetical other packages that want to use glusterfs headers _and_ <uuid.h> have to do is compile with -iquote/usr/include/glusterfs (but they better have a config.h somewhere in the scope of their includes.) ISO C (ISO/IEC 9899:1999, 6.10.2) states that #include <foo.h> searches ... implementation defined places for the header. #include "foo.h" searches first in the same directory as the C file which included it, then in implementation defined places, as with <foo.h> The gcc info pages describe the implementation. For: #include <foo.h> gcc looks in first in directories added with -I, then in /usr/local/include, $libdir/gcc/$target/$version/include, /usr/$target/include, and /usr/include. For: #include "foo.h" gcc looks first in the directory containing the current file (i.e. the file with the #include), then in directories specified with -iquote, then as for <foo.h>. For truth-and-beauty we should probably use -iquote for CloudFS.
kkeithley: I don't see an updated SPEC or SRPM, can you post links to the latest version?
http://kkeithle.fedorapeople.org/cloudfs-0.7-1.fc15.src.rpm http://kkeithle.fedorapeople.org/cloudfs.spec
Spec URL: http://kkeithle.fedorapeople.org/cloudfs.spec SRPM URL: http://kkeithle.fedorapeople.org/cloudfs-0.7-1.fc15.src.rpm Description: CloudFS is a cloud-capable filesystem based on GlusterFS (http://gluster.org) with additional authentication/encryption/multi-tenancy features. N.B. Name change pending selection of a new name due to trademark issue(s) with 'CloudFS'
Kkeithley: Here's the review, there are a number of problems here, but nothing to painful to fix. In the meantime, can you do some unofficial reviews, I'll send an email with some suggestions, but you are by no means bound to those. That will give you some good experience with the packaging process that a single package won't achieve. Thanks for your patience with me on this. [ ] MUST: rpmlint must be run on every package [ke4qqq@nalleyx200 SPECS]$ rpmlint ./cloudfs.spec ../SRPMS/cloudfs-0.7-1.fc15.src.rpm ../RPMS/x86_64/cloudfs- cloudfs-0.7-1.fc15.x86_64.rpm cloudfs-debuginfo-0.7-1.fc15.x86_64.rpm [ke4qqq@nalleyx200 SPECS]$ rpmlint ./cloudfs.spec ../SRPMS/cloudfs-0.7-1.fc15.src.rpm ../RPMS/x86_64/cloudfs-* ./cloudfs.spec: W: invalid-url Source0: http://cloudfs.org/dist/0.7/cloudfs-0.7.tgz <urlopen error timed out> cloudfs.src: W: spelling-error %description -l en_US filesystem -> file system, file-system, systemically cloudfs.src: W: spelling-error %description -l en_US multi -> mulch, mufti cloudfs.x86_64: W: spelling-error %description -l en_US filesystem -> file system, file-system, systemically cloudfs.x86_64: W: spelling-error %description -l en_US multi -> mulch, mufti cloudfs.x86_64: W: hidden-file-or-dir /var/run/cloudfs/.idle_ports cloudfs.x86_64: W: hidden-file-or-dir /var/run/cloudfs/.idle_ports cloudfs.x86_64: W: hidden-file-or-dir /var/run/cloudfs/.used_ports cloudfs.x86_64: W: hidden-file-or-dir /var/run/cloudfs/.used_ports cloudfs.x86_64: W: devel-file-in-non-devel-package /usr/lib64/glusterfs/3.2.1/xlator/features/libmaprbtree.so cloudfs.x86_64: W: log-files-without-logrotate /var/log/cloudfs cloudfs.x86_64: W: no-manual-page-for-binary cfs_stop_volume.py cloudfs.x86_64: W: no-manual-page-for-binary cfs_add_directory.py cloudfs.x86_64: W: no-manual-page-for-binary cfs_add_volume.py cloudfs.x86_64: W: no-manual-page-for-binary cfs_list_vols.py cloudfs.x86_64: W: no-manual-page-for-binary cfs_add_tenant.py cloudfs.x86_64: W: no-manual-page-for-binary cfs_rm_volume.py cloudfs.x86_64: W: no-manual-page-for-binary cfs_mount.py cloudfs.x86_64: W: no-manual-page-for-binary cfs_start_volume.py cloudfs.x86_64: W: no-manual-page-for-binary cfs_delete_tenant.py cloudfs.x86_64: W: no-manual-page-for-binary cfs_add_node.py cloudfs.x86_64: W: no-manual-page-for-binary cfs_enable_tenant.py cloudfs.x86_64: W: no-manual-page-for-binary cfs_list_tenants.py cloudfs.x86_64: W: incoherent-subsys /etc/init.d/cloudfsd $prog cloudfs-debuginfo.x86_64: E: incorrect-fsf-address /usr/src/debug/cloudfs-0.7/uidmap/rb.h cloudfs-debuginfo.x86_64: E: incorrect-fsf-address /usr/src/debug/cloudfs-0.7/uidmap/rbmap.c 3 packages and 1 specfiles checked; 2 errors, 24 warnings. These obvious contain lots of non-blockers (such as lack of a man page) and some false positives. However, please try and make rpmlint shut up as much as possible. [OK ] MUST: The package must be named according to the Package Naming Guidelines [OK ] MUST: The spec file name must match the base package %{name} [...] [TBD ] MUST: The package must meet the Packaging Guidelines [OK ] MUST: The package must be licensed with a Fedora approved license and meet the Licensing Guidelines [FIX ] MUST: The License field in the package spec file must match the actual license So source contains at least GPLv2 and AGPLV3+, so the license tag is incorrect. Take a look at: http://fedoraproject.org/wiki/Packaging:LicensingGuidelines#Multiple_Licensing_Scenarios You may also want to consider whether your GPLv2 source can be used with AGPLv3+ source as they are not compatible. http://fedoraproject.org/wiki/Licensing [OK ] 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 [OK ] MUST: The spec file must be written in American English. [OK ] MUST: The spec file for the package MUST be legible. [FIX ] MUST: The sources used to build the package must match the upstream source, as provided in the spec URL. Reviewers should use md5sum for this task. If no upstream URL can be specified for this package, please see the Source URL Guidelines for how to deal with this. So either the sourceurl is broken - or it's the wrong sourceurl. [OK ] MUST: The package MUST successfully compile and build into binary rpms on at least one primary architecture [N/A ] 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. Each architecture listed in ExcludeArch MUST have a bug filed in bugzilla, describing the reason that the package does not compile/build/work on that architecture. The bug number MUST be placed in a comment, next to the corresponding ExcludeArch line [FIX ] MUST: All build dependencies must be listed in BuildRequires, except for any that are listed in the exceptions section of the Packaging Guidelines ; inclusion of those as BuildRequires is optional. Apply common sense. You don't need a BR for gcc or make see: http://fedoraproject.org/wiki/Packaging/Guidelines#Exceptions_2 [N/A ] MUST: The spec file MUST handle locales properly. This is done by using the %find_lang macro. Using %{_datadir}/locale/* is strictly forbidden [N/A ] MUST: Every binary RPM package (or subpackage) which stores shared library files (not just symlinks) in any of the dynamic linker's default paths, must call ldconfig in %post and %postun. [N/A ] MUST: If the package is designed to be relocatable, the packager must state this fact in the request for review, along with the rationalization for relocation of that specific package. Without this, use of Prefix: /usr is considered a blocker. [OK ] 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. [FIX] MUST: A package must not contain any duplicate files in the %files listing. warning: File listed twice: /var/run/cloudfs/.idle_ports warning: File listed twice: /var/run/cloudfs/.used_ports [OK ] 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. [OK ] MUST: Each package must have a %clean section, which contains rm -rf %{buildroot} (or $RPM_BUILD_ROOT). [OK ] MUST: Each package must consistently use macros. [OK ] MUST: The package must contain code, or permissable content. [N/A ] MUST: Large documentation files must go in a -doc subpackage. (The definition of large is left up to the packager's best judgement, but is not restricted to size. Large can refer to either size or quantity). [OK ] MUST: If a package includes something as %doc, it must not affect the runtime of the application. To summarize: If it is in %doc, the program must run properly if it is not present. [N/A ] MUST: Header files must be in a -devel package. [N/A ] MUST: Static libraries must be in a -static package. [N/A ] MUST: Packages containing pkgconfig(.pc) files must 'Requires: pkgconfig' (for directory ownership and usability). [N/A ] 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. [N/A ] MUST: In the vast majority of cases, devel packages must require the base package using a fully versioned dependency: Requires: %{name} = %{version}-%{release} [OK ] MUST: Packages must NOT contain any .la libtool archives, these must be removed in the spec if they are built. [N/A ] 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. If you feel that your packaged GUI application does not need a .desktop file, you must put a comment in the spec file with your explanation. [OK ] MUST: Packages must not own files or directories already owned by other packages. The rule of thumb here is that the first package to be installed should own the files or directories that other packages may rely upon. This means, for example, that no package in Fedora should ever share ownership with any of the files or directories owned by the filesystem or man package. If you feel that you have a good reason to own a file or directory that another package owns, then please present that at package review time. [N/A ] MUST: At the beginning of %install, each package MUST run rm -rf %{buildroot} (or $RPM_BUILD_ROOT). [OK ] MUST: All filenames in rpm packages must be valid UTF-8.
Quick update for my own 'records'. Kaleb has performed at least one unofficial review here: https://bugzilla.redhat.com/show_bug.cgi?id=680936
WRT license issue— I removed rb.c from the SRPM, it's not needed. I changed the license on rbmap.c to AGPL. I wrote it and put the wrong license in it. Leaving, for the moment, only rb.h. rb.h (and rb.c) came from glusterfs' contrib and rb.c is compiled into libglusterfs in the glusterfs RPM. (I suppose that technically this means that the glusterfs RPM has a license issue.) The glusterfs-devel package does not install rb.h. I can deal with this a number of different ways: 1) write the function decls I need into rbmap.c and continue to link against libglusterfs with its license issue. 2) refactor rbmap.c to use AVL tree impl. in avl.rpm/libavl. License is LGPL. 3) refactor rbmap.c to use rbtree hashmap impl. in libHX.rpm/libHX. License is LGPL. 4) refactor rbmap.c to use a BSD licensed rbtree impl. from *BSD. All the above include removing rb.h from the source N.B. Curiously rb.[ch] have comments that seem to imply that it came from avl, but it bears no resemblance to anything in avl.
New Spec and SRPM addresses all the issues in C14 above including as much of the rpmlint noise as is practical. For now I don't propose to fix the remaining rpmlint 'noise issues'. Spec URL: http://cloudfs.org/dist/0.7/cloudfs.spec SRPM URL: http://cloudfs.org/dist/0.7/cloudfs-0.7-2.fc15.src.rpm
New Spec and SRPM addresses all the issues in C14 above including as much of the rpmlint noise as is practical. For now I don't propose to fix the remaining rpmlint 'noise issues'. Spec URL: http://cloudfs.org/dist/0.7/cloudfs.spec SRPM URL: http://cloudfs.org/dist/0.7/cloudfs-0.7-3.fc15.src.rpm successful builds in mock, and koji https://koji.fedoraproject.org/koji/taskinfo?taskID=3196323 (i386) https://koji.fedoraproject.org/koji/taskinfo?taskID=3196316 (x86_64) % rpmlint SPECS/cloudfs.spec 0 packages and 1 specfiles checked; 0 errors, 0 warnings. % rpmlint SRPMS/cloudfs-0.7-3.fc15.src.rpm cloudfs.src: I: enchant-dictionary-not-found en_US 1 packages and 0 specfiles checked; 0 errors, 0 warnings. % rpmlint RPMS/x86_64/cloudfs-0.7-3.fc15.x86_64.rpm cloudfs.x86_64: I: enchant-dictionary-not-found en_US cloudfs.x86_64: W: devel-file-in-non-devel-package /usr/lib64/glusterfs/3.2.1/xlator/features/libmaprbtree.so cloudfs.x86_64: W: log-files-without-logrotate /var/log/cloudfs cloudfs.x86_64: W: no-manual-page-for-binary cfs_stop_volume.py cloudfs.x86_64: W: no-manual-page-for-binary cfs_add_directory.py cloudfs.x86_64: W: no-manual-page-for-binary cfs_add_volume.py cloudfs.x86_64: W: no-manual-page-for-binary cfs_list_vols.py cloudfs.x86_64: W: no-manual-page-for-binary cfs_add_tenant.py cloudfs.x86_64: W: no-manual-page-for-binary cfs_rm_volume.py cloudfs.x86_64: W: no-manual-page-for-binary cfs_mount.py cloudfs.x86_64: W: no-manual-page-for-binary cfs_start_volume.py cloudfs.x86_64: W: no-manual-page-for-binary cfs_delete_tenant.py cloudfs.x86_64: W: no-manual-page-for-binary cfs_add_node.py cloudfs.x86_64: W: no-manual-page-for-binary cfs_enable_tenant.py cloudfs.x86_64: W: no-manual-page-for-binary cfs_list_tenants.py cloudfs.x86_64: W: incoherent-subsys /etc/init.d/cloudfsd $prog 1 packages and 0 specfiles checked; 0 errors, 15 warnings.
Thanks for the updated files Source URL and Source now match. BR is fixed. WRT License field, I still see GPLv2 and AGPLv3+ in the source tarball. The license field needs to be corrected outside of any licensing issues. See earlier comments on that. You still have this problem: warning: File listed twice: /var/run/cloudfs/idle_ports warning: File listed twice: /var/run/cloudfs/used_ports What's the current thought on the licensing conflict?? How do we resolve that?
Sorry I missed you on IRC. | WRT License field, I still see GPLv2 and AGPLv3+ in the source tarball. Since none of the real source is GPLv2 I gather you're referring to the various autoconf and libtool scripts that configure had copied into the tree and were rolled into the tarball. They're now gone from the source tarball. | You still have this problem: | warning: File listed twice: /var/run/cloudfs/idle_ports | warning: File listed twice: /var/run/cloudfs/used_ports They weren't in the spec file twice, but I've managed to eliminate that warning. It's not clear to me why it was emitting that warning, maybe because those are subdirs and (or but) it was stripping off {idle,used}_ports and whining about /var/run/cloudfs being there twice? Anyway, it's gone. Spec URL: http://cloudfs.org/dist/0.7/cloudfs.spec SRPM URL: http://cloudfs.org/dist/0.7/cloudfs-0.7-4.fc15.src.rpm successful builds in mock, and koji https://koji.fedoraproject.org/koji/taskinfo?taskID=3210066 (i386) https://koji.fedoraproject.org/koji/taskinfo?taskID=3210050 (x86_64) rpmlint same as #18 above (even though I've added man pages)
Correction: rpmlint: % rpmlint SPECS/cloudfs.spec SRPMS/cloudfs-0.7-4.fc15.src.rpm RPMS/x86_64/cloudfs-0.7-4.fc15.x86_64.rpm cloudfs.src: I: enchant-dictionary-not-found en_US cloudfs.x86_64: W: devel-file-in-non-devel-package /usr/lib64/glusterfs/3.2.1/xlator/features/libmaprbtree.so cloudfs.x86_64: W: log-files-without-logrotate /var/log/cloudfs cloudfs.x86_64: W: incoherent-subsys /etc/init.d/cloudfsd $prog 2 packages and 1 specfiles checked; 0 errors, 3 warnings.
(In reply to comment #20) > Sorry I missed you on IRC. > > | WRT License field, I still see GPLv2 and AGPLv3+ in the source tarball. > > Since none of the real source is GPLv2 I gather you're referring to the various > autoconf and libtool scripts that configure had copied into the tree and were > rolled into the tarball. They're now gone from the source tarball. So there are really two problems here: The first is that you list AGPLv3, when the actual license is AGPLv3+ (e.g. it contains the phrase 'or at your option any later version' The second is that the source tarball you are distributing has code that's GPLv2 (I took the source tarball from the SRPM and ran grep -ir license ./* after uncompressing it, and what's being distributed is GPLv2 and AGPLv3+ in source, which is what the license field tells folks about.) Even if you don't use that source at all in the final binary. I can't see that it's been removed from the 0.7 tarball, but feel free to correct me if I have missed something. > > | You still have this problem: > | warning: File listed twice: /var/run/cloudfs/idle_ports > | warning: File listed twice: /var/run/cloudfs/used_ports > > They weren't in the spec file twice, but I've managed to eliminate that > warning. It's not clear to me why it was emitting that warning, maybe because > those are subdirs and (or but) it was stripping off {idle,used}_ports and > whining about /var/run/cloudfs being there twice? Anyway, it's gone. Great! > > Spec URL: http://cloudfs.org/dist/0.7/cloudfs.spec > SRPM URL: http://cloudfs.org/dist/0.7/cloudfs-0.7-4.fc15.src.rpm > > successful builds in mock, and koji > https://koji.fedoraproject.org/koji/taskinfo?taskID=3210066 (i386) > https://koji.fedoraproject.org/koji/taskinfo?taskID=3210050 (x86_64) > > rpmlint same as #18 above (even though I've added man pages) Wow, thats awesome, thanks for going the extra step and adding man pages! To sum up I think the remaining blockers are the license field and possibly license conflict issue, any status on that?? Is it a non-issue?
I over-wrote the files: Spec URL: http://cloudfs.org/dist/0.7/cloudfs.spec SRPM URL: http://cloudfs.org/dist/0.7/cloudfs-0.7-4.fc15.src.rpm Only diff is AGPLv3 -> AGPLv3+. rpmlint now whines that AGPLv3+ is not valid, but looking at /usr/share/rpmlint/TagsCheck.py it seems that it should be valid. No idea whether use of the rb_* functions in libglusterfs.so is directly an issue. Indirectly the glusterfs package definitely has a license issue. If the glusterfs rpm removes that code then we will be forced to use something else at that point in time, if we don't do something sooner on our own.
I talked with spot about rbtree stuff. It's licensed GPLv2+ (somehow I missed the +) which means you could apply the terms of GPLv3 to it, and that's relatively compatible with AGPLV3. Thanks for your patience in my slow progress on getting this reviewed. APPROVED.
New Package SCM Request ======================= Package Name: cloudfs Short Description: CloudFS is a cloud-capable file system based on GlusterFS (http://gluster.org) Owners: kkeithle Branches: f16 InitialCC: jdarcy
Git done (by process-git-requests). Don't request f16, devel is created by default.
Re-review after package name change from CloudFS to HekaFS rpmlint SPECS/hekafs.spec SRPMS/hekafs-0.7-7.fc15.src.rpm RPMS/x86_64/hekafs-0.7-7.fc15.x86_64.rpm hekafs.src: I: enchant-dictionary-not-found en_US hekafs.src: W: invalid-license AGPLv3+ hekafs.x86_64: W: invalid-license AGPLv3+ hekafs.x86_64: W: obsolete-not-provided cloudfs hekafs.x86_64: W: devel-file-in-non-devel-package /usr/lib64/glusterfs/3.2.1/xlator/features/libmaprbtree.so hekafs.x86_64: W: log-files-without-logrotate /var/log/hekafs hekafs.x86_64: W: incoherent-subsys /etc/init.d/hekafsd $prog 2 packages and 1 specfiles checked; 0 errors, 6 warnings. cloudfs never shipped, so nothing ever provided cloudfs and the Obsoletes is only for for possible truth-and-beauty and the few early adopters and as such I'm not sure I see the value of having a 'Provides: cloudfs' Successful koji scratch builds of x86_64 and i686.
Re-review after package name change from CloudFS to HekaFS Spec URL: http://cloudfs.org/dist/0.7/hekafs.spec SRPM URL: http://cloudfs.org/dist/0.7/hekafs-0.7-7.fc15.src.rpm rpmlint SPECS/hekafs.spec SRPMS/hekafs-0.7-7.fc15.src.rpm RPMS/x86_64/hekafs-0.7-7.fc15.x86_64.rpm hekafs.src: I: enchant-dictionary-not-found en_US hekafs.src: W: invalid-license AGPLv3+ hekafs.x86_64: W: invalid-license AGPLv3+ hekafs.x86_64: W: obsolete-not-provided cloudfs hekafs.x86_64: W: devel-file-in-non-devel-package /usr/lib64/glusterfs/3.2.1/xlator/features/libmaprbtree.so hekafs.x86_64: W: log-files-without-logrotate /var/log/hekafs hekafs.x86_64: W: incoherent-subsys /etc/init.d/hekafsd $prog 2 packages and 1 specfiles checked; 0 errors, 6 warnings. cloudfs never shipped, so nothing ever provided cloudfs and the Obsoletes is only for for possible truth-and-beauty and the few early adopters and as such I'm not sure I see the value of having a 'Provides: cloudfs' Successful koji scratch builds of x86_64 and i686.
New Package SCM Request ======================= Package Name: hekafs Short Description: HekaFS is a cloud-capable file system based on GlusterFS (http://gluster.org) Owners: kkeithle Branches: f16 InitialCC: jdarcy
I'll review this. I've taken the liberty of renaming the Summary to mention hekafs instead of cloudfs.
A couple of nits: 1) In recent fedora, the python_sitelib definition at the top is no longer necessary, as RPM does it for you. 2) There are a couple of stray pieces of whitespace at the ends of lines. Not a huge deal, but maybe nice to fix when you import. 3) It would probably be a good idea to add a variable for the glusterfs version (%global glusterfs_version 3.2.1), since you use it in multiple places. 4) The comment talking about "release_version" at the top doesn't make much sense, since it looks like release_version was removed at some point. For the Obsoletes, I agree with your Comment #28; just remove it, since it never shipped that way. Otherwise it looks fine. The nits above are all small enough that I'm comfortable with approving, and just asking that you fix when you import. APPROVED
Git done (by process-git-requests).
Package Change Request ======================= Package Name: hekafs Short Description: HekaFS is a cloud-capable file system based on GlusterFS (http://gluster.org) Owners: kkeithle Branches: el6
Misformatted, please see: https://fedoraproject.org/wiki/Package_SCM_admin_requests
Package Change Request ======================= Package Name: hekafs Short Description: HekaFS is a cloud-capable file system based on GlusterFS (http://gluster.org) Owners: kkeithle New Branches: el6