Bug 176071 - Review Request: silgraphite
Review Request: silgraphite
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Greg DeKoenigsberg
Fedora Package Reviews List
Depends On:
  Show dependency treegraph
Reported: 2005-12-18 20:16 EST by Michael A. Peters
Modified: 2008-04-14 12:17 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-06-27 16:57:04 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Michael A. Peters 2005-12-18 20:16:35 EST
Spec Name or Url: http://mpeters.us/silgraphite/silgraphite.spec
SRPM Name or Url: http://mpeters.us/silgraphite/silgraphite-2.0.0-0.10.svn106.src.rpm

Graphite is a project within SIL's scripts and software dev groups to provide
cross-platform rendering for complex writing systems.

Graphite is intended to serve as the principal non-Roman renderer for the
FieldWorks package, the new generation of linguistic and translation tools
under development within SIL.

We also want to make the Graphite library available to any software developer
who is working to develop multilingual text processing applications.

URL with Demonstration:

Targeting FC5 only - the pango wrapper needs fontconfig too new for FC4, the library itself builds on FC4 but AFAIK nothing exists for Linux that wants to make use of the library itself.

There's an rpmlint error on the src.rpm -

E: silgraphite hardcoded-library-path in ../../lib/.libs

That's because the pango wrapper uses the silgraphite headers/libs - so to build it in same packaging run, I did the following:

pushd wrappers/pangographite
sh autogen.sh

export CXXFLAGS="%{optflags} -I../../include -L../../lib/.libs"

%configure --disable-static
make %{?_smp_mflags}

If there's a better way to do it such that rpmlint is happy, I don't know it.
Comment 1 Michael A. Peters 2005-12-27 18:09:16 EST
used patch suggested by upstream for g++ 4.1.0 explicit issue

Comment 3 Roozbeh Pournader 2006-01-08 05:17:31 EST
As far as I can tell from http://fedoraproject.org/wiki/PackageNamingGuidelines,
the release macros should use a format like the following, instead of what you
are currently using:

%define         svn_date 2006MMDD (replace MMDD with real dates)
%define         alphatag 11.%{svn_rev}svn

and then, from what I deduce from http://fedoraproject.org/wiki/DistTag, the
release tag itself should be like this:

Release:        0.%{alphatag}%{?dist}
Comment 4 Michael A. Peters 2006-01-08 06:42:51 EST
I don't use YYYYMMDD (I did initially) because the svn release is a lot more

The reviewer can do an svn co of the exact svn co used in the src.rpm and thus
can check against upstream with a diff.

It's also easier to report bugs upstream if the svn co revision is known.

I have no problem moving the svn to after the %{svn_rev} though.

With respect to placement of the dist tag - in this case it probably doesn't
matter because this package will not build on FC4 (dependencies not met), but if
the dist tag is before the alphatag - a build for an older distro won't ever
look newer to rpm. This could potentially be a problem if a newer svn release
fails to build in a newer core release, and the user upgrades. Having the
%{?dist} tag before the %{alphatag} means that yum would still upgrade the
package, even though the %{alphatag} was older, thus ensuring the user has a
package built against the right libraries.

That's my reasoning anyway. Again, it doesn't really matter that much for this
package since it requires rawhide anyway (due to fontconfig version).

There's also precedent for putting stuff after %{?dist}

foobar-3.fc3 foobar-3.fc4 foobar-3.fc5

Bug report for foobar in fc3 - bug does not affect fc4/fc5
When fixing the fc-3 issue, you would out a .1 - making it foobar-3.fc3.1 so
that you don't need to push useless updates in fc4/fc5

Essenstially that's what I'm doing - it's foobar-0.%{?dist} and the %{alphatag}
is equivalent to the .1
Comment 8 Michael A. Peters 2006-03-14 09:45:28 EST
updated svn co
patch no longer required to build will gcc 4.1.0

Comment 9 John Reiser 2006-03-14 13:50:01 EST
Responding to request in fedora-test-list of today:
     5) use the sil.txt file on the http://mpeters.us/silgraphite/ page
        (link at bottom).   Opening the file with gedit, it should look
        like the lower image.

