Bug 176200 - Review Request: mudmagic - Mud Magic Client
Review Request: mudmagic - Mud Magic Client
Status: CLOSED DEFERRED
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Thorsten Leemhuis (ignored mailbox)
David Lawrence
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-12-19 22:38 EST by Kyndig
Modified: 2007-11-30 17:11 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-02-08 23:32:20 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Patch fixing install as non-root user (366 bytes, patch)
2006-01-26 13:03 EST, Paul Howarth
no flags Details | Diff
Patch to remove standard-library rpath (486 bytes, patch)
2006-01-26 13:04 EST, Paul Howarth
no flags Details | Diff
Updated spec file incorporating patches and other tidying (2.41 KB, text/plain)
2006-01-26 13:07 EST, Paul Howarth
no flags Details

  None (edit)
Description Kyndig 2005-12-19 22:38:32 EST
Spec Name or Url: http://www.mudmagic.com/mud-client/downloads/mudmagic.spec.in
SRPM Name or Url: http://www.mudmagic.com/mud-client/downloads/mudmagic-1.8-0.fdr.3.src.rpm
Description :
Gtk program for connecting to online text games ( Muds ). This is a cross platform Linux / Windows based Open Source mud client.

Hi - this is a mud client for playing online text games. I'd like to add the upcoming 1.8 release of my client to Fedora Extra's. This is an early model of the upcoming release expected to be announced at the end of Dec. Currently the rpm will only install with --force, though the required libmxp is installed with the distro. I havn't solved this yet.
Comment 1 Warren Togami 2006-01-24 23:27:27 EST
"Currently the rpm will only install with --force, though the required libmxp is
installed with the distro. I havn't solved this yet."

Please update the report when you have solved this problem, Fedora cannot accept
a package with a problem like this.
Comment 2 Kyndig 2006-01-24 23:54:52 EST
Problem solved. I have just updated the spec file and the source rpm. Please see:

source rpm:
http://www.mudmagic.com/mud-client/downloads/mudmagic-1.8-0.fdr.4.src.rpm

spec:
http://www.mudmagic.com/mud-client/downloads/mudmagic.spec

I have also designed the autoconf system to build with 'rpm' from a tarball:
rpm -ta mudmagic-1.8.tar.gz   will work with the file from:
http://www.mudmagic.com/mud-client/download/mudmagic-1.8.tar.gz

Please note this is not the official release. I would like to submit this for
consideration to Fedora Extras. I do not plan on the final release of 1.8 to be
completed for another solid week if all goes well. At which time the above
mentioned files will be updated.

Libglade is being bundled with the distro as well - but for RedHat/Fedora
specific OS' it will be left as a required 3rd party to be installed with the
necessary package manager.

Thank you,
Calvin
Comment 3 Warren Togami 2006-01-25 00:09:56 EST
Hmm, it looks like you are basing this package on the old fedora.us guidelines.
 It is apparent that you haven't read the new Fedora Extras guidelines.

http://fedoraproject.org/wiki/Extras/
Please read through the new packaging requirements and process.

A few obvious things that need fixing, there might be more...
- %define version         1.8
This is unnecessary, just put the number directly after Version:
- Release: does not follow the new Extras guidelines
- %{_libdir}/libmudmagic.a
  %{_libdir}/libmudmagic.la
Do not ship these within the package.  Please delete them perhaps during %install.

I suppose it is OK to fix up the spec first in this case, but typically one only
submits a package for review only after they have a version that they intend on
releasing.  Please re-submit another URL when you have read through the
packaging guidelines and made necessary changes.  Maybe wait until after you
have an official 1.8 release too in order to avoid confusion?

After package approval, sponsorship of your membership will be based not on the
package approval but your demonstration of understanding of the guidelines and
process as documented in those web pages.
Comment 4 Kyndig 2006-01-25 00:25:04 EST
Certainly. Will do.

