Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1645848 (libb64)
Summary: | Review Request: libb64 - A library for fast encoding/decoding data into and from a base64-encoded format | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Ankur Sinha (FranciscoD) <sanjay.ankur> |
Component: | Package Review | Assignee: | Robert-André Mauchin 🐧 <zebob.m> |
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | rawhide | CC: | fedora, manasmangaonkar, package-review, zebob.m |
Target Milestone: | --- | Flags: | zebob.m:
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: | 2018-11-18 02:57:08 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: | |||
Bug Depends On: | |||
Bug Blocks: | 1276941 |
Description
Ankur Sinha (FranciscoD)
2018-11-04 11:02:52 UTC
(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. |