Bug 630681 - Review Request: lasem - SVG and MathML rendering library
Review Request: lasem - SVG and MathML rendering library
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Dmitrij S. Kryzhevich
Fedora Extras Quality Assurance
:
Depends On:
Blocks: FE-DEADREVIEW 630683
  Show dependency treegraph
 
Reported: 2010-09-06 13:30 EDT by Owen Taylor
Modified: 2012-12-11 18:16 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-12-11 18:16:38 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Owen Taylor 2010-09-06 13:30:24 EDT
Spec URL: http://people.fedoraproject.org/~otaylor/lasem.spec
SRPM URL: http://people.fedoraproject.org/~otaylor/lasem-0.3.0-1.fc13.src.rpm
Description:

Lasem is a library for rendering SVG and MathML, implementing a DOM like
API. It's based on GObject and uses Pango and Cairo for the rendering. 

There's a neat Reinteract extension that uses lasem and pylasem to render Sympy output as math, which is why I created this package. (https://bugzilla.gnome.org/show_bug.cgi?id=628491)

Very simple package. Only complexity here is that it builds with gobject-introspection and the introspection files it depends upon (Pango, etc.) moved from gir-repository into the respective packages in Fedora 14. Hence the conditionals.

lasemrender is in a -tools subpackage to avoid creating a multilib conflict. I'm not completely sure where it is in the spectrum between useful tool and demo program.
Comment 1 Dmitrij S. Kryzhevich 2010-11-02 04:17:39 EDT
You hadn't run rpmlint.
If you did, you would find:

>lasem-tools.x86_64: W: non-standard-group System environment/Libraries

Must be: "System Environment/Libraries"

>lasem.x86_64: W: shared-lib-calls-exit /usr/lib64/liblasem-0.4.so.3.0.0 exit@GLIBC_2.2.5

It says by itself, needs to be fixed.

>lasem-tools.x86_64: E: binary-or-shlib-defines-rpath /usr/bin/lasemrender ['/usr/lib64']

Look at https://fedoraproject.org/wiki/Packaging:Guidelines#Beware_of_Rpath

Source0 URL had changed to http://ftp.gnome.org/pub/GNOME/sources/lasem/0.3/%{name}-%{version}.tar.bz2 .

>lasem-tools.x86_64: W: no-manual-page-for-binary lasemrender

Try to follow https://fedoraproject.org/wiki/Packaging:Guidelines#Man_pages, if possible.
Comment 2 Dmitrij S. Kryzhevich 2010-11-02 07:39:38 EDT
On the second sight, itex2mml seems to be stand-along project. On http://golem.ph.utexas.edu/~distler/blog/itex2MML.html there is a new version of it available. According to https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries itex2MML needs to be packaged separately, and lasem - patched to force usage of it.
Comment 3 Orion Poplawski 2010-11-03 11:56:51 EDT
(In reply to comment #1)
> >lasem.x86_64: W: shared-lib-calls-exit /usr/lib64/liblasem-0.4.so.3.0.0 exit@GLIBC_2.2.5
> 
> It says by itself, needs to be fixed.
> 

$ rpmlint -I shared-lib-calls-exit
shared-lib-calls-exit:
This library package calls exit() or _exit(), probably in a non-fork()
context. Doing so from a library is strongly discouraged - when a library
function calls exit(), it prevents the calling program from handling the
error, reporting it to the user, closing files properly, and cleaning up any
state that the program has. It is preferred for the library to return an
actual error code and let the calling program decide how to handle the
situation.

--

My take - while upstream should be contacted and exit() probably should be removed, this is not a blocker.

> >lasem-tools.x86_64: W: no-manual-page-for-binary lasemrender
> 
> Try to follow https://fedoraproject.org/wiki/Packaging:Guidelines#Man_pages, if
> possible.

Same here.
Comment 4 Dmitrij S. Kryzhevich 2010-11-03 12:40:20 EDT
As for me, itex2MML is a blocker. If Owen Taylor have a trouble with it, I of cause will try to resolve this issue by myself.

>while upstream should be contacted and exit() probably should be
removed, this is not a blocker.

Any examples of other package? If so, I agree - it is not a blocker.

>Same here.

Sure. No man page is not a blocker, it is what I mean by phrase "if possible".
Comment 5 Orion Poplawski 2010-11-03 13:00:33 EDT
(In reply to comment #4)
> As for me, itex2MML is a blocker. 

Definitely.

> >while upstream should be contacted and exit() probably should be
> removed, this is not a blocker.
> 
> Any examples of other package? If so, I agree - it is not a blocker.

hdf5, which I maintain :), and netcdf.  Historical reasons at this point, and in at least one case it is called only in rare, specific cases, not as part of general use.
Comment 6 Dmitrij S. Kryzhevich 2010-11-03 13:15:37 EDT
>Historical reasons at this point, and in at least one case it is called only in rare, specific cases, not as part of general use.

I want to know upstream position on this question still. If it will be silence (for a rational amount of time) or willing to leave all as it is, it will be not a blocker.
Comment 7 Owen Taylor 2010-11-03 13:26:05 EDT
Just to say that if someone else is interested in this package and wants to take it over, that would be fine with me. Dealing with this isn't very high on my radar at the moment and it could easily be 6 months until I get back to this.

In terms of the notes above:

 * Fixing the rpath would be good. Weird that it ended up with one.... thought the build setup was pretty standard.
 * The 'library calls exit' stuff is just a pet-peeve of the rpmlint maintainer or something. I don't consider it to have any relevance to Fedora packaging. Haven't particularly evaluated the details for this package, but in every previous places I've encountered it, patching out the call would be a very odd thing to do in a Fedora package, and would often make the Fedora library incompatible with the upstream library.
 * I think man pages are only interesting if you write a real useful one and send it upstream. While that is never a bad thing to do, I consider it pretty much independent from the packaging process.
 * Haven't looked into itex2mml ... if it's something that can be packaged separately, sounds reasonable.
Comment 8 Dmitrij S. Kryzhevich 2010-11-04 01:59:58 EDT
I went throught the sources and I drop the "exit" issue. This call is in itex2mml code.
Comment 9 Miroslav Suchý 2012-12-11 18:16:38 EST
Closing per #7 and time passed from this comment.

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