http://bugzilla.rpmfusion.org/show_bug.cgi?id=1728
Hans de Goede <j.w.r.degoede(a)gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Blocks| |3
--- Comment #7 from Hans de Goede <j.w.r.degoede(a)gmail.com> 2011-05-05 14:56:32
---
(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
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.
No %{buildroot} or %clean. So I assume this package is intended for
F13+ (no
EPEL)
Correct.
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.
(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
File here please? As well as Xorg.0.log?
Also, shouldn't this be blocking bug #2?
Ah, right, well bug #3 now since review has begun more or less.
--
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.