Spec URL: https://download.copr.fedorainfracloud.org/results/noon/python-opentracing/fedora-rawhide-x86_64/01839008-python-opentracing/python-opentracing.spec SRPM URL: https://download.copr.fedorainfracloud.org/results/noon/python-opentracing/fedora-rawhide-x86_64/01839008-python-opentracing/python-opentracing-2.4.0-1.fc34.src.rpm Description: This library is a Python platform API for OpenTracing. It allows Python programs to interact with an OpenTracing server. Fedora Account System Username: noon
Hello, This is my first package: I need a sponsor. Could you please help me? It passes on koji: https://koji.fedoraproject.org/koji/taskinfo?taskID=57670863 Thanks in advance. Best regards Fabrice
Hello, I have improved the spec. Here are updated links: - Spec: https://download.copr.fedorainfracloud.org/results/noon/python-opentracing/fedora-rawhide-x86_64/01881290-python-opentracing/python-opentracing.spec - SRPM: https://download.copr.fedorainfracloud.org/results/noon/python-opentracing/fedora-rawhide-x86_64/01881290-python-opentracing/python-opentracing-2.4.0-1.fc34.src.rpm - Koji build: https://koji.fedoraproject.org/koji/taskinfo?taskID=59796679 Description: This library is a Python platform API for OpenTracing. It allows Python programs to interact with any OpenTracing-compliant server such as JaegerTracer. This is my first Fedora package. Could anybody please sponsor it? Thanks a lot! Best regards Fabrice
This is a great start! Some preliminary notes: ----- You do not need: # This is to avoid this error: # error: Empty %%files file /builddir/build/BUILD/opentracing-python-2.4.0/debugsourcefiles.list %global debug_package %{nil} Instead, since there is nothing architecture-specific (such as compiled extensions) in this package, add BuildArch: noarch to the top-level package “python-opentracing“; you may then remove it from the subpackages. ----- Unless you are planning to build for EPEL with the same spec file, Python dependencies are best written like: BuildRequires: python3dist(setuptools) rather than BuildRequires: python3-setuptools See https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/#_automatic_provides_with_a_standardized_name. ----- You can use https://src.fedoraproject.org/rpms/pyproject-rpm-macros to generate the BuildRequires for you. See https://src.fedoraproject.org/rpms/python-junit_xml/blob/rawhide/f/python-junit_xml.spec for a Python package I maintain that uses the full suite of macros. Using these macros is not mandatory, but it is very helpful and highly recommended. ----- All of this: Requires(post): info Requires(preun): info %post -n python3-opentracing /sbin/install-info %{_infodir}/%{pypi_name}.info %{_infodir}/dir || : %preun -n python3-opentracing if [ $1 = 0 ] ; then /sbin/install-info --delete %{_infodir}/%{pypi_name}.info %{_infodir}/dir || : fi is now handled by path triggers and is obsolete. Packaging has gotten a lot simpler in some ways since RHEL5–6. ----- I don’t think this is yet in the guidelines, but make is no longer in the buildroot, so you will need to add BuildRequires: make ----- Change cp docs/_build/texinfo/%{pypi_name}.info %{buildroot}%{_infodir}/ to cp -p docs/_build/texinfo/%{pypi_name}.info %{buildroot}%{_infodir}/ to preserve timestamps. ----- Change %{_infodir}/%{pypi_name}.info.gz to %{_infodir}/%{pypi_name}.info* to accommodate possible changes in info page compression. ----- Consider replacing %{__make} -C docs info PYTHONPATH=.. with %make_build -C docs info PYTHONPATH=.. ----- Consider also building the HTML documentation (just add the html target when you build the info page) and providing it in a -doc subpackage. ----- Some files are under an MIT license instead of the overall ASL 2.0 license. You must follow https://docs.fedoraproject.org/en-US/packaging-guidelines/LicensingGuidelines/#_multiple_licensing_scenarios. You can use “licensecheck” to help you find these files. ----- Consider running the “fedora-review” tool yourself to see what a reviewer will be a starting with. (I did not use it on this package yet because it would not build due to the missing make BR.) -----
Thanks for your review, it is very helpful and gives me lots of pointers for my next iteration. I was wondering why I had so much trouble finding how to register info files... Now I understand: it's implicit ;) Concerning EPEL, this is not the target of this submission, but I will certainly try to make an EPEL8 package if and when this one succeeds. As far as I understood, in Fedora this is done by creating a specific branch, so I'll put changes like "python3-setuptools" in that branch. %pyproject_buildrequires -x tests is indeed helpful, however it finds more BuildRequires than I think necessary; in particular it requires the PyPI packages doubles and flake8-quotes: - doubles is not used in the code (no import whatsoever), I guess upstream intends to use it in the future - flake8-quotes aims at forcing the use of e.g. single quotes in Python None of these two seem to exist as Fedora packages. So I think I'll stick to a manual list of BuildRequires... Thanks to your review, I've learned about fedora-review. After corrections from your input, it still complains about two particular things: a deprecated package, and Info documentation. Package must not depend on deprecated() packages. Note: python3-mock is deprecated, you must not depend on it. See: https://docs.fedoraproject.org/en-US/packaging-guidelines/deprecating-packages/. I'm pushing upstream to remove the dependency when Py3.3+ is there. See issue https://github.com/opentracing/opentracing-python/issues/142 and associated PR. Depending on upstream's reactivity, I might add a patch to the package. Texinfo files are installed using install-info in %post and %preun if package has .info files. Note: Texinfo .info file(s) in python3-opentracing See: https://docs.fedoraproject.org/en-US/packaging-guidelines/Scriptlets/#_texinfo Maybe this is not relevant: the link anchor is not found, and you told me to remove the post/preun that I originally put...
Updated links: - Spec: https://download.copr.fedorainfracloud.org/results/noon/python-opentracing/fedora-rawhide-x86_64/02010882-python-opentracing/python-opentracing.spec - SRPM: https://download.copr.fedorainfracloud.org/results/noon/python-opentracing/fedora-rawhide-x86_64/02010882-python-opentracing/python-opentracing-2.4.0-1.fc35.src.rpm - Koji build: https://koji.fedoraproject.org/koji/taskinfo?taskID=62394500 Thanks!
> I was wondering why I had so much trouble finding how to register info files... Now I understand: it's implicit ;) It’s frustrating how hard it is to track changes in required scriptlets in Fedora. Sometimes there is a “Change” you can point to, like https://fedoraproject.org/wiki/Changes/Removing_ldconfig_scriptlets, but sometimes there isn’t. You can see that it was a couple of years ago that the section about the texinfo scriptlets was removed from the Guidelines (https://pagure.io/packaging-committee/c/4485c124280cc138ba9f6cbda3b922a51ddd127e?branch=master). That history shows the scriptlets were last needed in Fedora 27. They were removed from the coreutils package, a major user of info pages, around the same time (https://src.fedoraproject.org/rpms/coreutils/c/9cc8a839e2dcb8ca42922452629941242f26150b?branch=rawhide, https://src.fedoraproject.org/rpms/coreutils/c/5decf6eab4c45e52d995f0223d9f9396fe09d821?branch=rawhide). And I can’t even point you to what it was that changed to make the scriptlets obsolete. Can you tell me exactly how to see the “link anchor” that is “not found”? If I know exactly what you’re talking about, maybe I can figure out what is going wrong. I do know that there are some rough edges in the documentation build. It’s trying to download intersphinx inventory 'https://docs.python.org/objects.inv' to cross-link against other packages’ documentation, and failing because package builds can’t access the network from mock or koji. There is also a problem importing opentracing.scope_managers.tornado because upstream is still not properly compatible with Tornado 6 and later: https://github.com/opentracing/opentracing-python/issues/136. This is not just a documentation problem, of course. > Concerning EPEL, this is not the target of this submission, but I will certainly try to make an EPEL8 package if and when this one succeeds. As far as I understood, in Fedora this is done by creating a specific branch, so I'll put changes like "python3-setuptools" in that branch. Some maintainers prefer “one true spec file” with conditionals for EPEL, while others prefer to let the branches diverge and keep the spec files cleaner. I sometimes do “one true spec file” when the differences are trivial, but more often find myself maintaining separate branches and cherry-picking commits as you intend to do, especially with Python packages where the RPM macro support has changed so much. > None of these two seem to exist as Fedora packages. So I think I'll stick to a manual list of BuildRequires... This is perfectly reasonable. I certainly wouldn’t package a linter plugin like flake8-quotes just for this purpose! Since %pyproject_buildrequires simply prints BR’s to stdout, you can filter them, e.g. %generate_buildrequires ( %pyproject_buildrequires -x tests ) | grep -vE 'doubles|flake8-quotes' or, more conventionally, patch setup.py to remove the unwanted BR’s. Any of these requires some attention during upstream updates, and falling back to manual BR’s is probably the simplest choice. > Thanks to your review, I've learned about fedora-review. After corrections from your input, it still complains about two particular things: a deprecated package, and Info documentation. Thanks for pushing the mock change upstream. This is the right thing to do (and I see your PR was accepted). Please link the upstream bug in a comment above your patch in the spec file (https://docs.fedoraproject.org/en-US/packaging-guidelines/PatchUpstreamStatus/). I believe the diagnostic on info pages is a fedora-review bug (like https://bugzilla.redhat.com/show_bug.cgi?id=1409315), and one of us should report it after we’re done here. > This is my first package: I need a sponsor. Unfortunately, it will be a couple more months until I am eligible to apply for sponsor status (https://fedoraproject.org/wiki/How_to_sponsor_a_new_contributor), so I can’t help out with this part in the short term.
Package Review ============== Legend: [x] = Pass, [!] = Fail, [-] = Not applicable, [?] = Not evaluated Issues: ======= - fedora-review says: Texinfo files are installed using install-info in %post and %preun if package has .info files. Note: Texinfo .info file(s) in python3-opentracing See: https://docs.fedoraproject.org/en-US/packaging- guidelines/Scriptlets/#_texinfo I believe this is a fedora-review bug. See https://pagure.io/packaging-committee/c/4485c124280cc138ba9f6cbda3b922a51ddd127e?branch=master, and particularly, from the removed documentation, “In Fedora 28 and newer, this is done automatically and no scriptlets are required.” Therefore, no change is required. - You can write %package -n python-opentracing-doc %description -n python-opentracing-doc %files -n python-opentracing-doc as %package doc %description doc %files doc and most packagers would. You are not required to change this, however. - The -doc subpackage can be installed on its own without a LICENSE file. Add “%license LICENSE” to the %files section for the -doc subpackage. See https://docs.fedoraproject.org/en-US/packaging-guidelines/LicensingGuidelines/#subpackage-licensing. - The patch needs a link to https://github.com/opentracing/opentracing-python/issues/142 in a comment above it. See https://docs.fedoraproject.org/en-US/packaging-guidelines/PatchUpstreamStatus/. ===== 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: Checking patched sources after %prep for licenses. Licenses found: "Unknown or generated", "*No copyright* Apache License 2.0", "*No copyright* Apache License", "Apache License 2.0", "Expat License". 70 files have unknown license. Detailed output of licensecheck in /home/reviewer/1908526-python- opentracing/licensecheck.txt [!]: License file installed when any subpackage combination is installed. No license file for -doc subpackage, which does not depend on any subpackage that contains it. [x]: If the package is under multiple licenses, the licensing breakdown must be documented in the spec. [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. [-]: 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]: Package is not known to require an ExcludeArch tag. [x]: Large documentation must go in a -doc subpackage. Large could be size (~1MB) or number of files. Note: Documentation size is 20480 bytes in 2 files. [x]: Package complies to the Packaging Guidelines (except as otherwise noted) [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: No rpmlint messages. [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 Python: [x]: Python eggs must not download any dependencies during the build process. [x]: A package which is used by another package via an egg interface should provide egg info. [x]: Package meets the Packaging Guidelines::Python [x]: Package contains BR: python2-devel or python3-devel [x]: Packages MUST NOT have dependencies (either build-time or runtime) on packages named with the unversioned python- prefix unless no properly versioned package exists. Dependencies on Python packages instead MUST use names beginning with python2- or python3- as appropriate. [x]: Python packages must not contain %{pythonX_site(lib|arch)}/* in %files [x]: Binary eggs must be removed in %prep ===== 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 python3-opentracing [x]: Package functions as described. Upstream bug https://github.com/opentracing/opentracing-python/issues/136 breaks part of the functionality, but there is no clear fix other than waiting for upstream, and the package appears otherwise usable. [x]: Latest version is packaged. [x]: Package does not include license text files separate from upstream. [!]: Patches link to upstream bugs/comments/lists or are otherwise justified. Add a link to the existing upstream bug report. [-]: 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. [x]: %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 all installed packages. Note: No rpmlint messages. [x]: Spec file according to URL is the same as in SRPM. Rpmlint ------- Checking: python3-opentracing-2.4.0-1.fc35.noarch.rpm python-opentracing-doc-2.4.0-1.fc35.noarch.rpm python-opentracing-2.4.0-1.fc35.src.rpm 3 packages and 0 specfiles checked; 0 errors, 0 warnings. Rpmlint (installed packages) ---------------------------- 2 packages and 0 specfiles checked; 0 errors, 0 warnings. Source checksums ---------------- https://github.com/opentracing/opentracing-python/archive/2.4.0.tar.gz : CHECKSUM(SHA256) this package : 55ee4afc1f58cdc7d6c40bcc7f51568099619c1ef2cb78ddfd5c2cff871a500d CHECKSUM(SHA256) upstream package : 55ee4afc1f58cdc7d6c40bcc7f51568099619c1ef2cb78ddfd5c2cff871a500d Requires -------- python3-opentracing (rpmlib, GLIBC filtered): python(abi) python-opentracing-doc (rpmlib, GLIBC filtered): Provides -------- python3-opentracing: python-opentracing python3-opentracing python3.9-opentracing python3.9dist(opentracing) python3dist(opentracing) python-opentracing-doc: python-opentracing-doc Generated by fedora-review 0.7.6 (b083f91) last change: 2020-11-10 Command line :/usr/bin/fedora-review -b 1908526 Buildroot used: fedora-rawhide-x86_64 Active plugins: Generic, Python, Shell-api Disabled plugins: Perl, Ruby, SugarActivity, C/C++, Ocaml, Haskell, fonts, PHP, R, Java Disabled flags: EPEL6, EPEL7, DISTTAG, BATCH, EXARCH
> Can you tell me exactly how to see the “link anchor” that is “not > found”? If I know exactly what you’re talking about, maybe I can > figure out what is going wrong. I mean in the output from fedora-review: Texinfo files are installed using install-info in %post and %preun if package has .info files. Note: Texinfo .info file(s) in python3-opentracing See: https://docs.fedoraproject.org/en-US/packaging-guidelines/Scriptlets/#_texinfo This URL has an anchor part (#_texinfo) which is not resolved inside the HTML page (because that section has been deleted, as you explained). I guess fedora-review should be updated to not suggest this anymore... So I've created this PR, which is now merged: https://pagure.io/FedoraReview/pull-request/412 Concerning the tornado issue: failed to import class 'tornado.TornadoScopeManager' from module 'opentracing.scope_managers'; the following exception was raised: No module named 'tornado.stack_context' > There is also a problem importing opentracing.scope_managers.tornado > because upstream is still not properly compatible with Tornado 6 and > later: https://github.com/opentracing/opentracing-python/issues/136. > This is not just a documentation problem, of course. In fact, depending on the versions of Python and of Tornado, some scope managers from OpenTracing can or can't be used. See https://github.com/opentracing/opentracing-python/pull/118 https://github.com/opentracing-contrib/python-tornado/pull/10 Basically, upstream's TornadoScopeManager is useful for contexts with a Tornado 4 or 5 based on gen.coroutine. With Tornado 5 or 6 based on async/await, the correct ScopeManager would rather be ContextVarsScopeManager. TornadoScopeManager cannot even be imported with Tornado 6. As long as upstream wants to support older Tornados based on gen.coroutine, they won't delete TornadoScopeManager. But that's basically a question for users of the opentracing library, who should make the correct choice. For building this package, the only impact is a few sphinx warnings. The error using sphinx seems to be some race condition due to the use of %make_build which inserts a -j12. I've removed it, and now it works correctly. I think I have now fixed all reported issues and remarks. The result is: Copr: https://copr.fedorainfracloud.org/coprs/noon/python-opentracing/build/2022866/ Koji: https://koji.fedoraproject.org/koji/taskinfo?taskID=62701779 Spec: https://download.copr.fedorainfracloud.org/results/noon/python-opentracing/fedora-rawhide-x86_64/02022866-python-opentracing/python-opentracing.spec SRPM: https://download.copr.fedorainfracloud.org/results/noon/python-opentracing/fedora-rawhide-x86_64/02022866-python-opentracing/python-opentracing-2.4.0-1.fc35.src.rpm
> So I've created this PR, which is now merged: Thank you! > Basically, upstream's TornadoScopeManager is useful for contexts with > a Tornado 4 or 5 based on gen.coroutine. With Tornado 5 or 6 based on > async/await, the correct ScopeManager would rather be > ContextVarsScopeManager. TornadoScopeManager cannot even be imported > with Tornado 6. As long as upstream wants to support older Tornados > based on gen.coroutine, they won't delete TornadoScopeManager. > > But that's basically a question for users of the opentracing library, > who should make the correct choice. For building this package, the > only impact is a few sphinx warnings. Makes sense. > The error using sphinx seems to be some race condition due to the use > of %make_build which inserts a -j12. I've removed it, and now it > works correctly. Non-parallel-safe Makefiles are frustrating. I’m glad you figured it out. You can also do # Makefile is not safe for parallel builds %make_build -j1 and the -j1 will override the previous -j#. Or, if no make invocations in the spec file are safe to parallelize, you can do %global _smp_mflags %{nil} What you did is fine, though. > I think I have now fixed all reported issues and remarks. I agree! Approved, with full re-review below. Good luck finding a sponsor. I have blocked the FE-NEEDSPONSOR bug to bring attention to this review. In the unlikely case you’re still looking for a sponsor in a couple of months, feel free to contact me. I should be able to successfully apply for sponsor status then, and would be happy to sponsor you at that time based on this review alone. Package Review ============== Legend: [x] = Pass, [!] = Fail, [-] = Not applicable, [?] = Not evaluated Issues: ======= - Texinfo files are installed using install-info in %post and %preun if package has .info files. Note: Texinfo .info file(s) in python3-opentracing See: https://docs.fedoraproject.org/en-US/packaging- guidelines/Scriptlets/#_texinfo This is a fedora-review bug, fixed by a PR from the submitter (thanks!) ===== 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: Checking patched sources after %prep for licenses. Licenses found: "Unknown or generated", "*No copyright* Apache License 2.0", "*No copyright* Apache License", "Apache License 2.0", "Expat License". 70 files have unknown license. Detailed output of licensecheck in /home/reviewer/1908526-python- opentracing/20210226/1908526-python-opentracing/licensecheck.txt [x]: License file installed when any subpackage combination is installed. [x]: If the package is under multiple licenses, the licensing breakdown must be documented in the spec. [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. [-]: 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]: Package is not known to require an ExcludeArch tag. [x]: Large documentation must go in a -doc subpackage. Large could be size (~1MB) or number of files. Note: Documentation size is 20480 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: No rpmlint messages. [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 Python: [x]: Python eggs must not download any dependencies during the build process. [x]: A package which is used by another package via an egg interface should provide egg info. [x]: Package meets the Packaging Guidelines::Python [x]: Package contains BR: python2-devel or python3-devel [x]: Packages MUST NOT have dependencies (either build-time or runtime) on packages named with the unversioned python- prefix unless no properly versioned package exists. Dependencies on Python packages instead MUST use names beginning with python2- or python3- as appropriate. [x]: Python packages must not contain %{pythonX_site(lib|arch)}/* in %files [x]: Binary eggs must be removed in %prep ===== 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 python3-opentracing [x]: Package functions as described. [x]: Latest version is packaged. [x]: Package does not include license text files separate from upstream. [x]: Patches link to upstream bugs/comments/lists or are otherwise justified. [-]: 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. [x]: %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 all installed packages. Note: No rpmlint messages. [x]: Spec file according to URL is the same as in SRPM. Rpmlint ------- Checking: python3-opentracing-2.4.0-1.fc35.noarch.rpm python-opentracing-doc-2.4.0-1.fc35.noarch.rpm python-opentracing-2.4.0-1.fc35.src.rpm 3 packages and 0 specfiles checked; 0 errors, 0 warnings. Rpmlint (installed packages) ---------------------------- 2 packages and 0 specfiles checked; 0 errors, 0 warnings. Source checksums ---------------- https://github.com/opentracing/opentracing-python/archive/2.4.0.tar.gz : CHECKSUM(SHA256) this package : 55ee4afc1f58cdc7d6c40bcc7f51568099619c1ef2cb78ddfd5c2cff871a500d CHECKSUM(SHA256) upstream package : 55ee4afc1f58cdc7d6c40bcc7f51568099619c1ef2cb78ddfd5c2cff871a500d Requires -------- python3-opentracing (rpmlib, GLIBC filtered): python(abi) python-opentracing-doc (rpmlib, GLIBC filtered): Provides -------- python3-opentracing: python-opentracing python3-opentracing python3.9-opentracing python3.9dist(opentracing) python3dist(opentracing) python-opentracing-doc: python-opentracing-doc Generated by fedora-review 0.7.6 (b083f91) last change: 2020-11-10 Command line :/usr/bin/fedora-review -b 1908526 Buildroot used: fedora-rawhide-x86_64 Active plugins: Shell-api, Python, Generic Disabled plugins: SugarActivity, fonts, PHP, Haskell, C/C++, R, Perl, Java, Ocaml, Ruby Disabled flags: EPEL6, EPEL7, DISTTAG, BATCH, EXARCH
As I have sponsored you into the packager group, you should be able to import this package into dist-git. Please let me know if you have any questions about the process.
Oops, it looks like this has waited too much: $ fedpkg request-repo python-opentracing 1908526 Could not execute request_repo: The Bugzilla bug's review was approved over 60 days ago What would be the best course of action in this situation? Is it possible to approve again? Sorry and thanks for any help! Best regards Fabrice
There hasn’t been a new upstream release since the original review, and nothing else has changed, so I will just toggle the fedora-review flag to indicated that the approval is still current.
There, now you should be able to request a repo.
Thanks! Requests created: Request for a repository: https://pagure.io/releng/fedora-scm-requests/issue/35322 Request for branch fc33: https://pagure.io/releng/fedora-scm-requests/issue/35317 Request for branch fc34: https://pagure.io/releng/fedora-scm-requests/issue/35316
(fedscm-admin): The Pagure repository was created at https://src.fedoraproject.org/rpms/python-opentracing
Builds for f33, f34 and f35 successful. Closing this bug as per step 12 of https://fedoraproject.org/wiki/New_package_process_for_existing_contributors .
Note that packages built for Rawhide are automatically submitted as updates, but for stable releases, you must manually create the update for each build. Use “fedpkg update” or the Bodhi web interface (https://bodhi.fedoraproject.org/updates/?packages=python-opentracing). You can associate these updates with bugs and auto-close them on stable, which is a common way to handle closing a package review bug. (Closing manually is fine too.) It’s possible to associate Rawhide builds with bugs too (https://bodhi.fedoraproject.org/docs/user/automatic_updates.html#associate-bugs-to-automatic-updates) but it’s my understanding that this won’t auto-close package review bugs, although it works in general. Please let me know if you have any questions.
Have you tried creating the Bodhi updates for F34 and F33 yet? Let me know if the process isn’t clear.
I have added this package to release-monitoring.org (anitya) so you can be notified of new upstream versions via automatically-created Red Hat Bugzilla issues: https://release-monitoring.org/project/221583/
Concerning the submission to rawhide, looking at step 12 of https://fedoraproject.org/wiki/New_package_process_for_existing_contributors , I am not clear which Resolution I should choose for the closure of a bug such as this one. I have chosen Resolution: RAWHIDE, but Resolution: NEXTRELEASE seems just as good, I'm unsure about the difference. Maybe I haven't yet stumbled upon the doc that explains it. I'm currently trying to learn a lot about the updates system and procedures and bodhi and so on, which I'm not familiar with. To submit an update for f34 or f33, it looks like I have to prepare a test case that will allow testers to try and see that python-opentracing works, correct? It might be quite involving, users would have to spawn a container with a jaegertracing server, run some test Python program and see things happening in the jaegertracing web UI... This might take some time until I can finally submit updates for f33/f34 or even epel8. When you say that I can associate the updates with bugs, do you mean with this bug? Or should I create new bugs, one for each update? I didn't know about anitya, it looks neat, it reminds me of debian's "uscan" facility but with a web UI. Thanks!
> Concerning the submission to rawhide, looking at step 12 of https://fedoraproject.org/wiki/New_package_process_for_existing_contributors , I am not clear which Resolution I should choose for the closure of a bug such as this one. I have chosen Resolution: RAWHIDE, but Resolution: NEXTRELEASE seems just as good, I'm unsure about the difference. Maybe I haven't yet stumbled upon the doc that explains it. I don’t think it matters much. RAWHIDE is common for manual closure of a review request. If you associate the bug with a “newpackage” update for a stable release and have it auto-close it, then it will look like this: https://bugzilla.redhat.com/show_bug.cgi?id=1974821 ----- > To submit an update for f34 or f33, it looks like I have to prepare a test case that will allow testers to try and see that python-opentracing works, correct? It might be quite involving, users would have to spawn a container with a jaegertracing server, run some test Python program and see things happening in the jaegertracing web UI... This might take some time until I can finally submit updates for f33/f34 or even epel8. You can do this. It is “recommended.” (https://docs.fedoraproject.org/en-US/fesco/Package_maintainer_responsibilities/#_work_with_testing) As far as I can tell, test cases belong here (https://fedoraproject.org/wiki/Category:Test_Cases), and the procedures for creating test cases and test plans are linked from that page. In practice, you can see that there are roughly 130 packages on that page, out of over 30 thousand packages in Fedora. Few packagers make these test cases, and most of the time you’ll never see anyone testing your updates anyway. You can also set up automated tests for your package (https://docs.fedoraproject.org/en-US/ci/). This is a great idea, but there’s a nontrivial learning curve and a lot of YAML to write, so it isn’t mandatory either. In practice, most packages have neither wiki test cases nor manually-configured CI gating, and that’s unlikely to change. ----- So here are the steps for using Bodhi, which you’ve probably already read: https://fedoraproject.org/wiki/Package_update_HOWTO#Later_Branched_and_stable_releases. Basically, the workflow for an update to a stable release goes like this: 1. If it’s a newpackage update, go ahead to the next step. If it’s a bugfix or enhancement update, consider if it contains any breaking API changes (or, for compiled libraries, ABI changes). For a tool or application, consider if it contains significant changes to the user experience. If so, the update shouldn’t go in a stable release. If there is a good reason to break this rule (for example, a security fix that can’t be backported), you should petition FESCo (Fedora Engineering Steering Council) for an exception. You’ll probably never have to do that. 2. OK, it’s a newpackage update, or a compatible patch or minor update. You’ve merged changes into the appropriate stable branch (“git merge rawhide”, or “git cherry-pick …”, depending on how you like to manage your branches). You’ve pushed to the branch and built the package. (I know you’ve gotten this far.) Now you can choose to use the Bodhi CLI, which is most easily accessed as “fedpkg update”, or the web interface at https://bodhi.fedoraproject.org/updates/new. The fields are pretty much the same for both. 3. If you are using the CLI, you already have a build associated with the update. If you are using the web interface, find the package you built. You should create separate updates for separate branches, i.e., one for F34 and one for F33. 4. Type a quick description of what has changed. This is for the benefit of end-users, so keep it simple and informative. When the update provides a new version, copying in the upstream changelog can be nice, if there is a useful one. For the initial newpackage update, you can just write something like “Initial package”. 5. Pick an update type. These are pretty self-explanatory. This time you’ll want “newpackage”. 6. You can leave severity unspecified except for security updates. You can leave suggestion unspecified unless there’s some reason you think users should logout or reboot after the update. That mostly applies to libraries likely to be used by the desktop session or by various daemons, especially when the update is a security one. 7. You can associate one or more bugs with the update. For a newpackage update, it’s nice to associate the review request issue (this bug). For an enhancement or bugfix update, there might or might not be a bug corresponding to an issue that’s fixed in the update, or a “new release is available” bug filed by upstream release monitoring (anitya). You usually do want to enable “close bugs” so that the status of the bug follows the update’s progress into testing and then stable. There is no requirement to have a bug for an update, even for a “bugfix” update. 8. You almost always want to disable “require bugs.” It’s very likely that nobody will ever test your package, so your update will sit in testing forever if you leave this enabled. 9. You should usually use the default karma and time settings. The minimums are 3/-3 karma and 7 days. This means that, normally, your package will sit in testing for a week and then get automatically pushed to stable. If you manage to attract three testers, and they all report the update is OK, then it will get pushed to stable early. ----- Does that make more sense? If something is still not clear, please keep asking questions!
FEDORA-2021-3ba59e70fe has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2021-3ba59e70fe
FEDORA-2021-96886b4471 has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2021-96886b4471
Thank you very much, your explanations helped me a lot!
FEDORA-2021-3ba59e70fe has been pushed to the Fedora 33 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf install --enablerepo=updates-testing --advisory=FEDORA-2021-3ba59e70fe \*` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-3ba59e70fe See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2021-96886b4471 has been pushed to the Fedora 34 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf install --enablerepo=updates-testing --advisory=FEDORA-2021-96886b4471 \*` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-96886b4471 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-EPEL-2021-e8351e0d65 has been submitted as an update to Fedora EPEL 8. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-e8351e0d65
FEDORA-EPEL-2021-e8351e0d65 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-2021-e8351e0d65 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2021-3ba59e70fe has been pushed to the Fedora 33 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2021-96886b4471 has been pushed to the Fedora 34 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-EPEL-2021-e8351e0d65 has been pushed to the Fedora EPEL 8 stable repository. If problem still persists, please make note of it in this bug report.