Thank you for your time,
Calvin
Comment 5 Mike McGrath 2006-01-25 00:25:50 EST
-Source should be http://dl.sourceforge.net/kyndig/%{name}-%{version}.tar.gz
-Source must be available at dl.sourceforge.net (currently only 1.7 is)
-Change Release: see http://fedoraproject.org/wiki/DistTag
-Duplicate Build Requires:
      glib2-devel provided by gtk2-devel
      pango-devel provided by gtk2-devel
      pkgconfig provided by glib2-devel
      gtk2-devel provided by libglade2-devel
-Inconsistant use of RPM_BUILD_ROOT
-I'd just define version under Version: 
-Don't include dist tag in the change log, version-release is fine

I could not get this to compile on my FC4 machine.  See error below:

--------------------------------------
creating libmxp.la
(cd .libs && rm -f libmxp.la && ln -s ../libmxp.la libmxp.la)
make[2]: *** No rule to make target `../bundled/bundled/pcre/pcre.c', needed by
`pcre.lo'.  Stop.
make[2]: Leaving directory
`/home/IES_CHICAGO/mmcgrath/rpm/BUILD/mudmagic-1.8/bundled'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/IES_CHICAGO/mmcgrath/rpm/BUILD/mudmagic-1.8'
make: *** [all] Error 2
error: Bad exit status from /home/IES_CHICAGO/mmcgrath/rpm/BUILD/rpm-tmp.45059
(%build)
-------------------------------------

Looks like Warren beat me to this but I'll submit it anyway because I too am
learning the packaging guidelines :-D
Comment 6 Warren Togami 2006-01-25 00:34:37 EST
McGrath is free to take the review. =)
Comment 7 Kyndig 2006-01-25 01:19:58 EST
"A few obvious things that need fixing, there might be more...
- %define version         1.8
This is unnecessary, just put the number directly after Version:"

done

"- Release: does not follow the new Extras guidelines
- %{_libdir}/libmudmagic.a
  %{_libdir}/libmudmagic.la"
%excluded

"-Source should be http://dl.sourceforge.net/kyndig/%{name}-%{version}.tar.gz"
redirected accordingly

"-Source must be available at dl.sourceforge.net (currently only 1.7 is)"
placed now on dedicated server

"-Change Release: see http://fedoraproject.org/wiki/DistTag"
Read ..partially =)

"Duplicate Build Requires:
      glib2-devel provided by gtk2-devel
      pango-devel provided by gtk2-devel
      pkgconfig provided by glib2-devel
      gtk2-devel provided by libglade2-devel"

unduplicated

"-Inconsistant use of RPM_BUILD_ROOT"
consisticised(sp?)

"-I'd just define version under Version:"
defined

"-Don't include dist tag in the change log, version-release is fine"
eh - tomato, tomahto


I could not get this to compile on my FC4 machine.  See error below:

--------------------------------------
creating libmxp.la
(cd .libs && rm -f libmxp.la && ln -s ../libmxp.la libmxp.la)
make[2]: *** No rule to make target `../bundled/bundled/pcre/pcre.c', needed by
`pcre.lo'.  Stop.
make[2]: Leaving directory
`/home/IES_CHICAGO/mmcgrath/rpm/BUILD/mudmagic-1.8/bundled'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/IES_CHICAGO/mmcgrath/rpm/BUILD/mudmagic-1.8'
make: *** [all] Error 2
error: Bad exit status from /home/IES_CHICAGO/mmcgrath/rpm/BUILD/rpm-tmp.45059
(%build)
-------------------------------------

Outstanding - thanks for the feedback, I would have missed that. Minor typo fixed.

I made these corrections to the autobuild system itself, reran the headers,
regenerated the configure, and rebundled the current distro. Again, I am testing
my waters with Fedora. I tried this a year ago and failed miserable ( I did read
all the docs back then =)

I will update this ticket once the final product is released. Please in the
meantime; should I have a newb error, let me know.

