Bug 1631988 - Review Request: s3fs-fuse - FUSE-based file system backed by Amazon S3
Summary: Review Request: s3fs-fuse - FUSE-based file system backed by Amazon S3
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: Package Review
Version: rawhide
Hardware: All
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Neal Gompa
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 725292 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-09-22 22:07 UTC by Julio Gonzalez Gil
Modified: 2018-10-09 17:19 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-10-09 17:19:20 UTC
Type: ---
Embargoed:
ngompa13: fedora-review+


Attachments (Terms of Use)

Description Julio Gonzalez Gil 2018-09-22 22:07:52 UTC
Spec URL: https://github.com/juliogonzalez/s3fs-fuse-rpm/blob/1.84-2/SPECS/s3fs-fuse.spec (also at https://copr-be.cloud.fedoraproject.org/results/juliogonzalez/s3fs-fuse/fedora-rawhide-x86_64/00801688-s3fs-fuse/s3fs-fuse.spec)

SRPM URL: https://copr-be.cloud.fedoraproject.org/results/juliogonzalez/s3fs-fuse/fedora-rawhide-x86_64/00801688-s3fs-fuse/s3fs-fuse-1.84-2.fc30.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.

Fedora Account System Username: juliogonzalez

Koji: Results are at https://koji.fedoraproject.org/koji/taskinfo?taskID=29814931

Additional info: I am a new packager, so I will need a sponsor (I will present my self at devel list in a few minutes)

s3fs-fuse is pending review at https://bugzilla.redhat.com/show_bug.cgi?id=725292 since seven years ago. Some years ago I started using the SPEC from https://github.com/cfg/s3fs (based on that request) to maintain the SPEC and a set of scripts to build s3fs-fuse at https://github.com/juliogonzalez/s3fs-fuse-rpm

We tried to get feedback from the original submitter (Jorge A. Gallegos) but did not succeed, so I am opening a new review request as discussed at https://bugzilla.redhat.com/show_bug.cgi?id=725292#c30

This package conflicts with an existing package already in fedora: fuse-s3fs (this is stated in the spec file).

This submission was requested by upstream, so they are aware and are fine with using s3fs-fuse as package name (despite at other distributions the name is s3fs). See https://github.com/s3fs-fuse/s3fs-fuse/issues/785 and https://bugzilla.redhat.com/show_bug.cgi?id=725292#c35

Comment 1 Neal Gompa 2018-09-22 22:36:56 UTC
Taking this review. In addition, I will sponsor you. :)

Comment 2 Neal Gompa 2018-09-22 23:58:58 UTC
Spec review:

> Release:        %{_release_simple}%{?dist}

You should just put the number in. That is, it should be "2%{?dist}".

Strictly speaking, it's not required to change this, and if you have particular automation centered around that, you should document it.

Cf. https://fedoraproject.org/wiki/Packaging:DistTag

> License:        GPLv2

A quick glance at the source files for the project indicate that this is actually GPLv2+. Please adjust accordingly.

> Source1:        https://github.com/juliogonzalez/s3fs-fuse-rpm/blob/%{version}-%{_release_simple}/SOURCES/passwd-s3fs

It's better to change this to a plain source reference. When the package is imported into Dist-Git, the file will exist in the Dist-Git repository anyway.

> Requires:	fuse >= 2.8.4
> Requires:       fuse-libs >= 2.8.4

Is there a reason for this? Can't we just depend on the autodeps here? Or do we also need the fuse CLI tools, too?

> Requires:	curl >= 7.0
> Requires:	libxml2 >= 2.6
> Requires:	openssl >= 0.9

Why do these need to be explicitly requested?

> BuildRequires:  curl-devel, fuse-devel, libxml2-devel, openssl-devel
> BuildRequires:	automake, gcc-c++, make

Please lay these out with one BR per line, as it makes it easier for diffing.
Since the software build code uses pkgconfig modules, please use `pkgconfig()` deps for these where possible.

> Conflicts:      fuse-s3fs

Please put a comment in the spec about why there's a conflict here.

> Obsoletes:	s3fs

Unversioned Obsoletes are not generally allowed in Fedora, and I don't believe we have an "s3fs" to replace.

