Spec URL: http://spotbox.dyn.dhs.org/telepathy-glib.spec SRPM URL: http://spotbox.dyn.dhs.org/telepathy-glib-0.5.13-1.fc7.src.rpm Description: GLib binding for the Telepathy D-Bus protocol.
Created attachment 156268 [details] Mock build log for telepathy-glib
The docs should be spun in a separate package IMHO
also unless a fortran numeric program depends on it the static bit should be killed
(In reply to comment #3) > also unless a fortran numeric program depends on it the static bit should be killed The static libraries have to stay, since there are no shared libraries for those functions.
but are they used by something and has this something been asked to use dynlinking instead?
(In reply to comment #5) > but are they used by something and has this something been asked to use > dynlinking instead? Yes, it is used by several telepathy connection managers (idle & gabble off the top of my head). And the reason it's static is that it's api is still changing as noted by the unstable name.
*** Bug 244482 has been marked as a duplicate of this bug. ***
OLPC needs the static bits as they enable things like TUBES!!! which we heavly use. The only comment I have is the unstable header files should be included with the static bits since they are a BuildRequires not a Requires. Unstable bits should have to be explictly requested in a package and not gotten mearly by having a BR on -devel. Please remeber to create an OLPC-2 branch when this is approved since we may be updating this package quite a bit. Also this is important for OLPC so I am upping the priority. Thanks.
(In reply to comment #6) > Yes, it is used by several telepathy connection managers (idle & gabble off the > top of my head). And the reason it's static is that it's api is still changing > as noted by the unstable name. Well the telepathy guys should just move those bits to a telepathy-glib-unstable lib, and bump its version every time they do a release. They can play the static game but I don't have to review the result (you'll probably find another reviewer though)
Spec URL: http://spotbox.dyn.dhs.org/telepathy-glib.spec SRPM URL: http://spotbox.dyn.dhs.org/telepathy-glib-0.5.13-2.fc7.src.rpm Updated spec based on J5's comments.
Some rpmlint noise: W: telepathy-glib mixed-use-of-spaces-and-tabs (spaces: line 1, tab: line 14) This is not really a problem; fix it if you like. W: telepathy-glib unused-direct-shlib-dependency /usr/lib64/libtelepathy-glib.so.0.2.0 /lib64/libdbus-1.so.3 My understanding is that this is merely an inefficiency, and not a real one at that because dbus is going to be there in any case. So I don't think it's a blocker. W: telepathy-glib-devel no-documentation W: telepathy-glib-unstable-static no-documentation On their surface these are OK, but t does beg the question of whether %{_datadir}/gtk-doc/html/%{name}/ in the -devel subpackage should be %doc or not. There's a test suite included; I added a simple %check section: %check make check and it seemed to run fine. Any reason not to run it? Regarding the static library issue, I don't think that there's any reason to believe that upstream won't drop the static library as soon as they have a stable API. Review: * source files match upstream: b65afe985035b2fe88aeda82bb012fb9c40babbcd78b0043c03e32a943625014 telepathy-glib-0.5.13.tar.gz * package meets naming and versioning guidelines. * specfile is properly named, is cleanly written and uses macros consistently. * summary is OK. * description is OK. * dist tag is present. * build root is OK. * license field matches the actual license. * license is open source-compatible. * license text included in package. * latest version is being packaged. * BuildRequires are proper. * compiler flags are appropriate. * %clean is present. * package builds in mock (development, x86_64). * package installs properly * debuginfo package looks complete. ? rpmlint has one questionable issue (%doc for gtk-doc directory) * final provides and requires are sane: telepathy-glib-0.5.13-2.fc8.x86_64.rpm libtelepathy-glib.so.0()(64bit) telepathy-glib = 0.5.13-2.fc8 = /sbin/ldconfig libdbus-1.so.3()(64bit) libdbus-glib-1.so.2()(64bit) libglib-2.0.so.0()(64bit) libgobject-2.0.so.0()(64bit) libtelepathy-glib.so.0()(64bit) telepathy-glib-devel-0.5.13-2.fc8.x86_64.rpm telepathy-glib-devel = 0.5.13-2.fc8 = dbus-devel dbus-glib-devel libtelepathy-glib.so.0()(64bit) pkgconfig telepathy-filesystem telepathy-glib = 0.5.13-2.fc8 telepathy-glib-unstable-static-0.5.13-2.fc8.x86_64.rpm telepathy-glib-unstable-static = 0.5.13-2.fc8 = pkgconfig telepathy-glib = 0.5.13-2.fc8 telepathy-glib-devel = 0.5.13-2.fc8 X %check is not present, but there seems to be a runnable test suite. * no shared libraries present; ldconfig called as necessary. * owns the directories it creates. * doesn't own any directories it shouldn't. * no duplicates in %files. * file permissions are appropriate. * scriptlets OK (ldconfig) * code, not content. * documentation is in -devel subpackage and isn't excessively large. * %docs are not necessary for the proper functioning of the package. * headers are in -devel (or -static-unstable) package. * pkgconfig files present in -devel or -static* packages; pkgconfig dependency is there. * static library is in -static* package. * no libtool .la files.
Spec URL: http://spotbox.dyn.dhs.org/telepathy-glib.spec SRPM URL: http://spotbox.dyn.dhs.org/telepathy-glib-0.5.13-3.fc7.src.rpm * Mon Jun 18 2007 Brian Pepple <bpepple> - 0.5.13-3 - Add check section to run test suite. - Mark gtk-docs as docs.
OK, looks good to me. The test suite passes with no issues: PASS: test-handle-set PASS: test-heap PASS: test-intset Testing tp_strdiff... ... OK Testing tp_g_ptr_array_contains... ... OK Testing tp_escape_as_identifier... ... OK PASS: test-util PASS: test-internal-debug ================== All 5 tests passed ================== APPROVED
New Package CVS Request ======================= Package Name: telepathy-glib Short Description: GLib bindings for Telepathy Owners: bdpepple,johnp Branches: F-7,OLPC-2 InitialCC: Tibbs, thanks for the review.
cvs done. Note that the bugzilla sync process isn't yet caught up to the merge of core and extras components, so it might not be until tomorrow for this to have a bugzilla component.
Imported & tagged for each branch in CVS. Built devel & F-7 branches. will leave the olpc branch for J5 to build.
Package Change Request ====================== Package Name: telepathy-glib New Branches: F-8
cvs done.
New Package CVS Request ======================= Package Name: telepathy-glib Short Description: GLib bindings for Telepathy Owners: morgan.collett, tomeu Branches: OLPC-3
Package Change Request ====================== Package Name: telepathy-glib New Branches: EL-6 Owners: pbrobinson sdz
Have you checked with Brian to see if he would like to maintain this in EPEL?
Package Change Request ====================== Package Name: telepathy-glib New Branches: EL-6 Owners: pbrobinson sdz bpepple I emailed Brian and he said that it would probably be better if someone else maintained the EPEL branches, since he's not currently running any systems that use EPEL. If you need additional confirmation, can you comment here please, Brian? For background, we're interested in maintaining these in EPEL since they are dependencies of the Sugar Environment, which we're trying to push into EPEL.
Argh, I'm being stupid. Setting fedora-cvs instead of fedora-review. Sorry for the noise.
CVS done (by process-cvs-requests.py).