spec:
http://www.mudmagic.com/mud-client/downloads/mudmagic.spec
srpm:
http://www.mudmagic.com/mud-client/downloads/mudmagic-1.8-0.fdr.4.src.rpm
tarball:
http://www.mudmagic.com/mud-client/downloads/mudmagic-1.8-0.tar.gz

Thank you,
Calvin


Comment 8 Ville Skyttä 2006-01-25 02:00:42 EST
Quick observation based on some comments here, not actually checked: the tarball
ships private copies of libglade, libmxp, pcre, sqlite3 and zlib.  Private
copies like these are problematic from the security point of view, they're hard
to track and don't benefit from the distro's updates but must be handled
individually.  And obviously they bloat binaries.

Please make sure that the built package does not use this bundled stuff where
the corresponding package is available in FC/FE.  This seems to be done for
libglade, but I did not notice it being done for pcre, sqlite and zlib.  libmxp
is not available in FC/FE, so either it should be packaged and submitted
separately and this package converted to use the "external" one, or the bundled
one used until it is available separately.
Comment 9 Kyndig 2006-01-25 05:57:44 EST
Yes, the distro does not install any of these bundled libs if you already have
one installed. This includes pcre-devel, sqlite3-devel, and zlib.h (whichever
package that is frome)

Calvin
Comment 10 Paul Howarth 2006-01-25 06:07:54 EST
(In reply to comment #9)
> Yes, the distro does not install any of these bundled libs if you already have
> one installed. This includes pcre-devel, sqlite3-devel, and zlib.h (whichever
> package that is frome)

zlib.h is from zlib-devel

You should enforce the installation of the required -devel packages on the
buildsystem to ensure that the system versions of these libraries are used.
You'd do this by adding BuildRequires for the relevant packages.

As it happens, zlib-devel would be pulled in by freetype-devel, which is a dep
of pango-devel, which is a dep of gtk2-devel, which you already have listed as a
BuildRequire. In fact, you could also remove gtk2-devel from the BuildRequires
list because that itself is a dep of libglade2-devel. You'll probably need to
add pcre-devel and sqlite3-devel though.
Comment 11 Kyndig 2006-01-25 07:47:00 EST
I had thought about that. Since its Fedora/RedHat spec - I can compile the
binary with the standard sqlite3, pcre, zlib, libglade2 that comes with Fedora
and place a requirement for them in the spec. The -devel isn't required though -
only for compiling are these libs needed. The source itself makes use of a few
functions in these 3rd party softwares. For Fedora the packaging is pretty
simple - its keeping it available for most linux flavors that is requiring me to
bundle the required portions of 3rd party software needed.

I'll add the standard 3rd party software available in Fedora to the spec
requirement then. ( sqlite3, pcre, libglade2, libxml2 )

The autoconf system itself if you read configure.in - 
http://cvs.mudmagic.com/co.php/mudmagic_client/configure.in?r=1.14
handles tarball compile requirements by performing a check on the local OS for
the needed libs - and compiling them in with the client if missing.

Thanks for the pointer,
Calvin
Comment 12 Paul Howarth 2006-01-25 07:51:03 EST
Add the -devel packages as BuildRequires (not just Requires) to ensure that the
needed header files are installed for the configure script to detect them.

The library deps should be handled automatically by RPM so there should be no
need to add a Requires: for pcre, libglade2, libxml2, and probably sqlite3 too.
Comment 13 Kyndig 2006-01-25 13:26:45 EST
Thank you for the help and info. I updated my Fedora distro and performed
several tests of the BuildRequires and Requires to ensure the package
requirements are correct for both installing a binary rpm and rebuilding the rpm
from either a source rpm or the tarball.

I added the BuildRequires for the needed libs. I also added the Requires macro -
though it isn't required, I'd prefer to have a user know the name of the package
they need to install to satisfy requirements; opposed to the name of the shared
object missing.

These updates have been committed to CVS and the autoconf system for building. 

spec:
http://www.mudmagic.com/mud-client/downloads/mudmagic.spec
srpm:
http://www.mudmagic.com/mud-client/downloads/mudmagic-1.8-0.fdr.4.src.rpm
tarball:
http://www.mudmagic.com/mud-client/downloads/mudmagic-1.8.tar.gz

Once more - a warm thanks for the attention and help everyone has shown and given,
Calvin
Comment 14 Paul Howarth 2006-01-25 13:57:07 EST
The best way to check BuildRequires is I think to use mock
(http://fedoraproject.org/wiki/Legacy/Mock). This builds your package in a
minimal chroot with only your additionally-specified build-requirements added,
so if you've missed anything it usually causes the build to fail (or sometimes
produce packages that are missing features).

Other suggestions:
* Don't use an Epoch: tag if it's going to be "0"
* Use Release: 0.4%{?dist} rather than Release: 0.fdr.4
* Replace "1.8" with "%{version}" in the Source: tag for easier spec maintenance
* The %configure macro should set CFLAGS so there's no need to do it yourself
* Use e.g. "%post -p /sbin/ldconfig" rather than "%post" and "/sbin/ldconfig" on
separate lines
* Add changelog entries for your changes so it doesn't look like the last change
was by Michael Schwendt in 2004
Comment 15 Mike McGrath 2006-01-25 15:37:24 EST
- Use $RPM_BUILD_ROOT or %{buildroot}, not ${RPM_BUILD_ROOT}
- libxml2-devel is provided by libglade2-devel
- Description should be in sentence form (put a period after MudMagic.Com.)
- Requires(post): /sbin/ldconfig
- Requires(postun): /sbin/ldconfig
- Mock build failed (Also failed on my machine):

libtool: install: warning: remember to run `libtool --finish /usr/lib/mudmagic/libs'
make[2]: Nothing to be done for `install-data-am'.
make[2]: Leaving directory `/builddir/build/BUILD/mudmagic-1.8/bundled'
make[1]: Leaving directory `/builddir/build/BUILD/mudmagic-1.8/bundled'
Making install in interface
make[1]: Entering directory `/builddir/build/BUILD/mudmagic-1.8/interface'
make[2]: Entering directory `/builddir/build/BUILD/mudmagic-1.8/interface'
/bin/sh ../mkinstalldirs /usr/lib/mudmagic/plugins
mkdir -p -- /usr/lib/mudmagic/plugins
mkdir: cannot create directory `/usr/lib/mudmagic': Permission denied
make[2]: *** [install-exec-local] Error 1
make[2]: Leaving directory `/builddir/build/BUILD/mudmagic-1.8/interface'
make[1]: *** [install-am] Error 2
make[1]: Leaving directory `/builddir/build/BUILD/mudmagic-1.8/interface'
make: *** [install-recursive] Error 1
error: Bad exit status from /var/tmp/rpm-tmp.8107 (%install)

Fix the build problem and Paul's comments and I think you'll be in pretty good
shape.  Though I haven't been able to actually build the package yet.  :-)
Comment 16 Wart 2006-01-25 17:01:03 EST
(In reply to comment #15)

> make[2]: Entering directory `/builddir/build/BUILD/mudmagic-1.8/interface'
> /bin/sh ../mkinstalldirs /usr/lib/mudmagic/plugins
> mkdir -p -- /usr/lib/mudmagic/plugins
> mkdir: cannot create directory `/usr/lib/mudmagic': Permission denied
> make[2]: *** [install-exec-local] Error 1
> make[2]: Leaving directory `/builddir/build/BUILD/mudmagic-1.8/interface'
> make[1]: *** [install-am] Error 2
> make[1]: Leaving directory `/builddir/build/BUILD/mudmagic-1.8/interface'
> make: *** [install-recursive] Error 1
> error: Bad exit status from /var/tmp/rpm-tmp.8107 (%install)
> 

One of the install targets in the Makefile is not obeying DESTDIR.  You'll have
to patch the following line in interface/Makefile.in:

install-exec-local:
        $(mkinstalldirs) @plugin_libdir@

to


install-exec-local:
        $(mkinstalldirs) $DESTDIR@plugin_libdir@
Comment 17 Ignacio Vazquez-Abrams 2006-01-25 17:11:13 EST
(In reply to comment #16)
>         $(mkinstalldirs) $DESTDIR@plugin_libdir@

Whoops.

$(mkinstalldirs) $(DESTDIR)@plugin_libdir@
Comment 18 Kyndig 2006-01-25 22:16:17 EST
" * Don't use an Epoch: tag if it's going to be "0" "
removed

" * Use Release: 0.4%{?dist} rather than Release: 0.fdr.4 "
used

" * Replace "1.8" with "%{version}" in the Source: tag for easier spec maintenance "
this is actually already present, the mudmagic.spec is created during configure
with mudmagic.spec.in which uses an @VERSION@ variable to output the mudmagic
source version

" * The %configure macro should set CFLAGS so there's no need to do it yourself "
Removed CFLAGS

" * Use e.g. "%post -p /sbin/ldconfig" rather than "%post" and "/sbin/ldconfig"
on separate lines "
Used - and also used for %postun

" * Add changelog entries for your changes so it doesn't look like the last
change was by Michael Schwendt in 2004 "
Added all entries from this ticket with appropriate credits

" - Use $RPM_BUILD_ROOT or %{buildroot}, not ${RPM_BUILD_ROOT} "
using %{buildroot} now

" - libxml2-devel is provided by libglade2-devel "
removed libxml2-devel

" - Description should be in sentence form (put a period after MudMagic.Com.) "
period added

" - Requires(post): /sbin/ldconfig
- Requires(postun): /sbin/ldconfig "
These two requires added

" - Mock build failed (Also failed on my machine): "
Rewrote the method of --prefix and --exec-prefix handling for autoconf. I won't
go into details - but it was a heavy rewrite. included the usage of user defined
variables for installation directories opposed to hard coded directory locations
in Makefile.am files and configure.in file.


Autoconf build system rebuilt and changes commited to CVS.

spec:
http://www.mudmagic.com/mud-client/downloads/mudmagic.spec
srpm:
http://www.mudmagic.com/mud-client/downloads/mudmagic-1.8-0.4.src.rpm
tarball:
http://www.mudmagic.com/mud-client/downloads/mudmagic-1.8.tar.gz

Thank you all,
Calvin
Comment 19 Paul Howarth 2006-01-26 03:20:23 EST
(In reply to comment #18)
> " * Replace "1.8" with "%{version}" in the Source: tag for easier spec
naintenance "
> this is actually already present, the mudmagic.spec is created during configure
> with mudmagic.spec.in which uses an @VERSION@ variable to output the mudmagic
> source version

Actually I would still suggest making this change. The reason for this is that
although you generate a spec file yourself during configure, that is not the
spec file that is used when you rebuild an SRPM. And since this is a package for
Fedora Extras, the spec file will eventually be held in Fedora's cvs and will
need to be maintained there too. Using %{version} will at least result in
smaller diffs :-)

> " - Use $RPM_BUILD_ROOT or %{buildroot}, not ${RPM_BUILD_ROOT} "
> using %{buildroot} now

There's nothing wrong with ${RPM_BUILD_ROOT} really (as long as you're
consistent about it and don't use $RPM_BUILD_ROOT in the same spec), but
%{buildroot} is fine too (and what I ise in my own specs).

> " - Mock build failed (Also failed on my machine): "
> Rewrote the method of --prefix and --exec-prefix handling for autoconf. I won't
> go into details - but it was a heavy rewrite. included the usage of user defined
> variables for installation directories opposed to hard coded directory locations
> in Makefile.am files and configure.in file.

Build in mock still fails.

Making install in interface
make[1]: Entering directory `/builddir/build/BUILD/mudmagic-1.8/interface'
make[2]: Entering directory `/builddir/build/BUILD/mudmagic-1.8/interface'
/bin/sh ../mkinstalldirs /usr/lib/mudmagic/plugins
mkdir -p -- /usr/lib/mudmagic/plugins
mkdir: cannot create directory `/usr/lib/mudmagic': Permission denied
make[2]: *** [install-exec-local] Error 1
make[2]: Leaving directory `/builddir/build/BUILD/mudmagic-1.8/interface'
make[1]: *** [install-am] Error 2
make[1]: Leaving directory `/builddir/build/BUILD/mudmagic-1.8/interface'
make: *** [install-recursive] Error 1
error: Bad exit status from /var/tmp/rpm-tmp.93171 (%install)

There's a missing $(DESTDIR) in that mkinstalldirs invocation.

> spec:
> http://www.mudmagic.com/mud-client/downloads/mudmagic.spec
> srpm:
> http://www.mudmagic.com/mud-client/downloads/mudmagic-1.8-0.4.src.rpm
> tarball:
> http://www.mudmagic.com/mud-client/downloads/mudmagic-1.8.tar.gz

I'd suggest incrementing the RPM release number each time you change the spec,
and include the release number in the changelog entries, which makes them easier
to follow.

Comment 20 Michael Schwendt 2006-01-26 07:32:21 EST
> Use $RPM_BUILD_ROOT or %{buildroot}, not ${RPM_BUILD_ROOT}

Huh? May I ask the reason for that? ${RPM_BUILD_ROOT} is perfectly
fine.

> I also added the Requires macro - though it isn't required, I'd
> prefer to have a user know the name of the package they need to
> install to satisfy requirements; opposed to the name of the shared
> object missing.

Veto. It is a mistake. If more packagers attempt at sneaking in
dependencies on hardcoded package names where automatic dependencies
on sonames suffice, we will need to make this a strict policy - a
MUST NOT. We rely on rpmbuild's automatic soname dependencies. We
don't care whether the package which provides libsqlite3.so.0 is
called sqlite3, sqlite or libsqlite3.

> * Add changelog entries for your changes so it doesn't look like
> the last change was by Michael Schwendt in 2004 "

Oh, please! Especially if that old changelog entry is useless anyway.
The spec file has been modified a lot since then without mentioning
the changes, packaging bugs have been reintroduced and things like that.

> Added all entries from this ticket with appropriate credits

Please don't. Don't act as the ghostwriter of other people. Don't
use other people's names for work you did on the spec file. This
is really impolite IMO,

> * Wed Jan 25 2005 Warren Togami <wtogami[AT]redhat.com> - 1.8
> - %define version @ VERSION @ removed
>   Version: defined with the @ VERSION @ macro from configure
>  exlude %{_libdir}/libmudmagic.a
>  exlude %{_libdir}/libmudmagic.la

since Warren did not write this changelog entry himself. Apart from
that, the entry is quite incomprehensible (at least to me). And it's
spelled "exclude" not "exlude". ;)
Comment 21 Kyndig 2006-01-26 11:55:24 EST
"We rely on rpmbuild's automatic soname dependencies. We
don't care whether the package which provides libsqlite3.so.0"

