Bug 1645848 (libb64)

(Required for biosig: https://pagure.io/neuro-sig/NeuroFedora/issue/56)

>%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.

(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

* /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

(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

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.

(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.

> 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.

(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

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.

(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

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

The license field should be CC0. The website links to Creative Commons Zero 1.0 Universal.

(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?

(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.

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.

Thanks for the review, Robert. SCM requested: https://pagure.io/releng/fedora-scm-requests/issue/8768

(fedscm-admin):  The Pagure repository was created at https://src.fedoraproject.org/rpms/libb64

libb64-1.2-3.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2018-48c5becff8

libb64-1.2-3.fc29 has been submitted as an update to Fedora 29. https://bodhi.fedoraproject.org/updates/FEDORA-2018-e39db43366

libb64-1.2-3.fc28 has been submitted as an update to Fedora 28. https://bodhi.fedoraproject.org/updates/FEDORA-2018-ea295e864d

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

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

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

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.

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.

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.