Bug 1645848 (libb64) - Review Request: libb64 - A library for fast encoding/decoding data into and from a base64-encoded format
Summary: Review Request: libb64 - A library for fast encoding/decoding data into and f...
Keywords:
Status: CLOSED ERRATA
Alias: libb64
Product: Fedora
Classification: Fedora
Component: Package Review
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Robert-André Mauchin
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: fedora-neuro
TreeView+ depends on / blocked
 
Reported: 2018-11-04 11:02 UTC by Ankur Sinha (FranciscoD)
Modified: 2018-11-18 06: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-11-18 02:57:08 UTC
zebob.m: fedora-review+


Attachments (Terms of Use)

Description Ankur Sinha (FranciscoD) 2018-11-04 11:02:52 UTC
Spec URL: https://ankursinha.fedorapeople.org/libb64/libb64.spec
SRPM URL: https://ankursinha.fedorapeople.org/libb64/libb64-1.2-1.fc29.src.rpm

Description: 
libb64 is a library of ANSI C routines for fast encoding/decoding data into and
from a base64-encoded format. C++ wrappers are included, as well as the source
code for standalone encoding and decoding executables.

Base64 uses a subset of displayable ASCII characters, and is therefore a useful
encoding for storing binary data in a text file, such as XML, or sending binary
data over text-only email.


Fedora Account System Username: ankursinha

Comment 1 Ankur Sinha (FranciscoD) 2018-11-04 11:03:23 UTC
(Required for biosig: https://pagure.io/neuro-sig/NeuroFedora/issue/56)

Comment 2 Artur Iwicki 2018-11-04 11:38:29 UTC
>%global _description %{expand: \
Any particular reason for putting the description into a macro?

>export "CFLAGS=%{optflags}"
>export "CXXFLAGS=%{optflags}"
>export "LDFLAGS=%{build_ldflags}"
Use "%set_build_flags" instead.

Comment 3 Ankur Sinha (FranciscoD) 2018-11-04 12:05:08 UTC
(In reply to Artur Iwicki from comment #2)
> >%global _description %{expand: \
> Any particular reason for putting the description into a macro?

Sorry--left over from my spec template. Comes in handy when there are multiple sub packages :)

> 
> >export "CFLAGS=%{optflags}"
> >export "CXXFLAGS=%{optflags}"
> >export "LDFLAGS=%{build_ldflags}"
> Use "%set_build_flags" instead.

Ah, nice one. Done!

New spec/srpm:

https://ankursinha.fedorapeople.org/libb64/libb64.spec
https://ankursinha.fedorapeople.org/libb64/libb64-1.2-2.fc29.src.rpm

Scratch build: https://koji.fedoraproject.org/koji/taskinfo?taskID=30656539

Thanks,
Ankur

Comment 4 Michael Schwendt 2018-11-05 11:12:56 UTC
* /usr/bin/base64 conflicts with coreutils [!]


* The explicit dependencies are dubious:

1) The -devel subpackage does not need the base package, since it is complete due to headers *and* the static lib.

2) The license file does not need to be duplicated as long as the -devel package explicitly requires the base package, which also contains the same license file.


* Package %summary and %description are not clear yet IMO. The base package describes a library. Yet it only contains an executable. The %description continues with a very brief comment on "Base64" without telling what functionality is provided by this package.


> https://kojipkgs.fedoraproject.org//work/tasks/6540/30656540/build.log

https://fedoraproject.org/wiki/Packaging:Guidelines#Compiler_flags

Comment 5 Ankur Sinha (FranciscoD) 2018-11-05 11:57:23 UTC
(In reply to Michael Schwendt from comment #4)
> * /usr/bin/base64 conflicts with coreutils [!]

Ugh, and it seems to do the exact same thing too. However, coreutils does not provide the headers or the lib that this provides (and biosig needs). Would it be OK to rename this binary to differentiate it from the one coreutils provides?

$ sudo dnf whatprovides '*/cencode.h'
Io-language-devel-20151111-0.e64ff9.fc29.13.i686 : Development files for Io-language
Repo        : fedora
Matched from:
Filename    : /usr/include/io/cencode.h

Io-language-devel-20151111-0.e64ff9.fc29.13.x86_64 : Development files for Io-language
Repo        : fedora
Matched from:
Filename    : /usr/include/io/cencode.h


> 
> 
> * The explicit dependencies are dubious:
> 
> 1) The -devel subpackage does not need the base package, since it is
> complete due to headers *and* the static lib.

Updated.

> 
> 2) The license file does not need to be duplicated as long as the -devel
> package explicitly requires the base package, which also contains the same
> license file.

