Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=489564 --- Comment #16 from Christian Krause <chkr@xxxxxxxxxxx> 2009-03-15 18:32:50 EDT --- Hi, Here is now a more detailed review of Juan's last package with the patch added by Rajeesh. We've already worked on this package for quite some time to make it fulfill the requirements, so I've used Juan's package as base. I've investigated the build problem and it is caused by the following: Python (similar to perl) uses two directories for vendor specific data: - %{python_sitearch} (architecture specific, usually shared objects) - %{python_sitelib} (architecture-independend *.py files) Since both directories point to the same dir on x86 (/usr/lib/python2.5/site-packages) but differ on x86_64 systems (/usr/lib/python2.6/site-packages for noarch and /usr/lib64/python2.6/site-packages for arch-sepcific files). This will cause problems if only %{python_sitearch} is used and so they must be used both - please see my spec file (attached to the bug) and http://fedoraproject.org/wiki/Packaging/Python for details. The spec file I've attached builds on all architectures in F11. It would be good to go further using this one. ;-) https://koji.fedoraproject.org/koji/taskinfo?taskID=1242586 I've changed the build requirements so that it builds and I've changed the deletion of the *.la and *.a file. Just a hint: even in this case there was no harm, but if you know, that you only want to delete files with rm, please don't use the '-r' switch. Here is a more detailed review (of Juan's package with Rajeesh's patch and my small modifications of the spec file - it is attached to this bug). Please note, that I cannot sponsor you, since I'm quite new here, too. * rpmlint: OK rpmlint SPECS/blueman.spec RPMS/i386/blueman-1.02-6.fc10.i386.rpm RPMS/i386/blueman-debuginfo-1.02-6.fc10.i386.rpm SRPMS/blueman-1.02-6.fc10.src.rpm 3 packages and 1 specfiles checked; 0 errors, 0 warnings. * naming: OK * spec file name matches %{name}: OK * License: for the code it seems OK (GPL3 COPYING file, *.c files and a couple of python files refer to GPLv3+, no direct indication of a different license), but the svg icons are GPL2.0 * License packaged: OK * Source0: OK (matches upstream, spectool -g works): 7f66f569a716f8c6fce9360176166eac blueman-1.02.tar.gz * package builds in F11 on all archs: https://koji.fedoraproject.org/koji/taskinfo?taskID=1242586 * build requirements: OK * locale handling: OK, %{find_lang} is used * ldconfig: OK (n/a, since no libraries in linker's default paths) * dir ownership: TODO - since it places files into %{_datadir}/gnome/autostart the package should require gnome-session which owns this directory - same applies to %{_datadir}/PolicyKit/policy/org.blueman.policy -> PolicyKit should be required - the following two entries would cause that "/usr/share/blueman" would not have a proper owner: %{_datadir}/%{name}/icons/hicolor/* %{_datadir}/%{name}/ui/*.ui -> you have to use %{_datadir}/%{name}/ instead (so that all files below including /usr/share/blueman belong to the package) * files not listed twice: OK * file permssions: OK * rm -rf $RPM_BUILD_ROOT in %install and %clean: OK * macro usage: OK, probably %{python_sitelib}/blueman can be changed to %{python_sitelib}/%{name} * code vs. content: no content besides some icons * large docu: OK (n/a) * %doc: OK * header files / static libs: OK (n/a) * pkgconfig files: OK (n/a) * shared libs: OK (n/a) * *.la, *.a files: OK (deleted in %install) * desktop-file: TODO - update-desktop-database not needed any more * gtk-update-icon-cache: TODO - the directories must be "touch"ed before gtk-update-icon-cache runs - the preferred usage is now in Fedora: %post touch --no-create %{_datadir}/icons/hicolor &>/dev/null || : %postun if [ $1 -eq 0 ] ; then touch --no-create %{_datadir}/icons/hicolor &>/dev/null gtk-update-icon-cache %{_datadir}/icons/hicolor &>/dev/null || : fi %posttrans gtk-update-icon-cache %{_datadir}/icons/hicolor &>/dev/null || : * patches: TODO - since the package contains now an upstream patch, it is necessary to add a comment about the status of the patch (e.g. was it already committed upstream, is there a corresponding bug report upstream, etc.) (see: http://fedoraproject.org/wiki/Packaging:Guidelines -> All Patches should have an upstream bug link or commnet) * compiler flags: OK (rpmoptflags used) * debuginfo complete: OK * functional check: TODO - I did just installed the package and tried to use it, but without much success. Please can you give me some easy to reproduce use-cases? - As far as I know bluez-gnome and gnome-bluetooth provide similar functionality. How do these packages interact? Which are necessary? Are they mutual exclusive? It would be great if you could give me some insights about this... Best regards, Christian -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. _______________________________________________ Fedora-package-review mailing list Fedora-package-review@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-package-review