Spec URL: http://people.fedoraproject.org/~hadess/libgdata/libgdata.spec SRPM URL: http://people.fedoraproject.org/~hadess/libgdata/libgdata-0.1.0-1.fc10.src.rpm Description: libgdata is a GLib-based library for accessing online service APIs using the GData protocol --- most notably, Google's services. It provides APIs to access the common Google services, and has full asynchronous support.
Scratch build at: http://koji.fedoraproject.org/koji/taskinfo?taskID=1271012 This package will replace the python-gdata dependency for Totem, as the YouTube plugin is being replaced by a C version.
Is there really no upstream URL? You probably want to remove the commented URL tag as it seems unrelated. Unfortunately without an upstream site I don't have a clue as to how you find new version of the source. You also get a few rpmlint complaints: libgdata.x86_64: W: no-url-tag libgdata-debuginfo.x86_64: W: no-url-tag libgdata-devel.x86_64: W: no-url-tag which are OK as long as there really isn't some upstream site to point to. Also: libgdata.x86_64: W: unused-direct-shlib-dependency /usr/lib64/libgdata.so.2.0.0 /lib64/libgthread-2.0.so.0 libgdata.x86_64: W: unused-direct-shlib-dependency /usr/lib64/libgdata.so.2.0.0 /lib64/librt.so.1 libgdata.x86_64: W: unused-direct-shlib-dependency /usr/lib64/libgdata.so.2.0.0 /lib64/libgmodule-2.0.so.0 libgdata.x86_64: W: unused-direct-shlib-dependency /usr/lib64/libgdata.so.2.0.0 /lib64/libpthread.so.0 The library is linked against a few things that are not really necessary. This should cause any real problems as those will always be loaded anyway. I don't see where the license is LGPLv2+. The source looks to me as if it's GPLv3+, which might have implications for your planned usage. Unpack the source and grep for 'of the License'. It's true that for whatever bizarre reason, upstream included version 2 of the actual LGPL text, but that has no bearing on the actual license that's on the code. Can you query upstream about this? As far as I can tell, there is a test suite but it makes calls out to network services which must already be set up, so there's no way it could be run during the build process. So really the only must-fix blocker issue I see is the license tag. * source files match upstream. sha256sum: bb19c90e8bb2f1ead0d7f407ba15e2f6b6d8a2a355b263ca9338bf68846a5b72 libgdata-0.1.0.tar.bz2 * 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. X license field does not match the actual license. * license is open source-compatible. * license text not included upstream. ? latest version is being packaged. * BuildRequires are proper. * compiler flags are appropriate. * %clean is present. * package builds in mock (rawhide, x86_64). * package installs properly. * debuginfo package looks complete. * rpmlint has acceptable complaints. * final provides and requires are sane: libgdata-0.1.0-1.fc11.x86_64.rpm libgdata.so.2()(64bit) libgdata = 0.1.0-1.fc11 libgdata(x86-64) = 0.1.0-1.fc11 = /sbin/ldconfig libgdata.so.2()(64bit) libgio-2.0.so.0()(64bit) libglib-2.0.so.0()(64bit) libgmodule-2.0.so.0()(64bit) libgobject-2.0.so.0()(64bit) libgthread-2.0.so.0()(64bit) libsoup-2.4.so.1()(64bit) libxml2.so.2()(64bit) libgdata-devel-0.1.0-1.fc11.x86_64.rpm pkgconfig(libgdata) = 0.1.0 libgdata-devel = 0.1.0-1.fc11 libgdata-devel(x86-64) = 0.1.0-1.fc11 = /usr/bin/pkg-config gtk-doc libgdata = 0.1.0-1.fc11 libgdata.so.2()(64bit) pkgconfig pkgconfig(libsoup-2.4) pkgconfig(libxml-2.0) * %check is not present; included test suite can't be run at build time. * shared libraries installed: ldconfig is called properly. unversioned .so link is in the -devel package. * owns the directories it creates. * doesn't own any directories it shouldn't. * no duplicates in %files. * file permissions are appropriate. * no generically named files. * scriptlets are OK (ldconfig). * code, not content. * documentation is small, so no -doc subpackage is necessary. * %docs are not necessary for the proper functioning of the package. * headers are in the -devel package. * pkgconfig files are in the -devel package, with pkgconfig dependency. * no static libraries. * no libtool .la files. The package review process needs reviewers! If you haven't done any package reviews recently, please consider doing one.
I'm the author of libgdata. I've just released version 0.1.1, which fixes the licencing issues (standardises on LGPLv2.1) and adds a website: http://live.gnome.org/libgdata. Re. test suites, you can run the "general" test program, which makes no network requests (and will continue not to do so, since there are no "general" GData service providers). What do you mean by "network services which must already be set up"?
(In reply to comment #2) > Is there really no upstream URL? You probably want to remove the commented URL > tag as it seems unrelated. Unfortunately without an upstream site I don't > have a clue as to how you find new version of the source. That would be because I asked upstream to make their first release shortly before posting this bug :) > You also get a few > rpmlint complaints: > > libgdata.x86_64: W: no-url-tag > libgdata-debuginfo.x86_64: W: no-url-tag > libgdata-devel.x86_64: W: no-url-tag > which are OK as long as there really isn't some upstream site to point to. > > Also: > libgdata.x86_64: W: unused-direct-shlib-dependency > /usr/lib64/libgdata.so.2.0.0 /lib64/libgthread-2.0.so.0 > libgdata.x86_64: W: unused-direct-shlib-dependency > /usr/lib64/libgdata.so.2.0.0 /lib64/librt.so.1 > libgdata.x86_64: W: unused-direct-shlib-dependency > /usr/lib64/libgdata.so.2.0.0 /lib64/libgmodule-2.0.so.0 > libgdata.x86_64: W: unused-direct-shlib-dependency > /usr/lib64/libgdata.so.2.0.0 /lib64/libpthread.so.0 > The library is linked against a few things that are not really necessary. This > should cause any real problems as those will always be loaded anyway. > > I don't see where the license is LGPLv2+. The source looks to me as if it's > GPLv3+, which might have implications for your planned usage. Unpack the > source and grep for 'of the License'. It's true that for whatever bizarre > reason, upstream included version 2 of the actual LGPL text, but that has no > bearing on the actual license that's on the code. Can you query upstream about > this? LGPLv2+ it is, fixed in 0.1.1 > As far as I can tell, there is a test suite but it makes calls out to network > services which must already be set up, so there's no way it could be run during > the build process. It's not run by default. > So really the only must-fix blocker issue I see is the license tag. > > > * source files match upstream. sha256sum: > bb19c90e8bb2f1ead0d7f407ba15e2f6b6d8a2a355b263ca9338bf68846a5b72 > libgdata-0.1.0.tar.bz2 > * 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. > X license field does not match the actual license. > * license is open source-compatible. > * license text not included upstream. > ? latest version is being packaged. > * BuildRequires are proper. > * compiler flags are appropriate. > * %clean is present. > * package builds in mock (rawhide, x86_64). > * package installs properly. > * debuginfo package looks complete. > * rpmlint has acceptable complaints. > * final provides and requires are sane: > libgdata-0.1.0-1.fc11.x86_64.rpm > libgdata.so.2()(64bit) > libgdata = 0.1.0-1.fc11 > libgdata(x86-64) = 0.1.0-1.fc11 > = > /sbin/ldconfig > libgdata.so.2()(64bit) > libgio-2.0.so.0()(64bit) > libglib-2.0.so.0()(64bit) > libgmodule-2.0.so.0()(64bit) > libgobject-2.0.so.0()(64bit) > libgthread-2.0.so.0()(64bit) > libsoup-2.4.so.1()(64bit) > libxml2.so.2()(64bit) > > libgdata-devel-0.1.0-1.fc11.x86_64.rpm > pkgconfig(libgdata) = 0.1.0 > libgdata-devel = 0.1.0-1.fc11 > libgdata-devel(x86-64) = 0.1.0-1.fc11 > = > /usr/bin/pkg-config > gtk-doc > libgdata = 0.1.0-1.fc11 > libgdata.so.2()(64bit) > pkgconfig > pkgconfig(libsoup-2.4) > pkgconfig(libxml-2.0) > > * %check is not present; included test suite can't be run at build time. > * shared libraries installed: > ldconfig is called properly. > unversioned .so link is in the -devel package. > * owns the directories it creates. > * doesn't own any directories it shouldn't. > * no duplicates in %files. > * file permissions are appropriate. > * no generically named files. > * scriptlets are OK (ldconfig). > * code, not content. > * documentation is small, so no -doc subpackage is necessary. > * %docs are not necessary for the proper functioning of the package. > * headers are in the -devel package. > * pkgconfig files are in the -devel package, with pkgconfig dependency. > * no static libraries. > * no libtool .la files. New version at: http://people.fedoraproject.org/~hadess/libgdata/libgdata.spec http://people.fedoraproject.org/~hadess/libgdata/libgdata-0.1.1-1.fc10.src.rpm
(In reply to comment #3) > What do you mean by "network services which must already be set up"? It looked to me as if it would attempt to connect to a preexisting google account to extract calendar data. I only briefly skimmed the source for the tests so I may have come away with the wrong impression. In any case, the environment in which packages are built for Fedora does not have any reasonable form of network access, so that's right out, but if it's reasonable to run the "general" test then it would be good to do so. I'll look over the updated package.
(In reply to comment #5) > It looked to me as if it would attempt to connect to a preexisting google > account to extract calendar data. I only briefly skimmed the source for the > tests so I may have come away with the wrong impression. It does, but the account username and password are hardcoded, and the account's specially registered for testing purposes, for what it's worth.
OK, this looks good now. However, given that Philip indicates that we can run the general test without network access, I think we should do it. This works for me: %check # Only the general test can be run without network access cd gdata/tests ./general It only seems to test two things, but that's better than testing nothing. If you agree, please consider this approved and add something like that when you import the package.
(In reply to comment #7) > It only seems to test two things, but that's better than testing nothing. If > you agree, please consider this approved and add something like that when you > import the package. None of the test programs are particularly comprehensive yet, but I do plan to improve their coverage.
New Package CVS Request ======================= Package Name: libgdata Short Description: Library for the GData protocol Owners: hadess Branches: F-11 devel InitialCC:
cvs done.
Built in F11 and devel, thanks!