https://bugzilla.redhat.com/show_bug.cgi?id=1485458 --- Comment #12 from Martin Brandenburg <martin@xxxxxxxxxxxxxxxxxxxxx> --- (In reply to Jonathan Dieter from comment #10) > > (In reply to Jonathan Dieter from comment #8) > > > (In reply to Martin Brandenburg from comment #0) > > > > I am not sure how to handle this. I assume that the BSD/MIT style > > > > licenses will not pose a problem, but I don't know where to document it. > > > > > > Normally like this: GPLv3 and BSD and ... > > Ok, a quick note on the licensing. The NTP license is actually a variant of > MIT, and, at least according to > https://lists.fedoraproject.org/archives/list/legal@xxxxxxxxxxxxxxxxxxxxxxx/ > thread/JM7YJILE4GIFRD3J636EAT2PBOEND7WP/, should be listed as such. > > And, according https://fedoraproject.org/wiki/Licensing:Main#Good_Licenses, > you can list LGPLv2.1 as LGPLv2. And LGPLv2 and LGPLv2+? They're still listed separately. > > Most of the client applications look for /etc/pvfs2tab. Should I patch > > it to look for /etc/orangefs/pvfs2tab? The server configuration is > > given on the command line, but this is hardcoded (or settable by > > environment variable). > > Thanks for this. If /etc/pvfs2tab is a well-known location, I sure wouldn't > change it unless upstream is planning to make the change universal. Then that will remain as it is now. > > > > The utility programs distributed and others which can be linked against > > > > our libraries will run against the server. It is also possible to use a > > > > userspace client program along with the kernel module (distributed by > > > > kernel.org and already present in Fedora). This would require running > > > > the client program and mounting the filesystem through the kernel. I > > > > suppose systemd scripts are needed, but I'm not sure what to distribute. > > > > > > If the client needs to be run with arguments to mount the filesystem, I'd > > > probably not bother with a systemd service, but if it reads the > > > configuration from /etc, a service might make sense. > > > > It doesn't need any arguments. The mount request comes in from the > > kernel with all the information it needs. I've added a systemd unit for > > it. > > > > I'm not sure how to arrange things so that systemd doesn't try to mount > > the filesystem before the daemon is started. > > You could try putting After= in the mount unit file, which would order it > after the server if and only if the server is also installed on the same > machine. If there is no server on the local machine, then the client will > start in parallel with everything else. No you've misunderstood me, though you bring up another good point. If a pvfs2 filesystem appears in fstab, it cannot be mounted before the pvfs2-client (i.e. orangefs-client.service) is running. The mount will hang until either a timeout expires or the client starts running. Given systemd's parallel nature this might not actually cause a problem, but certainly isn't very clean. And you bring up something I hadn't thought about: if the server and client are to run on the same machine, it will be necessary to start the server first. > > > The one other thing I noticed is that you're packaging .a files in your > > > -devel package. I'd remove them as part of your build process. > > > > I figure somebody may want to link statically, but I have no preference > > either way, and this is easy to change. I've left it in for now, but > > will remove if there's a Fedora policy or anyone has a strong opinion. > > Fedora has very specific guidelines if you're packaging static libraries > (see: > https://fedoraproject.org/wiki/Packaging: > Guidelines#Packaging_Static_Libraries, specifically the part about splitting > static libraries into a separate subpackage), so I'd recommend just > dropping the static libraries, unless you have a deep and overwhelming > desire to deal with the extra red tape. ;) Then I will take the static libraries out. > One major thing you need to do is remove the manual Provides in the orangefs > client package. The reason the libraries aren't automatically being > Provided: is that they're not executable, so you need to make sure they are > installed with 0755 permissions. Once you do that, rpm will automatically > add the Provides: for you. Okay fixed with Dave Love's orangefs-soname.patch. > Hopefully this will sort out some of the rpmlint errors I'm seeing. I am a > bit concerned by the shared-lib-calls-exit warning I'm getting. Do you > intend for your library to actually exit the calling program as opposed to > returning an error? Unfortunately, probably yes. I've done some quick grepping, and many of them look like places where an assert wouldn't be unreasonable. (In reply to Dave Love from comment #11) > Somewhat late, these are comments partly as a user and partly as a > packager (which may duplicate the reviewer's somewhat). I've put an > updated version of what I ran on an HPC system previously at > <http://loveshack.fedorapeople.org/reviews/orangefs>. It's probably > not packaging standard, but it has things like support for dkms and > multiple transports -- I'd expect openib support for HPC -- and > addresses some of these comments. > > HTH. > > * Use correct svn Version and Source forms > > * Use ./prepare in %prep on straight exported source Should we? The release tarballs will not require it. > * Use unbundled lmdb (see patch) I fixed this a while ago, though we are still shipping a copy of LMDB for those who want it. > * Use interface-related soname (see patch); the interface was > sufficiently stable over some previous versions I checked with > abipkgdiff to keep a major version. Thanks for this. I assume you are good with me merging your orangefs-soname.patch upstream? > * It needs an IB version (unless you can configure for both IB and TCP > now) It complains loudly that performance will suffer, but it's wrong or at least misleading. Performance will only suffer if you actually attempt to use both at the same time. Just having the code built and available for run-time configuration doesn't harm anything. > * Probably should have combinatorial builds over network and security > types too Do you use any of the security modes? We built all that stuff, but haven't really heard from anyone who uses it. I agree it would be nice to have, and I don't want to rule it out this early. There's several network modes in src/io/bmi, but all we've focused on recently is bmi_tcp and bmi_ib. I'm not sure if the others build. I don't want to make something that is missing features people want to use. > * Remove the Provides: (but combinatorial builds should maybe provide > "orangefs") > > * Make -libs-<transport> packages for use with mpi-io etc. I have to admit I'm not entirely sure what you're talking about with either of these. > * Fix strange aarch64-specific build failure, but conditionalize it > for now -- ask about it on devel list? > > src/client/usrint/pvfs-path.c: In function 'PVFS_expand_path': > src/client/usrint/pvfs-path.c:266:25: error: 'SYS_readlink' undeclared > (first use in this function); did you mean 'SYS_readlinkat'? > n = syscall(SYS_readlink, > ^~~~~~~~~~~~ > SYS_readlinkat They dropped obsolete syscalls in the kernel for the new architecture. That code is somewhat fragile (can't you tell from the fact it calls syscall instead of readlink?), so I'm not going to attempt to fix this, but I will forward the bug upstream. > * Configure --disable-static Done. > * -devel should have Requires, but not the Provides > > * Install service file correctly, but provide init file for el6 > > * Don't try to configure the server/client; just provide -example files Honestly that probably makes more sense than what I'm doing. I'm going to go ahead and do it. > * Add %licence with correct contents > > * Expand description? Not a bad idea. May I take (and probably tweak) your description? > * Cosmetic: Order of stanzas is confusing (e.g. %changelog is > conventionally at end) I think it is now? Please suggest anything else I should reorder. > * Build Java, and possibly web, stuff. > Any reason not to --enable-fuse ? There is much debate here about this. > * Include pacemaker stuff Again I have to admit I don't know what this is. > * pvfs2-{start,stop}-all should be %config as they need editing? They're also in /usr/sbin. Putting them somewhere as an example or extending them to take command line arguments may make more sense. > * Ship examples and built doc > > * Don't mark %mandir as %doc Done. > * Fix the build upstream to be smp-safe: currently tends to fail in > statecomp/scanner directory After who knows how long, I finally fixed that one. There's some argument here that we should not package Karma, because it may not work. I will test it. I've also been advised to add --disable-threaded, which is non-default but supposedly the thread does not help performance. I'm less excited about enabling a bunch of non-default (and thus poorly tested) options, though. I have created a repository here so that others may see my work with its history: https://github.com/omnibond/orangefs-fedora Koji: https://koji.fedoraproject.org/koji/taskinfo?taskID=22006250 Spec: http://dev.orangefs.org/2017/marbran/0921/orangefs.spec SRPM: http://dev.orangefs.org/2017/marbran/0921/orangefs-2.9.6-0.2.20170904svn.fc26.src.rpm -- You are receiving this mail because: You are on the CC list for the bug. You are always notified about changes to this product and component _______________________________________________ package-review mailing list -- package-review@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to package-review-leave@xxxxxxxxxxxxxxxxxxxxxxx
