http://bugzilla.rpmfusion.org/show_bug.cgi?id=1728
--- Comment #8 from Richard <hobbes1069(a)gmail.com> 2011-05-05 15:36:45 ---
(In reply to comment #7)
(In reply to comment #5)
> Had a second at work, I reviewed as much as I could the Review guidelines.
>
> I think the License in the spec file should be updated:
> License: GPLv2
> Found in ./COPYING-2.0
>
I can understand your reasoning, but this is not how the GPL version which
actual applies gets determined. The rule is first source code headers, then
readme, the version of the COPYING file is irrelevant from a legal pov.
Since the README only specifies GPL without mentioning a header any GPL version
will do (the person distributing can choose which version he wants to
distribute under), so the correct license tag is
Wow, welcome to the convoluted world of GPL... :)
> rm $RPM_BUILD_ROOT/usr/lib/X11/app-defaults
> If the files that go in this folder are not needed (they are in the resulting
> package) I think this needs -rf since it puts files in the directory and rm
> will not remove a directory by default.
This rm command is removing a symlink for compatibility with older libX*
versions which imake insists on installing.
Since it's not obvious (atleast to me) what's going on there it may be helpful
to add a comment to better meet the "spec files must be legible" requirement.
> I know common practice for subpackages is to require the main
package
> i.e.: Requires: %{name} = %{version}-%{release}
> But the packaging guidelines recommend arch specific as well:
> i.e.: Requires: %{name}%{?_isa} = %{version}-%{release}
> In this case since it's just an editor I would expect it to work fine but is it
> still more approprite to include the arch?
isa requires are only relevant for packages with are multilib, iow both the
i386 and x86_64 versions of them get included into 64 bit composes. This only
happens for libraries (well the diagnostic used by the compose tool is packages
with a -devel subpackage, either wat this package won't get multilib-ed, so npo
need for isa requires.
Hmm... maybe the wiki needs to be updated then to be more clear as it doesn't
even mention the non-arch version.
(In reply to comment #6)
> Ok, I'm getting the following error trying to run:
>
> $ xmris
> X Error of failed request: BadName (named color or font does not exist)
> Major opcode of failed request: 45 (X_OpenFont)
> Serial number of failed request: 14
> Current serial number in output stream: 15
>
> $ xmred
> X Error: BadName (named color or font does not exist)
> Major opcode: 45
> Minor opcode: 0
> Resource id: 0x4000001
> Serial number: 14
> Aborted (core dumped)
>
> This looks to be a font issue but starting the xfs server didn't help. I'm
> still trying to figure out what the problem is.
>
Hmm, that should not happen :) Can you attach your
/etc/X11/fontpath.d/xorg-x11-fonts-Type1/fonts.dir
Never mind, it was my fault. I had changed the before mentioned 'rm' to 'rm
-rf' which was the culprit.
Richard
--
Configure bugmail:
http://bugzilla.rpmfusion.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
You are the assignee for the bug.