Spec URL: http://oirase.annexia.org/reviews/libnbd/libnbd.spec SRPM URL: http://oirase.annexia.org/reviews/libnbd/libnbd-0.1-1.fc30.src.rpm Description: NBD client library in userspace Fedora Account System Username: rjones
rpmlint says: libnbd.x86_64: W: spelling-error %description -l en_US multithreaded -> multicolored - rpmlint is wrong libnbd.x86_64: W: crypto-policy-non-compliance-gnutls-1 /usr/lib64/libnbd.so.0.0.0 gnutls_priority_set_direct - I think this is fine, but I asked about it on fedora-devel: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/IGQQHBP56DY5W5G7BKSYDIECNPF3YC73/ python3-libnbd.x86_64: W: private-shared-object-provides /usr/lib64/python3.7/site-packages/libnbdmod.cpython-37m-x86_64-linux-gnu.so libnbdmod.cpython-37m-x86_64-linux-gnu.so()(64bit) - no idea about this one python3-libnbd.x86_64: W: no-documentation python3-libnbd.x86_64: W: no-manual-page-for-binary nbdsh - These are correct. We intend to add documentation upstream soon. libnbd.src: W: spelling-error %description -l en_US multithreaded -> multicolored libnbd.src: W: strange-permission libnbd-0.1.tar.gz.sig 775 - not sure about this one 7 packages and 0 specfiles checked; 0 errors, 7 warnings.
Possibly the Python library should be called python3-nbd? I'm not sure.
Successful scratch build in F31: https://koji.fedoraproject.org/koji/taskinfo?taskID=35036198
I'll review this in exchange for gnatcoll-db, bug 1692166, if you think that's sufficiently similar in complexity.
Yup, I've got it thanks.
(In reply to Richard W.M. Jones from comment #1) > python3-libnbd.x86_64: W: private-shared-object-provides > /usr/lib64/python3.7/site-packages/libnbdmod.cpython-37m-x86_64-linux-gnu.so > libnbdmod.cpython-37m-x86_64-linux-gnu.so()(64bit) > > - no idea about this one It's a Python extension module that is called "lib..." and the RPM provides generator picks it up. You SHOULD filter it out, see https://docs.fedoraproject.org/en-US/packaging-guidelines/AutoProvidesAndRequiresFiltering/ Use something like (untested): %global __requires_exclude_from ^%{python3_sitearch}/lib.*\\.so > libnbd.src: W: strange-permission libnbd-0.1.tar.gz.sig 775 > > - not sure about this one I don't understand why a signature file has executable permissions.
(In reply to Richard W.M. Jones from comment #2) > Possibly the Python library should be called python3-nbd? I'm not sure. Please, don't. See https://pypi.org/project/nbd/
(In reply to Miro Hrončok from comment #6) > It's a Python extension module that is called "lib..." and the RPM provides > generator picks it up. > You SHOULD filter it out, see > https://docs.fedoraproject.org/en-US/packaging-guidelines/ > AutoProvidesAndRequiresFiltering/ > > Use something like (untested): > > %global __requires_exclude_from ^%{python3_sitearch}/lib.*\\.so Thanks for identifying this. In the final package as it was built in Koji: https://koji.fedoraproject.org/koji/taskinfo?taskID=35036199 I don't seem to see any "rogue" requires: $ wget https://kojipkgs.fedoraproject.org//work/tasks/6199/35036199/python3-libnbd-0.1-1.fc31.x86_64.rpm $ rpm -qRp ./python3-libnbd-0.1-1.fc31.x86_64.rpm /usr/bin/sh libc.so.6()(64bit) libc.so.6(GLIBC_2.14)(64bit) libc.so.6(GLIBC_2.2.5)(64bit) libc.so.6(GLIBC_2.4)(64bit) libgnutls.so.30()(64bit) libnbd(x86-64) = 0.1-1.fc31 libnbd.so.0()(64bit) python(abi) = 3.7 rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(FileDigests) <= 4.6.0-1 rpmlib(PartialHardlinkSets) <= 4.0.4-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 rpmlib(PayloadIsXz) <= 5.2-1 rtld(GNU_HASH) I can add the exclude anyway. Do you think the same could also apply to these packages, as they both have Python modules called lib<something>? https://koji.fedoraproject.org/koji/buildinfo?buildID=1260105 https://koji.fedoraproject.org/koji/buildinfo?buildID=1235402 > > libnbd.src: W: strange-permission libnbd-0.1.tar.gz.sig 775 > > > > - not sure about this one > > I don't understand why a signature file has executable permissions. > Please, don't. See https://pypi.org/project/nbd/ Heh, who knew :-) OK we'll leave it as libnbd.
> I don't understand why a signature file has executable permissions. Just an accident, will fix it in the next version.
I realize the message is talking about provides and not requires, and I can see the bogus provides: $ rpm -q --provides -p ../RPMS/x86_64/python3-libnbd-0.1-1.fc30.x86_64.rpm libnbdmod.cpython-37m-x86_64-linux-gnu.so()(64bit) <--------- python3-libnbd = 0.1-1.fc30 python3-libnbd(x86-64) = 0.1-1.fc30 I will filter this out in the next version.
Spec URL: http://oirase.annexia.org/reviews/libnbd/libnbd.spec SRPM URL: http://oirase.annexia.org/reviews/libnbd/libnbd-0.1-2.fc30.src.rpm * Sat May 25 2019 Richard W.M. Jones <rjones> - 0.1-2 - Filter Python provides. - Remove executable permission on the tar.gz.sig file. The new set of rpmlint warnings is: libnbd.x86_64: W: spelling-error %description -l en_US multithreaded -> multicolored libnbd.x86_64: W: crypto-policy-non-compliance-gnutls-1 /usr/lib64/libnbd.so.0.0.0 gnutls_priority_set_direct python3-libnbd.x86_64: W: no-documentation python3-libnbd.x86_64: W: no-manual-page-for-binary nbdsh libnbd.src: W: spelling-error %description -l en_US multithreaded -> multicolored 7 packages and 0 specfiles checked; 0 errors, 5 warnings.
FYI I have added a man page for nbdsh upstream: https://github.com/libguestfs/libnbd/commit/3e436bdc34a3644cfd9466d4c964ed29acedb1d3 This addresses one of the rpmlint issues. However I cannot backport it to 0.1 as it depends on a bunch of other changes. But it's something I can add to Fedora in the 0.2 release.
Yes, __requires_exclude_from was indeed supposed to be __provides_exclude_from
Some things I've found so far: · Please remove the condition around Source1 and Source2. Those files will be left out of the source package if verify_tarball_signature is turned off, and then that source package can't be rebuilt with verification enabled. I can't see that it will hurt to have the files present even if verification is disabled. · Would it be possible to provide a URL to the keyring? Use HTTPS if at all possible. Then anyone can verify that the keyring in the package is the same as upstream. (The build would of course still use the keyring in the Git repository.) · lib/nbd-protocol.h has a BSD license, so I think the license tag for the library becomes "LGPLv2+ and BSD". · The license tag of libnbd-devel should include the license of the examples. At the moment I'm not sure what to call that license. · There's an outdated FSF address in python/run-python-tests.in and python/t/*. Since you're the upstream author if I understand correctly, I think you should correct the address. The FSF seem to use a URL instead of a postal address nowadays.
> · Would it be possible to provide a URL to the keyring? Use HTTPS if at all possible. Then anyone can verify that the keyring in the package is the same as upstream. (The build would of course still use the keyring in the Git repository.) It's been on my to-do list for a long time to set up letsencrypt on http://libguestfs.org but I haven't got around to it yet. However in this case the key is available from your favourite GPG keyserver: https://pgp.key-server.io/pks/lookup?search=rjones%40redhat.com&fingerprint=on&op=vindex and you can verify it by doing: $ gpg2 -k --fingerprint --homedir=`pwd` --keyring=libguestfs.keyring Please ignore the revoked key at the first link. A few years ago to prove some point someone generated a bunch of keys of open source software developers with colliding 32 bit IDs. The correct key has fingerprint F777 4FB1 AD07 4A7E 8C87 67EA 9173 8F73 E1B7 68A0. > · lib/nbd-protocol.h has a BSD license, so I think the license tag for the library becomes "LGPLv2+ and BSD". I'm not clear if the License field refers to the source or the binary, but if it refers to the binary then the license is LGPLv2+, but if it's for the source then it's mixed as you say. > · The license tag of libnbd-devel should include the license of the examples. At the moment I'm not sure what to call that license. It's intended to be as close to public domain as possible. Will fix the other things and post a new link soon.
The license does refer to the binary, not the source: https://fedoraproject.org/wiki/Packaging:LicensingGuidelines#License:_field and I believe LGPLv2+ is correct for the binary lib*.so.* file, even though it uses a BSD-licensed header file as part of the build.
Spec URL: http://oirase.annexia.org/reviews/libnbd/libnbd.spec SRPM URL: http://oirase.annexia.org/reviews/libnbd/libnbd-0.1-3.fc30.src.rpm * Sun May 26 2019 Richard W.M. Jones <rjones> - 0.1-3 - Include the signature and keyring even if validation is disabled. - Update devel subpackage license. - Fix old FSF address in Python tests.
(In reply to Richard W.M. Jones from comment #15) > It's been on my to-do list for a long time to set up letsencrypt on > http://libguestfs.org > but I haven't got around to it yet. However in this case the key is > available from > your favourite GPG keyserver: It's nice that the key is on the keyservers but that's not an authoritative source. A keyring on an HTTPS server under the control of the authors allows anyone to determine with a high degree of confidence that that is the correct key. Anyway, that's not a blocker. (In reply to Richard W.M. Jones from comment #16) > The license does refer to the binary, not the source: > > https://fedoraproject.org/wiki/Packaging:LicensingGuidelines#License:_field > > and I believe LGPLv2+ is correct for the binary lib*.so.* file, even though > it uses a BSD-licensed header file as part of the build. You may be right. I was thinking this was a "mixed source licensing scenario" but it's not entirely clear to me which license combinations that applies to: https://docs.fedoraproject.org/en-US/packaging-guidelines/LicensingGuidelines/#_mixed_source_licensing_scenario
Issues to be resolved ===================== · The man pages are BSD-licensed, so BSD must be mentioned in the license tag of libnbd-devel. At least in this case the LGPL does not apply to the BSD-licensed files. · I'm awaiting your decision on a license for the examples. Do you want to use CC0 or 0BSD? (I don't see 0BSD in the list of good licenses by the way.) As I understand it you can call it Public Domain only if the files explicitly say "public domain": https://docs.fedoraproject.org/en-US/packaging-guidelines/LicensingGuidelines/#_public_domain · I still need to study how GnuTLS works to understand the situation with the crypto policy. I hope you'll get an answer on the devel list. Package Review ============== Legend: [x] = Pass, [!] = Fail, [-] = Not applicable, [?] = Not evaluated ===== MUST items ===== C/C++: [x]: Package does not contain kernel modules. [x]: Package contains no static executables. [x]: Development (unversioned) .so files in -devel subpackage, if present. Note: Unversioned so-files in private %_libdir subdirectory. → That's the Python module so that's correct. [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]: ldconfig not called in %post and %postun for Fedora 28 and later. [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. [!]: License field in the package spec file matches the actual license. Note: Checking patched sources after %prep for licenses. Licenses found: "Unknown or generated", "LGPL (v2)", "LGPL (v2 or later)", "MIT/X11 (BSD like)", "BSD (3 clause)", "GPL", "GPL (v2 or later)". 50 files have unknown license. → Files that go into the library are LGPLv2+ and BSD, which combine into LGPLv2+, so the main license tag is probably OK. The man pages are BSD, which must be mentioned in the license tag of libnbd-devel. The license of the examples remains to determine. GPL and various free and permissive licenses occur in helper files and tests, and don't affect the license tags. [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. → I haven't tested them in GDB but it looks like the expected files are present. [x]: Package is not known to require an ExcludeArch tag. → The scratch build worked on all six arches. [x]: Large documentation must go in a -doc subpackage. Large could be size (~1MB) or number of files. Note: Documentation size is 40960 bytes in 6 files. → That's not large in my opinion. [!]: Package complies to the Packaging Guidelines → no problems other than the licensing and possibly the crypto policy [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 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: [-]: Python eggs must not download any dependencies during the build process. [-]: A package which is used by another package via an egg interface should provide egg info. → no eggs [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 [-]: 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). [x]: Fully versioned dependency in subpackages if applicable. [?]: Package functions as described. → I don't have the means to try it with a reasonable amount of work. [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. [x]: Description and summary sections in the package spec file contains translations for supported Non-English languages, if available. → No other languages are available as far as I know. [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]: Uses parallel make %{?_smp_mflags} macro. → make_build isn't used but _smp_mflags is, so that's OK. [x]: The placement of pkgconfig(.pc) files are correct. [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: libnbd-0.1-3.fc31.x86_64.rpm libnbd-devel-0.1-3.fc31.x86_64.rpm python3-libnbd-0.1-3.fc31.x86_64.rpm libnbd-debuginfo-0.1-3.fc31.x86_64.rpm libnbd-debugsource-0.1-3.fc31.x86_64.rpm libnbd-0.1-3.fc31.src.rpm libnbd.x86_64: W: spelling-error %description -l en_US multithreaded -> multicolored libnbd.x86_64: W: crypto-policy-non-compliance-gnutls-1 /usr/lib64/libnbd.so.0.0.0 gnutls_priority_set_direct python3-libnbd.x86_64: W: no-documentation python3-libnbd.x86_64: W: no-manual-page-for-binary nbdsh libnbd.src: W: spelling-error %description -l en_US multithreaded -> multicolored 6 packages and 0 specfiles checked; 0 errors, 5 warnings. Rpmlint (debuginfo) ------------------- Checking: libnbd-debuginfo-0.1-3.fc31.x86_64.rpm 1 packages and 0 specfiles checked; 0 errors, 0 warnings. Rpmlint (installed packages) ---------------------------- python3-libnbd.x86_64: W: no-documentation python3-libnbd.x86_64: W: no-manual-page-for-binary nbdsh → I understand that the next release will include a man page. That's satisfactory. libnbd.x86_64: W: spelling-error %description -l en_US multithreaded -> multicolored → Ignore. libnbd.x86_64: W: crypto-policy-non-compliance-gnutls-1 /usr/lib64/libnbd.so.0.0.0 gnutls_priority_set_direct → As I said, I need to study this more. 5 packages and 0 specfiles checked; 0 errors, 4 warnings. Requires -------- libnbd (rpmlib, GLIBC filtered): libc.so.6()(64bit) libgnutls.so.30()(64bit) libgnutls.so.30(GNUTLS_3_4)(64bit) libpthread.so.0()(64bit) rtld(GNU_HASH) libnbd-devel (rpmlib, GLIBC filtered): /usr/bin/pkg-config libnbd(x86-64) libnbd.so.0()(64bit) python3-libnbd (rpmlib, GLIBC filtered): /usr/bin/sh libc.so.6()(64bit) libgnutls.so.30()(64bit) libnbd(x86-64) libnbd.so.0()(64bit) python(abi) rtld(GNU_HASH) libnbd-debuginfo (rpmlib, GLIBC filtered): libnbd-debugsource (rpmlib, GLIBC filtered): Provides -------- libnbd: libnbd libnbd(x86-64) libnbd.so.0()(64bit) libnbd-devel: libnbd-devel libnbd-devel(x86-64) pkgconfig(libnbd) python3-libnbd: python3-libnbd python3-libnbd(x86-64) libnbd-debuginfo: debuginfo(build-id) libnbd-debuginfo libnbd-debuginfo(x86-64) libnbd-debugsource: libnbd-debugsource libnbd-debugsource(x86-64)
(In reply to Björn Persson from comment #19) > Issues to be resolved > ===================== > > · The man pages are BSD-licensed, so BSD must be mentioned in the license > tag of libnbd-devel. At least in this case the LGPL does not apply to the > BSD-licensed files. Damn, this is a mistake. The man pages are supposed to contain the LGPLv2+ blurb. I have fixed this upstream now: https://github.com/libguestfs/libnbd/commit/8b6e4ccda1a51cd840bb47a3f12e0b4000788130 > · I'm awaiting your decision on a license for the examples. Do you want to > use CC0 or 0BSD? (I don't see 0BSD in the list of good licenses by the way.) > As I understand it you can call it Public Domain only if the files > explicitly say "public domain": > https://docs.fedoraproject.org/en-US/packaging-guidelines/ > LicensingGuidelines/#_public_domain I had an email back from Richard Fontana saying that CC0 is no longer recommended (it doesn't contain a patent grant). https://lists.fedoraproject.org/archives/list/legal@lists.fedoraproject.org/thread/JR53JW52OKOL2S6O27NMNMO5SIM356X6/ As I'm familiar with the simple BSD license that we used for nbdkit, I will use that for the examples: https://github.com/libguestfs/libnbd/commit/e498c3b16f6acb70f5768fe6d508aa986fb3ba63 > · I still need to study how GnuTLS works to understand the situation with > the crypto policy. I hope you'll get an answer on the devel list. I'm pretty certain what we're doing is correct, as this is how libvirt has worked and they changed to this after discussions with the GnuTLS maintainer. As there are a number of upstream changes required, I'm going to do a 0.1.1 release upstream and post another package.
Spec URL: http://oirase.annexia.org/reviews/libnbd/libnbd.spec SRPM URL: http://oirase.annexia.org/reviews/libnbd/libnbd-0.1.1-1.fc30.src.rpm - Fix license in man pages and examples. - Add nbdsh(1) man page. Scratch build: https://koji.fedoraproject.org/koji/taskinfo?taskID=35103991
Here's the positive answer about the GnuTLS warning: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/IGQQHBP56DY5W5G7BKSYDIECNPF3YC73/
I believe I now understand the crypto policy. The system-wide policy is in effect by default, but the sysadmin can override it specifically for programs that use libnbd by creating a file named /etc/crypto-policies/local.d/gnutls-*.config with a line that begins with "LIBNBD=", and then running update-crypto-policies. This is quite reasonable. The licensing issues have been resolved in version 0.1.1. This package is APPROVED.
That's right. I basically copied the idea from libvirt where it works like this: https://www.berrange.com/posts/2016/11/15/new-tls-algorithm-priority-config-for-libvirt-with-gnutls-on-fedora-25/ Thanks for taking the time to carefully review this package.
Crap, how did I manage to change the review flag? That was accidental, and I've set it back to "+" based on the review in comment 23.
Sorry about this - apparently the repo can't be created if the fedora-review+ flag is set by the same person who opened the bug. Would it be possible for you to set the fedora-review+ flag again?
(fedscm-admin): The Pagure repository was created at https://src.fedoraproject.org/rpms/libnbd
FEDORA-2019-c29b9bbf0d has been submitted as an update to Fedora 30. https://bodhi.fedoraproject.org/updates/FEDORA-2019-c29b9bbf0d
FEDORA-2019-dd6247f38d has been submitted as an update to Fedora 29. https://bodhi.fedoraproject.org/updates/FEDORA-2019-dd6247f38d
libnbd-0.1.1-1.fc30 has been pushed to the Fedora 30 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-2019-c29b9bbf0d
libnbd-0.1.1-1.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-2019-dd6247f38d
FEDORA-2019-8dfd404323 has been submitted as an update to Fedora 30. https://bodhi.fedoraproject.org/updates/FEDORA-2019-8dfd404323
FEDORA-2019-a40e08c4c6 has been submitted as an update to Fedora 29. https://bodhi.fedoraproject.org/updates/FEDORA-2019-a40e08c4c6
libnbd-0.1.2-1.fc30 has been pushed to the Fedora 30 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-2019-8dfd404323
libnbd-0.1.2-1.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-2019-a40e08c4c6
FEDORA-2019-8cd668c9ac has been submitted as an update to Fedora 30. https://bodhi.fedoraproject.org/updates/FEDORA-2019-8cd668c9ac
FEDORA-2019-ee6a08797a has been submitted as an update to Fedora 29. https://bodhi.fedoraproject.org/updates/FEDORA-2019-ee6a08797a
libnbd-0.1.2-2.fc30 has been pushed to the Fedora 30 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-2019-8cd668c9ac
libnbd-0.1.2-2.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-2019-ee6a08797a
FEDORA-2019-962710433b has been submitted as an update to Fedora 30. https://bodhi.fedoraproject.org/updates/FEDORA-2019-962710433b
FEDORA-2019-9bd8df2659 has been submitted as an update to Fedora 29. https://bodhi.fedoraproject.org/updates/FEDORA-2019-9bd8df2659
libnbd-0.1.4-1.fc30 has been pushed to the Fedora 30 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-2019-962710433b
libnbd-0.1.4-1.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-2019-9bd8df2659
libnbd-0.1.4-1.fc30 has been pushed to the Fedora 30 stable repository. If problems still persist, please make note of it in this bug report.
libnbd-0.1.4-1.fc29 has been pushed to the Fedora 29 stable repository. If problems still persist, please make note of it in this bug report.