Spec URL: http://www.haxxed.com/rpms/secondlife/xmlrpc-epi.spec SRPM URL: http://www.haxxed.com/rpms/secondlife/xmlrpc-epi-0.51-1.src.rpm Description: An implementation of the xmlrpc protocol in C. This library is required by the Second Life client.
http://www.haxxed.com/rpms/secondlife/xmlrpc-epi.spec http://www.haxxed.com/rpms/secondlife/xmlrpc-epi-0.51-2.src.rpm * Tue Mar 13 2007 Callum Lerwick <seg> 0.51-2 - Ooops, the use-system-expat patch was completely broken. Fixed.
Conflicts with xmlrpc-c-devel? Installing packages (4): xmlrpc-epi-0.51-2@x86_64 xmlrpc-epi-devel-0.51-2@x86_64 xmlrpc-epi-debuginfo-0.51-2@x86_64 xmlrpc-epi-examples-0.51-2@x86_64 206.9kB of package files are needed. 730.5kB will be used. Confirm changes? (Y/n): y Committing transaction... error: file /usr/lib64/libxmlrpc.so from install of xmlrpc-epi-devel-0.51-2 conflicts with file from package xmlrpc-c-devel-1.06.11-2.fc6
(In reply to comment #2) > Conflicts with xmlrpc-c-devel? > > Installing packages (4): > xmlrpc-epi-0.51-2@x86_64 xmlrpc-epi-devel-0.51-2@x86_64 > xmlrpc-epi-debuginfo-0.51-2@x86_64 xmlrpc-epi-examples-0.51-2@x86_64 > > 206.9kB of package files are needed. 730.5kB will be used. > > Confirm changes? (Y/n): y > > Committing transaction... > > error: file /usr/lib64/libxmlrpc.so from install of xmlrpc-epi-devel-0.51-2 > conflicts with file from package xmlrpc-c-devel-1.06.11-2.fc6 > Hmm, nasty. Well as xmlrpc-c is I would like to suggest that you rename the lib (and its soname to libxmlrpc-epi.so.X . Can you provide a new package with this fixed? Then I'll do a full review for you. I just rea today that mandrake wants to include the second life client in their next release and I want to beat them to it by having it readuy for Fedora 7 :) So let me know if you need any help with openjpeg or the client itself.
Yeah I noticed spot fixed that in his package but I was getting confused as to why I wasn't hitting it and backburnered it in favor of other bugs. :) I'll fix this in the next round of compiles...
http://www.haxxed.com/rpms/secondlife/xmlrpc-epi.spec http://www.haxxed.com/rpms/secondlife/xmlrpc-epi-0.51-3.src.rpm * Sat May 26 2007 Callum Lerwick <seg> 0.51-3 - Rename the library so we don't conflict with xmlrpc-c.
Created attachment 155533 [details] PATCH: fix 64 bit warnings MUST: ===== * rpmlint output is: * Package and spec file named appropriately * Packaged according to packaging guidelines * License ok * spec file is legible and in Am. English. * Source matches upstream * Compiles and builds on devel x86_64 * BR: ok * No locales * ldconfig properly run for shared libraries * Not relocatable * Package owns / or requires all dirs * No duplicate files & Permissions * %clean & macro usage OK * Contains code only * %doc does not affect runtime, and isn't large enough to warrent a sub package * -devel as package needed * no .desktop file required Must Fix: --------- * Main package group should be System Environment/Libraries, Development/Libraries is only for -devel sub packages. * There are a few 64 bit related warning, please apply the attached patch to fix this. Also in general you may want to take a stab at fixing some of the other compiler warnings, esp. the missing prototypes ones. * Change license to BSD-ish (it isn't the real BSD license) Should Fix: ----------- * Change Source0 URL from: Source0: http://dl.sf.net/sourceforge/xmlrpc-epi/xmlrpc-epi-%{version}.tar.gz To the (new guidelines adviced one): http://downloads.sourceforge.net/%{name}/%{name}-%{version}.tar.gz Notice that the current one doesn't work for me (spectool -g) * Move NEWS to main package %doc, remove now empty %doc from devel * remove empty %doc from examples %files
ping?
ping again?
ping again??
Well, what should we do with this review request?
It's needed for Second Life. I'm currently concentrating on OpenJPEG, but I've been busy with various RL issues. I'll get back to it... eventually. :P
i tried looking up the license and it only shows up on one page in google at http://www.thepromisedlan.org/flatnuke/sections/Download/Freedom/LICENSE-libraries-linux.txt under "xmlrpc-epi license". i'm not sure if this is can be packaged in fedora based on the license, and if it can, what do we call it? (the license also shows up at http://xmlrpc-epi.sourceforge.net/main.php?t=license ) i'm assuming the reason it was considered "BSD" before was because that is what it is considered on the sf.net project home page. i'm not sure where to make an upstream inquiry, their devel list on sf.net has turned into a spam list.
(In reply to comment #13) > i tried looking up the license and it only shows up on one page in google at > http://www.thepromisedlan.org/flatnuke/sections/Download/Freedom/LICENSE-libraries-linux.txt > under "xmlrpc-epi license". i'm not sure if this is can be packaged in fedora > based on the license, and if it can, what do we call it? > The license listed here: http://xmlrpc-epi.sourceforge.net/main.php?t=license Is perfectly fine, what makes you unsure about this? Its just a variant of the MIT license, and as such we will call it MIT, more specific see: http://fedoraproject.org/wiki/Licensing/MIT And then do a word for word comparision between the xmlrpc-epi and the "Modern Style with sublicense" MIT variant. Notice how they are almost 100% the same?
two other thoughts -- 1. should all of the subpackages have the same documentation files, or are we going to consider that redundant? rpmlint complains about there being no documentation in the subpackages. 2. *-examples installs the examples in %{_bindir}, and the examples have relatively generic names. this seems like it could potentially cause conflicts with other packages. shouldn't they be store within %doc, inside an EXAMPLES directory or the like?
Callum, ping?
callum: have you made further progress ? would you like some patches to address the above issues ?
(In reply to comment #17) > callum: have you made further progress ? > would you like some patches to address the above issues ? David, maybe you are interested in picking this up? Callum seems to be spending most if its time working on secondlife itself (mostly upstream).
Hrm, I tried to post something earlier but bugzilla was b0rked at the time. I've been in contact with some Debian people (who are working on packaging Second Life for Debian) who have decided to take over upstream xmlrpc-epi maintenance since the previous upstream is quite dead. They've been able to get access to the Sourceforge project and it looks like they released a 0.52 tarball which should have all the current needed patches merged. They also pointed out PHP is carrying a private copy of xmlrpc-epi, they're working on merging in the PHP changes (Which seems to consist of the same fixes everyone else needs anyway) so PHP can be built against an external copy. Fedora policy dictates we do likewise when this package is accepted, so I guess we need to get the PHP maintainers in on this review... I suggest reading through their ITP: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=413986 I suppose if someone really wants to take this package over, I wouldn't mind. I already have my work cut out for me with the Second Life client itself... :) Also of note, there was a rather vague message from a Linden Lab developer saying xmlrpc is being phased out: https://lists.secondlife.com/pipermail/sldev/2008-March/008733.html Which would seem to imply the use of xmlrpc-epi in the SL client may be discontinued at some point in the hand-wavey future.
I'd like to take this package over.
Bryan: I haven't done any further work on this. In my understanding, the reporter of a review request needs to be the eventual package maintainer. As such I would propose you begin a new review request bug, improving upon the .spec posted in this bug, and marking this review request as closed - duplicate of the new bug.
Re-assigning this to nobody, iow throwing it back into the review queue, I'm done with this ticket, its a real shame as it would be really nice to get the secondlife client into Fedora.
I don't understand why this is back in the queue instead of just being closed. Without a package to review and a submitter to make one, an open review ticket is completely pointless. Bryan, if you want to submit an xmlrpc-epi package, please do so in another ticket when you're ready.
*** This bug has been marked as a duplicate of bug 539388 ***