Following the review of reprotest (https://bugzilla.redhat.com/show_bug.cgi?id=1924918) and its dependencies, I open a separate ticket for disorderfs: - Description: FUSE filesystem that introduces non-determinism - GIT: https://github.com/fepitre/fedora-disorderfs - SPEC: https://raw.githubusercontent.com/fepitre/fedora-disorderfs/master/disorderfs.spec - SRPM: https://download.copr.fedorainfracloud.org/results/fepitre/fedora/fedora-rawhide-x86_64/01945458-disorderfs/disorderfs-0.5.10-2.fc34.src.rpm With respect to the original version provided in https://bugzilla.redhat.com/show_bug.cgi?id=1924918, I've took into account the review comments and updated the spec and rebuilt the package.
> %{_datadir}/man/man1/disorderfs.1.gz → %{_datadir}/man/man1/disorderfs.1* (We might want to change the default compression alg at some point.) Maybe update to 0.5.11? Are the tags under https://reproducible-builds.org/_lfs/releases/disorderfs/ reliable? If yes, then we'd want to have signature verification as described in https://docs.fedoraproject.org/en-US/packaging-guidelines/#_source_file_verification > %doc README The README has no useful information. Maybe do '%doc NEWS' instead? + package name is OK + latest version (almost ;)) + license is acceptable for Fedora (GPLv3+) + license is specified correctly + builds fine in mock + B/R/PR seem to be specified correctly + fedora-review and rpmlint find no issues
(In reply to Zbigniew Jędrzejewski-Szmek from comment #1) > > %{_datadir}/man/man1/disorderfs.1.gz > → %{_datadir}/man/man1/disorderfs.1* > (We might want to change the default compression alg at some point.) Fixed. > Maybe update to 0.5.11? I've updated the version. > Are the tags under https://reproducible-builds.org/_lfs/releases/disorderfs/ > reliable? > If yes, then we'd want to have signature verification as described in > https://docs.fedoraproject.org/en-US/packaging-guidelines/ > #_source_file_verification Yes they are, notably I've reviewed it with upstream and also ask them to publish the keyring. I've updated the code accordingly the guidelines. I've added the keyring hash into "sources" file too. Should I add it into the git repo too? > > %doc README > The README has no useful information. > Maybe do '%doc NEWS' instead? NEWS is older and looks like some kind of changelog. I propose you to help upstream in updating the current README for which they refer to https://salsa.debian.org/reproducible-builds/disorderfs/-/blob/master/disorderfs.1.txt for information but few useful info can be extracted to the README. What do you think?
> Yes they are, notably I've reviewed it with upstream and also ask them to publish the keyring. I've updated the code accordingly the guidelines. > I've added the keyring hash into "sources" file too. Should I add it into the git repo too? The docs say: - Any detached signature file (e.g. foo.tar.gz.asc or foo.tar.gz.sig) must be uploaded to the package lookaside cache alongside the source code, while the keyring must be committed directly to the package SCM. So the keyring should *not* be in 'sources' file. > NEWS is older and looks like some kind of changelog. Ack. > I propose you to help upstream in updating the current README Well, the debian upstream does have a problem with good NEWS files. I'm annoyed by the changelog in diffoscope: it's better than nothing, but it's full of debian-only bits, information about individual commits and their reverts, etc. The only thing that is useful for the user (or a non-developer packager) is a file that list big high-level user-visible changes. So even stuff like a major refactoring or new tests that have no user-visible impact should not be mentioned, except maybe if it results in a massive efficiency change. But to create this kind of file, a really good understanding of what was happening in the repo is needed. I.e. I think it only makes sense to let the main developers do this. In my experience, even a semi-frequent contributor, who didn't look at every patch as it came in, would have a hard trouble putting this file together correctly. Continuing from https://bugzilla.redhat.com/show_bug.cgi?id=1925759#c1: + package name is OK + latest version + license is acceptable for Fedora (GPLv3+) + license is specified correctly + builds fine in mock + B/R/PR seem to be specified correctly + fedora-review and rpmlint find no issues Package is APPROVED. -- I'll add you to the packagers group. Please consider changing your settings in fas to non-private, so that other people can see your real name. (It can be guessed from the email anyway…) You will need to use 'fedpkg request-repo' and then 'fedpkg import', etc. See https://fedoraproject.org/wiki/New_package_process_for_existing_contributors if you haven't already. Please close the two review bugs after the packages have been built in rawhide.
… Feel free to ping me on irc (zbyszek in #fedora-devel on freenode) or on matrix if you have questions about the process.
(fedscm-admin): The Pagure repository was created at https://src.fedoraproject.org/rpms/disorderfs
Package is built in rawhide. Closing it. Thank you for all.