It doesn't require the base package now, so I'll leave that in here.

> 
> 
> * Package %summary and %description are not clear yet IMO. The base package
> describes a library. Yet it only contains an executable. 

Is this better, do you think?

"Tool for fast encoding/decoding data into and from a base64-encoded format"


> The %description
> continues with a very brief comment on "Base64" without telling what
> functionality is provided by this package.

This is all upstream says:

"libb64 is a library of ANSI C routines for fast encoding/decoding data into and from a base64-encoded format. C++ wrappers are included, as well as the source code for standalone encoding and decoding executables. "

I've now copied bits from wikipedia too. How is this?

"Base64 is a group of similar binary-to-text encoding schemes that represent
binary data in an ASCII string format by translating it into a radix-64
representation. The term Base64 originates from a specific MIME content
transfer encoding. Each Base64 digit represents exactly 6 bits of data. Three
8-bit bytes (i.e., a total of 24 bits) can therefore be represented by four
6-bit Base64 digits.

Base64 uses a subset of displayable ASCII characters, and is therefore a useful
encoding for storing binary data in a text file, such as XML, or sending binary
data over text-only email.

libb64 is a library of ANSI C routines for fast encoding/decoding data into and
from a base64-encoded format. C++ wrappers are included, as well as the source
code for standalone encoding and decoding executables.
"

> 
> 
> > https://kojipkgs.fedoraproject.org//work/tasks/6540/30656540/build.log
> 
> https://fedoraproject.org/wiki/Packaging:Guidelines#Compiler_flags

Can you please be more clear on what I'm missing here? Is it the addition of -O3 to the flags? I've corrected that bit now, but you'll have to point out what else I'm missing, I'm afraid.

Updated spec/srpm: 
https://ankursinha.fedorapeople.org/libb64/libb64.spec
https://ankursinha.fedorapeople.org/libb64/libb64-1.2-3.fc29.src.rpm

Scratch build: https://koji.fedoraproject.org/koji/taskinfo?taskID=30684654

Cheers,
Ankur

Comment 6 Manas Mangaonkar (Pac23) 2018-11-06 06:37:32 UTC
libb64.x86_64: - can you include a man page for the binary libb64-base64
also a zero length error in the libb64/TODO

devel.x86_64 lacks documentation aswell. 

Package builds fine otherwise.

