SRPM URL: http://www.environnement.ens.fr/perso/dumas/fc-srpms/xbae-4.60.2-1.src.rpm Description: XbaeMatrix is a free Motif(R) table widget (also compatible with the free LessTif) which presents an editable array of string data to the user in a scrollable table similar to a spreadsheet. The rows and columns of the Matrix may optionally be labelled. A number of "fixed" and "trailing fixed" rows or columns may be specified. The XbaeCaption widget is a simple Motif manager widget that associates a label with a child. In addition the XbaeInput widget is being distributed, a text input field that provides generic customised data entry and formatting for strings.
Once/if this package is accepted grace may be rebuilt against it, I tested that grace builds against the exterenal Xbae, but not that it runs.
I packaged version 4.60.4 and submitted it for review https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=193772 and just now saw your submission. I used the spec file that came with the xbae that used to be in fedora 1. Not sure what to do about these duplicates. Tobias.
*** Bug 193772 has been marked as a duplicate of this bug. ***
srpm for the new version, with the .m4 file packaged and new summary http://www.environnement.ens.fr/perso/dumas/fc-srpms/xbae-4.60.4-1.src.rpm
Updated srpm, such that xbae don't depend on Wcl http://www.environnement.ens.fr/perso/dumas/fc-srpms/xbae.spec http://www.environnement.ens.fr/perso/dumas/fc-srpms/xbae-4.60.4-2.src.rpm - remove dependency on Wcl-devel (was only of use for an example) - clean docs
I will review this package. One question before starting, why do we need automake? # for the aclocal directory Requires: automake I am aware that automake is not as bad as autoconf, or is the other way around... ;-)
It is for the aclocal directory detection which is done by calling aclocal which is part of automake. Moreover /usr/share/aclocal/ is in that package.
You are right, my mistake. The issue I was addressing relates with automake as BuildRequires and not Requires. I was wrong, apologies for that. Here I get: $ rpm -qf /usr/share/aclocal/ libXaw-devel-1.0.1-1.2 automake-1.9.6-2 and $ rpm -q --requires libXaw-devel libXaw = 1.0.1-1.2 libXmu-devel rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 xorg-x11-filesystem >= 0.99.2-3 So it seems that libXaw-devel is claiming /usr/share/aclocal/ wrongly. I should probably fill this as a packaging bug.
New version http://www.environnement.ens.fr/perso/dumas/fc-srpms/xbae-4.60.4-3.src.rpm - rebuild against lesstif - add Obsolete/Provides for Xbae As a side note, I think that grace won't have to be modified otherwise than BuildRequiring xbae-devel instead of openmotif-devel once xbae is in, to switch to using lesstif.
What is the motivation for switching from openmotif to lesstif? From my experience lesstif is more buggy than openmotif. Tobias
You could have a look at Bug #202527, in short openmotif isn't OSI compatible, this conflicts with fedora goals. There are many threads on mailing lists also if you want further references.
Review for release 3: * RPM name is OK * Source xbae-4.60.4.tar.gz is the same as upstream * This is the latest version * Builds fine in mock * rpmlint of xbae looks OK * rpmlint of xbae-devel looks OK * File list of xbae looks OK * File list of xbae-devel looks OK * License is OK (BSD), text in %doc, matches source * Spec is readable and written in American English * no missing BR * no unnecessary BR Notes: Any reason for Obsoletes: Xbae < %{version}-%{release}
(In reply to comment #12) > Review for release 3: > > Notes: > Any reason for > Obsoletes: Xbae < %{version}-%{release} It is to replace Xbae packages that have been provided up to fedora core 2.
Ah, I see now. What I did not notice the first time is that Xbae is a capitalized version of xbae. That is why it was weird. You could add a comment there saying this, it is easier to understand that way. * there are no duplicates in %files and all the directories are owned * scripts are reasonable and according to the rules * there are no static libraries * there are no language specific files * there is no need for a desktop file * follows the packaging guidelines APPROVED
Built in devel, added to owners. Do you want a branch for FC5 for grace? Otherwise I don't think it is necessary to have a FC5 branch, since there hasn't been xbae since FC1, without anybody complaining...
Please do. I would like, as far as possible, to maintain the same spec for different version. Thank you.
Done.