Spec URL: http://kad.fedorapeople.org/packages/s3fs/s3fs.spec SRPM URL: http://kad.fedorapeople.org/packages/s3fs/s3fs-1.58-1.fc15.src.rpm Description: s3fs is a FUSE filesystem that allows you to mount an Amazon S3 bucket as a local filesystem. It stores files natively and transparently in S3 (i.e., you can use other programs to access the same files). Maximum file size=64GB (limited by s3fs, not Amazon). s3fs is stable and is being used in number of production environments, e.g., rsync backup to s3. Additional info: I am a new packager, and need a sponsor. Also, this package conflicts with an existing package already in fedora: fuse-s3fs (this is stated in the spec file). However the fuse-s3fs appears to be abandoned in upstream (most recent commit at https://fedorahosted.org/s3fs/browser is from 3 years ago) and, in fact, I couldn't make it work as it is right now. This package on the other hand is being actively maintained and claims to be more mature.
I am currently not a packager nor a sponsor but I will list a problem or problems: 1. Need to either use %{buildroot} or $RPM_BUILD_ROOT not both. 2. %defattr is no longer nessasary 3. License field needs to be GPLv2+ and not GPL 4. Missing Several build dependencies: a.libcurl-devel b.libxml2-devel c.openssl-devel 5. Remove Requires: Explicit Requires is not suggested. 6. passwd-s3fs is non-readable since the permissions on the file is set to 640. I would probably install it as 644 and set it as an example config file, so that the user can set it and set the permissions to how he or she wants it to be.
Thanks for the feedback! 1. Chose %{buildroot} 2. Done 3. License is explicitly set as "GNU GPL v2" in the project page, I used "GPLv2" (sans the +) in the spec file, is that correct? 4. Added missing libs according to http://code.google.com/p/s3fs/wiki/InstallationNotes 5. http://code.google.com/p/s3fs/wiki/FuseOverAmazon has an important note in the Overview section: "Important Note: Your kernel must support FUSE, kernels earlier than 2.6.18-164 may not have FUSE support". However I think there's no fedora release (that is not EOL'd) with a kernel that old, so perhaps you are correct, dropped the Requires section 6. That file is supposed to be only readable by root, such as root is the only one able to mount given the system-wide passwd file. Users can create ~/.passwd-s3fs files for user-specific mounts. Perhaps I should add a README.Fedora file to the docs? Updated .spec and .src.rpm files in http://kad.fedorapeople.org/packages/s3fs/ Cheers
Also make sure when you make changes you note it in Changelog and also bump the release number. I tested it on Koji and it builds fine for i686 and x86_64 and rpmlint only gives s3fs.x86_64: E: non-readable /etc/passwd-s3fs 0640L Other than that, that is all I can point out. Though another person may see things that I don't since I am still pretty new to RPM packaging.
Made a couple of adjustments: - Added docs - Put passwd file's ownership in post-install script. This raises a warning, not a fatal as before Spec: http://kad.fedorapeople.org/packages/s3fs/s3fs.spec SRPM: http://kad.fedorapeople.org/packages/s3fs/s3fs-1.58-2.fc15.src.rpm
[ndowens@revan Downloads]$ rpmlint /var/lib/mock/fedora-15-x86_64/result/s3fs-1.58-2.fc15.x86_64.rpm s3fs.x86_64: W: spelling-error %description -l en_US filesystem -> file system, file-system, systemically s3fs.x86_64: W: spelling-error %description -l en_US natively -> naively, negatively, alternatively s3fs.x86_64: W: spelling-error %description -l en_US rsync -> sync, r sync s3fs.x86_64: W: dangerous-command-in-%post chmod I would ignore the spelling errors I believe, except for filesystem, the others are spelled correctly. The chmod in %post wouldn't be allowed, it is a Warning. Either: 1. Leave the passwd file as 644 and let the user know to change the permissions if they want the file to be secure. 2. Install as a example file. Also I would probably install the passwd file, however you decide which of the two above would be better, in /etc/s3fs/
Fair enough. I set passwd-s3fs as a doc file. Spec: http://kad.fedorapeople.org/packages/s3fs/s3fs.spec SRPM: http://kad.fedorapeople.org/packages/s3fs/s3fs-1.58-3.fc15.src.rpm
Remove the line [ "%{buildroot}" != "/" ] && rm -rf %{buildroot}
Good catch, I got rid of the buildroot cleaning as per the guidelines: """ BuildRoot tag Fedora (as of F-10) does not require the presence of the BuildRoot tag in the spec and if one is defined it will be ignored. The provided buildroot will automatically be cleaned before commands in %install are called. """ Spec: http://kad.fedorapeople.org/packages/s3fs/s3fs.spec SRPM: http://kad.fedorapeople.org/packages/s3fs/s3fs-1.58-4.fc15.src.rpm Builds cleanly in koji.
Looks good to me, I only get s3fs.x86_64: W: spelling-error %description -l en_US natively -> naively, negatively, alternatively s3fs.x86_64: W: spelling-error %description -l en_US rsync -> sync, r sync 1 packages and 0 specfiles checked; 0 errors, 2 warnings. on the RPM file on the SRPM: s3fs.src: W: spelling-error %description -l en_US natively -> naively, negatively, alternatively s3fs.src: W: spelling-error %description -l en_US rsync -> sync, r sync s3fs.src:54: W: macro-in-%changelog %files s3fs.src: W: invalid-url Source0: http://s3fs.googlecode.com/files/s3fs-1.58.tar.gz HTTP Error 404: Not Found 1 packages and 0 specfiles checked; 0 errors, 4 warnings. So you need to find the macro in the %changelog "%files". You can mask %files by using %%files or so. On the invalid-url issue, I don't know why it is giving that because clicking the link works fine.
Perfect, uploaded again: http://kad.fedorapeople.org/packages/s3fs/s3fs-1.58-5.fc15.src.rpm http://kad.fedorapeople.org/packages/s3fs/s3fs.spec The 404 error is most likely due to googlecode not accepting whatever user-agent rpmlint is sending, I remember setting it in /etc/rpmdevtools/curlrc for spectool but it seems to not work in this case.
From what I can see, it looks pretty good, though I am not a sponsor so unfortunately, you will have to wait for a sponsor to look at this package.
> Conflicts: fuse-s3fs https://fedoraproject.org/wiki/Packaging:Conflicts https://fedoraproject.org/wiki/Packaging:Conflicts#Common_Conflicting_Files_Cases_and_Solutions Could you sort out the "Conflicts" by getting in contact with Neil Horman ( https://fedorahosted.org/s3fs/ ) and the developers of this s3fs software? That web page already comments on the potentially conflicting naming, but if the conflict cannot be resolved, it will be necessary to talk to the Fedora Packaging Committee: https://fedoraproject.org/wiki/Packaging:Conflicts#Other_Uses_of_Conflicts: There has been a new release of fuse-s3fs recently, btw, so one cannot claim it would be dead: http://koji.fedoraproject.org/koji/packageinfo?packageID=5960
I have not been able to get the the fuse-s3fs package from either Fedora 16 or rawhide to work. It seems to authenticate, but a simple command to create a bucket or to mount an existing bucket fails. Since there is little in the way of documentation other than the man page, and no logging that I can see, I am not sure what the problem is and have hesitated to file a bug. Hopefully this naming will be resolved and we can get at least one of these packages that works!
(In reply to comment #12) > > Conflicts: fuse-s3fs > > https://fedoraproject.org/wiki/Packaging:Conflicts > https://fedoraproject.org/wiki/Packaging:Conflicts#Common_Conflicting_Files_Cases_and_Solutions That anchor does not exist, but I believe this case https://fedoraproject.org/wiki/Packaging:Conflicts#Binary_Name_Conflicts is what would apply here. The only reason I am setting the Conflicts flag is because the binaries actually clash, both are installed as /usr/bin/s3fs. It suggests using either alternatives or environment modules to alleviate this. I have a question tho, would installing this new binary as /usr/bin/fuse-s3fs (or similar) be an acceptable workaround? this program hasn't been packaged in either arch, debian or ubuntu (I searched in all). I believe this would be the first "official" package of said software. If that is an acceptable workaround I can even propose that when contacting upstream, it would basically be a "heads up, guys" and see if they are happy with it. > > Could you sort out the "Conflicts" by getting in contact with Neil Horman ( > https://fedorahosted.org/s3fs/ ) and the developers of this s3fs software? I will contact Norman and the guys from google code's s3fs and see what I can find out. Historically, the google code's take on s3fs would get to keep the name since Norman's version came up later (there's mention of that project in the fedorahosted page). There was even a third one that went nowhere (http://code.google.com/p/s3fs-fuse/) > > That web page already comments on the potentially conflicting naming, but if > the conflict cannot be resolved, it will be necessary to talk to the > Fedora Packaging Committee: > https://fedoraproject.org/wiki/Packaging:Conflicts#Other_Uses_of_Conflicts: > > There has been a new release of fuse-s3fs recently, btw, so one cannot claim it > would be dead: http://koji.fedoraproject.org/koji/packageinfo?packageID=5960 That is probably because of this recent thread: http://lists.fedoraproject.org/pipermail/devel/2011-August/155935.html I would note that http://code.google.com/p/s3fs/source/list looks more active than https://fedorahosted.org/s3fs/log/src/s3fs
FWIW, I think renaming your s3fs to fuse-s3fs would be acceptable, if thats a feasible solution (I imagine it would require some doc changes to indicate how to setup a mount in /etc/fstab and the like). Beyond that I think the pacakge is ready to go. I'll approve it once thats square. Also, it appears you no longer need a sponsor, as your email is in the pacakger group. Can I unblock this from NEEDSPONSOR?
ping, any feedback?
ping again
Yes, I pinged them about this in the same google code ticket I had opened a while ago: http://code.google.com/p/s3fs/issues/detail?id=211 about my intent to package under a different package/binary name. However I am not clear on a couple of things: (Neil is already CCed in this bug, so perhaps he can respond?) 1) the fuse-s3fs package provides the /usr/bin/s3fs binary and this review package also provides the same binary. Renaming this package's binary to /usr/bin/fuse-s3fs would only complicate matters more, i.e. fuse-s3fs.rpm provides /usr/bin/s3fs and s3fs.rpm would provide /usr/bin/fuse-s3fs. 2) not entirely sure what the behavior would be when having both packages installed and trying to use the /etc/fstab entries. As far as I can see both packages register an s3fs fuse driver... Thoughts?
Well, I'm Neil, and I'm the one asking the questions in comment 15, so hoping that I respond probably isn't too helpful. FWIW, I maintain the upstream project for the current s3fs thats in fedora, and unless the google code s3fs maintainers are going to be responsive, I don't intend to concede the name. I don't see any problem with renaming the binary as I noted in the comment above, If you're waiting for the project maintainers to respond, it seems like its been almost a year since they did any work on the project (which doesn't bode well for their role as maintainers). If I were you, I would simply make the changes to your review package (and teh corresponding docs changes and such), test it, and if it works, post it for me to review. If you're interested, once we get your package in, we can come up with a name that no one uses for s3fs (perhaps amzs3fs or some such), and both modify our packages to use the alternatives system to create a single binary to access it. Although that would be tricky if our option use didn't line up. and can I clear the NEEDSPONSOR?
no response in over a month. closing.
Neil, can we please reopen this? There seem to be issues with the current s3fs package, not the least of which is that the majority of the examples and references to s3fs out there now refer to the newer FuseOverAmazon package.:) The existing package doesn't seem to be getting much attention, whereas FuseOverAmazon is actively maintained. If the conflicts are the holdup, could we consider replacing the existing package with FuseOverAmazon? Yes, I realize I'm asking the author to replace his own package. :) Thanks.
My bad, I dropped this on the floor :( I went ahead and made the changes we discussed. The developers never got back to me, even though they keep releasing new versions fairly often, they never responded to my ticket. * Renamed it to s3fs-fuse * spec file http://kad.fedorapeople.org/packages/s3fs/s3fs-fuse.spec * srpm file http://kad.fedorapeople.org/packages/s3fs/s3fs-fuse-1.73-1.fc19.src.rpm The rpmlint checks pass and mock builds it just fine. Unsure if this ticket should be renamed to reflect the name change and also unsure if I should add the background of the rename in the %description field in the spec file. Once again, sorry I dropped the ball here. I don't need a sponsor anymore, fwiw.
yes, you should rename the ticket, just so we can find it in the future if you need to. Its a bit disconcerting that we're packing something here where the devlopers refuse to acknowledge the community, but I suppose that irrelevant here Spec file looks good, as does the srpm Looks like they were releasing new versions fairly often, until august, then they abruptly stopped. have you checked to see if they're moving the project, given that code.google.com is going to discontinue downloads early next year? If so, it might be better to update the spec now with the new location.
and the other questions I had?
(Didn't see the "i am providing requested info" checkbox is checked by default even when I am updating the ticket) There is an existing ticket in https://code.google.com/p/s3fs/issues/detail?id=379 with a suggestion to move to github and the author saying "yes, I just haven't had time". I sent an email directly to him to ask about it. Will report back when/if I get information.
src rpm works flawlessly for me, as does s3fs-fuse. Thanks, Jorge! However, I think having the binary named s3fs-fuse is going to confuse people, since it will conflict with the documentation online as well as the man page itself. If removing the other package isn't palatable, can we stick with the original binary name of s3fs and make this package conflict with the original s3fs package?
I really don't agree with using s3fs-fuse to name it. This, as Cott said, will certainly confuse people.
Status update: The migration to github already started here: https://github.com/s3fs-fuse/s3fs-fuse and the current maintainer plans on moving the existing docs and issues over (he's already closed a bunch). Regarding naming, the maintainers have already decided and they picked the name 's3fs-fuse' and used it. I hear the new version is nearing, once the whole thing is moved to github so there is a general issue cleanup. I will update the spec file again to point to the new sources when there's a new release.
I contribute to s3fs; is there anything I could do to move this along? s3fs has been releasing versions for the past few years and now Ubuntu packages it as "s3fs".
Well, first thing to do is see if Jorge is still willing to continue with this submission something like seven years after it was first opened. If so, I guess he just needs to present an updated package. If not, then this should be closed and someone else can open their own review. If someone else does have a package they wish to submit now, I think it would be fair (after 4.5 years without progress) to just close this ticket out and open a new one without waiting. Since Neil had closed this out and didn't clear the assignments or the flags when he did so, I've gone ahead and cleaned things up now. (I have no personal interest in s3fs; I'm just trying to indicate what needs to happen next. If there is anything I can do to facilitate, please feel free to contact me but I'm not CCing myself on this ticket.)
I can take care of this if Jorge is not willing to continue. We could say that I continued Jorge's work somehow at https://github.com/juliogonzalez/s3fs-fuse-rpm, so I guess preparing my current SPEC for Fedora should not be that hard after some cleaning up, and adapting to the Fedora policies (and learning how to submit, since I am a SUSE guy and I am not yet familiar with how things work at Fedora :-) @A(In reply to Andrew Gaul from comment #29) > I contribute to s3fs; is there anything I could do to move this along? s3fs > has been releasing versions for the past few years and now Ubuntu packages > it as "s3fs". As far as I can see https://src.fedoraproject.org/rpms/fuse-s3fs/blob/master/f/fuse-s3fs.spec does not provide s3fs, so there should not be a conflict if we pick up this name. But to have all the alternatives covered before I contact Norman: Andrew, would be fine using the naming s3fs-fuse for the package if s3fs is still being used somehow?
Unfortunately s3fs has a naming conflict with the long-defunct Python-based s3fs: https://web.archive.org/web/20161008081920/https://fedorahosted.org/s3fs/ It did not have updates after 2009 and I cannot find other references to it. Perhaps Fedora could rename the existing s3fs package to s3fs-python, s3fs-legacy, or similar? Agree that s3fs-fuse is probably the best near-term name for the C++-based s3fs, although it would be nice to reclaim the s3fs name in the future.
I'm not sure what the issue is here. Years ago, I said I wanted to keep the name, and I'm not sure why that would change now. I admit that I've not had alot of time to maintain the package, but it works perfectly well for my needs here. What exactly is the problem with picking a new name?
No problem from my side. I was using it as s3fs-fuse for non-RHEL distributions for a few years (that's the reason I am kept updating Jorge's SPEC inside my GitHub repository, but I guess Andrew wanted the package name to be consistent with the name at Debian/Ubuntu/SUSE/openSUSE. SO let's wait a few days more to see if Jorge wants to handle this again, or otherwise I will review the policies and procedures for Fedora packages, clean my spec as needed, and submit the package.
Julio could you submit your spec file with the name s3fs-fuse?
Andrew: Sure, just give me some days to review Fedora doc about how to submit, and cleanup the SPEC (if needed).
New submission is now ready at https://bugzilla.redhat.com/show_bug.cgi?id=1631988, so I think this review can be closed (adding "needinfo" from nhorman as former assignee, in case he can close it)
*** This bug has been marked as a duplicate of bug 1631988 ***
yup, I'm good with closing it