You should post direct links to the spec and srpm you want the reviewer to use.  We download those and run software against them.

I am willing to fish around on your COPR for candidates, other reviewers would not be so willing.

Can you issue a release on your github instead of using git commit hashes in the spec?  Just create an annotated tag then issue a release tarball, e.g. hasciicam-1.1.2.tar.bz2 (or whatevcer version you use), along with sha and md5 checksums?  Then come back here and use a conventional, release-oriented spec instead of a git commit hash spec.  The latter implies a very active project and this project is very old and dead.

On git hub, create an annotated tag and sign it with your gpg key.  Upload the public gpg key to github so that the tag will appear as "verified"

1. Create gpg key pair
2. Upload public key to github
3. git tag -a -s -m "Release of vX.Y.Z"
4. Issue a release, e.g. hasciicam-1.1.2.tar.bz2
5. Display sha1sum hasciicam-1.1.2.tar.bz2
6. Display md5sum hasciicam-1.1.2.tar.bz2
7. Rewrite the rpm spec and remove all git commit features, use release syntax instead.

(In reply to Philip Kovacs from comment #1)
> You should post direct links to the spec and srpm you want the reviewer to
> use.  We download those and run software against them.

Ok. I will remember that.

(In reply to Philip Kovacs from comment #2)
> Can you issue a release on your github instead of using git commit hashes in
> the spec?  Just create an annotated tag then issue a release tarball, e.g.
> hasciicam-1.1.2.tar.bz2 (or whatevcer version you use), along with sha and
> md5 checksums?  Then come back here and use a conventional, release-oriented
> spec instead of a git commit hash spec.  The latter implies a very active
> project and this project is very old and dead.

The point is, as you have seen, that I'm not the developer/maintainer of this software. And I'm not the owner of such git repository.
This project is very old, true, but it still works, and it looks that the developer replies to the issues. 
Let's see what upstream says.

Thank you.

>License:  GNU 2
"GNU" is not a licence, though they did publish the rather popular GNU General Public License. ;)
The upstream readme says it's GPL 2 or later, so you should use "GPLv2+" here.
https://fedoraproject.org/wiki/Licensing:Main#Good_Licenses

>%description
>[...long text here...]
You need to manually wrap the description text so that each line has no more than 80 characters.

>%files
>%{_datadir}/applications/hasciicam.desktop
You should add "BuildRequires: desktop-file-utils" to the spec and run "desktop-file-validate" on the .desktop file (preferably during %check).
>https://docs.fedoraproject.org/en-US/packaging-guidelines/#_desktop_file_install_usage

>%files
>%{_datadir}/icons/hasciicam.png
I'm not entirely sure about this, but the icon should go in "%{_datadir}/icons/hicolor/$SIZE/apps/", or alternatively "%{_datadir}/pixmaps/".
You can either patch the build files or move the file in %install.

>%files
>%{_mandir}/man1/hasciicam.1.gz
Do not assume that man pages will be gzip-compressed. Use a wildcard here.
https://docs.fedoraproject.org/en-US/packaging-guidelines/#_manpages

>%files
>%doc README AUTHORS COPYING NEWS TODO ChangeLog
The COPYING file should be marked as "%license", not "%doc".

We're working with upstream on a number of issues before we continue with the review.

I'm not really in love with the idea of this particular software installing .desktop and .png files at all.
It doesn't really have any gui to speak of and launching an x11 terminal as a proxy for a gui doesn't really fly.

Files are 404, any update here?

(In reply to Robert-André Mauchin from comment #7)
> Files are 404, any update here?

No updates. Upstream didn't reply since then.

Alessio, when the package bocomes better and ready for the review, delete the "NotReady" word from the whiteboard field. I added it to hide this review from reviewers until the package is finished for the review.

(In reply to Petr Pisar from comment #9)
> Alessio, when the package bocomes better and ready for the review, delete
> the "NotReady" word from the whiteboard field. I added it to hide this
> review from reviewers until the package is finished for the review.

Thank you.
I didn't hear anything new from upstream.
I will ping them again in the near future.

This is an automatic check from review-stats script.

This review request ticket hasn't been updated for some time. We're sorry
it is taking so long. If you're still interested in packaging this software
into Fedora repositories, please respond to this comment clearing the
NEEDINFO flag.

You may want to update the specfile and the src.rpm to the latest version
available and to propose a review swap on Fedora devel mailing list to increase
chances to have your package reviewed. If this is your first package and you
need a sponsor, you may want to post some informal reviews. Read more at
https://fedoraproject.org/wiki/How_to_get_sponsored_into_the_packager_group.

Without any reply, this request will shortly be considered abandoned
and will be closed.
Thank you for your patience.

This is an automatic action taken by review-stats script.

The ticket submitter failed to clear the NEEDINFO flag in a month.
As per https://fedoraproject.org/wiki/Policy_for_stalled_package_reviews
we consider this ticket as DEADREVIEW and proceed to close it.