Cf. https://fedoraproject.org/wiki/Packaging:Guidelines#Renaming.2FReplacing_Existing_Packages


> %description
> s3fs is a FUSE file system that allows you to mount an Amazon S3 bucket as a
> local file system. 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.

Please drop the line with only a ".", as that is not required for newline separation in spec files. 

> %global debug_package %{nil}

Please drop this, as there's no reason that debuginfo cannot be produced for this package.

> %setup -q

"%autosetup" is preferable to "%setup -q". If you're concerned about it not working for EPEL builds, that's not a problem, as %autosetup has been backported to all supported EPEL targets.

Cf. http://rpm.org/user_doc/autosetup.html

> make %{?_smp_mflags}

"%make_build" is preferred over "make %{?_smp_mflags}". Like "%autosetup", this has been backported to all supported EPEL targets.

> make install DESTDIR=%{buildroot}

Please use "%make_install".

> cp -p %{SOURCE1} passwd-s3fs

This belongs in the prep section.

> %doc AUTHORS README.md ChangeLog COPYING passwd-s3fs

"%license" must be used for COPYING in the file list. Again, this works on all targets.

Cf. https://fedoraproject.org/wiki/Packaging:LicensingGuidelines#License_Text

Comment 3 Julio Gonzalez Gil 2018-09-23 00:11:19 UTC
Thanks!

I'll take care of everything tomorrow. Most of the stuff is just inherited from the original SPEC submitted at 725292, so I think I can just change most of the stuff as required.

About:

> Release:        %{_release_simple}%{?dist}

I just changed it so I could use

> Source1:        https://github.com/juliogonzalez/s3fs-fuse-rpm/blob/%{version}-%{_release_simple}/SOURCES/passwd-s3fs

because otherwise copr would refuse to build the package when using:

> Source1: passwd-s3fs

But now I see https://docs.pagure.org/copr.copr/user_documentation.html#scm, I think I misunderstood the use of 'Subdirectory' :-)

So most probably the _release_simple variable will go away as well.

Comment 4 Julio Gonzalez Gil 2018-09-23 06:07:30 UTC
SPEC: https://copr-be.cloud.fedoraproject.org/results/juliogonzalez/s3fs-fuse/fedora-rawhide-x86_64/00801776-s3fs-fuse/s3fs-fuse.spec (committed the original git repo: https://github.com/juliogonzalez/s3fs-fuse-rpm/blob/f1d7a1fe3af208d05737c33fe33a2e11a1169f14/SPECS/s3fs-fuse.spec)
SRPM: https://copr-be.cloud.fedoraproject.org/results/juliogonzalez/s3fs-fuse/fedora-rawhide-x86_64/00801776-s3fs-fuse/s3fs-fuse-1.84-2.fc30.src.rpm
Koji: https://koji.fedoraproject.org/koji/taskinfo?taskID=29823228

> A quick glance at the source files for the project indicate that this is actually GPLv2+. Please adjust accordingly.

Right, I was reading the COPYING file itself and the license configured at the GitHub repository, but the headers at the source files are GPLv2+

> Requires:	 fuse-libs >= 2.8.4
> BuildRequires: fuse-devel >= 2.8.4

