Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=578290 --- Comment #13 from Mamoru Tasaka <mtasaka@xxxxxxxxxxxxxxxxxxx> 2010-04-19 13:54:43 EDT --- spot, thank you for auditing this. (In reply to comment #11) > Is it ok to include non-GPL tiles in the source package > when the non-GPL tiles are not included in the binary packages? > I suppose I should ask Tom 'spot' Callaway about that, but > how should I do that? By a direct e-mail to him with a copy > on the present page? - As the license of the tiles is legally forbidden on Fedora, these files should also be removed from the source tarball itself. Please refer to https://fedoraproject.org/wiki/Packaging/SourceURL#When_Upstream_uses_Prohibited_Code > The package uses the directory /usr/share/icons/hicolor/32x32/apps/ > which is owned by package hicolor-icon-theme-0.10-6.noarch. How > can I know whether or not one needs to require > hicolor-icon-theme-0.10-6.noarch? - Usually for gtk2-dependent packages we don't add "R: hicolor-icon-theme" explicitly because gtk2 already has this dependency. > Packaging guidelines says that "Each package must consistently > use macros." Is this a question of using either $RPM_OPT_FLAGS > style or %{optflags} style? - I usually interpret this like: * Once a macro is defined by in the spec explicitly, the packager should always use the macro where the macro can be used. For this package, as %icondir is explicitly defined, "/usr/share/icons/hicolor/32x32/apps" should always be replaced by %icondir. * Also when some already-defined macros can be used, we should use such macros as much as possible. * A packager should not use both %optflags and $RPM_OPT_FLAGS but choose one. To Klaus: As you are sponsored, you can formally review this. Would you want to do so? -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. _______________________________________________ package-review mailing list package-review@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/package-review