Bug 1824156

Summary: Review Request: exfatprogs - Userspace utilities for exFAT filesystems
Product: [Fedora] Fedora Reporter: Simone Caronni <negativo17>
Component: Package ReviewAssignee: Neal Gompa <ngompa13>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: medium    
Version: rawhideCC: bcotton, esandeen, gary.buhrmaster, gedakc, hannes, mattia.verga, mike.fleetwood, ngompa13, package-review, pbrobinson, spotrh, thib, vascom2, vtrefny, yanqiyu01
Target Milestone: ---Flags: ngompa13: fedora-review+
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-12-28 01:08:38 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Simone Caronni 2020-04-15 13:04:23 UTC
Spec URL: https://slaanesh.fedorapeople.org/exfat-utils.spec
SRPM URL: https://slaanesh.fedorapeople.org/exfat-utils-1.0.1-1.fc31.src.rpm
Description: Utilities for formatting and repairing exFAT filesystems.
Fedora Account System Username: slaanesh

Comment 1 Simone Caronni 2020-04-15 13:07:24 UTC
Note:

These are the Samsung open source userspace components that matche what has been included already in mainline kernel 5.7 and that is already enabled in Fedora:

https://src.fedoraproject.org/rpms/kernel/blob/master/f/kernel-x86_64-fedora.config#_1628

Adding FE-Legal in CC so they can check, as the previous exFAT implementations were not possible.

Comment 2 Simone Caronni 2020-04-15 13:09:51 UTC
I've set the Epoch to 1 and obsoleted the fuse implementation, so it correctly obsoletes both exfat-utils and fuse-exfat that are shipped in RPMFusion.

If and when the review will be approved, the package will be added to the updates when kernel 5.7 (or patch) will be backported in the appropriate release, thus providing users an upgrade path from the old packages to the correct implementation.

Comment 3 Neal Gompa 2020-04-15 19:29:43 UTC
Taking this review.

Comment 4 Neal Gompa 2020-04-15 19:46:56 UTC
(In reply to Simone Caronni from comment #2)
> I've set the Epoch to 1 and obsoleted the fuse implementation, so it
> correctly obsoletes both exfat-utils and fuse-exfat that are shipped in
> RPMFusion.

I'm very confused why an Epoch is needed. Also, why obsolete+provide the FUSE implementation? This does not provide the ability to use exfat in FUSE.

Comment 5 Eric Sandeen 2020-04-15 20:29:35 UTC
Note that there has been a request upstream to rename this to something like exfatprogs to avoid the name clash, not sure if that will happen.

Comment 6 Tom "spot" Callaway 2020-04-16 18:31:53 UTC
Well, because legal stuff is fun, we need to know what the package name for this utility is going to be, before we can get it cleared. If you can encourage upstream to figure that out ASAP, it would be helpful.

Comment 7 Eric Sandeen 2020-04-16 19:03:37 UTC
Upstream thread is at https://lore.kernel.org/lkml/001201d60e12%248454abb0%248cfe0310%24@samsung.com/t/


The question, and maintainer response summarized:

> For the sake of sanity of the distributions which already carry exfat-
> utils based on fuse (https://protect2.fireeye.com/url?k=20c6da2a-7d5874b0-
> 20c75165-0cc47a336fae-
> 6943064efcd15854&q=1&u=https%3A%2F%2Fgithub.com%2Frelan%2Fexfat), would it
> be possible to either change the name of the project to say exfat-progs or
> increase the version number to beyond 1.4?
> 
> exfat-progs is more in line with xfsprogs, btrfsprogs or e2fsprogs :)
Oh, I see. I agree to rename to exfat-progs. I will work to release version
1.0.2 with that name.

So we might see an 'exfat-progs' in upstream git soon-ish.

Comment 8 Tom "spot" Callaway 2020-04-17 18:47:49 UTC
Looks like they went with exfatprogs. Let's go ahead and rename the Fedora package accordingly, but we still need to keep this one on a legal hold for the time being.