This certainly makes sense. Thanks for the explanation. When viewed in that
manner - it is much more preferrable than using a name for Requires.

"Don't act as the ghostwriter of other people."
I didn't much care for the ChangeLog requirement myself - I really don't care
about ChangeLog entries - but it was a requirement for adding this proejct. I
have removed it. 

The build problem in Mock calls for more looking into as I can not find the
location of the error or recreate the issue. Makefile.in is created by running
configure by the configure.in and Makefile.am located in the source. It honors
prefefix and exec_prefix appropriately. I installed mock and must not have it
configured correctly as it just freezes on me when I try building the source rpm
( I did add my user login to the group list )

I'm playing DLL hell with windows packaging right now though and am working on
the MAC OSX port.

These updates were done. and can be viewed here. Short of an innapropriate entry
- this package for Fedora users won't be updated further for rpm packaging ( the
source has one final bugfix update before it is released ) I will attempt the
Fedora Extra's entry again in about a year with 2.0 release.

spec:
http://www.mudmagic.com/mud-client/downloads/mudmagic.spec
srpm:
http://www.mudmagic.com/mud-client/downloads/mudmagic-1.8-0.4.src.rpm
tarball:
http://www.mudmagic.com/mud-client/downloads/mudmagic-1.8.tar.gz


Thanks everyone for the wonderful support and help,
Calvin
Comment 22 Paul Howarth 2006-01-26 13:03:33 EST
Created attachment 123727 [details]
Patch fixing install as non-root user
Comment 23 Paul Howarth 2006-01-26 13:04:32 EST
Created attachment 123728 [details]
Patch to remove standard-library rpath
Comment 24 Paul Howarth 2006-01-26 13:07:48 EST
Created attachment 123729 [details]
Updated spec file incorporating patches and other tidying

