[Bug 1728] Review request: xmris - Maze digging and cherry eating game

RPM Fusion Bugzilla noreply at rpmfusion.org
Thu May 5 15:36:46 CEST 2011


http://bugzilla.rpmfusion.org/show_bug.cgi?id=1728





--- Comment #8 from Richard <hobbes1069 at 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.


More information about the rpmfusion-developers mailing list