Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: httptunnel - Tunnels a data stream in HTTP requests https://bugzilla.redhat.com/show_bug.cgi?id=239471 ------- Additional Comments From kevin@xxxxxxxxxxxxxxxx 2007-12-10 20:11 EST ------- > BuildRoot doesn't match the most preferred value, although it's OK. Most packages use that BuildRoot and it's sane, so I don't see why it should be changed. :-) > However, the source files simply say "see COPYING for license". Isn't GPL > code supposed to have a specific format for the comments in the source files > that reference COPYING. That's upstream's call to make, the problem with this format is that it's vague as to what versions of the GPL are allowed, but putting in License: GPLv2 is safe. > In %files, the following: > %defattr(-,root,root,-) > relies on "make install" to set the correct permissions. And "make install" should set the correct permissions if it's working correctly. :-) Actually, almost all packages use this format, setting permissions explicitly is normally only used if the upstream "make install" is broken. > File Makefile has (c) statement but no license. I don't know if that's OK. All the rest being GPLed, I'd assume this is just an oversight and the Makefile is covered by the COPYING being shipped too. It isn't copied from somewhere else or anything. > One more thing. I notice that the latest stable release is 3.0.5, and version > 3.3 (which is being packaged) is a development release. Is it appropriate to > package the development release? The "development release" isn't really under development. :-) To the submitter: can you please look at Stephen Warren's other comments and either fix the issues or say why they aren't problems? It looks to me like the review is stalled on that. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. _______________________________________________ Fedora-package-review mailing list Fedora-package-review@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-package-review