Bug 725292

Summary: Review Request: s3fs-fuse - FUSE-based file system backed by Amazon S3
Product: [Fedora] Fedora Reporter: Jorge A Gallegos <kad>
Component: Package ReviewAssignee: Nobody's working on this, feel free to take it <nobody>
Status: ASSIGNED --- QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: unspecified    
Version: rawhideCC: andrew, bkelly, cott, i, kad, nhorman, package-review
Target Milestone: ---Keywords: Reopened
Target Release: ---Flags: nhorman: needinfo? (kad)
Hardware: All   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-08-30 07:30:11 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Description Jorge A Gallegos 2011-07-24 21:19:54 EDT
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.
Comment 1 Nathan Owe 2011-07-24 22:23:51 EDT
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:
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.
Comment 2 Jorge A Gallegos 2011-07-24 23:15:06 EDT
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/

Comment 3 Nathan Owe 2011-07-25 00:11:21 EDT
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.
Comment 4 Jorge A Gallegos 2011-07-28 01:03:41 EDT
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
Comment 5 Nathan Owe 2011-07-30 23:34:03 EDT
[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. 

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/
Comment 6 Jorge A Gallegos 2011-07-31 18:43:31 EDT
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
Comment 7 Nathan Owe 2011-07-31 22:32:02 EDT
Remove the line [ "%{buildroot}" != "/" ] && rm -rf %{buildroot}
Comment 8 Jorge A Gallegos 2011-08-01 01:55:00 EDT
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.
Comment 9 Nathan Owe 2011-08-15 21:53:49 EDT
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.
Comment 10 Jorge A Gallegos 2011-08-15 22:28:31 EDT
Perfect, uploaded again:


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.
Comment 11 Nathan Owe 2011-08-24 20:54:08 EDT
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.
Comment 12 Michael Schwendt 2011-11-23 15:42:48 EST
> Conflicts:      fuse-s3fs


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:

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
Comment 13 Boyd 2011-11-30 19:03:46 EST
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!
Comment 14 Jorge A Gallegos 2012-01-19 01:06:05 EST
(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
Comment 15 Neil Horman 2012-04-26 09:22:05 EDT
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?
Comment 16 Neil Horman 2012-05-17 06:42:41 EDT
ping, any feedback?
Comment 17 Neil Horman 2012-07-12 07:30:27 EDT
ping again
Comment 18 Jorge A Gallegos 2012-07-13 01:06:35 EDT
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...

Comment 19 Neil Horman 2012-07-13 06:57:51 EDT
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?
Comment 20 Neil Horman 2012-08-30 07:30:11 EDT
no response in over a month.  closing.
Comment 21 Cott Lang 2013-11-17 22:39:53 EST
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. :)

Comment 22 Jorge A Gallegos 2013-11-18 14:02:41 EST
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.
Comment 23 Neil Horman 2013-11-18 14:50:04 EST
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.
Comment 24 Neil Horman 2013-11-18 15:58:41 EST
and the other questions I had?
Comment 25 Jorge A Gallegos 2013-11-18 16:12:50 EST
(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.
Comment 26 Cott Lang 2013-11-19 14:09:56 EST
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?
Comment 27 Christopher Meng 2013-11-19 22:08:43 EST
I really don't agree with using s3fs-fuse to name it.

This, as Cott said, will certainly confuse people.
Comment 28 Jorge A Gallegos 2013-11-26 12:21:53 EST
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.
Comment 29 Andrew Gaul 2018-05-16 19:44:45 EDT
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".
Comment 30 Jason Tibbitts 2018-05-16 20:01:40 EDT
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.)