Spec URL: http://togami.com/~warren/fedora/wraplinux.spec
SRPM URL: http://togami.com/~warren/fedora/wraplinux-1.5-1.fc9.src.rpm
A tool to wrap an x86 Linux kernel and one or more initrd files into a
single file in ELF or NBI format, as required by some booting protocols.
As requested by drago01:
- Builds in mock (yes it really doesn't have any build reqs)
- wraplinux.i386: W: executable-stack /usr/bin/wraplinux
This is the only rpmlint warning. Asking hpa upstream if this was intended or not.
No remaining rpmlint warnings, builds cleanly in mock.
Looks clean. Approved.
Rahul, sorry to rain on your parade once again, but the license tag is wrong. It's GPLv2+, not GPLv2. You did check the headers, did you?
Warren, please fix this in the next version or rebuild. Thanks.
I don't recall what all I checked six months backs and whether the headers have changed meanwhile in new releases but I am feeling quite amused you decided to recheck all my reviews. I suggest that if you find packaging bugs, you file a new bug report instead of commenting on closed reviews. I know package maintainers who filter out comments on closed bug reports to low priority or even /dev/null.
(In reply to comment #5)
> I don't recall what all I checked six months backs
One more reason to write it down in the review...
> and whether the headers have changed meanwhile in new releases
There was no new release in the meantime.
> but I am feeling quite amused you decided to
> recheck all my reviews.
Not all your reviews, just the obvious errors that are easy to find.
> I suggest that if you find packaging bugs, you file a
> new bug report instead of commenting on closed reviews.
Thanks for the suggestion, I will CC you then because I want you to become aware of your errors.
Writing down makes no real difference to me. There has been instances of people blindly copy pasting templates and still overlooking checklist items. Again, instead of approaching it on a case by case basis, if you feel strongly about how reviews should be done, it is better to take it to the packaging committee or FESCo and make it part of the guidelines/rules. Otherwise it is just individual's freedom to do the reviews as they see fit.
I would also note that packaging is primarily the responsibility of the package maintainers. Reviewers are merely volunteering to help out with the process as QA assistance. Mistakes are bound to happen either way even with a recheck. Just to demonstrate, I checked the copyright notices again, GPLv2+ doesn't seem the right choice here either. reloc_linux.c seems to be under the MIT license actually and xmalloc.c doesn't even have a license notice. Warren, I suggest you contact upstream and clarify these.
> It's GPLv2+, not GPLv2. You did check the headers, did you?
What if I choose to use it only under the GPLv2?
You know, I really don't care. Aren't you a provenpackager? Just fix it yourself if you care. It really doesn't matter.