Spec URL: https://download.copr.fedorainfracloud.org/results/bkeys/nibbles/fedora-37-ppc64le/04813230-nibbles/nibbles.spec SRPM URL: https://bkeys.org/nibbles-1.0-1.fc36.src.rpm Description: Game I made in 2015 as my first stepping stones into OpenGL game development. It's a simple rendition of the classic arcade game nibbles. Collect the red fruit to increase your score while avoiding green pot obstacles. Fedora Account System Username:bkeys
I have added this package as a copr repo, and it has successfully built on all recent versions of Fedora and CentOS Stream. Here is the link: https://copr.fedorainfracloud.org/coprs/bkeys/nibbles/build/4813230/
Thank you for your contribution! This is not a formal review, but some findings when having a very first look to it: - Summary tag is too long and quoted See: https://docs.fedoraproject.org/en-US/packaging-guidelines/#_summary_and_description - Description tag is quoted and shorter than summary See: https://docs.fedoraproject.org/en-US/packaging-guidelines/#_summary_and_description - Source0 should use URL to upstream tarball See: https://docs.fedoraproject.org/en-US/packaging-guidelines/SourceURL/ - Don't disable %debug_package See: https://docs.fedoraproject.org/en-US/packaging-guidelines/Debuginfo/ - License tag doesn't use SPDX See: https://docs.fedoraproject.org/en-US/packaging-guidelines/LicensingGuidelines/ - Use %{_bindir} instead of /usr/bin See: https://docs.fedoraproject.org/en-US/packaging-guidelines/RPMMacros/ - COPYING listed in %doc and %license -> remove from %doc See: https://docs.fedoraproject.org/en-US/packaging-guidelines/LicensingGuidelines/ - Requires tag seems to be unnecessary due to SONAME See: https://docs.fedoraproject.org/en-US/packaging-guidelines/#_explicit_requires Hint: A possible future formal reviewer will follow these guidelines: https://docs.fedoraproject.org/en-US/packaging-guidelines/ReviewGuidelines/
Oh, according FAS, you are not a Fedora packager yet; setting FE-NEEDSPONSOR.
Brigham, please also read https://docs.fedoraproject.org/en-US/fesco/Packager_sponsor_policy/#requesting_sponsorship - thank you :)
Created attachment 1913862 [details] This is a new SRPM with all of Robert's suggestedchanges This new SRPM builds successfully on all relevant platforms on copr https://copr.fedorainfracloud.org/coprs/bkeys/nibbles/build/4870465/
Created attachment 1913864 [details] New SRPM that passes rpmlint Please ignore my previous srpm, it has a long description. This attachment is an SRPM that passes rpmlint entirely.
Thank you for the package Brigham, and also for making the changes > Created attachment 1913864 [details] > New SRPM that passes rpmlint Typically you should always post the updated package the same way you did in the bug description, i.e. Spec URL: ... SRPM URL: ... There are tools like `fedora-review` that can parse the BZ comments, find the newest package, download it, run some checks on it, and make the reviewer's life easier. > BuildRequires: freeglut-devel SDL2-devel cmake gcc gcc-c++ This is fine, and I have no problem with this. Just from a personal experience, I find it better to write each dependency on a new line, like this: BuildRequires: freeglut-devel BuildRequires: SDL2-devel BuildRequires: cmake BuildRequires: gcc BuildRequires: gcc-c++ This way you can have as many dependencies as you need and you are not limited by line length, and also it is much clearer in git diffs what dependency was added and when. But if you prefer the single-line format, that's fine as well. I just wanted to make it known, that there is an alternative. > %license COPYING I am a bit uneasy that there are both LICENSE and COPYING files and they are not the same (although they both appear to be GPLv3). Since you are the upstream developer, I think you can easily fix this within the project itself. Or I would just do %license COPYING %license LICENSE to install them both. Otherwise, the package looks good to me. --- Since this would be your first Fedora package, you will need to get sponsored into the `packager' group before this package can be accepted. I recently became a sponsor and I would like to sponsor you. That would make it my responsibility to guide you through the processes that you will do, and the tools that you will need as a package maintainer. I would also be there to answer your packaging-related questions, or to help you find somebody who knows the answers. But before that, I should make sure that you will be able to fulfill your package maintainer responsibilities https://docs.fedoraproject.org/en-US/fesco/Package_maintainer_responsibilities/ Please take a look here https://docs.fedoraproject.org/en-US/fesco/Packager_sponsor_policy/#requirements I think the most beneficial option for you as a sponsoree would be reviewing 2-3 packages from somebody else. It will help you understand the packaging guidelines better but at the same time, it will help somebody else to get also their packages accepted to Fedora. If you are interested, please ping me on #fedora-devel IRC, my nick is FrostyX, or send me an email, and we can get started. I will explain what is necessary as we go.
This is an automatic check from review-stats script. This review request ticket hasn't been updated for some time, but it seems that the review is still being working out by you. If this is right, please respond to this comment clearing the NEEDINFO flag and try to reach out the submitter to proceed with the review. If you're not interested in reviewing this ticket anymore, please clear the fedora-review flag and reset the assignee, so that a new reviewer can take this ticket. Without any reply, this request will shortly be resetted.
> If you're not interested in reviewing this ticket anymore I am interested in reviewing this ticket but there is no response from the contributor.