Comment 9 Simone Caronni 2020-04-23 07:15:44 UTC
(In reply to Neal Gompa from comment #4)
> (In reply to Simone Caronni from comment #2)
> > I've set the Epoch to 1 and obsoleted the fuse implementation, so it
> > correctly obsoletes both exfat-utils and fuse-exfat that are shipped in
> > RPMFusion.
> 
> I'm very confused why an Epoch is needed. Also, why obsolete+provide the
> FUSE implementation? This does not provide the ability to use exfat in FUSE.

Hi, thanks for the review.

The exfat-utils in RPMFusion had the same name but with version 1.3.1, so an Epoch was for sure needed.

The Fuse implementation was a "workaround" for a missing kernel implementation, so in my idea this would replace the fuse based installation on the user system. But now that the package has been renamed we can drop this entirely as they can coexist. Not sure of the benefit though, I think it will create more confusion than anything.

Spec URL: https://slaanesh.fedorapeople.org/exfatprogs.spec
SRPM URL: https://slaanesh.fedorapeople.org/exfatprogs-1.0.1-2.fc32.src.rpm

- Rename to exfatprogs.
- Removed provides/obsoletes on Fuse implementation.

Comment 10 Neal Gompa 2020-04-23 11:21:19 UTC
Packaging spec review:

=== Preamble ===

> URL:            https://github.com/exfat-utils/exfat-utils

The URL should be "https://github.com/exfatprogs/exfatprogs"

> Source0:        %{url}/archive/%{version}.tar.gz#/%{name}-%{version}.tar.gz

This should be "%{url}/archive/%{version}/%{name}-%{version}.tar.gz"

There's also missing BRs for gcc and make, as those are not guaranteed in the build root anymore.

=== libextfat ===

> Requires:       libexfat%{?_isa} = %{version}-%{release}

This self-requires is completely pointless, please remove it

=== libextfat-devel ===

There's an undefined macro "%{libs}" in the summary. This probably should be changed to "libextfat".

=== Scriptlets ===

"%ldconfig_scriptlets libextfat" is completely unneeded. It does nothing on Fedora, and this package will not be useful on non-Fedora without the kernel module being backported first. And if it's getting backported to anything, it'd be EL8, which *also* does not need this.

Comment 11 Neal Gompa 2020-04-23 11:21:53 UTC
Blech, I repeatedly said "libextfat" when I meant "libexfat" :)

Comment 12 Eric Sandeen 2020-04-23 13:40:29 UTC
btw exfat-utils has now been renamed exfatprogs as of v1.0.2:

===
This is the second release of exfatprogs since the initial version(1.0.1).
We have received various feedbacks and patches since the previous release
and applied them in this release. Thanks for feedback and patches!

According to Goldwyn's comments, We renamed the project name from
exfat-utils to exfatprogs. However, There is an opinion that just renaming
the name is not enough. Because the binary names(mkfs.exfat, fsck.exfat)
still are same with ones in current exfat-utils RPM package.
===

I'll probably chime in on that thread, I think keeping the binary names is
the only way to go, but a conflicts: tag in packaging might be wise?

-Eric

Comment 13 Simone Caronni 2020-04-27 09:32:33 UTC
(In reply to Neal Gompa from comment #10)
> > URL:            https://github.com/exfat-utils/exfat-utils
> 
> The URL should be "https://github.com/exfatprogs/exfatprogs"

Good point :D

> > Source0:        %{url}/archive/%{version}.tar.gz#/%{name}-%{version}.tar.gz
> 
> This should be "%{url}/archive/%{version}/%{name}-%{version}.tar.gz"

Fixed, I was stuck with the old format.

> There's also missing BRs for gcc and make, as those are not guaranteed in
> the build root anymore.

Added, not cleaning the mock buildroot was not a good idea.

> > Requires:       libexfat%{?_isa} = %{version}-%{release}
> 
> This self-requires is completely pointless, please remove it
> 
> There's an undefined macro "%{libs}" in the summary. This probably should be
> changed to "libextfat".

Fixed, leftovers from some other changes.

> === Scriptlets ===
> 
> "%ldconfig_scriptlets libextfat" is completely unneeded. It does nothing on
> Fedora, and this package will not be useful on non-Fedora without the kernel
> module being backported first. And if it's getting backported to anything,
> it'd be EL8, which *also* does not need this.

I actually was planning to build it also for RHEL 7, leaving the option for the user to add DKMS/kmod modules for it. I will add it eventually if needed.

Spec URL: https://slaanesh.fedorapeople.org/exfatprogs.spec
SRPM URL: https://slaanesh.fedorapeople.org/exfatprogs-1.0.2-1.fc32.src.rpm

- Update to 1.0.2.
- Added gcc/make build requirements.
- Fixed URL and source URL.
- Removed useless require on libexfat and macro in libexfat-devel summary.
- Removed ldconfig scriptlet.

Comment 14 Simone Caronni 2020-04-27 09:33:33 UTC
(In reply to Eric Sandeen from comment #12)
> btw exfat-utils has now been renamed exfatprogs as of v1.0.2:
> 
> ===
> This is the second release of exfatprogs since the initial version(1.0.1).
> We have received various feedbacks and patches since the previous release
> and applied them in this release. Thanks for feedback and patches!
> 
> According to Goldwyn's comments, We renamed the project name from
> exfat-utils to exfatprogs. However, There is an opinion that just renaming
> the name is not enough. Because the binary names(mkfs.exfat, fsck.exfat)
> still are same with ones in current exfat-utils RPM package.
> ===
> 
> I'll probably chime in on that thread, I think keeping the binary names is
> the only way to go, but a conflicts: tag in packaging might be wise?
> 
> -Eric

As you wish, but then in the end the conflict in the package is the same as the conflict in the files. I would still favour obsoleting/provides exfat-utils.

Comment 15 Eric Sandeen 2020-04-27 13:14:48 UTC
I have no strong preferences or opinions re: conflicts/provides/obsoletes/whatever, that's not my strong point at all.  So please don't take anything I said there as an imperative.

Comment 16 Simone Caronni 2020-04-29 17:55:02 UTC
(In reply to Eric Sandeen from comment #15)
> I have no strong preferences or opinions re:
> conflicts/provides/obsoletes/whatever, that's not my strong point at all. 
> So please don't take anything I said there as an imperative.

Absolutely, no worries. Any input is valuable! Thanks.

Comment 17 Simone Caronni 2020-05-12 08:31:19 UTC
Any update on the review/legal check?

Thanks.

Comment 18 Eric Sandeen 2020-05-12 15:43:26 UTC
Hi spot pls see comment #17, thanks!

Comment 19 Tom "spot" Callaway 2020-05-12 16:16:04 UTC
Don't block the review on the legal clearance, go ahead and get the package reviewed, it just cannot go into Fedora until I lift the FE-Legal flag. Which I cannot do yet, but I anticipate being able to do in the near future.

(apologies for the vague language, yay legal issues!)

Comment 20 Simone Caronni 2020-05-12 17:07:19 UTC
Perfect, thank you! @Nael we can proceed in the meanwhile.

Thanks.

Comment 21 Simone Caronni 2020-05-19 07:55:08 UTC
Hi Nael, any chance we can proceed? Thanks!

Comment 22 Neal Gompa 2020-05-19 10:46:51 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]: If your application is a C or C++ application you must list a
     BuildRequires against gcc, gcc-c++ or clang.
[x]: Header files in -devel subpackage, if present.
[x]: ldconfig not called in %post and %postun for Fedora 28 and later.
[x]: Package does not contain any libtool archives (.la)
[x]: Rpath absent or only used for internal libs.
[x]: Development (unversioned) .so files in -devel subpackage, if present.

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: "Unknown or generated", "GNU Lesser General Public License". 27
     files have unknown license. Detailed output of licensecheck in
     /home/ngompa/1824156-exfatprogs/licensecheck.txt
[x]: License file installed when any subpackage combination is installed.
[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.
[-]: Package contains desktop file if it is a GUI application.
[x]: 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.
[-]: 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.
[-]: 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.
[-]: Large documentation must go in a -doc subpackage. Large could be size
     (~1MB) or number of files.
     Note: Documentation size is 10240 bytes in 1 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 does not own files or directories owned by other packages.
[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 must not depend on deprecated() packages.
[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 libexfat
     , libexfat-devel
[x]: Package functions as described.
[x]: Latest version is packaged.
[x]: Package does not include license text files separate from upstream.
[-]: Sources are verified with gpgverify first in %prep if upstream
     publishes signatures.
     Note: gpgverify is not used.
[-]: 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.
[x]: 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:
[!]: Package should not use obsolete m4 macros
     Note: Some obsoleted macros found, see the attachment.
     See: https://fedorahosted.org/FedoraReview/wiki/AutoTools
[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]: Spec file according to URL is the same as in SRPM.


Rpmlint
-------
Checking: exfatprogs-1.0.2-1.fc33.x86_64.rpm
          libexfat-1.0.2-1.fc33.x86_64.rpm
          libexfat-devel-1.0.2-1.fc33.x86_64.rpm
          exfatprogs-debuginfo-1.0.2-1.fc33.x86_64.rpm
          exfatprogs-debugsource-1.0.2-1.fc33.x86_64.rpm
          exfatprogs-1.0.2-1.fc33.src.rpm
exfatprogs.x86_64: W: spelling-error Summary(en_US) Userspace -> User space, User-space, Users pace
exfatprogs.x86_64: W: spelling-error Summary(en_US) exFAT -> ex Fat, expat, ex-fat
exfatprogs.x86_64: W: spelling-error %description -l en_US exFAT -> ex Fat, expat, ex-fat
exfatprogs.x86_64: W: no-manual-page-for-binary fsck.exfat
exfatprogs.x86_64: W: no-manual-page-for-binary label.exfat
exfatprogs.x86_64: W: no-manual-page-for-binary mkfs.exfat
libexfat.x86_64: W: spelling-error Summary(en_US) exFAT -> ex Fat, expat, ex-fat
libexfat.x86_64: W: spelling-error %description -l en_US exFAT -> ex Fat, expat, ex-fat
libexfat.x86_64: W: no-documentation
libexfat.x86_64: E: script-without-shebang /usr/share/licenses/libexfat/COPYING
libexfat-devel.x86_64: W: no-documentation
exfatprogs.src: W: spelling-error Summary(en_US) Userspace -> User space, User-space, Users pace
exfatprogs.src: W: spelling-error Summary(en_US) exFAT -> ex Fat, expat, ex-fat
exfatprogs.src: W: spelling-error %description -l en_US exFAT -> ex Fat, expat, ex-fat
6 packages and 0 specfiles checked; 1 errors, 13 warnings.




Rpmlint (debuginfo)
-------------------
Checking: exfatprogs-debuginfo-1.0.2-1.fc33.x86_64.rpm
1 packages and 0 specfiles checked; 0 errors, 0 warnings.





Rpmlint (installed packages)
----------------------------
libexfat.x86_64: W: spelling-error Summary(en_US) exFAT -> ex Fat, expat, ex-fat
libexfat.x86_64: W: spelling-error %description -l en_US exFAT -> ex Fat, expat, ex-fat
libexfat.x86_64: W: invalid-url URL: https://github.com/exfatprogs/exfatprogs <urlopen error [Errno -2] Name or service not known>
libexfat.x86_64: W: no-documentation
libexfat.x86_64: E: script-without-shebang /usr/share/licenses/libexfat/COPYING
exfatprogs-debuginfo.x86_64: W: invalid-url URL: https://github.com/exfatprogs/exfatprogs <urlopen error [Errno -2] Name or service not known>
exfatprogs.x86_64: W: spelling-error Summary(en_US) Userspace -> User space, User-space, Users pace
exfatprogs.x86_64: W: spelling-error Summary(en_US) exFAT -> ex Fat, expat, ex-fat
exfatprogs.x86_64: W: spelling-error %description -l en_US exFAT -> ex Fat, expat, ex-fat
exfatprogs.x86_64: W: invalid-url URL: https://github.com/exfatprogs/exfatprogs <urlopen error [Errno -2] Name or service not known>
exfatprogs.x86_64: W: no-manual-page-for-binary fsck.exfat
exfatprogs.x86_64: W: no-manual-page-for-binary label.exfat
exfatprogs.x86_64: W: no-manual-page-for-binary mkfs.exfat
libexfat-devel.x86_64: W: invalid-url URL: https://github.com/exfatprogs/exfatprogs <urlopen error [Errno -2] Name or service not known>
libexfat-devel.x86_64: W: no-documentation
exfatprogs-debugsource.x86_64: W: invalid-url URL: https://github.com/exfatprogs/exfatprogs <urlopen error [Errno -2] Name or service not known>
5 packages and 0 specfiles checked; 1 errors, 15 warnings.



Source checksums
----------------
https://github.com/exfatprogs/exfatprogs/archive/1.0.2/exfatprogs-1.0.2.tar.gz :
  CHECKSUM(SHA256) this package     : e7f14f32dd67601ff42717f432093a400de878774796f6f1684fb9dbf0d499e1
  CHECKSUM(SHA256) upstream package : e7f14f32dd67601ff42717f432093a400de878774796f6f1684fb9dbf0d499e1


Requires
--------
exfatprogs (rpmlib, GLIBC filtered):
    libc.so.6()(64bit)
    libexfat.so.0()(64bit)
    libm.so.6()(64bit)
    rtld(GNU_HASH)

libexfat (rpmlib, GLIBC filtered):
    libc.so.6()(64bit)
    rtld(GNU_HASH)

libexfat-devel (rpmlib, GLIBC filtered):
    libexfat(x86-64)
    libexfat.so.0()(64bit)

exfatprogs-debuginfo (rpmlib, GLIBC filtered):

exfatprogs-debugsource (rpmlib, GLIBC filtered):



Provides
--------
exfatprogs:
    exfatprogs
    exfatprogs(x86-64)

libexfat:
    libexfat
    libexfat(x86-64)
    libexfat.so.0()(64bit)

libexfat-devel:
    libexfat-devel
    libexfat-devel(x86-64)

exfatprogs-debuginfo:
    debuginfo(build-id)
    exfatprogs-debuginfo
    exfatprogs-debuginfo(x86-64)

exfatprogs-debugsource:
    exfatprogs-debugsource
    exfatprogs-debugsource(x86-64)



AutoTools: Obsoleted m4s found
------------------------------
  AC_PROG_LIBTOOL found in: exfatprogs-1.0.2/configure.ac:23


Generated by fedora-review 0.7.5 (5fa5b7e) last change: 2020-02-16
Command line :/usr/bin/fedora-review -b 1824156 -m fedora-rawhide-x86_64
Buildroot used: fedora-rawhide-x86_64
Active plugins: Generic, Shell-api, C/C++
Disabled plugins: Python, Haskell, Ocaml, Perl, R, fonts, SugarActivity, Java, PHP
Disabled flags: EPEL6, EPEL7, DISTTAG, BATCH, EXARCH

Comment 23 Neal Gompa 2020-05-19 10:47:56 UTC
No serious issues found.

PACKAGE APPROVED (sans FE-LEGAL!).

Comment 24 Simone Caronni 2020-05-20 11:21:27 UTC
Thanks for the review. I'm updating to 1.0.3, upstream has disabled building shared libraries:

https://github.com/exfatprogs/exfatprogs/commit/9d5bb880e3c310012c75f590f53e0f70a8173cef#diff-e8acc63b1e238f3255c900eed37254b8

But headers are installed anyway.

Shall I revert the relevant commits so we have a shared library again or just remove the library part? I think the library might come handy.

> libexfat.x86_64: E: script-without-shebang /usr/share/licenses/libexfat/COPYING
I will fix this in the spec file for 1.0.3.

Comment 25 Eric Sandeen 2020-05-20 16:15:19 UTC
If upstream is not building shared libraries or providing a stable API, Fedora should not try to do on its own.

Comment 26 Eric Sandeen 2020-05-20 17:05:26 UTC
(to put a finer point on it, I'd drop the whole -devel package; make install does not install headers, they aren't meant for public consumption)

Comment 27 Simone Caronni 2020-05-22 20:08:22 UTC
(In reply to Eric Sandeen from comment #25)
> If upstream is not building shared libraries or providing a stable API,
> Fedora should not try to do on its own.

Sound reasonable. Thanks.

Version 1.0.3 with no more libraries and license file in the main package.

Spec URL: https://slaanesh.fedorapeople.org/exfatprogs.spec
SRPM URL: https://slaanesh.fedorapeople.org/exfatprogs-1.0.3-1.fc32.src.rpm


$ rpmlint /var/lib/mock/fedora-32-x86_64/result/exfatprogs-1.0.3-1.fc32.*
exfatprogs.src: W: spelling-error Summary(en_US) Userspace -> User space, User-space, Users pace
exfatprogs.src: W: spelling-error Summary(en_US) exFAT -> ex Fat, expat, ex-fat
exfatprogs.src: W: spelling-error %description -l en_US exFAT -> ex Fat, expat, ex-fat
exfatprogs.x86_64: W: spelling-error Summary(en_US) Userspace -> User space, User-space, Users pace
exfatprogs.x86_64: W: spelling-error Summary(en_US) exFAT -> ex Fat, expat, ex-fat
exfatprogs.x86_64: W: spelling-error %description -l en_US exFAT -> ex Fat, expat, ex-fat
2 packages and 0 specfiles checked; 0 errors, 6 warnings.


Now let's wait for the FE-LEGAL waiver.

Comment 28 Eric Sandeen 2020-05-22 20:54:44 UTC
Cool, thanks - yes I think that's better, if they ever do release a shared library (which TBH would be a little surprising...) easy enough to add the subpackage back.

Comment 29 Peter Lemenkov 2020-05-28 18:41:04 UTC
*** Bug 822049 has been marked as a duplicate of this bug. ***

Comment 30 Gary Buhrmaster 2020-06-20 15:10:51 UTC
(In reply to Simone Caronni from comment #27)
 
> Now let's wait for the FE-LEGAL waiver.

I would have expected that FE-LEGAL would have made a decision by now given that the 5.7 kernel (with the exfat driver included) has now entered a test day.

Comment 31 Tom "spot" Callaway 2020-06-20 15:17:04 UTC
(In reply to Gary Buhrmaster from comment #30)
> (In reply to Simone Caronni from comment #27)
>  
> > Now let's wait for the FE-LEGAL waiver.
> 
> I would have expected that FE-LEGAL would have made a decision by now given
> that the 5.7 kernel (with the exfat driver included) has now entered a test
> day.

Life is full of unfulfilled expectations. :)

This situation is not simple, and unfortunately, I can't explain it. I don't know when the hold will be able to be lifted, but I don't think this is going to be blocked indefinitely. Thanks for your patience.

Comment 32 Simone Caronni 2020-07-03 07:24:41 UTC
Just FYI, kernel is now also stable in Fedora 32:

$ uname -r
5.7.6-201.fc32.x86_64
$ modinfo exfat | head -3
filename:       /lib/modules/5.7.6-201.fc32.x86_64/kernel/fs/exfat/exfat.ko.xz
author:         Samsung Electronics Co., Ltd.
description:    exFAT filesystem support

Comment 33 Simone Caronni 2020-08-24 07:35:15 UTC
Just saw that Tom is no longer working for Red Hat.. does this change anything regarding the legal approval? He has been removed from CC in this ticket.

I would set a needinfo to some address but I wouldn't know who to...

Comment 34 Peter Robinson 2020-08-24 10:32:27 UTC
(In reply to Simone Caronni from comment #33)
> Just saw that Tom is no longer working for Red Hat.. does this change
> anything regarding the legal approval? He has been removed from CC in this
> ticket.
> 
> I would set a needinfo to some address but I wouldn't know who to...

See https://pagure.io/Fedora-Council/tickets/issue/311 for details. Everything is still in motion, handled currently by Matthew and Ben

Comment 35 Simone Caronni 2020-08-24 11:11:50 UTC
(In reply to Peter Robinson from comment #34)
> See https://pagure.io/Fedora-Council/tickets/issue/311 for details.
> Everything is still in motion, handled currently by Matthew and Ben

I get a 404 on that URL, but good to hear. Thanks!

Comment 36 Simone Caronni 2020-10-08 07:15:27 UTC
Any update on this? How is the legal review going?

Comment 37 Ben Cotton 2020-10-08 14:16:57 UTC
It's on a process hold. I expect to have an update toward the end of the year.

Comment 38 Simone Caronni 2020-12-04 14:58:22 UTC
In the meanwhile... any update on the legal side by chance?

Spec URL: https://slaanesh.fedorapeople.org/exfatprogs.spec
SRPM URL: https://slaanesh.fedorapeople.org/exfatprogs-1.0.4-1.fc32.src.rpm

* Fri Dec 04 2020 Simone Caronni <negativo17> - 1.0.4-1
- Update to 1.0.4.

Comment 39 Ben Cotton 2020-12-04 15:07:57 UTC
Expect an update at the end of the month.

Comment 40 Ben Cotton 2020-12-22 14:08:23 UTC
OIN Table 10 published today includes exfatprogs. Lifting legal hold.

Comment 41 Simone Caronni 2020-12-26 10:01:13 UTC
Had to reset the review status as I was getting this:

$ fedpkg request-repo exfatprogs 1824156
Could not execute request_repo: The Bugzilla bug's review was approved over 60 days ago

Requested repository now: https://pagure.io/releng/fedora-scm-requests/issue/31449

Comment 42 Neal Gompa 2020-12-26 18:55:59 UTC
I've redone the approval so that it won't fail.

Comment 43 Igor Raits 2020-12-26 18:59:15 UTC
(fedscm-admin):  The Pagure repository was created at https://src.fedoraproject.org/rpms/exfatprogs

Comment 44 Fedora Update System 2020-12-27 13:58:09 UTC
FEDORA-EPEL-2020-b83de3a61f has been submitted as an update to Fedora EPEL 8. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-b83de3a61f

Comment 45 Fedora Update System 2020-12-27 13:58:10 UTC
FEDORA-EPEL-2020-7e23671a4b has been submitted as an update to Fedora EPEL 7. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-7e23671a4b

Comment 46 Fedora Update System 2020-12-28 01:08:38 UTC
FEDORA-2020-1c309da089 has been pushed to the Fedora 33 stable repository.
If problem still persists, please make note of it in this bug report.

Comment 47 Fedora Update System 2020-12-28 01:34:05 UTC
FEDORA-2020-673357b782 has been pushed to the Fedora 32 stable repository.
If problem still persists, please make note of it in this bug report.

Comment 48 Fedora Update System 2020-12-28 01:44:32 UTC
FEDORA-EPEL-2020-b83de3a61f has been pushed to the Fedora EPEL 8 testing repository.

You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-b83de3a61f

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 49 Fedora Update System 2020-12-28 01:47:47 UTC
FEDORA-EPEL-2020-7e23671a4b has been pushed to the Fedora EPEL 7 testing repository.

You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-7e23671a4b

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 50 Fedora Update System 2021-01-12 01:34:16 UTC
FEDORA-EPEL-2020-7e23671a4b has been pushed to the Fedora EPEL 7 stable repository.
If problem still persists, please make note of it in this bug report.

Comment 51 Fedora Update System 2021-01-12 01:41:16 UTC
FEDORA-EPEL-2020-b83de3a61f has been pushed to the Fedora EPEL 8 stable repository.
If problem still persists, please make note of it in this bug report.