This spec file fixes the mock-build issues for FC4 (i386).

rpmlint says that libmudmagic.so and mudmagic.pc should be in a separate -devel
subpackage and I'm inclined to agree with it.
Comment 25 Kyndig 2006-01-26 14:02:21 EST
Paul - Thank you for taking the time to create the patchset which fixes the
problem with the mock-build. The solution you found was an area I had not even
looked into. When the interface/Makefile.am was built, it was simply to install
the required files for the gtk/glade interface widgets and it never occurred to
me that these are the files which were causing the issue.

I have applied your patches to the source itself and used your spec file patch
to create the mudmagic.spec.in . I reran the autoconf - updated CVS and
republished this build. 

I would have left the patchset as-is; but since the patch modifies to the build
system itself and provides a stronger cross-platform build, it was applied
directly to the source.

spec:
http://www.mudmagic.com/mud-client/downloads/mudmagic.spec
srpm:
http://www.mudmagic.com/mud-client/downloads/mudmagic-1.8-0.5.src.rpm
tarball:
http://www.mudmagic.com/mud-client/downloads/mudmagic-1.8.tar.gz


Comment 26 Kyndig 2006-02-01 04:07:01 EST
The ready for release version is completed. Documentation, Themes, Network
bugfixes were implemented. No changes to the Fedora spec file were performed.