Fuse is required according to the s3fs-fuse README at least for compilation( https://github.com/s3fs-fuse/s3fs-fuse#compilation), but after a few tries I noticed it's neither required to build or to run. fuse-libs is enough as you correctly guessed. I will submit a PR to s3fs-fuse to correct the README.

I am still keeping a "Requires:	 fuse-libs >= 2.8.4" as it is needed for CentOS6/RHEL6 because otherwise the s3fs-fuse will install but will not work because both distributions have 2.8.3 (while s3fs-fuse requires at least 2.8.4). 

Obviously fuse 2.8.4 must be obtained from a third-party (I offer the specs at the same repo).

Should I add comment about it at the SPEC?

> Unversioned Obsoletes are not generally allowed in Fedora, and I don't believe we have an "s3fs" to replace.

Yes, it seems there was s3fs a long time ago (https://bugzilla.redhat.com/show_bug.cgi?id=725292#c32), but not anymore. Removed.

> "%make_build" is preferred over "make %{?_smp_mflags}". Like "%autosetup", this has been backported to all supported EPEL targets.

For CentOS7 and Amazon Linux (and I guess in general recent distributions), it works out of the box without EPEL repositories, but at CentOS6 it requires EPEL repository present, and then the package epel-rpm-macros installed.

Otherwise the macro is not recognized and the build fails.

And given that %{license} macro seems to have the same problem, instead of having ifs all over the place, I think the best solution is adding a Build Require:

> %if 0%{?rhel} == 6
> BuildRequire:  epel-rpm-macros
> %endif

Is it acceptable? Versions < 6 are out of support, and having "<= 6 breaks" Amazon Linux.

I would like to have a SPEC that serves for several distributions, as it was until now :-)

I already tried it, and it works fine for CentOS6, CentOS7 and Amazon Linux (2017.03, yes, I know should be using something more recent): 

If it is, I will update the SPEC and SRPMS tomorrow, so the review can continue.

Comment 5 Neal Gompa 2018-09-23 12:05:32 UTC
(In reply to Julio Gonzalez Gil from comment #4)
> SPEC:
> https://copr-be.cloud.fedoraproject.org/results/juliogonzalez/s3fs-fuse/
> fedora-rawhide-x86_64/00801776-s3fs-fuse/s3fs-fuse.spec (committed the
> original git repo:
> https://github.com/juliogonzalez/s3fs-fuse-rpm/blob/
> f1d7a1fe3af208d05737c33fe33a2e11a1169f14/SPECS/s3fs-fuse.spec)
> SRPM:
> https://copr-be.cloud.fedoraproject.org/results/juliogonzalez/s3fs-fuse/
> fedora-rawhide-x86_64/00801776-s3fs-fuse/s3fs-fuse-1.84-2.fc30.src.rpm
> Koji: https://koji.fedoraproject.org/koji/taskinfo?taskID=29823228
> 
> > A quick glance at the source files for the project indicate that this is actually GPLv2+. Please adjust accordingly.
> 
> Right, I was reading the COPYING file itself and the license configured at
> the GitHub repository, but the headers at the source files are GPLv2+
> 
> > Requires:	 fuse-libs >= 2.8.4
> > BuildRequires: fuse-devel >= 2.8.4
> 
> Fuse is required according to the s3fs-fuse README at least for compilation(
> https://github.com/s3fs-fuse/s3fs-fuse#compilation), but after a few tries I
> noticed it's neither required to build or to run. fuse-libs is enough as you
> correctly guessed. I will submit a PR to s3fs-fuse to correct the README.
> 
> I am still keeping a "Requires:	 fuse-libs >= 2.8.4" as it is needed for
> CentOS6/RHEL6 because otherwise the s3fs-fuse will install but will not work
> because both distributions have 2.8.3 (while s3fs-fuse requires at least
> 2.8.4). 
> 
> Obviously fuse 2.8.4 must be obtained from a third-party (I offer the specs
> at the same repo).
> 
> Should I add comment about it at the SPEC?
> 

A comment is probably a good idea. When this package is approved, just don't request an EPEL branch for EL6.

> > Unversioned Obsoletes are not generally allowed in Fedora, and I don't believe we have an "s3fs" to replace.
> 
> Yes, it seems there was s3fs a long time ago
> (https://bugzilla.redhat.com/show_bug.cgi?id=725292#c32), but not anymore.
> Removed.
> 
> > "%make_build" is preferred over "make %{?_smp_mflags}". Like "%autosetup", this has been backported to all supported EPEL targets.
> 
> For CentOS7 and Amazon Linux (and I guess in general recent distributions),
> it works out of the box without EPEL repositories, but at CentOS6 it
> requires EPEL repository present, and then the package epel-rpm-macros
> installed.
> 
> Otherwise the macro is not recognized and the build fails.
> 

If you want it to work with "bare" EL6, you can put the following at the top of your spec:

%{!?make_build: %global make_build %{__make} %{?_smp_mflags}}

(This is not _exactly_ the definition of %make_build, but it is a reasonable fallback)

> And given that %{license} macro seems to have the same problem, instead of
> having ifs all over the place, I think the best solution is adding a Build
> Require:
> 
> > %if 0%{?rhel} == 6
> > BuildRequire:  epel-rpm-macros
> > %endif
> 
> Is it acceptable? Versions < 6 are out of support, and having "<= 6 breaks"
> Amazon Linux.
> 

You can put the following compatibility statement in the %files section just above your usage of %license:

%{!?_licensedir:%global license %doc}

This works for EL6, SLE11, AMZN1, and other older distributions.

Comment 6 Neal Gompa 2018-09-23 12:16:56 UTC
(In reply to Julio Gonzalez Gil from comment #4)
> 
> > Requires:	 fuse-libs >= 2.8.4
> > BuildRequires: fuse-devel >= 2.8.4
> 
> Fuse is required according to the s3fs-fuse README at least for compilation(
> https://github.com/s3fs-fuse/s3fs-fuse#compilation), but after a few tries I
> noticed it's neither required to build or to run. fuse-libs is enough as you
> correctly guessed. I will submit a PR to s3fs-fuse to correct the README.
> 
> I am still keeping a "Requires:	 fuse-libs >= 2.8.4" as it is needed for
> CentOS6/RHEL6 because otherwise the s3fs-fuse will install but will not work
> because both distributions have 2.8.3 (while s3fs-fuse requires at least
> 2.8.4). 
> 

Did you check to see if fuse 2.8.3 would work? I looked at the commit that changed it to 2.8.4[1], and I don't see anything in it that indicates it was changed in such a way that 2.8.3 couldn't work.

[1]: https://github.com/s3fs-fuse/s3fs-fuse/commit/147dd86215f58593748095f70af8dd66d44bc1f3

Comment 7 Neal Gompa 2018-09-23 16:34:06 UTC
*** Bug 725292 has been marked as a duplicate of this bug. ***

Comment 8 Julio Gonzalez Gil 2018-09-23 17:30:36 UTC
> Did you check to see if fuse 2.8.3 would work? I looked at the commit that changed it to 2.8.4[1], and I don't see anything in it that indicates it was changed in such a way that 2.8.3 couldn't work.

Well, because of the changes at configure.ac, s3fs-fuse does not even build without a patch, and that's (I guess) the reason Jorge added the requirement, and I never tried 2.8.3

However if I patch configure.ac to allow 2.8.3, then yes, it compiles and at least some basic tests are working (mounting the bucket, listing the objects, getting an object...).

However when running the testsuite, 4 tests failed:

> FAIL: test_truncate_file
> FAIL: test_remove_nonempty_directory
> FAIL: test_special_characters
> FAIL: test_extended_attributes

The key seems to be here: https://github.com/s3fs-fuse/s3fs-fuse/issues/42

So besides that instability that is mentioned (reading the linked issue at google code I would say it was not related to fuse, but I am not an expert), some basic functionality already don't now (and in the future more functionality could stop working).

FMPOV we should keep the requirement >= 2.8.4 to allow people to use s3fs-fuse on CentOS6/RHEL6 if they want to install a newer fuse version, even if it's not official (just googling there are a lot of links about how to do it, and I even provide the SPEC to create 2.8.4).

I will add a comment with a brief explanation and a link to the GitHub issue. Is this OK?

Comment 9 Neal Gompa 2018-09-23 18:35:07 UTC
(In reply to Julio Gonzalez Gil from comment #8)
> 
> I will add a comment with a brief explanation and a link to the GitHub
> issue. Is this OK?

That is fine. Just remember you should not request an el6 branch for this package in Fedora. epel7 and currently available Fedora will be fine though.

Comment 11 Neal Gompa 2018-09-24 16:46:17 UTC
> BuildRequires:  fuse-devel >= 2.8.4

Please use "pkgconfig(fuse) >= 2.8.4"

> BuildRequires:  libxml2-devel

Please use "pkgconfig(libxml-2.0)"

Comment 12 Neal Gompa 2018-09-24 16:56:50 UTC
> Source0:        https://github.com/s3fs-fuse/s3fs-fuse/archive/v%{version}.tar.gz

Please use the following form:

https://github.com/s3fs-fuse/s3fs-fuse/archive/v%{version}/%{name}-%{version}.tar.gz


That way, the tarball is named properly (this is valid for GitHub)

Comment 14 Neal Gompa 2018-09-26 17:31:37 UTC
> BuildRequires:  pkgconfig

This doesn't hurt anything, but strictly speaking, isn't required, since every devel package that generates a pkgconfig() dep also generates a /usr/bin/pkg-config Requires.

Comment 15 Neal Gompa 2018-09-26 17:34:14 UTC
Could you please make a post with the Spec URL and SRPM URL pointing directly to raw files? fedora-review can't deal with links that point to html blobs.

Comment 17 Julio Gonzalez Gil 2018-09-26 18:12:57 UTC
(In reply to Neal Gompa from comment #14)
> > BuildRequires:  pkgconfig
> 
> This doesn't hurt anything, but strictly speaking, isn't required, since
> every devel package that generates a pkgconfig() dep also generates a
> /usr/bin/pkg-config Requires.

Yes, for an automated build system of course. But I added it for local buildings (as the SPEC is from a repository that can be used to build locally).

At CentOS I can see pkgconfig is a dependency for rpm-build, as well as at Amazon Linux 2017.03, but not for example at openSUSE Leap 42.3, and maybe not at other RPM based distribution.

So if a user is trying to build the package at any distribution without pkgconfig installed and not having pkgconfig as rpm-build dependency, pkgconfig will be mentioned on its own:

error: Failed build dependencies:
        pkgconfig is needed by s3fs-fuse-1.84-2.x86_64
        pkgconfig(fuse) >= 2.8.4 is needed by s3fs-fuse-1.84-2.x86_64
        pkgconfig(libcurl) is needed by s3fs-fuse-1.84-2.x86_64
        pkgconfig(libxml-2.0) is needed by s3fs-fuse-1.84-2.x86_64
        pkgconfig(openssl) is needed by s3fs-fuse-1.84-2.x86_64

Comment 18 Neal Gompa 2018-09-26 22:11:56 UTC
> At CentOS I can see pkgconfig is a dependency for rpm-build, as well as at Amazon Linux 2017.03, but not for example at openSUSE Leap 42.3, and maybe not at other RPM based distribution.

It's a dependency of the devel packages themselves. If you look at fuse-devel (which provides pkgconfig(fuse)), it will have `Requires: /usr/bin/pkg-config`.

This is also true on openSUSE, but the bizarre thing is that pkgconfig isn't pulled in by default in a package build environment. Thus, the pkgconfig dep generator doesn't add the dependency automatically always. It is pulled in if a package has been generated with pkgconfig() Provides, since that means it has `/usr/bin/pkg-config` Requires.

Comment 19 Neal Gompa 2018-09-26 22:12:14 UTC
Package Review
==============

Legend:
[x] = Pass, [!] = Fail, [-] = Not applicable, [?] = Not evaluated


===== 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: "FSF All Permissive", "GPL (v2 or later)", "GPL (v3 or later)",
     "Unknown or generated". 22 files have unknown license. Detailed output
     of licensecheck in /home/makerpm/1631988-s3fs-fuse/licensecheck.txt
[x]: License file installed when any subpackage combination is installed.
[x]: Package does not own files or directories owned by other packages.
[x]: %build honors applicable compiler flags or justifies otherwise.
[x]: Package contains no bundled libraries without FPC exception.
[x]: Changelog in prescribed format.
[x]: Sources contain only permissible code or content.
[x]: 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.
[x]: If the package is a rename of another package, proper Obsoletes and
     Provides are present.
[x]: 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.
[x]: Package is not known to require an ExcludeArch tag.
[x]: Large documentation must go in a -doc subpackage. Large could be size
     (~1MB) or number of files.
     Note: Documentation size is 30720 bytes in 4 files.
[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 %license.
[x]: Package requires other packages for directories it uses.
[x]: Package must own all directories that it creates.
[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]: Macros in Summary, %description expandable at SRPM build time.
[x]: Dist tag is present.
[x]: Package does not contain duplicates in %files.
[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 does not use a name that already exists.
[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

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

Generic:
[-]: 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 s3fs-
     fuse-debuginfo , s3fs-fuse-debugsource
[x]: Package functions as described.
[x]: Latest version is packaged.
[x]: Package does not include license text files separate from upstream.
[x]: Description and summary sections in the package spec file contains
     translations for supported Non-English languages, if available.
[x]: Package should compile and build into binary rpms on all supported
     architectures.
[-]: %check is present and all tests pass.
[-]: Packages should try to preserve timestamps of original installed
     files.
[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]: No file requires outside of /etc, /bin, /sbin, /usr/bin, /usr/sbin.
[x]: Packager, Vendor, PreReq, Copyright tags should not be in spec file
[x]: Sources can be downloaded from URI in Source: tag
[x]: SourceX is a working URL.
[x]: Spec use %global instead of %define unless justified.

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

Generic:
[x]: Rpmlint is run on debuginfo package(s).
     Note: No rpmlint messages.
[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]: Package should not use obsolete m4 macros
[x]: Spec file according to URL is the same as in SRPM.


Rpmlint
-------
Checking: s3fs-fuse-1.84-2.fc30.x86_64.rpm
          s3fs-fuse-debuginfo-1.84-2.fc30.x86_64.rpm
          s3fs-fuse-debugsource-1.84-2.fc30.x86_64.rpm
          s3fs-fuse-1.84-2.fc30.src.rpm
s3fs-fuse.x86_64: W: spelling-error %description -l en_US natively -> naively, negatively, tentatively
s3fs-fuse.x86_64: W: spelling-error %description -l en_US rsync -> sync, r sync
s3fs-fuse.src: W: spelling-error %description -l en_US natively -> naively, negatively, tentatively
s3fs-fuse.src: W: spelling-error %description -l en_US rsync -> sync, r sync
s3fs-fuse.src:88: W: mixed-use-of-spaces-and-tabs (spaces: line 4, tab: line 88)
4 packages and 0 specfiles checked; 0 errors, 5 warnings.




Rpmlint (debuginfo)
-------------------
Checking: s3fs-fuse-debuginfo-1.84-2.fc30.x86_64.rpm
1 packages and 0 specfiles checked; 0 errors, 0 warnings.





Rpmlint (installed packages)
----------------------------
sh: /usr/bin/python: No such file or directory
s3fs-fuse.x86_64: W: spelling-error %description -l en_US natively -> naively, negatively, tentatively
s3fs-fuse.x86_64: W: spelling-error %description -l en_US rsync -> sync, r sync
3 packages and 0 specfiles checked; 0 errors, 2 warnings.



Requires
--------
s3fs-fuse (rpmlib, GLIBC filtered):
    fuse-libs
    libc.so.6()(64bit)
    libcrypto.so.1.1()(64bit)
    libcrypto.so.1.1(OPENSSL_1_1_0)(64bit)
    libcurl.so.4()(64bit)
    libfuse.so.2()(64bit)
    libfuse.so.2(FUSE_2.2)(64bit)
    libfuse.so.2(FUSE_2.5)(64bit)
    libfuse.so.2(FUSE_2.6)(64bit)
    libfuse.so.2(FUSE_2.8)(64bit)
    libgcc_s.so.1()(64bit)
    libgcc_s.so.1(GCC_3.0)(64bit)
    libpthread.so.0()(64bit)
    libstdc++.so.6()(64bit)
    libstdc++.so.6(CXXABI_1.3)(64bit)
    libstdc++.so.6(CXXABI_1.3.8)(64bit)
    libstdc++.so.6(CXXABI_1.3.9)(64bit)
    libxml2.so.2()(64bit)
    libxml2.so.2(LIBXML2_2.4.30)(64bit)
    libxml2.so.2(LIBXML2_2.6.0)(64bit)
    rtld(GNU_HASH)

s3fs-fuse-debuginfo (rpmlib, GLIBC filtered):

s3fs-fuse-debugsource (rpmlib, GLIBC filtered):



Provides
--------
s3fs-fuse:
    s3fs-fuse
    s3fs-fuse(x86-64)

s3fs-fuse-debuginfo:
    debuginfo(build-id)
    s3fs-fuse-debuginfo
    s3fs-fuse-debuginfo(x86-64)

s3fs-fuse-debugsource:
    s3fs-fuse-debugsource
    s3fs-fuse-debugsource(x86-64)



Source checksums
----------------
https://github.com/s3fs-fuse/s3fs-fuse/archive/v1.84/s3fs-fuse-1.84.tar.gz :
  CHECKSUM(SHA256) this package     : 39b844fe94b44af48ab8d57645a0a3fd9a64486bb54413ba7f928111cb4093a3
  CHECKSUM(SHA256) upstream package : 39b844fe94b44af48ab8d57645a0a3fd9a64486bb54413ba7f928111cb4093a3


Generated by fedora-review 0.6.1 (f03e4e7) last change: 2016-05-02
Command line :/usr/bin/fedora-review -b 1631988 -m fedora-rawhide-x86_64
Buildroot used: fedora-rawhide-x86_64
Active plugins: Generic, Shell-api, C/C++
Disabled plugins: Java, Python, fonts, SugarActivity, Ocaml, Perl, Haskell, R, PHP
Disabled flags: EXARCH, DISTTAG, EPEL5, BATCH, EPEL6

Comment 20 Neal Gompa 2018-09-26 22:12:41 UTC
Package looks good to me at this point!

PACKAGE APPROVED.

Comment 21 Neal Gompa 2018-09-26 22:13:57 UTC
Congratulations, you are now sponsored as a Fedora packager. You may proceed to request your package git repo. :)

Comment 22 Julio Gonzalez Gil 2018-09-29 18:32:06 UTC
Repository requested: https://pagure.io/releng/fedora-scm-requests/issue/8355

Comment 23 Neal Gompa 2018-09-29 21:34:16 UTC
You may also want to request branches too, since you've only requested the "master" branch with that request (aka, only rawhide).

Comment 24 Julio Gonzalez Gil 2018-09-29 22:13:15 UTC
Done, for current Fedora and EPEL7, as discussed before.

Comment 25 Jason Tibbitts 2018-10-01 23:17:53 UTC
(fedscm-admin):  The Pagure repository was created at https://src.fedoraproject.org/rpms/s3fs-fuse

Comment 26 Julio Gonzalez Gil 2018-10-03 21:21:05 UTC
Packages ready at the repository, and built at Koji succesfully.

Last remaining thing is submission to Bodhi and approval from testing to release, which I will complete after I can get it to work (right now fedora-packager-setup returns an HTTP 500, I guess because of the planned downtime I see at https://status.fedoraproject.org/)

Comment 27 Fedora Update System 2018-10-03 22:19:01 UTC
s3fs-fuse-1.84-2.fc29 has been submitted as an update to Fedora 29. https://bodhi.fedoraproject.org/updates/FEDORA-2018-e6a34c4917

Comment 28 Fedora Update System 2018-10-03 22:19:49 UTC
s3fs-fuse-1.84-2.fc28 has been submitted as an update to Fedora 28. https://bodhi.fedoraproject.org/updates/FEDORA-2018-e986513c51

Comment 29 Fedora Update System 2018-10-03 22:20:28 UTC
s3fs-fuse-1.84-2.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2018-c6b8690956

Comment 30 Fedora Update System 2018-10-03 22:21:16 UTC
s3fs-fuse-1.84-2.el7 has been submitted as an update to Fedora EPEL 7. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-9ad5351ee5

Comment 31 Fedora Update System 2018-10-05 15:58:46 UTC
s3fs-fuse-1.84-2.fc27 has been pushed to the Fedora 27 stable repository. If problems still persist, please make note of it in this bug report.

Comment 32 Fedora Update System 2018-10-05 17:10:52 UTC
s3fs-fuse-1.84-2.fc28 has been pushed to the Fedora 28 stable repository. If problems still persist, please make note of it in this bug report.

Comment 33 Fedora Update System 2018-10-05 17:19:47 UTC
s3fs-fuse-1.84-2.el7 has been pushed to the Fedora EPEL 7 stable repository. If problems still persist, please make note of it in this bug report.

Comment 34 Fedora Update System 2018-10-07 21:00:31 UTC
s3fs-fuse-1.84-2.fc29 has been pushed to the Fedora 29 stable repository. If problems still persist, please make note of it in this bug report.

Comment 35 Julio Gonzalez Gil 2018-10-09 17:19:20 UTC
So it seems fuse was needed for the users to mount the bucket via systemd, mount (with/without /etc/fstab entry).

https://github.com/juliogonzalez/s3fs-fuse-rpm/issues/9

I will open a new bug for this, and will fix it separately.

Closing this one.


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