Comment 7 Ankur Sinha (FranciscoD) 2018-11-06 11:10:48 UTC
(In reply to Manas Mangaonkar (Pac23) from comment #6)
> libb64.x86_64: - can you include a man page for the binary libb64-base64

Not really. Upstream doesn't provide one :(


> also a zero length error in the libb64/TODO

Removed.

> 
> devel.x86_64 lacks documentation aswell. 

Again, upstream does not provide any, so there is none to include :(

> 
> Package builds fine otherwise.

Thanks.

Comment 8 Michael Schwendt 2018-11-06 12:21:28 UTC
> Can you please be more clear on what I'm missing here? Is it the addition of
> -O3 to the flags? I've corrected that bit now, but you'll have to point out
> what else I'm missing, I'm afraid.

Yes, -O3 and possibly more flags that override Fedora's defaults. The guidelines offer multiple choices how to handle such a case. Removing -O3 is the most plausible option.


> I've now copied bits from wikipedia too. How is this?

The primary issue remains. The base package "libb64" does not contain a library. It also doesn't contain the source code. It contains only the command-line executable with nothing in the %description commenting on it or its strengths compared with the tool from coreutils.

Is the primary interest in the library and API or the executable? I understand that you need the lib as buildreq for other packages, but if shipping the tool in a separate non-devel package starting with a "lib" prefix in its name, the package description should mention that.

Note that you could also build a "libb64-tools" subpackage instead, even if it's only a single executable.

Comment 9 Ankur Sinha (FranciscoD) 2018-11-06 22:30:29 UTC
(In reply to Michael Schwendt from comment #8)
> > Can you please be more clear on what I'm missing here? Is it the addition of
> > -O3 to the flags? I've corrected that bit now, but you'll have to point out
> > what else I'm missing, I'm afraid.
> 
> Yes, -O3 and possibly more flags that override Fedora's defaults. The
> guidelines offer multiple choices how to handle such a case. Removing -O3 is
> the most plausible option.

I've removed the flags that upstream was adding.

> 
> 
> > I've now copied bits from wikipedia too. How is this?
> 
> The primary issue remains. The base package "libb64" does not contain a
> library. It also doesn't contain the source code. It contains only the
> command-line executable with nothing in the %description commenting on it or
> its strengths compared with the tool from coreutils.
> 
> Is the primary interest in the library and API or the executable? I
> understand that you need the lib as buildreq for other packages, but if
> shipping the tool in a separate non-devel package starting with a "lib"
> prefix in its name, the package description should mention that.
> 
> Note that you could also build a "libb64-tools" subpackage instead, even if
> it's only a single executable.

I've updated the description of the main package to mention that it includes the tool, and that users should install the -devel package if they wish to develop using the library:

"This package provides the %{name}-b64 binary tool for encoding to and decoding
from the Base64 scheme. Please install the %{name}-devel package to develop
software using %{name}."

Do you think that's clear enough? If not, I'll put the binary into a separate -tools subpackage.

Updated spec/srpm: 
https://ankursinha.fedorapeople.org/libb64/libb64.spec
https://ankursinha.fedorapeople.org/libb64/libb64-1.2-3.fc29.src.rpm

Cheers,
Ankur

Comment 10 Artur Iwicki 2018-11-06 23:26:02 UTC
From what I've seen, libraries in Fedora usually are divided like this:
- main package: stuff needed for running executables using the lib
- devel: headers
- static: stuff needed for static compilation
- tools: any library-related executables
As such, my personal suggestion would be to make the -devel package provide the -static package (already done from what I see), put the binary in -tools, and omit the main package.

Comment 11 Ankur Sinha (FranciscoD) 2018-11-07 07:49:55 UTC
(In reply to Artur Iwicki from comment #10)
> From what I've seen, libraries in Fedora usually are divided like this:
> - main package: stuff needed for running executables using the lib
> - devel: headers
> - static: stuff needed for static compilation
> - tools: any library-related executables
> As such, my personal suggestion would be to make the -devel package provide
> the -static package (already done from what I see), put the binary in
> -tools, and omit the main package.

Done.

Updated spec/srpm: 
https://ankursinha.fedorapeople.org/libb64/libb64.spec
https://ankursinha.fedorapeople.org/libb64/libb64-1.2-3.fc29.src.rpm

Scratch builds:
F30: https://koji.fedoraproject.org/koji/taskinfo?taskID=30721323
F29: https://koji.fedoraproject.org/koji/taskinfo?taskID=30721330

Comment 12 Ankur Sinha (FranciscoD) 2018-11-08 10:54:26 UTC
Hello,

Would either of you be able to do the formal review for libb64 here? I'll request a review swap on the devel list again, otherwise.

Cheers,
Ankur

Comment 13 Robert-André Mauchin 2018-11-09 11:34:35 UTC
The license field should be CC0. The website links to Creative Commons Zero 1.0 Universal.

Comment 14 Ankur Sinha (FranciscoD) 2018-11-09 12:05:24 UTC
(In reply to Robert-André Mauchin from comment #13)
> The license field should be CC0. The website links to Creative Commons Zero
> 1.0 Universal.

Hrm, but he goes "This work is released into the Public Domain.", and the link there goes to a "retired license": https://creativecommons.org/licenses/publicdomain/. This is not the CC0 universal license which is here: https://creativecommons.org/publicdomain/zero/1.0/legalcode

CC0 etc are also content licenses

Isn't it OK to use Public Domain here, since that is the intention of the author?

Comment 15 Robert-André Mauchin 2018-11-09 14:18:19 UTC
(In reply to Ankur Sinha (FranciscoD) from comment #14)
> (In reply to Robert-André Mauchin from comment #13)
> > The license field should be CC0. The website links to Creative Commons Zero
> > 1.0 Universal.
> 
> Hrm, but he goes "This work is released into the Public Domain.", and the
> link there goes to a "retired license":
> https://creativecommons.org/licenses/publicdomain/. This is not the CC0
> universal license which is here:
> https://creativecommons.org/publicdomain/zero/1.0/legalcode
> 
> CC0 etc are also content licenses
> 
> Isn't it OK to use Public Domain here, since that is the intention of the
> author?

Ah you're right.

Comment 16 Robert-André Mauchin 2018-11-09 14:38:03 UTC
Package is approved.



Package Review
==============

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



===== 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]: 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: "Public domain", "Unknown or generated", "*No copyright* Public
     domain". 12 files have unknown license. Detailed output of
     licensecheck in /home/bob/packaging/review/libb64/review-
     libb64/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 2 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 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 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]: Static libraries in -static or -devel subpackage, providing -devel if
     present.
     Note: Package has .a files: libb64-devel.
[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).
[-]: Fully versioned dependency in subpackages if applicable.
     Note: No Requires: %{name}%{?_isa} = %{version}-%{release} in
     libb64-devel , libb64-tools , libb64-debugsource
[?]: Package functions as described.
[x]: Latest version is packaged.
[x]: Package does not include license text files separate from upstream.
[-]: 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:
[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: libb64-devel-1.2-3.fc30.x86_64.rpm
          libb64-tools-1.2-3.fc30.x86_64.rpm
          libb64-debugsource-1.2-3.fc30.x86_64.rpm
          libb64-1.2-3.fc30.src.rpm
libb64-devel.x86_64: W: no-documentation
libb64-tools.x86_64: W: summary-not-capitalized C libb64-b64 binary provided by libb64
libb64-tools.x86_64: W: no-manual-page-for-binary libb64-base64
4 packages and 0 specfiles checked; 0 errors, 3 warnings.

Comment 17 Ankur Sinha (FranciscoD) 2018-11-09 15:04:02 UTC
Thanks for the review, Robert. SCM requested: https://pagure.io/releng/fedora-scm-requests/issue/8768

Comment 18 Gwyn Ciesla 2018-11-09 15:42:47 UTC
(fedscm-admin):  The Pagure repository was created at https://src.fedoraproject.org/rpms/libb64

Comment 19 Fedora Update System 2018-11-09 16:23:26 UTC
libb64-1.2-3.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2018-48c5becff8

Comment 20 Fedora Update System 2018-11-09 16:23:32 UTC
libb64-1.2-3.fc29 has been submitted as an update to Fedora 29. https://bodhi.fedoraproject.org/updates/FEDORA-2018-e39db43366

Comment 21 Fedora Update System 2018-11-09 16:23:37 UTC
libb64-1.2-3.fc28 has been submitted as an update to Fedora 28. https://bodhi.fedoraproject.org/updates/FEDORA-2018-ea295e864d

Comment 22 Fedora Update System 2018-11-10 04:06:58 UTC
libb64-1.2-3.fc27 has been pushed to the Fedora 27 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-48c5becff8

Comment 23 Fedora Update System 2018-11-10 05:01:13 UTC
libb64-1.2-3.fc29 has been pushed to the Fedora 29 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-e39db43366

Comment 24 Fedora Update System 2018-11-10 05:09:38 UTC
libb64-1.2-3.fc28 has been pushed to the Fedora 28 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-ea295e864d

Comment 25 Fedora Update System 2018-11-18 02:57:08 UTC
libb64-1.2-3.fc28 has been pushed to the Fedora 28 stable repository. If problems still persist, please make note of it in this bug report.

Comment 26 Fedora Update System 2018-11-18 03:55:43 UTC
libb64-1.2-3.fc29 has been pushed to the Fedora 29 stable repository. If problems still persist, please make note of it in this bug report.

Comment 27 Fedora Update System 2018-11-18 06:19:00 UTC
libb64-1.2-3.fc27 has been pushed to the Fedora 27 stable repository. If problems still persist, please make note of it in this bug report.


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