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.
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.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.
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.
(In reply to comment #1) > >lasem.x86_64: W: shared-lib-calls-exit /usr/lib64/liblasem-0.4.so.3.0.0 exit.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.
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".
(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.
>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.
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.
I went throught the sources and I drop the "exit" issue. This call is in itex2mml code.
Closing per #7 and time passed from this comment.