Spec URL: https://jwboyer.fedorapeople.org/pub/manifest-tool.spec SRPM URL: https://jwboyer.fedorapeople.org/pub/manifest-tool-0.6.0-1.gita28af2b.fc25.src.rpm Description: This tool was mainly created for the purpose of viewing, creating, and pushing the new manifests list object type in the Docker registry. Manifest lists are defined in the v2.2 image specification and exist mainly for the purpose of supporting multi-architecture and/or multi-platform images within a Docker registry. Fedora Account System Username: jwboyer
%global with_bundled is not used anywhere? > %{!?_licensedir:%global license %doc} %license is defined everywhere now. You've got an awful lot of macros that get used at most one time. %provider_tld, really? Looks OK, but I know nothing about go.
(In reply to Zbigniew Jędrzejewski-Szmek from comment #1) > %global with_bundled is not used anywhere? > > > %{!?_licensedir:%global license %doc} > %license is defined everywhere now. Dropped both. > You've got an awful lot of macros that get used at most one time. > %provider_tld, really? So I copied this infrastructure from the buildah package. I believe the intention is to allow for different upstream repositories to be used by simply changing the macros rather than redefining every location in the spec. E.g. one could switch to pulling from a projectatomic.io repository in case there were changes needed before they are merged upstream. A number of the go-based container tools do this. > Looks OK, but I know nothing about go. New version of the spec and SRPM: Spec URL: https://jwboyer.fedorapeople.org/pub/manifest-tool.spec SRPM URL: https://jwboyer.fedorapeople.org/pub/manifest-tool-0.6.0-2.gita28af2b.fc25.src.rpm
> E.g. one could switch to pulling from a projectatomic.io repository in case there were changes needed before they are merged upstream. I find such excess of macros not very useful — in the unlikely event that the url even changes, search&replace works just as well. And macros make it hard to copy&paste, so I prefer to use macros only for stuff which actually changes, like %_lib, or %version, or %release. Personal preference of course. > New version of the spec and SRPM: Unfortunately I cannot volunteer for the review because I lack go knowledge. Sorry!
(In reply to Zbigniew Jędrzejewski-Szmek from comment #3) > > E.g. one could switch to pulling from a projectatomic.io repository in case there were changes needed before they are merged upstream. > > I find such excess of macros not very useful — in the unlikely event that > the url even changes, search&replace works just as well. And macros make it > hard to copy&paste, so I prefer to use macros only for stuff which actually > changes, like %_lib, or %version, or %release. Personal preference of course. This url changing actually happens frequently for other go packages. I don't really care either way though. > > New version of the spec and SRPM: > > Unfortunately I cannot volunteer for the review because I lack go knowledge. > Sorry! Well, thanks for the initial comments anyway.
Package Review ============== Legend: [x] = Pass, [!] = Fail, [-] = Not applicable, [?] = Not evaluated [ ] = Manual review needed Issues: ======= - Package installs properly. Note: Installation errors (see attachment) See: https://fedoraproject.org/wiki/Packaging:Guidelines ===== MUST items ===== 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: There is no build directory. Running licensecheck on vanilla upstream sources. Licenses found: "Apache (v2.0)", "Unknown or generated", "MIT/X11 (BSD like)", "BSD (3 clause)", "BSD (2 clause)", "*No copyright* Apache (v2.0)". 795 files have unknown license. Detailed output of licensecheck in /home/admiller/reviews/1467322 -manifest-tool/licensecheck.txt [-]: License file installed when any subpackage combination is installed. [x]: %build honors applicable compiler flags or justifies otherwise. [!]: 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. [-]: 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 20480 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]: 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]: All build dependencies are listed in BuildRequires, except for any that are listed in the exceptions section of Packaging Guidelines. [x]: Package uses either %{buildroot} or $RPM_BUILD_ROOT [x]: Package does not run rm -rf %{buildroot} (or $RPM_BUILD_ROOT) at the beginning of %install. [x]: Macros in Summary, %description expandable at SRPM build time. [x]: Dist tag is present. [x]: Package does not contain duplicates in %files. [x]: Permissions on files are set properly. [x]: Package use %makeinstall only when make install DESTDIR=... doesn't work. [x]: Package is named using only allowed ASCII characters. [x]: Package does not use a name that already exists. [x]: Package is not relocatable. [x]: Sources used to build the package match the upstream source, as provided in the spec URL. [x]: Spec file name must match the spec package %{name}, in the format %{name}.spec. [x]: File names are valid UTF-8. [x]: Packages must not store files under /srv, /opt or /usr/local ===== SHOULD items ===== Generic: [-]: Uses parallel make %{?_smp_mflags} macro. [-]: 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 manifest-tool-debuginfo [x]: Package functions as described. [x]: Latest version is packaged. [x]: Package does not include license text files separate from upstream. [x]: Description and summary sections in the package spec file contains translations for supported Non-English languages, if available. [-]: %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]: Package should compile and build into binary rpms on all supported architectures. [x]: Spec use %global instead of %define unless justified. ===== EXTRA items ===== Generic: [x]: Rpmlint is run on all installed packages. See: http://fedoraproject.org/wiki/Packaging/Guidelines#rpmlint [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: manifest-tool-0.6.0-2.gita28af2b.fc25.x86_64.rpm manifest-tool-debuginfo-0.6.0-2.gita28af2b.fc25.x86_64.rpm manifest-tool-0.6.0-2.gita28af2b.fc25.src.rpm manifest-tool.x86_64: W: spelling-error %description -l en_US multi -> mulch, mufti manifest-tool.x86_64: W: no-manual-page-for-binary manifest-tool manifest-tool.src: W: spelling-error %description -l en_US multi -> mulch, mufti 3 packages and 0 specfiles checked; 0 errors, 3 warnings. Requires -------- manifest-tool (rpmlib, GLIBC filtered): libc.so.6()(64bit) libpthread.so.0()(64bit) rtld(GNU_HASH) manifest-tool-debuginfo (rpmlib, GLIBC filtered): Provides -------- manifest-tool: manifest-tool manifest-tool(x86-64) manifest-tool-debuginfo: manifest-tool-debuginfo manifest-tool-debuginfo(x86-64) Source checksums ---------------- https://github.com/estesp/manifest-tool/archive/a28af2b6bf3748859149bf161eb0630e677c3906/manifest-tool-a28af2b.tar.gz : CHECKSUM(SHA256) this package : 9db9b4ec70f9b0c71510cde05139833c192b5649bda2b07af39fbde47aa8d972 CHECKSUM(SHA256) upstream package : 9db9b4ec70f9b0c71510cde05139833c192b5649bda2b07af39fbde47aa8d972 Generated by fedora-review 0.6.1 (f03e4e7) last change: 2016-05-02 Command line :/usr/bin/fedora-review -b 1467322 Buildroot used: fedora-25-x86_64 Active plugins: Generic, Shell-api, C/C++ Disabled plugins: Java, Python, fonts, SugarActivity, Ocaml, Perl, Haskell, R, PHP Disabled flags: EXARCH, DISTTAG, EPEL5, BATCH, EPEL6 ITEMS TO FIX ------------ - All bundled golang libraries need to be listed as 'Provides: bundled(<libname>) = <version>' directives as per https://fedoraproject.org/wiki/Packaging:Guidelines#Bundling_and_Duplication_of_system_libraries Other than that, the package looks good.
(In reply to Adam Miller from comment #5) Thanks for picking up the review! > ITEMS TO FIX > ------------ > > - All bundled golang libraries need to be listed as 'Provides: > bundled(<libname>) = <version>' directives as per > https://fedoraproject.org/wiki/Packaging: > Guidelines#Bundling_and_Duplication_of_system_libraries > > Other than that, the package looks good. OK, so I have two questions: 1) Why do e.g. runc, docker, etc not Provide anything they bundle? Confused there. I see stuff in -devel, but not in the main packages. 2) An example of a Provide for this package would be: Provides: bundled(golang(github.com/codegangsta/cli/)) = v1.2.0 Provides: bundled(golang(golang.org/x/net)) = master correct?
(In reply to Josh Boyer from comment #6) > (In reply to Adam Miller from comment #5) > > Thanks for picking up the review! > > > ITEMS TO FIX > > ------------ > > > > - All bundled golang libraries need to be listed as 'Provides: > > bundled(<libname>) = <version>' directives as per > > https://fedoraproject.org/wiki/Packaging: > > Guidelines#Bundling_and_Duplication_of_system_libraries > > > > Other than that, the package looks good. > > OK, so I have two questions: > > 1) Why do e.g. runc, docker, etc not Provide anything they bundle? Confused > there. I see stuff in -devel, but not in the main packages. > runc and docker should and if they aren't, they are in violation of the Guidelines, should have bugs filed against them, and should be fixed. > 2) An example of a Provide for this package would be: > > Provides: bundled(golang(github.com/codegangsta/cli/)) = v1.2.0 > Provides: bundled(golang(golang.org/x/net)) = master > > correct? The first one looks good pending that is a git tag that can be checked out, the latter however needs to correlate to a commit id or tag. For an examples, check the OpenShift Origin and/or reg specs: http://pkgs.fedoraproject.org/cgit/rpms/reg.git/tree/reg.spec http://pkgs.fedoraproject.org/cgit/rpms/origin.git/tree/origin.spec
(In reply to Adam Miller from comment #7) > (In reply to Josh Boyer from comment #6) > > (In reply to Adam Miller from comment #5) > > > > Thanks for picking up the review! > > > > > ITEMS TO FIX > > > ------------ > > > > > > - All bundled golang libraries need to be listed as 'Provides: > > > bundled(<libname>) = <version>' directives as per > > > https://fedoraproject.org/wiki/Packaging: > > > Guidelines#Bundling_and_Duplication_of_system_libraries > > > > > > Other than that, the package looks good. > > > > OK, so I have two questions: > > > > 1) Why do e.g. runc, docker, etc not Provide anything they bundle? Confused > > there. I see stuff in -devel, but not in the main packages. > > > > runc and docker should and if they aren't, they are in violation of the > Guidelines, should have bugs filed against them, and should be fixed. > > > > 2) An example of a Provide for this package would be: > > > > Provides: bundled(golang(github.com/codegangsta/cli/)) = v1.2.0 > > Provides: bundled(golang(golang.org/x/net)) = master > > > > correct? > > The first one looks good pending that is a git tag that can be checked out, > the latter however needs to correlate to a commit id or tag. Erm... any tips on how to determine what commit has been vendored? The vendor.conf file literally lists "master". > For an examples, check the OpenShift Origin and/or reg specs: > > http://pkgs.fedoraproject.org/cgit/rpms/reg.git/tree/reg.spec > http://pkgs.fedoraproject.org/cgit/rpms/origin.git/tree/origin.spec Yeah, I looked at those to come up with my examples above. I'll be away from keyboard for a few days, but I'll see what I can come up with and submit a new spec Monday.
I wouldn't sweat it. In decreasing order of compliance with the guidelines: - just use a date: Provides: bundled(golang(golang.org/x/net)) = 20170305 (where the date is the date where the vendorization was done or something) - just use unversioned provides: Provides: bundled(golang(golang.org/x/net)) (The latter is pretty common, try "rpm -q -a --provides|grep bundled"... The guidelines are well-intentioned, but if it's so hard to find which version exactly is bundled, *and* this is something you'd have to do after every update, I just don't think it's worth your time.)
(In reply to Zbigniew Jędrzejewski-Szmek from comment #9) > I wouldn't sweat it. In decreasing order of compliance with the guidelines: > - just use a date: Provides: bundled(golang(golang.org/x/net)) = 20170305 > (where the date is the date where the vendorization was done or something) > - just use unversioned provides: Provides: bundled(golang(golang.org/x/net)) > > (The latter is pretty common, try "rpm -q -a --provides|grep bundled"... The > guidelines are well-intentioned, but if it's so hard to find which version > exactly is bundled, *and* this is something you'd have to do after every > update, I just don't think it's worth your time.) Neither of those options is in line with the Guidelines that went through FPC and FESCo for approval, please don't advocate for their use. Neither of those options provide a proper mechanism for auditing. I have opened a ticket with FESCo to determine appropriate action for dealing with all the not versioned bundled entries currently in existence. https://pagure.io/fesco/issue/1734
I've added the bundled Provides. For the bundled versions with explicit tags or commits, I've included those. For those where I can't tell which upstream is explicitly vendored, I've left the Provides unversioned. Hopefully that's sufficient in light of the on-going devel discussions. SPEC: https://jwboyer.fedorapeople.org/pub/manifest-tool.spec SRPM: https://jwboyer.fedorapeople.org/pub/manifest-tool-0.6.0-3.gita28af2b.fc25.src.rpm
+1 - I'm not going to block this while things are still up in the air on how Fedora as a whole wants to handle this. APPROVED
Package request has been approved: https://admin.fedoraproject.org/pkgdb/package/rpms/manifest-tool
manifest-tool-0.6.0-3.gita28af2b.fc25 has been submitted as an update to Fedora 25. https://bodhi.fedoraproject.org/updates/FEDORA-2017-b093304055
manifest-tool-0.6.0-4.gita28af2b.el7 has been submitted as an update to Fedora EPEL 7. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-bef4cbcf4b
manifest-tool-0.6.0-4.gita28af2b.el7 has been pushed to the Fedora EPEL 7 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-EPEL-2017-bef4cbcf4b
manifest-tool-0.6.0-3.gita28af2b.fc25 has been pushed to the Fedora 25 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-2017-b093304055
manifest-tool-0.6.0-3.gita28af2b.fc26 has been pushed to the Fedora 26 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-2017-38e46e1e68
manifest-tool-0.6.0-3.gita28af2b.fc26 has been pushed to the Fedora 26 stable repository. If problems still persist, please make note of it in this bug report.
manifest-tool-0.6.0-3.gita28af2b.fc25 has been pushed to the Fedora 25 stable repository. If problems still persist, please make note of it in this bug report.
manifest-tool-0.6.0-4.gita28af2b.el7 has been pushed to the Fedora EPEL 7 stable repository. If problems still persist, please make note of it in this bug report.