Final build prior to 1.8 release ( pending any bugs )
spec:
http://www.mudmagic.com/mud-client/downloads/mudmagic.spec
srpm:
http://www.mudmagic.com/mud-client/downloads/mudmagic-1.8-0.6.src.rpm
tarball:
http://www.mudmagic.com/mud-client/downloads/mudmagic-1.8.tar.gz

Thank you all again for the tremendous support.
Calvin
Comment 27 Mike McGrath 2006-02-08 23:18:43 EST
Sorry Calvin, I didn't realize this was FE-NEEDSPONSOR.  I'm only just recently
sponsored myself so I can't sponsor you, I'll assign this to
bugzilla-sink@leemhuis.info  Which by the sounds of the name is not unlike
/dev/null :-D  but someone will pick it up soon I'm sure.
Comment 28 Kyndig 2006-02-08 23:24:16 EST
*lol* Thank you. 

The 1.8 version is published. 1.9 will be mostly internal updates and completion
of MXP and will not be a major release. I'll work again on getting it in Fedora
for version 2.0 in about a year.

http://www.mudmagic.com/mud-client/downloads/mudmagic-1.8-fdr.src.rpm

Calvin
Comment 29 Christian Iseli 2006-10-18 09:10:11 EDT
Normalize summary field for easy parsing

Note You need to log in before you can comment on or make changes to this bug.