I got to step 5 on x86_64, but my system with 1GB RAM slowed to a crawl before
gedit could finish starting.  /usr/bin/top showed:
   19771 jreiser   26  10 2773m 859m 2792 D  8.3 85.8   0:03.61 gedit
so that's a 2.7GB process (with 859MB of resident RAM) for a 61-byte input file
sil.txt, and there was no display yet from gedit after a couple minutes of waiting.

Specific .rpms:
   pango-1.12.0-1  (both i386 and x86_64)
Comment 10 John Reiser 2006-03-14 14:54:21 EST
I got to step 5 on ppc (32-bit Apple Macintosh Mini) with success: gedit
displays the same picture as the lower image on the web page.

$ ps axl | grep gedit
0   500  2488  2470  15   0  72184 23992 sys_po S+   pts/2      0:01 gedit

Specific .rpms:
Comment 11 Michael A. Peters 2006-03-14 15:54:13 EST
OK - so it looks like it works with ppc, there may be a missing BuildRequires
(which might explain the build failure reported on list) and a massive memory
leak on x86_64.
Comment 12 Michael A. Peters 2006-03-14 18:48:24 EST
updated (added missing BuildRequires so it builds in x86 mock)

Comment 13 Michael A. Peters 2006-04-19 13:32:08 EDT
This is almost official release from upstream.
The tarball is not generated with make dist, it is generated with ViewVC from



New src.rpm:
New spec file:

The alphatag stuff is gone because this is not a CVS checkout but is a upstream
sanctioned release. If it is brought into Extras, the dist tag will be added
again to differentiate from (and replace) the upstream rpms.
Comment 14 Jason Tibbitts 2006-06-26 18:57:37 EDT
So this ticket has been around for a really long time and I'd like to see it
either move forward or be closed.

So, is this package ready?  Is there anything intrinsic to the package that
would keep it out?  Michael's page indicates a notable crash with Firefox which
could be problematic; is it bad enough that this package should be held until
that works?

It looks like all of the necessary infrastructure is in place and is already
being used; this package just drops some more pango modules in place.  The spec
is a bit ugly and some of the installation gymnastics are a bit nasty but I
don't know enough about the underlying issues to say whether it has to be that way.
Comment 15 Michael A. Peters 2006-06-27 06:49:14 EDT
The gymnastics are unfortunately necessary because pango does not do multilib

An /etc/pango/pangorc is used to tell pango where additional modules are.
Unfortunately both 32 bit and 64 bit pango look for the same file. So if you
have 64-bit linux and have installed 32-bit firefox, that would pull in 32-bit
pango - and the /etc/pango/pangorc file can only be correct for 32 bit or 64
bit, it can't be correct for both because of /usr/lib64 vs /usr/lib.

pango upstream seems to be at disagreement with silgraphite, they think
silgraphite should install the pango modules in the top level pango module
directory. But the silgraphite coders need to make sure that their modules are
loaded after the core pango modules. From what I understand, upstream pango
considers that to be a design bug.

My understanding is that a future version of upstream pango is going to do this
better so that even with what they consider to be a "design bug" in silgraphite,
multilib will be handled better.

Both 32 and 64 bit pango looking at the same config file with full path
%{_libdir} in it is definitely wrong and they apparently are addressing that.
Comment 16 Jason Tibbitts 2006-06-27 14:27:46 EDT
So I guess the fundamental question is whether this package gets added now or
whether we wait for changes to pango.  You're the maintainer and I'm happy to
leave that decision to you; the situation I want to avoid is that future changes
in core libraries break because this package is installed.  Do you see any
chance of that happening?
Comment 17 Michael A. Peters 2006-06-27 16:57:04 EDT
Yeah there's a good chance future pango would break it - this probably should be
closed for now and re-opened later when the multilib pango issue is resolved.

Apparently there are some OO.o guys looking at using the library in OO.o so I
wouldn't be surprised if the library itself popped into rawhide at some point in
the future from a RH developer (with or without the pango module).

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