https://bugzilla.redhat.com/show_bug.cgi?id=2279277
--- Comment #7 from Petr Menšík <[email protected]> --- (In reply to Jaroslav Škarvada from comment #3) > > Source0: > > https://github.com/jarikomppa/emu8051/archive/%{gitcommit}.tar.gz#/%{name}-%{gitcommit}.tar.gz > You can utilize github arbitrary download names instead of the RPM hacks, > e.g.: > Source0: > https://github.com/jarikomppa/emu8051/archive/%{gitcommit}/%{name}- > %{gitcommit}.tar.gz Okay. I tend to not find special github correct paths, so I have derived this from download button link on web UI. But okay, your is a bit nicer. > > BuildRequires: gcc make > Maybe better to add each requirement on individual line. It's better to > manage and more clear, e.g. you can easily comment out individual deps. Unless something very important changes, project like this cannot omit gcc or make. This does not change anything. > > sed -e "s,^BIN := emu,BIN := %{name}," -i Makefile > Why not just use: > %make_build BIN=%{name} > You could omit 'sed' build requirement then. Yeah. I made this before I have realized Makefile does not provide install target anyway. So I could rename it just in install command. > > > install -m 0755 %{name} %{buildroot}%{_bindir}/%{name} > Please use '-p' to preserve time stamps. I do not see any point in keeping time stamp of build, which is different on each rebuild anyway. What is the point for keeping always changing stamp? It makes perfect sense on content from source archive. Not on always regenerated build pieces. In short. I see every MUST passed. Only with minor formatting or style issues. Where is my + flag then? :-o -- You are receiving this mail because: You are always notified about changes to this product and component You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2279277 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-spam&short_desc=Report%20of%20Bug%202279277%23c7 -- _______________________________________________ package-review mailing list -- [email protected] To unsubscribe send an email to [email protected] Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/[email protected] Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
